- Test - lists.nanog.org

ideas for half-open sync flood fixs
by peter＠telescan.com 20 Sep '96

20 Sep '96

ideas for half-open sync flood fixs? What I understand about this venerability: If a spoofed packet contains a host address that does exist on the net then the real host sends a reset and the fake half open socket is killed. No problem for the host. If a spoofed packet contains a nonexistent host address then no host is present to send a reset. Big problem for the host. fix 1. Doesn't the network respond with ICMP message to the attacked host telling it that the nonexistent host is unreachable. The attacked host could close a half open socket if it received a ICMP message with the corresponding host address and socket port data. fix 2. If a router cannot deliver a sync ack packet it could send a reset for that sync ack. fix 3. If a host sent a ping to the requesting source address before sending the sync ack then it could kill nonresponding hosts quickly. Three ideas form a lurker. Peter Cole peter(a)telescan.com Telescan Inc. (713) 588-9155 Better computing through lack of sleep Peter Cole (713)588-9155

2 1

filtering out reserved AS numbers
by Rob Liebschutz 20 Sep '96

20 Sep '96

I just noticed in the route server statistics web pages, that ANS is passing along a route to a network in AS 64512, somewhere in Mexico, which we are in turn also passing to our clients. I thought about filtering these AS numbers, but decided that it gets too costly to filter reserved AS numbers that might appear in arbitrary places in the ASPATH. Rob

1 0

Re: New Denial of Service Attack on Panix
by Justin W. Newton 20 Sep '96

20 Sep '96

At 12:37 PM 9/17/96 -0700, Michael Dillon wrote: >I still haven't seen anyone here volunteer a website for this although >http://www.mtiweb.com/isp has some information available. ISP/C has offered web space for this. Anyon who has filters for non-cisco routers alon with a short explanation, please email ray(a)carpe.net Justin Newton Internet Architect Erol's Internet Services

2 1

FW: MINDANAO: SYN Flooding Attack resulting in "Denial of ISP Service"
by Bernard S. Lopuz 20 Sep '96

20 Sep '96

just wud like to inquire abt this news...... ---------- From: Weedy Tan[SMTP:weedy@mnl.sequel.net] Sent: Friday, September 20, 1996 1:21 AM To: mindanao-l(a)teleport.com Subject: MINDANAO: SYN Flooding Attack resulting in "Denial of ISP Service" Dear FOM and in particular, ISPs in Mindanao Just like to inform you that there is a raging discussion about SYN attack in the USA resulting in the shutdown of an ISP. For more information, you can subscribe to "nanog(a)merit.edu" ___________________________________________________________________ Weedy Tan S R Printing, 810 Benavidez St., Binondo, Manila 1006, Philippines Tels: (632)2448306; (632)2448325 Fax: (632)2448325 Email: weedy(a)mnl.sequel.net Visit my home page at "http://www.sequel.net/~weedy" ___________________________________________________________________

2 1

MAE West congested again?
by booloo＠cats.ucsc.edu 19 Sep '96

19 Sep '96

It looks to me as if MAE West may be congesting again. While things look fine at the moment, earlier I was seeing congestion when transitting between CERFNET (134.24.9.115) and ESNET (198.32.136.41). My understanding of the topology of MAE West is that there is a Gigaswitch at Ames and a Gigaswitch at MFS (in San Jose) connected by a pair of OC-3 ATM circuits. My belief is that CERFNET and ESNET have ports on different Gigaswitches. MFS has changed the web page which lists MAE West connections such that I am unable to easily tell who is on which switch. In looking back at stats for the OC-3 link prior to the addition of the second circuit, I note the circuit maxes out around 70 Mbits/sec. In discussing this around here, we concluded that data is probably clocked out the Gigaswitch at 100 Mbits/sec and ATM overhead accounts for the remaining loss of available bandwidth. Can anyone confirm this for me? The graph for the OC-3 pair from yesterday indicates that it's time to add more bandwidth between switches. I'm real interested in knowing what plans MFS has up its sleeves for alleviating congestion this time around. Provisioning an OC-3 and only burning half the available bandwidth doesn't strike me as a scalable solution. mb

2 2

Re: New Denial of Service Attack on Panix
by Kent W. England 19 Sep '96

19 Sep '96

At 01:24 PM 9/18/96 -0400, Paul Ferguson wrote: >At 10:43 AM 9/18/96 -0400, Jeff Young wrote: > >> >>i guess the one common thread of this discussion is that whatever >>must be done, must be done on the edges of the internet. and that's >>not a cop out, we have as many edge cases as we have connections to >>isp's. >> > >No argument here. > If that be the consensus then there is only one way to accomplish anything and that is for a handful of large backbone providers to begin checking and to require that their peers also check source addresses. Otherwise it's just an undocumented BCP. --Kent

