- Test - lists.nanog.org

Re: DoS, ICMP, proxies, SYNDefender
by salo＠msc.edu 08 Oct '96

08 Oct '96

> From: Tim Bass <bass(a)linux.silkroad.com> > Subject: Re: DoS, ICMP, proxies, SYNDefender > To: michael(a)memra.com (Michael Dillon) > Date: Fri, 4 Oct 1996 17:18:25 -0400 (EDT) > Cc: nanog(a)merit.edu, iepg(a)iepg.org > > > This is not the right forum to discuss TCP internals nor is it the right > > forum to discuss building hardened kernels > > That may or may not be true, I'll pass on that one. > > What is the name of the 'right list' for this discussion, BTW? > linux-net is quiet and the linux code fragement for linux > does not work on high speed networks..... > [...] The real TCP people tend to hang out on the end-to-end mail list. They could, and probably would, provide a high-quality critique of a well- written summary of what you propose. On the other hand, the e-2-e mail list probably doesn't have much patience for the sort of chatter that has appeared on this topic on nanog... I suggest you write an internet draft and send it to end-to-end for comments. -tjs

4 3

Re: My First Denial of Service Attack..... (fwd)
by Eric Kozowski 08 Oct '96

08 Oct '96

>Is "Denial Of Service" what "DOS" has stood for all along? Cool. It >all makes sense now after all these years... ROTFL. I normally don't reply with spurious info, but this one was too good to not respond. -- Eric Kozowski Senior Network Engineer eric(a)structured.net Structured Network Systems, Inc. (503)656-3235 FAX Better, Cheaper, Faster -- pick any two. (800)881-0962 Voice http://www.structured.net/ "Providing High Quality, Reliable Internet Service" -- 56k to DS1

1 0

Re: </24 from AS1673
by Bill Nowak 07 Oct '96

07 Oct '96

Howdy... We are looking into this and will have it taken care of shortly... Bill > Date: Mon, 07 Oct 1996 07:51:33 PDT > From: dlr(a)bungi.com (Dave Rand) > To: nanog(a)merit.edu > Subject: </24 from AS1673 > X-Mhl-File: --mhl.format-- > > ans seems to be releasing a bunch of very specific routes carved out > of a class B address. Is anyone else seeing this, or is it just me? > > I see /24's, /26's and /30's in their advertisements... > > Network Next Hop Metric LocPrf Weight Path > *> 140.222.48.192/26 198.32.136.39 0 174 1673 i > *> 140.222.56.64/26 198.32.136.39 0 174 1673 i > *> 140.222.56.192/26 198.32.136.39 0 174 1673 i > *> 140.222.64.192/26 198.32.136.39 0 174 1673 i > *> 140.222.72.192/26 198.32.136.39 0 174 1673 i > *> 140.222.80.192/26 198.32.136.39 0 174 1673 i > *> 140.222.88.192/26 198.32.136.39 0 174 1673 i > *> 140.222.96.192/26 198.32.136.39 0 174 1673 i > *> 140.222.104.192/26 198.32.136.39 0 174 1673 i > *> 140.222.112.192/26 198.32.136.39 0 174 1673 i > ... > > -- > Dave Rand > dlr(a)bungi.com > http://www.bungi.com

1 0

</24 from AS1673
by dlr＠bungi.com 07 Oct '96

07 Oct '96

ans seems to be releasing a bunch of very specific routes carved out of a class B address. Is anyone else seeing this, or is it just me? I see /24's, /26's and /30's in their advertisements... Network Next Hop Metric LocPrf Weight Path *> 140.222.48.192/26 198.32.136.39 0 174 1673 i *> 140.222.56.64/26 198.32.136.39 0 174 1673 i *> 140.222.56.192/26 198.32.136.39 0 174 1673 i *> 140.222.64.192/26 198.32.136.39 0 174 1673 i *> 140.222.72.192/26 198.32.136.39 0 174 1673 i *> 140.222.80.192/26 198.32.136.39 0 174 1673 i *> 140.222.88.192/26 198.32.136.39 0 174 1673 i *> 140.222.96.192/26 198.32.136.39 0 174 1673 i *> 140.222.104.192/26 198.32.136.39 0 174 1673 i *> 140.222.112.192/26 198.32.136.39 0 174 1673 i ... -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: TCP SYN attacks - a simple solution
by Jeff Weisberg 07 Oct '96

