Re: [Dots] Data Channel ACL fragments

["Jon Shallow" <[e-mail]>]

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: [e-mail]] On Behalf Of
[e-mail]
Sent: 16 April 2018 13:23
To: Jon Shallow; Konda, Tirumaleswar Reddy; [e-mail]
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": [

            {

              "name": "drop-all-fragments",

              "matches": {

                "ipv6": {

                  "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:[e-mail]] 
Envoyé : lundi 16 avril 2018 14:08
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [e-mail]
Objet : RE: [Dots] Data Channel ACL fragments

 

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:[e-mail]] On Behalf Of
[e-mail]
Sent: 16 April 2018 12:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; [e-mail]
Subject: Re: [Dots] Data Channel ACL fragments

 

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:[e-mail]] 
Envoyé : samedi 14 avril 2018 06:48
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [e-mail]
Objet : RE: [Dots] Data Channel ACL fragments

 

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

 

-Tiru

 

From: Jon Shallow [mailto:[e-mail]] 
Sent: Friday, April 13, 2018 6:00 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>;
[e-mail]; [e-mail]
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

 

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

 

[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:[e-mail]] 
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>;
[e-mail]; [e-mail]
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru,

 

See inline [Jon6]

 

Regards

 

Jon

 

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

 

Hi Jon,

 

Please see inline [TR4]

 

 

From: Konda, Tirumaleswar Reddy [mailto: [e-mail]]

Sent: 10 April 2018 07:10
To: Jon Shallow; [e-mail]; [e-mail]
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.

 

[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.

 

 

“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.

 

[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

            "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";

    }

 

[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. 

 

[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).

 

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

~jon6

 

-Tiru

 

…

{

       "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

 

[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