- NANOG - lists.nanog.org

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

TCP SYN attacks - a simple solution
by rex＠staff.cs.su.oz.au 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! There is, I believe, a much simpler solution. The problem is, as I see it, that the current implementations are keeping the first packet (in some form) around, as state. Instead, we want to discard all this state information, to allow us to accept more packets. Only when we have a full connection do we want to keep state information. The only piece of information we require at this early stage is the initial sequence number for our side. 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. This means that initial packets, fired from random addreses will never have the third packet, and no overheads are consumed, except for the hash calculation. Since there is only one random number in the connection, the initial sequence number from the originating site, there is a higher probability of "rogue", or lost packets, but if the initial ISN was truely random this shouldn't be to much of a problem (hmmm - am I sure?). Pictorally: Host A to conenct to Host B host A (good) Host B (good) gen ISN send packet to B ---> receives packet, and ISN. uses F(ISN(A) + ports + secret) as calculated ISN for return and sends to A, discards all receives packet <---- state. as normal, and sends third packet ---> receives packet, recalculates ISN from 1st step. If it matches the ACK in the packet then this is a valid connection. The nice thing about this is that no changes have to occur on the sending side. This solution will work with current IP stacks, but will automatically reject bogus connections, and has no silly timeout on valid connections. This scheme does have implications with firewalls that base all decisions on the first packet, such as packet filtering firewalls, but then again, I don't consider them real firewalls. :-) I'm going to implement this, using boring old md5, and give it a try, but I was wondering if there are any thoughts about this as a solution? Any obvious holes I missed. Rex di Bona.

2 1