Subject: [Dots] Data Channel ACL fragments

From: "Jon Shallow" <[email-masked]>
Date: Wed, 4 Apr 2018 14:51:20 +0100

Hi there,

Do we still need to have the fragment definition for ACEs in the data
channel?

draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags +
options) and implicitly in ipv6 through the next header field protocol set
to 44 (fragment extension header).

IPV4

====

  grouping acl-ipv4-header-fields {

    description

      "Fields in IPv4 header.";

...

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

            "Reserved. Must be zero.";

        }

        bit fragment {

          position 1;

          description

            "Setting value to 0 indicates may fragment, while setting

             the value to 1 indicates do not fragment.";

        }

        bit more {

          position 2;

          description

            "Setting the value to 0 indicates this is the last fragment,

             and setting the value to 1 indicates more fragments are

             coming.";

        }

      }

      description

        "Bit definitions for the flags field in IPv4 header.";

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

        "The fragment offset is measured in units of 8 octets (64 bits).

         The first fragment has offset zero. The length is 13 bits";

    }

Regards

Jon

---

From: <[email-masked]>
Date: Wed, 4 Apr 2018 14:26:59 +0000

Re-,

I guess we do still need this because we wanted to achieve this functionality (especially for the non-initial fragments):

==
   This document supports fragment filtering which adds an additional
   layer of protection against a DoS attack that uses non-initial
   fragments only.  When there is only layer 3 information in the ACL
   entry and the fragments keyword is present, for non-initial fragments
   matching the ACE entry, the 'deny' or 'accept' action associated with
   the ACE entry will be enforced.  For initial or non-fragment matching
   the ACE entry, the next ACE entry will be processed.  When there is
   both layer 3 and layer 4 information in the ACE entry and the
   fragments keyword is present, the ACE action is conservative for both
   'accept' and 'deny' actions.  The actions are conservative to not
   accidentally deny a fragmented portion of a flow because the
   fragments do not contain sufficient information to match all of the
   filter attributes.  In the 'deny' action case, instead of denying a
   non-initial fragment, the next ACE entry is processed.  In the
   'accept' case, it is assumed that the layer 4 information in the non-
   initial fragment, if available, matches the layer 4 information in
   the ACE entry.
==

No?

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mercredi 4 avril 2018 15:51
À : [email-masked]
Objet : [Dots] Data Channel ACL fragments

Hi there,

Do we still need to have the fragment definition for ACEs in the data channel?

draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + options) and implicitly in ipv6 through the next header field protocol set to 44 (fragment extension header).

IPV4
====

    leaf offset {
      type uint16 {
        range "20..65535";
      }
      description

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 4 Apr 2018 16:29:31 +0100

Hi Med et all,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 04 April 2018 15:27
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Re-,

I guess we do still need this because we wanted to achieve this
functionality (especially for the non-initial fragments):

==

   the ACE entry.

==

[Jon] Actually, as I read the text above, if the additional layer of
protection is required against fragmented attacks and v-[46]-fragment is set
with action “drop”, then any non-initial fragment is dropped – fine.

However, the initial fragment skips this ACE test and goes onto the next
ACE.  Assuming that there is a “accept” that matches everything else (i.e.
we like the packet apart from when it is fragmented), then the initial
fragment is let through.

The target IP then consumes lots of RAM whilst waiting for the missing
fragment segments……..D(D)oS Success.

There is no way to drop the initial fragment with the above text other than
to “drop” genuine non fragmented traffic as well.  I think that logic is
flawed to drop just subsequent fragments.

[Jon] I also wonder how the above is going to get implemented – it would be
easier to say any fragmented packet sequence is not allowed (including the
initial packet) rather than only a part of the sequence which then leads to
a DoS in its own rights.

No?

[Jon] See above.  I do agree that flags -> fragment -> 1 is a bit ambiguous
is its definition when used to match a packet as an acl/ace, but I do think
the match intent is that the packet is not fragmented.

Cheers,

Med

Hi there,

IPV4

====

    description

...

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 5 Apr 2018 08:22:50 +0000

Hi Jon,

The fragment definition to protect the target from attacks that use non-initial fragments only.
We followed the Security considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so the non-initial fragments will be discarded by the destination host (its implemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html).

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 9:00 PM
To: [email-masked]; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Hi Med et all,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 04 April 2018 15:27
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Re-,

==

[Jon] Actually, as I read the text above, if the additional layer of protection is required against fragmented attacks and v-[46]-fragment is set with action "drop", then any non-initial fragment is dropped - fine.

However, the initial fragment skips this ACE test and goes onto the next ACE.  Assuming that there is a "accept" that matches everything else (i.e. we like the packet apart from when it is fragmented), then the initial fragment is let through.

The target IP then consumes lots of RAM whilst waiting for the missing fragment segments........D(D)oS Success.

There is no way to drop the initial fragment with the above text other than to "drop" genuine non fragmented traffic as well.  I think that logic is flawed to drop just subsequent fragments.

[Jon] I also wonder how the above is going to get implemented - it would be easier to say any fragmented packet sequence is not allowed (including the initial packet) rather than only a part of the sequence which then leads to a DoS in its own rights.

No?

[Jon] See above.  I do agree that flags -> fragment -> 1 is a bit ambiguous is its definition when used to match a packet as an acl/ace, but I do think the match intent is that the packet is not fragmented.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mercredi 4 avril 2018 15:51
À : [email-masked]<mailto:[email-masked]>
Objet : [Dots] Data Channel ACL fragments

Hi there,

IPV4
====

    leaf offset {
      type uint16 {
        range "20..65535";
      }
      description

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Apr 2018 10:44:34 +0100

Hi Tiru,

Actually no, as there is a disconnect between the Cisco document and what we
have currently got set up.

The Cisco Document refers to ACL, which is an ACE in netmod-acl-model/DOTS
speak.  A DOTS ACL can be a list of separate matching ACEs.

With netmod-acl, we have layer 3 definitions and then separately layer 4
definitions – there is now no concept of L3+L4 within the same ACE.

So, the Cisco statement “Note: When there is both Layer 3 and Layer 4
information in the ACL line and the fragments keyword is present” will never
be true for an ACE entry.

----

I still do not understand from the Cisco Document how you can build a set of
ACLs that say (but I may be missing something)

“All traffic to port 53 is allowed unless it is fragmented, in which case
all fragments are to be dropped”

I can create a set of ACLs that say

“All traffic to port 53 is allowed unless it is fragmented, in which case
all non-initial fragments are to be dropped”

Which does set things up for a DoS of the target with all the initial
fragments waiting re-assembly.

----

Which then gets more complicated to construct something when we can only do
either L3 or L4 matching on a per ACE.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Hi Jon,

The fragment definition to protect the target from attacks that use
non-initial fragments only.

We followed the Security considerations for IP filtering given in Section 2
of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so the
non-initial fragments will be discarded by the destination host (its
implemented and discussed in
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-
gre/8014-acl-wp.html).

-Tiru

Hi Med et all,

See inline [Jon]

Regards

Jon

Re-,

==

   the ACE entry.

==

No?

 

Cheers,

Med

Hi there,

IPV4

====

    description

...

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Apr 2018 06:54:43 +0000

Hi Jon,

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]]
Sent: Thursday, April 5, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

