[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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
