On Mon, Jan 4, 2016 at 10:37 AM, Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
Patrik wrote:
why not start with the single home customers. What about look at default
configuration of CPEs and alike? What about...I just do not know. Something
just must be done.
Certainly CeroWrt (Dave Taht's version of OpenWrt where much of the
bufferbloat work was done) implements BCP38. And a home router has to know
what address ranges it is responsible for routing; it makes sense to
delegate the home part of the problem to the home router.
Dave may be able to comment as to whether BCP 38's requirements cause any
compute issues in a home router, given the processors/software on those
devices. It was implemented using the usual Linux packet filtering
mechanism.
The bigger headache is the previously unsolved problem: the very slow
uptake from upstream sources and brokenness of home router market. I
typically find a minimum of *four years* old firmware packages even on
*brand new *devices on the market, with little sign of security software
updates/fixes.
Here, ISP's that provide home routers could have leverage; but only if
ISP's are willing to make it a hard requirement on purchasing decisions
they make, rather than the currently observed behavior of buying from the
lowest vendor the junk they typically buy today. The technical side of the
ISP's need to educate the business people that they are encouraging a "race
to the bottom" with possibly catastrophic consequences; BCP 38 is the least
of the problem. I'll take ongoing prompt security updates for the life of
devices such as home routers over BCP 38 any day, and if the devices
continue insecure, BCP 38 is moot, as an attacker will just take over the
router first.
As an industry, this is the bigger challenge.
For more information on the dysfunctional embedded market, see my Berkman
Center talk:
https://cyber.law.harvard.edu/events/luncheon/2014/06/gettys
Jim