- Test - lists.nanog.org

Re: Work Work Work
by Scott Stansbury 09 Sep '96

09 Sep '96

-> > For those not at the last IEPG mtg, this was discussed with the trade off -> > being 13 host routes vs coordinating root cache updates for 20-30 million -> > end nodes. -> -> Luckily, as Havard points out, this seems to work now. Don't folk have real -> work to do? -> Unfortunately, this doesn't work now. Our name servers get tens of thousands of hits a day for a former root, c.nyser.net, a machine that hasn't existed for quite some time. Scott... *************************** Scott Stansbury NYSERNet, Inc. 125 Elwood Davis Road Syracuse, NY 13212-4311 315-453-2912 Ext. 253 scotts(a)nysernet.org ****************************

8 8

Re: The SWAMP
by Nick Hilliard 09 Sep '96

09 Sep '96

> 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. Nick

5 4

MAE-East still no generator
by Nathan Stratton 09 Sep '96

09 Sep '96

Check out the nice graph of MAE-East for that last 5 days. When are they going to get a generator installed? Why can't you pay for a generator when you are charging +30 people $5,700 a month? Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales(a)netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34

20 43

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