- Test - lists.nanog.org

RE: Internet Backbone Index
by Rodney Joffe 13 Jul '97

13 Jul '97

Heh..... To throw more oil on this fire, here's what one of our customers is using to beat us over the head with! http://www.internetweather.com Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net

1 0

Re: NSPs and filters
by Vadim Antonov 13 Jul '97

13 Jul '97

Daniel Senie <dts(a)proteon.com> wrote: >Would you care to explain just exactly WHY a CAM type architecture could >not filter packets WHILE BEING RECEIVED from a given type of wire? This >is NOT an unsolveable problem. Perhaps you've been blinded by the >current architecture of the equipment you've invested in to date. I didn't say this problem is not "solveable". I said that the solution is known, but to my knowledge nobody implemented or plans to implement it in hardware (and for several good reasons, too). --vadim

1 0

Re: NSPs and filters
by Vadim Antonov 13 Jul '97

13 Jul '97

randy> So, at POP X, I take in maybe 100 prefixes, with maybe 1000 randy> at some POPs. How do I build and maintain that filter list, alan(a)mindvision.com (Alan Hannan) wrote: > The same way you build and maintain routing filter lists for the > prefixes you take in. Bzzt. Routing filter lists are applied to routing updates. Packet filter lists are applied to packets. Big difference. 1000-entry packet filter will slow any existing router down to crawl, and practically all future boxes won't do any better. --vadim

3 2

Re: NSPs and filters
by ice9 13 Jul '97

13 Jul '97

On Fri, 11 Jul 1997, Jon Lewis wrote: > Why is it that the NSPs I've encountered refuse to do any sort of sanity > filtering on their customer connections? i.e. If UUNet knows that FDT has > only 205.229.48/20 and 208.215.0/20, why should they let me send traffic > through their network with random source addresses? > > FDT has been the target of forged source address UDP attacks for the past > 2 days. It's all being stopped at our router that takes our UUNet T1, but > the extra T1 traffic is causing UUNet's usually unreliable network to be > even less reliable, and we've lost connectivity to UUNet several times > this evening. Its not feasible to filter packets on customer gateway routers. When you impose a packet filter on a GW router customer interface, all packets destined to that customer have to be matched to an access-list and then forwarded down the pipe or dropped. This increases the load on the router CPU, because it is used to switching the packets. Now you have to analyze each packet which takes up CPU time. This is not a nice thing to do to a router, especially while the router is trying to keep up with 50 other customers... And if more than 1 customer wants this type of service, you start really feeling the load. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ice9(a)paranoia.com http://www.paranoia.com/~ice9 My opinion may not reflect that of any living person, but its the only one that counts!! main() {for(;;fork());} =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

7 8

More on ingress filtering
by Daniel Senie 13 Jul '97

13 Jul '97

I'd encourage folks to read the draft that Paul Fergusen and I have written on this subject. We talk about some things that COULD be implemented that would greatly help with source address problems. One of these would be a change to your remote access servers, and would be quite straightforward for vendors to implement: For DIALUP users, provide an option (would need to be per user) to require the packets arriving from that dialup user have the IP address that was assigned by the RAS server when the user dialed up. At modem or ISDN speeds, the packet rate is QUITE low, and this filtering should NOT be a CPU overhead problem. A SINGLE compare of a 32 bit integer is ALL we're talking about here. The reason to make this configurable per-user is to allow dialups by remote routers that are routing separate nets or subnets behind them. In those cases, a more complex filter would be desirable, but perhaps somewhat less necessary. It is my suspicion that a vast majority of the intentional source IP address trouble comes from dialup users who can leap from provider to provider. Filtering should be done as close to the actual customers as possible. I do understand the difficulty with the present core routing equipment when trying to filter large amounts of traffic, but that doesn't apply to routers at the periphery of the net. As someone else suggested, even if some of the core networks can't do all of their own filtering, they COULD add that as a requirement for those networks that are fed from them, and they from their downstreams, etc. until the T1 line, or 56K leased line, or dialup modem line at the periphery IS FILTERED. Daniel Senie OpenROUTE Networks, Inc. -- ------------------------------------------------------- Daniel Senie dts(a)openroute.com OpenROUTE Networks, Inc. http://www.openroute.com/ 508-898-2800

