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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <jari.arkko@xxxxxxxxx> 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 X+somenumber@xxxxxxxxx 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]