- Test - lists.nanog.org

Re: The SWAMP
by Vadim Antonov 09 Sep '96

09 Sep '96

Nick Hilliard <nick(a)eunet.ie> wrote: > 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. >Hardwiring anything like this into a system like DNS sounds like a really >bad idea if only for the simple reason that DNS is not just used on the >Internet, but also within private networks. Having hardwiring IP numbers in >this case would cause headaches of unimaginable proportions. Er. This is _root zone_. You either have access to it, or not. Those are completely separated name spaces. If you have an intranet you may want to have internal routes for local roots. A *lot* less headache when all namseservers on all machines work out-of-box without system administrator running in circles changing addresses. Anyway, i would rather have an override for root NS addresses, instead of required configuration. How many root caches out there are configured with all correct addresses? My estimate is below 20%. --vadim PS. Thanks to those who pointed that it is not resolver but rather cacheing NS.

1 0

Re[4]: SYN floods (was: does history repeat itself?)
by pcalhoun＠usr.com 09 Sep '96

09 Sep '96

Justin, I understand and share your concern. Unfortunately I cannot tell you since I have no idea what you use. In our case, we test them with unrealistic loads (all ports running ttcp) which is much more than a typical user will ever do. Adding such a filter is quite minimal in our case since our algorithms are pretty tight. Pat R. Calhoun e-mail: pcalhoun(a)usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: SYN floods (was: does history repeat itself?) Author: "Justin W. Newton" <justin(a)erols.com> at Internet Date: 9/9/96 3:30 PM At 01:19 PM 9/9/96 -0500, Pat Calhoun wrote: >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Description: cc:Mail note part > > Perry, > > This is actually quite simple to implement on Dial Access Routers, > and obviously this is the best place to add the filtering. How much spare processor do a lot of the dial access servers have left on them? I am somewhat concerned about the amount of processor left on my dial access servers. Justin Newton Internet Architect Erol's Internet Services

1 0

Re: Re[2]: SYN floods (was: does history repeat itself?)
by Justin W. Newton 09 Sep '96

09 Sep '96

At 01:19 PM 9/9/96 -0500, Pat Calhoun wrote: >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Description: cc:Mail note part > > Perry, > > This is actually quite simple to implement on Dial Access Routers, > and obviously this is the best place to add the filtering. How much spare processor do a lot of the dial access servers have left on them? I am somewhat concerned about the amount of processor left on my dial access servers. Justin Newton Internet Architect Erol's Internet Services

1 0

Re: The SWAMP
by Vadim Antonov 09 Sep '96

09 Sep '96

Geoff Huston <gih(a)aarnet.edu.au> wrote: >My humble suggestion is forced non-local proxy aggregation. That is unfortunately more easily said than done. I can recite PSI's blocks if you wake me up in the night... --vadim

1 0

Re: Work Work Work
by Justin W. Newton 09 Sep '96

09 Sep '96

At 09:06 AM 9/9/96 -0400, Jon Zeeff wrote: > >Let's also analyze the cost of wasting the remainder of /24s in this >special case. Much worse has happened. It would be a bad precedent for IANA to be promoting such a waste of space when they are promoting space conservation for everyone else. "Do as I say, not as I do" is a bad policy. Justin Newton Internet Architect Erol's Internet Services

5 4

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