Subject: [OPSAWG] MUD : ietf-acldns YANG model question.

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 25 Oct 2017 09:39:05 -0400

Is it possible to modify the YANG model for ietf-acldns to explicitly
disallow "drop" ACE rules?
(i.e. only "forwarding":"accept" } not knowledgeable enough about YANG to
suggest the change).

It would also be convenient if there were a way to disallow both
controllers AND hostnames in a single ACL entry (for reasons of clarity)
but again I don't know how to state that in YANG.

Thanks,

-- 
M. Ranganathan

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 25 Oct 2017 14:23:09 +0000

Technically, you could express both of these constraints.

But why would we want to do this? One developer’s clarity may be another’s verbosity, and what if someone actually does want to drop certain DNS requests?

Cheers,

Einar

> On 25 Oct 2017, at 14:39, M. Ranganathan <[email-masked]> wrote:
> 
> Is it possible to modify the YANG model for ietf-acldns to explicitly disallow "drop" ACE rules?
> (i.e. only "forwarding":"accept" } not knowledgeable enough about YANG to suggest the change).
> 
> It would also be convenient if there were a way to disallow both controllers AND hostnames in a single ACL entry (for reasons of clarity) but again I don't know how to state that in YANG.
> 
> Thanks,
> 
> 
> 
> -- 
> M. Ranganathan
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Oct 2017 16:30:16 +0200

RFC 7858 defines DNS over TLS and this uses port 853 over TCP. ;-)
It is generally risky to hard code things based on the assumption
that something never changes or is always needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 25 Oct 2017 10:44:21 -0400

Hi Juergen, Einar,

> that something never changes or is always needed.

I just want to disallow the following:

        "rule-name": "myctl0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "my-controller": [
                    null
                  ]
                },
                "ipv4-acl": {
                    "ietf-acldns:src-dnsname": "www.nist.gov",
                   "protocol": 6,
                  "source-port-range": {
                    "lower-port": 443,
                    "upper-port": 443
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              },
              "actions": {
                "forwarding": "accept"
              }

It is possible to express this as two separate ACL entries. I believe the
current YANG model would accept this.

> > But why would we want to do this? One developer’s clarity may be
> another’s verbosity, and what if someone actually does want to drop certain
> DNS requests?
>

The working model in MUD is to implicitly DENY any communication that is
not expressly allowed. It seems redundant to start with this working
assumption and then allow DENY rules anyway.

Thanks,

Ranga.

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Oct 2017 17:01:50 +0200

I did add some text into the last draft explictly warning against this
sort of construct.

Eliot

On 10/25/17 4:44 PM, M. Ranganathan wrote:
> Hi Juergen, Einar,
>
> On Wed, Oct 25, 2017 at 10:30 AM, Juergen Schoenwaelder
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>                     "ietf-acldns:src-dnsname": "www.nist.gov
> <http://www.nist.gov>",
>                    "protocol": 6,
>                   "source-port-range": {
>                     "lower-port": 443,
>                     "upper-port": 443
>                   }
>                 },
>                 "tcp-acl": {
> It is possible to express this as two separate ACL entries. I believe
> the current YANG model would accept this.
>
>  
>
>     another’s verbosity, and what if someone actually does want to
>     drop certain DNS requests?
>
>
> The working model in MUD is to implicitly DENY any communication that
> is not expressly allowed. It seems redundant to start with this
> working assumption and then allow DENY rules anyway.
>
>
> Thanks,
>
> Ranga.
>
>  
>
>     >
>     > Cheers,
>     >
>     > Einar
>     >
>
>
>     --
>     Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587>       
>      Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103 <tel:%2B49%20421%20200%203103>       
>      <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
>
>
>
>
> -- 
> M. Ranganathan
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Oct 2017 17:57:00 +0200

May I ask what this warning is and where I find it? And yes, I am still
reading and learning so be patient with me.

/js

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Oct 2017 18:45:32 +0200

Sure.  Section 2.1:

>    A valid MUD file will contain two root objects, a "mud" container and
>    an "access-lists" container.  Extensions may add additional root
>    objects as required.  As a reminder, when parsing access-lists,
>    elements within a "match" block are logically ANDed.  In general, a
>    single abstraction in a match statement should be used.  For
>    instance, it makes little sense to match both "my-controller" and
>    "controller" with an argument, since they are highly unlikely to be
>    the same value.

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 25 Oct 2017 13:11:45 -0400

> >    "controller" with an argument, since they are highly unlikely to be
Since these are sets, I think a better statement could be:

"an intersection is computed between elements within a match block" (rather
than ANDed).

If possible it would be nice to impose a restriction on single abstraction
in a match statement (I see no benefit in allowing more than one element).
However, I do not know if it is possible to enforce such a restriction via
YANG.

Ranga

-- 
M. Ranganathan

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 25 Oct 2017 18:41:17 +0000

Ranga,

Looking at this:

  augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches:
    +--rw mud-acl
       +--rw manufacturer?        inet:host
       +--rw same-manufacturer?   empty
       +--rw model?               inet:uri
       +--rw local-networks?      empty
       +--rw controller?          inet:uri
       +--rw my-controller?       empty

It would be possible to, for example:

  *   Make the mud-acl container just contain a choice of all 6 elements. At that point, you would only be specifying one of them.
  *   If not all the elements are mutually exclusive, you could have specific constraints that say “when controller is present, my-controller cannot be present” and vice-versa. This would make specifying both elements illegal per the constraints.

Each approve would inform the client and server what is “valid”. The first approach would effectively force multiple “access control entries”, meaning one for each condition you wanted to test.

Cheers,

Einar

On 25 Oct 2017, at 18:11, M. Ranganathan <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Oct 25, 2017 at 12:45 PM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

"an intersection is computed between elements within a match block" (rather than ANDed).

If possible it would be nice to impose a restriction on single abstraction in a match statement (I see no benefit in allowing more than one element). However, I do not know if it is possible to enforce such a restriction via YANG.

Ranga

--
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Oct 2017 21:53:43 +0200

I'd be ok with doing a choice.

Eliot

On 10/25/17 8:41 PM, Einar Nilsen-Nygaard (einarnn) wrote:
>   * Make the mud-acl container just contain a choice of all 6
>     elements. At that point, you would only be specifying one of them.
>   * If not all the elements are mutually exclusive, you could have
>     specific constraints that say “when controller is present,
>     my-controller cannot be present” and vice-versa. This would make
>     specifying both elements illegal per the constraints.
>
>
> Each approve would inform the client and server what is “valid”. The
> first approach would effectively force multiple “access control
> entries”, meaning one for each condition you wanted to test.
>
> Cheers,
>
> Einar
>
>> If possible it would be nice to impose a restriction on single
>> abstraction in a match statement (I see no benefit in allowing more
>> than one element). However, I do not know if it is possible to
>> enforce such a restriction via YANG.
>>
>> Ranga
>>
>>  
>>
>>
>>
>>
>>
>>
>> -- 
>> M. Ranganathan
>