Skip to main content

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
RFC 8783

Document Type RFC - Proposed Standard (May 2020) Errata
Authors Mohamed Boucadair , Tirumaleswar Reddy.K
Last updated 2022-01-20
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Benjamin Kaduk
Send notices to (None)
RFC 8783
" query
   parameter set to 'non-config' to exclusively retrieve non-
   configuration data bound to a given ACL as shown in Figure 30.  A
   response to this GET request is shown in Figure 31.

     GET /restconf/data/ietf-dots-data-channel:dots-data\
         /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
         /acl=test-acl-ipv6-udp?content=non-config HTTP/1.1
     Host: example.com
     Accept: application/yang-data+json

       Figure 30: Retrieve the Non-Configuration Data for a Filtering
                             Rule (GET Request)

   {
     "ietf-dots-data-channel:acls":  {
       "acl": [
         {
           "name": "test-acl-ipv6-udp",
           "pending-lifetime": 8000,
           "aces": {
             "ace": [
               {
                 "name": "my-test-ace"
               }
             ]
           }
         }
       ]
     }
   }

       Figure 31: Retrieve the Non-Configuration Data for a Filtering
                        Rule (Response Message Body)

7.4.  Removing Filtering Rules

   A 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 a "204 No Content" status-line, and removes the
   filtering rules accordingly.

   Figure 32 shows an example of a request to remove the IPv4 ACL
   "sample-ipv4-acl" created in Section 7.2.

     DELETE  /restconf/data/ietf-dots-data-channel:dots-data\
             /dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\
             /acl=sample-ipv4-acl HTTP/1.1
     Host: example.com

            Figure 32: Remove a Filtering Rule (DELETE Request)

   Figure 33 shows an example of a response received from the DOTS
   server to confirm the deletion of "sample-ipv4-acl".

    HTTP/1.1 204 No Content
    Server: Apache
    Date: Fri, 27 Jul 2018 10:05:15 GMT
    Cache-Control: no-cache
    Content-Type: application/yang-data+json
    Content-Length: 0
    Connection: Keep-Alive

               Figure 33: Remove a Filtering Rule (Response)

8.  Operational Considerations

   The following operational considerations should be taken into
   account:

   *  DOTS servers MUST NOT enable both DOTS data channel and direct
      configuration, to avoid race conditions and inconsistent
      configurations arising from simultaneous updates from multiple
      sources.

   *  DOTS agents SHOULD enable the DOTS data channel to configure
      aliases and ACLs, and only use direct configuration as a stop-gap
      mechanism to test DOTS signal channel with aliases and ACLs.
      Further, direct configuration SHOULD only be used when the on-path
      DOTS agents are within the same domain.

   *  If a DOTS server has enabled direct configuration, it can reject
      the DOTS data channel connection using hard ICMP error [RFC1122]
      or RST (Reset) bit in the TCP header or reject the RESTCONF
      request using an error response containing a "503 Service
      Unavailable" status-line.

9.  IANA Considerations

   IANA has registered the following URI in the "ns" subregistry within
   the "IETF XML Registry" [RFC3688]:

   ID:  yang:ietf-dots-data-channel
   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.
   Reference:  RFC 8783

   IANA has registered the following YANG module in the "YANG Module
   Names" subregistry [RFC7950] within the "YANG Parameters" registry.

   Name:  ietf-dots-data-channel
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-dots-data-channel
   Prefix:  data-channel
   Reference:  RFC 8783

   This module is not maintained by IANA.

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

   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.

   The installation of drop-list or accept-list rules using RESTCONF
   over TLS reveals the attacker IP addresses and legitimate IP
   addresses only to the DOTS server trusted by the DOTS client.  The
   secure communication channel between DOTS agents provides privacy and
   prevents a network eavesdropper from directly gaining access to the
   drop-listed and accept-listed IP addresses.

   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
   Authentication Option (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.

   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 domain
   can 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 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 from 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., limiting the number of aliases and filters to be
   installed by DOTS clients) prevents DOTS server resources from being
   aggressively used by some DOTS clients and therefore ensures DDoS
   mitigation usage fairness.  Additionally, DOTS servers may limit the
   number of DOTS clients that can be enabled per domain.

   When FQDNs are used as targets, the DOTS server MUST rely upon DNS
   privacy enabling protocols (e.g., DNS over TLS [RFC7858] or DNS over
   HTTPS (DoH) [RFC8484]) to prevent eavesdroppers from possibly
   identifying the target resources protected by the DDoS mitigation
   service, and means to ensure the target FQDN resolution is authentic
   (e.g., DNSSEC [RFC4034]).

   The presence of DOTS gateways may lead to infinite forwarding loops,
   which is undesirable.  To prevent and detect such loops, a mechanism
   is defined in Section 3.4.

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  The DOTS data channel is responsible
   for exchanging configuration data that affect traffic filtering
   during DDoS attack mitigation, in particular.  Appropriate security
   measures are recommended to prevent illegitimate users from invoking
   DOTS data channel primitives on writable data nodes.  Nevertheless,
   an attacker who can access a DOTS client is technically capable of
   launching various attacks, such as:

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

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

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

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

   This module reuses YANG structures from [RFC8519], and the security
   considerations for those nodes continue to apply for this usage.

