Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
draft-ietf-dots-data-channel-15

Internet-Draft         DOTS Data Channel Protocol             April 2018

   attribute", "invalid-value", or "unknown-element" as a function of
   the encountered error.

   If the request is received via a server-domain DOTS gateway, but the
   DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
   is expected to be supplied, the DOTS server MUST reply with "403
   Forbidden" status-line and the error-tag "access-denied".  Upon
   receipt of this message, the DOTS client MUST register (Section 5).

   A DOTS client uses the PUT request to modify the aliases in the DOTS
   server.  In particular, a DOTS client MUST update its alias entries
   upon change of the prefix indicated in the 'target-prefix'.

   A DOTS server MUST maintain an alias for at least 10080 minutes (1
   week).  If no refresh request is seen from the DOTS client, the DOTS
   server removes expired entries.

6.2.  Retrieve Installed Aliases

   GET request is used to retrieve one or all installed aliases by a
   DOTS client from a DOTS server (Section 3.3.1 in [RFC8040]).  If no
   'name' is included in the request, this is an indication that the
   request is about retrieving all aliases instantiated by the DOTS
   client.

   Figure 18 shows an example to retrieve all the aliases that were
   instantiated by the requesting DOTS client.  The 'content' parameter
   and its permitted values are defined in Section 4.8.1 of [RFC8040].

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw\
         /aliases?content=config HTTP/1.1
     Host: {host}:{port}
     Accept: application/yang-data+json

             Figure 18: GET to Retrieve All Installed Aliases

   Figure 19 shows an example of the response message body that includes
   all the aliases that are maintained by the DOTS server for the DOTS
   client identified by the 'cuid' parameter.

Reddy, et al.           Expires October 20, 2018               [Page 41]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   {
     "ietf-dots-data-channel:aliases": {
       "alias": [
         {
           "name": "Server1",
           "traffic-protocol": [
             6
           ],
           "target-prefix": [
             "2001:db8:6401::1/128",
             "2001:db8:6401::2/128"
           ],
           "target-port-range": [
             {
               "lower-port": 443
             }
           ],
           "pending-lifetime": 3596
         },
         {
           "name": "Server2",
           "target-protocol": [
             6
           ],
           "target-prefix": [
             "2001:db8:6401::10/128",
             "2001:db8:6401::20/128"
           ],
           "target-port-range": [
             {
               "lower-port": 80
             }
           ],
           "pending-lifetime": 9869
         }
       ]
     }
   }

                  Figure 19: An Example of Response Body

   Figure 20 shows an example of a GET request to retrieve the alias
   "Server2" that was instantiated by the DOTS client.

Reddy, et al.           Expires October 20, 2018               [Page 42]
Internet-Draft         DOTS Data Channel Protocol             April 2018

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw\
         /aliases/alias=Server2?content=config HTTP/1.1
     Host: {host}:{port}
     Accept: application/yang-data+json

                    Figure 20: GET to Retrieve an Alias

   If an alias name ('name') is included in the request, but the DOTS
   server does not find that alias name for this DOTS client in its
   configuration data, it MUST respond with a "404 Not Found" status-
   line.

6.3.  Delete Aliases

   DELETE request is used to delete an alias maintained by a DOTS
   server.

   If the DOTS server does not find the alias name, conveyed in the
   DELETE request, in its configuration data for this DOTS client, it
   MUST respond with a "404 Not Found" status-line.

   The DOTS server successfully acknowledges a DOTS client's request to
   remove the alias using "204 No Content" status-line in the response.

   Figure 21 shows an example of a request to delete an alias.

     DELETE /restconf/data/ietf-dots-data-channel:dots-data\
            /dots-client=dz6pHjaADkaFTbjr0JGBpw\
            /aliases/alias=Server1 HTTP/1.1
     Host: {host}:{port}

                        Figure 21: Delete an Alias

