- NANOG - lists.nanog.org

BGP update propogation times
by Jon 'tex' Boone 19 Sep '96

19 Sep '96

Folks, Last time I had any reasonable idea as to the time it took for network updates to propogate across the various backbones, I concluded that it took approximately 15 minutes for reachability via BGP to be advertised to what seemed like a widely dispersed set of locations. Some of them were connected either directly or indirectly to the MCI backbone, but others were connected to ANS or Sprint. Today, we had a scheduled outage of our main routing core here at Penn. We powered all of the routers back on at approximately 09:00 EDT. Until approximately 10:20 EDT, we were unable to perform nameservice lookups due to the root name servers not sending responses to us. Between approximately 09:30 EDT and 10:20 EDT, we were able to get to more and more of the root nameservers, but it wasn't untill after 10:00 EDT that any of the root namerservers were reachable. Does it really take over 30 minutes for routes to propogate across the major US backbones? [I'm ignoring the fact that we were unable to get answers to name service queries from the root name servers until after 10:20 EDT - I don't know what caused it, but for the purpose of determining how long it takes for reachability to propogate, that fact that I could ping or traceroute to the servers means that my nets were reachable.] Has anyone done any testing on this to try to determine the propogation time? Was there some major problem this morning on MCI or Sprint or some NAP? I have a net that I could use for this testing, but I need a good selection of hosts to try to ping [preferably at least one on each network providers network - ie. one for MCI backbone, one for JVNCnet/GES, one for Sprintlink, one for bob's stop-n-shop dial-up service, etc.] By the way, is there still a large amount of route flapping going on in the core routers? -------------------------------------------------- Jon Boone Operations Engineer ISC Networking University of Pennsylvania tex(a)isc.upenn.edu (215) 898-2477

1 0

FDDI concentrator w/DC power
by matthew＠scruz.net 19 Sep '96

19 Sep '96

Sorry to break up the endless discussion of SYN flooding with this off-topic question :) I cannot find a FDDI concentrator that runs on -48 VDC. Is there a product I've missed? This shortage of DC-powered concentrators might explain some of the transient outages during power problems at MAE-East, perhaps? -matthew kaufman matthew(a)scruz.net

1 0

Re: router syn/syn-ack/ack alarming...
by Vern Paxson 19 Sep '96

19 Sep '96

> have something in their logs like SYN/ACK RATIO 33:1 POSSIBLE HACKER > ATTACK which will make them sit up and take notice. I don't see how in reality to make the syn/syn-ack/ack ratio work soundly. It seems too easy for the cracker to synthesize bogus syn-ack's or ack's to manipulate the ratio however they please. The bookkeeping to tell a true syn-ack or ack-syn-ack from a bogus one entails keeping around connection state, and suddenly the cheap ratio gets expensive. Vern

5 5

Re: router syn/syn-ack/ack alarming...
by Justin W. Newton 19 Sep '96

19 Sep '96

At 01:57 PM 9/18/96 -0700, Vadim Antonov wrote: >And half of them wouldn't know what SYN/ACK ratio is. half? Now you're being optimistic ;) Justin Newton Internet Architect Erol's Internet Services

1 0

Re: router syn/syn-ack/ack alarming...
by Vadim Antonov 19 Sep '96

19 Sep '96

Michael Dillon <michael(a)memra.com> wrote: >This ratio detection >doesn't need to shutdown anything, just syslog the fact so that admins >have something in their logs like SYN/ACK RATIO 33:1 POSSIBLE HACKER >ATTACK which will make them sit up and take notice. Ah, you're an optimist. Most sysadmins would simply ignore whatever warnings they get as long as their internal users aren't complaining. And half of them wouldn't know what SYN/ACK ratio is. --vadim

3 2

Re: router syn/syn-ack/ack alarming...
by Paul Ferguson 19 Sep '96

19 Sep '96

