[要約] RFC 9133は、分散型サービス拒否（DDoS）攻撃からの保護を目的として、DOTS信号チャネルを使用してフィルタリングルールを制御する方法について説明しています。この規格は、攻撃検出時に迅速に対応し、攻撃軽減を自動化するためのメカニズムを提供します。主に、インターネットサービスプロバイダーや大規模ネットワークを運用する組織での利用が想定されています。
Internet Engineering Task Force (IETF) K. Nishizuka
Request for Comments: 9133 NTT Communications
Category: Standards Track M. Boucadair
ISSN: 2070-1721 Orange
T. Reddy.K
Akamai
T. Nagata
Lepidum
September 2021
Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
分散サービス拒否オープン脅威シグナリング（ドット）信号チャネルを使用したフィルタリングルールの制御
Abstract
概要
This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active.
このドキュメントは、攻撃の軽減がアクティブなときにドットクライアントがそれらのフィルタリングルールを制御できるように、分散サービス拒否オープン脅威シグナリング（ドット）信号チャネルプロトコルへの拡張を指定します。
Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.
特に、この拡張機能により、ドットクライアントは、分散サービス拒否（DDOS）攻撃中に既存のフィルタリングルールを起動または無効にすることができます。これらのフィルタリング規則のキャラクタリゼーションは、ドットデータチャネルプロトコルによって、「アイドル」時間（すなわち、緩和が有効ではない）中にドットクライアントによって伝達される。
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/rfc9133.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc9133で入手できます。
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
1.1. The Problem
1.2. Controlling Filtering Rules Using DOTS Signal Channel
2. Terminology
3. Controlling Filtering Rules of a DOTS Client
3.1. Binding DOTS Data and Signal Channels
3.2. DOTS Signal Channel Extension
3.2.1. Parameters and Behaviors
3.2.2. DOTS Signal Filtering Control Module
3.2.2.1. Tree Structure
3.2.2.2. YANG Module
4. Some Examples
4.1. Conflict Handling
4.2. On-Demand Activation of an Accept-List Filter
4.3. DOTS Servers/Mitigators Lacking Capacity
5. IANA Considerations
5.1. DOTS Signal Channel CBOR Key Values Subregistry
5.2. A New YANG Module
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
In the Distributed Denial-of-Service Open Threat Signaling (DOTS) architecture [RFC8811], DOTS clients and servers communicate using both a signal channel protocol [RFC9132] and a data channel protocol [RFC8783].
分散サービス拒否オープン脅威シグナリング（DOTS）アーキテクチャ[RFC8811]では、ドットクライアントとサーバは、信号チャネルプロトコル[RFC9132]とデータチャネルプロトコルの両方を使用して通信します[RFC8783]。
The DOTS data channel protocol [RFC8783] is used for bulk data exchange between DOTS agents to improve the coordination of parties involved in the response to a Distributed Denial-of-Service (DDoS) attack. Filter management, which is one of the tasks of the DOTS data channel protocol, enables a DOTS client to retrieve the filtering capabilities of a DOTS server and to manage filtering rules. Typically, these filtering rules are used for dropping or rate-limiting unwanted traffic, and permitting accept-listed traffic.
ドットデータチャネルプロトコル[RFC8783]は、分散サービス拒否（DDOS）攻撃に対する応答に関与する当事者の調整を改善するためのドットエージェント間のバルクデータ交換に使用されます。Dotsデータチャネルプロトコルのタスクの1つであるフィルタ管理は、ドットクライアントがドットサーバーのフィルタリング機能を検索し、フィルタリングルールを管理できます。通常、これらのフィルタリング規則は、不要なトラフィックを削除またはレート制限するために使用され、承認リストのトラフィックを許可します。
The DOTS signal channel protocol [RFC9132] is designed to be resilient under extremely hostile network conditions and provides continued contact between DOTS agents even as DDoS attack traffic saturates the link. The DOTS signal channel can be established between two DOTS agents prior to or during an attack. At any time, the DOTS client may send mitigation requests (as per Section 4.4 of [RFC9132]) to a DOTS server over the active signal channel. While mitigation is active, the DOTS server periodically sends status messages to the DOTS client, including basic mitigation feedback details. 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. However, the DOTS server may still receive DOTS messages sent from the DOTS client over the signaling channel thanks to the heartbeat requests keeping the channel active (as described in Section 4.7 of [RFC9132]).
DOTS信号チャネルプロトコル[RFC9132]は、極めて敵対的なネットワーク条件下で弾力性があり、DDOS攻撃トラフィックがリンクを飽和させてもドットエージェント間で連絡先を提供します。ドット信号チャネルは、攻撃の前または攻撃の間に2つのドットエージェント間で確立することができる。いつでも、ドットクライアントは（[RFC9132]のセクション4.4と同様に）アクティブ信号チャネルを介してドットサーバーに軽減要求を送信することができます。緩和が有効な一方で、ドットサーバーは定期的に、基本的な緩和フィードバックの詳細を含むDOTSクライアントに定期的に送信されます。着信リンクをドットクライアントに飽和させる大規模なDDOS攻撃の場合、ドットサーバーからドットクライアントへのすべてのトラフィックが削除される可能性があります。しかしながら、ドットサーバは、チャネルをアクティブに保ちながら（RFC9132のセクション4.7で説明されているように）ハートビート要求のおかげで、ドットクライアントから送信されたドットメッセージをシグナリングチャネルを介して受信することがある。
Unlike the DOTS signal channel protocol, the DOTS data channel protocol is not expected to deal with attack conditions. As such, an issue that might be encountered in some deployments is when filters installed by means of the DOTS data channel protocol may not function as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS attack. In such conditions, the DOTS data channel protocol cannot be used to change these filters, which may complicate DDoS mitigation operations [INTEROP].
ドット信号チャネルプロトコルとは異なり、ドットデータチャネルプロトコルは攻撃条件に対処することが期待されていません。このように、一部の展開で遭遇する可能性がある問題は、DOTSデータチャネルプロトコルによってインストールされたフィルタがDDOS攻撃または悪化しても機能しない場合があります。これは、進行中のDDOS攻撃を悪化させます。このような条件では、DOTSデータチャネルプロトコルを使用してこれらのフィルタを変更することはできません。
A typical case is a conflict between filtering rules installed by a DOTS client and the mitigation actions of a DDoS mitigator. Consider, for instance, a DOTS client that configures during 'idle' time (i.e., no mitigation is active) some filtering rules using the DOTS data channel protocol to permit traffic from accept-listed sources. However, during a volumetric DDoS attack, the DDoS mitigator identifies the source addresses/prefixes in the accept-listed filtering rules are attacking the target. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attack traffic, or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack.
典型的な場合は、ドットクライアントによってインストールされたフィルタリングルールとDDOSの軽減アクションとの間の競合です。例えば、「アイドル」時間中に設定されるドットクライアント（すなわち、軽減はアクティブではない）を考慮して、ドットデータチャネルプロトコルを使用したいくつかのフィルタリング規則は、同時に配置されたソースからのトラフィックを許可する。ただし、VolumeTric DDOS攻撃の間、DDOS Mitigatorはaccept-listedフィルタリングルール内の送信元アドレス/プレフィックスを識別しています。たとえば、攻撃者は、攻撃上リストされたソースのIPアドレスを偽装することができ、または攻撃者は承認リストのソースを危険にさらすことができ、それらをDDOS攻撃を起動するようにプログラムすることができます。
[RFC9132] is designed so that the DDoS server notifies the above conflict to the DOTS client (that is, the 'conflict-cause' parameter is set to 2 (conflict-with-acceptlist)), but the DOTS client may not be able to withdraw the accept-list rules during the attack period due to the high-volume attack traffic saturating the inbound link to the DOTS client domain. In other words, the DOTS client cannot use the DOTS data channel protocol to withdraw the accept-list filters when a DDoS attack is in progress.
[RFC9132] DDOSサーバーが上記の競合をドットクライアントに通知するように設計されています（つまり、「競合 - 原因」パラメータは2（競合 - access-inpactlist）に設定されています）、ドットクライアントができない場合があります。攻撃期間中にaccept-listルールを撤回すると、ボリュームの攻撃トラフィックがドットクライアントドメインへのインバウンドリンクを飽和させます。言い換えれば、DOTSクライアントはDOTSデータチャネルプロトコルを使用して、DDOS攻撃が進行中のときにACCEPT-LISTフィルタを引き出すことはできません。
This specification addresses the problems discussed in Section 1.1 by adding a capability for managing filtering rules using the DOTS signal channel protocol, which enables a DOTS client to request the activation (or deactivation) of filtering rules during a DDoS attack. Note that creating these filtering rules is still the responsibility of the DOTS data channel [RFC8783].
この仕様は、DOTS攻撃中にドットクライアントがフィルタリングルールの起動（または無効化）を要求できるように、ドットシグナルチャネルプロトコルを使用してフィルタリングルールを管理する機能を追加することによって、セクション1.1で説明した問題に対処します。これらのフィルタリング規則を作成することはまだドットデータチャネル[RFC8783]の責任です。
The DOTS signal channel protocol is designed to enable a DOTS client to contact a DOTS server for help even under severe network congestion conditions. Therefore, extending the DOTS signal channel protocol to manage the filtering rules during an attack will enhance the protection capability offered by DOTS protocols.
ドット信号チャネルプロトコルは、厳しいネットワーク輻輳条件下でもドットクライアントがドットサーバに連絡することができるように設計されている。したがって、ドット信号チャネルプロトコルを拡張して攻撃中にフィルタリングルールを管理すると、ドットプロトコルによって提供される保護機能が向上します。
Note: The experiment at the IETF 103 hackathon [INTEROP] showed that even when the inbound link is saturated by DDoS attack traffic, the DOTS client can signal mitigation requests using the DOTS signal channel over the saturated link.
注：IETF 103 Hackathon [Interop]の実験は、着信リンクがDDOS攻撃トラフィックによって飽和している場合でも、ドットクライアントは飽和リンクを介してドット信号チャネルを使用して緩和要求を信号にします。
Conflicts that are induced by filters installed by other DOTS clients of the same domain are not discussed in this specification.
同じドメインの他のドットクライアントによってインストールされたフィルタによって引き起こされる競合は、本明細書では説明されていません。
An augmentation to the DOTS signal channel YANG module is defined in Section 3.2.2.
ドット信号チャネルヤンモジュールへの拡張はセクション3.2.2で定義されています。
Sample examples are provided in Section 4, in particular:
例示的な例はセクション4、特に：
* Section 4.1 illustrates how the filter control extension is used when conflicts with Access Control Lists (ACLs) are detected and reported by a DOTS server.
* セクション4.1は、アクセス制御リスト（ACL）との競合がドットサーバーによって検出され報告されたときにフィルタ制御の拡張機能をどのように使用するかを示しています。
* Section 4.2 shows how a DOTS client can instruct a DOTS server to safely forward some specific traffic in 'attack' time.
* セクション4.2は、ドットクライアントが「攻撃」時間でいくつかの特定のトラフィックを安全に転送するようにドットサーバーに指示する方法を示しています。
* Section 4.3 shows how a DOTS client can react if the DDoS traffic is still being forwarded to the DOTS client domain even if mitigation requests were sent to a DOTS server.
* 緩和要求がドットサーバーに送信されても、DDSトラフィックがドットクライアントドメインに転送されている場合、DOTSクライアントがどのように転送されているかを示します。
The JavaScript Object Notation (JSON) encoding of YANG-modeled data [RFC7951] is used to illustrate the examples.
Yangモデルデータ[RFC7951]のJavaScriptオブジェクト表記（JSON）エンコードは、例を説明するために使用されます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader should be familiar with the terms defined in [RFC8612].
リーダーは[RFC8612]で定義されている用語に精通している必要があります。
The terminology for describing YANG modules is defined in [RFC7950]. The meaning of the symbols in the tree diagram is defined in [RFC8340] and [RFC8791].
Yangモジュールを記述するための用語は[RFC7950]で定義されています。ツリー図のシンボルの意味は[RFC8340]と[RFC8791]で定義されています。
The filtering rules eventually managed using the DOTS signal channel protocol are created a priori by the same DOTS client using the DOTS data channel protocol. Managing conflicts with filters installed by other DOTS clients of the same domain is out of scope.
ドット信号チャネルプロトコルを使用して最終的に管理されたフィルタリング規則は、ドットデータチャネルプロトコルを使用して同じドットクライアントによって先験的に作成されます。同じドメインの他のドットクライアントによってインストールされているフィルタとの競合の管理は範囲外です。
As discussed in Section 4.4.1 of [RFC9132], a DOTS client must use the same 'cuid' for both the DOTS signal and data channels. This requirement is meant to facilitate binding DOTS channels used by the same DOTS client.
[RFC9132]のセクション4.4.1で説明したように、ドットクライアントはドット信号とデータチャネルの両方に同じ「CUID」を使用する必要があります。この要件は、同じドットクライアントによって使用されるバインディングドットチャネルを容易にすることを意図しています。
The DOTS signal and data channels from a DOTS client may or may not use the same DOTS server. Nevertheless, the scope of the mitigation request, alias, and filtering rules are not restricted to the DOTS server but to the DOTS server domain. To that aim, DOTS servers within a domain are assumed to have a mechanism to coordinate the mitigation requests, aliases, and filtering rules to coordinate their decisions for better mitigation operation efficiency. The exact details about such a mechanism is out of the scope of this document.
ドットクライアントからのドット信号およびデータチャネルは、同じドットサーバを使用してもしなくてもよい。それにもかかわらず、緩和要求、エイリアス、およびフィルタリング規則の範囲は、ドットサーバには限らず、ドットサーバドメインに制限されない。その目的のために、ドメイン内のドットサーバは、緩和要求、エイリアス、およびフィルタリングルールを調整するためのメカニズムを有すると仮定され、より良い緩和運用効率のために決定を調整する。そのようなメカニズムに関する正確な詳細はこの文書の範囲外です。
A filtering rule controlled by the DOTS signal channel is identified by its ACL name (Section 4.3 of [RFC8783]). Note that an ACL name unambiguously identifies an ACL bound to a DOTS client, but the same name may be used by distinct DOTS clients.
ドット信号チャネルによって制御されるフィルタリング規則は、そのACL名によって識別されます（[RFC8783]のセクション4.3）。ACL名は、DOTSクライアントにバインドされたACLを明確に識別しますが、同じ名前が異なるドットクライアントによって使用される可能性があります。
The activation or deactivation of an ACL by the DOTS signal channel overrides the 'activation-type' (defined in Section 4.3 of [RFC8783]) a priori conveyed with the filtering rules using the DOTS data channel protocol.
ドット信号チャネルによるACLのアクティベーションまたは非アクティブ化は、ドットデータチャネルプロトコルを使用してフィルタリングルールで伝送された先験的な「アクティベーションタイプ」をオーバーライドします（RFC8783のセクション4.3で定義）。
Once the attack is mitigated, the DOTS client may use the data channel to control the 'activation-type' (e.g., revert to a default value) of some of the filtering rules controlled by the DOTS signal channel or delete some of these filters. This behavior is deployment specific.
攻撃が軽減されると、ドットクライアントはデータチャネルを使用して、ドット信号チャネルによって制御されるフィルタリングルールのいくつかの「起動タイプ」（例えば、デフォルト値に戻す）を使用して、またはこれらのフィルタのいくつかを削除することができる。この動作は展開固有です。
This specification extends the mitigation request defined in Section 4.4.1 of [RFC9132] to convey the intended control of configured filtering rules. Concretely, the DOTS client conveys the 'acl-list' attribute with the following sub-attributes in the Concise Binary Object Representation (CBOR) body of a mitigation request (see the YANG structure in Section 3.2.2.1):
この仕様は[RFC9132]のセクション4.4.1で定義されている緩和要求を拡張して、設定されたフィルタリング規則の意図された制御を伝達します。具体的には、DOTSクライアントは、緩和要求の簡潔なバイナリオブジェクト表現（CBOR）本体で、次のサブ属性を使用して「ACL-list」属性を伝えます（セクション3.2.2.1のヤン構造を参照）。
acl-name: A name of an access list defined using the DOTS data channel (Section 4.3 of [RFC8783]) that is associated with the DOTS client.
ACL名：ドットクライアントに関連付けられているドットデータチャネル（[RFC8783]のセクション4.3）を使用して定義されたアクセスリストの名前。
As a reminder, an ACL is an ordered list of Access Control Entries (ACEs). Each ACE has a list of match criteria and a list of actions [RFC8783]. The list of configured ACLs can be retrieved using the DOTS data channel during 'idle' time.
リマインダーとして、ACLはアクセス制御エントリの順序付きリスト（ACE）です。各ACEには、一致基準のリストとアクションのリスト[RFC8783]があります。設定されたACLのリストは、「アイドル」時間中にドットデータチャネルを使用して取得できます。
This is a mandatory attribute when 'acl-list' is included.
'acl-list'が含まれている場合、これは必須の属性です。
activation-type: An attribute indicating the activation type of an ACL overriding the existing 'activation-type' installed by the DOTS client using the DOTS data channel.
activation-type：ドットデータチャネルを使用してドットクライアントによってインストールされている既存の 'Activation-Type'をオーバーライドするACLのアクティベーションタイプを示す属性。
As a reminder, this attribute can be set to 'deactivate', 'immediate', or 'activate-when-mitigating' as defined in [RFC8783].
リマインダーとして、この属性は[RFC8783]で定義されているように、 '非アクティブ化'、 '即値'、または 'Activate-When-ittagating'に設定できます。
Note that both 'immediate' and 'activate-when-mitigating' have an immediate effect when a mitigation request is being processed by the DOTS server.
「immediate」と「軽減の場合はアクティブなとき」の両方が、緩和要求がドットサーバーによって処理されているときに即時の影響を与えます。
This is an optional attribute.
これはオプションの属性です。
By default, ACL-related operations are achieved using the DOTS data channel protocol when no attack is ongoing. DOTS clients MUST NOT use the filtering control over the DOTS signal channel in 'idle' time; such requests MUST be discarded by DOTS servers with 4.00 (Bad Request).
デフォルトでは、ACL関連の操作は、攻撃が継続していないときにドットデータチャネルプロトコルを使用して実現されます。ドットクライアントは、「アイドル」時にドット信号チャネルを介してフィルタリング制御を使用してはいけません。そのような要求は、4.00（不良要求）を備えたドットサーバーによって破棄されなければなりません。
During an attack time, DOTS clients may include 'acl-list', 'acl-name', and 'activation-type' attributes in a mitigation request. This request may be the initial mitigation request for a given mitigation scope or a new one overriding an existing request. In both cases, a new 'mid' MUST be used. Nevertheless, it is NOT RECOMMENDED to include ACL attributes in an initial mitigation request for a given mitigation scope or in a mitigation request adjusting the mitigation scope. This recommendation is meant to avoid delaying attack mitigations because of failures to process ACL attributes.
攻撃時間中、ドットクライアントは、緩和要求で「ACL-list」、 'ACL名'、および「アクティベーションタイプ」属性を含めることができます。この要求は、特定の緩和範囲または既存の要求をオーバーライドする新しい緩和範囲に対する初期緩和要求であり得る。どちらの場合も、新しい「MID」を使用する必要があります。それにもかかわらず、所与の緩和範囲または緩和範囲を調整する緩和要求の初期緩和要求においてACL属性を含めることは推奨されない。この推奨事項は、ACL属性を処理するための障害のため、攻撃軽減の遅延を避けることを目的としています。
As the attack evolves, DOTS clients can adjust the 'activation-type' of an ACL conveyed in a mitigation request or control other filters as necessary. This can be achieved by sending a PUT request with a new 'mid' value.
攻撃が進化するにつれて、ドットクライアントは、緩和要求で伝達されたACLの「起動型」を調整することも、必要に応じて他のフィルタを制御することができます。これは、新しい「MID」値でPUTリクエストを送信することで実現できます。
It is RECOMMENDED for a DOTS client to subscribe to asynchronous notifications of the attack mitigation, as detailed in Section 4.4.2.1 of [RFC9132]. If not, the polling mechanism in Section 4.4.2.2 of [RFC9132] has to be followed by the DOTS client.
[RFC9132]のセクション4.4.2.1に詳述されているように、ドットクライアントが攻撃軽減の非同期通知を購読することをお勧めします。もしそうでなければ、[RFC9132]の4.4.2.2項のポーリングメカニズムの後にドットクライアントが続く必要があります。
A DOTS client relies on the information received from the DOTS server and/or local information to the DOTS client domain to trigger a filter control request. Only filters that are pertinent for an ongoing mitigation should be controlled by a DOTS client using the DOTS signal channel.
ドットクライアントは、ドットサーバから受信された情報および/またはローカル情報からドットクライアントドメインへの情報に依存して、フィルタ制御要求をトリガする。継続的な緩和について適切なフィルタのみは、ドット信号チャネルを使用してドットクライアントによって制御されるべきです。
'acl-list', 'acl-name', and 'activation-type' are defined as comprehension-required parameters. Following the rules in Section 6 of [RFC9132], if the DOTS server does not understand the 'acl-list', 'acl-name', or 'activation-type' attributes, it responds with a 4.00 (Bad Request) error response code.
'acl-list'、 'acl-name'、および 'activation-type'は、理解されているパラメータとして定義されています。[RFC9132]のセクション6の規則に従って、DOTSサーバーが 'ACL-list'、 'acl-name'、または 'activation-type'属性を理解していない場合は、4.00（不良要求）エラー応答で応答します。コード。
If the DOTS server does not find the ACL name ('acl-name') conveyed in the mitigation request for this DOTS client, it MUST respond with a 4.04 (Not Found) error response code.
このドットクライアントの軽減要求でDOTSサーバーがACL名（ 'ACL名'）が見つからない場合は、4.04（見つからない）エラー応答コードで応答する必要があります。
If the DOTS server finds the ACL name for this DOTS client, and assuming the request passed the validation checks in Section 4.4.1 of [RFC9132], the DOTS server MUST proceed with the 'activation-type' update. The update is immediately enforced by the DOTS server and will be maintained as the new activation type for the ACL name even after the termination of the mitigation request. In addition, the DOTS server MUST update the lifetime of the corresponding ACL similar to the update when a refresh request is received using the DOTS data channel (Section 7.2 of [RFC8783]). If, for some reason, the DOTS server fails to apply the filter update, it MUST respond with a 5.03 (Service Unavailable) error response code and include the failed ACL update in the diagnostic payload of the response (an example is shown in Figure 1). Else, the DOTS server replies with the appropriate response code defined in Section 4.4.1 of [RFC9132].
ドットサーバがこのドットクライアントのACL名を見つけ、[RFC9132]のセクション4.4.1で検証チェックを渡した場合、ドットサーバーは 'Activation-Type'アップデートを続行する必要があります。更新は直ちにドットサーバーによって強制され、緩和要求の終了後もACL名の新しいアクティベーションタイプとして維持されます。さらに、ドットサーバは、ドットデータチャネルを使用してリフレッシュ要求を受信したときに更新と同様の対応するACLの寿命を更新する必要があります（[RFC8783]のセクション7.2）。何らかの理由で、ドットサーバがフィルタ更新の適用に失敗した場合は、5.03（サービス利用不可）エラー応答コードで応答し、応答の診断ペイロードに障害が発生したACLアップデートを含める必要があります（例を図1に示します）。）。そうでなければ、DOTSサーバーは[RFC9132]の4.4.1項で定義されている適切な応答コードに応答します。
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 123,
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "an-accept-list",
"activation-type": "deactivate"
}
]
}
]
}
}
Figure 1: Example of a Diagnostic Payload Including Failed ACL Update
図1：ACLアップデートに失敗した診断ペイロードの例
The JSON/YANG mappings for DOTS filter control attributes are shown in Table 1. As a reminder, the mapping for 'acl-name' is defined in Table 5 of [RFC9132].
ドットフィルタ制御属性のJSON / YANGマッピングを表1に示します。リマインダーとして、「ACL名」のマッピングは[RFC9132]の表5に定義されています。
+===================+=============+======+=================+========+
| Parameter Name | YANG Type | CBOR | CBOR Major Type | JSON |
| | | Key | & Information | Type |
+===================+=============+======+=================+========+
| activation-type | enumeration | 52 | 0 unsigned | String |
+-------------------+-------------+------+-----------------+--------+
| ietf-dots- | list | 53 | 4 array | Array |
| signal- | | | | |
| control:acl-list | | | | |
+-------------------+-------------+------+-----------------+--------+
| acl-name | leafref | 23 | 3 text string | String |
+-------------------+-------------+------+-----------------+--------+
Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes
表1：フィルタ制御属性のためのCBORへのJSON / YANGマッピング
If the DOTS client receives a 5.03 (Service Unavailable) with a diagnostic payload indicating a failed ACL update as a response to an initial mitigation or a mitigation with adjusted scope, the DOTS client MUST immediately send a new request that repeats all the parameters as sent in the failed mitigation request but without including the ACL attributes. After the expiry of Max-Age returned in the 5.03 (Service Unavailable) response, the DOTS client retries with a new mitigation request (i.e., a new 'mid') that repeats all the parameters as sent in the failed mitigation request (i.e., the one including the ACL attributes).
DOTSクライアントが最初の緩和または調整されたスコープを使用した軽減として失敗したACLアップデートを示す診断ペイロードで5.03（サービスが利用できない）を受信した場合、ドットクライアントはすぐに送信されたパラメータを繰り返す新しい要求を送信する必要があります。失敗した緩和要求ではなく、ACL属性を含まない。5.03（サービス利用不可）応答で返されたMax-Anageの有効期限が返された後、ドットクライアントは、失敗した緩和要求で送信されたすべてのパラメータを繰り返す新しい緩和要求（つまり、新しい 'MID'）で再試行します（つまり、ACL属性を含むもの）。
If, during an active mitigation, the 'activation-type' is changed at the DOTS server (e.g., as a result of an external action) for an ACL bound to a DOTS client, the DOTS server notifies that DOTS client of the change by including the corresponding ACL parameters in an asynchronous notification (the DOTS client is observing the active mitigation) or in a response to a polling request (Section 4.4.2.2 of [RFC9132]).
アクティブな緩和の間に、DOTSクライアントにバインドされたACLの場合は、DOTSサーバーが変更のドットクライアントであることを通知します。非同期通知（ドットクライアントがアクティブな軽減を監視している）またはポーリング要求に対する応答にある対応するACLパラメータを含みます（[RFC9132]のセクション4.4.2.2）。
If the DOTS signal and data channels of a DOTS client are not established with the same DOTS server of a DOTS server domain, the above request processing operations are undertaken using the coordination mechanism discussed in Section 3.1.
ドットクライアントのドット信号およびデータチャネルがドットサーバドメインの同じドットサーバで確立されていない場合、上記の要求処理動作は、セクション3.1で説明した調整メカニズムを使用して行われる。
This specification does not require any modification to the efficacy update and the withdrawal procedures defined in [RFC9132]. In particular, ACL-related clauses are not included in a PUT request used to send an efficacy update and DELETE requests.
この仕様では、[RFC9132]で定義されている有効性更新と撤退手順を修正する必要はありません。特に、ACL関連句は、有効性の更新および削除要求を送信するために使用されるPUTリクエストには含まれていません。
This document augments the "ietf-dots-signal-channel" YANG module defined in [RFC9132] for managing filtering rules.
この文書は、フィルタリング規則を管理するための[RFC9132]で定義されている「IETF-DOTS-Signal-Channel」Yangモジュールを増強します。
This document defines the YANG module "ietf-dots-signal-control", which has the following tree structure:
このドキュメントでは、次のツリー構造を持つYANGモジュール「IETF-DOTS-Signal-Control」を定義します。
module: ietf-dots-signal-control
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope:
+-- acl-list* [acl-name]
+-- acl-name
| -> /data-channel:dots-data/dots-client/acls/acl/name
+-- activation-type? data-channel:activation-type
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 a data model and encoding, but not a management data model.
このYANGモジュールは、ドットサーバー管理目的でNETCONF / RESTCONFを介して使用されることを意図していません。そのようなモジュールはこの文書の範囲外です。それはデータモデルと符号化を提供するだけでなく、管理データモデルでは役立ちます。
This module uses types defined in [RFC8783].
このモジュールは[RFC8783]で定義されている型を使用します。
<CODE BEGINS> file "ietf-dots-signal-control@2021-09-02.yang"
module ietf-dots-signal-control {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
prefix dots-control;
import ietf-dots-signal-channel {
prefix 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";
}
import ietf-dots-data-channel {
prefix data-channel;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Kaname Nishizuka
<mailto:kaname@nttv6.jp>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Tirumaleswar Reddy.K
<mailto:kondtir@gmail.com>
Author: Takahiko Nagata
<mailto:nagata@lepidum.co.jp>";
description "This module contains YANG definition for the signaling messages exchanged between a DOTS client and a DOTS server to control, by means of the DOTS signal channel, filtering rules configured using the DOTS data channel.
「このモジュールは、ドット信号チャネルを使用して、ドットデータチャネルを使用して構成されたフィルタリング規則を使用して、ドットクライアントとドットサーバーとの間で交換されるシグナリングメッセージの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 (https://trustee.ietf.org/license-info).
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（https://trustee.ietf.org/License-info）。
This version of this YANG module is part of RFC 9133; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9133の一部です。完全な法的通知のためのRFC自体を見てください。」
revision 2021-09-02 {
description
"Initial revision.";
reference
"RFC 9133: Controlling Filtering Rules Using Distributed
Denial-of-Service Open Threat Signaling (DOTS)
Signal Channel";
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:mitigation-scope"
+ "/dots-signal:scope" {
description "ACL name and activation type.";
説明 "ACL名とアクティベーションタイプ。";
list acl-list {
key "acl-name";
description
"List of ACLs as defined using the DOTS data
channel. ACLs bound to a DOTS client are uniquely
identified by a 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 ACL name bound to a DOTS client.";
}
leaf activation-type {
type data-channel:activation-type;
default "activate-when-mitigating";
description
"Sets the activation type of an ACL.";
}
}
}
}
<CODE ENDS>
This section provides some examples to illustrate the behavior specified in Section 3.2.1. These examples are provided for illustration purposes; they should not be considered as deployment recommendations.
このセクションでは、セクション3.2.1で指定された動作を説明するためのいくつかの例を示します。これらの例は説明の目的のために提供されている。それらは展開の推奨事項と見なされるべきではありません。
Let's consider a DOTS client that contacts its DOTS server during 'idle' time to install an accept-list allowing for UDP traffic issued from 2001:db8:1234::/48 with a destination port number 443 to be forwarded to 2001:db8:6401::2/127. It does so by sending, for example, a PUT request as shown in Figure 2.
2001年から発行されたUDPトラフィックをインストールするために「アイドル」時間中にドットサーバーに連絡するドットクライアントを検討しましょう。宛先ポート番号443は2001に転送されます.DB8：6401 :: 2/127。たとえば、図2に示すようにPUTリクエストを送信することによってそうします。
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=an-accept-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "an-accept-list",
"type": "ipv6-acl-type",
"activation-type": "activate-when-mitigating",
"aces": {
"ace": [
{
"name": "test-ace-ipv6-udp",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/48"
},
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 443
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 2: DOTS Data Channel Request to Create a Filter
図2：フィルタを作成するためのドットデータチャネル要求
Sometime later, consider that a DDoS attack is detected by the DOTS client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in Figure 3.
しばらくして、2001年のDOTSクライアントによってDDOS攻撃が検出されたことを検討してください.DB8：6401 :: 2/127。その結果、ドットクライアントは図3に示すように、そのドットサーバに緩和要求を送信する。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"lifetime": 3600
}
]
}
}
Figure 3: DOTS Signal Channel Mitigation Request
図3：ドット信号チャネルの緩和要求
The DOTS server immediately accepts the request by replying with 2.01 (Created) (Figure 4 depicts the message body of the response).
DOTSサーバーはすぐに2.01（作成された）で返信することによって要求を受け入れます（図4は応答のメッセージ本文を示しています）。
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 123,
"lifetime": 3600
}
]
}
}
Figure 4: Status Response (Message Body)
図4：ステータス応答（メッセージ本文）
Assuming the DOTS client subscribed to asynchronous notifications, when the DOTS server concludes that some of the attack sources belong to 2001:db8:1234::/48, it sends a notification message with 'status' code set to 1 (attack-mitigation-in-progress) and 'conflict-cause' set to 2 (conflict-with-acceptlist) to the DOTS client to indicate that this mitigation request is in progress, but a conflict is detected.
ドットクライアントが非同期通知を購読していると仮定すると、ドットサーバが2001年に属すると判断した場合：DB8：1234 :: / 48の一部が「ステータス」コードに設定されている通知メッセージを1に送信します（攻撃 - 緩和 - この軽減要求が進行中であることを示すために、ドットクライアントに2（競合 - accesslist）に設定されていますが、競合が検出されます。
Upon receipt of the notification message from the DOTS server, the DOTS client sends a PUT request to deactivate the "an-accept-list" ACL as shown in Figure 5.
ドットサーバから通知メッセージを受信すると、ドットクライアントは、図5に示すように「AN - ACCEPT - LIST」ACLを無効にするためのPUT要求を送信する。
The DOTS client can also decide to send a PUT request to deactivate the "an-accept-list" ACL if suspect traffic is received from an accept-listed source (2001:db8:1234::/48). The structure of that PUT is the same as the one shown in Figure 5.
DOTSクライアントは、疑わしいトラフィックが受信側の送信元（2001：DB8：1234 :: / 48）から受信された場合、「AN-ACCEPT-LIST」ACLを無効にするためのPUTリクエストを送信することを決定することもできます（2001：DB8：1234 :: / 48）。その置きの構造は、図5に示すものと同じです。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=124"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "an-accept-list",
"activation-type": "deactivate"
}
],
"lifetime": 3600
}
]
}
}
Figure 5: PUT for Deactivating a Conflicting Filter
図5：競合するフィルタを無効にするために置く
Then, the DOTS server deactivates the "an-accept-list" ACL and replies with a 2.04 (Changed) response to the DOTS client to confirm the successful operation. The message body is similar to the one depicted in Figure 4.
その後、ドットサーバは、「An-Accept-List」ACLを無効にし、ドットクライアントへの2.04（変更）応答で返信を行い、成功した操作を確認します。メッセージ本体は、図4に示すものと似ています。
Once the attack is mitigated, the DOTS client may use the data channel to retrieve its ACLs maintained by the DOTS server. As shown in Figure 6, the activation type is set to 'deactivate' as set by the DOTS signal channel (Figure 5) instead of the type initially set using the DOTS data channel (Figure 2).
攻撃が軽減されると、ドットクライアントはデータチャネルを使用して、ドットサーバーによって維持されているACLを取得することができます。図6に示すように、起動タイプは、ドットデータチャネルを使用して最初に設定されたタイプの代わりに、ドット信号チャネル（図5）によって設定されているように「無効化」に設定されています（図2）。
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "an-accept-list",
"type": "ipv6-acl-type",
"activation-type": "deactivate",
"pending-lifetime": 10021,
"aces": {
"ace": [
{
"name": "test-ace-ipv6-udp",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/48"
},
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 443
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 6: DOTS Data Channel GET Response after Mitigation (Message Body)
図6：ドットデータチャネル軽減後の応答を得る（メッセージ本文）
Let's consider a DOTS client that contacts its DOTS server during 'idle' time to install an accept-list allowing for UDP traffic issued from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It does so by sending, for example, a PUT request shown in Figure 7. The DOTS server installs this filter with a "deactivated" state.
2001年から発行されたUDPトラフィックを提供するACCEPT-LISTをインストールするために「アイドル」時間中にドットサーバーに連絡するドットクライアントを検討しましょう.DB8：1234 :: / 48に転送されます.DB8：6401 :: 2/127。たとえば、図7に示すPUTリクエストを送信することによってそうします。ドットサーバーはこのフィルタを「無効化」状態でインストールします。
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
/acl=my-accept-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "my-accept-list",
"type": "ipv6-acl-type",
"activation-type": "deactivate",
"aces": {
"ace": [
{
"name": "an-ace",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/48",
"protocol": 17
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 7: DOTS Data Channel Request to Create an Accept-List Filter
図7：承認リストフィルタを作成するためのドットデータチャネル要求
Sometime later, consider that a UDP DDoS attack is detected by the DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let the traffic from 2001:db8:1234::/48 be accept-listed to the DOTS client domain. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in Figure 8.
しばらくして、2001年のDOTSクライアントによってUDP DDOS攻撃が検出されたことを検討してください.BOT：DOTSクライアントは、2001からのトラフィックを許可したいと考えています.DB8：1234 :: / 48は承認されます。ドットクライアントドメイン。その結果、DOTSクライアントは図8に示すようにそのドットサーバに緩和要求を送信する。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
Uri-Path: "mid=4879"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "my-accept-list",
"activation-type": "immediate"
}
],
"lifetime": 3600
}
]
}
}
Figure 8: DOTS Signal Channel Mitigation Request with a Filter Control
図8：フィルタ制御によるドット信号チャネル緩和要求
The DOTS server activates the "my-accept-list" ACL and replies with a 2.01 (Created) response to the DOTS client to confirm the successful operation.
DOTSサーバーは、成功した操作を確認するために、DOTSクライアントへの「My-Accept-List」ACLを有効にします。
This section describes a scenario in which a DOTS client activates a drop-list or a rate-limit filter during an attack.
このセクションでは、ドットクライアントが攻撃中にドロップリストまたはレート制限フィルタをアクティブにするシナリオについて説明します。
Consider a DOTS client that contacts its DOTS server during 'idle' time to install an accept-list that rate-limits all (or a part thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort countermeasure whenever required. Installing the accept-list can be done by sending, for example, the PUT request shown in Figure 9. The DOTS server installs this filter with a "deactivated" state.
「アイドル」時間中にドットサーバーに連絡するドットクライアントを考えてみましょう。最後のリゾートの対策として、Rate-Limits Accept-Limits（またはその一部）トラフィックをレート制限します.DB8：123 :: / 48必要だったときはいつでも。accept-listのインストールは、たとえば、図9に示すPUT要求を送信することによって行うことができます.DOTSサーバーはこのフィルタを「無効化」状態でインストールします。
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=OopPisZqo4SLv64TLPXrxA/acls\
/acl=my-ratelimit-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "my-ratelimit-list",
"type": "ipv6-acl-type",
"activation-type": "deactivate",
"aces": {
"ace": [
{
"name": "my-ace",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:123::/48"
}
},
"actions": {
"forwarding": "accept",
"rate-limit": "20000.00"
}
}
]
}
}
]
}
}
Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter
図9：レート制限フィルタを作成するためのドットデータチャネル要求
Consider now that a DDoS attack is detected by the DOTS client on 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation request to its DOTS server (Figure 10).
2001年のDOTSクライアントによってDDOS攻撃が検出されることを検討してください.DB8：123 :: / 48。その結果、ドットクライアントはそのドットサーバに緩和要求を送信する（図10）。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=85"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"lifetime": 3600
}
]
}
}
Figure 10: DOTS Signal Channel Mitigation Request
図10：ドット信号チャネルの緩和要求
For some reason (e.g., the DOTS server, or the mitigator, is lacking a capability or capacity), the DOTS client is still receiving attack traffic, which saturates available links. To soften the problem, the DOTS client decides to activate the filter that rate-limits the traffic destined to the DOTS client domain. To that aim, the DOTS client sends the mitigation request to its DOTS server shown in Figure 11.
何らかの理由で（例えば、ドットサーバ、または備考能力が能力または容量を欠いている）、ドットクライアントは依然として攻撃トラフィックを受信しており、それは利用可能なリンクを飽和させる。問題を解決するために、ドットクライアントは、ドットクライアントドメイン宛てのトラフィックをレート制限するフィルタをアクティブにすることを決定します。その目的のために、ドットクライアントは図11に示すドットサーバに緩和要求を送信する。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=86"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "my-ratelimit-list",
"activation-type": "immediate"
}
],
"lifetime": 3600
}
]
}
}
Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate-Limit Filter
図11：レート制限フィルタを有効にするためのドット信号チャネルの緩和要求
Then, the DOTS server activates the "my-ratelimit-list" ACL and replies with a 2.04 (Changed) response to the DOTS client to confirm the successful operation.
そして、ドットサーバは、「my-ratelimit-list」ACLを起動し、ドットクライアントへの2.04（変更）応答で応答を有効にして、成功した操作を確認します。
As the attack mitigation evolves, the DOTS client may decide to deactivate the rate-limit policy (e.g., upon receipt of a notification status change from 'attack-exceeded-capability' to 'attack-mitigation-in-progress'). Based on the mitigation status conveyed by the DOTS server, the DOTS client can deactivate the rate-limit action. It does so by sending the request shown in Figure 12.
攻撃緩和が進化するにつれて、ドットクライアントは、レート制限ポリシーを無効にすることを決定してもよい（例えば、「攻撃超え - 能力」から「攻撃 - 緩和 - 進行中」への通知ステータスの変更を受けると）。ドットサーバーによって伝達された緩和ステータスに基づいて、ドットクライアントはレート制限アクションを無効にすることができます。図12に示す要求を送信することによってそうします。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=87"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "my-ratelimit-list",
"activation-type": "deactivate"
}
],
"lifetime": 3600
}
]
}
}
Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit Filter
図12：レート制限フィルタを無効にするためのドット信号チャネルの緩和要求
Per this specification, IANA has registered the following parameters in the "DOTS Signal Channel CBOR Key Values" subregistry within the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" registry [Key-Map].
この仕様ごとに、IANAは、「分散サービス拒否オープン脅威シグナリング（ドット）信号チャネルレジストリ」レジストリ[キーマップ]内の「ドット信号チャネルCBORキー値」サブレイストに以下のパラメータを登録しました。
+==================+==========+=======+============+===============+
| Parameter Name | CBOR Key | CBOR | Change | Specification |
| | Value | Major | Controller | Document(s) |
| | | Type | | |
+==================+==========+=======+============+===============+
| activation-type | 52 | 0 | IESG | RFC 9133 |
+------------------+----------+-------+------------+---------------+
| ietf-dots- | 53 | 4 | IESG | RFC 9133 |
| signal- | | | | |
| control:acl-list | | | | |
+------------------+----------+-------+------------+---------------+
Table 2
表2.
IANA has registered the following URI 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-control Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：URN：IETF：PARAMS：XML：NS：YANG：IETF-DOTS-Signal-Control登録者連絡先：IESG。XML：n / a;要求されたURIはXMLネームスペースです。
IANA has registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.
IANAは、「YANGパラメータ」レジストリ内に「Yang Module Names」サブレジスト[RFC6020]に次のYANGモジュールを登録しています。
Name: ietf-dots-signal-control
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Maintained by IANA: N
Prefix: dots-control
Reference: RFC 9133
The security considerations for the DOTS signal channel protocol are discussed in Section 11 of [RFC9132], while those for the DOTS data channel protocol are discussed in Section 10 of [RFC8783]. The following discusses the security considerations that are specific to the DOTS signal channel extension defined in this document.
ドット信号チャネルプロトコルのセキュリティ上の考慮事項は[RFC9132]のセクション11で説明されているが、ドットデータチャネルプロトコルのためのものは[RFC8783]の第10章で説明されている。以下に、このドキュメントで定義されているDOTS信号チャネル拡張機能に固有のセキュリティ上の考慮事項について説明します。
This specification does not allow the creation of new filtering rules, which is the responsibility of the DOTS data channel. DOTS client domains should be adequately prepared prior to an attack, e.g., by creating filters that will be activated on demand when an attack is detected.
この仕様では、ドットデータチャネルの責任である新しいフィルタリングルールを作成することはできません。ドットクライアントドメインは、攻撃が検出されたときにオンデマンドでアクティブになるフィルタを作成することによって、攻撃の前に適切に準備されるべきである。
A DOTS client is entitled to access only the resources it creates. In particular, a DOTS client can not tweak filtering rules created by other DOTS clients of the same DOTS client domain. As a reminder, DOTS servers must associate filtering rules with the DOTS client that created these resources. Failure to ensure such association by a DOTS server will have severe impact on DOTS client domains.
ドットクライアントは、作成したリソースのみにアクセスする権利があります。特に、ドットクライアントは、同じドットクライアントドメインの他のドットクライアントによって作成されたフィルタリングルールを調整することはできません。リマインダーとして、ドットサーバーはフィルタリングルールをこれらのリソースを作成したドットクライアントと関連付ける必要があります。ドットサーバーによるそのような関連付けを確実にすることができないと、ドットクライアントドメインに深刻な影響があります。
A compromised DOTS client can use the filtering control capability to exacerbate an ongoing attack. Likewise, such a compromised DOTS client may abstain from reacting to an ACL conflict notification received from the DOTS server during attacks. These are not new attack vectors, but variations of threats discussed in [RFC9132] and [RFC8783]. DOTS operators should carefully monitor and audit DOTS agents to detect misbehaviors and deter misuses.
妥協されたドットクライアントは、継続的な攻撃を悪化させるためにフィルタリング制御機能を使用することができます。同様に、そのような妥協されたドットクライアントは、攻撃中にドットサーバから受信されたACL競合通知への反応から棄権することがある。これらは新しい攻撃ベクトルではありませんが、[RFC9132]と[RFC8783]で議論されている脅威のバリエーション。ドットオペレータは、誤動作者と誤解を検出するためにドットエージェントを慎重に監視および監査する必要があります。
[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>。
[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>。
[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>。
[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>。
[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>。
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, <https://www.rfc-editor.org/info/rfc9132>.
[RFC9132] Boucadair、M.、Ed。、浅い、J.、およびT.Reddy.k、「分散サービス拒否オープン脅威シグナリング（ドット）信号チャネル仕様」、RFC 9132、DOI 10.17487 / RFC9132、9月2021、<https://www.rfc-editor.org/info/rfc9132>。
[INTEROP] Nishizuka, K., Shallow, J., and L. Xia, "DOTS Interop test report, IETF 103 Hackathon", November 2018, <https://datatracker.ietf.org/meeting/103/materials/ slides-103-dots-interop-report-from-ietf-103-hackathon-00>.
【Interop】西塚、K。、浅い、J.、およびL. XIA、「ドット間テストレポート、IETF 103ハッカソン」、2018年11月、<https：//datatracker.ietf.org/meeting/103/materials/スライド-103 - DOTS - IETF - 103 - Hackathon - 00
[Key-Map] IANA, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel", <https://www.iana.org/assignments/dots>.
[キーマップ] IANA、「サービス拒否オープン脅威シグナリング（ドット）信号チャネル」、<https://www.iana.org/ashignments/dots>。
[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>。
[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>。
[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>。
Acknowledgements
謝辞
Many thanks to Wei Pan, Xia Liang, Jon Shallow, Dan Wing, Christer Holmberg, Shawn Emery, Tim Chown, Murray Kucherawy, Roman Danyliw, Erik Kline, and Éric Vyncke for the comments.
Wei Pan、Xia Liang、Jon Shallow、Dan Wing、Christer Holmberg、Shawn Emery、Tim Chown、Murray Kucherawy、Roman DanyLiw、Erik Kline、およびコメントのためのéricVynckeに感謝します。
Thanks to Benjamin Kaduk for the AD review.
広告レビューのためにBenjamin Kadukに感謝します。
Authors' Addresses
著者の住所
Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118 Japan
カナム西塚NTTコミュニケーションズGRANPARK 16F 3-4-1芝浦、東京都港区108-8118日本
Email: kaname@nttv6.jp
Mohamed Boucadair Orange 35000 Rennes France
Mohamed Boucadair Orange 35000 Rennesフランス
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K Akamai Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy.K Akamai大使館ゴルフリンクビジネスパークバンガロール560071カルナータカインド
Email: kondtir@gmail.com
Takahiko Nagata Lepidum Japan
永田貴彦レピダムジャパン
Email: nagata@lepidum.co.jp