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

[Eliot Lear <[e-mail]>]

On 22.01.18 23:02, Alex Campbell wrote:
>
>
> 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?
>

Yes, and so I agreed to Mahesh's simpler change.

Eliot
>
>
>
> ------------------------------------------------------------------------
> *From:* netmod <[e-mail]> on behalf of Eliot Lear
> <[e-mail]>
> *Sent:* Tuesday, 23 January 2018 8:14 a.m.
> *To:* Kent Watsen; [e-mail]
> *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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>