Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

From: <[email-masked]>
Date: Mon, 16 Jul 2018 21:22:12 +0000

Sending this message to share with the WG the outcome of the discussion with the author of the issue.

As a reminder, the current version relies on netmod-acl for manipulating IPv4 fragments, but specifies a new behavior for IPv4.

The first change below on Figure 28 can be easily fixed, but the second one raised a serious issue on handling IPv4 last fragment. The current netmod-acl does not allow to assess whether a fragment is the last one. Things may be simple with flags but this requires the support of “operator”, for example, so that we can manipulate offset and so on. Unfortunately, I don’t think we can get those fixed in the netmod acl (refer to the discussion we had with the authors of netmod-acl) about the IPv6, hence my preference to reintroduce the “fragment” thing.

As a result, we will re-introduce fragment keyword for IPv4 to simplify handling of fragments.

Cheers,
Med

De : __kaname__ [mailto:[email-masked]]
Envoyé : samedi 14 juillet 2018 12:25
À : boucadair/draft-ietf-dots-data-channel
Cc : Subscribed
Objet : [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits
https://tools.ietf.org/html/rfc7951#section-6.5 The "bits" Type

  1.  "flags": {""}
Can it be used for representation of all bits are zero?

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty
https://tools.ietf.org/html/rfc7951#section-6.9 The "empty" Type

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/boucadair/draft-ietf-dots-data-channel/issues/2>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AO8fV9qHuUbLp5Gmso7XowEmDfCRftCOks5uGhtqgaJpZM4VP6Vz>.

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 17 Jul 2018 09:48:58 +0100

Hi there,

If we are going to re-introduce fragment, should we not take the opportunity to extend the fragment definition so that it can be used by a DOTS mitigator to map into BGP FlowSpec?

[I do have a hard time working with the limited capability of the Cisco ACL fragments keyword.  For example the often quoted

  access-list 101 deny ip any host 171.16.23.1 fragments

  access-list 101 permit tcp any host 171.16.23.1 eq 80

  access-list 101 deny ip any any

will allow any non-fragmented or initial-fragment packets to 171.16.23.1:80.  All I need to do is send a high rate of initial-fragment packets to 171.16.23.1:80 and the server runs out of memory waiting for fragmentation re-assembly…]

The YANG update could look something like

    typedef fragment-operator {

    type bits {

      bit not {

        position 0;

        description

          "If set, logical negation of operation.";

      }

      bit match {

        position 1;

        description

          "Match bit.  If set, this is a bitwise match operation

           defined as "(data & value) == value"; if unset, (data &

           value) evaluates to TRUE if any of the bits in the value

           mask are set in the data.";

      }

    }

    description

      "How to apply the defined fragment type bits.";

  }

  typedef fragment-type {

    type bits {

      bit df {

        position 0;

        description

          "Don't fragment.";

      }

      bit isf {

        position 1;

        description

          "Is a fragment.";

      }

      bit ff {

        position 2;

        description

          "First fragment.";

      }

      bit lf {

        position 3;

        description

          "Last fragment.";

      }

    }

    description

      "Different fragmentation types to match against.";

  }

  grouping fragment-fields {

    leaf frag-operator {

      type fragment-operator;

      description

        "How to interpret the fragment type."

    }

    leaf frag-type {

      type fragment-type;

      description

        "What fragment types to look for."

    }

  }

.....

          leaf destination-prefix {

            type boolean;

            description 

              "Support of filtering based on the destination prefix.";

          }          

          container fragment {

            description

              "Indicates the capability of a DOTS server to

               enforce filters on IPv4 fragments.";

            uses fragment-fields;

          }

.....

          leaf destination-prefix {

            type boolean;

            description

              "Support of filtering based on the destination prefix.";

          }

          container fragment {

            description

              "Indicates the capability of a DOTS server to

               enforce filters on IPv6 fragments.";

            uses fragment-fields;

          }

Regards

Jon  

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 16 July 2018 22:22
To: [email-masked]
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Cheers,

Med

Figure 28

1.	"flags": {"more"}

                   "ipv4": {
                     "flags": {"more"}
                   }

would be

                   "ipv4": {
                     "flags": "more"
                   }

according to
+--rw flags? bits

2.	"flags": {""}

Figure 29

3.	"fragment"

                   "ipv6": {
                     "fragment"
                   }

is

                   "ipv6": {
                     "fragment": [null]
                   }

according to
+--rw fragment? empty

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <https://github.com/boucadair/draft-ietf-dots-data-channel/issues/2> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AO8fV9qHuUbLp5Gmso7XowEmDfCRftCOks5uGhtqgaJpZM4VP6Vz> .  <https://github.com/notifications/beacon/AO8fV9Mx-XII4wMsTI8w1XK2UhhDu2gmks5uGhtqgaJpZM4VP6Vz.gif>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 17 Jul 2018 11:15:42 +0000

Hi Jon and Med,

I don’t follow the discussion, we previously agreed that flags defined in netmod-acl-model can be used to drop IPv4 fragments (both initial and non-initial)  (see the thread https://www.ietf.org/mail-archive/web/dots/current/msg02220.html) .

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, July 17, 2018 2:19 PM
To: [email-masked]; [email-masked]
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi there,

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 16 July 2018 22:22
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 17 Jul 2018 13:23:15 +0100

Hi Tiru,

I created all this confusion when I thought that it was possible to replace the use of the DOTS addition (non netmod-acl) definition for “fragment” by using what was available in netmod-acl (which I thought would handle the dropping of all the fragments of IP packet sequence, including the initial fragment).

Timeline

. IPv4 and IPv6 use added keyword fragment

. Alternative to fragment – IPv4 uses “flags” : “more” in a convoluted configuration and IPv6 used flow label 44 (fragment label) to drop all fragments

. Netmod-acl confirms that flow label is only to be used for protocols (e.g. TCP), not fragment header – so fragment for IPv6 re-instated.

So

Should “fragment” be re-used for IPv4 fragments (for consistency across the 2 IP protocol types) instead of the convoluted “flags” : “more” configuration as “fragment” is supported for IPv6 again.

[Interestingly IPv4 fragment is defined in “container capabilities”, but not “container ipv4” – which does need to be fixed either way.]

Then, if we are going to include “fragment” again, should we make it more friendly as outlined by my YANG below.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 17 July 2018 12:16
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Jon and Med,

Cheers,

-Tiru

  _____  

Hi there,

    type bits {

      bit not {

        position 0;

        description

      }

      bit match {

        position 1;

        description

      }

    }

    description

  }

  typedef fragment-type {

    type bits {

      bit df {

        position 0;

        description

          "Don't fragment.";

      }

      bit isf {

        position 1;

        description

          "Is a fragment.";

      }

      bit ff {

        position 2;

        description

          "First fragment.";

      }

      bit lf {

        position 3;

        description

          "Last fragment.";

      }

    }

    description

  }

    leaf frag-operator {

      type fragment-operator;

      description

    }

    leaf frag-type {

      type fragment-type;

      description

    }

  }

