Thanks, Einar. I think this is probably a good change, on the whole. What I like about it is that we can extend later to include things that have nothing to do with access lists, such as QoS. I had initially had QoS as a goal, but it's just a bit too much to bite off this time.
Note: there are several other changes that need to happen in order to be
consistent with the new acl model:
* Because now everything is a feature in the ACL matches statement and
we are not using NETCONF, we will need to be explicit as to what
"features" are expected in MUD. I'll put up a strawman in the next
draft, but I would expect we'll want to fiddle with it a bit.
* As Einar notes below, I think we need to discuss direction-initiated
a bit in the WG. This can be implemented in several ways in TCP,
but not necessarily easily in some implementations for UDP. Thus we
need to be careful as to where to place that in the model, and how
it compares against flags.
* Similarly, we will need to make some changes to the dns model. I
will do a placeholder for now and we can discuss in Prague.
Comments?
Eliot
On 6/30/17 4:39 PM, Einar Nilsen-Nygaard (einarnn) wrote:
> All,
>
> As I mentioned last week, I had a couple of concerns about how we
> expressed from-device-to-device ACL policy. As a result, I sent Eliot
> a couple of updates to the 07 draft. I’ll summarise them here, but the
> full text of the updated version can be see at:
>
>
> https://github.com/einarnn/mud/blob/master/drafts/draft-ietf-opsawg-mud-08.txt
>
>
> The main change is to the model. I have taken “direction” out of the
> ACL, and instead introduced a new container. The new content is in
> bold below, and you will see that some of the previous augmentation
> content has been removed:
>
> module: ietf-mud
> +--rw metainfo
> | +--rw last-update? yang:date-and-time
> | +--rw cache-validity? uint8
> | +--rw masa-server? inet:uri
> | +--rw is-supported? boolean
> | +--rw systeminfo? inet:uri
> | +--rw extensions* string
> * +--rw device
> +--rw from-device-policy
> | +--rw access-lists
> | +--rw access-list* [acl-name acl-type]
> | +--rw acl-name -> /acl:access-lists/acl/acl-name
> | +--rw acl-type identityref
> +--rw to-device-policy
> +--rw access-lists
> +--rw access-list* [acl-name acl-type]
> +--rw acl-name -> /acl:access-lists/acl/acl-name
> +--rw acl-type identityref*
> augment "/acl:access-lists/acl:acl" +
> "/acl:access-list-entries/acl:ace/acl:matches":
> +--rw manufacturer? inet:host
> +--rw same-manufacturer? empty
> +--rw model? string
> +--rw local-networks? empty
> +--rw controller? inet:uri
> +--rw my-controller? empty
> +--rw direction-initiated? direction
>
> Note that as a follow-on I have a couple off concerns about the
> “direction-initiated” match augmentation and also about the general
> position of the ACE augmentations. I haven’t had time to fully
> articulate my concerns with direction-initiated, but the augmentation
> position is simpler; it just needs to be fully aligned with the draft
> IETF ACL model.
>
> The model change also necessitated some text changes. Specifically in
> the description of the model content, which now reads:
>
> This module is structured into three parts:
>
> o The first container, metainfo, holds information that is relevant
> to retrieval and validity of the MUD file itself.
>
> o The second container, device, describes the policies to be applied
> to traffic to and from the device. The only policy currently
> defined is a list of access control lists, but the from-device-
> policy and to-device-policy containers serve as extension points
> for subsequent augmentation.
>
> o The final container augments the matching container of the ACL
> model to add several elements that are relevant to the MUD URL, or
> other otherwise abstracted for use within a local environment.
>
> You may also notice that I explicitly allude to extensibility for
> policies beyond access control. This is another benefit I see from the
> restructuring I have proposed, so I thought it worth mentioning here.
>
> Related to extensibility, I also suggested the addition of this text
> to section 1.5:
>
> While the policy examples given here focus on access control, this is
> not intended to be the sole focus, and by structuring the model
> described in this document with clear extension points, and by
> leveraging YANG-based models, we provide the opportunity for new
> policies to be introduced as required.
>
> Cheers,
>
> Einar
>
>
>> On 22 Jun 2017, at 17:39, Einar Nilsen-Nygaard (einarnn)
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>> I just had a chat with Eliot after reviewing the latest draft he is
>> working on, and I expressed a couple of concerns about how the
>> from-device/to-device semantics for traffic have been baked into the
>> ACL definition. I think this approach is intrusive and somewhat
>> non-obvious (depending who you are;-), so I'd like to propose a
>> change to this to take the binding of an ACL to a "MUD device" out of
>> the ACL and instead have a standalone container construct to express
>> this binding. I think that this could also set the basic direction
>> for future extensibility targeted at going beyond just access policy.
>>
>> I will propose something early-to-mid next week and will work with
>> Eliot to ensure the cut-off isn't missed.
>>
>> Cheers,
>>
>> Einar
>>
>>
>>> Hi everyone,
>>>
>>> I wanted to give a brief update on this draft. Right now we've resolved
>>> a lot of comments in our previous version. I am awaiting an update on
>>> draft-ietf-netmod-acl-model, which is undergoing revisions, as discussed
>>> in the last opsawg meeting. Once that has taken place I will rev the
>>> draft again. At the same time, we have gotten some amount of experience
>>> in terms of generating config that we can share in the draft, much of
>>> which is common sense. And so, for instance, we would want to probably
>>> at least suggest or perhaps require that MUD files that are generated
>>> use "permit" parts of the ACLs to keep things simple at the beginning.
>>> Also, making use of IP addresses themselves in the ACL would be
>>> considered unfriendly, unless it's a multicast address. This is because
>>> the whole scaling function of MUD is to abstract those addresses out.
>>>
>>> Beyond that, look for more before the last call cutoff.
>>>
>>> Eliot
>>>
>>>
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
