North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BCP38 making it work, solving problems

  • From: Daniel Senie
  • Date: Mon Oct 11 22:53:10 2004 
At 07:51 PM 10/11/2004, Richard A Steenbergen wrote:


On Mon, Oct 11, 2004 at 06:03:08PM -0400, Daniel Senie wrote:
>
> I've removed the rest of your message, talking about which vendors do or
> don't have what capabilities. While I agree it'd be nice if more vendors
> offered automated tools for implementing ingress filtering, such tools are
> unnecessary in most corporate network cases, thus the lack of corporate
> customers asking for the feature. In reality every device offering access
> control lists capable of filtering on source IP address can and does have
> sufficient capability to implement BCP38.
>
> While I appreciate the desire to have a single switch solution, like was
> possible with BCP34, it's a bit more complex to do in this case. It is,
> however, disingenuous to say that devices don't support BCP38 because they
> don't have an automated widget to implement it. Keep in mind that uRPF is
> an implementation of BCP38 capability, and other implementations are
> entirely possible.
>
> This was probably obvious to you, but others reading might find the
> clarification useful.

Yes if a box has source address packet filtering capabilities you can
filter packets by source address ("Duh"). This doesn't mean that it is
going to be sane or easy to implement the filtering by manually
maintaining an acl of every prefix/host on every interface where you could
have a customer or corporate box injecting spoofed packets into the
network. I believe there are plenty of corporate networks out there that
are far too complex to maintain with manual ACLs, I believe the reason
that no one cares is simply because... no one cares. :)
One of your arguments presented was that corporate customers weren't asking for unicast RPF, and I responded that corporate customers are not in need of automated mechanisms to implement BCP38, since in most cases their networks are EDGE networks, and it's quite simple to filter your egress points to ensure you don't send out any spoofed packets.

You laid out a complaint against the equipment makers claiming they weren't implementing automated mechanisms BECAUSE the corporate customers were not asking for such tools, and I simply pointed out they shouldn't be expected to do so. If network operators need features, they need to ask for them when talking with potential vendors.

Network operators need to ensure downstreams don't advertise AS's they're not supposed to. Last I looked, that required some custom work (whether done by scripting or whatever, it's done off the router and pushed in). At the same time you're building those lists, you could be building ACLs. Some border routers will do this just fine, others won't. Next time you're qualifying routers for possible use, maybe the ability to handle wire speed acls might be worth testing?


If you expect people to be able to maintain these filters on any scale,
they need tools.
Why do those tools need to be built into the router? Are your tools for maintaining AS path filteirng built into the routers? Are the tools to archive and compare router configurations most of you use built into the routers?

 Certainly uRPF is a good tool to do this, and certainly
someone could implement some others that are different, but the complete
lack of any tool, especially on the boxes where you should be doing this
filtering, counts as a failure in my book.
I disagree that the tools must be an integral part of the router software. Perhaps it's time to think outside the (router) box?