North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: down sev0?

  • From: Daniel Senie
  • Date: Thu Oct 26 14:32:19 2006

At 07:25 AM 10/26/2006, Jared Mauch wrote:

On Thu, Oct 26, 2006 at 06:03:54AM +0000, Fergie wrote:
> Randy,
> I don't think I implied anything of the sort.
> I did, however, pipe up when a BCP is mentioned that I endorse,
> and co-authored -- and likewise, cannot figure out for life of
> me, why there is such push-back from the Ops community on doing
> The Right Thing.

        The challenge is that the router vendors still haven't
done "The Right Thing".

        I have one device that

1) halves its forwarding table space by enabling u-rpf
2) can only do either strict or loose mode rpf *GLOBALLY* so I can
   not strict rpf-check a static customer AND loose rpf someone
   larger for unrouted space.
It was possible to implement BCP38 before the router vendors came up with uRPF.

        because of the above (#1 isn't that bad, but #2 is)
I can't enable u-rpf on the device as a policy.  Changing one
interface from loose -> strict silently changes all other u-rpf
interfaces and then customers gripe about dropped packets.

        obviously moving these checks closer to the edge
is ideal, such as always doing rpf on the ethernet lan
interface for your customer CPE.
Yes, it is. And does not require uRPF.

I know you're looking to do the right thing. It's important though that this not be put entirely on the router vendors. How many "managed T1" services out there have routers controlled by the ISP providing them? How many of those routers are configured with a single line ACL that would implement BCP38 sufficiently?

How many aggregation routers for incoming T1s are not configured with a single line ACL per T-1 to ensure the packets coming in are from assigned, not-multihomed space?

If scripts are being used to auto-configure routers to ship out to T-1 customers, then appropriate ACLs should be written by such scripts at the same time. Scripts that configure aggregation switches should similarly be reviewed for ACL inclusion.

It's certainly helpful to have implementations such as uRPF to help make it easier to deploy BCP38, but deployment of BCP38 is not dependent on the existence of uRPF.

> Having said that, botnets don't need to spoof addresses -- the
> sheer dispersion of geographic and AS infection base renders the
> whole point of spoofing almost moot.

        yup, it's an evolving threat, even if some solution to the
botnet problem is discovered, it will take years to fix.  Think of
the smurf amplifiers that are still out there[1].
(the other co-author of the BCP in question)