[要約] RFC 8903は、DDoS Open Threat Signaling (DOTS)の使用例について説明しています。この文書の目的は、DDoS攻撃の脅威に対処するためにDOTSがどのように利用されるかを示すことです。利用場面には、攻撃の検出時に自動的に防御メカニズムをトリガーするシナリオが含まれます。関連するRFCにはRFC 8782（DOTSシグナリングの要件）などがあります。
From: draft-ietf-dots-use-cases-25 InformationalInternet Engineering Task Force (IETF) R. Dobbins
Request for Comments: 8903 Netscout, Inc.
Category: Informational D. Migault
ISSN: 2070-1721 Ericsson
R. Moskowitz
HTT Consulting
N. Teague
Iron Mountain Data Centers
L. Xia
Huawei
K. Nishizuka
NTT Communications
May 2021
Use Cases for DDoS Open Threat Signaling
DDOSオープン脅威シグナリングの使用例
Abstract
概要
The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS Mitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.
DDOSオープン脅威シグナリング（DOTS）の努力は、異種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/rfc8903.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc8903で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology and Acronyms
3. Use Cases
3.1. Upstream DDoS Mitigation by an Upstream Internet Transit
Provider
3.2. DDoS Mitigation by a Third-Party DDoS Mitigation Service
Provider
3.3. DDoS Orchestration
4. Security Considerations
5. IANA Considerations
6. Informative References
Acknowledgments
Authors' Addresses
At the time of writing, distributed denial-of-service (DDoS) attack mitigation solutions are largely based upon siloed, proprietary communications schemes with vendor lock-in as a side effect. This can result in the configuration, provisioning, operation, and activation of these solutions being a highly manual and often time-consuming process. Additionally, coordinating multiple DDoS Mitigation solutions simultaneously is fraught with both technical and process-related hurdles. This greatly increases operational complexity, which in turn can degrade the efficacy of mitigations that are generally highly dependent on a timely reaction by the system.
執筆時点で、分散サービス拒否（DDOS）攻撃軽減ソリューションは、副作用としてベンダーロックインを備えたシロイド独自の通信方式に大きく基づいています。これにより、これらの解決策の構成、プロビジョニング、操作、およびアクティベーションが非常に手動で、しばしば時間がかかるプロセスになる可能性があります。さらに、複数のDDOの軽減ソリューションを同時に調整することは、技術的およびプロセス関連のハードルの両方で助けられます。これは動作複雑さを大幅に増大させ、それは順番にシステムによるタイムリーな反応に一般的に高度に依存する軽減の有効性を低下させる可能性がある。
The DDoS Open Threat Signaling (DOTS) effort is intended to specify protocols that facilitate interoperability between diverse DDoS Mitigation solutions and ensure greater integration in terms of attack detection, mitigation requests, and attack characterization patterns.
DDOSオープン脅威シグナリング（ドット）の取り組みは、多様なDDOの緩和ソリューション間の相互運用性を促進し、攻撃検出、緩和要求、および攻撃の特性評価パターンに関してより大きな統合を確実にするプロトコルを指定することを目的としています。
As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differing DDoS solutions, such as detecting DDoS attacks, initiating/ terminating DDoS Mitigation assistance, or requesting the status of a DDoS Mitigation.
DDOSソリューションがベンダーの間で広く異種のものであるため、ドットの主な目標は、DDOS攻撃の検出、DDOの軽減の開始、DDOの軽減の開始、またはDDOの軽減の状況を要求するなど、さまざまなDDOSソリューションの間で高レベルの相互作用を提供することです。
This document provides sample use cases that provided input for the requirements [RFC8612] and design of the DOTS protocols [RFC8782][RFC8783]. The use cases are not exhaustive, and future use cases are expected to emerge as DOTS is adopted and evolves.
この資料は、要件の入力（RFC8612]とドットプロトコルの設計[RFC8782] [RFC8783]を提供するサンプルユースケースを提供しています。ユースケースは網羅的なものではなく、ドットが採用され、進化するにつれて、将来の使用症例は出現すると予想されます。
This document makes use of the same terminology and definitions as [RFC8612]. In addition, it uses the terms defined below:
この文書は[RFC8612]と同じ用語と定義を利用しています。さらに、以下に定義されている用語を使用します。
DDoS Mitigation System (DMS): A system that performs DDoS Mitigation. The DDoS Mitigation System may be composed of a cluster of hardware and/or software resources but could also involve an orchestrator that may make decisions, such as outsourcing some or all of the mitigation to another DDoS Mitigation System.
DDOS軽減システム（DMS）：DDOS緩和を実行するシステム。DDOS緩和システムは、ハードウェアおよび/またはソフトウェアリソースのクラスタから構成されてもよいが、別のDDOS軽減システムへのいくつかまたは全部をアウトソーシングするなどの決定を下すことができるオーケストレータを含み得る。
DDoS Mitigation: The action performed by the DDoS Mitigation System.
DDOSの軽減：DDOS軽減システムによって実行されたアクション。
DDoS Mitigation Service: Designates a service provided to a customer to mitigate DDoS attacks. Each service subscription usually involve Service Level Agreement (SLA) that has to be met. It is the responsibility of the DDoS Service provider to instantiate the DDoS Mitigation System to meet these SLAs.
DDOSの軽減サービス：DDOS攻撃を軽減するために顧客に提供されるサービスを指定します。各サービスサブスクリプションは通常、満たされなければならないサービスレベル契約（SLA）を含みます。これらのSLAを満たすためにDDOSの軽減システムをインスタンス化するのはDDOSサービスプロバイダの責任です。
DDoS Mitigation Service Provider: Designates the administrative entity providing the DDoS Mitigation Service.
DDOS軽減サービスプロバイダ：DDOS軽減サービスを提供する管理エンティティを指定します。
Internet Transit Provider (ITP): Designates the entity that delivers the traffic to a customer network. It can be an Internet Service Provider (ISP) or an upstream entity delivering the traffic to the ISP.
インターネットトランジットプロバイダー（ITP）：トラフィックをカスタマーネットワークに配信するエンティティを指定します。ISPへのトラフィックを提供するインターネットサービスプロバイダ（ISP）または上流のエンティティです。
This use case describes how an enterprise or a residential customer network may take advantage of a pre-existing relation with its ITP in order to mitigate a DDoS attack targeting its network.
このユースケースは、ネットワークを対象としたDDOS攻撃を軽減するために、企業または住宅顧客ネットワークがITPとの既存の関係を利用することができる方法を説明しています。
For clarity of discussion, the targeted network is indicated as an enterprise network, but the same scenario applies to any downstream network, including residential and cloud hosting networks.
議論を明確にするために、ターゲットネットワークはエンタープライズネットワークとして示されていますが、同じシナリオは、住宅用およびクラウドホスティングネットワークを含む任意のダウンストリームネットワークに適用されます。
As the ITP provides connectivity to the enterprise network, it is already on the path of the inbound and outbound traffic of the enterprise network and is well aware of the networking parameters associated with the enterprise network WAN connectivity. This eases both the configuration and the instantiation of a DDoS Mitigation Service.
ITPはエンタープライズネットワークへの接続を提供するため、すでにエンタープライズネットワークの着信トラフィックのパスにあり、エンタープライズネットワークWAN接続に関連するネットワーキングパラメータをよく認識しています。これにより、DDOS緩和サービスの構成とインスタンス化の両方が簡単になります。
This section considers two kinds of DDoS Mitigation Service between an enterprise network and an ITP:
このセクションでは、エンタープライズネットワークとITPの間で2種類のDDOS軽減サービスを検討します。
* The upstream ITP may instantiate a DMS upon receiving a request from the enterprise network. This typically corresponds to a case when the enterprise network is under attack.
* アップストリームITPは、エンタープライズネットワークからの要求を受信したときにDMSをインスタンス化できます。これは通常、エンタープライズネットワークが攻撃中の場合に対応しています。
* On the other hand, the ITP may identify an enterprise network as the source of an attack and send a mitigation request to the enterprise DMS to mitigate this at the source.
* 一方、ITPは企業ネットワークを攻撃の原因として識別し、ソースでこれを軽減するために企業DMSに軽減要求を送信することができます。
The two scenarios, though different, have similar interactions between the DOTS client and server. For the sake of simplicity, only the first scenario will be detailed in this section. Nevertheless, the second scenario is also in scope for DOTS.
2つのシナリオは異なるが、ドットクライアントとサーバ間の同様の対話を有する。簡単にするために、最初のシナリオのみがこのセクションで詳述されています。それにもかかわらず、2番目のシナリオもドットの範囲内である。
In the first scenario, as depicted in Figure 1, an enterprise network with self-hosted Internet-facing properties such as web servers, authoritative DNS servers, and Voice over IP (VoIP) servers has a DMS deployed to protect those servers and applications from DDoS attacks. In addition to on-premise DDoS defense capabilities, the enterprise has contracted with its ITP for DDoS Mitigation Services when attacks threaten to overwhelm the bandwidth of their WAN link(s).
最初のシナリオでは、図1に示すように、Webサーバー、権限のあるDNSサーバー、およびVoice Over IP（VoIP）サーバーなどの自己ホスト型インターネット向けプロパティを持つエンタープライズネットワークには、それらのサーバーとアプリケーションを保護するためのDMSがあります。DDOS攻撃オンプレミスのDDOSディフェンス機能に加えて、企業は彼らのWANリンクの帯域幅を圧倒することを脅かしているとき、企業はDDOSの軽減サービスのITPと契約しました。
+------------------+ +------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| | | Provider |
| +--------+ | | DDoS Attack
| | DDoS | | <=================================
| | Target | | <=================================
| +--------+ | | +------------+ |
| | +-------->| DDoS | |
| | | |S | Mitigation | |
| | | | | System | |
| | | | +------------+ |
| | | | |
| | | | |
| | | | |
| +------------+ | | | |
| | DDoS |<---+ | |
| | Mitigation |C | | |
| | System | | | |
| +------------+ | | |
+------------------+ +------------------+
* C is for DOTS client functionality * S is for DOTS server functionality
* Cはドットクライアント機能のためのものです* Sはドットサーバー機能のためのものです
Figure 1: Upstream Internet Transit Provider DDoS Mitigation
図1：アップストリームインターネットトランジットプロバイダDDOS軽減
The enterprise DMS is configured such that if the incoming Internet traffic volume exceeds 50% of the provisioned upstream Internet WAN link capacity, the DMS will request DDoS Mitigation assistance from the upstream transit provider. More sophisticated detection means may be considered as well.
エンタープライズDMSは、着信インターネットトラフィックボリュームがプロビジョニングされたアップストリームインターネットWANリンク容量の50％を超えると、DMSはアップストリームトランジットプロバイダからDDOSの軽減援助を要求するように構成されています。より洗練された検出手段も考慮され得る。
The requests to trigger, manage, and finalize a DDoS Mitigation between the enterprise DMS and the ITP are made using DOTS. The enterprise DMS implements a DOTS client while the ITP implements a DOTS server, which is integrated with their DMS in this example.
エンタープライズDMSとITPとの間のDDOの軽減をトリガ、管理、および最終決定する要求は、ドットを使用して行われます。ITPがこの例ではDMSと統合されているドットサーバーを実装している間、エンタープライズDMSはドットクライアントを実装しています。
When the enterprise DMS locally detects an inbound DDoS attack targeting its resources (e.g., servers, hosts, or applications), it immediately begins a DDoS Mitigation.
エンタープライズDMSがリソースをターゲットとしたインバウンドDDOS攻撃（例えば、サーバー、ホスト、またはアプリケーション）をローカルで検出すると、すぐにDDOが軽減を開始します。
During the course of the attack, the inbound traffic volume to the enterprise network exceeds the 50% threshold, and the enterprise DMS escalates the DDoS Mitigation. The enterprise DMS DOTS client signals to the DOTS server on the upstream ITP to initiate DDoS Mitigation. The DOTS server replies to the DOTS client that it can serve this request, and mitigation is initiated on the ITP network by the ITP DMS.
攻撃の過程で、エンタープライズネットワークへのインバウンドトラフィック量が50％のしきい値を超え、Enterprise DMSはDDOの軽減をエスカレートします。DDSの軽減を開始するために、企業DMSはアップストリームITP上のドットサーバーへのクライアント信号をドットします。DOTSサーバーは、この要求に応えることができるドットクライアントに返信し、ITP DMSによってITPネットワーク上で軽減が開始されます。
Over the course of the attack, the DOTS server of the ITP periodically informs the DOTS client on the mitigation status, statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended or decreased to a certain level that the enterprise DMS might handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided.
攻撃の過程で、ITPのドットサーバーは定期的にDOTSクライアントに軽減のステータス、DDOS攻撃トラフィックの軽減に関連する統計情報、および関連情報を通知します。DDOS攻撃がエンタープライズDMSがそれ自体を処理する可能性がある特定のレベルに終了または減少したら、DOTSサーバーは攻撃が深刻化したエンタープライズDMSドットクライアントに通知します。
The DOTS client on the enterprise DMS then requests that the ITP terminate the DDoS Mitigation. The DOTS server on the ITP receives this request and, once the mitigation has ended, confirms the end of upstream DDoS Mitigation to the enterprise DMS DOTS client.
その後、エンタープライズDMS上のドットクライアントは、ITPがDDOS軽減を終了するように要求します。ITP上のドットサーバーはこの要求を受け取り、緩和が終了したら、Upstream DDosクライアントへのアップストリームDDOの軽減を確認します。
The following is an overview of the DOTS communication model for this use case:
このユースケースのドット通信モデルの概要は次のとおりです。
1. A DDoS attack is initiated against resources of a network organization (here, the enterprise), which has deployed a DOTS-capable DMS -- typically a DOTS client.
1. DOTS対応DMSを展開しているネットワーク組織（ここでは企業）のリソースに対してDDOS攻撃が開始されます。通常はドットクライアントです。
2. The enterprise DMS detects, classifies, and begins the DDoS Mitigation.
2. 企業DMSはDDOSの軽減を検出、分類し、開始します。
3. The enterprise DMS determines that its capacity and/or capability to mitigate the DDoS attack is insufficient and sends a DOTS DDoS Mitigation request via its DOTS client to one or more DOTS servers residing on the upstream ITP.
3. エンタープライズDMSは、DDOS攻撃を軽減するためのその容量および/または機能が不十分であると判断し、そのドットクライアントを介してドットDDOSの軽減要求をアップストリームITPに存在する1つ以上のドットサーバーに送信します。
4. The DOTS server, which receives the DOTS Mitigation request, determines that it has been configured to honor requests from the requesting DOTS client and does so by orchestrating its own DMS.
4. ドットの軽減要求を受信するドットサーバは、要求側のドットクライアントからの要求を尊重し、それ自身のDMSを調整することによってそうするように構成されていると判断する。
5. While the DDoS Mitigation is active, the DOTS server regularly transmits DOTS DDoS Mitigation status updates to the DOTS client.
5. DDOSの軽減がアクティブな間、ドットサーバーは定期的にドットのDDOSの軽減ステータスの更新をドットクライアントに送信します。
6. Informed by the DOTS server status update that the attack has ended or subsided, the DOTS client transmits a DOTS DDoS Mitigation termination request to the DOTS server.
6. ドットサーバーのステータスの更新攻撃が終了または鎮静したことを更新すると、ドットクライアントはドットDDOSの軽減の終了要求をドットサーバーに送信します。
7. The DOTS server terminates DDoS Mitigation and sends the notification to the DOTS client.
7. DOTSサーバーはDDOSの軽減を終了し、通知をドットクライアントに送信します。
Note that communications between the enterprise DOTS client and the upstream ITP DOTS server may take place in band within the main Internet WAN link between the enterprise and the ITP; out of band via a separate, dedicated wireline network link utilized solely for DOTS signaling; or out of band via some other form of network connectivity such as third-party wireless 4G network connectivity.
エンタープライズドットクライアントとアップストリームITPドットサーバー間の通信は、企業とITPの間のメインインターネットWANリンク内でバンドで行われることがあります。ドットシグナリングのためだけに利用される別個の専用の有線ネットワークリンクを介してバンドの不足。またはサードパーティのワイヤレス4Gネットワーク接続などの他の形式のネットワーク接続性を介してバンドの外に。
Note also that a DOTS client that sends a DOTS Mitigation request may also be triggered by a network admin that manually confirms the request to the upstream ITP, in which case the request may be sent from an application such as a web browser or a dedicated mobile application.
また、ドット軽減要求を送信するドットクライアントは、アップストリームITPへの要求を手動で確認するネットワーク管理者によってトリガされてもよく、その場合、その要求はウェブブラウザや専用のモバイルなどのアプリケーションから送信されてもよい応用。
Note also that when the enterprise is multihomed and connected to multiple upstream ITPs, each ITP is only able to provide a DDoS Mitigation Service for the traffic it transits. As a result, the enterprise network may be required to coordinate the various DDoS Mitigation Services associated with each link. More multihoming considerations are discussed in [DOTS-MULTIHOMING].
また、企業がマルチホーム化されて複数のアップストリームITPに接続されている場合、各ITPはITトラフィックのDDOS軽減サービスを提供することができます。その結果、エンタープライズネットワークは、各リンクに関連するさまざまなDDOの軽減サービスを調整するために必要とされることがあります。より多くのマルチホーム上の考慮事項は[DOTS-MULTIHOMING]で説明されています。
This use case differs from the previous use case described in Section 3.1 in that the DDoS Mitigation Service is not provided by an upstream ITP. In other words, as represented in Figure 2, the traffic is not forwarded through the DDoS Mitigation Service Provider by default. In order to steer the traffic to the DDoS Mitigation Service Provider, some network configuration changes are required. As such, this use case is likely to apply to large enterprises or large data centers but, as for the other use cases, is not exclusively limited to them.
このユースケースは、DDOS軽減サービスが上流のITPによって提供されていない点で、セクション3.1に記載されている以前のユースケースとは異なる。つまり、図2に示すように、トラフィックはデフォルトでDDOS軽減サービスプロバイダを介して転送されません。トラフィックをDDOS軽減サービスプロバイダに操縦するためには、いくつかのネットワーク構成変更が必要です。このように、このユースケースは大企業または大規模なデータセンターに適用される可能性がありますが、他のユースケースはそれらに限定されません。
Another typical scenario for this use case is for there to be a relationship between DDoS Mitigation Service Providers, forming an overlay of DMS. When a DDoS Mitigation Service Provider mitigating a DDoS attack reaches its resource capacity, it may choose to delegate the DDoS Mitigation to another DDoS Mitigation Service Provider.
このユースケースのための別の典型的なシナリオは、DDOS緩和サービスプロバイダ間の関係があり、DMSのオーバーレイを形成することである。DDOS攻撃を軽減するDDOS軽減サービスプロバイダがそのリソース容量に達すると、DDOS緩和を別のDDOS軽減サービスプロバイダに委任することを選択できます。
+------------------+ +------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| | | Provider |
| +--------+ | | DDoS Attack
| | DDoS | | <=================================
| | Target | | <=================================
| +--------+ | | |
| | | |
| | +------------------+
| |
| | +------------------+
| | | DDoS Mitigation |
| | | Service Provider |
| | | |
| +------------+ | | +------------+ |
| | DDoS |<------------>| DDoS | |
| | Mitigation |C | | S| Mitigation | |
| | System | | | | System | |
| +------------+ | | +------------+ |
+------------------+ +------------------+
* C is for DOTS client functionality * S is for DOTS server functionality
* Cはドットクライアント機能のためのものです* Sはドットサーバー機能のためのものです
Figure 2: DDoS Mitigation between an Enterprise Network and a Third-Party DDoS Mitigation Service Provider
図2：エンタープライズネットワークとサードパーティのDDOS軽減サービスプロバイダ間のDDOの軽減
In this scenario, an enterprise network has entered into a prearranged DDoS Mitigation assistance agreement with one or more third-party DDoS Mitigation Service Providers in order to ensure that sufficient DDoS Mitigation capacity and/or capabilities may be activated in the event that a given DDoS attack threatens to overwhelm the ability of the enterprise or any other given DMS to mitigate the attack on its own.
このシナリオでは、エンタープライズネットワークは、1つ以上のサードパーティのDDOの軽減サービスプロバイダを確実に設置したことを確実にするために、1つ以上のサードパーティのDDOSの軽減サービスプロバイダを確実に締結しました。攻撃は、企業や他の特定のDMSの能力を自分で軽減する能力を圧倒することを脅かしています。
The prearrangement typically includes agreement on the mechanisms used to redirect the traffic to the DDoS Mitigation Service Provider, as well as the mechanism to re-inject the traffic back to the Enterprise Network. Redirection to the DDoS Mitigation Service Provider typically involves BGP prefix announcement or DNS redirection, while re-injection of the scrubbed traffic to the enterprise network may be performed via tunneling mechanisms (e.g., GRE). The exact mechanisms used for traffic steering are out of scope of DOTS but will need to be prearranged, while in some contexts such changes could be detected and considered as an attack.
PREARRANGENTEMENTは通常、トラフィックをDDOS軽減サービスプロバイダにリダイレクトするために使用されるメカニズムに対する合意と、トラフィックをエンタープライズネットワークに戻すメカニズムを含みます。DDOS緩和サービスプロバイダへのリダイレクトは、通常、BGPプレフィックスアナウンスメントまたはDNSリダイレクトを含み、企業ネットワークへのスクラブテープへの再注入はトンネリングメカニズム（例えば、GRE）を介して実行され得る。交通ステアリングに使用される正確なメカニズムはドットの範囲外であるが、事前には事実上、そのような変更が検出され、攻撃として考慮される可能性がある。
In some cases, the communication between the enterprise DOTS client and the DOTS server of the DDoS Mitigation Service Provider may go through the ITP carrying the DDoS attack, which would affect the communication. On the other hand, the communication between the DOTS client and DOTS server may take a path that is not undergoing a DDoS attack.
場合によっては、Enterprise DotsクライアントとDDOS軽減サービスプロバイダのドットサーバとの間の通信が、通信に影響を与えることになるDDOS攻撃を担うITPを通過することができる。一方、ドットクライアントとドットサーバとの間の通信は、DDOS攻撃を受けていないパスをとることができる。
+------------------+ +------------------+
| Enterprise | | Upstream |
| Network | | Internet Transit |
| | | Provider |
| +--------+ | | DDoS Attack
| | DDoS | |<----------------+ | ++====
| | Target | | Mitigated | | || ++=
| +--------+ | | | | || ||
| | | | | || ||
| | +--------|---------+ || ||
| | | || ||
| | +--------|---------+ || ||
| | | DDoS Mitigation | || ||
| | | Service Provider | || ||
| | | | | || ||
| +------------+ | | +------------+ | || ||
| | DDoS |<------------>| DDoS | | || ||
| | mitigation |C | |S | mitigation |<===++ ||
| | system | | | | system |<======++
| +------------+ | | +------------+ |
+------------------+ +------------------+
* C is for DOTS client functionality * S is for DOTS server functionality
* Cはドットクライアント機能のためのものです* Sはドットサーバー機能のためのものです
Figure 3: Redirection to a DDoS Mitigation Service Provider
図3：DDOS軽減サービスプロバイダへのリダイレクト
When the enterprise network is under attack or at least is reaching its capacity or ability to mitigate a given DDoS attack, the DOTS client sends a DOTS request to the DDoS Mitigation Service Provider to initiate network traffic diversion -- as represented in Figure 3 -- and DDoS Mitigation activities. Ongoing attack and mitigation status messages may be passed between the enterprise network and the DDoS Mitigation Service Provider using DOTS. If the DDoS attack has stopped or the severity of the attack has subsided, the DOTS client can request that the DDoS Mitigation Service Provider terminate the DDoS Mitigation.
エンタープライズネットワークが攻撃中または少なくとも所与のDDOS攻撃を軽減する能力に達すると、DOTSクライアントはネットワークトラフィックの転換を開始するためにDOTSクライアントがDOTSリクエストを送信します - 図3に示すように - そしてDDOSの軽減活動。継続的な攻撃および緩和ステータスメッセージは、ドットを使用して、エンタープライズネットワークとDDOSの軽減サービスプロバイダの間で渡されます。DDOS攻撃が停止した、または攻撃の重大度が低下した場合、DOTSクライアントはDDOS軽減サービスプロバイダがDDOS軽減を終了するように要求することができます。
In this use case, one or more DDoS telemetry systems or monitoring devices monitor a network -- typically an ISP network, an enterprise network, or a data center. Upon detection of a DDoS attack, these DDoS telemetry systems alert an orchestrator in charge of coordinating the various DMSs within the domain. The DDoS telemetry systems may be configured to provide required information, such as a preliminary analysis of the observation, to the orchestrator.
このユースケースでは、1つ以上のDDOSテレメトリシステムまたは監視装置はネットワークを監視する - 通常、ISPネットワーク、エンタープライズネットワーク、またはデータセンター。DDOS攻撃を検出すると、これらのDDOSテレメトリシステムは、ドメイン内のさまざまなDMSを調整することを担当するオーケストレーションを警告します。DDOSテレメトリシステムは、観察の予備分析などの要求された情報をオーケストレータに提供するように構成されてもよい。
The orchestrator analyzes the various sets of information it receives from DDoS telemetry systems and initiates one or more DDoS Mitigation strategies. For example, the orchestrator could select the DMS in the enterprise network or one provided by the ITP.
オーケストレータは、DDOSテレメトリシステムから受信したさまざまな情報を分析し、1つまたは複数のDDOの軽減戦略を開始します。たとえば、オーケストレータは、エンタープライズネットワーク内のDMSまたはITPによって提供されたものを選択することができます。
DMS selection and DDoS Mitigation techniques may depend on the type of the DDoS attack. In some cases, a manual confirmation or selection may also be required to choose a proposed strategy to initiate a DDoS Mitigation. The DDoS Mitigation may consist of multiple steps such as configuring the network or updating already-instantiated DDoS Mitigation functions. Eventually, the coordination of the mitigation may involve external DDoS Mitigation resources such as a transit provider or a third-party DDoS Mitigation Service Provider.
DMS選択およびDDOSの軽減技術は、DDOS攻撃の種類によって異なります。場合によっては、DDOの軽減を開始するための提案された戦略を選択するために手動の確認または選択を必要とすることもあります。DDOSの軽減は、ネットワークの構成や既にインスタンス化されたDDOSの軽減機能の更新などの複数のステップからなることがあります。最終的に、緩和の調整は、トランジットプロバイダやサードパーティのDDOSの軽減サービスプロバイダなどの外部DDOの軽減リソースを含み得る。
The communication used to trigger a DDoS Mitigation between the DDoS telemetry and monitoring systems and the orchestrator is performed using DOTS. The DDoS telemetry system implements a DOTS client while the orchestrator implements a DOTS server.
DDOSテレメトリと監視システムとの間のDDOS軽減を起動するために使用される通信は、ドットを使用して実行されます。DDOSテレメトリシステムは、オーケストレータがドットサーバを実装している間にドットクライアントを実装する。
The communication between a network administrator and the orchestrator is also performed using DOTS. The network administrator uses, for example, a web interface that interacts with a DOTS client, while the orchestrator implements a DOTS server.
ネットワーク管理者とオーケストレータとの間の通信もドットを用いて行われる。ネットワーク管理者は、例えば、Orchestratorがドットサーバを実装している間、ドットクライアントと対話するWebインターフェースを使用する。
The communication between the orchestrator and the DMSs is performed using DOTS. The orchestrator implements a DOTS client while the DMSs implement a DOTS server.
オーケストレータとDMSとの間の通信は、ドットを用いて行われる。Orchestratorは、DMSSがドットサーバーを実装している間にドットクライアントを実装しています。
The configuration aspects of each DMS, as well as the instantiations of DDoS Mitigation functions or network configuration, are not part of DOTS. Similarly, the discovery of available DDoS Mitigation functions is not part of DOTS and, as such, is out of scope.
各DMSの構成の態様、ならびにDDOS緩和関数またはネットワーク構成のインスタンス化は、ドットの一部ではない。同様に、利用可能なDDOS緩和機能の発見はドットの一部ではなく、そのように範囲外である。
+----------+
| network |C (Enterprise Network)
| admini- |<-+
| strator | |
+----------+ |
|
+----------+ | S+--------------+ +-----------+
|telemetry/| +->| |C S| DDoS |+
|monitoring|<--->| Orchestrator |<--->| mitigation||
|systems |C S| |<-+ | systems ||
+----------+ +--------------+C | +-----------+|
| +----------+
-----------------------------------|-----------------
|
|
(Internet Transit Provider) |
| +-----------+
| S| DDoS |+
+->| mitigation||
| systems ||
+-----------+|
* C is for DOTS client functionality +----------+
* S is for DOTS server functionality
Figure 4: DDoS Orchestration
図4：DDOSオーケストレーション
The DDoS telemetry systems monitor various aspects of the network traffic and perform some measurement tasks.
DDOSテレメトリシステムは、ネットワークトラフィックのさまざまな側面を監視し、いくつかの測定タスクを実行します。
These systems are configured so that when an event or some measurement indicators reach a predefined level, their associated DOTS client sends a DOTS mitigation request to the orchestrator DOTS server. The DOTS mitigation request may be associated with some optional mitigation hints to let the orchestrator know what has triggered the request. In particular, it is possible for something that looks like an attack locally to one telemetry system is not actually an attack when seen from the broader scope (e.g., of the orchestrator).
これらのシステムは、イベントまたはいくつかの測定インジケータが事前定義されたレベルに達すると、それらの関連するドットクライアントがオーケストレータドットサーバにドット緩和要求を送信するように構成されている。ドット緩和要求は、オーケストレータに要求をトリガーしたものを知らせるためのいくつかのオプションの緩和ヒントと関連付けられてもよい。特に、1つのテレメトリシステムへの攻撃のように見えるものが、より広い範囲から見たとき（例えば、オーケストレーターの）攻撃ではないものではありません。
Upon receipt of the DOTS mitigation request from the DDoS telemetry system, the orchestrator DOTS server responds with an acknowledgment to avoid retransmission of the request for mitigation. The orchestrator may begin collecting additional fine-grained and specific information from various DDoS telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the orchestrator may ask for additional information from the DDoS telemetry system; however, the collection of this information is out of scope of DOTS.
DDOSテレメトリシステムからドット緩和要求を受信すると、オーケストレータドットサーバは、軽減の要求の再送信を回避するために確認応答で応答する。オーケストレータは、測定値を相関させ、そのイベントの分析を提供するために、さまざまなDDOSテレメトリシステムからの追加の微細および特定の情報を収集し始めることができます。最終的に、オーケストレータはDDOSテレメトリシステムからの追加情報を要求することができる。ただし、この情報の収集はドットの範囲外です。
The orchestrator may be configured to start a DDoS Mitigation upon approval from a network administrator. The analysis from the orchestrator is reported to the network administrator via, for example, a web interface. If the network administrator decides to start the mitigation, the network administrator triggers the DDoS Mitigation request using, for example, a web interface of a DOTS client communicating to the orchestrator DOTS server. This request is expected to be associated with a context that provides sufficient information to the orchestrator DOTS server to infer, elaborate, and coordinate the appropriate DDoS Mitigation.
オーケストレータは、ネットワーク管理者からの承認時にDDOを軽減するように構成されてもよい。オーケストラからの分析は、例えばWebインターフェースを介してネットワーク管理者に報告される。ネットワーク管理者が緩和を開始することを決定すると、ネットワーク管理者は、例えば、オーケストレータドットサーバに通信するドットクライアントのWebインターフェースを使用してDDOS軽減要求をトリガする。この要求は、適切なDDOの軽減を推測、作成、および調整するために、オーケストレータドットサーバに十分な情報を提供するコンテキストと関連付けられると予想される。
Upon receiving a request to mitigate a DDoS attack aimed at a target, the orchestrator may evaluate the volume of the attack as well as the value that the target represents. The orchestrator may select the DDoS Mitigation Service Provider based on the attack severity. It may also coordinate the DDoS Mitigation performed by the DDoS Mitigation Service Provider with some other tasks such as, for example, moving the target to another network so new sessions will not be impacted. The orchestrator requests a DDoS Mitigation by the selected DMSs via its DOTS client, as described in Section 3.1.
ターゲットを対象としたDDOS攻撃を軽減するための要求を受信すると、オーケストラは攻撃の量を評価し、ターゲットが表す値を評価することができる。オーケストレータは、攻撃重大度に基づいてDDOS軽減サービスプロバイダを選択することができる。また、DDOS緩和サービスプロバイダによって実行されるDDOS緩和を、例えばターゲットを他のネットワークに移動させるように、新しいセッションが影響を受けないように、他のいくつかのタスクを調整することもできる。Orchestratorは、セクション3.1で説明されているように、選択されたDMSによってそのドットクライアントを介してDDOS軽減を要求します。
The orchestrator DOTS client is notified that the DDoS Mitigation is effective by the selected DMSs. The orchestrator DOTS server returns this information to the network administrator.
Orchestrator Dotsクライアントには、DDOSの軽減が選択されたDMSによって有効であることが通知されます。オーケストレータドットサーバーは、この情報をネットワーク管理者に返します。
Similarly, when the DDoS attack has stopped, the orchestrator DOTS client is notified and the orchestrator's DOTS server indicates the end of the DDoS Mitigation to the DDoS telemetry systems as well as to the network administrator.
同様に、DDOS攻撃が停止したときに、オーケストレータドットクライアントが通知され、Orchestratorのドットサーバは、DDOSテレメトリシステムおよびネットワーク管理者へのDDOS緩和の終了を示す。
In addition to the DDoS orchestration shown in Figure 4, the selected DMS can return a mitigation request to the orchestrator as an offloading. For example, when the DDoS attack becomes severe and the DMS's utilization rate reaches its maximum capacity, the DMS can send mitigation requests with additional hints, such as its blocked traffic information, to the orchestrator. Then the orchestrator can take further actions such as requesting forwarding nodes (e.g., routers) to filter the traffic. In this case, the DMS implements a DOTS client while the orchestrator implements a DOTS server. Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services). These validation checks are part of the mitigation and are therefore out of the scope of the document.
図4に示すDDOSオーケストレーションに加えて、選択されたDMSはオフロードとしてオーケストレータに緩和要求を返すことができる。たとえば、DDOS攻撃がひどくなり、DMSの利用率が最大容量に達すると、DMSはそのブロックされたトラフィック情報などの追加のヒントとオーケストレータに緩和要求を送信できます。次いで、オーケストレータは、トラフィックをフィルタリングするために転送ノード（例えば、ルータ）を要求するなど、さらなる動作を実行することができる。この場合、DMSはドットクライアントを実装している間、Orchestratorはドットサーバを実装する。他のドット使用例と同様に、オフロードシナリオは、いくつかの検証チェックの後にDMS、オーケストレーレータ、またはその両方が続くと仮定している（例えば、転送ノードのリソースまたは正当なサービスの誤った中断の中断を排除しない）。これらの検証チェックは緩和の一部であり、したがって文書の範囲外です。
The document does not describe any protocol, though there are still a few high-level security considerations to discuss.
この文書は任意のプロトコルを説明していませんが、依然としていくつかの高レベルのセキュリティ上の考慮事項があります。
DOTS is at risk from three primary attacks: DOTS agent impersonation, traffic injection, and signaling blocking.
ドットは3つの主要な攻撃から危険にさらされています。ドットエージェントの偽装、トラフィック注入、およびシグナリングブロッキング。
Impersonation and traffic injection mitigation can be mitigated through current secure communications best practices, including mutual authentication. Preconfigured mitigation steps to take on the loss of keepalive traffic can partially mitigate signal blocking. But in general, it is impossible to comprehensively defend against an attacker that can selectively block any or all traffic. Alternate communication paths that are (hopefully) not subject to blocking by the attacker in question is another potential mitigation.
相互認証を含む、現在の安全な通信のベストプラクティスを通じて、偽装およびトラフィック噴射緩和を軽減することができる。キープアライブトラフィックの損失をとるための事前設定された緩和ステップは、信号ブロッキングを部分的に軽減することができます。しかし一般的に、トラフィックやすべてのトラフィックを選択的にブロックすることができる攻撃者に対して包括的に防御することは不可能です。問題の攻撃者によるブロッキングの対象とはならない（うまくいけば）代替通信経路は別の潜在的な緩和です。
Additional details of DOTS security requirements can be found in [RFC8612].
ドットセキュリティ要件の追加情報は[RFC8612]にあります。
Service disruption may be experienced if inadequate mitigation actions are applied. These considerations are out of the scope of DOTS.
不適切な緩和措置が適用されている場合、サービスの混乱が経験される可能性があります。これらの考慮事項はドットの範囲外です。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[DOTS-MULTIHOMING] Boucadair, M., Reddy, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Work in Progress, Internet-Draft, draft-ietf-dots-multihoming-06, 25 May 2021, <https://tools.ietf.org/html/draft-ietf-dots-multihoming-06>.
[DOT-MULTIHOMING] Boucadair、M.、Reddy、T.、およびW. Pan、「配布サービス拒否開放シグナル伝達（ドット）」の「マルチホーミング展開に関する考慮事項」、進行中の作業、インターネットドラフト、draft-ietf-dots-mortihoming-06,2021、<https：//tools.ietf.org/html/draft-ietf-dots-multihoming-06>。
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, <https://www.rfc-editor.org/info/rfc8612>.
[RFC8612] Mortensen、A.、Reddy、T.、およびR. Moskowitz、 "DDOSオープン脅威シグナリング（ドット）要件"、RFC 8612、DOI 10.17487 / RFC8612、2019年5月、<https：//www.rfc-編集者.org / info / rfc8612>。
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, <https://www.rfc-editor.org/info/rfc8782>.
[RFC8782] Reddy.K、T.、ED。、Boucadair、M.、Ed。、Patil、P.、Mortensen、A.、およびN. TeaGue、 "Distribe Service Open Threatシグナリング（ドット）信号Channel Specification "、RFC 8782、DOI 10.17487 / RFC8782、2020年5月、<https：//www.rfc-editor.org/info/rfc8782>。
[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
謝辞
The authors would like to thank, among others, Tirumaleswar Reddy.K, Andrew Mortensen, Mohamed Boucadair, Artyom Gavrichenkov, Jon Shallow, Yuuhei Hayashi, Elwyn Davies, the DOTS WG Chairs (at the time of writing) Roman Danyliw and Tobias Gondrom, as well as the Security AD Benjamin Kaduk for their valuable feedback.
著者は、とりわけ、Tirumaleswar Reddy.k、Andrew Mortensen、Mohamed Boucadair、Artyom Gavrichenkov、Jon Shallow、Jon Shallow、Elwyn Davies（執筆時）、ローマDanyylwとTobias Gondrom、Roman Danyylw、Tobias Gondrom貴重なフィードバックのためのセキュリティ広告ベンジャミンKaduk。
We also would like to thank Stephan Fouant, who was one of the initial coauthors of the documents.
私達はまた文書の初期の共和国の一人だったStephan Fouantにも感謝したいです。
Authors' Addresses
著者の住所
Roland Dobbins Netscout, Inc. Singapore
Roland Dobbins NetScout、Inc。シンガポール
Email: roland.dobbins@netscout.com
Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, Quebec 4S 0B6 Canada
Daniel Migault Ericsson 8275トランスカナダルートSaint Laurent、ケベック4S 0B6カナダ
Email: daniel.migault@ericsson.com
Robert Moskowitz HTT Consulting Oak Park, MI 48237 United States of America
Robert Moskowitz Htt Consulting Oak Park、MI 48237アメリカ合衆国
Email: rgm@labs.htt-consult.com
Nik Teague Iron Mountain Data Centers United Kingdom
Nik Teague Iron Mountainデータセンターイギリス
Email: nteague@ironmountain.co.uk
Liang Xia Huawei No. 101, Software Avenue, Yuhuatai District Nanjing China
Liang Xia Huawei No. 101、ソフトウェアアベニュー、雲首区南京中国
Email: Frank.xialiang@huawei.com
Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118 Japan
カナム西塚NTTコミュニケーションズGRANPARK 16F 3-4-1芝浦、東京都港区108-8118日本
Email: kaname@nttv6.jp