11.  References

11.1.  Normative References

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

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

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

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

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

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8519]  Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
              "YANG Data Model for Network Access Control Lists (ACLs)",
              RFC 8519, DOI 10.17487/RFC8519, March 2019,
              <https://www.rfc-editor.org/info/rfc8519>.

   [RFC8782]  Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
              Mortensen, A., and N. Teague, "Distributed Denial-of-
              Service Open Threat Signaling (DOTS) Signal Channel
              Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
              <https://www.rfc-editor.org/info/rfc8782>.

11.2.  Informative References

   [DOTS-ARCH]
              Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
              R. Compton, "Distributed-Denial-of-Service Open Threat
              Signaling (DOTS) Architecture", Work in Progress,
              Internet-Draft, draft-ietf-dots-architecture-18, 6 March
              2020, <https://tools.ietf.org/html/draft-ietf-dots-
              architecture-18>.

   [DOTS-SERVER-DISC]
              Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-
              Service Open Threat Signaling (DOTS) Agent Discovery",
              Work in Progress, Internet-Draft, draft-ietf-dots-server-
              discovery-10, 7 February 2020,
              <https://tools.ietf.org/html/draft-ietf-dots-server-
              discovery-10>.

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

   [RESTCONF-MODELS]
              Watsen, K., "RESTCONF Client and Server Models", Work in
              Progress, Internet-Draft, draft-ietf-netconf-restconf-
              client-server-19, 20 May 2020,
              <https://tools.ietf.org/html/draft-ietf-netconf-restconf-
              client-server-19>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

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

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <https://www.rfc-editor.org/info/rfc5575>.

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

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

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

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RFC8612]  Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
              Threat Signaling (DOTS) Requirements", RFC 8612,
              DOI 10.17487/RFC8612, May 2019,
              <https://www.rfc-editor.org/info/rfc8612>.

Appendix A.  Examples: Filtering Fragments

   This specification strongly recommends the use of 'fragment' for
   handling fragments.

   Figure 34 shows the content of the POST request to be 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):

   *  "drop-all-fragments" ACE: discards all fragments.

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

   POST /restconf/data/ietf-dots-data-channel:dots-data\
        /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-dots-data-channel:acls": {
       "acl": [
         {
           "name": "dns-fragments",
           "type": "ipv4-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "drop-all-fragments",
                 "matches": {
                   "ipv4": {
                     "fragment": {
                       "operator": "match",
                       "type": "isf"
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "drop"
                 }
               },
               {
                 "name": "allow-dns-packets",
                 "matches": {
                   "ipv4": {
                     "destination-ipv4-network": "198.51.100.0/24"
                   },
                   "udp": {
                     "destination-port-range-or-operator": {
                       "operator": "eq",
                       "port": 53
                     }
                   },
                   "actions": {
                     "forwarding": "accept"
                   }
                 }
               }
             ]
           }
         }
       ]
     }
   }

                Figure 34: Filtering IPv4 Fragmented Packets

   Figure 35 shows an example of a POST request 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):

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

   *  "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
   Host: example.com
   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": {
                       "operator": "match",
                       "type": "isf"
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "drop"
                 }
               },
               {
                 "name": "allow-dns-packets",
                 "matches": {
                   "ipv6": {
                     "destination-ipv6-network": "2001:db8::/32"
                   },
                   "udp": {
                     "destination-port-range-or-operator": {
                       "operator": "eq",
                       "port": 53
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "accept"
                 }
               }
             ]
           }
         }
       ]
     }
   }

                Figure 35: Filtering IPv6 Fragmented Packets

