[要約] RFC 9066は、分散型サービス拒否（DDoS）攻撃から保護するためのDOTS Signal Channel Call Homeプロトコルを定義します。このプロトコルの目的は、攻撃検出システムが攻撃情報を自動的にホームネットワークに通知し、迅速な対応を可能にすることです。利用場面には、企業や組織が自社のインフラをDDoS攻撃から守るための通信手段としての活用が含まれます。
Internet Engineering Task Force (IETF) T. Reddy.K
Request for Comments: 9066 Akamai
Category: Standards Track M. Boucadair, Ed.
ISSN: 2070-1721 Orange
J. Shallow
December 2021
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home
分散サービス拒否オープン脅威シグナリング（ドット）信号チャンネルコールホーム
Abstract
概要
This document specifies the Denial-of-Service Open Threat Signaling (DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s).
このドキュメントでは、サービス拒否オープン脅威シグナリング（ドット）信号チャネル呼び出しホームを指定します。これにより、Call Home Dots Serverがコールホームドットクライアントへの安全な接続を開始し、コールホームドットクライアントから攻撃トラフィック情報を受信できます。。Call Home Dots Serverは、攻撃トラフィック情報を使用して、発信されたDDOS攻撃を起動し、適切な軽減措置を講じることを識別します。
The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack.
ドット信号チャネル呼び出しホームはホームネットワークに固有のものではありません。このソリューションは、DDOS攻撃のソースに近いDDOS攻撃トラフィックをブロックする必要がある展開をターゲットにします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9066.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc9066で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Applicability Scope
4. Coexistence of a Base DOTS Signal Channel and DOTS Call Home
5. DOTS Signal Channel Call Home
5.1. Procedure
5.2. DOTS Signal Channel Variations
5.2.1. Heartbeat Mechanism
5.2.2. Redirected Signaling
5.3. DOTS Signal Channel Extension
5.3.1. Mitigation Request
5.3.2. Address Sharing Considerations
6. DOTS Signal Call Home YANG Module
6.1. Tree Structure
6.2. YANG/JSON Mapping Parameters to CBOR
6.3. YANG Module
7. IANA Considerations
7.1. DOTS Signal Channel CBOR Mappings Registry
7.2. New DOTS Conflict Cause
7.3. DOTS Signal Call Home YANG Module
8. Security Considerations
9. Privacy Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Some Home Network Issues
Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home
Acknowledgements
Contributors
Authors' Addresses
The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol [RFC9132] is used to carry information about a network resource or a network (or a part thereof) that is under a Distributed Denial-of-Service (DDoS) attack [RFC4732]. Such information is sent by a DOTS client to one or multiple DOTS servers so that appropriate mitigation actions are undertaken on traffic deemed suspicious. Various use cases are discussed in [RFC8903].
分散サービス拒否オープン脅威シグナリング（DOTS）信号チャネルプロトコル[RFC9132]は、分散サービス拒否サービス（DDO）の下にあるネットワークリソースまたはネットワーク（またはその一部）に関する情報を伝送するために使用される。攻撃[RFC4732]。そのような情報は、疑わしいと見なされるトラフィック上で適切な緩和措置が行われるように、ドットクライアントが1つまたは複数のドットサーバーに送信されます。[RFC8903]では、さまざまなユースケースについて説明します。
However, [RFC9132] only covers how to mitigate when being attacked (i.e., protecting a network from inbound DDoS attacks). It does not cover how to control the attacks close to their source(s) that are misusing network resources (i.e., outbound DDoS attacks). In particular, the DOTS signal protocol does not discuss cooperative DDoS mitigation between the network hosting an attack source and the Internet Service Provider (ISP) to suppress the outbound DDoS attack traffic originating from that network. As a reminder, the base basic DOTS architecture is depicted in Figure 1 (Section 2 of [RFC8811]).
ただし、[RFC9132]攻撃されたときに軽減する方法のみを説明します（すなわち、インバウンドDDOS攻撃からネットワークを保護する）。ネットワークリソースを誤用しているソースに近い攻撃を制御する方法をカバーしません（すなわち、アウトバウンドDDOS攻撃）。特に、ドット信号プロトコルは、攻撃送信元とインターネットサービスプロバイダ（ISP）をホストしているネットワーク間の協調DDO（ISP）との間の協調DDos緩和を説明して、そのネットワークから発信されたアウトバウンドDDOS攻撃トラフィックを抑制する。リマインダーとして、基本的な基本的なドットアーキテクチャは図1に示されています（[RFC8811のセクション2）。
+-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +-------------+
|
|
|
+---------------+ +-------------+
| Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+
Figure 1: Basic DOTS Architecture
図1：基本ドットアーキテクチャ
Appendix A details why the rise of Internet of Things (IoT) compounds the possibility of these being used as malicious actors that need to be controlled. Similar issues can be encountered in enterprise networks, data centers, etc. The ISP offering a DDoS mitigation service can detect outgoing DDoS attack traffic originating from its subscribers, or the ISP may receive filtering rules (e.g., using BGP Flowspec [RFC8955] [RFC8956]) from a transit provider to filter, block, or rate-limit DDoS attack traffic originating from the ISP's subscribers to a downstream target. Nevertheless, the DOTS signal channel does not provide means for the ISP to request blocking such attacks close to the sources without altering legitimate traffic. This document fills that void by specifying an extension to the DOTS signal channel: DOTS signal channel Call Home.
付録A物事のインターネットの上昇（IoT）化合物の詳細は、これらが制御される必要がある悪意のある俳優として使用されている可能性を示しています。企業ネットワーク、データセンターなどで同様の問題が発生する可能性があります.DDOSの軽減サービスを提供するISPは、その加入者から発信された送信DDOS攻撃トラフィックを検出できます。またはISPはフィルタリングルールを受信することがあります（例：BGP Flowspec [RFC8955]を使用して[RFC8956]]）ISPの加入者からダウンストリームターゲットへのDDOS攻撃トラフィックをフィルタリング、ブロック、またはレート制限するためのトランジットプロバイダから。それにもかかわらず、ドット信号チャネルは、正当なトラフィックを変更することなく、そのような攻撃を起源に近づけることを要求するための手段を提供しない。このドキュメントは、ドット信号チャネルの拡張を指定することによって、そのvoidを埋めます。ドット信号チャネル呼び出しホーム。
Note: Another design approach would be to extend the DOTS signal channel with a new attribute to explicitly indicate whether a mitigation request concerns an outbound DDoS attack. In such an approach, it is assumed that a DOTS server is deployed within the domain that is hosting the attack source(s), while a DOTS client is enabled within an upstream network (e.g., access network). However, initiating a DOTS signal channel from an upstream network to a source network is complicated because of the presence of translators and firewalls. Moreover, the use of the same signal channel to handle both inbound and outbound attacks complicates both the heartbeat and redirection mechanisms that are executed as a function of the attack direction (see Sections 5.2.1 and 5.2.2). Also, the DOTS server will be subject to fingerprinting (e.g., using scanning tools) and DoS attacks (e.g., by having the DOTS server perform computationally expensive operations). Various management and deployment considerations that motivate the Call Home functionality are listed in Section 1.1 of [RFC8071].
注意：別の設計アプローチは、緩和要求がアウトバウンドDDOS攻撃に関するものであるかどうかを明示的に示すために、ドット信号チャネルを新しい属性で拡張することです。そのようなアプローチでは、ドットサーバが攻撃送信元をホストしているドメイン内に展開され、ドットクライアントはアップストリームネットワーク（例えば、アクセスネットワーク）内で有効にされると仮定する。しかしながら、翻訳者およびファイアウォールが存在するため、アップストリームネットワークからソースネットワークへのドット信号チャネルを開始することが複雑になる。さらに、インバウンドおよびアウトバウンド攻撃の両方を処理するために同じ信号チャネルを使用すると、攻撃方向の関数として実行されるハートビートとリダイレクトメカニズムの両方が複雑になります（セクション5.2.1および5.2.2を参照）。また、ドットサーバは、（例えば、走査ツールを使用する）とDOS攻撃（例えば、ドットサーバを用いて計算的に高価な操作を実行させることによって）を指紋処理することになる。コールホーム機能を動機付ける様々な管理と展開の考慮事項は、[RFC8071]のセクション1.1にリストされています。
"DOTS signal channel Call Home" (or "DOTS Call Home" for short) refers to a DOTS signal channel established at the initiative of a DOTS server thanks to a role reversal at the (D)TLS layer (Section 5.1). That is, the DOTS server initiates a secure connection to a DOTS client and uses that connection to receive the attack traffic information (e.g., attack sources) from the DOTS client.
「ドット信号チャネルコールホーム」（または短絡のための「ドットコールホーム」）は、（D）TLS層（セクション5.1）での役割の逆転のおかげで、ドットサーバのイニシアチブで確立されたドット信号チャネルを指す。すなわち、ドットサーバはドットクライアントへの安全な接続を開始し、その接続を使用して、ドットクライアントから攻撃トラフィック情報（例えば、攻撃ソース）を受信する。
A high-level DOTS Call Home functional architecture is shown in Figure 2. Attack source(s) are within the DOTS server domain.
高水準ドット呼び出しホーム機能アーキテクチャを図2に示します。攻撃ソースはドットサーバードメイン内にあります。
Scope
+.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+ : +-------------+ :
| Alert | ~~~:~~~ | Call Home | :
| | : | DOTS client | :
+---------------+ : +------+------+ :
: | :
: | :
: | :
+---------------+ : +------+------+ :
| Attack | ~~~:~~~ | Call Home | :
| Source(s) | : | DOTS server | :
+---------------+ : +-------------+ :
+.-.-.-.-.-.-.-.-.-.-.-.+
Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture
図2：基本ドット信号チャネル呼び出しホーム機能アーキテクチャ
DOTS agents involved in the DOTS Call Home otherwise adhere to the DOTS roles as defined in [RFC8612]. For clarity, this document uses "Call Home DOTS client" (or "Call Home DOTS server") to refer to a DOTS client (or DOTS server) deployed in a Call Home scenario (Figure 2). Call Home DOTS agents may (or may not) be co-located with DOTS agents that are compliant with [RFC9132] (see Section 4 for more details).
ドットコールホームに関与するドットエージェントは、[RFC8612]で定義されているようにドットの役割を遵守します。明確にするために、このドキュメントでは「呼び出しホームドットクライアント」（または「呼び出しホームドットサーバー」）を使用して、コールホームシナリオでデプロイされているドットクライアント（またはドットサーバー）を参照しています（図2）。Home Dotsエージェントを呼び出してください（またはRFC9132]に準拠しているドットエージェントと同じ場所に配置されている場合があります（詳細についてはセクション4を参照）。
A Call Home DOTS client relies upon a variety of triggers to make use of the Call Home function (e.g., scrubbing the traffic from the attack source or receiving an alert from an attack target, a peer DDoS Mitigation System (DMS), or a transit provider). The definition of these triggers is deployment specific. It is therefore out of the scope of this document to elaborate on how these triggers are made available to a Call Home DOTS client.
呼び出しホームドットクライアントは、コールホーム機能を利用するためのさまざまなトリガーに依存しています（たとえば、攻撃元からのトラフィックをスクラブするか、攻撃対象からの警告、ピアDDOSの軽減システム（DMS）、またはトランジット）プロバイダ）。これらのトリガの定義は展開固有です。したがって、この文書の範囲外は、これらのトリガーがコールホームドットクライアントにどのように利用可能にされるかについて詳しく説明しています。
In a typical deployment scenario, the Call Home DOTS server is enabled on a Customer Premises Equipment (CPE), which is aligned with recent trends to enrich the CPE with advanced security features. For example, the DOTS Call Home service can be part of services supported by an ISP-managed CPE or a managed security service subscribed to by the user. Unlike classic DOTS deployments [RFC8903], a Call Home DOTS server maintains a single DOTS signal channel session for each DOTS-capable upstream provisioning domain [DOTS-MULTIHOMING].
典型的な展開シナリオでは、Call Home Dots Serverは、CPEを高度なセキュリティ機能で充実させるために最近のトレンドと整列している顧客宅内機器（CPE）で有効になっています。例えば、ドットコールホームサービスは、ISP管理対象CPEまたはユーザが購読している管理対象セキュリティサービスによってサポートされているサービスの一部にすることができる。クラシックドット展開とは異なり、Call Home Dotsサーバは、各ドット対応アップストリームプロビジョニングドメイン毎に単一のドット信号チャネルセッションを維持します[DOTS-MULTIHOMING]。
For instance, the Call Home DOTS server in the home network initiates the signal channel Call Home in "idle" time; subsequently, the Call Home DOTS client in the ISP environment can initiate a mitigation request whenever the ISP detects there is an attack from a compromised device in the DOTS server domain (i.e., from within the home network).
たとえば、ホームネットワーク内の呼び出しホームドットサーバーは、 "アイドル"時間内のシグナルチャネル呼び出しホームを開始します。続いて、ISP環境内の呼び出しホームドットクライアントは、ISPがDOTSサーバドメイン内の侵入先デバイスからの攻撃があるときはいつでも（すなわち、ホームネットワーク内から）軽減要求を開始することができる。
The Call Home DOTS server uses the DDoS attack traffic information to identify the compromised device in its domain that is responsible for launching the DDoS attack, optionally notifies a network administrator, and takes appropriate mitigation action(s). For example, a mitigation action can be to quarantine the compromised device or block its traffic to the attack target(s) until the mitigation request is withdrawn.
Call Home Dots ServerはDDOS攻撃トラフィック情報を使用して、DDOS攻撃を起動する責任があるドメイン内の侵入先デバイスを識別し、オプションでネットワーク管理者に通知し、適切な軽減アクションを取ります。たとえば、緩和されたデバイスを隔離するか、緩和要求が引き出されるまで、侵入先のデバイスを隔離するか、トラフィックを攻撃対象にブロックすることです。
This document assumes that Call Home DOTS servers are provisioned with a way to know how to reach the upstream Call Home DOTS client(s), which could occur by a variety of means (e.g., [RFC8973]). The specification of such means are out of scope of this document.
この文書は、コールホームドットサーバが、上流の呼び出しホームドットクライアントに到達する方法を知っていて、さまざまな手段（例えば、[RFC8973]）で発生する可能性があるという方法でプロビジョニングされていると想定しています。そのような手段の仕様はこの文書の範囲外です。
More information about the applicability scope of the DOTS signal channel Call Home is provided in Section 3.
ドット信号チャネル呼び出しホームの適用範囲に関する追加情報はセクション3に提供されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader should be familiar with the terms defined in Section 1.2 of [RFC8612].
リーダーは[RFC8612]のセクション1.2で定義されている用語に精通している必要があります。
"DDoS Mitigation System (DMS)" refers to a system that performs DDoS mitigation.
「DDOS軽減システム（DMS）」とは、DDOS緩和を実行するシステムを指します。
"Base DOTS signal channel" refers to [RFC9132].
「基本ドット信号チャネル」とは、[RFC9132]を指します。
The meaning of the symbols in YANG tree diagrams are defined in [RFC8340] and [RFC8791].
Yangツリー図のシンボルの意味は[RFC8340]と[RFC8791]で定義されています。
(D)TLS is used for statements that apply to both Transport Layer Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) [RFC6347] [DTLS13]. Specific terms are used for any statement that applies to either protocol alone.
（d）TLSは、トランスポート層セキュリティ（TLS）[RFC8446]とデータグラムトランスポートレイヤセキュリティ（DTLS）[RFC6347] [DTLS13]の両方に適用されるステートメントに使用されます。特定の用語は、プロトコル単独のいずれかに適用される任意のステートメントに使用されます。
The problems discussed in Section 1 may be encountered in many deployments (e.g., home networks, enterprise networks, transit networks, data centers). The solution specified in this document can be used for those deployments to block DDoS attack traffic closer to the source(s) of the attack. That is, attacks that are issued, e.g., from within an enterprise network or a data center will thus be blocked before exiting these networks.
セクション1で説明した問題は、多くの展開において遭遇する可能性があります（例えば、ホームネットワーク、エンタープライズネットワーク、トランジットネットワーク、データセンター）。このドキュメントで指定されているソリューションは、攻撃のソースに近いDDOS攻撃トラフィックをブロックするための展開に使用できます。つまり、これらのネットワークを出る前に、エンタープライズネットワーク内で発行された攻撃またはデータセンター内の攻撃をブロックすることができる。
An instantiation of the Call Home functional architecture is depicted in Figure 3.
コールホーム機能アーキテクチャのインスタンス化を図3に示します。
+-------------+
|Attack Target|
+-----+-------+
| /\ Target Network
......................|.||....................
.--------+-||-------.
( || )-.
.' || '
( Internet || )
( || -'
'-( || )
'------+-||---------'
......................|.||.....................
.--------+-||-------. Network
( || )-. Provider
.' Call Home || ' (DMS)
( DOTS client || )
( || -'
'-( || )
'------+-||---------'
......................|.||.......................
.--------+-||-------. Source Network
( || )-.
.' Call Home || '
( DOTS server || Outbound )
( || DDoS -'
'-( || Attack )
'------+-||---------'
| ||
+-----+-++----+
|Attack Source|
+-------------+
Figure 3: DOTS Signal Channel Call Home Reference Architecture
図3：ドット信号チャネルコールホーム参照アーキテクチャ
It is out of the scope of this document to identify an exhaustive list of such deployments.
このような展開の徹底的なリストを特定するのはこの文書の範囲外です。
Call Home DOTS agent relationships are similar to those discussed in Section 2.3 of [RFC8811]. For example, multiple Call Home DOTS servers of the same domain can be associated with the same Call Home DOTS client. A Call Home DOTS client may decide to contact these Call Home DOTS servers sequentially, fork a mitigation request to all of them, or select one Call Home DOTS server to place a mitigation request. Such a decision is implementation specific.
呼び出しホームドットエージェントの関係は、[RFC8811]のセクション2.3で説明したものと同様です。たとえば、同じドメインの複数の呼び出しホームドットサーバーを同じコールホームドットクライアントに関連付けることができます。呼び出しホームドットクライアントは、これらの呼び出しホームドットサーバに順次連絡し、それらのすべてに対する緩和要求をフォークしたり、軽減のために1つの呼び出し元のホームドットサーバを選択することを決定してもよい。そのような決定は実装固有のものです。
For some mitigations, feedback may be required from an administrator to confirm a filtering action. The means to seek an administrator's consent are deployment specific. Indeed, a variety of implementation options can be considered for any given Call Home DOTS deployment, such as push notifications using a dedicated application, Syslog, etc. It is out of the scope of this document to make recommendations about how such interactions are implemented (see Figure 2).
いくつかの軽減のために、管理者からフィードバックが必要に応じてフィルタリングアクションを確認することができます。管理者の同意を求める手段は展開固有です。実際、専用アプリケーション、syslogなどを使用したプッシュ通知など、任意の通話ホームドット展開については、任意の所与の呼び出しオプションについて考慮することができる。図2を参照してください。
The Call Home DOTS server can be enabled on a border router or a dedicated appliance. For the particular case of home networks, the Call Home DOTS server functionality can be enabled on a managed CPE or bundled with a CPE management application that is provided by an ISP to its subscribers. These managed services are likely to be designed to hide the complexity of managing (including configuring) the CPE. For example, managed CPEs support the means to notify the user when a new device is detected in order to seek confirmation as to whether or not access should be granted to the device. These means can be upgraded to interface with the Call Home DOTS server. Customized settings can be configured by users to control the notifications (e.g., triggers, type) and default actions.
コールホームドットサーバは、境界ルータまたは専用アプライアンスで有効にできます。ホームネットワークの特定のケースでは、コールホームドットサーバー機能を管理対象のCPEで有効にすることも、ISPからその加入者に提供されるCPE管理アプリケーションにバンドルされます。これらの管理対象サービスは、管理の複雑さ（構成を含む）CPEの複雑さを隠すように設計されています。例えば、管理対象CPEは、アクセスがデバイスに付与されるべきかどうかに関して確認をシークするために新しいデバイスが検出されたときにユーザに通知するための手段をサポートする。これらの手段は、呼び出しホームドットサーバーとのインターフェースにアップグレードできます。カスタマイズされた設定は、通知（例えば、トリガー、Type）およびデフォルトのアクションを制御するためにユーザーが設定できます。
The DOTS signal channel Call Home does not require or preclude the activation of the base DOTS signal channel [RFC9132]. Some sample deployment schemes are discussed in this section for illustration purposes.
DOTS信号チャネル呼び出しホームは、ベースドット信号チャネル[RFC9132]の起動を必要とせずに排除しません。例示のためにこのセクションでサンプル展開スキームについて説明します。
The network that hosts an attack source may also be subject to inbound DDoS attacks. In that case, both the base DOTS signal channel and DOTS signal channel Call Home may be enabled as shown in Figure 4 (same DMS provider) or Figure 5 (distinct DMS providers).
攻撃源をホストするネットワークは、インバウンドDDOS攻撃の対象となる可能性があります。その場合、図4（同じDMSプロバイダ）または図5（異なるDMSプロバイダ）に示すように、基本ドット信号チャネルとドット信号チャネル呼び出しホームの両方が有効になることがあります。
DOTS Signal Channel Base DOTS
Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +------+ :: +------+ :
: | DOTS | :: | DOTS | :
: |client| :: |server| :
: +--+---+ :: +---+--+ :
: /\ | :: | : Network
: || | :: | :Provider
: || | :: | : (DMS)
...:.....||......|.....::.....|.............:........
Outbound || | :: | || Inbound
DDoS || | :: | || DDoS
Attack || | :: | \/ Attack
: +--+---+ :: +---+--+ :
: | DOTS | :: | DOTS | :
: |server| :: |client| :
: +------+ :: +------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #A
Figure 4: Activation of a Base DOTS Signal Channel and Call Home (Same DMS Provider)
図4：基本ドット信号チャネルの起動とコールホーム（同じDMSプロバイダ）
Note that a DMS provider may not be on the default forwarding path of inbound DDoS attack traffic targeting a network (e.g., Network #B in Figure 5). Nevertheless, the DOTS signal channel Call Home requires the DMS provider to be on the default forwarding path of the outbound traffic from a given network.
DMSプロバイダは、ネットワークを対象としたインバウンドDDOS攻撃トラフィックのデフォルトの転送パス（例えば、図5のネットワーク#B）にないことに注意してください。それにもかかわらず、DOTS信号チャネル呼び出しホームは、特定のネットワークからの発信トラフィックのデフォルトの転送パス上にDMSプロバイダを求める必要がある。
DOTS Signal Channel Base DOTS
Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: Network +------+ :: +------+ Third :
: Provider | DOTS | :: | DOTS | Party :
: (DMS) |client| :: |server| DMS :
: +--+---+ :: +---+--+ Provider :
: /\ | :: | :
: || | :: | :
: || | :: | :
...:.....||......|.....::.....|.............:........
Outbound || | :: | || Inbound
DDoS || | :: | || DDoS
Attack || | :: | \/ Attack
: +--+---+ :: +---+--+ :
: | DOTS | :: | DOTS | :
: |server| :: |client| :
: +------+ :: +------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #B
Figure 5: Activation of a Base DOTS Signal Channel and Call Home (Distinct DMS Providers)
図5：ベースドット信号チャネルの起動とコールホーム（異なるDMSプロバイダ）
Figures 6 and 7 depict examples where the same node embeds both base DOTS and Call Home DOTS agents. For example, a DOTS server and a Call Home DOTS client may be enabled on the same device within the infrastructure of a DMS provider (e.g., Node #i in Figure 6), or a DOTS client and a Call Home DOTS server may be enabled on the same device within a source network (e.g., Node #j with Network #D shown in Figure 7).
図6および図7は、同じノードが基本ドットと呼んでいるホームドットエージェントの両方を埋め込む例を示す。例えば、DOTSサーバおよびコールホームドットクライアントは、DMSプロバイダ（例えば、図6のノード#I）のインフラストラクチャ内の同じデバイス上で有効にされてもよく、またはドットクライアントおよびコールホームドットサーバが有効にされてもよい。ソースネットワーク内の同じデバイス（例えば、図7に示すネットワーク#Dを有するノード＃j）。
Whether the same or distinct nodes are used to host base DOTS and Call Home DOTS agents is specific to each domain.
同じまたは異なるノードがベースドットをホストするために使用され、ホームドットエージェントが各ドメインに固有のものです。
DOTS Signal Channel Base DOTS
Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +----------------------+ :
: | Node #i | :
: | +------+ +------+ | :
: | | DOTS | | DOTS | | :
: | |client| |server| | :
: | +--+---+ +---+--+ | :
: +----|-----::-----|----+ : Network
: /\ | :: | :Provider
: || | :: | : (DMS)
...:.....||......|.....::.....|.............:........
Outbound || | :: | || Inbound
DDoS || | :: | || DDoS
Attack || | :: | \/ Attack
: +--+---+ :: +---+--+ :
: | DOTS | :: | DOTS | :
: |server| :: |client| :
: +------+ :: +------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #C
Figure 6: The Same Node Embedding a Call Home DOTS Client and a DOTS Server at the Network Provider's Side
図6：ネットワークプロバイダ側にコールホームドットクライアントとドットサーバを埋め込むのと同じノード
DOTS Signal Channel Base DOTS
Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +----------------------+ :
: | Node #k | :
: | +------+ +------+ | :
: | | DOTS | | DOTS | | :
: | |client| |server| | :
: | +--+---+ +---+--+ | :
: +----|-----::-----|----+ : Network
: /\ | :: | :Provider
: || | :: | : (DMS)
...:.....||......|.....::.....|.............:........
Outbound || | :: | || Inbound
DDoS || | :: | || DDoS
Attack || | :: | \/ Attack
: +----|-----::-----|----+ :
: | +--+---+ +---+--+ | :
: | | DOTS | | DOTS | | :
: | |server| |client| | :
: | +------+ +------+ | :
: | Node #j | :
: +----------------------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #D
Figure 7: The Same Node Embedding both a DOTS Client and a Call Home DOTS Server
図7：ドットクライアントとコールホームドットサーバーの両方を埋め込むのと同じノード
Appendix B elaborates on the considerations to unambiguously distinguish DOTS messages that belong to each of these channels.
付録Bは、これらの各チャンネルに属するドットメッセージを明確に区別するための考慮事項について詳しく説明しています。
The DOTS signal channel Call Home preserves all but one of the DOTS client/server roles in the DOTS protocol stack, as compared to the client-initiated DOTS signal channel protocol [RFC9132]. The role reversal that occurs is at the (D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS client, and the Call Home DOTS client acts as a DTLS server; or (2) the Call Home DOTS server acts as a TLS client initiating the underlying TCP connection, and the Call Home DOTS client acts as a TLS server. The Call Home DOTS server initiates a (D)TLS handshake to the Call Home DOTS client.
ドット信号チャネル呼び出しホームは、クライアント開始ドット信号チャネルプロトコル[RFC9132]と比較して、ドットプロトコルスタック内のドットクライアント/サーバロールの1つを保持します。発生する役割の逆転は（D）TLS層にある。つまり、（1）呼び出しホームドットサーバはDTLSクライアントとして機能し、Call Home DotsクライアントはDTLSサーバとして機能します。（2）Call Home Dots Serverは、基盤となるTCP接続を開始するTLSクライアントとして機能し、Call Home Dots ClientはTLSサーバーとして機能します。Call Home Dots Serverは、Call Home Dotsクライアントへの（D）TLSハンドシェイクを開始します。
For example, a home network element (e.g., home router) co-located with a Call Home DOTS server is the (D)TLS client. That is, the Call Home DOTS server assumes the role of the (D)TLS client, but the network element's role as a DOTS server remains the same.
たとえば、コールホームドットサーバーと同じ場所にあるホームネットワーク要素（例えば、ホームルーター）は、（D）TLSクライアントです。つまり、Call Home Dotsサーバーは（D）TLSクライアントの役割を想定していますが、ドットサーバーとしてのネットワーク要素の役割は同じです。
Existing certificate chains and mutual authentication mechanisms between the DOTS agents are unaffected by the Call Home function. From a deployment standpoint, and given the scale of Call Home DOTS servers that may be involved, enabling means for automating the provisioning of credentials on Call Home DOTS servers to authenticate to the Call Home DOTS client is encouraged. It is out of the scope of this document to elaborate on these means.
ドットエージェント間の既存の証明書チェーンおよび相互認証メカニズムは、呼出ホーム機能の影響を受けません。展開の観点から、コールホームドットサーバーのスケールを考慮して、コールホームドットサーバー上の認証情報のプロビジョニングを自動化するための手段は、コールホームドットクライアントに認証されます。この文書の範囲外には、これらの手段に精巧にしています。
Figure 8 illustrates a sample DOTS Call Home flow exchange:
図8は、サンプルドットコールホームフロー交換を示しています。
+-----------+ +-----------+
| Call Home | | Call Home |
| DOTS | | DOTS |
| server | | client |
+-----+-----+ +-----+-----+
(D)TLS client (D)TLS server
| |
| 1. (D)TLS connection |
|----------------------------------->|
| 2. Mitigation request |
|<-----------------------------------|
| ... |
Figure 8: DOTS Signal Channel Call Home Sequence Diagram
図8：ドット信号チャネル呼び出しホームシーケンス図
The DOTS signal channel Call Home procedure is as follows:
ドット信号チャネル呼び出しホーム手順は次のとおりです。
1. If UDP transport is used, the Call Home DOTS server begins by initiating a DTLS connection to the Call Home DOTS client.
1. UDPトランスポートが使用されている場合、コールホームドットサーバーは、コールホームドットクライアントへのDTLS接続を開始することから始まります。
If TCP is used, the Call Home DOTS server begins by initiating a TCP connection to the Call Home DOTS client. Once connected, the Call Home DOTS server continues to initiate a TLS connection to the Call Home DOTS client.
TCPが使用されている場合、コールホームドットサーバーは、Call Home DotsクライアントへのTCP接続を開始することから始まります。接続されると、Call Home Dots ServerはコールホームドットクライアントへのTLS接続を開始し続けます。
Peer DOTS agents may have mutual agreement to use a specific port number, such as by explicit configuration or dynamic discovery [RFC8973]. The interaction between the base DOTS signal channel and the Call Home is discussed in Appendix B.
ピアトドットエージェントは、明示的な構成やダイナミックディスカバリなどによって特定のポート番号を使用すると相互合意を持つことができます[RFC8973]。基本ドット信号チャネルとコールホームの間の相互作用については、付録Bで説明しています。
The Happy Eyeballs mechanism explained in Section 4.3 of [RFC9132] is used for initiating (D)TLS connections.
[RFC9132]の4.3節で説明した幸せな眼球機構は、（D）TLS接続を開始するために使用されます。
2. Using this (D)TLS connection, the Call Home DOTS client may request, withdraw, or retrieve the status of mitigation requests. The Call Home DOTS client supplies the source information by means of new attributes defined in Section 5.3.1.
2. この（D）TLS接続を使用して、コールホームドットクライアントは、緩和要求のステータスを要求、撤回、または取得することができます。Call Home Dotsクライアントは、セクション5.3.1で定義されている新しい属性を使用してソース情報を提供します。
The heartbeat mechanism used for the DOTS Call Home deviates from the one defined in Section 4.7 of [RFC9132]. Section 5.2.1 specifies the behavior to be followed by Call Home DOTS agents.
ドットコールに使用されるハートビートメカニズムは、[RFC9132]のセクション4.7で定義されているものから外れています。セクション5.2.1コールホームドットエージェントが続く動作を指定します。
Once the (D)TLS section is established between the DOTS agents, the Call Home DOTS client contacts the Call Home DOTS server to retrieve the session configuration parameters (Section 4.5 of [RFC9132]). The Call Home DOTS server adjusts the "heartbeat-interval" to accommodate binding timers used by on-path NATs and firewalls. Heartbeats will then be exchanged by the DOTS agents following the instructions retrieved using the signal channel session configuration exchange.
ドットエージェント間で（D）TLSセクションが確立されると、Call Home DotsクライアントはCall Home Dotsサーバーに連絡してセッション構成パラメータを取得します（[RFC9132]のセクション4.5）。呼び出しホームドットサーバは、オンパスNATとファイアウォールで使用されるバインディングタイマに対応するための「ハートビートインターバル」を調整します。その後、ハートビートは、シグナルチャネルセッション構成交換を使用して取得された命令に従ってドットエージェントによって交換されます。
It is the responsibility of Call Home DOTS servers to ensure that on-path translators/firewalls are maintaining a binding so that the same external IP address and/or port number is retained for the DOTS signal channel session. A Call Home DOTS client MAY trigger their heartbeat requests immediately after receiving heartbeat probes from its peer Call Home DOTS server.
コールホームドットサーバーの責任は、On-Pathトランスレータ/ファイアウォールがバインディングを維持していることを保証するための責任です。これにより、同じ外部IPアドレスやポート番号がドット信号チャネルセッションのために保持されます。呼び出しホームドットクライアントは、ピアコールホームドットサーバからハートビートプローブを受信した直後にハートビート要求をトリガすることがあります。
When an outgoing attack that saturates the outgoing link from the Call Home DOTS server is detected and reported by a Call Home DOTS client, the latter MUST continue to use the DOTS signal channel even if no traffic is received from the Call Home DOTS server.
コールホームドットサーバからの発信リンクを飽和させる発信攻撃が、コールホームドットクライアントによって検出され報告された場合、呼び出しホームドットサーバからトラフィックが受信されなくてもドット信号チャネルを使用し続ける必要がある。
If the Call Home DOTS server receives traffic from the Call Home DOTS client, the Call Home DOTS server MUST continue to use the DOTS signal channel even if the threshold of allowed missing heartbeats ("missing-hb-allowed") is reached.
Call Home DotsサーバーがCall Home Dotsクライアントからトラフィックを受信した場合、Call Home Dotsサーバーは、不足しているハートビート（ "Missing-Hb-Allowed"）の閾値に達してもドット信号チャネルを使用する必要があります。
If the Call Home DOTS server does not receive any traffic from the peer Call Home DOTS client during the time span required to exhaust the maximum "missing-hb-allowed" threshold, the Call Home DOTS server concludes the session is disconnected. Then, the Call Home DOTS server MUST try to establish a new DOTS signal channel session, preferably by resuming the (D)TLS session.
コールホームドットサーバがピアコールホームドットクライアントからのトラフィックを受信しない場合、最大の「Missing-HB-Allowed」しきい値を消費するのに必要な期間中に、コールホームドットサーバはセッションが切断されたと結論付けられます。次に、コールホームドットサーバは、（D）TLSセッションを再開することによって、新しいドット信号チャネルセッションを確立しようとする必要があります。
A Call Home DOTS server MUST NOT support the redirected signaling mechanism as specified in Section 4.6 of [RFC9132] (i.e., a 5.03 response that conveys an alternate DOTS server's Fully Qualified Domain Name (FQDN) or IP address(es)). A Call Home DOTS client MUST silently discard such a message as only a Call Home DOTS server can initiate a new (D)TLS connection.
Call Home Dots Serverは、[RFC9132]のセクション4.6で指定されているリダイレクトシグナリングメカニズムをサポートしてはいけません（すなわち、代替ドットサーバの完全修飾ドメイン名（FQDN）またはIPアドレスを伝達する5.03回答）。Call Home Dotsクライアントは、Call Home Dotsサーバーのみが新しい（D）TLS接続を開始できるため、そのようなメッセージを黙って破棄する必要があります。
If a Call Home DOTS client wants to redirect a Call Home DOTS server to another Call Home DOTS client, it MUST send a Non-confirmable PUT request to the predefined resource ".well-known/dots/redirect" with the following attributes in the body of the PUT request:
呼び出しホームドットクライアントが、呼び出しホームドットサーバーを別のコールホームドットクライアントにリダイレクトしたい場合は、次の属性を持つ定義済みのリソース ".well既知/ドット/リダイレクト"に、予め定義されたリソース ".well既知/ドット/リダイレクト"に送信する必要があります。PUTリクエストの本文：
alt-ch-client: The FQDN of an alternate Call Home DOTS client. It is also presented as a reference identifier for authentication purposes.
ALT-CH-Client：代替呼び出しホームドットクライアントのFQDN。認証目的のための参照識別子としても表示されます。
This is a mandatory attribute for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations.
これは、ドット信号Call Homeの必須属性です。基本ドット信号チャネル操作には使用しないでください。
alt-ch-client-record: List of IP addresses for the alternate Call Home DOTS client. If no "alt-ch-client-record" is provided, the Call Home DOTS server passes the "alt-ch-client" name to a name resolution library to retrieve one or more IP addresses of the alternate Call Home DOTS client.
ALT-CH-Client-Record：代替呼び出しホームドットクライアントのIPアドレスの一覧。"Alt-Ch-Client-Record"が提供されていない場合、Call Home Dots Serverは "Alt-Ch-Client"という名前を名前解決ライブラリに渡して、代替呼び出しホームドットクライアントの1つ以上のIPアドレスを取得します。
This is an optional attribute for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations.
これは、ドット信号Call Homeのオプションの属性です。基本ドット信号チャネル操作には使用しないでください。
ttl: The Time To Live (TTL) of the alternate Call Home DOTS client. That is, the time interval in which the alternate Call Home DOTS client may be cached for use by a Call Home DOTS server.
TTL：代替呼び出しホームドットクライアントのライブ（TTL）の時間。すなわち、代替呼び出しホームドットクライアントが呼び出しホームドットサーバによる使用のためにキャッシュされ得る時間間隔。
This is an optional attribute for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations.
これは、ドット信号Call Homeのオプションの属性です。基本ドット信号チャネル操作には使用しないでください。
On receipt of this PUT request, the Call Home DOTS server responds with a 2.01 (Created), closes this connection, and establishes a connection with the new Call Home DOTS client. The processing of the TTL is defined in Section 4.6 of [RFC9132]. If the Call Home DOTS server cannot service the PUT request, the response is rejected with a 4.00 (Bad Request).
このPUTリクエストを受信すると、呼び出しホームドットサーバは2.01（作成）で応答し、この接続を閉じ、新しいコールホームドットクライアントとの接続を確立します。TTLの処理は[RFC9132]のセクション4.6で定義されています。Call Home Dots ServerがPUTリクエストを処理できない場合、応答は4.00（不良要求）で拒否されます。
Figure 9 shows a PUT request example to convey the alternate Call Home DOTS client "alt-call-home-client.example" together with its IP addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of this alternate Call Home DOTS client is 10 minutes.
図9は、代替コールホームドットクライアント「ALT-CALL-HOME-CLIENT.EXAMPLE」をそのIPアドレス2001とともに伝えるためのPUTリクエスト例を示しています.DB8：6401 :: 2。この代替呼び出しホームドットクライアントの有効性は10分です。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "redirect"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:redirected-signal": {
"ietf-dots-call-home:alt-ch-client":
"alt-call-home-client.example",
"ietf-dots-call-home:alt-ch-client-record": [
"2001:db8:6401::1",
"2001:db8:6401::2"
],
"ietf-dots-call-home:ttl": 600
}
Figure 9: Example of a PUT Request for Redirected Signaling
図9：リダイレクトシグナリングのPUTリクエストの例
Figure 9 uses the JSON encoding of YANG-modeled data for the CoAP message body. The same encoding is used in Figure 10 (Section 5.3.1).
図9は、COAPメッセージ本文のYangモデルデータのJSONエンコーディングを使用しています。図10（5.3.1項）では同じ符号化が使用されています。
This specification extends the mitigation request defined in Section 4.4.1 of [RFC9132] to convey the attack source information (e.g., source prefixes, source port numbers). The DOTS client conveys the following new parameters in the Concise Binary Object Representation (CBOR) body of the mitigation request:
この仕様は、[RFC9132]のセクション4.4.1で定義されている緩和要求を拡張して、攻撃元の情報（例えば、ソースプレフィックス、送信元ポート番号）を伝達します。DOTSクライアントは、緩和要求の簡潔なバイナリオブジェクト表現（CBOR）本体で次の新しいパラメータを伝えます。
source-prefix: A list of attacker IP prefixes used to attack the target. Prefixes are represented using Classless Inter-Domain Routing (CIDR) notation (BCP 122 [RFC4632]).
source-prefix：ターゲットを攻撃するために使用される攻撃者IPプレフィックスのリスト。プレフィックスは、クラスレス間ドメイン間ルーティング（CIDR）表記法（BCP 122 [RFC4632]）を使用して表されます。
As a reminder, the prefix length MUST be less than or equal to 32 (or 128) for IPv4 (or IPv6).
リマインダーとして、プレフィックス長はIPv4（またはIPv6）の32（または128）以下でなければなりません。
The prefix list MUST NOT include broadcast, loopback, or multicast addresses. These addresses are considered invalid values. Note that link-local addresses are allowed. The Call Home DOTS client MUST validate that attacker prefixes are within the scope of the Call Home DOTS server domain (e.g., prefixes assigned to the Call Home DOTS server domain or networks it services). This check is meant to avoid contacting Call Home DOTS servers that are not entitled to enforce actions on specific prefixes.
プレフィックスリストには、ブロードキャスト、ループバック、またはマルチキャストアドレスを含めてはいけません。これらのアドレスは無効な値と見なされます。リンクローカルアドレスが許可されていることに注意してください。呼び出しホームドットクライアントは、攻撃者のプレフィックスがCall Home Dots Serverドメインの範囲内（例えば、Call Home Dots Serverドメインに割り当てられているプレフィックスまたはネットワークITサービス）の範囲内であることを検証する必要があります。このチェックは、特定のプレフィックス上でアクションを強制する権利がない呼び出しホームドットサーバーへの連絡を回避するためのものです。
This is an optional attribute for the base DOTS signal channel operations.
これは、ベースドット信号チャネル操作のオプションの属性です。
source-port-range: A list of port numbers used by the attack traffic flows.
source-port-range：攻撃トラフィックフローによって使用されるポート番号のリスト。
A port range is defined by two bounds, a lower port number ("lower-port") and an upper port number ("upper-port"). When only "lower-port" is present, it represents a single port number.
ポート範囲は、2つの範囲、低いポート番号（「下位ポート」）と上位ポート番号（「上位ポート」）で定義されています。「低ポート」のみが存在する場合は、単一のポート番号を表します。
For TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4340], a range of ports can be any subrange of 0-65535 -- for example, 0-1023, 1024-65535, or 1024-49151.
TCP、UDP、Stream Control Transmission Protocol（SCTP）[RFC4960]、またはデータグラム輻輳制御プロトコル（DCCP）[RFC4340]、範囲のポートは0~65535の任意のサブレンジです。たとえば、0-1023,1024-65535、または1024-49151。
This is an optional attribute for the base DOTS signal channel operations.
これは、ベースドット信号チャネル操作のオプションの属性です。
source-icmp-type-range: A list of ICMP types used by the attack traffic flows. An ICMP type range is defined by two bounds, a lower ICMP type (lower-type) and an upper ICMP type (upper-type). When only "lower-type" is present, it represents a single ICMP type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are supported. Whether ICMP or ICMPv6 types are to be used is determined by the address family of the "target-prefix".
source-icmp-type-range：攻撃トラフィックフローによって使用されるICMP型のリスト。ICMPタイプの範囲は、2つの範囲、低いICMPタイプ（下段）と上限ICMPタイプ（上部タイプ）によって定義されます。「下型」のみが存在する場合は、単一のICMPタイプを表します。ICMP [RFC0792]とICMPv6 [RFC4443]タイプの両方がサポートされています。ICMPまたはICMPv6型を使用するかどうかは、「ターゲットプレフィックス」のアドレスファミリによって決まります。
This is an optional attribute for the base DOTS signal channel operations.
これは、ベースドット信号チャネル操作のオプションの属性です。
The "source-prefix" parameter is a mandatory attribute when the attack traffic information is signaled by a Call Home DOTS client (i.e., the Call Home scenario depicted in Figure 8). The "target-prefix" attribute MUST be included in the mitigation request signaling the attack information to a Call Home DOTS server. The "target-uri" or "target-fqdn" parameters can be included in a mitigation request for diagnostic purposes to notify the Call Home DOTS server domain administrator but SHOULD NOT be used to determine the target IP addresses. "alias-name" is unlikely to be conveyed in a Call Home mitigation request given that a target may be any IP resource and that there is no incentive for a Call Home DOTS server (embedded, for example, in a CPE) to maintain aliases.
"source-prefix"パラメータは、攻撃トラフィック情報がCall Home Dotsクライアント（すなわち、図8に示すコールホームシナリオ）によってシグナリングされている場合の必須の属性です。"target-prefix"属性は、攻撃情報をCall Home Dotsサーバーにシグナリングする軽減要求に含める必要があります。"target-uri"または "target-fqdn"パラメータは、コールホームドットサーバードメイン管理者に通知するために診断目的の軽減要求に含めることができますが、ターゲットIPアドレスを決定するために使用しないでください。「エイリアス名」は、ターゲットが任意のIPリソースである可能性があり、エイリアスを維持するためにターゲットが任意のIPリソースである可能性があり、呼び出しホームドットサーバ（例えば、CPE内に埋め込まれた）にはインセンティブがないことがわかっていない。。
In order to help attack source identification by a Call Home DOTS server, the Call Home DOTS client SHOULD include in its mitigation request additional information such as "source-port-range" or "source-icmp-type-range" to disambiguate nodes sharing the same "source-prefix". IPv6 addresses/prefixes are sufficient to uniquely identify a network endpoint, without need for port numbers or ICMP type information. While this is also possible for IPv4, it is much less often the case than for IPv6. More address sharing implications on the setting of source information ("source-prefix", "source-port-range") are discussed in Section 5.3.2.
コールホームドットサーバによる攻撃ソースの識別を助けるために、コールホームドットクライアントは、ノード共有を曖昧させるための「ソース - ポート範囲」または「source-icmp型範囲」などの追加情報を緩和する必要があります。同じ "source-prefix"。IPv6アドレス/プレフィックスは、ポート番号またはICMPタイプの情報を必要とせずに、ネットワークエンドポイントを一意に識別するのに十分です。これはIPv4の場合も可能ですが、IPv6よりもはるかに頻繁ではありません。より多くのアドレス共有の影響ソース情報の設定（ "source-prefix"、 "source-port-range"）の意味については、5.3.2項で説明します。
Only immediate mitigation requests (i.e., "trigger-mitigation" set to "true") are allowed; Call Home DOTS clients MUST NOT send requests with "trigger-mitigation" set to "false". Such requests MUST be discarded by the Call Home DOTS server with a 4.00 (Bad Request).
即時緩和要求のみ（すなわち、「TRUE」に設定されている）は許可されている。呼び出しホームドットクライアントは、「Trigger-ittigation」を「false」に設定して要求を送信してはいけません。そのような要求は、Call Home Dots Serverが4.00（不良要求）によって破棄されなければなりません。
An example of a mitigation request sent by a Call Home DOTS client is shown in Figure 10.
コールホームドットクライアントによって送信された緩和要求の例を図10に示す。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=56"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:c000::/128"
],
"ietf-dots-call-home:source-prefix": [
"2001:db8:123::1/128"
],
"lifetime": 3600
}
]
}
}
Figure 10: An Example of a Mitigation Request Issued by a Call Home DOTS Client
図10：コールホームドットクライアントによって発行された緩和要求の例
The Call Home DOTS server MUST check that the "source-prefix" is within the scope of the Call Home DOTS server domain. Note that in a DOTS Call Home scenario, the Call Home DOTS server considers, by default, that any routable IP prefix enclosed in "target-prefix" is within the scope of the Call Home DOTS client. Invalid mitigation requests are handled as per Section 4.4.1 of [RFC9132].
呼び出しホームドットサーバーは、 "source-prefix"が呼び出しホームドットサーバードメインの範囲内にあることを確認する必要があります。コールホームドットサーバーは、ドットコールホームシナリオで、「ターゲットプレフィックス」で囲まれたルーティング可能なIPプレフィックスがCall Home Dotsクライアントの範囲内にあると考えています。無効な緩和要求は、[RFC9132]のセクション4.4.1に従って処理されます。
Note: These validation checks do not apply when the source information is included as a hint in the context of the base DOTS signal channel.
注：ソース情報がベースドット信号チャネルのコンテキスト内のヒントとして含まれている場合、これらの検証チェックは適用されません。
Call Home DOTS server domain administrator consent MAY be required to block the traffic from the compromised device to the attack target. An implementation MAY have a configuration knob to block the traffic from the compromised device to the attack target with or without DOTS server domain administrator consent.
呼び出しホームドットサーバードメイン管理者の同意は、侵入先のデバイスから攻撃対象へのトラフィックをブロックするために必要な場合があります。実装は、ドットサーバドメイン管理者の同意の有無にかかわらず、侵入先デバイスから攻撃対象へのトラフィックをブロックするための構成ノブを有することができる。
If consent from the Call Home DOTS server domain administrator is required, the Call Home DOTS server replies with 2.01 (Created) and the "status" code set to 1 (attack-mitigation-in-progress). Then, the mechanisms defined in Section 4.4.2 of [RFC9132] are followed by the DOTS agents to update the mitigation status. In particular, if the attack traffic is blocked, the Call Home DOTS server informs the Call Home DOTS client that the attack is being mitigated (i.e., by setting the "status" code to 2 (attack-successfully-mitigated)).
Call Home Dots Server Domain管理者からの同意が必要な場合は、Call Home Dots Serverは2.01（作成）と「ステータス」コードが1に設定されている（攻撃軽減）。その後、[RFC9132]のセクション4.4.2で定義されているメカニズムの後にドットエージェントが続き、軽減ステータスが更新されます。特に、攻撃トラフィックがブロックされている場合、コールホームドットサーバは、攻撃が軽減されていること（すなわち、「ステータス」コードを2に設定すること（攻撃成功））。
If the attack traffic information is identified by the Call Home DOTS server or the Call Home DOTS server domain administrator as legitimate traffic, the mitigation request is rejected with a 4.09 (Conflict) (e.g., when no consent is required from an administrator) or a notification message with the "conflict-clause" (Section 4.4.1 of [RFC9132]) set to the following new value:
攻撃トラフィック情報がCall Home Dots ServerまたはCall Home Dots Serverドメイン管理者によって正当なトラフィックとして識別された場合、緩和要求は4.09（競合）（例えば、管理者からの同意がない場合など）または"conflict-句"（[RFC9132]のセクション4.4.1）を使用した通知メッセージ：次の新しい値に設定します。
4: Mitigation request rejected. This code is returned by the DOTS server to indicate the attack traffic has been classified as legitimate traffic.
4：緩和要求が拒否されました。このコードは、攻撃トラフィックが正当なトラフィックとして分類されていることを示すためにドットサーバーによって返されます。
Once the request is validated by the Call Home DOTS server, appropriate actions are enforced to block the attack traffic within the source network. For example, if the Call Home DOTS server is embedded in a CPE, it can program the packet processor to punt all the traffic from the compromised device to the target to slow path. The CPE inspects the punted slow path traffic to detect and block the outgoing DDoS attack traffic or quarantine the device (e.g., using MAC-level filtering) until it is remediated and notifies the CPE administrator about the compromised device. Note that the Call Home DOTS client is informed about the progress of the attack mitigation following the rules in Section 4.4.2 of [RFC9132].
コールホームドットサーバーによって要求が検証されると、ソースネットワーク内の攻撃トラフィックをブロックするために適切なアクションが適用されます。たとえば、Call Home DotsサーバーがCPEに埋め込まれている場合、それはパケットプロセッサをプログラムして、侵入先のデバイスからターゲットへのすべてのトラフィックを遅いパスにパントするようにプログラムできます。CPEは、発信されたDDOS攻撃トラフィックを検出してブロックして、それが修正されるまで（例えば、MACレベルフィルタリングを使用して）、CPE管理者に侵入先デバイスについて通知するために、パントされたスローパストラフィックを検査します。[RFC9132]のセクション4.4.2の規則に従って、コールホームドットクライアントは攻撃軽減の進行状況について知らされていることに注意してください。
The DOTS agents follow the same procedures specified in [RFC9132] for managing a mitigation request.
ドットエージェントは、緩和要求を管理するために[RFC9132]で指定された同じ手順に従います。
Figure 11 depicts an example of a network provider that hosts a Call Home DOTS client and deploys a Carrier-Grade NAT (CGN) between the DOTS client domain and DOTS server domain. In such cases, communicating an external IP address in a mitigation request by a Call Home DOTS client is likely to be discarded by the Call Home DOTS server because the external IP address is not visible locally to the Call Home DOTS server (Figure 11). The Call Home DOTS server is only aware of the internal IP addresses/prefixes bound to its domain (i.e., those used in the internal realm shown in Figure 11). Thus, Call Home DOTS clients that are aware of the presence of on-path CGNs MUST NOT include the external IP address and/or port number identifying the suspect attack source (i.e., those used in the external realm shown in Figure 11) but MUST include the internal IP address and/or port number. To that aim, the Call Home DOTS client SHOULD rely on mechanisms, such as those described in [RFC8512] or [RFC8513], to retrieve the internal IP address and port number that are mapped to an external IP address and port number. For the particular case of NAT64 [RFC6146], if the target address is an IPv4 address, the IPv4-converted IPv6 address of this target address [RFC6052] SHOULD be used.
図11は、コールホームドットクライアントをホストし、ドットクライアントドメインとドットサーバドメイン間のキャリアグレードNAT（CGN）を展開するネットワークプロバイダの例を示す。そのような場合、外部IPアドレスがコールホームドットサーバーにローカルに表示されないため、コールホームドットクライアントによる軽減要求で外部IPアドレスを通信する可能性が高いです（図11）。呼び出しホームドットサーバは、そのドメインにバインドされている内部IPアドレス/プレフィックス（すなわち、図11に示す内部レルムで使用されているもの）を認識しています。したがって、オンパスCGNの存在を認識しているホームドットクライアントを呼び出す必要がありますが、容疑者攻撃源を識別する外部IPアドレスやポート番号（すなわち、図11に示す外部レルムで使用されているもの）を含めてはいけません内部IPアドレスおよび/またはポート番号を含めます。その目的のために、コールホームドットクライアントは、[RFC8512]または[RFC8513]に記載されているようなメカニズムに依存して、外部IPアドレスとポート番号にマッピングされている内部IPアドレスとポート番号を取得する必要があります。 NAT64 [RFC6146]の特定のケースでは、ターゲットアドレスがIPv4アドレスの場合、このターゲットアドレス[RFC6052]のIPv4変換IPv6アドレスを使用する必要があります。
N | .-------------------.
E | ( )-.
T | .' '
W | ( Call Home )
O | ( DOTS client -'
R | '-( )
K | '-------+-----------'
| |
P | |
R | +---+---+
O | | CGN | External Realm
V |..............| |......................
I | | | Internal Realm
D | +---+---+
E | |
R | |
--- |
.---------+---------.
( )-.
.' Source Network '
( )
( Call Home -'
'-( DOTS server )
'------+------------'
|
+-----+-------+
|Attack Source|
+-------------+
Figure 11: Example of a CGN between DOTS Domains
図11：ドットドメイン間のCGNの例
If a Mapping of Address and Port (MAP) Border Relay [RFC7597] or Lightweight Address Family Transition Router (lwAFTR) [RFC7596] is enabled in the provider's domain to service its customers, the identification of an attack source bound to an IPv4 address/prefix MUST also rely on source port numbers because the same IPv4 address is assigned to multiple customers. The port information is required to unambiguously identify the source of an attack.
Providerのドメインでアドレスとポート（マップ）ボーダーリレー[RFC7597]またはLWAFTRのアドレスの遷移ルータ（LWAF7596]のマッピングが有効になっている場合は、プロバイダーのドメインで、IPv4アドレスにバインドされている攻撃ソースの識別が有効になっています。同じIPv4アドレスが複数の顧客に割り当てられているため、プレフィックスも送信元ポート番号に依存する必要があります。ポート情報は、攻撃の原因を明確に識別するために必要です。
If a translator is enabled on the boundaries of the domain hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in Figures 12 and 13), the Call Home DOTS server uses the attack traffic information conveyed in a mitigation request to find the internal source IP address of the compromised device and blocks the traffic from the compromised device traffic to the attack target until the mitigation request is withdrawn. The Call Home DOTS server proceeds with a NAT mapping table lookup using the attack information (or a subset thereof) as a key. The lookup can be local (Figure 12) or via a dedicated administration interface that is offered by the CPE (Figure 13). This identification allows the suspicious device to be isolated while avoiding disturbances of other services.
コールホームドットサーバをホストしているドメインの境界でトランスレータが有効になっている場合（例えば、図12および図13に示すようにNATが有効になっているCPE）、呼び出しホームドットサーバは、緩和要求で伝達された攻撃トラフィック情報を使用する。妥協されたデバイスの内部送信元IPアドレスを見つけ、軽減の要求が引き出されるまで、侵入先のデバイストラフィックから攻撃対象へのトラフィックをブロックします。呼び出しホームドットサーバーは、攻撃情報（またはそのサブセット）をキーとして使用してNATマッピングテーブルルックアップを進めます。ルックアップはローカル（図12）またはCPEによって提供される専用の管理インターフェイスを介して（図13）。この識別により、他のサービスの妨害を回避しながら、疑わしい装置を分離することができます。
.-------------------.
( )-.
.' Network Provider (DMS)'
( )
( Call Home -'
'-( DOTS client )
'-------+-----------'
|
--- +---+---+
S | | CPE | External Realm
O |..............| |................
U | | NAT | Internal Realm
R | +---+---+
C | |
E | .---------+---------.
| ( )-.
N | .' '
E | ( Call Home )
T | ( DOTS server -'
W | '-( )
O | '-------+-----------'
R | |
K | +------+------+
| |Attack Source|
+-------------+
Figure 12: Example of a DOTS Server Domain with a NAT Embedded in a CPE
図12：CPEに埋め込まれたNATを持つドットサーバードメインの例
.-------------------.
( )-.
.' Network Provider (DMS) '
( )
( Call Home -'
'-( DOTS client )
'---------+---------'
|
--- +-----+-----+
S | | CPE/NAT | External Realm
O |..............| |................
U | | Call Home | Internal Realm
R | |DOTS server|
C | +-----+-----+
E | |
| .-----------+-------.
| ( )-.
N | .' '
E | ( Local Area Network )
T | ( -'
W | '-( )
O | '--------+----------'
R | |
K | +------+------+
| |Attack Source|
+-------------+
Figure 13: Example of a Call Home DOTS Server and a NAT Embedded in a CPE
図13：Call Home DotsサーバーとCPEに埋め込まれたNATの例
If, for any reason, address sharing is deployed in both source and provider networks, both Call Home DOTS agents have to proceed with address mapping lookups following the behavior specified in reference to Figure 11 (network provider) and Figures 12 and 13 (source network).
何らかの理由で、アドレス共有がソースネットワークとプロバイダネットワークの両方にデプロイされている場合、両方のコールホームドットエージェントは、図11（ネットワークプロバイダ）および図12および13（ソースネットワーク）を参照して指定された動作に続くアドレスマッピング検索を続行する必要があります。）。
This document augments the "ietf-dots-signal-channel" (dots-signal) DOTS signal YANG module defined in [RFC9132] for signaling the attack traffic information. This document defines the YANG module "ietf-dots-call-home", which has the following tree structure:
この文書は、[RFC9132]で定義されている「IETF - DOTS - 信号チャネル」（DOTS - 信号）のドット信号YANGモジュールを拡張して、攻撃交通情報をシグナリングするために拡大する。この文書は、次のツリー構造を持つYANGモジュール「IETF-DOTS-CALL-HOME」を定義します。
module: ietf-dots-call-home
モジュール：IETF-DOTS-Call-home
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope:
+-- source-prefix* inet:ip-prefix
+-- source-port-range* [lower-port]
| +-- lower-port inet:port-number
| +-- upper-port? inet:port-number
+-- source-icmp-type-range* [lower-type]
+-- lower-type uint8
+-- upper-type? uint8
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:redirected-signal:
+-- (type)?
+--:(call-home-only)
+-- alt-ch-client inet:domain-name
+-- alt-ch-client-record* inet:ip-address
+-- ttl? uint32
The YANG/JSON mapping parameters to CBOR are listed in Table 1.
CBORへのYang / JSONマッピングパラメータを表1に示します。
Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the content of Table 1.
注：実装者は、Yang-To-CBOR符号化方式によって提供されたマッピング出力が表1の内容と整列していることを確認する必要があります。
+========================+=============+=====+=============+========+
|Parameter Name |YANG Type |CBOR |CBOR Major | JSON |
| | |Key |Type & | Type |
| | |Value|Information | |
+========================+=============+=====+=============+========+
|ietf-dots-call- |leaf-list |32768|4 array | Array |
|home:source-prefix |inet:ip- | |3 text string| String |
| |prefix | | | |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call- |list |32769|4 array | Array |
|home:source-port-range | | | | |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call- |list |32770|4 array | Array |
|home:source-icmp-type- | | | | |
|range | | | | |
+------------------------+-------------+-----+-------------+--------+
|lower-type |uint8 |32771|0 unsigned | Number |
+------------------------+-------------+-----+-------------+--------+
|upper-type |uint8 |32772|0 unsigned | Number |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-home:alt-|inet: domain-|32773|3 text string| String |
|ch-client |name | | | |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-home:alt-|leaf-list |32774|4 array | Array |
|ch-client-record |inet:ip- | |3 text string| String |
| |address | | | |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-home:ttl |uint32 |32775|0 unsigned | Number |
+------------------------+-------------+-----+-------------+--------+
Table 1: YANG/JSON Mapping Parameters to CBOR
表1：CBORへのヤン/ JSONマッピングパラメータ
The YANG/JSON mappings to CBOR for "lower-port" and "upper-port" are already defined in Table 5 of [RFC9132].
"Lower-Port"と "Upper-Port"のCBORのYang / JSONマッピングは、[RFC9132]の表5にすでに定義されています。
This module uses the common YANG types defined in [RFC6991] and the data structure extension defined in [RFC8791].
このモジュールは[RFC6991]で定義されている一般的なYANTタイプと[RFC8791]で定義されているデータ構造拡張です。
<CODE BEGINS> file "ietf-dots-call-home@2021-12-09.yang"
module ietf-dots-call-home {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
prefix dots-call-home;
import ietf-inet-types {
prefix inet;
reference
"Section 4 of RFC 6991";
}
import ietf-dots-signal-channel {
prefix dots-signal;
reference
"RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Konda, Tirumaleswar Reddy
<mailto:kondtir@gmail.com>;
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>;
Author: Jon Shallow <mailto:ietf-supjps@jpshallow.com>"; description "This module contains YANG definitions for the signaling messages exchanged between a DOTS client and a DOTS server for the Call Home deployment scenario.
著者：Jon Shallow <mailto：ietf-supjps@jpshallow.com> "; description"このモジュールには、コールホーム展開シナリオのドットクライアントとドットサーバーとの間で交換されるシグナリングメッセージのYANG定義が含まれています。
Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（C）2021 IETF信頼とコードの著者として識別された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
修正の有無にかかわらず、ソースおよびバイナリフォームでの再配布と使用は、IETFドキュメントに関するIETF文書の法定条項のセクション4.Cに記載されている単純化されたBSDライセンスに準拠しています。http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9066; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンはRFC 9066の一部です。完全な法的通知のためのRFC自体を参照してください。」
revision 2021-12-09 {
description
"Initial revision.";
reference
"RFC 9066: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Call Home";
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:mitigation-scope"
+ "/dots-signal:scope" {
description
"Attack source details.";
leaf-list source-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifying the attack source(s).";
}
list source-port-range {
key "lower-port";
description
"Port range. When only lower-port is
present, it represents a single port number.";
leaf lower-port {
type inet:port-number;
description
"Lower port number of the port range.";
}
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
error-message
"The upper port number must be greater than
or equal to the lower port number.";
}
description
"Upper port number of the port range.";
}
}
list source-icmp-type-range {
key "lower-type";
description
"ICMP/ICMPv6 type range. When only lower-type is
present, it represents a single ICMP/ICMPv6 type.
The address family of the target-prefix is used
to determine whether ICMP or ICMPv6 is used.";
leaf lower-type {
type uint8;
description
"Lower ICMP/ICMPv6 type of the ICMP type range.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification.";
}
leaf upper-type {
type uint8;
must '. >= ../lower-type' {
error-message
"The upper ICMP/ICMPv6 type must be greater than
or equal to the lower ICMP type.";
}
description
"Upper type of the ICMP type range.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification.";
}
}
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:redirected-signal" {
description
"Augments the redirected signal to communicate an
alternate Call Home DOTS client.";
choice type {
description
"Indicates the type of the DOTS session (e.g., base
DOTS signal channel, DOTS Call Home).";
case call-home-only {
description
"These attributes appear only in a signal Call Home
channel message from a Call Home DOTS client
to a Call Home DOTS server.";
leaf alt-ch-client {
type inet:domain-name;
mandatory true;
description
"FQDN of an alternate Call Home DOTS client.
This name is also presented as a reference
identifier for authentication purposes.";
}
leaf-list alt-ch-client-record {
type inet:ip-address;
description
"List of IP addresses for the alternate Call
Home DOTS client.
If this data node is not present, a Call Home
DOTS server resolves the alt-ch-client into
one or more IP addresses.";
}
leaf ttl {
type uint32;
units "seconds";
description
"The Time To Live (TTL) of the alternate Call Home
DOTS client.";
reference
"Section 4.6 of RFC 9132";
}
}
}
}
}
<CODE ENDS>
This specification registers the following comprehension-optional parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
この仕様は、IANA "DOTS信号チャネルCBORキー値"レジストリ[キーマップ]に、次の理解任意のパラメータ（表2）を登録します。
+========================+=======+=======+============+===========+
| Parameter Name | CBOR | CBOR | Change | Reference |
| | Key | Major | Controller | |
| | Value | Type | | |
+========================+=======+=======+============+===========+
| ietf-dots-call- | 32768 | 4 | IESG | RFC 9066 |
| home:source-prefix | | | | |
+------------------------+-------+-------+------------+-----------+
| ietf-dots-call- | 32769 | 4 | IESG | RFC 9066 |
| home:source-port-range | | | | |
+------------------------+-------+-------+------------+-----------+
| ietf-dots-call- | 32770 | 4 | IESG | RFC 9066 |
| home:source-icmp-type- | | | | |
| range | | | | |
+------------------------+-------+-------+------------+-----------+
| lower-type | 32771 | 0 | IESG | RFC 9066 |
+------------------------+-------+-------+------------+-----------+
| upper-type | 32772 | 0 | IESG | RFC 9066 |
+------------------------+-------+-------+------------+-----------+
| ietf-dots-call- | 32773 | 3 | IESG | RFC 9066 |
| home:alt-ch-client | | | | |
+------------------------+-------+-------+------------+-----------+
| ietf-dots-call- | 32774 | 4 | IESG | RFC 9066 |
| home:alt-ch-client- | | | | |
| record | | | | |
+------------------------+-------+-------+------------+-----------+
| ietf-dots-call-home: | 32775 | 0 | IESG | RFC 9066 |
| ttl | | | | |
+------------------------+-------+-------+------------+-----------+
Table 2: Assigned DOTS Signal Channel CBOR Key Values
表2：割り当てられたドット信号チャネルCBOBキー値
Per this document, IANA has assigned a new code from the "DOTS Signal Channel Conflict Cause Codes" registry [Cause].
このドキュメントごとに、IANAは「ドット信号チャネル紛争原因コード」レジストリ[原因]から新しいコードを割り当てました。
+====+=====================================+=============+==========+
|Code| Label |Description |Reference |
+====+=====================================+=============+==========+
|4 | request-rejected-legitimate-traffic |Mitigation |RFC 9066 |
| | |request | |
| | |rejected. | |
| | |This code is | |
| | |returned by | |
| | |the DOTS | |
| | |server to | |
| | |indicate the | |
| | |attack | |
| | |traffic has | |
| | |been | |
| | |classified as| |
| | |legitimate | |
| | |traffic. | |
+----+-------------------------------------+-------------+----------+
Table 3: Assigned DOTS Signal Channel Conflict Cause Code
表3：割り当てられたドット信号チャネルの紛争原因コード
Per this document, IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
このドキュメントごとに、IANAは「IETF XMLレジストリ」内の「NS」サブレジストで次のURIを登録しました[RFC3688]
URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home Registrant Contact: The IETF. XML: N/A; the requested URI is an XML namespace.
URI：URN：IETF：PARAMS：XML：NS：YANG：IETF-DOTS-CALL-HOME登録者連絡先：IETF。XML：n / a;要求されたURIはXMLネームスペースです。
Per this document, IANA has registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry:
この文書によると、IANAは「YANG PARAMETERS」レジストリ内の「Yang Module Names」サブレジスト[RFC6020]に次のYangモジュールを登録しています。
name: ietf-dots-call-home
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
maintained by IANA: N
prefix: dots-call-home
reference: RFC 9066
This document deviates from classic DOTS signal channel usage by having the DOTS server initiate the (D)TLS connection. Security considerations related to the DOTS signal channel discussed in Section 11 of [RFC9132] and (D)TLS early data discussed in Section 7 of [RFC9132] MUST be considered. DOTS agents MUST authenticate each other using (D)TLS before a DOTS signal channel session is considered valid.
このドキュメントは、DOTSサーバーが（D）TLS接続を開始させることによって、古典的なドット信号チャネルの使用法を逸脱します。[RFC9132]のセクション11で論じられているドット信号チャネルに関連するセキュリティ上の考慮事項[RFC9132]のセクション7で説明した初期データを考慮する必要があります。ドットエージェントは、ドット信号チャネルセッションが有効であると見なされる前に（D）TLSを使用して互いに認証しなければなりません。
The Call Home function enables a Call Home DOTS server to be reachable by only the intended Call Home DOTS client. Appropriate filters (e.g., access control lists) can be installed on the Call Home DOTS server and network between the Call Home DOTS agents so that only communications from a trusted Call Home DOTS client to the Call Home DOTS server are allowed. These filters can be automatically installed by a Call Home DOTS server based on the configured or discovered peer Call Home DOTS client(s).
呼び出し元のホーム機能を使用すると、コールホームドットサーバーは、意図されたコールホームドットクライアントのみによって到達可能になります。適切なフィルタ（例えば、アクセス制御リスト）は、コールホームドットエージェント間の呼び出しホームドットサーバおよびネットワークにインストールすることができ、そのため、コールホームドットサーバへの信頼できる呼び出しホームドットクライアントからの通信のみが許可される。これらのフィルタは、設定されたまたは検出されたピアコールのホームドットクライアントに基づいて、呼び出しホームドットサーバーによって自動的にインストールできます。
An attacker may launch a DoS attack on the DOTS client by having it perform computationally expensive operations before deducing that the attacker doesn't possess a valid key. For instance, in TLS 1.3 [RFC8446], the ServerHello message contains a key share value based on an expensive asymmetric key operation for key establishment. Common precautions mitigating DoS attacks are recommended, such as temporarily adding the source address to a drop-list after a set number of unsuccessful authentication attempts.
攻撃者は、攻撃者が有効なキーを持たないことを推測する前に、計算上高価な操作を実行することによって、ドットクライアントにDOS攻撃を開始することがあります。たとえば、TLS 1.3 [RFC8446]では、ServerHelloメッセージには、キー設立のための高価な非対称キー操作に基づく鍵共有値が含まれています。一般的な注意事項の発生回数の後に、ドロップリストに送信元アドレスを一時的に追加するなど、DOS攻撃を軽減することをお勧めします。
The DOTS signal Call Home channel can be misused by a misbehaving Call Home DOTS client by arbitrarily signaling legitimate traffic as being attack traffic or falsifying mitigation signals so that some sources are disconnected or some traffic is rate-limited. Such misbehaving Call Home DOTS clients may include sources identified by IP addresses that are used for internal use only (that is, these addresses are not visible outside a Call Home DOTS server domain). Absent explicit policy (e.g., the Call Home DOTS client and server are managed by the same administrative entity), such requests should be discarded by the Call Home DOTS server. More generally, Call Home DOTS servers should not blindly trust mitigation requests from Call Home DOTS clients. For example, Call Home DOTS servers could use the attack flow information contained in a mitigation request to enable a full-fledged packet inspection function to inspect all the traffic from the compromised device to the target. They could also redirect the traffic from the potentially compromised device to the target towards a DDoS mitigation system that can scrub the suspicious traffic without blindly blocking all traffic from the indicated attack source to the target. Call Home DOTS servers can also seek the consent of the DOTS server domain administrator to block the traffic from the potentially compromised device to the target (see Section 5.3.1). The means to seek consent are implementation specific.
ドット信号呼び出しホームチャネルは、一部のソースが切断されるように正当なトラフィックを任意にシグナリングすることによって、不正確なコールホームドットクライアントを任意にシグナリングすることによって、または緩和信号を改ざんすることによって誤用することができます。そのような不正な誤って呼び出しホームドットクライアントは、内部使用のみに使用されるIPアドレスによって識別されるソースを含み得る（つまり、これらのアドレスは、コールホームドットサーバドメインの外側には見えない）。明示的なポリシーが不在（例えば、呼び出しホームドットクライアントとサーバーは同じ管理エンティティによって管理されています）、そのような要求は呼び出しホームドットサーバーによって破棄されるべきです。より一般的には、コールホームドットサーバは、コールホームドットクライアントから軽減要求を盲目的に信頼するべきではありません。例えば、呼び出しホームドットサーバは、緩和されたパケット検査機能を有効にして、侵入先のデバイスからターゲットへのすべてのトラフィックを調べることを可能にするために緩和要求に含まれる攻撃フロー情報を使用することができる。また、潜在的に侵害されたデバイスからのトラフィックをDDOS軽減システムに向けて、示された攻撃源からターゲットへのすべてのトラフィックを盲目的に遮断することなく、疑わしいトラフィックをスクラブすることができるDDOS軽減システムに向けてリダイレクトすることもできます。コールホームドットサーバーは、潜在的に侵害されたデバイスからターゲットへのトラフィックをブロックするために、ドットサーバードメイン管理者の同意を求めることもできます（セクション5.3.1を参照）。同意を求める手段は実装固有です。
Call Home DOTS agents may interact with on-path address sharing functions to retrieve an internal IP address / external IP address mapping (Section 5.3.2) identifying an attack source. Blocking access or manipulating the mapping information will complicate DDoS attack mitigation close to an attack source. Additional security considerations are specific to the actual mechanism used to access that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of [RFC8513]).
呼び出しホームドットエージェントは、オンパスアドレス共有関数と対話して、内部IPアドレス/外部IPアドレスマッピング（セクション5.3.2）を取得することができます（セクション5.3.2）攻撃ソースを識別します。ブロッキングアクセスまたはマッピング情報の操作は、DDOS攻撃軽減を攻撃源に近づけます。追加のセキュリティ上の考慮事項は、そのマッピングにアクセスするために使用される実際のメカニズムに特有のメカニズムに固有のものです（例えば、[RFC8513]の[RFC8513]のセクション4）。
This document augments YANG data structures that are meant to be used as an abstract representation of DOTS signal channel Call Home messages. As such, the "ietf-dots-call-home" module does not introduce any new vulnerabilities beyond those specified above and in [RFC9132].
この文書は、ドット信号チャネル呼び出しホームメッセージの抽象表現として使用されることを意図しているYangデータ構造を増強する。そのため、 "IETF-dots-call-home"モジュールは、[RFC9132]で指定されたものを超えて新しい脆弱性を導入しません。
The considerations discussed in [RFC6973] were taken into account to assess whether the DOTS Call Home introduces privacy threats.
[RFC6973]で議論された考慮事項は、ドットコールホームがプライバシーの脅威を紹介するかどうかを評価するために考慮されました。
Concretely, the protocol does not leak any new information that can be used to ease surveillance. In particular, the Call Home DOTS server is not required to share information that is local to its network (e.g., internal identifiers of an attack source) with the Call Home DOTS client. Also, the recommended data to be included in Call Home DOTS messages is a subset of the Layer 3 / Layer 4 information that can be learned from the overall traffic flows that exit the Call Home DOTS server domain. Furthermore, Call Home DOTS clients do not publicly reveal attack identification information; that information is encrypted and only shared with an authorized entity in the domain to which the IP address/prefix is assigned, from which an attack was issued.
具体的には、監視を容易にするために使用できる新しい情報をプロトコルに漏らさない。特に、コールホームドットサーバは、コールホームドットクライアントとのネットワーク（例えば、攻撃元の内部識別子）にローカルな情報を共有する必要はない。また、コールホームドットメッセージに含まれる推奨データは、コールホームドットサーバドメインを終了する全体的なトラフィックフローから学習できるレイヤ3 /レイヤ4の情報のサブセットである。さらに、呼び出しホームドットクライアントは攻撃識別情報を公に公示していない。その情報は暗号化され、IPアドレス/プレフィックスが割り当てられているドメイン内の許可されたエンティティとのみ共有され、そこから攻撃が発行されました。
The DOTS Call Home does not preclude the validation of mitigation requests received from a Call Home DOTS client. For example, a security service running on the CPE may require an administrator's consent before the CPE acts upon the mitigation request indicated by the Call Home DOTS client. How the consent is obtained is out of scope of this document.
ドットコールホームは、呼び出しホームドットクライアントから受信した緩和要求の検証を排除しません。たとえば、CPE上で実行されているセキュリティサービスは、CPEがCall Home Dotsクライアントが示す緩和要求に役立つ前に管理者の同意を要求することがあります。同意が得られるのはこの文書の範囲外です。
Note that a Call Home DOTS server can seek an administrator's consent, validate the request by inspecting the relevant traffic for attack signatures, or proceed with both courses of action.
呼び出しホームドットサーバーは管理者の同意を求めることができ、攻撃シグネチャの関連トラフィックを検査するか、または両方の行動コースを進めることで、要求を検証することができます。
The DOTS Call Home is only advisory in nature. Concretely, the DOTS Call Home does not impose any action to be enforced within the network hosting an attack source; it is up to the Call Home DOTS server (and/or network administrator) to decide whether and which actions are required.
ドットコールホームは本質的に勧めているだけです。具体的には、ドットコールホームは攻撃源をホストしているネットワーク内で強制されるべき行動を課しません。どのアクションが必要かどうかを決定するのは、コールホームドットサーバー（および/またはネットワーク管理者）次第です。
Moreover, the DOTS Call Home avoids misattribution by appropriately identifying the network to which a suspect attack source belongs (e.g., address sharing issues discussed in Section 5.3.1).
さらに、ドットコールホームは、疑わしい攻撃ソースが属するネットワークを適切に識別することによって（例えば、セクション5.3.1で説明されているアドレス共有の問題）。
Triggers to send a DOTS mitigation request to a Call Home DOTS server are deployment specific. For example, a Call Home DOTS client may rely on the output of some DDoS detection systems (flow exports or similar functions) deployed within the DOTS client domain to detect potential outbound DDoS attacks or may rely on abuse claims received from remote victim networks. These systems may be misused to track users and infer their activities. Such misuses are not required to achieve the functionality defined in this document (that is, protect the Internet and avoid altering the IP reputation of source networks). It is out of the scope to identify privacy threats specific to given attack detection technology. The reader may refer, for example, to Section 11.8 of [RFC7011].
コールホームドットサーバーにドット軽減要求を送信するためのトリガーは展開固有です。たとえば、コールホームドットクライアントは、ドットクライアントドメイン内に配置されたいくつかのDDOS検出システム（フローエクスポートまたは類似の機能）の出力に依存して、潜在的なアウトバウンドDDOS攻撃を検出したり、リモートの被害者ネットワークから受信した不正行為の主張に依存している可能性があります。これらのシステムは、ユーザーを追跡し、その活動を推測するように誤用されることがあります。このような誤解は、この文書で定義されている機能を達成する必要はありません（つまり、インターネットを保護し、ソースネットワークのIPレピュテーションの変更を避けます）。与えられた攻撃検出技術に特有のプライバシーの脅威を特定するのは範囲外です。リーダは、例えば、[RFC7011]の第11.8項を参照することができる。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[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、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M.、 "IETF XML Registry"、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https：//www.rfc-editor.org/info/rfc3688>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S、およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M.、Ed。、 "Yang - ネットワーク構成プロトコルのデータモデリング言語（NetConf）"、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-編集者。org / info / rfc6020>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.
[RFC6052] BAO、C、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX.Li、「IPv4 / IPv6翻訳者のIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、<https://www.rfc-editor.org/info/rfc6052>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P.、I。van Beijnum、「IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https：//www.rfc-editor.org/info/rfc6146>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E.およびN. ModAdugu、「データグラムトランスポート層セキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。
[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>。
[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、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8791] Bierman、A.、Björklund、M.、K。Watsen、「Yang Data Struction Extensions」、RFC 8791、DOI 10.17487 / RFC8791、2020年6月、<https://www.rfc-editor.org/info/ RFC8791>。
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, <https://www.rfc-editor.org/info/rfc9132>.
[RFC9132] Boucadair、M.、Ed。、浅い、J.、およびT.Reddy.k、「分散サービス拒否オープン脅威シグナリング（ドット）信号チャネル仕様」、RFC 9132、DOI 10.17487 / RFC9132、9月2021、<https://www.rfc-editor.org/info/rfc9132>。
[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", <https://www.iana.org/assignments/dots/>.
[原因] IANA、「ドット信号チャネル紛争原因コード」、<https：//www.iana.org/assignments/dots/>。
[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-09, 2 December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-09>.
[DOT-MULTIHOMING] Boucadair、M.、Reddy、T.、およびW. Pan、「配布拒否オープン脅威シグナルシグナル（ドット）」の「マルチホーミング展開上の考慮事項」、進捗状況、インターネットドラフト、draft-ietf-dots-multihoming-09,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-09>。
[DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-43, 30 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>.
[DTLS13] Rescorla、E.、Tschofenig、H.、およびN. MODADUGU、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、Draft-IETF-TLS-DTLS13-43、2021年4月30日、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>。
[I2NSF-TERMS] Hares, S., Strassner, J., Lopez, D. R., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", Work in Progress, Internet-Draft, draft-ietf-i2nsf-terminology-08, 5 July 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-terminology-08>.
[I2NSF-TOLSS] HARES、S、STRASSNER、J。、Lopez、DR、XIA、L.、H.Birkholz、「ネットワークセキュリティ機能へのインタフェース（I2NSF）用語」、進行中、インターネットドラフト、ドラフト-ietf-i2nsf-terminology-08,2019,57月5日、<https：//datatracker.ietf.org/doc/html/draft-ietf-i2nsf-terminology-08>。
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", <https://www.iana.org/assignments/dots/>.
[キーマップ] IANA、「ドット信号チャネルCBORキー値」、<https：//www.iana.org/assignments/dots/>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] SRISERSH、P、およびM.OLSERGE、「IPネットワークアドレストランスレータ（NAT）用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<https：//www.rfc-editor.org/info/ RFC2663>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M.およびS. Floyd、「データグラム輻輳制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<https：//www.rfc-編集者。ORG / INFO / RFC4340>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V.およびT.LI、「クラスレスドメイン間ルーティング（CIDR）：インターネットアドレス割り当てと集約計画」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<https：//www.rfc-editor.org/info/rfc4632>。
[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>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R.、 "Internet Security Glossary、バージョン2"、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<https：//www.rfc-editor.org/info/rfc4949>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6398] Le Faucheur、F.、ED。、「IP Router Alertの考慮と使用方法」、BCP 168、RFC 6398、DOI 10.17487 / RFC6398、2011年10月、<https：//www.rfc-editor.org/info/RFC6398>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルに関するプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B.、ED。、Trammell、B.、ED。、「フロー情報交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、DOI 10.17487 / RFC7011、2013年9月、<https：//www.rfc-editor.org/info/rfc7011>。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7596] CUI、Y.、Sun、Q.、Boucadair、M.、T.、T.、Lee、Y.、およびI。Farrer、 "Lightweight 4Over6：デュアルスタックライトアーキテクチャへの拡張"、RFC 7596、DOI 10.17487 / RFC7596、2015年7月、<https：//www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、ED、DEC、W.、LI、X、BAO、C、松島、S、村上、T.、およびT。Taylor、「アドレスとポートのマッピング」カプセル化（MAP-E） "、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<https：//www.rfc-editor.org/info/rfc7597>。
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", RFC 8071, DOI 10.17487/RFC8071, February 2017, <https://www.rfc-editor.org/info/rfc8071>.
[RFC8071] Watsen、K.、 "NetConf Call Home and Restconf Call Home"、RFC 8071、DOI 10.17487 / RFC8071、2017年2月、<https：//www.rfc-editor.org/info/rfc8071>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M.およびL. Berger、Ed。、「Yang Tree Diagress」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https：//www.rfc-editor.org/info/RFC8340>。
[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>。
[RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, <https://www.rfc-editor.org/info/rfc8513>.
[RFC8513]Boucadair、M.、Jacquenet、C.、およびS.シバクマー、"デュアルスタックライト（DS-Liteの）のためのAYANGデータモデル"、RFC8513、DOI10.17487/RFC8513、2019年1月、<HTTPS：//www.rfc-editor.org/info/rfc8513>。
[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. Jacquenet, "An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective", RFC 8517, DOI 10.17487/RFC8517, February 2019, <https://www.rfc-editor.org/info/rfc8517>.
[RFC8517] Dolson、D.、ED。、Snellman、J.、Boucadair、M.、Ed。、およびC.Jacquenet、「MiddleBoxesによって提供されるトランスポート中心関数のインベントリ：オペレータの展望」、RFC 8517、DOI10.17487 / RFC8517、2019年2月、<https://www.rfc-editor.org/info/rfc8517>。
[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of Things (IoT) Security: State of the Art and Challenges", RFC 8576, DOI 10.17487/RFC8576, April 2019, <https://www.rfc-editor.org/info/rfc8576>.
[RFC8576] Garcia-Morchon、O.、Kumar、S.、およびM. Sethi、 "Mothingのインターネット（IoT）セキュリティ：芸術と挑戦の状態"、RFC 8576、DOI 10.17487 / RFC8576、2019年4月、<HTTPS//www.rfc-editor.org/info/rfc8576>。
[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、<https：//www.rfc-編集者.org / info / rfc8612>。
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, August 2020, <https://www.rfc-editor.org/info/rfc8811>.
[RFC8811] Mortensen、A.、ED。、Reddy.k、T.、Ed。、Andreasen、F.、Teague、N.、R. Compton、「DDOSオープン脅威シグナル伝達（ドット）アーキテクチャ」、RFC 8811、DOI 10.17487 / RFC8811、2020年8月、<https://www.rfc-editor.org/info/rfc8811>。
[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use Cases for DDoS Open Threat Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, <https://www.rfc-editor.org/info/rfc8903>.
[RFC8903]ドビンズ、R.、Migaute、D.、Moskowitz、R.、Teague、N.、Xia、L.、およびK。西塚、「DDOSオープン脅威シグナル伝達のためのユースケース」、RFC 8903、DOI 10.17487 / RFC89032021年5月、<https：//www.rfc-editor.org/info/rfc8903>。
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.
[RFC8955] LOIBL、C.、HARES、S.、Raszuk、R.、McPherson、D.、およびM. Bacher、「フロー仕様規則の普及」、RFC 8955、DOI 10.17487 / RFC8955、2020年12月、<https：//www.rfc-editor.org/info/rfc8955>。
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/info/rfc8956>.
[RFC8956] LOIBL、C、ED。、RASZUK、R.、ED。、およびS.HARES、ED。、「IPv6のフロー仕様規則の普及」、RFC 8956、DOI 10.17487 / RFC8956、2020年12月、<HTTPS//www.rfc-editor.org/info/rfc8956>。
[RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, January 2021, <https://www.rfc-editor.org/info/rfc8973>.
[RFC8973] Boucadair、M.およびT.Reddy.k、 "DDOS Open Threat Signaling（ドット）エージェントディスカバリー"、RFC 8973、DOI 10.17487 / RFC8973、2021年1月、<https://www.rfc-editor.org/情報/ RFC8973>。
[RS] RSnake, "Slowloris HTTP DoS", <https://web.archive.org/web/20150315054838/ http://ha.ckers.org/slowloris/>.
[RS] RSNAKE、「Slowloris HTTP DOS」、<https://web.archive.org/web/20150315054838/ http://ha.ckers.org/slowloris/>。
[Sec-by-design] UK Department for Digital, Culture, Media & Sport, "Secure by Design: Improving the cyber security of consumer Internet of Things Report", March 2018, <https://www.gov.uk/government/publications/secure-by-design-report>.
[Sec-By-Design]イギリスデジタル、文化、メディア＆スポーツ、「セキュアバイデザイン：コンシューマインターネットのサイバーセキュリティの改善」2018年3月、<https：//www.gov.uk/政府/出版物/セキュアバイデザインレポート>。
Internet of Things (IoT) devices are becoming more and more prevalent, in particular in home networks. With compute and memory becoming cheaper and cheaper, various types of IoT devices become available in the consumer market at affordable prices. But on the downside, there is a corresponding threat since most of these IoT devices are bought off-the-shelf and most manufacturers haven't considered security in the product design (e.g., [Sec-by-design]). IoT devices deployed in home networks can be easily compromised, they often do not have an easy mechanism to upgrade, and even when upgradable, IoT manufacturers may cease manufacture and/or discontinue patching vulnerabilities on IoT devices (Sections 5.4 and 5.5 of [RFC8576]). These vulnerable and compromised devices will continue to be used for a long period of time in the home, and the end-user does not know that IoT devices in his/her home are compromised. The compromised IoT devices are typically used for launching DDoS attacks (Section 3 of [RFC8576]) on victims while the owner/administrator of the home network is not aware about such misbehaviors. Similar to other DDoS attacks, the victim in this attack can be an application server, a host, a router, a firewall, or an entire network. Such misbehaviors can cause collateral damage that will affect end users, and can also harm the reputation of an Internet Service Provider (ISP) for being a source of attack traffic.
物事のインターネット（IoT）装置は、特にホームネットワークでますます一般的になっています。計算とメモリが安くて安くなるにつれて、様々な種類のIoTデバイスが手頃な価格で消費者市場で入手可能になる。しかし、下側には、これらのIoTデバイスのほとんどが既製で、ほとんどの製造業者が製品設計（例えば、[Sec-by-Design]）のセキュリティを検討していないため、対応する脅威があります。ホームネットワークに展開されているIoTデバイスは簡単に妥協することができ、アップグレード可能なメカニズムが簡単ではありません。アップグレード可能なIoT製造元は製造やIOTデバイス上のパッチ適用脆弱性を中止することができます（[RFC8576]のセクション5.4と5.5] ）。これらの脆弱で妥協したデバイスは、自宅で長期間使用され続け、エンドユーザーは自分の家の中のIOTデバイスが侵害されていることを知りません。侵入されたIoTデバイスは通常、被害者に関するDDOS攻撃（RFC8576]のセクション3）を起動するために使用されます。ホームネットワークの所有者/管理者はそのような不正なバリオールについて認識していません。他のDDOS攻撃と同様に、この攻撃の被害者は、アプリケーションサーバー、ホスト、ルータ、ファイアウォール、またはネットワーク全体にすることができます。そのような不正行為は、エンドユーザーに影響を与える担保の損傷を引き起こす可能性があり、攻撃トラフィックの源泉であるためのインターネットサービスプロバイダ（ISP）の評判も損なわれる可能性があります。
Nowadays, network devices in a home network can offer network security functions (e.g., firewall [RFC4949] or Intrusion Protection System (IPS) service [I2NSF-TERMS] on a home router) to protect the devices connected to the home network from both external and internal attacks. It is natural to seek to provide DDoS defense in these devices as well, and over the years several techniques have been identified to detect DDoS attacks; some of these techniques can be enabled on home network devices but most of them are used within the ISP's network.
今日では、ホームネットワーク内のネットワークデバイスは、ホームネットワークに接続されているデバイスを両方の外部から保護するために、ネットワークセキュリティ機能（ホームルーター上のファイアウォール[RFC4949]またはIPSF-TORPERS [I2NSF-TORNS]）を提供できます。そして内部攻撃。これらのデバイスにDDOS防衛を提供しようとするのは自然であり、そして長年にわたり、DDOS攻撃を検出するためにいくつかの技術が特定されています。これらの技術のいくつかはホームネットワークデバイスで有効にすることができますが、それらのほとんどはISPのネットワーク内で使用されています。
Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris [RS], and Transport Layer Security (TLS) renegotiation are difficult to detect on a home network device without adversely affecting its performance. The reason is that typically home devices such as home routers have fast path to boost the throughput. For every new TCP/ UDP flow, only the first few packets are punted through the slow path. Hence, it is not possible to detect various DDoS attacks in the slow path, since the attack payload is sent to the target server after the flow is switched to fast path. The reader may refer to Section 2 of [RFC6398] for a brief definition of slow and fast paths.
偽造されたRSTまたはFINパケット、Slowloris [RS]、およびトランスポート層セキュリティ（TLS）の再交渉のようなDDOS攻撃の中には、その性能に悪影響を及ぼすことなく、ホームネットワークデバイスで検出するのが困難です。その理由は、通常、ホームルータなどのホームデバイスがスループットを向上させるための高速パスを持っているからです。新しいTCP / UDPフローごとに、最初の数パケットのみがスローパスを介してパントされています。したがって、フローが高速経路に切り替えられた後に攻撃ペイロードがターゲットサーバに送信されるため、スローパスでさまざまなDDOS攻撃を検出することはできません。リーダーは、遅い経路と高速な経路の簡単な定義については、[RFC6398]のセクション2を参照することがあります。
Deep Packet Inspection (DPI) of all the packets of a flow would be able to detect some of the attacks. However, a full-fledged DPI to detect these type of DDoS attacks is functionally or operationally not possible for all the devices attached to the home network because of the memory and CPU limitations of the home routers. Furthermore, for certain DDoS attacks the logic needed to distinguish legitimate traffic from attack traffic on a per-packet basis is complex. This complexity is because that the packet itself may look "legitimate" and no attack signature can be identified. The anomaly can be identified only after detailed statistical analysis. In addition, network security services in home networks may not be able to detect all types of DDoS attacks using DPI. ISPs offering DDoS mitigation services have a DDoS detection capability that relies upon anomaly detection to identify zero day DDoS attacks and to detect DDoS attacks that cannot be detected using signatures and rate-limit techniques.
フローのすべてのパケットのディープパケット検査（DPI）は、いくつかの攻撃を検出することができます。ただし、これらの種類のDDOS攻撃を検出するための本格的なDPIは、ホームネットワークに接続されているすべてのデバイスがホームネットワークに接続されているすべてのデバイスがホームネットワークに接続されているため、ホームネットワークに接続されていません。さらに、特定のDDOSの場合、合法的なトラフィックをパケットごとに区別するために必要なロジックは複雑です。この複雑さは、パケット自体が「正当な」と見え、攻撃署名が識別されない可能性があるためです。異常は、詳細な統計分析後にのみ識別できます。さらに、ホームネットワーク内のネットワークセキュリティサービスは、DPIを使用してすべてのタイプのDDOS攻撃を検出できない可能性があります。 DDOS軽減サービスを提供するISPは、ゼロデイDDOS攻撃を識別し、署名とレート制限技術を使用して検出できないDDOS攻撃を検出するために異常検出に依存するDDOS検出機能を持っています。
ISPs can detect some DDoS attacks originating from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP usually does not have a mechanism to detect which device in the home network is generating the DDoS attack traffic. The primary reason for this is that devices in an IPv4 home network are typically behind a Network Address Translation (NAT) border [RFC2663]. Even in case of an IPv6 home network, although the ISP can identify the infected device in the home network launching the DDoS traffic by tracking its unique IPv6 address, the infected device can easily change its IPv6 address to evade remediation. A security function on the local home network is better positioned to track the compromised device across IPv6 address (and potentially even MAC address) changes and thus ensure that remediation remains in place across such events.
ISPは、ホームネットワークから発生したいくつかのDDOS攻撃を検出することができます（例えば、[RFC8517]のセクション2.6）、通常、ISPは通常、ホームネットワーク内のどのデバイスがDDOS攻撃トラフィックを生成しているかを検出するためのメカニズムを持っていません。これの主な理由は、IPv4ホームネットワーク内のデバイスが通常、ネットワークアドレス変換（NAT）ボーダー[RFC2663]の背後にあることです。IPv6ホームネットワークの場合でも、ISPは自宅ネットワーク内の感染したデバイスを識別することができますが、独自のIPv6アドレスを追跡することによってDDOSトラフィックを起動すると、感染したデバイスは簡単にIPv6アドレスを変更して回復を回避できます。ローカルホームネットワーク上のセキュリティ機能は、IPv6アドレス（そして潜在的にさえもMACアドレス）の変化を介して侵入されたデバイスを追跡するように配置され、したがって、修復がそのようなイベントを介して整備されたままであることを確認します。
With the DOTS signal channel Call Home, there is a chance that two DOTS agents can simultaneously establish two DOTS signal channels with different directions (base DOTS signal channel and DOTS signal channel Call Home). Here is one example drawn from the home network. Nevertheless, the outcome of the discussion is not specific to these networks, but applies to any DOTS Call Home scenario.
ドット信号チャネル呼び出しホームでは、2つのドットエージェントが異なる方向（ベースドット信号チャネルおよびドット信号チャネルコールホーム）を有する2つのドット信号チャネルを同時に確立することができる可能性がある。これはホームネットワークから描かれた一例です。それにもかかわらず、議論の結果はこれらのネットワークに固有のものではありませんが、どのドットコールホームシナリオにも適用されます。
In the Call Home scenario, the Call Home DOTS server in, for example, the home network can mitigate the DDoS attacks launched by the compromised device in its domain by receiving the mitigation request sent by the Call Home DOTS client in the ISP environment. In addition, the DOTS client in the home network can initiate a mitigation request to the DOTS server in the ISP environment to ask for help when the home network is under a DDoS attack. Such Call Home DOTS server and DOTS client in the home network can co-locate in the same home network element (e.g., the Customer Premises Equipment). In this case, with the same peer at the same time the home network element will have the base DOTS signal channel defined in [RFC9132] and the DOTS signal channel Call Home defined in this specification. Thus, these two signal channels need to be distinguished when they are both supported. Two approaches have been considered for distinguishing the two DOTS signal channels, but only the one that using the dedicated port number has been chosen as the best choice.
例えば、ホームネットワークの呼び出しホームドットサーバは、ISP環境でコールホームドットクライアントによって送信された緩和要求を受信することによって、そのドメイン内の侵入先デバイスによって起動されたDDOS攻撃を軽減することができる。さらに、ホームネットワーク内のドットクライアントは、ホームネットワークがDDOS攻撃の下にあるときに、ISP環境内のドットサーバーへの軽減要求を開始することができます。ホームネットワーク内のそのような呼び出しホームドットサーバおよびドットクライアントは、同じホームネットワーク要素（例えば、顧客宅内機器）内で同時に位置決めすることができる。この場合、同時に同じピアで、ホームネットワーク要素は、[RFC9132]で定義されているベースドット信号チャネルと、この仕様で定義されているドット信号チャネル呼び出しホームを持ちます。したがって、これら2つの信号チャネルは、それらが両方ともサポートされているときに区別される必要がある。 2つのドット信号チャネルを区別するための2つのアプローチが考慮されていますが、専用のポート番号を使用するものだけが最良の選択肢として選択されています。
By using a dedicated port number for each, these two signal channels can be separated unambiguously and easily. For example, the CPE uses the port number 4646 allocated in [RFC9132] to initiate the basic signal channel to the ISP when it acts as the DOTS client, and uses another port number to initiate the signal channel Call Home. Based on the different port numbers, the ISP can directly decide which kind of procedures should follow immediately after it receives the DOTS messages. This approach just requires two (D)TLS sessions to be established respectively for the basic signal channel and signal channel Call Home.
専用のポート番号を使用することによって、これら2つの信号チャネルを明確にそして容易に分離することができる。たとえば、CPEは[RFC9132]に割り当てられたポート番号4646を使用して、ドットクライアントとして機能するときに基本的な信号チャネルをISPに開始し、他のポート番号を使用して信号チャネル呼び出しホームを開始します。さまざまなポート番号に基づいて、ISPは、ドットメッセージを受信した直後にどのような種類の手順をたどるかを直接決定できます。このアプローチは、基本信号チャネルと信号チャネル呼び出しホームにそれぞれ確立される2つの（D）TLSセッションを必要とする。
The other approach is signaling the role of each DOTS agent (e.g., by using the DOTS data channel as depicted in Figure 14). For example, the DOTS agent in the home network first initiates a DOTS data channel to the peer DOTS agent in the ISP environment, at this time the DOTS agent in the home network is the DOTS client and the peer DOTS agent in the ISP environment is the DOTS server. After that, the DOTS agent in the home network retrieves the DOTS Call Home capability of the peer DOTS agent. If the peer supports the DOTS Call Home, the DOTS agent needs to subscribe to the peer to use this extension. Then, the reversal of DOTS role can be recognized as done by both DOTS agents. When the DOTS agent in the ISP environment, which now is the DOTS client, wants to filter the attackers' traffic, it requests the DOTS agent in the home network, which now is the DOTS server, for help.
他のアプローチは、各ドットエージェントの役割をシグナリングしている（例えば、図14に示されるようにドットデータチャネルを使用することによって）。例えば、ホームネットワーク内のドットエージェントは、最初にISP環境のピアドットエージェントへのドットデータチャネルを開始し、現時点ではホームネットワーク内のドットエージェントはドットクライアントであり、ISP環境のピアドットエージェントはドットサーバーその後、ホームネットワーク内のドットエージェントは、ピアドットエージェントのドット呼び出しホーム機能を検索する。ピアがドットコールホームをサポートしている場合、ドットエージェントはこの拡張機能を使用するためにピアを購読する必要があります。次に、ドットの役割の逆転は両方のドット剤によって行われるように認識され得る。現在ドットクライアントであるISP環境のドットエージェントが攻撃者のトラフィックをフィルタリングしたい場合は、ホームネットワーク内のドットエージェントを要求します。これは、現在はドットサーバーです。
augment /ietf-data:dots-data/ietf-data:capabilities:
+--ro call-home-support? boolean
augment /ietf-data:dots-data/ietf-data:dots-client:
+--rw call-home-enable? boolean
Figure 14: Example of DOTS Data Channel Augmentation
図14：ドットデータチャネル拡張の例
Signaling the role will complicate the DOTS protocols, and this complexity is not required in context where the DOTS Call Home is not required or only when the DOTS Call Home is needed. Besides, the DOTS data channel may not work during attack time. Even if changing the above example from using the DOTS data channel to the DOTS signal channel, the more procedures will still reduce the efficiency. Using the dedicated port number is much easier and more concise compared to the second approach, and its cost that establishing two (D)TLS sessions is much less. So, using a dedicated port number for the DOTS Call Home is recommended in this specification. The dedicated port number can be configured locally or discovered using means such as [RFC8973].
シグナリング役割はドットプロトコルを複雑にします。この複雑さは、ドットコールホームが必要ではない、またはドットコールホームが必要な場合にのみ必要ではありません。その上、ドットデータチャネルは攻撃時間中に機能しないかもしれません。上記の例をドットデータチャネルをドット信号チャネルに使用するのを変更しても、より多くの手順は依然として効率を低下させます。専用のポート番号を使用することは、2番目のアプローチと比較してはるかに簡単で簡潔で、2つの（D）TLSセッションを確立するコストがはるかに少ないです。したがって、この仕様では、ドットコールホームの専用ポート番号を使用することをお勧めします。専用のポート番号は、[RFC8973]などの手段を使用してローカルに設定または検出できます。
Acknowledgements
謝辞
Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema Gavrichenkov, Daniel Migault, Sean Turner, and Valery Smyslov for the comments.
Wei Pei、Xia Liang、Roman Danyliw、Dan Wing、Toema Gavrichenkov、Daniel Migault、Sean Turner、およびComents for Coments Smyslovのおかげで。
Benjamin Kaduk's AD review is valuable. Many thanks to him for the detailed review.
Benjamin Kadukの広告レビューは貴重です。詳細レビューのために彼に感謝します。
Thanks to Radia Perlman and David Schinazi for the directorate reviews.
Radia PerlmanとDavid Schinaziのおかげで、ディレクトリズレビュー。
Thanks to Ebben Aries for the YANG Doctors review.
Yangの医者のレビューのためのeBbenの牡羊座のおかげで。
Thanks to Éric Vyncke, Roman Danyliw, Barry Leiba, Robert Wilton, and Erik Kline for the IESG review.
IESGレビューのために、エリックビンケ、ローマのダニーリ、バリーレイラ、ロバートウィルトン、そしてエリックklineのおかげで。
Contributors
貢献者
The following individuals have contributed to this document:
次の個人はこの文書に貢献しています。
Joshi Harsha McAfee, Inc. Embassy Golf Link Business Park Bangalore 560071 Karnataka India
大使館マカフィー株式会社エンバシーゴルフリンクビジネスパークバンガロール560071カルナータカインド
Email: harsha_joshi@mcafee.com
Wei Pan Huawei Technologies China
Wei Pan Huawei Technologies China
Email: william.panwei@huawei.com
Authors' Addresses
著者の住所
Tirumaleswar Reddy.K Akamai Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy.kアカマイ大使館ゴルフリンクビジネスパークバンガロール560071カルナタカインド
Email: kondtir@gmail.com
Mohamed Boucadair (editor) Orange 35000 Rennes France
Mohamed Boucadair（編集）オレンジ35000 Rennes France
Email: mohamed.boucadair@orange.com
Jon Shallow United Kingdom
Jon Shallowイギリス
Email: supjps-ietf@jpshallow.com