[要約] RFC 8811は、DDoS Open Threat Signaling（DOTS）アーキテクチャに関する標準化文書です。このRFCの目的は、ネットワークにおけるDDoS攻撃への対応を改善し、セキュリティイベントの通知と制御を効果的に行うための仕組みを提供することです。
Internet Engineering Task Force (IETF) A. Mortensen, Ed.
Request for Comments: 8811 Forcepoint
Category: Informational T. Reddy.K, Ed.
ISSN: 2070-1721 McAfee, Inc.
F. Andreasen
Cisco
N. Teague
Iron Mountain
R. Compton
Charter
August 2020
DDoS Open Threat Signaling (DOTS) Architecture
DDOSオープン脅威シグナリング（ドット）アーキテクチャ
Abstract
概要
This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.
このドキュメントでは、ドメイン内およびドメイン間で分散サービス拒否（DDOS）オープン脅威シグナリング（ドット）を確立し維持するためのアーキテクチャについて説明します。この文書は、プロトコルまたはプロトコル拡張を指定しません。代わりに、ドット展開で使用されるアーキテクチャの関係、コンポーネント、および概念の定義に焦点を当てています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8811.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8811で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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. Context and Motivation
1.1. Terminology
1.1.1. Key Words
1.1.2. Definition of Terms
1.2. Scope
1.3. Assumptions
2. DOTS Architecture
2.1. DOTS Operations
2.2. Components
2.2.1. DOTS Client
2.2.2. DOTS Server
2.2.3. DOTS Gateway
2.3. DOTS Agent Relationships
2.3.1. Gatewayed Signaling
3. Concepts
3.1. DOTS Sessions
3.1.1. Preconditions
3.1.2. Establishing the DOTS Session
3.1.3. Maintaining the DOTS Session
3.2. Modes of Signaling
3.2.1. Direct Signaling
3.2.2. Redirected Signaling
3.2.3. Recursive Signaling
3.2.4. Anycast Signaling
3.2.5. Signaling Considerations for Network Address
Translation
3.3. Triggering Requests for Mitigation
3.3.1. Manual Mitigation Request
3.3.2. Automated Conditional Mitigation Request
3.3.3. Automated Mitigation on Loss of Signal
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Signaling the need for help to defend against an active distributed denial-of-service (DDoS) attack requires a common understanding of mechanisms and roles among the parties coordinating a defensive response. The signaling layer and supplementary messaging are the focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of coordinating defensive measures among willing peers to mitigate attacks quickly and efficiently, enabling hybrid attack responses coordinated locally at or near the target of an active attack, or anywhere in path between attack sources and target. Sample DOTS use cases are elaborated in [DOTS-USE-CASES].
シグナリング活動的な分散サービス拒否（DDOS）攻撃に対して守るための助けが必要になるには、守備対応の関係者の間のメカニズムと役割について一般的な理解が必要です。シグナリング層と補足メッセージングは、DDOSオープン脅威シグナリング（ドット）の焦点です。ドットは、攻撃を迅速かつ効率的に軽減するために警戒ピア間で防御的な尺度を調整する方法を定義し、攻撃攻撃のターゲットまたは攻撃源とターゲット間の経路内のどこでも調整することができます。サンプルドット使用症例は[Dots-Use-Sepose]で詳しく説明されています。
This document describes an architecture used in establishing, maintaining, or terminating a DOTS relationship within a domain or between domains.
このドキュメントでは、ドメイン内またはドメイン間のドットの関係を確立、維持、または終了するのに使用されるアーキテクチャについて説明します。
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.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
This document uses the terms defined in [RFC8612].
この文書は[RFC8612]で定義されている用語を使用しています。
In this architecture, DOTS clients and servers communicate using DOTS signal channel [RFC8782] and data channel [RFC8783] protocols.
このアーキテクチャでは、ドットクライアントとサーバーは、ドット信号チャネル[RFC8782]とデータチャネル[RFC8783]プロトコルを使用して通信します。
The DOTS architecture presented here is applicable across network administrative domains, for example, between an enterprise domain and the domain of a third-party attack mitigation service, as well as to a single administrative domain. DOTS is generally assumed to be most effective when aiding coordination of attack response between two or more participating networks, but single domain scenarios are valuable in their own right, as when aggregating intra-domain DOTS client signals for an inter-domain coordinated attack response.
ここで提示されているドットアーキテクチャは、例えば、企業ドメインとサードパーティの攻撃軽減サービスのドメインと一人の管理ドメインとの間で、ネットワーク管理ドメイン間で適用されます。ドットは一般に、2つ以上の参加ネットワーク間の攻撃応答の調整を補助する場合に最も効果的であると仮定されていますが、ドメイン間協調攻撃応答のためのドメイン内ドットのクライアント信号を集約するときのように、単一のドメインシナリオは独自に貴重です。
This document does not address any administrative or business agreements that may be established between involved DOTS parties. Those considerations are out of scope. Regardless, this document assumes necessary authentication and authorization mechanisms are put in place so that only authorized clients can invoke the DOTS service.
この文書は、関係するドット当事者間で確立される可能性のある管理上またはビジネス契約に対処しません。それらの考慮事項は範囲外です。とにかく、この文書は必要な認証と認証メカニズムが適していると仮定し、許可されたクライアントだけがドットサービスを呼び出すことができるようにします。
A detailed set of DOTS requirements are discussed in [RFC8612], and the DOTS architecture is designed to follow those requirements. Only new behavioral requirements are described in this document.
DOTSアーキテクチャの詳細な一連のドット要件は、それらの要件に従うように設計されています。この文書には、新しい行動要件のみが説明されています。
This document makes the following assumptions:
この文書は次の仮定を述べる：
* All domains in which DOTS is deployed are assumed to offer the required connectivity between DOTS agents and any intermediary network elements, but the architecture imposes no additional limitations on the form of connectivity.
* ドットが展開されているすべてのドメインは、ドットエージェントと仲介ネットワーク要素との間に必要な接続性を提供すると仮定されていますが、アーキテクチャは接続性の形式に追加の制限を課しません。
* Congestion and resource exhaustion are intended outcomes of a DDoS attack [RFC4732]. Some operators may utilize non-impacted paths or networks for DOTS. However, in general, conditions should be assumed to be hostile, and DOTS must be able to function in all circumstances, including when the signaling path is significantly impaired. Congestion control requirements are discussed in Section 3 of [RFC8612]. The DOTS signal channel defined in [RFC8782] is designed to be extremely resilient under extremely hostile network conditions, and it provides continued contact between DOTS agents even as DDoS attack traffic saturates the link.
* 輻輳と資源の枯渇は、DDOS攻撃の意図的な結果[RFC4732]です。一部のオペレータは、ドットのために非影響を受けたパスまたはネットワークを利用することができます。しかしながら、一般に、条件は敵対的であると仮定されるべきであり、そしてシグナリング経路が著しく損なわれたときを含む、ドットはあらゆる状況において機能することができなければならない。輻輳制御要件については、[RFC8612]のセクション3で説明します。[RFC8782]で定義されているドット信号チャネルは、極めて敵対的なネットワーク状態の下で極端に弾力があるように設計されており、DDOS攻撃トラフィックがリンクを飽和させてもドットエージェント間の連絡先を提供します。
* There is no universal DDoS attack scale threshold triggering a coordinated response across administrative domains. A network domain administrator or service or application owner may arbitrarily set attack scale threshold triggers, or manually send requests for mitigation.
* 管理ドメイン間で協調した応答を引き起こすユニバーサルDDOS攻撃スケールスレッショルドはありません。ネットワークドメイン管理者またはサービス所有者またはアプリケーションの所有者は、攻撃スケールのしきい値トリガを任意に設定するか、または手動で緩和の要求を送信することができます。
* Mitigation requests may be sent to one or more upstream DOTS servers based on criteria determined by DOTS client administrators and the underlying network configuration. The number of DOTS servers with which a given DOTS client has established communications is determined by local policy and is deployment specific. For example, a DOTS client of a multihomed network may support built-in policies to establish DOTS relationships with DOTS servers located upstream of each interconnection link.
* 緩和要求は、ドットクライアント管理者および基礎となるネットワーク構成によって決定された基準に基づいて、1つまたは複数のアップストリームドットサーバに送信されてもよい。与えられたドットクライアントが確立されたドットサーバの数は、ローカルポリシーによって決定され、展開固有の展開である。例えば、マルチホームネットワークのドットクライアントは、各相互接続リンクの上流にあるドットサーバとのドット関係を確立するために内蔵ポリシーをサポートすることができる。
* The mitigation capacity and/or capability of domains receiving requests for coordinated attack response is opaque to the domains sending the request. The domain receiving the DOTS client signal may or may not have sufficient capacity or capability to filter any or all DDoS attack traffic directed at a target. In either case, the upstream DOTS server may redirect a request to another DOTS server. Redirection may be local to the redirecting DOTS server's domain or may involve a third-party domain.
* 調整された攻撃応答の要求を受信したドメインの軽減能力および/または能力は、要求を送信するドメインに対して不透明です。ドットクライアント信号を受信するドメインは、ターゲットに向けられた任意のまたはすべてのDDOS攻撃トラフィックをフィルタリングするのに十分な容量または機能を有していてもいなくてもよい。いずれの場合も、上流のドットサーバは要求を別のドットサーバにリダイレクトすることができる。リダイレクトは、リダイレクトドットサーバのドメインに対してローカルであるか、またはサードパーティドメインを含み得る。
* DOTS client and server signals, as well as messages sent through the data channel, are sent across any transit networks with the same probability of delivery as any other traffic between the DOTS client domain and the DOTS server domain. Any encapsulation required for successful delivery is left untouched by transit network elements. DOTS servers and DOTS clients cannot assume any preferential treatment of DOTS signals. Such preferential treatment may be available in some deployments (e.g., intra-domain scenarios), and the DOTS architecture does not preclude its use when available. However, DOTS itself does not address how that may be done.
* ドットクライアントおよびサーバーの信号、およびデータチャネルを介して送信されたメッセージは、ドットクライアントドメインとドットサーバードメインの間の他のトラフィックと同じ配信確率で、任意のトランジットネットワークにわたって送信されます。配信が成功するために必要なカプセル化は、トランジットネットワーク要素によってタッチされなくなります。ドットサーバおよびドットクライアントは、ドット信号の優先的な処理を想定することはできない。そのような優先治療は、いくつかの展開（例えば、ドメイン内シナリオ）において利用可能であり得、そしてドットアーキテクチャは利用可能なときにその使用を妨げない。ただし、ドット自体は、それがどのように行われる可能性があるかに対処しません。
* The architecture allows for, but does not assume, the presence of Quality-of-Service (QoS) policy agreements between DOTS-enabled peer networks or local QoS prioritization aimed at ensuring delivery of DOTS messages between DOTS agents. QoS is an operational consideration only, not a functional part of the DOTS architecture.
* アーキテクチャは、ドット対応のピアネットワーク間のサービス品質（QoS）ポリシー契約の存在（QoS）ポリシー契約またはドットエージェント間のドットメッセージの配信を確実にすることを目的としている。QoSは、ドットアーキテクチャの機能的部分ではなく、運用上の考慮事項のみです。
* The signal and data channels are loosely coupled and might not terminate on the same DOTS server. How the DOTS servers synchronize the DOTS configuration is out of scope of this specification.
* 信号チャネルとデータチャネルは緩やかに結合され、同じドットサーバー上で終了しない可能性があります。ドットサーバがドット設定をどのように同期させるかは、この仕様の範囲外です。
The basic high-level DOTS architecture is illustrated in Figure 1:
基本的な高水準ドットアーキテクチャは図1に示されています。
+-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +-------------+
|
|
|
+---------------+ +-------------+
| Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+
Figure 1: Basic DOTS Architecture
図1：基本ドットアーキテクチャ
A simple example instantiation of the DOTS architecture could be an enterprise as the attack target for a volumetric DDoS attack and an upstream DDoS mitigation service as the mitigator. The service provided by the mitigator is called "DDoS mitigation service". The enterprise (attack target) is connected to the Internet via a link that is getting saturated, and the enterprise suspects it is under DDoS attack. The enterprise has a DOTS client, which obtains information about the DDoS attack and signals the DOTS server for help in mitigating the attack. In turn, the DOTS server invokes one or more mitigators, which are tasked with mitigating the actual DDoS attack and, hence, aim to suppress the attack traffic while allowing valid traffic to reach the attack target.
ドットアーキテクチャの簡単な例では、ボリュメトリックDDOS攻撃および省略可能なDDOS軽減サービスの攻撃対象としての企業であり得る。Mitigatorによって提供されるサービスは「DDOS軽減サービス」と呼ばれます。企業（攻撃対象）は、飽和しているリンクを介してインターネットに接続されており、企業はDDOS攻撃の下にあると思われます。企業にはDOTSクライアントがあります。これは、DDOS攻撃に関する情報を取得し、攻撃を軽減するのに役立つドットサーバーをシグナリングします。次に、DOTSサーバーは、実際のDDOS攻撃を軽減することで任意の採用されている1つ以上の複雑なものを呼び出します。したがって、有効なトラフィックを攻撃対象に到達させながら攻撃トラフィックを抑制することを目的としています。
The scope of the DOTS specifications is the interfaces between the DOTS client and DOTS server. The interfaces to the attack target and the mitigator are out of scope of DOTS. Similarly, the operation of both the attack target and the mitigator is out of scope of DOTS. Thus, DOTS specifies neither how an attack target decides it is under DDoS attack nor does DOTS specify how a mitigator may actually mitigate such an attack. A DOTS client's request for mitigation is advisory in nature and might not lead to any mitigation at all, depending on the DOTS server domain's capacity and willingness to mitigate on behalf of the DOTS client domain.
ドット指定の範囲は、ドットクライアントとドットサーバーの間のインターフェイスです。攻撃対象と軽減者へのインタフェースはドットの範囲外です。同様に、攻撃対象と軽減者の両方の操作はドットの範囲外です。したがって、DOTは、攻撃対象がDDOS攻撃の下にあることを決定したり、ドットは、実際にそのような攻撃を軽減する方法を指定したりすることも、どのようにしていかないかを指定しません。ドットクライアントの緩和の要求は、自然の中で勧められており、ドット・クライアント・ドメインの代わりに軽減するためのドット・サーバーのドメインの容量と意思に応じて、まったく緩和されない可能性があります。
The DOTS client may be provided with a list of DOTS servers, each associated with one or more IP addresses. These addresses may or may not be of the same address family. The DOTS client establishes one or more sessions by connecting to the provided DOTS server addresses.
ドットクライアントは、それぞれ1つまたは複数のIPアドレスに関連付けられているドットサーバのリストを備えることができる。これらのアドレスは同じアドレスファミリである場合とそうでない場合があります。ドットクライアントは、提供されたドットサーバーアドレスに接続することによって1つ以上のセッションを確立します。
As illustrated in Figure 2, there are two interfaces between a DOTS server and a DOTS client: a signal channel and (optionally) a data channel.
図2に示すように、ドットサーバとドットクライアントとの間には2つのインターフェースがあり、信号チャネルおよび（オプションで）データチャネルがある。
+---------------+ +---------------+
| | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | |
+---------------+ +---------------+
Figure 2: DOTS Interfaces
図2：ドットインタフェース
The primary purpose of the signal channel is for a DOTS client to ask a DOTS server for help in mitigating an attack and for the DOTS server to inform the DOTS client about the status of such mitigation. The DOTS client does this by sending a client signal that contains information about the attack target(s). The client signal may also include telemetry information about the attack, if the DOTS client has such information available. In turn, the DOTS server sends a server signal to inform the DOTS client of whether it will honor the mitigation request. Assuming it will, the DOTS server initiates attack mitigation and periodically informs the DOTS client about the status of the mitigation. Similarly, the DOTS client periodically informs the DOTS server about the client's status, which, at a minimum, provides client (attack target) health information; it should also include efficacy information about the attack mitigation as it is now seen by the client. At some point, the DOTS client may decide to terminate the server-side attack mitigation, which it indicates to the DOTS server over the signal channel. A mitigation may also be terminated if a DOTS client-specified mitigation lifetime is exceeded. Note that the signal channel may need to operate over a link that is experiencing a DDoS attack and, hence, is subject to severe packet loss and high latency.
信号チャネルの主な目的は、ドットクライアントがドットサーバに攻撃を軽減するためのドットサーバとドットサーバにそのような緩和の状況についてドットクライアントに知らせるためにドットサーバを依頼することである。ドットクライアントは、攻撃対象に関する情報を含むクライアント信号を送信することによってこれを行います。クライアント信号はまた、ドットクライアントがそのような情報を利用可能にしている場合、攻撃に関する遠隔測定情報を含み得る。順番に、ドットサーバはそれが緩和要求を尊重するかどうかのドットクライアントに通知するためにサーバ信号を送信する。それがそうなると仮定すると、ドットサーバは攻撃の軽減を開始し、緩和の状況についてドットクライアントに定期的に通知する。同様に、ドットクライアントは、クライアントのステータスについて定期的にドットサーバーに通知します。これは、最低限、クライアント（攻撃対象）の健康情報を提供します。現在クライアントから見られるように攻撃軽減に関する有効な情報も含まれるべきです。ある時点で、ドットクライアントはサーバー側の攻撃軽減を終了することを決定します。これは、それが信号チャネルを介してドットサーバーを示すことを示します。ドットクライアント指定の緩和寿命を超えると、軽減も終了することがあります。信号チャネルは、DDOS攻撃を経験しているリンクを介して動作する必要があるかもしれないので、厳しいパケット損失と高い待ち時間の対象となる。
While DOTS is able to request mitigation with just the signal channel, the addition of the DOTS data channel provides for additional, more efficient capabilities. The primary purpose of the data channel is to support DOTS-related configuration and policy information exchange between the DOTS client and the DOTS server. Examples of such information include, but are not limited to:
ドットは信号チャネルだけで緩和を要求することができるが、ドットデータチャネルの追加は追加のより効率的な能力を提供する。データチャネルの主な目的は、ドットクライアントとドットサーバーとの間のドット関連の設定およびポリシー情報交換をサポートすることです。そのような情報の例としては、以下が含まれるが、これらに限定されない。
* Creating identifiers, such as names or aliases, for resources for which mitigation may be requested. Such identifiers may then be used in subsequent signal channel exchanges to refer more efficiently to the resources under attack.
* 軽減が要求される可能性があるリソースについては、名前やエイリアスなどの識別子を作成します。その場合、そのような識別子は、後続の信号チャネル交換で攻撃下のリソースにより効率的に参照することができる。
* Drop-list management, which enables a DOTS client to inform the DOTS server about sources to suppress.
* ドットクライアントがドットサーバーに抑制するようにドットサーバーに通知することを可能にするドットリスト管理。
* Accept-list management, which enables a DOTS client to inform the DOTS server about sources from which traffic is always accepted.
* Accept-List Management。これにより、ドットクライアントがトラフィックが常に受け入れられたソースについてドットサーバーに通知することができます。
* Filter management, which enables a DOTS client to install or remove traffic filters dropping or rate-limiting unwanted traffic.
* Dotsクライアントがトラフィックフィルタをインストールまたは削除できるようにするフィルタ管理は、不要なトラフィックを削除またはレート制限することができます。
* DOTS client provisioning.
* ドットクライアントプロビジョニング
Note that, while it is possible to exchange the above information before, during, or after a DDoS attack, DOTS requires reliable delivery of this information and does not provide any special means for ensuring timely delivery of it during an attack. In practice, this means that DOTS deployments should rely on such information being exchanged only under normal traffic conditions.
なお、DDOS攻撃の前、終了、または後に上記の情報を交換することは可能であるが、ドットはこの情報を信頼できる配信を必要とし、攻撃中のタイムリーな配信を確実にするための特別な手段を提供しない。実際には、これは、ドット展開が通常のトラフィック条件下でのみ交換される情報に依存する必要があることを意味します。
DOTS does not prescribe any specific deployment models; however, DOTS is designed with some specific requirements around the different DOTS agents and their relationships.
ドットは特定の展開モデルを規定していません。ただし、ドットは異なるドットエージェントとその関係の周囲の特定の要件を備えて設計されています。
First of all, a DOTS agent belongs to a domain that has an identity that can be authenticated and authorized. DOTS agents communicate with each other over a mutually authenticated signal channel and (optionally) data channel. However, before they can do so, a service relationship needs to be established between them. The details and means by which this is done is outside the scope of DOTS; however, an example would be for an enterprise A (DOTS client) to sign up for DDoS service from provider B (DOTS server). This would establish a (service) relationship between the two that enables enterprise A's DOTS client to establish a signal channel with provider B's DOTS server. A and B will authenticate each other, and B can verify that A is authorized for its service.
まず第一に、ドットエージェントは、認証および許可されたアイデンティティを持つドメインに属します。ドットエージェントは、相互認証された信号チャネルと（オプションで）データチャネルを介して互いに通信します。しかし、彼らがそうする前に、それらの間にサービス関係を確立する必要があります。これが行われる詳細と手段はドットの範囲外です。ただし、例としては、Enterprise A（ドットクライアント）がプロバイダB（ドットサーバ）からDDOSサービスにサインアップすることがあります。これは、エンタープライズAのドットクライアントがプロバイダBのドットサーバーを持つシグナルチャネルを確立できるようにする2つの間に（サービス）関係を確立します。AとBは互いに認証され、BはAがそのサービスの許可されていることを確認できます。
From an operational and design point of view, DOTS assumes that the above relationship is established prior to a request for DDoS attack mitigation. In particular, it is assumed that bidirectional communication is possible at this time between the DOTS client and DOTS server. Furthermore, it is assumed that additional service provisioning, configuration, and information exchange can be performed by use of the data channel if operationally required. It is not until this point that the mitigation service is available for use.
運用上および設計上の観点から、DOTはDDOS攻撃の緩和の要求の前に上記の関係が確立されていると仮定しています。特に、このとき、ドットクライアントとドットサーバの間で双方向通信が可能であるとする。また、操作上に必要な場合は、データチャネルを用いて追加のサービスプロビジョニング、構成、および情報交換を行うことができると仮定する。この時点までではなく、軽減サービスが使用可能です。
Once the mutually authenticated signal channel has been established, it will remain active. This is done to increase the likelihood that the DOTS client can signal the DOTS server for help when the attack target is being flooded, and similarly raise the probability that DOTS server signals reach the client regardless of inbound link congestion. This does not necessarily imply that the attack target and the DOTS client have to be co-located in the same administrative domain, but it is expected to be a common scenario.
相互認証された信号チャネルが確立されると、アクティブのままになります。これは、攻撃ターゲットがあふれているときにドットクライアントがドットサーバを送ることができる可能性を高めるために行われ、同様に、インバウンドリンクの輻輳に関係なくドットサーバ信号がクライアントに到達する確率を上げる。これは必ずしも攻撃対象とドットクライアントが同じ管理ドメイン内に同じ場所に配置されなければならないことを必ずしも意味しますが、一般的なシナリオであると予想されます。
DDoS mitigation with the help of an upstream mitigator may involve some form of traffic redirection whereby traffic destined for the attack target is steered towards the mitigator. Common mechanisms to achieve this redirection depend on BGP [RFC4271] and DNS [RFC1035]. In turn, the mitigator inspects and scrubs the traffic and forwards the resulting (hopefully non-attack) traffic to the attack target. Thus, when a DOTS server receives an attack mitigation request from a DOTS client, it can be viewed as a way of causing traffic redirection for the attack target indicated.
上流の軽減者の助けを借りたDDOS緩和は、攻撃対象宛てのトラフィックが採用されているいくつかの形式の交通方向リダイレクトを含み得る。このリダイレクトを達成するための一般的なメカニズムは、BGP [RFC4271]とDNS [RFC1035]に依存します。順番に、障害者はトラフィックを検査してスクラブし、結果として生じる（うまくいけば非攻撃）トラフィックを攻撃対象に転送します。したがって、ドットサーバがドットクライアントから攻撃の軽減要求を受信すると、攻撃対象のトラフィックリダイレクトを指示する方法として表示することができる。
DOTS relies on mutual authentication and the pre-established service relationship between the DOTS client domain and the DOTS server domain to provide authorization. The DOTS server should enforce authorization mechanisms to restrict the mitigation scope a DOTS client can request, but such authorization mechanisms are deployment specific.
ドットは、承認を提供するために、相互認証とドットクライアントドメインとドットサーバードメインの間の事前確立されたサービス関係に依存しています。ドットサーバーは、ドットクライアントが要求できる緩和スコープを制限するための許可メカニズムを強制する必要がありますが、そのような許可メカニズムは展開固有です。
Although co-location of DOTS server and mitigator within the same domain is expected to be a common deployment model, it is assumed that operators may require alternative models. Nothing in this document precludes such alternatives.
同じドメイン内のドットサーバーと採取者のコロケーションは一般的な展開モデルであると予想されますが、オペレータは代替モデルを必要とする可能性があると仮定されます。この文書の中では、そのような選択肢を妨げるものは何もない。
A DOTS client is a DOTS agent from which requests for help coordinating an attack response originate. The requests may be in response to an active, ongoing attack against a target in the DOTS client domain, but no active attack is required for a DOTS client to request help. Operators may wish to have upstream mitigators in the network path for an indefinite period and are restricted only by business relationships when it comes to duration and scope of requested mitigation.
DOTSクライアントは、攻撃応答を調整するための要求が発生する要求が発生するドットエージェントです。要求は、ドットクライアントドメイン内のターゲットに対するアクティブな継続的な攻撃に応答している可能性がありますが、ドットクライアントがヘルプを要求するのに有効な攻撃は必要ありません。オペレータは、不定期間のネットワークパスに上流の施設を持ち、それが要求された緩和の期間および範囲になると業務関係によってのみ制限されているかもしれません。
The DOTS client requests attack response coordination from a DOTS server over the signal channel, including in the request the DOTS client's desired mitigation scoping, as described in [RFC8612] (SIG-008). The actual mitigation scope and countermeasures used in response to the attack are up to the DOTS server and mitigator operators, as the DOTS client may have a narrow perspective on the ongoing attack. As such, the DOTS client's request for mitigation should be considered advisory: guarantees of DOTS server availability or mitigation capacity constitute Service Level Agreements (SLAs) and are out of scope for this document.
DOTSクライアントは、[RFC8612]（SIG-008）に記載されているように、ドットクライアントの希望の緩和スコープを要求することを含む、信号チャネルを介してドットチャネルを介してドットサーバーからの攻撃応答調整を要求します（SIG-008）。ドットクライアントが進行中の攻撃について狭い視点を持つことができるので、攻撃に対応して使用された実際の緩和範囲および対策は、ドットサーバーと復元演算子になります。このように、ドットクライアントの緩和の要求はアドバイザリと見なされるべきです：ドットサーバーの可用性または緩和能力の保証はサービスレベル契約（SLA）を構成し、この文書の範囲外です。
The DOTS client adjusts mitigation scope and provides available mitigation feedback (e.g., mitigation efficacy) at the direction of its local administrator. Such direction may involve manual or automated adjustments in response to updates from the DOTS server.
ドットクライアントは緩和スコープを調整し、そのローカル管理者の方向に利用可能な緩和フィードバック（例えば、緩和効果）を提供する。そのような方向は、ドットサーバからの更新に応答して手動または自動調整を含み得る。
To provide a metric of signal health and distinguish an idle signal channel from a disconnected or defunct session, the DOTS client sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS client similarly expects a heartbeat from the DOTS server and may consider a session terminated in the extended absence of a DOTS server heartbeat.
シグナルヘルスのメトリックを提供し、アイドル信号チャネルを切断またはデフルセッションから区別するために、ドットクライアントはチャネルの半分を維持するために信号チャネル上にハートビートを送る。ドットクライアントは、ドットサーバからのハートビートを同様に期待し、ドットサーバハートビートの拡張された不在においてセッションを終了することを考慮することができる。
A DOTS server is a DOTS agent capable of receiving, processing, and possibly acting on requests for help coordinating attack responses from DOTS clients. The DOTS server authenticates and authorizes DOTS clients as described in Section 3.1 and maintains session state, tracks requests for mitigation, reports on the status of active mitigations, and terminates sessions in the extended absence of a client heartbeat or when a session times out.
ドットサーバは、ドットクライアントからの攻撃応答を調整するための要求に応じて、処理、処理、およびおそらく行動することができるドットエージェントである。DOTSサーバーは、セクション3.1で説明されているようにドットクライアントを認証して承認し、セッション状態を維持し、緩和の要求を維持し、アクティブな軽減のステータスについての報告、およびクライアントのハートビートの不在のセッションまたはセッションがタイムアウトしたときにセッションを終了します。
Assuming the preconditions discussed below exist, a DOTS client maintaining an active session with a DOTS server may reasonably expect some level of mitigation in response to a request for coordinated attack response.
後述の前提条件が存在すると仮定すると、ドットサーバとのアクティブセッションを維持するドットクライアントは、協調攻撃応答の要求に応じて、ある程度の軽減を合理的に期待することができる。
For a given DOTS client (administrative) domain, the DOTS server needs to be able to determine whether a given resource is in that domain. For example, this could take the form of associating a set of IP addresses and/or prefixes per DOTS client domain. The DOTS server enforces authorization of signals for mitigation, filtering rules, and aliases for resources from DOTS clients. The mechanism of enforcement is not in scope for this document but is expected to restrict mitigation requests, filtering rules, aliases for addresses and prefixes, and/or services owned by the DOTS client domain, such that a DOTS client from one domain is not able to influence the network path to another domain. A DOTS server MUST reject mitigation requests, filtering rules, and aliases for resources not owned by the requesting DOTS client's administrative domain. The exact mechanism for the DOTS servers to validate that the resources are within the scope of the DOTS client domain is deployment specific. For example, if the DOTS client domain uses Provider-Aggregatable prefixes for its resources and leverages the DDoS mitigation service of the Internet Transit Provider (ITP); the ITP knows the prefixes assigned to the DOTS client domain because they are assigned by the ITP itself. However, if the DDoS Mitigation is offered by a third-party DDoS mitigation service provider; it does not know the resources owned by the DOTS client domain. The DDoS mitigation service provider and the DOTS client domain can opt to use the identifier validation challenges discussed in [RFC8555] and [RFC8738] to identify whether or not the DOTS client domain actually controls the resources. The challenges for validating control of resources must be performed when no attack traffic is present and works only for "dns" and "ip" identifier types. Further, if the DOTS client lies about the resources owned by the DOTS client domain, the DDoS mitigation service provider can impose penalties for violating the SLA. A DOTS server MAY also refuse a DOTS client's mitigation request for arbitrary reasons, within any limits imposed by business or SLAs between client and server domains. If a DOTS server refuses a DOTS client's request for mitigation, the DOTS server MUST include the refusal reason in the server signal sent to the client.
特定のドットクライアント（管理）ドメインの場合、ドットサーバは、特定のリソースがそのドメイン内にあるかどうかを判断できる必要があります。たとえば、これは、一連のIPアドレスと/またはドットクライアントドメインごとにプレフィックスを関連付けるという形式をとることができます。 DOTSサーバは、ドットクライアントからのリソースのための緩和、フィルタリング規則、およびエイリアスのための信号の許可を強制します。執行のメカニズムはこの文書には範囲内ではありませんが、ドットクライアントドメインが所有する緩和要求、フィルタリングルール、エイリアス、および/または1つのドメインからのドットクライアントが有効ではないように予想されます。ネットワークパスに別のドメインへの影響を与える。ドットサーバーは、要求側のドットクライアントの管理ドメインによって所有されていないリソースの軽減要求、フィルタリングルール、およびエイリアスを拒否する必要があります。ドットサーバの正確なメカニズムは、リソースがドットクライアントドメインの範囲内にあることを検証するための正確なメカニズムは展開固有のものです。たとえば、ドットクライアントドメインがプロバイダ - 集約可能なプレフィックスを使用している場合は、インターネットトランジットプロバイダ（ITP）のDDOS軽減サービスを利用しています。 ITPは、ITP自体によって割り当てられているため、ドットクライアントドメインに割り当てられているプレフィックスを知っています。ただし、DDOの軽減がサードパーティのDDOS軽減サービスプロバイダによって提供されている場合。ドットクライアントドメインが所有するリソースがわかりません。 DDOS軽減サービスプロバイダとDOTSクライアントドメインは、[RFC8555]と[RFC8738]で説明した識別子検証の課題を使用して、ドットクライアントドメインが実際にリソースを制御するかどうかを識別することを選択できます。リソースの制御を検証するための課題は、攻撃トラフィックが存在しない場合に実行されなければならず、「DNS」および「IP」識別子タイプのみが機能します。さらに、ドットクライアントがドットクライアントドメインによって所有されているリソースの周りにある場合、DDOS軽減サービスプロバイダーはSLAに違反するための罰則を課すことができます。ドットサーバはまた、クライアントドメインとサーバドメイン間のビジネスやSLAによって課される任意の制限内で、任意の理由に対するドットクライアントの緩和要求を拒否することができる。ドットサーバがドットクライアントの緩和要求を拒否した場合、ドットサーバはクライアントに送信されたサーバ信号内の拒否理由を含める必要があります。
A DOTS server is in regular contact with one or more mitigators. If a DOTS server accepts a DOTS client's request for help, the DOTS server forwards a translated form of that request to the mitigator(s) responsible for scrubbing attack traffic. Note that the form of the translated request passed from the DOTS server to the mitigator is not in scope; it may be as simple as an alert to mitigator operators, or highly automated using vendor or open application programming interfaces supported by the mitigator. The DOTS server MUST report the actual scope of any mitigation enabled on behalf of a client.
ドットサーバーは1つ以上の採取者と定期的に連絡します。ドットサーバーがドットクライアントのヘルプの要求を受け入れると、ドットサーバーはその要求の翻訳された形式を攻撃トラフィックのスクラビングを担当する担当者に転送します。ドットサーバから省略された翻訳要求の形式は範囲内ではないことに注意してください。それは、演算子の演算子の警告や、製造者によってサポートされているベンダーまたはオープンアプリケーションプログラミングインタフェースを使用して高度に自動化されている可能性があります。ドットサーバーは、クライアントに代わって軽減の実際の範囲を報告する必要があります。
The DOTS server SHOULD retrieve available metrics for any mitigations activated on behalf of a DOTS client and SHOULD include them in server signals sent to the DOTS client originating the request for mitigation.
ドットサーバは、ドットクライアントの代わりにアクティブ化された任意の軽減のために利用可能なメトリックを取得する必要があり、緩和の要求を発信するドットクライアントに送信されたサーバ信号に含めるべきである。
To provide a metric of signal health and distinguish an idle signal channel from a disconnected or defunct channel, the DOTS server MUST send a heartbeat over the signal channel to maintain its half of the channel. The DOTS server similarly expects a heartbeat from the DOTS client and MAY consider a session terminated in the extended absence of a DOTS client heartbeat.
シグナルヘルスのメトリックを提供し、アイドル信号チャネルを切断または除算チャネルから区別するために、ドットサーバはチャネルの半分を維持するために信号チャネル上にハートビートを送る必要があります。DOTSサーバは、ドットクライアントからのハートビートを同様に期待し、ドットクライアントハートビートの拡張された不在でセッションを終了すると考えることができる。
Traditional client/server relationships may be expanded by chaining DOTS sessions. This chaining is enabled through "logical concatenation" of a DOTS server and a DOTS client, resulting in an application analogous to the Session Initiation Protocol (SIP) [RFC3261] logical entity of a Back-to-Back User Agent (B2BUA) [RFC7092]. The term "DOTS gateway" is used here in the descriptions of selected scenarios involving this application.
伝統的なクライアント/サーバーの関係は、ドットセッションをチェーン化することによって拡張されます。この連鎖は、ドットサーバーとドットクライアントの「論理的な連結」を介して有効になり、その結果、セッション開始プロトコル（SIP）[RFC3261]バックツーバックユーザーエージェントの論理エンティティ（B2BUA）[RFC7092）]。このアプリケーションを含む選択されたシナリオの説明では、「ドットゲートウェイ」という用語がここで使用されています。
A DOTS gateway may be deployed client side, server side, or both. The gateway may terminate multiple discrete client connections and may aggregate these into a single or multiple DOTS session(s).
ドットゲートウェイは、クライアント側、サーバー側、またはその両方を展開することができます。ゲートウェイは複数のディスクリートクライアント接続を終了し、これらを単一または複数のドットセッションに集約してもよい。
The DOTS gateway will appear as a server to its downstream agents and as a client to its upstream agents, a functional concatenation of the DOTS client and server roles, as depicted in Figure 3:
ドットゲートウェイは、図3に示すように、その下流のエージェントへのサーバーとして、そしてその上流のエージェントへのクライアントとして、ドットクライアントとサーバーの役割の機能的な連結です。
+-------------+
| | D | |
+----+ | | O | | +----+
| c1 |----------| s1 | T | c2 |---------| s2 |
+----+ | | S | | +----+
| | G | |
+-------------+
Figure 3: DOTS Gateway
図3：ドットゲートウェイ
The DOTS gateway MUST perform full stack DOTS session termination and reorigination between its client and server side. The details of how this is achieved are implementation specific.
ドットゲートウェイは、クライアントとサーバー側の間の完全スタックドットセッション終了と再調整を実行する必要があります。これがどのように達成されるかの詳細は実装固有です。
So far, we have only considered a relatively simple scenario of a single DOTS client associated with a single DOTS server; however, DOTS supports more advanced relationships.
これまでのところ、単一のドットサーバーに関連付けられた単一のドットクライアントの比較的単純なシナリオと見なされています。ただし、ドットはより高度な関係をサポートします。
A DOTS server may be associated with one or more DOTS clients, and those DOTS clients may belong to different domains. An example scenario is a mitigation provider serving multiple attack targets (Figure 4).
ドットサーバは、1つまたは複数のドットクライアントに関連付けられていてもよく、それらのドットクライアントは異なるドメインに属することがある。シナリオの例は、複数の攻撃対象を提供する軽減プロバイダです（図4）。
DOTS clients DOTS server
+---+
| c |-----------
+---+ \
c1.example.org \
\
+---+ \ +---+
| c |----------------| S |
+---+ / +---+
c1.example.com / dots1.example.net
/
+---+ /
| c |-----------
+---+
c2.example.com
Figure 4: DOTS Server with Multiple Clients
図4：複数のクライアントを持つドットサーバー
A DOTS client may be associated with one or more DOTS servers, and those DOTS servers may belong to different domains. This may be to ensure high availability or coordinate mitigation with more than one directly connected ISP. An example scenario is for an enterprise to have DDoS mitigation service from multiple providers, as shown in Figure 5.
ドットクライアントは1つまたは複数のドットサーバに関連付けられていてもよく、それらのドットサーバは異なるドメインに属することがある。これは、高可用性を確保すること、または複数の直接接続されたISPを使用して緩和を調整することです。例示的なシナリオは、図5に示すように、企業が複数のプロバイダからDDOS軽減サービスを提供することです。
DOTS client DOTS servers
+---+
-----------| S |
/ +---+
/ dots1.example.net
/
+---+/ +---+
| c |---------------| S |
+---+\ +---+
\ dots.example.org
\
\ +---+
-----------| S |
+---+
c.example.com dots2.example.net
Figure 5: Multihomed DOTS Client
図5：マルチホームドットクライアント
Deploying a multihomed client requires extra care and planning, as the DOTS servers with which the multihomed client communicates might not be affiliated. Should the multihomed client simultaneously request for mitigation from all servers with which it has established signal channels, the client may unintentionally inflict additional network disruption on the resources it intends to protect. In one of the worst cases, a multihomed DOTS client could cause a permanent routing loop of traffic destined for the client's protected services, as the uncoordinated DOTS servers' mitigators all try to divert that traffic to their own scrubbing centers.
マルチホームクライアントを展開するには、マルチホームクライアントが通信するドットサーバが所属していない可能性があるため、特別な注意と計画が必要です。マルチホームクライアントが同時に信号チャネルを確立したすべてのサーバーからの緩和を要求する場合、クライアントは意図していると意図しているリソースに対して意図せずに追加のネットワークの混乱を増大させる可能性があります。最悪の場合、マルチホームドットクライアントは、未処理のドットサーバの障害者がそのトラフィックを自分のスクラブ中心に転送しようとすると、クライアントの保護されたサービス宛てのトラフィックの永続的なルーティングループを引き起こす可能性があります。
The DOTS protocol itself provides no fool-proof method to prevent such self-inflicted harms as a result of deploying multihomed DOTS clients. If DOTS client implementations nevertheless include support for multihoming, they are expected to be aware of the risks, and consequently to include measures aimed at reducing the likelihood of negative outcomes. Simple measures might include:
ドットプロトコル自体は、マルチホームドットクライアントを展開した結果として、そのような自己増幅の害を防ぐための耐用性のある方法を提供しません。それにもかかわらず、ドットクライアントの実装がマルチホームのサポートを含む場合、それらはリスクを認識することが期待されており、その結果、否定的な結果の可能性を低下させることを目的とした措置を含めること。単純な対策には以下が含まれます。
* Requesting mitigation serially, ensuring only one mitigation request for a given address space is active at any given time;
* 緩和を依頼して、特定のアドレス空間に対する1つの緩和要求のみを確実にすることで、任意の時間にアクティブになります。
* Dividing the protected resources among the DOTS servers, such that no two mitigators will be attempting to divert and scrub the same traffic;
* DOTSサーバーの間で保護されたリソースを分割して、2つの採用者が同じトラフィックを迂回しスクラブしようとしていないようにします。
* Restricting multihoming to deployments in which all DOTS servers are coordinating management of a shared pool of mitigation resources.
* すべてのドットサーバーが緩和リソースの共有プールの管理を調整している展開にマルチホームを制限します。
As discussed in Section 2.2.3, a DOTS gateway is a logical function chaining DOTS sessions through concatenation of a DOTS server and DOTS client.
セクション2.2.3で説明したように、ドットゲートウェイは、ドットサーバーとドットクライアントの連結を通してドットセッションを連鎖する論理関数です。
An example scenario, as shown in Figure 6 and Figure 7, is for an enterprise to have deployed multiple DOTS-capable devices that are able to signal intra-domain using TCP [RFC0793] on uncongested links to a DOTS gateway that may then transform these to a UDP [RFC0768] transport inter-domain where connection-oriented transports may degrade; this applies to the signal channel only, as the data channel requires a connection-oriented transport. The relationship between the gateway and its upstream agents is opaque to the initial clients.
図6および図7に示すように、シナリオの例は、企業が、存在しないリンクゲートウェイへのTCP [RFC0793]を使用してドメイン内ドメインを使用して、ドットゲートウェイへの電子内ドメインを使用することができる複数のドット対応デバイスを展開しています。接続指向のトランスポートが劣化する可能性があるUDP [RFC0768]輸送間のドメインへ。これは、データチャネルが接続指向のトランスポートを必要とするため、信号チャネルにのみ適用されます。ゲートウェイとその上流のエージェントの間の関係は、最初のクライアントに対する不透明です。
+---+
| c |\
+---+ \ +---+
\-----TCP-----| D | +---+
+---+ | O | | |
| c |--------TCP-----| T |------UDP------| S |
+---+ | S | | |
/-----TCP-----| G | +---+
+---+ / +---+
| c |/
+---+
example.com example.com example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 6: Client-Side Gateway with Aggregation
図6：集約付きクライアントサイドゲートウェイ
+---+
| c |\
+---+ \ +---+
\-----TCP-----| D |------UDP------+---+
+---+ | O | | |
| c |--------TCP-----| T |------UDP------| S |
+---+ | S | | |
/-----TCP-----| G |------UDP------+---+
+---+ / +---+
| c |/
+---+
example.com example.com example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 7: Client-Side Gateway without Aggregation
図7：集約なしのクライアントサイドゲートウェイ
This may similarly be deployed in the inverse scenario where the gateway resides in the server-side domain and may be used to terminate and/or aggregate multiple clients to a single transport as shown in Figure 8 and Figure 9.
これは、ゲートウェイがサーバ側ドメインに存在する逆シナリオに同様に展開され、図8および図9に示すように、複数のクライアントを単一のトランスポートに終了および/または集約するために使用され得る。
+---+
| c |\
+---+ \ +---+
\-----UDP-----| D | +---+
+---+ | O | | |
| c |--------TCP-----| T |------TCP------| S |
+---+ | S | | |
/-----TCP-----| G | +---+
+---+ / +---+
| c |/
+---+
example.com example.net example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 8: Server-Side Gateway with Aggregation
図8：集計付きサーバーサイドゲートウェイ
+---+
| c |\
+---+ \ +---+
\-----UDP-----| D |------TCP------+---+
+---+ | O | | |
| c |--------TCP-----| T |------TCP------| S |
+---+ | S | | |
/-----UDP-----| G |------TCP------+---+
+---+ / +---+
| c |/
+---+
example.com example.net example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
Figure 9: Server-Side Gateway without Aggregation
図9：集約なしのサーバーサイドゲートウェイ
This document anticipates scenarios involving multiple DOTS gateways. An example is a DOTS gateway at the network client's side and another one at the server side. The first gateway can be located at Customer Premises Equipment (CPE) to aggregate requests from multiple DOTS clients enabled in an enterprise network. The second DOTS gateway is deployed on the provider side. This scenario can be seen as a combination of the client-side and server-side scenarios.
この文書は、複数のドットゲートウェイを含むシナリオを予測します。一例は、ネットワーククライアントの側のドットゲートウェイとサーバー側の別のものです。最初のゲートウェイは、企業ネットワークで有効になっている複数のドットクライアントからの要求を集約するために、顧客宅内機器（CPE）に配置できます。2番目のドットゲートウェイはプロバイダ側に展開されています。このシナリオは、クライアント側のシナリオとサーバー側のシナリオの組み合わせとして見ることができます。
In order for DOTS to be effective as a vehicle for DDoS mitigation requests, one or more DOTS clients must establish ongoing communication with one or more DOTS servers. While the preconditions for enabling DOTS in or among network domains may also involve business relationships, SLAs, or other formal or informal understandings between network operators, such considerations are out of scope for this document.
ドットがDDOS緩和要求のための車両として有効であるためには、1つまたは複数のドットクライアントは1つ以上のドットサーバとの途中の通信を確立しなければならない。ネットワークドメイン内またはネットワークドメインの間でドットを有効にするための前提条件は、ネットワーク事業者間のビジネス関係、SLA、またはその他の正式または非公式の理解を含み得るが、そのような考慮事項はこの文書の範囲外である。
A DOTS session is established to support bilateral exchange of data between an associated DOTS client and a DOTS server. In the DOTS architecture, data is exchanged between DOTS agents over signal and data channels. As such, a DOTS session can be a DOTS signal channel session, a DOTS data channel session, or both. The DOTS server couples the DOTS signal and data channel sessions using the DOTS client identity. The DOTS session is further elaborated in the DOTS signal channel protocol defined in [RFC8782] and the DOTS data channel protocol defined in [RFC8783].
関連付けられたドットクライアントとドットサーバとの間のデータの二国間のデータ交換をサポートするためのドットセッションが確立される。ドットアーキテクチャでは、信号チャネルとデータチャネルの上のドットエージェント間でデータが交換されます。したがって、ドットセッションは、ドット信号チャネルセッション、ドットデータチャネルセッション、またはその両方であり得る。ドットサーバは、ドットクライアントアイデンティティを使用してドット信号およびデータチャネルセッションを結合する。ドットセッションは、[RFC8782]で定義されているドット信号チャネルプロトコルと[RFC8783]で定義されているドットデータチャネルプロトコルで詳しく説明されています。
A DOTS agent can maintain one or more DOTS sessions.
ドットエージェントは1つ以上のドットセッションを維持することができます。
A DOTS signal channel session is associated with a single transport connection (TCP or UDP session) and a security association (a TLS or DTLS session). Similarly, a DOTS data channel session is associated with a single TCP connection and a TLS security association.
ドット信号チャネルセッションは、単一のトランスポート接続（TCPまたはUDPセッション）およびセキュリティアソシエーション（TLSまたはDTLSセッション）に関連付けられています。同様に、ドットデータチャネルセッションは、単一のTCP接続とTLSセキュリティアソシエーションに関連付けられています。
Mitigation requests created using the DOTS signal channel are not bound to the DOTS signal channel session. Instead, mitigation requests are associated with a DOTS client and can be managed using different DOTS signal channel sessions.
ドット信号チャネルを使用して作成された緩和要求は、ドット信号チャネルセッションにバインドされていません。代わりに、緩和要求はドットクライアントに関連付けられ、異なるドット信号チャネルセッションを使用して管理することができます。
Prior to establishing a DOTS session between agents, the owners of the networks, domains, services or applications involved are assumed to have agreed upon the terms of the relationship involved. Such agreements are out of scope for this document but must be in place for a functional DOTS architecture.
エージェント間のドットセッションを確立する前に、関係するネットワーク、ドメイン、サービス、またはアプリケーションの所有者は、関係の条件に合意したと想定されています。そのような協定はこの文書の範囲外であるが、機能的なドットアーキテクチャのために整っている必要があります。
It is assumed that, as part of any DOTS service agreement, the DOTS client is provided with all data and metadata required to establish communication with the DOTS server. Such data and metadata would include any cryptographic information necessary to meet the message confidentiality, integrity, and authenticity requirement (SEC-002) in [RFC8612] and might also include the pool of DOTS server addresses and ports the DOTS client should use for signal and data channel messaging.
それは、いかなるドットサービス契約の一部として、ドットクライアントは、ドットサーバとの通信を確立するために必要なすべてのデータおよびメタデータを提供されると仮定される。そのようなデータとメタデータには、[RFC8612]のメッセージの機密性、整合性、および信頼性の要件（SEC-002）を満たすために必要なすべての暗号化情報が含まれ、ドットサーバーアドレスのプールやポートのプールを含めることもできます。データチャネルメッセージング
With the required business agreements in place, the DOTS client initiates a DOTS session by contacting its DOTS server(s) over the signal channel and (possibly) the data channel. To allow for DOTS service flexibility, neither the order of contact nor the time interval between channel creations is specified. A DOTS client MAY establish the signal channel first, and then the data channel, or vice versa.
必要なビジネス契約を整えて、ドットクライアントは、信号チャネルを介して（場合によっては）データチャネルを介してそのドットサーバーに連絡することによってドットセッションを開始します。ドットサービスの柔軟性を可能にするために、コンタクトの順序もチャネル作成の間の時間間隔も指定されていません。ドットクライアントは、最初に信号チャネルを確立し、次いでデータチャネル、またはその逆も同様である。
The methods by which a DOTS client receives the address and associated service details of the DOTS server are not prescribed by this document. For example, a DOTS client may be directly configured to use a specific DOTS server IP address and port, and be directly provided with any data necessary to satisfy the Peer Mutual Authentication requirement (SEC-001) in [RFC8612], such as symmetric or asymmetric keys, usernames, passwords, etc. All configuration and authentication information in this scenario is provided out of band by the domain operating the DOTS server.
ドットクライアントがドットサーバのアドレスおよび関連するサービス詳細を受信する方法は、この文書によって規定されていない。例えば、ドットクライアントは、特定のドットサーバIPアドレスとポートを使用するように直接構成され、対称的または[RFC8612]の[RFC8612]のピア相互認証要件（SEC - 001）を満たすのに必要なデータを直接提供させることができる。非対称キー、ユーザ名、パスワードなど、このシナリオのすべての設定と認証情報は、ドットサーバーを操作するドメインによって帯域外に提供されます。
At the other extreme, the architecture in this document allows for a form of DOTS client auto-provisioning. For example, the domain operating the DOTS server or servers might provide the client domain only with symmetric or asymmetric keys to authenticate the provisioned DOTS clients. Only the keys would then be directly configured on DOTS clients, but the remaining configuration required to provision the DOTS clients could be learned through mechanisms similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763].
他の極端に、この文書のアーキテクチャはドットクライアントの自動プロビジョニングの形式を可能にします。たとえば、ドットサーバーまたはサーバーを操作するドメインは、プロビジョニングされたドットクライアントを認証するための対称または非対称のキーでのみクライアントドメインを提供する可能性があります。キーのみがドットクライアントに直接設定されますが、ドットクライアントのプロビジョニングに必要な残りの設定は、DNS SRV [RFC2782]またはDNSサービス検出[RFC6763]と同様のメカニズムを通じて学習できます。
The DOTS client SHOULD successfully authenticate and exchange messages with the DOTS server over both the signal and (if used) data channel as soon as possible to confirm that both channels are operational.
DOTSクライアントは、両方のチャネルが動作可能であることを確認するために、できるだけ早くデータチャネルの両方を介してDOTSサーバーとのメッセージを正常に認証して（使用されている）データチャネルを正常に認証して交換する必要があります。
As described in [RFC8612] (DM-008), the DOTS client can configure preferred values for acceptable signal loss, mitigation lifetime, and heartbeat intervals when establishing the DOTS signal channel session. A DOTS signal channel session is not active until DOTS agents have agreed on the values for these DOTS session parameters, a process defined by the protocol.
[RFC8612]（DM-008）に記載されているように、ドットクライアントは、ドット信号チャネルセッションを確立するときに、許容可能な信号損失、緩和寿命、およびハートビート間隔のための優先値を構成することができる。ドット信号チャネルセッションは、ドットエージェントがこれらのドットセッションパラメータの値に合意されるまでアクティブではなく、プロトコルによって定義されたプロセスである。
Once the DOTS client begins receiving DOTS server signals, the DOTS session is active. At any time during the DOTS session, the DOTS client may use the data channel to manage aliases, manage drop- and accept-listed prefixes or addresses, leverage vendor-specific extensions, and so on. Note that unlike the signal channel, there is no requirement that the data channel remains operational in attack conditions. (See "Data Channel Requirements" Section 2.3 of [RFC8612]).
ドットクライアントがドットサーバー信号の受信を開始すると、ドットセッションはアクティブです。ドットセッションの間にいつでも、ドットクライアントはデータチャネルを使用してエイリアスを管理し、ドロップリストおよびアドレス指定されたプレフィックスまたはアドレスを管理し、ベンダー固有の拡張機能などを活用できます。信号チャネルとは異なり、データチャネルが攻撃条件で動作可能なままであるという要件はありません。（[RFC8612]の「データチャネル要件」セクション2.3を参照してください。
DOTS clients and servers periodically send heartbeats to each other over the signal channel, discussed in [RFC8612] (SIG-004). DOTS agent operators SHOULD configure the heartbeat interval such that the frequency does not lead to accidental denials of service due to the overwhelming number of heartbeats a DOTS agent must field.
ドットクライアントとサーバーは、[RFC8612]（SIG-004）で説明したシグナルチャネルを介して互いにハートビートを互いに周期的に送信します。ドットエージェントオペレータは、圧倒的な数のハートビートが分野であるため、誤った数のハートビートのために周波数が偶発的なサービス拒否につながらないようにハートビート間隔を設定する必要があります。
Either DOTS agent may consider a DOTS signal channel session terminated in the extended absence of a heartbeat from its peer agent. The period of that absence will be established in the protocol definition.
いずれのドットエージェントも、そのピアエージェントから心拍の延長されていない状態で終了したドット信号チャネルセッションを考慮することができる。その不在の期間はプロトコル定義に確立されます。
This section examines the modes of signaling between agents in a DOTS architecture.
このセクションでは、ドットアーキテクチャ内のエージェント間のシグナリングモードについて説明します。
A DOTS session may take the form of direct signaling between the DOTS clients and servers, as shown in Figure 10.
図10に示すように、ドットセッションは、ドットクライアントとサーバとの間の直接シグナリングの形をとることができる。
+-------------+ +-------------+
| DOTS client |<------signal session------>| DOTS server |
+-------------+ +-------------+
Figure 10: Direct Signaling
図10：直接シグナリング
In a direct DOTS session, the DOTS client and server are communicating directly. Direct signaling may exist inter- or intra-domain. The DOTS session is abstracted from the underlying networks or network elements the signals traverse; in direct signaling, the DOTS client and server are logically adjacent.
直接ドットセッションでは、ドットクライアントとサーバーは直接通信しています。直接シグナリングは、インタラオンまたはイントラドメインを存在する可能性があります。ドットセッションは、信号がトラバースする基盤となるネットワークまたはネットワーク要素から抽象化されています。直接シグナリングでは、ドットクライアントとサーバーは論理的に隣接しています。
In certain circumstances, a DOTS server may want to redirect a DOTS client to an alternative DOTS server for a DOTS signal channel session. Such circumstances include but are not limited to:
特定の状況では、ドットサーバはドットクライアントをドット信号チャネルセッションのための代替ドットサーバにリダイレクトすることを望む。そのような状況には、以下が含まれますが、これらに限定されません。
* Maximum number of DOTS signal channel sessions with clients has been reached;
* クライアントを持つドット信号チャネルセッションの最大数に達しました。
* Mitigation capacity exhaustion in the mitigator with which the specific DOTS server is communicating;
* 特定のドットサーバが通信している軽減者における緩和能力の枯渇。
* Mitigator outage or other downtime such as scheduled maintenance;
* スケジュールされたメンテナンスなどの障害者停止またはその他のダウンタイム。
* Scheduled DOTS server maintenance;
* スケジュールドットサーバーのメンテナンス。
* Scheduled modifications to the network path between DOTS server and DOTS client.
* ドットサーバーとドットクライアント間のネットワークパスへのスケジュール変更。
A basic redirected DOTS signal channel session resembles the following, as shown in Figure 11.
図11に示すように、基本リダイレクトドット信号チャネルセッションは以下のように似ています。
+-------------+ +---------------+
| |<-(1)--- DOTS signal ------>| |
| | channel session 1 | |
| |<=(2)== redirect to B ======| |
| DOTS client | | DOTS server A |
| |X-(4)--- DOTS signal ------X| |
| | channel session 1 | |
| | | |
+-------------+ +---------------+
^
|
(3) DOTS signal channel
| session 2
v
+---------------+
| DOTS server B |
+---------------+
Figure 11: Redirected Signaling
図11：リダイレクトシグナリング
1. Previously established DOTS signal channel session 1 exists between a DOTS client and DOTS server A.
1. 以前に確立されたドット信号チャネルセッション1は、ドットクライアントとドットサーバAとの間に存在する。
2. DOTS server A sends a server signal redirecting the client to DOTS server B.
2. ドットサーバAは、クライアントをドットサーバBにリダイレクトするサーバ信号を送信する。
3. If the DOTS client does not already have a separate DOTS signal channel session with the redirection target, the DOTS client initiates and establishes DOTS signal channel session 2 with DOTS server B.
3. ドットクライアントがリダイレクトターゲットと別のドットシグナルチャネルセッションをまだ持っていない場合、ドットクライアントはドットサーバBを有するドット信号チャネルセッション2を開始し確立する。
4. Having redirected the DOTS client, DOTS server A ceases sending server signals. The DOTS client likewise stops sending client signals to DOTS server A. DOTS signal channel session 1 is terminated.
4. ドットクライアントをリダイレクトしたドットサーバーAはサーバーの信号を送信します。ドットクライアントは、同様に、クライアント信号をドットサーバAに送信する停止する。ドット信号チャネルセッション1は終了する。
DOTS is centered around improving the speed and efficiency of a coordinated response to DDoS attacks. One scenario not yet discussed involves coordination among federated domains operating DOTS servers and mitigators.
ドットは、DDOS攻撃に対する調整された応答の速度と効率を改善することを中心にしています。まだ議論されていないシナリオの1つのシナリオは、連携ドメイン間の調整を伴い、ドットサーバーと障害者を営業しています。
In the course of normal DOTS operations, a DOTS client communicates the need for mitigation to a DOTS server, and that server initiates mitigation on a mitigator with which the server has an established service relationship. The operator of the mitigator may in turn monitor mitigation performance and capacity, as the attack being mitigated may grow in severity beyond the mitigating domain's capabilities.
通常のドット操作の過程で、ドットクライアントはドットサーバーへの緩和の必要性を通信し、サーバーはサーバーが確立されたサービス関係を持つ軽減策で軽減を開始します。緩和されている攻撃が緩和されているドメインの能力を超えて重大度で成長する可能性があるため、軽減者のオペレータは緩和性能と容量を監視する可能性があります。
The operator of the mitigator has limited options in the event a DOTS client-requested mitigation is being overwhelmed by the severity of the attack. Out-of-scope business or SLAs may permit the mitigating domain to drop the mitigation and let attack traffic flow unchecked to the target, but this only encourages attack escalation. In the case where the mitigating domain is the upstream service provider for the attack target, this may mean the mitigating domain and its other services and users continue to suffer the incidental effects of the attack.
Mitigatorのオペレータは、ドットクライアント要求された軽減が攻撃の重大度に圧倒されている場合に限られたオプションがあります。範囲外のビジネスやSLAは、軽減ドメインが軽減を落としてターゲットにチェックされずに攻撃トラフィックフローを攻撃することができますが、これは攻撃の昇格のみを奨励します。緩和ドメインが攻撃対象のアップストリームサービスプロバイダである場合、これは緩和ドメインとその他のサービスが攻撃の付随的な影響を受け続けることを意味します。
A recursive signaling model as shown in Figure 12 offers an alternative. In a variation of the use case "Upstream DDoS Mitigation by an Upstream Internet Transit Provider" described in [DOTS-USE-CASES], a domain operating a DOTS server and mitigator also operates a DOTS client. This DOTS client has an established DOTS session with a DOTS server belonging to a separate administrative domain.
図12に示すような再帰的シグナリングモデルは代替案を提供します。[DotS-Use-Secess]で説明したユースケース「アップストリームDDOS軽減」の変形例では、ドットサーバーと採取プログラムを操作するドメインもドットクライアントを運用します。このDOTSクライアントは、別の管理ドメインに属するドットサーバとの確立されたドットセッションを有する。
With these preconditions in place, the operator of the mitigator being overwhelmed or otherwise performing inadequately may request mitigation for the attack target from this separate DOTS-aware domain. Such a request recurses the originating mitigation request to the secondary DOTS server in the hope of building a cumulative mitigation against the attack.
これらの前提条件が適所に、障害者のオペレータは圧倒されているかそうでなければ不十分であることは、この別々のドット対応ドメインから攻撃対象の緩和を要求することができる。そのような要求は、攻撃に対する累積的な緩和を構築することを期待して、発信緩和要求を二次ドットサーバに再帰的に再帰的に再帰的に再帰的に再帰的に再帰的に再帰的に再帰的に再帰する。
example.net domain
. . . . . . . . . . . . . . . . .
. Gn .
+----+ 1 . +----+ +-----------+ .
| Cc |<--------->| Sn |~~~~~~~| Mitigator | .
+----+ . +====+ | Mn | .
. | Cn | +-----------+ .
example.com . +----+ .
client . ^ .
. . .|. . . . . . . . . . . . . .
|
2 |
|
. . .|. . . . . . . . . . . . . .
. v .
. +----+ +-----------+ .
. | So |~~~~~~~| Mitigator | .
. +----+ | Mo | .
. +-----------+ .
. .
. . . . . . . . . . . . . . . . .
example.org domain
Figure 12: Recursive Signaling
図12：再帰的シグナリング
In Figure 12, client Cc signals a request for mitigation across inter-domain DOTS session 1 to the DOTS server Sn belonging to the example.net domain. DOTS server Sn enables mitigation on mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed logically back to back with DOTS client Cn, which has preexisting inter-domain DOTS session 2 with the DOTS server So belonging to the example.org domain. At any point, DOTS server Sn MAY recurse an ongoing mitigation request through DOTS client Cn to DOTS server So, in the expectation that mitigator Mo will be activated to aid in the defense of the attack target.
図12では、クライアントCCは、ドメイン間ドットセッション1にわたる緩和の要求を、example.netドメインに属するドットサーバSNへのドットサーバSNへの要求を知らせる。DOTSサーバーSNは、MITIGATOR MNでの軽減を可能にします。ドットサーバSNはドットゲートウェイGNの半分であり、ドットクライアントCNで論理的に戻って展開され、ドットサーバが既存のドメイン間ドットセッション2がexample.orgドメインに属している。任意の時点で、ドットサーバSNは、ドットクライアントCNを介してドットクライアントCNを介して継続的な緩和要求を再発することができるので、攻撃対象の防御を支援するために活性化されることが期待される。
Recursive signaling is opaque to the DOTS client. To maximize mitigation visibility to the DOTS client, however, the recursing domain SHOULD provide recursed mitigation feedback in signals reporting on mitigation status to the DOTS client. For example, the recursing domain's DOTS server should incorporate available metrics such as dropped packet or byte counts from the recursed domain's DOTS server into mitigation status messages.
再帰的シグナリングはドットクライアントに不透明です。しかしながら、ドットクライアントへの緩和の可視性を最大化するために、再帰ドメインは、緩和ステータスでの信号報告においてDOTSクライアントへの縮小緩和フィードバックを提供するべきである。たとえば、再帰ドメインのドットサーバーは、再帰ドメインのドットサーバーからのドロップされたパケットまたはバイト数などの利用可能なメトリックを軽減ステータスメッセージに組み込む必要があります。
DOTS clients involved in recursive signaling must be able to withdraw requests for mitigation without warning or justification per SIG-006 in [RFC8612].
再帰的シグナリングに関与するドットクライアントは、[RFC8612]のSIG-006あたりの警告または正当化なしに緩和の要求を引き出すことができなければなりません。
Operators recursing mitigation requests MAY maintain the recursed mitigation for a brief protocol-defined period in the event the DOTS client originating the mitigation withdraws its request for help, as per the discussion of managing mitigation toggling in SIG-006 of [RFC8612].
緩和要求を再帰する演算子は、[RFC8612]のSIG-006の軽減の管理の説明に従って、軽減の原因となるドットクライアントがヘルプの要求を引き受ける場合、短いプロトコル定義の期間の再帰軽減を維持することができます。
Deployment of recursive signaling may result in traffic redirection, examination, and mitigation extending beyond the initial bilateral relationship between DOTS client and DOTS server. As such, client control over the network path of mitigated traffic may be reduced. DOTS client operators should be aware of any privacy concerns and work with DOTS server operators employing recursive signaling to ensure shared sensitive material is suitably protected. Typically, there is a contractual SLA negotiated among the DOTS client domain, the recursed domain, and the recursing domain to meet the privacy requirements of the DOTS client domain and authorization for the recursing domain to request mitigation for the resources controlled by the DOTS client domain.
再帰的シグナリングの展開は、トラフィックリダイレクト、検査、および緩和が、ドットクライアントとドットサーバーとの間の初期の両側関係を超えて延長されます。そのため、軽減されたトラフィックのネットワーク経路に対するクライアント制御を減らすことができる。ドットクライアントオペレータは、どのプライバシーの懸念を認識し、再帰的なシグナリングを使用して、共有機密材料を適切に保護するために再帰的シグナリングを採用しているドットサーバー演算子を操作する必要があります。通常、ドットクライアントドメインのプライバシー要件を満たすドットクライアントドメイン、再帰ドメインと再帰ドメインの間にネゴシエートされた契約上のSLAがあり、DOTSクライアントドメインによって制御されるリソースの軽減を要求する。
The DOTS architecture does not assume the availability of anycast within a DOTS deployment, but neither does the architecture exclude it. Domains operating DOTS servers MAY deploy DOTS servers with an anycast Service Address as described in BCP 126 [RFC4786]. In such a deployment, DOTS clients connecting to the DOTS Service Address may be communicating with distinct DOTS servers, depending on the network configuration at the time the DOTS clients connect. Among other benefits, anycast signaling potentially offers the following:
ドットアーキテクチャは、ドット展開内のエネルギーの可用性を想定していませんが、アーキテクチャはそれを除外していません。ドメイン操作ドットサーバーは、BCP 126 [RFC4786]で説明されているように、Anycastサービスアドレスを持つドットサーバーを展開することがあります。そのような展開では、ドットサービスアドレスに接続するドットクライアントは、ドットクライアントが接続するときのネットワーク構成に応じて、異なるドットサーバと通信することができる。他の利点の中で、エニーキャストシグナリングは潜在的に次のことを提供します。
* Simplified DOTS client configuration, including service discovery through the methods described in [RFC7094]. In this scenario, the "instance discovery" message would be a DOTS client initiating a DOTS session to the DOTS server anycast Service Address, to which the DOTS server would reply with a redirection to the DOTS server unicast address the client should use for DOTS.
* [RFC7094]に記載されている方法によるサービス発見を含む簡易ドットクライアント構成。このシナリオでは、「インスタンスディスカバリ」メッセージは、ドットサーバがドットサーバにリダイレクトを返信し、ドットサーバがドットに使用すべきドットサーバへのドットセッションを開始するドットクライアントになることになる。
* Region- or customer-specific deployments, in which the DOTS Service Addresses route to distinct DOTS servers depending on the client region or the customer network in which a DOTS client resides.
* ドットサービスが、ドットクライアントが存在するクライアント領域または顧客ネットワークに応じて、ドットサービスが異なるドットサーバへのルートをアドレス指定する領域または顧客固有の展開。
* Operational resiliency, spreading DOTS signaling traffic across the DOTS server domain's networks, and thereby also reducing the potential attack surface, as described in BCP 126 [RFC4786].
* オペレーションの回復力、ドットサーバードメインのネットワーク全体でトラフィックをシグナリングし、それによってBCP 126 [RFC4786]に記載されているように、潜在的な攻撃面を減らす。
As long as network configuration remains stable, anycast DOTS signaling is to the individual DOTS client indistinct from direct signaling. However, the operational challenges inherent in anycast signaling are anything but negligible, and DOTS server operators must carefully weigh the risks against the benefits before deploying.
ネットワーク構成が安定している限り、エニーキャストドットシグナリングは個々のドットクライアントに直接シグナリングと不明瞭になります。ただし、エニーキャストシグナリングに固有の運用上の課題はごくわずかであり、ドットサーバーの事業者は展開前に利点に対してリスクを慎重に計算する必要があります。
While the DOTS signal channel primarily operates over UDP per SIG-001 in [RFC8612], the signal channel also requires mutual authentication between DOTS agents, with associated security state on both ends.
DOTS信号チャネルは、[RFC8612]では主にSIG-001あたりUDPを介して動作しますが、信号チャネルはドットエージェント間の相互認証を必要とし、両端に関連するセキュリティ状態を伴う。
Network instability is of particular concern with anycast signaling, as DOTS signal channels are expected to be long lived and potentially operating under congested network conditions caused by a volumetric DDoS attack.
ネットワークの不安定性は、ドット信号チャネルが長く住んでいると予想されるため、エニーキャストシグナリングに特に懸念されています。
For example, a network configuration altering the route to the DOTS server during active anycast signaling may cause the DOTS client to send messages to a DOTS server other than the one with which it initially established a signaling session. That second DOTS server might not have the security state of the existing session, forcing the DOTS client to initialize a new DOTS session. This challenge might in part be mitigated by use of resumption via a pre-shared key (PSK) in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS-PROTOCOL] (session resumption in TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must then be available to all DOTS servers sharing the anycast Service Address, which has operational challenges of its own.
例えば、Active Anycastシグナリング中にドットサーバへのルートを変更するネットワーク構成は、ドットクライアントが最初にシグナリングセッションを確立したもの以外のドットサーバにメッセージを送信することがある。その第2のドットサーバは既存のセッションのセキュリティ状態を持たない可能性があり、ドットクライアントを強制的に新しいドットセッションを初期化するように強制することがある。この課題は、TLS 1.3 [RFC8446]およびDTLS 1.3 [DTLS-Protocol]（TLS 1.2 [RFC5246]およびDTLS 1.2 [RFC6347]のセッション再開）での事前共有キー（PSK）を介した再開を軽減することができます。ただし、キーイングマテリアルは、Anycastサービスアドレスを共有するすべてのドットサーバーで利用可能でなければなりません。これは、独自の動作上の課題を持っています。
While the DOTS client will try to establish a new DOTS session with the DOTS server now acting as the anycast DOTS Service Address, the link between DOTS client and server may be congested with attack traffic, making signal session establishment difficult. In such a scenario, anycast Service Address instability becomes a sort of signal session flapping, with obvious negative consequences for the DOTS deployment.
ドットクライアントは、Anycastドットサービスアドレスとして行動するDOTSサーバーとの新しいドットセッションを確立しようとしますが、ドットクライアントとサーバー間のリンクは攻撃トラフィックで輻輳している可能性があり、シグナルセッション確立を困難にします。このようなシナリオでは、Anycastサービスアドレスの不安定性は一種のシグナルセッションフラッピングになり、ドット展開には明らかな悪影響があります。
Anycast signaling deployments similarly must also take into account active mitigations. Active mitigations initiated through a DOTS session may involve diverting traffic to a scrubbing center. If the DOTS session flaps due to anycast changes as described above, mitigation may also flap as the DOTS servers sharing the anycast DOTS service address toggles mitigation on detecting DOTS session loss, depending on whether or not the client has configured mitigation on loss of signal (Section 3.3.3).
エニーキャストシグナリング展開も同様にアクティブな軽減を考慮に入れる必要があります。ドットセッションを通じて開始された能動的軽減は、スクラブセンターへのトラフィックをそらすことを含み得る。上述のようにエネルギーが変化したためにドットセッションがフラップしても、クライアントが信号の損失に緩和されたかどうかに応じて、ドットのセッション損失の検出に対するドットサーバとして緩和がフラップされる可能性があります。セクション3.3.3）。
Network address translators (NATs) are expected to be a common feature of DOTS deployments. The middlebox traversal guidelines in [RFC8085] include general NAT considerations that are applicable to DOTS deployments when the signal channel is established over UDP.
ネットワークアドレストランスレータ（NAT）は、ドット展開の一般的な機能であると予想されます。[RFC8085]のミドルボックストラバーサルガイドラインには、信号チャネルがUDP上で確立されたときにドット展開に適用可能な一般的なNATの考慮事項が含まれています。
Additional DOTS-specific considerations arise when NATs are part of the DOTS architecture. For example, DDoS attack detection behind a NAT will detect attacks against internal addresses. A DOTS client subsequently asked to request mitigation for the attacked scope of addresses cannot reasonably perform the task, due to the lack of externally routable addresses in the mitigation scope.
NATSがドットアーキテクチャの一部である場合、追加のドット固有の考慮事項が発生します。たとえば、NATの背後にあるDDOS攻撃検出は内部アドレスに対する攻撃を検出します。緩和範囲内の外部からルーティング可能なアドレスがないため、攻撃された住所の攻撃の範囲に対する緩和を要求するように依頼されたドットクライアントは、その攻撃範囲の範囲の範囲の範囲を要求することはできません。
The following considerations do not cover all possible scenarios but are meant rather to highlight anticipated common issues when signaling through NATs.
次の考慮事項は、すべての可能なシナリオをカバーしていませんが、NATを通じてシグナリングするときに予想される一般的な問題を強調することを意味します。
Operators may circumvent the problem of translating internal addresses or prefixes to externally routable mitigation scopes by directly provisioning the mappings of external addresses to internal protected resources on the DOTS client. When the operator requests mitigation scoped for internal addresses, directly or through automated means, the DOTS client looks up the matching external addresses or prefixes and issues a mitigation request scoped to that externally routable information.
オペレータは、外部アドレスのマッピングをドットクライアント上の内部保護されたリソースに直接プロビジョニングすることによって、内部アドレスまたはプレフィックスを外部からルーティング可能な緩和スコープに変換するという問題を回避することができます。オペレータが内部アドレスを軽減を要求すると、直接または自動化された手段を介して、ドットクライアントは一致する外部アドレスまたはプレフィックスを調べ、その外部からルーティング可能な情報にスコープされた軽減要求を発行します。
When directly provisioning the address mappings, operators must ensure the mappings remain up to date or they risk losing the ability to request accurate mitigation scopes. To that aim, the DOTS client can rely on mechanisms such as [RFC8512] or [RFC7658] to retrieve static explicit mappings. This document does not prescribe the method by which mappings are maintained once they are provisioned on the DOTS client.
アドレスマッピングを直接プロビジョニングするとき、演算子はマッピングが最新のままであることを確認する必要があります。または、正確な緩和スコープを要求する能力を失う危険性があります。その目的のために、ドットクライアントは[RFC8512]または[RFC7658]のようなメカニズムに依存して静的な明示的マッピングを取得することができます。この文書は、ドットクライアント上でプロビジョニングされた後にマッピングが維持される方法を規定していません。
3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol (PCP)
3.2.5.2. ポート制御プロトコル（PCP）による公共軽減範囲の解決
Port Control Protocol (PCP) [RFC6887] may be used to retrieve the external addresses/prefixes and/or port numbers if the NAT function embeds a PCP server.
NAT関数がPCPサーバを埋め込む場合は、ポート制御プロトコル（PCP）[RFC6887]を使用して外部アドレス/プレフィックスおよび/またはポート番号を取得することができます。
A DOTS client can use the information retrieved by means of PCP to feed the DOTS protocol(s) messages that will be sent to a DOTS server. These messages will convey the external addresses/prefixes as set by the NAT.
DOTSクライアントは、PCPによって検索された情報を使用して、ドットサーバに送信されるドットプロトコルメッセージを送ることができる。これらのメッセージは、NATによって設定されている外部アドレス/プレフィックスを伝えます。
PCP also enables discovery and configuration of the lifetime of port mappings instantiated in intermediate NAT devices. Discovery of port mapping lifetimes can reduce the dependency on heartbeat messages to maintain mappings and, therefore, reduce the load on DOTS servers and the network.
PCPはまた、中間NATデバイスでインスタンス化されたポートマッピングの有効期間の検出と構成を可能にします。ポートマッピングのディスカバリの発見は、マッピングを維持するためのハートビートメッセージへの依存関係を減らすことができ、したがって、ドットサーバとネットワークの負荷を減らすことができます。
3.2.5.3. Resolving Public Mitigation Scope with Session Traversal Utilities (STUN)
3.2.5.3. セッショントラバーサルユーティリティ（STUN）による公共軽減範囲の解決
An internal resource, e.g., a web server, can discover its reflexive transport address through a STUN Binding request/response transaction, as described in [RFC8489]. After learning its reflexive transport address from the STUN server, the internal resource can export its reflexive transport address and internal transport address to the DOTS client, thereby enabling the DOTS client to request mitigation with the correct external scope, as depicted in Figure 13. The mechanism for providing the DOTS client with the reflexive transport address and internal transport address is unspecified in this document.
[RFC8489]で説明されているように、内部リソース、例えばWebサーバは、STUNバインディング要求/応答トランザクションを介してその反射転送アドレスを発見することができる。STUNサーバーからの反射的なトランスポートアドレスを学習した後、内部リソースはその反射転送アドレスと内部トランスポートアドレスと内部トランスポートアドレスをドットクライアントにエクスポートし、それによってドットクライアントが図13に示すように、正しい外部スコープと軽減を要求することができます。このドキュメントでは、ドットクライアントを再帰的なトランスポートアドレスと内部トランスポートアドレスに提供するためのメカニズムが指定されていません。
In order to prevent an attacker from modifying the STUN messages in transit, the STUN client and server must use the message-integrity mechanism discussed in Section 9 of [RFC8489] or use STUN over DTLS [RFC7350] or STUN over TLS. If the STUN client is behind a NAT that performs Endpoint-Dependent Mapping [RFC5128], the internal service cannot provide the DOTS client with the reflexive transport address discovered using STUN. The behavior of a NAT between the STUN client and the STUN server could be discovered using the experimental techniques discussed in [RFC5780], but note that there is currently no standardized way for a STUN client to reliably determine if it is behind a NAT that performs Endpoint-Dependent Mapping.
攻撃者がトランジット内のSTUNメッセージを変更するのを防ぐために、STUNクライアントとサーバーは[RFC8489]のセクション9で説明されているメッセージ整合性メカニズムを使用するか、DTLS [RFC7350]またはTLS上でSTUNを使用してください。STUNクライアントがエンドポイント依存マッピング[RFC5128]を実行するNATの背後にある場合、内部サービスはDOTSクライアントにSTUNを使用して検出された再帰転送アドレスを提供することはできません。STUNクライアントとSTUNサーバーの間のNATの動作は、[RFC5780]で説明した実験的な手法を使用して発見されますが、STUNクライアントが実行するNATの背後にあるかどうかを確実に判断するための標準化された方法は現在ありません。エンドポイント依存マッピング
Binding Binding
+--------+ request +---+ request +--------+
| STUN |<----------| N |<----------| STUN |
| server | | A | | client |
| |---------->| T |---------->| |
+--------+ Binding +---+ Binding +--------+
response response |
| reflexive transport address
| & internal transport address
v
+--------+
| DOTS |
| client |
+--------+
Figure 13: Resolving Mitigation Scope with STUN
図13：スティンによる軽減範囲の解決
DOTS supports mitigation scoped to DNS names. As discussed in [RFC3235], using DNS names instead of IP addresses potentially avoids the address translation problem, as long as the same domain name is internally and externally resolvable. For example, a detected attack's internal target address can be mapped to a DNS name through a reverse lookup. The DNS name returned by the reverse lookup can then be provided to the DOTS client as the external scope for mitigation. For the reverse DNS lookup, DNS Security Extensions (DNSSEC) [RFC4033] must be used where the authenticity of response is critical.
ドットはDNS名にスコープされた軽減をサポートしています。[RFC3235]で説明したように、IPアドレスの代わりにDNS名を使用すると、同じドメイン名が内部および外部から解決可能なものである限り、アドレス変換の問題を回避できます。たとえば、検出された攻撃の内部ターゲットアドレスを逆方向ルックアップを介してDNS名にマッピングできます。逆引き合わせによって返されるDNS名は、緩和のための外部範囲としてドットクライアントに提供され得る。Reverse DNS Lookupの場合、応答の信頼性が重要な場合は、DNSセキュリティ拡張（DNSSEC）[RFC4033]を使用する必要があります。
[RFC8612] places no limitation on the circumstances in which a DOTS client operator may request mitigation, nor does it demand justification for any mitigation request, thereby reserving operational control over DDoS defense for the domain requesting mitigation. This architecture likewise does not prescribe the network conditions and mechanisms triggering a mitigation request from a DOTS client.
[RFC8612]ドットクライアントオペレータが緩和を要求したり、緩和依頼を要求することも、緩和のためにDDOSの防衛を求めることも、DOTSクライアント事業者が緩和依頼を推進したりすることも、制限を制限したりしません。このアーキテクチャも同様に、ドットクライアントからの緩和要求を引き起こすネットワーク条件およびメカニズムを処方するものではない。
However, considering selected possible mitigation triggers from an architectural perspective offers a model for alternative or unanticipated triggers for DOTS deployments. In all cases, what network conditions merit a mitigation request are at the discretion of the DOTS client operator.
しかしながら、アーキテクチャの観点から選択された可能な緩和トリガーを考慮することは、ドット展開のための代替または予期せぬトリガーのためのモデルを提供する。すべての場合において、どのネットワーク条件が緩和要求に値するのは、ドットクライアントオペレータの裁量にあります。
The mitigation request itself is defined by DOTS; however, the interfaces required to trigger the mitigation request in the following scenarios are implementation specific.
緩和要求自体はドットによって定義されます。ただし、次のシナリオで緩和要求をトリガするのに必要なインタフェースは実装固有です。
A DOTS client operator may manually prepare a request for mitigation, including scope and duration, and manually instruct the DOTS client to send the mitigation request to the DOTS server. In context, a manual request is a request directly issued by the operator without automated decision making performed by a device interacting with the DOTS client. Modes of manual mitigation requests include an operator entering a command into a text interface, or directly interacting with a graphical interface to send the request.
ドットクライアントオペレータは、範囲および期間を含む緩和の要求を手動で準備し、ドットクライアントにドットサーバに緩和要求を送信するように手動で指示することができる。コンテキストでは、マニュアル要求は、ドットクライアントと対話するデバイスによって実行される自動決定を行うことなく、オペレータによって直接発行された要求です。手動緩和要求のモードには、テキストインタフェースにコマンドを入力する、またはリクエストを送信するためのグラフィカルインタフェースと直接対話することが含まれます。
An operator might do this, for example, in response to notice of an attack delivered by attack detection equipment or software, and the alerting detector lacks interfaces or is not configured to use available interfaces to translate the alert to a mitigation request automatically.
オペレータは、例えば、攻撃検出装置またはソフトウェアによって提供される攻撃の通知に応答して行うことができ、警告検出器はインターフェースを欠いているか、または警告を自動的に緩和要求に変換するために利用可能なインターフェースを使用するように構成されていない。
In a variation of the above scenario, the operator may have preconfigured on the DOTS client mitigation requests for various resources in the operator's domain. When notified of an attack, the DOTS client operator manually instructs the DOTS client to send the relevant preconfigured mitigation request for the resources under attack.
上記のシナリオの変形では、オペレータは、オペレータのドメイン内の様々なリソースに対するドットクライアント緩和要求に対して事前設定されていてもよい。攻撃に通知されたとき、ドットクライアントオペレータは、攻撃下のリソースに対する関連する事前設定された軽減要求を送信するようにドットクライアントに手動で指示します。
A further variant involves recursive signaling, as described in Section 3.2.3. The DOTS client in this case is the second half of a DOTS gateway (back-to-back DOTS server and client). As in the previous scenario, the scope and duration of the mitigation request are preexisting but, in this case, are derived from the mitigation request received from a downstream DOTS client by the DOTS server. Assuming the preconditions required by Section 3.2.3 are in place, the DOTS gateway operator may at any time manually request mitigation from an upstream DOTS server, sending a mitigation request derived from the downstream DOTS client's request.
3.2.3節で説明されているように、さらなる変形例は再帰的シグナリングを含む。この場合のドットクライアントは、ドットゲートウェイの後半（バックツーバックドットサーバーとクライアント）です。以前のシナリオと同様に、緩和要求の範囲および期間は既存のものであるが、この場合、ドットサーバによってダウンストリームドットクライアントから受信された緩和要求から導出される。セクション3.2.3によって必要な前提条件が整っていると仮定すると、ドットゲートウェイ事業者はいつでもアップストリームドットサーバから緩和を手動で要求し、下流のドットクライアントの要求から派生した緩和要求を送信することができる。
The motivations for a DOTS client operator to request mitigation manually are not prescribed by this architecture but are expected to include some of the following:
緩和を手動で要求するためのドットクライアントオペレータの動機は、このアーキテクチャによって規定されていないが、以下のいくつかを含むと予想される。
* Notice of an attack delivered via email or alternative messaging
* 電子メールまたは代替メッセージングを介して配信された攻撃のお知らせ
* Notice of an attack delivered via phone call
* 電話で配信された攻撃のお知らせ
* Notice of an attack delivered through the interface(s) of networking monitoring software deployed in the operator's domain
* オペレータのドメインに展開されているネットワーキング監視ソフトウェアのインタフェースを通じて配信された攻撃のお知らせ
* Manual monitoring of network behavior through network monitoring software
* ネットワーク監視ソフトウェアによるネットワーク動作の手動モニタリング
Unlike manual mitigation requests, which depend entirely on the DOTS client operator's capacity to react with speed and accuracy to every detected or detectable attack, mitigation requests triggered by detected attack conditions reduce the operational burden on the DOTS client operator and minimize the latency between attack detection and the start of mitigation.
検出された攻撃または検出可能な攻撃に応じたドットクライアント演算子の容量に完全に依存する手動緩和要求とは異なり、検出された攻撃条件によって引き起こされる緩和要求は、ドットクライアントオペレータの運用上の負担を軽減し、攻撃検出の間の待ち時間を最小限に抑えます。そして緩和の開始。
Mitigation requests are triggered in this scenario by operator-specified network conditions. Attack detection is deployment specific and not constrained by this architecture. Similarly, the specifics of a condition are left to the discretion of the operator, though common conditions meriting mitigation include the following:
このシナリオでは、演算子指定のネットワーク条件によって緩和要求が発生します。攻撃検出は、このアーキテクチャによって展開されていて制約されていません。同様に、条件の詳細はオペレータの裁量に任されていますが、軽減率には次のものがあります。
* Detected attack exceeding a rate in packets per second (pps).
* 検出された攻撃は、毎秒/秒（PPS）の割合を超えています。
* Detected attack exceeding a rate in bytes per second (bps).
* 検出された攻撃が1秒あたりのバイト数（BPS）を超える。
* Detected resource exhaustion in an attack target.
* 攻撃対象のリソースの枯渇を検出しました。
* Detected resource exhaustion in the local domain's mitigator.
* ローカルドメインの採用者でリソースの枯渇を検出しました。
* Number of open connections to an attack target.
* 攻撃対象への開いた接続数。
* Number of attack sources in a given attack.
* 与えられた攻撃における攻撃源の数。
* Number of active attacks against targets in the operator's domain.
* オペレータのドメイン内のターゲットに対するアクティブな攻撃の数。
* Conditional detection developed through arbitrary statistical analysis or deep learning techniques.
* 条件付き検出は任意の統計分析または深部学習技術を通して開発された。
* Any combination of the above.
* 上記の任意の組み合わせ。
When automated conditional mitigation requests are enabled, violations of any of the above conditions, or any additional operator-defined conditions, will trigger a mitigation request from the DOTS client to the DOTS server. The interfaces between the application detecting the condition violation and the DOTS client are implementation specific.
自動化された条件付き緩和要求が有効になっている場合、上記の条件のいずれか、または追加のオペレータ定義の条件の違反は、ドットクライアントからドットサーバーへの緩和要求を引き起こします。条件違反とドットクライアントを検出するアプリケーション間のインターフェイスは実装固有です。
To maintain a DOTS signal channel session, the DOTS client and the DOTS server exchange regular but infrequent messages across the signal channel. In the absence of an attack, the probability of message loss in the signaling channel should be extremely low. Under attack conditions, however, some signal loss may be anticipated as attack traffic congests the link, depending on the attack type.
ドット信号チャネルセッション、ドットクライアントおよびドットサーバを定期的に交換することは、信号チャネル全体で正常にメッセージを交換するために。攻撃がない場合、シグナリングチャネル内のメッセージ損失の確率は極めて低くなければなりません。しかし、攻撃の種類によっては、攻撃トラフィックがリンクを輻輳するため、一部の信号損失が予想される場合があります。
While [RFC8612] specifies the DOTS protocol be robust when signaling under attack conditions, there are nevertheless scenarios in which the DOTS signal is lost in spite of protocol best efforts. To handle such scenarios, a DOTS operator may request one or more mitigations, which are triggered only when the DOTS server ceases receiving DOTS client heartbeats beyond the miss count or interval permitted by the protocol.
[RFC8612] [RFC8612]は、攻撃条件下でシグナリングするときにドットプロトコルを堅牢に指定しますが、それでも、プロトコルの最良の取り組みにもかかわらず、ドット信号が失われるシナリオがあります。そのようなシナリオを処理するために、ドット演算子は1つ以上の緩和を要求することができ、それはドットサーバがプロトコルによって許可されたミスカウントまたは間隔を超えてドットクライアントハートビートを受け取るときにのみトリガされる。
The impact of mitigating due to loss of signal in either direction must be considered carefully before enabling it. Attack traffic congesting links is not the only reason why signal could be lost, and as such, mitigation requests triggered by signal channel degradation in either direction may incur unnecessary costs due to scrubbing traffic, adversely impact network performance and operational expense alike.
どちらの方向の信号の損失による軽減の影響は、それを可能にする前に慎重に考慮されなければなりません。攻撃トラフィック輻輳リンクは、信号が失われる可能性があるのは唯一の理由ではありません。どちらの方向のシグナルチャネルの劣化によって引き起こされる緩和要求は、トラフィックをスクラブすることによって不要なコストが発生し、ネットワーク性能と運用費用に悪影響を及ぼす可能性があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This section describes identified security considerations for the DOTS architecture.
このセクションでは、DOTSアーキテクチャについての識別されたセキュリティ上の考慮事項について説明します。
Security considerations and security requirements discussed in [RFC8612] need to be taken into account.
[RFC8612]で説明したセキュリティ上の考慮事項とセキュリティ要件を考慮に入れる必要があります。
DOTS is at risk from three primary attack vectors: agent impersonation, traffic injection, and signal blocking. These vectors may be exploited individually or in concert by an attacker to confuse, disable, take information from, or otherwise inhibit DOTS agents.
ドットは3つの主要な攻撃ベクトルから危険にさらされています。エージェントの偽装、トラフィック注入、およびシグナルブロック。これらのベクトルは、攻撃者によって個別にまたはコンサートされて、ドットエージェントを混乱させ、無効化、情報を取り込む、またはその他の方法で阻害することができます。
Any attacker with the ability to impersonate a legitimate DOTS client or server or, indeed, inject false messages into the stream may potentially trigger/withdraw traffic redirection, trigger/cancel mitigation activities or subvert drop-/accept-lists. From an architectural standpoint, operators MUST ensure conformance to the security requirements defined in Section 2.4 of [RFC8612] to secure data in transit. Similarly, as the received data may contain network topology, telemetry, and threat and mitigation information that could be considered sensitive in certain environments, it SHOULD be protected at rest per required local policy.
正当なドットクライアントまたはサーバーを偽装する機能を持つ任意の攻撃者、または実際には、誤ったメッセージをストリームに挿入すると、トラフィックリダイレクト、トリガー/キャンセルまたは削除ドロップ/承認リストを削除する可能性があります。アーキテクチャ上の観点から、演算子は[RFC8612]のセクション2.4で定義されているセキュリティ要件に適合して、輸送中のデータを保護する必要があります。同様に、受信したデータには、特定の環境で敏感に見える可能性があるネットワークトポロジ、テレメトリ、および脅威情報、および軽減情報が含まれている場合があります。必要なローカルポリシーごとに安静時に保護されるべきです。
DOTS agents MUST perform mutual authentication to ensure authenticity of each other, and DOTS servers MUST verify that the requesting DOTS client is authorized to request mitigation for specific target resources (see Section 2.2.2).
ドットエージェントは、信頼性を確保するために相互認証を実行しなければならず、ドットサーバは、要求側のドットクライアントが特定のターゲットリソースに対する緩和を要求することを許可されていることを確認する必要がある（セクション2.2.2を参照）。
A man-in-the-middle (MITM) attacker can intercept and drop packets, preventing the DOTS peers from receiving some or all of the DOTS messages; automated mitigation on loss of signal can be used as a countermeasure but with risks discussed in Section 3.3.3.
中間中（MITM）の攻撃者はパケットを傍受したり落としたり、ドットのピアがドットメッセージの一部または全部を受け取るのを防ぎます。信号の損失に対する自動化された緩和は対策として使用することができますが、3.3.3節で議論されているリスクがあります。
An attacker with control of a DOTS client may negatively influence network traffic by requesting and withdrawing requests for mitigation for particular prefixes, leading to route or DNS flapping. DOTS operators should carefully monitor and audit DOTS clients to detect misbehavior and deter misuse.
ドットクライアントを制御する攻撃者は、特定のプレフィックスに対する緩和の要求を要求および撤回することによってネットワークトラフィックに悪影響を及ぼし、ルートまたはDNSフラッピングをもたらす。ドットオペレータは、誤って誤用と誤用を検出するためにドットクライアントを慎重に監視および監査する必要があります。
Any attack targeting the availability of DOTS servers may disrupt the ability of the system to receive and process DOTS signals resulting in failure to fulfill a mitigation request. DOTS servers MUST be given adequate protections in accordance with best current practices for network and host security.
ドットサーバの可用性をターゲットとする任意の攻撃は、緩和要求を満たすことに失敗したドット信号を受信し処理する能力を妨害する可能性がある。ドットサーバーは、ネットワークとホストのセキュリティのための最良の現在の慣行に従って適切な保護を与えられなければなりません。
[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>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4786]能力、J.およびK.Lindqvist、「Anycast Servicesの操作」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<https：//www.rfc-editor.org/info/rfc4786>。
[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>。
[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>。
[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>。
[DOTS-USE-CASES] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Work in Progress, Internet-Draft, draft-ietf-dots-use-cases-25, 5 July 2020, <https://tools.ietf.org/html/draft-ietf-dots-use-cases-25>.
[ドットユースケース]ドビンズ、R.、Migault、D.、Moskowitz、R.、Teague、N.、Xia、L.、K。西塚、「DDOSオープン脅威シグナル伝達のためのユースケース」、進行中の作業、インターネットドラフト、ドラフト - IETF - DOTS-expe-ecase-25,25,57月5日、<https：//tools.ietf.org/html/draft-ietf-dots-use-cases-25>。
[DTLS-PROTOCOL] 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-38, 29 May 2020, <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.
[DTLS-Protocol] Rescorla、E.、TSchofenig、H.、およびN. ModAdugu、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-DTLS13-2020年5月38日、<https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：//www.rfc-editor.org/info/rfc2782>。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, DOI 10.17487/RFC3235, January 2002, <https://www.rfc-editor.org/info/rfc3235>.
[RFC3235] Senie、D.、「ネットワークアドレス翻訳者（NAT） - Friendly Application Design Guidelines」、RFC 3235、DOI 10.17487 / RFC3235、2002年1月、<https：//www.rfc-editor.org/info/rfc3235>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[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>。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <https://www.rfc-editor.org/info/rfc5128>.
[RFC5128] SRISURESH、P.、FORD、B.およびD.Kegel、「ネットワークアドレス翻訳者全体のピアツーピア（P2P）通信（NATS）」、RFC 5128、DOI 10.17487 / RFC5128、2008年3月<https://www.rfc-editor.org/info/rfc5128>。
[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>。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>.
[RFC5780] MacDonald、D.およびB. Lowekamp、「NAT（STUN）のセッショントラバーサルユーティリティを使用したNAT行動発見」、RFC 5780、DOI 10.17487 / RFC5780、<https：//ww.rfc-editor.org/ info / rfc5780>。
[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>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S.およびM. Krochmal、「DNSベースのサービス発見」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https：//www.rfc-editor.org/info/rfc6763>。
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <https://www.rfc-editor.org/info/rfc7092>.
[RFC7092] Kaplan、H.およびV. Pascual、「セッション開始プロトコルの分類（SIP）バックツーバックユーザーエージェントの分類法、RFC 7092、DOI 10.17487 / RFC7092、2013年12月、<https：//www.rfc-editor.org/info/rfc7092>。
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.
[RFC7094] McPherson、D.、Oran、D.、Thaler、D.、およびE.osterweil、「IP Anercastのアーキテクチャ上の考慮事項」、RFC 7094、DOI 10.17487 / RFC7094、2014年1月、<https：//www.rfc-editor.org/info/rfc7094>。
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[RFC7350] Petit-Huguenin、M.およびG.Salgueiro、「データグラムトランスポート層セキュリティ（DTLS）、「STUN（STUN）」、RFC 7350、DOI 10.17487 / RFC7350、2014年8月、<https：//www.rfc-editor.org/info/rfc7350>。
[RFC7658] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, "Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs)", RFC 7658, DOI 10.17487/RFC7658, October 2015, <https://www.rfc-editor.org/info/rfc7658>.
[RFC7658] PerreAll、S.、Tsou、T.、Sivakumar、S.、およびT.Taylor、「MIBモジュールの廃止：ネットワークアドレス翻訳者用管理対象オブジェクト（NATS）」、RFC 7658 / RFC76582015年10月、<https://www.rfc-editor.org/info/rfc7658>。
[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>。
[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>。
[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>。
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8512>.
[RFC8512] Boucadair、M.、Ed。、Sivakumar、S、Jacquenet、C、Vinapamula、S.、およびQ. WU、「ネットワークアドレス変換用Yangモジュール」（NAT）およびネットワークプレフィックス翻訳（NPT） "、RFC 8512、DOI 10.17487 / RFC8512、2019年1月、<https：//www.rfc-editor.org/info/rfc8512>。
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D.、およびJ.Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：//www.rfc-editor.org/info/rfc8555>。
[RFC8738] Shoemaker, R.B., "Automated Certificate Management Environment (ACME) IP Identifier Validation Extension", RFC 8738, DOI 10.17487/RFC8738, February 2020, <https://www.rfc-editor.org/info/rfc8738>.
[RFC8738] ShoeMaker、R.B.、「自動証明書管理環境（ACME）IP識別子検証拡張」、RFC 8738、DOI 10.17487 / RFC8738、2020年2月、<https：//www.rfc-editor.org/info/rfc8738>。
[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>。
[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>。
Acknowledgments
謝辞
Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow, Paul Kyzivat, Warren Kumari, Benjamin Kaduk, and Mohamed Boucadair for their comments and suggestions.
Matt Richardson、Roman Danyliw、Frank Xialiang、Roland Dobbins、Wei Pan、Kaname Nishizuka、Jon Shallow、Paul Kyzivat、Warren Kumari、Benjamin Kaduk、そしてMohamed Boucadairのコメントや提案のために、Mohamed Boucadair。
Special thanks to Roman Danyliw for the AD review.
広告レビューのためのローマのDanyliwに感謝します。
Contributors
貢献者
Mohamed Boucadair Orange mohamed.boucadair@orange.com
Mohamed Boucadair Orange Mohamed.boucadair@orange.com
Cristopher Gray Christopher_Gray3@cable.comcast.com
クリストファーグレークリストファーグレー3@cable.comcast.com
Authors' Addresses
著者の住所
Andrew Mortensen (editor) Forcepoint United States of America
Andrew Mortensen（編集）フォースポイントアメリカ
Email: andrewmortensen@gmail.com
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
Flemming Andreasen Cisco United States of America
フレームミングアンドリーゼンシスコアメリカ合衆国
Email: fandreas@cisco.com
Nik Teague Iron Mountain United States of America
Nik Teague Iron Mountainアメリカ合衆国
Email: nteague@ironmountain.co.uk
Rich Compton Charter
リッチコンプトンチャーター
Email: Rich.Compton@charter.com