Re: Fwd: What to improve? BCP-38/SAC-004 anyone?

[dave taht <[e-mail]>]

I note that I am now off all ietf mailing lists - I am trying to focus 
on make-wifi-fast, and while I'd like help on that from any org willing, 
it leaves me with no time to spare on anything else for at least the 
next year. Please do feel free to cc me on items of interest, please 
note my new email address.

I note also that I have also flipped all my email servers to encrypt via 
starttls *always*. Perhaps the ietf could consider that as a weak 
protest in the post-snowden, post CISA era.

After 10+ years of "may" -

It turned out that I had issues with email interchange with 3 out of 100 
of my regular correspondents, which I emailed via a separate channel to 
notify them of the problem, and I am now down to 1 out of hundred that I 
cannot swap mail with - which is a small price to pay compared the total 
silence of the spams, thus far, AND getting a reliable message back when 
something fails to transfer (unlike silent dropping of messages which 
happens far too often these days)

Anyway, moving on below.

On Mon, Jan 4, 2016 at 10:37 AM, Jari Arkko <[e-mail]> 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.
... BCP38 on openwrt ...

We implemented bcp38 with the powerful ipset mechanism built into linux. 
The package is now part of mainline openwrt, but it is not the default. 
Toke has had a writeup on how it worked that has long needed a venue to 
publish in (circleid? isoc? ). Technically, however, that package is an 
extension of bcp38 - not only does it prevent invalid real source 
addresses from being used from the router, it also stops rfc1918 
addresses from escaping.

Although the package contains a method to handle simple double-natted 
situations, (leveraging the dhcp supplied by upstream), we ran into 
enough places where it wouldn't work without manual intervention for it 
to not be the default for a customer supplied device. An ISP-supplied 
device could probably do it right.

An example of this is that cable modems - even when presenting a real IP 
- have a fixed configuration IP address of 192 dot 168 dot X dot Y. 
(100.1? can't remember)  which you can only get to if you allow that ip 
address through the router otherwise doing bcp38.

(ipset is often used as a means to block bad actors also - for example, 
I am using it right now to block a botnet that insists on registering a 
mailman account of [e-mail] every few seconds. There are 
thus far 20+ different ips so flooding my mailman server alone, there 
must be hundreds or thousands more under attack - totally saturating the 
target accounts at gmail. I have no idea why this thing exists, I could 
be exceptionally paranoid and suspect that this is also a known 
plaintext attack along the starttls channel between me and gmail.)

Dynamic and flexible responses to all sorts of attack vectors should get 
built into everything.

...

Secondly, a lot of my involvement in the ietf was intended to push along 
those actors using other hardware and OSes besides Linux. There are 
plenty of commercial products out there that hopefully have similar 
methods, but I see a remarkable lack of public documentation on how to 
do it right: http://www.bcp38.info/index.php/HOWTO:Juniper for example.

I miss the days when whois actually could get you a sysadmin responsible.

Thirdly, I pushed source specific routing for ipv6 as a default so as to 
avoid the bcp38 problem in the future there - but of course, with 
attackers having 2^64 addresses to choose from or more, it's uglier 
there to start with, and I go back again, to automated, shared, 
distributed defenses.

I would like to see far more 3 way handshakes in key protocols - like 
what rfc6013 promised for dns - in the future.

>
> 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.
Other forms of DDOS attack exist, even with perfect bcp38 coverage, I 
doubt that linode's
recent survival of a massive onslought over the holidays would have been 
made any easier.

http://status.linode.com/

>   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.

Specifically on the CPE front, I agree with jim's position, that the 
edges have got to get hardened, and regularly updated, and bcp38 is the 
least of the problems there compared to the common wholesale takeovers 
possible.

And even then, well, devices inside the firewall have rather major 
issues also:

http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

To me, bcp38 is something that ISPs should be doing to contain their 
problems inside
their own networks - from their interchange points, to containing the 
edge (bras/dslam/cmtses) to just their allocations. The ipset facility 
already mentioned scales to 10s of thousands of ips/subnets on
really cheap hardware.



> As an industry, this is the bigger challenge.
In the recent savewifi campaign, and the mandates laid out therein, we 
tried to raise the bar for the industry to build better - and 
maintainable, regularly updated stuff. Many of the good actors already 
come close to our suggestions.

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf

We didn't go into legal things - like revising liability law, or 
bringing insurers into the equation that would help enforce those 
mandates, in that piece, but I'm pretty sure at this point that only 
legal/financial threats - like what has hit vw for cheating emissions 
standards - will make for ongoing technical investments in user safety, 
security, and privacy from those companies "responsible".

In context with this, bcp38 compliance could be made a legal or 
insurer's requirement for an ISP to function.

> For more information on the dysfunctional embedded market, see my
> Berkman Center talk:
> https://cyber.law.harvard.edu/events/luncheon/2014/06/gettys
>
> Jim