November 2002 - Test - lists.nanog.org

Attacker Data / Wall of Shame
by Daniel Senie 05 Nov '02

05 Nov '02

We have had enough regular attacks on our web farm to put together tools that catalogue the attacks, report them to a central database, and post them to a website. The data is extracted hourly for the website to cut down on server / database loading. You can find our display of this data at: http://www.shame.denialinfo.com/ You have the option of viewing the data by IP address, Date of attack or sorted by the number of attacks from a host. The attacking systems seem well distributed around the world, though the extent to which that's a result of open proxies is unclear. The data is aged out of the display (but not the database, just use select options to pick the data) after a period of time. We have much more data than we display on these pages, but this is enough for network operators to see if they've got habitually misbehaving hosts on their networks or their downstreams. Attacks we track include Nimda, Slapper and Formmail. Our servers are not vulnerable to the attacks, but the attacks generate enough traffic to result in a Denial of Service when they come in. We have considered a number of measures for blackholing traffic from these sites, but have not yet employed any of them. Building filter lists based on the dataset is impractical. We age the data in expectation of using it in a blackhole mechanism. We'd only want to block a host for a limited number of days after the last attack registered, so that hosts that have been secured will age off the list on their own. We'd be interested in comments and feedback on this mechanism, and hope some folks find it useful. ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranth.com

5 5

number of hops != performance
by Mikael Abrahamsson 05 Nov '02

05 Nov '02

We have competitors that are claiming that their network is superior to ours (salesdroids to customers) because they have fewer L3 hops in their network. I see this "fact" pop up in customer questions all the time. I can see that L3 hops adds latency if a network is built on slow (2meg for instance) links, but at gigabit speeds, L3 hops adds microseconds in latency (if you use equipment that forward using hardware-assisted forwarding, but as far as I know there are no routers out there nowadays that doesnt). Does anyone have a nice reference I can point to to once and for all state that just because a customer has 6-8 L3 hops within our network (all at gigabit speeds or higher) that doesnt automatically mean they are getting bad performance or higher latency. Hiding the L3 hops in a MPLS core (or other L2 switching) doesnt mean customers are getting better performance since equipment today forwards just as quickly on L3 as on L2. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

4 4

Blackholing APNIC Routes (or a subset of)
by Eric Germann 05 Nov '02

05 Nov '02