Appendix B.  Examples: Filtering TCP Messages

   This section provides examples to illustrate TCP-specific filtering
   based on the flag bits.  These examples should not be interpreted as
   recommended filtering behaviors under specific DDoS attacks.

B.1.  Discard TCP Null Attack

   Figure 36 shows an example of a DOTS request sent by a DOTS client to
   install immediately a filter to discard incoming TCP messages having
   all flags unset.  The bitmask can be set to 255 to check against the
   (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN) flags.

   PUT /restconf/data/ietf-dots-data-channel:dots-data\
       /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
       /acl=tcp-flags-example HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-dots-data-channel:acls": {
       "acl": [{
         "name": "tcp-flags-example",
         "activation-type": "immediate",
         "aces": {
           "ace": [{
             "name": "null-attack",
             "matches": {
               "tcp": {
                 "flags-bitmask": {
                   "operator": "not any",
                   "bitmask": 4095
                 }
               }
             },
             "actions": {
               "forwarding": "drop"
             }
           }]
         }
       }]
     }
   }

   Figure 36: Example of a DOTS Request to Deny TCP Null Attack Messages

B.2.  Rate-Limit SYN Flooding

   Figure 37 shows an ACL example to rate-limit incoming SYNs during a
   SYN flood attack.

   PUT /restconf/data/ietf-dots-data-channel:dots-data\
       /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
       /acl=tcp-flags-example HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-dots-data-channel:acls": {
       "acl": [{
         "name": "tcp-flags-example",
         "activation-type": "activate-when-mitigating",
         "aces": {
           "ace": [{
             "name": "rate-limit-syn",
             "matches": {
               "tcp": {
                 "flags-bitmask": {
                   "operator": "match",
                   "bitmask": 2
                 }
               }
             },
             "actions": {
               "forwarding": "accept",
               "rate-limit": "20.00"
             }
           }]
         }
       }]
     }
   }

     Figure 37: Example of DOTS Request to Rate-Limit Incoming TCP SYNs

B.3.  Rate-Limit ACK Flooding

   Figure 38 shows an ACL example to rate-limit incoming ACKs during an
   ACK flood attack.

   PUT /restconf/data/ietf-dots-data-channel:dots-data\
       /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
       /acl=tcp-flags-example HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-dots-data-channel:acls": {
       "acl": [{
         "name": "tcp-flags-example",
         "type": "ipv4-acl-type",
         "activation-type": "activate-when-mitigating",
         "aces": {
           "ace": [{
             "name": "rate-limit-ack",
             "matches": {
               "tcp": {
                 "flags-bitmask": {
                   "operator": "match",
                   "bitmask": 16
                 }
               }
             },
             "actions": {
               "forwarding": "accept",
               "rate-limit": "20.00"
             }
           }]
         }
       }]
     }
   }

     Figure 38: Example of DOTS Request to Rate-Limit Incoming TCP ACKs

Acknowledgements

   Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud
   Doron, Russ White, Gilbert Clark, Kathleen Moriarty, Nesredien
   Suleiman, Roni Even, and Brian Trammel for the discussion and
   comments.

   The authors would like to give special thanks to Kaname Nishizuka and
   Jon Shallow for their efforts in implementing the protocol and
   performing interop testing at IETF Hackathons.

   Many thanks to Benjamin Kaduk for the detailed AD review.

   Thanks to Martin Björklund for the guidance on RESTCONF.

   Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja
   Kühlewind, and Warren Kumari for the review.

Contributors

   The following people contributed substantially to the content of this
   document and should be considered coauthors:

   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

   Andrew Mortensen
   Arbor Networks, Inc.
   2727 S. State Street
   Ann Arbor, Michigan 48104
   United States of America

   Email: andrew@moretension.com

   Nik Teague
   Iron Mountain Data Centers
   United Kingdom

   Email: nteague@ironmountain.co.uk

   The following individuals have contributed to this document:

   Dan Wing

   Email: dwing-ietf@fuggles.com

   Jon Shallow
   NCC Group

   Email: jon.shallow@nccgroup.com

Authors' Addresses

   Mohamed Boucadair (editor)
   Orange
   35000 Rennes
   France

   Email: mohamed.boucadair@orange.com

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

   Email: kondtir@gmail.com