Re: Getting on with Things

[Eliot Lear <[e-mail]>]

Hi Adrian and thanks for your comment.

On 3/9/16 5:53 PM, Adrian Farrel wrote:
> Eliot,
>
> Picking one piece out of your MUD...
>
>> I've floated an idea in draft-lear-mud-framework-00.txt which talks a
>> little about this.  The idea is to learn what the Thing is and then have
>> its manufacturer communicate to a deployment how the thing is intended
>> to be used.
> This approach worries me. While the manufacturer might not object to this, the user and the system integrator should. The fact that a device was manufactured for foo should not stop it being used for bar. 
>

I imagine you'll not be surprised to know that you're not the first to
raise this concern.  And it plays in at least two directions: devices
are given too little or too much access.  Some time ago, Cullen pointed
me to the case of a television that he would like not to have access to
the Internet, lest its microphone send stuff upstream to the
manufacturer.  That is actually the harder problem because the
manufacturer will offer other services, perhaps some of them vital, that
the network will not be able to distinguish from the unwanted services,
perhaps through HTTP2/TLS.

But let's stick to your concern for the moment.  First, a great many
devices will have a limited number of uses.  In these cases, there is
little if any tussle, as Carsten put it.  Printers print.  They may
accept numerous protocols to accomplish this task (such as LPD, IPP,
etc).  Limiting inbound access to those protocols seems reasonable and
addresses the cases where-

  * someone accidentally left the SSH (or some other) code in;
  * the device is misbehaving (e.g., stepping out of that profile);
  * someone is attempting to talk to that device that has no business
    printing (this might be the null set as far as the example of
    printing is concerned, but you can envision many cases where that
    would not be true).

Moreover, in this case, because these rules are intended as guidance to
the router, it should be possible for the administrator to override or
modify them.  The administrator might want to apply different rules
based on the class of device.  The approach taken separates identity of
the type of device from the usage description itself, and the former may
be used without the latter if that is desired.

Eliot