register.com down sev0?

Thu Oct 26 18:26:27 UTC 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].

Dan
(the other co-author of the BCP in question) 