.....

            type boolean;

            description 

          }          

          container fragment {

            description

            uses fragment-fields;

          }

.....

            type boolean;

            description

          }

          container fragment {

            description

            uses fragment-fields;

          }

Regards

Jon  

Cheers,

Med

Figure 28

1.	"flags": {"more"}

                   "ipv4": {
                     "flags": {"more"}
                   }

would be

                   "ipv4": {
                     "flags": "more"
                   }

according to
+--rw flags? bits

2.	"flags": {""}

Figure 29

3.	"fragment"

                   "ipv6": {
                     "fragment"
                   }

is

                   "ipv6": {
                     "fragment": [null]
                   }

according to
+--rw fragment? empty

—

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 17 Jul 2018 13:17:56 +0000

The IPv4 fragment defined in the container capabilities means “flags” is supported to filter IPv4 fragments. To avoid confusion, “fragment” in IPv4 container capabilities can be replaced with flags.
We should try to use netmod-acl wherever possible and use “flags” to block IPv4 fragmentation attacks.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 5:53 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Timeline

So

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 17 July 2018 12:16
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Jon and Med,

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, July 17, 2018 2:19 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 13:23:12 +0000

Jon,

See below.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 08:23
À : 'Konda, Tirumaleswar Reddy'; [email-masked]; BOUCADAIR Mohamed IMT/OLN
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Tiru,