Actually no, as there is a disconnect between the Cisco document and what we have currently got set up.

The Cisco Document refers to ACL, which is an ACE in netmod-acl-model/DOTS speak.  A DOTS ACL can be a list of separate matching ACEs.

With netmod-acl, we have layer 3 definitions and then separately layer 4 definitions - there is now no concept of L3+L4 within the same ACE.

So, the Cisco statement "Note: When there is both Layer 3 and Layer 4 information in the ACL line and the fragments keyword is present" will never be true for an ACE entry.

[TR] No, as per the ACE definition in draft-ietf-netmod-acl-model-16, The choice statements within the match container allow for selection of one header within each of "l2", "l3", or "l4" headers.
It is possible to specify both L3 and L4 information in the ACE (each ACE has a group of match criteria).
----

I still do not understand from the Cisco Document how you can build a set of ACLs that say (but I may be missing something)
"All traffic to port 53 is allowed unless it is fragmented, in which case all fragments are to be dropped"

I can create a set of ACLs that say
"All traffic to port 53 is allowed unless it is fragmented, in which case all non-initial fragments are to be dropped"
Which does set things up for a DoS of the target with all the initial fragments waiting re-assembly.

[TR] The don't think a ACL should blindly drop all fragmented packets, fragmentation may or may not happen because of a DoS attack. Do vendors currently support what you are asking ?

-Tiru

----

Which then gets more complicated to construct something when we can only do either L3 or L4 matching on a per ACE.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Hi Jon,

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 9:00 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Hi Med et all,

See inline [Jon]

Regards

Jon

Re-,

==

No?

Cheers,
Med

Hi there,

IPV4
====

    leaf offset {
      type uint16 {
        range "20..65535";
      }
      description

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 10:45:17 +0100

Hi Tiru,

See inline [Jon1]

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]]

Sent: 07 April 2018 07:55
To: Jon Shallow; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Jon,

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]] 
Sent: Thursday, April 5, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

[TR] No, as per the ACE definition in draft-ietf-netmod-acl-model-16, The
choice statements within the match container allow for selection of one
header within each of "l2", "l3", or "l4" headers. 

It is possible to specify both L3 and L4 information in the ACE (each ACE
has a group of match criteria).

[Jon1] – My bad – I was reading “Choice” as choosing L3 or L4, not that the
choice was referring to the sub-elements within the choice.  So, yes, L3 +
L4 are supported.

----

[TR] The don’t think a ACL should blindly drop all fragmented packets,
fragmentation may or may not happen because of a DoS attack. Do vendors
currently support what you are asking ?