Please forgive me for ignoring previous posts of this discipline; Has this topic been added as an agenda item for NANOG? - paul At 04:59 PM 9/18/96 -0700, Michael Dillon wrote: >On Wed, 18 Sep 1996, Michael Dillon wrote: > >> Wouldn't the ratio be calculated from outgoing SYN's and incoming ACK's? > >Ooops. I meant incoming SYN-ACK's with the emphasis on a ratio between >outgoing and incoming. > >Michael Dillon - ISP & Internet Consulting >Memra Software Inc. - Fax: +1-604-546-3049 >http://www.memra.com - E-mail: michael(a)memra.com > > >

1 0

Re: router syn/syn-ack/ack alarming...
by Vern Paxson 18 Sep '96

18 Sep '96

> From: Michael Dillon <michael(a)memra.com> > ... > Wouldn't the ratio be calculated from outgoing SYN's and incoming ACK's? There are two ratios that could be calculated and it's not clear to me which one we're talking about here. The first ratio is the number of SYN-ack packets sent in one direction vs. the number of acks-of-SYN-ack packets coming in from the other. These should be about equal. A skew indicates a likely flooding attack. But computing this ratio requires keeping around per connection state, since the ack-of-SYN-ack packet otherwise looks like any other ack. The second ratio is the number of SYN packets sent in one direction vs. the number of SYN-acks in the other. This ratio is a much easier to measure but also a much less reliable indicator of a SYN flooding attack. In particular, SYN packets can elicit RST's or ICMP's instead of SYN-acks, and they can also elicit no response whatsoever. Furthermore, the cracker can, while flooding host A with SYN's, in addition also flood host B *and follow up immediately with a RST packet* that clears out B's state. This second stream can be maintained indefinitely, and will have the effect of bringing the count of SYN-ack's quite close to the count of SYN's, since B is always able to generate the SYN-ack. Vern

1 0

Re: BCP writers
by Paul Ferguson 18 Sep '96

18 Sep '96

Michael, I'm traveling at the moment -- could you provide a quick synopsis of the people that have expressed an interested in writing this document? I really don't have the time at the moment to surf through the 2500 messages that wait me. Thanks, - paul At 09:23 AM 9/18/96 -0700, Michael Dillon wrote: >On Wed, 18 Sep 1996, Hank Nussbacher wrote: > >> Since more and more are blocking source routing and breaking traceroute -g >> then those that block it at their router should at the very least make >> a WWW traceroute available from their system so as to diagnose those >> problems you mention. > >In the BCP document, please explain the difference between source routing >and source spoofing as well as SYN flooding. And please cover source >address filters for both incoming and outgoing. > > >Michael Dillon - ISP & Internet Consulting >Memra Software Inc. - Fax: +1-604-546-3049 >http://www.memra.com - E-mail: michael(a)memra.com > > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: New Denial of Service Attack on Panix
by Paul Ferguson 18 Sep '96

18 Sep '96

For what its worth, we are looking at this. - paul At 04:32 PM 9/17/96 -0700, Leonid Egoshin wrote: >>From: "Forrest W. Christian" <forrestc(a)iMach.com> >> >> 5 minute SYNS: 123423 5 minute SYN-ACKS: 50000 >> >>Then, if the ratio got too high, it can start yelping about "Potential SYN >>D-O-S Atttack in progress on Interface Serial 1" > > I suggest to check not only ratio (assymetric routing !), >but high number of SYNs to single host. > > - Leonid Yegoshin, LY22 > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: A modest proposal
by Paul Ferguson 18 Sep '96

18 Sep '96

At 07:19 PM 9/17/96 -0400, Allan Chong wrote: >Hmmmm. If I were a hacker, I would be doing my best to make sure that >my route to the victim was taking a path through as many foreign >speaking networks as possible. You'd have to speak Swahili and >Cantonese :) > TCP (and UDP) happens to be a global village. :-) - paul

1 0