7.  Managing DOTS Filtering Rules

   The following sub-sections define means for a DOTS client to retrieve
   DOTS filtering capabilities (Section 7.1), create filtering rules
   (Section 7.2), retrieve active filtering rules (Section 7.3), and
   delete a filtering rule (Section 7.4).

7.1.  Retrieve DOTS Filtering Capabilities

   A DOTS client MAY send a GET request to retrieve the filtering
   capabilities supported by a DOTS server.  Figure 22 shows an example
   of such request.

Reddy, et al.           Expires October 20, 2018               [Page 43]
Internet-Draft         DOTS Data Channel Protocol             April 2018

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /capabilities HTTP/1.1
     Host: {host}:{port}
     Accept: application/yang-data+json

       Figure 22: GET to Retrieve the Capabilities of a DOTS Server

   A DOTS client which issued a GET request to retrieve the filtering
   capabilities supported by its, SHOULD NOT request for filtering
   actions that are not supported by that DOTS server.

   Figure 23 shows an example of a response received from a DOTS server
   which only supports the mandatory filtering criteria listed in
   Section 4.1.

Reddy, et al.           Expires October 20, 2018               [Page 44]
Internet-Draft         DOTS Data Channel Protocol             April 2018

    Content-Type: application/yang-data+json
    {
     "ietf-dots-data-channel:capabilities": {
       "address-family": ["ipv4", "ipv6"],
       "forwarding-actions": ["drop", "accept"],
       "rate-limit": "true",
       "fragment": ["v4-fragment", "v6-fragment"],
       "transport-protocols": [1, 6, 17, 58],
       "ipv4": {
         "length": "true",
         "protocol": "true",
         "destination-prefix": "true",
         "source-prefix": "true"
       },
       "ipv6": {
         "length": "true",
         "protocol": "true",
         "destination-prefix": "true",
         "source-prefix": "true"
       },
       "tcp": {
         "flags": "true",
         "source-port": "true",
         "destination-port": "true",
         "port-range": "true"
       },
       "udp": {
         "length": "true",
         "source-port": "true",
         "destination-port": "true",
         "port-range": "true"
       },
       "icmp": {
         "type": "true",
         "code": "true"
       }
     }
   }

      Figure 23: Reply to a GET Response with Filtering Capabilities

7.2.  Install Filtering Rules

   A POST or PUT request is used by a DOTS client to communicate
   filtering rules to a DOTS server.

Reddy, et al.           Expires October 20, 2018               [Page 45]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   Figure 24 shows a POST request example to block traffic from
   192.0.2.0/24 and destined to 198.51.100.0/24.  Other examples are
   discussed in Appendix A.

    POST /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
     "ietf-dots-data-channel:acls": {
       "acl": [
         {
           "name": "sample-ipv4-acl",
           "type": "ipv4-acl-type",
           "activation-type": "activate-when-mitigating",
           "aces": {
             "ace": [
               {
                 "name": "rule1",
                 "matches": {
                   "ipv4": {
                     "destination-ipv4-network": "198.51.100.0/24",
                     "source-ipv4-network": "192.0.2.0/24"
                   }
                 },
                 "actions": {
                   "forwarding": "drop"
                 }
               }
             ]
           }
         }
       ]
     }
    }

                Figure 24: POST to Install Filtering Rules

   The meaning of these parameters is as follows:

   name:  The name of the access list.

      This is a mandatory attribute.

   type:  Indicates the primary intended type of match criteria (e.g.,
      IPv4, IPv6).  It is set to 'ipv4-acl-type' in this example.

      This is an optional attribute.

