- NANOG - lists.nanog.org

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

Re: Questions: Long Range Dependence
by Vern Paxson 16 Mar '98

16 Mar '98

> 1. Single VBR video source traffic is considered as LRD traffic. What are > the characteristics of multiplexing traffic of multiple sources, (e.g., > does the output traffic of an ATM multiplexer have the property of LRD?). Yes - multiplexed LRD is likewise LRD. > 2. Since Internet traffic (i.e., LAN/WAN) is partly considered as LRD > traffic, what impact does it have on design of Bridge/Router? You need a whole lot of buffer to absorb bursts. > 3. Where can I find Video traffic database (e.g., film compressed by > Mpeg-2)? I know these exist, but unfortunately can't point you at any. > 4. Are there any mail groups discussing LRD and/or ATM? I don't know of any for LRD. ATM is discussed in the newsgroup comp.dcom.cell-relay. To get more detailed answers, you should dig through the past five years of SIGCOMM proceedings, and also the past three or so years of IEEE/ACM Transactions on Networking, both of which have had a number of LRD-related papers. Vern

1 0

Questions: Long Range Dependence
by Zhang Peng 16 Mar '98

16 Mar '98

Hi, I am greatly interested in doing some work on Long Range Dependence of ATM traffic modeling. I have several questions as follows. 1. Single VBR video source traffic is considered as LRD traffic. What are the characteristics of multiplexing traffic of multiple sources, (e.g., does the output traffic of an ATM multiplexer have the property of LRD?). 2. Since Internet traffic (i.e., LAN/WAN) is partly considered as LRD traffic, what impact does it have on design of Bridge/Router? 3. Where can I find Video traffic database (e.g., film compressed by Mpeg-2)? 4. Are there any mail groups discussing LRD and/or ATM? Thanks, Zhang Peng

1 0

BGP: IOS 11.2(12)P & Route-Map problems?!
by jlixfeld＠idirect.ca 15 Mar '98

15 Mar '98

I recently upgraded to IOS 11.2(12)P and I'm having some trouble with route-maps taking. I'm wondering if anyone has had a similar incident: neighbor 205.150.206.65 route-map UUNET in neighbor 206.47.45.128 route-map BGS in ! ip as-path access-list 100 permit _816_ ip as-path access-list 100 permit _701_ ip as-path access-list 100 permit _1673_ ip as-path access-list 100 permit _2548_ ip as-path access-list 100 permit _3602_ ip as-path access-list 100 permit _1239_ ip as-path access-list 100 permit _6463_ ip as-path access-list 100 permit _2493_ ip as-path access-list 100 permit _174_ ip as-path access-list 101 permit .* ip as-path access-list 110 permit _2493_ ip as-path access-list 110 permit _174_ ip as-path access-list 110 permit _3804_ ip as-path access-list 110 permit _577_ ip as-path access-list 110 permit _3561_ ip as-path access-list 110 permit _6453_ ip as-path access-list 110 permit _2551_ ip as-path access-list 110 permit _6996_ ip as-path access-list 110 permit _1324_ ip as-path access-list 110 permit _1_ ip as-path access-list 110 permit _6347_ ip as-path access-list 110 permit _6463_ ip as-path access-list 110 permit _3602_ ip as-path access-list 110 permit _1239_ ip as-path access-list 110 permit _1673_ ip as-path access-list 110 permit _2548_ ip as-path access-list 111 permit .* ! route-map BGS permit 10 match as-path 100 set local-preference 50 ! route-map BGS permit 20 match as-path 101 set local-preference 60 ! route-map BGS permit 30 ! route-map UUNET permit 10 match as-path 110 set local-preference 40 ! route-map UUNET permit 20 match as-path 111 set local-preference 60 ! route-map UUNET permit 30 c7# sh ip bgp reg 701 * 16.0.0.0 206.222.95.53 60 0 6463 1239 701 33 i * 206.47.45.128 60 0 3804 577 6453 701 33 i *> 205.150.206.65 60 0 816 701 33 i The path 3804 577 6453 33 should have a local preference of 50 (access-list 100), not 60! (access-list 101) Path 816 701 33 is correct at 60 (access-list 111) c7# sh ip bgp reg 3561 * 12.10.14.0/23 206.47.45.128 60 0 3804 577 3561 10815 ? *> 205.150.206.65 60 0 816 701 3561 10815 ? It looks as though it is tagging everything as .*.. but this is odd. It tagged this route properly: * 24.231.0.0/19 206.47.45.128 50 0 3804 577 3561 2493 2493 8160 8160 i Anyone have any ideas?! I've done clear ip bgp xxx soft in but not clear ip bgp xxx I was running 11.2(5) before which had an route cache bug so I'm used to doing a clear ip cache after each reload. Did that too, and nothing. -- 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 Pat Darisme 15 Mar '98

15 Mar '98

I don't see a problem here ? According to RFC 1918 the Net 10 and Net 172.16/12 and 192.168/16 addresses are for use privately or internally such as when : " - Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise." These addresses are however not advertised to the outside world and should thus cause no problem here. We are simply seeing those net 10 addresses as a source address for those packets returned by the traceroute, but that address should not be reacheable or advertised from outside the internal network. See http://www.cis.ohio-state.edu/htbin/rfc/rfc1918.html for more details. Thanks Pat @Home Network Operations Once upon a time, Marc Hurst arranged the electrons in @Home's private scaleable, ATM, OC3 BackBone to write: > Subject: Someones being naughty again... > (Mar 13, 6:56pm) > Here is a traceoute from BBN Planet to my machine... (sorry D, couldn't > resist...:) > > traceroute to 24.112.43.xx (24.112.43.xx), 30 hops max, 40 byte packets > 1 netgwb (205.227.188.1) 196 ms 611 ms 9 ms > 2 oakland-cr2.bbnplanet.net (4.0.68.77) 20 ms 15 ms 19 ms > 3 oakland-br2.bbnplanet.net (4.0.16.17) 16 ms 15 ms 22 ms > 4 sanjose1-br1.bbnplanet.net (4.0.1.74) 25 ms 16 ms 15 ms > 5 bb.mae-w.home.net (198.32.136.70) 19 ms 17 ms 21 ms > 6 172.16.2.174 (172.16.2.174) 110 ms 108 ms 107 ms > 7 r3-fe0-0-100bt.rdc1.on.wave.home.net (24.2.9.4) 121 ms 108 ms 112 ms > 8 10.0.184.34 (10.0.184.34) 153 ms 109 ms 106 ms > 9 pc-30xxx.on.rogers.wave.ca (24.112.43.xx) 110 ms 111 ms 110 ms > > Nice 10.x.x.x. > End of included message written by Marc Hurst on Mar 13, 6:56pm, >

11 16