Timeline

So

[Interestingly IPv4 fragment is defined in “container capabilities”, but not “container ipv4” – which does need to be fixed either way.]
[Med] I’m not sure to understand this one. “Fragment” capability for IPv4 is defined as follows:

Which means filtering based on the current flags. So that is (partially) fine.

The issue is that flags alone do not allow us the flexibility to manipulate all types of fragments. For example, identifying last fragments and so on.

Then, if we are going to include “fragment” again, should we make it more friendly as outlined by my YANG below.
[Med] I’m personally open for this, but I’d like to hear more opinions.

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 13:28:35 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 09:18
À : Jon Shallow; [email-masked]; BOUCADAIR Mohamed IMT/OLN
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

The IPv4 fragment defined in the container capabilities means “flags” is supported to filter IPv4 fragments.
[Med] Agree.

To avoid confusion, “fragment” in IPv4 container capabilities can be replaced with flags.
[Med] That is one possibility, but the point is that some fragment handling requires to manipulate other fragment-related fields (e.g., offset). For example, we cannot distinguish a last fragment vs non-fragmented packet. This can be easy if we had an op based on the offset, or we have a primitive that will say whether this is a fragment or not.

We should try to use netmod-acl wherever possible and use “flags” to block IPv4 fragmentation attacks.
[Med] Yes, but what we have currently in the draft for the last fragment is broken:

==
                 "name": "drop-last-fragment",
                 "matches": {
                   "ipv4": {
                     "flags": {""}
                   }
==

-Tiru

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 17 Jul 2018 14:13:39 +0000

Hi Med,

We should check with the authors of netmod-acl draft to fix the issue, they just need to add another bit to flags to identify last fragment (the doc has not yet completed ISEG review, and the authors will probably do more changes to the draft).

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 6:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 09:18
À : Jon Shallow; [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

==

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 5:53 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 17 Jul 2018 15:17:14 +0100

Hi,

See inline Jon1.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 17 July 2018 14:29
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-, 

Please see inline.

Cheers,

Med

[Med] Agree.

Jon1> A tenuous cross connection!

Jon1> Actually, “flags”:”” does do this for a final drop, so offset is not needed, but see caveat below.

==

                 "matches": {

                   "ipv4": {

                     "flags": {""}

                   }

== 

Jon1> As per RFC7951, this should be

==

                 "matches": {

                   "ipv4": {

OLD                  "flags": {""}

NEW                  "flags": ""

                   }

== 

However, if the “Do Not Fragment Packet” bit is also set in the packet as well as the More bit is not set (i.e. Last Fragment), then it will not match this ACE entry and will get through (bits tested are reserved, fragment and more) as per 

    u_short ip_off;                     /* fragment offset field */

#define IP_RF 0x8000                    /* reserved fragment flag */

#define IP_DF 0x4000                    /* dont fragment flag */

#define IP_MF 0x2000                    /* more fragments flag */

#define IP_OFFMASK 0x1fff               /* mask for fragmenting bits */

as the “flags” field is defining which bits are set and which bits are not set, not a mask on bits.  Grr.

The same is also true for 

==

               {

                 "name": "drop-all-except-last-fragment",

                 "matches": {

                   "ipv4": {

Updated        "flags": "more"

                   }

                 },

                 "actions": {

                   "forwarding": "drop"

                 }

               }

==

If the packet contains the Don’t Fragment or Reserved bit set.

~Jon1

-Tiru

  _____  

Hi Tiru,

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,

-Tiru

  _____  

Hi there,

    type bits {

      bit not {

        position 0;

        description

      }

      bit match {

        position 1;

        description

      }

    }

    description

  }

  typedef fragment-type {

    type bits {

      bit df {

        position 0;

        description

          "Don't fragment.";

      }

      bit isf {

        position 1;

        description

          "Is a fragment.";

      }

      bit ff {

        position 2;

        description

          "First fragment.";

      }

      bit lf {

        position 3;

        description

          "Last fragment.";

      }

    }

    description

  }

    leaf frag-operator {

      type fragment-operator;

      description

    }

    leaf frag-type {

      type fragment-type;

      description

    }

  }

.....

            type boolean;

            description 

          }          

          container fragment {

            description

            uses fragment-fields;

          }

.....

            type boolean;

            description

          }

          container fragment {

            description

            uses fragment-fields;

          }