Anyone want to admit privately (I'll summarize to the list) if they actively filter certain partitions of APNIC space? We did a little experiment the past couple of days and saw at 85% of our port 13[5-9] scans, Code Red/Nimda/formmail attempts, etc. go out the door by blackholing those networks in .cn and .kr. Thoughts? Is it a valid thesis? I've seen the discussions for spam mitigation, etc via DNS, but this is actually null routing all their traffic. Eric ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert OH 45801 http://www.cctec.com Ph: 419 968 2640 Fax: 603 825 5893 "The fact that there are actually ways of knowing and characterizing the extent of one’s ignorance, while still remaining ignorant, may ultimately be more interesting and useful to people than Yarkovsky" -- Jon Giorgini of NASA’s Jet Propulsion Laboratory

5 4

Re: number of hops != performance
by Michael.Dillon＠radianz.com 05 Nov '02

05 Nov '02

>Does anyone have a nice reference I can point to to once and for all state >that just because a customer has 6-8 L3 hops within our network (all at >gigabit speeds or higher) that doesnt automatically mean they are getting >bad performance or higher latency. When I was at Ebone I would sometimes visit large accounts just to help the salespeople with this question. I would bring along a copy of our measurement data and show these customers exactly what our network latency was measured in milliseconds not in hops. Everyone understood milliseconds and I knew that our network had lower latency than the competition. Of course, the fact that we did measure latency with a matrix of over 20 cities was a strong selling point as was the fact that we made this data available to customers. The salespeople were overjoyed because this was far stronger than the material that our marketing department made available. >Hiding the L3 hops in a MPLS core (or other L2 switching) doesnt mean >customers are getting better performance since equipment today forwards >just as quickly on L3 as on L2. And this is exactly what I would explain. Customers are intelligent enough to understand that hops equal devices and that hiding the hops/devices from IP traceroutes does not make them go away. Then I told them that we engineered our network for speed (wirespeed switching, zero buffering, zero packet loss) so that we weren't ashamed of the hops. But perhaps the other guys had something to hide? When you have something great to sell, you have to cut through the bullshit and demonstrate the greatness to the customer. Assuming that they want low latency, you have to show them beyond a shadow of a doubt that your latency is low. And if your latency isn't low, then you need to either fix the problem or find customers who care about other things like PoP locations or SLA reporting or something other than network quality. --Michael Dillon

1 0

Problems with UU->Level3 last night?
by Temkin, David 05 Nov '02

05 Nov '02

Last night I saw an issue with connectivity between a domestic site in Pennsylvania off of Level3's network connecting to a site on UUNet in Australia - latency was almost triple of what it normally is... Level3's response was of course "We don't see anything" - even with traceroutes showing otherwise. Did anyone else experience anything or hear anything about it? Latency is normally in the ~240ms range. 1 Loopback0.GW1.SYD2.Alter.Net (210.80.0.54) 4 msec 4 msec 4 msec 2 321.at-3-0-0.XR1.SYD2.Alter.Net (210.80.3.89) 8 msec 8 msec 4 msec 3 so-3-0-0.TR2.SYD2.Alter.Net (210.80.48.145) 4 msec so-3-0-0.TR1.SYD2.Alter.Net (210.80.48.133) 4 msec 4 msec 4 0.so-5-0-0.IR1.SAC2.Alter.Net (210.80.49.150) 164 msec 0.so-1-0-2.IR2.SAC2.Alter.Net (210.80.50.142) 164 msec 0.so-5-0-0.IR1.SAC2.Alter.Net (210.80.49.150) 164 msec 5 POS2-0.IR2.SAC1.ALTER.NET (137.39.31.206) 156 msec 156 msec POS2-0.IR1.SAC1.ALTER.NET (137.39.31.190) 164 msec 6 0.so-0-0-0.TL1.SAC1.ALTER.NET (152.63.0.114) 184 msec 180 msec 0.so-4-1-0.TL2.SAC1.ALTER.NET (152.63.0.118) 156 msec 7 0.so-7-0-0.XL1.SAC1.ALTER.NET (152.63.53.249) 172 msec 0.so-7-0-0.XL2.SAC1.ALTER.NET (152.63.54.9) 168 msec 164 msec 8 POS6-0.BR5.SAC1.ALTER.NET (152.63.52.225) 168 msec POS7-0.BR5.SAC1.ALTER.NET (152.63.52.229) 156 msec 156 msec 9 atm3-0.core2.SanFrancisco1.Level3.net (166.90.50.133) 496 msec 496 msec 492 msec 10 so-4-1-0.mp2.SanFrancisco1.Level3.net (209.247.10.237) 492 msec 500 msec 492 msec 11 so-0-1-0.mp1.Philadelphia1.Level3.net (64.159.0.141) 572 msec 572 msec 564 msec 12 gig10-2.hsa1.Philadelphia1.level3.net (209.247.9.26) 560 msec 560 msec 564 msec 13 unknown.Level3.net (63.209.178.162) 560 msec 556 msec 556 msec 3 ge-6-1-0.mp2.Philadelphia1.level3.net (64.159.3.29) [AS 3356] 4 msec 4 msec 4 msec 4 unknown.Level3.net (209.247.8.66) [AS 3356] 8 msec 4 msec 8 msec 5 unknown.Level3.net (64.159.17.166) [AS 3356] 8 msec 4 msec 8 msec 6 102.ATM2-0.BR3.NYC8.ALTER.NET (209.244.160.162) [AS 3356] 8 msec 8 msec 8 msec 7 0.so-6-1-0.XL2.NYC8.ALTER.NET (152.63.19.50) [AS 3356] 4 msec 8 msec 8 msec 8 0.so-1-0-0.TL2.NYC8.ALTER.NET (152.63.0.169) [AS 3356] 8 msec 0.so-2-0-0.TL2.NYC8.ALTER.NET (152.63.0.185) [AS 3356] 8 msec 8 msec 9 0.so-2-0-0.TL2.SAC1.ALTER.NET (152.63.8.2) [AS 3356] 464 msec 460 msec 456 msec 10 0.POS6-0.IR2.SAC1.ALTER.NET (152.63.0.117) [AS 3356] 464 msec 0.POS6-0.IR2.SAC1.ALTER.NET (152.63.0.149) [AS 3356] 80 msec 0.POS6-0.IR2.SAC1.ALTER.NET (152.63.0.117) [AS 3356] 468 msec 11 so-7-1-0.IR2.SAC2.ALTER.NET (137.39.31.209) [AS 3356] 468 msec 472 msec 468 msec 12 so-3-0-0.TR2.SYD2.Alter.Net (210.80.48.145) [AS 3356] 628 msec 0.so-1-0-0.TR2.SYD2.Alter.Net (210.80.50.141) [AS 3356] 624 msec so-3-0-0.TR2.SYD2.Alter.Net (210.80.48.145) [AS 3356] 644 msec 13 so-6-2-0.XR1.SYD2.Alter.Net (210.80.48.146) [AS 3356] 628 msec 624 msec 624 msec 14 311.ATM5-0-0.GW1.SYD2.Alter.Net (210.80.3.90) [AS 3356] 620 msec 616 msec 608 msec David Temkin Susquehanna International Group, LLP IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

BGP Problem with Reachability 38.0.0.0
by Jan Czmok 05 Nov '02

05 Nov '02

Hi, can some clueful person help me ? I have some issues in reaching former PSI.NET Address space (38.0.0.0) from our networks (212.20.128.x) as an example. contacting Cogentco support only brings them answering "it's a latency issue and we're not responsible for it". I know that AS6461 <-> AS2914 <-> AS174 was the old path (kinda weird) but now it's AS6461 <-> AS16631 <-> AS174. More and more customers are bugging... Thanks for any hints in advance --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok(a)gatel.de

1 0

Re: Where is the edge of the Internet?
by alok 05 Nov '02

05 Nov '02

just curious.... do most SPs/IXs actually have the entire BGP routing table with them? so that every network in the world which is registered is availble to them in some form or another? -rgds Alok ----- Original Message ----- From: alok <alok.dube(a)apara.com> To: <nanog(a)nanog.org>; Martin <marty(a)supine.com> Sent: Tuesday, November 05, 2002 1:26 PM Subject: Re: Where is the edge of the Internet? Hi see inline :o), ----- Original Message ----- From: Martin <marty(a)supine.com> To: <nanog(a)nanog.org> Sent: Tuesday, November 05, 2002 12:59 PM Subject: Re: Where is the edge of the Internet? $author = "alok" ; > > makes sense on the edge/aggregation but if you do it further up in > the network.....there maybe some cases where we have assymetric routing, > where the path of uplink is never the path the same as the downlink hence the suggestion of "reachable-via any" rather then "route to source IP must be out the interface packet came in" in the scenario you paint. it's hard to block spoofed source addresses that actually exist in the routing table except at the "edges", hence the discussion about where the "edge" is... =====> ..he does cover it in the cisco docs...but then that means only the edges..which means deployment problems and blah blah .... i was answering the question as to why not on the "non customer facing side"...... if you pick the right places to implement filtering there is no need to do it to all routers. ====> they will charge you a whooping sum for that "picking places" bit ;o) ... i agree that the best place to actually address such scenarios is the "backbone"/"peering points"/"borders" where all traffic is seen..rather than go around tinkering at all edges..but i dont know how RPF would address the assymetry there.. but at the edges...depolyment costs is a problem..i think...dont ask me if i have a better idea :o) i would be writing a paper if i did..... > infact the source network of the packet may never be present in the routing > table....(it is possible, after all its a packet switched network and the > routing is destination IP based) ... ummmm, if the source address isn't in the routing table why would we bother carrying the packet a single hop further? =======> coz the destination network is there..... its still a viable config isnt it..incase of assymetric uplinks and downlinks? ......wht stops u from "not having a route to the source" as routing is destination IP based... some particular network may be covered with 0.0.0.0/0 for example and you may have no routing entry for it... or you could be having a customer who uplinks a particular network segment via your ISP, but doesnt advertise his network to you as he actually downlinks that network from somewhere else...nothing to stop that topology either.........right?

