- Test - lists.nanog.org

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

06 Nov '02

heard of default routes..?.... u dont always need an iBGP full mesh u cud redistribute a bit and "default route" a bit.... okie i know now...u give me a practice doc and say "bad boy" :o)... u can redistribute im sure there is nothing bad with that.......and also u will tend to summarize a lot with default routes too.... that was my point..... the other angle being "DDoS with spoofed ips".. right? those IPs care intertnet registerd ips? now no reason that if the router B runs OSPF that u may not have an entry for the source IP... it will be there either via redistribution or via iBGP if thats the way u want it.....or covered under default.... :o) what i mean by valid is this: "registered internet IP address" in this case you may have routes to the source network anyways iva iBGP or redistribution... inspite of a "DDoS" or "assymetric cases" ....or it may be a part of the "default route"..... also agreed this default route is more on the access end most guys tend to have links between BGP routers or run iBGP etc......then the same logic applies there too.... -rgds Alok ----- Original Message ----- From: Martin <marty(a)supine.com> To: alok <alok.dube(a)apara.com> Sent: Wednesday, November 06, 2002 12:36 PM Subject: Re: Where is the edge of the Internet? $author = "alok" ; > > here is the scenario > > u have a bgp A ---ospf-B - bgpC router setup > > what will u do on ospf -B ? > > coz transit traffic can flow thru it... how does router B know where to send packets transitting the network? you'd need to run iBGP on it or be redistributing routes from BGP into OSPF, otherwise router B is not going to pass packets appropriately. > but what i was trying to say to Valdis....was that u cant just "blindly" > drop packets in the core whose source doesnt have a route...for eg ospfB is > a problem in the above that's why you don't do it blindly. :) you pick a router that has it's eyes wide open (ie. has a full table) to do RPF filtering on. marty -- Can't buy what I want because it's free. Can't be what they want because I'm me. "Corduroy" - Pearl Jam

1 0

Re: who are the root server operators?
by Valdis.Kletnieks＠vt.edu 06 Nov '02

06 Nov '02

On Mon, 04 Nov 2002 12:32:06 EST, Joe Baptista said: > If the roots are once again under attack - how will the root server > operators be contacted by a frustrated isp who can't resolve. The chances of a frustrated isp being unable to resolve things during a DDoS attack and the root operators not already knowing about it are a lot lower than the chances that the root operators will be deluged with mail from frustrated ISPs who can't figure out why queries originating in RFC1918 space don't get answered. And remember - Paul Vixie has shown that 10% of the inbound traffic at c.root-server.net is bogus rfc1918 sourced. Making the addresses public will serve as a DDoS vector against the root operators.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech

3 2

Re: Attacker Data / Wall of Shame
by Daniel Senie 06 Nov '02

06 Nov '02

At 10:56 PM 11/5/2002, Christopher L. Morrow wrote: >On Tue, 5 Nov 2002, Daniel Senie wrote: > > > > > 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. > >This is neat, BUT what exactly is a DoS attack in this definition? Is >this: > >web proxy probes No. >web formmail submission attempts yes. >slapper/nimda/cr/crII probes Yes. >Just curious really. Our servers are not vulnerable to the actual attacks, but the volume of the probe traffic, whether formmail, slapper or nimda and friends, constitue a denial of service in that they tie up our servers for a period of time and keep us from serving customer websites to legitimate users. That we pay for bandwidth does not help matters. We have to rate limit incoming traffic to keep bandwidth within our targets and our customers' targets. The attack traffic overwhelms the legitimate traffic, though even if we didn't rate limit we'd still wind up with overwhelmed servers.

1 0

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

06 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