[要約] RFC 9132は、分散型サービス拒否（DDoS）攻撃からの保護を目的としたDOTS信号チャネルの仕様を定義します。このプロトコルは、攻撃検出時に迅速な軽減措置を促進するために設計されています。利用場面は、インターネットサービスプロバイダーやデータセンターなど、DDoS攻撃のリスクがある環境です。
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
分散サービス拒否オープン脅威シグナリング（ドット）信号チャネル仕様
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 adheres to the DOTS architecture [RFC8811]. The requirements for the DOTS signal channel protocol are documented in [RFC8612]. This document satisfies all the use cases discussed in [RFC8903].
この文書はドットアーキテクチャ[RFC8811]に準拠しています。ドット信号チャネルプロトコルの要件は[RFC8612]に記載されています。この文書は[RFC8903]で説明したすべてのユースケースを満たします。
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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
(D)TLS is used for statements that apply to both Transport Layer Security [RFC5246] [RFC8446] and Datagram Transport Layer Security [RFC6347]. Specific terms are used for any statement that applies to either protocol alone.
（d）TLSは、トランスポート層セキュリティ[RFC5246] [RFC8446] [RFC8446]とデータグラムトランスポートレイヤセキュリティ[RFC6347]の両方に適用されるステートメントに使用されます。特定の用語は、どちらのプロトコルのみにも適用される任意のステートメントに使用されます。
The reader should be familiar with the terms defined in [RFC8612] and [RFC7252].
リーダーは[RFC8612]と[RFC7252]で定義されている用語に精通している必要があります。
The meaning of the symbols in YANG tree diagrams are defined in [RFC8340] and [RFC8791].
Yangツリー図のシンボルの意味は[RFC8340]と[RFC8791]で定義されています。
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信号チャネルは、UDPとTCPとTCPの両方で、（つまり、ポート番号4646のドット番号4646）の両方で、セクション10.1で定義されているようにポート番号4646を介して実行する必要があります。（4646とは対照的に）個別のポート番号を使用するには、DOTSクライアントとサーバーは、使用するポート番号を指定するための設定可能なパラメータをサポートする必要があります。
| 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 signal channel uses the "coaps" URI scheme defined in Section 6 of [RFC7252] and the "coaps+tcp" URI scheme defined in Section 8.2 of [RFC8323] to identify DOTS server resources that are accessible using CoAP over UDP secured with DTLS and CoAP over TCP secured with TLS, respectively.
シグナルチャネルは[RFC7252]のセクション6で定義されている「COAPS」URIスキームを使用し、[RFC8323]のセクション8.2で定義されている「COAP TCP」URIスキームを使用して、DTLSを介してCOAPを使用してアクセス可能なドットサーバーリソースを識別します。TCPをそれぞれTLSで固定したCOAP。
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.
ドットエージェントは、COAPメソッドの取得、挿入、および削除をサポートしている必要があります。2.xx応答コードを使用したCOAP応答に含まれるペイロードは、コンテンツタイプの「アプリケーション/ドットCBOR」でなければなりません。4.xxと5.xxエラー応答コードを使用したCOAP応答には、診断ペイロード（RFC7252]のセクション5.5.2）を含める必要があります。診断ペイロードは、トラブルシューティングを支援するための追加情報を含み得る。
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:
クライアントのネットワークとドットサーバーとの間で、1つ以上の翻訳者（例えば、従来のNAT [RFC3022]、CGN [RFC6146]、NTV6 [RFC6296]）が有効になっている展開では、任意のドット信号チャネルメッセージがAに転送されます。ドットサーバーには、内部IPアドレス/プレフィックスやポート番号を含めないでください。代わりに、トランスレータによって割り当てられた外部アドレス/プレフィックスおよび/またはポート番号を使用する必要があります。この文書は、可能な翻訳者の発見メカニズムについての推奨事項はありません。以下は考慮され得るいくつかの（網羅的な）展開例です。
* 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.
* Port Control Protocol（PCP）[RFC6887]または[STUN）[RFC8489]の[RFC6887] [RFC8489]は、外部アドレス/プレフィックスやポート番号を取得するためにクライアントによって使用されることがあります。PCPまたはSTUNによって取得された情報を使用して、ドットサーバーに送信されるドット信号チャネルメッセージを送ります。
* 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.
* ドットゲートウェイは翻訳者と同じ場所に配置することができる。ドットゲートウェイは、ローカルトランスレータのバインディングテーブルに基づいてドットメッセージを更新する必要があります。
The main changes to [RFC8782] are listed in Appendix A. These modifications are made with the constraint to avoid changes to the mapping table defined in Table 5 of [RFC8782] (see also Section 6 of the present document).
[RFC8782]の主な変更は付録Aに記載されています。これらの変更は[RFC8782]の表5で定義されているマッピングテーブルの変更を回避するための制約を使用して行われます（本文書のセクション6も参照）。
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値を要求する将来のドット拡張は、前述のドットテレメトリのものと同様の手段をサポートしなければなりません。
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"の登録名をサポートしている必要があります。各ドット操作は、意図された操作を示す経路接尾辞によって示される。操作経路（表1）は、所望のドット操作を実行するための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.
* 接続を正常に確立した後、ドットクライアントは特定の期間の各接続試行の結果に関する情報をキャッシュする必要があります。それはその情報を使用して、その後の試みでネットワークをスラッシングしないでください。キャッシュされた情報は、その年齢が数分程度の特定の期間を超えるとフラッシュされます（例えば、10分）。典型的には、幸せな眼球機構が完成した後、ドットクライアントが同じドットサーバとの接続を数秒以内に再確立する必要がある場合、キャッシュは特に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（ただし失敗した）で確立されている場合、ドットクライアントは、UDP上のDTLSとDOTS信号チャネルメッセージがドットサーバから利用可能になるかどうかを検出するためのメカニズムを定期的に繰り返します。これは、ドットクライアントがTCPからUDPへのドット信号チャネルを移行できるようになるためです。そのようなプロービングは24時間毎に頻繁に行われてはならず、5分ごとよりも頻繁に行われてはならない。
When connection attempts are made during an attack, the DOTS client SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms.
攻撃中に接続試行が行われると、ドットクライアントは「接続試行遅延」[RFC8305]を100 msに設定する必要があります。
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.
ドットエージェント間の単一のドット信号チャネルを使用して、複数のドット信号メッセージを交換することができます。ドットクライアントとドットサーバーのワークロードを減らすには、ドットクライアントは（D）TLSセッションを再利用する必要があります。
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].
ドットエージェントは、[RFC8085]のセクション3.1.3で説明したデータ伝送ガイドラインに従って、平均してピアトドットエージェントに1回以上のUDPデータグラムを1回以上送信してはいけません。
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]).
DOTSクライアントが確認できないメッセージとしてマークされた要求は、ドットサーバから応答が受信されるまで定期的に送信される。ドットクライアントがRTT推定値を維持できない場合は、3秒ごとに複数の不承認の要求を送信してはならず、可能な限り積極的なレートを使用する必要があります（[RFC8085のセクション2の場合2）。プロービングレートのチェックのために緩和要求を遅らせるべきではありません（[RFC7252]のセクション4.7）。
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クライアントは自分自身をドットサーバーに認証する必要があります（セクション8）。DOTSサーバーは[RFC7589]のセクション7に示されているアルゴリズムを使用して、クライアント証明書からドットクライアントIDまたはユーザー名を導きます。ドットクライアントアイデンティティを使用すると、ドットサーバは、ドットクライアントが管理を許可されているスコープで緩和要求を受け入れることができます。
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」に従わなければなりません。
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：クライアント固有の識別子を表します。グローバルに固有の識別子は、ドットクライアント、特に同じドメインのものの衝突を防ぐことを目的とした識別子です。ドットクライアントによって生成されなければなりません。
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」を設定する必要があります。まず、DOTSクライアントは、次のいずれかのものをSHA-256 [RFC6234]暗号化ハッシュに入力しています：DER符号化ASN.1表現Subject Public Key Info（SPKI）X.509証明書[RFC5280]、RAW Public Key [RFC7250]、TLS 1.2 ClientKeyExchangeメッセージ、または「ID」で使用されます。「PRE_SHARED_KEY」TLS 1.3拡張子で使用します。次に、暗号化ハッシュアルゴリズムの出力は16バイトに切り捨てられます。切り捨ては最後の16バイトを削除することによって行われます。切り捨てられた出力は、符号化から2つの末尾の「=」を除去したBase64URL符号化（[RFC4648]のセクション5）であり、その結果の値は「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」は、所与のドットサーバと通信するとき、すなわちドットクライアントによって使用される「CUID」が経時的に変化しないで安定することを意図している。異なる「cuid」値は、ドットサーバあたり単一のドットクライアントによって使用されてもよい。
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」にとって稼働している場合はそうしないことがあります。UDP上のドット信号メッセージの断片化を避けるために、「CUID」は22文字になる必要があります。さらに、ドット・クライアントがドット・データ・チャネルを使用してドット・サーバーのエイリアスとフィルタリング・エントリを作成した場合は、古い「CUID」にバインドされているすべてのエントリーを削除し、新しい「CUID」を使用してそれらを再インストールする必要があります。
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]).
ドットサーバは、「CUID」がすでに別のドットクライアントによって使用されていることを通知するために、4.09（競合）エラーコードをドットピアに返す必要があります。そのエラーコードを受信すると、新しい「CUID」はドットピアによって（例えば、[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.
クライアントドメインドットゲートウェイは「CUID」衝突を直接処理する必要があり、「CUID」の衝突はサーバドメインドットゲートウェイによって直接処理されることをお勧めします。
DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. Triggers for such rewriting are out of scope.
ドットゲートウェイは、ピアトドットクライアントによって使用される「CUID」を書き換えることができる。そのような書き換えのためのトリガは範囲外です。
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：整数で表される緩和要求の識別子。この識別子は、ドットクライアントにバインドされた各緩和要求に対して固有でなければならない、すなわち、緩和要求の「MID」パラメータ値は、アクティブの「MID」パラメータ値を基準にして（「CUID」およびドットサーバごと）である必要がある（「CUID」およびドットサーバごと）。ドットクライアントからドットサーバに伝達された緩和要求。
In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically.
緩和要求の順序配信を処理するために、「MID」値は単調に増加しなければなりません。
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）（すなわち3221225471）の3/4に達した場合、および攻撃が検出されない場合、ドットクライアントは '中央のロールオーバーを処理するために' mid 'to 0をリセットする必要があります。ドットクライアントが事前設定されたスコープで緩和要求を維持している場合は、0で再起動する 'MID'を再起動する必要があります。
This identifier MUST be generated by the DOTS client.
この識別子は、ドットクライアントによって生成されなければなりません。
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要求メッセージ本体に表示されてはならない（図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.
プレフィックスリストには、ブロードキャスト、ループバック、またはマルチキャストアドレスを含める必要があります。これらのアドレスは無効な値と見なされます。さらに、ドットサーバーは、ターゲットプレフィックスがドットクライアントドメインの範囲内にあることを検証する必要があります。他の検証チェックは、ドットサーバでサポートされている可能性があります。
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」のみが存在する場合は、単一のポート番号を表します。
For TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4340], a range of ports can be, for example, 0-1023, 1024-65535, or 1024-49151.
TCP、UDP、Stream Control Transmission Protocol（SCTP）[RFC4960]、またはデータグラム輻輳制御プロトコル（DCCP）[RFC4340]、さまざまなポートで、例えば0~1023,1024-65535、または1024-49151にすることができます。。
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アドレスに解決されると、ドットサーバーは 'target-prefix'の場合と同じ検証チェックを適用する必要があります。これらの検証チェックは、名前が基礎となる名前解決ライブラリ（例えば、DNS TTLの有効期限が切れる）に渡されるたびにドットサーバによって繰り返される。
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を検証するためにドットサーバーが続く必要があります。
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.
寿命：秒単位での緩和要求の存続期間。緩和要求の推奨寿命は3600秒です。この値は、クライアントが予期せずに終了したときにリクエストをタイムリーに期限が切れている間に、リフレッシュがドットクライアント上の負担ではないように十分に長くなるように選択されました。ドットクライアントは、緩和要求にこのパラメータを含める必要があります。
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）の寿命は、緩和要求のための不定寿命を示します。政策上の理由から、ドットサーバーは無期限の有効期間を拒否することがあります。付与されたライフタイム値は応答に返されます。ドットクライアントは、無期限の寿命で軽減されないように準備されなければなりません。
The DOTS server MUST always indicate the actual lifetime in the response and the remaining lifetime in status messages sent to the DOTS client.
ドットサーバは、常に応答内の実際の有効期間と、ドットクライアントに送信されたステータスメッセージ内の残りの有効期間を示す必要があります。
Upon the expiry of the negotiated lifetime (i.e., the remaining lifetime reaches '0'), and if the request is not refreshed by the DOTS client, the mitigation request is removed by the DOTS server. The request can be refreshed by sending the same request again.
交渉された寿命の有効期限（すなわち、残りの寿命が「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リクエストの「スコープ」アレイに複数のエントリを含めないでください。
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'が存在している必要があります。
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パラメータは、リクエスト全体が無効になるため、リクエストに存在しないでください。
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の攻撃トラフィックを受信している。「CDID」の存在が示されている。サーバードメインドットゲートウェイは、ドットクライアントによって送信された最初のPUTリクエストを変更しました。「CDID」は、PUTリクエストメッセージ本文に表示されてはならないことに注意してください。
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.
サーバードメインドットゲートウェイが有効になっている展開では、オリジンソースクライアントドメイン（ 'CDID'）に関するID情報をドットサーバーに伝播する必要があります。その情報は、同じドットドメインに属するドットクライアントのグループ化、ドット要求の数を制限し、軽減範囲の識別など、一部のポリシーを強制するのを支援することを目的としています。これらのポリシーは、クライアントごと、クライアントドメインごと、またはその両方を強制できます。また、識別情報は監査目的とデバッグ目的に使用されてもよい。
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:
サーバードメインドットゲートウェイは、次のURIパスパラメータを追加する必要があります。
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.
サーバードメインドットゲートウェイは、 'cdid'パラメータを挿入するかどうかを指示するための設定オプションをサポートする必要があります。
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クライアントX.509証明書のSPKIハッシュを供給する必要があります。「CUID」で運ばれたハッシュを生成するための同じ規則に従って、「CDID」のドットクライアント生の公開鍵、または「PSKアイデンティティ」のハッシュは、対応するものを決定するために最終的なドットサーバによって使用される。クライアントのドメインサーバードメインゲートウェイによって生成された「CDID」は、ドットメッセージがクライアントドメインドットゲートウェイによって中継された場合を除く「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 Clientがプロビジョニングされている場合は、異なるサーバードメインドットゲートウェイを同じドットサーバーにピアに使用するために使用するためにプロビジョニングされている場合、同じドットサーバーにピアが表示されます。異なる「CDID」の値は、サーバードメインドットゲートウェイによってサーバーへの供給されている可能性があります。。究極のドットサーバーは、それらのCDID '値を同等のものとして扱う必要があります。
The 'cdid' attribute MUST NOT be generated and included by DOTS clients.
'cdid'属性は生成されていて、ドットクライアントによって含まれていなければなりません。
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.
ドットサーバは、ソースドットクライアントまたはクライアントドメインドットゲートウェイによって直接供給される「CDID」属性を無視する必要があります。これは、最初のサーバードメインドットゲートウェイがドットクライアントによって提供される「CDID」属性をストリップする必要があることを意味します。ドットサーバーは、「CDID」属性を指定するのに信頼されているドットゲートウェイを識別するための構成パラメータをサポートする必要があります。
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パスです。存在する場合、「CDID」は「CUID」の前に配置する必要があります。
A DOTS gateway SHOULD add the CoAP Hop-Limit Option [RFC8768].
ドットゲートウェイは、COAP HOP-LIMITオプション[RFC8768]を追加する必要があります。
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.
ドットサーバは、ドットクライアントアイデンティティとオプションで 'CDID'パラメータ値を使用してドット信号とデータチャネルセッションを結合するため、ドットサーバは、緩和要求で伝達されたエイリアスが実際にドットを使用して同じドットクライアントによって作成されたかどうかを検証できます。データチャネルセッションエイリアスがドットクライアントによって作成されなかった場合、ドットサーバーは応答に4.00（不良要求）を返す必要があります。
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オプションには含まれていません。ドットエージェントは、理解していない理解任意のパラメータを安全に無視することができます（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).
'0'に設定された '0'で緩和要求を受信するドットサーバーは、4.00（不良要求）で返信する必要があります。
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.
ドットサーバがその構成データ内のPUT要求で伝達されている「MID」パラメータ値が見つからない場合、それはDOTSクライアントに2.01（作成された）応答を送り返すことによって緩和要求を受け入れることができる。その結果、ドットサーバーは攻撃を軽減しようとします。DOTSサーバは、例えば容量近くである場合、または特定のクライアントをレート制限する必要があるときに緩和要求を拒否することができる。
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:
ドットクライアントからの同じ「トリガ緩和」タイプを有する2つの緩和要求の相対順序は、それらのそれぞれの「MID」値を比較することによって決定される。同じ「トリガ緩和」タイプを持つ2つの緩和要求が緩和スコープを重複している場合、最大の数値「MID」値を持つ緩和要求は他の緩和要求をオーバーライドします。共通のIPアドレス、IPプレフィックス、FQDN、URI、またはエイリアスがある場合、ドットクライアントからの2つの緩和要求は重複スコープを持ちます。ドットクライアントから重複する緩和要求の長いリスト（つまり、同じ 'トリガー軽減の'タイプおよび重複スコープを要求する）を維持し、ドットクライアントからの緩和要求のエラーが発生するのを避けるために、オーバーラップされた下位数値'mid'は自動的に削除されなければならず、ドットサーバーではもう利用できません。たとえば、DOTSサーバーが既存の軽減と同じ数値の「MID」と重なる緩和要求を受け取ると、ドットサーバーはドットクライアントに4.09（競合）を返すことによって要求を拒否します。 「競合情報」サブツリー（セクション5.1）に記載されているように、ドットクライアントのための十分な情報は、関連するノードだけがリストされています。
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:
競合 - 原因：競合の原因を示します。次の値を返す必要があります。
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サーバーがアクティブな緩和要求と重なる緩和要求を受信したが両方とも異なる「トリガ軽減」タイプがある場合、ドットサーバは非アクティブ化（明示的なポリシー/構成が不在）「トリガ軽減」セットを使用した軽減要求'False'へ。特に、「false」に設定されている「トリガ緩和」を使用した緩和要求がアクティブである場合、ドットサーバは緩和要求を引き出し（すなわち、表3で定義されているように「7」に設定される）、その状態を遷移させる。「8」への緩和要求。
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.
ドット信号チャネルセッション損失がピアトドットクライアントであると、ドットサーバは（特に明示的なポリシー/構成が不在）（そうでなければ）そのドットクライアントから 'false'に設定されている緩和要求と重複する能動的な緩和要求を撤回する必要があります。セッションの損失が暗黙のうちにこれらの事前設定された緩和要求を暗黙のうちに起動し、優先されます。ドットサーバのイニシアチブで撤回された軽減のために、アクティブボタン末尾期間は観察されないことに留意されたい。
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:
要求が異なるドットクライアントからの既存の軽減要求と競合する場合、ドットサーバは、要求側のドットクライアントに2.01（作成）または4.09（競合）を返すことがある。ドットサーバが新しい緩和要求を維持することを決定した場合、ドットサーバは要求側のドットクライアントに2.01（作成）を返します。ドットサーバが新しい緩和要求を拒否することを決定した場合、ドットサーバは要求側のドットクライアントに4.09（競合）を返します。2.01（作成）と4.09（競合）応答の両方について、以下に説明するように競合の原因を認識するためにドットクライアントに十分な情報を含める必要があります。
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衝突。このコードは、ドットクライアントがすでに別のドットクライアントによって使用されている「CUID」を使用しているときに返されます。このコードは、要求が拒否され、新しい「CUID」を持つ新しい要求は、ドットクライアントによって再送信されることがあることを示しています（図11に示す例を参照）。'conflict-status'、 'conflict-scope'、および 'retry-timer'をエラー応答に返されてはいけません。
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'はアクティブな緩和要求の存続期間に等しくなり、競合する緩和要求が無効になります。
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」値を使用する必要があります。これは、「Lifetime」パラメータ値に変更可能な変更から、元の緩和要求で送信された他のすべてのパラメータを繰り返す必要があります。そのような場合、ドットサーバは、残りの寿命を新たにネゴシムされた寿命に設定することによって緩和要求を更新し、2.04（変更）応答が返され、緩和要求の成功の更新が示す。そうでない場合、ドットサーバーは4.00（不良要求）で要求を拒否する必要があります。
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パスパラメータは、要求に存在してはなりません。
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で指定されたサーバードメインドットゲートウェイで「CDID」パラメータを操作するための同じ考察は、取得要求のために続いている必要があります。
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」（Content）パラメータとその許容値を使用して、非構成データ（攻撃軽減状態）、構成データ、またはその両方を検索できます。ドットサーバは、このオプションのフィルタリング機能をサポートすることがあります。サポートされていない場合は安全に無視できます。DOTSクライアントがオプションのフィルタリング機能をサポートしている場合は、DDOS攻撃がある場合は、「C = N」クエリ（動的に変更されたデータのみに戻す）または「C = C」のクエリ（静的設定値を取得するには）を使用する必要があります。応答のサイズを制限するためにアクティブです。
+=======+=====================================================+
| 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.
ドットクライアントは、ドットサーバーによって維持されているすべての軽減のリストを取得するためにブロックワイズ転送[RFC7959]を使用できます。応答のサイズを制限するのに役立つように、num = 0の取得要求にblock2オプションを送信できます。ドットクライアントに関連付けられているすべてのアクティブな緩和要求の表現が単一のデータグラム内に収まらない場合、ドットサーバーはGETレスポンスでnum = 0でblock2オプションを使用する必要があります。 size2オプションは、リソース表現の合計サイズを示すために応答で伝えられます。 DOTSクライアントは、ゼロより大きいNUM値を含むBlock2オプションを使用して追加のGETリクエストを送信することによって、表現の残りの部分を取得します。ドットクライアントは、応答内のドットサーバーによって示されているブロックサイズの環境設定に準拠している必要があります。 DOTSサーバーがGET応答でBLABS2オプションを使用しており、応答は動的に変更されたリソース（ "C = N"または "C = A"クエリなど）の場合、ドットサーバーは応答にetagオプションを含める必要があります。 。ドットクライアントは、残りの表現を取得するための後続のGET要求で同じETAG値を含める必要があります。
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'.
ドットサーバが要求されているドットクライアントの設定データでGETリクエストで伝送されている「MID」URIパス値が見つからない場合は、4.04（NOTが見つかりません）エラー応答コードで応答する必要があります。同様に、ドットサーバーがそのドットの軽減レコードが見つからない場合は、すべての軽減レコードを取得する要求に対する応答として同じエラーを返信する必要があります（つまり、 'MID' URIパスは定義されていません）。クライアント。リマインダとして、ドットクライアントはその識別情報（例えば、クライアント証明書、「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.
緩和 - 開始：緩和開始時刻は、UTC時間の1970-01-01T00：00Zを比較して秒単位で表されます（[RFC8949]のセクション3.4.1）。CBOR符号化は、先行タグ1（EPOCHベースの日時）を省略しなければならないように修正される。
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ドロップされた：攻撃軽減以降の緩和要求のための毎秒1秒あたりの平均ドロップバイト数。この平均は5分の間隔（つまり、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ドロップ：攻撃軽減以降の緩和要求のための毎秒1秒あたりのドロップパケットの平均数。この平均は5分以上の間隔であるべきです（つまり、緩和がトリガーされてからのパケットを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]で定義されている監視オプションは、CoAPクライアントがCoAPサーバー上のリソースを「監視する」ためのメカニズムでCoAPコアプロトコルを拡張します。クライアントはリソースの表現を取得し、この表現をサーバーによって更新する要求を長く更新します。クライアントがリソースに興味があるように。ドットの実装は、 'mitigate'と 'config'の両方の観察オプションをサポートしなければなりません（セクション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）確認可能または確認不可能なメッセージで通知を送信できることを示し、（2）使用されるメッセージタイプは通常アプリケーションに依存し、各通知のためにサーバーによって個別に決定される可能性があることを示しています。DOTSサーバーアプリケーションの場合、基盤となるCOAPライブラリが確認可能なメッセージで送信される通知を選択しても、メッセージタイプは常に確認不能に設定されている必要があります。これにより、[RFC7641]のセクション4.5で定義されていない動作を次の理由で少なくとも24時間ごとに確認可能なメッセージの代わりに確認可能なメッセージを送信します。まず、DOTS信号チャネルは、ドットクライアントがかどうかを判断するためにハートビートメカニズムを使用します。生きている。第二に、確認可能なメッセージは攻撃中には適していません。
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サーバーがRTT推定値を維持できない場合は、3秒ごとに複数の非同期通知を送信してはいけません（[RFC8085]のセクション2のケース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.
競合のために緩和要求が無効になっていることを示す競合通知メッセージを受信すると、ドットクライアントは「再試行タイマ」の有効期限の前に同じ軽減要求を再送信してはいけません。ドットクライアントが緩和競合について管理者に警告するための手段をサポートすることも推奨されます。
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.
ドットサーバーから通知を受け取ることに興味がなくなったドットクライアントは、観察を「忘れる」ことができます。ドットサーバが次の通知を送信すると、ドットクライアントはメッセージ内のトークンを認識しないため、リセットメッセージを返します。これにより、ドットサーバーは関連付けられているエントリを削除します。あるいは、ドットクライアントは、テクスフィールドを検知のトークンに設定しているGET要求を発行することによって明示的に登録され、値を「1」に設定されている（登録解除）に設定された監視オプションを含むことができる。後者はより確定的であり、したがって推奨される。
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クライアントは、視覚要求の構成データと非構成データ（すなわち、攻撃状況）を検索するために、観察オプションなしに頻繁な間隔でGET要求を送信することができる。ドットクライアントは、軽減の状態を得るためのポーリングドットサーバーの頻度を示すポリシーで構成されてもよい。[RFC8085]のセクション3.1.3で説明したように、この周波数はRTTごとに複数のUDPデータグラムにしてはなりません。
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.
ドットクライアントは、攻撃が軽減されたことで、ドットサーバーによって送信された情報ごとに攻撃のステータスに反応します。これにより、ドットクライアントがそのリソースに対するDDOS攻撃を検出しない可能性があるため、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軽減が進行中であるが、パケット損失の可能性のために、ドットクライアントは定期的にドット緩和有効性更新を関連するドットサーバに送信することができる。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」パラメータ値とは別に、ドット緩和要求（セクション4.4.1）を使用しないPUTリクエストで使用されるすべてのパラメータを含める必要があります。そうでない場合、ドットサーバーは4.00（不良要求）で要求を拒否する必要があります。
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」パラメータを操作するための同じ考察は、削除要求について続く必要があります。空の値を持つURIパスパラメータは、要求に存在してはなりません。
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).
削除要求に「cuid」と 'mid'のパラメータが含まれていない場合、ドットサーバーは4.00（不良要求）で返信する必要があります。
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).
ドットサーバがドットクライアントの構成データ内の削除要求で伝達された「MID」パラメータ値を見つけた場合、ドットクライアントによって引き起こされるルートまたはDNSフラッピングから保護し、迅速に軽減を抑制し、振動攻撃の影響を減衰させる、ドットサーバは、ドットクライアントの緩和要求の撤退を認めた後、緩和が限られた期間を継続させることができる。この期間中、DOTSサーバーのステータスメッセージは、緩和がアクティブであるが終了していることを示している必要があります（セクション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).
経路伝播によって発生した待ち時間を吸収するのに十分な長期的であるべきである。アクティブながら終端期間は、デフォルトで120秒に設定する必要があります。最初のアクティブで終わる期間が経過する前にクライアントが再び緩和を要求した場合、ドットサーバーは指数関数的に増加する可能性があります（指数の基部は2）、最大300秒（5分）までのアクティブでターミナルの期間です。。
Once the active-but-terminating period elapses, the DOTS server MUST treat the mitigation as terminated.
アクティブながら終端期間が経過すると、ドットサーバーは緩和を終了したときに治療する必要があります。
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.
信号チャネル損失のために緩和がトリガされた場合、ドットサーバは通常のトリガに依存して、その軽減を停止する（通常は有効な削除要求の受信、軽減寿命の有効期限、またはトラフィックを攻撃対象にスクラブする）。特に、ドットサーバーは、軽減を停止するためのトリガとしての信号チャネルの回復を考慮してはいけません。
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'）。これは、アクティブドットクライアントが緩和を要求していないときに、ハートビート頻度を減らすことができるか、またはハートビート交換を中止することができるドットサーバーに特に役立ちます。異なる構成が使用されている場合、ドットエージェントは緩和アクティビティの関数として設定された適切な構成セットに従う必要があります（たとえば、軽減要求がアクティブな場合（IDLE '時間とも呼ばれます）、' idle-config 'に関連する値は必須です。続く。さらに、ドットエージェントは、緩和アクティビティの変更時に自動的に他の構成に切り替わらなければなりません（たとえば、「アイドル状態の後に起動された場合は、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).
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要求は、ドット信号チャネルセッション構成については、ドットサーバ上の許容可能な（例えば、最小値および最大値）および現在の構成パラメータを取得するために使用される。この手順は、ドットクライアントとその即時ピアトドットサーバーの間で発生します。そのように、この取得要求はドットゲートウェイによって中継されてはならない。
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で定義されています。送信パラメータ値の推奨値は、 'ACK-TIMEOUT'（2秒）、 'max-retransmit'（3）、および 'ACKランダムファクタ'（1.5）です。これらのパラメータに加えて、推奨される特定のドットの送信パラメータ値は「ハートビートインターバル」（30秒）と「欠けている - HB-許可」（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.
ドットエージェントがメッセージ送信パラメータのデフォルト値を変更したい場合は、[RFC7252]のセクション4.8.1に記載されているガイダンスに従ってください。ドットエージェントは、メッセージ送信パラメータおよび非ネゴシエートされていないメッセージ送信パラメータのデフォルト値のネゴシエートされた値を使用する必要があります。
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.
信号チャネルセッション構成は、ドットエージェント間の単一のドット信号チャネルセッションに適用可能であるので、「CUID」URI経路を使用してはいけません。
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：セッション識別子は、整数として表されるドット信号チャネルセッション構成データの識別子です。この識別子はドットクライアントによって生成されなければなりません。「SID」値は単調に増加しなければなりません（Signal Channelの設定パラメータを伝えるために新しい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.
属性 'ハートビートインターバル'、 'Missing-Hb-Allow'、 'Probing-Rate'、 'Max-Retransmit'、 'Ack-Random-Factor'、および 'Ack-Random-Factor'、およびAck-Random-Factor '、およびAck-Random-Factor'、および 'Ack-Random-Factor'は、PUTリクエスト。'ハートビートインターバル'、 'Missing-Hb-許可'、 'プロービングレート'、 'max-retransmit'、 'ack-rangeout'、および 'ack-random-factor'、 'ack-random-factor'、 '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リクエストは、PUTリクエストによってインストールされたドットシグナルチャネルセッション構成データが、低い数値の 'SID'値でオーバーライドします。つまり、ドットサーバーのデフォルトの代わりに、数値の「SID」値を持つPUT要求に含まれている構成パラメータが使用されます。ドットクライアントからの「SID」要求の長いリストを維持することを避けるために、下位数値の「SID」は自動的に削除され、ドットサーバーでは使用できなくなりました。
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パスを含めたり、1つ以上の無効または不明なパラメータを含んでいません.4.00（不良要求）を返信してください。
* 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.
* ドットサーバが構成データ内のPUT要求で伝達された「SID」パラメータ値が見つからない場合、およびドットサーバが構成パラメータを受け入れた場合は、応答コード2.01（作成）を応答に返す必要があります。
* 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.
* ドットサーバが構成データ内のPUT要求で伝達された「SID」パラメータ値を見つけ、ドットサーバが更新された構成パラメータを受け入れた場合、2.04（変更）は応答に返されなければならない。
* 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).
* 「ハートビートインターバル」、 'Missing-HB-許可'、 'プロービングレート'、 'max-retransmit'、 'target-protocol'、 'ack-timeout'、および 'ack-random-factor'のいずれかの場合属性値はドットサーバーには受け入れられません、4.22（未処理のエンティティ）は応答に返されなければなりません。このエラーコードを受信すると、ドットクライアントはドットサーバに受け入れ可能な最大値と最小属性値を取得する必要があります（セクション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.
有効期限を送信する設定で有効期間を関連付けるために、MAX-AGEオプション（[RFC7252]のセクション5.10.5）をドットサーバーによって返す必要があります。この機能は、ドットサーバ側で変更が発生した場合にクライアントが更新された構成データを検索するように強制します。例えば、新しい構成は、ハートビートを中止するか、または心拍の周波数を減らすようにドットクライアントに指示することができる。
It is NOT RECOMMENDED to return a Max-Age Option set to 0.
MAX-AGEオプションを0に設定することはお勧めできません。
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オプションがドットクライアントによって受信された場合、MAXで囲まれた値の有効期限が切れる前に、現在および許容できる設定を取得するには、「SID」URI-PATHパラメータを使用してGETリクエストを発行する必要があります。オプションオプション。この要求は、シグナルチャネルの構成パラメータを更新するための手段となるように、クライアントとサーバと見なされる。DDOS攻撃がアクティブな場合は、リフレッシュ要求はドットクライアントによって送信されてはならず、DOTSサーバーはMAX-AGEオプションで返された値の有効期限が切断された後に（D）TLSセッションを終了してはいけません。
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オプションが応答で返されない場合、ドットクライアントは60秒ごとに構成パラメータを更新する要求が取得を開始します（[RFC7252]のセクション5.10.5）。そのような過負荷を防ぐために、GET応答でドットサーバーが最大エージングオプションを返すことをお勧めします。どの値を使用するかとそのような値がどのように設定されているかに関する考慮事項は、実装と展開固有です。
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サーバーがドットサーバーに接続されていないことをドットサーバーが検出した場合は、（D）TLSセッションを終了できます。（D）TLSセッションは、接続を閉じる認証されたメッセージの受信（例えば、致命的な警告（RFC8446]））によって終了する。
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'.
ブートストラップまたは再起動時に、ドットクライアントは、構成パラメータをデフォルト値に設定するための削除要求を送信することができます。そのような要求には「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.
代替ドットサーバーTTLが期限切れになっている場合、ドットクライアントはセクション4.1で説明した手段を使用してプロビジョニングされたドットサーバーを使用する必要があります。このフォールバックメカニズムは、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を尊重するか、または明示的なリダイレクトメッセージに反応することを守らないドットクライアントが誤って発行された要求は、ドットサーバーによって拒否される可能性があります。
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応答を受信すると、現在のリクエストが失敗したことを考慮しますが、その要求を代替ドットサーバーに再送するようにしてください。 DDOS攻撃の間、DNSサーバーは別のDDOS攻撃のターゲットである可能性があります。 5.03応答で伝達された代替ドットサーバーのIPアドレスは、最初のドットサーバーを信頼するための代替ドットサーバーのDNSルックアップをスキップして正確な情報を提供するコストで、DOTSクライアントがSCをスキップします。その後、ドットクライアントは、代替ドットサーバーとのUDPまたはTCPセッションを確立しようとします（セクション4.3）。状態同期（例えば、信号セッション構成、エイリアス）は、元のドットサーバと代替ドットの間の位置にあると見なされます。そのような同期手段は範囲外である。リダイレクトが整っている間にセッション構成の更新が必要な場合、DOTSクライアントはセクション4.5.3で定義されている手順に従います。 「アイドル」時間と状況（例えば、無限の構成の有効期間、無限リダイレクトTTL、および構成の更新の失敗）で、DOTSクライアントはセクション4.5.2で定義されている手順に従い、ドットシグナルチャネルセッション構成を次のようにネゴシエートします。代替サーバードットクライアントは、IPv4内蔵IPv6アドレス[RFC6052]を構築する方法を実装することができます。これは、IPv6専用のドットクライアントがIPv4専用の代替ドットサーバーと通信するシナリオを処理する必要があります。
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.
最後の5分以内に既に通知されているドットクライアントにリダイレクトされたドットサーバーにリダイレクトされている場合は、リダイレクトを無視して、ローカル構成にリストされている他のドットサーバーに連絡してください。DHCPまたはSRVの手順[RFC8973]として。ドットクライアントがリダイレクトループについて管理者に警告する手段をサポートすることをお勧めします。
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.
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ハートビートメカニズムは、予想される2.04（変更）応答コードを使用して、確認不可能なPUTリクエスト（図27）を使用します（図28）。この手順は、ドットエージェントとその即時ピアトドットエージェントとの間で起こる。そのように、このput要求はドットゲートウェイによって中継されてはならない。ドットハートビートに使用されるPUTリクエストは、「CUID」、「CDID」、または「MID」URIパスを持たないでください。
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.
ドットサーバーは、ピアトドットクライアントからハートビートプローブを受信した直後に、ハートビート要求をトリガーすることがあります。オンパストランスレータ/ファイアウォールがバインディングを維持していることは、ドット信号チャネルセッションのために同じ外部IPアドレスおよび/またはポート番号が保持されるように、ドットクライアントの責任です。
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.
通常のトラフィック条件下（つまり、攻撃は進行中です）で、ドットエージェントがピアドットエージェントから「Missing-HB-許可」個の連続したハートビートメッセージの数を受信しない場合、ドット信号チャネルセッションは終了します。切断されました。その場合、ドットクライアントは、（D）TLSセッションを再開することによって、ドット信号チャネルセッションを再確立しようとする必要があります。
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.
注：新しいドットシグナルチャネルセッションを確立できない場合、ドットクライアントは300秒ごと（5分）より頻繁にドット信号チャネルセッションを確立し、60秒ごと（1分）よりも頻繁に再試行してはいけません。。ドットクライアントは、（D）TLSセッションを確立できなかった場合に管理者に警告するための手段をサポートすることをお勧めします。
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サーバーは、によって送信されたドットメッセージに加えてハートビート要求を受け取ります。ドットクライアント。このシナリオでは、ドットクライアントは、リンク飽和時のメッセージ送信とドット信号チャネルセッションの生活性を処理するために異なる動作をしなければなりません。
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クライアントは、最大の「欠損HB-許可」しきい値に達すると、ドット信号チャネルセッションを終了してはいけません。ドットクライアントがドット・クライアントがドット・シグナルチャネル・セッションを切断していないことを知っているように、ドット・クライアントは現在のドット・シグナルチャネル・セッションを使用してハートビート・リクエストを送信する必要があります。
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-許可'しきい値に達すると、ドットクライアントは新しいドット信号チャネルセッションを確立しようとするはずです。ドットクライアントは、現在のドット信号チャネルセッションを介して緩和要求を送信し、並行して新しいドット信号チャネルセッションを介して緩和要求を送信する必要があります。これは、例えば、（D）TLSセッションの再開またはDTLS 1.3で0-RTTモードを使用して、ClientHelloメッセージ内の緩和要求をピギーバックすることによって処理することができる。
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.
ドットサーバがピアドットクライアント（例えば、ピアドットクライアント開始ハートビート）からトラフィックを受信するが、最大 'Missing - Hb許可'しきい値に達すると、ドットサーバはドット信号チャネルセッションが切断されていると検討してはいけません。ドットクライアントが現在のドット信号チャネルセッションを介して緩和要求を送信できるように、ドットサーバは現在のドット信号チャネルセッションを使用し続ける必要があります。この場合、ドットサーバは、ドットクライアントが攻撃中であり、ドットクライアント（ドメイン）への着信リンクが飽和していることを識別することができる。さらに、ドットサーバがドットクライアントから軽減要求を受信しない場合、ドットクライアントが攻撃を検出していないこと、または攻撃の軽減が進行中である場合、それは適用されたDDOの緩和措置がまだ効果的ではないことを意味する。DDOS攻撃ボリュームを処理します。
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 module uses the common YANG types defined in [RFC6991] and types defined in [RFC8783].
このモジュールは[RFC6991]で定義されている一般的なYANTタイプと[RFC8783]で定義されています。
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.
表5に示すように、DOT信号チャネルのペイロード内のすべてのパラメータはCBORタイプにマッピングされなければならず、スペースを節約するための整数キーが割り当てられています。
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キー値は2つのタイプに分けられます。理解が必要で理解されています。ドットエージェントは、理解していない理解のオプションの値を安全に無視することができますが、理解されていない理解の必要な値が含まれている場合は、要求を正常に処理できません。4.00応答には、未知の理解が必要なCBORキー値を記述する診断ペイロードを含める必要があります。本明細書で定義されているCBORキー値の初期セットは、理解が必要です。
+=====================+==============+======+=============+========+
| 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.
Man-In-the-the-the-the-the-the-the-the-thredgrade攻撃など、既知の攻撃があります。これらは（D）TLSの一般的な攻撃であり、したがって、それらは（D）TLSのドットに固有のものではありません。これらのセキュリティ問題について説明するには、（D）TLS RFCを参照してください。ドットエージェントは、（D）TLSバージョンに関しては、[RFC7525]の[RFC7525]のセキュリティ上の考慮事項を（D）TLSの実装の推奨事項とセキュリティ上の考慮事項を遵守しなければなりません。（D）TLSに依存しているドット信号チャネル暗号化は実質的にグリーンフィールド展開であるため、ドットエージェントは（D）TLS 1.2以降だけを実装する必要があります。
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.
ドットクライアントがドットサーバのドメイン名で構成されており、設定されたドットサーバに接続されている場合、サーバはそれをPKIX証明書で提示することができる。適切な認証を確実にするために、ドットクライアントは[RFC5280]ごとの認証パス全体を検証する必要があります。さらに、ドットクライアントはドメイン名を提供された証明書と比較するために[RFC6125]検証技術を使用する必要があります。DOTSサーバー証明書を発行する認証局は、DNS-IDおよびSRV-ID識別子型をサポートする必要があります。ドットサーバは、証明書要求における共通名ID（CN - ID）識別子型でDNS - IDとSRV - IDの使用を好む（[RFC6125]のセクション2.3）、およびワイルドカード文字 '*'ではないはずです。提示された識別子に含まれています。ドットはサーバーID検証に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クライアントにSNI拡張子にドットサーバーFQDNを含める必要があります。
Implementations compliant with this profile MUST implement all of the following items:
このプロファイルに準拠した実装は、以下のすべての項目を実装する必要があります。
* 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セッション再開。
* At least one of raw public keys [RFC7250] or PSK handshake [RFC4279] with (EC)DHE key exchange. This reduces the size of the ServerHello. Also, this can be used by DOTS agents that cannot obtain certificates.
* RAW Public Keys [RFC7250]またはPSKハンドシェイク[RFC4279]の少なくとも一方（EC）DHEキー交換。これにより、ServerHelloのサイズが小さくなります。また、証明書を入手できないドットエージェントで使用できます。
Implementations compliant with this profile SHOULD implement all of the following items to reduce the delay required to deliver a DOTS signal channel message:
このプロファイルに準拠した実装は、ドット信号チャネルメッセージを配信するために必要な遅延を減らすために、以下のすべての項目を実装する必要があります。
* 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をサポートするドットサーバは、ドットクライアントが早期データ（0-RTT）を送信することを可能にし得る。ドットクライアントは、早期データとして「COAP PING」を送信してはいけません。そのようなメッセージはドットサーバーによって拒否されなければなりません。[RFC8446]のセクション8は、0-RTTデータに対する再生攻撃の影響を制限するために実装するメカニズムをいくつか説明します。ドットサーバが0 - RTTを受け入れると、TLSレイヤでの再生を防ぐためにこれらのメカニズムの1つを実装する必要があります。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信号チャネルメッセージは、IDEmpotent要求です。リマインダーとして、新しいCOAP要求が送信されるたびにメッセージID（[RFC7252]のセクション3）が変更され、各COAP要求でトークン（[RFC7252]のセクション5.3.1）がランダム化されます。ドットサーバは、ドット信号チャネルメッセージ内のメッセージIDとトークンを使用して、アプリケーション層での早期データの再生を検出し、同じドットクライアントから最大0-RTTデータを受け入れる必要があります。この再生対象防止防御は、ドットサーバドメイン内のドットサーバ間で0 - RTTデータ内のメッセージIDとトークンを共有することを必要とする。ドットサーバーは、ドットピアを識別するための輸送座標に依存しません。セクション4.4.1で指定されているように、ドットサーバーは、ドットクライアントアイデンティティとオプションで 'CDID'パラメータ値を使用してドット信号チャネルセッションを結合します。さらに、「MID」値は各緩和要求についてドットクライアントによって単調に増加し、したがって、より低い数値の「MID」値および重複スコープをより高い数字の「中MID」値を有する緩和要求を有する攻撃者は、体系的に拒否されるであろう。ドットサーバー同様に、「SID」値は、各構成要求についてドットクライアントによって単調に増加しています（セクション4.5.2）。攻撃者は、このドットクライアントにとってより高い数値の「SID」値を維持する場合、数値の低い設定要求を再生することは、ドットサーバによって拒否されます。
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]).
ドット信号メッセージの断片化を避けるために、メッセージ配信の確率が低下した後に、DLTSレコードは単一のデータグラムの中に収まる必要があります[RFC6347]。DTLSは、アプリケーションデータではなくハンドシェイクメッセージのみに断片化と再構成を処理します（[RFC6347]のセクション4.1.1）。パスMTU（PMTU）を検出できない場合、IPv6は、[RFC8200]で指定されているように、インターネット内のすべてのリンクが1280オクテット以上のMTUを持つ必要があるため、ドットエージェントは1280バイトのPMTUを想定する必要があります。Legacyまたは異常なネットワーク上のIPv4のサポートが考慮されており、PMTUが不明な場合、DOTS実装はIPv4データグラムのための576バイトのPMTUを仮定することができます（[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 Message Size DTLS 1.2オービエットのオーバーヘッド13オクテット認証オーバーヘッドのオーバーヘッド]（[RFC6347]のセクション4.1.1.1）以上でなければなりません。合計要求サイズがPMTUを超えると、ドットクライアントはドット信号を別々のメッセージに分割する必要があります。たとえば、 '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].
(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.
ドットサーバーは証明書ベースのクライアント認証をサポートする必要があります。ドットクライアントは、ドットクライアントによって保持されているPKIX証明書を使用して、ドットサーバーのTLS CertificateRequestメッセージに応答する必要があります。ドットクライアント証明書検証は[RFC5280]ごとに実行する必要があり、ドットクライアント証明書は[RFC5280]証明書プロファイルに準拠している必要があります。ドットクライアントがTLSクライアント証明書認証をサポートしていない場合は、事前共有キーまたはRAW公開鍵に基づいてクライアント認証をサポートする必要があります。
+---------------------------------------------+
| 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：/で利用可能な「サービス名とトランスポートプロトコルポート番号レジストリ」からUDPとTCPの両方のドット信号チャネルプロトコルにポート番号4646（ ".."））を割り当てました。/ww.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]
サービス名：ドット - 信号ポート番号：4646トランスポートプロトコル：TCP説明：配布サービス拒否オープン脅威シグナリング（ドット）信号チャネルプロトコル。サービス名は、ドット信号チャネルを確立するために使用されるドットサーバを検出するためのSRVサービス名「_dots-signal._udp」および「_dots-signal._tcp」を構築するために使用されます。譲受人：IESG連絡先：IETF議長登録日：2020-01-16参考文献：[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]
サービス名：ドット - 信号ポート番号：4646トランスポートプロトコル：UDP説明：Service拒否サービス拒否シグナリング（ドット）信号チャネルプロトコル。サービス名は、ドット信号チャネルを確立するために使用されるドットサーバを検出するためのSRVサービス名「_dots-signal._udp」および「_dots-signal._tcp」を構築するために使用されます。譲受人：IESG連絡先：IETF議長登録日：2020-01-16参考文献：[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データ構造がドット信号チャネルオブジェクトであることを宣言するアプリケーション用の他の手段として、ドットCBOBOBORタグを定義します。その使用は任意であり、この情報がそうでなければ知られていない場合に使用することを意図している。このドキュメントで指定されたドット信号チャネルプロトコルのバージョンには、ドットCBORタグが必要とされません。存在する場合、ドットタグはドット信号チャネルオブジェクトを接頭辞める必要があります。
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キー値：パラメータのキー値。キー値は1-65535範囲の整数でなければなりません。
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：初期ドット信号チャネルステータスコード
New codes can be assigned via Standards Action [RFC8126].
新しいコードは、標準アクション[RFC8126]を介して割り当てることができます。
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：初期ドット信号チャネル競合ステータスコード
New codes can be assigned via Standards Action [RFC8126].
新しいコードは、標準アクション[RFC8126]を介して割り当てることができます。
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：初期ドット信号チャネルの紛争原因コード
New codes can be assigned via Standards Action [RFC8126].
新しいコードは、標準アクション[RFC8126]を介して割り当てることができます。
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：初期ドット信号チャネル攻撃ステータスコード
New codes can be assigned via Standards Action [RFC8126].
新しいコードは、標準アクション[RFC8126]を介して割り当てることができます。
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]
IANA has registered the additional following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. This obsoletes the registration in [RFC8782].
IANAは、「Yang Parameters」レジストリ内に「Yang Module Names」サブレジスト[RFC6020]に追加の次のYangモジュールを登録しました。これにより、[RFC8782]の登録が廃止されます。
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]で定義されているように更新する必要があります。
High-level DOTS security considerations are documented in [RFC8612] and [RFC8811].
高水準ドットセキュリティ上の考慮事項は[RFC8612]と[RFC8811]に記載されています。
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.
認証された暗号化は、データの機密性とメッセージの整合性に使用する必要があります。ドットエージェント間の相互作用は、機密保護を提供する暗号スイートを使用してデータグラムトランスポート層セキュリティ（DTLS）またはトランスポートレイヤセキュリティ（TLS）を必要とし、[RFC7525]で与えられたガイダンスは（D）TLSの攻撃を回避する必要があります。ドット信号チャネルに使用される（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.
同じドットクライアントからの新しい 'CUID'値を含むレート制限ドット要求は、DOS攻撃に対してDOS攻撃に対してDOTSサーバーリソースを排気することになるでしょう。レートリミットポリシーは、ドットゲートウェイ（デプロイされている場合）およびドットサーバーで強制されるべきです。
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.
クライアントのドメイン外の内部情報の漏洩を防ぐために、クライアントドメイン内にあるドットゲートウェイは、明示的に実行されるように構成されていない限り、内部ドットクライアント（例えば、送信元IPアドレス、クライアントのホスト名）に関連する識別情報を明らかにしないでください。
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.
ドットサーバーは、ドットクライアントの要求が特定のIPプレフィックスでアクションをトリガーする権利があることを確認する必要があります。ドットサーバーは、そのドットクライアントのドメインIPリソースに限定されない限り、ドットクライアント要求のためにアクションを許可してはいけません。ターゲットプレフィックスがドットクライアントドメインの範囲内にあることを検証するためのドットサーバの正確なメカニズムは展開固有のものです。
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]).
FQDNがターゲットとして使用される場合、DOTSサーバーはDNSプライバシー有効化プロトコル（例えば、TLS over TLS [RFC7858]またはDNS over https over https（DOH）[RFC8484]）に頼らなければなりません。盗聴者がターゲットFQDN解決が本物であることを確認するためのDDOSの軽減サービス（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.、Field、R.、および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、<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.および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.および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.、および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-編集者。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]イーストレイク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.および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.、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.、C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。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.および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.、B. Moeller、「トランスポート層セキュリティ（TLS）偽のスタート」、RFC 7918、DOI 10.17487 / RFC7918、2016年8月、<https：//www.rfc-編集者.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.および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および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.、および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]綿、M.、Leiba、B.および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] The'th、S.および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.および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.、およびB.Raymor、Ed。、TCP、TLS、およびWebocketsの上のCOAP（制約付きアプリケーションプロトコル）"、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]ノッティンガム、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-編集者。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.、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.および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>.
[コア - 昏睡] Veillette、M.、ED。、Stok、P.、Ed。、Pelov、A.、Bierman、A。、そしてI。Petrov、「Coap Management Interface（CORECONF）」、進行中、インターネット--draft、draft-ietf-core-comi-11,2021、<https://datatracker.ietf.org/doc/html/ proft-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。、およびA.ペローフ、「ヤンでモデル化されたデータの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/ashignments/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.および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.、および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]リーチ、P.、Mealling、M.、および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.、S. Floyd、「データグラム輻輳制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<https：//www.rfc-編集者。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]ハンドリー、M.、ED。、RESCORLA、E.、ED。、および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。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.、R.ボニカ、「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.、および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.、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]イーストレイク3RD、D.および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.および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.、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.、および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]、D.、ED、Cheshire、S.、Boucadair、M.、Penno、R.、および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] PerreAll、S、ED。、山形、I。、宮川、西川、西田、そして芦田、「キャリアグレードの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。、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.、A. Jain、 "TCP Fast Open"、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：///www.rfc-編集者.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.、および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。、および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.、および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.および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.および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.、およびP.Stthews、「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.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ 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.、およびR. Moskowitz、 "DDOSオープン脅威シグナリング（ドット）要件"、RFC 8612、DOI 10.17487 / RFC8612、2019年5月、<https：//www.rfc-編集者.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]ドビンズ、R.、Migault、D.、Moskowitz、R.、Teague、N.、Xia、L.、およびK。西塚、「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/情報/ 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。、および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>。
The main changes compared to [RFC8782] are as follows:
[RFC8782]と比較した主な変更は次のとおりです。
* 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.
広告レビューのために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.
詳細な広告レビューのための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