January 1999 - Test - lists.nanog.org

Performance problems between sprint and uunet?
by Fletcher E Kittredge 14 Jan '99

14 Jan '99

Apologies for bothering the list, but we have had tickets open with both parties without resolution. For the last few weeks, we have been seeing performance issues between sprint and uunet. We have not been able to determine anything which would be unique about our configuration. The symptoms are a 400ms latency between Sprint and UUnet routers and a 25% packet loss. An example trace fragment is: 2 Serial4-1-1.GW1.BOS1.ALTER.NET (157.130.4.25) 6.810 ms 9.343 ms 10.909 ms 3 123.ATM2-0.XR1.BOS1.ALTER.NET (146.188.176.226) 11.137 ms 10.868ms 17.13 5 ms 4 191.ATM3-0.XR1.EWR1.ALTER.NET (146.188.176.133) 22.651 ms 21.483ms 14.98 8 ms 5 193.ATM1-0-0.BR1.EWR1.ALTER.NET (146.188.176.49) 12.580 ms12.849 ms 16.1 78 ms 6 sl-pen-11-h3.sprintlink.net (137.39.44.130) 434.196 ms 432.565ms 438.700 ms 7 sl-bb11-pen-0-1.sprintlink.net (144.232.5.9) 451.170 ms 464.872ms 426.18 1 ms 8 sl-bb12-pen-10-0.sprintlink.net (144.232.5.158) 488.077 ms * 419.564 ms 9 sl-bb11-fw-3-0.sprintlink.net (144.232.8.157) 444.772 ms 462.465ms 457.6 47 ms 10 sl-gw15-fw-8-0-0.sprintlink.net (144.232.11.82) 499.928 ms476.629 ms 481 .154 ms Is anyone else seeing this? thanks! fletcher

1 0

Re: Smurfing and IP filtering
by Jeff Mcadams 14 Jan '99

14 Jan '99

Thus spake Steven J. Sobol >On Thu, Jan 14, 1999 at 01:30:01PM +0300, Alex P. Rudnev wrote: >> There is RFC recommendation for the router. >> Why there is not RFC describing the policy (mandatory!) for the ISP? >An RFC is a recommendation. A typical RFC usually ends up being a de-facto >standard, however it does not have the force of law. >Backbone operators have to start putting pressure on their downstreams to >fix their router configs. The downstreams have to put pressure on THEIR >downstreams, etc. The only way to get everyone to fix their routers is to >write clauses into contracts saying "if your network ends up being a smurf >amplifier, and we find that your routers are misconfigured, you will be >disconnected from the Net without any kind of refund or credit for your >downtime, and you will remain down until you fix things." >That, and education, will do the trick. True, but publishing an RFC to add some weight to that might help in that education effort and help the upstreams convince their downstreams that it needs to be done. A well written RFC might also be a document that the upstreams could send to the downstreams to help them understand actually what's going on with the situation and help them understand why it needs to be fixed (why in the greater overall good scheme of things, though why in the "do this or we're axing your connection" will help as well). If the issues are outlined in a nice format that people can read, I suspect you'll get less opposition from downstreams that don't want to muck with their already fine (as far as their performance can tell) router configs. While I agree...education, and threatening to ax connections *should* do the trick, the sad truth here is that before you can deal with router configs, you're dealing with humans in these organizations that you have to convince this is a good thing to do. I believe that an RFC would *help* to do that. No, it shouldn't be necessary, but if there's very little downside to it (and I don't see much downside to publishing an RFC...maybe a Best Current Practices or something), and there's some upside to it in that it might help convince some recalcitrant or ignorant network operators out there to change their router configs...well then, I say, let's do it. -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

2 1

RE: Smurfing and IP filtering
by Scott McGrath 14 Jan '99

14 Jan '99

