Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Hi,

Good point - adding on to that, I'd like to point out that there are more protocols that use ports besides TCP and UDP, such as SCTP and DCCP.
If the port number was not protocol-specific then devices would also have to match SCTP ports, DCCP ports, and other protocol ports, even for protocols which haven't been invented yet. This is not possible to implement.

> Thus, if a very simple device can understand TCP and UDP ports but cannot understand more detailed information, that is supported.

I don't think YANG features can possibly envision or handle all the potential variations between devices, unless we give each criterion its own separate feature.

To my knowledge, the device I am currently working on doesn't support port range matching, or operators other than 'equals', and I see there is currently no YANG feature for that.

Do you think it would be better to let vendors use deviations to indicate which features aren't supported?

________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Eliot Lear <lear@cisco.com>
Sent: Tuesday, 23 January 2018 8:14 a.m.
To: Kent Watsen; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Hi Kent and Mahesh and Sonal,

Thanks very much for working on this draft.  I have noted one problem that I think needs correcting.  I come prepared with a diff.

The current model has {source,dest}-port-or-range hanging off ipv4 or ipv6.  This is a transport parameter and is not appropriate for protocols that do not use ports (ie, ICMP, ESP, etc).  A better locale would be to hang these components underneath l4 underneath their respective tcp and udp branches.

Because this is so basic a function, I propose that this not be included in match-on-tcp or match-on-udp.  Instead, the contents of both tcp and udp be moved to new containers "tcp-all" and "udp-all", respectively, and the ports hang as peers to that.  Thus, if a very simple device can understand TCP and UDP ports but cannot understand more detailed information, that is supported.

 And so from a tree perspective, it would look like this:

       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw tcp-all {match-on-tcp}?
       |        |  |  |        +--rw sequence-number?          uint32
       |        |  |  |        +--rw acknowledgement-number?   uint32
       |        |  |  |        +--rw data-offset?              uint8
       |        |  |  |        +--rw reserved?                 uint8
       |        |  |  |        +--rw flags?                    bits
       |        |  |  |        +--rw window-size?              uint16
       |        |  |  |        +--rw urgent-pointer?           uint16
       |        |  |  |        +--rw options?                  uint32
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp
       |        |  |  |     +--rw source-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw destination-port-range-or-operator
       |        |  |  |     |  +--rw (port-range-or-operator)?
       |        |  |  |     |     +--:(range)
       |        |  |  |     |     |  +--rw lower-port    inet:port-number
       |        |  |  |     |     |  +--rw upper-port    inet:port-number
       |        |  |  |     |     +--:(operator)
       |        |  |  |     |        +--rw operator?     operator
       |        |  |  |     |        +--rw port          inet:port-number
       |        |  |  |     +--rw udp-all {match-on-udp}?
       |        |  |  |        +--rw length?   uint16

A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is attached.

Eliot

On 17.01.18 22:55, Kent Watsen wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-15.

This working group last call ends on January 31st.
Please send your comments to the NETMOD mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Also, could the authors, explicitly CC-ed on this email,
please confirm at this time that they are unaware of
any IPR related to this draft.

Thank you,
NETMOD Chairs

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod