| < draft-ietf-dots-rfc8782-bis-02.txt | draft-ietf-dots-rfc8782-bis-08.txt > | |||
|---|---|---|---|---|
| DOTS M. Boucadair, Ed. | DOTS M. Boucadair, Ed. | |||
| Internet-Draft Orange | Internet-Draft Orange | |||
| Obsoletes: 8782 (if approved) J. Shallow | Obsoletes: 8782 (if approved) J. Shallow | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: May 21, 2021 T. Reddy.K | Expires: December 5, 2021 T. Reddy.K | |||
| McAfee | McAfee | |||
| November 17, 2020 | June 3, 2021 | |||
| Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal | |||
| Channel Specification | Channel Specification | |||
| draft-ietf-dots-rfc8782-bis-02 | draft-ietf-dots-rfc8782-bis-08 | |||
| Abstract | Abstract | |||
| This document specifies the Distributed Denial-of-Service Open Threat | This document specifies the Distributed Denial-of-Service Open Threat | |||
| Signaling (DOTS) signal channel, a protocol for signaling the need | Signaling (DOTS) signal channel, a protocol for signaling the need | |||
| for protection against Distributed Denial-of-Service (DDoS) attacks | for protection against Distributed Denial-of-Service (DDoS) attacks | |||
| to a server capable of enabling network traffic mitigation on behalf | to a server capable of enabling network traffic mitigation on behalf | |||
| of the requesting client. | of the requesting client. | |||
| A companion document defines the DOTS data channel, a separate | A companion document defines the DOTS data channel, a separate | |||
| skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on May 21, 2021. | This Internet-Draft will expire on December 5, 2021. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| skipping to change at page 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.1. Backward Compatibility Considerations . . . . . . . . . . 9 | 3.1. Backward Compatibility Considerations . . . . . . . . . . 9 | |||
| 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 10 | 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 10 | |||
| 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 10 | 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 10 | |||
| 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 10 | 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 11 | |||
| 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 13 | 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 13 | |||
| 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13 | 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 14 | |||
| 4.4.2. Retrieve Information Related to a Mitigation . . . . 29 | 4.4.1.1. Building Mitigation Requests . . . . . . . . . . 14 | |||
| 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 35 | 4.4.1.2. Server-domain DOTS Gateways . . . . . . . . . . . 22 | |||
| 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37 | 4.4.1.3. Processing Mitigation Requests . . . . . . . . . 24 | |||
| 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38 | 4.4.2. Retrieve Information Related to a Mitigation . . . . 30 | |||
| 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40 | 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 36 | |||
| 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41 | 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 38 | |||
| 4.5.1. Discover Configuration Parameters . . . . . . . . . . 43 | 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 39 | |||
| 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 41 | ||||
| 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 42 | ||||
| 4.5.1. Discover Configuration Parameters . . . . . . . . . . 44 | ||||
| 4.5.2. Convey DOTS Signal Channel Session Configuration . . 48 | 4.5.2. Convey DOTS Signal Channel Session Configuration . . 48 | |||
| 4.5.3. Configuration Freshness and Notifications . . . . . . 54 | 4.5.3. Configuration Freshness and Notifications . . . . . . 54 | |||
| 4.5.4. Delete DOTS Signal Channel Session Configuration . . 55 | 4.5.4. Delete DOTS Signal Channel Session Configuration . . 55 | |||
| 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 56 | 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 56 | |||
| 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 58 | 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 58 | |||
| 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 61 | 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 61 | |||
| 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 61 | 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 61 | |||
| 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 64 | 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 64 | |||
| 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 68 | 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 68 | |||
| 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 81 | 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 81 | |||
| 7. (D)TLS Protocol Profile and Performance Considerations . . . 84 | 7. (D)TLS Protocol Profile and Performance Considerations . . . 85 | |||
| 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 84 | 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 85 | |||
| 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 86 | 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 87 | |||
| 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 88 | 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 89 | |||
| 8. Mutual Authentication of DOTS Agents & Authorization of DOTS | 8. Mutual Authentication of DOTS Agents & Authorization of DOTS | |||
| Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 | Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 | |||
| 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 91 | 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 91 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 | |||
| 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 92 | 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 92 | |||
| 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 93 | 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 93 | |||
| 10.3. Media Type Registration . . . . . . . . . . . . . . . . 93 | 10.3. Media Type Registration . . . . . . . . . . . . . . . . 93 | |||
| 10.4. CoAP Content-Formats Registration . . . . . . . . . . . 94 | 10.4. CoAP Content-Formats Registration . . . . . . . . . . . 94 | |||
| 10.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . 95 | 10.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . 95 | |||
| 10.6. DOTS Signal Channel Protocol Registry . . . . . . . . . 95 | 10.6. DOTS Signal Channel Protocol Registry . . . . . . . . . 95 | |||
| 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry . . 95 | 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry . . 95 | |||
| 10.6.1.1. Registration Template . . . . . . . . . . . . . 95 | 10.6.1.1. Registration Template . . . . . . . . . . . . . 95 | |||
| 10.6.1.2. Update Subregistry Content . . . . . . . . . . . 97 | 10.6.1.2. Update Subregistry Content . . . . . . . . . . . 97 | |||
| 10.6.2. Status Codes Subregistry . . . . . . . . . . . . . . 100 | 10.6.2. Status Codes Subregistry . . . . . . . . . . . . . . 97 | |||
| 10.6.3. Conflict Status Codes Subregistry . . . . . . . . . 101 | 10.6.3. Conflict Status Codes Subregistry . . . . . . . . . 99 | |||
| 10.6.4. Conflict Cause Codes Subregistry . . . . . . . . . . 102 | 10.6.4. Conflict Cause Codes Subregistry . . . . . . . . . . 100 | |||
| 10.6.5. Attack Status Codes Subregistry . . . . . . . . . . 103 | 10.6.5. Attack Status Codes Subregistry . . . . . . . . . . 101 | |||
| 10.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 104 | 10.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 102 | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 106 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 104 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 108 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 106 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 111 | 12.2. Informative References . . . . . . . . . . . . . . . . . 109 | |||
| Appendix A. Summary of Changes From RFC8782 . . . . . . . . . . 116 | Appendix A. Summary of Changes From RFC8782 . . . . . . . . . . 114 | |||
| Appendix B. CUID Generation . . . . . . . . . . . . . . . . . . 117 | Appendix B. CUID Generation . . . . . . . . . . . . . . . . . . 115 | |||
| Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 117 | Appendix C. Summary of Protocol Recommended/Default Values . . . 115 | |||
| C.1. Acknowledgements from RFC8782 . . . . . . . . . . . . . . 117 | Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 116 | |||
| Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 118 | D.1. Acknowledgements from RFC8782 . . . . . . . . . . . . . . 116 | |||
| D.1. Authors of RFC8782 . . . . . . . . . . . . . . . . . . . 118 | Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 116 | |||
| D.2. Contributors to RFC8782 . . . . . . . . . . . . . . . . . 119 | E.1. Authors of RFC8782 . . . . . . . . . . . . . . . . . . . 116 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 | E.2. Contributors to RFC8782 . . . . . . . . . . . . . . . . . 117 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118 | ||||
| 1. Introduction | 1. Introduction | |||
| A Distributed Denial-of-Service (DDoS) attack is a distributed | A Distributed Denial-of-Service (DDoS) attack is a distributed | |||
| attempt to make machines or network resources unavailable to their | attempt to make machines or network resources unavailable to their | |||
| intended users. In most cases, sufficient scale for an effective | intended users. In most cases, sufficient scale for an effective | |||
| attack can be achieved by compromising enough end hosts and using | attack can be achieved by compromising enough end hosts and using | |||
| those infected hosts to perpetrate and amplify the attack. The | those infected hosts to perpetrate and amplify the attack. The | |||
| victim in this attack can be an application server, a host, a router, | victim in this attack can be an application server, a host, a router, | |||
| a firewall, or an entire network. | a firewall, or an entire network. | |||
| skipping to change at page 4, line 30 ¶ | skipping to change at page 4, line 33 ¶ | |||
| determine the cause(s) of an attack. They may instead just realize | determine the cause(s) of an attack. They may instead just realize | |||
| that certain resources seem to be under attack. This document | that certain resources seem to be under attack. This document | |||
| defines a lightweight protocol that allows a DOTS client to request | defines a lightweight protocol that allows a DOTS client to request | |||
| mitigation from one or more DOTS servers for protection against | mitigation from one or more DOTS servers for protection against | |||
| detected, suspected, or anticipated attacks. This protocol enables | detected, suspected, or anticipated attacks. This protocol enables | |||
| cooperation between DOTS agents to permit a highly automated network | cooperation between DOTS agents to permit a highly automated network | |||
| defense that is robust, reliable, and secure. Note that "secure" | defense that is robust, reliable, and secure. Note that "secure" | |||
| means the support of the features defined in Section 2.4 of | means the support of the features defined in Section 2.4 of | |||
| [RFC8612]. | [RFC8612]. | |||
| In typical deployments, the DOTS client belongs to a different | ||||
| administrative domain than the DOTS server. For example, the DOTS | ||||
| client is embedded in a firewall protected services owned and | ||||
| operated by a customer, while the DOTS server is owned and operated | ||||
| by a different administrative entity (service provider, typically) | ||||
| providing DDoS mitigation services. The latter might or might not | ||||
| provide connectivity services to the network hosting the DOTS client. | ||||
| The DOTS server may or may not be co-located with the DOTS mitigator. | ||||
| In typical deployments, the DOTS server belongs to the same | ||||
| administrative domain as the mitigator. The DOTS client can | ||||
| communicate directly with a DOTS server or indirectly via a DOTS | ||||
| gateway. | ||||
| An example of a network diagram that illustrates a deployment of DOTS | An example of a network diagram that illustrates a deployment of DOTS | |||
| agents is shown in Figure 1. In this example, a DOTS server is | agents is shown in Figure 1. In this example, a DOTS server is | |||
| operating on the access network. A DOTS client is located on the LAN | operating on the access network. A DOTS client is located on the LAN | |||
| (Local Area Network), while a DOTS gateway is embedded in the CPE | (Local Area Network), while a DOTS gateway is embedded in the CPE | |||
| (Customer Premises Equipment). | (Customer Premises Equipment). | |||
| Network | Network | |||
| Resource CPE Router Access Network __________ | Resource CPE Router Access Network __________ | |||
| +-----------+ +--------------+ +-------------+ / \ | +-------------+ +--------------+ +-------------+ / \ | |||
| | |___| |____| |___ | Internet | | | | | | | | | Internet | | |||
| |DOTS Client| | DOTS Gateway | | DOTS Server | | | | | DOTS Client +---+ DOTS Gateway +---+ DOTS Server +----+ | | |||
| | | | | | | | | | | | | | | | | | | |||
| +-----------+ +--------------+ +-------------+ \__________/ | +-------------+ +--------------+ +-------------+ \__________/ | |||
| Figure 1: Sample DOTS Deployment (1) | Figure 1: Sample DOTS Deployment (1) | |||
| DOTS servers can also be reachable over the Internet, as depicted in | DOTS servers can also be reachable over the Internet, as depicted in | |||
| Figure 2. | Figure 2. | |||
| Network DDoS Mitigation | Network DDoS Mitigation | |||
| Resource CPE Router __________ Service | Resource CPE Router _________ Service | |||
| +-----------+ +--------------+ / \ +-------------+ | +-------------+ +--------------+ / \ +-------------+ | |||
| | |___| |____| |___ | | | | | | | | | | | | |||
| |DOTS Client| | DOTS Gateway | | Internet | | DOTS Server | | | DOTS Client +---+ DOTS Gateway +---+ Internet +---+ DOTS Server | | |||
| | | | | | | | | | | | | | | | | | | |||
| +-----------+ +--------------+ \__________/ +-------------+ | +-------------+ +--------------+ \_________/ +-------------+ | |||
| Figure 2: Sample DOTS Deployment (2) | Figure 2: Sample DOTS Deployment (2) | |||
| In typical deployments, the DOTS client belongs to a different | ||||
| administrative domain than the DOTS server. For example, the DOTS | ||||
| client is embedded in a firewall protecting services owned and | ||||
| operated by a customer, while the DOTS server is owned and operated | ||||
| by a different administrative entity (service provider, typically) | ||||
| providing DDoS mitigation services. The latter might or might not | ||||
| provide connectivity services to the network hosting the DOTS client. | ||||
| The DOTS server may (not) be co-located with the DOTS mitigator. In | ||||
| typical deployments, the DOTS server belongs to the same | ||||
| administrative domain as the mitigator. The DOTS client can | ||||
| communicate directly with a DOTS server or indirectly via a DOTS | ||||
| gateway. | ||||
| This document adheres to the DOTS architecture [RFC8811]. The | This document adheres to the DOTS architecture [RFC8811]. The | |||
| requirements for DOTS signal channel protocol are documented in | requirements for DOTS signal channel protocol are documented in | |||
| [RFC8612]. This document satisfies all the use cases discussed in | [RFC8612]. This document satisfies all the use cases discussed in | |||
| [I-D.ietf-dots-use-cases]. | [RFC8903]. | |||
| This document focuses on the DOTS signal channel. This is a | This document focuses on the DOTS signal channel. This is a | |||
| companion document of the DOTS data channel specification [RFC8783] | companion document of the DOTS data channel specification [RFC8783] | |||
| that defines a configuration and a bulk data exchange mechanism | that defines a configuration and a bulk data exchange mechanism | |||
| supporting the DOTS signal channel. | supporting the DOTS signal channel. | |||
| Backward compatibility (including upgrade) considerations are | Backward compatibility (including upgrade) considerations are | |||
| discussed in Section 3.1. | discussed in Section 3.1. | |||
| 2. Terminology | 2. Terminology | |||
| skipping to change at page 6, line 4 ¶ | skipping to change at page 5, line 51 ¶ | |||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119][RFC8174] when, and only when, they appear in all | 14 [RFC2119][RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| (D)TLS is used for statements that apply to both Transport Layer | (D)TLS is used for statements that apply to both Transport Layer | |||
| Security [RFC5246] [RFC8446] and Datagram Transport Layer Security | Security [RFC5246] [RFC8446] and Datagram Transport Layer Security | |||
| [RFC6347]. Specific terms are used for any statement that applies to | [RFC6347]. Specific terms are used for any statement that applies to | |||
| either protocol alone. | either protocol alone. | |||
| The reader should be familiar with the terms defined in [RFC8612]. | The reader should be familiar with the terms defined in [RFC8612] and | |||
| [RFC7252]. | ||||
| The meaning of the symbols in YANG tree diagrams are defined in | The meaning of the symbols in YANG tree diagrams are defined in | |||
| [RFC8340] and [RFC8791]. | [RFC8340] and [RFC8791]. | |||
| 3. Design Overview | 3. Design Overview | |||
| The DOTS signal channel is built on top of the Constrained | The DOTS signal channel is built on top of the Constrained | |||
| Application Protocol (CoAP) [RFC7252], a lightweight protocol | Application Protocol (CoAP) [RFC7252], a lightweight protocol | |||
| originally designed for constrained devices and networks. The many | originally designed for constrained devices and networks. The many | |||
| features of CoAP (expectation of packet loss, support for | features of CoAP (expectation of packet loss, support for | |||
| asynchronous Non-confirmable messaging, congestion control, small | asynchronous Non-confirmable messaging, congestion control, small | |||
| message overhead limiting the need for fragmentation, use of minimal | message overhead limiting the need for fragmentation, use of minimal | |||
| resources, and support for (D)TLS) make it a good candidate upon | resources, and support for (D)TLS) make it a good candidate upon | |||
| which to build the DOTS signaling mechanism. | which to build the DOTS signaling mechanism. | |||
| DOTS clients and servers behave as CoAP endpoints. By default, a | DOTS clients and servers behave as CoAP endpoints. By default, a | |||
| DOTS client (or server) behaves as a CoAP client (or server). | DOTS client behaves as a CoAP client and a DOTS server behaves as | |||
| Nevertheless, a DOTS client (or server) behaves as a CoAP server (or | CoAP server. Nevertheless, a DOTS client (or server) behaves as a | |||
| client) for specific operations such as DOTS heartbeat operations | CoAP server (or client) for specific operations such as DOTS | |||
| (Section 4.7). | heartbeat operations (Section 4.7). | |||
| The DOTS signal channel is layered on existing standards (see | The DOTS signal channel is layered on existing standards (see | |||
| Figure 3). | Figure 3). | |||
| +---------------------+ | +---------------------+ | |||
| | DOTS Signal Channel | | | DOTS Signal Channel | | |||
| +---------------------+ | +---------------------+ | |||
| | CoAP | | | CoAP | | |||
| +----------+----------+ | +----------+----------+ | |||
| | TLS | DTLS | | | TLS | DTLS | | |||
| skipping to change at page 6, line 50 ¶ | skipping to change at page 6, line 48 ¶ | |||
| | TCP | UDP | | | TCP | UDP | | |||
| +----------+----------+ | +----------+----------+ | |||
| | IP | | | IP | | |||
| +---------------------+ | +---------------------+ | |||
| Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over | Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over | |||
| (D)TLS | (D)TLS | |||
| In some cases, a DOTS client and server may have a mutual agreement | In some cases, a DOTS client and server may have a mutual agreement | |||
| to use a specific port number, such as by explicit configuration or | to use a specific port number, such as by explicit configuration or | |||
| dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such | dynamic discovery [RFC8973]. Absent such mutual agreement, the DOTS | |||
| mutual agreement, the DOTS signal channel MUST run over port number | signal channel MUST run over port number 4646 as defined in | |||
| 4646 as defined in Section 10.1, for both UDP and TCP. In order to | Section 10.1, for both UDP and TCP (that is, the DOTS server listens | |||
| use a distinct port number (as opposed to 4646), DOTS clients and | on port number 4646). In order to use a distinct port number (as | |||
| servers SHOULD support a configurable parameter to supply the port | opposed to 4646), DOTS clients and servers SHOULD support a | |||
| number to use. | configurable parameter to supply the port number to use. | |||
| | Note: The rationale for not using the default port number 5684 | | Note: The rationale for not using the default port number 5684 | |||
| | ((D)TLS CoAP) is to avoid the discovery of services and | | ((D)TLS CoAP) is to avoid the discovery of services and | |||
| | resources discussed in [RFC7252] and allow for differentiated | | resources discussed in [RFC7252] and allow for differentiated | |||
| | behaviors in environments where both a DOTS gateway and an | | behaviors in environments where both a DOTS gateway and an | |||
| | Internet of Things (IoT) gateway (e.g., Figure 3 of [RFC7452]) | | Internet of Things (IoT) gateway (e.g., Figure 3 of [RFC7452]) | |||
| | are co-located. | | are co-located. | |||
| | | | | |||
| | Particularly, the use of a default port number is meant to | | Particularly, the use of a default port number is meant to | |||
| | simplify DOTS deployment in scenarios where no explicit IP | | simplify DOTS deployment in scenarios where no explicit IP | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
| request message (Section 4.4) to a DOTS server over the active signal | request message (Section 4.4) to a DOTS server over the active signal | |||
| channel. While mitigation is active (because of the higher | channel. While mitigation is active (because of the higher | |||
| likelihood of packet loss during a DDoS attack), the DOTS server | likelihood of packet loss during a DDoS attack), the DOTS server | |||
| periodically sends status messages to the client, including basic | periodically sends status messages to the client, including basic | |||
| mitigation feedback details. Mitigation remains active until the | mitigation feedback details. Mitigation remains active until the | |||
| DOTS client explicitly terminates mitigation or the mitigation | DOTS client explicitly terminates mitigation or the mitigation | |||
| lifetime expires. Also, the DOTS server may rely on the signal | lifetime expires. Also, the DOTS server may rely on the signal | |||
| channel session loss to trigger mitigation for preconfigured | channel session loss to trigger mitigation for preconfigured | |||
| mitigation requests (if any). | mitigation requests (if any). | |||
| DOTS signaling can happen with DTLS over UDP and TLS over TCP. | DOTS signaling can use DTLS over UDP and TLS over TCP. Likewise, | |||
| Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer | DOTS requests may be sent using IPv4 or IPv6 transfer capabilities. | |||
| capabilities. A Happy Eyeballs procedure for the DOTS signal channel | A Happy Eyeballs procedure for the DOTS signal channel is specified | |||
| is specified in Section 4.3. | in Section 4.3. | |||
| A DOTS client is entitled to access only the resources it creates. | A DOTS client is entitled to access only the resources it creates. | |||
| In particular, a DOTS client cannot retrieve data related to | In particular, a DOTS client cannot retrieve data related to | |||
| mitigation requests created by other DOTS clients of the same DOTS | mitigation requests created by other DOTS clients of the same DOTS | |||
| client domain. | client domain. | |||
| Messages exchanged between DOTS agents are serialized using Concise | Messages exchanged between DOTS agents are serialized using Concise | |||
| Binary Object Representation (CBOR) [RFC7049], a binary encoding | Binary Object Representation (CBOR) [RFC8949], a binary encoding | |||
| scheme designed for small code and message size. CBOR-encoded | scheme designed for small code and message size. CBOR-encoded | |||
| payloads are used to carry signal channel-specific payload messages | payloads are used to carry signal channel-specific payload messages | |||
| that convey request parameters and response information such as | that convey request parameters and response information such as | |||
| errors. In order to allow the reusing of data models across | errors. In order to allow the reusing of data models across | |||
| protocols, [RFC7951] specifies the JavaScript Object Notation (JSON) | protocols, [RFC7951] specifies the JavaScript Object Notation (JSON) | |||
| encoding of YANG-modeled data. A similar effort for CBOR is defined | encoding of YANG-modeled data. A similar effort for CBOR is defined | |||
| in [I-D.ietf-core-yang-cbor]. | in [I-D.ietf-core-yang-cbor]. | |||
| DOTS agents determine that a CBOR data structure is a DOTS signal | DOTS agents determine that a CBOR data structure is a DOTS signal | |||
| channel object from the application context, such as from the port | channel object from the application context, such as from the port | |||
| skipping to change at page 8, line 49 ¶ | skipping to change at page 8, line 49 ¶ | |||
| recommendations documented in Section 4.6 of [RFC7252]. Refer to | recommendations documented in Section 4.6 of [RFC7252]. Refer to | |||
| Section 7.3 for more details. | Section 7.3 for more details. | |||
| DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The | DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The | |||
| payload included in CoAP responses with 2.xx Response Codes MUST be | payload included in CoAP responses with 2.xx Response Codes MUST be | |||
| of content type "application/dots+cbor". CoAP responses with 4.xx | of content type "application/dots+cbor". CoAP responses with 4.xx | |||
| and 5.xx error Response Codes MUST include a diagnostic payload | and 5.xx error Response Codes MUST include a diagnostic payload | |||
| (Section 5.5.2 of [RFC7252]). The diagnostic payload may contain | (Section 5.5.2 of [RFC7252]). The diagnostic payload may contain | |||
| additional information to aid troubleshooting. | additional information to aid troubleshooting. | |||
| In deployments where multiple DOTS clients are enabled in a network | In deployments where multiple DOTS clients are enabled in a single | |||
| (owned and operated by the same entity), the DOTS server may detect | network and administrative domain (called, DOTS client domain), the | |||
| conflicting mitigation requests from these clients. This document | DOTS server may detect conflicting mitigation requests from these | |||
| does not aim to specify a comprehensive list of conditions under | clients. This document does not aim to specify a comprehensive list | |||
| which a DOTS server will characterize two mitigation requests from | of conditions under which a DOTS server will characterize two | |||
| distinct DOTS clients as conflicting, nor does it recommend a DOTS | mitigation requests from distinct DOTS clients as conflicting, nor | |||
| server behavior for processing conflicting mitigation requests. | does it recommend a DOTS server behavior for processing conflicting | |||
| Those considerations are implementation and deployment specific. | mitigation requests. Those considerations are implementation and | |||
| Nevertheless, this document specifies the mechanisms to notify DOTS | deployment specific. Nevertheless, this document specifies the | |||
| clients when conflicts occur, including the conflict cause | mechanisms to notify DOTS clients when conflicts occur, including the | |||
| (Section 4.4). | conflict cause (Section 4.4). | |||
| In deployments where one or more translators (e.g., Traditional NAT | In deployments where one or more translators (e.g., Traditional NAT | |||
| [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are | [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are | |||
| enabled between the client's network and the DOTS server, any DOTS | enabled between the client's network and the DOTS server, any DOTS | |||
| signal channel messages forwarded to a DOTS server MUST NOT include | signal channel messages forwarded to a DOTS server MUST NOT include | |||
| internal IP addresses/prefixes and/or port numbers; instead, external | internal IP addresses/prefixes and/or port numbers; instead, external | |||
| addresses/prefixes and/or port numbers as assigned by the translator | addresses/prefixes and/or port numbers as assigned by the translator | |||
| MUST be used. This document does not make any recommendations about | MUST be used. This document does not make any recommendations about | |||
| possible translator discovery mechanisms. The following are some | possible translator discovery mechanisms. The following are some | |||
| (non-exhaustive) deployment examples that may be considered: | (non-exhaustive) deployment examples that may be considered: | |||
| o Port Control Protocol (PCP) [RFC6887] or Session Traversal | o Port Control Protocol (PCP) [RFC6887] or Session Traversal | |||
| Utilities for NAT (STUN) [RFC8489] may be used to retrieve the | Utilities for NAT (STUN) [RFC8489] may be used by the client to | |||
| external addresses/prefixes and/or port numbers. Information | retrieve the external addresses/prefixes and/or port numbers. | |||
| retrieved by means of PCP or STUN will be used to feed the DOTS | Information retrieved by means of PCP or STUN will be used to feed | |||
| signal channel messages that will be sent to a DOTS server. | the DOTS signal channel messages that will be sent to a DOTS | |||
| server. | ||||
| o A DOTS gateway may be co-located with the translator. The DOTS | o A DOTS gateway may be co-located with the translator. The DOTS | |||
| gateway will need to update the DOTS messages based upon the local | gateway will need to update the DOTS messages based upon the local | |||
| translator's binding table. | translator's binding table. | |||
| 3.1. Backward Compatibility Considerations | 3.1. Backward Compatibility Considerations | |||
| The main changes to [RFC8782] are listed in Appendix A. These | The main changes to [RFC8782] are listed in Appendix A. These | |||
| modifications are made with the constraint to avoid changes to the | modifications are made with the constraint to avoid changes to the | |||
| mapping table defined in Table 5 of [RFC8782] (see also Section 6). | mapping table defined in Table 5 of [RFC8782] (see also Section 6 of | |||
| For both legacy and implementations that follow the present | the present document). | |||
| For both legacy [RFC8782] and implementations that follow the present | ||||
| specification, a DOTS signal channel attribute will thus have the | specification, a DOTS signal channel attribute will thus have the | |||
| same CBOR key value and CBOR major type. The only upgrade that is | same CBOR key value and CBOR major type. The only upgrade that is | |||
| required to [RFC8782] implementations is to handle the CBOR key value | required to [RFC8782] implementations is to handle the CBOR key value | |||
| range "128-255" as comprehension-optional instead of comprehension- | range "128-255" as comprehension-optional instead of comprehension- | |||
| required. Note that this range is anticipated to be used by the DOTS | required. Note that this range is anticipated to be used by the DOTS | |||
| telemetry [I-D.ietf-dots-telemetry] in which the following means are | telemetry [I-D.ietf-dots-telemetry] in which the following means are | |||
| supported to avoid that a DOTS signal channel message enriched with | used to prevent message processing failure of a DOTS signal channel | |||
| telemetry data will exacerbate message failure: (1) DOTS agents use | message enriched with telemetry data: (1) DOTS agents use dedicated | |||
| dedicated (new) path suffixes (Section 5 of | (new) path suffixes (Section 5 of [I-D.ietf-dots-telemetry]) and (2) | |||
| [I-D.ietf-dots-telemetry]) and (2) a DOTS server won't include | a DOTS server won't include telemetry attributes in its responses | |||
| telemetry attributes in its responses unless it is explicitly told to | unless it is explicitly told to do so by a DOTS client (Section 6.1.2 | |||
| do so by a DOTS client (Section 6.1.2 of [I-D.ietf-dots-telemetry]). | of [I-D.ietf-dots-telemetry]). | |||
| Future DOTS extensions that request a CBOR value in the range | Future DOTS extensions that request a CBOR value in the range | |||
| "128-255" must support means similar to the aforementioned DOTS | "128-255" MUST support means similar to the aforementioned DOTS | |||
| telemetry ones. | telemetry ones. | |||
| 4. DOTS Signal Channel: Messages & Behaviors | 4. DOTS Signal Channel: Messages & Behaviors | |||
| 4.1. DOTS Server(s) Discovery | 4.1. DOTS Server(s) Discovery | |||
| This document assumes that DOTS clients are provisioned with the | This document assumes that DOTS clients are provisioned with the | |||
| reachability information of their DOTS server(s) using any of a | reachability information of their DOTS server(s) using any of a | |||
| variety of means (e.g., local configuration or dynamic means such as | variety of means (e.g., local configuration or dynamic means such as | |||
| DHCP [I-D.ietf-dots-server-discovery]). The description of such | DHCP [RFC8973]). The description of such means is out of scope of | |||
| means is out of scope of this document. | this document. | |||
| Likewise, it is out of the scope of this document to specify the | Likewise, it is out of the scope of this document to specify the | |||
| behavior to be followed by a DOTS client in order to send DOTS | behavior to be followed by a DOTS client in order to send DOTS | |||
| requests when multiple DOTS servers are provisioned (e.g., contact | requests when multiple DOTS servers are provisioned (e.g., contact | |||
| all DOTS servers, select one DOTS server among the list). Such | all DOTS servers, select one DOTS server among the list). Such | |||
| behavior is specified in other documents (e.g., | behavior is specified in other documents (e.g., | |||
| [I-D.ietf-dots-multihoming]). | [I-D.ietf-dots-multihoming]). | |||
| 4.2. CoAP URIs | 4.2. CoAP URIs | |||
| skipping to change at page 13, line 15 ¶ | skipping to change at page 13, line 19 ¶ | |||
| 4.4. DOTS Mitigation Methods | 4.4. DOTS Mitigation Methods | |||
| The following methods are used by a DOTS client to request, withdraw, | The following methods are used by a DOTS client to request, withdraw, | |||
| or retrieve the status of mitigation requests: | or retrieve the status of mitigation requests: | |||
| PUT: DOTS clients use the PUT method to request mitigation from a | PUT: DOTS clients use the PUT method to request mitigation from a | |||
| DOTS server (Section 4.4.1). During active mitigation, DOTS | DOTS server (Section 4.4.1). During active mitigation, DOTS | |||
| clients may use PUT requests to carry mitigation efficacy | clients may use PUT requests to carry mitigation efficacy | |||
| updates to the DOTS server (Section 4.4.3). | updates to the DOTS server (Section 4.4.3). | |||
| GET: DOTS clients may use the GET method to subscribe to DOTS | GET: DOTS clients may use the GET method to retrieve the list of | |||
| server status messages or to retrieve the list of its | its mitigations maintained by a DOTS server (Section 4.4.2) | |||
| mitigations maintained by a DOTS server (Section 4.4.2). | or to receive asynchronous DOTS server status messages | |||
| (Section 4.4.2.1). | ||||
| DELETE: DOTS clients use the DELETE method to withdraw a request for | DELETE: DOTS clients use the DELETE method to withdraw a request for | |||
| mitigation from a DOTS server (Section 4.4.4). | mitigation from a DOTS server (Section 4.4.4). | |||
| Mitigation request and response messages are marked as Non- | Mitigation request and response messages are marked as Non- | |||
| confirmable messages (Section 2.2 of [RFC7252]). | confirmable messages (Section 2.2 of [RFC7252]). | |||
| DOTS agents MUST NOT send more than one UDP datagram per round-trip | DOTS agents MUST NOT send more than one UDP datagram per round-trip | |||
| time (RTT) to the peer DOTS agent on average following the data | time (RTT) to the peer DOTS agent on average following the data | |||
| transmission guidelines discussed in Section 3.1.3 of [RFC8085]. | transmission guidelines discussed in Section 3.1.3 of [RFC8085]. | |||
| skipping to change at page 13, line 42 ¶ | skipping to change at page 13, line 47 ¶ | |||
| NOT send more than one Non-confirmable request every 3 seconds, and | NOT send more than one Non-confirmable request every 3 seconds, and | |||
| SHOULD use an even less aggressive rate whenever possible (case 2 in | SHOULD use an even less aggressive rate whenever possible (case 2 in | |||
| Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed | Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed | |||
| because of checks on probing rate (Section 4.7 of [RFC7252]). | because of checks on probing rate (Section 4.7 of [RFC7252]). | |||
| JSON encoding of YANG modeled data [RFC7951] is used to illustrate | JSON encoding of YANG modeled data [RFC7951] is used to illustrate | |||
| the various methods defined in the following subsections. Also, the | the various methods defined in the following subsections. Also, the | |||
| examples use the Labels defined in Sections 10.6.2, 10.6.3, 10.6.4, | examples use the Labels defined in Sections 10.6.2, 10.6.3, 10.6.4, | |||
| and 10.6.5. | and 10.6.5. | |||
| The DOTS client MUST authenticate itself to the DOTS server | ||||
| (Section 8). The DOTS server MAY use the algorithm presented in | ||||
| Section 7 of [RFC7589] to derive the DOTS client identity or username | ||||
| from the client certificate. The DOTS client identity allows the | ||||
| DOTS server to accept mitigation requests with scopes that the DOTS | ||||
| client is authorized to manage. | ||||
| 4.4.1. Request Mitigation | 4.4.1. Request Mitigation | |||
| 4.4.1.1. Building Mitigation Requests | ||||
| When a DOTS client requires mitigation for some reason, the DOTS | When a DOTS client requires mitigation for some reason, the DOTS | |||
| client uses the CoAP PUT method to send a mitigation request to its | client uses the CoAP PUT method to send a mitigation request to its | |||
| DOTS server(s) (Figures 5 and 6). | DOTS server(s) (Figures 5 and 6). | |||
| If a DOTS client is entitled to solicit the DOTS service, the DOTS | If a DOTS client is entitled to solicit the DOTS service, the DOTS | |||
| server enables mitigation on behalf of the DOTS client by | server enables mitigation on behalf of the DOTS client by | |||
| communicating the DOTS client's request to a mitigator (which may be | communicating the DOTS client's request to a mitigator (which may be | |||
| co-located with the DOTS server) and relaying the feedback of the | co-located with the DOTS server) and relaying the feedback of the | |||
| thus-selected mitigator to the requesting DOTS client. | thus-selected mitigator to the requesting DOTS client. | |||
| skipping to change at page 14, line 30 ¶ | skipping to change at page 14, line 44 ¶ | |||
| resource. In particular, 'mid' MUST follow 'cuid'. | resource. In particular, 'mid' MUST follow 'cuid'. | |||
| The additional Uri-Path parameters to those defined in Section 4.2 | The additional Uri-Path parameters to those defined in Section 4.2 | |||
| are as follows: | are as follows: | |||
| cuid: Stands for Client Unique Identifier. A globally unique | cuid: Stands for Client Unique Identifier. A globally unique | |||
| identifier that is meant to prevent collisions among DOTS | identifier that is meant to prevent collisions among DOTS | |||
| clients, especially those from the same domain. It MUST be | clients, especially those from the same domain. It MUST be | |||
| generated by DOTS clients. | generated by DOTS clients. | |||
| For the reasons discussed in Appendix A, implementations SHOULD | For the reasons discussed in Appendix B, implementations SHOULD | |||
| set 'cuid' using the following procedure: first, the DOTS | set 'cuid' using the following procedure: first, the DOTS | |||
| client inputs one of the following into the SHA-256 [RFC6234] | client inputs one of the following into the SHA-256 [RFC6234] | |||
| cryptographic hash: the DER-encoded ASN.1 representation of the | cryptographic hash: the DER-encoded ASN.1 representation of the | |||
| Subject Public Key Info (SPKI) of its X.509 certificate | Subject Public Key Info (SPKI) of its X.509 certificate | |||
| [RFC5280], its raw public key [RFC7250], the "Pre-Shared Key | [RFC5280], its raw public key [RFC7250], the "Pre-Shared Key | |||
| (PSK) identity" it uses in the TLS 1.2 ClientKeyExchange | (PSK) identity" it uses in the TLS 1.2 ClientKeyExchange | |||
| message, or the "identity" it uses in the "pre_shared_key" TLS | message, or the "identity" it uses in the "pre_shared_key" TLS | |||
| 1.3 extension. Then, the output of the cryptographic hash | 1.3 extension. Then, the output of the cryptographic hash | |||
| algorithm is truncated to 16 bytes; truncation is done by | algorithm is truncated to 16 bytes; truncation is done by | |||
| stripping off the final 16 bytes. The truncated output is | stripping off the final 16 bytes. The truncated output is | |||
| base64url encoded (Section 5 of [RFC4648]) with the trailing | base64url encoded (Section 5 of [RFC4648]) with the two | |||
| "=" removed from the encoding, and the resulting value used as | trailing "=" removed from the encoding, and the resulting value | |||
| the 'cuid'. | used as the 'cuid'. | |||
| The 'cuid' is intended to be stable when communicating with a | The 'cuid' is intended to be stable when communicating with a | |||
| given DOTS server, i.e., the 'cuid' used by a DOTS client | given DOTS server, i.e., the 'cuid' used by a DOTS client | |||
| SHOULD NOT change over time. Distinct 'cuid' values MAY be | SHOULD NOT change over time. Distinct 'cuid' values MAY be | |||
| used by a single DOTS client per DOTS server. | used by a single DOTS client per DOTS server. | |||
| If a DOTS client has to change its 'cuid' for some reason, it | If a DOTS client has to change its 'cuid' for some reason, it | |||
| MUST NOT do so when mitigations are still active for the old | MUST NOT do so when mitigations are still active for the old | |||
| 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS | 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS | |||
| signal message fragmentation over UDP. Furthermore, if that | signal message fragmentation over UDP. Furthermore, if that | |||
| skipping to change at page 16, line 47 ¶ | skipping to change at page 17, line 12 ¶ | |||
| Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body | Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body | |||
| Schema) | Schema) | |||
| The parameters in the CBOR body (Figure 6) of the PUT request are | The parameters in the CBOR body (Figure 6) of the PUT request are | |||
| described below: | described below: | |||
| target-prefix: A list of prefixes identifying resources under | target-prefix: A list of prefixes identifying resources under | |||
| attack. Prefixes are represented using Classless Inter-Domain | attack. Prefixes are represented using Classless Inter-Domain | |||
| Routing (CIDR) notation [RFC4632]. | Routing (CIDR) notation [RFC4632]. | |||
| As a reminder, the prefix length must be less than or equal to 32 | The prefix length must be less than or equal to 32 for IPv4 and | |||
| for IPv4 and 128 for IPv6. | 128 for IPv6. | |||
| The prefix list MUST NOT include broadcast, loopback, or multicast | The prefix list MUST NOT include broadcast, loopback, or multicast | |||
| addresses. These addresses are considered to be invalid values. | addresses. These addresses are considered to be invalid values. | |||
| In addition, the DOTS server MUST validate that target prefixes | In addition, the DOTS server MUST validate that target prefixes | |||
| are within the scope of the DOTS client domain. Other validation | are within the scope of the DOTS client domain. Other validation | |||
| checks may be supported by DOTS servers. | checks may be supported by DOTS servers. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| target-port-range: A list of port numbers bound to resources under | target-port-range: A list of port numbers bound to resources under | |||
| skipping to change at page 17, line 24 ¶ | skipping to change at page 17, line 38 ¶ | |||
| 'lower-port' is present, it represents a single port number. | 'lower-port' is present, it represents a single port number. | |||
| For TCP, UDP, Stream Control Transmission Protocol (SCTP) | For TCP, UDP, Stream Control Transmission Protocol (SCTP) | |||
| [RFC4960], or Datagram Congestion Control Protocol (DCCP) | [RFC4960], or Datagram Congestion Control Protocol (DCCP) | |||
| [RFC4340], a range of ports can be, for example, 0-1023, | [RFC4340], a range of ports can be, for example, 0-1023, | |||
| 1024-65535, or 1024-49151. | 1024-65535, or 1024-49151. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| target-protocol: A list of protocols involved in an attack. Values | target-protocol: A list of protocols involved in an attack. Values | |||
| are taken from the IANA protocol registry [IANA-Proto]. | are integers in the range of 0 to 255. See [IANA-Proto] for | |||
| common values. | ||||
| If 'target-protocol' is not specified, then the request applies to | If 'target-protocol' is not specified, then the request applies to | |||
| any protocol. | any protocol. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| target-fqdn: A list of Fully Qualified Domain Names (FQDNs) | target-fqdn: A list of Fully Qualified Domain Names (FQDNs) | |||
| identifying resources under attack [RFC8499]. | identifying resources under attack [RFC8499]. | |||
| How a name is passed to an underlying name resolution library is | How a name is passed to an underlying name resolution library is | |||
| implementation and deployment specific. Nevertheless, once the | implementation and deployment specific. Nevertheless, once the | |||
| name is resolved into one or multiple IP addresses, DOTS servers | name is resolved into one or multiple IP addresses, DOTS servers | |||
| MUST apply the same validation checks as those for 'target- | MUST apply the same validation checks as those for 'target- | |||
| prefix'. | prefix'. These validation checks are reiterated by DOTS servers | |||
| each time a name is passed to an underlying name resolution | ||||
| library (e.g., upon expiry of DNS TTL). | ||||
| The use of FQDNs may be suboptimal because: | The use of FQDNs may be suboptimal because: | |||
| * It induces both an extra load and increased delays on the DOTS | * It induces both an extra load and increased delays on the DOTS | |||
| server to handle and manage DNS resolution requests. | server to handle and manage DNS resolution requests. | |||
| * It does not guarantee that the DOTS server will resolve a name | * It does not guarantee that the DOTS server will resolve a name | |||
| to the same IP addresses that the DOTS client does. | to the same IP addresses that the DOTS client does. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| skipping to change at page 18, line 25 ¶ | skipping to change at page 18, line 41 ¶ | |||
| more efficiently to the resources under attack. | more efficiently to the resources under attack. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| lifetime: Lifetime of the mitigation request in seconds. The | lifetime: Lifetime of the mitigation request in seconds. The | |||
| RECOMMENDED lifetime of a mitigation request is 3600 seconds: this | RECOMMENDED lifetime of a mitigation request is 3600 seconds: this | |||
| value was chosen to be long enough so that refreshing is not | value was chosen to be long enough so that refreshing is not | |||
| typically a burden on the DOTS client, while still making the | typically a burden on the DOTS client, while still making the | |||
| request expire in a timely manner when the client has unexpectedly | request expire in a timely manner when the client has unexpectedly | |||
| quit. DOTS clients MUST include this parameter in their | quit. DOTS clients MUST include this parameter in their | |||
| mitigation requests. Upon the expiry of this lifetime, and if the | mitigation requests. | |||
| request is not refreshed, the mitigation request is removed. The | ||||
| request can be refreshed by sending the same request again. | ||||
| A lifetime of '0' in a mitigation request is an invalid value. | A lifetime of '0' in a mitigation request is an invalid value. | |||
| A lifetime of negative one (-1) indicates indefinite lifetime for | A lifetime of negative one (-1) indicates indefinite lifetime for | |||
| the mitigation request. The DOTS server MAY refuse an indefinite | the mitigation request. The DOTS server MAY refuse an indefinite | |||
| lifetime, for policy reasons; the granted lifetime value is | lifetime, for policy reasons; the granted lifetime value is | |||
| returned in the response. DOTS clients MUST be prepared to not be | returned in the response. DOTS clients MUST be prepared to not be | |||
| granted mitigations with indefinite lifetimes. | granted mitigations with indefinite lifetimes. | |||
| The DOTS server MUST always indicate the actual lifetime in the | The DOTS server MUST always indicate the actual lifetime in the | |||
| response and the remaining lifetime in status messages sent to the | response and the remaining lifetime in status messages sent to the | |||
| DOTS client. | DOTS client. | |||
| Upon the expiry of the negotiated lifetime (i.e., the remaining | ||||
| lifetime reaches '0'), and if the request is not refreshed by the | ||||
| DOTS client, the mitigation request is removed by the DOTS server. | ||||
| The request can be refreshed by sending the same request again. | ||||
| This is a mandatory attribute. | This is a mandatory attribute. | |||
| trigger-mitigation: If the parameter value is set to 'false', DDoS | trigger-mitigation: If the parameter value is set to 'false', DDoS | |||
| mitigation will not be triggered for the mitigation request unless | mitigation will not be triggered for the mitigation request unless | |||
| the DOTS signal channel session is lost. | the DOTS signal channel session is lost. | |||
| If the DOTS client ceases to respond to heartbeat messages, the | If the DOTS client ceases to respond to heartbeat messages, the | |||
| DOTS server can detect that the DOTS signal channel session is | DOTS server can detect that the DOTS signal channel session is | |||
| lost. More details are discussed in Section 4.7. | lost. More details are discussed in Section 4.7. | |||
| The default value of the parameter is 'true' (that is, the | The default value of the parameter is 'true' (that is, the | |||
| mitigation starts immediately). If 'trigger-mitigation' is not | mitigation starts immediately). If 'trigger-mitigation' is not | |||
| present in a request, this is equivalent to receiving a request | present in a request, this is equivalent to receiving a request | |||
| with 'trigger-mitigation' set to 'true'. | with 'trigger-mitigation' set to 'true'. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| In deployments where server-domain DOTS gateways are enabled, | ||||
| identity information about the origin source client domain ('cdid') | ||||
| SHOULD be propagated to the DOTS server. That information is meant | ||||
| to assist the DOTS server in enforcing some policies such as grouping | ||||
| DOTS clients that belong to the same DOTS domain, limiting the number | ||||
| of DOTS requests, and identifying the mitigation scope. These | ||||
| policies can be enforced per client, per client domain, or both. | ||||
| Also, the identity information may be used for auditing and debugging | ||||
| purposes. | ||||
| Figure 7 shows an example of a request relayed by a server-domain | ||||
| DOTS gateway. | ||||
| Header: PUT (Code=0.03) | ||||
| Uri-Path: ".well-known" | ||||
| Uri-Path: "dots" | ||||
| Uri-Path: "mitigate" | ||||
| Uri-Path: "cdid=7eeaf349529eb55ed50113" | ||||
| Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | ||||
| Uri-Path: "mid=123" | ||||
| Content-Format: "application/dots+cbor" | ||||
| { | ||||
| ... | ||||
| } | ||||
| Figure 7: PUT for DOTS Mitigation Request as Relayed by a DOTS | ||||
| Gateway | ||||
| A server-domain DOTS gateway SHOULD add the following Uri-Path | ||||
| parameter: | ||||
| cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed by | ||||
| a server-domain DOTS gateway to propagate the source domain | ||||
| identity from the gateway's client-facing side to the gateway's | ||||
| server-facing side, and from the gateway's server-facing side | ||||
| to the DOTS server. 'cdid' may be used by the final DOTS server | ||||
| for policy enforcement purposes (e.g., enforce a quota on | ||||
| filtering rules). These policies are deployment specific. | ||||
| Server-domain DOTS gateways SHOULD support a configuration | ||||
| option to instruct whether 'cdid' parameter is to be inserted. | ||||
| In order to accommodate deployments that require enforcing per- | ||||
| client policies, per-client domain policies, or a combination | ||||
| thereof, server-domain DOTS gateways instructed to insert the | ||||
| 'cdid' parameter MUST supply the SPKI hash of the DOTS client | ||||
| X.509 certificate, the DOTS client raw public key, or the hash | ||||
| of the "PSK identity" in the 'cdid', following the same rules | ||||
| for generating the hash conveyed in 'cuid', which is then used | ||||
| by the ultimate DOTS server to determine the corresponding | ||||
| client's domain. The 'cdid' generated by a server-domain | ||||
| gateway is likely to be the same as the 'cuid' except the case | ||||
| in which the DOTS message was relayed by a client-domain DOTS | ||||
| gateway or the 'cuid' was generated from a rogue DOTS client. | ||||
| If a DOTS client is provisioned, for example, with distinct | ||||
| certificates as a function of the peer server-domain DOTS | ||||
| gateway, distinct 'cdid' values may be supplied by a server- | ||||
| domain DOTS gateway. The ultimate DOTS server MUST treat those | ||||
| 'cdid' values as equivalent. | ||||
| The 'cdid' attribute MUST NOT be generated and included by DOTS | ||||
| clients. | ||||
| DOTS servers MUST ignore 'cdid' attributes that are directly | ||||
| supplied by source DOTS clients or client-domain DOTS gateways. | ||||
| This implies that first server-domain DOTS gateways MUST strip | ||||
| 'cdid' attributes supplied by DOTS clients. DOTS servers | ||||
| SHOULD support a configuration parameter to identify DOTS | ||||
| gateways that are trusted to supply 'cdid' attributes. | ||||
| Only single-valued 'cdid' are defined in this document. That | ||||
| is, only the first on-path server-domain DOTS gateway can | ||||
| insert a 'cdid' value. This specification does not allow | ||||
| multiple server-domain DOTS gateways, whenever involved in the | ||||
| path, to insert a 'cdid' value for each server-domain gateway. | ||||
| This is an optional Uri-Path. When present, 'cdid' MUST be | ||||
| positioned before 'cuid'. | ||||
| A DOTS gateway SHOULD add the CoAP Hop-Limit Option [RFC8768]. | ||||
| Because of the complexity of handling partial failure cases, this | Because of the complexity of handling partial failure cases, this | |||
| specification does not allow the inclusion of multiple mitigation | specification does not allow the inclusion of multiple mitigation | |||
| requests in the same PUT request. Concretely, a DOTS client MUST NOT | requests in the same PUT request. Concretely, a DOTS client MUST NOT | |||
| include multiple entries in the 'scope' array of the same PUT | include multiple entries in the 'scope' array of the same PUT | |||
| request. | request. | |||
| FQDN and URI mitigation scopes may be thought of as a form of scope | FQDN and URI mitigation scopes may be thought of as a form of scope | |||
| alias, in which the addresses associated with the domain name or URI | alias, in which the addresses associated with the domain name or URI | |||
| (as resolved by the DOTS server) represent the scope of the | (as resolved by the DOTS server) represent the scope of the | |||
| mitigation. Particularly, the IP addresses to which the host | mitigation. Particularly, the IP addresses to which the host | |||
| skipping to change at page 21, line 20 ¶ | skipping to change at page 20, line 9 ¶ | |||
| in the authority component, the default port defined for the URI | in the authority component, the default port defined for the URI | |||
| scheme represents the 'target-port'. | scheme represents the 'target-port'. | |||
| In the PUT request, at least one of the attributes 'target-prefix', | In the PUT request, at least one of the attributes 'target-prefix', | |||
| 'target-fqdn','target-uri', or 'alias-name' MUST be present. | 'target-fqdn','target-uri', or 'alias-name' MUST be present. | |||
| Attributes and Uri-Path parameters with empty values MUST NOT be | Attributes and Uri-Path parameters with empty values MUST NOT be | |||
| present in a request as an empty value will render the entire request | present in a request as an empty value will render the entire request | |||
| invalid. | invalid. | |||
| Figure 8 shows a PUT request example to signal that servers | Figure 7 shows a PUT request example to signal that servers | |||
| 2001:db8:6401::1 and 2001:db8:6401::2 are receiving attack traffic on | 2001:db8:6401::1 and 2001:db8:6401::2 are receiving attack traffic on | |||
| TCP port numbers 80, 8080, and 443. The presence of 'cdid' indicates | TCP port numbers 80, 8080, and 443. The presence of 'cdid' indicates | |||
| that a server-domain DOTS gateway has modified the initial PUT | that a server-domain DOTS gateway has modified the initial PUT | |||
| request sent by the DOTS client. Note that 'cdid' MUST NOT appear in | request sent by the DOTS client. Note that 'cdid' MUST NOT appear in | |||
| the PUT request message body. | the PUT request message body. | |||
| Header: PUT (Code=0.03) | Header: PUT (Code=0.03) | |||
| Uri-Path: ".well-known" | Uri-Path: ".well-known" | |||
| Uri-Path: "dots" | Uri-Path: "dots" | |||
| Uri-Path: "mitigate" | Uri-Path: "mitigate" | |||
| skipping to change at page 22, line 42 ¶ | skipping to change at page 21, line 42 ¶ | |||
| ], | ], | |||
| "target-protocol": [ | "target-protocol": [ | |||
| 6 | 6 | |||
| ], | ], | |||
| "lifetime": 3600 | "lifetime": 3600 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 8: PUT for DOTS Mitigation Request (An Example) | Figure 7: PUT for DOTS Mitigation Request (An Example) | |||
| The corresponding CBOR encoding format for the payload is shown in | The corresponding CBOR encoding format for the payload is shown in | |||
| Figure 9. | Figure 8. | |||
| A1 # map(1) | A1 # map(1) | |||
| 01 # unsigned(1) | 01 # unsigned(1) | |||
| A1 # map(1) | A1 # map(1) | |||
| 02 # unsigned(2) | 02 # unsigned(2) | |||
| 81 # array(1) | 81 # array(1) | |||
| A4 # map(4) | A4 # map(4) | |||
| 06 # unsigned(6) | 06 # unsigned(6) | |||
| 82 # array(2) | 82 # array(2) | |||
| 74 # text(20) | 74 # text(20) | |||
| skipping to change at page 23, line 34 ¶ | skipping to change at page 22, line 34 ¶ | |||
| 19 01BB # unsigned(443) | 19 01BB # unsigned(443) | |||
| A1 # map(1) | A1 # map(1) | |||
| 08 # unsigned(8) | 08 # unsigned(8) | |||
| 19 1F90 # unsigned(8080) | 19 1F90 # unsigned(8080) | |||
| 0A # unsigned(10) | 0A # unsigned(10) | |||
| 81 # array(1) | 81 # array(1) | |||
| 06 # unsigned(6) | 06 # unsigned(6) | |||
| 0E # unsigned(14) | 0E # unsigned(14) | |||
| 19 0E10 # unsigned(3600) | 19 0E10 # unsigned(3600) | |||
| Figure 9: PUT for DOTS Mitigation Request (CBOR) | Figure 8: PUT for DOTS Mitigation Request (CBOR) | |||
| In both DOTS signal and data channel sessions, the DOTS client MUST | 4.4.1.2. Server-domain DOTS Gateways | |||
| authenticate itself to the DOTS server (Section 8). The DOTS server | ||||
| MAY use the algorithm presented in Section 7 of [RFC7589] to derive | In deployments where server-domain DOTS gateways are enabled, | |||
| the DOTS client identity or username from the client certificate. | identity information about the origin source client domain ('cdid') | |||
| The DOTS client identity allows the DOTS server to accept mitigation | SHOULD be propagated to the DOTS server. That information is meant | |||
| requests with scopes that the DOTS client is authorized to manage. | to assist the DOTS server in enforcing some policies such as grouping | |||
| DOTS clients that belong to the same DOTS domain, limiting the number | ||||
| of DOTS requests, and identifying the mitigation scope. These | ||||
| policies can be enforced per client, per client domain, or both. | ||||
| Also, the identity information may be used for auditing and debugging | ||||
| purposes. | ||||
| Figure 9 shows an example of a request relayed by a server-domain | ||||
| DOTS gateway. | ||||
| Header: PUT (Code=0.03) | ||||
| Uri-Path: ".well-known" | ||||
| Uri-Path: "dots" | ||||
| Uri-Path: "mitigate" | ||||
| Uri-Path: "cdid=7eeaf349529eb55ed50113" | ||||
| Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | ||||
| Uri-Path: "mid=123" | ||||
| Content-Format: "application/dots+cbor" | ||||
| { | ||||
| ... | ||||
| } | ||||
| Figure 9: PUT for DOTS Mitigation Request as Relayed by a DOTS | ||||
| Gateway | ||||
| A server-domain DOTS gateway SHOULD add the following Uri-Path | ||||
| parameter: | ||||
| cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed by | ||||
| a server-domain DOTS gateway to propagate the source domain | ||||
| identity from the gateway's client-facing side to the gateway's | ||||
| server-facing side, and from the gateway's server-facing side | ||||
| to the DOTS server. 'cdid' may be used by the final DOTS | ||||
| server for policy enforcement purposes (e.g., enforce a quota | ||||
| on filtering rules). These policies are deployment specific. | ||||
| Server-domain DOTS gateways SHOULD support a configuration | ||||
| option to instruct whether 'cdid' parameter is to be inserted. | ||||
| In order to accommodate deployments that require enforcing per- | ||||
| client policies, per-client domain policies, or a combination | ||||
| thereof, server-domain DOTS gateways instructed to insert the | ||||
| 'cdid' parameter MUST supply the SPKI hash of the DOTS client | ||||
| X.509 certificate, the DOTS client raw public key, or the hash | ||||
| of the "PSK identity" in the 'cdid', following the same rules | ||||
| for generating the hash conveyed in 'cuid', which is then used | ||||
| by the ultimate DOTS server to determine the corresponding | ||||
| client's domain. The 'cdid' generated by a server-domain | ||||
| gateway is likely to be the same as the 'cuid' except the case | ||||
| in which the DOTS message was relayed by a client-domain DOTS | ||||
| gateway or the 'cuid' was generated by a rogue DOTS client. | ||||
| If a DOTS client is provisioned, for example, with distinct | ||||
| certificates to use to peer with distinct server-domain DOTS | ||||
| gateways that peer to the same DOTS server, distinct 'cdid' | ||||
| values may be supplied by the server-domain DOTS gateways to | ||||
| the server. The ultimate DOTS server MUST treat those 'cdid' | ||||
| values as equivalent. | ||||
| The 'cdid' attribute MUST NOT be generated and included by DOTS | ||||
| clients. | ||||
| DOTS servers MUST ignore 'cdid' attributes that are directly | ||||
| supplied by source DOTS clients or client-domain DOTS gateways. | ||||
| This implies that first server-domain DOTS gateways MUST strip | ||||
| 'cdid' attributes supplied by DOTS clients. DOTS servers | ||||
| SHOULD support a configuration parameter to identify DOTS | ||||
| gateways that are trusted to supply 'cdid' attributes. | ||||
| Only single-valued 'cdid' are defined in this document. That | ||||
| is, only the first on-path server-domain DOTS gateway can | ||||
| insert a 'cdid' value. This specification does not allow | ||||
| multiple server-domain DOTS gateways, whenever involved in the | ||||
| path, to insert a 'cdid' value for each server-domain gateway. | ||||
| This is an optional Uri-Path. When present, 'cdid' MUST be | ||||
| positioned before 'cuid'. | ||||
| A DOTS gateway SHOULD add the CoAP Hop-Limit Option [RFC8768]. | ||||
| 4.4.1.3. Processing Mitigation Requests | ||||
| The DOTS server couples the DOTS signal and data channel sessions | The DOTS server couples the DOTS signal and data channel sessions | |||
| using the DOTS client identity and optionally the 'cdid' parameter | using the DOTS client identity and optionally the 'cdid' parameter | |||
| value, so the DOTS server can validate whether the aliases conveyed | value, so the DOTS server can validate whether the aliases conveyed | |||
| in the mitigation request were indeed created by the same DOTS client | in the mitigation request were indeed created by the same DOTS client | |||
| using the DOTS data channel session. If the aliases were not created | using the DOTS data channel session. If the aliases were not created | |||
| by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in | by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in | |||
| the response. | the response. | |||
| The DOTS server couples the DOTS signal channel sessions using the | The DOTS server couples the DOTS signal channel sessions using the | |||
| DOTS client identity and optionally the 'cdid' parameter value, and | DOTS client identity and optionally the 'cdid' parameter value, and | |||
| the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to | the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to | |||
| detect duplicate mitigation requests. If the mitigation request | detect duplicate mitigation requests. If the mitigation request | |||
| contains the 'alias-name' and other parameters identifying the target | contains the 'alias-name' and other parameters identifying the target | |||
| resources (such as 'target-prefix', 'target-port-range', 'target- | resources (such as 'target-prefix', 'target-port-range', 'target- | |||
| fqdn', or 'target-uri'), the DOTS server appends the parameter values | fqdn', or 'target-uri'), the DOTS server appends the parameter values | |||
| in 'alias-name' with the corresponding parameter values in 'target- | associated with the 'alias-name' with the corresponding parameter | |||
| prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. | values in 'target-prefix', 'target-port-range', 'target-fqdn', or | |||
| 'target-uri'. | ||||
| The DOTS server indicates the result of processing the PUT request | The DOTS server indicates the result of processing the PUT request | |||
| using CoAP Response Codes. CoAP 2.xx codes are success. CoAP 4.xx | using CoAP Response Codes. CoAP 2.xx codes are success. CoAP 4.xx | |||
| codes are some sort of invalid requests (client errors). COAP 5.xx | codes are some sort of invalid requests (client errors). CoAP 5.xx | |||
| codes are returned if the DOTS server is in an error state or is | codes are returned if the DOTS server is in an error state or is | |||
| currently unavailable to provide mitigation in response to the | currently unavailable to provide mitigation in response to the | |||
| mitigation request from the DOTS client. | mitigation request from the DOTS client. | |||
| Figure 10 shows an example response to a PUT request that is | Figure 10 shows an example response to a PUT request that is | |||
| successfully processed by a DOTS server (i.e., CoAP 2.xx Response | successfully processed by a DOTS server (i.e., CoAP 2.xx Response | |||
| Codes). This version of the specification forbids 'cuid' and 'cdid' | Codes). This version of the specification forbids 'cuid' and 'cdid' | |||
| (if used) to be returned in a response message body. | (if used) to be returned in a response message body. | |||
| { | { | |||
| skipping to change at page 24, line 51 ¶ | skipping to change at page 25, line 40 ¶ | |||
| ignore comprehension-optional parameters they don't understand | ignore comprehension-optional parameters they don't understand | |||
| (Section 10.6.1.1). | (Section 10.6.1.1). | |||
| A DOTS server that receives a mitigation request with a 'lifetime' | A DOTS server that receives a mitigation request with a 'lifetime' | |||
| set to '0' MUST reply with a 4.00 (Bad Request). | set to '0' MUST reply with a 4.00 (Bad Request). | |||
| If the DOTS server does not find the 'mid' parameter value conveyed | If the DOTS server does not find the 'mid' parameter value conveyed | |||
| in the PUT request in its configuration data, it MAY accept the | in the PUT request in its configuration data, it MAY accept the | |||
| mitigation request by sending back a 2.01 (Created) response to the | mitigation request by sending back a 2.01 (Created) response to the | |||
| DOTS client; the DOTS server will consequently try to mitigate the | DOTS client; the DOTS server will consequently try to mitigate the | |||
| attack. A DOTS server could reject mitigation requests when it is | attack. A DOTS server MAY reject mitigation requests when it is near | |||
| near capacity or needs to rate-limit a particular client, for | capacity or needs to rate-limit a particular client, for example. | |||
| example. | ||||
| The relative order of two mitigation requests with the same 'trigger- | The relative order of two mitigation requests with the same 'trigger- | |||
| mitigation' type from a DOTS client is determined by comparing their | mitigation' type from a DOTS client is determined by comparing their | |||
| respective 'mid' values. If two mitigation requests with the same | respective 'mid' values. If two mitigation requests with the same | |||
| 'trigger-mitigation' type have overlapping mitigation scopes, the | 'trigger-mitigation' type have overlapping mitigation scopes, the | |||
| mitigation request with the highest numeric 'mid' value will override | mitigation request with the highest numeric 'mid' value will override | |||
| the other mitigation request. Two mitigation requests from a DOTS | the other mitigation request. Two mitigation requests from a DOTS | |||
| client have overlapping scopes if there is a common IP address, IP | client have overlapping scopes if there is a common IP address, IP | |||
| prefix, FQDN, URI, or alias. To avoid maintaining a long list of | prefix, FQDN, URI, or alias. To avoid maintaining a long list of | |||
| overlapping mitigation requests (i.e., requests with the same | overlapping mitigation requests (i.e., requests with the same | |||
| 'trigger-mitigation' type and overlapping scopes) from a DOTS client | 'trigger-mitigation' type and overlapping scopes) from a DOTS client | |||
| and to avoid error-prone provisioning of mitigation requests from a | and to avoid error-prone provisioning of mitigation requests from a | |||
| DOTS client, the overlapped lower numeric 'mid' MUST be automatically | DOTS client, the overlapped lower numeric 'mid' MUST be automatically | |||
| deleted and no longer available at the DOTS server. For example, if | deleted and no longer available at the DOTS server. For example, if | |||
| the DOTS server receives a mitigation request that overlaps with an | the DOTS server receives a mitigation request that overlaps with an | |||
| existing mitigation with a higher numeric 'mid', the DOTS server | existing mitigation with a higher numeric 'mid', the DOTS server | |||
| rejects the request by returning 4.09 (Conflict) to the DOTS client. | rejects the request by returning 4.09 (Conflict) to the DOTS client. | |||
| The response includes enough information for a DOTS client to | The response MUST include enough information for a DOTS client to | |||
| recognize the source of the conflict as described below in the | recognize the source of the conflict as described below in the | |||
| 'conflict-information' subtree with only the relevant nodes listed: | 'conflict-information' subtree (Section 5.1) with only the relevant | |||
| nodes listed: | ||||
| conflict-information: Indicates that a mitigation request is | conflict-information: Indicates that a mitigation request is | |||
| conflicting with another mitigation request. This optional | conflicting with another mitigation request. This attribute has | |||
| attribute has the following structure: | the following structure: | |||
| conflict-cause: Indicates the cause of the conflict. The | conflict-cause: Indicates the cause of the conflict. The | |||
| following values are defined: | following value MUST be returned: | |||
| 1: Overlapping targets. 'conflict-scope' provides more details | 1: Overlapping targets. 'conflict-scope' provides more details | |||
| about the conflicting target clauses. | about the conflicting target clauses. | |||
| conflict-scope: Characterizes the exact conflict scope. It may | conflict-scope: Characterizes the exact conflict scope. It may | |||
| include a list of IP addresses, a list of prefixes, a list of | include a list of IP addresses, a list of prefixes, a list of | |||
| port numbers, a list of target protocols, a list of FQDNs, a | target protocols, a list of FQDNs, a list of URIs, a list of | |||
| list of URIs, a list of aliases, or a 'mid'. | aliases, or a 'mid'. A list of port numbers may also be | |||
| included if there is a common IP address, IP prefix, FQDN, URI, | ||||
| or alias. | ||||
| If the DOTS server receives a mitigation request that overlaps with | If the DOTS server receives a mitigation request that overlaps with | |||
| an active mitigation request, but both have distinct 'trigger- | an active mitigation request, but both have distinct 'trigger- | |||
| mitigation' types, the DOTS server SHOULD deactivate (absent explicit | mitigation' types, the DOTS server SHOULD deactivate (absent explicit | |||
| policy/configuration otherwise) the mitigation request with 'trigger- | policy/configuration otherwise) the mitigation request with 'trigger- | |||
| mitigation' set to 'false'. Particularly, if the mitigation request | mitigation' set to 'false'. Particularly, if the mitigation request | |||
| with 'trigger-mitigation' set to 'false' is active, the DOTS server | with 'trigger-mitigation' set to 'false' is active, the DOTS server | |||
| withdraws the mitigation request (i.e., status code is set to '7' as | withdraws the mitigation request (i.e., status code is set to '7' as | |||
| defined in Table 3) and transitions the status of the mitigation | defined in Table 3) and transitions the status of the mitigation | |||
| request to '8'. | request to '8'. | |||
| skipping to change at page 26, line 32 ¶ | skipping to change at page 27, line 23 ¶ | |||
| broad mitigation when the DOTS signal channel collapses and to | broad mitigation when the DOTS signal channel collapses and to | |||
| maximize the chance of recovery. | maximize the chance of recovery. | |||
| If the request conflicts with an existing mitigation request from a | If the request conflicts with an existing mitigation request from a | |||
| different DOTS client, the DOTS server may return 2.01 (Created) or | different DOTS client, the DOTS server may return 2.01 (Created) or | |||
| 4.09 (Conflict) to the requesting DOTS client. If the DOTS server | 4.09 (Conflict) to the requesting DOTS client. If the DOTS server | |||
| decides to maintain the new mitigation request, the DOTS server | decides to maintain the new mitigation request, the DOTS server | |||
| returns 2.01 (Created) to the requesting DOTS client. If the DOTS | returns 2.01 (Created) to the requesting DOTS client. If the DOTS | |||
| server decides to reject the new mitigation request, the DOTS server | server decides to reject the new mitigation request, the DOTS server | |||
| returns 4.09 (Conflict) to the requesting DOTS client. For both 2.01 | returns 4.09 (Conflict) to the requesting DOTS client. For both 2.01 | |||
| (Created) and 4.09 (Conflict) responses, the response includes enough | (Created) and 4.09 (Conflict) responses, the response MUST include | |||
| information for a DOTS client to recognize the source of the conflict | enough information for a DOTS client to recognize the source of the | |||
| as described below: | conflict as described below: | |||
| conflict-information: Indicates that a mitigation request is | conflict-information: Indicates that a mitigation request is | |||
| conflicting with another mitigation request(s) from other DOTS | conflicting with another mitigation request(s) from other DOTS | |||
| client(s). This optional attribute has the following structure: | client(s). This attribute has the following structure: | |||
| conflict-status: Indicates the status of a conflicting mitigation | conflict-status: Indicates the status of a conflicting mitigation | |||
| request. The following values are defined: | request. The following values are defined: | |||
| 1: DOTS server has detected conflicting mitigation requests | 1: DOTS server has detected conflicting mitigation requests | |||
| from different DOTS clients. This mitigation request is | from different DOTS clients. This mitigation request is | |||
| currently inactive until the conflicts are resolved. | currently inactive until the conflicts are resolved. | |||
| Another mitigation request is active. | Another mitigation request is active. | |||
| 2: DOTS server has detected conflicting mitigation requests | 2: DOTS server has detected conflicting mitigation requests | |||
| skipping to change at page 27, line 31 ¶ | skipping to change at page 28, line 21 ¶ | |||
| uses a 'cuid' that is already used by another DOTS client. | uses a 'cuid' that is already used by another DOTS client. | |||
| This code is an indication that the request has been | This code is an indication that the request has been | |||
| rejected and a new request with a new 'cuid' is to be re- | rejected and a new request with a new 'cuid' is to be re- | |||
| sent by the DOTS client (see the example shown in | sent by the DOTS client (see the example shown in | |||
| Figure 11). Note that 'conflict-status', 'conflict-scope', | Figure 11). Note that 'conflict-status', 'conflict-scope', | |||
| and 'retry-timer' MUST NOT be returned in the error | and 'retry-timer' MUST NOT be returned in the error | |||
| response. | response. | |||
| conflict-scope: Characterizes the exact conflict scope. It may | conflict-scope: Characterizes the exact conflict scope. It may | |||
| include a list of IP addresses, a list of prefixes, a list of | include a list of IP addresses, a list of prefixes, a list of | |||
| port numbers, a list of target protocols, a list of FQDNs, a | target protocols, a list of FQDNs, a list of URIs, a list of | |||
| list of URIs, a list of aliases, or references to conflicting | aliases, or references to conflicting ACLs (by an 'acl-name', | |||
| ACLs (by an 'acl-name', typically [RFC8783]). | typically [RFC8783]). A list of port numbers may also be | |||
| included if there is a common IP address, IP prefix, FQDN, URI, | ||||
| or alias. | ||||
| retry-timer: Indicates, in seconds, the time after which the DOTS | retry-timer: Indicates, in seconds, the time after which the DOTS | |||
| client may reissue the same request. The DOTS server returns | client may reissue the same request. The DOTS server returns | |||
| 'retry-timer' only to DOTS client(s) for which a mitigation | 'retry-timer' only to DOTS client(s) for which a mitigation | |||
| request is deactivated. Any retransmission of the same | request is deactivated. Any retransmission of the same | |||
| mitigation request before the expiry of this timer is likely to | mitigation request before the expiry of this timer is likely to | |||
| be rejected by the DOTS server for the same reasons. | be rejected by the DOTS server for the same reasons. | |||
| The 'retry-timer' SHOULD be equal to the lifetime of the active | The 'retry-timer' SHOULD be equal to the lifetime of the active | |||
| mitigation request resulting in the deactivation of the | mitigation request resulting in the deactivation of the | |||
| skipping to change at page 28, line 7 ¶ | skipping to change at page 29, line 5 ¶ | |||
| If the DOTS server decides to maintain a state for the | If the DOTS server decides to maintain a state for the | |||
| deactivated mitigation request, the DOTS server updates the | deactivated mitigation request, the DOTS server updates the | |||
| lifetime of the deactivated mitigation request to 'retry-timer | lifetime of the deactivated mitigation request to 'retry-timer | |||
| + 45 seconds' (that is, this mitigation request remains | + 45 seconds' (that is, this mitigation request remains | |||
| deactivated for the entire duration of 'retry-timer + 45 | deactivated for the entire duration of 'retry-timer + 45 | |||
| seconds') so that the DOTS client can refresh the deactivated | seconds') so that the DOTS client can refresh the deactivated | |||
| mitigation request after 'retry-timer' seconds, but before the | mitigation request after 'retry-timer' seconds, but before the | |||
| expiry of the lifetime, and check if the conflict is resolved. | expiry of the lifetime, and check if the conflict is resolved. | |||
| (1) Request with a conflicting 'cuid' | ||||
| Header: PUT (Code=0.03) | Header: PUT (Code=0.03) | |||
| Uri-Path: ".well-known" | Uri-Path: ".well-known" | |||
| Uri-Path: "dots" | Uri-Path: "dots" | |||
| Uri-Path: "mitigate" | Uri-Path: "mitigate" | |||
| Uri-Path: "cuid=7eeaf349529eb55ed50113" | Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | |||
| Uri-Path: "mid=12" | Uri-Path: "mid=12" | |||
| (1) Request with a conflicting 'cuid' | (2) Message body of the 4.09 (Conflict) response | |||
| from the DOTS server | ||||
| { | { | |||
| "ietf-dots-signal-channel:mitigation-scope": { | "ietf-dots-signal-channel:mitigation-scope": { | |||
| "scope": [ | "scope": [ | |||
| { | { | |||
| "conflict-information": { | "conflict-information": { | |||
| "conflict-cause": "cuid-collision" | "conflict-cause": "cuid-collision" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| (2) Message body of the 4.09 (Conflict) response | (3) Request with a new 'cuid' | |||
| from the DOTS server | ||||
| Header: PUT (Code=0.03) | Header: PUT (Code=0.03) | |||
| Uri-Path: ".well-known" | Uri-Path: ".well-known" | |||
| Uri-Path: "dots" | Uri-Path: "dots" | |||
| Uri-Path: "mitigate" | Uri-Path: "mitigate" | |||
| Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" | Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" | |||
| Uri-Path: "mid=12" | Uri-Path: "mid=12" | |||
| (3) Request with a new 'cuid' | ||||
| Figure 11: Example of Generating a New 'cuid' | Figure 11: Example of Generating a New 'cuid' | |||
| As an active attack evolves, DOTS clients can adjust the scope of | As an active attack evolves, DOTS clients can adjust the scope of | |||
| requested mitigation as necessary, by refining the scope of resources | requested mitigation as necessary, by refining the scope of resources | |||
| requiring mitigation. This can be achieved by sending a PUT request | requiring mitigation. This can be achieved by sending a PUT request | |||
| with a new 'mid' value that will override the existing one with | with a new 'mid' value that will override the existing one with | |||
| overlapping mitigation scopes. | overlapping mitigation scopes. | |||
| For a mitigation request to continue beyond the initial negotiated | For a mitigation request to continue beyond the initial negotiated | |||
| lifetime, the DOTS client has to refresh the current mitigation | lifetime, the DOTS client has to refresh the current mitigation | |||
| request by sending a new PUT request. This PUT request MUST use the | request by sending a new PUT request. This PUT request MUST use the | |||
| same 'mid' value, and it MUST repeat all the other parameters as sent | same 'mid' value, and it MUST repeat all the other parameters as sent | |||
| in the original mitigation request apart from a possible change to | in the original mitigation request apart from a possible change to | |||
| the 'lifetime' parameter value. In such a case, the DOTS server MAY | the 'lifetime' parameter value. In such a case, the DOTS server MAY | |||
| update the mitigation request, and a 2.04 (Changed) response is | update the mitigation request by setting the remaining lifetime to | |||
| the newly negotiated lifetime, and a 2.04 (Changed) response is | ||||
| returned to indicate a successful update of the mitigation request. | returned to indicate a successful update of the mitigation request. | |||
| If this is not the case, the DOTS server MUST reject the request with | If this is not the case, the DOTS server MUST reject the request with | |||
| a 4.00 (Bad Request). | a 4.00 (Bad Request). | |||
| 4.4.2. Retrieve Information Related to a Mitigation | 4.4.2. Retrieve Information Related to a Mitigation | |||
| A GET request is used by a DOTS client to retrieve information | A GET request is used by a DOTS client to retrieve information | |||
| (including status) of DOTS mitigations from a DOTS server. | (including status) of DOTS mitigations from a DOTS server. | |||
| 'cuid' is a mandatory Uri-Path parameter for GET requests. | 'cuid' is a mandatory Uri-Path parameter for GET requests. | |||
| skipping to change at page 32, line 51 ¶ | skipping to change at page 33, line 51 ¶ | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 14: Response Body to a GET Request | Figure 14: Response Body to a GET Request | |||
| The mitigation status parameters are described below: | The mitigation status parameters are described below: | |||
| mitigation-start: Mitigation start time is expressed in seconds | mitigation-start: Mitigation start time is expressed in seconds | |||
| relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of | relative to 1970-01-01T00:00Z in UTC time (Section 3.4.1 of | |||
| [RFC7049]). The CBOR encoding is modified so that the leading tag | [RFC8949]). The CBOR encoding is modified so that the leading tag | |||
| 1 (epoch-based date/time) MUST be omitted. | 1 (epoch-based date/time) MUST be omitted. | |||
| This is a mandatory attribute when an attack mitigation is active. | This is a mandatory attribute when an attack mitigation is active. | |||
| Particularly, 'mitigation-start' is not returned for a mitigation | Particularly, 'mitigation-start' is not returned for a mitigation | |||
| with 'status' code set to 8. | with 'status' code set to 8. | |||
| lifetime: The remaining lifetime of the mitigation request, in | lifetime: The remaining lifetime of the mitigation request, in | |||
| seconds. | seconds. | |||
| This is a mandatory attribute. | This is a mandatory attribute. | |||
| skipping to change at page 35, line 12 ¶ | skipping to change at page 36, line 12 ¶ | |||
| Table 3: Values of 'status' Parameter | Table 3: Values of 'status' Parameter | |||
| 4.4.2.1. DOTS Servers Sending Mitigation Status | 4.4.2.1. DOTS Servers Sending Mitigation Status | |||
| The Observe Option defined in [RFC7641] extends the CoAP core | The Observe Option defined in [RFC7641] extends the CoAP core | |||
| protocol with a mechanism for a CoAP client to "observe" a resource | protocol with a mechanism for a CoAP client to "observe" a resource | |||
| on a CoAP server: the client retrieves a representation of the | on a CoAP server: the client retrieves a representation of the | |||
| resource and requests this representation be updated by the server as | resource and requests this representation be updated by the server as | |||
| long as the client is interested in the resource. DOTS | long as the client is interested in the resource. DOTS | |||
| implementations MUST use the Observe Option for both 'mitigate' and | implementations MUST support the Observe Option for both 'mitigate' | |||
| 'config' (Section 4.2). | and 'config' (Section 4.2). | |||
| A DOTS client conveys the Observe Option set to '0' in the GET | A DOTS client conveys the Observe Option set to '0' in the GET | |||
| request to receive asynchronous notifications of attack mitigation | request to receive asynchronous notifications of attack mitigation | |||
| status from the DOTS server. | status from the DOTS server. | |||
| Unidirectional mitigation notifications within the bidirectional | Unidirectional mitigation notifications within the bidirectional | |||
| signal channel enables asynchronous notifications between the agents. | signal channel enables asynchronous notifications between the agents. | |||
| [RFC7641] indicates that (1) a notification can be sent in a | [RFC7641] indicates that (1) a notification can be sent in a | |||
| Confirmable or a Non-confirmable message, and (2) the message type | Confirmable or a Non-confirmable message, and (2) the message type | |||
| used is typically application dependent and may be determined by the | used is typically application dependent and may be determined by the | |||
| server for each notification individually. For the DOTS server | server for each notification individually. For the DOTS server | |||
| application, the message type MUST always be set to Non-confirmable | application, the message type MUST always be set to Non-confirmable | |||
| even if the underlying COAP library elects a notification to be sent | even if the underlying CoAP library elects a notification to be sent | |||
| in a Confirmable message. This overrides the behavior defined in | in a Confirmable message. This overrides the behavior defined in | |||
| Section 4.5 of [RFC7641] to send a Confirmable message instead of a | Section 4.5 of [RFC7641] to send a Confirmable message instead of a | |||
| Non-confirmable message at least every 24 hours for the following | Non-confirmable message at least every 24 hours for the following | |||
| reasons: First, the DOTS signal channel uses a heartbeat mechanism to | reasons: First, the DOTS signal channel uses a heartbeat mechanism to | |||
| determine if the DOTS client is alive. Second, Confirmable messages | determine if the DOTS client is alive. Second, Confirmable messages | |||
| are not suitable during an attack. | are not suitable during an attack. | |||
| Due to the higher likelihood of packet loss during a DDoS attack, the | Due to the higher likelihood of packet loss during a DDoS attack, the | |||
| DOTS server periodically sends attack mitigation status to the DOTS | DOTS server periodically sends attack mitigation status to the DOTS | |||
| client and also notifies the DOTS client whenever the status of the | client and also notifies the DOTS client whenever the status of the | |||
| skipping to change at page 37, line 48 ¶ | skipping to change at page 38, line 48 ¶ | |||
| The DOTS client can send the GET request at frequent intervals | The DOTS client can send the GET request at frequent intervals | |||
| without the Observe Option to retrieve the configuration data of the | without the Observe Option to retrieve the configuration data of the | |||
| mitigation request and non-configuration data (i.e., the attack | mitigation request and non-configuration data (i.e., the attack | |||
| status). DOTS clients MAY be configured with a policy indicating the | status). DOTS clients MAY be configured with a policy indicating the | |||
| frequency of polling DOTS servers to get the mitigation status. This | frequency of polling DOTS servers to get the mitigation status. This | |||
| frequency MUST NOT be more than one UDP datagram per RTT as discussed | frequency MUST NOT be more than one UDP datagram per RTT as discussed | |||
| in Section 3.1.3 of [RFC8085]. | in Section 3.1.3 of [RFC8085]. | |||
| If the DOTS server has been able to mitigate the attack and the | If the DOTS server has been able to mitigate the attack and the | |||
| attack has stopped, the DOTS server indicates as such in the status. | attack has stopped, the DOTS server indicates as such in the status. | |||
| In such case, the DOTS client recalls the mitigation request by | In such case, the DOTS client withdraws the mitigation request by | |||
| issuing a DELETE request for this mitigation request (Section 4.4.4). | issuing a DELETE request for this mitigation request (Section 4.4.4). | |||
| A DOTS client SHOULD react to the status of the attack per the | A DOTS client SHOULD react to the status of the attack per the | |||
| information sent by the DOTS server rather than performing its own | information sent by the DOTS server rather than performing its own | |||
| detection that the attack has been mitigated. This ensures that the | detection that the attack has been mitigated. This ensures that the | |||
| DOTS client does not recall a mitigation request prematurely because | DOTS client does not withdraw a mitigation request prematurely | |||
| it is possible that the DOTS client does not sense the DDoS attack on | because it is possible that the DOTS client does not sense the DDoS | |||
| its resources, but the DOTS server could be actively mitigating the | attack on its resources, but the DOTS server could be actively | |||
| attack because the attack is not completely averted. | mitigating the attack because the attack is not completely averted. | |||
| 4.4.3. Efficacy Update from DOTS Clients | 4.4.3. Efficacy Update from DOTS Clients | |||
| While DDoS mitigation is in progress, due to the likelihood of packet | While DDoS mitigation is in progress, due to the likelihood of packet | |||
| loss, a DOTS client MAY periodically transmit DOTS mitigation | loss, a DOTS client MAY periodically transmit DOTS mitigation | |||
| efficacy updates to the relevant DOTS server. A PUT request is used | efficacy updates to the relevant DOTS server. A PUT request is used | |||
| to convey the mitigation efficacy update to the DOTS server. This | to convey the mitigation efficacy update to the DOTS server. This | |||
| PUT request is treated as a refresh of the current mitigation. | PUT request is treated as a refresh of the current mitigation. | |||
| The 'attack-status' parameter is a mandatory attribute when | ||||
| performing an efficacy update. The various possible values contained | ||||
| in the 'attack-status' parameter are described in Table 4. | ||||
| +-----------+-------------------------------------+ | ||||
| | Parameter | Description | | ||||
| | Value | | | ||||
| +===========+=====================================+ | ||||
| | 1 | The DOTS client determines that it | | ||||
| | | is still under attack. | | ||||
| +-----------+-------------------------------------+ | ||||
| | 2 | The DOTS client determines that the | | ||||
| | | attack is successfully mitigated | | ||||
| | | (e.g., attack traffic is not seen). | | ||||
| +-----------+-------------------------------------+ | ||||
| Table 4: Values of 'attack-status' Parameter | ||||
| The PUT request used for the efficacy update MUST include all the | The PUT request used for the efficacy update MUST include all the | |||
| parameters used in the PUT request to carry the DOTS mitigation | parameters used in the PUT request to carry the DOTS mitigation | |||
| request (Section 4.4.1) unchanged apart from the 'lifetime' parameter | request (Section 4.4.1) unchanged apart from the 'lifetime' parameter | |||
| value. If this is not the case, the DOTS server MUST reject the | value. If this is not the case, the DOTS server MUST reject the | |||
| request with a 4.00 (Bad Request). | request with a 4.00 (Bad Request). | |||
| The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty | The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty | |||
| value is used to make the PUT request conditional on the current | value is used to make the PUT request conditional on the current | |||
| existence of the mitigation request. If UDP is used as transport, | existence of the mitigation request. If UDP is used as transport, | |||
| CoAP requests may arrive out of order. For example, the DOTS client | CoAP requests may arrive out of order. For example, the DOTS client | |||
| skipping to change at page 39, line 44 ¶ | skipping to change at page 40, line 49 ¶ | |||
| 6 | 6 | |||
| ], | ], | |||
| "attack-status": "under-attack" | "attack-status": "under-attack" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 16: An Example of Efficacy Update | Figure 16: An Example of Efficacy Update | |||
| The 'attack-status' parameter is a mandatory attribute when | ||||
| performing an efficacy update. The various possible values contained | ||||
| in the 'attack-status' parameter are described in Table 4. | ||||
| +-----------+-------------------------------------+ | ||||
| | Parameter | Description | | ||||
| | Value | | | ||||
| +===========+=====================================+ | ||||
| | 1 | The DOTS client determines that it | | ||||
| | | is still under attack. | | ||||
| +-----------+-------------------------------------+ | ||||
| | 2 | The DOTS client determines that the | | ||||
| | | attack is successfully mitigated | | ||||
| | | (e.g., attack traffic is not seen). | | ||||
| +-----------+-------------------------------------+ | ||||
| Table 4: Values of 'attack-status' Parameter | ||||
| The DOTS server indicates the result of processing a PUT request | The DOTS server indicates the result of processing a PUT request | |||
| using CoAP Response Codes. The Response Code 2.04 (Changed) is | using CoAP Response Codes. The Response Code 2.04 (Changed) is | |||
| returned if the DOTS server has accepted the mitigation efficacy | returned if the DOTS server has accepted the mitigation efficacy | |||
| update. The error Response Code 5.03 (Service Unavailable) is | update. The error Response Code 5.03 (Service Unavailable) is | |||
| returned if the DOTS server has erred or is incapable of performing | returned if the DOTS server has erred or is incapable of performing | |||
| the mitigation. As specified in [RFC7252], 5.03 uses Max-Age Option | the mitigation. As specified in [RFC7252], 5.03 uses Max-Age Option | |||
| to indicate the number of seconds after which to retry. | to indicate the number of seconds after which to retry. | |||
| 4.4.4. Withdraw a Mitigation | 4.4.4. Withdraw a Mitigation | |||
| skipping to change at page 41, line 6 ¶ | skipping to change at page 41, line 35 ¶ | |||
| Uri-Path: "mitigate" | Uri-Path: "mitigate" | |||
| Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | |||
| Uri-Path: "mid=123" | Uri-Path: "mid=123" | |||
| Figure 17: Withdraw a DOTS Mitigation | Figure 17: Withdraw a DOTS Mitigation | |||
| If the DELETE request does not include 'cuid' and 'mid' parameters, | If the DELETE request does not include 'cuid' and 'mid' parameters, | |||
| the DOTS server MUST reply with a 4.00 (Bad Request). | the DOTS server MUST reply with a 4.00 (Bad Request). | |||
| Once the request is validated, the DOTS server immediately | Once the request is validated, the DOTS server immediately | |||
| acknowledges a DOTS client's request to withdraw the DOTS signal | acknowledges a DOTS client's request to withdraw the DOTS mitigation | |||
| using 2.02 (Deleted) Response Code with no response payload. A 2.02 | request using 2.02 (Deleted) Response Code with no response payload. | |||
| (Deleted) Response Code is returned even if the 'mid' parameter value | A 2.02 (Deleted) Response Code is returned even if the 'mid' | |||
| conveyed in the DELETE request does not exist in its configuration | parameter value conveyed in the DELETE request does not exist in its | |||
| data before the request. | configuration data before the request. | |||
| If the DOTS server finds the 'mid' parameter value conveyed in the | If the DOTS server finds the 'mid' parameter value conveyed in the | |||
| DELETE request in its configuration data for the DOTS client, then to | DELETE request in its configuration data for the DOTS client, then to | |||
| protect against route or DNS flapping caused by a DOTS client rapidly | protect against route or DNS flapping caused by a DOTS client rapidly | |||
| removing a mitigation, and to dampen the effect of oscillating | removing a mitigation, and to dampen the effect of oscillating | |||
| attacks, the DOTS server MAY allow mitigation to continue for a | attacks, the DOTS server MAY allow mitigation to continue for a | |||
| limited period after acknowledging a DOTS client's withdrawal of a | limited period after acknowledging a DOTS client's withdrawal of a | |||
| mitigation request. During this period, the DOTS server status | mitigation request. During this period, the DOTS server status | |||
| messages SHOULD indicate that mitigation is active but terminating | messages SHOULD indicate that mitigation is active but terminating | |||
| (Section 4.4.2). | (Section 4.4.2). | |||
| The initial active-but-terminating period SHOULD be sufficiently long | The initial active-but-terminating period SHOULD be sufficiently long | |||
| to absorb latency incurred by route propagation. The active-but- | to absorb latency incurred by route propagation. The active-but- | |||
| terminating period SHOULD be set by default to 120 seconds. If the | terminating period SHOULD be set by default to 120 seconds. If the | |||
| client requests mitigation again before the initial active-but- | client requests mitigation again before the initial active-but- | |||
| terminating period elapses, the DOTS server MAY exponentially | terminating period elapses, the DOTS server MAY exponentially | |||
| increase (the base of the exponent is 2) the active-but-terminating | increase (the base of the exponent is 2) the active-but-terminating | |||
| period up to a maximum of 300 seconds (5 minutes). | period up to a maximum of 300 seconds (5 minutes). | |||
| Once the active-but-terminating period elapses, the DOTS server MUST | Once the active-but-terminating period elapses, the DOTS server MUST | |||
| treat the mitigation as terminated, as the DOTS client is no longer | treat the mitigation as terminated. | |||
| responsible for the mitigation. | ||||
| If a mitigation is triggered due to a signal channel loss, the DOTS | If a mitigation is triggered due to a signal channel loss, the DOTS | |||
| server relies upon normal triggers to stop that mitigation | server relies upon normal triggers to stop that mitigation | |||
| (typically, receipt of a valid DELETE request, expiry of the | (typically, receipt of a valid DELETE request, expiry of the | |||
| mitigation lifetime, or scrubbing the traffic to the attack target). | mitigation lifetime, or scrubbing the traffic to the attack target). | |||
| In particular, the DOTS server MUST NOT consider the signal channel | In particular, the DOTS server MUST NOT consider the signal channel | |||
| recovery as a trigger to stop the mitigation. | recovery as a trigger to stop the mitigation. | |||
| 4.5. DOTS Signal Channel Session Configuration | 4.5. DOTS Signal Channel Session Configuration | |||
| skipping to change at page 42, line 14 ¶ | skipping to change at page 42, line 45 ¶ | |||
| b. Missing heartbeats allowed ('missing-hb-allowed'): This variable | b. Missing heartbeats allowed ('missing-hb-allowed'): This variable | |||
| indicates the maximum number of consecutive heartbeat messages | indicates the maximum number of consecutive heartbeat messages | |||
| for which a DOTS agent did not receive a response before | for which a DOTS agent did not receive a response before | |||
| concluding that the session is disconnected or defunct. | concluding that the session is disconnected or defunct. | |||
| c. Acceptable probing rate ('probing-rate'): This parameter | c. Acceptable probing rate ('probing-rate'): This parameter | |||
| indicates the average data rate that must not be exceeded by a | indicates the average data rate that must not be exceeded by a | |||
| DOTS agent in sending to a peer DOTS agent that does not respond. | DOTS agent in sending to a peer DOTS agent that does not respond. | |||
| d. Acceptable signal loss ratio: Maximum retransmissions, | d. Acceptable signal loss ratio: Maximum retransmissions ('max- | |||
| retransmission timeout value, and other message transmission | retransmit'), retransmission timeout value ('ack-timeout'), and | |||
| parameters for Confirmable messages over the DOTS signal channel. | other message transmission parameters for Confirmable messages | |||
| over the DOTS signal channel. | ||||
| When the DOTS signal channel is established over a reliable transport | When the DOTS signal channel is established over a reliable transport | |||
| (e.g., TCP), there is no need for the reliability mechanisms provided | (e.g., TCP), there is no need for the reliability mechanisms provided | |||
| by CoAP over UDP since the underlying TCP connection provides | by CoAP over UDP since the underlying TCP connection provides | |||
| retransmissions and deduplication [RFC8323]. As a reminder, CoAP | retransmissions and deduplication [RFC8323]. CoAP over reliable | |||
| over reliable transports does not support Confirmable or Non- | transports does not support Confirmable or Non-confirmable message | |||
| confirmable message types. As such, the transmission-related | types. As such, the transmission-related parameters ('missing-hb- | |||
| parameters ('missing-hb-allowed' and acceptable signal loss ratio) | allowed' and acceptable signal loss ratio) are negotiated only for | |||
| are negotiated only for DOTS over unreliable transports. | DOTS over unreliable transports. | |||
| The same or distinct configuration sets may be used during times when | The same or distinct configuration sets may be used during times when | |||
| a mitigation is active ('mitigating-config') and when no mitigation | a mitigation is active ('mitigating-config') and when no mitigation | |||
| is active ('idle-config'). This is particularly useful for DOTS | is active ('idle-config'). This is particularly useful for DOTS | |||
| servers that might want to reduce heartbeat frequency or cease | servers that might want to reduce heartbeat frequency or cease | |||
| heartbeat exchanges when an active DOTS client has not requested | heartbeat exchanges when an active DOTS client has not requested | |||
| mitigation. If distinct configurations are used, DOTS agents MUST | mitigation. If distinct configurations are used, DOTS agents MUST | |||
| follow the appropriate configuration set as a function of the | follow the appropriate configuration set as a function of the | |||
| mitigation activity (e.g., if no mitigation request is active (also | mitigation activity (e.g., if no mitigation request is active (also | |||
| referred to as 'idle' time), values related to 'idle-config' must be | referred to as 'idle' time), values related to 'idle-config' must be | |||
| skipping to change at page 45, line 41 ¶ | skipping to change at page 46, line 30 ¶ | |||
| '0' is used to disable the heartbeat mechanism. | '0' is used to disable the heartbeat mechanism. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| missing-hb-allowed: Maximum number of consecutive heartbeat | missing-hb-allowed: Maximum number of consecutive heartbeat | |||
| messages for which the DOTS agent did not receive a response | messages for which the DOTS agent did not receive a response | |||
| before concluding that the session is disconnected. | before concluding that the session is disconnected. | |||
| This is an optional attribute. | This is an optional attribute. | |||
| probing-rate: The average data rate that must not be exceeded by | probing-rate: The average data rate, in bytes/second, that must | |||
| a DOTS agent in sending to a peer DOTS agent that does not | not be exceeded by a DOTS agent in sending to a peer DOTS agent | |||
| respond (referred to as PROBING_RATE parameter in CoAP). | that does not respond (referred to as PROBING_RATE parameter in | |||
| CoAP). | ||||
| This is an optional attribute. | This is an optional attribute. | |||
| max-retransmit: Maximum number of retransmissions for a message | max-retransmit: Maximum number of retransmissions for a message | |||
| (referred to as MAX_RETRANSMIT parameter in CoAP). | (referred to as MAX_RETRANSMIT parameter in CoAP). | |||
| This is an optional attribute. | This is an optional attribute. | |||
| ack-timeout: Timeout value in seconds used to calculate the | ack-timeout: Timeout value in seconds used to calculate the | |||
| initial retransmission timeout value (referred to as | initial retransmission timeout value (referred to as | |||
| skipping to change at page 52, line 14 ¶ | skipping to change at page 52, line 14 ¶ | |||
| The meaning of the parameters in the CBOR body (Figure 22) is defined | The meaning of the parameters in the CBOR body (Figure 22) is defined | |||
| in Section 4.5.1. | in Section 4.5.1. | |||
| At least one of the attributes 'heartbeat-interval', 'missing-hb- | At least one of the attributes 'heartbeat-interval', 'missing-hb- | |||
| allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and 'ack- | allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and 'ack- | |||
| random-factor' MUST be present in the PUT request. Note that | random-factor' MUST be present in the PUT request. Note that | |||
| 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max- | 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max- | |||
| retransmit', 'ack-timeout', and 'ack-random-factor', if present, do | retransmit', 'ack-timeout', and 'ack-random-factor', if present, do | |||
| not need to be provided for both 'mitigating-config', and 'idle- | not need to be provided for both 'mitigating-config', and 'idle- | |||
| config' in a PUT request. | config' in a PUT request. A request does not need to include both | |||
| 'mitigating-config' and 'idle-config' attributes. | ||||
| The PUT request with a higher numeric 'sid' value overrides the DOTS | The PUT request with a higher numeric 'sid' value overrides the DOTS | |||
| signal channel session configuration data installed by a PUT request | signal channel session configuration data installed by a PUT request | |||
| with a lower numeric 'sid' value. To avoid maintaining a long list | with a lower numeric 'sid' value. That is, the configuration | |||
| of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be | parameters that are included in the PUT request with a higher numeric | |||
| automatically deleted and no longer available at the DOTS server. | 'sid' value will be used instead of the DOTS server's defaults. To | |||
| avoid maintaining a long list of 'sid' requests from a DOTS client, | ||||
| the lower numeric 'sid' MUST be automatically deleted and no longer | ||||
| available at the DOTS server. | ||||
| Figure 23 shows a PUT request example to convey the configuration | Figure 23 shows a PUT request example to convey the configuration | |||
| parameters for the DOTS signal channel. In this example, the | parameters for the DOTS signal channel. In this example, the | |||
| heartbeat mechanism is disabled when no mitigation is active, while | heartbeat mechanism is disabled when no mitigation is active, while | |||
| the heartbeat interval is set to '30' when a mitigation is active. | the heartbeat interval is set to '30' when a mitigation is active. | |||
| Header: PUT (Code=0.03) | Header: PUT (Code=0.03) | |||
| Uri-Path: ".well-known" | Uri-Path: ".well-known" | |||
| Uri-Path: "dots" | Uri-Path: "dots" | |||
| Uri-Path: "config" | Uri-Path: "config" | |||
| skipping to change at page 54, line 33 ¶ | skipping to change at page 54, line 33 ¶ | |||
| 'probing-rate', 'max-retransmit', 'target-protocol', 'ack- | 'probing-rate', 'max-retransmit', 'target-protocol', 'ack- | |||
| timeout', and 'ack-random-factor' attribute values are not | timeout', and 'ack-random-factor' attribute values are not | |||
| acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be | acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be | |||
| returned in the response. Upon receipt of this error code, the | returned in the response. Upon receipt of this error code, the | |||
| DOTS client SHOULD retrieve the maximum and minimum attribute | DOTS client SHOULD retrieve the maximum and minimum attribute | |||
| values acceptable to the DOTS server (Section 4.5.1). | values acceptable to the DOTS server (Section 4.5.1). | |||
| The DOTS client may retry and send the PUT request with updated | The DOTS client may retry and send the PUT request with updated | |||
| attribute values acceptable to the DOTS server. | attribute values acceptable to the DOTS server. | |||
| A DOTS client may issue a GET message with a 'sid' Uri-Path parameter | A DOTS client may issue a GET message for 'config' with a 'sid' Uri- | |||
| to retrieve the negotiated configuration. The response does not need | Path parameter to retrieve the negotiated configuration. The | |||
| to include 'sid' in its message body. | response does not need to include 'sid' in its message body. | |||
| 4.5.3. Configuration Freshness and Notifications | 4.5.3. Configuration Freshness and Notifications | |||
| Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a | Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a | |||
| DOTS server to associate a validity time with a configuration it | DOTS server to associate a validity time with a configuration it | |||
| sends. This feature allows the update of the configuration data if a | sends. This feature forces the client to retrieve the updated | |||
| change occurs at the DOTS server side. For example, the new | configuration data if a change occurs at the DOTS server side. For | |||
| configuration may instruct a DOTS client to cease heartbeats or | example, the new configuration may instruct a DOTS client to cease | |||
| reduce heartbeat frequency. | heartbeats or reduce heartbeat frequency. | |||
| It is NOT RECOMMENDED to return a Max-Age Option set to 0. | It is NOT RECOMMENDED to return a Max-Age Option set to 0. | |||
| Returning a Max-Age Option set to 2^(32)-1 is equivalent to | Returning a Max-Age Option set to 2^(32)-1 is equivalent to | |||
| associating an infinite lifetime with the configuration. | associating an infinite lifetime with the configuration. | |||
| If a non-zero value of Max-Age Option is received by a DOTS client, | If a non-zero value of Max-Age Option is received by a DOTS client, | |||
| it MUST issue a GET request with a 'sid' Uri-Path parameter to | it MUST issue a GET request with a 'sid' Uri-Path parameter to | |||
| retrieve the current and acceptable configuration before the expiry | retrieve the current and acceptable configuration before the expiry | |||
| of the value enclosed in the Max-Age Option. This request is | of the value enclosed in the Max-Age Option. This request is | |||
| skipping to change at page 56, line 10 ¶ | skipping to change at page 56, line 10 ¶ | |||
| Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request | Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request | |||
| to set the configuration parameters to default values. Such a | to set the configuration parameters to default values. Such a | |||
| request does not include any 'sid'. | request does not include any 'sid'. | |||
| 4.6. Redirected Signaling | 4.6. Redirected Signaling | |||
| Redirected DOTS signaling is discussed in detail in Section 3.2.2 of | Redirected DOTS signaling is discussed in detail in Section 3.2.2 of | |||
| [RFC8811]. | [RFC8811]. | |||
| If a DOTS server wants to redirect a DOTS client to an alternative | To redirect a DOTS client to an alternative DOTS server, the DOTS | |||
| DOTS server for a signal session, then the Response Code 5.03 | server can return the error Response Code 5.03 (Service Unavailable) | |||
| (Service Unavailable) will be returned in the response to the DOTS | in response to a request from the DOTS client or convey the error | |||
| Response Code 5.03 in a unidirectional notification response to the | ||||
| client. | client. | |||
| The DOTS server can return the error Response Code 5.03 in response | ||||
| to a request from the DOTS client or convey the error Response Code | ||||
| 5.03 in a unidirectional notification response from the DOTS server. | ||||
| The DOTS server in the error response conveys the alternate DOTS | The DOTS server in the error response conveys the alternate DOTS | |||
| server's FQDN, and the alternate DOTS server's IP address(es) values | server's FQDN, and the alternate DOTS server's IP address(es) values | |||
| in the CBOR body (Figure 25). | in the CBOR body (Figure 25). | |||
| { | { | |||
| "ietf-dots-signal-channel:redirected-signal": { | "ietf-dots-signal-channel:redirected-signal": { | |||
| "alt-server": "string", | "alt-server": "string", | |||
| "alt-server-record": [ | "alt-server-record": [ | |||
| "string" | "string" | |||
| ] | ] | |||
| skipping to change at page 57, line 18 ¶ | skipping to change at page 57, line 14 ¶ | |||
| a Max-Age Option may adversely impact DOTS clients on slow links. | a Max-Age Option may adversely impact DOTS clients on slow links. | |||
| Returning short values should be avoided under such conditions. | Returning short values should be avoided under such conditions. | |||
| If the alternate DOTS server TTL has expired, the DOTS client MUST | If the alternate DOTS server TTL has expired, the DOTS client MUST | |||
| use the DOTS server(s) that was provisioned using means discussed in | use the DOTS server(s) that was provisioned using means discussed in | |||
| Section 4.1. This fallback mechanism is triggered immediately upon | Section 4.1. This fallback mechanism is triggered immediately upon | |||
| expiry of the TTL, except when a DDoS attack is active. | expiry of the TTL, except when a DDoS attack is active. | |||
| Requests issued by misbehaving DOTS clients that do not honor the TTL | Requests issued by misbehaving DOTS clients that do not honor the TTL | |||
| conveyed in the Max-Age Option or react to explicit redirect messages | conveyed in the Max-Age Option or react to explicit redirect messages | |||
| can be rejected by DOTS servers. | MAY be rejected by DOTS servers. | |||
| Figure 26 shows a 5.03 response example to convey the DOTS alternate | Figure 26 shows a 5.03 response example to convey the DOTS alternate | |||
| server 'alt-server.example' together with its IP addresses | server 'alt-server.example' together with its IP addresses | |||
| 2001:db8:6401::1 and 2001:db8:6401::2. | 2001:db8:6401::1 and 2001:db8:6401::2. | |||
| { | { | |||
| "ietf-dots-signal-channel:redirected-signal": { | "ietf-dots-signal-channel:redirected-signal": { | |||
| "alt-server": "alt-server.example", | "alt-server": "alt-server.example", | |||
| "alt-server-record": [ | "alt-server-record": [ | |||
| "2001:db8:6401::1", | "2001:db8:6401::1", | |||
| skipping to change at page 57, line 44 ¶ | skipping to change at page 57, line 40 ¶ | |||
| Figure 26: Example of Redirected Server Error Response Body | Figure 26: Example of Redirected Server Error Response Body | |||
| When the DOTS client receives a 5.03 response with an alternate | When the DOTS client receives a 5.03 response with an alternate | |||
| server included, it considers the current request to have failed, but | server included, it considers the current request to have failed, but | |||
| it SHOULD try resending the request to the alternate DOTS server. | it SHOULD try resending the request to the alternate DOTS server. | |||
| During a DDoS attack, the DNS server may be the target of another | During a DDoS attack, the DNS server may be the target of another | |||
| DDoS attack, the alternate DOTS server's IP addresses conveyed in the | DDoS attack, the alternate DOTS server's IP addresses conveyed in the | |||
| 5.03 response help the DOTS client skip the DNS lookup of the | 5.03 response help the DOTS client skip the DNS lookup of the | |||
| alternate DOTS server, at the cost of trusting the first DOTS server | alternate DOTS server, at the cost of trusting the first DOTS server | |||
| to provide accurate information. The DOTS client can then try to | to provide accurate information. The DOTS client can then try to | |||
| establish a UDP or a TCP session with the alternate DOTS server. The | establish a UDP or a TCP session with the alternate DOTS server | |||
| DOTS client MAY implement a method to construct IPv4-embedded IPv6 | (Section 4.3). Note that state synchronization (e.g., signal session | |||
| configuration, aliases) is assumed to be in place between the | ||||
| original and alternate DOTS servers; such synchronization means are | ||||
| out of scope. If session configuration refresh is needed while | ||||
| redirection is in place, the DOTS client follows the procedure | ||||
| defined in Section 4.5.3. In 'idle' time and under some conditions | ||||
| (e.g., infinite configuration lifetime, infinite redirection TTL, and | ||||
| failure to refresh the configuration), the DOTS client follows the | ||||
| procedure defined in Section 4.5.2 to negotiate the DOTS signal | ||||
| channel session configuration with the alternate server. The DOTS | ||||
| client MAY implement a method to construct IPv4-embedded IPv6 | ||||
| addresses [RFC6052]; this is required to handle the scenario where an | addresses [RFC6052]; this is required to handle the scenario where an | |||
| IPv6-only DOTS client communicates with an IPv4-only alternate DOTS | IPv6-only DOTS client communicates with an IPv4-only alternate DOTS | |||
| server. | server. | |||
| If the DOTS client has been redirected to a DOTS server with which it | If the DOTS client has been redirected to a DOTS server with which it | |||
| has already communicated within the last five (5) minutes, it MUST | has already communicated within the last five (5) minutes, it MUST | |||
| ignore the redirection and try to contact other DOTS servers listed | ignore the redirection and try to contact other DOTS servers listed | |||
| in the local configuration or discovered using dynamic means such as | in the local configuration or discovered using dynamic means such as | |||
| DHCP or SRV procedures [I-D.ietf-dots-server-discovery]. It is | DHCP or SRV procedures [RFC8973]. It is RECOMMENDED that DOTS | |||
| RECOMMENDED that DOTS clients support the means to alert | clients support the means to alert administrators about redirect | |||
| administrators about redirect loops. | loops. | |||
| 4.7. Heartbeat Mechanism | 4.7. Heartbeat Mechanism | |||
| To provide an indication of signal health and to distinguish an | To provide an indication of signal health and to distinguish an | |||
| 'idle' signal channel from a 'disconnected' or 'defunct' session, the | 'idle' signal channel from a 'disconnected' or 'defunct' session, the | |||
| DOTS agent sends a heartbeat over the signal channel to maintain its | DOTS agent sends a heartbeat over the signal channel to maintain its | |||
| half of the channel (also, aligned with the "consents" recommendation | half of the channel (also, aligned with the "consents" recommendation | |||
| in Section 6 of [RFC8085]). The DOTS agent similarly expects a | in Section 6 of [RFC8085]). The DOTS agent similarly expects a | |||
| heartbeat from its peer DOTS agent, and it may consider a session | heartbeat from its peer DOTS agent, and it may consider a session | |||
| terminated in the prolonged absence of a peer agent heartbeat. | terminated in the prolonged absence of a peer agent heartbeat. | |||
| skipping to change at page 59, line 12 ¶ | skipping to change at page 59, line 26 ¶ | |||
| Figure 27: PUT to Check Peer DOTS Agent Is Responding | Figure 27: PUT to Check Peer DOTS Agent Is Responding | |||
| The mandatory 'peer-hb-status' attribute is set to 'true' (or | The mandatory 'peer-hb-status' attribute is set to 'true' (or | |||
| 'false') to indicate that a DOTS agent is (or is not) receiving | 'false') to indicate that a DOTS agent is (or is not) receiving | |||
| heartbeat messages from its peer in the last (2 * 'heartbeat- | heartbeat messages from its peer in the last (2 * 'heartbeat- | |||
| interval') period. Such information can be used by a peer DOTS agent | interval') period. Such information can be used by a peer DOTS agent | |||
| to detect or confirm connectivity issues and react accordingly. For | to detect or confirm connectivity issues and react accordingly. For | |||
| example, if a DOTS client receives a 2.04 response for its heartbeat | example, if a DOTS client receives a 2.04 response for its heartbeat | |||
| messages but no server-initiated heartbeat messages, the DOTS client | messages but no server-initiated heartbeat messages, the DOTS client | |||
| sets 'peer-hb-status' to 'false'. The DOTS server then will need to | sets 'peer-hb-status' to 'false' in its next heartbeat message. Upon | |||
| try another strategy for sending the heartbeats (e.g., adjust the | receipt of this message, the DOTS server then will need to try | |||
| another strategy for sending the heartbeats (e.g., adjust the | ||||
| heartbeat interval or send a server-initiated heartbeat immediately | heartbeat interval or send a server-initiated heartbeat immediately | |||
| after receiving a client-initiated heartbeat message). | after receiving a client-initiated heartbeat message). | |||
| Header: (Code=2.04) | Header: (Code=2.04) | |||
| Figure 28: Response to a DOTS Heartbeat Request | Figure 28: Response to a DOTS Heartbeat Request (with an Empty Body) | |||
| DOTS servers MAY trigger their heartbeat requests immediately after | DOTS servers MAY trigger their heartbeat requests immediately after | |||
| receiving heartbeat probes from peer DOTS clients. As a reminder, it | receiving heartbeat probes from peer DOTS clients. It is the | |||
| is the responsibility of DOTS clients to ensure that on-path | responsibility of DOTS clients to ensure that on-path translators/ | |||
| translators/firewalls are maintaining a binding so that the same | firewalls are maintaining a binding so that the same external IP | |||
| external IP address and/or port number is retained for the DOTS | address and/or port number is retained for the DOTS signal channel | |||
| signal channel session. | session. | |||
| Under normal traffic conditions (i.e., no attack is ongoing), if a | Under normal traffic conditions (i.e., no attack is ongoing), if a | |||
| DOTS agent does not receive any response from the peer DOTS agent for | DOTS agent does not receive any response from the peer DOTS agent for | |||
| 'missing-hb-allowed' number of consecutive heartbeat messages, it | 'missing-hb-allowed' number of consecutive heartbeat messages, it | |||
| concludes that the DOTS signal channel session is disconnected. The | concludes that the DOTS signal channel session is disconnected. The | |||
| DOTS client MUST then try to reestablish the DOTS signal channel | DOTS client MUST then try to reestablish the DOTS signal channel | |||
| session, preferably by resuming the (D)TLS session. | session, preferably by resuming the (D)TLS session. | |||
| | Note: If a new DOTS signal channel session cannot be | | Note: If a new DOTS signal channel session cannot be | |||
| | established, the DOTS client SHOULD NOT retry to establish the | | established, the DOTS client SHOULD NOT retry to establish the | |||
| skipping to change at page 64, line 15 ¶ | skipping to change at page 64, line 31 ¶ | |||
| | | +-- current-value-decimal? decimal64 | | | +-- current-value-decimal? decimal64 | |||
| | +-- ack-random-factor | | +-- ack-random-factor | |||
| | +-- (direction)? | | +-- (direction)? | |||
| | | +--:(server-to-client-only) | | | +--:(server-to-client-only) | |||
| | | +-- max-value-decimal? decimal64 | | | +-- max-value-decimal? decimal64 | |||
| | | +-- min-value-decimal? decimal64 | | | +-- min-value-decimal? decimal64 | |||
| | +-- current-value-decimal? decimal64 | | +-- current-value-decimal? decimal64 | |||
| +--:(redirected-signal) | +--:(redirected-signal) | |||
| | +-- (direction)? | | +-- (direction)? | |||
| | +--:(server-to-client-only) | | +--:(server-to-client-only) | |||
| | +-- alt-server string | | +-- alt-server inet:domain-name | |||
| | +-- alt-server-record* inet:ip-address | | +-- alt-server-record* inet:ip-address | |||
| +--:(heartbeat) | +--:(heartbeat) | |||
| +-- peer-hb-status boolean | +-- peer-hb-status boolean | |||
| 5.2. IANA DOTS Signal Channel YANG Module | 5.2. IANA DOTS Signal Channel YANG Module | |||
| This version obsoletes the version described in Section 5.2 of | This version obsoletes the version described in Section 5.2 of | |||
| [RFC8782]. | [RFC8782]. | |||
| <CODE BEGINS> file "iana-dots-signal-channel@2020-09-24.yang" | <CODE BEGINS> file "iana-dots-signal-channel@2020-09-24.yang" | |||
| skipping to change at page 64, line 35 ¶ | skipping to change at page 65, line 4 ¶ | |||
| <CODE BEGINS> file "iana-dots-signal-channel@2020-09-24.yang" | <CODE BEGINS> file "iana-dots-signal-channel@2020-09-24.yang" | |||
| module iana-dots-signal-channel { | module iana-dots-signal-channel { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; | namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; | |||
| prefix iana-dots-signal; | prefix iana-dots-signal; | |||
| organization | organization | |||
| "IANA"; | "IANA"; | |||
| contact | contact | |||
| "Internet Assigned Numbers Authority | "Internet Assigned Numbers Authority | |||
| Postal: ICANN | Postal: ICANN | |||
| 12025 Waterfront Drive, Suite 300 | 12025 Waterfront Drive, Suite 300 | |||
| Los Angeles, CA 90094-2536 | Los Angeles, CA 90094-2536 | |||
| United States of America | United States of America | |||
| Tel: +1 310 301 5800 | Tel: +1 310 301 5800 | |||
| <mailto:iana@iana.org>"; | <mailto:iana@iana.org>"; | |||
| description | description | |||
| "This module contains a collection of YANG data types defined | "This module contains a collection of YANG data types defined | |||
| by IANA and used for DOTS signal channel protocol. | by IANA and used for DOTS signal channel protocol. | |||
| Copyright (c) 2020 IETF Trust and the persons identified as | Copyright (c) 2021 IETF Trust and the persons identified as | |||
| authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
| Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
| without modification, is permitted pursuant to, and subject | without modification, is permitted pursuant to, and subject | |||
| to the license terms contained in, the Simplified BSD License | to the license terms contained in, the Simplified BSD License | |||
| set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
| Relating to IETF Documents | Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info). | |||
| This version of this YANG module is part of RFC 8782; see | This version of this YANG module is part of RFC 8782; see | |||
| skipping to change at page 68, line 28 ¶ | skipping to change at page 68, line 44 ¶ | |||
| <CODE ENDS> | <CODE ENDS> | |||
| 5.3. IETF DOTS Signal Channel YANG Module | 5.3. IETF DOTS Signal Channel YANG Module | |||
| This module uses the common YANG types defined in [RFC6991] and types | This module uses the common YANG types defined in [RFC6991] and types | |||
| defined in [RFC8783]. | defined in [RFC8783]. | |||
| This version obsoletes the version described in Section 5.3 of | This version obsoletes the version described in Section 5.3 of | |||
| [RFC8782]. | [RFC8782]. | |||
| <CODE BEGINS> file "ietf-dots-signal-channel@2020-09-24.yang" | <CODE BEGINS> file "ietf-dots-signal-channel@2021-03-02.yang" | |||
| module ietf-dots-signal-channel { | module ietf-dots-signal-channel { | |||
| yang-version 1.1; | yang-version 1.1; | |||
| namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; | namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; | |||
| prefix dots-signal; | prefix dots-signal; | |||
| import ietf-inet-types { | ||||
| prefix inet; | ||||
| reference | ||||
| "Section 4 of RFC 6991"; | ||||
| } | ||||
| import ietf-yang-types { | ||||
| prefix yang; | ||||
| reference | ||||
| "Section 3 of RFC 6991"; | ||||
| } | ||||
| import ietf-dots-data-channel { | ||||
| prefix data-channel; | ||||
| reference | ||||
| "RFC 8783: Distributed Denial-of-Service Open Threat Signaling | ||||
| (DOTS) Data Channel Specification"; | ||||
| } | ||||
| import iana-dots-signal-channel { | ||||
| prefix iana-dots-signal; | ||||
| reference | ||||
| "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling | ||||
| (DOTS) Signal Channel Specification"; | ||||
| } | ||||
| import ietf-yang-structure-ext { | ||||
| prefix sx; | ||||
| reference | ||||
| "RFC 8791: YANG Data Structure Extensions"; | ||||
| } | ||||
| organization | import ietf-inet-types { | |||
| "IETF DDoS Open Threat Signaling (DOTS) Working Group"; | prefix inet; | |||
| contact | reference | |||
| "WG Web: <https://datatracker.ietf.org/wg/dots/> | "Section 4 of RFC 6991"; | |||
| WG List: <mailto:dots@ietf.org> | } | |||
| import ietf-yang-types { | ||||
| prefix yang; | ||||
| reference | ||||
| "Section 3 of RFC 6991"; | ||||
| } | ||||
| import ietf-dots-data-channel { | ||||
| prefix data-channel; | ||||
| reference | ||||
| "RFC 8783: Distributed Denial-of-Service Open Threat Signaling | ||||
| (DOTS) Data Channel Specification"; | ||||
| } | ||||
| import iana-dots-signal-channel { | ||||
| prefix iana-dots-signal; | ||||
| reference | ||||
| "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling | ||||
| (DOTS) Signal Channel Specification"; | ||||
| } | ||||
| import ietf-yang-structure-ext { | ||||
| prefix sx; | ||||
| reference | ||||
| "RFC 8791: YANG Data Structure Extensions"; | ||||
| } | ||||
| Editor: Mohamed Boucadair | organization | |||
| <mailto:mohamed.boucadair@orange.com> | "IETF DDoS Open Threat Signaling (DOTS) Working Group"; | |||
| contact | ||||
| "WG Web: <https://datatracker.ietf.org/wg/dots/> | ||||
| WG List: <mailto:dots@ietf.org> | ||||
| Editor: Jon Shallow | Editor: Mohamed Boucadair | |||
| <mailto:supjps-ietf@jpshallow.com> | <mailto:mohamed.boucadair@orange.com> | |||
| Author: Konda, Tirumaleswar Reddy.K | Editor: Jon Shallow | |||
| <mailto:TirumaleswarReddy_Konda@McAfee.com> | <mailto:supjps-ietf@jpshallow.com> | |||
| Author: Prashanth Patil | Author: Konda, Tirumaleswar Reddy.K | |||
| <mailto:praspati@cisco.com> | <mailto:TirumaleswarReddy_Konda@McAfee.com> | |||
| Author: Andrew Mortensen | Author: Prashanth Patil | |||
| <mailto:amortensen@arbor.net> | <mailto:praspati@cisco.com> | |||
| Author: Nik Teague | Author: Andrew Mortensen | |||
| <mailto:nteague@ironmountain.co.uk>"; | <mailto:amortensen@arbor.net> | |||
| description | ||||
| "This module contains YANG definition for the signaling | ||||
| messages exchanged between a DOTS client and a DOTS server. | ||||
| Copyright (c) 2020 IETF Trust and the persons identified as | Author: Nik Teague | |||
| authors of the code. All rights reserved. | <mailto:nteague@ironmountain.co.uk>"; | |||
| description | ||||
| "This module contains YANG definition for the signaling | ||||
| messages exchanged between a DOTS client and a DOTS server. | ||||
| Redistribution and use in source and binary forms, with or | Copyright (c) 2021 IETF Trust and the persons identified as | |||
| without modification, is permitted pursuant to, and subject | authors of the code. All rights reserved. | |||
| to the license terms contained in, the Simplified BSD License | ||||
| set forth in Section 4.c of the IETF Trust's Legal Provisions | ||||
| Relating to IETF Documents | ||||
| (http://trustee.ietf.org/license-info). | ||||
| This version of this YANG module is part of RFC XXXX; see | Redistribution and use in source and binary forms, with or | |||
| the RFC itself for full legal notices."; | without modification, is permitted pursuant to, and subject | |||
| to the license terms contained in, the Simplified BSD License | ||||
| set forth in Section 4.c of the IETF Trust's Legal Provisions | ||||
| Relating to IETF Documents | ||||
| (http://trustee.ietf.org/license-info). | ||||
| revision 2020-09-24 { | This version of this YANG module is part of RFC XXXX; see | |||
| description | the RFC itself for full legal notices."; | |||
| "Updated revision to comply with RFC8791."; | ||||
| reference | ||||
| "RFC XXXX: Distributed Denial-of-Service Open Threat | ||||
| Signaling (DOTS) Signal Channel Specification"; | ||||
| } | ||||
| revision 2020-05-28 { | ||||
| description | ||||
| "Initial revision."; | ||||
| reference | ||||
| "RFC 8782: Distributed Denial-of-Service Open Threat | ||||
| Signaling (DOTS) Signal Channel Specification"; | ||||
| } | ||||
| /* | revision 2021-03-02 { | |||
| * Groupings | description | |||
| */ | "Updated revision to comply with RFC8791. | |||
| grouping mitigation-scope { | This version is not backward compatible with the version | |||
| description | published in RFC 8782."; | |||
| "Specifies the scope of the mitigation request."; | reference | |||
| list scope { | "RFC XXXX: Distributed Denial-of-Service Open Threat | |||
| description | Signaling (DOTS) Signal Channel Specification"; | |||
| "The scope of the request."; | } | |||
| uses data-channel:target; | revision 2020-05-28 { | |||
| leaf-list alias-name { | description | |||
| type string; | "Initial revision."; | |||
| description | reference | |||
| "An alias name that points to a resource."; | "RFC 8782: Distributed Denial-of-Service Open Threat | |||
| } | Signaling (DOTS) Signal Channel Specification"; | |||
| leaf lifetime { | } | |||
| type union { | ||||
| type uint32; | ||||
| type int32 { | ||||
| range "-1"; | ||||
| } | ||||
| } | ||||
| units "seconds"; | ||||
| default "3600"; | ||||
| description | ||||
| "Indicates the lifetime of the mitigation request. | ||||
| A lifetime of '0' in a mitigation request is an | /* | |||
| invalid value. | * Groupings | |||
| */ | ||||
| A lifetime of negative one (-1) indicates indefinite | grouping mitigation-scope { | |||
| lifetime for the mitigation request. | description | |||
| "Specifies the scope of the mitigation request."; | ||||
| list scope { | ||||
| description | ||||
| "The scope of the request."; | ||||
| uses data-channel:target; | ||||
| leaf-list alias-name { | ||||
| type string; | ||||
| description | ||||
| "An alias name that points to a resource."; | ||||
| } | ||||
| leaf lifetime { | ||||
| type union { | ||||
| type uint32; | ||||
| type int32 { | ||||
| range "-1"; | ||||
| } | ||||
| } | ||||
| units "seconds"; | ||||
| default "3600"; | ||||
| description | ||||
| "Indicates the lifetime of the mitigation request. | ||||
| Lifetime is mandatory in a mitigation request. | A lifetime of '0' in a mitigation request is an | |||
| invalid value. | ||||
| The DOTS server must always indicate the actual lifetime | A lifetime of negative one (-1) indicates indefinite | |||
| in the response to an accepted mitigation request and the | lifetime for the mitigation request. | |||
| remaining lifetime in status messages sent to the | ||||
| DOTS client."; | ||||
| } | ||||
| leaf trigger-mitigation { | ||||
| type boolean; | ||||
| default "true"; | ||||
| description | ||||
| "If set to 'false', DDoS mitigation will not be | ||||
| triggered unless the DOTS signal channel | ||||
| session is lost."; | ||||
| } | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf mid { | ||||
| type uint32; | ||||
| description | ||||
| "Mitigation request identifier. | ||||
| This identifier must be unique for each mitigation | Lifetime is mandatory in a mitigation request. | |||
| request bound to the DOTS client."; | ||||
| } | ||||
| leaf mitigation-start { | ||||
| type uint64; | ||||
| description | ||||
| "Mitigation start time is represented in seconds | ||||
| relative to 1970-01-01T00:00:00Z in UTC time. | ||||
| This is a mandatory attribute when an attack mitigation | The DOTS server must always indicate the actual lifetime | |||
| is active. It must not be returned for a | in the response to an accepted mitigation request and the | |||
| mitigation with 'status' code set to 8."; | remaining lifetime in status messages sent to the | |||
| } | DOTS client."; | |||
| leaf status { | } | |||
| type iana-dots-signal:status; | leaf trigger-mitigation { | |||
| description | type boolean; | |||
| "Indicates the status of a mitigation request. | default "true"; | |||
| description | ||||
| "If set to 'false', DDoS mitigation will not be | ||||
| triggered unless the DOTS signal channel | ||||
| session is lost."; | ||||
| } | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf mid { | ||||
| type uint32; | ||||
| description | ||||
| "Mitigation request identifier. | ||||
| It must be included in responses only. | This identifier must be unique for each mitigation | |||
| request bound to the DOTS client."; | ||||
| } | ||||
| leaf mitigation-start { | ||||
| type uint64; | ||||
| description | ||||
| "Mitigation start time is represented in seconds | ||||
| relative to 1970-01-01T00:00:00Z in UTC time. | ||||
| This is a mandatory attribute if a mitigation | This is a mandatory attribute when an attack mitigation | |||
| request is accepted and processed by the server."; | is active. It must not be returned for a | |||
| } | mitigation with 'status' code set to 8."; | |||
| container conflict-information { | } | |||
| description | leaf status { | |||
| "Indicates that a conflict is detected. | type iana-dots-signal:status; | |||
| Must only be used for responses."; | description | |||
| leaf conflict-status { | "Indicates the status of a mitigation request. | |||
| type iana-dots-signal:conflict-status; | It must be included in responses only. | |||
| description | ||||
| "Indicates the conflict status."; | ||||
| } | ||||
| leaf conflict-cause { | ||||
| type iana-dots-signal:conflict-cause; | ||||
| description | ||||
| "Indicates the cause of the conflict."; | ||||
| } | ||||
| leaf retry-timer { | ||||
| type uint32; | ||||
| units "seconds"; | ||||
| description | ||||
| "The DOTS client must not resend the | ||||
| same request that has a conflict before the expiry of | ||||
| this timer."; | ||||
| } | ||||
| container conflict-scope { | ||||
| description | ||||
| "Provides more information about the conflict scope."; | ||||
| uses data-channel:target { | ||||
| when "/dots-signal/scope/conflict-information/" | ||||
| + "conflict-cause = 'overlapping-targets'"; | ||||
| } | ||||
| leaf-list alias-name { | ||||
| when "../../conflict-cause = 'overlapping-targets'"; | ||||
| type string; | ||||
| description | ||||
| "Conflicting alias-name."; | ||||
| } | ||||
| list acl-list { | ||||
| when "../../conflict-cause =" | ||||
| + " 'conflict-with-acceptlist'"; | ||||
| key "acl-name"; | ||||
| description | ||||
| "List of conflicting ACLs as defined in the DOTS data | ||||
| channel. These ACLs are uniquely defined by | ||||
| cuid and acl-name."; | ||||
| leaf acl-name { | This is a mandatory attribute if a mitigation | |||
| type leafref { | request is accepted and processed by the server."; | |||
| path "/data-channel:dots-data/data-channel:dots-client/" | } | |||
| + "data-channel:acls/data-channel:acl/data-channel:name"; | container conflict-information { | |||
| } | description | |||
| description | "Indicates that a conflict is detected."; | |||
| "Reference to the conflicting ACL name bound to | leaf conflict-status { | |||
| a DOTS client."; | type iana-dots-signal:conflict-status; | |||
| } | description | |||
| leaf acl-type { | "Indicates the conflict status."; | |||
| type leafref { | } | |||
| path "/data-channel:dots-data/data-channel:dots-client/" | leaf conflict-cause { | |||
| + "data-channel:acls/data-channel:acl/data-channel:type"; | type iana-dots-signal:conflict-cause; | |||
| } | description | |||
| description | "Indicates the cause of the conflict."; | |||
| "Reference to the conflicting ACL type bound to | } | |||
| a DOTS client."; | leaf retry-timer { | |||
| } | type uint32; | |||
| } | units "seconds"; | |||
| leaf mid { | description | |||
| when "../../conflict-cause = 'overlapping-targets'"; | "The DOTS client must not resend the | |||
| type uint32; | same request that has a conflict before the expiry of | |||
| description | this timer."; | |||
| "Reference to the conflicting 'mid' bound to | } | |||
| the same DOTS client."; | container conflict-scope { | |||
| } | description | |||
| } | "Provides more information about the conflict scope."; | |||
| } | ||||
| leaf bytes-dropped { | ||||
| type yang:zero-based-counter64; | ||||
| units "bytes"; | ||||
| description | ||||
| "The total dropped byte count for the mitigation | ||||
| request since the attack mitigation was triggered. | ||||
| The count wraps around when it reaches the maximum value | ||||
| of counter64 for dropped bytes."; | ||||
| } | ||||
| leaf bps-dropped { | ||||
| type yang:gauge64; | ||||
| description | ||||
| "The average number of dropped bits per second for | ||||
| the mitigation request since the attack | ||||
| mitigation was triggered. This should be over | ||||
| five-minute intervals (that is, measuring bytes | ||||
| into five-minute buckets and then averaging these | ||||
| buckets over the time since the mitigation was | ||||
| triggered)."; | ||||
| } | ||||
| leaf pkts-dropped { | ||||
| type yang:zero-based-counter64; | ||||
| description | ||||
| "The total number of dropped packet count for the | ||||
| mitigation request since the attack mitigation was | ||||
| triggered. The count wraps around when it reaches | ||||
| the maximum value of counter64 for dropped packets."; | ||||
| } | ||||
| leaf pps-dropped { | ||||
| type yang:gauge64; | ||||
| description | ||||
| "The average number of dropped packets per second | ||||
| for the mitigation request since the attack | ||||
| mitigation was triggered. This should be over | ||||
| five-minute intervals (that is, measuring packets | ||||
| into five-minute buckets and then averaging these | ||||
| buckets over the time since the mitigation was | ||||
| triggered)."; | ||||
| } | ||||
| } | ||||
| case client-to-server-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the client to the server."; | ||||
| leaf attack-status { | ||||
| type iana-dots-signal:attack-status; | ||||
| description | ||||
| "Indicates the status of an attack as seen by the | ||||
| DOTS client. | ||||
| Ths is is a mandatory attribute when a client | uses data-channel:target { | |||
| performs an efficacy update."; | when "/dots-signal/scope/conflict-information/" | |||
| } | + "conflict-cause = 'overlapping-targets'"; | |||
| } | } | |||
| } | leaf-list alias-name { | |||
| } | when "../../conflict-cause = 'overlapping-targets'"; | |||
| } | type string; | |||
| description | ||||
| "Conflicting alias-name."; | ||||
| } | ||||
| list acl-list { | ||||
| when "../../conflict-cause =" | ||||
| + " 'conflict-with-acceptlist'"; | ||||
| key "acl-name"; | ||||
| description | ||||
| "List of conflicting ACLs as defined in the DOTS data | ||||
| channel. These ACLs are uniquely defined by | ||||
| cuid and acl-name."; | ||||
| leaf acl-name { | ||||
| type leafref { | ||||
| path "/data-channel:dots-data" | ||||
| + "/data-channel:dots-client/data-channel:acls" | ||||
| + "/data-channel:acl/data-channel:name"; | ||||
| } | ||||
| description | ||||
| "Reference to the conflicting ACL name bound to | ||||
| a DOTS client."; | ||||
| } | ||||
| leaf acl-type { | ||||
| type leafref { | ||||
| path "/data-channel:dots-data" | ||||
| + "/data-channel:dots-client/data-channel:acls" | ||||
| + "/data-channel:acl/data-channel:type"; | ||||
| } | ||||
| description | ||||
| "Reference to the conflicting ACL type bound to | ||||
| a DOTS client."; | ||||
| } | ||||
| } | ||||
| leaf mid { | ||||
| when "../../conflict-cause = 'overlapping-targets'"; | ||||
| type uint32; | ||||
| description | ||||
| "Reference to the conflicting 'mid' bound to | ||||
| the same DOTS client."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf bytes-dropped { | ||||
| type yang:zero-based-counter64; | ||||
| units "bytes"; | ||||
| description | ||||
| "The total dropped byte count for the mitigation | ||||
| request since the attack mitigation was triggered. | ||||
| The count wraps around when it reaches the maximum value | ||||
| of counter64 for dropped bytes."; | ||||
| } | ||||
| leaf bps-dropped { | ||||
| type yang:gauge64; | ||||
| units "bytes per second"; | ||||
| description | ||||
| "The average number of dropped bytes per second for | ||||
| the mitigation request since the attack | ||||
| mitigation was triggered. This should be over | ||||
| five-minute intervals (that is, measuring bytes | ||||
| into five-minute buckets and then averaging these | ||||
| buckets over the time since the mitigation was | ||||
| triggered)."; | ||||
| } | ||||
| leaf pkts-dropped { | ||||
| type yang:zero-based-counter64; | ||||
| description | ||||
| "The total number of dropped packet count for the | ||||
| mitigation request since the attack mitigation was | ||||
| triggered. The count wraps around when it reaches | ||||
| the maximum value of counter64 for dropped packets."; | ||||
| } | ||||
| leaf pps-dropped { | ||||
| type yang:gauge64; | ||||
| units "packets per second"; | ||||
| description | ||||
| "The average number of dropped packets per second | ||||
| for the mitigation request since the attack | ||||
| mitigation was triggered. This should be over | ||||
| five-minute intervals (that is, measuring packets | ||||
| into five-minute buckets and then averaging these | ||||
| buckets over the time since the mitigation was | ||||
| triggered)."; | ||||
| } | ||||
| } | ||||
| case client-to-server-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the client to the server."; | ||||
| leaf attack-status { | ||||
| type iana-dots-signal:attack-status; | ||||
| description | ||||
| "Indicates the status of an attack as seen by the | ||||
| DOTS client. | ||||
| grouping config-parameters { | This is a mandatory attribute when a client | |||
| description | performs an efficacy update."; | |||
| "Subset of DOTS signal channel session configuration."; | } | |||
| container heartbeat-interval { | } | |||
| description | } | |||
| "DOTS agents regularly send heartbeats to each other | } | |||
| after mutual authentication is successfully | } | |||
| completed in order to keep the DOTS signal channel | ||||
| open."; | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value { | ||||
| type uint16; | ||||
| units "seconds"; | ||||
| description | ||||
| "Maximum acceptable heartbeat-interval value."; | ||||
| } | ||||
| leaf min-value { | ||||
| type uint16; | ||||
| units "seconds"; | ||||
| description | ||||
| "Minimum acceptable heartbeat-interval value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value { | ||||
| type uint16; | ||||
| units "seconds"; | ||||
| default "30"; | ||||
| description | ||||
| "Current heartbeat-interval value. | ||||
| '0' means that heartbeat mechanism is deactivated."; | grouping config-parameters { | |||
| } | description | |||
| } | "Subset of DOTS signal channel session configuration."; | |||
| container missing-hb-allowed { | container heartbeat-interval { | |||
| description | description | |||
| "Maximum number of missing heartbeats allowed."; | "DOTS agents regularly send heartbeats to each other | |||
| choice direction { | after mutual authentication is successfully | |||
| description | completed in order to keep the DOTS signal channel | |||
| "Indicates the communication direction in which the | open."; | |||
| data nodes can be included."; | choice direction { | |||
| case server-to-client-only { | description | |||
| description | "Indicates the communication direction in which the | |||
| "These data nodes appear only in a mitigation message | data nodes can be included."; | |||
| sent from the server to the client."; | case server-to-client-only { | |||
| leaf max-value { | description | |||
| type uint16; | "These data nodes appear only in a mitigation message | |||
| description | sent from the server to the client."; | |||
| "Maximum acceptable missing-hb-allowed value."; | leaf max-value { | |||
| } | type uint16; | |||
| leaf min-value { | units "seconds"; | |||
| type uint16; | description | |||
| description | "Maximum acceptable heartbeat-interval value."; | |||
| "Minimum acceptable missing-hb-allowed value."; | } | |||
| } | leaf min-value { | |||
| } | type uint16; | |||
| } | units "seconds"; | |||
| leaf current-value { | description | |||
| type uint16; | "Minimum acceptable heartbeat-interval value."; | |||
| default "15"; | } | |||
| description | } | |||
| "Current missing-hb-allowed value."; | } | |||
| } | leaf current-value { | |||
| } | type uint16; | |||
| container probing-rate { | units "seconds"; | |||
| description | default "30"; | |||
| "The limit for sending Non-confirmable messages with | description | |||
| no response."; | "Current heartbeat-interval value. | |||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value { | ||||
| type uint16; | ||||
| units "byte/second"; | ||||
| description | ||||
| "Maximum acceptable probing-rate value."; | ||||
| } | ||||
| leaf min-value { | ||||
| type uint16; | ||||
| units "byte/second"; | ||||
| description | ||||
| "Minimum acceptable probing-rate value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value { | ||||
| type uint16; | ||||
| units "byte/second"; | ||||
| default "5"; | ||||
| description | ||||
| "Current probing-rate value."; | ||||
| } | ||||
| } | ||||
| container max-retransmit { | ||||
| description | ||||
| "Maximum number of retransmissions of a Confirmable | ||||
| message."; | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value { | ||||
| type uint16; | ||||
| description | ||||
| "Maximum acceptable max-retransmit value."; | ||||
| } | ||||
| leaf min-value { | ||||
| type uint16; | ||||
| description | ||||
| "Minimum acceptable max-retransmit value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value { | ||||
| type uint16; | ||||
| default "3"; | ||||
| description | ||||
| "Current max-retransmit value."; | ||||
| } | ||||
| } | ||||
| container ack-timeout { | ||||
| description | ||||
| "Initial retransmission timeout value."; | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| units "seconds"; | ||||
| description | ||||
| "Maximum ack-timeout value."; | ||||
| } | '0' means that heartbeat mechanism is deactivated."; | |||
| leaf min-value-decimal { | } | |||
| type decimal64 { | } | |||
| fraction-digits 2; | container missing-hb-allowed { | |||
| } | description | |||
| units "seconds"; | "Maximum number of missing heartbeats allowed."; | |||
| description | choice direction { | |||
| "Minimum ack-timeout value."; | description | |||
| } | "Indicates the communication direction in which the | |||
| } | data nodes can be included."; | |||
| } | case server-to-client-only { | |||
| leaf current-value-decimal { | description | |||
| type decimal64 { | "These data nodes appear only in a mitigation message | |||
| fraction-digits 2; | sent from the server to the client."; | |||
| } | leaf max-value { | |||
| units "seconds"; | type uint16; | |||
| default "2"; | description | |||
| description | "Maximum acceptable missing-hb-allowed value."; | |||
| "Current ack-timeout value."; | } | |||
| } | leaf min-value { | |||
| } | type uint16; | |||
| container ack-random-factor { | description | |||
| description | "Minimum acceptable missing-hb-allowed value."; | |||
| "Random factor used to influence the timing of | } | |||
| retransmissions."; | } | |||
| choice direction { | } | |||
| description | leaf current-value { | |||
| "Indicates the communication direction in which the | type uint16; | |||
| data nodes can be included."; | default "15"; | |||
| case server-to-client-only { | description | |||
| description | "Current missing-hb-allowed value."; | |||
| "These data nodes appear only in a mitigation message | } | |||
| sent from the server to the client."; | } | |||
| leaf max-value-decimal { | container probing-rate { | |||
| type decimal64 { | description | |||
| fraction-digits 2; | "The limit for sending Non-confirmable messages with | |||
| } | no response."; | |||
| description | choice direction { | |||
| "Maximum acceptable ack-random-factor value."; | description | |||
| } | "Indicates the communication direction in which the | |||
| leaf min-value-decimal { | data nodes can be included."; | |||
| type decimal64 { | case server-to-client-only { | |||
| fraction-digits 2; | description | |||
| } | "These data nodes appear only in a mitigation message | |||
| description | sent from the server to the client."; | |||
| "Minimum acceptable ack-random-factor value."; | leaf max-value { | |||
| } | type uint16; | |||
| } | units "byte/second"; | |||
| description | ||||
| "Maximum acceptable probing-rate value."; | ||||
| } | ||||
| leaf min-value { | ||||
| type uint16; | ||||
| units "byte/second"; | ||||
| description | ||||
| "Minimum acceptable probing-rate value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value { | ||||
| type uint16; | ||||
| units "byte/second"; | ||||
| default "5"; | ||||
| description | ||||
| "Current probing-rate value."; | ||||
| } | ||||
| } | ||||
| container max-retransmit { | ||||
| description | ||||
| "Maximum number of retransmissions of a Confirmable | ||||
| message."; | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value { | ||||
| type uint16; | ||||
| description | ||||
| "Maximum acceptable max-retransmit value."; | ||||
| } | ||||
| leaf min-value { | ||||
| type uint16; | ||||
| description | ||||
| "Minimum acceptable max-retransmit value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value { | ||||
| type uint16; | ||||
| default "3"; | ||||
| description | ||||
| "Current max-retransmit value."; | ||||
| } | ||||
| } | ||||
| container ack-timeout { | ||||
| description | ||||
| "Initial retransmission timeout value."; | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| units "seconds"; | ||||
| description | ||||
| "Maximum ack-timeout value."; | ||||
| } | ||||
| leaf min-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| units "seconds"; | ||||
| description | ||||
| "Minimum ack-timeout value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| units "seconds"; | ||||
| default "2"; | ||||
| description | ||||
| "Current ack-timeout value."; | ||||
| } | ||||
| } | ||||
| container ack-random-factor { | ||||
| description | ||||
| "Random factor used to influence the timing of | ||||
| retransmissions."; | ||||
| choice direction { | ||||
| description | ||||
| "Indicates the communication direction in which the | ||||
| data nodes can be included."; | ||||
| case server-to-client-only { | ||||
| description | ||||
| "These data nodes appear only in a mitigation message | ||||
| sent from the server to the client."; | ||||
| leaf max-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| description | ||||
| "Maximum acceptable ack-random-factor value."; | ||||
| } | ||||
| leaf min-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| description | ||||
| "Minimum acceptable ack-random-factor value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| leaf current-value-decimal { | ||||
| type decimal64 { | ||||
| fraction-digits 2; | ||||
| } | ||||
| default "1.5"; | ||||
| description | ||||
| "Current ack-random-factor value."; | ||||
| } | ||||
| } | ||||
| } | ||||
| } | grouping signal-config { | |||
| leaf current-value-decimal { | description | |||
| type decimal64 { | "DOTS signal channel session configuration."; | |||
| fraction-digits 2; | container mitigating-config { | |||
| } | description | |||
| default "1.5"; | "Configuration parameters to use when a mitigation | |||
| description | is active."; | |||
| "Current ack-random-factor value."; | uses config-parameters; | |||
| } | } | |||
| } | container idle-config { | |||
| } | description | |||
| "Configuration parameters to use when no mitigation | ||||
| is active."; | ||||
| uses config-parameters; | ||||
| grouping signal-config { | } | |||
| description | } | |||
| "DOTS signal channel session configuration."; | ||||
| container mitigating-config { | ||||
| description | ||||
| "Configuration parameters to use when a mitigation | ||||
| is active."; | ||||
| uses config-parameters; | ||||
| } | ||||
| container idle-config { | ||||
| description | ||||
| "Configuration parameters to use when no mitigation | ||||
| is active."; | ||||
| uses config-parameters; | ||||
| } | ||||
| } | ||||
| grouping redirected-signal { | grouping redirected-signal { | |||
| description | description | |||
| "Grouping for the redirected signaling."; | "Grouping for the redirected signaling."; | |||
| choice direction { | choice direction { | |||
| description | description | |||
| "Indicates the communication direction in which the | "Indicates the communication direction in which the | |||
| data nodes can be included."; | data nodes can be included."; | |||
| case server-to-client-only { | case server-to-client-only { | |||
| description | description | |||
| "These data nodes appear only in a mitigation message | "These data nodes appear only in a mitigation message | |||
| sent from the server to the client."; | sent from the server to the client."; | |||
| leaf alt-server { | leaf alt-server { | |||
| type string; | type inet:domain-name; | |||
| mandatory true; | mandatory true; | |||
| description | description | |||
| "FQDN of an alternate server."; | "FQDN of an alternate server."; | |||
| } | } | |||
| leaf-list alt-server-record { | leaf-list alt-server-record { | |||
| type inet:ip-address; | type inet:ip-address; | |||
| description | description | |||
| "List of records for the alternate server."; | "List of records for the alternate server."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| /* | /* | |||
| * DOTS Signal Channel Structure | * DOTS Signal Channel Structure | |||
| */ | */ | |||
| sx:structure dots-signal { | ||||
| description | ||||
| "Main structure for DOTS signal message. | ||||
| A DOTS signal message can be a mitigation, a configuration, | sx:structure dots-signal { | |||
| or a redirected signal message."; | description | |||
| choice message-type { | "Main structure for DOTS signal message. | |||
| description | ||||
| "Can be a mitigation, a configuration, or a redirect | ||||
| message."; | ||||
| case mitigation-scope { | ||||
| description | ||||
| "Mitigation scope of a mitigation message."; | ||||
| uses mitigation-scope; | ||||
| } | ||||
| case signal-config { | ||||
| description | ||||
| "Configuration message."; | ||||
| uses signal-config; | ||||
| } | ||||
| case redirected-signal { | ||||
| description | ||||
| "Redirected signaling."; | ||||
| uses redirected-signal; | ||||
| } | ||||
| case heartbeat { | ||||
| description | ||||
| "DOTS heartbeats."; | ||||
| leaf peer-hb-status { | ||||
| type boolean; | ||||
| mandatory true; | ||||
| description | ||||
| "Indicates whether a DOTS agent receives heartbeats | ||||
| from its peer. The value is set to 'true' if the | ||||
| DOTS agent is receiving heartbeat messages | ||||
| from its peer."; | ||||
| } | ||||
| } | ||||
| } | A DOTS signal message can be a mitigation, a configuration, | |||
| } | a redirected, or a heartbeat signal message."; | |||
| } | choice message-type { | |||
| <CODE ENDS> | description | |||
| "Can be a mitigation, a configuration, a redirect, or | ||||
| a heartbeat message."; | ||||
| case mitigation-scope { | ||||
| description | ||||
| "Mitigation scope of a mitigation message."; | ||||
| uses mitigation-scope; | ||||
| } | ||||
| case signal-config { | ||||
| description | ||||
| "Configuration message."; | ||||
| uses signal-config; | ||||
| } | ||||
| case redirected-signal { | ||||
| description | ||||
| "Redirected signaling."; | ||||
| uses redirected-signal; | ||||
| } | ||||
| case heartbeat { | ||||
| description | ||||
| "DOTS heartbeats."; | ||||
| leaf peer-hb-status { | ||||
| type boolean; | ||||
| mandatory true; | ||||
| description | ||||
| "Indicates whether a DOTS agent receives heartbeats | ||||
| from its peer. The value is set to 'true' if the | ||||
| DOTS agent is receiving heartbeat messages | ||||
| from its peer."; | ||||
| } | ||||
| } | ||||
| } | ||||
| } | ||||
| } | ||||
| <CODE ENDS> | ||||
| 6. YANG/JSON Mapping Parameters to CBOR | 6. YANG/JSON Mapping Parameters to CBOR | |||
| All parameters in the payload of the DOTS signal channel MUST be | All parameters in the payload of the DOTS signal channel MUST be | |||
| mapped to CBOR types as shown in Table 5 and are assigned an integer | mapped to CBOR types as shown in Table 5 and are assigned an integer | |||
| key to save space. | key to save space. | |||
| Note: Implementers must check that the mapping output provided by | Note: Implementers must check that the mapping output provided by | |||
| their YANG-to-CBOR encoding schemes is aligned with the content of | their YANG-to-CBOR encoding schemes is aligned with the content of | |||
| Table 5. For example, some CBOR and JSON types for enumerations | Table 5. For example, some CBOR and JSON types for enumerations | |||
| skipping to change at page 84, line 24 ¶ | skipping to change at page 84, line 46 ¶ | |||
| | idle-config | container | 44 | 5 map | Object | | | idle-config | container | 44 | 5 map | Object | | |||
| +---------------------+--------------+------+-------------+--------+ | +---------------------+--------------+------+-------------+--------+ | |||
| | trigger-mitigation | boolean | 45 | 7 bits 20 | False | | | trigger-mitigation | boolean | 45 | 7 bits 20 | False | | |||
| | | | +-------------+--------+ | | | | +-------------+--------+ | |||
| | | | | 7 bits 21 | True | | | | | | 7 bits 21 | True | | |||
| +---------------------+--------------+------+-------------+--------+ | +---------------------+--------------+------+-------------+--------+ | |||
| | ietf-dots-signal- | container | 46 | 5 map | Object | | | ietf-dots-signal- | container | 46 | 5 map | Object | | |||
| | channel:redirected- | | | | | | | channel:redirected- | | | | | | |||
| | signal | | | | | | | signal | | | | | | |||
| +---------------------+--------------+------+-------------+--------+ | +---------------------+--------------+------+-------------+--------+ | |||
| | alt-server | string | 47 | 3 text | String | | | alt-server | inet:domain- | 47 | 3 text | String | | |||
| | | | | string | | | | | name | | string | | | |||
| +---------------------+--------------+------+-------------+--------+ | +---------------------+--------------+------+-------------+--------+ | |||
| | alt-server-record | leaf-list | 48 | 4 array | Array | | | alt-server-record | leaf-list | 48 | 4 array | Array | | |||
| | +--------------+------+-------------+--------+ | | +--------------+------+-------------+--------+ | |||
| | | inet:ip- | | 3 text | String | | | | inet:ip- | | 3 text | String | | |||
| | | address | | string | | | | | address | | string | | | |||
| +---------------------+--------------+------+-------------+--------+ | +---------------------+--------------+------+-------------+--------+ | |||
| | ietf-dots-signal- | container | 49 | 5 map | Object | | | ietf-dots-signal- | container | 49 | 5 map | Object | | |||
| | channel:heartbeat | | | | | | | channel:heartbeat | | | | | | |||
| +---------------------+--------------+------+-------------+--------+ | +---------------------+--------------+------+-------------+--------+ | |||
| | probing-rate | container | 50 | 5 map | Object | | | probing-rate | container | 50 | 5 map | Object | | |||
| skipping to change at page 88, line 28 ¶ | skipping to change at page 89, line 8 ¶ | |||
| Note that: | Note that: | |||
| () Indicates messages protected 0-RTT keys | () Indicates messages protected 0-RTT keys | |||
| {} Indicates messages protected using handshake keys | {} Indicates messages protected using handshake keys | |||
| [] Indicates messages protected using 1-RTT keys | [] Indicates messages protected using 1-RTT keys | |||
| Figure 29: A Simplified TLS 1.3 Handshake with 0-RTT | Figure 29: A Simplified TLS 1.3 Handshake with 0-RTT | |||
| 7.3. DTLS MTU and Fragmentation | 7.3. DTLS MTU and Fragmentation | |||
| To avoid DOTS signal message fragmentation and the subsequent | To avoid DOTS signal message fragmentation and the subsequent | |||
| decreased probability of message delivery, DOTS agents MUST ensure | decreased probability of message delivery, the DLTS records need to | |||
| that the DTLS record fits within a single datagram. As a reminder, | fit within a single datagram [RFC6347]. DTLS handles fragmentation | |||
| DTLS handles fragmentation and reassembly only for handshake messages | and reassembly only for handshake messages and not for the | |||
| and not for the application data (Section 4.1.1 of [RFC6347]). If | application data (Section 4.1.1 of [RFC6347]). If the path MTU | |||
| the path MTU (PMTU) cannot be discovered, DOTS agents MUST assume a | (PMTU) cannot be discovered, DOTS agents MUST assume a PMTU of 1280 | |||
| PMTU of 1280 bytes, as IPv6 requires that every link in the Internet | bytes, as IPv6 requires that every link in the Internet have an MTU | |||
| have an MTU of 1280 octets or greater as specified in [RFC8200]. If | of 1280 octets or greater as specified in [RFC8200]. If IPv4 support | |||
| IPv4 support on legacy or otherwise unusual networks is a | on legacy or otherwise unusual networks is a consideration and the | |||
| consideration and the PMTU is unknown, DOTS implementations MAY | PMTU is unknown, DOTS implementations MAY assume a PMTU of 576 bytes | |||
| assume a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host | for IPv4 datagrams (see Section 3.3.3 of [RFC1122]). | |||
| must be capable of receiving a packet whose length is equal to 576 | ||||
| bytes as discussed in [RFC0791] and [RFC1122]. | ||||
| The DOTS client must consider the amount of record expansion expected | The DOTS client must consider the amount of record expansion expected | |||
| by the DTLS processing when calculating the size of the CoAP message | by the DTLS processing when calculating the size of the CoAP message | |||
| that fits within the PMTU. PMTU MUST be greater than or equal to | that fits within the PMTU. PMTU MUST be greater than or equal to | |||
| [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication | [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication | |||
| overhead of the negotiated DTLS cipher suite + block padding] | overhead of the negotiated DTLS cipher suite + block padding] | |||
| (Section 4.1.1.1 of [RFC6347]). If the total request size exceeds | (Section 4.1.1.1 of [RFC6347]). If the total request size exceeds | |||
| the PMTU, then the DOTS client MUST split the DOTS signal into | the PMTU, then the DOTS client MUST split the DOTS signal into | |||
| separate messages; for example, the list of addresses in the 'target- | separate messages; for example, the list of addresses in the 'target- | |||
| prefix' parameter could be split into multiple lists and each list | prefix' parameter could be split into multiple lists and each list | |||
| skipping to change at page 90, line 31 ¶ | skipping to change at page 90, line 36 ¶ | |||
| | | | | | | | | |||
| | +----------------+ | | | | +----------------+ | | | |||
| | | DDoS detector | | | | | | DDoS detector | | | | |||
| | | (DOTS client) +<-------------+ | | | | (DOTS client) +<-------------+ | | |||
| | +----------------+ | | | +----------------+ | | |||
| +---------------------------------------------+ | +---------------------------------------------+ | |||
| Figure 30: Example of Authentication and Authorization of DOTS Agents | Figure 30: Example of Authentication and Authorization of DOTS Agents | |||
| In the example depicted in Figure 30, the DOTS gateway and DOTS | In the example depicted in Figure 30, the DOTS gateway and DOTS | |||
| clients within the 'example.com' domain mutually authenticate. After | clients within the 'example.com' domain proceed with mutual | |||
| the DOTS gateway validates the identity of a DOTS client, it | authentication. After the DOTS gateway validates the identity of a | |||
| communicates with the AAA server in the 'example.com' domain to | DOTS client, it communicates with the AAA server in the 'example.com' | |||
| determine if the DOTS client is authorized to request DDoS | domain to determine if the DOTS client is authorized to request DDoS | |||
| mitigation. If the DOTS client is not authorized, a 4.01 | mitigation. If the DOTS client is not authorized, a 4.01 | |||
| (Unauthorized) is returned in the response to the DOTS client. In | (Unauthorized) is returned in the response to the DOTS client. In | |||
| this example, the DOTS gateway only allows the application server and | this example, the DOTS gateway only allows the application server and | |||
| DDoS attack detector to request DDoS mitigation, but does not permit | DDoS attack detector to request DDoS mitigation, but does not permit | |||
| the user of type 'guest' to request DDoS mitigation. | the user of type 'guest' to request DDoS mitigation. | |||
| Also, DOTS gateways and servers located in different domains must | Also, DOTS gateways and servers located in different domains must | |||
| perform mutual authentication (e.g., using certificates). A DOTS | perform mutual authentication (e.g., using certificates). A DOTS | |||
| server will only allow a DOTS gateway with a certificate for a | server will only allow a DOTS gateway with a certificate for a | |||
| particular domain to request mitigation for that domain. In | particular domain to request mitigation for that domain. In | |||
| skipping to change at page 91, line 20 ¶ | skipping to change at page 91, line 22 ¶ | |||
| In general, there may be an additional plain text diagnostic payload | In general, there may be an additional plain text diagnostic payload | |||
| (Section 5.5.2 of [RFC7252]) to help troubleshooting in the body of | (Section 5.5.2 of [RFC7252]) to help troubleshooting in the body of | |||
| the response unless detailed otherwise. | the response unless detailed otherwise. | |||
| Errors returned by a DOTS server can be broken into two categories, | Errors returned by a DOTS server can be broken into two categories, | |||
| those associated with CoAP itself and those generated during the | those associated with CoAP itself and those generated during the | |||
| validation of the provided data by the DOTS server. | validation of the provided data by the DOTS server. | |||
| The following list of common CoAP errors that are implemented by DOTS | The following list of common CoAP errors that are implemented by DOTS | |||
| servers. This list is not exhaustive, other errors defined by CoAP | servers. This list is not exhaustive; other errors defined by CoAP | |||
| and associated RFCs may be applicable. | and associated RFCs may be applicable. | |||
| o 4.00 (Bad Request) is returned by the DOTS server when the DOTS | 4.00 (Bad Request) is returned by the DOTS server when the DOTS | |||
| client has sent a request that violates the DOTS protocol | client has sent a request that violates the DOTS protocol | |||
| (Section 4). | (Section 4). | |||
| o 4.01 (Unauthorized) is returned by the DOTS server when the DOTS | 4.01 (Unauthorized) is returned by the DOTS server when the DOTS | |||
| client is not authorized to access the DOTS server (Section 4). | client is not authorized to access the DOTS server (Section 4). | |||
| o 4.02 (Bad Option) is returned by the DOTS server when one or more | 4.02 (Bad Option) is returned by the DOTS server when one or more | |||
| CoAP options are unknown or malformed by the CoAP layer [RFC7252]. | CoAP options are unknown or malformed by the CoAP layer [RFC7252]. | |||
| o 4.04 (Not Found) is returned by the DOTS server when the DOTS | 4.04 (Not Found) is returned by the DOTS server when the DOTS client | |||
| client is requesting a 'mid' or 'sid' that is not valid | is requesting a 'mid' or 'sid' that is not valid (Section 4). | |||
| (Section 4). | ||||
| o 4.05 (Method Not Allowed) is returned by the DOTS server when the | 4.05 (Method Not Allowed) is returned by the DOTS server when the | |||
| DOTS client is requesting a resource by a method (e.g., GET) that | DOTS client is requesting a resource by a method (e.g., GET) that | |||
| is not supported by the DOTS server [RFC7252]. | is not supported by the DOTS server [RFC7252]. | |||
| o 4.08 (Request Entity Incomplete) is returned by the DOTS server if | 4.08 (Request Entity Incomplete) is returned by the DOTS server if | |||
| one or multiple blocks of a block transfer request is missing | one or multiple blocks of a block transfer request is missing | |||
| [RFC7959]. | [RFC7959]. | |||
| o 4.09 (Conflict) is returned by the DOTS server if the DOTS server | 4.09 (Conflict) is returned by the DOTS server if the DOTS server | |||
| detects that a request conflicts with a previous request. The | detects that a request conflicts with a previous request. The | |||
| response body is formatted using "application/dots+cbor", and | response body is formatted using "application/dots+cbor", and | |||
| contains the "conflict-clause" (Section 4.4). | contains the "conflict-clause" (Section 4.4). | |||
| o 4.13 (Request Entity Too Large) may be returned by the DOTS server | 4.13 (Request Entity Too Large) may be returned by the DOTS server | |||
| during a block transfer request [RFC7959]. | during a block transfer request [RFC7959]. | |||
| o 4.15 (Unsupported Content-Format) is returned by the DOTS server | 4.15 (Unsupported Content-Format) is returned by the DOTS server | |||
| when the Content-Format used in the request is not formatted as | when the Content-Format is used but the request is not formatted | |||
| "application/dots+cbor" (Section 4). | as "application/dots+cbor" (Section 4). | |||
| o 4.22 (Unprocessable Entity) is returned by the DOTS server when | 4.22 (Unprocessable Entity) is returned by the DOTS server when one | |||
| one or more session configuration parameters are not valid | or more session configuration parameters are not valid | |||
| (Section 4.5). | (Section 4.5). | |||
| o 5.03 (Service Unavailable) is returned by the DOTS server if the | 5.03 (Service Unavailable) is returned by the DOTS server if the | |||
| DOTS server is unable to handle the request (Section 4). An | DOTS server is unable to handle the request (Section 4). An | |||
| example is the DOTS server needs to redirect the DOTS client to | example is the DOTS server needs to redirect the DOTS client to | |||
| use an alternate DOTS server (Section 4.6). The response body is | use an alternate DOTS server (Section 4.6). The response body is | |||
| formatted using "application/dots+cbor", and contains how to | formatted using "application/dots+cbor", and contains how to | |||
| handle the 5.03 Response Code. | handle the 5.03 Response Code. | |||
| o 5.08 (Hop Limit Reached) is returned by the DOTS server if there | 5.08 (Hop Limit Reached) is returned by the DOTS server if there is | |||
| is a data path loop through upstream DOTS gateways. The response | a data path loop through upstream DOTS gateways. The response | |||
| body is formatted using plain text and contains a list of servers | body is formatted using plain text and contains a list of servers | |||
| that are in the data path loop [RFC8768]. | that are in the data path loop [RFC8768]. | |||
| 10. IANA Considerations | 10. IANA Considerations | |||
| 10.1. DOTS Signal Channel UDP and TCP Port Number | 10.1. DOTS Signal Channel UDP and TCP Port Number | |||
| IANA has assigned the port number 4646 (the ASCII decimal value for | IANA has assigned the port number 4646 (the ASCII decimal value for | |||
| ".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP | ".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP | |||
| from the "Service Name and Transport Protocol Port Number Registry" | from the "Service Name and Transport Protocol Port Number Registry" | |||
| available at <https://www.iana.org/assignments/service-names-port- | available at <https://www.iana.org/assignments/service-names-port- | |||
| numbers/>. | numbers/>. | |||
| IANA is requested to update these entries with the RFC number to be | IANA is requested to update these entries with the RFC number to be | |||
| assigned to this docuement: | assigned to this document: | |||
| Service Name: dots-signal | Service Name: dots-signal | |||
| Port Number: 4646 | Port Number: 4646 | |||
| Transport Protocol: TCP | Transport Protocol: TCP | |||
| Description: Distributed Denial-of-Service Open Threat Signaling | Description: Distributed Denial-of-Service Open Threat Signaling | |||
| (DOTS) Signal Channel | (DOTS) Signal Channel | |||
| Assignee: IESG | Assignee: IESG | |||
| Contact: IETF Chair | Contact: IETF Chair | |||
| Registration Date: 2020-01-16 | Registration Date: 2020-01-16 | |||
| Reference: [RFCXXXX] | Reference: [RFCXXXX] | |||
| skipping to change at page 93, line 27 ¶ | skipping to change at page 93, line 27 ¶ | |||
| Transport Protocol: UDP | Transport Protocol: UDP | |||
| Description: Distributed Denial-of-Service Open Threat Signaling | Description: Distributed Denial-of-Service Open Threat Signaling | |||
| (DOTS) Signal Channel | (DOTS) Signal Channel | |||
| Assignee: IESG | Assignee: IESG | |||
| Contact: IETF Chair | Contact: IETF Chair | |||
| Registration Date: 2020-01-16 | Registration Date: 2020-01-16 | |||
| Reference: [RFCXXXX] | Reference: [RFCXXXX] | |||
| 10.2. Well-Known 'dots' URI | 10.2. Well-Known 'dots' URI | |||
| IANA is requested to update the the 'dots' well-known URI (Table 6) | IANA is requested to update the 'dots' well-known URI (Table 6) entry | |||
| entry in the Well- Known URIs registry [URI] as follows: | in the Well- Known URIs registry [URI] as follows: | |||
| +------------+------------+-----------+-----------+-------------+ | +------------+------------+-----------+-----------+-------------+ | |||
| | URI Suffix | Change | Reference | Status | Related | | | URI Suffix | Change | Reference | Status | Related | | |||
| | | Controller | | | information | | | | Controller | | | information | | |||
| +============+============+===========+===========+=============+ | +============+============+===========+===========+=============+ | |||
| | dots | IETF | [RFCXXXX] | permanent | None | | | dots | IETF | [RFCXXXX] | permanent | None | | |||
| +------------+------------+-----------+-----------+-------------+ | +------------+------------+-----------+-----------+-------------+ | |||
| Table 6: 'dots' Well-Known URI | Table 6: 'dots' Well-Known URI | |||
| skipping to change at page 94, line 16 ¶ | skipping to change at page 94, line 16 ¶ | |||
| Subtype name: dots+cbor | Subtype name: dots+cbor | |||
| Required parameters: N/A | Required parameters: N/A | |||
| Optional parameters: N/A | Optional parameters: N/A | |||
| Encoding considerations: binary | Encoding considerations: binary | |||
| Security considerations: See the Security Considerations section of | Security considerations: See the Security Considerations section of | |||
| [RFCXXXx]. | [RFCXXXX]. | |||
| Interoperability considerations: N/A | Interoperability considerations: N/A | |||
| Published specification: [RFCXXXX] | Published specification: [RFCXXXX] | |||
| Applications that use this media type: DOTS agents sending DOTS | Applications that use this media type: DOTS agents sending DOTS | |||
| messages over CoAP over (D)TLS. | messages over CoAP over (D)TLS. | |||
| Fragment identifier considerations: N/A | Fragment identifier considerations: N/A | |||
| skipping to change at page 95, line 26 ¶ | skipping to change at page 95, line 26 ¶ | |||
| CBOR tag is not required for DOTS signal channel protocol version | CBOR tag is not required for DOTS signal channel protocol version | |||
| specified in this document. If present, the DOTS tag MUST prefix a | specified in this document. If present, the DOTS tag MUST prefix a | |||
| DOTS signal channel object. | DOTS signal channel object. | |||
| IANA is requested to update the DOTS signal channel CBOR tag in the | IANA is requested to update the DOTS signal channel CBOR tag in the | |||
| "CBOR Tags" registry [IANA-CBOR-Tags]: | "CBOR Tags" registry [IANA-CBOR-Tags]: | |||
| * Tag: 271 | * Tag: 271 | |||
| * Data Item: DDoS Open Threat Signaling (DOTS) signal channel object | * Data Item: DDoS Open Threat Signaling (DOTS) signal channel object | |||
| * Semantics: DDoS Open Threat Signaling (DOTS) signal channel | * Semantics: DDoS Open Threat Signaling (DOTS) signal channel | |||
| object, as defined in [RFXXXX] | object, as defined in [RFCXXXX] | |||
| * Reference: [RFCXXXX] | * Reference: [RFCXXXX] | |||
| 10.6. DOTS Signal Channel Protocol Registry | 10.6. DOTS Signal Channel Protocol Registry | |||
| The following sections update the "Distributed Denial-of- Service | The following sections update the "Distributed Denial-of- Service | |||
| Open Threat Signaling (DOTS) Signal Channel" subregistries | Open Threat Signaling (DOTS) Signal Channel" subregistries | |||
| [REG-DOTS]. | [REG-DOTS]. | |||
| 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry | 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry | |||
| skipping to change at page 97, line 29 ¶ | skipping to change at page 97, line 29 ¶ | |||
| address) may also be included. | address) may also be included. | |||
| Specification Document(s): | Specification Document(s): | |||
| Reference to the document or documents that specify the parameter, | Reference to the document or documents that specify the parameter, | |||
| preferably including URIs that can be used to retrieve copies of | preferably including URIs that can be used to retrieve copies of | |||
| the documents. An indication of the relevant sections may also be | the documents. An indication of the relevant sections may also be | |||
| included but is not required. | included but is not required. | |||
| 10.6.1.2. Update Subregistry Content | 10.6.1.2. Update Subregistry Content | |||
| IANA is requested to update these entries from the "DOTS Signal | IANA is requested to update entries in the "0-51" and "49152-65535" | |||
| Channel CBOR Key Values" registry with the RFC number to be assigned | ranges from the "DOTS Signal Channel CBOR Key Values" registry with | |||
| to this document: | the RFC number to be assigned to this document. | |||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | Parameter Name | CBOR Key |CBOR | Change | Specification | | ||||
| | | Value |Major|Controller| Document(s) | | ||||
| | | |Type | | | | ||||
| +=====================+============+=====+==========+===============+ | ||||
| | Reserved | 0 | | | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | ietf-dots-signal- | 1 | 5 | IESG | [RFCXXXX] | | ||||
| | channel:mitigation- | | | | | | ||||
| | scope | | | | | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | scope | 2 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | cdid | 3 | 3 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | cuid | 4 | 3 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | mid | 5 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | target-prefix | 6 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | target-port-range | 7 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | lower-port | 8 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | upper-port | 9 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | target-protocol | 10 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | target-fqdn | 11 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | target-uri | 12 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | alias-name | 13 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | lifetime | 14 | 0/1 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | mitigation-start | 15 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | status | 16 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| |conflict-information | 17 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | conflict-status | 18 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | conflict-cause | 19 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | retry-timer | 20 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | conflict-scope | 21 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | acl-list | 22 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | acl-name | 23 | 3 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | acl-type | 24 | 3 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | bytes-dropped | 25 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | bps-dropped | 26 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | pkts-dropped | 27 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | pps-dropped | 28 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | attack-status | 29 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | ietf-dots-signal- | 30 | 5 | IESG | [RFCXXXX] | | ||||
| |channel:signal-config| | | | | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | sid | 31 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | mitigating-config | 32 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | heartbeat-interval | 33 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | min-value | 34 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | max-value | 35 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | current-value | 36 | 0 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | max-retransmit | 38 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | ack-timeout | 39 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | min-value-decimal | 41 |6tag4| IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | max-value-decimal | 42 |6tag4| IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| |current-value-decimal| 43 |6tag4| IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | idle-config | 44 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | ietf-dots-signal- | 46 | 5 | IESG | [RFCXXXX] | | ||||
| | channel:redirected- | | | | | | ||||
| | signal | | | | | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | alt-server | 47 | 3 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | alt-server-record | 48 | 4 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | ietf-dots-signal- | 49 | 5 | IESG | [RFCXXXX] | | ||||
| | channel:heartbeat | | | | | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | probing-rate | 50 | 5 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | peer-hb-status | 51 | 7 | IESG | [RFCXXXX] | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| | Unassigned | 52-49151 | | | | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| |Reserved for Private |49152-65535 | | | [RFCXXXX] | | ||||
| | Use | | | | | | ||||
| +---------------------+------------+-----+----------+---------------+ | ||||
| Table 6: Initial DOTS Signal Channel CBOR Key Values Registry | ||||
| 10.6.2. Status Codes Subregistry | 10.6.2. Status Codes Subregistry | |||
| IANA is requested to update these entries from the "DOTS Signal | IANA is requested to update these entries from the "DOTS Signal | |||
| Channel Status Codes" registry with the RFC number to be assigned to | Channel Status Codes" registry with the RFC number to be assigned to | |||
| this document: | this document: | |||
| +--------------+---------------+----------------------+-----------+ | +--------------+---------------+----------------------+-----------+ | |||
| | Code | Label | Description | Reference | | | Code | Label | Description | Reference | | |||
| +==============+===============+======================+===========+ | +==============+===============+======================+===========+ | |||
| skipping to change at page 101, line 26 ¶ | skipping to change at page 98, line 47 ¶ | |||
| | | mitigation- | will be triggered | | | | | mitigation- | will be triggered | | | |||
| | | signal-loss | for the mitigation | | | | | signal-loss | for the mitigation | | | |||
| | | | request only when | | | | | | request only when | | | |||
| | | | the DOTS signal | | | | | | the DOTS signal | | | |||
| | | | channel session is | | | | | | channel session is | | | |||
| | | | lost. | | | | | | lost. | | | |||
| +--------------+---------------+----------------------+-----------+ | +--------------+---------------+----------------------+-----------+ | |||
| | 9-2147483647 | Unassigned | | | | | 9-2147483647 | Unassigned | | | | |||
| +--------------+---------------+----------------------+-----------+ | +--------------+---------------+----------------------+-----------+ | |||
| Table 8: Initial DOTS Signal Channel Status Codes | Table 7: Initial DOTS Signal Channel Status Codes | |||
| New codes can be assigned via Standards Action [RFC8126]. | New codes can be assigned via Standards Action [RFC8126]. | |||
| 10.6.3. Conflict Status Codes Subregistry | 10.6.3. Conflict Status Codes Subregistry | |||
| IANA is requested to update these entries from the "DOTS Signal | IANA is requested to update these entries from the "DOTS Signal | |||
| Channel Conflict Status Codes" registry with the RFC number to be | Channel Conflict Status Codes" registry with the RFC number to be | |||
| assigned to this document: | assigned to this document: | |||
| +--------------+-------------------+--------------------+-----------+ | +--------------+-------------------+--------------------+-----------+ | |||
| skipping to change at page 102, line 38 ¶ | skipping to change at page 100, line 12 ¶ | |||
| | | | different DOTS | | | | | | different DOTS | | | |||
| | | | clients. All | | | | | | clients. All | | | |||
| | | | conflicting | | | | | | conflicting | | | |||
| | | | mitigation | | | | | | mitigation | | | |||
| | | | requests are | | | | | | requests are | | | |||
| | | | inactive. | | | | | | inactive. | | | |||
| +--------------+-------------------+--------------------+-----------+ | +--------------+-------------------+--------------------+-----------+ | |||
| | 4-2147483647 | Unassigned | | | | | 4-2147483647 | Unassigned | | | | |||
| +--------------+-------------------+--------------------+-----------+ | +--------------+-------------------+--------------------+-----------+ | |||
| Table 9: Initial DOTS Signal Channel Conflict Status Codes | Table 8: Initial DOTS Signal Channel Conflict Status Codes | |||
| New codes can be assigned via Standards Action [RFC8126]. | New codes can be assigned via Standards Action [RFC8126]. | |||
| 10.6.4. Conflict Cause Codes Subregistry | 10.6.4. Conflict Cause Codes Subregistry | |||
| IANA is requested to update these entries from the "DOTS Signal | IANA is requested to update these entries from the "DOTS Signal | |||
| Channel Conflict Cause Codes" registry with the RFC number to be | Channel Conflict Cause Codes" registry with the RFC number to be | |||
| assigned to this document: | assigned to this document: | |||
| +--------------+---------------------+----------------+-----------+ | +--------------+---------------------+----------------+-----------+ | |||
| skipping to change at page 103, line 42 ¶ | skipping to change at page 101, line 42 ¶ | |||
| | | | a DOTS client | | | | | | a DOTS client | | | |||
| | | | uses a 'cuid' | | | | | | uses a 'cuid' | | | |||
| | | | that is | | | | | | that is | | | |||
| | | | already used | | | | | | already used | | | |||
| | | | by another | | | | | | by another | | | |||
| | | | DOTS client. | | | | | | DOTS client. | | | |||
| +--------------+---------------------+----------------+-----------+ | +--------------+---------------------+----------------+-----------+ | |||
| | 4-2147483647 | Unassigned | | | | | 4-2147483647 | Unassigned | | | | |||
| +--------------+---------------------+----------------+-----------+ | +--------------+---------------------+----------------+-----------+ | |||
| Table 10: Initial DOTS Signal Channel Conflict Cause Codes | Table 9: Initial DOTS Signal Channel Conflict Cause Codes | |||
| New codes can be assigned via Standards Action [RFC8126]. | New codes can be assigned via Standards Action [RFC8126]. | |||
| 10.6.5. Attack Status Codes Subregistry | 10.6.5. Attack Status Codes Subregistry | |||
| IANA is requested to update these entries from the "DOTS Signal | IANA is requested to update these entries from the "DOTS Signal | |||
| Channel Attack Status Codes" registry with the RFC number to be | Channel Attack Status Codes" registry with the RFC number to be | |||
| assigned to this document: | assigned to this document: | |||
| +--------------+----------------------+-----------------+-----------+ | +--------------+----------------------+-----------------+-----------+ | |||
| skipping to change at page 104, line 28 ¶ | skipping to change at page 102, line 28 ¶ | |||
| | | mitigated | client | | | | | mitigated | client | | | |||
| | | | determines | | | | | | determines | | | |||
| | | | that the | | | | | | that the | | | |||
| | | | attack is | | | | | | attack is | | | |||
| | | | successfully | | | | | | successfully | | | |||
| | | | mitigated. | | | | | | mitigated. | | | |||
| +--------------+----------------------+-----------------+-----------+ | +--------------+----------------------+-----------------+-----------+ | |||
| | 3-2147483647 | Unassigned | | | | | 3-2147483647 | Unassigned | | | | |||
| +--------------+----------------------+-----------------+-----------+ | +--------------+----------------------+-----------------+-----------+ | |||
| Table 11: Initial DOTS Signal Channel Attack Status Codes | Table 10: Initial DOTS Signal Channel Attack Status Codes | |||
| New codes can be assigned via Standards Action [RFC8126]. | New codes can be assigned via Standards Action [RFC8126]. | |||
| 10.7. DOTS Signal Channel YANG Modules | 10.7. DOTS Signal Channel YANG Modules | |||
| IANA already registered the following URIs in the "ns" subregistry | IANA already registered the following URIs in the "ns" subregistry | |||
| within the "IETF XML Registry" [RFC3688]: | within the "IETF XML Registry" [RFC3688]: | |||
| URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel | URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel | |||
| Registrant Contact: The IESG. | Registrant Contact: The IESG. | |||
| skipping to change at page 106, line 33 ¶ | skipping to change at page 104, line 33 ¶ | |||
| TLS authentication is used. Because the application data is TLS | TLS authentication is used. Because the application data is TLS | |||
| protected, this will not result in the application receiving bogus | protected, this will not result in the application receiving bogus | |||
| data, but it will constitute a DoS on the connection. This attack | data, but it will constitute a DoS on the connection. This attack | |||
| can be countered by using TCP Authentication Option (TCP-AO) | can be countered by using TCP Authentication Option (TCP-AO) | |||
| [RFC5925]. Although not widely adopted, if TCP-AO is used, then any | [RFC5925]. Although not widely adopted, if TCP-AO is used, then any | |||
| bogus packets injected by an attacker will be rejected by the TCP-AO | bogus packets injected by an attacker will be rejected by the TCP-AO | |||
| integrity check and therefore will never reach the TLS layer. | integrity check and therefore will never reach the TLS layer. | |||
| If the 'cuid' is guessable, a misbehaving DOTS client from within the | If the 'cuid' is guessable, a misbehaving DOTS client from within the | |||
| client's domain can use the 'cuid' of another DOTS client of the | client's domain can use the 'cuid' of another DOTS client of the | |||
| domain to delete or alter active mitigations. For this attack vector | domain to delete or alter active mitigations. For this attack to | |||
| to happen, the misbehaving client needs to pass the security | succeed, the misbehaving client's messages need to pass the security | |||
| validation checks by the DOTS server, and eventually the checks of a | validation checks by the DOTS server and, if the communication | |||
| client-domain DOTS gateway. | involves a client-domain DOTS gateway, the security checks of that | |||
| gateway. | ||||
| A similar attack can be achieved by a compromised DOTS client that | A similar attack can be achieved by a compromised DOTS client that | |||
| can sniff the TLS 1.2 handshake, use the client certificate to | can sniff the TLS 1.2 handshake, use the client certificate to | |||
| identify the 'cuid' used by another DOTS client. This attack is not | identify the 'cuid' used by another DOTS client. This attack is not | |||
| possible if algorithms such as version 4 Universally Unique | possible if algorithms such as version 4 Universally Unique | |||
| IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate | IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate | |||
| the 'cuid' because such UUIDs are not a deterministic function of the | the 'cuid' because such UUIDs are not a deterministic function of the | |||
| client certificate. Likewise, this attack is not possible with TLS | client certificate. Likewise, this attack is not possible with TLS | |||
| 1.3 because most of the TLS handshake is encrypted and the client | 1.3 because most of the TLS handshake is encrypted and the client | |||
| certificate is not visible to eavesdroppers. | certificate is not visible to eavesdroppers. | |||
| A compromised DOTS client can collude with a DDoS attacker to send | A compromised DOTS client can collude with a DDoS attacker to send a | |||
| mitigation request for a target resource, get the mitigation efficacy | mitigation request for a target resource, get the mitigation efficacy | |||
| from the DOTS server, and convey the mitigation efficacy to the DDoS | from the DOTS server, and convey the mitigation efficacy to the DDoS | |||
| attacker to possibly change the DDoS attack strategy. Obviously, | attacker to possibly change the DDoS attack strategy. Obviously, | |||
| signaling an attack by the compromised DOTS client to the DOTS server | signaling an attack by the compromised DOTS client to the DOTS server | |||
| will trigger attack mitigation. This attack can be prevented by | will trigger attack mitigation. This attack can be prevented by | |||
| monitoring and auditing DOTS clients to detect misbehavior and to | monitoring and auditing DOTS clients to detect misbehavior and to | |||
| deter misuse, and by only authorizing the DOTS client to request | deter misuse, and by only authorizing the DOTS client to request | |||
| mitigation for specific target resources (e.g., an application server | mitigation for specific target resources (e.g., an application server | |||
| is authorized to request mitigation for its IP addresses, but a DDoS | is authorized to request mitigation for its IP addresses, but a DDoS | |||
| mitigator can request mitigation for any target resource in the | mitigator can request mitigation for any target resource in the | |||
| skipping to change at page 107, line 27 ¶ | skipping to change at page 105, line 28 ¶ | |||
| limit policies SHOULD be enforced on DOTS gateways (if deployed) and | limit policies SHOULD be enforced on DOTS gateways (if deployed) and | |||
| DOTS servers. | DOTS servers. | |||
| In order to prevent leaking internal information outside a client's | In order to prevent leaking internal information outside a client's | |||
| domain, DOTS gateways located in the client domain SHOULD NOT reveal | domain, DOTS gateways located in the client domain SHOULD NOT reveal | |||
| the identification information that pertains to internal DOTS clients | the identification information that pertains to internal DOTS clients | |||
| (e.g., source IP address, client's hostname) unless explicitly | (e.g., source IP address, client's hostname) unless explicitly | |||
| configured to do so. | configured to do so. | |||
| DOTS servers MUST verify that requesting DOTS clients are entitled to | DOTS servers MUST verify that requesting DOTS clients are entitled to | |||
| trigger actions on a given IP prefix. That is, only actions on IP | trigger actions on a given IP prefix. A DOTS server MUST NOT | |||
| resources that belong to the DOTS client's domain MUST be authorized | authorize actions due to a DOTS client request unless those actions | |||
| by a DOTS server. The exact mechanism for the DOTS servers to | are limited to that DOTS client's domain IP resources. The exact | |||
| validate that the target prefixes are within the scope of the DOTS | mechanism for the DOTS servers to validate that the target prefixes | |||
| client domain is deployment specific. | are within the scope of the DOTS client domain is deployment | |||
| specific. | ||||
| The presence of DOTS gateways may lead to infinite forwarding loops, | The presence of DOTS gateways may lead to infinite forwarding loops, | |||
| which is undesirable. To prevent and detect such loops, this | which is undesirable. To prevent and detect such loops, this | |||
| document uses the Hop-Limit Option. | document uses the Hop-Limit Option. | |||
| When FQDNs are used as targets, the DOTS server MUST rely upon DNS | 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 | privacy-enabling protocols (e.g., DNS over TLS [RFC7858] or DNS over | |||
| HTTPS (DoH) [RFC8484]) to prevent eavesdroppers from possibly | HTTPS (DoH) [RFC8484]) to prevent eavesdroppers from possibly | |||
| identifying the target resources protected by the DDoS mitigation | identifying the target resources protected by the DDoS mitigation | |||
| service to ensure the target FQDN resolution is authentic (e.g., | service to ensure the target FQDN resolution is authentic (e.g., | |||
| DNSSEC [RFC4034]). | DNSSEC [RFC4034]). | |||
| CoAP-specific security considerations are discussed in Section 11 of | CoAP-specific security considerations are discussed in Section 11 of | |||
| [RFC7252], while CBOR-related security considerations are discussed | [RFC7252], while CBOR-related security considerations are discussed | |||
| in Section 8 of [RFC7049]. | in Section 10 of [RFC8949]. | |||
| This document defines YANG data structures that are meant to be used | This document defines YANG data structures that are meant to be used | |||
| as an abstract representation of DOTS signal channel messages. As | as an abstract representation of DOTS signal channel messages. As | |||
| such, the "ietf-dots-signal-channel" module does not introduce any | such, the "ietf-dots-signal-channel" module does not introduce any | |||
| new vulnerabilities beyond those specified above. | new vulnerabilities beyond those specified above. | |||
| 12. References | 12. References | |||
| 12.1. Normative References | 12.1. Normative References | |||
| skipping to change at page 109, line 36 ¶ | skipping to change at page 107, line 36 ¶ | |||
| 2011, <https://www.rfc-editor.org/info/rfc6125>. | 2011, <https://www.rfc-editor.org/info/rfc6125>. | |||
| [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
| Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
| January 2012, <https://www.rfc-editor.org/info/rfc6347>. | January 2012, <https://www.rfc-editor.org/info/rfc6347>. | |||
| [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | |||
| RFC 6991, DOI 10.17487/RFC6991, July 2013, | RFC 6991, DOI 10.17487/RFC6991, July 2013, | |||
| <https://www.rfc-editor.org/info/rfc6991>. | <https://www.rfc-editor.org/info/rfc6991>. | |||
| [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | ||||
| Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | ||||
| October 2013, <https://www.rfc-editor.org/info/rfc7049>. | ||||
| [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., | [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., | |||
| Weiler, S., and T. Kivinen, "Using Raw Public Keys in | Weiler, S., and T. Kivinen, "Using Raw Public Keys in | |||
| Transport Layer Security (TLS) and Datagram Transport | Transport Layer Security (TLS) and Datagram Transport | |||
| Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, | Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, | |||
| June 2014, <https://www.rfc-editor.org/info/rfc7250>. | June 2014, <https://www.rfc-editor.org/info/rfc7250>. | |||
| [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
| Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
| DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
| <https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
| skipping to change at page 111, line 38 ¶ | skipping to change at page 109, line 33 ¶ | |||
| [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed | [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed | |||
| Denial-of-Service Open Threat Signaling (DOTS) Data | Denial-of-Service Open Threat Signaling (DOTS) Data | |||
| Channel Specification", RFC 8783, DOI 10.17487/RFC8783, | Channel Specification", RFC 8783, DOI 10.17487/RFC8783, | |||
| May 2020, <https://www.rfc-editor.org/info/rfc8783>. | May 2020, <https://www.rfc-editor.org/info/rfc8783>. | |||
| [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data | [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data | |||
| Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | |||
| June 2020, <https://www.rfc-editor.org/info/rfc8791>. | June 2020, <https://www.rfc-editor.org/info/rfc8791>. | |||
| [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | ||||
| Representation (CBOR)", STD 94, RFC 8949, | ||||
| DOI 10.17487/RFC8949, December 2020, | ||||
| <https://www.rfc-editor.org/info/rfc8949>. | ||||
| 12.2. Informative References | 12.2. Informative References | |||
| [I-D.boucadair-dots-earlydata] | [I-D.boucadair-dots-earlydata] | |||
| Boucadair, M. and R. K, "Using Early Data in DOTS", draft- | Boucadair, M. and T. Reddy, "Using Early Data in DOTS", | |||
| boucadair-dots-earlydata-00 (work in progress), January | draft-boucadair-dots-earlydata-00 (work in progress), | |||
| 2019. | January 2019. | |||
| [I-D.ietf-core-comi] | [I-D.ietf-core-comi] | |||
| Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. | Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and | |||
| Petrov, "CoAP Management Interface (CORECONF)", draft- | I. Petrov, "CoAP Management Interface (CORECONF)", draft- | |||
| ietf-core-comi-10 (work in progress), July 2020. | ietf-core-comi-11 (work in progress), January 2021. | |||
| [I-D.ietf-core-yang-cbor] | [I-D.ietf-core-yang-cbor] | |||
| Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of | Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of | |||
| Data Modeled with YANG", draft-ietf-core-yang-cbor-13 | Data Modeled with YANG", draft-ietf-core-yang-cbor-15 | |||
| (work in progress), July 2020. | (work in progress), January 2021. | |||
| [I-D.ietf-dots-multihoming] | [I-D.ietf-dots-multihoming] | |||
| Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing | Boucadair, M., Reddy, T., and W. Pan, "Multi-homing | |||
| Deployment Considerations for Distributed-Denial-of- | Deployment Considerations for Distributed-Denial-of- | |||
| Service Open Threat Signaling (DOTS)", draft-ietf-dots- | Service Open Threat Signaling (DOTS)", draft-ietf-dots- | |||
| multihoming-04 (work in progress), May 2020. | multihoming-05 (work in progress), November 2020. | |||
| [I-D.ietf-dots-server-discovery] | ||||
| Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- | ||||
| Service Open Threat Signaling (DOTS) Agent Discovery", | ||||
| draft-ietf-dots-server-discovery-15 (work in progress), | ||||
| November 2020. | ||||
| [I-D.ietf-dots-telemetry] | [I-D.ietf-dots-telemetry] | |||
| Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., | Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. | |||
| and J. Shallow, "Distributed Denial-of-Service Open Threat | Shallow, "Distributed Denial-of-Service Open Threat | |||
| Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-14 | Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 | |||
| (work in progress), November 2020. | (work in progress), December 2020. | |||
| [I-D.ietf-dots-use-cases] | ||||
| Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, | ||||
| L., and K. Nishizuka, "Use cases for DDoS Open Threat | ||||
| Signaling", draft-ietf-dots-use-cases-25 (work in | ||||
| progress), July 2020. | ||||
| [I-D.ietf-tls-dtls13] | [I-D.ietf-tls-dtls13] | |||
| Rescorla, E., Tschofenig, H., and N. Modadugu, "The | Rescorla, E., Tschofenig, H., and N. Modadugu, "The | |||
| Datagram Transport Layer Security (DTLS) Protocol Version | Datagram Transport Layer Security (DTLS) Protocol Version | |||
| 1.3", draft-ietf-tls-dtls13-39 (work in progress), | 1.3", draft-ietf-tls-dtls13-43 (work in progress), April | |||
| November 2020. | 2021. | |||
| [IANA-CBOR-Tags] | [IANA-CBOR-Tags] | |||
| IANA, "Concise Binary Object Representation (CBOR) Tags", | IANA, "Concise Binary Object Representation (CBOR) Tags", | |||
| <http://www.iana.org/assignments/cbor-tags/cbor- | <https://www.iana.org/assignments/cbor-tags/cbor- | |||
| tags.xhtml>. | tags.xhtml>. | |||
| [IANA-CoAP-Content-Formats] | [IANA-CoAP-Content-Formats] | |||
| IANA, "CoAP Content-Formats", | IANA, "CoAP Content-Formats", | |||
| <http://www.iana.org/assignments/core-parameters/core- | <https://www.iana.org/assignments/core-parameters/core- | |||
| parameters.xhtml#content-formats>. | parameters.xhtml#content-formats>. | |||
| [IANA-MediaTypes] | [IANA-MediaTypes] | |||
| IANA, "Media Types", | IANA, "Media Types", | |||
| <http://www.iana.org/assignments/media-types>. | <https://www.iana.org/assignments/media-types>. | |||
| [IANA-Proto] | [IANA-Proto] | |||
| IANA, "Protocol Numbers", 2011, | IANA, "Protocol Numbers", 2011, | |||
| <http://www.iana.org/assignments/protocol-numbers>. | <https://www.iana.org/assignments/protocol-numbers>. | |||
| [REG-DOTS] | [REG-DOTS] | |||
| IANA, "Distributed Denial-of-Service Open Threat Signaling | IANA, "Distributed Denial-of-Service Open Threat Signaling | |||
| (DOTS) Signal Channel", | (DOTS) Signal Channel", | |||
| <https://www.iana.org/assignments/dots/dots.xhtml>. | <https://www.iana.org/assignments/dots/dots.xhtml>. | |||
| [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | |||
| Address Translator (Traditional NAT)", RFC 3022, | Address Translator (Traditional NAT)", RFC 3022, | |||
| DOI 10.17487/RFC3022, January 2001, | DOI 10.17487/RFC3022, January 2001, | |||
| <https://www.rfc-editor.org/info/rfc3022>. | <https://www.rfc-editor.org/info/rfc3022>. | |||
| skipping to change at page 116, line 16 ¶ | skipping to change at page 114, line 5 ¶ | |||
| Mortensen, A., and N. Teague, "Distributed Denial-of- | Mortensen, A., and N. Teague, "Distributed Denial-of- | |||
| Service Open Threat Signaling (DOTS) Signal Channel | Service Open Threat Signaling (DOTS) Signal Channel | |||
| Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, | Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, | |||
| <https://www.rfc-editor.org/info/rfc8782>. | <https://www.rfc-editor.org/info/rfc8782>. | |||
| [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., | [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., | |||
| Teague, N., and R. Compton, "DDoS Open Threat Signaling | Teague, N., and R. Compton, "DDoS Open Threat Signaling | |||
| (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, | (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, | |||
| August 2020, <https://www.rfc-editor.org/info/rfc8811>. | August 2020, <https://www.rfc-editor.org/info/rfc8811>. | |||
| [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, | ||||
| L., and K. Nishizuka, "Use Cases for DDoS Open Threat | ||||
| Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, | ||||
| <https://www.rfc-editor.org/info/rfc8903>. | ||||
| [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling | ||||
| (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, | ||||
| January 2021, <https://www.rfc-editor.org/info/rfc8973>. | ||||
| [URI] IANA, "Well-Known URIs", | [URI] IANA, "Well-Known URIs", | |||
| <https://www.iana.org/assignments/well-known-uris/well- | <https://www.iana.org/assignments/well-known-uris/well- | |||
| known-uris.xhtml>. | known-uris.xhtml>. | |||
| Appendix A. Summary of Changes From RFC8782 | Appendix A. Summary of Changes From RFC8782 | |||
| The main changes compared to [RFC8782] are as follows: | The main changes compared to [RFC8782] are as follows: | |||
| o Update the "ietf-dots-signal-channel" YANG module (Section 5.3) | o Update the "ietf-dots-signal-channel" YANG module (Section 5.3) | |||
| and the tree structure (Section 5.1) to follow the new YANG data | and the tree structure (Section 5.1) to follow the new YANG data | |||
| skipping to change at page 117, line 11 ¶ | skipping to change at page 115, line 7 ¶ | |||
| o Add a new section with a summary of the error code responses that | o Add a new section with a summary of the error code responses that | |||
| can be returned by a DOTS server (Section 9). | can be returned by a DOTS server (Section 9). | |||
| o Update the IANA section to allocate a new range for comprehension- | o Update the IANA section to allocate a new range for comprehension- | |||
| optional attributes (Section 10.6.1.1). This modification is | optional attributes (Section 10.6.1.1). This modification is | |||
| motivated by the need to allow for compact DOTS signal messages | motivated by the need to allow for compact DOTS signal messages | |||
| that include a long list of comprehension-optional attributes, | that include a long list of comprehension-optional attributes, | |||
| e.g., DOTS telemetry messages [I-D.ietf-dots-telemetry]. | e.g., DOTS telemetry messages [I-D.ietf-dots-telemetry]. | |||
| o Add Appendix C to list recommended/default values of key DOTS | ||||
| signal channel parameters. | ||||
| o Add subsections to Section 4.4.1 for better readability. | ||||
| Appendix B. CUID Generation | Appendix B. CUID Generation | |||
| The document recommends the use of SPKI to generate the 'cuid'. This | The document recommends the use of SPKI to generate the 'cuid'. This | |||
| design choice is motivated by the following reasons: | design choice is motivated by the following reasons: | |||
| o SPKI is globally unique. | o SPKI is globally unique. | |||
| o It is deterministic. | o It is deterministic. | |||
| o It allows the avoidance of extra cycles that may be induced by | o It allows the avoidance of extra cycles that may be induced by | |||
| 'cuid' collision. | 'cuid' collision. | |||
| o DOTS clients do not need to store the 'cuid' in a persistent | o DOTS clients do not need to store the 'cuid' in a persistent | |||
| storage. | storage. | |||
| o It allows the detection of compromised DOTS clients that do not | o It allows the detection of compromised DOTS clients that do not | |||
| adhere to the 'cuid' generation algorithm. | adhere to the 'cuid' generation algorithm. | |||
| Appendix C. Acknowledgements | Appendix C. Summary of Protocol Recommended/Default Values | |||
| +--------------------------------+---------------------------+ | ||||
| | Parameter | Recommended/Default Value | | ||||
| +--------------------------------+---------------------------+ | ||||
| | Port number | 4646 (tcp/udp) | | ||||
| | lifetime | 3600 seconds | | ||||
| | active-but-terminating | 120 seconds | | ||||
| | maximum active-but-terminating | 300 seconds | | ||||
| | heartbeat-interval | 30 seconds | | ||||
| | minimum 'heartbeat-interval' | 15 seconds | | ||||
| | maximum 'heartbeat-interval' | 240 seconds | | ||||
| | missing-hb-allowed | 15 | | ||||
| | max-retransmit | 3 | | ||||
| | ack-timeout | 2 seconds | | ||||
| | ack-random-factor | 1.5 | | ||||
| | probing-rate | 5 bytes/second | | ||||
| | trigger-mitigation | true | | ||||
| +--------------------------------+---------------------------+ | ||||
| Appendix D. Acknowledgements | ||||
| Many thanks to Martin Bjoerklund for the suggestion to use RFC8791. | Many thanks to Martin Bjoerklund for the suggestion to use RFC8791. | |||
| Thanks to Ebben Aries for the yangdoctors review and Dan Romascanu | Thanks to Valery Smyslov for the comments, guidance, and support. | |||
| for the opsdir review. | ||||
| C.1. Acknowledgements from RFC8782 | Thanks to Ebben Aries for the yangdoctors review, Dan Romascanu for | |||
| the opsdir review, Michael Tuexen for the tsv-art review, Dale Worley | ||||
| for the genart review, and Donald Eastlake for the secdir review. | ||||
| Thanks to Benjamin Kaduk for the AD review. | ||||
| Thanks to Martin Duke, Lars Eggert, Erik Kline, Murray Kucherawy, | ||||
| Eric Vyncke, and Robert Wilton for the IESG review. | ||||
| D.1. Acknowledgements from RFC8782 | ||||
| Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael | Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael | |||
| Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, | Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, | |||
| Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien | Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien | |||
| Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion | Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion | |||
| and comments. | and comments. | |||
| The authors would like to give special thanks to Kaname Nishizuka and | The authors would like to give special thanks to Kaname Nishizuka and | |||
| Jon Shallow for their efforts in implementing the protocol and | Jon Shallow for their efforts in implementing the protocol and | |||
| performing interop testing at IETF Hackathons. | performing interop testing at IETF Hackathons. | |||
| skipping to change at page 118, line 11 ¶ | skipping to change at page 116, line 43 ¶ | |||
| redirect signaling. | redirect signaling. | |||
| Special thanks to Benjamin Kaduk for the detailed AD review. | Special thanks to Benjamin Kaduk for the detailed AD review. | |||
| Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja | Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja | |||
| Kuehlewind, and Alissa Cooper for the review. | Kuehlewind, and Alissa Cooper for the review. | |||
| Thanks to Carsten Bormann for his review of the DOTS heartbeat | Thanks to Carsten Bormann for his review of the DOTS heartbeat | |||
| mechanism. | mechanism. | |||
| Appendix D. Contributors | Appendix E. Contributors | |||
| D.1. Authors of RFC8782 | E.1. Authors of RFC8782 | |||
| The authors of RFC8782 are listed below: | The authors of RFC8782 are listed below: | |||
| Tirumaleswar Reddy.K (editor) | Tirumaleswar Reddy.K (editor) | |||
| McAfee, Inc. | McAfee, Inc. | |||
| Embassy Golf Link Business Park | Embassy Golf Link Business Park | |||
| Bangalore 560071 | Bangalore 560071 | |||
| Karnataka | Karnataka | |||
| India | India | |||
| skipping to change at page 119, line 40 ¶ | skipping to change at page 117, line 40 ¶ | |||
| United States of America | United States of America | |||
| Email: andrew@moretension.com | Email: andrew@moretension.com | |||
| Nik Teague | Nik Teague | |||
| Iron Mountain Data Centers | Iron Mountain Data Centers | |||
| United Kingdom | United Kingdom | |||
| Email: nteague@ironmountain.co.uk | Email: nteague@ironmountain.co.uk | |||
| D.2. Contributors to RFC8782 | E.2. Contributors to RFC8782 | |||
| The following individuals have contributed to RFC8782: | The following individuals have contributed to RFC8782: | |||
| Jon Shallow | Jon Shallow | |||
| NCC Group | NCC Group | |||
| Email: jon.shallow@nccgroup.trust | Email: jon.shallow@nccgroup.trust | |||
| Mike Geller | Mike Geller | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| End of changes. 170 change blocks. | ||||
| 1125 lines changed or deleted | 1074 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||