Subject: [Dots] Mail regarding draft-ietf-netmod-acl-model

From: <[email-masked]>
Date: Mon, 16 Apr 2018 15:08:29 +0000

Dear authors,

We do have a question regarding the interpretation of "protocol" when an IPv6 match filter is applied because the draft is not clear.

Can you please clarify whether "protocol" covers only the base IPv6 header or it includes also "next header" of any enclosed Extension Header?

For example, does the following ACL accept DNS packets + drop fragments efficiently? Does it work even if other EHs are preceding a Fragment header ?

{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        "name": "dns-fragments",
        "type": "ipv6-acl-type",
        "aces": {
          "ace": [
            {
              "name": "drop-all-fragments",
              "matches": {
                "ipv6": {
                  "protocol": 44
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
          "ace": [
            {
              "name": "allow-dns-packets",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8::/32"
                }
                "udp": {
                  "destination-port": {
                    "operator": "eq",
                    "port": 53
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}
Cheers,
Med

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 19 Apr 2018 12:17:11 -0700

Mohamed,

While I wait for my co-authors to get back to me, here is my take on this.

> On Apr 16, 2018, at 8:08 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Dear authors, 
>  
> We do have a question regarding the interpretation of “protocol” when an IPv6 match filter is applied because the draft is not clear.
>  
> Can you please clarify whether “protocol” covers only the base IPv6 header or it includes also “next header” of any enclosed Extension Header?

The current draft covers only the base IPv6 header. It does not cover Extension Headers. 

If there is such a requirement, we will have to take it up in the bis version of this draft.

>                   "destination-ipv6-network": "2001:db8::/32"

Again, my personal take on it (and I will wait for my co-authors to correct me if I am wrong), is that these are two separate entries. Depending on the order of the rules, and again assuming the rules are in the order stated above, if you do receive a fragmented DNS packet, the second rule will never be hit. The first rule would apply and the packet will be dropped. If the rules are reversed, then all DNS packets to IPv6 address 2001:db8::/32 will be accepted, whether they are fragmented or not.

Cheers.

> Med

Mahesh Jethanandani
[email-masked]

---

From: Sonal Agarwal <[email-masked]>
Date: Thu, 19 Apr 2018 16:35:19 -0700

Hi Med,

Replies inline:

Can you please clarify whether “protocol” covers only the base IPv6 header
or it includes also “next header” of any enclosed Extension Header?

The protocol covers the entire IPv6 packet, which includes the extension
header(s). The EH's do not individually contain the protocol information.
When EH's are present, then the protocol will be in the "Upper layer
header".

For example, does the following ACL accept DNS packets + drop fragments
efficiently? Does it work even if other EHs are preceding a Fragment header
?

     I have not seen an ACL that is used to filter DNS packets, but I
presume it would have the protocol to be tcp/udp and the L4 port to be 53.

"ace": [
            {

This ACE is saying match protocol 44 in upper header and drop the packet.
It will only work for packets that have 44 set as the protocol. For
hardware to truly drop all fragmented packets, the correct match would be
something like "deny any any frag". This indicates to dataplane to figure
out if a packet is a fragment, and then drop it.

"ace": [
            {

I presume you want the protocol here to be ipv6. This ACE indicates to
match packets with protocol ipv6 and match on destination-port 53. In order
to do this, dataplane needs to extract L4 information from the payload. If
the packet matches destination port of 53, then accept the packets.
Dataplane should be capable of extracting L4 from the payload, regardless
of the number of extension headers present.

Thanks,
Sonal.

On Thu, Apr 19, 2018 at 12:17 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> We do have a question regarding the interpretation of “protocol” when an
> IPv6 match filter is applied because the draft is not clear.
>
> Can you please clarify whether “protocol” covers only the base IPv6 header
> or it includes also “next header” of any enclosed Extension Header?
>
>
> For example, does the following ACL accept DNS packets + drop fragments
> efficiently? Does it work even if other EHs are preceding a Fragment header
> ?
>
> {
> Again, my personal take on it (and I will wait for my co-authors to
> correct me if I am wrong), is that these are two separate entries.
> Depending on the order of the rules, and again assuming the rules are in
> the order stated above, if you do receive a fragmented DNS packet, the
> second rule will never be hit. The first rule would apply and the packet
> will be dropped. If the rules are reversed, then all DNS packets to IPv6
> address 2001:db8::/32 will be accepted, whether they are fragmented or
> not.
>
> Cheers.
>
> Cheers,
> Med
>
>
> Mahesh Jethanandani
> [email-masked]
>
>

---

From: <[email-masked]>
Date: Fri, 20 Apr 2018 05:33:51 +0000

Hi Mahesh,

Thank you for the follow-up.

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani [mailto:[email-masked]]
Envoyé : jeudi 19 avril 2018 21:17
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; [email-masked]; Kent Watsen
Objet : Re: Mail regarding draft-ietf-netmod-acl-model
Importance : Haute

Mohamed,

On Apr 16, 2018, at 8:08 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Dear authors,

The current draft covers only the base IPv6 header. It does not cover Extension Headers.
[Med] Thank you for clarifying. Can you please add a sentence to the draft to make this explicit?

If there is such a requirement, we will have to take it up in the bis version of this draft.
[Med] Filtering EHs is a requirement. I would hope this is in scope, but I won’t ask for it to be included at this stage of the publication process given that I would like to see netmod-acl published ASAP.

{

Again, my personal take on it (and I will wait for my co-authors to correct me if I am wrong), is that these are two separate entries. Depending on the order of the rules, and again assuming the rules are in the order stated above, if you do receive a fragmented DNS packet, the second rule will never be hit. The first rule would apply and the packet will be dropped.
[Med] Yes, if and only if there is no EH preceding the Fragment header. That is if the next-header of the base IPv6 points to another header that the fragment header, a fragmented packet won’t be dropped.

If the rules are reversed, then all DNS packets to IPv6 address 2001:db8::/32 will be accepted, whether they are fragmented or not.
[Med] Yes.

Cheers.

Cheers,
Med

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 20 Apr 2018 05:46:23 +0000

Hi Sonal,

Thank you for the reply. Much appreciated!

Please see inline.

Cheers,
Med

De : Sonal Agarwal [mailto:[email-masked]]
Envoyé : vendredi 20 avril 2018 01:35
À : Mahesh Jethanandani
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]; Kent Watsen
Objet : Re: Mail regarding draft-ietf-netmod-acl-model

Hi Med,

Replies inline:

Can you please clarify whether “protocol” covers only the base IPv6 header or it includes also “next header” of any enclosed Extension Header?
The protocol covers the entire IPv6 packet, which includes the extension header(s). The EH's do not individually contain the protocol information.
[Med] Actually, “protocol” is defined in the netmod-acl as follows:

    leaf protocol {
      type uint8;
      description
        "Internet Protocol number. Refers to the protocol of the
         payload. In IPv6, this field is known as 'next-header.";

This text is really not clear what it covers. This is confusing given that “next header” is present in the base header and also in EHs.

In order to avoid confusion, please consider adding one sentence to two to clarify the intent.

When EH's are present, then the protocol will be in the "Upper layer header".

     I have not seen an ACL that is used to filter DNS packets, but I presume it would have the protocol to be tcp/udp and the L4 port to be 53.
"ace": [
            {
              "name": "drop-all-fragments",
              "matches": {
                "ipv6": {
                  "protocol": 44
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]

This ACE is saying match protocol 44 in upper header and drop the packet. It will only work for packets that have 44 set as the protocol. For hardware to truly drop all fragmented packets, the correct match would be something like "deny any any frag". This indicates to dataplane to figure out if a packet is a fragment, and then drop it.

"ace": [
            {

I presume you want the protocol here to be ipv6. This ACE indicates to match packets with protocol ipv6 and match on destination-port 53. In order to do this, dataplane needs to extract L4 information from the payload. If the packet matches destination port of 53, then accept the packets. Dataplane should be capable of extracting L4 from the payload, regardless of the number of extension headers present.

Thanks,
Sonal.

On Thu, Apr 19, 2018 at 12:17 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:
Mohamed,

Dear authors,

{

Cheers.

Cheers,
Med

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 20 Apr 2018 12:18:19 -0700

Med,

See comment inline with [mj]

> On Apr 19, 2018, at 10:46 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Sonal,
>  
> De : Sonal Agarwal [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Kent Watsen
> When EH's are present, then the protocol will be in the "Upper layer header”.

[mj] Med, how about this?

OLD:

Internet Protocol number. Refers to the protocol of the
payload. In IPv6, this field is known as 'next-header.

NEW:

Internet Protocol number. Refers to the protocol of the
payload. In IPv6, this field is known as 'next-header',
and if extension headers are present, the protocol
is present in the 'upper-layer' header.

>  
> For example, does the following ACL accept DNS packets + drop fragments efficiently?Does it work even if other EHs are preceding a Fragment header ?
>  
> On Thu, Apr 19, 2018 at 12:17 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> Mohamed,
>  
> On Apr 16, 2018, at 8:08 AM, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Dear authors, 
>  
> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]

---

From: <[email-masked]>
Date: Mon, 23 Apr 2018 06:13:52 +0000

Hi Mahesh,

Thank you.

I suggest this modified NEW text:

   payload. That is, the protocol layer immediately above IPv6 (upper layer).
   This is indicated in the 'next header' of the IPv6 header when
   no extension headers are present.
   When processing a sequence of Next Header values in a packet,

   the first one that is not an extension header indicates that

   the next item in the packet is the corresponding upper-layer

   header.

Cheers,

Med

De : Mahesh Jethanandani [mailto:[email-masked]]
Envoyé : vendredi 20 avril 2018 21:18
À : BOUCADAIR Mohamed IMT/OLN
Cc : Sonal Agarwal; [email-masked]; [email-masked]; Kent Watsen
Objet : Re: Mail regarding draft-ietf-netmod-acl-model

Med,

On Apr 19, 2018, at 10:46 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sonal,

Please see inline.

Cheers,
Med

De : Sonal Agarwal [mailto:[email-masked]]
Envoyé : vendredi 20 avril 2018 01:35
À : Mahesh Jethanandani
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kent Watsen
Objet : Re: Mail regarding draft-ietf-netmod-acl-model

Hi Med,

Replies inline:

    leaf protocol {
      type uint8;
      description

OLD:

NEW:

"ace": [
            {

Thanks,
Sonal.

Dear authors,

{

Cheers.

Cheers,
Med

Mahesh Jethanandani

Mahesh Jethanandani