That would be a good starting point for the more sophisticated users however most small networks have very uneven clue distribution so I believe something in a FAQ format would be more approachable to the small ISP/Network operator and therefore more likely to be implemented even if they did not fully understand the configuration. We also need to create documents which explain what each of the configs do > -----Original Message----- > From: Chris Cook [SMTP:ccook@netasset.com] > Sent: Wednesday, January 13, 1999 1:28 PM > To: 'Scott McGrath' > Subject: RE: Smurfing and IP filtering > > This is a really good idea. A thought on what to start with would the > Cisco IOS Essentials Guide that was mentioned about a month ago. I have > begun implementing parts of this on our edge devices (mostly cisco's). It > could probably be simplified and amended (for things like Bay hardware). > > Chris Cook > > NetAsset, LLC > Fresno, CA > > -----Original Message----- > From: Scott McGrath [mailto:SMcGrath@YBP.com] > Sent: Wednesday, January 13, 1999 9:08 AM > To: nanog(a)merit.edu > Subject: Smurfing and IP filtering > > > I have been lurking on the Smurfing issue for a while > > In my experience most tier 2&3 ISP's when they sell T1 access to the > internet just deliver a basic configuration > on the router with NO route filters whatever they do not even put the most > basic access restrictions on the router > We as a group should create a best practices document (with sample > config's) > to increase the distribution of cluefulness > across the network as a whole to reduce the incidence of these problems > and > make less firefighting neccessary for ourselves. > > > Scott Mc Grath > Yankee Book Peddler > 999 Maple Street > Contoocook, NH 03229 > Phone: 603 746-3102 x3350 > Fax: 603 746-5628 > > mailto:smcgrath@ybp.com

3 3

latency vs. packet loss
by jzeeff＠whs.verio.net 14 Jan '99

14 Jan '99

How well does latency correlate to packet loss on the Internet? For example, if one were to pick one of several randomly placed sites on the net based on lowest latency to/from point x, what percentage of this time would this also yield the site with the lowest packet loss to/from point x? My guess is that the correlation is high (due to typical buffer sizes).

2 2

RE: source filtering
by Scott McGrath 14 Jan '99

14 Jan '99

I only spoke from my own experience with both carriers no offense intended > -----Original Message----- > From: Tony Tauber [SMTP:ttauber@bbnplanet.com] > Sent: Wednesday, January 13, 1999 10:38 PM > To: Scott McGrath; Jared Mauch; nanog(a)merit.edu > Subject: Re: source filtering > > On Jan 13, 3:41pm, Scott McGrath wrote: > > Subject: RE: source filtering > > GTE and ATT both filter via access lists on the customers CPE routers IF > > they provide the routers to the customer > > > > It'd be nice if this information came from one of the entities > named above. Here's a refinement for our part. > > GTE does not impose mandatory source address filtering via > access-lists on customers' CPE routers. However, we have recently > implemented Cisco's "ip verify unicast reverse-path". > > Tony Tauber > GTE Network Engineering

1 0

RE: Smurfing and IP filtering
by Scott McGrath 13 Jan '99

13 Jan '99

Both would be a good idea as it would cover all the bases for most network operators > -----Original Message----- > From: Steven J. Sobol [SMTP:sjsobol@nacs.net] > Sent: Wednesday, January 13, 1999 9:50 PM > To: Scott McGrath > Cc: Chris Cook; nanog(a)merit.edu > Subject: Re: Smurfing and IP filtering > > On Wed, Jan 13, 1999 at 02:19:47PM -0500, Scott McGrath wrote: > > That would be a good starting point for the more sophisticated users > however > > most small networks have very uneven > > clue distribution so I believe something in a FAQ format would be more > > approachable to the small ISP/Network operator > > ...why not both? > > Cover configuration for, say, the top 5 brands of routers (which, > realistically, should cover the majority of ISP's out there...) > > -- > Steve Sobol [sjsobol(a)nacs.net] > Part-time Support Droid [support(a)nacs.net] > NACS Spaminator [abuse(a)nacs.net] > > Proud resident of Cleveland Heights, Ohio, the coolest place on earth. > http://www.ClevelandHeights.com

1 0

Re: Solution: Re: Huge smurf attack
by Dean Anderson 13 Jan '99

13 Jan '99

Actually, I think all major providers use automatic provisioning systems which generate router configs. They don't need to rely on router vendors to set particular defaults. If all major providers made sure their provisioning systems turned off directed broadcast, a lot of the problem would go away. So "Router defaults" is a lame excuse for ISP's. Even little ISP's have a list of things they have to setup, (eg ip classless, subnet zero, etc) which have "legacy" or otherwise inappropriate defaults. And yes, some customers may in fact want or need directed broadcasts on. For example, if they are subnetting. In that case, you change it for them. I tell our customers certain things are turned off by default, and if they really want it on, they will need to ask. Of course, the problem remains that some smurfers are undoubtedly on this list, possibly working for major providers. (This is my guess as to source of the 10.x smurf amps.) --Dean At 02:05 AM 1/12/1999 -0500, Brandon Ross wrote: >On Mon, 11 Jan 1999, Daniel Senie wrote: > >> The proper answer to this is to disable directed broadcasts on the >> routers themselves. It'd be helpful if routers came out of the box with >> this feature disabled by default. Perhaps folks should talk with their >> router vendors of choice and ask for this change. I have submitted a >> draft into the IETF process to require this change, updating RFC 1812 >> (router requirements). > >I'm happy to say that progress is being made in this area. When a vendor >comes to us for the first time, one of things I tell them is that we will >not buy their hardware until they ship with directed broadcast disabled by >default. We've had a lot of success in this area, we'd have even more if >others would do the same. > >Brandon Ross Network Engineering 404-815-0770 800-719-4664 >Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com > ICQ: 2269442 > >Stop Smurf attacks! Configure your router interfaces to block directed >broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 6

Re: Huge smurf attack
by Dean Anderson 13 Jan '99

13 Jan '99

At 09:48 AM 1/12/1999 -0800, Dalvenjah FoxFire wrote: >On Tue, Jan 12, 1999 at 05:12:22PM +0000, Michael Shields put this into my mailbox: > >> In article <19990111101351.04195(a)dragonlair.dal.net>, >> Dalvenjah FoxFire <dalvenjah(a)DAL.NET> wrote: >> > Much as I hate to say it, this seems to be one area where industry >> > self-regulation has utterly failed. I don't know what would be a better >> > solution; I hate to suggest government regulation. But I'm at a loss here. >> >> Civil liability? > >Possibly. I don't know of anyone who's tried suing over a smurf attack. >If I could afford the lawyer and the court time I'd do it myself. >All we really need is one or two good cases to establish some case law; >then the rest of us can have some legal precedent to point to and say >"If you don't fix your networks, you're screwed." Criminal. DOS attacks are covered by 18 USC 1030. And I think there might even be smurf included in the Kevin Mitnick case, but I'm not sure about that. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: Huge smurf attack
by Brandon Ross 13 Jan '99

13 Jan '99

Doh! That should have read: ftp://ftp.mindspring.net/users/bross/smurfsources On Sat, 9 Jan 1999, Quan Nguyen wrote: > On Sat, 9 Jan 1999, Brandon Ross wrote: > > > Since a couple folks have asked for it, and I think the list is a bit > > large to send to the entire list, I've put the list up for anonymous ftp > > at: > > > > ftp://www.mindspring.net/users/bross/smurfsources > > I got this. My network is 132.206.0.0/26. > > % ftp www.mindspring.net > ftp: connect to address 207.69.200.96: Connection refused > Trying 207.69.200.97... > ftp: connect: Connection refused > ftp> quit > > > Quan, > > Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

14 25

Re: Solution: Re: Huge smurf attack
by danderson＠lycos.com 13 Jan '99

13 Jan '99

I should have been more careful when stating 'filtering icmp' in my previous messages. I use something similar to this: >access-list 101 deny icmp any any echo >access-list 101 deny icmp any any echo-reply >access-list 101 permit icmp any any Only I'm allowing the echo-reply so I can ping/traceroute out for my troubleshooting needs. However, I don't buy the 'it breaks testing methods' because there are other ways to test that using icmp for incoming stuff. Plus, if you use named access lists (in new code releases), you can throw in a permit statement then delete it without taking out the whole list. (That is done with the 'ip access-list extended <name>' subset- very nice, check it out) Of course this doesn't do anything for your upstream links, but what can you do about that anyway? Get on your tier 1 provider for that! Plus, you STILL have directed broadcasts turned off in my scenario so the access list is almost futile. And if you are worried about excess CPU utilization, so what? Look into stuff like the netflow switching commands rather than the optimal setting. That can make a tremendous difference. Or you can always buy better gear! How important is your service?? later- devin "Craig A. Huegen" <chuegen(a)quadrunner.com> on 01/12/99 02:01:04 PM To: Steve Gibbard <scg(a)wwnet.net>, Devin Anderson/Lycos cc: nanog(a)merit.edu Subject: Re: Solution: Re: Huge smurf attack On Tue, Jan 12, 1999 at 01:11:09PM -0500, Steve Gibbard wrote: ==>On Tue, 12 Jan 1999 danderson(a)lycos.com wrote: ==> ==>> I'm not sure what the big issue here is with the smurf attacks. If you set ==>> up some kind of access list that disables incoming icmp traffic, then turn ==> ==>That breaks path MTU discovery (see RFC 1435 for more info on that), among ==>other things. Two choices: access-list 101 deny icmp any any echo access-list 101 deny icmp any any echo-reply access-list 101 permit icmp any any -or- access-list 101 permit icmp any any packet-too-big access-list 101 deny icmp any any Neither of these is a particularly elegant solution because they block troubleshooting tools such as ping and traceroute. CAR works well to provide these troubleshooting services during normal operations and to help suppress attacks. /cah

4 3