Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 24 Feb 2014 22:49:55 +0000

Hello NETMOD working group,

we addressed the comments from the Working Group on earlier versions and we did not receive any new comments on the current version, so we consider the document done.  We would like to request to move it to last call.  Please advise in case there is anything else we need to do.

Thank you and kind regards
--- Alex

From: Alexander Clemm (alex)
Sent: Friday, February 14, 2014 3:38 PM
To: [email-masked]
Cc: Juergen Schoenwaelder ([email-masked]); [email-masked]; Benoit Claise (bclaise); Andy Bierman ([email-masked]); Lisa Huang (yihuan)
Subject: draft-huang-netmod-acl (Stateless Packet Filter Configuration)

Hello Netmod Working Group,

we are happy to see that stateless packet filter configuration is likely part of the newly revised charter.

We have not posted an update to the current draft (http://tools.ietf.org/html/draft-huang-netmod-acl-03), as we think that the current draft addresses all comments that were previously raised by the working group.  However, there has not been discussion on this subject recently.  If you have additional comments, let's discuss them, otherwise we would like to see the document take the "next step".

Thank you and kind regards
--- Alex (on behalf of Lisa, Andy)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Feb 2014 00:22:59 +0100

> we addressed the comments from the Working Group on earlier versions and we did not receive any new comments on the current version, so we consider the document done.  We would like to request to m…

Alex,

please note that this document right now still has the status of an
individual submission and as such we can't last call it (at least not
in the sense of a WG last call). The normal IETF procedure is that
documents first become WG items (if they fall into the charter of a WG
and the WG adopts a document as a WG document) and one they are stable
WG documents, they go to WG last call. Also note that silence may
indicate there are no open issues but it may also indicate that nobody
bothered to review a document.

>From a quick look at the document, it seems there are leafs without
description clauses etc. which is quite uncommon for IETF data
models. I am also not sure whether you cover IPv4 and IPv6 on equal
footing. (For example, masks are a rather unknown concept in IPv6,
IGMP really is an IPv4 mechanism - so why is it under case ipv6-pfe,
why do you cover ARP but not the ND IPv6 equivalent.) It is unclear
why port filters are limited to TCP, UDP and SCTP - there is as well
DCCP and this may need to be future proofed. Type definitions should
have a canonical representation. There are also more general issues
like module naming conventions etc. that are not followd yet. There is
an empty security considerations section, no IANA considerations
section, a reference section that is amazingly short (given the number
of [normative] references embodied in the YANG modules). And finally,
there are some TODOs in the text that I assume the authors are aware
of.

All this is fine for an individual submission. But a WG product needs
to have many more of these things worked out.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Feb 2014 00:36:17 +0100

> > we addressed the comments from the Working Group on earlier versions and we did not receive any new comments on the current version, so we consider the document done.  We would like to request to…

One more thing before I go to sleep: The leaf tcp-flag-operation
specifies behaviour in the description clause that goes beyond YANG
rules - you can't simply stick more information into an enum by
appending magic strings to the enum name.

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 24 Feb 2014 23:51:49 +0000

Hi Juergen,
Thank you for your response.  Clearly, we need some guidance from you and the working group.  
Looking forward to the discussion at the working group meeting.  Andy will present as neither Lisa nor I will be there in person.
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, February 24, 2014 3:23 PM
To: Alexander Clemm (alex)
Cc: [email-masked]; [email-masked]; Benoit Claise (bclaise); Andy Bierman ([email-masked]); Lisa Huang (yihuan)
Subject: Re: draft-huang-netmod-acl (Stateless Packet Filter Configuration)

Alex,

please note that this document right now still has the status of an individual submission and as such we can't last call it (at least not in the sense of a WG last call). The normal IETF procedure is that documents first become WG items (if they fall into the charter of a WG and the WG adopts a document as a WG document) and one they are stable WG documents, they go to WG last call. Also note that silence may indicate there are no open issues but it may also indicate that nobody bothered to review a document.

