- Test - lists.nanog.org

Re: Top-50 Report
by Paul Ferguson 26 Sep '96

26 Sep '96

At 11:48 AM 9/26/96 +0100, Tony Barber wrote: >The above is an excellent idea. Perhaps if you could mail the output to >nanog and ripe-list the peer pressure would help and in some cases inform >LIRS/ISPs what they may unknowingly be doing wrong. >RIPE did this earlier inthe year for the European registries and it worked. > >Is there an APNIC equivelant ? > Yes -- AP Ops <apops(a)apnic.net> - paul

1 0

Re: Advice on dealing with Sprint
by Rob Liebschutz 26 Sep '96

26 Sep '96

> > > I spoke to a sprint salesperson about 2 weeks ago and was told that I > > > could not get any kind of BGP4 peering with Sprint unless I had a > > > Cisco 7000 series router. > > > > This is my experience also, althought I was able to get my sales > > weasel to say that they might except a 45xx series if it had > > sufficient memory, as some "exceptions" had been granted on a "case > > by case" basis. > > > > As a reseller of IP services they will not manage my router for me, > > but said I still had to have a Cisco(tm) router, even if I'm not > > peering BGP. > > > > Jay Stewart > > I won't say there's "no way they can know", but basically they really > shouldn't. If you disable incoming telnet to your Bay box and tell > them it's a cisco with "cdp disabled", they shouldn't be able to > tell the difference. > > Of course, you'd best know how the hell to configure the bay box > if you want to go this route. > > Avi > > Actually, I was planning to change the login prompt on my BSDI box to User Access Verification Password: Rob

1 0

Re: Advice on dealing with Sprint
by Rob Liebschutz 26 Sep '96

26 Sep '96

I'm not criticizing Sprint, for this policy, only confirming the fact that I received similar information about their requirements to use Cisco equipment. I've had my share of bad experiences with customers buying some El Cheapo brand router and throwing it in my lap to deal with. I have my official list of routers & CSU/DSU's that I support (Cisco's are on that list) and for anything else the customer is on their own. On the other hand I wasn't asking Sprint to manage my router for me either and would hope that they would peer with any "reasonable" router that I might have if I could demonstrate to them that I was competent in bgp4 routing with it and that it would not cause them any problems. > > I spoke to a sprint salesperson about 2 weeks ago and was told that I > > could not get any kind of BGP4 peering with Sprint unless I had a > > Cisco 7000 series router. > > I suspect two problems. > > Some [potential] cvustomers are not hearing clearly, or Sprint has some > internal communication problem that is leaking out to customers. Probably > more of the latter then the former, but likely a bit of both. > > But the tough question is what to do when a customer wants to attach > something 'strange'. We're a few decades past the Carterphone decision, so > we probably should let the customer do it. But how much are we obliged to > debug it for them? And how are we compensated for our efforts beyond those > to which we are used? > > randy >

1 0

Re: New Denial of Service Attack ...
by vjs＠mica.denver.sgi.com 26 Sep '96

26 Sep '96

> From: Barney Wolff <barney(a)databus.com> > To: vjs(a)sgi.com (Vernon Schryver), nanog(a)merit.edu > > At R=100 SYNs/sec, RTT=250, and L=382, ((L-1)/L)^(RTT*R) = 93%, which > > is not so bad. Drop-oldest is better with those three numbers, since > > it works 100% (modulo ordinary problems), but its performance falls off > > the cliff to 0% at R=L/RTT. If you have a short queue and care about > > long RTT's, random drop is better than drop-oldest. > > Agreed. Note that 93% is not bad for a human-initiated telnet, but is > disastrous for a Web browser which initiates a dozen tcp sessions to > retrieve one page, because the browser will probably not retry at all if > it gets a reset, but instead report failure to retrieve the page to the > user, who can only ask it to start over from the beginning. Caching should keep them from having to retransfer everthing. Of course, if the problem is getting through the listen queue, that might not help much. > So I think > that it's better to accept the limited-radius-under-attack property of > drop-oldest, gaining the immunity from interference within the safe > radius. If you have a useful safe radius. At only 130 SYNs/sec, a 260 entry queue seems useful today, giving a 2 second radius. What is the limit on the queue in the typical router or Ethernet hub? > If it were possible to set the syn-rcvd timeout with sub-second > granularity, this "fix" would not even take any kernel code mods - but > of course it does not adjust the safe radius dynamically as the attack > rate changes. Again, I think it is practical to switch automagically from drop-oldest when the attack rate is modest to random-drop when the bad guys get something better than a v.34 modem, such as ISDN or just a corrupted machine somewhere on an Ethernet connected with a T1. > What's absolutely clear is that any method of queue pruning is better > than none, and a big queue is required for survival. A queue limit 50 to 500 times larger than the 7 from the classic BSD SO_MAXCONN=5 seems useful for handling the 100's of valid TCP connections/sec that you get on a busy WWW server. Vernon Schryver, vjs(a)sgi.com