[Jon1] If (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 packet,
then the packet is a part of a fragmented packet sequence.  Dropping any
packets with (IP_MF | IP_OFFMASK) != 0 will safely drop all the fragmented
packets.  This then protects the target’s IP reassembly logic’s RAM usage.
Similarly, for IPv6 there is the detection of protocol 44.

[Jon1] NCC’s mitigation appliances can disable fragmented packets either
manually or when there is an ongoing fragmentation attack where the complete
set of fragments for a packet are not seen.

[Jon1] I still question as to whether we should be using netmod-acl’s
version of fragmentation instead of using a DOTS extension.

~jon1

-Tiru

----

Regards

Jon

From: Dots [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow;  <mailto:[email-masked]>
[email-masked];  <mailto:[email-masked]> [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Hi Jon,

We followed the Security considerations for IP filtering given in Section 2
of  <https://www.ietf.org/rfc/rfc1858.txt>
https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so the
non-initial fragments will be discarded by the destination host (its
implemented and discussed in
<https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation
-gre/8014-acl-wp.html>
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-
gre/8014-acl-wp.html).

-Tiru

From: Dots [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 9:00 PM
To:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Hi Med et all,

See inline [Jon]

Regards

Jon

From: Dots [mailto:  <mailto:[email-masked]> [email-masked]]
On Behalf Of  <mailto:[email-masked]>
[email-masked]
Sent: 04 April 2018 15:27
To: Jon Shallow;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Re-,

==

   the ACE entry.

==

No?

 

Cheers,

Med

De : Dots [ <mailto:[email-masked]> mailto:[email-masked]] De
la part de Jon Shallow
Envoyé : mercredi 4 avril 2018 15:51
À :  <mailto:[email-masked]> [email-masked]
Objet : [Dots] Data Channel ACL fragments

Hi there,

IPV4

====

    description

...

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 11:04:43 +0000

Hi Jon,

Please see inline [TR2]

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, April 9, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

See inline [Jon1]

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]<mailto:[email-masked]>]
Sent: 07 April 2018 07:55
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Data Channel ACL fragments

Hi Jon,

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]]
Sent: Thursday, April 5, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

[Jon1] - My bad - I was reading "Choice" as choosing L3 or L4, not that the choice was referring to the sub-elements within the choice.  So, yes, L3 + L4 are supported.

----