2 1

Re: Important Informational Message - root.zone change
by Daniel Karrenberg 05 Nov '02

05 Nov '02

At 12:59 AM 11/5/2002, Sean Donelan wrote: >Since its been 5 years since the hints/cache boot file has changed, >it may be useful to remind people an immediate change to your >local configuration files is not required. You don't need to >slashdot internic.net tomorrow morning trying to download the file. > >As long as 1 listed IP address responds with the current list of root >servers, the server doesn't even need to be a root server itself, your >name server should figure out who are the current roots. In the 1980's >and 1990's when the hints/cache file changed regularly, some people when >years without updating it. Or only updated it when they upgraded their >name server code. > >Don't Panic. Well said! I am quite disappointed that ICANN has not included similar language in their announcement. They know better. Daniel

1 0

Important Informational Message - root.zone change
by John Crain 04 Nov '02

04 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 *****PLEASE NOTE***** This is an important Informational Message to the internet community: November 5, 2002, the IP address for J.root-servers.net will change in the authoritative NS set for "dot". The change will be reflected in zone serial # 2002110501. The new set of servers authoritative for "dot" will be: A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 This WILL require a change to your root hints file. The new file will be available via anonymous ftp from rs.internic.net:/domain/named.root as well as ftp.internic.net:/doamin/named.root starting 11/5/02 1700UTC (12pm EST/9am PST). Both the new and old j.root-servers.net IP space will provide answers in parallel for the foreseeable future. _________________________________________ John Crain Manager of Technical Operations ICANN/IANA crain(a)icann.org 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _________________________________________ -----BEGIN PGP SIGNATURE----- Version: PGP Personal Security 7.0.3 iQA/AwUBPcb/pdGxp5XUiliSEQJzewCg2sa+RFanZQ9XZa+t0Yif0zKnzhkAoMSa FVW9Q1ekZl49+X1RGPKaHqNy =FZjZ -----END PGP SIGNATURE-----

2 2

IP Address Allocations
by Gawie Marais (Home) 04 Nov '02

04 Nov '02

Hi, Is there a site on the Internet that actually has a up-to-date list of all IP subnet allocations that will show me who actually owns the IP range ? Gawie J Marais Technical Member inX - Internet eXchange SA Tel: +27 11 956 6935 Fax: +27 11 956 6851 Mail: gawie(a)inx.co.za Web: http://www.inx.co.za/

2 1