Subject: [OPSAWG] binding ACLs to mud devices || [was Re: FYI on draft-ietf-opsawg-mud]

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 22 Jun 2017 16:39:30 +0000

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
> 
>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Fri, 30 Jun 2017 14:39:21 +0000

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-masked]<mailto:[email-masked]>> wrote:

Cheers,

Einar

Hi everyone,

Eliot