- NANOG - lists.nanog.org

RE: DDOS anecdotes
by Tim Devries 23 Jun '01

23 Jun '01

-----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Saturday, June 23, 2001 4:16 PM To: 'nanog(a)merit.edu' Subject: RE: DDOS anecdotes On Sat, 23 Jun 2001, Tim Devries wrote: > FYI beware of service pack 2. It sets the DF bit so packets cannot > fragment. Particularily offensive if your server is on the other side of a > tunnel (due to the overhead). The solution is to reduce the MTU on the box. > Or use a different OS :) >I thought this was standard behaviour of Microsoft OSes since at least >Win95. I know NT does this as standard, so does Win95 and 98. Win2k does >this standard out of the box (at least last time I checked). I have tested it with sp1 and this behaviour does not occur. I have not tested it without any serverice packs so you may be correct in that regard. Tim Devries Technical Trainer Q9 Networks 100% Uptime

1 0

RE: DDOS anecdotes
by Tim Devries 23 Jun '01

23 Jun '01

-----Original Message----- From: woods(a)weird.com [mailto:woods@weird.com] Sent: Saturday, June 23, 2001 3:56 PM To: nanog(a)merit.edu Subject: RE: DDOS anecdotes [ On Saturday, June 23, 2001 at 20:04:06 (+0200), Mikael Abrahamsson wrote: ] > Subject: RE: DDOS anecdotes > > This is a real problem. It's not FUD. Microsofts choice to include full > IP stack capabilities will make the problem worse, but I do not blame > their IP stack for this like Mr Gibson does though. >No, their stack's not the root of the problem -- all the rest of their >OS is (and of course in particular the security model, or lack thereof). FYI beware of service pack 2. It sets the DF bit so packets cannot fragment. Particularily offensive if your server is on the other side of a tunnel (due to the overhead). The solution is to reduce the MTU on the box. Or use a different OS :) Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

2 1

RE: DDOS anecdotes
by Daniel Senie 23 Jun '01

23 Jun '01

At 02:37 PM 6/23/01, Tim Wilde wrote: > > This is a real problem. It's not FUD. Microsofts choice to include full > > IP stack capabilities will make the problem worse, but I do not blame > > their IP stack for this like Mr Gibson does though. > >Oh, it's most certainly a real problem, but I don't agree that the changes >in Win XP will really make any difference whatsoever. With some very >trivial driver additions, raw sockets can be accessed under any previous >version of Windows, just like in XP. Indeed, there have been LAN analyzers which run on all variants of Windows for a very long time. These can generate / play back traffic, using whatever source IP addresses and MAC addresses were on the original packets. Obviously, a general spoofing tool for Win95 could be written. After reading that part of the tirade, I came to the same conclusion as a previous poster... lots of FUD, and not much more. It's been 5 years since the document now published as RFC 2827 was first a draft. Many sites do ingress or egress filtering. Many don't. Most router equipment can now handle it, according to the manufacturers. Yes, there are issues dealing with multi-homing. However, it appears many attacks still originate from single homed sites, dialup sites, cable modem attached systems, and the like. In most cases, these could be filtered. Has anyone at any of the cable modem vendors made any attempts to try ingress filtering in the cable system head-end routers? Did it work? Need help trying it out? While Ingress filtering will not cure the world, it can help de-fang many attacks. Unfortunately, it requires cooperation to be effective. ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranth.com

5 4

RE: DDOS anecdotes
by Tim Devries 23 Jun '01

23 Jun '01

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Sean M. Doran > Sent: June 23, 2001 11:31 AM > To: nanog(a)merit.edu > Subject: DDOS anecdotes > > > Some of you may find http://grc.com/dos/grcdos.htm > very interesting. The rest of NANOG may, as we do, wonder why Mr. Gibson, after almost naming us in that page (he didn't name _us_ directly, but left enough not-so-subtle hints that both us and our users noticed us being mentioned), chose to brush off our offers to help, claiming instead that he just wanted to move on and forget about the whole thing. (I ought to mention that it took at least a week to get a reply from Mr. Gibson) We ended up concluding that Mr. Gibson's main goal is the distribution of large quantities of FUD. It seems, I might add, that Mr. Gibson is particularly successful at this remarkably valuable art. Vivien -- Can you elaborate further? Tim