1 0

Re: New Denial of Service Attack ...
by Barney Wolff 26 Sep '96

26 Sep '96

> Date: Wed, 25 Sep 1996 18:01:50 -0600 > From: vjs(a)mica.denver.sgi.com (Vernon Schryver) > > At R=100 SYNs/sec, RTT=250, and L=382, ((L-1)/L)^(RTT*R) = 93%, which > is not so bad. Drop-oldest is better with those three numbers, since > it works 100% (modulo ordinary problems), but its performance falls off > the cliff to 0% at R=L/RTT. If you have a short queue and care about > long RTT's, random drop is better than drop-oldest. Agreed. Note that 93% is not bad for a human-initiated telnet, but is disastrous for a Web browser which initiates a dozen tcp sessions to retrieve one page, because the browser will probably not retry at all if it gets a reset, but instead report failure to retrieve the page to the user, who can only ask it to start over from the beginning. So I think that it's better to accept the limited-radius-under-attack property of drop-oldest, gaining the immunity from interference within the safe radius. If it were possible to set the syn-rcvd timeout with sub-second granularity, this "fix" would not even take any kernel code mods - but of course it does not adjust the safe radius dynamically as the attack rate changes. What's absolutely clear is that any method of queue pruning is better than none, and a big queue is required for survival. Barney Wolff <barney(a)databus.com>

1 0

Re: New Denial of Service Attack ...
by vjs＠mica.denver.sgi.com 26 Sep '96

26 Sep '96