Reddy, et al.           Expires October 20, 2018               [Page 46]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   activation-type:  Indicates whether an ACL has to be installed
      immediately or during mitigation time.  If this attribute is not
      provided, the DOTS server MUST use 'activate-when-mitigating' as
      default value.  Filters that are activated only when a mitigation
      is in progress MUST be bound to the DOTS client which created the
      filtering rule.

      This is an optional attribute.

   matches:  Define criteria used to identify a flow on which to apply
      the rule.  It can be "l3" (IPv4, IPv6) or "l4" (TCP, UDP, ..).
      The detailed match parameters are specified in Section 4.

      In this example, an IPv4 matching criteria is used.

      This is an optional attribute.

   destination-ipv4-network:  The destination IPv4 prefix.  DOTS servers
      MUST validate that these prefixes are within the scope of the DOTS
      client's domain.  Other validation checks may be supported by DOTS
      servers.  If this attribute is not provided, the DOTS server
      enforces the ACL on any destination IP address that belong to the
      DOTS client's domain.

      This is a mandatory attribute in requests with an 'activation-
      type' set to 'immediate'.

   source-ipv4-network:  The source IPv4 prefix.

      This is an optional attribute.

   actions:   Actions in the forwarding ACL category can be "drop" or
      "accept".  The "accept" action is used to white-list traffic.  The
      "drop" action is used to black-list traffic.

      Accepted traffic may be subject to "rate-limit"; the allowed
      traffic rate is represented in bytes per second indicated in IEEE
      floating point format [IEEE.754.1985].

      This is a mandatory attribute.

   The DOTS server indicates the result of processing the POST request
   using the status-line header.  Concretely, "201 Created" status-line
   MUST be returned in the response if the DOTS server has accepted the
   filtering rules.  If the request is missing a mandatory attribute or
   contains an invalid or unknown parameter (e.g., a match field not
   supported by the DOTS server), "400 Bad Request" status-line MUST be
   returned by the DOTS server in the response.  The error-tag is set to

Reddy, et al.           Expires October 20, 2018               [Page 47]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   "missing-attribute", "invalid-value", or "unknown-element" as a
   function of the encountered error.

   If the request is received via a server-domain DOTS gateway, but the
   DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
   is expected to be supplied, the DOTS server MUST reply with "403
   Forbidden" status-line and the error-tag "access-denied".  Upon
   receipt of this message, the DOTS client MUST register (Figure 11).

   If the request is conflicting with an existing filtering installed by
   another DOTS client of the domain, the DOTS server returns "409
   Conflict" status-line to the requesting DOTS client.  The error-tag
   "resource-denied" is used in this case.

   The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used
   to specify how an access control entry is inserted within an ACL and
   how an ACL is inserted within an ACL set.

   The DOTS client uses the PUT request to modify its filtering rules
   maintained by the DOTS server.  In particular, a DOTS client MUST
   update its filtering entries upon change of the destination-prefix.
   How such change is detected is out of scope.

   A DOTS server MUST maintain a filtering rule for at least 10080
   minutes (1 week).  If no refresh request is seen from the DOTS
   client, the DOTS server removes expired entries.

7.3.  Retrieve Installed Filtering Rules

   The DOTS client periodically queries the DOTS server to check the
   counters for installed filtering rules.  GET request is used to
   retrieve filtering rules from a DOTS server.

   If the DOTS server does not find the access list name conveyed in the
   GET request in its configuration data for this DOTS client, it
   responds with a "404 Not Found" status-line.

   Figure 25 shows how to retrieve all the filtering rules that were
   instantiated by the DOTS client and the number of matches for the
   installed filtering rules.

Reddy, et al.           Expires October 20, 2018               [Page 48]
Internet-Draft         DOTS Data Channel Protocol             April 2018

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw\
         /acls?content=all HTTP/1.1
     Host: {host}:{port}
     Accept: application/yang-data+json

   Figure 25: GET to Retrieve the Configuration Data and State Data for
                            the Filtering Rules

   Figure 26 shows how to retrieve "sample-ipv6-acl" filtering rule
   instantiated by the DOTS client, having
   "cuid=dz6pHjaADkaFTbjr0JGBpw", and the number of matches for the
   installed filtering rules.

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\
         /acl=sample-ipv6-acl?content=all HTTP/1.1
     Host: {host}:{port}
     Accept: application/yang-data+json

   Figure 26: GET to Retrieve the Configuration Data and State Data for
                             a Filtering Rule

