March 1998 - Test - lists.nanog.org

why filtering ICMP can break PMTU-D
by Marc Slemko 16 Mar '98

16 Mar '98

I have had a few requests regarding just how ICMP messages not reaching where they should (for whatever reason, including using private address space that is filtered somewhere) can break path MTU discovery. Anyone interested who doesn't understand it should take a look at the brief description I have available at: http://www.worldgate.com/~marcs/mtu/ which tries to be as simple as possible and explain it in a way that almost anyone can understand. Was originally made for referencing in complaints to silly providers that break connectivity by broken filtering and can't understand the problems.

1 0

E-mail quotas
by Steve Hultquist 16 Mar '98

16 Mar '98

I'd like to get some input on how many of you are doing quotas for e-mail and what mechanism you are using for it. If you can take a minute, please send your replies to me (mailto:ssh@HSAnet.net) and I'll summarize to the list if there is interest. Thanks, ssh -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

1 0

Re: Building a NOC
by David A. Greer 16 Mar '98

16 Mar '98

Bill, Skipping John's message for a minute with the number of small ISP's out there it is actually forseeable that a book on starting an ISP might be possible to a limited extent. I would have welcomed such a book when I set up our internet gear (we would qualify as a medium sized ISP in our own right.) Now to get back to John's message, although there is some information out there that could be read there are a number of questions that you should ask yourself as far as scope of the project, number of sites, technical level at the remote sites, do you need to monitor Sniffers and the like or just plain Openview/Spectrum. Also does this NOC have to monitor and dispatch repair techs only or does it have to answer questions like how do I change my password on the server in my office. What about monitoring of the various servers in the enterprise? Novell? NT? Unix flavors, etc. Put all this together and the project manager in charge better have done it before at least once, or else this would quickly become a moneypit. Another major consideration is how much money and floor space is available for the NOC. I have seen several companies under-estimate the floor space needed and end up shoving stuff into corners to get it all into the allocated space, or scrimping money because the budget didn't live up to the pipe dreams of over eager planning personnel. David Greer Project Manager, Wide Area Telecommunications General Nutrition Companies, Inc. David-Greer(a)GNC-HQ.COM -----Original Message----- From: Goldstein_William(a)bns.att.com <Goldstein_William(a)bns.att.com> To: John_W_Connors(a)res.raytheon.com <John_W_Connors(a)res.raytheon.com>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, March 16, 1998 3:36 PM Subject: RE: Building a NOC

1 0

Re: [nsp] UDP broadcast filters. (fwd)
by Eric Germann 16 Mar '98

16 Mar '98

At 10:52 AM 3/16/98 -0800, Craig A. Huegen wrote: > <SNIP> </SNIP> > >#echo stream tcp nowait root internal >#echo dgram udp wait root internal >#chargen stream tcp nowait root internal >#chargen dgram udp wait root internal > As an additional note, on NT boxes, these can all be effectively whacked by not installing or disabling the "Simple TCP/IP Services" service. Mail me if you care. Eric ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

Re: UDP broadcast filters.
by Joe Provo - Network Architect 16 Mar '98

16 Mar '98

> I've kept hearing about a UDP smurf floating around and I'd like to put up [snip] This is nothing new, except that code for those that just want toys to break other people's networks has been put out on bigtraq (fraggle.c). Shut off udp services you don't need. Re-read the last bit; in generally, if you don't need to be running something, you're inviting it to be abused. Pare down to what you need. Anyway, use "no service udp-small" in global config on a cisco. Go into inetd and shut off echo and chargen on un*x boxen; review what else you have turned on while you're at it. Keep using "no ip directed-broadcast" (and relatives on non-cisco gear). Squirting packets at open UDP ports happens; it can only get amplified in a "smurf-like" [smurfy?; eg, meaningfully damaging] fashion if you've got interesting combinations of echo and chargen involved. joe, speaking for himself as usual.

1 0

Re: [nsp] UDP broadcast filters. (fwd)
by Craig A. Huegen 16 Mar '98

16 Mar '98