2 1

IP Addresses for colocation
by Mark J. Scheller 23 Jun '01

23 Jun '01

Hello NANOG, I'm in the process of evaluating whether to transition away from self-hosting web servers to have them hosted at a colocation facility. The obvious advantages being greater capacities for bandwidth, power, cooling, and oh yes, proper methods of putting out a fire (instead of drowning the servers in water if they so much as overheat). The concern I have is this: if we decide a few months down the road that we don't like this particular colocation facility and wish to move to another one across the street, I'd have to renumber all of my hosts. Is it possible to go to any colocation facility with a block of IP addresses in hand and use them? I'm talking about a /24 here, so I cannot request the addresses directly from ARIN, rather I need to get them from some other source. I attempted to get them from our current bandwidth provider, but they seem to be a little taken aback by my request for a block of addresses that will not be routed by them -- in fact, while writing this they called to tell me they will not provide IP space unless they route to it. Is there a better way to get a /24 that can "go anywhere"? Or should I just justify a /24 at the colocation facility and go through the same process should we decide to change? Is there a way to buy a routable /24? Thanks in advance for any advice, on or off list. I will summarize unless the answer is "you're crazy, such things aren't possible" in which case I'll be off drowning my sorrows at a nearby watering hole. Mark J. Scheller (scheller(a)u1.net)

1 1

The Cidr Report
by Tony Bates 23 Jun '01

23 Jun '01

This is an auto-generated mail on Fri Jun 22 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 22Jun01 0) General Status Table History ------------- Date Prefixes 150601 101429 160601 101413 170601 101455 180601 101185 190601 101168 200601 101266 210601 101030 220601 101078 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11056 Number of ASes announcing only one prefix: 6521 (3719 cidr, 2802 classful) Largest number of cidr routes: 1030 announced by AS701 Largest number of classful routes: 1425 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Jun01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1363 1022 341 25.0% TELSTRA-AS AS701 1425 1226 199 14.0% Alternet AS4755 261 140 121 46.4% Videsh Sanchar Nigam Ltd. Autonom AS4293 398 283 115 28.9% part of AS assignment AS4287 - AS AS6595 157 58 99 63.1% DoD Education Activity Network As AS6429 203 105 98 48.3% ATT LA Internet Chile AS705 238 142 96 40.3% part of AS assignment AS701 - AS7 AS13999 103 11 92 89.3% Mega Cable S.A. de C.V. AS7018 725 642 83 11.4% AT&T WorldNet Service Backbone AS4151 158 77 81 51.3% part of AS assignment AS4151 - AS AS8013 293 218 75 25.6% PSINet Ltd. Canada AS577 250 177 73 29.2% Bell Advanced Communications Inc. AS6471 114 51 63 55.3% ENTEL CHILE S.A. AS3464 152 90 62 40.8% Alabama Research and Education Ne AS724 217 156 61 28.1% part of AS assignment AS721 - AS7 AS7046 303 242 61 20.1% UUNET Technologies, Inc. AS1 591 532 59 10.0% GTE Internetworking AS16758 63 6 57 90.5% IKON Office Solutions AS1239 445 390 55 12.4% SprintLink Backbone AS2149 326 272 54 16.6% PSINET-2 AS3908 203 150 53 26.1% Supernet, Inc. AS226 143 90 53 37.1% Los Nettos AS6413 66 14 52 78.8% Southern Online Systems, Inc. AS4323 236 184 52 22.0% Time Warner Telecom Internet AS5106 94 43 51 54.3% Ameritech Advanced Data Services, AS17561 112 61 51 45.5% Internet service provision to Wes AS9842 54 5 49 90.7% Lotte Data Communication Company AS852 209 161 48 23.0% Telus Advanced Communications AS855 143 97 46 32.2% part of AS assignment AS853 - AS1 AS3602 225 179 46 20.4% Sprint Canada Inc. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: IP Addresses for colocation
by smd＠clock.org 23 Jun '01