7.4.  Remove Filtering Rules

   DELETE request is used by a DOTS client to delete filtering rules
   from a DOTS server.

   If the DOTS server does not find the access list name carried in the
   DELETE request in its configuration data for this DOTS client, it
   MUST respond with a "404 Not Found" status-line.  The DOTS server
   successfully acknowledges a DOTS client's request to withdraw the
   filtering rules using "204 No Content" status-line, and removes the
   filtering rules accordingly.

   Figure 27 shows an example of a request to remove the IPv4 ACL named
   "sample-ipv4-acl".

     DELETE  /restconf/data/ietf-dots-data-channel:dots-data\
             /dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\
             /acl=sample-ipv4-acl HTTP/1.1
     Host: {host}:{port}

               Figure 27: DELETE to Remove a Filtering Rule

Reddy, et al.           Expires October 20, 2018               [Page 49]
Internet-Draft         DOTS Data Channel Protocol             April 2018

8.  IANA Considerations

   This document requests IANA to register the following URI in the
   "IETF XML Registry" [RFC3688]:

            URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
            Registrant Contact: The IESG.
            XML: N/A; the requested URI is an XML namespace.

   This document requests IANA to register the following YANG module in
   the "YANG Module Names" registry [RFC7950].

           name: ietf-dots-data-channel
           namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
           prefix: data-channel
           reference: RFC XXXX

9.  Contributors

   The following individuals have contributed to this document:

   o  Dan Wing, Email: dwing-ietf@fuggles.com

   o  Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust

10.  Security Considerations

   RESTCONF security considerations are discussed in [RFC8040].  In
   particular, DOTS agents MUST follow the security recommendations in
   Sections 2 and 12 of [RFC8040].  Also, DOTS agents MUST support the
   mutual authentication TLS profile discussed in Sections 7.1 and 8 of
   [I-D.ietf-dots-signal-channel].  YANG ACL-specific security
   considerations are discussed in [I-D.ietf-netmod-acl-model].

   Authenticated encryption MUST be used for data confidentiality and
   message integrity.  The interaction between the DOTS agents requires
   Transport Layer Security (TLS) with a cipher suite offering
   confidentiality protection and the guidance given in [RFC7525] MUST
   be followed to avoid attacks on TLS.

   An attacker may be able to inject RST packets, bogus application
   segments, etc., regardless of whether TLS authentication is used.
   Because the application data is TLS protected, this will not result
   in the application receiving bogus data, but it will constitute a DoS
   on the connection.  This attack can be countered by using TCP-AO
   [RFC5925].  If TCP-AO is used, then any bogus packets injected by an
   attacker will be rejected by the TCP-AO integrity check and therefore
   will never reach the TLS layer.