>From a quick look at the document, it seems there are leafs without description clauses etc. which is quite uncommon for IETF data models. I am also not sure whether you cover IPv4 and IPv6 on equal footing. (For example, masks are a rather unknown concept in IPv6, IGMP really is an IPv4 mechanism - so why is it under case ipv6-pfe, why do you cover ARP but not the ND IPv6 equivalent.) It is unclear why port filters are limited to TCP, UDP and SCTP - there is as well DCCP and this may need to be future proofed. Type definitions should have a canonical representation. There are also more general issues like module naming conventions etc. that are not followd yet. There is an empty security considerations section, no IANA considerations section, a reference section that is amazingly short (given the number of [normative] references embodied in the YANG modules). And finally, there are some TODOs in the text that I assume the authors are aware of.

All this is fine for an individual submission. But a WG product needs to have many more of these things worked out.

/js

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Wed, 26 Feb 2014 19:10:47 +0000

Juergen,

Thank you for your feed back. Responded in line. Sorry, it took me a little while to reply to your comments. Thanks,

Lisa

description clauses etc. which is quite uncommon for IETF data
models.
<Lisa>I will add descriptions to all leaves. Leaves without description are self-explained from the name. I will add them since this is required. Thanks for pointing it out.

I am also not sure whether you cover IPv4 and IPv6 on equal
footing.
<Lisa> I studied both IPv4 and IPv6 and tried to model as much as I can. Peer review is definite important to help to complete it. ACL clearly is a complex module. We have covered a lot of leaves, but we are sure we have not cover all. The structure of this module allows easy augmenting if more need to be added. I appreciate anyone who comments when an important parts is missing or anything is wrong.

(For example, masks are a rather unknown concept in IPv6,
IGMP really is an IPv4 mechanism
- so why is it under case ipv6-pfe,
<Lisa> I will research more and make corresponding change. Thank you for pointing it out.

why do you cover ARP but not the ND IPv6 equivalent.)
<Lisa> Could you elaborate what is "ND IPv6"? ARP is one of the ACL that widely used in network systems. The IP, Mac, ARP Stateless Packet Filt(SPF, ACL) modules are modules that are just starting points of SPF. Have them in the draft is to show how instance SPF module can augments the top SPF module. We did not meant to cover all SPF related module but try to give the most popular used instance SPF yang module enough contents. I am open to ideas if there is a necessary to separate instance modules from the top SPF module to different I-D so it will be clearer that we did not intent to cover all ACLs.

It is unclear
why port filters are limited to TCP, UDP and SCTP - there is as well
DCCP and this may need to be future proofed.
<Lisa>That is a good point. The system I looked at so far does not has port filter implemented for DCCP. I was trying to balance how much new requirement to add to current system if I have port as filter for DCCP vs what make sense. We had discussions with implementation teams from different company. Most system plan to use YANG as model and develop tools to auto generate code for implementation. They expect the model defination as specific as possible. If you know systems that have port filter for DCCP, please let me know.

As you mentioned, this may need to be future proofed. I have thought to use "feature" on port, but feature does not serve the purpose. Another solution is to ask implementation to write Conformance Specification from Andy's draft. My first concern is conformance I-D is still a draft. My other concern is, a lot of times, capability becomes implementation trash can to dump any feature that has not implemented.  Let me know if you have other suggestions. I copied the port below if anyone has any comments.

 choice src-ports {
           when "protocol = '6' or protocol = '17' or " +
                "protocol = '132'";

            description
              "Apply only when the protocol is TCP,
              UDP or SCTP.";

            case port-number-range {
                description
                    "Port group includes all ports between port-lower
                    and port-upper (including those)";
                leaf src-port-lower {
                    type inet:port-number;
                    description "Lower Port number.";
                    mandatory true;
                }
                leaf src-port-upper {
                    type inet:port-number;
                    description "Upper Port number.";
                    mandatory true;
                    must "../src-port-lower <= ../src-port-upper";
                }
            }
            case port-number {
                description
                    "Port group includes all ports that are greater
                    than, greater or equal, less than, less or equal,
                    or not equal the port, per the indicated
                    comparator.  It is possible for the port group
                    to be empty (for example, in case a port group
                    that is less than the minimum port number is
                    specified).";
                leaf src-comparator {
                    type spf:spf-comparator;
                    mandatory true;
                }
                leaf src-port {
                    type inet:port-number;
                    description "Port number.";
                    mandatory true;
                }
            }
            case port-group-ref {
                if-feature spf:port-groups;
                leaf src-port-group-name {
                    type spf:port-group-ref;
                    mandatory true;
                    description
                        "Reference a port group by the Port
                        Group name.";
                }
            }
        }  // choice src-ports