1 0

Re: MAE West congested again?
by feldman＠MFSDatanet.COM 19 Sep '96

19 Sep '96

> At http://ext2.mfsdatanet.com/MAE/west.map.html you will find a > connection map dated Sept 18. It was incorrect for some reason, today's map is at the end of this message. > I should add that CERFnet has TWO routers on Gigaswitches: one > of each side of the MAE ( NASA and MFS-San Jose). > > ESNET seems to have a router on the MFS side . The CERFnet router > you mention is on the MFS-San Jose side as well. The IP address > (134.24.9.115) you refer to is the SMDS interface to the CIX on that > router. The MAE-FDDI side address of that router 198.32.136.55. > > What you report seems to suggest congestion in the switch at the > MFS side ... Yup, one of the OC3c circuits was down, the other was full. It's all better now! > > If you can share more information about the end to end path you > were testing, I could shed more light on it. > > --pushpendra > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > Hope this helps, Steve Map generated: Thu Sep 19 12:00:00 PDT 1996 Ames-Giga/1 198.32.136.1 rs1.mae-west.ra.net Ames-Giga/1 198.32.136.2 rs2.mae-west.ra.net Ames-Giga/1 198.32.136.3 rs3.mae-west.ra.net Ames-Giga/1 198.32.136.10 T3-CRL-SFO-01-H1/0.US.CRL.NET Ames-Giga/1 198.32.136.24 mae-west.geonet.net Ames-Giga/1 198.32.136.41 esnet-1mae-west.es.net Ames-Giga/1 198.32.136.70 bb.mae-w.home.net Ames-Giga/1 198.32.136.81 mae-west.dren.net Ames-Giga/1 198.32.136.84 maew.nsn.net Ames-Giga/1 198.32.136.88 fix-west-pilot-fddi2.disa.mil Ames-Giga/2 198.32.136.12 mae-west.SanFrancisco.mci.net Ames-Giga/3 198.32.136.11 sl-mae-w-F0/0.sprintlink.net Ames-Giga/4 198.32.136.62 fddi0/0.br1.nqu1.alter.net Ames-Giga/5 198.32.136.5 maewest-nasa-fddi.cerf.net Ames-Giga/6 198.32.136.9 mae-west.ans.net Ames-Giga/9 198.32.136.43 ames3.mae-west.nasa.gov Ames-Giga/9 198.32.136.44 ames4.mae-west.nasa.gov Catalyst-1/4 198.32.136.53 mae-w1.idt.net Catalyst-1/5 198.32.136.85 mae-west.dx.net Catalyst-1/6 198.32.136.32 MAE-WEST.AIMNET.NET Catalyst-1/9 198.32.136.74 maewest.r1.brainstorm.net Catalyst-2/3 198.32.136.28 San-Jose1.CA.US.EU.net Catalyst-2/4 198.32.136.35 MAE-West-gw.ThePlanet.co.uk Catalyst-2/5 198.32.136.18 mae-west.scruz.net Catalyst-2/9 198.32.136.29 mae-west.itl.net Catalyst-3/3 198.32.136.71 mae-west.linkage.net Catalyst-3/5 198.32.136.52 mae-west.ncit.net Catalyst-3/6 198.32.136.57 maewest-gw.vbc.net Catalyst-3/7 198.32.136.67 mae-west.euro.net Catalyst-3/8 198.32.136.76 mae-west.nacamar.net Catalyst-3/9 198.32.136.33 mae-west.exodus.net MFS FDDI 198.32.136.16 mae-west2.agis.net MFS FDDI 198.32.136.26 mae-west.pch.net MFS FDDI 198.32.136.38 mae-west.internex.net MFS-Giga/10 198.32.136.23 mae-west.psi.com MFS-Giga/11 198.32.136.34 mae-west.wenet.net MFS-Giga/12 198.32.136.14 mae-w.bbnplanet.net MFS-Giga/13 198.32.136.31 mae-west.above.net MFS-Giga/14 198.32.136.37 mae-west.good.net MFS-Giga/15 198.32.136.19 sanjose1-br1.bbnplanet.net MFS-Giga/16 198.32.136.27 sjc7k01-fddi4-0-maewest.noc.conxion.net MFS-Giga/17 198.32.136.55 maewest-sjose-fddi.cerf.net MFS-Giga/18 198.32.136.13 mae-west.nap.net MFS-Giga/18 198.32.136.22 mae-west.tlg.net MFS-Giga/18 198.32.136.25 mae-west.iconnet.net MFS-Giga/18 198.32.136.30 mae-west.hlc.net MFS-Giga/18 198.32.136.47 mae-west.iij.net MFS-Giga/18 198.32.136.48 snfc1.grid.net MFS-Giga/18 198.32.136.49 snfc4.grid.net MFS-Giga/18 198.32.136.68 sfd1-mae-west.cwix.net MFS-Giga/18 198.32.136.69 sfd2-mae-west.cwix.net MFS-Giga/18 198.32.136.78 mae-west.he.net MFS-Giga/19 198.32.136.56 f1.sj1.genuity.net MFS-Giga/20 198.32.136.59 mae-west.sf.compuserve.net MFS-Giga/22 198.32.136.39 enss220.t3.ans.net MFS-Giga/23 198.32.136.40 mae-west.isi.net MFS-Giga/24 198.32.136.15 mae-west.netcom.net MFS-Giga/25 198.32.136.72 cpe1.hay.mci.net MFS-Giga/26 198.32.136.60 mae-west.digex.net MFS-Giga/28 198.32.136.36 mae-west.best.net MFS-Giga/29 198.32.136.21 mae-west.agis.net MFS-Giga/29 198.32.136.61 mw.mainstreet.net MFS-Giga/29 198.32.136.63 mae-west1.agis.net MFS-Giga/30 198.32.136.42 san-jose3.ca.alter.net MFS-Giga/31 198.32.136.80 mae-west.wna.net MFS-Giga2/10 198.32.136.50 mae-west1.SanJose.mfs.net MFS-Giga2/11 198.32.136.58 sjc-01-f6/0.primenet.net MFS-Giga2/22 198.32.136.86 mae-west.dra.net MFS-Giga2/23 198.32.136.20 mae-west.advantis.net MFS-Giga2/24 198.32.136.75 gte_mae_west.GTE.NET

