- NANOG - lists.nanog.org

Re: The SWAMP
by Vadim Antonov 09 Sep '96

09 Sep '96

>I will echo Randy's sentiment here: is there a technical reason >why the root name servers need special "provider-independent" >addresses, or is this a solution looking for a problem? Root name servers is the only legitimate use for fixed IP addresses. How about allocating some "good sounding" IP addresses for them, (like 1.0.0.x/32) and hard-wiring them into resolver code? Would save quite a lot of configuration headaches for newbies. --vadim

1 0

Re: SYN floods (was: does history repeat itself?)
by Ben Tersian 09 Sep '96

09 Sep '96

At 09:13 AM 9/9/96 -0700, you wrote: >A friend of mine gave me a photocopy of a page in the latest 2600 >magazine. It was the source code for a SYN flooder on Linux, with a >description of what it does and a notice on how it can really cause >denial-of-service attacks. > Hello Craig [Flashman], The SYN Flooding is not only the problem on IRC, but the TCP sequencing as well. Using a TCP sequencer, one of these 13 year olds who has no idea how or what they are doing, can SYN flood a host without knowing it at all. This involves hosing a host with SYN floods to keep it from sending out the correct ACKs so that you can sequence them on your side and "spoof" them. Well, sadly to say, all these kids want to do is be "eleet" and hide thier real host names so they can trade pirated software etc. However, this leads to a bigger problem seeing as how this same code can be used to do blind rcommands using the same sequencing technique. Fortunately, the person who wrote the orginal TCP sequencer had only IRC in mind, and mainly the people that have used it were IRC kiddies, and even they had a hard time using it because it needs a modification to raw.c in order to patch the kernel to do the correct raw socket operations under the mask of a faked packet. struct tcphdr * fake_tcp; fake_tcp = ( struct tcphdr *)( packet + offsetTCP ); fake_tcp->th_dport = htons(fromport); fake_tcp->th_sport = htons(toport); fake_tcp->th_seq = htonl(sequence); fake_tcp->th_ack = htonl(acknum); fake_tcp->th_off = (sizeof(struct tcphdr))/4; fake_tcp->th_win = 2; I think you get the point. I'm not sure what a real feasable solution would be, except to do a tcpdump or start a sniffer during an attack and try and trace it from there. However, if the packets are carrying fake headers, there's not much you can do. P.S. Lets try not to get mad at Emmanuel Goldstein (Editor 2600 Magazine) for what he puts in his magazine. True, the code can and will be used for malicious purposes, but if it weren't published, only a select few people would have the code and very few people would be hearing about SYN floods, instead, simply being attacked without the slightest clue what was happening. Ben Tersian -LebaNet Inc. C.S.O.

1 0

Re: MAE-East still no generator
by Hank Nussbacher 09 Sep '96

09 Sep '96

On Sat, 7 Sep 1996 23:24:14 -0400 (EDT) Andrew Partan wrote: >> I am moving to ... a Cascade 9000 ... > >My condolences. Care to explain that last comment? > --asp > Hank

2 1

"installing UPSes isn't hard"
by mo＠uu.net 09 Sep '96

09 Sep '96

Clearly you've never owned a UPS the size of a large DC Plant. One of the ongoing problems with UPS boxes is they have batteries in them, too, and they have to be managed and maintained. one of the BIGGEST wins in going with House DC as a source is that there is just one battery plant to be managed, and it is always rated for at least 8 hours continuous full load. sizing a UPS for that much is very, very expensive. If you wanna run AC, use inverters from House DC. That's just a UPS with the crap made redunant by a huge DC plant left off. If you insist on buying AC-powered things, then you will have inverters somewhere, either inside the UPS box or outside connected right from the DC plant. EIther way, there are many more parts involved to break. the MTBF WILL be lower. there is no way around that. The Telco folks have 100 years of hard-won experience and some of it is worth borrowing to prevent learning it the hard way. But if you insist on relearning them, be my guest. Just don't offer bad advice to other impressionable young minds. cheers, -Mike O'Dell VP, Chief Scientist UUNET Technologies, Inc.

2 1

Re: The SWAMP
by Havard.Eidnes＠runit.sintef.no 09 Sep '96

09 Sep '96

> Isn't the argument of the non-default routing tables growing by an > additional 13 entries or not is specious noise? The routing bucket is > leaking through bloody great open chasms and we are wondering about > the incremental damage throuigh a pinhole! The 13 additional entries are not the issue. The issue is one of setting a bad high-profile example. Any suggestions for closing the open chasms in the routing bucket? - Havard

4 3

Re: MAE-East still no generator
by Peter Lothberg 09 Sep '96

09 Sep '96

> is dead you are ok, I just don't think that is the point. MAE-East needs > to have some money dumped in to fix some of the power and other problems > before it is a big disaster. Well, the NY-NAP (in south NY...), has like a day of -48V and generators for weeks, and excellent physical security. --Peter

2 1

Re: The SWAMP
by Bradley Dunn 09 Sep '96

09 Sep '96

> If there has to be a separate route for each one anyway, why not just > blow 253*10 addresses and announce a /24 for each root name server, even > if only one IP out of each /24 is used? > > Less CPU to blow holes in filters that normally deny > /24. > > Avi How far does this get extended, then? What if, to encourage aggregation, /24s start to be filtered? Do you then blow a /23? A /22? I guess the real question is how do you balance between two scarce resources, router CPU and IPv4 address space. -BD

