Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -

[Michael Richardson <[e-mail]>]

Black, David <[e-mail]> wrote:
    > I have a few reactions to Tero's message, which may not be coherent or
    > consistent taken as a whole.  I've excerpted the text of interest.  

    >> If my IoT device crashes when someone makes some new remote attack to
    >> it, I will change configuration of my local "thing" called firewall
    >> and block all access to IoT device, except to those few addresses it
    >> will need to connect to.

    > Some of the people on this list are among the fraction of 1% of
    > Internet users who can configure a firewall.

But, MUD will let us automate it this configuration.

    > However, that's probably more of an argument for ISP/ISV/IHV firewall
    > management as a security service that may or may not be bundled with
    > other services than an argument for encrypted traffic access.

Agreed.  We don't need to see the traffic to authorize it.
If we had some better home-router/desktop/phone integration, end users could
get requests and might authorize things sensibly.  Or not, but at least, they
would realize what's going on.  Again, MUD.

    >> IoT devices usually only require connection to the one of two
    >> locations, i.e., their own cloud service, or to my local home are IoT
    >> gateway. In both cases protecting the IoT device is best done by
    >> limiting access to device using normal firewall rules. Installing
    >> firewall rules does not require seeing the traffic inside the
    >> encrypted flow.

    > That's not as simple as one might like.   I recently had to request
    > opening up the corporate firewall to allow a web conferencing service
    > (name of service omitted to protect the innocent ... and the guilty).
    > That request involved two TCP ports (in addition to 443) plus a large
    > UDP port range (for RTP) across seven IPv4 address blocks whose size
    > ranges from /26 to /21.   That's quite a bit more than "two locations,"
    > and this is something that an IoT web conferencing system could
    > require.

It would be interesting if applications could emit a cooked (JSON or maybe
XML format) file that users could forward to corporate IT that made the
request precise and exact.    Well,  really we could reuse MUD format for
that, along with the signature format, it's just that the statement would
come out of a browser rather than via https from MUD URL.

    >> >  Some people in this discussion have proposed narrowing the scope so
    >> >  that endpoints only trust a set of well-known, manually
    >> >  pre-configured set of such appliances, but still tackle challenges
    >> >  like end2end integrity.
    >> 
    >> I think set of well-known pre-configured set of device is good idea
    >> for most of the IoT devices. IoT devices usually do not want to talk
    >> to random devices in the internet, they will need to talk to the few
    >> things pre-configured to them. And for that filtering basic firewall
    >> is usually enough.
    >> 
    >> This does not work for laptops or similar, but works for most of the
    >> IoT devices.

    > That suggests separation of those two classes of use cases in
    > discussion and design applicability.  The above line of reasoning also
    > appears to assume that it's acceptable to prohibit P2P functionality
    > (i.e., "talk[ing] to random devices in the Internet") in IoT devices.
    > I'm not sure about that.

Given that we have no real technical definition of IoT (I've proposed some,
btw), it's hard to make categories.  95% of devices that currently are called
IoT are really in my definition, "Web Connected Devices", because they never
talk to anything other than the "cloud", and sometimes they want to open a
port-80 equivalent.

-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-