| < draft-ietf-dots-rfc8782-bis-07.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: November 28, 2021 T. Reddy.K | Expires: December 5, 2021 T. Reddy.K | |||
| McAfee | McAfee | |||
| May 27, 2021 | 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-07 | 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 November 28, 2021. | This Internet-Draft will expire on December 5, 2021. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 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 | |||
| 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.1.1. Building Mitigation Requests . . . . . . . . . . 13 | 4.4.1.1. Building Mitigation Requests . . . . . . . . . . 14 | |||
| 4.4.1.2. Server-domain DOTS Gateways . . . . . . . . . . . 21 | 4.4.1.2. Server-domain DOTS Gateways . . . . . . . . . . . 22 | |||
| 4.4.1.3. Processing Mitigation Requests . . . . . . . . . 23 | 4.4.1.3. Processing Mitigation Requests . . . . . . . . . 24 | |||
| 4.4.2. Retrieve Information Related to a Mitigation . . . . 29 | 4.4.2. Retrieve Information Related to a Mitigation . . . . 30 | |||
| 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 35 | 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 36 | |||
| 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37 | 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 38 | |||
| 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38 | 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 39 | |||
| 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40 | 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 41 | |||
| 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41 | 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 42 | |||
| 4.5.1. Discover Configuration Parameters . . . . . . . . . . 43 | 4.5.1. Discover Configuration Parameters . . . . . . . . . . 44 | |||
| 4.5.2. Convey DOTS Signal Channel Session Configuration . . 47 | 4.5.2. Convey DOTS Signal Channel Session Configuration . . 48 | |||
| 4.5.3. Configuration Freshness and Notifications . . . . . . 53 | 4.5.3. Configuration Freshness and Notifications . . . . . . 54 | |||
| 4.5.4. Delete DOTS Signal Channel Session Configuration . . 54 | 4.5.4. Delete DOTS Signal Channel Session Configuration . . 55 | |||
| 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55 | 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 56 | |||
| 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57 | 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 58 | |||
| 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 60 | 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 61 | |||
| 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 60 | 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 61 | |||
| 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 63 | 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 64 | |||
| 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 67 | 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 68 | |||
| 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 80 | 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 . . . . . . . . . . . . . . . 87 | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 | Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 | |||
| 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90 | 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 91 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 | |||
| 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 91 | 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 92 | |||
| 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 92 | 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 93 | |||
| 10.3. Media Type Registration . . . . . . . . . . . . . . . . 92 | 10.3. Media Type Registration . . . . . . . . . . . . . . . . 93 | |||
| 10.4. CoAP Content-Formats Registration . . . . . . . . . . . 93 | 10.4. CoAP Content-Formats Registration . . . . . . . . . . . 94 | |||
| 10.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . 94 | 10.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . 95 | |||
| 10.6. DOTS Signal Channel Protocol Registry . . . . . . . . . 94 | 10.6. DOTS Signal Channel Protocol Registry . . . . . . . . . 95 | |||
| 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry . . 94 | 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry . . 95 | |||
| 10.6.1.1. Registration Template . . . . . . . . . . . . . 94 | 10.6.1.1. Registration Template . . . . . . . . . . . . . 95 | |||
| 10.6.1.2. Update Subregistry Content . . . . . . . . . . . 96 | 10.6.1.2. Update Subregistry Content . . . . . . . . . . . 97 | |||
| 10.6.2. Status Codes Subregistry . . . . . . . . . . . . . . 96 | 10.6.2. Status Codes Subregistry . . . . . . . . . . . . . . 97 | |||
| 10.6.3. Conflict Status Codes Subregistry . . . . . . . . . 98 | 10.6.3. Conflict Status Codes Subregistry . . . . . . . . . 99 | |||
| 10.6.4. Conflict Cause Codes Subregistry . . . . . . . . . . 99 | 10.6.4. Conflict Cause Codes Subregistry . . . . . . . . . . 100 | |||
| 10.6.5. Attack Status Codes Subregistry . . . . . . . . . . 100 | 10.6.5. Attack Status Codes Subregistry . . . . . . . . . . 101 | |||
| 10.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 101 | 10.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 102 | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 103 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 104 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 105 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 106 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 108 | 12.2. Informative References . . . . . . . . . . . . . . . . . 109 | |||
| Appendix A. Summary of Changes From RFC8782 . . . . . . . . . . 113 | Appendix A. Summary of Changes From RFC8782 . . . . . . . . . . 114 | |||
| Appendix B. CUID Generation . . . . . . . . . . . . . . . . . . 114 | Appendix B. CUID Generation . . . . . . . . . . . . . . . . . . 115 | |||
| Appendix C. Summary of Protocol Recommended/Default Values . . . 114 | Appendix C. Summary of Protocol Recommended/Default Values . . . 115 | |||
| Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 115 | Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 116 | |||
| D.1. Acknowledgements from RFC8782 . . . . . . . . . . . . . . 115 | D.1. Acknowledgements from RFC8782 . . . . . . . . . . . . . . 116 | |||
| Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 115 | Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 116 | |||
| E.1. Authors of RFC8782 . . . . . . . . . . . . . . . . . . . 115 | E.1. Authors of RFC8782 . . . . . . . . . . . . . . . . . . . 116 | |||
| E.2. Contributors to RFC8782 . . . . . . . . . . . . . . . . . 116 | E.2. Contributors to RFC8782 . . . . . . . . . . . . . . . . . 117 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 41 ¶ | skipping to change at page 4, line 41 ¶ | |||
| [RFC8612]. | [RFC8612]. | |||
| In typical deployments, the DOTS client belongs to a different | In typical deployments, the DOTS client belongs to a different | |||
| administrative domain than the DOTS server. For example, the DOTS | administrative domain than the DOTS server. For example, the DOTS | |||
| client is embedded in a firewall protected services owned and | client is embedded in a firewall protected services owned and | |||
| operated by a customer, while the DOTS server is owned and operated | operated by a customer, while the DOTS server is owned and operated | |||
| by a different administrative entity (service provider, typically) | by a different administrative entity (service provider, typically) | |||
| providing DDoS mitigation services. The latter might or might not | providing DDoS mitigation services. The latter might or might not | |||
| provide connectivity services to the network hosting the DOTS client. | provide connectivity services to the network hosting the DOTS client. | |||
| The DOTS server may or may not not be co-located with the DOTS | The DOTS server may or may not be co-located with the DOTS mitigator. | |||
| mitigator. In typical deployments, the DOTS server belongs to the | In typical deployments, the DOTS server belongs to the same | |||
| same administrative domain as the mitigator. The DOTS client can | administrative domain as the mitigator. The DOTS client can | |||
| communicate directly with a DOTS server or indirectly via a DOTS | communicate directly with a DOTS server or indirectly via a DOTS | |||
| gateway. | 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) | |||
| 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 9, line 37 ¶ | skipping to change at page 9, line 37 ¶ | |||
| server. | 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 | |||
| used to prevent message processing failure of a DOTS signal channel | used to prevent message processing failure of a DOTS signal channel | |||
| message enriched with telemetry data: (1) DOTS agents use dedicated | message enriched with telemetry data: (1) DOTS agents use dedicated | |||
| (new) path suffixes (Section 5 of [I-D.ietf-dots-telemetry]) and (2) | (new) path suffixes (Section 5 of [I-D.ietf-dots-telemetry]) and (2) | |||
| a DOTS server won't include telemetry attributes in its responses | a DOTS server won't include telemetry attributes in its responses | |||
| skipping to change at page 13, line 43 ¶ | 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 | 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 | |||
| skipping to change at page 14, line 33 ¶ | 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 | |||
| skipping to change at page 17, line 43 ¶ | skipping to change at page 18, line 4 ¶ | |||
| 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 30 ¶ | 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. | |||
| skipping to change at page 21, line 36 ¶ | skipping to change at page 22, line 36 ¶ | |||
| 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 8: 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 | ||||
| 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.2. Server-domain DOTS Gateways | 4.4.1.2. Server-domain DOTS Gateways | |||
| In deployments where server-domain DOTS gateways are enabled, | In deployments where server-domain DOTS gateways are enabled, | |||
| identity information about the origin source client domain ('cdid') | identity information about the origin source client domain ('cdid') | |||
| SHOULD be propagated to the DOTS server. That information is meant | SHOULD be propagated to the DOTS server. That information is meant | |||
| to assist the DOTS server in enforcing some policies such as grouping | to assist the DOTS server in enforcing some policies such as grouping | |||
| DOTS clients that belong to the same DOTS domain, limiting the number | DOTS clients that belong to the same DOTS domain, limiting the number | |||
| of DOTS requests, and identifying the mitigation scope. These | of DOTS requests, and identifying the mitigation scope. These | |||
| policies can be enforced per client, per client domain, or both. | policies can be enforced per client, per client domain, or both. | |||
| Also, the identity information may be used for auditing and debugging | Also, the identity information may be used for auditing and debugging | |||
| purposes. | purposes. | |||
| Figure 9 shows an example of a request relayed by a server-domain | Figure 9 shows an example of a request relayed by a server-domain | |||
| DOTS gateway. | DOTS gateway. | |||
| 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 24, line 7 ¶ | skipping to change at page 24, line 51 ¶ | |||
| 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 | |||
| associated with the 'alias-name' with the corresponding parameter | associated with the 'alias-name' with the corresponding parameter | |||
| values in 'target-prefix', 'target-port-range', 'target-fqdn', or | values in 'target-prefix', 'target-port-range', 'target-fqdn', or | |||
| 'target-uri'. | '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 28, line 5 ¶ | 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 35, line 26 ¶ | skipping to change at page 36, line 26 ¶ | |||
| 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 45, line 30 ¶ | 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 69, line 24 ¶ | skipping to change at page 70, line 24 ¶ | |||
| 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 XXXX; see | This version of this YANG module is part of RFC XXXX; see | |||
| the RFC itself for full legal notices."; | the RFC itself for full legal notices."; | |||
| revision 2021-03-02 { | revision 2021-03-02 { | |||
| description | description | |||
| "Updated revision to comply with RFC8791."; | "Updated revision to comply with RFC8791. | |||
| This version is not backward compatible with the version | ||||
| published in RFC 8782."; | ||||
| reference | reference | |||
| "RFC XXXX: Distributed Denial-of-Service Open Threat | "RFC XXXX: Distributed Denial-of-Service Open Threat | |||
| Signaling (DOTS) Signal Channel Specification"; | Signaling (DOTS) Signal Channel Specification"; | |||
| } | } | |||
| revision 2020-05-28 { | revision 2020-05-28 { | |||
| description | description | |||
| "Initial revision."; | "Initial revision."; | |||
| reference | reference | |||
| "RFC 8782: Distributed Denial-of-Service Open Threat | "RFC 8782: Distributed Denial-of-Service Open Threat | |||
| Signaling (DOTS) Signal Channel Specification"; | Signaling (DOTS) Signal Channel Specification"; | |||
| skipping to change at page 73, line 12 ¶ | skipping to change at page 74, line 15 ¶ | |||
| type yang:zero-based-counter64; | type yang:zero-based-counter64; | |||
| units "bytes"; | units "bytes"; | |||
| description | description | |||
| "The total dropped byte count for the mitigation | "The total dropped byte count for the mitigation | |||
| request since the attack mitigation was triggered. | request since the attack mitigation was triggered. | |||
| The count wraps around when it reaches the maximum value | The count wraps around when it reaches the maximum value | |||
| of counter64 for dropped bytes."; | of counter64 for dropped bytes."; | |||
| } | } | |||
| leaf bps-dropped { | leaf bps-dropped { | |||
| type yang:gauge64; | type yang:gauge64; | |||
| units "bytes per second"; | ||||
| description | description | |||
| "The average number of dropped bits per second for | "The average number of dropped bytes per second for | |||
| the mitigation request since the attack | the mitigation request since the attack | |||
| mitigation was triggered. This should be over | mitigation was triggered. This should be over | |||
| five-minute intervals (that is, measuring bytes | five-minute intervals (that is, measuring bytes | |||
| into five-minute buckets and then averaging these | into five-minute buckets and then averaging these | |||
| buckets over the time since the mitigation was | buckets over the time since the mitigation was | |||
| triggered)."; | triggered)."; | |||
| } | } | |||
| leaf pkts-dropped { | leaf pkts-dropped { | |||
| type yang:zero-based-counter64; | type yang:zero-based-counter64; | |||
| description | description | |||
| "The total number of dropped packet count for the | "The total number of dropped packet count for the | |||
| mitigation request since the attack mitigation was | mitigation request since the attack mitigation was | |||
| triggered. The count wraps around when it reaches | triggered. The count wraps around when it reaches | |||
| the maximum value of counter64 for dropped packets."; | the maximum value of counter64 for dropped packets."; | |||
| } | } | |||
| leaf pps-dropped { | leaf pps-dropped { | |||
| type yang:gauge64; | type yang:gauge64; | |||
| units "packets per second"; | ||||
| description | description | |||
| "The average number of dropped packets per second | "The average number of dropped packets per second | |||
| for the mitigation request since the attack | for the mitigation request since the attack | |||
| mitigation was triggered. This should be over | mitigation was triggered. This should be over | |||
| five-minute intervals (that is, measuring packets | five-minute intervals (that is, measuring packets | |||
| into five-minute buckets and then averaging these | into five-minute buckets and then averaging these | |||
| buckets over the time since the mitigation was | buckets over the time since the mitigation was | |||
| triggered)."; | triggered)."; | |||
| } | } | |||
| } | } | |||
| case client-to-server-only { | case client-to-server-only { | |||
| description | description | |||
| "These data nodes appear only in a mitigation message | "These data nodes appear only in a mitigation message | |||
| sent from the client to the server."; | sent from the client to the server."; | |||
| leaf attack-status { | leaf attack-status { | |||
| type iana-dots-signal:attack-status; | type iana-dots-signal:attack-status; | |||
| description | description | |||
| "Indicates the status of an attack as seen by the | "Indicates the status of an attack as seen by the | |||
| DOTS client. | DOTS client. | |||
| Ths is is a mandatory attribute when a client | This is a mandatory attribute when a client | |||
| performs an efficacy update."; | performs an efficacy update."; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| grouping config-parameters { | grouping config-parameters { | |||
| description | description | |||
| "Subset of DOTS signal channel session configuration."; | "Subset of DOTS signal channel session configuration."; | |||
| skipping to change at page 79, line 40 ¶ | skipping to change at page 80, line 46 ¶ | |||
| */ | */ | |||
| sx:structure dots-signal { | sx:structure dots-signal { | |||
| description | description | |||
| "Main structure for DOTS signal message. | "Main structure for DOTS signal message. | |||
| A DOTS signal message can be a mitigation, a configuration, | A DOTS signal message can be a mitigation, a configuration, | |||
| a redirected, or a heartbeat signal message."; | a redirected, or a heartbeat signal message."; | |||
| choice message-type { | choice message-type { | |||
| description | description | |||
| "Can be a mitigation, a configuration, or a redirect | "Can be a mitigation, a configuration, a redirect, or | |||
| message."; | a heartbeat message."; | |||
| case mitigation-scope { | case mitigation-scope { | |||
| description | description | |||
| "Mitigation scope of a mitigation message."; | "Mitigation scope of a mitigation message."; | |||
| uses mitigation-scope; | uses mitigation-scope; | |||
| } | } | |||
| case signal-config { | case signal-config { | |||
| description | description | |||
| "Configuration message."; | "Configuration message."; | |||
| uses signal-config; | uses signal-config; | |||
| } | } | |||
| skipping to change at page 91, line 36 ¶ | skipping to change at page 92, line 39 ¶ | |||
| 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 92, 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 109, line 22 ¶ | skipping to change at page 110, line 22 ¶ | |||
| 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-05 (work in progress), November 2020. | multihoming-05 (work in progress), November 2020. | |||
| [I-D.ietf-dots-telemetry] | [I-D.ietf-dots-telemetry] | |||
| Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. | Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. | |||
| Shallow, "Distributed Denial-of-Service Open Threat | Shallow, "Distributed Denial-of-Service Open Threat | |||
| Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 | Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 | |||
| (work in progress), December 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-43 (work in progress), April | 1.3", draft-ietf-tls-dtls13-43 (work in progress), April | |||
| 2021. | 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 113, line 10 ¶ | 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 | [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling | |||
| (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, | (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, | |||
| January 2021, <https://www.rfc-editor.org/info/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 | |||
| skipping to change at page 114, line 10 ¶ | skipping to change at page 115, line 10 ¶ | |||
| 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 | o Add Appendix C to list recommended/default values of key DOTS | |||
| signal channel parameters. | 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 | |||
| skipping to change at page 115, line 17 ¶ | skipping to change at page 116, line 17 ¶ | |||
| Many thanks to Martin Bjoerklund for the suggestion to use RFC8791. | Many thanks to Martin Bjoerklund for the suggestion to use RFC8791. | |||
| Thanks to Valery Smyslov for the comments, guidance, and support. | Thanks to Valery Smyslov for the comments, guidance, and support. | |||
| Thanks to Ebben Aries for the yangdoctors review, Dan Romascanu for | Thanks to Ebben Aries for the yangdoctors review, Dan Romascanu for | |||
| the opsdir review, Michael Tuexen for the tsv-art review, Dale Worley | the opsdir review, Michael Tuexen for the tsv-art review, Dale Worley | |||
| for the genart review, and Donald Eastlake for the secdir review. | for the genart review, and Donald Eastlake for the secdir review. | |||
| Thanks to Benjamin Kaduk for the AD 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 | 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 | |||
| End of changes. 44 change blocks. | ||||
| 122 lines changed or deleted | 139 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/ | ||||