[要約] RFC 9132は、DDoS攻撃の発生を通知し、ネットワーク側での迅速な緩和措置を要請するためのプロトコル「DOTS」の信号チャネル仕様を規定しています。軽量なCoAPをベースに、(D)TLSによる認証と暗号化、CBORによる効率的な転送を用い、攻撃下でも確実に緩和要求やステータス情報を交換できる仕組みを定義しています。本文書はRFC 8782を置換し、下位互換性を維持しつつ、セッション構成の柔軟性向上やフィードバック情報の詳細化、運用上の明確化を取り込んだインターネット標準です。
Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Request for Comments: 9132 Orange
Obsoletes: 8782 J. Shallow
Category: Standards Track
ISSN: 2070-1721 T. Reddy.K
Akamai
September 2021
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
分散型サービス拒否オープン脅威シグナリング（DOTS）シグナルチャネル仕様
Abstract
概要
This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
このドキュメントは、分散サービス拒否オープン脅威シグナリング（DOTS）信号チャネルを指定して、分散サービス拒否（DDoS）攻撃に対する保護の必要性（DDoS）攻撃を可能にするためのプロトコルです。要求しているクライアント。
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.
コンパニオン文書は、ドットデータチャネル、ドット管理および構成目的のための別個の信頼性の高い通信層を定義します。
This document obsoletes RFC 8782.
この文書はRFC 8782を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9132.
この文書の現在の状況、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9132で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 2. Terminology 3. Design Overview 3.1. Backward Compatibility Considerations 4. DOTS Signal Channel: Messages & Behaviors 4.1. DOTS Server(s) Discovery 4.2. CoAP URIs 4.3. Happy Eyeballs for DOTS Signal Channel 4.4. DOTS Mitigation Methods 4.4.1. Request Mitigation 4.4.1.1. Building Mitigation Requests 4.4.1.2. Server-Domain DOTS Gateways 4.4.1.3. Processing Mitigation Requests 4.4.2. Retrieve Information Related to a Mitigation 4.4.2.1. DOTS Servers Sending Mitigation Status 4.4.2.2. DOTS Clients Polling for Mitigation Status 4.4.3. Efficacy Update from DOTS Clients 4.4.4. Withdraw a Mitigation 4.5. DOTS Signal Channel Session Configuration 4.5.1. Discover Configuration Parameters 4.5.2. Convey DOTS Signal Channel Session Configuration 4.5.3. Configuration Freshness and Notifications 4.5.4. Delete DOTS Signal Channel Session Configuration 4.6. Redirected Signaling 4.7. Heartbeat Mechanism 5. DOTS Signal Channel YANG Modules 5.1. Tree Structure 5.2. IANA DOTS Signal Channel YANG Module 5.3. IETF DOTS Signal Channel YANG Module 6. YANG/JSON Mapping Parameters to CBOR 7. (D)TLS Protocol Profile and Performance Considerations 7.1. (D)TLS Protocol Profile 7.2. (D)TLS 1.3 Considerations 7.3. DTLS MTU and Fragmentation 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 9. Error Handling 10. IANA Considerations 10.1. DOTS Signal Channel UDP and TCP Port Number 10.2. Well-Known 'dots' URI 10.3. Media Type Registration 10.4. CoAP Content-Formats Registration 10.5. CBOR Tag Registration 10.6. DOTS Signal Channel Protocol Registry 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry 10.6.1.1. Registration Template 10.6.1.2. Update Subregistry Content 10.6.2. Status Codes Subregistry 10.6.3. Conflict Status Codes Subregistry 10.6.4. Conflict Cause Codes Subregistry 10.6.5. Attack Status Codes Subregistry 10.7. DOTS Signal Channel YANG Modules 11. Security Considerations 12. References 12.1. Normative References 12.2. Informative References Appendix A. Summary of Changes From RFC 8782 Appendix B. CUID Generation Appendix C. Summary of Protocol Recommended/Default Values Acknowledgements Contributors Authors' Addresses
A Distributed Denial-of-Service (DDoS) attack is a distributed attempt to make machines or network resources unavailable to their intended users. In most cases, sufficient scale for an effective attack can be achieved by compromising enough end hosts and using those infected hosts to perpetrate and amplify the attack. The victim in this attack can be an application server, a host, a router, a firewall, or an entire network.
分散サービス拒否（DDoS）攻撃は、機械やネットワークリソースを自分の意図されたユーザーに利用できないようにするための分散試行です。ほとんどの場合、十分なエンドホストを犠牲にし、それらの感染したホストを使用して攻撃を攻撃して増幅することで、効果的な攻撃のための十分な規模を達成することができます。この攻撃の被害者は、アプリケーションサーバー、ホスト、ルータ、ファイアウォール、またはネットワーク全体にすることができます。
Network applications have finite resources, like CPU cycles, the number of processes or threads they can create and use, the maximum number of simultaneous connections they can handle, the resources assigned to the control plane, etc. When processing network traffic, such applications are supposed to use these resources to provide the intended functionality in the most efficient manner. However, a DDoS attacker may be able to prevent an application from performing its intended task by making the application exhaust its finite resources.
ネットワークアプリケーションには、CPUサイクル、作成および使用できるプロセスまたはスレッドの数など、CPUサイクルの数、使用可能な同時接続の最大数、コントロールプレーンに割り当てられているリソースなど、このようなアプリケーションはこれらのリソースを使用して、意図した機能を最も効率的な方法で提供することになっています。しかしながら、DDoS攻撃者は、アプリケーションがその有限のリソースを排出させることによって、アプリケーションがその意図されたタスクを実行するのを防ぐことができるかもしれない。
A TCP DDoS SYN flood [RFC4987], for example, is a memory-exhausting attack, while an ACK flood is a CPU-exhausting attack. Attacks on the link are carried out by sending enough traffic so that the link becomes congested, thereby likely causing packet loss for legitimate traffic. Stateful firewalls can also be attacked by sending traffic that causes the firewall to maintain an excessive number of states that may jeopardize the firewall's operation overall, in addition to likely performance impacts. The firewall then runs out of memory, and it can no longer instantiate the states required to process legitimate flows. Other possible DDoS attacks are discussed in [RFC4732].
たとえば、TCP DDoS SYNフラッド[RFC4987]はメモリ排気攻撃ですが、ACKフラッドはCPU-排気攻撃です。リンクへの攻撃は、リンクが混雑するように十分なトラフィックを送信することによって実行され、それによって正当なトラフィックのためのパケット損失を引き起こす可能性があります。ステートフルファイアウォールは、ファイアウォールが過度の数の状態を維持することによって、ファイアウォールの多数の状態を維持することによって、パフォーマンスの影響に加えて、過剰な数の状態を維持することによって攻撃することもできます。ファイアウォールはメモリから実行されず、正当なフローを処理するために必要な状態をインスタンス化できなくなります。他の可能なDDoS攻撃は[RFC4732]で説明されています。
In many cases, it may not be possible for network administrators to determine the cause(s) of an attack. They may instead just realize that certain resources seem to be under attack. This document defines a lightweight protocol that allows a DOTS client to request mitigation from one or more DOTS servers for protection against detected, suspected, or anticipated attacks. This protocol enables cooperation between DOTS agents to permit a highly automated network defense that is robust, reliable, and secure. Note that "secure" means the support of the features defined in Section 2.4 of [RFC8612].
多くの場合、ネットワーク管理者が攻撃の原因を判断することは不可能かもしれません。彼らは代わりに、特定の資源が攻撃を受けているように思われることを理解するかもしれません。このドキュメントは、ドットクライアントが、検出された、疑われる、または予想される攻撃に対する保護のために、1つまたは複数のドットサーバーからの軽減を要求することを可能にする軽量プロトコルを定義します。このプロトコルは、ドットエージェント間の協力を可能にして、堅牢で信頼性があり、安全である高度に自動化されたネットワーク防御を可能にします。「セキュア」とは、[RFC8612]のセクション2.4で定義されている機能のサポートを意味します。
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 service 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.
一般的な展開では、ドットクライアントはドットサーバーとは異なる管理ドメインに属します。例えば、ドットクライアントは、顧客によって所有および操作されたファイアウォール保護されたサービスに埋め込まれており、ドットサーバはDDoS軽減サービスを提供する別の管理エンティティ（典型的にはサービスプロバイダ）によって所有および操作される。後者は、ドットクライアントをホストしているネットワークに接続サービスを提供しない場合があります。
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.
ドットサーバは、ドット採取装置と同じ場所に配置されていてもいなくてもよい。一般的な展開では、ドットサーバーはMitigatorと同じ管理ドメインに属します。ドットクライアントは、ドットサーバと直接通信することも、ドットゲートウェイを介して間接的に通信することができる。
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 operating on the access network. A DOTS client is located on the Local Area Network (LAN), while a DOTS gateway is embedded in the Customer Premises Equipment (CPE).
ドットエージェントの展開を示すネットワーク図の例を図1に示します。この例では、ドットサーバがアクセスネットワーク上で動作している。ドットクライアントはローカルエリアネットワーク（LAN）にあり、ドットゲートウェイは顧客宅内機器（CPE）に埋め込まれています。
Network
Resource CPE Router Access Network __________
+-------------+ +--------------+ +-------------+ / \
| | | | | | | Internet |
| DOTS Client +---+ DOTS Gateway +---+ DOTS Server +----+ |
| | | | | | | |
+-------------+ +--------------+ +-------------+ \__________/
Figure 1: Sample DOTS Deployment (1)
図1：サンプルドット展開（1）
DOTS servers can also be reachable over the Internet, as depicted in Figure 2.
図2に示すように、ドットサーバはインターネット上で到達可能であり得る。
Network DDoS Mitigation
Resource CPE Router _________ Service
+-------------+ +--------------+ / \ +-------------+
| | | | | | | |
| DOTS Client +---+ DOTS Gateway +---+ Internet +---+ DOTS Server |
| | | | | | | |
+-------------+ +--------------+ \_________/ +-------------+
Figure 2: Sample DOTS Deployment (2)
図2：サンプルドット展開（2）
This document focuses on the DOTS signal channel. This is a companion document of the DOTS data channel specification [RFC8783] that defines a configuration and a bulk data exchange mechanism supporting the DOTS signal channel.
この文書はドット信号チャネルに焦点を当てています。これは、ドット信号チャネルをサポートする構成とバルクデータ交換機構を定義するドットデータチャネル仕様[RFC8783]のコンパニオン文書です。
Backward compatibility (including upgrade) considerations are discussed in Section 3.1.
下位互換性（アップグレードを含む）考慮事項については、セクション3.1で説明します。
The DOTS signal channel is built on top of the Constrained Application Protocol (CoAP) [RFC7252], a lightweight protocol originally designed for constrained devices and networks. The many features of CoAP (expectation of packet loss, support for asynchronous Non-confirmable messaging, congestion control, small message overhead limiting the need for fragmentation, use of minimal resources, and support for (D)TLS) make it a good candidate upon which to build the DOTS signaling mechanism.
DOTS信号チャネルは、制約付きアプリケーションプロトコル（COAAP）[RFC7252]の上に構築されており、最初に制約付きデバイスおよびネットワーク用に設計された軽量プロトコル。CoAPの多くの機能（パケット損失の期待、非同期以外のメッセージングのサポート、輻輳制御、断片化の必要性、断片化の必要性、最小限のリソースの使用、および（D）TLSのサポート）を候補者にするDOTSシグナリングメカニズムを構築するには、
DOTS clients and servers behave as CoAP endpoints. By default, a DOTS client behaves as a CoAP client and a DOTS server behaves as CoAP server. Nevertheless, a DOTS client (or server) behaves as a CoAP server (or client) for specific operations, such as DOTS heartbeat operations (Section 4.7).
ドットクライアントとサーバーはCoAPエンドポイントとして動作します。デフォルトでは、DOTSクライアントはCoAPクライアントとして動作し、DOTSサーバーはCoAPサーバーとして動作します。それにもかかわらず、ドットクライアント（またはサーバー）は、ドットハートビート操作（セクション4.7）などの特定の操作のためのCoAPサーバー（またはクライアント）として動作します。
The DOTS signal channel is layered on existing standards (see Figure 3).
ドット信号チャネルは既存の標準上に階層化されています（図3を参照）。
+---------------------+
| DOTS Signal Channel |
+---------------------+
| CoAP |
+----------+----------+
| TLS | DTLS |
+----------+----------+
| TCP | UDP |
+----------+----------+
| IP |
+---------------------+
Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over (D)TLS
図3：CoAP上のドット信号チャネルの抽象層（D）TLS
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 dynamic discovery [RFC8973]. Absent such mutual agreement, the DOTS signal channel MUST run over port number 4646, as defined in Section 10.1, for both UDP and TCP (that is, the DOTS server listens on port number 4646). In order to use a distinct port number (as opposed to 4646), DOTS clients and servers SHOULD support a configurable parameter to supply the port number to use.
場合によっては、DOTSクライアントとサーバーは、明示的な設定や動的発見[RFC8973]などにより、特定のポート番号を使用することに相互合意している場合があります。そのような相互合意がない場合、DOTSシグナルチャネルは、セクション10.1で定義されているように、UDPとTCPの両方でポート番号4646上で実行されなければなりません (MUST)（すなわち、DOTSサーバーはポート番号4646でリッスンします）。（4646とは異なる）個別のポート番号を使用するために、DOTSクライアントとサーバーは使用するポート番号を指定するための設定可能パラメータをサポートすべきです (SHOULD)。
| Note: The rationale for not using the default port number 5684
| ((D)TLS CoAP) is to avoid the discovery of services and
| resources discussed in [RFC7252] and allow for differentiated
| behaviors in environments where both a DOTS gateway and an
| Internet of Things (IoT) gateway (e.g., Figure 3 of [RFC7452])
| are co-located.
|
| Particularly, the use of a default port number is meant to
| simplify DOTS deployment in scenarios where no explicit IP
| address configuration is required. For example, the use of the
| default router as the DOTS server aims to ease DOTS deployment
| within LANs (in which CPEs embed a DOTS gateway, as illustrated
| in Figures 1 and 2) without requiring a sophisticated discovery
| method and configuration tasks within the LAN. It is also
| possible to use anycast addresses for DOTS servers to simplify
| DOTS client configuration, including service discovery. In
| such an anycast-based scenario, a DOTS client initiating a DOTS
| session to the DOTS server anycast address may, for example, be
| (1) redirected to the DOTS server unicast address to be used by
| the DOTS client following the procedure discussed in
| Section 4.6 or (2) relayed to a unicast DOTS server.
The DOTS signal channel can be established between two DOTS agents prior to or during an attack. The DOTS signal channel is initiated by the DOTS client. The DOTS client can then negotiate, configure, and retrieve the DOTS signal channel session behavior with its DOTS peer (Section 4.5). Once the signal channel is established, the DOTS agents may periodically send heartbeats to keep the channel active (Section 4.7). At any time, the DOTS client may send a mitigation request message (Section 4.4) to a DOTS server over the active signal channel. While mitigation is active (because of the higher likelihood of packet loss during a DDoS attack), the DOTS server periodically sends status messages to the client, including basic mitigation feedback details. Mitigation remains active until the DOTS client explicitly terminates mitigation or the mitigation lifetime expires. Also, the DOTS server may rely on the signal channel session loss to trigger mitigation for preconfigured mitigation requests (if any).
ドット信号チャネルは、攻撃の前または攻撃の間に2つのドットエージェント間で確立することができる。ドット信号チャネルはドットクライアントによって開始されます。ドットクライアントは、ドット信号チャネルセッションの動作をそのドットピアでネゴシエート、設定、および取得できます（セクション4.5）。信号チャネルが確立されると、ドットエージェントは周期的にハートビートを送信してチャネルをアクティブに保つ（セクション4.7）。いつでも、ドットクライアントは、アクティブ信号チャネルを介して緩和要求メッセージ（セクション4.4）をドットサーバに送信することができる。緩和はアクティブですが（DDoS攻撃中のパケット損失の可能性が高いため）、DOTSサーバーは定期的に基本的な軽減フィードバックの詳細を含むステータスメッセージをクライアントに送信します。緩和は、ドットクライアントが緩和または緩和寿命の有効期限を明示的に終了するまで積極的なままです。また、ドットサーバは、事前設定された緩和要求の緩和をトリガするために信号チャネルセッション損失に依存している（任意の場合）。
DOTS signaling can use DTLS over UDP and TLS over TCP. Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer capabilities. A Happy Eyeballs procedure for the DOTS signal channel is specified in Section 4.3.
ドットシグナリングは、TCPを介してUDP上のDTLSとTLSを使用できます。同様に、ドット要求は、IPv4またはIPv6転送機能を使用して送信されてもよい。ドット信号チャネルの幸せな眼球手続きはセクション4.3で指定されています。
A DOTS client is entitled to access only the resources it creates. In particular, a DOTS client cannot retrieve data related to mitigation requests created by other DOTS clients of the same DOTS client domain.
ドットクライアントは、作成したリソースのみにアクセスする権利があります。特に、ドットクライアントは、同じドットクライアントドメインの他のドットクライアントによって作成された緩和要求に関連するデータを取得することができない。
Messages exchanged between DOTS agents are serialized using Concise Binary Object Representation (CBOR) [RFC8949], a binary encoding scheme designed for small code and message size. CBOR-encoded payloads are used to carry signal-channel-specific payload messages that convey request parameters and response information, such as errors. In order to allow the reusing of data models across protocols, [RFC7951] specifies the JavaScript Object Notation (JSON) encoding of YANG-modeled data. A similar effort for CBOR is defined in [CORE-YANG-CBOR].
ドットエージェント間で交換されるメッセージは、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]、小コードとメッセージサイズ用に設計されたバイナリエンコード方式を使用して直列化されています。CBORエンコードされたペイロードは、要求パラメータとエラーなどの応答情報を伝達する信号チャネル固有のペイロードメッセージを搬送するために使用されます。プロトコル間でデータモデルの再利用を可能にするために、[RFC7951]は、YangモデルデータのJavaScriptオブジェクト表記（JSON）エンコーディングを指定します。CBORの同様の努力は[Core-Yang-Cbor]で定義されています。
DOTS agents determine that a CBOR data structure is a DOTS signal channel object from the application context, such as from the port number assigned to the DOTS signal channel. The other method DOTS agents use to indicate that a CBOR data structure is a DOTS signal channel object is the use of the "application/dots+cbor" content type (Section 10.3).
ドットエージェントは、CBORデータ構造が、ドット信号チャネルに割り当てられているポート番号などから、アプリケーションコンテキストからのドット信号チャネルオブジェクトであると判断します。他の方法ドットエージェントは、CBORデータ構造がドット信号チャネルオブジェクトであることを示すために使用され、「アプリケーション/ドットCBOR」コンテンツタイプ（セクション10.3）の使用です。
This document specifies a YANG module for representing DOTS mitigation scopes, DOTS signal channel session configuration data, and DOTS redirected signaling (Section 5). All parameters in the payload of the DOTS signal channel are mapped to CBOR types, as specified in Table 5 (Section 6).
このドキュメントは、ドットの軽減範囲、ドット信号チャネルセッション構成データ、およびドットリダイレクトシグナリングを表すためのYANGモジュールを指定します（セクション5）。ドット信号チャネルのペイロード内のすべてのパラメータは、表5で指定されているように、CBORタイプにマッピングされます（セクション6）。
In order to prevent fragmentation, DOTS agents must follow the recommendations documented in Section 4.6 of [RFC7252]. Refer to Section 7.3 for more details.
断片化を防ぐために、ドットエージェントは[RFC7252]のセクション4.6に記載されている推奨事項に従わなければなりません。詳細については7.3項を参照してください。
DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The payload included in CoAP responses with 2.xx Response Codes MUST be of content type "application/dots+cbor". CoAP responses with 4.xx and 5.xx error Response Codes MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The diagnostic payload may contain additional information to aid troubleshooting.
DOTSエージェントはGET、PUT、およびDELETE CoAPメソッドをサポートしなければなりません (MUST)。2.xx応答コードを持つCoAP応答に含まれるペイロードは、コンテンツタイプが「application/dots+cbor」でなければなりません (MUST)。4.xxおよび5.xxエラー応答コードを持つCoAP応答は、診断ペイロード（[RFC7252]のセクション5.5.2）を含まなければなりません (MUST)。診断ペイロードには、トラブルシューティングを支援するための追加情報が含まれる場合があります。
In deployments where multiple DOTS clients are enabled in a single network and administrative domain (called DOTS client domain), the DOTS server may detect conflicting mitigation requests from these clients. This document does not aim to specify a comprehensive list of conditions under which a DOTS server will characterize two mitigation requests from distinct DOTS clients as conflicting, nor does it recommend a DOTS server behavior for processing conflicting mitigation requests. Those considerations are implementation and deployment specific. Nevertheless, this document specifies the mechanisms to notify DOTS clients when conflicts occur, including the conflict cause (Section 4.4.1.3).
単一のネットワークおよび管理ドメイン（ドットクライアントドメインと呼ばれる）で複数のドットクライアントが有効になっている展開では、ドットサーバーはこれらのクライアントから競合する緩和要求を検出できます。この文書は、DOTSサーバーが競合すると、競合すると競合する緩和要求を処理するためのドットサーバーの動作を推奨することも、ドットサーバーが2つの緩和要求を特徴付ける条件の包括的なリストを指定することを目的としていません。これらの考慮事項は実装と展開固有です。それにもかかわらず、このドキュメントは競合の原因を含めて競合が発生したときにドットクライアントに通知するメカニズムを指定します（4.4.1.3項）。
In deployments where one or more translators (e.g., Traditional NAT [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are enabled between the client's network and the DOTS server, any DOTS signal channel messages forwarded to a DOTS server MUST NOT include internal IP addresses/prefixes and/or port numbers; instead, external addresses/prefixes and/or port numbers as assigned by the translator MUST be used. This document does not make any recommendations about possible translator discovery mechanisms. The following are some (non-exhaustive) deployment examples that may be considered:
クライアントのネットワークとDOTSサーバーの間で1つ以上の変換器（例えば、Traditional NAT [RFC3022]、CGN [RFC6888]、NAT64 [RFC6146]、NPTv6 [RFC6296]）が有効になっている配備では、DOTSサーバーに転送されるDOTSシグナルチャネルメッセージに内部IPアドレス/プレフィックスおよび/またはポート番号を含めてはならず (MUST NOT)、代わりに変換器によって割り当てられた外部アドレス/プレフィックスおよび/またはポート番号が使用されなければなりません (MUST)。本文書は、考えられる変換器発見メカニズムについてはいかなる推奨も行いません。以下は考慮される可能性のある（網羅的ではない）配備例です:
* Port Control Protocol (PCP) [RFC6887] or Session Traversal Utilities for NAT (STUN) [RFC8489] may be used by the client to retrieve the external addresses/prefixes and/or port numbers. Information retrieved by means of PCP or STUN will be used to feed the DOTS signal channel messages that will be sent to a DOTS server.
* A DOTS gateway may be co-located with the translator. The DOTS gateway will need to update the DOTS messages based upon the local translator's binding table.
* ドットゲートウェイは翻訳者と同じ場所に配置することができる。ドットゲートウェイは、ローカルトランスレータのバインディングテーブルに基づいてドットメッセージを更新する必要があります。
For both legacy [RFC8782] and implementations that follow the present specification, a DOTS signal channel attribute will thus have the same CBOR key value and CBOR major type. The only upgrade that is required to [RFC8782] implementations is to handle the CBOR key value range "128-255" as comprehension-optional instead of comprehension-required. Note that this range is anticipated to be used by the DOTS telemetry [DOTS-TELEMETRY] in which the following means are used to prevent message processing failure of a DOTS signal channel message enriched with telemetry data: (1) DOTS agents use dedicated (new) path suffixes (Section 5 of [DOTS-TELEMETRY]) and (2) a DOTS server won't include telemetry attributes in its responses unless it is explicitly told to do so by a DOTS client (Section 6.1.2 of [DOTS-TELEMETRY]).
レガシー[RFC8782]と本明細書に続く実装の両方で、ドット信号チャネル属性は、同じCBORキー値とCBORメジャータイプを持ちます。[RFC8782]実装に必要なアップグレードのみは、理解が必要ではなく、柔迅に任意のCBORキー値範囲 "128-255"を扱うことです。この範囲は、テレメトリデータを充実させたドット信号チャネルメッセージのメッセージ処理障害を防止するために以下の手段を使用したドットテレメトリ[ドットテレメトリ]によって使用されることが予想される：（1）ドットエージェント使用専用（新規））パスサフィックス（DOTS-Telemetry]のセクション5）と（2）ドットサーバーには、ドットクライアントによって明示的に言われていない限り、回答内のテレメトリ属性が含まれません（[ドット]のセクション6.1.2テレメトリー]）。
Future DOTS extensions that request a CBOR value in the range "128-255" MUST support means similar to the aforementioned DOTS telemetry ones.
「128-255」の範囲のCBOR値を要求する将来のDOTS拡張は、前述のDOTSテレメトリのものと同様の手段をサポートしなければなりません (MUST)。
This document assumes that DOTS clients are provisioned with the reachability information of their DOTS server(s) using any of a variety of means (e.g., local configuration or dynamic means, such as DHCP [RFC8973]). The description of such means is out of scope of this document.
この文書は、ドットクライアントが、さまざまな手段（例えば、DHCP [RFC8973]などのローカル構成または動的手段）のいずれかを使用して、ドットサーバーの到達可能性情報をプロビジョニングすることを前提としています。そのような手段の説明はこの文書の範囲外です。
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 requests when multiple DOTS servers are provisioned (e.g., contact all DOTS servers, select one DOTS server among the list). Such behavior is specified in other documents (e.g., [DOTS-MULTIHOMING]).
同様に、複数のドットサーバーがプロビジョニングされたときにドット要求を送信するためにドットクライアントが続くように行動を指定するのはこの文書の範囲外です（例：すべてのドットサーバーに連絡し、リストの中に1つのドットサーバーを選択します）。。そのような動作は他の文書（例えば、[ドット - マルチホーム]）で指定される。
The DOTS server MUST support the use of the path prefix of "/.well-known/" as defined in [RFC8615] and the registered name of "dots". Each DOTS operation is denoted by a path suffix that indicates the intended operation. The operation path (Table 1) is appended to the path prefix to form the URI used with a CoAP request to perform the desired DOTS operation.
DOTSサーバーは、[RFC8615]で定義されているパスプレフィックス「/.well-known/」と「dots」の登録名の使用をサポートしなければなりません (MUST)。各DOTS操作は、意図された操作を示すパスサフィックスによって表されます。操作パス（表1）がパスプレフィックスに追加され、目的のDOTS操作を実行するためのCoAP要求で使用されるURIが形成されます。
+=======================+================+=============+
| Operation | Operation Path | Details |
+=======================+================+=============+
| Mitigation | /mitigate | Section 4.4 |
+-----------------------+----------------+-------------+
| Session configuration | /config | Section 4.5 |
+-----------------------+----------------+-------------+
| Heartbeat | /hb | Section 4.7 |
+-----------------------+----------------+-------------+
Table 1: Operations and Corresponding URIs
表1：操作と対応するURI
[RFC8612] mentions that DOTS agents will have to support both connectionless and connection-oriented protocols. As such, the DOTS signal channel is designed to operate with DTLS over UDP and TLS over TCP. Further, a DOTS client may acquire a list of IPv4 and IPv6 addresses (Section 4.1), each of which can be used to contact the DOTS server using UDP and TCP. If no list of IPv4 and IPv6 addresses to contact the DOTS server is configured (or discovered), the DOTS client adds the IPv4/IPv6 addresses of its default router to the candidate list to contact the DOTS server.
[RFC8612]ドットエージェントがコネクションレスプロトコルと接続指向プロトコルの両方をサポートする必要があることを表します。そのように、ドット信号チャネルは、TCP上のUDPおよびTLS上のDTLSで動作するように設計されている。さらに、ドットクライアントはIPv4アドレスおよびIPv6アドレスのリストを取得し（セクション4.1）、それぞれUDPおよびTCPを使用してドットサーバに連絡するために使用することができる。DOTSサーバーに連絡するIPv4およびIPv6アドレスのリストが設定されていない場合（または検出された）場合、ドットクライアントはそのデフォルトルーターのIPv4/IPv6アドレスを候補リストに追加して、ドットサーバーに連絡します。
The following specifies the procedure to follow to select the address family and the transport protocol for sending DOTS signal channel messages.
以下は、ドット信号チャネルメッセージを送信するためのアドレスファミリとトランスポートプロトコルを選択するための手順を次に示します。
Such a procedure is needed to avoid experiencing long connection delays. For example, if an IPv4 path to a DOTS server is functional, but the DOTS server's IPv6 path is nonfunctional, a dual-stack DOTS client may experience a significant connection delay compared to an IPv4-only DOTS client in the same network conditions. The other problem is that if a middlebox between the DOTS client and DOTS server is configured to block UDP traffic, the DOTS client will fail to establish a DTLS association with the DOTS server; consequently, it will have to fall back to TLS over TCP, thereby incurring significant connection delays.
そのような手順は、長い接続遅延を経験することを回避するために必要とされる。たとえば、ドットサーバーへのIPv4パスが機能していますが、ドットサーバーのIPv6パスが機能していない場合、デュアルスタックドットクライアントは、同じネットワーク条件でIPv4のみのドットクライアントと比較して大きな接続遅延を経験できます。その他の問題は、ドットクライアントとドットサーバー間のミドルボックスがUDPトラフィックをブロックするように設定されている場合、ドットクライアントはドットサーバーとのDTLSアソシエーションを確立できません。その結果、TCPを介してTLSに戻る必要があり、それによって重要な接続遅延を発生させる。
To overcome these connection setup problems, the DOTS client attempts to connect to its DOTS server(s) using both IPv6 and IPv4, and it tries both DTLS over UDP and TLS over TCP following a DOTS Happy Eyeballs approach. To some extent, this approach is similar to the Happy Eyeballs mechanism defined in [RFC8305]. The connection attempts are performed by the DOTS client when it initializes or, in general, when it has to select an address family and transport to contact its DOTS server. The results of the Happy Eyeballs procedure are used by the DOTS client for sending its subsequent messages to the DOTS server. The differences in behavior with respect to the Happy Eyeballs mechanism [RFC8305] are listed below:
これらの接続セットアップの問題を克服するために、DOTSクライアントはIPv6とIPv4の両方を使用してそのドットサーバーへの接続を試みます。これは、ドットハッピーアイボールアプローチに従って、TCPを介してUDPとTLSを介してDTLを試みます。ある程度、このアプローチは[RFC8305]で定義されている幸せな眼球機構に似ています。接続試行は、それが初期化されたとき、またはそのドットサーバに連絡するためにアドレスファミリとトランスポートを選択しなければならないときに、ドットクライアントによって実行されます。幸せな眼球の手順の結果は、後続のメッセージをドットサーバーに送信するためにドットクライアントによって使用されます。ハッピーアイボールメカニズム[RFC8305]に関する行動の違いは以下のとおりです。
* The order of preference of the DOTS signal channel address family and transport protocol (most preferred first) is the following: UDP over IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres to the address preference order specified in [RFC6724] and the DOTS signal channel preference that promotes the use of UDP over TCP (to avoid TCP's head of line blocking).
* ドット信号チャネルアドレスファミリおよびトランスポートプロトコル（最も好ましい最初の）の嗜好の順序は以下の通りである：IPv6を介したUDP、IPv6 over IPv6、および最後にIPv4を介したTCP。この順序は、[RFC6724]で指定されたアドレス嗜好順序と、TCPを介したUDPの使用を促進するドットシグナルチャネルの設定（TCPのラインブロックヘッドを回避するため）に準拠しています。
* After successfully establishing a connection, the DOTS client MUST cache information regarding the outcome of each connection attempt for a specific time period; it uses that information to avoid thrashing the network with subsequent attempts. The cached information is flushed when its age exceeds a specific time period on the order of few minutes (e.g., 10 min). Typically, if the DOTS client has to reestablish the connection with the same DOTS server within a few seconds after the Happy Eyeballs mechanism is completed, caching avoids thrashing the network especially in the presence of DDoS attack traffic.
* 接続を正常に確立した後、DOTSクライアントは特定の期間、各接続試行の結果に関する情報をキャッシュしなければなりません (MUST)。後続の試行によってネットワークをスラッシングすることを回避するためにその情報を使用します。キャッシュされた情報は、その経過時間が数分程度（例えば10分）の特定の期間を超えたときにフラッシュされます。通常、Happy Eyeballsメカニズムが完了してから数秒以内にDOTSクライアントが同じDOTSサーバーとの接続を再確立しなければならない場合、キャッシングによって特にDDoS攻撃トラフィックが存在する中でネットワークがスラッシングされるのを回避します。
* If a DOTS signal channel session is established with TLS (but DTLS failed), the DOTS client periodically repeats the mechanism to discover whether DOTS signal channel messages with DTLS over UDP become available from the DOTS server; this is so the DOTS client can migrate the DOTS signal channel from TCP to UDP. Such probing SHOULD NOT be done more frequently than every 24 hours and MUST NOT be done more frequently than every 5 minutes.
* DOTSシグナルチャネルセッションがTLSで確立された場合（ただしDTLSは失敗した場合）、DOTSクライアントは、DOTSサーバーからUDP上のDTLSを使用したDOTSシグナルチャネルメッセージが利用可能になるかどうかを発見するためのメカニズムを定期的に繰り返します。これは、DOTSクライアントがDOTSシグナルチャネルをTCPからUDPに移行できるようにするためです。そのようなプロービングは24時間ごとよりも頻繁に行われるべきではなく (SHOULD NOT)、5分ごとよりも頻繁に行われてはなりません (MUST NOT)。
When connection attempts are made during an attack, the DOTS client SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms.
攻撃中に接続試行が行われる場合、DOTSクライアントは100 msに設定された「Connection Attempt Delay」[RFC8305]を使用すべきです (SHOULD)。
In Figure 4, the DOTS client proceeds with the connection attempts following the rules in [RFC8305]. In this example, it is assumed that the IPv6 path is broken and UDP traffic is dropped by a middlebox, but this has little impact on the DOTS client because there is not a long delay before using IPv4 and TCP.
図4では、DOTSクライアントは[RFC8305]の規則に従って接続試行を進めます。この例では、IPv6パスが破損し、UDPトラフィックがミドルボックスによってドロップされますが、IPv4とTCPを使用する前に長い遅延がないため、DOTSクライアントにはほとんど影響がありません。
+-----------+ +-----------+
|DOTS Client| |DOTS Server|
+-----------+ +-----------+
| |
T0 |--DTLS ClientHello, IPv6 ---->X |
T1 |--DTLS ClientHello, IPv4 ---->X |
T2 |--TCP SYN, IPv6-------------->X |
T3 |--TCP SYN, IPv4------------------------------------->|
|<-TCP SYNACK-----------------------------------------|
|--TCP ACK------------------------------------------->|
|<------------Establish TLS Session------------------>|
|----------------DOTS signal------------------------->|
| |
Note: * Retransmission messages are not shown. * T1-T0=T2-T1=T3-T2= Connection Attempt Delay.
注：*再送メッセージは表示されません。* T1-T0=T2-T1=T3-T2 =接続試行遅延。
Figure 4: DOTS Happy Eyeballs (Sample Flow)
図4：ドットハッピーアイボール（サンプルフロー）
A single DOTS signal channel between DOTS agents can be used to exchange multiple DOTS signal messages. To reduce DOTS client and DOTS server workload, DOTS clients SHOULD reuse the (D)TLS session.
DOTSエージェント間の単一のDOTSシグナルチャネルを使用して、複数のDOTSシグナルメッセージを交換できます。DOTSクライアントおよびDOTSサーバーのワークロードを軽減するために、DOTSクライアントは(D)TLSセッションを再利用すべきです (SHOULD)。
The following methods are used by a DOTS client to request, retrieve, or withdraw the status of mitigation requests:
緩和要求のステータスを要求、取得、または引き出すために、次の方法がドットクライアントによって使用されます。
PUT: DOTS clients use the PUT method to request mitigation from a DOTS server (Section 4.4.1). During active mitigation, DOTS clients may use PUT requests to carry mitigation efficacy updates to the DOTS server (Section 4.4.3).
PUT：ドットクライアントPUTメソッドを使用して、ドットサーバーから軽減を要求します（セクション4.4.1）。能動的な緩和の間、ドットクライアントは、緩和効果の更新をドットサーバーに携帯するためのPUT要求を使用することがあります（4.4.3項）。
GET: DOTS clients may use the GET method to retrieve the list of its mitigations maintained by a DOTS server (Section 4.4.2) or to receive asynchronous DOTS server status messages (Section 4.4.2.1).
GET：ドットクライアントはGETメソッドを使用して、ドットサーバー（4.4.2項）によって維持されたその軽減のリストを取得するか、非同期ドットサーバーのステータスメッセージを受信することができます（セクション4.4.2.1）。
DELETE: DOTS clients use the DELETE method to withdraw a request for mitigation from a DOTS server (Section 4.4.4).
DELETE：ドットクライアントDETELメソッドを使用して、ドットサーバーからの軽減要求を撤回します（セクション4.4.4）。
Mitigation request and response messages are marked as Non-confirmable messages (Section 2.2 of [RFC7252]).
緩和要求と応答メッセージは、確認不能メッセージとしてマークされています（[RFC7252]のセクション2.2）。
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 transmission guidelines discussed in Section 3.1.3 of [RFC8085].
DOTSエージェントは、[RFC8085]のセクション3.1.3で説明されているデータ送信ガイドラインに従い、平均してRTT（Round-Trip Time）あたり複数個のUDPデータグラムをピアDOTSエージェントに送信してはなりません (MUST NOT)。
Requests marked by the DOTS client as Non-confirmable messages are sent at regular intervals until a response is received from the DOTS server. If the DOTS client cannot maintain an RTT estimate, it MUST NOT send more than one Non-confirmable request every 3 seconds and SHOULD use an even less aggressive rate whenever possible (case 2 in Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed because of checks on probing rate (Section 4.7 of [RFC7252]).
JSON encoding of YANG-modeled data [RFC7951] is used to illustrate 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, and 10.6.5.
YangモデルデータのJSONエンコーディング[RFC7951]は、以下のサブセクションで定義されたさまざまな方法を説明するために使用されます。また、セクション10.6.2,10.6.3,10.6.4、および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.
DOTSクライアントはDOTSサーバーに対して自身を認証しなければなりません (MUST)（セクション8）。DOTSサーバーは、[RFC7589]のセクション7に提示されているアルゴリズムを使用して、クライアント証明書からDOTSクライアント識別子またはユーザー名を導出してもよいです (MAY)。DOTSクライアント識別子により、DOTSサーバーは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 DOTS server(s) (Figures 5 and 6).
ドットクライアントが何らかの理由で緩和を必要とするとき、ドットクライアントはCoAP PUTメソッドを使用してそのドットサーバに緩和要求を送信する（図5および6）。
If a DOTS client is entitled to solicit the DOTS service, the DOTS server enables mitigation on behalf of the DOTS client by communicating the DOTS client's request to a mitigator (which may be co-located with the DOTS server) and relaying the feedback of the thus-selected mitigator to the requesting DOTS client.
ドットクライアントがドットサービスを犠牲にする権利がある場合、ドットサーバはドットクライアントの要求を軽減（ドットサーバと同じ場所に配置されている可能性がある）を通信し、そのフィードバックを中継することによってドットクライアントの代わりに軽減を可能にする。このようにして選択されている積み込み具を要求するドットクライアントに。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"
{
...
}
Figure 5: PUT to Convey DOTS Mitigation Requests
図5：ドットの軽減要求を伝えるために置く
The order of the Uri-Path options is important, as it defines the CoAP resource. In particular, 'mid' MUST follow 'cuid'.
Uri-Pathオプションの順序はCoAPリソースを定義するため重要です。特に、'mid'は'cuid'の後に続かなければなりません (MUST)。
The additional Uri-Path parameters to those defined in Section 4.2 are as follows:
セクション4.2で定義されている追加のURIパスパラメータは次のとおりです。
cuid: Stands for Client Unique Identifier. A globally unique identifier that is meant to prevent collisions among DOTS clients, especially those from the same domain. It MUST be generated by DOTS clients.
cuid: Client Unique Identifierを表します。特に同じドメインのDOTSクライアント間での衝突を防ぐことを目的とした、グローバルに一意の識別子です。これはDOTSクライアントによって生成されなければなりません (MUST)。
For the reasons discussed in Appendix B, implementations SHOULD set 'cuid' using the following procedure: first, the DOTS client inputs one of the following into the SHA-256 [RFC6234] cryptographic hash: the DER-encoded ASN.1 representation of the Subject Public Key Info (SPKI) of its X.509 certificate [RFC5280], its raw public key [RFC7250], the "Pre-Shared Key (PSK) identity" it uses in the TLS 1.2 ClientKeyExchange message, or the "identity" it uses in the "pre_shared_key" TLS 1.3 extension. Then, the output of the cryptographic hash algorithm is truncated to 16 bytes; truncation is done by stripping off the final 16 bytes. The truncated output is base64url encoded (Section 5 of [RFC4648]) with the two trailing "=" removed from the encoding, and the resulting value used as the 'cuid'.
付録Bで説明されている理由により、実装は以下の手順を使用して'cuid'を設定すべきです (SHOULD): まず、DOTSクライアントは以下のいずれかをSHA-256 [RFC6234]暗号ハッシュに入力します: そのX.509証明書[RFC5280]のSubject Public Key Info (SPKI) のDERエンコードされたASN.1表現、そのrawパブリックキー[RFC7250]、TLS 1.2 ClientKeyExchangeメッセージで使用する「Pre-Shared Key (PSK) identity」、または「pre_shared_key」TLS 1.3拡張で使用する「identity」。次に、暗号ハッシュアルゴリズムの出力を16バイトに切り詰めます。切り詰めは最後の16バイトを剥ぎ取ることによって行われます。切り詰められた出力はbase64urlエンコードされ（[RFC4648]のセクション5）、エンコーディングから末尾の2つの「=」が削除され、その結果の値が'cuid'として使用されます。
The 'cuid' is intended to be stable when communicating with a given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD NOT change over time. Distinct 'cuid' values MAY be used by a single DOTS client per DOTS server.
'cuid'は、特定のDOTSサーバーと通信する際に安定していることが意図されています。すなわち、DOTSクライアントによって使用される'cuid'は時間の経過とともに変更されるべきではありません (SHOULD NOT)。単一のDOTSクライアントがDOTSサーバーごとに異なる'cuid'値を使用してもよいです (MAY)。
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 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS signal message fragmentation over UDP. Furthermore, if that DOTS client created aliases and filtering entries at the DOTS server by means of the DOTS data channel, it MUST delete all the entries bound to the old 'cuid' and reinstall them using the new 'cuid'.
DOTSクライアントが何らかの理由でその'cuid'を変更しなければならない場合、古い'cuid'に対して緩和が依然としてアクティブであるときに変更してはなりません (MUST NOT)。UDP上でのDOTSシグナルメッセージの断片化を回避するために、'cuid'は22文字であるべきです (SHOULD)。さらに、そのDOTSクライアントがDOTSデータチャネルを介してDOTSサーバーにエイリアスおよびフィルタリングエントリを作成していた場合、古い'cuid'にバインドされているすべてのエントリを削除し、新しい'cuid'を使用してそれらを再インストールしなければなりません (MUST)。
DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer to notify that the 'cuid' is already in use by another DOTS client. Upon receipt of that error code, a new 'cuid' MUST be generated by the DOTS peer (e.g., using [RFC4122]).
DOTSサーバーは、'cuid'がすでに別のDOTSクライアントによって使用されていることを通知するために、4.09 (Conflict) エラーコードをDOTSピアに返さなければなりません (MUST)。そのエラーコードを受信すると、DOTSピアによって新しい'cuid'が生成されなければなりません (MUST)（例えば[RFC4122]を使用）。
Client-domain DOTS gateways MUST handle 'cuid' collision directly, and it is RECOMMENDED that 'cuid' collision is handled directly by server-domain DOTS gateways.
クライアントドメインDOTSゲートウェイは'cuid'の衝突を直接処理しなければならず (MUST)、サーバー側ドメインDOTSゲートウェイによって'cuid'の衝突が直接処理されることが推奨されます (RECOMMENDED)。
DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. Triggers for such rewriting are out of scope.
DOTSゲートウェイは、ピアDOTSクライアントによって使用される'cuid'を書き換えてもよいです (MAY)。そのような書き換えのトリガーは対象外です。
This is a mandatory Uri-Path parameter.
これは必須のURI-PATHパラメータです。
mid: Identifier for the mitigation request represented with an integer. This identifier MUST be unique for each mitigation request bound to the DOTS client, i.e., the 'mid' parameter value in the mitigation request needs to be unique (per 'cuid' and DOTS server) relative to the 'mid' parameter values of active mitigation requests conveyed from the DOTS client to the DOTS server.
mid: 整数で表される緩和要求の識別子。この識別子は、DOTSクライアントにバインドされた各緩和要求に対して一意でなければなりません (MUST)。すなわち、緩和要求における'mid'パラメータ値は、DOTSクライアントからDOTSサーバーへ伝達されたアクティブな緩和要求の'mid'パラメータ値に対して（'cuid'およびDOTSサーバーごとに）一意である必要があります。
In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically.
緩和要求の順不同配信を処理するために、'mid'値は単調に増加しなければなりません (MUST)。
If the 'mid' value has reached 3/4 of (2^(32) - 1) (i.e., 3221225471) and no attack is detected, the DOTS client MUST reset 'mid' to 0 to handle 'mid' rollover. If the DOTS client maintains mitigation requests with preconfigured scopes, it MUST recreate them with the 'mid' restarting at 0.
'mid'値が (2^(32) - 1) の 3/4（すなわち 3221225471）に達し、攻撃が検出されない場合、DOTSクライアントは'mid'のロールオーバーを処理するために'mid'を0にリセットしなければなりません (MUST)。DOTSクライアントが事前設定されたスコープで緩和要求を維持している場合、'mid'を0から再開してそれらを再作成しなければなりません (MUST)。
This identifier MUST be generated by the DOTS client.
この識別子はDOTSクライアントによって生成されなければなりません (MUST)。
This is a mandatory Uri-Path parameter.
これは必須のURI-PATHパラメータです。
'cuid' and 'mid' MUST NOT appear in the PUT request message body (Figure 6). The schema in Figure 6 uses the types defined in Section 6. Note that this figure (and other similar figures depicting a schema) are non-normative sketches of the structure of the message.
'cuid'および'mid'は、PUT要求メッセージ本文に現れてはなりません (MUST NOT)（図6）。図6のスキーマはセクション6で定義されている型を使用しています。この図（およびスキーマを描いた他の同様の図）は、メッセージ構造の非規範的なスケッチであることに注意してください。
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"string"
],
"target-port-range": [
{
"lower-port": number,
"upper-port": number
}
],
"target-protocol": [
number
],
"target-fqdn": [
"string"
],
"target-uri": [
"string"
],
"alias-name": [
"string"
],
"lifetime": number,
"trigger-mitigation": true|false
}
]
}
}
Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body Schema)
図6：ドットの緩和要求を伝えるために置く（メッセージ本文スキーマ）
The parameters in the CBOR body (Figure 6) of the PUT request are described below:
PUTリクエストのCBOR本体（図6）のパラメータを以下に説明します。
target-prefix: A list of prefixes identifying resources under attack. Prefixes are represented using Classless Inter-Domain Routing (CIDR) notation [RFC4632].
target-prefix：攻撃の下でリソースを識別する接頭辞のリスト。プレフィックスは、クラスレス間ドメイン間ルーティング（CIDR）表記[RFC4632]を使用して表されます。
The prefix length must be less than or equal to 32 for IPv4 and 128 for IPv6.
Prefix長はIPv4およびIPv6の場合は32以下でなければなりません。
The prefix list MUST NOT include broadcast, loopback, or multicast addresses. These addresses are considered to be invalid values. In addition, the DOTS server MUST validate that target prefixes are within the scope of the DOTS client domain. Other validation checks may be supported by DOTS servers.
プレフィックスリストにブロードキャスト、ループバック、またはマルチキャストアドレスを含めてはなりません (MUST NOT)。これらのアドレスは無効な値とみなされます。さらに、DOTSサーバーはターゲットプレフィックスがDOTSクライアントドメインのスコープ内にあることを検証しなければなりません (MUST)。他の検証チェックがDOTSサーバーによってサポートされてもよいです。
This is an optional attribute.
これはオプションの属性です。
target-port-range: A list of port numbers bound to resources under attack.
target-port-range：攻撃下のリソースにバインドされているポート番号のリスト。
A port range is defined by two bounds: a lower port number ('lower-port') and an upper port number ('upper-port'). When only 'lower-port' is present, it represents a single port number.
ポート範囲は2つの範囲で定義されています：下位ポート番号（「下位ポート」）と上位ポート番号（「上位ポート」）。「Lower-Port」のみが存在する場合は、単一のポート番号を表します。
This is an optional attribute.
これはオプションの属性です。
target-protocol: A list of protocols involved in an attack. Values are integers in the range of 0 to 255. See [IANA-Proto] for common values.
ターゲットプロトコル：攻撃に関わるプロトコルのリスト。値は0から255の範囲の整数です。一般的な値の[IANA-PROTO]を参照してください。
If 'target-protocol' is not specified, then the request applies to any protocol.
'target-protocol'が指定されていない場合、要求は任意のプロトコルに適用されます。
This is an optional attribute.
これはオプションの属性です。
target-fqdn: A list of Fully Qualified Domain Names (FQDNs) identifying resources under attack [RFC8499].
target-fqdn：攻撃下でのリソースを識別する完全修飾ドメイン名（FQDNS）のリスト[RFC8499]。
How a name is passed to an underlying name resolution library is implementation and deployment specific. Nevertheless, once the name is resolved into one or multiple IP addresses, DOTS servers MUST apply the same validation checks as those for 'target-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).
名前が基盤となる名前解決ライブラリにどのように渡されるかは、実装および配備に依存します。それにもかかわらず、名前が1つまたは複数のIPアドレスに解決されたら、DOTSサーバーは'target-prefix'に対するものと同じ検証チェックを適用しなければなりません (MUST)。これらの検証チェックは、名前が基盤となる名前解決ライブラリに渡されるたびに（例えばDNS TTLの満了時）、DOTSサーバーによって再度実行されます。
The use of FQDNs may be suboptimal because:
FQDNを使用すると、次のように最適なものがあります。
* It induces both an extra load and increased delays on the DOTS server to handle and manage DNS resolution requests.
* DNS解決要求を処理および管理するために、追加の負荷とドットサーバー上の増加の遅延の両方を引き起こします。
* It does not guarantee that the DOTS server will resolve a name to the same IP addresses that the DOTS client does.
* ドットサーバーが、ドットクライアントが実行するのと同じIPアドレスに名前を解決することを保証しません。
This is an optional attribute.
これはオプションの属性です。
target-uri: A list of URIs [RFC3986] identifying resources under attack.
target-uri：攻撃の下でリソースを識別するURIのリスト[RFC3986]。
The same validation checks used for 'target-fqdn' MUST be followed by DOTS servers to validate a target URI.
'target-fqdn'に使用されるのと同じ検証チェックに、ターゲットURIを検証するためにDOTSサーバーが従わなければなりません (MUST)。
This is an optional attribute.
これはオプションの属性です。
alias-name: A list of aliases of resources for which the mitigation is requested. Aliases can be created using the DOTS data channel (Section 6.1 of [RFC8783]), direct configuration, or other means.
alias-name：緩和が要求されているリソースのエイリアスのリスト。エイリアスは、ドットデータチャネル（[RFC8783]のセクション6.1）、直接構成、またはその他の手段を使用して作成できます。
An alias is used in subsequent signal channel exchanges to refer more efficiently to the resources under attack.
エイリアスは、後続の信号チャネル交換に使用され、攻撃下のリソースにより効率的に参照されます。
This is an optional attribute.
これはオプションの属性です。
lifetime: Lifetime of the mitigation request in seconds. The RECOMMENDED lifetime of a mitigation request is 3600 seconds; this value was chosen to be long enough so that refreshing is not typically a burden on the DOTS client while still making the request expire in a timely manner when the client has unexpectedly quit. DOTS clients MUST include this parameter in their mitigation requests.
lifetime: 秒単位での緩和要求の有効期間。緩和要求の推奨される有効期間は3600秒です (RECOMMENDED)。この値は、リフレッシュが通常DOTSクライアントの負担にならない程度に十分に長く、かつクライアントが予期せず終了したときにも適時に要求が期限切れになるように選択されました。DOTSクライアントは緩和要求にこのパラメータを含めなければなりません (MUST)。
A lifetime of '0' in a mitigation request is an invalid value.
緩和要求の「0」の寿命は無効な値です。
A lifetime of negative one (-1) indicates indefinite lifetime for the mitigation request. The DOTS server MAY refuse an indefinite lifetime, for policy reasons; the granted lifetime value is returned in the response. DOTS clients MUST be prepared to not be granted mitigations with indefinite lifetimes.
-1（マイナス1）の有効期間は、緩和要求に対する無期限の有効期間を示します。DOTSサーバーはポリシー上の理由から無期限の有効期間を拒否してもよく (MAY)、許可された有効期間の値が応答で返されます。DOTSクライアントは、無期限の有効期間を持つ緩和が許可されないことに備えておかなければなりません (MUST)。
The DOTS server MUST always indicate the actual lifetime in the response and the remaining lifetime in status messages sent to the DOTS client.
DOTSサーバーは、常に応答で実際の有効期間を示し、DOTSクライアントに送信されるステータスメッセージで残りの有効期間を示さなければなりません (MUST)。
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.
交渉された寿命の有効期限（すなわち、残りの寿命が「0」に達する）、そして要求がドットクライアントによって更新されない場合、緩和要求はドットサーバによって削除される。同じ要求を再度送信することでリクエストを更新できます。
This is a mandatory attribute.
これは必須の属性です。
trigger-mitigation: If the parameter value is set to 'false', DDoS mitigation will not be triggered for the mitigation request unless the DOTS signal channel session is lost.
トリガ緩和：パラメータ値が 'false'に設定されている場合、DOTS信号チャネルセッションが失われない限り、DDoSの軽減は緩和要求に対してトリガされません。
If the DOTS client ceases to respond to heartbeat messages, the DOTS server can detect that the DOTS signal channel session is lost. More details are discussed in Section 4.7.
ドットクライアントがハートビートメッセージに応答しなくなると、ドットサーバはドット信号チャネルセッションが失われていることを検出することができる。詳細については4.7項で説明します。
The default value of the parameter is 'true' (that is, the mitigation starts immediately). If 'trigger-mitigation' is not present in a request, this is equivalent to receiving a request with 'trigger-mitigation' set to 'true'.
パラメータのデフォルト値は 'true'です（つまり、軽減はすぐに始まります）。リクエストに「トリガー軽減」が存在しない場合、これは 'trigger-itigation'を 'true'に設定して要求を受信することと同じです。
This is an optional attribute.
これはオプションの属性です。
Because of the complexity of handling partial failure cases, this specification does not allow the inclusion of multiple mitigation requests in the same PUT request. Concretely, a DOTS client MUST NOT include multiple entries in the 'scope' array of the same PUT request.
部分的な障害ケースを処理することの複雑さのため、本仕様は同じPUT要求に複数の緩和要求を含めることを許可しません。具体的には、DOTSクライアントは同じPUT要求の'scope'配列に複数のエントリを含めてはなりません (MUST NOT)。
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 (as resolved by the DOTS server) represent the scope of the mitigation. Particularly, the IP addresses to which the host subcomponent of authority component of a URI resolves represent the 'target-prefix', the URI scheme represents the 'target-protocol', and the port subcomponent of authority component of a URI represents the 'target-port-range'. If the optional port information is not present in the authority component, the default port defined for the URI scheme represents the 'target-port'.
FQDNおよびURIの緩和スコープは、ドメイン名またはURIに関連付けられているアドレス（ドットサーバによって解決された）が緩和の範囲を表すスコープエイリアスの形式として考えることができます。特に、URI解決の権限コンポーネントのホストサブコンポーネントが 'target-prefix'を表すIPアドレスは 'target-prefix'を表し、URIスキームは 'target-protocol'を表し、URIの権限コンポーネントのportサブコンポーネントは 'ターゲットを表す-port-range '。オプションのポート情報が権限コンポーネントに存在しない場合、URIスキームに定義されているデフォルトのポートは 'target-port'を表します。
In the PUT request, at least one of the attributes 'target-prefix', 'target-fqdn','target-uri', or 'alias-name' MUST be present.
PUT要求では、属性'target-prefix'、'target-fqdn'、'target-uri'、または'alias-name'の少なくとも1つが存在しなければなりません (MUST)。
Attributes and Uri-Path parameters with empty values MUST NOT be present in a request, as an empty value will render the entire request invalid.
空の値を持つ属性およびUri-Pathパラメータは要求内に存在してはなりません (MUST NOT)。空の値は要求全体を無効にするためです。
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 TCP port numbers 80, 8080, and 443. The presence of 'cdid' indicates that a server-domain DOTS gateway has modified the initial PUT request sent by the DOTS client. Note that 'cdid' MUST NOT appear in the PUT request message body.
図7は、サーバー2001:db8:6401::1および2001:db8:6401::2がTCPポート番号80、8080、および443で攻撃トラフィックを受信していることを通知するPUT要求の例を示しています。'cdid'の存在は、サーバー側ドメインDOTSゲートウェイがDOTSクライアントによって送信された初期PUT要求を変更したことを示します。'cdid'はPUT要求メッセージ本文に現れてはならない (MUST NOT) ことに注意してください。
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"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"target-port-range": [
{
"lower-port": 80
},
{
"lower-port": 443
},
{
"lower-port": 8080
}
],
"target-protocol": [
6
],
"lifetime": 3600
}
]
}
}
Figure 7: PUT for DOTS Mitigation Request (An Example)
図7：ドットの軽減要求のために置く（例）
The corresponding CBOR encoding format for the payload is shown in Figure 8.
ペイロードの対応するCBOR符号化フォーマットを図8に示す。
A1 # map(1)
01 # unsigned(1)
A1 # map(1)
02 # unsigned(2)
81 # array(1)
A4 # map(4)
06 # unsigned(6)
82 # array(2)
74 # text(20)
323030313A6462383A363430313A3A312F313238
74 # text(20)
323030313A6462383A363430313A3A322F313238
07 # unsigned(7)
83 # array(3)
A1 # map(1)
08 # unsigned(8)
18 50 # unsigned(80)
A1 # map(1)
08 # unsigned(8)
19 01BB # unsigned(443)
A1 # map(1)
08 # unsigned(8)
19 1F90 # unsigned(8080)
0A # unsigned(10)
81 # array(1)
06 # unsigned(6)
0E # unsigned(14)
19 0E10 # unsigned(3600)
Figure 8: PUT for DOTS Mitigation Request (CBOR)
図8：ドット軽減要求（CBOR）
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.
サーバー側ドメインDOTSゲートウェイが有効になっている配備では、発信元クライアントドメインに関する識別情報（'cdid'）がDOTSサーバーに伝播されるべきです (SHOULD)。その情報は、同じDOTSドメインに属するDOTSクライアントのグループ化、DOTS要求の数の制限、緩和スコープの特定など、DOTSサーバーが一部のポリシーを強制するのを支援することを目的としています。これらのポリシーは、クライアントごと、クライアントドメインごと、またはその両方に強制できます。また、識別情報は監査およびデバッグの目的で使用されてもよいです。
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
図9：ドットゲートウェイによって中継されているドットの軽減要求のために置く
A server-domain DOTS gateway SHOULD add the following Uri-Path parameter:
サーバー側ドメインDOTSゲートウェイは、以下のUri-Pathパラメータを追加すべきです (SHOULD) :
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.
CDID：クライアントドメイン識別子を表します。「CDID」は、サーバドメインドットゲートウェイによって伝送され、ゲートウェイのクライアント側の側面からゲートウェイのサーバ対向側、およびゲートウェイのサーバ面側からドットサーバへの送信元ドメインIDが伝播される。「CDID」は、ポリシー執行目的のために最終的なドットサーバによって使用され得る（例えば、フィルタリング規則に関するクォータを適用する）。これらのポリシーは展開固有です。
Server-domain DOTS gateways SHOULD support a configuration option to instruct whether the 'cdid' parameter is to be inserted.
サーバー側ドメインDOTSゲートウェイは、'cdid'パラメータを挿入するかどうかを指示する設定オプションをサポートすべきです (SHOULD)。
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.
クライアントごとのポリシー、クライアントドメインごとのポリシー、またはそれらの組み合わせの強制を要求する配備に対応するために、'cdid'パラメータを挿入するよう指示されたサーバー側ドメインDOTSゲートウェイは、DOTSクライアントX.509証明書のSPKIハッシュ、DOTSクライアントのrawパブリックキー、または「PSK identity」のハッシュを'cdid'で提供しなければならず (MUST)、'cuid'で伝達されるハッシュを生成するための同じ規則に従い、これは最終的なDOTSサーバーによって対応するクライアントのドメインを決定するために使用されます。サーバー側ドメインゲートウェイによって生成された'cdid'は、DOTSメッセージがクライアントドメインDOTSゲートウェイによって中継された場合や、不正なDOTSクライアントによって'cuid'が生成された場合を除き、'cuid'と同じになる可能性が高いです。
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.
例えば、DOTSクライアントが同じDOTSサーバーにピア接続する別々のサーバー側ドメインDOTSゲートウェイとピア接続するために使用する個別の証明書でプロビジョニングされている場合、サーバー側ドメインDOTSゲートウェイによってサーバーに個別の'cdid'値が提供される場合があります。最終的なDOTSサーバーは、それらの'cdid'値を同等として扱わなければなりません (MUST)。
The 'cdid' attribute MUST NOT be generated and included by DOTS clients.
'cdid'属性は、DOTSクライアントによって生成および含められてはなりません (MUST NOT)。
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.
DOTSサーバーは、送信元DOTSクライアントまたはクライアントドメインDOTSゲートウェイによって直接提供された'cdid'属性を無視しなければなりません (MUST)。これは、最初のサーバー側ドメインDOTSゲートウェイがDOTSクライアントによって提供された'cdid'属性を除去しなければならない (MUST) ことを意味します。DOTSサーバーは、'cdid'属性を提供することが信頼されているDOTSゲートウェイを識別するための設定パラメータをサポートすべきです (SHOULD)。
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.
この文書では、単数値の「CDID」のみが定義されています。つまり、最初のオンパスサーバードメインドットゲートウェイのみが「CDID」の値を挿入できます。この仕様は、パスに含まれるときはいつでも、複数のサーバードメインドットゲートウェイを使用して、サーバードメインゲートウェイごとに「CDID」値を挿入します。
This is an optional Uri-Path. When present, 'cdid' MUST be positioned before 'cuid'.
これはオプションのUri-Pathです。存在する場合、'cdid'は'cuid'の前に配置されなければなりません (MUST)。
A DOTS gateway SHOULD add the CoAP Hop-Limit Option [RFC8768].
DOTSゲートウェイはCoAP Hop-Limitオプション[RFC8768]を追加すべきです (SHOULD)。
The DOTS server couples the DOTS signal and data channel sessions using the DOTS client identity and optionally the 'cdid' parameter value, so the DOTS server can validate whether the aliases conveyed in the mitigation request were indeed created by the same DOTS client 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 the response.
DOTSサーバーは、DOTSクライアント識別子とオプションの'cdid'パラメータ値を使用してDOTSシグナルチャネルおよびデータチャネルセッションを結合するため、DOTSサーバーは、緩和要求で伝達されたエイリアスが実際にDOTSデータチャネルセッションを使用して同じDOTSクライアントによって作成されたかどうかを検証できます。エイリアスがそのDOTSクライアントによって作成されていなかった場合、DOTSサーバーは応答で4.00 (Bad Request) を返さなければなりません (MUST)。
The DOTS server couples the DOTS signal channel sessions using the DOTS client identity and optionally the 'cdid' parameter value, and the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to detect duplicate mitigation requests. If the mitigation request contains the 'alias-name' and other parameters identifying the target resources (such as 'target-prefix', 'target-port-range', 'target-fqdn', or 'target-uri'), the DOTS server appends the parameter values associated with the 'alias-name' with the corresponding parameter values in 'target-prefix', 'target-port-range', 'target-fqdn', or 'target-uri'.
ドットサーバは、ドットクライアントアイデンティティとオプションで 'CDID'パラメータ値を使用してドット信号チャネルセッションを結合し、ドットサーバは「MID」および「CUID」URIパスパラメータ値を使用して重複緩和要求を検出する。緩和要求に「alias-name」およびその他のパラメータが含まれている場合（ 'target-prefix'、 'target-port-range'、 'target-fqdn'、 'target-uri'など）、Dots Serverは、 'target-prefix'、 'target-port-range'、 'target-fqdn'、または 'target-uri'の対応するパラメータ値との 'alias-name'に関連付けられているパラメータ値を追加します。
The DOTS server indicates the result of processing the PUT request 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 returned if the DOTS server is in an error state or is currently unavailable to provide mitigation in response to the mitigation request from the DOTS client.
ドットサーバは、CoAP応答コードを用いてPUT要求を処理した結果を示す。COAAS 2.xxコードは成功です。COAAP 4.xxコードは、ある種の無効な要求（クライアントエラー）です。COAAS 5.xxコードは、ドットサーバーがエラー状態にある場合、またはドットクライアントからの緩和要求に応答して軽減を提供するために現在使用できない場合に返されます。
Figure 10 shows an example response to a PUT request that is successfully processed by a DOTS server (i.e., CoAP 2.xx Response Codes). This version of the specification forbids 'cuid' and 'cdid' (if used) to be returned in a response message body.
図10は、ドットサーバ（すなわち、COAAS 2.xx応答コード）によって正常に処理されるPUT要求に対する応答例を示す。このバージョンの仕様書は、応答メッセージ本文で返される「CUID」および「CDID」（使用されている場合）を禁止する。
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 123,
"lifetime": 3600
}
]
}
}
Figure 10: 2.xx Response Body
図10：2.xx応答本体
If the request is missing a mandatory attribute, does not include 'cuid' or 'mid' Uri-Path options, includes multiple 'scope' parameters, or contains invalid or unknown parameters, the DOTS server MUST reply with 4.00 (Bad Request). DOTS agents can safely ignore comprehension-optional parameters they don't understand (Section 10.6.1.1).
要求に必須属性が欠落している場合、'cuid'または'mid'のUri-Pathオプションが含まれていない場合、複数の'scope'パラメータが含まれている場合、あるいは無効または不明なパラメータが含まれている場合、DOTSサーバーは4.00 (Bad Request) で応答しなければなりません (MUST)。DOTSエージェントは、理解できないcomprehension-optionalパラメータを安全に無視できます（セクション10.6.1.1）。
A DOTS server that receives a mitigation request with a 'lifetime' set to '0' MUST reply with a 4.00 (Bad Request).
'lifetime'が'0'に設定された緩和要求を受信したDOTSサーバーは、4.00 (Bad Request) で応答しなければなりません (MUST)。
If the DOTS server does not find the 'mid' parameter value conveyed in the PUT request in its configuration data, it MAY accept the mitigation request by sending back a 2.01 (Created) response to the DOTS client; the DOTS server will consequently try to mitigate the attack. A DOTS server MAY reject mitigation requests when it is near capacity or needs to rate-limit a particular client, for example.
DOTSサーバーは、PUT要求で伝達された'mid'パラメータ値がその設定データ内に見つからない場合、DOTSクライアントに2.01 (Created) 応答を送り返すことによって緩和要求を受け入れてもよく (MAY)、その結果、DOTSサーバーは攻撃の緩和を試みます。DOTSサーバーは、例えばキャパシティに近い場合や特定のクライアントをレート制限する必要がある場合に、緩和要求を拒否してもよいです (MAY)。
The relative order of two mitigation requests with the same 'trigger-mitigation' type from a DOTS client is determined by comparing their respective 'mid' values. If two mitigation requests with the same 'trigger-mitigation' type have overlapping mitigation scopes, the mitigation request with the highest numeric 'mid' value will override the other mitigation request. Two mitigation requests from a DOTS client have overlapping scopes if there is a common IP address, IP prefix, FQDN, URI, or alias. To avoid maintaining a long list of overlapping mitigation requests (i.e., requests with the same 'trigger-mitigation' type and overlapping scopes) from a DOTS client and to avoid error-prone provisioning of mitigation requests from a DOTS client, the overlapped lower numeric 'mid' MUST be automatically deleted and no longer available at the DOTS server. For example, if the DOTS server receives a mitigation request that overlaps with an existing mitigation with a higher numeric 'mid', the DOTS server rejects the request by returning 4.09 (Conflict) to the DOTS client. The response MUST include enough information for a DOTS client to recognize the source of the conflict, as described below in the 'conflict-information' subtree (Section 5.1), with only the relevant nodes listed:
DOTSクライアントからの同じ'trigger-mitigation'タイプを持つ2つの緩和要求の相対的な順序は、それぞれの'mid'値を比較することによって決定されます。同じ'trigger-mitigation'タイプを持つ2つの緩和要求の緩和スコープが重複している場合、最も高い数値の'mid'値を持つ緩和要求がもう一方の緩和要求を上書きします。共通のIPアドレス、IPプレフィックス、FQDN、URI、またはエイリアスがある場合、DOTSクライアントからの2つの緩和要求は重複するスコープを持ちます。DOTSクライアントからの重複する緩和要求（すなわち、同じ'trigger-mitigation'タイプと重複するスコープを持つ要求）の長いリストを維持することを回避し、DOTSクライアントからの緩和要求のエラーを起こしやすいプロビジョニングを回避するために、重複したより小さな数値の'mid'は自動的に削除されなければならず (MUST)、DOTSサーバーで利用できなくなります。例えば、DOTSサーバーが、より大きな数値の'mid'を持つ既存の緩和と重複する緩和要求を受信した場合、DOTSサーバーはDOTSクライアントに4.09 (Conflict) を返すことによってその要求を拒否します。応答には、以下で説明する'conflict-information'サブツリー（セクション5.1）のように、DOTSクライアントが競合の原因を認識するのに十分な情報が含まれなければならず (MUST)、関連するノードのみがリストされます:
conflict-information: Indicates that a mitigation request is conflicting with another mitigation request. This attribute has the following structure:
競合 - 情報：緩和要求が別の緩和要求と矛盾していることを示します。この属性には次のような構造があります。
conflict-cause: Indicates the cause of the conflict. The following value MUST be returned:
conflict-cause: 競合の原因を示します。以下の値が返されなければなりません (MUST) :
1: Overlapping targets. 'conflict-scope' provides more details about the conflicting target clauses.
1：重なり合うターゲット。'conflict-scope'は、競合するターゲット句の詳細を提供します。
conflict-scope: Characterizes the exact conflict scope. It may include a list of IP addresses, a list of prefixes, a list of target protocols, a list of FQDNs, a list of URIs, a list of 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.
競合スコープ：正確な競合スコープを特徴付けます。IPアドレスのリスト、プレフィックスのリスト、ターゲットプロトコルのリスト、FQDNのリスト、URIのリスト、エイリアスのリスト、または「MID」を含めることがあります。共通のIPアドレス、IPプレフィックス、FQDN、URI、またはエイリアスがある場合は、ポート番号のリストも含まれている可能性があります。
If the DOTS server receives a mitigation request that overlaps with an active mitigation request, but both have distinct 'trigger-mitigation' types, the DOTS server SHOULD deactivate (absent explicit policy/configuration otherwise) the mitigation request with 'trigger-mitigation' set to 'false'. Particularly, if the mitigation request with 'trigger-mitigation' set to 'false' is active, the DOTS server withdraws the mitigation request (i.e., status code is set to '7' as defined in Table 3) and transitions the status of the mitigation request to '8'.
DOTSサーバーがアクティブな緩和要求と重複する緩和要求を受信したが、両者が異なる'trigger-mitigation'タイプを持つ場合、DOTSサーバーは（別段の明示的なポリシー/設定がない限り）'trigger-mitigation'が'false'に設定された緩和要求を非アクティブ化すべきです (SHOULD)。特に、'trigger-mitigation'が'false'に設定された緩和要求がアクティブであり、重複するスコープを持つ'trigger-mitigation'が'true'に設定された新しい緩和要求を受信した場合、DOTSサーバーは事前設定された緩和要求を自動的に非アクティブ化し、新しい緩和要求を通常どおり処理すべきです (SHOULD)。新しくアクティブ化された緩和要求が終了したとき、DOTSサーバーは重複する事前設定された緩和要求を自動的に再アクティブ化しなければなりません (MUST)。DOTSサーバーが事前設定された緩和要求を自動的に非アクティブ化するとき、DOTSサーバーはピアDOTSクライアントに非アクティブ化を通知する非同期通知を送信します（セクション4.4.2.2を参照）。
Upon DOTS signal channel session loss with a peer DOTS client, the DOTS server SHOULD withdraw (absent explicit policy/configuration otherwise) any active mitigation requests that overlap with mitigation requests having 'trigger-mitigation' set to 'false' from that DOTS client, as the loss of the session implicitly activates these preconfigured mitigation requests, and they take precedence. Note that the active-but-terminating period is not observed for mitigations withdrawn at the initiative of the DOTS server.
ピアDOTSクライアントとのDOTSシグナルチャネルセッションが失われた場合、DOTSサーバーは（別段の明示的なポリシー/設定がない限り）、そのDOTSクライアントからの'trigger-mitigation'が'false'に設定された緩和要求と重複するアクティブな緩和要求を取り下げるべきです (SHOULD)。セッションの喪失によってこれらの事前設定された緩和要求が暗黙的にアクティブ化され、それらが優先されるためです。DOTSサーバーの主導で取り下げられた緩和については、active-but-terminating期間は適用されないことに注意してください。
DOTS clients may adopt various strategies for setting the scopes of immediate and preconfigured mitigation requests to avoid potential conflicts. For example, a DOTS client may tweak preconfigured scopes so that the scope of any overlapping immediate mitigation request will be a subset of the preconfigured scopes. Also, if an immediate mitigation request overlaps with any of the preconfigured scopes, the DOTS client sets the scope of the overlapping immediate mitigation request to be a subset of the preconfigured scopes, so as to get a broad mitigation when the DOTS signal channel collapses and to maximize the chance of recovery.
ドットクライアントは、潜在的な競合を回避するために即時および事前設定された緩和要求の範囲を設定するための様々な戦略を採用することができる。例えば、ドットクライアントは、重複する即時緩和要求の範囲が事前設定されたスコープのサブセットになるように、事前設定されたスコープを調整することができる。また、即時の緩和要求が事前設定されたスコープのいずれかと重なる場合、ドットクライアントは重複する即時緩和要求の範囲を事前設定されたスコープのサブセットになるように設定し、ドット信号チャネルが崩壊するときに幅広い緩和を得る。回復の可能性を最大化するため。
If the request conflicts with an existing mitigation request from a different DOTS client, the DOTS server may return 2.01 (Created) or 4.09 (Conflict) to the requesting DOTS client. If 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 server decides to reject the new mitigation request, the DOTS server returns 4.09 (Conflict) to the requesting DOTS client. For both 2.01 (Created) and 4.09 (Conflict) responses, the response MUST include enough information for a DOTS client to recognize the source of the conflict as described below:
要求が異なるDOTSクライアントからの既存の緩和要求と競合する場合、DOTSサーバーは要求側DOTSクライアントに2.01 (Created) または4.09 (Conflict) を返すことがあります。DOTSサーバーが新しい緩和要求を維持することを決定した場合、DOTSサーバーは要求側DOTSクライアントに2.01 (Created) を返します。DOTSサーバーが新しい緩和要求を拒否することを決定した場合、DOTSサーバーは要求側DOTSクライアントに4.09 (Conflict) を返します。2.01 (Created) と4.09 (Conflict) の両方の応答について、以下で説明するように、応答にはDOTSクライアントが競合の原因を認識するのに十分な情報が含まれなければなりません (MUST) :
conflict-information: Indicates that a mitigation request is conflicting with another mitigation request(s) from other DOTS client(s). This attribute has the following structure:
競合 - 情報：緩和要求が他のドットクライアントからの別の緩和要求と矛盾することを示します。この属性には次のような構造があります。
conflict-status: Indicates the status of a conflicting mitigation request. The following values are defined:
競合 - ステータス：競合する緩和要求のステータスを示します。以下の値が定義されています。
1: DOTS server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.
1：ドットサーバーは、異なるドットクライアントから競合する緩和要求を検出しました。この緩和要求は、競合が解決されるまで現在非アクティブです。別の緩和要求はアクティブです。
2: DOTS server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently active.
2：ドットサーバは、異なるドットクライアントから矛盾する緩和要求を検出しました。この緩和要求は現在アクティブです。
3: DOTS server has detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are inactive.
3：ドットサーバーは、さまざまなドットクライアントから矛盾する緩和要求を検出しました。矛盾するすべての緩和要求は非アクティブです。
conflict-cause: Indicates the cause of the conflict. The following values are defined:
競合 - 原因：競合の原因を示します。以下の値が定義されています。
1: Overlapping targets. 'conflict-scope' provides more details about the conflicting target clauses.
1：重なり合うターゲット。'conflict-scope'は、競合するターゲット句の詳細を提供します。
2: Conflicts with an existing accept-list. This code is returned when the DDoS mitigation detects source addresses/prefixes in the accept-listed Access Control Lists (ACLs) are attacking the target.
2：既存のaccept-listと競合します。このコードは、DDoSの軽減がターゲットを攻撃しているAccept-Listed Access Controlリスト内の送信元アドレス/プレフィックスを検出したときに返されます。
3: CUID Collision. This code is returned when a DOTS client uses a 'cuid' that is already used by another DOTS client. This code is an indication that the request has been rejected and a new request with a new 'cuid' is to be re-sent by the DOTS client (see the example shown in Figure 11). Note that 'conflict-status', 'conflict-scope', and 'retry-timer' MUST NOT be returned in the error response.
3: CUID Collision。このコードは、DOTSクライアントが別のDOTSクライアントによってすでに使用されている'cuid'を使用した場合に返されます。このコードは、要求が拒否され、DOTSクライアントによって新しい'cuid'を持つ新しい要求が再送されるべきであることを示します（図11に示す例を参照）。エラー応答において'conflict-status'、'conflict-scope'、および'retry-timer'が返されてはならない (MUST NOT) ことに注意してください。
conflict-scope: Characterizes the exact conflict scope. It may include a list of IP addresses, a list of prefixes, a list of target protocols, a list of FQDNs, a list of URIs, a list of aliases, or references to conflicting ACLs (by an 'acl-name', typically [RFC8783]). A list of port numbers may also be included if there is a common IP address, IP prefix, FQDN, URI, or alias.
競合スコープ：正確な競合スコープを特徴付けます。IPアドレスのリスト、プレフィックスのリスト、ターゲットプロトコルのリスト、FQDNのリスト、URIのリスト、エイリアスのリスト、または競合するACLへの参照（通常は 'ACL-name'による）を含めることがあります。[RFC8783]）。共通のIPアドレス、IPプレフィックス、FQDN、URI、またはエイリアスがある場合は、ポート番号のリストも含まれている可能性があります。
retry-timer: Indicates, in seconds, the time after which the DOTS client may reissue the same request. The DOTS server returns 'retry-timer' only to DOTS client(s) for which a mitigation request is deactivated. Any retransmission of the same mitigation request before the expiry of this timer is likely to be rejected by the DOTS server for the same reasons.
Retry-Timer：DOTSクライアントが同じ要求を再発行する可能性がある時間を秒単位で示します。DOTSサーバーは、軽減要求が無効になっているドットクライアントにのみ「再試行タイマー」を返します。このタイマーの有効期限が切れる前の同じ緩和要求の再送は、同じ理由でドットサーバーによって拒否される可能性があります。
The 'retry-timer' SHOULD be equal to the lifetime of the active mitigation request resulting in the deactivation of the conflicting mitigation request.
'retry-timer'は、競合する緩和要求の非アクティブ化をもたらしたアクティブな緩和要求の有効期間と等しいべきです (SHOULD)。
If the DOTS server decides to maintain a state for the deactivated mitigation request, the DOTS server updates the lifetime of the deactivated mitigation request to 'retry-timer + 45 seconds' (that is, this mitigation request remains deactivated for the entire duration of 'retry-timer + 45 seconds') so that the DOTS client can refresh the deactivated mitigation request after 'retry-timer' seconds, but before the expiry of the lifetime, and check if the conflict is resolved.
DOTSサーバーが無効化された緩和要求の状態を維持することを決定した場合、DOTSサーバーは無効化された緩和要求の有効期間を「再試行タイマ45秒」に更新します（つまり、この緩和要求は、リトライの全期間の間無効になっています。-timer 45秒 '）「Retry-Timer」秒後に、有効期間の有効期限が切れる前に無効化された軽減要求を更新し、競合が解決されているかどうかを確認することができます。
(1) Request with a conflicting 'cuid'
(1) 矛盾する「CUID」を要求する
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12"
(2) Message body of the 4.09 (Conflict) response from the DOTS server
(2) ドットサーバーからの4.09（競合）応答のメッセージ本文
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"conflict-information": {
"conflict-cause": "cuid-collision"
}
}
]
}
}
(3) Request with a new 'cuid'
(3) 新しい「CUID」を要求する
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
Uri-Path: "mid=12"
Figure 11: Example of Generating a New 'cuid'
図11：新しい「CUID」を生成する例
As an active attack evolves, DOTS clients can adjust the scope of requested mitigation as necessary, by refining the scope of resources requiring mitigation. This can be achieved by sending a PUT request with a new 'mid' value that will override the existing one with overlapping mitigation scopes.
能動的な攻撃が進化するにつれて、ドットクライアントは必要に応じて要求された緩和の範囲を調整することができ、緩和を必要とするリソースの範囲を精製することによって。これは、重複する緩和スコープを持つ既存のものを上書きする新しい「MID」値でPUTリクエストを送信することによって達成できます。
For a mitigation request to continue beyond the initial negotiated lifetime, the DOTS client has to refresh the current mitigation 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 in the original mitigation request apart from a possible change to the 'lifetime' parameter value. In such a case, the DOTS server MAY 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. If this is not the case, the DOTS server MUST reject the request with a 4.00 (Bad Request).
緩和要求を最初に交渉された有効期間を超えて継続させるために、DOTSクライアントは新しいPUT要求を送信して現在の緩和要求をリフレッシュしなければなりません。このPUT要求は同じ'mid'値を使用しなければならず (MUST)、'lifetime'パラメータ値の変更の可能性を除き、元の緩和要求で送信された他のすべてのパラメータを繰り返さなければなりません (MUST)。そのような場合、DOTSサーバーは残りの有効期間を新しく交渉された有効期間に設定することによって緩和要求を更新してもよく (MAY)、緩和要求の更新成功を示す2.04 (Changed) 応答が返されます。そうでない場合、DOTSサーバーは4.00 (Bad Request) で要求を拒否しなければなりません (MUST)。
A GET request is used by a DOTS client to retrieve information (including status) of DOTS mitigations from a DOTS server.
ドット・リクエストは、ドット・クライアントがドット・サーバーからのドット軽減の情報（ステータスを含む）を取得するために使用されます。
'cuid' is a mandatory Uri-Path parameter for GET requests.
'cuid'はrequestsの要求のための必須のURI-Pathパラメータです。
Uri-Path parameters with empty values MUST NOT be present in a request.
空の値を持つUri-Pathパラメータは要求内に存在してはなりません (MUST NOT)。
The same considerations for manipulating the 'cdid' parameter by server-domain DOTS gateways specified in Section 4.4.1 MUST be followed for GET requests.
セクション4.4.1で指定されているサーバー側ドメインDOTSゲートウェイによる'cdid'パラメータの操作に関する同じ考慮事項に、GET要求でも従わなければなりません (MUST)。
The 'c' Uri-Query option is used to control selection of configuration and non-configuration data nodes. Concretely, the 'c' (content) parameter and its permitted values defined in Table 2 of [CORE-COMI] can be used to retrieve non-configuration data (attack mitigation status), configuration data, or both. The DOTS server MAY support this optional filtering capability. It can safely ignore it if not supported. If the DOTS client supports the optional filtering capability, it SHOULD use "c=n" query (to get back only the dynamically changing data) or "c=c" query (to get back the static configuration values) when the DDoS attack is active to limit the size of the response.
'c' Uri-Queryオプションは、設定データノードと非設定データノードの選択を制御するために使用されます。具体的には、[CORE-COMI]の表2で定義されている'c'（コンテンツ）パラメータおよびその許可された値を使用して、非設定データ（攻撃緩和ステータス）、設定データ、またはその両方を取得できます。DOTSサーバーはこのオプションのフィルタリング機能をサポートしてもよいです (MAY)。サポートされていない場合は安全に無視できます。DOTSクライアントがオプションのフィルタリング機能をサポートしている場合、応答のサイズを制限するためにDDoS攻撃がアクティブであるときには「c=n」クエリ（動的に変化するデータのみを返す）または「c=c」クエリ（静的な設定値を返す）を使用すべきです (SHOULD)。
+=======+=====================================================+
| Value | Description |
+=======+=====================================================+
| c | Return only configuration descendant data nodes |
+-------+-----------------------------------------------------+
| n | Return only non-configuration descendant data nodes |
+-------+-----------------------------------------------------+
| a | Return all descendant data nodes |
+-------+-----------------------------------------------------+
Table 2: Permitted Values of the 'c' Parameter
表2： 'c'パラメータの許容値
The DOTS client can use block-wise transfer [RFC7959] to get the list of all its mitigations maintained by a DOTS server; it can send a Block2 Option in a GET request with NUM = 0 to aid in limiting the size of the response. If the representation of all the active mitigation requests associated with the DOTS client does not fit within a single datagram, the DOTS server MUST use the Block2 Option with NUM = 0 in the GET response. The Size2 Option may be conveyed in the response to indicate the total size of the resource representation. The DOTS client retrieves the rest of the representation by sending additional GET requests with Block2 Options containing NUM values greater than zero. The DOTS client MUST adhere to the block size preferences indicated by the DOTS server in the response. If the DOTS server uses the Block2 Option in the GET response, and the response is for a dynamically changing resource (e.g., "c=n" or "c=a" query), the DOTS server MUST include the ETag Option in the response. The DOTS client MUST include the same ETag value in subsequent GET requests to retrieve the rest of the representation.
DOTSクライアントは、DOTSサーバーによって維持されているすべての緩和のリストを取得するためにブロックワイズ転送[RFC7959]を使用できます。応答のサイズを制限するのに役立つよう、num=0を指定したGET要求でBlock2オプションを送信できます。DOTSクライアントに関連付けられたすべてのアクティブな緩和要求の表現が単一のデータグラム内に収まらない場合、DOTSサーバーはGET応答においてnum=0のBlock2オプションを使用しなければならず (MUST)、リソース表現の合計サイズを示すためにSize2オプションが応答で伝達されます。DOTSクライアントは、0より大きいNUM値を含むBlock2オプションを持つ追加のGET要求を送信することによって、表現の残りの部分を取得します。DOTSクライアントは、応答においてDOTSサーバーによって示されたブロックサイズの好みに従わなければなりません (MUST)。DOTSサーバーがGET応答でBlock2オプションを使用しており、かつその応答が動的に変化するリソースに対するものである場合（例えば「c=n」または「c=a」クエリ）、DOTSサーバーは応答にETagオプションを含めなければなりません (MUST)。DOTSクライアントは、残りの表現を取得するための後続のGET要求に同じETag値を含めなければなりません (MUST)。
The following examples illustrate how a DOTS client retrieves active mitigation requests from a DOTS server. In particular:
次の例は、ドットクライアントがドットサーバーからアクティブな緩和要求を取得する方法を示しています。特に：
* Figure 12 shows the example of a GET request to retrieve all DOTS mitigation requests signaled by a DOTS client.
* 図12は、ドットクライアントによってシグナリングされたすべてのドット緩和要求を検索するための取得要求の例を示しています。
* Figure 13 shows the example of a GET request to retrieve a specific DOTS mitigation request signaled by a DOTS client. The configuration data to be reported in the response is formatted in the same order as it was processed by the DOTS server in the original mitigation request.
* 図13は、ドットクライアントによってシグナリングされた特定のドット緩和要求を検索するための取得要求の例を示す。応答で報告される構成データは、元の緩和要求のドットサーバーによって処理されたのと同じ順序でフォーマットされています。
These two examples assume the default of "c=a"; that is, the DOTS client asks for all data to be reported by the DOTS server.
これら2つの例は、デフォルトの "c=a"を想定しています。つまり、ドットクライアントは、ドットサーバーによって報告されるすべてのデータを要求します。
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0
Figure 12: GET to Retrieve All DOTS Mitigation Requests
図12：すべてのドットの軽減要求を取得する
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332"
Observe: 0
Figure 13: GET to Retrieve a Specific DOTS Mitigation Request
図13：特定のドットの軽減要求を取得する
If the DOTS server does not find the 'mid' Uri-Path value conveyed in the GET request in its configuration data for the requesting DOTS client, it MUST respond with a 4.04 (Not Found) error Response Code. Likewise, the same error MUST be returned as a response to a request to retrieve all mitigation records (i.e., 'mid' Uri-Path is not defined) of a given DOTS client if the DOTS server does not find any mitigation record for that DOTS client. As a reminder, a DOTS client is identified by its identity (e.g., client certificate, 'cuid') and optionally the 'cdid'.
要求側DOTSクライアントの設定データにおいて、GET要求で伝達された'mid' Uri-Path値がDOTSサーバーで見つからない場合、4.04 (Not Found) エラー応答コードで応答しなければなりません (MUST)。同様に、DOTSサーバーがそのDOTSクライアントの緩和レコードを1つも見つけられない場合、特定のDOTSクライアントのすべての緩和レコードを取得する要求（すなわち'mid' Uri-Pathが定義されていない要求）に対する応答として同じエラーが返されなければなりません (MUST)。念のため、DOTSクライアントはその識別情報（例えばクライアント証明書、'cuid'）およびオプションで'cdid'によって識別されます。
Figure 14 shows a response example of all active mitigation requests associated with the DOTS client, as maintained by the DOTS server. The response indicates the mitigation status of each mitigation request.
図14は、ドットサーバによって維持されるように、ドットクライアントに関連するすべての能動的緩和要求の応答例を示す。応答は、各緩和要求の軽減状態を示します。
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 12332,
"mitigation-start": "1507818434",
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"target-protocol": [
17
],
"lifetime": 1756,
"status": "attack-successfully-mitigated",
"bytes-dropped": "134334555",
"bps-dropped": "43344",
"pkts-dropped": "333334444",
"pps-dropped": "432432"
},
{
"mid": 12333,
"mitigation-start": "1507818393",
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"target-protocol": [
6
],
"lifetime": 1755,
"status": "attack-stopped",
"bytes-dropped": "0",
"bps-dropped": "0",
"pkts-dropped": "0",
"pps-dropped": "0"
}
]
}
}
Figure 14: Response Body to a GET Request
図14：GETリクエストへの応答本文
The mitigation status parameters are described below:
緩和ステータスパラメータは以下のとおりです。
mitigation-start: Mitigation start time is expressed in seconds relative to 1970-01-01T00:00Z in UTC time (Section 3.4.1 of [RFC8949]). The CBOR encoding is modified so that the leading tag 1 (epoch-based date/time) MUST be omitted.
mitigation-start: 緩和開始時間は、UTC時間における1970-01-01T00:00Zからの秒数として表されます（[RFC8949]のセクション3.4.1）。CBORエンコーディングは、先頭のタグ1（エポックベースの日時）を省略しなければならない (MUST) ように変更されています。
This is a mandatory attribute when an attack mitigation is active. Particularly, 'mitigation-start' is not returned for a mitigation with 'status' code set to 8.
攻撃の軽減が有効な場合、これは必須の属性です。特に、 'Status-Start'は 'Status'コードが8に設定されている軽減のために返されません。
lifetime: The remaining lifetime of the mitigation request, in seconds.
寿命：緩和要求の残りの寿命（秒単位）。
This is a mandatory attribute.
これは必須の属性です。
status: Status of attack mitigation. The various possible values of 'status' parameter are explained in Table 3.
ステータス：攻撃緩和の状況。「Status」パラメータの様々な可能な値を表3に説明する。
This is a mandatory attribute.
これは必須の属性です。
bytes-dropped: 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 unsigned integer64.
バイトドロップされた：攻撃の軽減が引き起こされたため、緩和要求の合計ドロップバイト数。カウントは、符号なし整数64の最大値に達すると折り返します。
This is an optional attribute.
これはオプションの属性です。
bps-dropped: The average number of dropped bytes per second for the mitigation request since the attack mitigation was triggered. This average 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).
bps-dropped: 攻撃緩和がトリガーされて以降の、緩和要求に対する1秒あたりの平均ドロップバイト数。この平均は5分間隔であるべきです (SHOULD)（すなわち、バイト数を5分間のバケットに測定し、緩和がトリガーされて以降の時間にわたってこれらのバケットを平均化します）。
This is an optional attribute.
これはオプションの属性です。
pkts-dropped: 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 unsigned integer64.
PKTSドロップ：攻撃の軽減以降の緩和要求のためのドロップされたパケット数の総数。カウントは、符号なし整数64の最大値に達すると折り返します。
This is an optional attribute.
これはオプションの属性です。
pps-dropped: The average number of dropped packets per second for the mitigation request since the attack mitigation was triggered. This average 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).
pps-dropped: 攻撃緩和がトリガーされて以降の、緩和要求に対する1秒あたりの平均ドロップパケット数。この平均は5分間隔であるべきです (SHOULD)（すなわち、パケット数を5分間のバケットに測定し、緩和がトリガーされて以降の時間にわたってこれらのバケットを平均化します）。
This is an optional attribute.
これはオプションの属性です。
+===========+====================================================+
| Parameter | Description |
| Value | |
+===========+====================================================+
| 1 | Attack mitigation setup is in progress (e.g., |
| | changing the network path to redirect the inbound |
| | traffic to a DOTS mitigator). |
+-----------+----------------------------------------------------+
| 2 | Attack is being successfully mitigated (e.g., |
| | traffic is redirected to a DDoS mitigator and |
| | attack traffic is dropped). |
+-----------+----------------------------------------------------+
| 3 | Attack has stopped and the DOTS client can |
| | withdraw the mitigation request. This status code |
| | will be transmitted for immediate mitigation |
| | requests till the mitigation is withdrawn or the |
| | lifetime expires. For mitigation requests with |
| | preconfigured scopes (i.e., 'trigger-mitigation' |
| | set to 'false'), this status code will be |
| | transmitted four times and then transition to '8'. |
+-----------+----------------------------------------------------+
| 4 | Attack has exceeded the mitigation provider |
| | capability. |
+-----------+----------------------------------------------------+
| 5 | DOTS client has withdrawn the mitigation request |
| | and the mitigation is active but terminating. |
+-----------+----------------------------------------------------+
| 6 | Attack mitigation is now terminated. |
+-----------+----------------------------------------------------+
| 7 | Attack mitigation is withdrawn (by the DOTS |
| | server). If a mitigation request with 'trigger- |
| | mitigation' set to 'false' is withdrawn because it |
| | overlaps with an immediate mitigation request, |
| | this status code will be transmitted four times |
| | and then transition to '8' for the mitigation |
| | request with preconfigured scopes. |
+-----------+----------------------------------------------------+
| 8 | Attack mitigation will be triggered for the |
| | mitigation request only when the DOTS signal |
| | channel session is lost. |
+-----------+----------------------------------------------------+
Table 3: Values of 'status' Parameter
表3：「Status」パラメータの値
The Observe Option defined in [RFC7641] extends the CoAP core protocol with a mechanism for a CoAP client to "observe" a resource on a CoAP server: the client retrieves a representation of the resource and requests this representation be updated by the server as long as the client is interested in the resource. DOTS implementations MUST support the Observe Option for both 'mitigate' and 'config' (Section 4.2).
[RFC7641]で定義されているObserveオプションは、CoAPクライアントがCoAPサーバー上のリソースを「監視（observe）」するためのメカニズムによってCoAPコアプロトコルを拡張します。クライアントはリソースの表現を取得し、クライアントがリソースに関心を持っている限り、この表現がサーバーによって更新されるよう要求します。DOTS実装は'mitigate'と'config'の両方についてObserveオプションをサポートしなければなりません (MUST)（セクション4.2）。
A DOTS client conveys the Observe Option set to '0' in the GET request to receive asynchronous notifications of attack mitigation status from the DOTS server.
ドットクライアントは、DOTSサーバーからの攻撃軽減ステータスの非同期通知を受信するために、監視要求の「0」に設定されているOpterveオプションを伝えます。
Unidirectional mitigation notifications within the bidirectional signal channel enables asynchronous notifications between the agents. [RFC7641] indicates that (1) a notification can be sent in a Confirmable or a Non-confirmable message and (2) the message type used is typically application dependent and may be determined by the server for each notification individually. For the DOTS server application, the message type MUST always be set to Non-confirmable even if the underlying CoAP library elects a notification to be sent in a Confirmable message. This overrides the behavior defined in Section 4.5 of [RFC7641] to send a Confirmable message instead of a Non-confirmable message at least every 24 hours for the following reasons: First, the DOTS signal channel uses a heartbeat mechanism to determine if the DOTS client is alive. Second, Confirmable messages are not suitable during an attack.
双方向シグナルチャネル内の一方向緩和通知により、エージェント間の非同期通知が可能になります。[RFC7641]は、(1) 通知はConfirmableまたはNon-confirmableメッセージで送信できること、および (2) 使用されるメッセージタイプは通常アプリケーションに依存し、各通知に対してサーバーによって個別に決定される場合があることを示しています。DOTSサーバーアプリケーションの場合、基盤となるCoAPライブラリがConfirmableメッセージでの通知送信を選択したとしても、メッセージタイプは常にNon-confirmableに設定されなければなりません (MUST)。これは以下の理由から、少なくとも24時間ごとにNon-confirmableメッセージの代わりにConfirmableメッセージを送信するという[RFC7641]のセクション4.5で定義された動作を上書きします: 第1に、DOTSシグナルチャネルはDOTSクライアントが生存しているかどうかを判断するためにハートビートメカニズムを使用します。第2に、Confirmableメッセージは攻撃中には適していません。
Due to the higher likelihood of packet loss during a DDoS attack, the DOTS server periodically sends attack mitigation status to the DOTS client and also notifies the DOTS client whenever the status of the attack mitigation changes. If the DOTS server cannot maintain an RTT estimate, it MUST NOT send more than one asynchronous notification every 3 seconds and SHOULD use an even less aggressive rate whenever possible (case 2 in Section 3.1.3 of [RFC8085]).
DDoS攻撃中のパケット損失の可能性が高いため、DOTSサーバーは定期的に攻撃緩和ステータスをDOTSクライアントに送信し、攻撃緩和のステータスが変化したときはいつでもDOTSクライアントに通知します。DOTSサーバーがRTT推定値を維持できない場合、3秒ごとに複数個の非同期通知を送信してはならず (MUST NOT)、可能な限りさらにアグレッシブでないレートを使用すべきです (SHOULD)（[RFC8085]のセクション3.1.3のケース2）。
When conflicting requests are detected, the DOTS server enforces the corresponding policy (e.g., accept all requests, reject all requests, accept only one request but reject all the others). It is assumed that this policy is supplied by the DOTS server administrator or that it is a default behavior of the DOTS server implementation. Then, the DOTS server sends a notification message(s) to the DOTS client(s) at the origin of the conflict (refer to the conflict parameters defined in Section 4.4.1). A conflict notification message includes information about the conflict cause, scope, and the status of the mitigation request(s). For example:
競合する要求が検出されると、ドットサーバは対応するポリシーを強制する（例えば、すべての要求を受け入れ、すべての要求を拒否し、1つの要求のみを受け入れますが、他のすべての要求のみを受け入れます）。このポリシーは、ドットサーバー管理者によって提供されているか、ドットサーバー実装のデフォルトの動作であることが仮定されています。その後、ドットサーバは、競合の原点で通知メッセージをドットクライアントに送信する（4.4.1項で定義されている競合パラメータを参照）。競合通知メッセージには、競合の原因、範囲、および緩和要求のステータスに関する情報が含まれています。例えば：
* A notification message with 'status' code set to '7 (Attack mitigation is withdrawn)' and 'conflict-status' set to '1' is sent to a DOTS client to indicate that an active mitigation request is deactivated because a conflict is detected.
* '7（攻撃軽減拒否）と' conflict-status 'が' 1 'に設定されている通知メッセージは、競合が検出されたために能動的な緩和要求が無効にされていることを示すために、ドットクライアントに送信されます。。
* A notification message with 'status' code set to '1 (Attack mitigation is in progress)' and 'conflict-status' set to '2' is sent to a DOTS client to indicate that this mitigation request is in progress, but a conflict is detected.
* '1（攻撃軽減の進行中）に設定されている「Status」コードを持つ通知メッセージと'競合 - ステータス 'が' 2 'に設定されているのは、この軽減要求が進行中であることを示すためにドットクライアントに送信されますが、競合検出されます。
Upon receipt of a conflict notification message indicating that a mitigation request is deactivated because of a conflict, a DOTS client MUST NOT resend the same mitigation request before the expiry of 'retry-timer'. It is also recommended that DOTS clients support the means to alert administrators about mitigation conflicts.
競合のために緩和要求が非アクティブ化されたことを示す競合通知メッセージを受信した際、DOTSクライアントは'retry-timer'が満了する前に同じ緩和要求を再送してはなりません (MUST NOT)。また、DOTSクライアントが管理者に緩和の競合について警告する手段をサポートすることが推奨されます。
A DOTS client that is no longer interested in receiving notifications from the DOTS server can simply "forget" the observation. When the DOTS server sends the next notification, the DOTS client will not recognize the token in the message and, thus, will return a Reset message. This causes the DOTS server to remove the associated entry. Alternatively, the DOTS client can explicitly de-register itself by issuing a GET request that has the Token field set to the token of the observation to be canceled and includes an Observe Option with the value set to '1' (de-register). The latter is more deterministic and, thus, is RECOMMENDED.
DOTSサーバーからの通知を受信することに関心がなくなったDOTSクライアントは、単に監視を「忘れる」ことができます。DOTSサーバーが次の通知を送信したとき、DOTSクライアントはメッセージ内のトークンを認識しないため、Resetメッセージを返します。これにより、DOTSサーバーは関連するエントリを削除します。あるいは、DOTSクライアントは、取り消す監視のトークンにTokenフィールドが設定され、値が「1」（登録解除）に設定されたObserveオプションを含むGET要求を発行することによって、明示的に自身を登録解除できます。後者の方がより確定的であり、したがって推奨されます (RECOMMENDED)。
Figure 15 shows an example of a DOTS client requesting a DOTS server to send notifications related to a mitigation request. Note that for mitigations with preconfigured scopes (i.e., 'trigger-mitigation' set to 'false'), the state will need to transition from '3' (attack-stopped) to '8' (attack-mitigation-signal-loss).
図15は、緩和要求に関連する通知を送信するためのドットサーバを要求するドットクライアントの例を示す。事前設定されたスコープ（すなわち、 'Trigger-ilitaging'が 'false'に設定されている）で軽減するためには、状態は '3'（攻撃停止）から '8'（攻撃軽減信号損失）に移行する必要があります。。
+-----------+ +-----------+
|DOTS Client| |DOTS Server|
+-----------+ +-----------+
| |
| GET /<mid> |
| Token: 0x4a | Registration
| Observe: 0 |
+----------------------------------------->|
| |
| 2.05 Content |
| Token: 0x4a | Notification of
| Observe: 12 | the current state
| status: "attack-mitigation-in-progress" |
|<-----------------------------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 44 | a state change
| status: "attack-successfully-mitigated" |
|<-----------------------------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 60 | a state change
| status: "attack-stopped" |
|<-----------------------------------------+
| |
...
Figure 15: Notifications of Attack Mitigation Status
図15：攻撃軽減の通知
The DOTS client can send the GET request at frequent intervals without the Observe Option to retrieve the configuration data of the mitigation request and non-configuration data (i.e., the attack status). DOTS clients MAY be configured with a policy indicating the frequency of polling DOTS servers to get the mitigation status. This frequency MUST NOT be more than one UDP datagram per RTT, as discussed in Section 3.1.3 of [RFC8085].
DOTSクライアントは、緩和要求の設定データおよび非設定データ（すなわち攻撃ステータス）を取得するために、Observeオプションなしで頻繁な間隔でGET要求を送信できます。DOTSクライアントは、緩和ステータスを取得するためのDOTSサーバーのポーリング頻度を示すポリシーで設定されてもよいです (MAY)。[RFC8085]のセクション3.1.3で説明されているように、この頻度はRTTあたり複数個のUDPデータグラムであってはなりません (MUST NOT)。
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. In such case, the DOTS client withdraws the mitigation request by issuing a DELETE request for this mitigation request (Section 4.4.4).
ドットサーバーが攻撃を軽減でき、攻撃が停止した場合、ドットサーバーはそのような状態に表示されます。そのような場合、ドットクライアントはこの軽減要求の削除要求を発行することによって緩和要求を引き出す（4.4.4項）。
A DOTS client SHOULD react to the status of the attack per the information sent by the DOTS server rather than performing its own detection that the attack has been mitigated. This ensures that the DOTS client does not withdraw a mitigation request prematurely because it is possible that the DOTS client does not sense the DDoS attack on its resources, but the DOTS server could be actively mitigating the attack because the attack is not completely averted.
DOTSクライアントは、攻撃が緩和されたという独自の検出を実行するのではなく、DOTSサーバーによって送信された情報に従って攻撃のステータスに反応すべきです (SHOULD)。これにより、DOTSクライアントがそのリソースに対するDDoS攻撃を検知していない可能性があるにもかかわらず、攻撃が完全に回避されていないためにDOTSサーバーが積極的に攻撃を緩和している可能性がある場合に、DOTSクライアントが途中で緩和要求を取り下げてしまわないようになります。
While DDoS mitigation is in progress, due to the likelihood of packet loss, a DOTS client MAY periodically transmit DOTS mitigation efficacy updates to the relevant DOTS server. A PUT request is used to convey the mitigation efficacy update to the DOTS server. This PUT request is treated as a refresh of the current mitigation.
DDoS緩和の進行中は、パケット損失の可能性のため、DOTSクライアントは関連するDOTSサーバーにDOTS緩和有効性更新を定期的に送信してもよいです (MAY)。緩和有効性更新をDOTSサーバーに伝達するためにPUT要求が使用されます。このPUT要求は、現在の緩和のリフレッシュとして扱われます。
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.
「attack-status」パラメータは、有効性更新を実行するときの必須の属性です。「攻撃状態」パラメータに含まれる様々な可能な値を表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
表4： 'attack-status'パラメータの値
The PUT request used for the efficacy update MUST include all the parameters used in the PUT request to carry the DOTS mitigation request (Section 4.4.1) unchanged apart from the 'lifetime' parameter value. If this is not the case, the DOTS server MUST reject the request with a 4.00 (Bad Request).
有効性更新に使用されるPUT要求は、'lifetime'パラメータ値を除き、DOTS緩和要求を伝達するためにPUT要求で使用されたすべてのパラメータ（セクション4.4.1）を変更せずに含まなければなりません (MUST)。そうでない場合、DOTSサーバーは4.00 (Bad Request) で要求を拒否しなければなりません (MUST)。
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 existence of the mitigation request. If UDP is used as transport, CoAP requests may arrive out of order. For example, the DOTS client may send a PUT request to convey an efficacy update to the DOTS server followed by a DELETE request to withdraw the mitigation request, but the DELETE request arrives at the DOTS server before the PUT request. To handle out-of-order delivery of requests, if an If-Match Option is present in the PUT request and the 'mid' in the request matches a mitigation request from that DOTS client, the request is processed by the DOTS server. If no match is found, the PUT request is silently ignored by the DOTS server.
空の値を持つIF-Matchオプション（[RFC7252]のセクション5.10.8.1）を使用して、緩和要求の現在の存在についてPUTリクエストを条件として条件付きにします。UDPがトランスポートとして使用されている場合、CoAP要求は順不同で到着する可能性があります。例えば、ドットクライアントは、無効更新をドットサーバに伝達するためのPUT要求を送信し、その後に緩和要求を引き出すための削除要求が行われてもよいが、PUT要求の前にドットサーバに到着する。要求の順序の順序配信を処理するために、IFマッチオプションがPUT要求に存在し、要求の「MID」がそのドットクライアントからの軽減要求と一致する場合、その要求はドットサーバによって処理されます。一致が見つからない場合、PUT要求はドットサーバーによって黙って無視されます。
An example of an efficacy update message, which includes an If-Match Option with an empty value, is depicted in Figure 16.
空の値を持つIFマッチオプションを含む有効性更新メッセージの例を図16に示します。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
If-Match:
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"target-port-range": [
{
"lower-port": 80
},
{
"lower-port": 443
},
{
"lower-port": 8080
}
],
"target-protocol": [
6
],
"attack-status": "under-attack"
}
]
}
}
Figure 16: An Example of Efficacy Update
図16：有効性更新の例
The DOTS server indicates the result of processing a PUT request using CoAP Response Codes. The Response Code 2.04 (Changed) is returned if the DOTS server has accepted the mitigation efficacy update. The error Response Code 5.03 (Service Unavailable) is returned if the DOTS server has erred or is incapable of performing the mitigation. As specified in [RFC7252], 5.03 uses Max-Age Option to indicate the number of seconds after which to retry.
ドットサーバは、CoAP応答コードを用いてPUT要求を処理した結果を示す。ドットサーバが緩和有効性更新を受け入れた場合、応答コード2.04（変更）が返されます。ドットサーバーが誤って緩和を実行することができない場合、エラー応答コード5.03（サービス使用不可）が返されます。[RFC7252]で指定されているように、5.03はmax-ageオプションを使用して再試行する秒数を示します。
DELETE requests are used to withdraw DOTS mitigation requests from DOTS servers (Figure 17).
ドットサーバーからドットの軽減要求を撤回するために要求を削除します（図17）。
'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE requests.
'cuid'と 'mid'は、削除要求のための必須のURIパスパラメータです。
The same considerations for manipulating the 'cdid' parameter by DOTS gateways, as specified in Section 4.4.1, MUST be followed for DELETE requests. Uri-Path parameters with empty values MUST NOT be present in a request.
セクション4.4.1で指定されているDOTSゲートウェイによる'cdid'パラメータの操作に関する同じ考慮事項に、DELETE要求でも従わなければなりません (MUST)。空の値を持つUri-Pathパラメータは要求内に存在してはなりません (MUST NOT)。
Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Figure 17: Withdraw a DOTS Mitigation
図17：ドット軽減を撤回する
If the DELETE request does not include 'cuid' and 'mid' parameters, the DOTS server MUST reply with a 4.00 (Bad Request).
DELETE要求に'cuid'および'mid'パラメータが含まれていない場合、DOTSサーバーは4.00 (Bad Request) で応答しなければなりません (MUST)。
Once the request is validated, the DOTS server immediately acknowledges a DOTS client's request to withdraw the DOTS mitigation request using a 2.02 (Deleted) Response Code with no response payload. A 2.02 (Deleted) Response Code is returned even if the 'mid' parameter value conveyed in the DELETE request does not exist in its configuration data before the request.
要求が検証されると、ドットサーバは直ちにドットクライアントの要求を承認し、無応答ペイロードのない2.02（削除済み）応答コードを使用してドット軽減要求を引き出すことを確認します。削除要求で伝達されている「MID」パラメータ値が要求の前にその構成データに存在しない場合でも、2.02（削除された）応答コードが返されます。
If the DOTS server finds the 'mid' parameter value conveyed in the DELETE request in its configuration data for the DOTS client, then to protect against route or DNS flapping caused by a DOTS client rapidly removing a mitigation and to dampen the effect of oscillating attacks, the DOTS server MAY allow mitigation to continue for a limited period after acknowledging a DOTS client's withdrawal of a mitigation request. During this period, the DOTS server status messages SHOULD indicate that mitigation is active but terminating (Section 4.4.2).
DOTSサーバーがDOTSクライアントの設定データ内のDELETE要求で伝達された'mid'パラメータ値を見つけた場合、DOTSクライアントが緩和を急速に取り下げたり要求したりすることによって引き起こされるルートやDNSのフラッピングから保護し、振動攻撃の影響を減衰させるために、DOTSサーバーはDOTSクライアントによる緩和要求の取り下げを認めた後、限られた期間だけ緩和を継続させてもよいです (MAY)。この期間中、DOTSサーバーのステータスメッセージは、緩和がアクティブであるが終了処理中（active-but-terminating）であることを示すべきです (SHOULD)（セクション4.4.2）。
The initial active-but-terminating period SHOULD be sufficiently long to absorb latency incurred by route propagation. The active-but-terminating period SHOULD be set by default to 120 seconds. If the client requests mitigation again before the initial active-but-terminating period elapses, the DOTS server MAY exponentially increase (the base of the exponent is 2) the active-but-terminating period up to a maximum of 300 seconds (5 minutes).
最初のアクティブ終了処理中（active-but-terminating）期間は、ルート伝播によって生じる遅延を吸収するのに十分な長さであるべきです (SHOULD)。active-but-terminating期間は、デフォルトで120秒に設定されるべきです (SHOULD)。最初のアクティブ終了処理中期間が経過する前にクライアントが再び緩和を要求した場合、DOTSサーバーはactive-but-terminating期間を指数関数的に増加させてもよく (MAY)（指数の底は2）、最大300秒（5分）までとします。
Once the active-but-terminating period elapses, the DOTS server MUST treat the mitigation as terminated.
active-but-terminating期間が経過すると、DOTSサーバーは緩和が終了したものとして扱わなければなりません (MUST)。
If a mitigation is triggered due to a signal channel loss, the DOTS server relies upon normal triggers to stop that mitigation (typically, receipt of a valid DELETE request, expiry of the mitigation lifetime, or scrubbing the traffic to the attack target). In particular, the DOTS server MUST NOT consider the signal channel recovery as a trigger to stop the mitigation.
シグナルチャネルの喪失によって緩和がトリガーされた場合、DOTSサーバーは通常トリガーに依存してその緩和を停止します（通常は有効なDELETE要求の受信、緩和有効期間の満了、または攻撃対象へのトラフィックのスクラビング）。特に、DOTSサーバーはシグナルチャネルの回復を緩和を停止するトリガーとみなしてはなりません (MUST NOT)。
A DOTS client can negotiate, configure, and retrieve the DOTS signal channel session behavior with its DOTS peers. The DOTS signal channel can be used, for example, to configure the following:
ドットクライアントは、ドットシグナルチャネルセッションの動作をドットピアと交渉、構成、および取得できます。ドット信号チャネルは、たとえば次のように構成できます。
a. Heartbeat interval ('heartbeat-interval'): DOTS agents regularly send heartbeats to each other after mutual authentication is successfully completed in order to keep the DOTS signal channel open. Heartbeat messages are exchanged between DOTS agents every 'heartbeat-interval' seconds to detect the current status of the DOTS signal channel session.
a. ハートビート間隔（ 'ハートビートインターバル'）：ドットエージェントは、ドット信号チャネルを開いたままにしておくために相互認証が成功した後に互いにハートビートを定期的に送信します。ハートビートメッセージは、ドット信号チャネルセッションの現在のステータスを検出するために「ハートビートインターバル」秒ごとにドットエージェント間で交換されます。
b. Missing heartbeats allowed ('missing-hb-allowed'): This variable indicates the maximum number of consecutive heartbeat messages for which a DOTS agent did not receive a response before concluding that the session is disconnected or defunct.
b. 存在しているハートビートが許可されていません（ 'Missing-Hb-ablells'）：この変数は、セッションが切断されたことを締めくくる前にドットエージェントが応答を受け取らなかった連続したハートビートメッセージの最大数を示します。
c. Acceptable probing rate ('probing-rate'): This parameter 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.
c. 許容可能なプロービングレート（「プロービングレート」）：このパラメータは、応答しないピアトドットエージェントに送信する際のドットエージェントによって超えてはいけない平均データレートを示します。
d. Acceptable signal loss ratio: Maximum retransmissions ('max-retransmit'), retransmission timeout value ('ack-timeout'), and other message transmission parameters for Confirmable messages over the DOTS signal channel.
d. 許容される信号損失比：最大再送（ 'max-retransmit'）、再送タイムアウト値（ 'ACK-TIMEOUT'）、およびDOTS信号チャネルを介した確認可能メッセージのためのその他のメッセージ送信パラメータ。
When the DOTS signal channel is established over a reliable transport (e.g., TCP), there is no need for the reliability mechanisms provided by CoAP over UDP since the underlying TCP connection provides retransmissions and deduplication [RFC8323]. CoAP over reliable transports does not support Confirmable or Non-confirmable message types. As such, the transmission-related parameters ('missing-hb-allowed' and acceptable signal loss ratio) are negotiated only for DOTS over unreliable transports.
ドット信号チャネルが信頼できる輸送（例えば、TCP）にわたって確立されると、基礎となるTCP接続は再送信および重複排除を提供するので、UDPを介して提供される信頼性メカニズムを必要としない。信頼できる輸送を協力しても、確認可能なメッセージタイプまたは確認不可能なメッセージタイプはサポートされていません。したがって、伝送関連パラメータ（ 'Missing-Hb許可'および許容信号損失率）は、信頼性の低い輸送の上でドットのみに交渉されます。
The same or distinct configuration sets may be used during times when a mitigation is active ('mitigating-config') and when no mitigation is active ('idle-config'). This is particularly useful for DOTS servers that might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation. If distinct configurations are used, DOTS agents MUST follow the appropriate configuration set as a function of the mitigation activity (e.g., if no mitigation request is active (also referred to as 'idle' time), values related to 'idle-config' must be followed). Additionally, DOTS agents MUST automatically switch to the other configuration upon a change in the mitigation activity (e.g., if an attack mitigation is launched after an 'idle' time, the DOTS agent switches from values related to 'idle-config' to values related to 'mitigating-config').
緩和がアクティブなとき（'mitigating-config'）と緩和がアクティブでないとき（'idle-config'）で、同じ設定セットまたは個別の設定セットを使用できます。これは、アクティブなDOTSクライアントが緩和を要求していないときにハートビート頻度を減らすか、またはハートビート交換を停止することを望むDOTSサーバーに特に役立ちます。個別の設定が使用される場合、DOTSエージェントは緩和アクティビティの関数として適切な設定セットに従わなければなりません (MUST)（例えば、アクティブな緩和要求がない場合（「アイドル」時間とも呼ばれます）、'idle-config'に関連する値に従わなければなりません）。さらに、DOTSエージェントは緩和アクティビティの変更時に自動的にもう一方の設定に切り替えなければなりません (MUST)（例えば、「アイドル」時間の後に攻撃緩和が開始された場合、DOTSエージェントは'idle-config'に関連する値から'mitigating-config'に関連する値に切り替えます）。
CoAP requests and responses are indicated for reliable delivery by marking them as Confirmable messages. DOTS signal channel session configuration requests and responses are marked as Confirmable messages. As explained in Section 2.1 of [RFC7252], a Confirmable message is retransmitted using a default timeout and exponential backoff between retransmissions until the DOTS server sends an Acknowledgement message (ACK) with the same Message ID conveyed from the DOTS client.
CoAP要求と応答は、確認可能なメッセージとしてそれらをマークすることによって信頼できる配信のために示されています。ドット信号チャネルセッション構成要求と応答は、確認可能なメッセージとしてマークされています。[RFC7252]のセクション2.1で説明されているように、DOTSサーバーがDOTSクライアントから伝達された同じメッセージIDを持つ確認メッセージ（ACK）を送信するまで、再送信間のデフォルトのタイムアウトと指数関数的バックオフを使用して確認可能なメッセージが再送信されます。
Message transmission parameters are defined in Section 4.8 of [RFC7252]. The DOTS server can either piggyback the response in the Acknowledgement message or, if the DOTS server cannot respond immediately to a request carried in a Confirmable message, it simply responds with an Empty Acknowledgement message so that the DOTS client can stop retransmitting the request. Empty Acknowledgement messages are explained in Section 2.2 of [RFC7252]. When the response is ready, the server sends it in a new Confirmable message, which, in turn, needs to be acknowledged by the DOTS client (see Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses exchanged between DOTS agents during 'idle' time, except heartbeat messages, are marked as Confirmable messages.
メッセージ送信パラメータは[RFC7252]のセクション4.8で定義されています。ドットサーバは、確認応答メッセージ内の応答にピギーバックすることができ、あるいは確認可能なメッセージで実行された要求に直ちに応答できない場合、それは単に空の確認メッセージで応答し、ドットクライアントが要求の再送信を停止することができる。空の確認応答メッセージは[RFC7252]のセクション2.2で説明されています。応答の準備ができたら、サーバーは新しい確認可能なメッセージで送信します。これは、DOTSクライアントによって確認される必要があります（[RFC7252]のセクション5.2.1と5.2.2を参照）。「アイドル」時刻の間に、ハートビートメッセージを除くドットエージェント間で交換された要求と応答は、確認可能なメッセージとしてマークされています。
| Implementation Note: A DOTS client that receives a response in a Confirmable message may want to clean up the message state right after sending the ACK. If that ACK is lost and the DOTS server retransmits the Confirmable message, the DOTS client may no longer have any state that would help it correlate this response; from the DOTS client's standpoint, the retransmission message is unexpected. The DOTS client will send a Reset message so it does not receive any more retransmissions. This behavior is normal and not an indication of an error (see Section 5.3.2 of [RFC7252] for more details).
| 実装上の注記：Confirmableメッセージで応答を受信したDOTSクライアントは、ACKを送信した直後にメッセージ状態を解放したくなる場合があります。そのACKが失われ、DOTSサーバーがConfirmableメッセージを再送すると、DOTSクライアントにはこの応答との関連付けに役立つ状態がもはやなく、DOTSクライアントから見ると再送メッセージは予期しないものです。DOTSクライアントは、これ以上再送を受信しないようResetメッセージを送信します。この動作は正常であり、エラーを示すものではありません（詳細は[RFC7252]のSection 5.3.2を参照）。
A GET request is used to obtain acceptable (e.g., minimum and maximum values) and current configuration parameters on the DOTS server for DOTS signal channel session configuration. This procedure occurs between a DOTS client and its immediate peer DOTS server. As such, this GET request MUST NOT be relayed by a DOTS gateway.
GET要求は、DOTSシグナルチャネルセッション設定について、DOTSサーバー上の許容可能な（例えば最小値および最大値）および現在の設定パラメータを取得するために使用されます。この手順はDOTSクライアントとその直接のピアDOTSサーバーの間で行われます。そのため、このGET要求はDOTSゲートウェイによって中継されてはなりません (MUST NOT)。
Figure 18 shows how to obtain configuration parameters that the DOTS server will find acceptable.
図18は、ドットサーバが許容できる設定パラメータを取得する方法を示しています。
Header: GET (Code=0.01) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "config"
ヘッダー：get（Code=0.01）URI-Path： ".well-knefic" uri-path： "dots" uri-path： "config"
Figure 18: GET to Retrieve Configuration
図18：設定を取得します
The DOTS server in the 2.05 (Content) response conveys the current, minimum, and maximum attribute values acceptable by the DOTS server (Figure 19).
2.05（コンテンツ）応答のドットサーバは、ドットサーバによって許容される現在、最小、および最大属性値を伝えます（図19）。
{
"ietf-dots-signal-channel:signal-config": {
"mitigating-config": {
"heartbeat-interval": {
"max-value": number,
"min-value": number,
"current-value": number
},
"missing-hb-allowed": {
"max-value": number,
"min-value": number,
"current-value": number
},
"probing-rate": {
"max-value": number,
"min-value": number,
"current-value": number
},
"max-retransmit": {
"max-value": number,
"min-value": number,
"current-value": number
},
"ack-timeout": {
"max-value-decimal": "string",
"min-value-decimal": "string",
"current-value-decimal": "string"
},
"ack-random-factor": {
"max-value-decimal": "string",
"min-value-decimal": "string",
"current-value-decimal": "string"
}
},
"idle-config": {
"heartbeat-interval": {
"max-value": number,
"min-value": number,
"current-value": number
},
"missing-hb-allowed": {
"max-value": number,
"min-value": number,
"current-value": number
},
"probing-rate": {
"max-value": number,
"min-value": number,
"current-value": number
},
"max-retransmit": {
"max-value": number,
"min-value": number,
"current-value": number
},
"ack-timeout": {
"max-value-decimal": "string",
"min-value-decimal": "string",
"current-value-decimal": "string"
},
"ack-random-factor": {
"max-value-decimal": "string",
"min-value-decimal": "string",
"current-value-decimal": "string"
}
}
}
}
Figure 19: GET Configuration Response Body Schema
図19：設定応答本文スキーマを取得します
The parameters in Figure 19 are described below:
図19のパラメータを以下に説明します。
mitigating-config: Set of configuration parameters to use when a mitigation is active. The following parameters may be included:
mitigating-config：軽減がアクティブなときに使用する構成パラメータのセットです。以下のパラメータが含まれている場合があります。
heartbeat-interval: Time interval in seconds between two consecutive heartbeat messages.
HeartBeat-Interval：2つの連続したハートビートメッセージの間の時間間隔。
'0' is used to disable the heartbeat mechanism.
ハートビートメカニズムを無効にするために '0'が使用されています。
This is an optional attribute.
これはオプションの属性です。
missing-hb-allowed: Maximum number of consecutive heartbeat messages for which the DOTS agent did not receive a response before concluding that the session is disconnected.
MUSING-HB-Allow：セッションが切断されたことを締めくくる前に、ドットエージェントが応答を受け取らなかった連続したハートビートメッセージの最大数。
This is an optional attribute.
これはオプションの属性です。
probing-rate: The average data rate, in bytes/second, that must not be exceeded by a DOTS agent in sending to a peer DOTS agent that does not respond (referred to as PROBING_RATE parameter in CoAP).
プロービングレート：平均データレート（バイト/秒単位）は、応答しないピアトドットエージェントに送信する際のドットエージェントによって超えてはいけません（CoAPのPROBING_RATEパラメータ）。
This is an optional attribute.
これはオプションの属性です。
max-retransmit: Maximum number of retransmissions for a message (referred to as MAX_RETRANSMIT parameter in CoAP).
MAX-RESTRANSMIT：メッセージの再送信の最大数（CoAPのMAX_RETRANSMITパラメータと呼びます）。
This is an optional attribute.
これはオプションの属性です。
ack-timeout: Timeout value in seconds used to calculate the initial retransmission timeout value (referred to as ACK_TIMEOUT parameter in CoAP).
ACK-TIMEOUT：初期再送信タイムアウト値（CoAP内のACK_TIMEOUTパラメータと呼ばれる）の計算に使用されるタイムアウト値。
This is an optional attribute.
これはオプションの属性です。
ack-random-factor: Random factor used to influence the timing of retransmissions (referred to as ACK_RANDOM_FACTOR parameter in CoAP).
ACK-Random-Factor：再送信のタイミング（COAQのACK_RANDOM_FACTORパラメータと呼ぶ）に影響を与えるために使用されるランダムファクタ。
This is an optional attribute.
これはオプションの属性です。
idle-config: Set of configuration parameters to use when no mitigation is active. This attribute has the same structure as 'mitigating-config'.
idle-config：緩和が有効なときに使用する構成パラメータのセット。この属性は 'mitigating-config'と同じ構造を持ちます。
Figure 20 shows an example of acceptable and current configuration parameters on a DOTS server for DOTS signal channel session configuration. The same acceptable configuration is used during mitigation and idle times.
図20は、ドット信号チャネルセッション構成のためのドットサーバ上の許容可能な構成パラメータの例を示す。緩和とアイドル時間の間に同じ許容設定が使用されます。
{
"ietf-dots-signal-channel:signal-config": {
"mitigating-config": {
"heartbeat-interval": {
"max-value": 240,
"min-value": 15,
"current-value": 30
},
"missing-hb-allowed": {
"max-value": 20,
"min-value": 3,
"current-value": 15
},
"probing-rate": {
"max-value": 20,
"min-value": 5,
"current-value": 15
},
"max-retransmit": {
"max-value": 15,
"min-value": 2,
"current-value": 3
},
"ack-timeout": {
"max-value-decimal": "30.00",
"min-value-decimal": "1.00",
"current-value-decimal": "2.00"
},
"ack-random-factor": {
"max-value-decimal": "4.00",
"min-value-decimal": "1.10",
"current-value-decimal": "1.50"
}
},
"idle-config": {
"heartbeat-interval": {
"max-value": 240,
"min-value": 15,
"current-value": 30
},
"missing-hb-allowed": {
"max-value": 20,
"min-value": 3,
"current-value": 15
},
"probing-rate": {
"max-value": 20,
"min-value": 5,
"current-value": 15
},
"max-retransmit": {
"max-value": 15,
"min-value": 2,
"current-value": 3
},
"ack-timeout": {
"max-value-decimal": "30.00",
"min-value-decimal": "1.00",
"current-value-decimal": "2.00"
},
"ack-random-factor": {
"max-value-decimal": "4.00",
"min-value-decimal": "1.10",
"current-value-decimal": "1.50"
}
}
}
}
Figure 20: Example of a Configuration Response Body
図20：構成応答本体の例
A PUT request (Figures 21 and 22) is used to convey the configuration parameters for the signal channel (e.g., heartbeat interval, maximum retransmissions). Message transmission parameters for CoAP are defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of transmission parameter values are 'ack-timeout' (2 seconds), 'max-retransmit' (3), and 'ack-random-factor' (1.5). In addition to those parameters, the RECOMMENDED specific DOTS transmission parameter values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' (15).
PUT要求（図21および22）は、シグナルチャネルの設定パラメータ（例えばハートビート間隔、最大再送信回数）を伝達するために使用されます。CoAPのメッセージ送信パラメータは[RFC7252]のセクション4.8で定義されています。送信パラメータ値の推奨される値 (RECOMMENDED) は、'ack-timeout'（2秒）、'max-retransmit'（3）、および'ack-random-factor'（1.5）です。これらのパラメータに加えて、推奨される特定のDOTS送信パラメータ値 (RECOMMENDED) は、'heartbeat-interval'（30秒）および'missing-hb-allowed'（15）です。
| Note: 'heartbeat-interval' should be tweaked to also assist
| DOTS messages for NAT traversal (SIG-011 of [RFC8612]).
| According to [RFC8085], heartbeat messages must not be sent
| more frequently than once every 15 seconds and should use
| longer intervals when possible. Furthermore, [RFC4787]
| recommends that NATs use a state timeout of 2 minutes or
| longer, but experience shows that sending packets every 15 to
| 30 seconds is necessary to prevent the majority of middleboxes
| from losing state for UDP flows. From that standpoint, the
| RECOMMENDED minimum 'heartbeat-interval' is 15 seconds and the
| RECOMMENDED maximum 'heartbeat-interval' is 240 seconds. The
| recommended value of 30 seconds is selected to anticipate the
| expiry of NAT state.
|
| A 'heartbeat-interval' of 30 seconds may be considered to be
| too chatty in some deployments. For such deployments, DOTS
| agents may negotiate longer 'heartbeat-interval' values to
| prevent any network overload with too frequent heartbeats.
|
| Different heartbeat intervals can be defined for 'mitigating-
| config' and 'idle-config' to reduce being too chatty during
| idle times. If there is an on-path translator between the DOTS
| client (standalone or part of a DOTS gateway) and the DOTS
| server, the 'mitigating-config' 'heartbeat-interval' has to be
| smaller than the translator session timeout. It is recommended
| that the 'idle-config' 'heartbeat-interval' also be smaller
| than the translator session timeout to prevent translator
| traversal issues or that it be disabled entirely. Means to
| discover the lifetime assigned by a translator are out of
| scope.
|
| Given that the size of the heartbeat request cannot exceed
| ('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate'
| should be set appropriately to avoid slowing down heartbeat
| exchanges. For example, 'probing-rate' may be set to 2 *
| ("size of encrypted DOTS heartbeat request"/'heartbeat-
| interval') or (("size of encrypted DOTS heartbeat request" +
| "average size of an encrypted mitigation request")/'heartbeat-
| interval'). Absent any explicit configuration or inability to
| dynamically adjust 'probing-rate' values (Section 4.8.1 of
| [RFC7252]), DOTS agents use 5 bytes/second as a default
| 'probing-rate' value.
If the DOTS agent wishes to change the default values of message transmission parameters, it SHOULD follow the guidance given in Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated values for message transmission parameters and default values for non-negotiated message transmission parameters.
DOTSエージェントがメッセージ送信パラメータのデフォルト値を変更したい場合は、[RFC7252]のセクション4.8.1で与えられているガイダンスに従うべきです (SHOULD)。DOTSエージェントは、メッセージ送信パラメータには交渉された値を、交渉されていないメッセージ送信パラメータにはデフォルト値を使用しなければなりません (MUST)。
The signal channel session configuration is applicable to a single DOTS signal channel session between DOTS agents, so the 'cuid' Uri-Path MUST NOT be used.
シグナルチャネルセッション設定は、DOTSエージェント間の単一のDOTSシグナルチャネルセッションに適用されるため、'cuid' Uri-Pathを使用してはなりません (MUST NOT)。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "config"
Uri-Path: "sid=123"
Content-Format: "application/dots+cbor"
{
...
}
Figure 21: PUT to Convey the DOTS Signal Channel Session Configuration Data
図21：ドット信号チャネルセッション構成データを伝える
The additional Uri-Path parameter to those defined in Table 1 is as follows:
表1に定義されている追加のURIパスパラメータは次のとおりです。
sid: Session Identifier is an identifier for the DOTS signal channel session configuration data represented as an integer. This identifier MUST be generated by DOTS clients. 'sid' values MUST increase monotonically (when a new PUT is generated by a DOTS client to convey the configuration parameters for the signal channel).
sid: セッション識別子（Session Identifier）は、整数として表されるDOTSシグナルチャネルセッション設定データの識別子です。この識別子はDOTSクライアントによって生成されなければなりません (MUST)。'sid'値は単調に増加しなければなりません (MUST)（シグナルチャネルの設定パラメータを伝達するためにDOTSクライアントによって新しいPUTが生成されるとき）。
This is a mandatory attribute.
これは必須の属性です。
{
"ietf-dots-signal-channel:signal-config": {
"mitigating-config": {
"heartbeat-interval": {
"current-value": number
},
"missing-hb-allowed": {
"current-value": number
},
"probing-rate": {
"current-value": number
},
"max-retransmit": {
"current-value": number
},
"ack-timeout": {
"current-value-decimal": "string"
},
"ack-random-factor": {
"current-value-decimal": "string"
}
},
"idle-config": {
"heartbeat-interval": {
"current-value": number
},
"missing-hb-allowed": {
"current-value": number
},
"probing-rate": {
"current-value": number
},
"max-retransmit": {
"current-value": number
},
"ack-timeout": {
"current-value-decimal": "string"
},
"ack-random-factor": {
"current-value-decimal": "string"
}
}
}
}
Figure 22: PUT to Convey the DOTS Signal Channel Session Configuration Data (Message Body Schema)
図22：ドット信号チャネルセッション構成データを伝えるために置く（メッセージ本文スキーマ）
The meaning of the parameters in the CBOR body (Figure 22) is defined in Section 4.5.1.
CBOR本体（図22）のパラメータの意味はセクション4.5.1で定義されています。
At least one of the attributes 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' MUST be present in the PUT request. Note that 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and 'ack-random-factor', if present, do not need to be provided for both 'mitigating-config' and 'idle-config' in a PUT request. A request does not need to include both 'mitigating-config' and 'idle-config' attributes.
属性'heartbeat-interval'、'missing-hb-allowed'、'probing-rate'、'max-retransmit'、'ack-timeout'、および'ack-random-factor'のうち少なくとも1つがPUT要求に存在しなければなりません (MUST)。'heartbeat-interval'、'missing-hb-allowed'、'probing-rate'、'max-retransmit'、'ack-timeout'、および'ack-random-factor'は、存在する場合でも、PUT要求内で'mitigating-config'と'idle-config'の両方に提供される必要はないことに注意してください。要求には'mitigating-config'と'idle-config'の両方の属性を含める必要はありません。
The PUT request with a higher numeric 'sid' value overrides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric 'sid' value. That is, the configuration parameters that are included in the PUT request with a higher numeric '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.
より大きな数値の'sid'値を持つPUT要求は、より小さな数値の'sid'値を持つPUT要求によってインストールされたDOTSシグナルチャネルセッション設定データを上書きします。すなわち、より大きな数値の'sid'値を持つPUT要求に含まれる設定パラメータが、DOTSサーバーのデフォルトの代わりに使用されます。DOTSクライアントからの'sid'要求の長いリストを保持することを避けるため、より小さな数値の'sid'は自動的に削除されなければならず (MUST)、DOTSサーバーで利用できなくなります。
Figure 23 shows a PUT request example to convey the configuration parameters for the DOTS signal channel. In this example, the heartbeat mechanism is disabled when no mitigation is active, while the heartbeat interval is set to '30' when a mitigation is active.
図23は、ドット信号チャネルの構成パラメータを伝達するためのPUT要求例を示す。この例では、ハートビートメカニズムはアクティブなときにハートビートメカニズムは無効になっていますが、ハートビート間隔は軽減がアクティブであるときに '30'に設定されます。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "config"
Uri-Path: "sid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:signal-config": {
"mitigating-config": {
"heartbeat-interval": {
"current-value": 30
},
"missing-hb-allowed": {
"current-value": 15
},
"probing-rate": {
"current-value": 15
},
"max-retransmit": {
"current-value": 3
},
"ack-timeout": {
"current-value-decimal": "2.00"
},
"ack-random-factor": {
"current-value-decimal": "1.50"
}
},
"idle-config": {
"heartbeat-interval": {
"current-value": 0
},
"max-retransmit": {
"current-value": 3
},
"ack-timeout": {
"current-value-decimal": "2.00"
},
"ack-random-factor": {
"current-value-decimal": "1.50"
}
}
}
}
Figure 23: PUT to Convey the Configuration Parameters
図23：構成パラメータを伝えるために置く
The DOTS server indicates the result of processing the PUT request using CoAP Response Codes:
DOTSサーバーは、CoAP応答コードを使用してPUTリクエストを処理した結果を示します。
* If the request is missing a mandatory attribute, does not include a 'sid' Uri-Path, or contains one or more invalid or unknown parameters, 4.00 (Bad Request) MUST be returned in the response.
* 要求に必須属性が欠落している場合、'sid' Uri-Pathが含まれていない場合、または1つ以上の無効もしくは不明なパラメータが含まれている場合は、応答で4.00 (Bad Request) を返さなければなりません (MUST)。
* If the DOTS server does not find the 'sid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the configuration parameters, then a Response Code 2.01 (Created) MUST be returned in the response.
* DOTSサーバーがPUT要求で伝達された'sid'パラメータ値をその設定データ内に見つけられず、かつDOTSサーバーが設定パラメータを受け入れた場合、応答コード2.01 (Created) が応答で返されなければなりません (MUST)。
* If the DOTS server finds the 'sid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the updated configuration parameters, 2.04 (Changed) MUST be returned in the response.
* DOTSサーバーがPUT要求で伝達された'sid'パラメータ値をその設定データ内で見つけ、かつDOTSサーバーが更新された設定パラメータを受け入れた場合、2.04 (Changed) が応答で返されなければなりません (MUST)。
* If any of the 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max-retransmit', 'target-protocol', 'ack-timeout', and 'ack-random-factor' attribute values are not acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be returned in the response. Upon receipt of this error code, the DOTS client SHOULD retrieve the maximum and minimum attribute values acceptable to the DOTS server (Section 4.5.1).
* 'heartbeat-interval'、'missing-hb-allowed'、'probing-rate'、'max-retransmit'、'target-protocol'、'ack-timeout'、および'ack-random-factor'のいずれかの属性値がDOTSサーバーに受け入れられない場合、4.22 (Unprocessable Entity) が応答で返されなければなりません (MUST)。このエラーコードを受信した際、DOTSクライアントはDOTSサーバーに受け入れ可能な最大および最小の属性値を取得すべきです (SHOULD)（セクション4.5.1）。
The DOTS client may retry and send the PUT request with updated attribute values acceptable to the DOTS server.
ドットクライアントは、ドットサーバに許容できる更新された属性値を更新要求を再試行して送信することができる。
A DOTS client may issue a GET message for 'config' with a 'sid' Uri-Path parameter to retrieve the negotiated configuration. The response does not need to include 'sid' in its message body.
ドットクライアントは、ネゴシエートされた構成を取得するために 'sid' uri-pathパラメータを使用して 'config'のGETメッセージを発行することができます。応答はそのメッセージ本体に「SID」を含める必要はありません。
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 sends. This feature forces the client to retrieve the updated configuration data if a change occurs at the DOTS server side. For example, the new configuration may instruct a DOTS client to cease heartbeats or reduce heartbeat frequency.
DOTSサーバーが送信する設定に有効期間を関連付けるために、DOTSサーバーによってMax-Ageオプション（[RFC7252]のセクション5.10.5）が返されるべきです (SHOULD)。この機能は、DOTSサーバー側で変更が発生した場合にクライアントに更新された設定データを取得させます。例えば、新しい設定はハートビートを停止するか、またはハートビートの頻度を減らすようDOTSクライアントに指示する場合があります。
It is NOT RECOMMENDED to return a Max-Age Option set to 0.
0に設定されたMax-Ageオプションを返すことは推奨されません (NOT RECOMMENDED)。
Returning a Max-Age Option set to 2^(32)-1 is equivalent to associating an infinite lifetime with the configuration.
MAX-AGEオプションを2 ^（32）-1に戻すことは、無限の有効期間を構成に関連付けるのと同じです。
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 retrieve the current and acceptable configuration before the expiry of the value enclosed in the Max-Age Option. This request is considered by the client and the server to be a means to refresh the configuration parameters for the signal channel. When a DDoS attack is active, refresh requests MUST NOT be sent by DOTS clients, and the DOTS server MUST NOT terminate the (D)TLS session after the expiry of the value returned in Max-Age Option.
ゼロ以外の値のMax-AgeオプションがDOTSクライアントによって受信された場合、Max-Ageオプションに含まれる値が満了する前に、現在および許容される設定を取得するために'sid' Uri-Pathパラメータを持つGET要求を発行しなければなりません (MUST)。この要求は、クライアントおよびサーバーによってシグナルチャネルの設定パラメータをリフレッシュするための手段とみなされます。DDoS攻撃がアクティブな場合、リフレッシュ要求はDOTSクライアントによって送信されてはならず (MUST NOT)、DOTSサーバーはMax-Ageオプションで返された値の満了後に(D)TLSセッションを終了してはなりません (MUST NOT)。
If Max-Age Option is not returned in a response, the DOTS client initiates GET requests to refresh the configuration parameters each 60 seconds (Section 5.10.5 of [RFC7252]). To prevent such overload, it is RECOMMENDED that DOTS servers return a Max-Age Option in GET responses. Considerations related to which value to use and how such a value is set are implementation and deployment specific.
Max-Ageオプションが応答で返されない場合、DOTSクライアントは設定パラメータをリフレッシュするために60秒ごとにGET要求を開始します（[RFC7252]のセクション5.10.5）。そのような過負荷を防ぐために、DOTSサーバーがGET応答でMax-Ageオプションを返すことが推奨されます (RECOMMENDED)。どの値を使用するか、およびそのような値がどのように設定されるかに関する考慮事項は、実装および展開に固有です。
If an Observe Option set to 0 is included in the configuration request, the DOTS server sends notifications of any configuration change (Section 4.2 of [RFC7641]).
設定要求に0に設定されている監視オプションが含まれている場合、ドットサーバーは任意の構成変更の通知を送信します（[RFC7641]のセクション4.2）。
If a DOTS server detects that a misbehaving DOTS client does not contact the DOTS server after the expiry of Max-Age to retrieve the signal channel configuration data, it MAY terminate the (D)TLS session. A (D)TLS session is terminated by the receipt of an authenticated message that closes the connection (e.g., a fatal alert (Section 6 of [RFC8446])).
Max-Ageの満了後に不正なDOTSクライアントがシグナルチャネル設定データを取得するためにDOTSサーバーに接触しないことをDOTSサーバーが検出した場合、DOTSサーバーは(D)TLSセッションを終了してもよいです (MAY)。(D)TLSセッションは、接続を閉じる認証済みメッセージ（例えば致命的なアラート（[RFC8446]のセクション6））の受信によって終了します。
A DELETE request is used to delete the installed DOTS signal channel session configuration data (Figure 24).
削除要求は、インストールされているドット信号チャネルセッション構成データを削除するために使用されます（図24）。
Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "config"
Uri-Path: "sid=123"
Figure 24: Delete Configuration
図24：構成の削除
The DOTS server resets the DOTS signal channel session configuration back to the default values and acknowledges a DOTS client's request to remove the DOTS signal channel session configuration using a 2.02 (Deleted) Response Code.
ドットサーバは、ドット信号チャネルセッション構成をデフォルト値にリセットし、2.02（削除済み）応答コードを使用してドット信号チャネルセッション構成を削除するためのドットクライアントの要求を確認します。
Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request to set the configuration parameters to default values. Such a request does not include any 'sid'.
ブートストラップ時または再起動時に、DOTSクライアントは設定パラメータをデフォルト値に設定するためにDELETE要求を送信してもよいです (MAY)。そのような要求には'sid'は含まれません。
Redirected DOTS signaling is discussed in detail in Section 3.2.2 of [RFC8811].
リダイレクトされたドットシグナリングについては、[RFC8811]の3.2.2項で詳細に説明されています。
To redirect a DOTS client to an alternative DOTS server, the DOTS server can return the error Response Code 5.03 (Service Unavailable) 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.
ドットクライアントを別のドットサーバにリダイレクトするには、ドットサーバは、ドットクライアントからの要求に応答してエラーレスポンスコード5.03（サービスが利用できない）を返すか、またはクライアントへの一方向通知応答でエラー応答コード5.03を伝達することができる。
The DOTS server in the error response conveys the alternate DOTS server's FQDN, and the alternate DOTS server's IP address(es) values in the CBOR body (Figure 25).
エラー応答のドットサーバーは、代替ドットサーバーのFQDN、およびCBOBOR本体内の代替ドットサーバーのIPアドレス（ES）値を伝達します（図25）。
{
"ietf-dots-signal-channel:redirected-signal": {
"alt-server": "string",
"alt-server-record": [
"string"
]
}
}
Figure 25: Redirected Server Error Response Body Schema
図25：リダイレクトされたサーバーエラーレスポンスボディスキーマ
The parameters are described below:
パラメータは以下のとおりです。
alt-server: FQDN of an alternate DOTS server.
Alt-Server：代替ドットサーバーのFQDN。
This is a mandatory attribute.
これは必須の属性です。
alt-server-record: A list of IP addresses of an alternate DOTS server.
alt-server-record：代替ドットサーバーのIPアドレスのリスト。
This is an optional attribute.
これはオプションの属性です。
The DOTS server returns the Time to Live (TTL) of the alternate DOTS server in a Max-Age Option. That is, the time interval that the alternate DOTS server may be cached for use by a DOTS client. A Max-Age Option set to 2^(32)-1 is equivalent to receiving an infinite TTL. This value means that the alternate DOTS server is to be used until the alternate DOTS server redirects the traffic with another 5.03 response that conveys an alternate server's FQDN.
DOTSサーバーは、MAX-AGEオプションで代替ドットサーバーのライブ（TTL）までの時間を返します。すなわち、代替ドットサーバがドットクライアントによる使用のためにキャッシュされ得る時間間隔。2 ^（32）-1に設定されている最大エージングオプションは、Infinite TTLを受信するのと同じです。この値は、代替ドットサーバーが別の5.03回答を別の5.03回答にリダイレクトするまで、代替ドットサーバーを使用することを意味します。
A Max-Age Option set to '0' may be returned for redirecting mitigation requests. Such a value means that the redirection applies only for the mitigation request in progress. Returning short TTL in a Max-Age Option may adversely impact DOTS clients on slow links. Returning short values should be avoided under such conditions.
緩和要求をリダイレクトするために、「0」に設定されているMAX-AGEオプションを返すことができます。そのような値は、リダイレクトが進行中の緩和要求に対してのみ適用されることを意味します。マックスエージングオプションで短いTTLを返すと、遅いリンクでドットクライアントに悪影響を及ぼす可能性があります。短い値を返すと、そのような条件下では避けてください。
If the alternate DOTS server TTL has expired, the DOTS client MUST use the DOTS server(s) that was provisioned using means discussed in Section 4.1. This fallback mechanism is triggered immediately upon expiry of the TTL, except when a DDoS attack is active.
代替DOTSサーバーのTTLが満了した場合、DOTSクライアントはセクション4.1で説明された手段を使用してプロビジョニングされたDOTSサーバーを使用しなければなりません (MUST)。このフォールバックメカニズムは、DDoS攻撃がアクティブである場合を除き、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 MAY be rejected by DOTS servers.
Max-Ageオプションで伝達されたTTLを尊重しない、または明示的なリダイレクトメッセージに反応しない不正なDOTSクライアントによって発行された要求は、DOTSサーバーによって拒否されてもよいです (MAY)。
Figure 26 shows a 5.03 response example to convey the DOTS alternate server 'alt-server.example' together with its IP addresses 2001:db8:6401::1 and 2001:db8:6401::2.
図26は、そのIPアドレス2001とともにドット代替サーバの 'Alt-Server.Example'を伝達するための5.03応答例を示しています.DB8：6401 :: 2。
{
"ietf-dots-signal-channel:redirected-signal": {
"alt-server": "alt-server.example",
"alt-server-record": [
"2001:db8:6401::1",
"2001:db8:6401::2"
]
}
}
Figure 26: Example of Redirected Server Error Response Body
図26：リダイレクトされたサーバーエラーレスポンスボディの例
When the DOTS client receives a 5.03 response with an alternate server included, it considers the current request to have failed, but it SHOULD try resending the request to the alternate DOTS server. 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 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 to provide accurate information. The DOTS client can then try to establish a UDP or a TCP session with the alternate DOTS server (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 IPv6-only DOTS client communicates with an IPv4-only alternate DOTS server.
DOTSクライアントが代替サーバーを含む5.03応答を受信した場合、現在の要求は失敗したとみなしますが、代替DOTSサーバーへの要求の再送信を試みるべきです (SHOULD)。DDoS攻撃の間、DNSサーバーが別のDDoS攻撃のターゲットになっている可能性があります。5.03応答で伝達された代替DOTSサーバーのIPアドレスは、正確な情報を提供するために最初のDOTSサーバーを信頼することを犠牲にして、DOTSクライアントが代替DOTSサーバーのDNS検索をスキップするのに役立ちます。DOTSクライアントはその後、代替DOTSサーバーとのUDPまたはTCPセッションの確立を試みることができます（セクション4.3）。元のDOTSサーバーと代替DOTSサーバーの間で状態同期（例えばシグナルセッション設定、エイリアス）が適切に行われていると仮定されていることに注意してください。そのような同期手段はスコープ外です。リダイレクトが適用されている間にセッション設定のリフレッシュが必要な場合、DOTSクライアントはセクション4.5.3で定義されている手順に従います。「アイドル」時間において一定の条件下（例えば無限の設定有効期間、無限のリダイレクトTTL、および設定のリフレッシュの失敗）では、DOTSクライアントは代替サーバーとDOTSシグナルチャネルセッション設定を交渉するためにセクション4.5.2で定義されている手順に従います。DOTSクライアントは、IPv4埋め込みIPv6アドレスを構築する方法を実装してもよいです (MAY)（[RFC6052]）。これは、IPv6専用のDOTSクライアントがIPv4専用の代替DOTSサーバーと通信するシナリオを処理するために必要とされます。
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 ignore the redirection and try to contact other DOTS servers listed in the local configuration or discovered using dynamic means, such as DHCP or SRV procedures [RFC8973]. It is RECOMMENDED that DOTS clients support the means to alert administrators about redirect loops.
DOTSクライアントが過去5分以内に既に通信したことがあるDOTSサーバーにリダイレクトされた場合、そのリダイレクトを無視しなければならず (MUST)、ローカル設定にリストされているか、DHCPやSRV手順などの動的手段を使用して発見された他のDOTSサーバーへの接続を試みなければなりません（[RFC8973]）。DOTSクライアントがリダイレクトループについて管理者に警告する手段をサポートすることが推奨されます (RECOMMENDED)。
To provide an indication of signal health and to distinguish an 'idle' signal channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel (also, aligned with the "consents" recommendation in Section 6 of [RFC8085]). The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and it may consider a session terminated in the prolonged absence of a peer agent heartbeat. Concretely, while the communication between the DOTS agents is otherwise quiescent, the DOTS client will probe the DOTS server to ensure it has maintained cryptographic state and vice versa. Such probes can also keep the bindings of firewalls and/or stateful translators alive. This probing reduces the frequency of establishing a new handshake when a DOTS signal needs to be conveyed to the DOTS server.
信号の正常性の指示を提供し、「IDLE」信号チャネルを「切断」または「DEFUNCT」セッションから区別するために、ドットエージェントはチャネルの半分を維持するためにシグナルチャネル上にハートビートを送信します（また、「RFC8085」のセクション6の推奨事項。ドット剤は同様にそのピアドット剤からの心拍を期待し、そしてそれはピア剤の心拍の長期の非存在下で終結したセッションを考慮することができる。具体的には、ドットエージェント間の通信が静止している間は、ドットクライアントはドットサーバをプローブして暗号化状態を維持し、その逆も同様です。そのようなプローブはまた、ファイアウォールおよび/またはステートフル翻訳者のバインディングを生き続けることもできる。このプロービングは、ドット信号をドットサーバに伝達する必要があるときに、新しいハンドシェイクを確立する頻度を低減する。
| Implementation Note: Given that CoAP roles can be multiplexed over the same session as discussed in [RFC7252] and are already supported by CoAP implementations, both the DOTS client and server can send DOTS heartbeat requests.
| 実装上の注記：CoAPの役割は[RFC7252]で説明されているように同じセッション上で多重化でき、CoAP実装ですでにサポートされているため、DOTSクライアントとサーバーの両方がDOTSハートビート要求を送信できます。
The DOTS heartbeat mechanism uses Non-confirmable PUT requests (Figure 27) with an expected 2.04 (Changed) Response Code (Figure 28). This procedure occurs between a DOTS agent and its immediate peer DOTS agent. As such, this PUT request MUST NOT be relayed by a DOTS gateway. The PUT request used for DOTS heartbeat MUST NOT have a 'cuid', 'cdid', or 'mid' Uri-Path.
DOTSハートビートメカニズムは、空のボディを持つNon-confirmable PUT要求（図25および26）を使用します。この手順はDOTSエージェントとその直接のピアの間で行われます。そのため、このPUT要求はDOTSゲートウェイによって中継されてはなりません (MUST NOT)。DOTSゲートウェイは、バックエンドDOTSサーバーに中継されるセッション内に独自のハートビートを注入してはなりません (MUST NOT)。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "hb"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:heartbeat": {
"peer-hb-status": true
}
}
Figure 27: PUT to Check Peer DOTS Agent Is Responding
図27：ピアトドットのチェックエージェントが応答している
The mandatory 'peer-hb-status' attribute is set to 'true' (or 'false') to indicate that a DOTS agent is (or is not) receiving heartbeat messages from its peer in the last (2 * 'heartbeat-interval') period. Such information can be used by a peer DOTS agent to detect or confirm connectivity issues and react accordingly. For example, if a DOTS client receives a 2.04 response for its heartbeat messages but no server-initiated heartbeat messages, the DOTS client sets 'peer-hb-status' to 'false' in its next heartbeat message. Upon 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 after receiving a client-initiated heartbeat message).
必須の 'peer-hb-status'属性は、最後の（2 * 'ハートビート間隔）のピアからのハートビートメッセージを受信していることを示す（またはそうでない）ことを示すために、' true '（または' false '）に設定されています。'） 期間。そのような情報は、接続の問題を検出または確認し、それに応じて反応するためのピアトドットエージェントによって使用され得る。たとえば、ドットクライアントがそのハートビートメッセージに対して2.04応答を受信したが、サーバが開始したハートビートメッセージがない場合、ドットクライアントは次のハートビートメッセージで 'false'に 'false'を 'peer-hb-status'に設定します。このメッセージを受信すると、ドットサーバは、ハートビートを送信するための別の戦略を試みる必要がある（例えば、ハートビート間隔を調整するか、クライアント開始ハートビートメッセージを受信した直後にサーバ開始ハートビートを送信する）。
Header: (Code=2.04)
ヘッダー:(コード= 2.04）
Figure 28: Response to a DOTS Heartbeat Request (with an Empty Body)
図28：ドットハートビートリクエストへの応答（空の本体付き）
DOTS servers MAY trigger their heartbeat requests immediately after receiving heartbeat probes from peer DOTS clients. It is the responsibility of DOTS clients to ensure that on-path translators/ firewalls are maintaining a binding so that the same external IP address and/or port number is retained for the DOTS signal channel session.
DOTSサーバーは、DOTSシグナルチャネルセッションの確立直後にハートビート要求をトリガーしてもよいです (MAY)。
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 'missing-hb-allowed' number of consecutive heartbeat messages, it concludes that the DOTS signal channel session is disconnected. The DOTS client MUST then try to reestablish the DOTS signal channel session, preferably by resuming the (D)TLS session.
通常のトラフィック条件下（すなわち、攻撃が進行していない場合）、DOTSエージェントはシグナルチャネルセッションの健全性を監視するために'idle-config'（セクション4.5）を使用しなければなりません (MUST)。
Note: If a new DOTS signal channel session cannot be established, the DOTS client SHOULD NOT retry to establish the DOTS signal channel session more frequently than every 300 seconds (5 minutes) and MUST NOT retry more frequently than every 60 seconds (1 minute). It is recommended that DOTS clients support the means to alert administrators about the failure to establish a (D)TLS session.
注意: 攻撃中に新しいDOTSシグナルチャネルセッションを確立できない場合、DOTSクライアントはDOTSシグナルチャネルセッションを切断すべきではありません (SHOULD NOT)。アクティブ終了処理中（active-but-terminating）の緩和が実施されている場合、DOTSクライアントはDOTSシグナルチャネルセッションを切断してはなりません (MUST NOT)。
In case of a massive DDoS attack that saturates the incoming link(s) to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped, although the DOTS server receives heartbeat requests in addition to DOTS messages sent by the DOTS client. In this scenario, DOTS clients MUST behave differently to handle message transmission and DOTS signal channel session liveliness during link saturation:
着信リンクを飽和させる大規模なDDoS攻撃が発生した場合、DOTSサーバーからのすべてのトラフィックがドロップされる可能性があります。例えば、DOTSサーバーはハートビートを受信できず、ハートビート欠落カウンターが増加します。DOTSクライアントは、最大'missing-hb-allowed'閾値に達した後にDOTSサーバーから応答（例えばハートビートまたはCoAP ACK）を受信しない場合、DOTSサーバーを利用不可とみなさなければなりません (MUST)。
The DOTS client MUST NOT consider the DOTS signal channel session terminated even after a maximum 'missing-hb-allowed' threshold is reached. The DOTS client SHOULD keep on using the current DOTS signal channel session to send heartbeat requests over it so that the DOTS server knows the DOTS client has not disconnected the DOTS signal channel session.
DOTSクライアントは、DOTSサーバーがDOTSクライアントのハートビートに応答しない場合であっても、DOTSサーバーからハートビートを受信している限り、DOTSシグナルチャネルセッションが終了したとみなしてはなりません (MUST NOT)。DOTSクライアントは、プロービングレートでDOTSサーバーへのハートビート送信を継続すべきです (SHOULD)。
After the maximum 'missing-hb-allowed' threshold is reached, the DOTS client SHOULD try to establish a new DOTS signal channel session. The DOTS client SHOULD send mitigation requests over the current DOTS signal channel session and, in parallel, send the mitigation requests over the new DOTS signal channel session. This may be handled, for example, by resumption of the (D)TLS session or using 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the ClientHello message.
最大'missing-hb-allowed'閾値に達した後、DOTSサーバーはセッションが切断されたとみなさなければなりません (MUST)。ハートビート要求を停止すべきであり (SHOULD)、(D)TLSセッションを切断すべきです (SHOULD)。DOTSサーバーは、切断されたDOTSシグナルチャネルセッションに関連付けられたアクティブな緩和を処理するために、セクション4.4.1の手順に従います。
As soon as the link is no longer saturated, if traffic from the DOTS server reaches the DOTS client over the current DOTS signal channel session, the DOTS client can stop the new DOTS signal channel session attempt or if a new DOTS signal channel session is successful then disconnect the current DOTS signal channel session.
リンクが飽和しなくなるとすぐに、ドットサーバからのトラフィックが現在のドットシグナルチャネルセッションを介してドットクライアントに達すると、ドットクライアントは新しいドットシグナルチャネルセッションの試みを停止することができ、または新しいドット信号チャネルセッションが成功した場合次に、現在のドット信号チャネルセッションを切断します。
If the DOTS server receives traffic from the peer DOTS client (e.g., peer DOTS client-initiated heartbeats) but the maximum 'missing-hb-allowed' threshold is reached, the DOTS server MUST NOT consider the DOTS signal channel session disconnected. The DOTS server MUST keep on using the current DOTS signal channel session so that the DOTS client can send mitigation requests over the current DOTS signal channel session. In this case, the DOTS server can identify that the DOTS client is under attack and that the inbound link to the DOTS client (domain) is saturated. Furthermore, if the DOTS server does not receive a mitigation request from the DOTS client, it implies that the DOTS client has not detected the attack or, if an attack mitigation is in progress, it implies that the applied DDoS mitigation actions are not yet effectively handling the DDoS attack volume.
ハートビート要求がまだ処理中である間にピアDOTSクライアントからトラフィック（例えばCoAP Ping、クライアントハートビート）を受信した場合、DOTSサーバーはDOTSシグナルチャネルセッションが切断されたとみなしてはなりません (MUST NOT)。DOTSサーバーは'missing-hb-allowed'カウンターをリセットしなければなりません (MUST)。
If the DOTS server does not receive any traffic from the peer DOTS client during the time span required to exhaust the maximum 'missing-hb-allowed' threshold, the DOTS server concludes the session is disconnected. The DOTS server can then trigger preconfigured mitigation requests for this DOTS client (if any).
DOTSサーバーがピアト・クライアントからのトラフィックを受信しない場合、最大 'Missing-Hb-Allow-Allected'さまき値を消費するのに必要な期間中に、DOTSサーバーはセッションが切断されています。ドットサーバーは、このドットクライアントの事前設定された軽減要求をトリガーできます（存在する場合）。
In DOTS over TCP, the sender of a DOTS heartbeat message has to allow up to 'heartbeat-interval' seconds when waiting for a heartbeat reply. When a failure is detected by a DOTS client, it proceeds with the session recovery, following the same approach as the one used for unreliable transports.
TCPを介してドットでは、無数のハートビートメッセージの送信者は、ハートビートの返信を待つときに「ハートビートインターバル」秒を許可する必要があります。障害がドットクライアントによって検出されると、信頼できないトランスポートに使用されるものと同じアプローチに従って、セッションの回復に進みます。
This document defines a YANG module [RFC7950] for DOTS mitigation scope, DOTS signal channel session configuration data, DOTS redirection signaling, and DOTS heartbeats.
このドキュメントでは、ドットの軽減範囲、ドット信号チャネルセッション構成データ、ドットリダイレクトシグナリング、およびドットハートビートのためのYangモジュール[RFC7950]を定義します。
This YANG module is not intended to be used via NETCONF/RESTCONF for DOTS server management purposes; such a module is out of the scope of this document. It serves only to provide abstract data structures. This document uses the "structure" extension specified in [RFC8791].
このYANGモジュールは、ドットサーバー管理目的でNETCONF/RESTCONFを介して使用されることを意図していません。そのようなモジュールはこの文書の範囲外です。それは抽象データ構造を提供するためだけに役立ちます。この資料は[RFC8791]で指定された「構造」拡張子を使用しています。
A companion YANG module is defined to include a collection of types defined by IANA: "iana-dots-signal-channel" (Section 5.2).
コンパニオンYANGモジュールは、IANA：「IANA-DOTS-SIGNAL-SHUNER」（セクション5.2）で定義された型の集まりを含むように定義されています。
This document defines the YANG module "ietf-dots-signal-channel", which has the following tree structure. A DOTS signal message can be a mitigation, a configuration, a redirect, or a heartbeat message.
この文書は、次のツリー構造を持つYANGモジュール「IETF-DOTS-Signal-Channel」を定義します。ドット信号メッセージは、軽減、構成、リダイレクト、またはハートビートメッセージであり得る。
This tree structure obsoletes the one described in Section 5.1 of [RFC8782].
この木構造は[RFC8782]のセクション5.1に記載されているものを廃止します。
module: ietf-dots-signal-channel
モジュール：IETF-dots-signal-channel
structure dots-signal:
+-- (message-type)?
+--:(mitigation-scope)
| +-- scope* []
| +-- target-prefix* inet:ip-prefix
| +-- target-port-range* [lower-port]
| | +-- lower-port inet:port-number
| | +-- upper-port? inet:port-number
| +-- target-protocol* uint8
| +-- target-fqdn* inet:domain-name
| +-- target-uri* inet:uri
| +-- alias-name* string
| +-- lifetime? union
| +-- trigger-mitigation? boolean
| +-- (direction)?
| +--:(server-to-client-only)
| | +-- mid? uint32
| | +-- mitigation-start? uint64
| | +-- status?
| | | iana-dots-signal:status
| | +-- conflict-information
| | | +-- conflict-status?
| | | | iana-dots-signal:conflict-status
| | | +-- conflict-cause?
| | | | iana-dots-signal:conflict-cause
| | | +-- retry-timer? uint32
| | | +-- conflict-scope
| | | +-- target-prefix* inet:ip-prefix
| | | +-- target-port-range* [lower-port]
| | | | +-- lower-port inet:port-number
| | | | +-- upper-port? inet:port-number
| | | +-- target-protocol* uint8
| | | +-- target-fqdn* inet:domain-name
| | | +-- target-uri* inet:uri
| | | +-- alias-name* string
| | | +-- acl-list* [acl-name]
| | | | +-- acl-name leafref
| | | | +-- acl-type? leafref
| | | +-- mid? uint32
| | +-- bytes-dropped?
| | | yang:zero-based-counter64
| | +-- bps-dropped? yang:gauge64
| | +-- pkts-dropped?
| | | yang:zero-based-counter64
| | +-- pps-dropped? yang:gauge64
| +--:(client-to-server-only)
| +-- attack-status?
| iana-dots-signal:attack-status
+--:(signal-config)
| +-- mitigating-config
| | +-- heartbeat-interval
| | | +-- (direction)?
| | | | +--:(server-to-client-only)
| | | | +-- max-value? uint16
| | | | +-- min-value? uint16
| | | +-- current-value? uint16
| | +-- missing-hb-allowed
| | | +-- (direction)?
| | | | +--:(server-to-client-only)
| | | | +-- max-value? uint16
| | | | +-- min-value? uint16
| | | +-- current-value? uint16
| | +-- probing-rate
| | | +-- (direction)?
| | | | +--:(server-to-client-only)
| | | | +-- max-value? uint16
| | | | +-- min-value? uint16
| | | +-- current-value? uint16
| | +-- max-retransmit
| | | +-- (direction)?
| | | | +--:(server-to-client-only)
| | | | +-- max-value? uint16
| | | | +-- min-value? uint16
| | | +-- current-value? uint16
| | +-- ack-timeout
| | | +-- (direction)?
| | | | +--:(server-to-client-only)
| | | | +-- max-value-decimal? decimal64
| | | | +-- min-value-decimal? decimal64
| | | +-- current-value-decimal? decimal64
| | +-- ack-random-factor
| | +-- (direction)?
| | | +--:(server-to-client-only)
| | | +-- max-value-decimal? decimal64
| | | +-- min-value-decimal? decimal64
| | +-- current-value-decimal? decimal64
| +-- idle-config
| +-- heartbeat-interval
| | +-- (direction)?
| | | +--:(server-to-client-only)
| | | +-- max-value? uint16
| | | +-- min-value? uint16
| | +-- current-value? uint16
| +-- missing-hb-allowed
| | +-- (direction)?
| | | +--:(server-to-client-only)
| | | +-- max-value? uint16
| | | +-- min-value? uint16
| | +-- current-value? uint16
| +-- probing-rate
| | +-- (direction)?
| | | +--:(server-to-client-only)
| | | +-- max-value? uint16
| | | +-- min-value? uint16
| | +-- current-value? uint16
| +-- max-retransmit
| | +-- (direction)?
| | | +--:(server-to-client-only)
| | | +-- max-value? uint16
| | | +-- min-value? uint16
| | +-- current-value? uint16
| +-- ack-timeout
| | +-- (direction)?
| | | +--:(server-to-client-only)
| | | +-- max-value-decimal? decimal64
| | | +-- min-value-decimal? decimal64
| | +-- current-value-decimal? decimal64
| +-- ack-random-factor
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+--:(redirected-signal)
| +-- (direction)?
| +--:(server-to-client-only)
| +-- alt-server inet:domain-name
| +-- alt-server-record* inet:ip-address
+--:(heartbeat)
+-- peer-hb-status boolean
This version obsoletes the version described in Section 5.2 of [RFC8782].
このバージョンは[RFC8782]のセクション5.2で説明されているバージョンを廃止します。
<CODE BEGINS> file "iana-dots-signal-channel@2021-09-02.yang"
module iana-dots-signal-channel {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel";
prefix iana-dots-signal;
organization "IANA"; contact "Internet Assigned Numbers Authority
組織「IANA」;インターネット割り当て番号局
Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 <mailto:iana@iana.org>"; description "This module contains a collection of YANG data types defined by IANA and used for DOTS signal channel protocol.
郵便番号：ICANN 12025 Waterfront Drive、Suite 300 Los Angeles、CA 90094-2536アメリカTel：1 310 301 5800 <mailto：iana@iana.org> ";説明"このモジュールには、によって定義されたYangデータ型のコレクションが含まれています。IANAとドット信号チャネルプロトコルに使用されます。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（c）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or 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).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9132; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9132の一部です。完全な法的通知のためのRFC自体を見てください。」
revision 2021-09-02 {
description
"Updated the prefix used for the module.";
reference
"RFC 9132: 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";
}
typedef status {
type enumeration {
enum attack-mitigation-in-progress {
value 1;
description
"Attack mitigation setup is in progress (e.g., changing
the network path to reroute the inbound traffic
to DOTS mitigator).";
}
enum attack-successfully-mitigated {
value 2;
description
"Attack is being successfully mitigated (e.g., traffic
is redirected to a DDoS mitigator and attack
traffic is dropped).";
}
enum attack-stopped {
value 3;
description
"Attack has stopped and the DOTS client can
withdraw the mitigation request.";
}
enum attack-exceeded-capability {
value 4;
description
"Attack has exceeded the mitigation provider
capability.";
}
enum dots-client-withdrawn-mitigation {
value 5;
description
"DOTS client has withdrawn the mitigation
request and the mitigation is active but
terminating.";
}
enum attack-mitigation-terminated {
value 6;
description
"Attack mitigation is now terminated.";
}
enum attack-mitigation-withdrawn {
value 7;
description
"Attack mitigation is withdrawn.";
}
enum attack-mitigation-signal-loss {
value 8;
description
"Attack mitigation will be triggered
for the mitigation request only when
the DOTS signal channel session is lost.";
}
}
description
"Enumeration for status reported by the DOTS server.";
}
typedef conflict-status {
type enumeration {
enum request-inactive-other-active {
value 1;
description
"DOTS server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently inactive
until the conflicts are resolved. Another
mitigation request is active.";
}
enum request-active {
value 2;
description
"DOTS server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently active.";
}
enum all-requests-inactive {
value 3;
description
"DOTS server has detected conflicting mitigation
requests from different DOTS clients. All
conflicting mitigation requests are inactive.";
}
}
description
"Enumeration for conflict status.";
}
typedef conflict-cause {
type enumeration {
enum overlapping-targets {
value 1;
description
"Overlapping targets. conflict-scope provides
more details about the exact conflict.";
}
enum conflict-with-acceptlist {
value 2;
description
"Conflicts with an existing accept-list.
This code is returned when the DDoS mitigation
detects that some of the source addresses/prefixes
listed in the accept-list ACLs are actually
attacking the target.";
}
enum cuid-collision {
value 3;
description
"Conflicts with the cuid used by another
DOTS client.";
}
}
description
"Enumeration for conflict causes.";
}
typedef attack-status {
type enumeration {
enum under-attack {
value 1;
description
"The DOTS client determines that it is still under
attack.";
}
enum attack-successfully-mitigated {
value 2;
description
"The DOTS client determines that the attack is
successfully mitigated.";
}
}
description
"Enumeration for attack status codes.";
}
}
<CODE ENDS>
This version obsoletes the version described in Section 5.3 of [RFC8782].
このバージョンは[RFC8782]のセクション5.3で説明されているバージョンを廃止します。
<CODE BEGINS> file "ietf-dots-signal-channel@2021-09-02.yang"
module ietf-dots-signal-channel {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";
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 9132: 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
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Editor: Jon Shallow
<mailto:supjps-ietf@jpshallow.com>
Author: Konda, Tirumaleswar Reddy.K
<mailto:kondtir@gmail.com>
Author: Prashanth Patil
<mailto:praspati@cisco.com>
Author: Andrew Mortensen
<mailto:amortensen@arbor.net>
Author: Nik Teague <mailto:nteague@ironmountain.co.uk>"; description "This module contains YANG definition for the signaling messages exchanged between a DOTS client and a DOTS server.
著者：Nik Teague <Mailto：Nteague@IronMountain.co.uk> ";説明"このモジュールには、ドットクライアントとドットサーバーとの間で交換されるシグナリングメッセージのYang定義が含まれています。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（c）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or 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).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9132; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9132の一部です。完全な法的通知のためのRFC自体を見てください。」
revision 2021-09-02 { description "Updated revision to comply with RFC 8791.
Revision 2021-09-02 {説明 "RFC 8791に準拠するための改訂の更新。
This version is not backward compatible with the version
published in RFC 8782.";
reference
"RFC 9132: 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";
}
/*
* Groupings
*/
grouping mitigation-scope {
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.
A lifetime of '0' in a mitigation request is an invalid value.
緩和要求の「0」の寿命は無効な値です。
A lifetime of negative one (-1) indicates indefinite lifetime for the mitigation request.
負の命題（-1）の寿命は、緩和要求のための不定寿命を示します。
Lifetime is mandatory in a mitigation request.
緩和要求では、寿命が必須です。
The DOTS server must always indicate the actual lifetime
in the response to an accepted mitigation request and the
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
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 is active. It must not be returned for
a mitigation with 'status' code set to 8.";
}
leaf status {
type iana-dots-signal:status;
description
"Indicates the status of a mitigation request.
It must be included in responses only.
This is a mandatory attribute if a mitigation
request is accepted and processed by the server.";
}
container conflict-information {
description
"Indicates that a conflict is detected.";
leaf conflict-status {
type iana-dots-signal:conflict-status;
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 {
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.
This is a mandatory attribute when a client
performs an efficacy update.";
}
}
}
}
}
grouping config-parameters {
description
"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.";
}
}
container missing-hb-allowed {
description
"Maximum number of missing heartbeats allowed.";
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 missing-hb-allowed value.";
}
leaf min-value {
type uint16;
description
"Minimum acceptable missing-hb-allowed value.";
}
}
}
leaf current-value {
type uint16;
default "15";
description
"Current missing-hb-allowed value.";
}
}
container probing-rate {
description
"The limit for sending Non-confirmable messages with
no response.";
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.";
}
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 {
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 {
description
"Grouping for the redirected signaling.";
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 alt-server {
type inet:domain-name;
mandatory true;
description
"FQDN of an alternate server.";
}
leaf-list alt-server-record {
type inet:ip-address;
description
"List of records for the alternate server.";
}
}
}
}
/*
* DOTS Signal Channel Structure
*/
sx:structure dots-signal { description "Main structure for DOTS signal message.
SX：構造ドット - 信号{DOTS信号のメイン構造物。
A DOTS signal message can be a mitigation, a configuration,
a redirected, or a heartbeat signal message.";
choice message-type {
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>
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 key to save space.
DOTSシグナルチャネルのペイロード内のすべてのパラメータは、表5のCBORマップキーを使用してCBOR型にマッピングされなければなりません (MUST)。
Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the content of Table 5. For example, some CBOR and JSON types for enumerations and the 64-bit quantities can differ depending on the encoder used.
注意：実装者は、Yang-To-CBORエンコード方式によって提供されたマッピング出力が表5の内容と揃っていることを確認する必要があります。たとえば、列挙のためのCBORとJSONタイプと64ビット数量はエンコーダによって異なる可能性があることを確認する必要があります。中古。
The CBOR key values are divided into two types: comprehension-required and comprehension-optional. DOTS agents can safely ignore comprehension-optional values they don't understand, but they cannot successfully process a request if it contains comprehension-required values that are not understood. The 4.00 response SHOULD include a diagnostic payload describing the unknown comprehension-required CBOR key values. The initial set of CBOR key values defined in this specification are of type comprehension-required.
CBORキー値は、包括的（comprehensive）とコンパクト（compact）の2つのタイプに分けられます。「アイドル」シグナルチャネル設定が有効な場合は包括的キー値を使用すべきであり (SHOULD)、攻撃中（すなわち'mitigating-config'が使用されている間）はコンパクトキー値を使用すべきです。
+=====================+==============+======+=============+========+
| Parameter Name | YANG Type | CBOR | CBOR Major | JSON |
| | | Key | Type & | Type |
| | | | Information | |
+=====================+==============+======+=============+========+
| ietf-dots-signal- | container | 1 | 5 map | Object |
| channel:mitigation- | | | | |
| scope | | | | |
+---------------------+--------------+------+-------------+--------+
| scope | list | 2 | 4 array | Array |
+---------------------+--------------+------+-------------+--------+
| cdid | string | 3 | 3 text | String |
| | | | string | |
+---------------------+--------------+------+-------------+--------+
| cuid | string | 4 | 3 text | String |
| | | | string | |
+---------------------+--------------+------+-------------+--------+
| mid | uint32 | 5 | 0 unsigned | Number |
+---------------------+--------------+------+-------------+--------+
| target-prefix | leaf-list | 6 | 4 array | Array |
| +--------------+------+-------------+--------+
| | inet:ip- | | 3 text | String |
| | prefix | | string | |
+---------------------+--------------+------+-------------+--------+
| target-port-range | list | 7 | 4 array | Array |
+---------------------+--------------+------+-------------+--------+
| lower-port | inet:port- | 8 | 0 unsigned | Number |
| | number | | | |
+---------------------+--------------+------+-------------+--------+
| upper-port | inet:port- | 9 | 0 unsigned | Number |
| | number | | | |
+---------------------+--------------+------+-------------+--------+
| target-protocol | leaf-list | 10 | 4 array | Array |
| +--------------+------+-------------+--------+
| | uint8 | | 0 unsigned | Number |
+---------------------+--------------+------+-------------+--------+
| target-fqdn | leaf-list | 11 | 4 array | Array |
| +--------------+------+-------------+--------+
| | inet:domain- | | 3 text | String |
| | name | | string | |
+---------------------+--------------+------+-------------+--------+
| target-uri | leaf-list | 12 | 4 array | Array |
| +--------------+------+-------------+--------+
| | inet:uri | | 3 text | String |
| | | | string | |
+---------------------+--------------+------+-------------+--------+
| alias-name | leaf-list | 13 | 4 array | Array |
| +--------------+------+-------------+--------+
| | string | | 3 text | String |
| | | | string | |
+---------------------+--------------+------+-------------+--------+
| lifetime | union | 14 | 0 unsigned | Number |
| | | +-------------+--------+
| | | | 1 negative | Number |
+---------------------+--------------+------+-------------+--------+
| mitigation-start | uint64 | 15 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| status | enumeration | 16 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| conflict- | container | 17 | 5 map | Object |
| information | | | | |
+---------------------+--------------+------+-------------+--------+
| conflict-status | enumeration | 18 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| conflict-cause | enumeration | 19 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| retry-timer | uint32 | 20 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| conflict-scope | container | 21 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| acl-list | list | 22 | 4 array | Array |
+---------------------+--------------+------+-------------+--------+
| acl-name | leafref | 23 | 3 text | String |
| | | | string | |
+---------------------+--------------+------+-------------+--------+
| acl-type | leafref | 24 | 3 text | String |
| | | | string | |
+---------------------+--------------+------+-------------+--------+
| bytes-dropped | yang:zero- | 25 | 0 unsigned | String |
| | based- | | | |
| | counter64 | | | |
+---------------------+--------------+------+-------------+--------+
| bps-dropped | yang:gauge64 | 26 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| pkts-dropped | yang:zero- | 27 | 0 unsigned | String |
| | based- | | | |
| | counter64 | | | |
+---------------------+--------------+------+-------------+--------+
| pps-dropped | yang:gauge64 | 28 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| attack-status | enumeration | 29 | 0 unsigned | String |
+---------------------+--------------+------+-------------+--------+
| ietf-dots-signal- | container | 30 | 5 map | Object |
| channel:signal- | | | | |
| config | | | | |
+---------------------+--------------+------+-------------+--------+
| sid | uint32 | 31 | 0 unsigned | Number |
+---------------------+--------------+------+-------------+--------+
| mitigating-config | container | 32 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| heartbeat-interval | container | 33 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| max-value | uint16 | 34 | 0 unsigned | Number |
+---------------------+--------------+------+-------------+--------+
| min-value | uint16 | 35 | 0 unsigned | Number |
+---------------------+--------------+------+-------------+--------+
| current-value | uint16 | 36 | 0 unsigned | Number |
+---------------------+--------------+------+-------------+--------+
| missing-hb-allowed | container | 37 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| max-retransmit | container | 38 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| ack-timeout | container | 39 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| ack-random-factor | container | 40 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| max-value-decimal | decimal64 | 41 | 6 tag 4 | String |
| | | | [-2, | |
| | | | integer] | |
+---------------------+--------------+------+-------------+--------+
| min-value-decimal | decimal64 | 42 | 6 tag 4 | String |
| | | | [-2, | |
| | | | integer] | |
+---------------------+--------------+------+-------------+--------+
| current-value- | decimal64 | 43 | 6 tag 4 | String |
| decimal | | | [-2, | |
| | | | integer] | |
+---------------------+--------------+------+-------------+--------+
| idle-config | container | 44 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| trigger-mitigation | boolean | 45 | 7 bits 20 | False |
| | | +-------------+--------+
| | | | 7 bits 21 | True |
+---------------------+--------------+------+-------------+--------+
| ietf-dots-signal- | container | 46 | 5 map | Object |
| channel:redirected- | | | | |
| signal | | | | |
+---------------------+--------------+------+-------------+--------+
| alt-server | inet:domain- | 47 | 3 text | String |
| | name | | string | |
+---------------------+--------------+------+-------------+--------+
| alt-server-record | leaf-list | 48 | 4 array | Array |
| +--------------+------+-------------+--------+
| | inet:ip- | | 3 text | String |
| | address | | string | |
+---------------------+--------------+------+-------------+--------+
| ietf-dots-signal- | container | 49 | 5 map | Object |
| channel:heartbeat | | | | |
+---------------------+--------------+------+-------------+--------+
| probing-rate | container | 50 | 5 map | Object |
+---------------------+--------------+------+-------------+--------+
| peer-hb-status | boolean | 51 | 7 bits 20 | False |
| | | +-------------+--------+
| | | | 7 bits 21 | True |
+---------------------+--------------+------+-------------+--------+
Table 5: CBOR Key Values Used in DOTS Signal Channel Messages & Their Mappings to JSON and YANG
表5：ドット信号チャネルメッセージとJSONとYANGへのマッピングで使用されるCBORキー値
This section defines the (D)TLS protocol profile of DOTS signal channel over (D)TLS and DOTS data channel over TLS.
このセクションでは、DOTS信号チャネルの（D）TLSプロトコルプロファイルを（D）TLSおよびDOTSデータチャネルを介してTLSを定義します。
There are known attacks on (D)TLS, such as man-in-the-middle and protocol downgrade attacks. These are general attacks on (D)TLS and, as such, they are not specific to DOTS over (D)TLS; refer to the (D)TLS RFCs for discussion of these security issues. DOTS agents MUST adhere to the (D)TLS implementation recommendations and security considerations of [RFC7525] except with respect to (D)TLS version. Because DOTS signal channel encryption relying upon (D)TLS is virtually a greenfield deployment, DOTS agents MUST implement only (D)TLS 1.2 or later.
中間者攻撃、暗号スイートのダウングレード、セッションハイジャックなど、(D)TLSに対する既知の攻撃が存在します。さらに、すべてのTCPおよびUDPの脆弱性を悪用して(D)TLS接続でDoSを引き起こすことができます。DOTSエージェントは、[RFC7525]またはその改訂版で概説されている適切な(D)TLSプラクティスに準拠しなければなりません (MUST)。DOTSエージェントは、DOTSシグナルチャネルメッセージを交換する前にそのピアを認証しなければなりません (MUST)。
When a DOTS client is configured with a domain name of the DOTS server, and it connects to its configured DOTS server, the server may present it with a PKIX certificate. In order to ensure proper authentication, a DOTS client MUST verify the entire certification path per [RFC5280]. Additionally, the DOTS client MUST use [RFC6125] validation techniques to compare the domain name with the certificate provided. Certification authorities that issue DOTS server certificates SHOULD support the DNS-ID and SRV-ID identifier types. DOTS servers SHOULD prefer the use of DNS-ID and SRV-ID over Common Name ID (CN-ID) identifier types in certificate requests (as described in Section 2.3 of [RFC6125]), and the wildcard character '*' SHOULD NOT be included in the presented identifier. DOTS doesn't use URI-IDs for server identity verification.
DOTSクライアントがDOTSサーバーのドメイン名で設定されており、設定されたDOTSサーバーに接続されている場合、サーバーはPKIX証明書を提示できます。適切な認証を確実にするために、DOTSクライアントは[RFC5280]に従って証明書パス全体を検証しなければなりません (MUST)。さらに、DOTSクライアントは提示された証明書とドメイン名を比較するために[RFC6125]の検証技術を使用しなければなりません (MUST)。DOTSサーバー証明書を発行する認証局は、DNS-IDおよびSRV-ID識別子タイプをサポートすべきです (SHOULD)。DOTSサーバーは、証明書要求においてCommon Name ID（CN-ID）識別子タイプよりもDNS-IDおよびSRV-IDの使用を優先すべきであり (SHOULD)（[RFC6125]のセクション2.3）、提示される識別子にワイルドカード文字'*'を含めるべきではありません (SHOULD NOT)。DOTSはサーバーの同一性検証にURI-IDを使用しません。
A key challenge to deploying DOTS is the provisioning of DOTS clients, including the distribution of keying material to DOTS clients to enable the required mutual authentication of DOTS agents. Enrollment over Secure Transport (EST) [RFC7030] defines a method of certificate enrollment by which domains operating DOTS servers may provide DOTS clients with all the necessary cryptographic keying material, including a private key and a certificate, to authenticate themselves. One deployment option is to have DOTS clients behave as EST clients for certificate enrollment from an EST server provisioned by the mitigation provider. This document does not specify which EST or other mechanism the DOTS client uses to achieve initial enrollment.
ドットを展開するための重要な課題は、ドット・エージェントの要求された相互認証を可能にするために、ドットクライアントへのキーイング資料の分布を含むドットクライアントのプロビジョニングです。Secure Transport（EST）の登録（RFC7030]は、自分自身を認証するために、秘密鍵と証明書を含むすべての必要な暗号キーイング材料をドットクライアントを提供することができるドレス登録の方法を定義します。1つの展開オプションは、ドットクライアントが軽減プロバイダによってプロビジョニングされたESTサーバーからの証明書登録のESTクライアントとして行動することです。この文書では、DOTSクライアントが最初の登録を達成するために使用するどのESTまたは他のメカニズムを指定していません。
The Server Name Indication (SNI) extension [RFC6066] defines a mechanism for a client to tell a (D)TLS server the name of the server it wants to contact. This is a useful extension for hosting environments where multiple virtual servers are reachable over a single IP address. The DOTS client may or may not know if it is interacting with a DOTS server in a virtual server-hosting environment, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extension.
サーバー名表示（SNI）拡張[RFC6066]は、クライアントが(D)TLSサーバーに対して接続を希望するサーバーの名前を伝えるためのメカニズムを定義します。これは、単一のIPアドレスを介して複数の仮想サーバーに到達可能なホスティング環境にとって有用な拡張です。DOTSクライアントは、仮想サーバーホスティング環境内のDOTSサーバーと対話しているかどうかを知らない可能性があるため、DOTSクライアントはSNI拡張にDOTSサーバーのFQDNを含めるべきです (SHOULD)。
Implementations compliant with this profile MUST implement all of the following items:
このプロファイルに準拠した実装は、以下のすべての項目を実装しなければなりません (MUST) :
* DTLS record replay detection (Section 3.3 of [RFC6347]) or an equivalent mechanism to protect against replay attacks.
* DTLSレコードの再生検出（[RFC6347]のセクション3.3）または再生攻撃から保護する等価なメカニズム。
* DTLS session resumption without server-side state to resume session and convey the DOTS signal.
* セッションを再開してドット信号を伝達するためのサーバー側の状態なしのDTLSセッション再開。
Implementations compliant with this profile SHOULD implement all of the following items to reduce the delay required to deliver a DOTS signal channel message:
このプロファイルに準拠した実装は、DOTSシグナルチャネルメッセージを配信するために必要な遅延を低減するために、以下のすべての項目を実装すべきです (SHOULD) :
* TLS False Start [RFC7918], which reduces round trips by allowing the TLS client's second flight of messages (ChangeCipherSpec) to also contain the DOTS signal. TLS False Start is formally defined for use with TLS, but the same technique is applicable to DTLS as well.
* TLS false start [RFC7918]。これは、TLSクライアントのメッセージ（ChangeCipherSpec）の2つのフライトを許可することで、ドット信号も含まれていることを許可します。TLS False StartはTLSで使用するために正式に定義されていますが、同じ手法もDTLSにも適用されます。
* Cached Information Extension [RFC7924], which avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake.
* キャッシュされた情報拡張[RFC7924]。クライアントが以前のTLSハンドシェイクからその情報をキャッシュした場合は、サーバーの証明書と証明書チェーンの送信を回避します。
Compared to UDP, DOTS signal channel over TCP requires an additional round-trip time (RTT) of latency to establish a TCP connection. DOTS implementations are encouraged to implement TCP Fast Open [RFC7413] to eliminate that RTT.
UDPと比較して、TCPを介したドット信号チャネルには、TCP接続を確立するためのレイテンシの追加の往復時間（RTT）が必要です。ドットの実装は、そのRTTを排除するためにTCP Fast Open [RFC7413]を実装することをお勧めします。
TLS 1.3 provides useful latency improvements for connection establishment over TLS 1.2. The DTLS 1.3 protocol [TLS-DTLS13] is based upon the TLS 1.3 protocol and provides equivalent security guarantees. (D)TLS 1.3 provides two basic handshake modes the DOTS signal channel can take advantage of:
TLS 1.3は、TLS 1.2よりも接続確立のための有用な待ち時間の改善を提供します。DTLS 1.3プロトコル[TLS-DTLS13]はTLS 1.3プロトコルに基づいており、同等のセキュリティ保証を提供します。（d）TLS 1.3は2つの基本ハンドシェイクモードを提供しますDOTS信号チャネルは次のことを利用できます。
* A full handshake mode in which a DOTS client can send a DOTS mitigation request message after one round trip and the DOTS server immediately responds with a DOTS mitigation response. This assumes no packet loss is experienced.
* 一回のラウンドトリップ後にドットクライアントがドット軽減要求メッセージを送信できるフルハンドシェイクモードであり、ドットサーバは直ちにドット軽減応答で応答する。これはパケット損失が経験されていないと仮定しています。
* 0-RTT mode in which the DOTS client can authenticate itself and send DOTS mitigation request messages in the first message, thus reducing handshake latency. 0-RTT only works if the DOTS client has previously communicated with that DOTS server, which is very likely with the DOTS signal channel.
* DOTSクライアントが自分自身を認証し、最初のメッセージにドットの軽減要求メッセージを送信できる0-RTTモードで、ハンドシェイクの待ち時間が低下します。0-RTTは、ドット・シグナルチャネルで非常に高いそのドット・サーバーと以前に伝達された場合にのみ機能します。
The DOTS client has to establish a (D)TLS session with the DOTS server during 'idle' time and share a PSK.
ドットクライアントは、「アイドル」時間中にドットサーバーと（D）TLSセッションを確立し、PSKを共有する必要があります。
During a DDoS attack, the DOTS client can use the (D)TLS session to convey the DOTS mitigation request message and, if there is no response from the server after multiple retries, the DOTS client can resume the (D)TLS session in 0-RTT mode using PSK.
DDoS攻撃の間、ドットクライアントは（D）TLSセッションを使用してドットの軽減要求メッセージを伝達することができ、複数の再試行後にサーバーからの応答がない場合、ドットクライアントは0で（D）TLSセッションを再開できます。PSKを使用した-RTTモード。
DOTS servers that support (D)TLS 1.3 MAY allow DOTS clients to send early data (0-RTT). DOTS clients MUST NOT send "CoAP Ping" as early data; such messages MUST be rejected by DOTS servers. Section 8 of [RFC8446] discusses some mechanisms to implement in order to limit the impact of replay attacks on 0-RTT data. If the DOTS server accepts 0-RTT, it MUST implement one of these mechanisms to prevent replay at the TLS layer. A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest.
(D)TLS 1.3をサポートするDOTSサーバーは、DOTSクライアントが早期データ（0-RTT）を送信することを許可してもよいです (MAY)。DOTSクライアントは早期データとして「CoAP Ping」を送信してはならず (MUST NOT)、そのようなメッセージはDOTSサーバーによって拒否されなければなりません (MUST)。[RFC8446]のセクション8では、0-RTTデータに対するリプレイ攻撃の影響を制限するために実装するいくつかのメカニズムについて説明しています。DOTSサーバーが0-RTTを受け入れる場合、TLS層でのリプレイを防止するためにこれらのメカニズムの1つを実装しなければなりません (MUST)。DOTSサーバーは、TLS HelloRetryRequestを送信することによって0-RTTを拒否できます。
The DOTS signal channel messages sent as early data by the DOTS client are idempotent requests. As a reminder, the Message ID (Section 3 of [RFC7252]) is changed each time a new CoAP request is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized in each CoAP request. The DOTS server(s) MUST use the Message ID and the Token in the DOTS signal channel message to detect replay of early data at the application layer and accept 0-RTT data at most once from the same DOTS client. This anti-replay defense requires sharing the Message ID and the Token in the 0-RTT data between DOTS servers in the DOTS server domain. DOTS servers do not rely on transport coordinates to identify DOTS peers. As specified in Section 4.4.1, DOTS servers couple the DOTS signal channel sessions using the DOTS client identity and optionally the 'cdid' parameter value. Furthermore, the 'mid' value is monotonically increased by the DOTS client for each mitigation request, thus attackers that replay mitigation requests with lower numeric 'mid' values and overlapping scopes with mitigation requests having higher numeric 'mid' values will be rejected systematically by the DOTS server. Likewise, the 'sid' value is monotonically increased by the DOTS client for each configuration request (Section 4.5.2); attackers replaying configuration requests with lower numeric 'sid' values will be rejected by the DOTS server if it maintains a higher numeric 'sid' value for this DOTS client.
DOTSクライアントによって早期データとして送信されるDOTSシグナルチャネルメッセージは、冪等（idempotent）な要求です。念のため、新しいCoAP要求が送信されるたびにメッセージID（[RFC7252]のセクション3）が変更され、各CoAP要求でトークン（[RFC7252]のセクション5.3.1）がランダム化されます。DOTSサーバーは、アプリケーション層での早期データのリプレイを検出し、同じDOTSクライアントからの0-RTTデータを最大1回受け入れるために、DOTSシグナルチャネルメッセージ内のメッセージIDとトークンを使用しなければなりません (MUST)。このアンチリプレイ防御には、DOTSサーバードメイン内のDOTSサーバー間で0-RTTデータ内のメッセージIDとトークンを共有することが必要です。DOTSサーバーはDOTSピアを識別するためにトランスポート座標に依存しません。セクション4.4.1で指定されているように、DOTSサーバーはDOTSクライアントIDおよびオプションで'cdid'パラメータ値を使用してDOTSシグナルチャネルセッションを結びつけます。さらに、'mid'値は各緩和要求についてDOTSクライアントによって単調に増加するため、より小さな数値の'mid'値を持ち、より大きな数値の'mid'値を持つ緩和要求と重複するスコープを持つ緩和要求をリプレイする攻撃者は、DOTSサーバーによって体系的に拒否されます。同様に、'sid'値は各設定要求についてDOTSクライアントによって単調に増加します（セクション4.5.2）。このDOTSクライアントに対してより大きな数値の'sid'値を保持している場合、より小さな数値の'sid'値を持つ設定要求をリプレイする攻撃者はDOTSサーバーによって拒否されます。
Owing to the aforementioned protections, all DOTS signal channel requests are safe to transmit in TLS 1.3 as early data. Refer to [DOTS-EARLYDATA] for more details.
前述の保護のために、すべてのドット信号チャネル要求は、早期データとしてTLS 1.3で送信して安全です。詳細については[DOTS-ELISTDATA]を参照してください。
A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request message exchange is shown in Figure 29.
0-RTTのドットの緩和要求メッセージ交換を備えた簡易TLS 1.3ハンドシェイクを図29に示します。
DOTS Client DOTS Server
ドットクライアントドットサーバー
ClientHello
(0-RTT DOTS signal message)
-------->
ServerHello
{EncryptedExtensions}
{Finished}
<-------- [DOTS signal message]
(end_of_early_data)
{Finished} -------->
[DOTS signal message] <-------> [DOTS signal message]
Note that: () Indicates messages protected 0-RTT keys {} Indicates messages protected using handshake keys [] Indicates messages protected using 1-RTT keys
：（）は、Protected 0-RTTキー{}を示し、ハンドシェイクキーを使用して保護されたメッセージを示します。[] 1-RTTキーを使用して保護されたメッセージを示します。
Figure 29: A Simplified TLS 1.3 Handshake with 0-RTT
図29：0-RTTで簡易TLS 1.3ハンドシェイク
To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, the DLTS records need to fit within a single datagram [RFC6347]. DTLS handles fragmentation and reassembly only for handshake messages and not for the application data (Section 4.1.1 of [RFC6347]). If the Path MTU (PMTU) cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater, as specified in [RFC8200]. If IPv4 support on legacy or otherwise unusual networks is a consideration and the PMTU is unknown, DOTS implementations MAY assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of [RFC1122]).
DOTSシグナルメッセージの断片化とそれに伴うメッセージ配信確率の低下を避けるため、DTLSレコードは単一のデータグラム内に収まらなければなりません (MUST)（[RFC6347]）。DTLSはハンドシェイクメッセージに対してのみ断片化と再構成を処理し、アプリケーションデータに対しては処理しません（[RFC6347]のセクション4.1.1）。パスMTU（PMTU）が検出できない場合、[RFC8200]で指定されているようにインターネット内のすべてのリンクが1280オクテット以上のMTUを持つ必要があるため、DOTSエージェントはIPv6に対して1280バイトのPMTUを想定しなければなりません (MUST)。レガシーまたは特殊なネットワーク上のIPv4のサポートが考慮され、PMTUが不明である場合、DOTS実装はIPv4データグラムに対して576バイトのPMTUを想定してもよいです (MAY)（[RFC1122]のセクション3.3.3）。
The DOTS client must consider the amount of record expansion expected by the DTLS processing when calculating the size of the CoAP message that fits within the PMTU. The PMTU MUST be greater than or equal to [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication overhead of the negotiated DTLS cipher suite + block padding] (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 separate messages; for example, the list of addresses in the 'target-prefix' parameter could be split into multiple lists and each list conveyed in a new PUT request.
DOTSクライアントは、PMTU内に収まるCoAPメッセージのサイズを計算する際、DTLS処理によって予想されるレコード拡張の量を考慮しなければなりません。PMTUは、[CoAPメッセージサイズ + 13オクテットのDTLS 1.2オーバーヘッド + 交渉されたDTLS暗号スイートの認証オーバーヘッド + ブロックパディング] 以上でなければなりません (MUST)（[RFC6347]のセクション4.1.1.1）。要求の合計サイズがPMTUを超える場合、DOTSクライアントはDOTSシグナルを別々のメッセージに分割しなければなりません (MUST)。例えば、'target-prefix'パラメータのアドレスのリストを複数のリストに分割し、各リストを新しいPUT要求で伝達することができます。
| Implementation Note: DOTS choice of message size parameters works well with IPv6 and with most of today's IPv4 paths. However, with IPv4, it is harder to safely make sure that there is no IP fragmentation. If the IPv4 PMTU is unknown, implementations may want to limit themselves to more conservative IPv4 datagram sizes, such as 576 bytes, per [RFC0791].
| 実装上の注記：DOTSのメッセージサイズパラメーターの選択は、IPv6および現在の大部分のIPv4経路で適切に機能します。ただしIPv4では、IPフラグメンテーションが発生しないことを安全に確認するのが難しくなります。IPv4 PMTUが不明な場合、実装は[RFC0791]に従い、576バイトなど、より保守的なIPv4データグラムサイズに制限するとよいでしょう。
(D)TLS based upon client certificates can be used for mutual authentication between DOTS agents. If, for example, a DOTS gateway is involved, DOTS clients and DOTS gateways must perform mutual authentication; only authorized DOTS clients are allowed to send DOTS signals to a DOTS gateway. The DOTS gateway and the DOTS server must perform mutual authentication; a DOTS server only allows DOTS signal channel messages from an authorized DOTS gateway, thereby creating a two-link chain of transitive authentication between the DOTS client and the DOTS server.
（d）クライアント証明書に基づくTLSは、ドットエージェント間の相互認証に使用できます。たとえば、ドットゲートウェイが関係している場合、ドットクライアントとドットゲートウェイは相互認証を実行しなければなりません。許可されたドットクライアントのみがドット信号をドットゲートウェイに送信することを許可されています。ドットゲートウェイとドットサーバーは相互認証を実行する必要があります。ドットサーバは、許可されたドットゲートウェイからのドット信号チャネルメッセージのみを可能にし、それによってドットクライアントとドットサーバとの間の2リンクチェーンの推移認証を作成する。
The DOTS server should support certificate-based client authentication. The DOTS client should respond to the DOTS server's TLS CertificateRequest message with the PKIX certificate held by the DOTS client. DOTS client certificate validation must be performed per [RFC5280], and the DOTS client certificate must conform to the [RFC5280] certificate profile. If a DOTS client does not support TLS client certificate authentication, it must support client authentication based on pre-shared key or raw public key.
+---------------------------------------------+
| example.com domain +---------+ |
| | AAA | |
| +---------------+ | Server | |
| | Application | +------+--+ |
| | server +<---------------+ ^ |
| | (DOTS client) | | | |
| +---------------+ | | |
| V V | example.net domain
| +-----+----+--+ | +---------------+
| +--------------+ | | | | |
| | Guest +<----x---->+ DOTS +<----->+ DOTS |
| | (DOTS client)| | gateway | | | server |
| +--------------+ | | | | |
| +----+--------+ | +---------------+
| ^ |
| | |
| +----------------+ | |
| | DDoS detector | | |
| | (DOTS client) +<-------------+ |
| +----------------+ |
+---------------------------------------------+
Figure 30: Example of Authentication and Authorization of DOTS Agents
図30：ドットエージェントの認証と承認の例
In the example depicted in Figure 30, the DOTS gateway and DOTS clients within the 'example.com' domain proceed with mutual authentication. After the DOTS gateway validates the identity of a DOTS client, it communicates with the Authentication, Authorization, and Accounting (AAA) server in the 'example.com' domain to determine if the DOTS client is authorized to request DDoS mitigation. If the DOTS client is not authorized, a 4.01 (Unauthorized) is returned in the response to the DOTS client. In this example, the DOTS gateway only allows the application server and DDoS attack detector to request DDoS mitigation, but does not permit the user of type 'guest' to request DDoS mitigation.
図30に示す例では、「example.com」ドメイン内のドットゲートウェイおよびドットクライアントは、相互認証を続行します。ドットゲートウェイがドットクライアントのIDを検証した後、DOTSクライアントがDDOの軽減を要求する権限があるかどうかを判断するために、「example.com」ドメインの認証、許可、およびアカウンティング（AAA）サーバと通信します。ドットクライアントが許可されていない場合は、ドットクライアントへの応答に4.01（不正）が返されます。この例では、ドットゲートウェイはアプリケーションサーバーとDDOS攻撃検出器のみをDDOSの軽減を要求するだけですが、「ゲスト」のタイプのユーザーはDDOの軽減を要求することを許可しません。
Also, DOTS gateways and servers located in different domains must perform mutual authentication (e.g., using certificates). A DOTS server will only allow a DOTS gateway with a certificate for a particular domain to request mitigation for that domain. In reference to Figure 30, the DOTS server only allows the DOTS gateway to request mitigation for the 'example.com' domain and not for other domains.
また、異なるドメインに配置されたドットゲートウェイやサーバーは、相互認証（例えば、証明書を使用）を実行する必要があります。ドットサーバーは、特定のドメインの証明書を持つドットゲートウェイだけでそのドメインの軽減を要求します。図30を参照して、ドットサーバは、ドットゲートウェイが他のドメインではなく「example.com」ドメインの軽減を要求するだけです。
This section is a summary of the Error Code responses that can be returned by a DOTS server. These error responses must contain a CoAP 4.xx or 5.xx Response Code.
このセクションは、ドットサーバーによって返されることができるエラーコードの応答の概要です。これらのエラー応答には、COAAP 4.xxまたは5.xxの応答コードが含まれている必要があります。
In general, there may be an additional plain text diagnostic payload (Section 5.5.2 of [RFC7252]) to help troubleshooting in the body of the response unless detailed otherwise.
一般に、詳しくは、詳細な別の方法では、レスポンスの本文でのトラブルシューティングを手助けするために、追加のプレーンテキスト診断ペイロード（[RFC7252]のセクション5.5.2）があります。
Errors returned by a DOTS server can be broken into two categories: those associated with CoAP itself and those generated during the validation of the provided data by the DOTS server.
ドットサーバーによって返されるエラーは、CoAP自体に関連付けられているものと、ドットサーバーによって提供されたデータの検証中に生成されたものの2つのカテゴリに分割できます。
The following is a list of common CoAP errors that are implemented by DOTS servers. This list is not exhaustive; other errors defined by CoAP and associated RFCs may be applicable.
以下は、ドットサーバーによって実装されている一般的なCoAPエラーのリストです。このリストは網羅的なものではありません。CoAPおよび関連するRFCによって定義された他のエラーが適用可能であり得る。
4.00 (Bad Request) is returned by the DOTS server when the DOTS client has sent a request that violates the DOTS protocol (Section 4).
4.00 ドットクライアントがドットプロトコルに違反した要求を送信したときに、（不良要求）がドットサーバーによって返されます（セクション4）。
4.01 (Unauthorized) is returned by the DOTS server when the DOTS client is not authorized to access the DOTS server (Section 4).
4.01 ドットクライアントがドットサーバにアクセスする権限がない場合（不正）はドットサーバによって返される（セクション4）。
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].
4.02 （BADオプション）CoAPレイヤ[RFC7252]によって1つ以上のCoAPオプションが不明であるか不正行為されている場合は、ドットサーバーによって返されます。
4.04 (Not Found) is returned by the DOTS server when the DOTS client is requesting a 'mid' or 'sid' that is not valid (Section 4).
4.04 DOTSクライアントが有効でない「MID」または「SID」を要求しているときに、DOTSサーバーによって返されます（セクション4）。
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 is not supported by the DOTS server [RFC7252].
4.05 （方法は許可されていない方法）は、ドットクライアントがドットサーバでサポートされていない方法（RFC7252]でリソースを要求しているときにドットサーバによって返される。
4.08 (Request Entity Incomplete) is returned by the DOTS server if one or multiple blocks of a block transfer request is missing [RFC7959].
4.08 （要求エンティティは不完全な）ブロック転送要求の1つまたは複数のブロックがない場合は、ドットサーバーによって返されます[RFC7959]。
4.09 (Conflict) is returned by the DOTS server if the DOTS server detects that a request conflicts with a previous request. The response body is formatted using "application/dots+cbor" and contains the "conflict-clause" (Section 4.4.1.3).
4.09 （競合）DOTSサーバーが要求が前の要求と競合することを検出した場合、ドットサーバーによって返されます。レスポンスボディは「アプリケーション/ドットCBOR」を使用してフォーマットされており、「競合句」（セクション4.4.1.3）が含まれています。
4.13 (Request Entity Too Large) may be returned by the DOTS server during a block transfer request [RFC7959].
4.13 （リクエストエンティティは大きすぎる）ブロック転送要求[RFC7959]の間にドットサーバーによって返されます。
4.15 (Unsupported Content-Format) is returned by the DOTS server when the Content-Format is used but the request is not formatted as "application/dots+cbor" (Section 4).
4.15 （サポートされていないcontent-format）は、コンテンツ形式が使用されているが、要求が「アプリケーション/ドットCBOBOR」としてフォーマットされていない場合は、ドットサーバーによって返されます（セクション4）。
4.22 (Unprocessable Entity) is returned by the DOTS server when one or more session configuration parameters are not valid (Section 4.5).
4.22 1つ以上のセッション構成パラメータが無効になっていない場合（未処理のエンティティ）はドットサーバーによって返されます（セクション4.5）。
5.03 (Service Unavailable) is returned by the DOTS server if the DOTS server is unable to handle the request (Section 4). An example is the DOTS server needs to redirect the DOTS client to use an alternate DOTS server (Section 4.6). The response body is formatted using "application/dots+cbor" and contains how to handle the 5.03 Response Code.
5.03 ドットサーバが要求を処理できない場合（サービスが利用できないサービス）はドットサーバによって返されます（セクション4）。例は、代替ドットサーバーを使用するようにドットクライアントをリダイレクトする必要があるドットサーバーです（セクション4.6）。応答本体は、「アプリケーション/ドットCBOR」を使用してフォーマットされており、5.03回答コードを処理する方法を含みます。
5.08 (Hop Limit Reached) is returned by the DOTS server if there is a data path loop through upstream DOTS gateways. The response body is formatted using plain text and contains a list of servers that are in the data path loop [RFC8768].
5.08 上流のドットゲートウェイを介してデータパスループがある場合は、（ホップ制限到達）がドットサーバーによって返されます。応答本体はプレーンテキストを使用してフォーマットされ、データパスループ[RFC8768]にあるサーバーのリストを含みます。
IANA has assigned the port number 4646 (the ASCII decimal value for ".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP from the "Service Name and Transport Protocol Port Number Registry" available at <https://www.iana.org/assignments/service-names-port-numbers/>.
IANAは、<https://www.iana.org/assignments/service-names-port-numbers/>。
IANA has updated these entries to refer to this document and updated the Description as described below:
IANAはこの文書を参照し、以下の説明を更新するためにこれらのエントリを更新しました。
Service Name: dots-signal Port Number: 4646 Transport Protocol: TCP Description: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Protocol. The service name is used to construct the SRV service names "_dots-signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to establish DOTS signal channel. Assignee: IESG Contact: IETF Chair Registration Date: 2020-01-16 Reference: [RFC8973][RFC9132]
Service Name: dots-signal Port Number: 4646 Transport Protocol: UDP Description: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Protocol. The service name is used to construct the SRV service names "_dots-signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to establish DOTS signal channel. Assignee: IESG Contact: IETF Chair Registration Date: 2020-01-16 Reference: [RFC8973][RFC9132]
IANA has updated the 'dots' well-known URI (Table 6) entry in the "Well-Known URIs" registry [URI] as follows:
IANAは、「有名なURI」レジストリ[URI]の「ドット」の有名なURI（表6）エントリを次のように更新しました。
+============+============+===========+===========+=============+
| URI Suffix | Change | Reference | Status | Related |
| | Controller | | | information |
+============+============+===========+===========+=============+
| dots | IETF | [RFC9132] | permanent | None |
+------------+------------+-----------+-----------+-------------+
Table 6: 'dots' Well-Known URI
表6：ドットの有名なURI
IANA has updated the "application/dots+cbor" media type in the "Media Types" registry [IANA-MediaTypes] in the manner described in [RFC6838], which can be used to indicate that the content is a DOTS signal channel object:
IANAは、コンテンツがドット信号チャネルオブジェクトであることを示すために使用できる「メディアタイプ」レジストリ[IANA-MediaTypes]の「アプリケーション/ドットCBOR」メディアタイプを更新しました。
Type name: application
タイプ名：アプリケーション
Subtype name: dots+cbor
サブタイプ名：ドット栓
Required parameters: N/A
必要なパラメータ：N/A.
Optional parameters: N/A
オプションのパラメータ：N/A.
Encoding considerations: binary
エンコードに関する考慮事項：バイナリ
Security considerations: See the Security Considerations section of RFC 9132.
セキュリティ上の考慮事項：RFC 9132の「セキュリティ上の考慮事項」セクションを参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：N/A.
Published specification: RFC 9132
公開仕様：RFC 9132
Applications that use this media type: DOTS agents sending DOTS messages over CoAP over (D)TLS.
このメディアタイプを使用するアプリケーション：ドットエージェントは、CoAP OVER（D）TLSを介してドットメッセージを送信します。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N/A.
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: IESG, iesg@ietf.org
詳細については、連絡先のある人とEメールアドレス：IESG、iesg@ietf.org
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: none
使用制限：なし
Author: See Authors' Addresses section.
著者：作者の住所のセクションを参照してください。
Change controller: IESG
変更コントローラー：IESG
Provisional registration? No
暫定登録？番号
IANA has updated the "application/dots+cbor" media type in the "CoAP Content-Formats" registry [IANA-CoAP-Content-Formats] as follows:
次のように、「COAA Content-Formats」レジストリ[IANA-COAAP-CONTENT-FORMAT）の「アプリケーション/ドットCBOR」メディアタイプを更新しました。
Media Type: application/dots+cbor Encoding: - ID: 271 Reference: [RFC9132]
This section defines the DOTS CBOR tag as another means for applications to declare that a CBOR data structure is a DOTS signal channel object. Its use is optional and is intended for use in cases in which this information would not otherwise be known. The DOTS CBOR tag is not required for the DOTS signal channel protocol version specified in this document. If present, the DOTS tag MUST prefix a DOTS signal channel object.
本セクションでは、CBORデータ構造がDOTSシグナルチャネルオブジェクトであることをアプリケーションが宣言するための別の手段としてDOTS CBORタグを定義します。その使用は任意であり、この情報が他の方法では認識されない場合に使用されることを意図しています。このドキュメントで指定されているDOTSシグナルチャネルプロトコルバージョンでは、DOTS CBORタグは要求されません。存在する場合、DOTSタグはDOTSシグナルチャネルオブジェクトのプレフィックスにならなければなりません (MUST)。
IANA has updated the DOTS signal channel CBOR tag in the "CBOR Tags" registry [IANA-CBOR-Tags] as follows:
次のように、「CBORタグ」レジストリ[IANA-CBOR-TAG]の「CBORタグ」レジストリ[IANA-CBOR-TAG]のドットシグナルチャネルCBORタグを更新しました。
Tag: 271 Data Item: DDoS Open Threat Signaling (DOTS) signal channel object Semantics: DDoS Open Threat Signaling (DOTS) signal channel object, as defined in [RFC9132] Reference: [RFC9132]
タグ：271データ項目：DDoSオープン脅威シグナリング（ドット）信号チャネルオブジェクトセマンティクス：DDoSオープン脅威シグナリング（DOTS）信号チャネルオブジェクト（RFC9132]参照：[RFC9132]
The following sections update the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" subregistries [REG-DOTS].
次のセクションでは、「分散サービス拒否オープン脅威シグナリング（DOTS）信号チャネル」サブレジスト[REG-DOTS]を更新します。
The structure of this subregistry is provided in Section 10.6.1.1.
このサブレジストの構造は、10.6.1.1項で提供されています。
IANA has updated the allocation policy of "DOTS Signal Channel CBOR Key Values" registry as follows:
IANAは次のように「ドット信号チャネルCBORキー値」レジストリの割り当て方針を更新しました。
Parameter name: Parameter name, as used in the DOTS signal channel.
パラメータ名：ドット信号チャネルで使用されるパラメータ名。
CBOR Key Value: Key value for the parameter. The key value MUST be an integer in the 1-65535 range.
CBOR Key Value: パラメータのキー値。キー値は1〜65535の範囲の整数でなければなりません (MUST)。
OLD:
旧：
+=============+=========================+========================+
| Range | Registration | Note |
| | Procedures | |
+=============+=========================+========================+
| 1-16383 | IETF Review | comprehension-required |
+-------------+-------------------------+------------------------+
| 16384-32767 | Specification | comprehension-optional |
| | Required | |
+-------------+-------------------------+------------------------+
| 32768-49151 | IETF Review | comprehension-optional |
+-------------+-------------------------+------------------------+
| 49152-65535 | Private Use | comprehension-optional |
+-------------+-------------------------+------------------------+
Table 7
表7.
NEW:
新：
+=============+=========================+========================+
| Range | Registration | Note |
| | Procedures | |
+=============+=========================+========================+
| 1-127 | IETF Review | comprehension-required |
+-------------+-------------------------+------------------------+
| 128-255 | IETF Review | comprehension-optional |
+-------------+-------------------------+------------------------+
| 256-16383 | IETF Review | comprehension-required |
+-------------+-------------------------+------------------------+
| 16384-32767 | Specification | comprehension-optional |
| | Required | |
+-------------+-------------------------+------------------------+
| 32768-49151 | IETF Review | comprehension-optional |
+-------------+-------------------------+------------------------+
| 49152-65535 | Private Use | comprehension-optional |
+-------------+-------------------------+------------------------+
Table 8
表8.
Registration requests for the 16384-32767 range are evaluated after a three-week review period on the dots-signal-reg-review@ietf.org mailing list, on the advice of one or more designated experts. However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published. New registration requests should be sent in the form of an email to the review mailing list; the request should use an appropriate subject (e.g., "Request to register CBOR Key Value for DOTS: example"). IANA will only accept new registrations from the designated experts, and it will check that review was requested on the mailing list in accordance with these procedures.
16384-32767の範囲の登録要求は、1つ以上の指定された専門家のアドバイスについて、DOTSSIGNAL-REG-Review@ietf.orgメーリングリストの3週間のレビュー期間の後に評価されます。しかしながら、出版前の値の割り当てを可能にするために、指定された専門家は、そのような仕様が公表されることが満たされると登録を承認することができる。新しい登録要求は、レビューメーリングリストへの電子メールの形式で送信されるべきです。要求は適切な主題（例えば、「ドットのためのCBORキー値を登録する要求：例」）を使用するべきです。IANAは指定された専門家からの新しい登録のみを受け入れ、これらの手順に従ってメーリングリストでレビューが要求されたことを確認します。
Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
レビュー期間内では、指定された専門家は登録要求を承認または拒否し、この決定をレビューリストとIANAに伝えます。拒否は説明を含み、該当する場合は、要求を成功させる方法に関する提案を含める必要があります。解像度のために、21日を超える期間にわたって未定の登録要求をIESGの注意（IESG@IETF.ORGメーリングリストを使用）にもたらすことができます。
Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single use case, and whether the registration description is clear. IANA must only accept registry updates to the 16384-32767 range from the designated experts and should direct all requests for registration to the review mailing list. It is suggested that multiple designated experts be appointed. In cases where a registration decision could be perceived as creating a conflict of interest for a particular expert, that expert should defer to the judgment of the other experts.
指定された専門家によって適用されるべき基準は、提案された登録が既存の機能を複製したかどうか、一般的な適用性または単一のユースケースにのみ有用であるかどうか、および登録記述が明確であるかどうかを判断することを含む。IANAは、指定された専門家からの16384-32767の範囲のレジストリアップデートのみを受け入れなければならず、レビューメーリングリストへの登録のためのすべての要求を指示する必要があります。複数の指定された専門家が任命されることが示唆されています。登録決定が特定の専門家にとって興味のある相反を生み出すこととして認識される可能性がある場合、その専門家は他の専門家の判断を延期するべきです。
CBOR Major Type: CBOR Major type and optional tag for the parameter.
CBORメジャータイプ：CBORメジャータイプとパラメータのオプションのタグ。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., email address) may also be included.
変更コントローラー：標準トラックRFCSの場合は、「IESG」をリストしてください。他の人にとって、責任者の名前を付けてください。他の詳細（例えば、電子メールアドレス）も含まれ得る。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
仕様書文書：文書のコピーを検索するために使用できるURIを含む、パラメータを指定する文書または文書への参照。関連するセクションの表示も含まれ得るが、必要ではない。
IANA has updated entries in the "0-51" and "49152-65535" ranges from the "DOTS Signal Channel CBOR Key Values" registry to refer this RFC.
このRFCを参照するために、「0-51」、「DOTS信号チャネルCBORキー値」レジストリから「0-51」、「49152-65535」のエントリが更新されました。
IANA has updated the following entries from the "DOTS Signal Channel Status Codes" registry to refer to this RFC:
このRFCを参照するには、IANAが「ドット信号チャネルステータスコード」レジストリから次のエントリを更新しました。
+==============+===============+======================+===========+
| Code | Label | Description | Reference |
+==============+===============+======================+===========+
| 0 | Reserved | | [RFC9132] |
+--------------+---------------+----------------------+-----------+
| 1 | attack- | Attack mitigation | [RFC9132] |
| | mitigation- | setup is in progress | |
| | in-progress | (e.g., changing the | |
| | | network path to | |
| | | redirect the inbound | |
| | | traffic to a DOTS | |
| | | mitigator). | |
+--------------+---------------+----------------------+-----------+
| 2 | attack- | Attack is being | [RFC9132] |
| | successfully- | successfully | |
| | mitigated | mitigated (e.g., | |
| | | traffic is | |
| | | redirected to a DDoS | |
| | | mitigator and attack | |
| | | traffic is dropped). | |
+--------------+---------------+----------------------+-----------+
| 3 | attack- | Attack has stopped | [RFC9132] |
| | stopped | and the DOTS client | |
| | | can withdraw the | |
| | | mitigation request. | |
+--------------+---------------+----------------------+-----------+
| 4 | attack- | Attack has exceeded | [RFC9132] |
| | exceeded- | the mitigation | |
| | capability | provider capability. | |
+--------------+---------------+----------------------+-----------+
| 5 | dots-client- | DOTS client has | [RFC9132] |
| | withdrawn- | withdrawn the | |
| | mitigation | mitigation request | |
| | | and the mitigation | |
| | | is active but | |
| | | terminating. | |
+--------------+---------------+----------------------+-----------+
| 6 | attack- | Attack mitigation is | [RFC9132] |
| | mitigation- | now terminated. | |
| | terminated | | |
+--------------+---------------+----------------------+-----------+
| 7 | attack- | Attack mitigation is | [RFC9132] |
| | mitigation- | withdrawn. | |
| | withdrawn | | |
+--------------+---------------+----------------------+-----------+
| 8 | attack- | Attack mitigation | [RFC9132] |
| | mitigation- | will be triggered | |
| | signal-loss | for the mitigation | |
| | | request only when | |
| | | the DOTS signal | |
| | | channel session is | |
| | | lost. | |
+--------------+---------------+----------------------+-----------+
| 9-2147483647 | Unassigned | | |
+--------------+---------------+----------------------+-----------+
Table 9: Initial DOTS Signal Channel Status Codes
表9：初期ドット信号チャネルステータスコード
IANA has updated the following entries from the "DOTS Signal Channel Conflict Status Codes" registry to refer to this RFC.
IANAは、このRFCを参照するために、「ドットシグナルチャネル競合ステータスコード」レジストリから次のエントリを更新しました。
+==============+===================+====================+===========+ | Code | Label | Description | Reference | +==============+===================+====================+===========+ | 0 | Reserved | | [RFC9132] | +--------------+-------------------+--------------------+-----------+ | 1 | request-inactive- | DOTS server | [RFC9132] | | | other-active | has detected | | | | | conflicting | | | | | mitigation | | | | | requests from | | | | | different DOTS | | | | | clients. This | | | | | mitigation | | | | | request is | | | | | currently | | | | | inactive until | | | | | the conflicts | | | | | are resolved. | | | | | Another | | | | | mitigation | | | | | request is | | | | | active. | | +--------------+-------------------+--------------------+-----------+ | 2 | request-active | DOTS server | [RFC9132] | | | | has detected | | | | | conflicting | | | | | mitigation | | | | | requests from | | | | | different DOTS | | | | | clients. This | | | | | mitigation | | | | | request is | | | | | currently | | | | | active. | | +--------------+-------------------+--------------------+-----------+ | 3 | all-requests- | DOTS server | [RFC9132] | | | inactive | has detected | | | | | conflicting | | | | | mitigation | | | | | requests from | | | | | different DOTS | | | | | clients. All | | | | | conflicting | | | | | mitigation | | | | | requests are | | | | | inactive. | | +--------------+-------------------+--------------------+-----------+ | 4-2147483647 | Unassigned | | | +--------------+-------------------+--------------------+-----------+
Table 10: Initial DOTS Signal Channel Conflict Status Codes
表10：初期ドット信号チャネル競合ステータスコード
IANA has updated the following entries from the "DOTS Signal Channel Conflict Cause Codes" registry to refer to this document:
IANAは、このドキュメントを参照するために、「ドット信号チャネル紛争原因コード」レジストリから次のエントリを更新しました。
+==============+=====================+================+===========+
| Code | Label | Description | Reference |
+==============+=====================+================+===========+
| 0 | Reserved | | [RFC9132] |
+--------------+---------------------+----------------+-----------+
| 1 | overlapping-targets | Overlapping | [RFC9132] |
| | | targets. | |
+--------------+---------------------+----------------+-----------+
| 2 | conflict-with- | Conflicts with | [RFC9132] |
| | acceptlist | an existing | |
| | | accept-list. | |
| | | This code is | |
| | | returned when | |
| | | the DDoS | |
| | | mitigation | |
| | | detects source | |
| | | addresses/ | |
| | | prefixes in | |
| | | the accept- | |
| | | listed ACLs | |
| | | are attacking | |
| | | the target. | |
+--------------+---------------------+----------------+-----------+
| 3 | cuid-collision | CUID | [RFC9132] |
| | | Collision. | |
| | | This code is | |
| | | returned when | |
| | | a DOTS client | |
| | | uses a 'cuid' | |
| | | that is | |
| | | already used | |
| | | by another | |
| | | DOTS client. | |
+--------------+---------------------+----------------+-----------+
| 4-2147483647 | Unassigned | | |
+--------------+---------------------+----------------+-----------+
Table 11: Initial DOTS Signal Channel Conflict Cause Codes
表11：初期ドット信号チャネルの紛争原因コード
IANA has updated the following entries from the "DOTS Signal Channel Attack Status Codes" registry to refer to this RFC:
このRFCを参照するには、IANAが「ドットシグナルチャネル攻撃ステータスコード」レジストリから次のエントリを更新しました。
+==============+======================+=================+===========+ | Code | Label | Description | Reference | +==============+======================+=================+===========+ | 0 | Reserved | | [RFC9132] | +--------------+----------------------+-----------------+-----------+ | 1 | under-attack | The DOTS | [RFC9132] | | | | client | | | | | determines | | | | | that it is | | | | | still under | | | | | attack. | | +--------------+----------------------+-----------------+-----------+ | 2 | attack-successfully- | The DOTS | [RFC9132] | | | mitigated | client | | | | | determines | | | | | that the | | | | | attack is | | | | | successfully | | | | | mitigated. | | +--------------+----------------------+-----------------+-----------+ | 3-2147483647 | Unassigned | | | +--------------+----------------------+-----------------+-----------+
Table 12: Initial DOTS Signal Channel Attack Status Codes
表12：初期ドット信号チャネル攻撃ステータスコード
IANA has registered the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」[RFC3688]内の「NS」サブレイストに次のURIを登録しました。
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：URN：IETF：PARAMS：XML：NS：YANG：IETF-DOTS-Signal-Channel Register連絡先：IESG。XML：N/A;要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel Registrant Contact: IANA. XML: N/A; the requested URI is an XML namespace.
URI：URN：IETF：Params：XML：NS：Yang：IANA-DOTS-Signal-Channel Register連絡先：IANA。XML：N/A;要求されたURIはXMLネームスペースです。
IANA has updated the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.
IANAは、「YANG PARAMETERS」レジストリ内の「Yang Module Names」サブレジスト[RFC6020]に次のYangモジュールを更新しました。
Name: iana-dots-signal-channel Maintained by IANA: Y Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel Prefix: iana-dots-signal Reference: [RFC9132]
Name: ietf-dots-signal-channel Maintained by IANA: N Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel Prefix: dots-signal Reference: [RFC9132]
This document obsoletes the initial version of the IANA-maintained iana-dots-signal-channel YANG module (Section 5.2 of [RFC8782]). IANA is requested to maintain this note:
この文書は、IANA保持されているIANA-DOTS-Signal-Channel Yangモジュールの初期版を廃止します（[RFC8782]のセクション5.2）。IANAはこのメモを維持するように要求されています。
Status, conflict status, conflict cause, and attack status values must not be directly added to the iana-dots-signal-channel YANG module. They must instead be respectively added to the "DOTS Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack Status Codes" registries.
ステータス、競合ステータス、競合の原因、および攻撃状況値をIANA-DOTS-Signal-Channel Yangモジュールに直接追加してはいけません。代わりに「ドットステータスコード」、「ドット競合状態コード」、「ドット紛争原因コード」、「ドット攻撃状況コード」レジストリには、それぞれ追加する必要があります。
When a 'status', 'conflict-status', 'conflict-cause', or 'attack-status' value is respectively added to the "DOTS Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack Status Codes" registry, a new "enum" statement must be added to the iana-dots-signal-channel YANG module. The following "enum" statement, and substatements thereof, should be defined:
「ステータス」、「紛争 - ステータス」、「紛争 - 原因」、または「攻撃状態」の値がそれぞれ「ドットステータスコード」、「ドット競合ステータスコード」、「ドット紛争原因コード」に追加されると、または「ドット攻撃状況コード」レジストリ、IANA-DOTS-Signal-Channel Yangモジュールに新しい "enum"ステートメントを追加する必要があります。以下の「enum」ステートメント、およびその代入は、定義されるべきです。
"enum": Replicates the label from the registry.
"enum"：レジストリからラベルを複製します。
"value": Contains the IANA-assigned value corresponding to the 'status', 'conflict-status', 'conflict-cause', or 'attack-status'.
"value"： 'status'、 'conflict-status'、 'conflict-furess'、または 'attack-status'に対応するIANA割り当てられた値を含みます。
"description": Replicates the description from the registry.
"description"：レジストリからの説明を複製します。
"reference": Replicates the reference from the registry and adds the title of the document.
"Reference"：レジストリからの参照を複製し、文書のタイトルを追加します。
When the iana-dots-signal-channel YANG module is updated, a new "revision" statement must be added in front of the existing revision statements.
IANA-DOTS-Signal-Channel YANGモジュールが更新されると、既存の改訂ステートメントの前に新しい「リビジョン」ステートメントを追加する必要があります。
IANA has updated this note in "DOTS Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack Status Codes" registries:
IANAは、このノートを「ドットステータスコード」、「ドット競合ステータスコード」、「ドット紛争原因コード」、「ドット攻撃状況コード」レジストリで更新しました。
When this registry is modified, the YANG module iana-dots-signal-channel must be updated as defined in [RFC9132].
このレジストリが変更されると、YangモジュールIANA-DOTS-Signal-Channelは[RFC9132]で定義されているように更新する必要があります。
Authenticated encryption MUST be used for data confidentiality and message integrity. The interaction between the DOTS agents requires Datagram Transport Layer Security (DTLS) or Transport Layer Security (TLS) with a cipher suite offering confidentiality protection, and the guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. The (D)TLS protocol profile used for the DOTS signal channel is specified in Section 7.
データの機密性とメッセージの完全性のために、認証付き暗号化を使用しなければなりません (MUST)。DOTSエージェント間の対話には、機密性保護を提供する暗号スイートを備えたデータグラムトランスポート層セキュリティ（DTLS）またはトランスポート層セキュリティ（TLS）が必要であり、(D)TLSへの攻撃を回避するために[RFC7525]で与えられているガイダンスに従わなければなりません (MUST)。DOTSシグナルチャネルに使用される(D)TLSプロトコルプロファイルはセクション7で指定されています。
If TCP is used between DOTS agents, an attacker may be able to inject RST packets, bogus application segments, etc., regardless of whether TLS authentication is used. Because the application data is TLS protected, this will not result in the application receiving bogus data, but it will constitute a DoS on the connection. This attack can be countered by using TCP Authentication Option (TCP-AO) [RFC5925]. Although not widely adopted, if TCP-AO is used, then any bogus packets injected by an attacker will be rejected by the TCP-AO integrity check and therefore will never reach the TLS layer.
TCPがドットエージェント間で使用されている場合、TLS認証が使用されているかどうかにかかわらず、攻撃者は、RSTパケット、偽のアプリケーションセグメントなどを注入できる可能性があります。アプリケーションデータはTLS保護されているため、これはアプリケーションがBogusデータを受信することはありませんが、接続上のDOSを構成します。この攻撃は、TCP認証オプション（TCP-AO）[RFC5925]を使用して対処できます。広く採用されていないが、TCP-AOが使用されている場合、攻撃者によって注入されたボーガスパケットはTCP-AOの整合性チェックによって拒否され、したがってTLS層に到達することはありません。
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 domain to delete or alter active mitigations. For this attack to succeed, the misbehaving client's messages need to pass the security validation checks by the DOTS server and, if the communication involves a client-domain DOTS gateway, the security checks of that gateway.
「cuid」が推測できる場合、クライアントのドメイン内からの不正なドットクライアントは、ドメインの別のドットクライアントの「cuid」を使用して、アクティブな軽減を削除または変更できます。この攻撃に成功するために、不正行為のクライアントのメッセージは、ドットサーバーによってセキュリティ検証チェックを渡す必要があり、通信にクライアントドメインドットゲートウェイが含まれる場合は、そのゲートウェイのセキュリティチェックが含まれます。
A similar attack can be achieved by a compromised DOTS client that can sniff the TLS 1.2 handshake: use the client certificate to identify the 'cuid' used by another DOTS client. This attack is not possible if algorithms such as version 4 Universally Unique IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate the 'cuid' because such UUIDs are not a deterministic function of the client certificate. Likewise, this attack is not possible with TLS 1.3 because most of the TLS handshake is encrypted and the client certificate is not visible to eavesdroppers.
同様の攻撃は、TLS 1.2ハンドシェイクをスニフすることができる妥協のあるドットクライアントによって達成できます。クライアント証明書を使用して、別のドットクライアントによって使用される「CUID」を識別します。このようなUUIDはクライアント証明書の決定論的関数ではないため、バージョン4の汎用のユニバーサリ固有の識別子（UUID）が「CUID」を生成するために使用される場合、この攻撃は不可能です。同様に、TLSハンドシェイクのほとんどが暗号化され、クライアント証明書が盗聴者には見えないため、この攻撃はTLS 1.3では不可能です。
A compromised DOTS client can collude with a DDoS attacker to send a mitigation request for a target resource, get the mitigation efficacy from the DOTS server, and convey the mitigation efficacy to the DDoS attacker to possibly change the DDoS attack strategy. Obviously, signaling an attack by the compromised DOTS client to the DOTS server will trigger attack mitigation. This attack can be prevented by monitoring and auditing DOTS clients to detect misbehavior and to deter misuse and by only authorizing the DOTS client to request mitigation for specific target resources (e.g., an application server is authorized to request mitigation for its IP addresses, but a DDoS mitigator can request mitigation for any target resource in the network). Furthermore, DOTS clients are typically co-located on network security services (e.g., firewall), and a compromised security service potentially can do a lot more damage to the network.
妥協されたドットクライアントは、DDoS攻撃者がターゲットリソースに対して軽減要求を送信し、ドットサーバーからの緩和効果を得て、DDoS攻撃戦略を変更することができるようにDDoS攻撃者に緩和効果を伝えます。明らかに、侵入されたドットクライアントによる攻撃をドットサーバーにシグナリングすると、攻撃の軽減が引き起こされます。この攻撃は、ドットクライアントを監視および監査して、不正行為を検出し、誤用を検出し、誤用を検出し、特定のターゲットリソースに対する緩和を要求するためにドットクライアントを承認することによって（アプリケーションサーバーがそのIPアドレスの軽減を要求されていますが、DDoS Mitigatorは、ネットワーク内の任意のターゲットリソースに対して緩和を要求することができます）。さらに、ドットクライアントは通常、ネットワークセキュリティサービス（例えばファイアウォール）上に同一に配置され、侵入されたセキュリティサービスがネットワークに大きな損傷を与える可能性がある。
Rate-limiting DOTS requests, including those with new 'cuid' values, from the same DOTS client defend against DoS attacks that would result in varying the 'cuid' to exhaust DOTS server resources. Rate-limit policies SHOULD be enforced on DOTS gateways (if deployed) and DOTS servers.
同一のDOTSクライアントからの新しい'cuid'値を持つものを含むDOTS要求をレート制限することは、DOTSサーバーのリソースを枯渇させるために'cuid'を変化させるDoS攻撃から保護します。レート制限ポリシーは、DOTSゲートウェイ（展開されている場合）およびDOTSサーバーで強制されるべきです (SHOULD)。
In order to prevent leaking internal information outside a client's domain, DOTS gateways located in the client domain SHOULD NOT reveal the identification information that pertains to internal DOTS clients (e.g., source IP address, client's hostname) unless explicitly configured to do so.
クライアントのドメイン外への内部情報の漏洩を防ぐため、クライアントドメイン内に配置されたDOTSゲートウェイは、明示的にそうするように設定されていない限り、内部DOTSクライアントに関する識別情報（例えば送信元IPアドレス、クライアントのホスト名）を明らかにすべきではありません (SHOULD NOT)。
DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. A DOTS server MUST NOT authorize actions due to a DOTS client request unless those actions are limited to that DOTS client's domain IP resources. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client domain is deployment specific.
DOTSサーバーは、要求を行っているDOTSクライアントに所定のIPプレフィックスに対してアクションをトリガーする権限があることを検証しなければなりません (MUST)。DOTSサーバーは、それらのアクションがそのDOTSクライアントのドメインIPリソースに限定されていない限り、DOTSクライアントの要求によるアクションを承認してはなりません (MUST NOT)。対象プレフィックスがDOTSクライアントドメインのスコープ内にあることをDOTSサーバーが検証するための正確なメカニズムは、展開に固有です。
The presence of DOTS gateways may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document uses the Hop-Limit Option.
ドットゲートウェイの存在は無限の転送ループをもたらし、これは望ましくない。そのようなループを防止および検出するために、このドキュメントはHOP-LIMITオプションを使用します。
When FQDNs are used as targets, the DOTS server MUST rely upon DNS privacy-enabling protocols (e.g., DNS over TLS [RFC7858] or DNS over HTTPS (DoH) [RFC8484]) to prevent eavesdroppers from possibly identifying the target resources protected by the DDoS mitigation service to ensure the target FQDN resolution is authentic (e.g., DNSSEC [RFC4034]).
CoAP-specific security considerations are discussed in Section 11 of [RFC7252], while CBOR-related security considerations are discussed in Section 10 of [RFC8949].
CBOR関連のセキュリティ上の考慮事項は[RFC8949]のセクション10で説明されていますが、CBC7252のセクション11のCoAP固有のセキュリティ上の考慮事項について説明します。
This document defines YANG data structures that are meant to be used as an abstract representation of DOTS signal channel messages. As such, the "ietf-dots-signal-channel" module does not introduce any new vulnerabilities beyond those specified above.
この文書は、ドット信号チャネルメッセージの抽象表現として使用されることを意図したYANGデータ構造を定義しています。そのため、 "IETF-dots-signal-channel"モジュールは上記で指定されたものを超えて新しい脆弱性を導入しません。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel, J.、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487/RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden, R., Ed.、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487/RFC1122、1989年10月、<https://www.rfc-editor.org/info/rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S.、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/rfc2119>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling, M., "The IETF XMLレジストリ"、BCP 81、RFC 3688、DOI 10.17487/RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https://www.rfc-editor.org/info/rfc3986>。
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>.
[RFC4279] Eronen、P、ED。2005年12月、<https://www.rfc-editor.org/info/rfc4279>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller, V. and T. Li、「クラスレスドメイン間ルーティング（CIDR）：インターネットアドレス割り当てと集約計画」、BCP 122、RFC 4632、DOI 10.17487/RFC4632、2006年8月、<https://www.rfc-editor.org/info/rfc4632>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson, S.、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks, T. and E. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487/RFC5246、2008年8月、<https://www.rfc-editor.org/info/rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund, M., Ed.、「Yang - ネットワーク構成プロトコルのデータモデリング言語（NetConf）」、RFC 6020、DOI 10.17487/RFC6020、2010年10月、<https://www.rfc-editor.org/info/rfc6020>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd, D.、「トランスポート層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487/RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487/RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla, E. and N. Modadugu、「データグラムトランスポートレイヤセキュリティバージョン1.2」、RFC 6347、DOI 10.17487/RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder, J., Ed.、「共通ヤンデータ型」、RFC 6991、DOI 10.17487/RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層での生の公開鍵を使用する」セキュリティ（DTLS） "、RFC 7250、DOI 10.17487/RFC7250、2014年6月、<https://www.rfc-editor.org/info/rfc7250>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https://www.rfc-editor.org/info/rfc7252>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke, K.、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7641、DOI 10.17487/RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/info/rfc7918>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller、「トランスポート層セキュリティ（TLS）偽のスタート」、RFC 7918、DOI 10.17487/RFC7918、2016年8月、<https://www.rfc-editor.org/info/rfc7918>。
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.
[RFC7924] Santesson, S. and H. Tschofenig、「トランスポート層セキュリティ（TLSキャッシュ情報拡張」、RFC 7924、DOI 10.17487/RFC7924、2016年7月、<https://www.rfc-editor.org/info/rfc7924>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund, M., Ed.、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann, C. and Z. Shelby, Ed.、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7959、DOI 10.17487/RFC7959、2016年8月、<https://www.rfc-editor.org/info/rfc7959>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https://www.rfc-editor.org/info/rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba, B.、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https://www.rfc-editor.org/info/rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering, S. and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/rfc8200>。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyaballs Version 2：並行性を使用したより良い接続"、RFC 8305、DOI 10.17487/RFC8305、2017年12月、<https://www.rfc-editor.org/info/rfc8305>。
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "、RFC 8323、DOI 10.17487/RFC8323、2018年2月、<https://www.rfc-editor.org/info/rfc8323>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla, E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC8615] Nottingham, M.、「よく知られているユニフォーム識別子（URIS）」、RFC 8615、DOI 10.17487/RFC8615、2019年5月、<https://www.rfc-editor.org/info/rfc8615>。
[RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained Application Protocol (CoAP) Hop-Limit Option", RFC 8768, DOI 10.17487/RFC8768, March 2020, <https://www.rfc-editor.org/info/rfc8768>.
[RFC8768] Boucadair、M.、Reddy.k、T.、およびJ.Shallow、「制約付きアプリケーションプロトコル（CoAP）ホップリミットオプション」、RFC 8768、DOI 10.17487/RFC8768、2020年3月、<https://www.rfc-editor.org/info/rfc8768>。
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8783] Boucadair、M.、Ed。そして、「分散サービス拒否オープン脅威シグナル伝達（ドット）データチャネル仕様」、RFC 8783、DOI 10.17487/RFC8783、<https://www.rfc-editor.org/info/rfc8783>。
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen、「Yang Data Structions Extensions」、RFC 8791、DOI 10.17487/RFC8791、2020年6月、<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>.
[RFC8949] Bormann, C. and P. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/rfc8949>。
[CORE-COMI] Veillette, M., Ed., Stok, P., Ed., Pelov, A., Bierman, A., and I. Petrov, "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-11, 17 January 2021, <https://datatracker.ietf.org/doc/html/ draft-ietf-core-comi-11>.
[CORE-COMI] Veillette, M., Ed., Stok, P., Ed., Pelov, A., Bierman, A., and I. Petrov、「CoAP Management Interface（CORECONF）」、進行中、インターネット--draft、draft-ietf-core-comi-11,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11>。
[CORE-YANG-CBOR] Veillette, M., Ed., Petrov, I., Ed., and A. Pelov, "CBOR Encoding of Data Modeled with YANG", Work in Progress, Internet-Draft, draft-ietf-core-yang-cbor-16, 25 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-16>.
[CORE-YANG-CBOR] Veillette, M., Ed., Petrov, I., Ed., and A. Pelov、「ヤンでモデル化されたデータのCBORエンコーディング」、進行中の作業、インターネットドラフト、ドラフト - IETF-Core-Yang-CBOR-16,2021 1月25日、<https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-16>。
[DOTS-EARLYDATA] Boucadair, M. and T. Reddy.K, "Using Early Data in DOTS", Work in Progress, Internet-Draft, draft-boucadair-dots-earlydata-00, 29 January 2019, <https://datatracker.ietf.org/doc/html/draft-boucadair-dots-earlydata-00>.
[DOTS-EarlData] Boucadair、M.およびT.Reddy.k、「ドットの早期データの使用」、進行中の作業、インターネットドラフト、ドラフト - Boucadair-dots-ewardata-00,2019、<https://datatracker.ietf.org/doc/html/draft-boucadair-dots-earlydata-00>。
[DOTS-MULTIHOMING] Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Work in Progress, Internet-Draft, draft-ietf-dots-multihoming-07, 6 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-07>.
[DOTS-MULTIHOMING] Boucadair、M.、Reddy.k、T.、およびW. Pan、「配布拒否開放脅威シグナル伝達（ドット）」の「マルチホーミング展開に関する考察」、進行中の取り組み、インターネット - ドラフト、ドラフトIETF-DOTS-MULTIHOMING-07,07,7,7,7,07,60,0,600 / DOC / html/draft-ietf-dots-multihoming-07>
[DOTS-TELEMETRY] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", Work in Progress, Internet-Draft, draft-ietf-dots-telemetry-16, 8 December 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-16>.
[ドットテレメトリ] Boucadair、M.、Ed。、Reddy.K、T.、ED。、DORON、E.、CHEN、M.、J。Shallow、 "Distribe-Service Operic脅威シグナリング（ドット）テレメトリ "）、進行中の作業、インターネットドラフト、ドラフト - IETF-DOTF-Telemetry-16,16,18,18、<https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-16>。
[IANA-CBOR-Tags] IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
[IANA-CBOR-Tags] IANA、「簡潔なバイナリオブジェクト表現（CBOR）タグ」、<https://www.iana.org/assignments/cbor-tags>。
[IANA-CoAP-Content-Formats] IANA, "CoAP Content-Formats", <https://www.iana.org/assignments/core-parameters>.
[IANA-CoAP-Content-Formats] IANA、「CoAP content-formats」、<https://www.iana.org/assignments/core-parameters>。
[IANA-MediaTypes] IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[IANA-MediaTypes] IANA、「メディアタイプ」、<https://www.iana.org/assignments/media-types>。
[IANA-Proto] IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers>.
[IANA-Proto] IANA、「プロトコル番号」、<https://www.iana.org/assignments/protocol-numbers>。
[REG-DOTS] IANA, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel", <https://www.iana.org/assignments/dots>.
[REG-DOTS] IANA、「サービス拒否オープン脅威シグナリング（ドット）信号チャネル」、<https://www.iana.org/assignments/dots>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh, P. and K. Egevang、「伝統的なIPネットワークアドレス翻訳者（伝統的なIPネットワークアドレス翻訳者（伝統的なNAT）」、RFC 3022、DOI 10.17487/RFC3022、2001年1月、<https://www.rfc-editor.org/info/rfc3022>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487/RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach, P., Mealling, M., and R. Salz、「普遍的にユニークな識別子（UUID）URN名前空間」、RFC 4122、DOI 10.17487/RFC4122、2005年7月、<https://www.rfc-editor.org/info/rfc4122>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd、「データグラム輻輳制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487/RFC4340、2006年3月、<https://www.rfc-editor.org/info/rfc4340>。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <https://www.rfc-editor.org/info/rfc4732>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB、「インターネット拒否サービス考慮事項」、RFC 4732、DOI 10.17487/RFC4732、2006年12月、<https://www.rfc-editor.org/info/rfc4732>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787] Audet, F., Ed. and C. Jennings、「ユニキャストUDPのネットワークアドレス翻訳（NAT）行動要件」、BCP 127、RFC 4787、DOI 10.17487/RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart, R., Ed.、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487/RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy, W.、「TCP SYNフラッディング攻撃および一般的な軽減」、RFC 4987、DOI 10.17487/RFC4987、2007年8月、<https://www.rfc-editor.org/info/rfc4987>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica、「TCP認証オプション」、RFC 5925、DOI 10.17487/RFC5925、2010年6月、<https://www.rfc-editor.org/info/rfc5925>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li、「IPv6 / IPv6翻訳者のIPv6アドレッシング」、RFC 6052、DOI 10.17487/RFC6052、2010年10月、<https://www.rfc-editor.org/info/rfc6052>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳"、RFC 6146、DOI 10.17487/RFC6146、2011年4月、<https://www.rfc-editor.org/info/rfc6146>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd, D. and T. Hansen、「米国セキュアハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487/RFC6234、2011年5月、<https://www.rfc-editor.org/info/rfc6234>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-ipv6ネットワークプレフィックス翻訳"、RFC 6296、DOI 10.17487/RFC6296、2011年6月、<https://www.rfc-editor.org/info/rfc6296>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown、「インターネットプロトコルバージョン6のデフォルトアドレス選択（IPv6）」、RFC 6724、DOI 10.17487/RFC6724、2012年9月<https://www.rfc-editor.org/info/rfc6724>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487/RFC6838、2013年1月、<https://www.rfc-editor.org/info/rfc6838>。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol（PCP）"、RFC 6887、DOI 10.17487/RFC6887、2013年4月<https://www.rfc-editor.org/info/rfc6887>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida、「キャリアグレードのNAT（CGNS）の共通要件」、BCP 127、RFC 6888、DOI 10.17487/RFC6888、2013年4月、<https://www.rfc-editor.org/info/rfc6888>。
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.、「セキュアトランスポートの登録」、RFC 7030、DOI 10.17487/RFC7030、2013年10月、<https://www.rfc-editor.org/info/rfc7030>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open"、RFC 7413、DOI 10.17487/RFC7413、2014年12月、<https://www.rfc-editor.org/info/rfc7413>。
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <https://www.rfc-editor.org/info/rfc7452>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson、「スマートオブジェクトネットワーキングにおける建築検討」、RFC 7452、DOI 10.17487/RFC7452、2015年3月、<https://www.rfc-editor.org/info/rfc7452>。
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, <https://www.rfc-editor.org/info/rfc7589>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder、「相互X.509認証によるトランスポート層セキュリティ（TLS）を介したNetConfプロトコル（TLS）を使用する」、RFC 7589、DOI 10.17487/RFC7589、2015年6月、<https://www.rfc-editor.org/info/rfc7589>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman、「トランスポート層セキュリティ（TLS）のDNSの仕様（TLS）」、RFC 7858、DOI10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[RFC7951] Lhotka, L.、「Yangでモデル化されたデータのJSONエンコーディング」、RFC 7951、DOI 10.17487/RFC7951、2016年8月、<https://www.rfc-editor.org/info/rfc7951>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund, M. and L. Berger, Ed.、「Yang Tree Diagress」、BCP 215、RFC 8340、DOI 10.17487/RFC8340、2018年3月、<https://www.rfc-editor.org/info/rfc8340>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] Hoffman, P. and P. McManus、「HTTPS経由のDNSクエリ（DOH）」、RFC 8484、DOI 10.17487/RFC8484、2018年10月、<https://www.rfc-editor.org/info/rfc8484>。
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews、「Nat（Stun）のセッショントラバーサルユーティリティ」、RFC 8489、DOI10.17487 / RFC8489、2020年2月、<https://www.rfc-editor.org/info/rfc8489>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487/RFC8499、2019年1月、<https://www.rfc-editor.org/info/rfc8499>。
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, <https://www.rfc-editor.org/info/rfc8612>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoSオープン脅威シグナリング（ドット）要件"、RFC 8612、DOI 10.17487/RFC8612、2019年5月、<https://www.rfc-editor.org/info/rfc8612>。
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, <https://www.rfc-editor.org/info/rfc8782>.
[RFC8782] Reddy.K、T.、ED。、Boucadair、M.、Ed。、Patil、P.、Mortensen、A.、およびN. TeaGue、 "Distribe Service Open Threatシグナリング（ドット）信号Channel Specification "、RFC 8782、DOI 10.17487/RFC8782、2020年5月、<https://www.rfc-editor.org/info/rfc8782>。
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, August 2020, <https://www.rfc-editor.org/info/rfc8811>.
[RFC8811] Mortensen、A.、ED。、Reddy.K、T.、ED。、Andreasen、F.、Teague、N.、R. Compton、DDoSオープン脅威シグナル伝達（ドット）アーキテクチャ "、RFC 8811、DOI 10.17487/RFC8811、2020年8月、<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>.
[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka、「DDoSオープン脅威シグナル伝達用ユースケース」、RFC 8903、DOI 10.17487/RFC8903、2021年5月、<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>.
[RFC8973] Boucadair、M.およびT.Reddy.k、 "DDoS Open Threat Signaling（ドット）エージェントディスカバリ"、RFC 8973、DOI 10.17487/RFC8973、2021年1月、<https://www.rfc-editor.org/info/rfc8973>。
[TLS-DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-43, 30 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>.
[TLS-DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-DTLS13-43,43,30 4月30日、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>。
[URI] IANA, "Well-Known URIs", <https://www.iana.org/assignments/well-known-uris>.
[URI] IANA、「有名なURI」、<https://www.iana.org/assignments/well-known-uris>。
* Update the "ietf-dots-signal-channel" YANG module (Section 5.3) and the tree structure (Section 5.1) to follow the new YANG data structure specified in [RFC8791]. In particular:
* [RFC8791]で指定された「IETF-DOTS-Signal-Channel」Yang Module（セクション5.3）とツリー構造（セクション5.1）を更新します。特に：
- Add in 'choice' to indicate the communication direction in which a data node applies. If no 'choice' is indicated, a data node can appear in both directions (i.e., from DOTS clients to DOTS servers and vice versa).
- データノードが適用される通信方向を示すために「選択」で追加してください。'選択'が示されていない場合、データノードは両方向に（すなわち、ドットクライアントからドットサーバへ、そしてその逆もまた同様である）。
- Remove 'config' clauses. Note that 'config' statements will be ignored (if present) anyway, according to Section 4 of [RFC8791]. This supersedes the references to the use of 'ro' and 'rw', which are now covered by 'choice' above.
- 'config'句を削除します。[RFC8791]のセクション4によると、「設定」ステートメントは無視されます（存在する場合）。これは 'RO'と 'RW'の使用への参照に優先されます。これは、上記の「選択」でカバーされています。
- Remove 'cuid', 'cdid', and 'sid' data nodes from the structure because these data nodes are included as Uri-Path options, not within the message body.
- これらのデータノードは、メッセージ本文内ではなくURIパスオプションとして含まれているため、構造から「CUID」、「CDID」、および「SID」データノードを削除します。
- Remove the list keys for the mitigation scope message type (i.e., 'cuid' and 'mid'). 'mid' is not indicated as a key because it is included as a Uri-Path option for requests and in the message body for responses. Note that Section 4 of [RFC8791] specifies that a list does not require to have a key statement defined.
- 緩和スコープメッセージタイプ（すなわち、「cuid」と「mid」）のリストキーを取り外します。「MID」はキーとして示されていません。リクエストと応答のメッセージ本文のURIパスオプションとして含まれているためです。[RFC8791]のセクション4は、リストがキーステートメントを定義する必要がないことを指定しています。
* Add a new section with a summary of the error code responses that can be returned by a DOTS server (Section 9).
* ドットサーバーによって返されることができるエラーコード応答の概要を持つ新しいセクションを追加します（セクション9）。
* Update the IANA section to allocate a new range for comprehension-optional attributes (Section 10.6.1.1). This modification is motivated by the need to allow for compact DOTS signal messages that include a long list of comprehension-optional attributes, e.g., DOTS telemetry messages [DOTS-TELEMETRY].
* IANAセクションを更新して、任意の属性の新しい範囲を割り当てる（10.6.1.1項）。この修正は、理解任意の属性の長いリスト、例えばドットテレメトリメッセージを含むコンパクトなドット信号メッセージを可能にする必要性によって動機付けされる。
* Add Appendix C to list recommended/default values of key DOTS signal channel parameters.
* キードット信号チャネルパラメータの推奨/デフォルト値を一覧表示するには付録Cを追加します。
* Add subsections to Section 4.4.1 for better readability.
* 読みやすくするために、セクション4.4.1にサブセクションを追加します。
The document recommends the use of SPKI to generate the 'cuid'. This design choice is motivated by the following reasons:
この文書は、「CUID」を生成するためにSPKIを使用することを推奨します。この設計選択は、次のような理由で動機付けられています。
* SPKI is globally unique.
* Spkiはグローバルにユニークです。
* It is deterministic.
* それは確定的です。
* It allows the avoidance of extra cycles that may be induced by 'cuid' collision.
* それは「CUID」衝突によって引き起こされる可能性がある追加のサイクルの回避を可能にする。
* DOTS clients do not need to store the 'cuid' in a persistent storage.
* ドットクライアントは、永続ストレージに「CUID」を保存する必要はありません。
* It allows the detection of compromised DOTS clients that do not adhere to the 'cuid' generation algorithm.
* それは「CUID」世代アルゴリズムに従わない妥協のあるドットクライアントの検出を可能にする。
Appendix C. Summary of Protocol Recommended/Default Values
付録C C.プロトコルの概要推奨/デフォルト値
+================================+===========================+
| 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 |
+--------------------------------+---------------------------+
Table 13
表13.
Acknowledgements
謝辞
Many thanks to Martin Björklund for the suggestion to use [RFC8791].
[RFC8791]を使用するための提案のためにMartinBjörklundに感謝します。
Thanks to Valery Smyslov for the comments, guidance, and support.
コメント、ガイダンス、そしてサポートのためにValery Smyslovのおかげで。
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 3rd for the secdir review.
YangdoctorsレビューのためのEBBEN ARIESのおかげで、Opsdir ReviewのためのDan Romascanu、TSVアートレビュー、Genart ReviewのためのDale Wrley、およびSecdirレビューのためのDonald EastLake 3rd。
Thanks to Benjamin Kaduk for the AD review.
AD（エリアディレクター）レビューのためにBenjamin Kadukに感謝します。
Thanks to Martin Duke, Lars Eggert, Erik Kline, Murray Kucherawy, Éric Vyncke, and Robert Wilton for the IESG review.
Martin Duke、Lars Eggert、Erik Kline、Murray Kucherawy、Murray Kucherawy、Erray Vyncke、およびIESGレビューのためのRobert Wiltonに感謝します。
Acknowledgements from RFC 8782
RFC 8782からの承認
Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion and comments.
クリスチャン・ジャッカーネット、ローランド・ドビンズ、ローマDanyliw、Michael Richardson、アザム・ドロン、Kaname西雲、ジェイヴ・ドルソン、Liang Xia、Gilbert Clark、Jim Schaad、Klaus Hartke、Nesredheen Sleell、西田義子・西田義子・西田義子そしてコメント。
The authors would like to give special thanks to Kaname Nishizuka and Jon Shallow for their efforts in implementing the protocol and performing interop testing at IETF Hackathons.
著者らは、議定書の実施とIETFハッカソンで相互運用試験を行うための努力のために、西西塚とJonが浅い浅いと感謝したいと思います。
Thanks to the core WG for the recommendations on Hop-Limit and redirect signaling.
ホップ限界とリダイレクトシグナリングに関する推奨事項については、コアWGのおかげで。
Special thanks to Benjamin Kaduk for the detailed AD review.
詳細なAD（エリアディレクター）レビューのためのBenjamin Kadukに感謝します。
Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja Kuehlewind, and Alissa Cooper for the review.
Alexey Melnikov、Adam Roach、Sureshnan、Mirja Kuehlewind、Alissa Cooperのおかげでレビューのおかげでください。
Thanks to Carsten Bormann for his review of the DOTS heartbeat mechanism.
ドットのハートビートメカニズムの彼のレビューのためにCarsten Bormannのおかげで。
Contributors
貢献者
The authors of RFC 8782 are listed below:
RFC 8782の著者は以下のとおりです。
Tirumaleswar Reddy.K (editor) McAfee, Inc. Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy.k（編集）McAfee、Inc。Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Email: kondtir@gmail.com
Mohamed Boucadair (editor) Orange 35000 Rennes France
Mohamed Boucadair（編集）オレンジ35000 Rennesフランス
Email: mohamed.boucadair@orange.com
Prashanth Patil Cisco Systems, Inc.
Prashanth Patil Cisco Systems、Inc。
Email: praspati@cisco.com
Andrew Mortensen Arbor Networks, Inc. 2727 S. State Street Ann Arbor, MI 48104 United States of America
Andrew Mortensen Arbor Networks、Inc。2727 S. State Street Ann Arbor、MI 48104アメリカ
Email: andrew@moretension.com
Nik Teague Iron Mountain Data Centers United Kingdom
Nik Teague Iron Mountainデータセンターイギリス
Email: nteague@ironmountain.co.uk
The following individuals have contributed to RFC 8782:
次の個人はRFC 8782に貢献しています。
Jon Shallow NCC Group
Jon Shallow NCCグループ
Email: jon.shallow@nccgroup.trust
Mike Geller Cisco Systems, Inc. FL 33309 United States of America
Mike Geller Cisco Systems、Inc。FL 33309アメリカ合衆国
Email: mgeller@cisco.com
Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States of America
Robert Moskowitz Htt Consulting Oak Park、MI 42837アメリカ合衆国
Email: rgm@htt-consult.com
Authors' Addresses
著者の住所
Mohamed Boucadair (editor) Orange 35000 Rennes France
Mohamed Boucadair（編集）オレンジ35000 Rennesフランス
Email: mohamed.boucadair@orange.com
Jon Shallow United Kingdom
Jon Shallowイギリス
Email: supjps-ietf@jpshallow.com
Tirumaleswar Reddy.K Akamai Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy.K Akamai大使館ゴルフリンクビジネスパークバンガロール560071カルナータカインド
Email: kondtir@gmail.com