Subject: Re: [OPSAWG] mud documents

From: Eliot Lear <[email-masked]>
Date: Wed, 18 May 2016 10:16:30 +0200

[It looks like we're moving some of this discussion to OPSAWG, so CCing
opsawg].

Getting back to some old threads.

On 4/8/16 10:05 PM, Michael Richardson wrote:
> Eliot and I have been conversing about policies.  I proposed that I want a
> policy like:
>
> He asked me three questions:
>
> 0 what happens when the policy enforcement point (PEP) that actually
>   operationalizes the policy does not understand the policy in its
>   entirety? Does it implement what it can, or does it discard?
>
> 1 Where does connections per unit of time fit in the above?
> 2 Where does logging/notification fit into the above?
>
> I proposed that we wanted policies like this:
>
>> ---<
> I am a printer.
> I accept connections on the IPP port.
> Please be suspicious when the connections are non-local.
>
> Eliot asked:
>     > There is no concept today of <be-suspicious>.  Let me ask what network
>     > behavior you would associate with that?
>
> I answered:
> mcr> Consider blocking them if they occur too frequently, or the
> mcr> connections have a small number of RTTs.
>
> I also think that the "be-suspicious" part might be significantly modified by
> local policy.  It could be that this results in no connections, it could be
> that it must be approved by an admin, that it's subject to some kind of
> site-wide ACL (such connections from the VPN, intranet and partners okay, not
> the wild internet...)
>
> We discussed whether we could clearly articulate other policies like
> connections/minute or connections/day that would be not-suspicious.
>
> I also suggested that this could extend beyond "THINGS" to *APPS* as well:
>
>    consider that the MUD could well be packaged with PC/Android/iPhone
>    *apps* as part of their security profile.
>    SELinux pretends to do this, but in practice configuring it is still close
>    to impossible.  The MUD specification would help a lot I think.
>

I think the following criteria are built into the MUD design that makes
these sorts of changes hard:

  * The identity of the Thing is tied to either DHCP, LLDP, or 802.1AR
    attributes, which are all around the Thing itself and not an app. 
    This having been said, if there is a way for an app to inform the
    network that it too has a MUD file, then the network can use that
    information.  The principle here is that the URL is distinct from
    its transmission means.  Also, our initial focus has been on
    admitting the device onto the network itself.  And so I think what
    we have here is future work, and I invite Michael to write a draft ;-)
  * As currently defined we're using the least common denominator for
    ACL capabilities.  That way the most network elements can implement
    MUD.  Question: is a time-based ACL common on a home router?  2nd
    question: what would happen to the policy if a part of it is not
    implementable?  It might be possible to put some #ifdef-like
    capability in there, but that leads to the final design criterion..
  * Keep it simple for the manufacturers, at least for the first
    version.  If they need to scratch their heads too much they'll just
    give up.

Eliot