Reddy, et al.           Expires October 20, 2018               [Page 50]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   In order to prevent leaking internal information outside a client-
   domain, client-side DOTS gateways SHOULD NOT reveal the identity of
   internal DOTS clients (e.g., source IP address, client's hostname)
   unless explicitly configured to do so.

   DOTS servers MUST verify that requesting DOTS clients are entitled to
   enforce filtering rules on a given IP prefix.  That is, only
   filtering rules on IP resources that belong to the DOTS client's
   domain MUST be authorized by a DOTS server.  The exact mechanism for
   the DOTS servers to validate that the target prefixes are within the
   scope of the DOTS client's domain is deployment-specific.

   Rate-limiting DOTS requests, including those with new 'cuid' values,
   from the same DOTS client defends against DoS attacks that would
   result in varying the 'cuid' to exhaust DOTS server resources.  Rate-
   limit policies SHOULD be enforced on DOTS gateways (if deployed) and
   DOTS servers.

   Applying resources quota per DOTS client and/or per DOTS client
   domain (e.g., limit the number of aliases and filters to be install
   by DOTS clients) prevents DOTS server resources to be aggressively
   used by some DOTS clients and ensures, therefore, DDoS mitigation
   usage fairness.  Additionally, DOTS servers may limit the number of
   DOTS clients that can be enabled per domain.

   All data nodes defined in the YANG module which can be created,
   modified, and deleted (i.e., config true, which is the default) are
   considered sensitive.  Write operations applied to these data nodes
   without proper protection can negatively affect network operations.
   Appropriate security measures are recommended to prevent illegitimate
   users from invoking DOTS data channel primitives.  Nevertheless, an
   attacker who can access a DOTS client is technically capable of
   launching various attacks, such as:

   o  Set an arbitrarily low rate-limit, which may prevent legitimate
      traffic from being forwarded (rate-limit).

   o  Set an arbitrarily high rate-limit, which may lead to the
      forwarding of illegitimate DDoS traffic (rate-limit).

   o  Communicate invalid aliases to the server (alias), which will
      cause the failure of associating both data and signal channels.

   o  Set invalid ACL entries, which may prevent legitimate traffic from
      being forwarded.  Likewise, invalid ACL entries may lead to
      forward DDoS traffic.

Reddy, et al.           Expires October 20, 2018               [Page 51]
Internet-Draft         DOTS Data Channel Protocol             April 2018

11.  Acknowledgements

   Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud
   Doron, Russ White, Gilbert Clark, and Nesredien Suleiman for the
   discussion and comments.

12.  References

12.1.  Normative References

   [I-D.ietf-dots-signal-channel]
              Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N.
              Teague, "Distributed Denial-of-Service Open Threat
              Signaling (DOTS) Signal Channel Specification", draft-
              ietf-dots-signal-channel-19 (work in progress), April
              2018.

   [I-D.ietf-netmod-acl-model]
              Jethanandani, M., Huang, L., Agarwal, S., and D. Blair,
              "Network Access Control List (ACL) YANG Data Model",
              draft-ietf-netmod-acl-model-18 (work in progress), March
              2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
              2006, <https://www.rfc-editor.org/info/rfc4632>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

Reddy, et al.           Expires October 20, 2018               [Page 52]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <https://www.rfc-editor.org/info/rfc7951>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

12.2.  Informative References

   [I-D.ietf-dots-architecture]
              Mortensen, A., Andreasen, F., Reddy, T.,
              christopher_gray3@cable.comcast.com, c., Compton, R., and
              N. Teague, "Distributed-Denial-of-Service Open Threat
              Signaling (DOTS) Architecture", draft-ietf-dots-
              architecture-06 (work in progress), March 2018.

   [I-D.ietf-dots-requirements]
              Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
              Denial of Service (DDoS) Open Threat Signaling
              Requirements", draft-ietf-dots-requirements-14 (work in
              progress), February 2018.

   [IEEE.754.1985]
              Institute of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic", August
              1985.

   [proto_numbers]
              "IANA, "Protocol Numbers"", 2011,
              <http://www.iana.org/assignments/protocol-numbers>.

   [RFC1983]  Malkin, G., Ed., "Internet Users' Glossary", FYI 18,
              RFC 1983, DOI 10.17487/RFC1983, August 1996,
              <https://www.rfc-editor.org/info/rfc1983>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

Reddy, et al.           Expires October 20, 2018               [Page 53]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340,
              DOI 10.17487/RFC4340, March 2006,
              <https://www.rfc-editor.org/info/rfc4340>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,
              <https://www.rfc-editor.org/info/rfc5389>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520,
              DOI 10.17487/RFC6520, February 2012,
              <https://www.rfc-editor.org/info/rfc6520>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <https://www.rfc-editor.org/info/rfc6887>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

Appendix A.  Sample Examples: Filtering Fragments

   Figure 28 shows a POST request example issued by a DOTS client to its
   DOTS server to allow the traffic destined to 198.51.100.0/24 and UDP
   port number 53, but to drop all fragmented packets.  The following
   ACEs are defined (in this order):