1 0

Re: MAE West congested again?
by feldman＠MFSDatanet.COM 19 Sep '96

19 Sep '96

One of the two OC3c circuits between MFS and Ames was down for a while today, resulting in the congestion you were seeing. It is better now. The 70 meg limit appears to be a measurement artifact, rather than a real throughput limit, though we're still trying to confirm that. We believe that the OC3c interface should be capable of nearly the full 100 Mbps limit of the Gigaswitch's crossbar, in each direction. I'll fix the map so it reports correctly starting tomorrow. Steve > From owner-nanog(a)merit.edu Thu Sep 19 14:50:38 1996 > From: booloo(a)cats.ucsc.edu (Mark Boolootian) > Subject: MAE West congested again? > To: nanog(a)merit.edu > Date: Thu, 19 Sep 1996 14:38:45 -0700 (PDT) > X-Mailer: ELM [version 2.4 PL23] > Content-Type: text > Sender: owner-nanog(a)merit.edu > > > It looks to me as if MAE West may be congesting again. While things look > fine at the moment, earlier I was seeing congestion when transitting between > CERFNET (134.24.9.115) and ESNET (198.32.136.41). > > My understanding of the topology of MAE West is that there is a Gigaswitch > at Ames and a Gigaswitch at MFS (in San Jose) connected by a pair of > OC-3 ATM circuits. My belief is that CERFNET and ESNET have ports on > different Gigaswitches. MFS has changed the web page which lists MAE West > connections such that I am unable to easily tell who is on which switch. > > In looking back at stats for the OC-3 link prior to the addition of the > second circuit, I note the circuit maxes out around 70 Mbits/sec. In > discussing this around here, we concluded that data is probably clocked > out the Gigaswitch at 100 Mbits/sec and ATM overhead accounts for the > remaining loss of available bandwidth. Can anyone confirm this for me? > > The graph for the OC-3 pair from yesterday indicates that it's time to > add more bandwidth between switches. I'm real interested in knowing what > plans MFS has up its sleeves for alleviating congestion this time around. > Provisioning an OC-3 and only burning half the available bandwidth doesn't > strike me as a scalable solution. > > mb >

1 0

does history repeat itself?
by Brett D. Watson 19 Sep '96

19 Sep '96

i noticed some pretty poor aggregation in some of the most recently allocated address space tonight: (advertising as's withheld to protect the innocent/guilty) 208.201.64.0/21 208.201.73.0 208.201.88.0/21 208.201.97.0 208.201.103.0 208.201.112.0/22 208.218.64.0/20 210.135.160.0/20 210.135.192.0/22 210.135.224.0/20 this seems especially bad with all the talk of better ways to allocate and advertise so that we don't waste address space. i do note that most of what i call poor aggregation appears to be due to "dual homing". are we just doomed to poor aggregation because of this? or maybe i'm just naive in thinking the internic is really cracking down on small allocations and that providers are really working hard to aggregate. -brett

16 26

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