07 Oct '96

| Hopefully there will be a working implementation of this by week's end. | Jeff Weisberg has code which runs on sun3s and (soon, I hope) on other | Suns under SunOS. well, it seems to be more subtle than a sun3 vs sun4 thing. the IPC has been up for 15 hours without problem (yet), it seems to only be production level machines that crash... --jeff

2 1

Re: TCP SYN attacks - a simple solution
by Jeff Weisberg 07 Oct '96

07 Oct '96

| There have been several (many?) products attempting to solve the TCP | SYN attack through timeouts. They watch the SYN packets, and flush | ones, by doing a RESET on the connection if the third packet isn't | received in time. Or letting conenctions fail by flushing the infant | connection table when full. I believe this is wrong! [...] | I propose a solution where the initial sequence number is calculated | (not random), and is based on a cryptographic calculation of the | senders Initial Sequence Number, the ports, and a "per boot" | secret number. In this way the initial packet can be discarded, | and on receipt of the third SYN packet can be recalculated. cool idea! look at: ftp.op.net:/pub/src/syn-prophylactica/ for an implementation. --jeff

1 0

Re: My First Denial of Service Attack..... (fwd)
by Eric Ziegast 07 Oct '96

07 Oct '96

> > The foreman commented, "We'd be sued for $100,000 for every 10 minutes > > the line was cut." Correction: $100,000 per minute. I was quite sure of the $6,000,000 per hour figure. -- Eric Ziegast

1 0

SYN flooding -- drop policies
by Vadim Antonov 07 Oct '96

07 Oct '96

Mike O'Dell suggested using drop oldest in some situations. Unfortunately it is about as good as RED if source of good SYNs is deterministic and is *much* worse then RED if it is bursty. Assuming that source of bad SYNs is deterministic as well as server, and good SYNs come as Poisson process chances of good SYN survival with RED are about 1-e^-1 times better than with Drop Oldest. With self-similar SYN inter-arrival pattern (there are some indications that it's like that) the advantage of RED is even bigger. I didn't do any serious research on that, so the result is of "back of envelope" kind, but it does make some intuitive sense. It should also be observed that tail-drop at customer access gateway would reduce usefulness of RED (or Drop Oldest), particularly when flood rate comes closer to link capacity. The question of what max. queue length is the best remains pretty much open; as well as how it interacts with back-off SYN retransmissions. --vadim

2 1

Re: Agenda item for Nanog?
by Guy T Almes 07 Oct '96

07 Oct '96

I would love to hear at least 20 minutes worth. -- Guy At 07:41 AM 10/4/96 DST, Peter Lothberg wrote: > >I could say some worlds about this if anyone is interested and there >are 20 minutes avaliable on the Nanog agenda. > > >-Peter > > > >"" > >Worlds first transatlantic 155Mbit native IP service > >On Monday 23 September 1996 00:15 UTC, > >Was the worlds first transatlantic 155Mbit native IP service brought >into operation by Sprint/USA and Tele2/Sweden. > >The circuit which is part of SprintLink and ICMnet runs between the >NY-NAP in Pennsauken, NJ, USA and Tele2 in Sweden and uses Cisco >packet-over-sonet/sdh technology. (Native IP over SDH) > >In 1995 the same team from Sprint and Tele2 brought up the worlds first >transatlantic E3 service between the same endpoints. > >For more information; > >Sprint: Tricia Schibler, +1 703 904 2042, <tricia.schibler(a)qm.sprintcorp.com> >Tele2: Olle Wallner, +46 8 5626 4058, <wallner(a)swip.net> > >"" >

1 0

Re: TCP SYN attacks - a simple solution
by Mike O'Dell 07 Oct '96

07 Oct '96

best solution known so far is Random Drop of waiting connections once queue fills to a limit at least as large as design RTT*Attack-Rate (queues in the 350-400 range appear to be quite sufficient for RTTs in the 250msec range with 1000-packets/second attacks). Some also argue that somewhat more aggressive aging with Oldest Drop (aka FIFO) also helps while the queue fills to the point of instigating Random Drop. One can mutter about where transition between Oldest and Random should occur. I'm willing to believe hybrid strategy could be better at possible cost of more complexity. (although more agressive Oldest Drop is probably just a timer tweek.) Note that with Random Drop and 350-400 max queue size legit connections almost always complete on the first SYN with no retransmission. cheers, -mo

3 2