Regards

Jon  

Cheers,

Med

Figure 28

1.	"flags": {"more"}

                   "ipv4": {
                     "flags": {"more"}
                   }

would be

                   "ipv4": {
                     "flags": "more"
                   }

according to
+--rw flags? bits

2.	"flags": {""}

Figure 29

3.	"fragment"

                   "ipv6": {
                     "fragment"
                   }

is

                   "ipv6": {
                     "fragment": [null]
                   }

according to
+--rw fragment? empty

—

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 14:20:47 +0000

Re-,

We have already done (please check the archives). The answer we got is as follows:

==
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.
==
Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 10:14
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Med,

-Tiru

Please see inline.

Cheers,
Med

==

-Tiru

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 17 Jul 2018 15:24:42 +0100

I think this conversation / thread has uncovered a fundamental flaw in how “bits” is being used for “matching” in netmod-acl.  Not only for IP Flags, but also for TCP Flags, where there should be an operator to define how the bits are going to be matched / used.

Acknowledged that they want to close and get out netmod-acl asap.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 17 July 2018 15:14
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Med,

-Tiru

  _____  

Re-, 

Please see inline.

Cheers,

Med

[Med] Agree.

==

                 "matches": {

                   "ipv4": {

                     "flags": {""}

                   }

== 

-Tiru

  _____  

Hi Tiru,

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,

-Tiru

  _____  

Hi there,

    type bits {

      bit not {

        position 0;

        description

      }

      bit match {

        position 1;

        description

      }

    }

    description

  }

  typedef fragment-type {

    type bits {

      bit df {

        position 0;

        description

          "Don't fragment.";

      }

      bit isf {

        position 1;

        description

          "Is a fragment.";

      }

      bit ff {

        position 2;

        description

          "First fragment.";

      }

      bit lf {

        position 3;

        description

          "Last fragment.";

      }

    }

    description

  }

    leaf frag-operator {

      type fragment-operator;

      description

    }

    leaf frag-type {

      type fragment-type;

      description

    }

  }

.....

            type boolean;

            description 

          }          

          container fragment {

            description

            uses fragment-fields;

          }

.....

            type boolean;

            description

          }

          container fragment {

            description

            uses fragment-fields;

          }

Regards

Jon  

Cheers,

Med

Figure 28

1.	"flags": {"more"}

                   "ipv4": {
                     "flags": {"more"}
                   }

would be

                   "ipv4": {
                     "flags": "more"
                   }

according to
+--rw flags? bits

2.	"flags": {""}

Figure 29

3.	"fragment"

                   "ipv6": {
                     "fragment"
                   }

is

                   "ipv6": {
                     "fragment": [null]
                   }

according to
+--rw fragment? empty

—

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 14:27:48 +0000

Re-,

Which part of 7951 are you referring to?

Thanks.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 10:17
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi,

See inline Jon1.

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

==

~Jon1

-Tiru

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 17 Jul 2018 15:33:25 +0100

Sorry – ‘RFC7951 6.5.  The “bits” Type’.  It is a simple string with the set bits’ name space delimited, not an array.

Regards

Jon

From: [email-masked] [mailto: [email-masked]] 
Sent: 17 July 2018 15:28
To: Jon Shallow; [email-masked]; Konda, Tirumaleswar Reddy
Subject: RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-,

Thanks.

Cheers,

Med

Hi,

See inline Jon1.

Regards

Jon

Re-, 

Please see inline.

Cheers,

Med

[Med] Agree.

