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