BCP38 Deployment

Wed Mar 28 19:03:17 UTC 2012

In a message written on Wed, Mar 28, 2012 at 09:52:49AM -0700, Michael Thomas wrote:
> Yeahbut, the CPE isn't trusted. It would be _nice_ for customers
> to be bcp38 clueful as well, but I don't think it's _required_ for
> successful deployment from the ISP's standpoint. Even with a
> system like DOCSIS where the CPE is semi-trustworthy from a
> provisioning/etc standpoint, I don't think I'd _count_ on them.

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?

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?

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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120328/342202d1/attachment.sig>