1 0

Re: NSPs and filters
by Vadim Antonov 13 Jul '97

13 Jul '97

randy(a)psg.com (Randy Bush) wrote: >So, at POP X, I take in maybe 100 prefixes, with maybe 1000 at some POPs. >How do I build and maintain that filter list, and how long does it take each >packet to get through it with a router that also does real routing? That can be done, and is relatively easy. Not in cisco's or any other hardware-assisted box, though (figuring out why is left as an excercise to the reader :) My estimate is that the total filtering overhead is at about 2.5% for a "software" router. And, yes, i do plan to implement that kind of filtering. --vadim PS. Hint: i described the technique for doing that in a mailing list, year ago.

1 0

Re: NSPs and filters (fwd)
by Michael 13 Jul '97

13 Jul '97

>> This is not a nice thing to do to a router, especially while the router is >> trying to keep up with 50 other customers... And if more than 1 customer >> wants this type of service, you start really feeling the load. > >I'm not saying UUNet should install whatever filters I want on their >routers. I'm just saying the net would be a MUCH nicer place if NSP's all >did ingress filtering on their customer connections. If current routers >can't handle the load this would create, then NSP's need to find vendors >willing to deliver the necessary power, or they need to rethink the way >they design their networks. Then couldn't the net also be a nicer place if the 'customer' filtered their outbound packets? Of course this involves trusting the engineer's of the downstream network to actually DO the filtering. Why have an NSP drop several customers off of the net because of one pre-pubescent ping flooder, when the offending customer himself can be dropped (unless his network is administered by pre-pubescent ping flooders) and not affect anyone else? Michael

2 1

NSPs and filters
by Jon Lewis 13 Jul '97

13 Jul '97

Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses? FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening. 5 minute input rate 1326000 bits/sec, 318 packets/sec 5 minute output rate 469000 bits/sec, 286 packets/sec PUNet suppost says there's nothing they can do, and that I should talk to their security people about buying a firewall for FDT on monday...like a firewall on our side of the T1 is going to do us a lot of good.... ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis(a)inorganic5.fdt.net for PGP public key_______

5 6

Re: NSPs and filters
by alan＠mindvision.com 13 Jul '97

13 Jul '97

jl> I'm not saying UUNet should install whatever filters I want on their jl> routers. I'm just saying the net would be a MUCH nicer place if NSP's all jl> did ingress filtering on their customer connections. If current routers jl> can't handle the load this would create, then NSP's need to find vendors jl> willing to deliver the necessary power, or they need to rethink the way jl> they design their networks. randy> Most of my customers have customers who in turn have randy> customers, not a few of whom are multi-homed. Same for randy> UUNET, ... randy> So, at POP X, I take in maybe 100 prefixes, with maybe 1000 randy> at some POPs. How do I build and maintain that filter list, The same way you build and maintain routing filter lists for the prefixes you take in. You do use routing filter lists, don't you? It should be the same list of networks. randy> and how long does it take each packet to get through it with randy> a router that also does real routing? Therein lies the argument. Do the huddled masses want things that move packets or things that make judgements on them? Difficult to have both. I don't think the world is yet able to technically support security within the infrastructure that provides transit. It needs to be at a separate layer, or on the fringe. The economies of today's customer aggregation routers do not allow a person to invest in that functionality inherent in the router. (yes, they could, but that cuts into the company's bottom line, and as there really isn't that big of an outcry or decrement in QOS of the company's IP product, why would they?) Accordingly, one must rely upon reactionary security folk to track down the attacks of bogus packets. Significant investment should be made and supported in building automated response systems and scripts. Should the USPS forbid mail with bad return addresses? -alan

1 0

Router peer access-list creating scripts
by Wookie 12 Jul '97

12 Jul '97

Hi, Does anyone know of any scripts which will help us keep the filters on our peering routers (Ciscos) up to date, so we only allow them to announce those routes to us that they have registered with one of the routing registries? Keeping these filter up to date manually is a pain, particularly where a peer announces several customer AS numbers to us. We'd rather filter than just leave ourselves open to our peers annoucing any old garbage to us. What does everyone else do? Wookie

2 1