Re: BCP38 Deployment

[Michael Thomas <mike () mtcc com>]

On 03/28/2012 12:03 PM, Leo Bicknell wrote:
> None of the routers are "trusted" if your perspective is right.
>
> It's easy to find a path like:
>
> "Tier 1 ISP" - Regional ISP - Local Provider - Subscriber - User
>
> Techologically it may look like:
>
> Tier 1       T640 core network with 10GE handoff
> Regional     Cisco GSR network with 1GE handoff
> Local        1006 to Arris CMTS
> Subscriber   Motorola Cable Modem to NetGear SOHO Gateway
> User         Patron with Airport Express sharing a wired connection to WiFi
>
> I don't trust any of the people in that list.  More interesting
> from a BCP38 perspective who should be doing the filtering?  If you
> were going to write it into law/regulation, where would you require
> it?

I wasn't talking about laws/regulation, just responding to your comment
that lack of RPF in CPE was the bigger problem which doesn't seem right
to me. If I'm the owner of the CMTS network, I really shouldn't be trusting
the CM to be doing filtering for me. Maybe it would be nice to have RPF
checks in the CM to nip a spoofed DDOS before it ever gets on the HFC
network, but I wouldn't count on the CM not being compromised too, which
means I should probably be running RPF on the aggregation router as well.

> Maybe all of them should, but can they from a technologial perspective?
> There's multi-homing in that chain somewhere.  Do you require it
> at the first single homed place?  If the subscriber is using a
> NetGear that does both ethernet and cell card backup and is thus
> multi-homed does that mean the user must do it?  It's not even in
> my list, but re-asking my previous question why don't we go a step
> further and require the Operating System to do unicast RPF on-box?

It's been a long time since I've read bcp 38, but I thought its
intent was if you can reasonably do it, you *should* do it. multipath
obviously makes RPF problematic, but the vast majority of the
edge networks aren't multi-homed, so they really should be running
RPF just as a matter of... best common practice.

> I think given the thorny set of issues that taking a step back and
> saying, "rather than a perfect solution, what gets us most of the
> way there the cheapest, and quick" is a good question to ask.  I'm
> going to point to the local boxes.  In my example the Netgear and
> Airport devices are in a posion to do super-cheap unicast RPF.  They
> have (generally) one network behind them, and one way out.  They
> are CPU based boxes for which this check requires no hardware
> changes.  They don't even have enough interfaces in most cases to
> multi-home, so the chance of it breaking is nil.  And yes, while
> the user may control both the end PC and these devices and thus be
> able to turn it off and circumvent all of this, that's really not
> the problem.  The problem is infected machines spewing crap their
> owners don't know about, and just having a separate device upstream
> that stops it will do the job.
>
> The perfect is the enemy of the good in this case.  Solving this at the
> consumer CPE level would remove 90-95% of the problem at zero hardware
> cost, a very small software cost, and a very small support cost and
> probably make us stop talking about this issue all together.

Except for the small problem that getting cheap home router box
manufacturers to do just about anything is a pushing on string exercise.
So if I want to a) protect my network and b) be a good netizen, I'm
still going to want to do BCP 38 regardless of whether others violate
a, b or both. Right?

Mike