Type definitions should
have a canonical representation.
<Lisa>Could you elaborate this?

There are also more general issues
like module naming conventions etc. that are not followd yet.
<Lisa> Could you be specific? We did spend some energy to follow naming convention, but we may miss some. Appreciate more detail comments.

There is
an empty security considerations section, no IANA considerations
section, a reference section that is amazingly short (given the number
of [normative] references embodied in the YANG modules).
<Lisa>I am still new to I-D writing. Could you give more guidance about what IANA should cover? I do have a lot of reference in modules. Should I list all of them in IANA section? Appreciate if you could pointing me to I-A writing guild line so I could cross check all sections. I will also ask two other co-author, Andy and Alex, as they definitely have more experience than me.

And finally,
there are some TODOs in the text that I assume the authors are aware
of.
<Lisa> That is my editing mistake. I will remove them.

<Lisa>Good point. I think YANG language does not have a way to module an operation related leaf(let me know if I am wrong). In this module, the purpose of having a leaf with tcp-flag-operation is to allow the system configure this leaf. It is similar to a leaf of permit-deny action in ACL. The system which implements the modules has to interoperate the configuration and act based the configuration on the system. What would you suggest for if this is not the right way? I copied the leave below if anyone is interested to give more comments.

leaf tcp-flag-operation {
            when "boolean(../tcp-flag-value)" ;
            description
                "TCP flag Match option.
                A match occurs if the TCP
                datagram has certain TCP flags
                set or not set. You use the
                match-any keyword to allow a match
                to occur if any of the specified
                TCP flags are present, or you can
                use the match-all keyword to allow
                a match to occur only if all of
                the specified TCP flags are
                present. You must follow the
                match-any and match-all keywords
                with the + or - keyword and the
                flag-name argument to match on
                one or more TCP flags. ";
            default match-any;
            type enumeration {
                enum match-any {
                    description "match any";
                }
                enum match-all {
                    description "match all";
                }
            }
        }

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Feb 2014 23:13:25 +0100

On Wed, Feb 26, 2014 at 07:10:47PM +0000, Lisa Huang (yihuan) wrote:

> <Lisa> Could you elaborate what is "ND IPv6"? 

The equivalent of ARP for IPv6 is Neighbor Discovery (ND).

> <Lisa>That is a good point. The system I looked at so far does not has port filter implemented for DCCP. I was trying to balance how much new requirement to add to current system if I have port as…

Linux iptables for example.

> As you mentioned, this may need to be future proofed. I have thought to use "feature" on port, but feature does not serve the purpose. Another solution is to ask implementation to write Conformance Specification from Andy's draft. My first concern is conformance I-D is still a draft. My other concern is, a lot of times, capability becomes implementation trash can to dump any feature that has not implemented.  Let me know if you have other suggestions. 

I can't follow you....

I copied the port below if anyone has any comments.
>            when "protocol = '6' or protocol = '17' or " +

What I meant is that hard wiring protocol numbers in a when expression
(like above) causes problems once the next protocol comes along. (I am
also not sure relying on protocol numbers is a good thing in terms of
readability of the resulting config but this is a different question.)
 
> <Lisa>Could you elaborate this?

It is often OK to accept multiple representations as input but we like
to have a single representation to be canonical so that it is easy to
compare and process config snippets. See section 9.1 or RFC 6020.

> <Lisa> Could you be specific? We did spend some energy to follow naming convention, but we may miss some. Appreciate more detail comments.

I suggest you study RFC 6087 and the documents this RFC refers to.