==

                 "matches": {

                   "ipv4": {

                     "flags": {""}

                   }

== 

==

                 "matches": {

                   "ipv4": {

OLD                  "flags": {""}

NEW                  "flags": ""

                   }

== 

==

               {

                 "matches": {

                   "ipv4": {

Updated        "flags": "more"

                   }

                 },

                 "actions": {

                   "forwarding": "drop"

                 }

               }

==

~Jon1

-Tiru

  _____  

Hi Tiru,

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,

-Tiru

  _____  

Hi there,

    type bits {

      bit not {

        position 0;

        description

      }

      bit match {

        position 1;

        description

      }

    }

    description

  }

  typedef fragment-type {

    type bits {

      bit df {

        position 0;

        description

          "Don't fragment.";

      }

      bit isf {

        position 1;

        description

          "Is a fragment.";

      }

      bit ff {

        position 2;

        description

          "First fragment.";

      }

      bit lf {

        position 3;

        description

          "Last fragment.";

      }

    }

    description

  }

    leaf frag-operator {

      type fragment-operator;

      description

    }

    leaf frag-type {

      type fragment-type;

      description

    }

  }

.....

            type boolean;

            description 

          }          

          container fragment {

            description

            uses fragment-fields;

          }

.....

            type boolean;

            description

          }

          container fragment {

            description

            uses fragment-fields;

          }

Regards

Jon  

Cheers,

Med

Figure 28

1.	"flags": {"more"}

                   "ipv4": {
                     "flags": {"more"}
                   }

would be

                   "ipv4": {
                     "flags": "more"
                   }

according to
+--rw flags? bits

2.	"flags": {""}

Figure 29

3.	"fragment"

                   "ipv6": {
                     "fragment"
                   }

is

                   "ipv6": {
                     "fragment": [null]
                   }

according to
+--rw fragment? empty

—

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 14:48:19 +0000

Re-,

That text says that clause is “a space-separated
   sequence of names of bits that are set.

A match on (flags: “”) (if we assume this is correct) does not allow to distinguish this is a non-fragmented packet vs. last fragment.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 10:33
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Regards

Jon

Re-,

Thanks.

Cheers,
Med

Hi,

See inline Jon1.

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

==

~Jon1

-Tiru

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 17 Jul 2018 15:59:48 +0100

Hi Med,

Actually, on the last fragment of a fragmented packet sequence, the “more” bit is not set as there is no further data beyond this end packet.  So ”flags”:”” is stating the match is true if the “more” bit is not set (and “reserved” and “fragment” (bad name choice for netmod-acl – it should be “dontfragment”) are not set as well).

RFC791 2.3 Function Description

…

Fragmentation

…

    To assemble the fragments of an internet datagram, an internet

    protocol module (for example at a destination host) combines

    internet datagrams that all have the same value for the four fields:

    identification, source, destination, and protocol.  The combination

    is done by placing the data portion of each fragment in the relative

    position indicated by the fragment offset in that fragment's

    internet header.  The first fragment will have the fragment offset

    zero, and the last fragment will have the more-fragments flag reset

    to zero.

Regards

Jon

Sent: 17 July 2018 15:48

Re-, 

Cheers,

Med

Regards

Jon

Re-,

Thanks.

Cheers,

Med

Hi,

See inline Jon1.

Regards

Jon

Re-, 

Please see inline.

Cheers,

Med

[Med] Agree.

==

                 "matches": {

                   "ipv4": {

                     "flags": {""}

                   }

== 

==

                 "matches": {

                   "ipv4": {

OLD                  "flags": {""}

NEW                  "flags": ""

                   }

== 

==

               {

                 "matches": {

                   "ipv4": {

Updated        "flags": "more"

                   }

                 },

                 "actions": {

                   "forwarding": "drop"

                 }

               }

==

~Jon1

-Tiru

  _____  

Hi Tiru,

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,

-Tiru

  _____  

Hi there,

    type bits {

      bit not {

        position 0;

        description

      }

      bit match {

        position 1;

        description

      }

    }

    description

  }

  typedef fragment-type {

    type bits {

      bit df {

        position 0;

        description

          "Don't fragment.";

      }

      bit isf {

        position 1;

        description

          "Is a fragment.";

      }

      bit ff {

        position 2;

        description

          "First fragment.";

      }

      bit lf {

        position 3;

        description

          "Last fragment.";

      }

    }

    description

  }

    leaf frag-operator {

      type fragment-operator;

      description

    }

    leaf frag-type {

      type fragment-type;

      description

    }

  }

