Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Eliot Lear <lear () cisco com>]

On 9/27/16 1:19 PM, Florian Weimer wrote:
> * Eliot Lear:
>
> > As some on this thread know, I've been working with the folks who make
> > light bulbs and switches.  They fit a certain class of device that is
> > not general purpose, but rather are specific in nature.  For those
> > devices it is possible for the manufacturers to inform the network what
> > the communication pattern of the device is designed to be.  This may be
> > extraordinarily broad or quite narrow, depending on the device. 
> > Conveniently, the technology for describing much of this dates back to
> > the paleolithic era in the form of access lists.  That is what
> > manufacturer usage descriptions are about.  (Yep- MUD.  There go my
> > marketing credentials). They're slightly abstracted for adaptation to
> > local deployments.   There's a draft and we authors are soliciting comments.
> What's the end goal here?  Charge extra if I'm connecting a TV instead
> of a light bulb?

Not my end goal.  My end goal is that consumers have a means to limit
risk in their home environments, and service providers have a means to
deliver that to them.

> I'm not convinced that expected traffic profiles are the right answer.
> We already have that in the server hosting market, and it does
> constraint the types of services you can run on hosted servers (for
> the hosting providers who does this).  I'm wary of the network putting
> severe constraints on application architecture, way beyond what is
> dictated by current technology.  NAT more or less killed servers on
> consumer networks, and this kind of traffic profiling has begun to
> kill clients on server networks.

The whole point of MUD is to leave control in the hands of those who
have developed and have to support Things.  It is not simply for the SP
to decide what traffic is ok, or to charge more for it, but to respect
the wishes of the developers.  That may be sufficient to stop a lot of
bad things from happening to a lot of Things.

> > The service providers has a strong role to play here, since they drive
> > standards for connectivity.  Having some access to residential CPE in
> > particular for this purpose, I believe, is very helpful because by doing
> > so not only can SPs protect others, but can also provide lateral
> > protection within the home.  As I wrote upthread, if consumers come to
> > see smart lightbulbs not just as useful, but also as a concern, they may
> > wish their SPs to help them.  That's the internalizing of an externality
> > that I see possible, and maybe even probable over time.
> Most service providers appear to be struggling to maintain up-to-date
> software on their CPEs (and their infrastructure), and following
> recommended configuration practices as they evolve.  This does not
> give me confidence that they could perform device management at
> consumer scale.

It's NOT device management.  Is network management.
> Do we know how much the average consumer trusts their ISP?  Would they
> want their ISP to control the digital (and increasingly, physical)
> doors in their home?  My own outlook is rather biased, unfortunately.
And again, this is the wrong way to look at it.  The consumer should
always get final say.  They're the customer.  This is a chance for the
manufacturer of the device they're using to explain how the device is
supposed to behave on the network.  Example: how many times have you
heard of some device leaving an extra service like SSH lying around? 
And would you really want that thermostat talking to ALL of the Internet
or just locally + its cloud service?  The manufacturer probably has a
view about that, and I bet it aligns with the consumer and with the
enterprise...

Eliot

Attachment: signature.asc
Description: OpenPGP digital signature