Reddy, et al.           Expires October 20, 2018               [Page 54]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   o  "drop-all-except-last-fragment" ACE: discards all fragments,
      except the last fragment.

   o  "allow-dns-packets" ACE: accepts DNS packets destined to
      198.51.100.0/24.

   o  "drop-last-fragment" ACE: drops the last fragment.

   The ACEs order is important to appropriately enforce the intended
   filtering policy.  For example, if the ACEs order is "allow-dns-
   packets" ACE, "drop-all-except-last-fragment" ACE, and then "drop-
   last-fragment" ACE, the first fragment won't be dropped because it
   includes both L3 and L4 information and will therefore match the
   "allow-dns-packets" ACE.

    POST /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
     "ietf-dots-data-channel:acls": {
       "acl": [
         {
           "name": "dns-fragments",
           "type": "ipv4-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "drop-all-except-last-fragment",
                 "matches": {
                   "ipv4": {
                     "flags": {
                       "more": 1
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "drop"
                 }
               }
             ]
             "ace": [
               {
                 "name": "allow-dns-packets",
                 "matches": {
                   "ipv4": {
                     "destination-ipv4-network": "198.51.100.0/24"
                   }

Reddy, et al.           Expires October 20, 2018               [Page 55]
Internet-Draft         DOTS Data Channel Protocol             April 2018

                   "udp": {
                     "destination-port": {
                       "operator": "eq",
                       "port": 53
                   }
                 },
                 "actions": {
                   "forwarding": "accept"
                 }
               }
             ]
             "ace": [
               {
                 "name": "drop-last-fragment",
                 "matches": {
                   "ipv4": {
                     "flags": {
                       "more": 0
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "drop"
                 }
               }
             ]
           }
         }
       ]
     }
    }

               Figure 28: Filtering IPv4 Fragmented Packets

   Figure 29 shows a POST request example issued by a DOTS client to its
   DOTS server to allow the traffic destined to 2001:db8::/32 and UDP
   port number 53, but to drop all fragmented packets.  The following
   ACEs are defined (in this order):

   o  "drop-all-fragments" ACE: discards all fragments (including atomic
      fragments).  That is, IPv6 packets which include a Fragment header
      (44) are dropped.

   o  "allow-dns-packets" ACE: accepts DNS packets destined to
      2001:db8::/32.

    POST /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1

Reddy, et al.           Expires October 20, 2018               [Page 56]
Internet-Draft         DOTS Data Channel Protocol             April 2018

    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
     "ietf-dots-data-channel:acls": {
       "acl": [
         {
           "name": "dns-fragments",
           "type": "ipv6-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "drop-all-fragments",
                 "matches": {
                   "ipv6": {
                     "fragment"
                   }
                 },
                 "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"
                 }
               }
             ]
           }
         }
       ]
     }
    }

               Figure 29: Filtering IPv6 Fragmented Packets

Reddy, et al.           Expires October 20, 2018               [Page 57]
Internet-Draft         DOTS Data Channel Protocol             April 2018

Authors' Addresses

   Tirumaleswar Reddy (editor)
   McAfee, Inc.
   Embassy Golf Link Business Park
   Bangalore, Karnataka  560071
   India

   Email: kondtir@gmail.com

   Mohamed Boucadair (editor)
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

   Kaname Nishizuka
   NTT Communications
   GranPark 16F 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Email: kaname@nttv6.jp

   Liang Xia
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: frank.xialiang@huawei.com

   Prashanth Patil
   Cisco Systems, Inc.

   Email: praspati@cisco.com

Reddy, et al.           Expires October 20, 2018               [Page 58]
Internet-Draft         DOTS Data Channel Protocol             April 2018

   Andrew Mortensen
   Arbor Networks, Inc.
   2727 S. State St
   Ann Arbor, MI  48104
   United States

   Email: amortensen@arbor.net

   Nik Teague
   Verisign, Inc.
   United States

   Email: nteague@verisign.com

Reddy, et al.           Expires October 20, 2018               [Page 59]