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-boun...@ietf.org> on behalf of Eliot Lear <l...@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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