.....

            type boolean;

            description 

          }          

          container fragment {

            description

            uses fragment-fields;

          }

.....

            type boolean;

            description

          }

          container fragment {

            description

            uses fragment-fields;

          }

Regards

Jon  

Cheers,

Med

Figure 28

1.	"flags": {"more"}

                   "ipv4": {
                     "flags": {"more"}
                   }

would be

                   "ipv4": {
                     "flags": "more"
                   }

according to
+--rw flags? bits

2.	"flags": {""}

Figure 29

3.	"fragment"

                   "ipv6": {
                     "fragment"
                   }

is

                   "ipv6": {
                     "fragment": [null]
                   }

according to
+--rw fragment? empty

—

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 15:26:30 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 11:19
À : BOUCADAIR Mohamed IMT/OLN
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Was not copying to the list intentional?
[Med] cced again. Sorry.

In Appendix A Figure 28, the first ACE catches any packet with the more bit set.  So this will catch any packet of a fragmented sequence apart from the last packet, including the first fragment which otherwise may match ACE #2

The second ACE allows through traffic through according to the layer 4 definition

The third ACE drops the last fragmented packet (and just about any other traffic as it happens).
[Med] Yes. This is OK for the example we have my comment is not specific to the example in the draft, but to the general use of it. If an action is required only on last fragment, but not at other packet types, this is challenging with the current netmod-acl.

This does rely on ACE #1 doing the right stuff.
It may be that there have to be a whole load more permit ACEs between #1 and #3.

Having the BGP equivalent of fragment matching would be a whole lot simpler…
[Med] Agree.

Regards

Jon

Sent: 17 July 2018 16:04
To: Jon Shallow

Re-,

Agree, but this is not the point I was trying to make.

My point is that that match cannot allow to distinguish “non-fragmented packet vs. last fragment” if we need to do some actions only on last fragments, not non-fragmented packets.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 11:00
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Med,

Regards

Jon

Re-,

Cheers,
Med

Regards

Jon

Re-,

Thanks.

Cheers,
Med

Hi,

See inline Jon1.

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

==

~Jon1

-Tiru

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 18 Jul 2018 09:13:14 +0000

Inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 17, 2018 8:57 PM
To: Jon Shallow <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Please see inline.

Cheers,
Med

[TR] +1

-Tiru

Regards

Jon

From: [email-masked]<mailto:[email-masked]> [mailto: [email-masked]<mailto:[email-masked]>]
Sent: 17 July 2018 16:04
To: Jon Shallow
Subject: RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-,

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 11:00
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi Med,

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 17 July 2018 15:48
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-,

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 10:33
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Regards

Jon

From: [email-masked]<mailto:[email-masked]> [mailto: [email-masked]<mailto:[email-masked]>]
Sent: 17 July 2018 15:28
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy
Subject: RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-,

Thanks.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 10:17
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Hi,

See inline Jon1.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 17 July 2018 14:29
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-,

Please see inline.

Cheers,
Med

==

~Jon1

-Tiru

Timeline

So

Regards

Jon

Hi Jon and Med,

Cheers,
-Tiru

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description

.....

.....

Regards

Jon

Cheers,
Med

Figure 28

  1.  "flags": {"more"}

                   "ipv4": {

                     "flags": {"more"}

                   }

would be

                   "ipv4": {

                     "flags": "more"

                   }

according to
+--rw flags? bits

  1.  "flags": {""}

Figure 29

  1.  "fragment"

                   "ipv6": {

                     "fragment"

                   }

is

                   "ipv6": {

                     "fragment": [null]

                   }

according to
+--rw fragment? empty

—