> From: Barney Wolff <barney(a)databus.com> > To: nanog(a)merit.edu > Cc: vjs(a)sgi.com (note that I'm not on the nanog mailing list) > Ok, I'm confused. Quoting from Vernon's message: > > > Date: Wed, 18 Sep 1996 14:32:14 -0600 > > From: vjs(a)mica.denver.sgi.com (Vernon Schryver) > > Subject: SYN bombing defense > > > > I've just hacked IRIX 6.3 to do random-drop when sonewconn() in > > tcp_input.c fails. It works great! An IP22 receiving 1200 bogus > > SYN's per second directed to port 23 continues to answer requests > > for new telnet as if nothing is happening. > > ... > > As I figure it, as long as the length of the queue is longer than RTT > > of the real telnet client times the rate of bogus SYNs, the real > > clients have an excellent probability of getting through on their > > first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3 > > telnet listen queue of 383, there should be no trouble with peers > > with RTT up to about 300 milliseconds. I've tested with a telnet > > client 250 milliseconds away while simultaneously bombing the machine > > from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions. > > Because the queue is always full, you must have been doing 1200 random- > drops per second, also. A telnet client 250ms away is therefore on > average exposed to 300 random-drops, each of which has a chance of 1/383 > of killing it. Its probability of survival is (1-1/383)^300, or .456, > not so good. It would be different if it were oldest-drop, but random- > drop is what's stated. > > Lacking evidence, I won't argue with the experimental finding that the > problem goes away - but if so, what's wrong with my computation? I don't see anything wrong with your computation. In subsequent experiements I did see losses consistent with that computation, varying the SYN rate R between 100 and 2700 SYNs/sec and the RTT between <10 and 500 ms. I don't know why I didn't see any losses in my first experiments. It's hard (and boring) to test the ((L-1)/L)^(RTT*R) formula, but it seems to fit. I guess I should have written a program to mechanize the testing. >From what I've been told, the bombing rates have been what you would expect from a v.34+v.42+v.42bis modem or a single B channel without compression, 100-150 SYNs per second, instead of what you can get over a single B channel with compression, 300-500 SYNs/sec. At R=100 SYNs/sec, RTT=250, and L=382, ((L-1)/L)^(RTT*R) = 93%, which is not so bad. Drop-oldest is better with those three numbers, since it works 100% (modulo ordinary problems), but its performance falls off the cliff to 0% at R=L/RTT. If you have a short queue and care about long RTT's, random drop is better than drop-oldest. Since the weekend, I've been pushing code that switches from drop-oldest to random-drop as the bombing rate increases. That might be overkill, but hey!, its only a handful of lines of code and the problem is fun to think about. Also since the weekend, I've been told FreeBSD and Linux have some kind of queue pruning code. Vernon Schryver, vjs(a)sgi.com

1 0

Re: New Denial of Service Attack ...
by Barney Wolff 25 Sep '96

25 Sep '96

Ok, I'm confused. Quoting from Vernon's message: > Date: Wed, 18 Sep 1996 14:32:14 -0600 > From: vjs(a)mica.denver.sgi.com (Vernon Schryver) > Subject: SYN bombing defense > > I've just hacked IRIX 6.3 to do random-drop when sonewconn() in > tcp_input.c fails. It works great! An IP22 receiving 1200 bogus > SYN's per second directed to port 23 continues to answer requests > for new telnet as if nothing is happening. > ... > As I figure it, as long as the length of the queue is longer than RTT > of the real telnet client times the rate of bogus SYNs, the real > clients have an excellent probability of getting through on their > first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3 > telnet listen queue of 383, there should be no trouble with peers > with RTT up to about 300 milliseconds. I've tested with a telnet > client 250 milliseconds away while simultaneously bombing the machine > from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions. Because the queue is always full, you must have been doing 1200 random- drops per second, also. A telnet client 250ms away is therefore on average exposed to 300 random-drops, each of which has a chance of 1/383 of killing it. Its probability of survival is (1-1/383)^300, or .456, not so good. It would be different if it were oldest-drop, but random- drop is what's stated. Lacking evidence, I won't argue with the experimental finding that the problem goes away - but if so, what's wrong with my computation? Barney Wolff <barney(a)databus.com>

1 0

Re: New Denial of Service Attack ...
by postel＠ISI.EDU 25 Sep '96

25 Sep '96

----- Begin Included Message ----- Subject: Re: FW: Latest attacks.... Date: Thu, 19 Sep 1996 08:39:02 +0100 From: Jon Crowcroft <J.Crowcroft(a)cs.ucl.ac.uk> problem solved: this just in on your trusty end2end research group's list (sorry, i know some of you may already read it) this guy is usually technically excellent, so i think we can trust that this solution is valid, will propagate, and is deployable for server sites that worry (you only need kernel reconfig rights for unix to add this - NT and MAC servers may have a tad more of a problem:-). cheers jon ------- Forwarded Message Date: Wed, 18 Sep 1996 14:32:14 -0600 From: vjs(a)mica.denver.sgi.com (Vernon Schryver) Subject: SYN bombing defense As reported here, in article <vxjiv9hkmcb.fsf_-_(a)dominator.eecs.harvard.edu> in comp.protocols.tcp-ip, Robert Morris <rtm(a)dominator.eecs.harvard.edu> wrote: >Perhaps TCP's listen queue should use random early drop (RED), a >technique used by routers to prevent any one source from monopolizing >a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or >rfc1254. > ... I've just hacked IRIX 6.3 to do random-drop when sonewconn() in tcp_input.c fails. It works great! An IP22 receiving 1200 bogus SYN's per second directed to port 23 continues to answer requests for new telnet as if nothing is happening. I don't think that random <<Early>> drop is necessary or desirable. It is not as if we're trying to drop packets early to trigger slow start in the sources. As I figure it, as long as the length of the queue is longer than RTT of the real telnet client times the rate of bogus SYNs, the real clients have an excellent probability of getting through on their first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3 telnet listen queue of 383, there should be no trouble with peers with RTT up to about 300 milliseconds. I've tested with a telnet client 250 milliseconds away while simultaneously bombing the machine from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions. Vernon Schryver, vjs(a)sgi.com ------- End of Forwarded Message ----- End Included Message -----

3 3

Re: New Denial of Service Attack ...
by Leonid Egoshin 25 Sep '96

25 Sep '96

>From: postel(a)ISI.EDU >From: vjs(a)mica.denver.sgi.com (Vernon Schryver) > >>Perhaps TCP's listen queue should use random early drop (RED), a >>technique used by routers to prevent any one source from monopolizing >>a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or >>rfc1254. >> ... > >As I figure it, as long as the length of the queue is longer than RTT ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >of the real telnet client times the rate of bogus SYNs, the real >clients have an excellent probability of getting through on their >first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3 >telnet listen queue of 383, there should be no trouble with peers >with RTT up to about 300 milliseconds. I've tested with a telnet >client 250 milliseconds away while simultaneously bombing the machine >from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions. As I understand it is the decision based on truncation long distance clients to fit in host resources under attack. And the more SYNs flood volume shrink more the service area. But why we use ten seconds in TCP as max RTT instead of hundreds milliseconds ? (see rfc1122) - Leonid Yegoshin, LY22

1 0

Re: New Denial of Service Attack ...
by rja＠cisco.com 25 Sep '96

25 Sep '96

I'll concur with Jon Postel and Jon Crowcroft. Vernon is usually right and in this case I've worked the analysis myself and fully concur with him. I understand that some versions of UNIX are already headed down the path Vernon has suggested. Ran rja(a)cisco.com --

1 0