Re: Getting on with Things

Eliot Lear <lear@xxxxxxxxx> · Wed, 9 Mar 2016 19:14:04 +0100

    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

Attachment:
signature.asc

Description: OpenPGP digital signature