> <Lisa>I am still new to I-D writing. Could you give more guidance about what IANA should cover? I do have a lot of reference in modules. Should I list all of them in IANA section? Appreciate if you…

Again, I suggest reading RFC 6087 and the documents this RFC refers
to.

>                 one or more TCP flags. ";

I do not really understand what you are trying to achieve here but I
am optimistic that YANG will have a way to do what you need. I have
not really reviewed the document in detail - I only took a quick look
to find out how mature this document is. I believe it is a starting
point but it still has to go a long way to get solid.

/js

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Wed, 26 Feb 2014 23:28:58 +0000

>The equivalent of ARP for IPv6 is Neighbor Discovery (ND).
If you are talking about ICMPV6 Neighbor Discovery, it is covered in IP
module with two leaves: icmp-type, and icmp-code. If there is a need to
make ND as a standalone module, I, or anyone else, could add it later.

leaf icmp-type {
            type c-types:icmp-type;
            description
                "ICMP message type number.
                Apply only when the protocol is icmp";
        }
        
        leaf icmp-code {
            when "boolean(../icmp-type) ";
            type c-types:icmp-code;
            description
            "ICMP subtype for a given icmp type.";
        }

>> <Lisa>That is a good point. The system I looked at so far does not has
>>port filter implemented for DCCP. I was trying to balance how much new
>>requirement to add to current system if I have port as filter for DCCP
>>vs what make sense. We had discussions with implementation teams from
>>different company. Most system plan to use YANG as model and develop
>>tools to auto generate code for implementation. They expect the model
>>defination as specific as possible. If you know systems that have port
>>filter for DCCP, please let me know.
>
I will take this into consideration.
>
>> As you mentioned, this may need to be future proofed. I have thought to
>>use "feature" on port, but feature does not serve the purpose. Another
>>solution is to ask implementation to write Conformance Specification
>>from Andy's draft. My first concern is conformance I-D is still a draft.
>>My other concern is, a lot of times, capability becomes implementation
>>trash can to dump any feature that has not implemented.  Let me know if
>>you have other suggestions.
>
>I can't follow you....
>
Agree the protocol number does not help the readability. More information
is in the description. I can match the number and protocol name in
description as well.

For TCP, UDP and SCTP protocol, port is a mandatory leaf as most likely
the system does not want to block packet for all TCP, UDP, SCTP for all
ports. For DCCP, port should be optional which is opposite. Is it a normal
case that a system want to permit DCCP on one port verse deny DCCP on
another port? 

>> <Lisa> Could you be specific? We did spend some energy to follow naming
>>convention, but we may miss some. Appreciate more detail comments.
>
I will look more into RFC 6087. Thanks for the pointer.
>> <Lisa>I am still new to I-D writing. Could you give more guidance about
>>what IANA should cover? I do have a lot of reference in modules. Should
>>I list all of them in IANA section? Appreciate if you could pointing me
>>to I-A writing guild line so I could cross check all sections. I will
>>also ask two other co-author, Andy and Alex, as they definitely have
>>more experience than me.
>
Will do. Thanks.
>> <Lisa>Good point. I think YANG language does not have a way to module
>>an operation related leaf(let me know if I am wrong). In this module,
>>the purpose of having a leaf with tcp-flag-operation is to allow the
>>system configure this leaf. It is similar to a leaf of permit-deny
>>action in ACL. The system which implements the modules has to
>>interoperate the configuration and act based the configuration on the
>>system. What would you suggest for if this is not the right way? I
>>copied the leave below if anyone is interested to give more comments.
>> 
>I do not really understand what you are trying to achieve here
This is a use case for TCP flag-checking mechanism using ACL. For example,
the following instance will allow TCP packets only if the TCP flags ACL
and SYN are set and the FIN flag is not set.
<...>
  <tcp-flag-value> ack syn <tcp-flag-value>
  <tcp-flag-mask>ack syn fin</tcp-flag-mask>
  <tcp-flag-operation>match-all</tcp-flag-operation>
</...>

The example is also in I-D.

>but I
 
Clearly, this is a good start.
>/js

Thanks,

Lisa