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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Inline [TR]

From: Dots [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, July 17, 2018 8:57 PM
To: Jon Shallow <[e-mail]>
Cc: [e-mail]
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.


________________________________
Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
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.

[TR] +1

-Tiru

Regards

Jon

From: [e-mail]<mailto:[e-mail]> [mailto: [e-mail]<mailto:[e-mail]>]
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-,

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:[e-mail]]
Envoyé : mardi 17 juillet 2018 11:00
À : BOUCADAIR Mohamed IMT/OLN; [e-mail]<mailto:[e-mail]>; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

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

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

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:[e-mail]]
Envoyé : mardi 17 juillet 2018 10:33
À : BOUCADAIR Mohamed IMT/OLN; [e-mail]<mailto:[e-mail]>; Konda, Tirumaleswar Reddy
Objet : RE: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

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

Re-,

Which part of 7951 are you referring to?

Thanks.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
Envoyé : mardi 17 juillet 2018 10:17
À : BOUCADAIR Mohamed IMT/OLN; [e-mail]<mailto:[e-mail]>; 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: [e-mail]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 17 July 2018 14:29
To: Konda, Tirumaleswar Reddy; Jon Shallow; [e-mail]<mailto:[e-mail]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
Envoyé : mardi 17 juillet 2018 09:18
À : Jon Shallow; [e-mail]<mailto:[e-mail]>; 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.
Jon1> A tenuous cross connection!

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.
Jon1> Actually, “flags”:”” does do this for a final drop, so offset is not needed, but see caveat below.

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": {""}
                   }
==
Jon1> As per RFC7951, this should be
==
                 "name": "drop-last-fragment",
                 "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

From: Jon Shallow [mailto:[e-mail]]
Sent: Tuesday, July 17, 2018 5:53 PM
To: Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 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: [e-mail]<mailto:[e-mail]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 17 July 2018 12:16
To: Jon Shallow; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

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:[e-mail]] On Behalf Of Jon Shallow
Sent: Tuesday, July 17, 2018 2:19 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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,

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: [e-mail]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 16 July 2018 22:22
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Dots] [boucadair/draft-ietf-dots-data-channel] flagment bits representation questions in Figure 28, 29 (#2)

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:[e-mail]]
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>.