23 Jun '01

| The concern I have is this: if we decide a few months down the road that we | don't like this particular colocation facility and wish to move to another one | across the street, I'd have to renumber all of my hosts. So, it's like the DNS has totally stopped working, to the point where there is zero possibility of adding in new A RRs? And the tools that allow centralizatioin of address administration, like DHCP, have also broken down, I guess. I blame the Internet Software Consortium for people wanting to migrate _whole /24s_ instead of doing a renumbering exercise when they shift gear from using one connection to the Internet to another, since obviously their software (like BIND and DHCP) is horribly flawed and unusable. | Is there a better way to get a /24 that can "go anywhere"? You can pay each of the thousands of ISPs whose routing tables will have to carry your prefix in their routing systems... have you considered that? (I'll do it for 100 U.S. dollars, inquire within!) Sean.

3 2

IETF draft on Operator Requirements of Network Management Tools
by Bill Woodcock 23 Jun '01

23 Jun '01

The IETF Operations and Management area held an interim meeting in Phoenix in conjunction with the last NANOG. It was called to address the gulf which has grown between the operator community and the management tools development community. There are clearly un-met needs for network management tools, and tools which haven't found use in operational networks. Randy and Bert want to get the two groups talking again so the management tools folks' time won't be wasted and the operators will get tools they can use. Suzanne Woolf and I have been tasked with producing a draft to document operator requirements of infrastructure management methods. We need to describe the tools, methods, and practices which operators need the management software community to support, in as unambiguous a fashion as possible. There's an email list for discussing the requirements, which you can subscribe to in the usual manner at: ops-nm-request(a)ops.ietf.org and there's an email address to which specific suggested requirements can be sent, which Suzanne and I will try to incorporate into the document. Please write up exactly what you're thinking, with clear examples, if possible, and as much detail as you think is necessary, and send them to: ops-nm-suggestions(a)ops.ietf.org As likely requirements are submitted, Suzanne and I will summarize them back to the ops-nm list for discussion. If you need to contact us privately we can be reached at: Suzanne Woolf woolf(a)mfnx.net +1 408 367 6666 (GMT +8) Bill Woodcock woody(a)pch.net +1 510 409 6620 (GMT +8) Thanks, -Suzanne Woolf -Bill Woodcock

1 0

Re: IP Addresses for colocation
by Roger Marquis 23 Jun '01

23 Jun '01

Mark J. Scheller wrote: > Is there a better way to get a /24 that can "go anywhere"? Or should I just > justify a /24 at the colocation facility and go through the same process > should we decide to change? Is there a way to buy a routable /24? Not sure I understand the concerns WRT renumbering. If you have numerous VPNs and ACLs which are dependent on the IPs then it may be a little work, but otherwise there's not really much to renumbering a /24. Just make sure the new nameservers are in place, the old TTLs are turned down to 24 hours or so, and the environment is replicated at the new co-lo. You can use GRE tunneling and optionally NAT to do this with even more cut-over transparency. If you've never done it before hire a consultant to draw up the project plan and walk you through. The second time is much easier, and after that you'll be free to choose a co-lo without needing to worry if it'll be forever viable. BTW, no matter what ISP you choose chances are that at some time in the future you'll want to move. Plan on it and you'll sleep a lot easier. One question for the gurus on this list: if a site were to get a portable /24 would they be able to assure connectivity to ISPs that filter small subnets from their BGP? -- Roger Marquis Roble Systems Consulting http://www.roble.com/

1 0

[OT] Lucent max tnt config
by Sabri Berisha 23 Jun '01

23 Jun '01

Hi, I have such a device for configuration on my desk however I'm completely clueless on how to. Does anyone have an example configuration which I can use? Please mail me off the list. Thanks in advance. -- /* Sabri Berisha CCNA,BOFH,+iO O.O speaking for just myself * Join HAL!!: www.HAL2001.org ____oOo_U_oOo____ http://www.bit.nl/~sabri * "We deliver quality services, we just can't get it on the internet" * Anonymous sysadmin - on IRC */

6 5