Here's some more information about the release of the UDP smurf, also called "fraggle", which was made this weekend. I understand a request was made to nanog as well requesting information. Almost the same rules as "smurf" applies. "no ip directed-broadcast" is your friend. /cah ---------- Forwarded message ---------- Date: Mon, 16 Mar 1998 09:35:36 -0800 (PST) From: "Craig A. Huegen" <chuegen(a)quadrunner.com> To: Cisco-NSP <cisco-nsp(a)iagnet.net> Cc: Cisco at Colorado <cisco(a)spot.colorado.edu> Subject: Re: [nsp] UDP broadcast filters. On Mon, 16 Mar 1998 jlixfeld(a)idirect.ca wrote: ==>I've kept hearing about a UDP smurf floating around and I'd like to put up ==>a firewall to prevent it. Can anyone give me any insight on how this is ==>done? I don't understand enough about UDP, broadcasts or enough about ==>access-lists to create an effective one. Can anyone give me some ==>pointers? I'm going to be updating my smurf pages at http://www.quadrunner.com/~chuegen/smurf/ to contain the information about the UDP smurf. Basically, here's the key points: * UDP smurf is just like the ICMP smurf, using directed-broadcast and UDP port 7 * A bit more dangerous if the packet is spoofed just right, because it can cause and endless packet loop with some stacks until the packets get dropped. Prevention pieces: * "no ip directed-broadcast" still prevents your network from being an intermediary * Disable the internal troubleshooting services in machines, where possible. For UNIX boxes, comment the "echo" and "chargen" services in inetd.conf and restart inetd: #echo stream tcp nowait root internal #echo dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal * It's easier to filter UDP smurfs without breaking something. For instance, filtering ICMP smurfs required that you break ping (and block ICMP echo-reply packets) access-list <x> deny udp any eq echo any access-list <x> deny udp any any eq echo Adding these to an inbound access-list will protect the traffic from getting past. You should see more information on my pages in a few days. /cah

1 0

RE: Building a NOC
by Goldstein_William＠bns.att.com 16 Mar '98

16 Mar '98

1 0

Buying b/w directly from undersea cable owners
by Hank Nussbacher 16 Mar '98

16 Mar '98

I have a client that has the option of buying b/w directly from the undersea cable owners. Turns out that the new non-PTT owned cables, allow anyone to own STM-1's. Depending on who you use (Gemina, AC-1, etc.) prices hover around $7-11m purchase and around $250K/yr for maintenance. Since I do not know of the European counterpart to NANOG, I am hoping that people outside the USA (as well as inside) that have gone down this path can provide more info as to the pros and cons of buying from one of the standard carriers like Teleglobe, Sprint, Worldcom, etc. vs buying/owning the b/w yourself. Thanks, Hank

3 2

UDP broadcast filters.
by jlixfeld＠idirect.ca 16 Mar '98

16 Mar '98

I've kept hearing about a UDP smurf floating around and I'd like to put up a firewall to prevent it. Can anyone give me any insight on how this is done? I don't understand enough about UDP, broadcasts or enough about access-lists to create an effective one. Can anyone give me some pointers? -- Regards, Jason A. Lixfeld jlixfeld(a)idirect.ca System Administrator [L5] jlixfeld(a)torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 ext 18 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------

1 0

Re: Someones being naughty again...
by Sean Donelan 16 Mar '98

16 Mar '98

>The upstreams should certainly be filtering this. I am truly surprised >someone is still leaking a ten/8 network to the world. I'm not surprised someone is still leaking a 10/8 network. Remember "Trust, but verify...." I'm surprised anyone on this list would still be accepting 10/8 (and admit it). In-bound filters are as important as out-bound filters. And out-bound filters are as important as in-bound filters. Its a fact of life, everyone makes mistakes. It doesn't matter if it is an upstream, downstream, or sideways connection. There have been mistakes made in all directions. You need filters on both sides, in both directions. This is why its important to know what your upstream, downstream and sideways connections should be announcing, otherwise it is very difficult to tell when one of your upstream, downstream or sideways connections announces something they shouldn't. Of course, finding out what they should be announcing, storing the list on your router, and finding enough CPU to process the access lists, is another topic. See previous thousand messages on that topic. This isn't rocket science, its management science. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0