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