[Jon1] If (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 packet, then the packet is a part of a fragmented packet sequence.  Dropping any packets with (IP_MF | IP_OFFMASK) != 0 will safely drop all the fragmented packets.  This then protects the target's IP reassembly logic's RAM usage.   Similarly, for IPv6 there is the detection of protocol 44.

[Jon1] NCC's mitigation appliances can disable fragmented packets either manually or when there is an ongoing fragmentation attack where the complete set of fragments for a packet are not seen.

[TR2]  My question is whether vendors support any ACL that drops all fragments (e.g. a separate feature called virtual fragmentation and reassembly is used by Cisco devices to protect the target's reassembly logic, see https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html but I did not find any proprietary ACL to drop all fragments) ?

[Jon1] I still question as to whether we should be using netmod-acl's version of fragmentation instead of using a DOTS extension.

[TR2] How will using netmod-acl version helps drop DoS attack using non-initial fragments only ?

-Tiru

~jon1

-Tiru

----

Regards

Jon

Hi Jon,

-Tiru

Hi Med et all,

See inline [Jon]

Regards

Jon

Re-,

==

No?

Cheers,
Med

Hi there,

IPV4
====

    leaf offset {
      type uint16 {
        range "20..65535";
      }
      description

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 22:20:44 +0100

Hi Tiru,

See inline [Jon2]

Regards

Jon

Hi Tiru,

----

[TR2]  My question is whether vendors support any ACL that drops all
fragments (e.g. a separate feature called virtual fragmentation and
reassembly is used by Cisco devices to protect the target’s reassembly
logic, see
https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide
/12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html but I did not find
any proprietary ACL to drop all fragments) ?

[Jon2] I would not want use virtual re-assembly (performance / RAM usage) as
that is a simple way to take out a router

[Jon2] Off the top of my head

[TR2] How will using netmod-acl version helps drop DoS attack using
non-initial fragments only ?

[Jon2] Dropping all but the initial fragment will in its own rights cause a
IP re-assembly RAM attack on the target if the L3+L4 definition is to allow
traffic through (as well as a potential performance lookup hit).  So, I
think we are asking the wrong question here.

[Jon2] In the early days of the Internet, someone had the smart idea of
sending the final fragment first – so the recipient could pre-allocate the
full packet size before the remaining fragments came in.  This then messed
up firewalls who could not properly do any filtering as the initial fragment
came in last.  And hence the perceived need to drop non-initial fragments to
get around this issue.  It still does not handle the buildup of the first
fragment set building up on the target server.

[Jon2] The “flags->fragment” definition is ambiguous for an ACE (but valid
as to whether to allow a packet to get fragmented or not – is that really a
ACE?) which I would like to use.  “Flags->more” definition covers all
fragments but the last fragment. “Offset” is unfortunately not a range, but
otherwise would get used for the final fragment.

~jon2

-Tiru

~jon1

-Tiru

----

Regards

Jon

Hi Jon,

-Tiru

Hi Med et all,

See inline [Jon]

Regards

Jon

Re-,

==

   the ACE entry.

==

No?

 

Cheers,

Med

Hi there,

IPV4

====

    description

...

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 06:10:14 +0000

[Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use.

[TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ?

"Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment.
~jon2

[TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset"  field for the final fragment ?

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 10:07:17 +0100

Hi Tiru,

See inline Jon3]

Regards

Jon

Sent: 10 April 2018 07:10
To: Jon Shallow; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

[Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid
as to whether to allow a packet to get fragmented or not - is that really a
ACE?) which I would like to use.  

[TR] I don't get it. What purpose does it serve to create a ACE rule using
"fragment" bit ?

[Jon3] Agreed - This definition has not been thought through for an ACE.  I
think they have just emulated the DF bit in RFC791 as this general flags
definition is the same as for the flags in RFC791.

"Flags->more" definition covers all fragments but the last fragment.
"Offset" is unfortunately not a range, but otherwise would get used for the
final fragment.

~jon2

[TR] It looks like two ACE entries are required to drop all the fragments
("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the
second ACE). How to use the "Offset"  field for the final fragment ?

[Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF
or more-fragments flag).  This is set for all fragments apart from the final
(as in last part of packet, not the order in which they are sent -
fortunately that early decision to send them in the wrong order was phased
out, but still there in some legacy systems!)

[Jon3] But as the final fragment of the sequence could have any offset, the
use of the offset field is not that helpful here.  Even if we do go with our
DOTS fragments definition (but widened to cover all fragments), we still
cannot generate a netmod-acl entry for onward processing by an upstream
mitigator.

[Jon3] FYI, for Juniper, you just need to set 'first-fragment' and
'is-fragment' in their ACL.  BGP FlowSpec does support fragmentation
detection properly (RFC5575 Type 12 Fragment).

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 09:47:44 +0000

Hi Jon,

Please see inline [TR2]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, April 10, 2018 2:37 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

See inline Jon3]

Regards

Jon

[TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ?
[Jon3] Agreed - This definition has not been thought through for an ACE.  I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791.

[TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit.

[Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag).  This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!)

[TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ?

-Tiru

[Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here.  Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator.

[Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL.  BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment).

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 12:00:28 +0100

Hi Tiru,

See inline [Jon4]

Regards

Jon

[TR2] You may want to inform the authors of netmod-acl draft, surprisingly
BGP flowspec also uses "fragment" bit.

[Jon4] On my ToDo list for a clean solution.  But we do now have a solution
- see below.

~jon2

[TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the
final fragment along with "flags->more" set to 1 to drop the first fragment
as another ACE entry so as to drop all fragments to the target ?

[Jon4] If "flags->more" is configured and it is configured with a value of
0, this will match not only the final fragment, but also a non-fragmented
packet.  If "flags->more" is not configured, then this will match a
non-fragmented packet only.

[Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by
an ACE with "flags->more" = 1 and "drop", followed by an ACE with
"flags->more" = 0 and "drop" will cause all fragmented packets to get
dropped, but still allow through the non-fragmented packet.  So, we have a
solution for

"allow all traffic to port 53, but drop all fragmented packets".

~jon4

-Tiru

 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 11:33:45 +0000

Please see inline [TR3]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, April 10, 2018 4:30 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

See inline [Jon4]

Regards

Jon

[TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit.
[Jon4] On my ToDo list for a clean solution.  But we do now have a solution - see below.

[TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ?
[Jon4] If "flags->more" is configured and it is configured with a value of 0, this will match not only the final fragment, but also a non-fragmented packet.  If "flags->more" is not configured, then this will match a non-fragmented packet only.

[TR3] net-mod-acl says "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming.". I think it means, if "flags->more" is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We should check with netmod-acl authors for confirmation.

[Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by an ACE with "flags->more" = 1 and "drop", followed by an ACE with "flags->more" = 0 and "drop" will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.  So, we have a solution for
"allow all traffic to port 53, but drop all fragmented packets".

[TR3] I don't think the above solution will work. In the above line, I think you  meant L3 ACE, and the first fragment will match the first entry and is allowed.

-Tiru

~jon4

-Tiru

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 13:35:26 +0100

Hi Tiru,

See inline [Jon5]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 10 April 2018 12:34
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Please see inline [TR3]

Hi Tiru,

See inline [Jon4]

Regards

Jon

 

~jon2

[TR3] net-mod-acl says "Setting the value to 0 indicates this is the last
fragment, and setting the value to 1 indicates more fragments are coming.".
I think it means, if "flags->more" is set to zero and offset is not zero
then it indicates this is the last fragments; the flags can be used in
isolation without comparing if offset value is zero or non-zero. We should
check with netmod-acl authors for confirmation. 

[Jon5].  The netmod-acl text for flags and offset is effectively a word for
word copy out of RFC791 3.1 Internet Header Format.  So I think it is meant
to be interpreted as being an exact match for the same - including the
offset specific value.

  Flags:  3 bits

    Various Control Flags.

      Bit 0: reserved, must be zero

      Bit 1: (DF) 0 = May Fragment,  1 = Don't Fragment.

      Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

          0   1   2

        +---+---+---+

        |   | D | M |

        | 0 | F | F |

        +---+---+---+

  Fragment Offset:  13 bits

    This field indicates where in the datagram this fragment belongs.

    The fragment offset is measured in units of 8 octets (64 bits).  The

    first fragment has offset zero.

----

Versus

----

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

[TR3] I don't think the above solution will work. In the above line, I think
you  meant L3 ACE, and the first fragment will match the first entry and is
allowed. 

[Jon5]No, the first ACE is a L3/L4 match.  If you have (a1 allows through
all non-fragmented packets, a2 & a3 drops all fragmented packets) the
following 

.

{

       "aces": [{

                                     "ace": {

                                                    "name": "a1",

                                                    "matches": [{

                                                                   "ipv4": {

"destination-network": "1.2.3.0/24"

                                                                   },

                                                                   "udp": {

"destination-port": 53

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "accept"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a2",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"destination-network": "1.2.3.0/24",

"more": 0

},

"udp": {

"destination-port": 53

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a3",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 1

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      }

       ]

}

.

[Jon5] It will work

-Tiru

~jon4

-Tiru

 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 13 Apr 2018 09:02:54 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, April 10, 2018 6:05 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

See inline [Jon5]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 April 2018 12:34
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Please see inline [TR3]

Hi Tiru,

See inline [Jon4]

Regards

Jon

[Jon5].  The netmod-acl text for flags and offset is effectively a word for word copy out of RFC791 3.1 Internet Header Format.  So I think it is meant to be interpreted as being an exact match for the same - including the offset specific value.

  Flags:  3 bits

    Various Control Flags.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description

[Jon5]No, the first ACE is a L3/L4 match.  If you have (a1 allows through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following

[TR4] The first fragment will have both L3 and L4 information, and matches a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped).

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 13 Apr 2018 11:08:45 +0100

Hi Tiru,

See inline [Jon6]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Hi Jon,

Please see inline [TR4]

 

~jon2

  Flags:  3 bits

    Various Control Flags.

          0   1   2

        +---+---+---+

        |   | D | M |

        | 0 | F | F |

        +---+---+---+

  Fragment Offset:  13 bits

 

----

Versus

----

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

[TR4] The first fragment will have both L3 and L4 information, and matches
a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will
drop all fragments except last-fragment, the last fragment will not have L4
info, so will not match a1 but will match a2 and get dropped).

[Jon6] - Yes - I stand corrected, your ordering is correct.  A2 no longer
needs destination-port.

~jon6

-Tiru

.

{

       "aces": [{

                                     "ace": {

                                                    "name": "a1",

                                                    "matches": [{

                                                                   "ipv4": {

                                                                   },

                                                                   "udp": {

"destination-port": 53

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "accept"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a2",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 0

},

"udp": {

"destination-port": 53

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a3",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 1

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      }

       ]

}

.

[Jon5] It will work

-Tiru

~jon4

-Tiru

 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 13 Apr 2018 12:24:32 +0000

[Jon6] - Yes - I stand corrected, your ordering is correct.  A2 no longer needs destination-port.

Yup. The summary of our discussion is to use the flags defined in netmod-acl-model to drop fragments (both initial and non-initial), and v4-fragments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed from the draft.

Cheers
-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

See inline [Jon6]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Hi Jon,

Please see inline [TR4]

  Flags:  3 bits

    Various Control Flags.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description

[Jon6] - Yes - I stand corrected, your ordering is correct.  A2 no longer needs destination-port.
~jon6

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 13 Apr 2018 13:29:33 +0100

Hi Tiru,

Thanks.

I think that we do need an example in the draft of how to do this though..

IPv6 will not be using flags, but looking instead for the next header of
protocol 44.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Yup. The summary of our discussion is to use the flags defined in
netmod-acl-model to drop fragments (both initial and non-initial), and
v4-fragments and v6-fragments and the associated text added to drop
non-initial fragments discussed in Section 4.1 will be removed from the
draft.

Cheers

-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

 

~jon2

  Flags:  3 bits

    Various Control Flags.

          0   1   2

        +---+---+---+

        |   | D | M |

        | 0 | F | F |

        +---+---+---+

  Fragment Offset:  13 bits

 

----

Versus

----

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

~jon6

-Tiru

.

{

       "aces": [{

                                     "ace": {

                                                    "name": "a1",

                                                    "matches": [{

                                                                   "ipv4": {

                                                                   },

                                                                   "udp": {

"destination-port": 53

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "accept"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a2",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 0

},

"udp": {

"destination-port": 53

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a3",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 1

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      }

       ]

}

.

[Jon5] It will work

-Tiru

~jon4

-Tiru

 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 14 Apr 2018 04:47:51 +0000

Sure, Appendix looks like the right place to add the filtering rule examples for both IPv4 and IPv6.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, April 13, 2018 6:00 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

Thanks.

I think that we do need an example in the draft of how to do this though....

IPv6 will not be using flags, but looking instead for the next header of protocol 44.

Regards

Jon

Cheers
-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

  Flags:  3 bits

    Various Control Flags.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

-Tiru

---

From: <[email-masked]>
Date: Mon, 16 Apr 2018 11:11:12 +0000

Hi all,

I do agree with the conclusion of this thread for IPv4 but not for IPv6.

For example, a DOTS client may send this POST request to filter fragmented packets (including atomic ones):

{
  "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"
              }
            }
          ]
        }
      }
    ]
  }
}

But these ACEs are efficient only if the next-header of the IPv6 header points to 44. If the IPv6 packet includes other EHs and the Fragment header is not the one which is immediately preceding the base header, then fragmented packets won't match the "drop-all-fragments" ACE.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : samedi 14 avril 2018 06:48
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Data Channel ACL fragments

-Tiru

Hi Tiru,

Thanks.

Regards

Jon

Cheers
-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

  Flags:  3 bits

    Various Control Flags.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 16 Apr 2018 13:08:03 +0100

Hi Med,

Currently we disagree over IPv6 and fragmentation.

As per
https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pape
r0900aecd8054d37d.html , ACL filtering does work on “fragments”.

Filtering Based on Extension Header Type

Routers can be explicitly instructed to look at and act on traffic that
contains certain extension header types. This functionality is available on
Cisco platforms and can be configured with the help of IPv6 Access List
options:

deny protocol {source-ipv6-prefix/prefix-length | any | host
source-ipv6-address} [operator [port-number]]
{destination-ipv6-prefix/prefix-length | any | host
destination-ipv6-address} [operator [port-number]] [dest-option-type
[doh-number | doh-type]] [dscp value] [flow-label value] [fragments] [log]
[log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing]
[routing-type routing-number] [sequence value] [time-range name]
[undetermined-transport]

Example 1: Access List Filtering based on Extension Header Type

ipv6 access-list EH-type

deny ipv6 any 2001:2B8:1:1::/64 routing

In order to permit or deny certain types of extension headers, routers are
configured with the ACL features listed above to filter based on the "Header
Type" value (see Table 1).

Note that in this case, the content of the EH is not processed and the
router simply makes a decision based on the presence of a certain EH type.
Software platforms can also analyze and filter based on additional EH fields
such as the "Type Field". These filtering capabilities are very useful in
implementing, for instance, security policies such as blocking source
routing.

…

Since this functionality is implemented through ACLs, platforms that support
hardware forwarding when ACLs are applied, will be able to handle the IPv6
traffic with EHs in hardware as well (Figure 7).

Juniper appears to support this on the MX router (see
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/f
irewall-filter-match-conditions-for-ipv6-traffic.html) 

extension-headers header-type

Match an extension header type that is contained in the packet by
identifying a Next Header value.

Note: This match condition is only supported on MPCs in MX Series routers.

In the first fragment of a packet, the filter searches for a match in any of
the extension header types. When a packet with a fragment header is found (a
subsequent fragment), the filter only searches for a match of the next
extension header type because the location of other extension headers is
unpredictable.

In place of the numeric value, you can specify one of the following text
synonyms (the field values are also listed): ah (51), destination (60), esp
(50), fragment (44), hop-by-hop (0), mobility (135), or routing (43).

To match any value for the extension header option, use the text synonym
any.

For MX Series routers with MPCs, initialize new firewall filters that
include this condition by walking the corresponding SNMP MIB.

So, no matter where the fragment header is (even with subsequent extended
headers (to me the Authenticating Header, or ESP header is the actual
protocol)) before the actual protocol, matching on protocol 44 works and is
map-able to Cisco/Juniper ALCs where they do not need to use the control
plane – or am I missing something here?

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 16 April 2018 12:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Hi all, 

For example, a DOTS client may send this POST request to filter fragmented
packets (including atomic ones): 

{

    "acl": [

      {

        "name": "dns-fragments",

        "type": "ipv6-acl-type",

        "aces": {

          "ace": [

            {

              "matches": {

                "ipv6": {

                  "protocol": 44

                }

              },

              "actions": {

                "forwarding": "drop"

              }

            }

          ]

          "ace": [

            {

              "matches": {

                "ipv6": {

                }

                "udp": {

                  "destination-port": {

                    "operator": "eq",

                    "port": 53

                  }

                }

              },

              "actions": {

                "forwarding": "accept"

              }

            }

          ]

        }

      }

    ]

  }

}

But these ACEs are efficient only if the next-header of the IPv6 header
points to 44. If the IPv6 packet includes other EHs and the Fragment header
is not the one which is immediately preceding the base header, then
fragmented packets won’t match the "drop-all-fragments" ACE.

Cheers,

Med

Sure, Appendix looks like the right place to add the filtering rule examples
for both IPv4 and IPv6.

-Tiru

Hi Tiru,

Thanks.

I think that we do need an example in the draft of how to do this though….

Regards

Jon

[Jon6] – Yes – I stand corrected, your ordering is correct.  A2 no longer
needs destination-port.

Cheers

-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

[TR] I don’t get it. What purpose does it serve to create a ACE rule using
“fragment” bit ?

[Jon3] Agreed – This definition has not been thought through for an ACE.  I
think they have just emulated the DF bit in RFC791 as this general flags
definition is the same as for the flags in RFC791.

[TR2] You may want to inform the authors of netmod-acl draft, surprisingly
BGP flowspec also uses “fragment” bit.

– see below.

“Flags->more” definition covers all fragments but the last fragment..
“Offset” is unfortunately not a range, but otherwise would get used for the
final fragment.

~jon2

[TR] It looks like two ACE entries are required to drop all the fragments
(“flags->more” set to 1 in the first ACE and “flags->more” set to 0 in the
second ACE). How to use the “Offset”  field for the final fragment ?

[Jon3] I read “flags-more” to refer to the IP_MF in the IP header (RFC791 MF
or more-fragments flag).  This is set for all fragments apart from the final
(as in last part of packet, not the order in which they are sent –
fortunately that early decision to send them in the wrong order was phased
out, but still there in some legacy systems!)

[TR2] Yes, why can’t “flags->more” be set to 0 as one ACE entry to drop the
final fragment along with “flags->more” set to 1 to drop the first fragment
as another ACE entry so as to drop all fragments to the target ?

[Jon4] If “flags->more” is configured and it is configured with a value of
0, this will match not only the final fragment, but also a non-fragmented
packet.  If “flags->more” is not configured, then this will match a
non-fragmented packet only.

I think it means, if “flags->more” is set to zero and offset is not zero

[Jon5].  The netmod-acl text for flags and offset is effectively a word for
word copy out of RFC791 3.1 Internet Header Format.  So I think it is meant
to be interpreted as being an exact match for the same – including the
offset specific value.

  Flags:  3 bits

    Various Control Flags.

          0   1   2

        +---+---+---+

        |   | D | M |

        | 0 | F | F |

        +---+---+---+

  Fragment Offset:  13 bits

 

----

Versus

----

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

[Jon4] So, a L4 ACE without “flags->more” defined and “allow”, followed by
an ACE with “flags->more” = 1 and “drop”, followed by an ACE with
“flags->more” = 0 and “drop” will cause all fragmented packets to get
dropped, but still allow through the non-fragmented packet.  So, we have a
solution for

“allow all traffic to port 53, but drop all fragmented packets”.

[TR3] I don’t think the above solution will work. In the above line, I think
you  meant L3 ACE, and the first fragment will match the first entry and is
allowed. 

[Jon6] – Yes – I stand corrected, your ordering is correct.  A2 no longer
needs destination-port.

~jon6

-Tiru

…

{

       "aces": [{

                                     "ace": {

                                                    "name": "a1",

                                                    "matches": [{

                                                                   "ipv4": {

                                                                   },

                                                                   "udp": {

"destination-port": 53

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "accept"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a2",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 0

},

"udp": {

"destination-port": 53

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a3",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 1

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      }

       ]

}

…

[Jon5] It will work

-Tiru

~jon4

-Tiru

[Jon3] FYI, for Juniper, you just need to set ‘first-fragment’ and
‘is-fragment’ in their ACL.  BGP FlowSpec does support fragmentation
detection properly (RFC5575 Type 12 Fragment).

-Tiru

---

From: <[email-masked]>
Date: Mon, 16 Apr 2018 12:23:27 +0000

Jon,

I'm afraid the current netmod-acl does not allow to appropriately handle IPv6 fragments (and more filtering based on Extension Header Types in general). At least, the text is not clear whether "protocol" applies for the next-header of the base header or the one of any enclosed EH.

The use of v6-fragment keyword (in the data-channel draft) solves this by performing a check whether a Fragment header is present.

          "ace": [
            {
                  "v6-fragment"
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]

This check is exactly what Cisco and Juniper are doing in the excerpts you provided.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 16 avril 2018 14:08
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] Data Channel ACL fragments

Hi Med,

As per https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html , ACL filtering does work on "fragments".

Routers can be explicitly instructed to look at and act on traffic that contains certain extension header types. This functionality is available on Cisco platforms and can be configured with the help of IPv6 Access List options:

deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [dest-option-type [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [routing-type routing-number] [sequence value] [time-range name] [undetermined-transport]

In order to permit or deny certain types of extension headers, routers are configured with the ACL features listed above to filter based on the "Header Type" value (see Table 1).

Note that in this case, the content of the EH is not processed and the router simply makes a decision based on the presence of a certain EH type. Software platforms can also analyze and filter based on additional EH fields such as the "Type Field". These filtering capabilities are very useful in implementing, for instance, security policies such as blocking source routing.
...
Since this functionality is implemented through ACLs, platforms that support hardware forwarding when ACLs are applied, will be able to handle the IPv6 traffic with EHs in hardware as well (Figure 7).

Juniper appears to support this on the MX router (see https://www.juniper.net/documentation/en_US/junos/topics/reference/general/firewall-filter-match-conditions-for-ipv6-traffic.html)

Match an extension header type that is contained in the packet by identifying a Next Header value.
Note: This match condition is only supported on MPCs in MX Series routers.

In the first fragment of a packet, the filter searches for a match in any of the extension header types. When a packet with a fragment header is found (a subsequent fragment), the filter only searches for a match of the next extension header type because the location of other extension headers is unpredictable.
In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), destination (60), esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing (43).
To match any value for the extension header option, use the text synonym any.
For MX Series routers with MPCs, initialize new firewall filters that include this condition by walking the corresponding SNMP MIB.

So, no matter where the fragment header is (even with subsequent extended headers (to me the Authenticating Header, or ESP header is the actual protocol)) before the actual protocol, matching on protocol 44 works and is map-able to Cisco/Juniper ALCs where they do not need to use the control plane - or am I missing something here?

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 16 April 2018 12:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Hi all,

{

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : samedi 14 avril 2018 06:48
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Data Channel ACL fragments

-Tiru

Hi Tiru,

Thanks.

Regards

Jon

Cheers
-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

"Flags->more" definition covers all fragments but the last fragment.. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment.
~jon2

  Flags:  3 bits

    Various Control Flags.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 16 Apr 2018 15:46:10 +0100

Hi Med,

I think that this comes down to external integration.  Whilst out of scope,
the data model communication method for transferring the ACL/ACEs between a
DOTS Server and a DOTS Mitigator cannot be using standard netmod-acl as
there is no way to define how to handle fragmentation usage in it (following
your reasoning/interpretation of netmod-acl) unless there is a separate
augmentation in that data model to include fragments definitions. 

Perhaps the right answer is to get the text in netmod-acl tightened up for
clarity between protocol and next-header (along with what is flags->
fragment really meant to do for an ACL in grouping acl-ipv4-header-fields).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 16 April 2018 13:23
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] Data Channel ACL fragments

Jon, 

I’m afraid the current netmod-acl does not allow to appropriately handle
IPv6 fragments (and more filtering based on Extension Header Types in
general). At least, the text is not clear whether “protocol” applies for the
next-header of the base header or the one of any enclosed EH. 

The use of v6-fragment keyword (in the data-channel draft) solves this by
performing a check whether a Fragment header is present. 

          "ace": [

            {

              "matches": {

                "ipv6": {

                  "v6-fragment"

                }

              },

              "actions": {

                "forwarding": "drop"

              }

            }

          ]

This check is exactly what Cisco and Juniper are doing in the excerpts you
provided. 

Cheers,

Med

Hi Med,

As per

ipv6 access-list EH-type

…

Regards

Jon

Hi all, 

{

    "acl": [

      {

        "name": "dns-fragments",

        "type": "ipv6-acl-type",

        "aces": {

          "ace": [

            {

              "matches": {

                "ipv6": {

                  "protocol": 44

                }

              },

              "actions": {

                "forwarding": "drop"

              }

            }

          ]

          "ace": [

            {

              "matches": {

                "ipv6": {

                }

                "udp": {

                  "destination-port": {

                    "operator": "eq",

                    "port": 53

                  }

                }

              },

              "actions": {

                "forwarding": "accept"

              }

            }

          ]

        }

      }

    ]

  }

}

Cheers,

Med

-Tiru

Hi Tiru,

Thanks.

Regards

Jon

Cheers

-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

 

“Flags->more” definition covers all fragments but the last fragment...
“Offset” is unfortunately not a range, but otherwise would get used for the
final fragment.

~jon2

  Flags:  3 bits

    Various Control Flags.

          0   1   2

        +---+---+---+

        |   | D | M |

        | 0 | F | F |

        +---+---+---+

  Fragment Offset:  13 bits

 

----

Versus

----

    leaf flags {

      type bits {

        bit reserved {

          position 0;

          description

        }

        bit fragment {

          position 1;

          description

        }

        bit more {

          position 2;

          description

             coming.";

        }

      }

      description

    }

    leaf offset {

      type uint16 {

        range "20..65535";

      }

      description

    }

~jon6

-Tiru

…

{

       "aces": [{

                                     "ace": {

                                                    "name": "a1",

                                                    "matches": [{

                                                                   "ipv4": {

                                                                   },

                                                                   "udp": {

"destination-port": 53

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "accept"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a2",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 0

},

"udp": {

"destination-port": 53

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      },

                      {

                                     "ace": {

                                                    "name": "a3",

                                                    "matches": [{

                                                                   "ipv4": {

"flags": {

"more": 1

}

                                                                   }

                                                    }],

                                                    "actions": {

"forwarding": "drop"

                                                    }

                                     }

                      }

       ]

}

…

[Jon5] It will work

-Tiru

~jon4

-Tiru

 

-Tiru

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 06:48:46 +0000

Hi all,

Given the clarification provided by the authors of the netmod-acl I-D, the current design for handling IPv6 fragments in the DOTS data channel specification is the appropriate way to proceed.

I consider this issue as closed.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 16 avril 2018 16:46
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] Data Channel ACL fragments

Hi Med,

I think that this comes down to external integration.  Whilst out of scope, the data model communication method for transferring the ACL/ACEs between a DOTS Server and a DOTS Mitigator cannot be using standard netmod-acl as there is no way to define how to handle fragmentation usage in it (following your reasoning/interpretation of netmod-acl) unless there is a separate augmentation in that data model to include fragments definitions.

Perhaps the right answer is to get the text in netmod-acl tightened up for clarity between protocol and next-header (along with what is flags-> fragment really meant to do for an ACL in grouping acl-ipv4-header-fields).

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 16 April 2018 13:23
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel ACL fragments

Jon,

          "ace": [
            {

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 16 avril 2018 14:08
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Data Channel ACL fragments

Hi Med,

Regards

Jon

Hi all,

{

Cheers,
Med

-Tiru

Hi Tiru,

Thanks.

Regards

Jon

Cheers
-Tiru

Hi Tiru,

See inline [Jon6]

Regards

Jon

Hi Jon,

Please see inline [TR4]

"Flags->more" definition covers all fragments but the last fragment... "Offset" is unfortunately not a range, but otherwise would get used for the final fragment.
~jon2

  Flags:  3 bits

    Various Control Flags.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

-Tiru