2 1

The SWAMP
by Bradley Dunn 09 Sep '96

09 Sep '96

I was doing my daily traceroutes to see who was down today, and i noticed some interesting things. One thing I noticed was that: c.root-servers.net e.root-servers.net g.root-servers.net i.root-servers.net all appear to be in the "twd", as well as being in the swamp. A well-known router vendor's web site also appeared to be in this category. Now I don't run anything nearing a real router, so I checked route-server.cerf.net, and sure enough they are being advertised as /24s. I realize renumbering the root servers is not really a good place to start.:-) Yet I think it shows what a massive task we have ahead of us, if we are to make progress in aggregating 192/8. I also think it would be hard to convince someone to renumber out of a /24 in 192, when they can say, "well almost half of the root servers haven't renumbered, why should I?". Just my observations. I'll crawl back into my little stub of the 'net and resume being a spectator. :) -BD

6 11

Re: The SWAMP
by Havard.Eidnes＠runit.sintef.no 09 Sep '96

09 Sep '96

Now, to create another sub-thread on this subject... Bradley Dunn wrote: > Now I don't run anything nearing a real router, so I checked > route-server.cerf.net, and sure enough they are being > advertised as /24s. I realize renumbering the root servers is > not really a good place to start.:-) Yet I think it shows what > a massive task we have ahead of us, if we are to make progress > in aggregating 192/8. The massive task of aggregation is not only in 192/8. Earlier today I took a dump of the BGP routing table on the above mentioned router (thanks to CERFnet!) and threw it at one of my Perl scripts which produces a report showing the distribution of prefix lengths for announced routes in each individual /8 block within the "class C" address space. The result is attached below. Note that the two "100% announced" entries are due to a well known jester announcing a couple of /8s... I will however here repeat the summary for all of the "class C" routes which shows the total number and the distribution over prefix lengths: All >=24 /23 /22 /21 /20 /19 /18 /17 /16 </16 #Rts 33220 24504 2388 1785 1170 933 918 486 226 642 168 Anyone for "War on /24"? (Oh, well, probably a lost cause before it got started...) - Havard Block #Rts >=/24 /23 /22 /21 /20 /19 /18 /17 /16 </16 As/rt % of spc 192 6446 5466 451 239 118 74 39 13 7 39 0 826 31.76 193 1911 1200 223 143 95 72 78 14 5 51 30 5299 60.36 194 2439 1609 226 146 88 56 146 35 20 99 14 4691 68.20 195 138 45 4 2 2 6 35 5 6 32 1 20288 16.69 196 375 266 33 30 15 10 4 3 1 11 2 44739 100.00 197 2 1 0 0 0 0 0 0 0 0 1 8388K 100.00 198 3965 3327 206 128 101 50 52 24 4 58 15 2113 49.94 199 3885 3285 174 111 95 66 39 38 18 46 13 2324 53.83 200 920 763 43 33 22 21 16 6 3 9 4 5252 28.80 201 0 0 0 0 0 0 0 0 0 0 0 0 0.00 202 1556 718 228 204 125 110 56 66 19 25 5 3787 35.12 203 1444 902 146 127 47 57 56 40 34 33 2 5852 50.38 204 3690 2817 216 138 131 124 86 58 22 78 20 2996 65.90 205 2151 1628 132 108 86 67 38 26 7 38 21 4550 58.34 206 2454 1392 183 230 137 132 177 68 31 78 26 5384 78.76 207 1164 665 61 69 60 57 81 87 34 40 10 6791 47.12 208 671 420 62 76 48 29 14 1 14 3 4 2972 11.89 209 0 0 0 0 0 0 0 0 0 0 0 0 0.00 210 9 0 0 1 0 2 1 2 1 2 0 23779 1.28 #Rts 33220 24504 2388 1785 1170 933 918 486 226 642 168 All >=24 /23 /22 /21 /20 /19 /18 /17 /16 </16

1 0

Re: The SWAMP
by Havard.Eidnes＠runit.sintef.no 09 Sep '96

09 Sep '96

> 'Deserve'? Is this like China 'deserves' a /8? Do root > servers have egos that need coddling? > > Why do they NEED special address space? What's the matter with > the address space of the normal networks in which they reside? > If there is someing bad about those networks, then they need > fixing, and access to the root (or other) servers will be fixed > with that change. I will echo Randy's sentiment here: is there a technical reason why the root name servers need special "provider-independent" addresses, or is this a solution looking for a problem? As far as I know, as long as one of the IP addresses in a local name server's root hints file is correct and that root name server is reachable, the local name server will operate correctly. Changes to the root hints file are currently not terribly frequent, and updating it once per half year (or maybe even less frequent) does not seem like an inordinately heavy burden. Without a technically well-founded reason for doing "weird" things with the routes for the root name servers, you can expect so see similarly ill-founded justifications from other folks wanting to do the same or similar things. As the recent events should make evident, the last thing we need right now is creating a precedent for spreading /32 routes or needlessly propagating other "special-purpose" and non-aggregateable routes. Regards, - Havard

3 2