Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34EC12D7E9 for ; Mon, 22 Jan 2018 14:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y98l3GBnIzs for ; Mon, 22 Jan 2018 14:02:08 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7510124D6C for ; Mon, 22 Jan 2018 14:02:06 -0800 (PST) From: Alex Campbell To: Eliot Lear , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 Thread-Index: AQHTj93UjCIcW+s9eES+j5KHC1NlIKOA0LyA//+d5sg= Date: Mon, 22 Jan 2018 22:02:05 +0000 Message-ID: <1516658524969.70610@Aviatnet.com> References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net>, <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com> In-Reply-To: <1e5da232-82cd-5a1a-930e-555796bd2ef7@cisco.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: multipart/alternative; boundary="_000_151665852496970610Aviatnetcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 22:02:11 -0000 --_000_151665852496970610Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Good point - adding on to that, I'd like to point out that there are more p= rotocols 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 t= o match SCTP ports, DCCP ports, and other protocol ports, even for protocol= s 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 potenti= al variations between devices, unless we give each criterion its own separa= te 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 curren= tly no YANG feature for that. Do you think it would be better to let vendors use deviations to indicate w= hich features aren't supported? ________________________________ From: netmod on behalf of Eliot Lear 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 d= o not use ports (ie, ICMP, ESP, etc). A better locale would be to hang the= se components underneath l4 underneath their respective tcp and udp branche= s. 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 b= e moved to new containers "tcp-all" and "udp-all", respectively, and the po= rts hang as peers to that. Thus, if a very simple device can understand TC= P and UDP ports but cannot understand more detailed information, that is su= pported. 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 attach= ed. 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 https://www.ietf.org/mailman/listinfo/netmod --_000_151665852496970610Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi,


Good point - adding on to that, I'd like to point out that there are more p= rotocols 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 t= o match SCTP ports, DCCP ports, and other protocol ports, even for protocol= s 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 can= not understand more detailed information, that is supported.


I don't think YANG features can possibly envision or handle all the pote= ntial variations between devices, unless we give each criterion its own sep= arate feature.

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

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



From: netmod <netmod-b= ounces@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 probl= em that I think needs correcting.  I come prepared with a diff.

The current model has {source,dest}-port-or-range hanging off ipv4 or ip= v6.  This is a transport parameter and is not appropriate for protocol= s that do not use ports (ie, ICMP, ESP, etc).  A better locale would b= e 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 i= ncluded in match-on-tcp or match-on-udp.  Instead, the contents of bot= h 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)?=0A=
       |        |  |  +--:(tcp)=0A=
       |        |  |  |  +--rw tcp=0A=
       |        |  |  |     +--rw source-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw destination-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw tcp-all {match-on-tcp}?=0A=
       |        |  |  |        +--rw sequence-number?          uint32=
=0A=
       |        |  |  |        +--rw acknowledgement-number?   uint32=
=0A=
       |        |  |  |        +--rw data-offset?              uint8=0A=
       |        |  |  |        +--rw reserved?                 uint8=0A=
       |        |  |  |        +--rw flags?                    bits=0A=
       |        |  |  |        +--rw window-size?              uint16=
=0A=
       |        |  |  |        +--rw urgent-pointer?           uint16=
=0A=
       |        |  |  |        +--rw options?                  uint32=
=0A=
       |        |  |  +--:(udp)=0A=
       |        |  |  |  +--rw udp=0A=
       |        |  |  |     +--rw source-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw destination-port-range-or-operator=0A=
       |        |  |  |     |  +--rw (port-range-or-operator)?=0A=
       |        |  |  |     |     +--:(range)=0A=
       |        |  |  |     |     |  +--rw lower-port    inet:port-numb=
er=0A=
       |        |  |  |     |     |  +--rw upper-port    inet:port-numb=
er=0A=
       |        |  |  |     |     +--:(operator)=0A=
       |        |  |  |     |        +--rw operator?     operator=0A=
       |        |  |  |     |        +--rw port          inet:port-numb=
er=0A=
       |        |  |  |     +--rw udp-all {match-on-udp}?=0A=
       |        |  |  |        +--rw length?   uint16


A diff ietf-packet-fields.yang and ietf-access-control-lists.yang is attach= ed.

Eliot



On 17.01.18 22:55, Kent Watsen wrote:
All,=0A=
=0A=
This starts a two-week working group last call on=0A=
draft-ietf-netmod-acl-model-15.=0A=
=0A=
This working group last call ends on January 31st.=0A=
Please send your comments to the NETMOD mailing list.=0A=
=0A=
Positive comments, e.g., "I've reviewed this document=0A=
and believe it is ready for publication", are welcome!=0A=
This is useful and important, even from authors.=0A=
=0A=
Also, could the authors, explicitly CC-ed on this email,=0A=
please confirm at this time that they are unaware of=0A=
any IPR related to this draft.=0A=
=0A=
Thank you,=0A=
NETMOD Chairs=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmo=
d@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=
=0A=

--_000_151665852496970610Aviatnetcom_--