[要約] RFC 9244は、DOTSプロトコルにさまざまなテレメトリ属性を追加し、最適なDDoS攻撃対策を可能にすることを目的としています。これにより、DOTSクライアントは通常のトラフィックベースラインや攻撃トラフィックなどの情報をDOTSサーバに伝え、効果的なDDoS攻撃対策を行うことができます。
Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Request for Comments: 9244 Orange
Category: Standards Track T. Reddy.K, Ed.
ISSN: 2070-1721 Akamai
E. Doron
Radware Ltd.
M. Chen
CMCC
J. Shallow
June 2022
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
分散型サービス拒否オープン脅威シグナル伝達（DOT）テレメトリ
Abstract
概要
This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.
このドキュメントは、分散されたサービス拒否オープン脅威シグナル伝達（DOT）シグナルチャネルプロトコルをさまざまなテレメトリ属性を備えており、最適な分散型サービス拒否（DDOS）攻撃緩和を可能にすることを目的としています。通常のトラフィックベースラインと攻撃トラフィックテレメトリー属性を攻撃クライアントが緩和要求でドットサーバーに伝えることができるドットテレメトリ属性、緩和ステータステレメトリはDOTSサーバーがDOTSクライアントに通信できる属性、および緩和効果テレメトリがDOTSクライアントができるドットテレメトリ属性属性を属性DOTSサーバーと通信します。Telemetry属性は、MitigatorがDDOS緩和技術の選択と最適なDDOS攻撃緩和を実行するのを支援できます。
This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.
このドキュメントは、2つのYangモジュールを指定します。1つはDOTSテレメトリメッセージタイプを表すための1つ、もう1つはDOTSデータチャネル上で詳細をマッピングする攻撃マッピングを共有するためです。
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/rfc9244.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9244で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology
3. DOTS Telemetry: Overview and Purpose
3.1. Need for More Visibility
3.2. Enhanced Detection
3.3. Efficient Mitigation
4. Design Overview
4.1. Overview of Telemetry Operations
4.2. Block-Wise Transfers
4.3. DOTS Multihoming Considerations
4.4. YANG Considerations
5. Generic Considerations
5.1. DOTS Client Identification
5.2. DOTS Gateways
5.3. Uri-Path Parameters and Empty Values
5.4. Controlling Configuration Data
5.5. Message Validation
5.6. A Note about Examples
6. Telemetry Operation Paths
7. DOTS Telemetry Setup Configuration
7.1. Telemetry Configuration
7.1.1. Retrieving the Current DOTS Telemetry Configuration
7.1.2. Conveying the DOTS Telemetry Configuration
7.1.3. Retrieving the Installed DOTS Telemetry Configuration
7.1.4. Deleting the DOTS Telemetry Configuration
7.2. Total Pipe Capacity
7.2.1. Conveying DOTS Client Domain Pipe Capacity
7.2.2. Retrieving Installed DOTS Client Domain Pipe Capacity
7.2.3. Deleting Installed DOTS Client Domain Pipe Capacity
7.3. Telemetry Baseline
7.3.1. Conveying DOTS Client Domain Baseline Information
7.3.2. Retrieving Installed Normal Traffic Baseline
Information
7.3.3. Deleting Installed Normal Traffic Baseline Information
7.4. Resetting the Installed Telemetry Setup
7.5. Conflict with Other DOTS Clients of the Same Domain
8. DOTS Pre-or-Ongoing-Mitigation Telemetry
8.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes
8.1.1. Target
8.1.2. Total Traffic
8.1.3. Total Attack Traffic
8.1.4. Total Attack Connections
8.1.5. Attack Details
8.1.6. Vendor Attack Mapping
8.2. From DOTS Clients to DOTS Servers
8.3. From DOTS Servers to DOTS Clients
9. DOTS Telemetry Mitigation Status Update
9.1. From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS
Telemetry Attributes
9.2. From DOTS Servers to DOTS Clients: Mitigation Status DOTS
Telemetry Attributes
10. Error Handling
11. YANG Modules
11.1. DOTS Signal Channel Telemetry YANG Module
11.2. Vendor Attack Mapping Details YANG Module
12. YANG/JSON Mapping Parameters to CBOR
13. IANA Considerations
13.1. DOTS Signal Channel CBOR Key Values
13.2. DOTS Signal Channel Conflict Cause Codes
13.3. DOTS Telemetry URIs and YANG Module Registrations
14. Security Considerations
14.1. DOTS Signal Channel Telemetry
14.2. Vendor Attack Mapping
15. References
15.1. Normative References
15.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
IT organizations and service providers are facing Distributed Denial-of-Service (DDoS) attacks that fall into two broad categories:
IT組織とサービスプロバイダーは、2つの広範なカテゴリに分類される分散拒否（DDOS）攻撃に直面しています。
1. Network-layer and transport-layer attacks target the victim's infrastructure. These attacks are not necessarily aimed at taking down the actual delivered services; rather, these attacks prevent various network elements (routers, switches, firewalls, transit links, and so on) from serving legitimate users' traffic.
1. ネットワーク層と輸送層攻撃は、被害者のインフラストラクチャをターゲットにしています。これらの攻撃は、必ずしも実際の配信されたサービスを削除することを目的としているわけではありません。むしろ、これらの攻撃は、さまざまなネットワーク要素（ルーター、スイッチ、ファイアウォール、トランジットリンクなど）が正当なユーザーのトラフィックを提供することを防ぎます。
The main method of such attacks is to send a large volume of traffic (e.g., high-pps (packets per second) traffic) toward the victim's infrastructure. Typically, attack volumes may vary from a few hundred Mbps to hundreds of Gbps or even Tbps. Attacks are commonly carried out leveraging botnets and attack reflectors for amplification attacks (Section 3.1 of [RFC4732]) such as NTP (Network Time Protocol), DNS (Domain Name System), SNMP (Simple Network Management Protocol), or SSDP (Simple Service Discovery Protocol).
このような攻撃の主な方法は、被害者のインフラストラクチャに向けて大量のトラフィック（たとえば、秒あたりのパケット）を送ることです。通常、攻撃量は、数百Mbpsから数百Gbps、さらにはTBPによって変化する場合があります。攻撃は一般に実行され、NTP（ネットワークタイムプロトコル）、DNS（ドメイン名システム）、SNMP（シンプルネットワーク管理プロトコル）、またはSSDP（単純サービス）などの増幅攻撃のためのボットネットと攻撃リフレクター（[RFC4732]のセクション3.1）の攻撃リフレクターを活用して実行されますディスカバリープロトコル）。
2. Application-layer attacks target various applications. Typical examples include attacks against HTTP/HTTPS, DNS, SIP (Session Initiation Protocol), or SMTP (Simple Mail Transfer Protocol). However, all applications with their port numbers open at network edges can be attractive attack targets.
2. アプリケーション層攻撃は、さまざまなアプリケーションを対象としています。典型的な例には、HTTP/HTTPS、DNS、SIP（セッション開始プロトコル）、またはSMTP（Simple Mail転送プロトコル）に対する攻撃が含まれます。ただし、ネットワークエッジでポート番号を開くすべてのアプリケーションは、魅力的な攻撃ターゲットになる可能性があります。
Application-layer attacks are considered more complex and harder to categorize and are therefore harder to detect and mitigate efficiently.
アプリケーション層攻撃は、分類がより複雑で難しいと考えられているため、効率的に検出して軽減するのが難しいと考えられています。
To compound the problem, attackers also leverage multi-vectored attacks. These attacks are assembled from dynamic network-layer and application-layer attack vectors and other tactics. As such, multiple attack vectors formed by multiple attack types and volumes are launched simultaneously toward a victim. Multi-vector attacks are harder to detect and defend against. Multiple and simultaneous mitigation techniques are needed to defeat such attack campaigns. It is also common for attackers to change attack vectors right after a successful mitigation, burdening their opponents with changing their defense methods.
問題を悪化させるために、攻撃者はマルチベクトル攻撃も活用します。これらの攻撃は、動的ネットワーク層およびアプリケーション層攻撃ベクトルおよびその他の戦術から組み立てられます。そのため、複数の攻撃タイプとボリュームによって形成された複数の攻撃ベクトルが、被害者に対して同時に起動されます。マルチベクトル攻撃は、検出して防御するのが困難です。このような攻撃キャンペーンを打ち負かすには、複数の同時緩和手法が必要です。また、攻撃者が緩和の成功後すぐに攻撃ベクターを変更し、防御方法の変更を相手に負担することも一般的です。
The conclusion derived from the aforementioned attack scenarios is that modern attack detection and mitigation are most certainly complicated and highly convoluted tasks. They demand a comprehensive knowledge of the attack attributes and the normal behavior of the targeted systems (including normal traffic patterns), as well as the attacker's ongoing and past actions. Even more challenging, retrieving all the analytics needed for detecting these attacks is not simple with the industry's current reporting capabilities.
前述の攻撃シナリオから導き出された結論は、現代の攻撃の検出と緩和は間違いなく複雑で高度に複雑なタスクであるということです。彼らは、攻撃属性とターゲットシステムの通常の動作（通常のトラフィックパターンを含む）の包括的な知識、ならびに攻撃者の継続的および過去の行動を要求します。さらに挑戦的なことに、これらの攻撃を検出するために必要なすべての分析を取得することは、業界の現在の報告機能では単純ではありません。
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 DDoS attack. 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]は、DDOS攻撃中のネットワークリソースまたはネットワーク（またはその一部）に関する情報を使用して使用されます。このような情報は、ドットクライアントから1つまたは複数のドットサーバーに送信されるため、適切な緩和アクションが疑わしいとみなされるトラフィックで行われます。さまざまなユースケースについては、[RFC8903]で説明しています。
DOTS clients can be integrated within a DDoS attack detector or within network and security elements that have been actively engaged with ongoing attacks. The DOTS client mitigation environment determines that it is no longer possible or practical for it to handle these attacks itself. This can be due to a lack of resources or security capabilities, as derived from the complexities and intensity of these attacks. In this circumstance, the DOTS client has invaluable knowledge about the actual attacks that need to be handled by its DOTS server(s). By enabling the DOTS client to share this comprehensive knowledge of an ongoing attack under specific circumstances, the DOTS server can drastically increase its ability to accomplish successful mitigation. While the attack is being handled by the mitigation resources associated with the DOTS server, the DOTS server has knowledge about the ongoing attack mitigation. The DOTS server can share this information with the DOTS client so that the client can better assess and evaluate the actual mitigation realized.
DOTSクライアントは、DDOS攻撃検出器内または進行中の攻撃に積極的に関与しているネットワークおよびセキュリティ要素内に統合できます。 DOTSクライアントの緩和環境は、これらの攻撃自体を処理することがもはや不可能または実用的であると判断します。これは、これらの攻撃の複雑さと強度に由来するリソースまたはセキュリティ機能の不足が原因である可能性があります。この状況では、DOTSクライアントは、DOTSサーバーで処理する必要がある実際の攻撃について非常に貴重な知識を持っています。 DOTSクライアントが特定の状況下で進行中の攻撃に関するこの包括的な知識を共有できるようにすることにより、DOTSサーバーは、成功した緩和を達成する能力を大幅に向上させることができます。攻撃はDOTSサーバーに関連付けられた緩和リソースによって処理されていますが、DOTSサーバーには進行中の攻撃緩和に関する知識があります。 DOTSサーバーは、この情報をDOTSクライアントと共有できるため、クライアントは実際の緩和を実現したことをより適切に評価および評価できます。
DOTS clients can send mitigation hints derived from attack details to DOTS servers, with the full understanding that a DOTS server may ignore mitigation hints, as described in [RFC8612] (Gen-004). Mitigation hints will be transmitted across the DOTS signal channel, as the data channel may not be functional during an attack. How a DOTS server handles normal and attack traffic attributes, and mitigation hints, is implementation specific.
DOTSクライアントは、[RFC8612]（GEN-004）で説明されているように、DOTSサーバーが軽減ヒントを無視する可能性があることを完全に理解して、攻撃の詳細から派生したヒントをDOTSサーバーに送信できます。攻撃中にデータチャネルが機能しない可能性があるため、緩和ヒントはドット信号チャネルを介して送信されます。DOTSサーバーが通常の属性を処理し、トラフィック属性を攻撃する方法、および緩和ヒントは実装固有です。
Both DOTS clients and servers can benefit from this information by presenting various information details in relevant management, reporting, and portal systems.
DOTSクライアントとサーバーの両方は、関連する管理、レポート、およびポータルシステムでさまざまな情報の詳細を提示することにより、この情報の恩恵を受けることができます。
This document defines DOTS telemetry attributes that can be conveyed by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry attributes are not mandatory attributes of the DOTS signal channel protocol [RFC9132]. When no limitation policy is provided to a DOTS agent, it can signal available telemetry attributes to its peers in order to optimize the overall mitigation service provisioned using DOTS. The aforementioned policy can be, for example, agreed upon during a service subscription (which is out of scope for this document) to identify a subset of DOTS clients among those deployed in a DOTS client domain that are allowed to send or receive telemetry data.
このドキュメントでは、DOTSクライアントがドットサーバーに伝えることができるDOTSテレメトリ属性を定義し、その逆も同様です。DOTSテレメトリ属性は、DOTS信号チャネルプロトコル[RFC9132]の必須属性ではありません。DOTSエージェントに制限ポリシーが提供されていない場合、ドットを使用して提供された全体的な緩和サービスを最適化するために、利用可能なテレメトリ属性を同業他社に信号することができます。前述のポリシーは、たとえば、サービスサブスクリプション（このドキュメントの範囲外）で合意することができ、テレメトリーデータの送信または受信が許可されているDOTSクライアントドメインに展開されているドットクライアントのサブセットを識別します。
Section 11.2 of this document specifies a YANG module that augments the DOTS data channel [RFC8783] with information related to attack details. Sharing such details during 'idle' time is meant to optimize the data exchanged over the DOTS signal channel.
このドキュメントのセクション11.2は、攻撃の詳細に関連する情報をDOTSデータチャネル[RFC8783]に補強するYangモジュールを指定しています。「アイドル」時間中にそのような詳細を共有することは、DOTS信号チャネルで交換されたデータを最適化することを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader should be familiar with the terms defined in [RFC8612].
読者は、[RFC8612]で定義されている用語に精通している必要があります。
"DOTS telemetry" is defined as the collection of attributes that are used to characterize the normal traffic baseline, attacks and their mitigation measures, and any related information that may help in enforcing countermeasures. "DOTS telemetry" is an optional set of attributes that can be signaled in the DOTS signal channel protocol.
「Dots Telemetry」は、通常のトラフィックベースライン、攻撃と緩和策、および対策の実施に役立つ関連情報を特徴付けるために使用される属性のコレクションとして定義されます。「Dots Telemetry」は、Dots Signal Channel Protocolで信号を送信できるオプションの属性セットです。
The Telemetry Setup Identifier (tsid) is an identifier that is generated by DOTS clients to uniquely identify DOTS telemetry setup configuration data. See Section 7.1.2 for more details.
Telemetryセットアップ識別子（TSID）は、DOTSクライアントによって生成される識別子であり、DOTS Telemetryセットアップ構成データを一意に識別します。詳細については、セクション7.1.2を参照してください。
The Telemetry Identifier (tmid) is an identifier that is generated by DOTS clients to uniquely identify DOTS telemetry data that is communicated prior to or during a mitigation. See Section 8.2 for more details.
Telemetry Identifier（TMID）は、DOTSクライアントによって生成される識別子であり、緩和前または緩和中に通信されるDOTSテレメトリデータを一意に識別します。詳細については、セクション8.2を参照してください。
"Overlapped" lower numeric 'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of two overlapping telemetry requests.
「オーバーラップされた」低い数値「TSID」（または「TMID」）は、2つのオーバーラップテレメトリー要求の「TSID」（または「TMID」）値を指します。
The term "pipe" represents the maximum level of traffic that the DOTS client domain can receive. Whether a "pipe" is mapped to one or a group of network interfaces is deployment specific. For example, each interconnection link may be considered as a specific pipe if the DOTS server is hosted by each upstream provider, while the aggregate of all links to connect to upstream network providers can be considered by a DOTS client domain as a single pipe when communicating with a DOTS server not hosted by these upstream providers.
「パイプ」という用語は、DOTSクライアントドメインが受信できるトラフィックの最大レベルを表します。「パイプ」が1つまたはネットワークインターフェイスのグループにマッピングされるかどうかは、展開固有です。たとえば、各相互接続リンクは、DOTSサーバーが各アップストリームプロバイダーによってホストされている場合、特定のパイプと見なされる場合がありますが、すべてのリンクの集計は、アップストリームネットワークプロバイダーに接続するために、DOTSクライアントドメインによって単一のパイプとして考慮することができます。これらのアップストリームプロバイダーによってホストされていないドットサーバーを使用します。
This document uses IANA-assigned Enterprise Numbers. These numbers are also known as "Private Enterprise Numbers" and "SMI (Structure of Management Information) Network Management Private Enterprise Codes" [Private-Enterprise-Numbers].
このドキュメントでは、IANAが割り当てられたエンタープライズ番号を使用しています。これらの数値は、「プライベートエンタープライズ番号」および「SMI（管理情報の構造）ネットワーク管理プライベートエンタープライズコード」[Private-Enterprise-Numbers]としても知られています。
The meanings of the symbols in YANG tree diagrams are defined in [RFC8340] and [RFC8791].
陽ツリー図のシンボルの意味は、[RFC8340]および[RFC8791]で定義されています。
Consistent with the convention set in Section 2 of [RFC8783], the examples in Section 8.1.6 use "/restconf" as the discovered RESTCONF API root path. Within these examples, some protocol header lines are split into multiple lines for display purposes only. When a line ends with a backslash ("\") as the last character, the line is wrapped for display purposes. It is considered to be joined to the next line by deleting the backslash, the following line break, and the leading whitespace of the next line.
[RFC8783]のセクション2で設定された規則と一致して、セクション8.1.6の例では、「/retsConf」を発見されたRestConf APIルートパスとして使用します。これらの例では、一部のプロトコルヘッダーラインは、表示目的でのみ複数の行に分割されます。ラインが最後のキャラクターとしてバックスラッシュ（ "\"）で終わると、行は表示目的でラップされます。バックスラッシュ、次のラインブレイク、次の行の主要な白文学を削除することにより、次の行に結合されると考えられています。
Timely and effective signaling of up-to-date DDoS telemetry to all elements involved in the mitigation process is essential and improves the overall DDoS mitigation service's effectiveness. Bidirectional feedback between DOTS agents is required for increased awareness by each party of the attack and mitigation efforts, supporting a superior and highly efficient attack mitigation service.
緩和プロセスに関与するすべての要素への最新のDDOSテレメトリのタイムリーかつ効果的なシグナリングは不可欠であり、DDOS緩和サービス全体の有効性を改善します。DOTSエージェント間の双方向フィードバックは、攻撃および緩和努力の各当事者による意識を高めるために必要であり、優れた非常に効率的な攻撃緩和サービスをサポートします。
When signaling a mitigation request, it is most certainly beneficial for DOTS clients to signal to DOTS servers any knowledge regarding ongoing attacks. This can happen in cases where DOTS clients are asking DOTS servers for support in defending against attacks that they have already detected and/or (partially) mitigated.
緩和要求を合図する場合、DOTSクライアントが継続的な攻撃に関する知識をDOTSサーバーに信号することは確かに有益です。これは、DOTSクライアントがDOTSサーバーに、すでに検出されている、および/または（部分的に）緩和された攻撃に対する防御のサポートを求めている場合に発生する可能性があります。
If attacks are already detected and categorized within a DOTS client domain, the DOTS server, and its associated mitigation services, can proactively benefit from this information and optimize the overall service delivery. It is important to note that DOTS client domains' and DOTS server domains' detection and mitigation approaches can be different and can potentially result in different results and attack classifications. The DDoS mitigation service treats the ongoing attack details received from DOTS clients as hints and cannot completely rely on or trust the attack details conveyed by DOTS clients.
DOTSクライアントドメイン内で攻撃が既に検出および分類されている場合、DOTSサーバーとそれに関連する緩和サービスは、この情報から積極的に利益を得て、全体的なサービス提供を最適化できます。DOTSクライアントドメインとDOTSサーバードメインの検出と緩和アプローチが異なる場合があり、結果が異なる可能性があることに注意してください。DDOS緩和サービスは、DOTSクライアントから受け取った継続的な攻撃の詳細をヒントとして扱い、DOTSクライアントによって伝えられた攻撃の詳細に完全に依存または信頼することはできません。
In addition to the DOTS server directly using telemetry data as operational hints, the DOTS server's security operation team also benefits from telemetry data. A basic requirement of security operation teams is to be aware of and get visibility into the attacks they need to handle. This holds especially for the case of ongoing attacks, where DOTS telemetry provides data about the current attack status. Even if some mitigation can be automated, operational teams can use the DOTS telemetry information to be prepared for attack mitigation and to assign the correct resources (e.g., operation staff, networking resources, mitigation resources) for the specific service. Similarly, security operations personnel at the DOTS client side ask for feedback about their requests for protection. Therefore, it is valuable for DOTS servers to share DOTS telemetry with DOTS clients.
Telemetry Dataを運用ヒントとして直接使用してDOTSサーバーに加えて、DOTSサーバーのセキュリティ操作チームもテレメトリデータの恩恵を受けます。セキュリティ運用チームの基本的な要件は、それらが処理する必要がある攻撃を認識し、可視性を取得することです。これは、DOTSテレメトリーが現在の攻撃ステータスに関するデータを提供する継続的な攻撃の場合に特に当てはまります。一部の緩和が自動化されたとしても、運用チームはDOTSテレメトリ情報を使用して、攻撃緩和のために準備し、特定のサービスに正しいリソース（運用スタッフ、ネットワーキングリソース、緩和リソース）を割り当てることができます。同様に、DOTSクライアント側のセキュリティオペレーション担当者は、保護の要求についてフィードバックを求めます。したがって、DOTSサーバーがDOTSテレメトリをDOTSクライアントと共有することは価値があります。
Mutual sharing of information is thus crucial for "closing the mitigation loop" between DOTS clients and servers. For the server-side team, it is important to confirm that the same attacks that the DOTS server's mitigation resources are seeing are those for which a DOTS client is requesting mitigation. For the DOTS client-side team, it is important to realize that the DOTS clients receive the required service -- for example, understanding that "I asked for mitigation of two attacks, and my DOTS server detects and mitigates only one of them." Cases of inconsistency in attack classification between DOTS clients and servers can be highlighted, and maybe handled, using the DOTS telemetry attributes.
したがって、情報の相互共有は、DOTSクライアントとサーバー間の「緩和ループを閉じる」ために重要です。サーバー側のチームにとって、DOTSサーバーの緩和リソースが見ているのと同じ攻撃が、DOTSクライアントが緩和を要求しているものであることを確認することが重要です。DOTSクライアントサイドチームの場合、DOTSクライアントが必要なサービスを受け取っていることを認識することが重要です。たとえば、「2つの攻撃の緩和を求め、DOTSサーバーはそれらの1つだけを検出して軽減する」ことを理解しています。DOTSクライアントとサーバー間の攻撃分類における矛盾のケースを強調表示し、DOTSテレメトリ属性を使用して処理することができます。
In addition, management and orchestration systems, at both the DOTS client and server sides, can use DOTS telemetry as feedback to automate various control and management activities derived from signaled telemetry information.
さらに、DOTSクライアントとサーバーの両方の側面で、管理およびオーケストレーションシステムは、シグナル付きテレメトリー情報から導出されたさまざまな制御および管理アクティビティを自動化するためのフィードバックとしてDOTSテレメトリを使用できます。
If the DOTS server's mitigation resources have the capabilities to facilitate the DOTS telemetry, the DOTS server adapts its protection strategy and activates the required countermeasures immediately (automation enabled) for the sake of optimized attack mitigation decisions and actions. Discussion regarding the interface from the DOTS server to the mitigator to signal the telemetry data is out of scope for this document.
DOTSサーバーの緩和リソースにDOTSテレメトリを促進する機能がある場合、DOTSサーバーは保護戦略を適応させ、最適化された攻撃緩和の決定とアクションのために、必要な対策をすぐにアクティブにします（自動化が有効）。DOTSサーバーからMitigatorへのインターフェイスに関する議論は、このドキュメントのテレメトリデータを信号することは範囲外です。
DOTS telemetry can also be used as input for determining what values to use for the tuning parameters available on the mitigation resources. During the last few years, DDoS attack detection technologies have evolved from threshold-based detection (that is, cases when all or specific parts of traffic cross a predefined threshold for a certain period of time is considered as an attack) to an "anomaly detection" approach. For the latter, it is required to maintain rigorous learning of "normal" behavior, and an "anomaly" (or an attack) is identified and categorized based on the knowledge about the normal behavior and a deviation from this normal behavior. Statistical and artificial intelligence algorithms (e.g., machine learning) are used such that the actual traffic thresholds are automatically calculated by learning the protected entity's normal traffic behavior during 'idle' time (i.e., no mitigation is active). The normal traffic characterization learned is referred to as the "normal traffic baseline". An attack is detected when the victim's actual traffic is deviating from this normal baseline pattern.
Dots Telemetryは、緩和リソースで利用可能なチューニングパラメーターに使用する値を決定するための入力として使用することもできます。過去数年間、DDOS攻撃検出技術はしきい値ベースの検出から進化しました（つまり、トラフィックのすべてまたは特定の部分が特定の期間にわたって事前定義されたしきい値を越えている場合、攻撃と見なされます）。 " アプローチ。後者の場合、「正常な」行動の厳密な学習を維持する必要があり、「異常」（または攻撃）が特定され、通常の行動とこの通常の動作からの逸脱に関する知識に基づいて分類されます。統計および人工知能のアルゴリズム（機械学習など）が使用され、実際のトラフィックのしきい値は、「アイドル」時に保護されたエンティティの通常のトラフィック行動を学習することによって自動的に計算されます（つまり、緩和はアクティブではありません）。学んだ通常のトラフィックの特性評価は、「通常のトラフィックベースライン」と呼ばれます。被害者の実際のトラフィックがこの通常のベースラインパターンから逸脱している場合、攻撃が検出されます。
In addition, subsequent activities toward mitigating an attack are much more challenging. The ability to distinguish legitimate traffic from attacker traffic on a per-packet basis is complex. For example, a packet may look "legitimate" and no attack signature can be identified. The anomaly can be identified only after detailed statistical analysis. DDoS attack mitigators use the normal baseline during the mitigation of an attack to identify and categorize the expected appearance of a specific traffic pattern. Particularly, the mitigators use the normal baseline to recognize the "level of normality" that needs to be achieved during the various mitigation processes.
さらに、攻撃を軽減するためのその後の活動は、はるかに困難です。パケットごとに合法的なトラフィックを攻撃者のトラフィックと区別する能力は複雑です。たとえば、パケットは「合法」に見える場合があり、攻撃の署名を特定することはできません。異常は、詳細な統計分析の後にのみ識別できます。DDOS攻撃緩和剤は、攻撃の緩和中に通常のベースラインを使用して、特定のトラフィックパターンの予想される外観を特定して分類します。特に、緩和剤は通常のベースラインを使用して、さまざまな緩和プロセス中に達成する必要がある「正常レベル」を認識します。
Normal baseline calculation is performed based on continuous learning of the normal behavior of the protected entities. The minimum learning period varies from hours to days and even weeks, depending on the protected applications' behavior. The baseline cannot be learned during active attacks because attack conditions do not characterize the protected entities' normal behavior.
通常のベースライン計算は、保護されたエンティティの正常な動作の継続的な学習に基づいて実行されます。最小学習期間は、保護されたアプリケーションの動作に応じて、数時間から数日、さらには数週間までさまざまです。攻撃条件は保護されたエンティティの通常の動作を特徴付けていないため、アクティブな攻撃中にベースラインを学ぶことはできません。
If the DOTS client has calculated the normal baseline of its protected entities, signaling such information to the DOTS server along with the attack traffic levels provides value. The DOTS server benefits from this telemetry by tuning its mitigation resources with the DOTS client's normal baseline. The DOTS server's mitigators use the baseline to familiarize themselves with the attack victim's normal behavior and target the baseline as the level of normality they need to achieve. Fed with this information, the overall mitigation performance is expected to be improved in terms of time to mitigate, accuracy, and false-negative and false-positive rates.
DOTSクライアントが保護されたエンティティの通常のベースラインを計算した場合、攻撃トラフィックレベルとともにそのような情報をDOTSサーバーに合図することが価値を提供します。DOTSサーバーは、DOTSクライアントの通常のベースラインで緩和リソースを調整することにより、このテレメトリの恩恵を受けます。DOTSサーバーの緩和剤は、ベースラインを使用して、攻撃被害者の通常の動作に慣れ、達成する必要がある正常性のレベルとしてベースラインをターゲットにします。この情報に供給されると、全体的な緩和パフォーマンスは、緩和、精度、偽陰性および偽陽性率の時間の観点から改善されると予想されます。
Mitigation of attacks without having certain knowledge of normal traffic can be inaccurate at best. This is especially true for recursive signaling (see Section 3.2.3 of [RFC8811]). Given that DOTS clients can be integrated in a highly diverse set of scenarios and use cases, this emphasizes the need for knowledge of the behavior of each DOTS client domain -- especially given that common global thresholds for attack detection can almost never be realized. Each DOTS client domain can have its own levels of traffic and normal behavior. Without facilitating normal baseline signaling, it may be very difficult for DOTS servers in some cases to detect and mitigate the attacks accurately:
通常のトラフィックに関する特定の知識を持たない攻撃の緩和は、せいぜい不正確になる可能性があります。これは、再帰シグナル伝達に特に当てはまります（[RFC8811]のセクション3.2.3を参照）。DOTSクライアントを非常に多様なシナリオとユースケースに統合できることを考えると、これは各DOTSクライアントドメインの動作に関する知識の必要性を強調します。各ドットクライアントドメインは、独自のレベルのトラフィックと通常の動作を持つことができます。通常のベースラインシグナル伝達を促進することなく、ドットサーバーが攻撃を正確に検出および軽減することは非常に困難な場合があります。
* It is important to emphasize that it is practically impossible for the DOTS server's mitigators to calculate the normal baseline in cases where they do not have any knowledge of the traffic beforehand.
* DOTSサーバーの緩和者が、事前にトラフィックの知識がない場合に通常のベースラインを計算することは実際には不可能であることを強調することが重要です。
Of course, this information can be provided using out-of-band mechanisms or manual configuration, at the risk of unmaintained information becoming inaccurate as the network evolves and "normal" patterns change. The use of a dynamic and collaborative means between the DOTS client and server to identify and share key parameters for the sake of efficient DDoS protection is valuable.
もちろん、この情報は、ネットワークが進化し、「通常の」パターンが変化するにつれて、維持されていない情報が不正確になるリスクがあるため、帯域外のメカニズムまたは手動構成を使用して提供できます。効率的なDDOS保護のために重要なパラメーターを特定して共有するために、DOTSクライアントとサーバーの間の動的で共同の手段を使用することは価値があります。
During a high-volume attack, DOTS client pipes can be totally saturated. DOTS clients ask their DOTS servers to handle the attack upstream so that DOTS client pipes return to a reasonable load level (normal pattern, ideally). At this point, it is essential to ensure that the mitigator does not overwhelm the DOTS client pipes by sending back large volumes of "clean traffic", or what it believes is "clean". This can happen when the mitigator has not managed to detect and mitigate all the attacks launched toward the DOTS client domain.
大量の攻撃中、ドットクライアントパイプは完全に飽和状態になります。ドットクライアントは、ドットサーバーに攻撃の上流を処理するように依頼し、ドットクライアントパイプが合理的な負荷レベル（通常のパターン）に戻るようにします。この時点で、ミチゲーターが大量の「クリーントラフィック」、または「クリーン」であると思われるものを送り返すことで、ドットクライアントパイプを圧倒しないようにすることが不可欠です。これは、MitigatorがDOTSクライアントドメインに向けて開始されたすべての攻撃を検出して軽減できなかった場合に発生する可能性があります。
In this case, it can be valuable to DOTS clients to signal to DOTS servers the total pipe capacity, which is the level of traffic the DOTS client domain can absorb from its upstream network. This is usually the circuit size, which includes all the packet overheads. Dynamic updates of the condition of pipes between DOTS agents while they are under a DDoS attack are essential (e.g., where multiple DOTS clients share the same physical connectivity pipes). The DOTS server should activate other mechanisms to ensure that it does not allow the DOTS client domain's pipes to be saturated unintentionally. The rate-limit action defined in [RFC8783] is a reasonable candidate to achieve this objective; the DOTS client can indicate the type(s) of traffic (such as ICMP, UDP, TCP port number 80) it prefers to limit. The rate-limit action can be controlled via the signal channel [RFC9133] even when the pipe is overwhelmed.
この場合、DOTSクライアントがDOTSに合計パイプ容量をサーバーに合図することが価値があります。これは、DOTSクライアントドメインがアップストリームネットワークから吸収できるトラフィックのレベルです。これは通常、すべてのパケットオーバーヘッドを含む回路サイズです。DDOS攻撃を受けている間にドットエージェント間のパイプの状態の動的更新が不可欠です（たとえば、複数のDOTSクライアントが同じ物理的な接続パイプを共有する場合）。DOTSサーバーは、他のメカニズムをアクティブにして、DOTSクライアントドメインのパイプを意図せずに飽和させないようにする必要があります。[RFC8783]で定義されているレート制限アクションは、この目的を達成するための合理的な候補です。DOTSクライアントは、トラフィックのタイプ（ICMP、UDP、TCPポート番号80など）を示すことができます。レート制限アクションは、パイプが圧倒された場合でも、信号チャネル[RFC9133]を介して制御できます。
The DOTS protocol suite is divided into two logical channels: the signal channel [RFC9132] and data channel [RFC8783]. This division is due to the vastly different requirements placed upon the traffic they carry. The DOTS signal channel must remain available and usable even in the face of attack traffic that might, for example, saturate one direction of the links involved, rendering acknowledgment-based mechanisms unreliable and strongly incentivizing messages to be small enough to be contained in a single IP packet (Section 2.2 of [RFC8612]). In contrast, the DOTS data channel is available for high-bandwidth data transfer before or after an attack, using more conventional transport protocol techniques (Section 2.3 of [RFC8612]). It is generally preferable to perform advance configuration over the DOTS data channel, including configuring aliases for static or nearly static data sets such as sets of network addresses/prefixes that might be subject to related attacks. This design helps to optimize the use of the DOTS signal channel for the small messages that are important to deliver during an attack. As a reminder, the DOTS signal channel and data channel both require secure communication channels (Section 11 of [RFC9132] and Section 10 of [RFC8783]).
DOTSプロトコルスイートは、信号チャネル[RFC9132]とデータチャネル[RFC8783]の2つの論理チャネルに分割されます。この部門は、携帯するトラフィックにかかる要件が大きく異なるためです。ドット信号チャネルは、たとえば関連するリンクの1つの方向を飽和させる可能性のある攻撃トラフィックに直面しても、利用可能で使用可能なままでなければなりません。 IPパケット（[RFC8612]のセクション2.2）。対照的に、DOTSデータチャネルは、より多くの従来の輸送プロトコル手法を使用して、攻撃の前後に高帯域幅データ転送に使用できます（[RFC8612]のセクション2.3）。一般に、関連する攻撃の対象となる可能性のあるネットワークアドレス/プレフィックスのセットなど、静的またはほぼ静的データセットのエイリアスの構成など、DOTSデータチャネルでアドバンス構成を実行することが望ましいです。この設計は、攻撃中に配信することが重要な小さなメッセージのドット信号チャネルの使用を最適化するのに役立ちます。リマインダーとして、DOTS信号チャネルとデータチャネルはどちらも安全な通信チャネル（[RFC9132]のセクション11と[RFC8783]のセクション10）が必要です。
Telemetry information has aspects that correspond to both operational modes (i.e., signal channel and data channel): there is certainly a need to convey updated information about ongoing attack traffic and targets during an attack, so as to convey detailed information about mitigation status and inform updates to mitigation strategy in the face of adaptive attacks. However, it is also useful to provide mitigation services with a picture of normal or "baseline" traffic toward potential targets to aid in detecting when incoming traffic deviates from normal into being an attack. Also, one might populate a "database" of classifications of known types of attacks so that a short attack identifier can be used during an attack period to describe an observed attack. This specification does make provision for use of the DOTS data channel for the latter function (Section 8.1.6) but otherwise retains most telemetry functionality in the DOTS signal channel.
テレメトリー情報には、両方の運用モード（つまり、信号チャネルとデータチャネル）の両方に対応する側面があります。攻撃中に進行中の攻撃トラフィックとターゲットに関する最新の情報を伝える必要があります。適応攻撃に直面した緩和戦略の更新。ただし、潜在的なターゲットへの通常または「ベースライン」トラフィックの写真を緩和サービスに提供して、受信トラフィックが通常から攻撃に逸脱したときの検出を支援するのを支援することも役立ちます。また、既知のタイプの攻撃の分類の「データベース」に入力する可能性があるため、観測された攻撃を記述するために攻撃期間中に短い攻撃識別子を使用できます。この仕様は、後者の関数（セクション8.1.6）にDOTSデータチャネルを使用するための提供を提供しますが、DOTS信号チャネルでほとんどのテレメトリ機能を保持しています。
Note that it is a functional requirement to convey information about ongoing attack traffic during an attack, and information about baseline traffic uses an essentially identical data structure that is naturally defined to sit next to the description of attack traffic. The related telemetry setup information used to parameterize actual traffic data is also sent over the signal channel, out of expediency.
攻撃中に進行中の攻撃トラフィックに関する情報を伝えるための機能的要件であり、ベースライントラフィックに関する情報は、攻撃トラフィックの説明の隣に座るために自然に定義された本質的に同一のデータ構造を使用します。実際のトラフィックデータのパラメーター化に使用される関連するテレメトリセットアップ情報も、便宜から信号チャネルを介して送信されます。
This document specifies an extension to the DOTS signal channel protocol. Considerations about how to establish, maintain, and make use of the DOTS signal channel are specified in [RFC9132].
このドキュメントは、DOTS信号チャネルプロトコルの拡張機能を指定します。[RFC9132]で指定されているDOTS信号チャネルの確立、維持、および使用方法に関する考慮事項。
Once the DOTS signal channel is established, DOTS clients that support the DOTS telemetry extension proceed with the telemetry setup configuration (e.g., measurement interval, telemetry notification interval, pipe capacity, normal traffic baseline) as detailed in Section 7. DOTS agents can then include DOTS telemetry attributes using the DOTS signal channel (Section 8.1). A DOTS client can use separate messages to share with its DOTS server(s) a set of telemetry data bound to an ongoing mitigation (Section 8.2). Also, a DOTS client that is interested in receiving telemetry notifications related to some of its resources follows the procedure defined in Section 8.3. A DOTS client that receives such notifications can then decide to send a mitigation request if an attack cannot be mitigated locally within the DOTS client domain.
DOTS信号チャネルが確立されると、DOTSテレメトリー拡張をサポートするDOTSクライアントは、セクション7で詳述されているように、テレメトリセットアップ構成（測定間隔、テレメトリ通知間隔、パイプ容量、通常のトラフィックベースラインなど）を進めます。DOTSテレメトリ属性属性は、DOTS信号チャネルを使用しています（セクション8.1）。DOTSクライアントは、個別のメッセージを使用して、進行中の緩和に結合したテレメトリデータのセットをDOTSサーバーと共有できます（セクション8.2）。また、いくつかのリソースに関連するテレメトリ通知を受信することに関心のあるDOTSクライアントは、セクション8.3で定義されている手順に従います。そのような通知を受信するDOTSクライアントは、DOTSクライアントドメイン内で攻撃をローカルに緩和できない場合、緩和要求を送信することを決定できます。
Aggregate DOTS telemetry data can also be included in efficacy update (Section 9.1) or mitigation update (Section 9.2) messages.
Aggregate Dots Telemetryデータは、有効性の更新（セクション9.1）または緩和更新（セクション9.2）メッセージにも含めることができます。
DOTS clients can use a block-wise transfer [RFC7959] with the recommendation detailed in Section 4.4.2 of [RFC9132] to control the size of a response when the data to be returned does not fit within a single datagram.
DOTSクライアントは、[RFC9132]のセクション4.4.2に詳述されている推奨事項を使用して、ブロックワイズ転送[RFC7959]を使用して、返されるデータが単一のデータグラム内に収まらない場合の応答のサイズを制御できます。
DOTS clients can also use the Constrained Application Protocol (CoAP) Block1 Option in a PUT request (Section 2.5 of [RFC7959]) to initiate large transfers, but these Block1 transfers are likely to fail if the inbound "pipe" is running full because the transfer requires a message from the server for each block, which would likely be lost in the incoming flood. Consideration needs to be made to try to fit this PUT into a single transfer or to separate out the PUT into several discrete PUTs where each of them fits into a single packet.
DOTSクライアントは、Put Request（[RFC7959]のセクション2.5）で制約付きアプリケーションプロトコル（COAP）Block1オプションを使用して、大きな転送を開始することもできますが、これらのブロック1転送は、インバウンド「パイプ」が完全に動作している場合に失敗する可能性があります。転送には、各ブロックのサーバーからのメッセージが必要であり、これは着信洪水で失われる可能性があります。このプットを単一の転送に取り付けるか、それぞれが単一のパケットに収まるいくつかの個別のプットにプットを分離するために、検討する必要があります。
Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and Block2 Options, but enable robust transmissions of big blocks of data with less packet interchanges using NON messages, are defined in [RFC9177]. DOTS implementations can consider the use of Q-Block1 and Q-Block2 Options [DOTS-Robust-Blocks].
COAP Block1およびBlock2オプションに似ているが、非メッセージを使用したパケットインターチェンジを少なくするデータの大きなブロックの堅牢な送信を有効にするQ-Block1およびQ-Block2オプションは、[RFC9177]で定義されています。DOTS実装では、Q-Block1およびQ-Block2オプション[DOT-Robust-Blocks]の使用を考慮することができます。
Considerations for multihomed DOTS clients to select which DOTS server to contact and which IP prefixes to include in a telemetry message to a given peer DOTS server are discussed in [DOTS-Multihoming]. For example, if each upstream network exposes a DOTS server and the DOTS client maintains DOTS channels with all of them, only the information related to prefixes assigned by an upstream network to the DOTS client domain will be signaled via the DOTS channel established with the DOTS server of that upstream network.
Multihomed Dotsクライアントが、接触するDOTSサーバーと、特定のピアドットサーバーへのテレメトリメッセージに含めるIPプレフィックスを[DOTS-Multihoming]で説明するための考慮事項。たとえば、各アップストリームネットワークがDOTSサーバーを公開し、DOTSクライアントがそれらすべてでDOTSチャネルを維持している場合、DOTSクライアントドメインにアップストリームネットワークによって割り当てられたプレフィックスに関連する情報のみが、DOTSで確立されたDOTSチャネルを介してシグナルになります。そのアップストリームネットワークのサーバー。
Considerations related to whether (and how) a DOTS client gleans some telemetry information (e.g., attack details) it receives from a first DOTS server and shares it with a second DOTS server are implementation and deployment specific.
DOTSクライアントがいくつかのテレメトリ情報（攻撃の詳細など）を収集するかどうかに関連する考慮事項最初のDOTSサーバーから受信し、2番目のDOTSサーバーと共有することは実装および展開固有です。
Telemetry messages exchanged between DOTS agents are serialized using Concise Binary Object Representation (CBOR) [RFC8949]. CBOR-encoded payloads are used to carry signal-channel-specific payload messages that convey request parameters and response information such as errors.
DOTSエージェント間で交換されたテレメトリメッセージは、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]を使用してシリアル化されます。CBORエンコードのペイロードは、要求パラメーターとエラーなどの応答情報を伝える信号チャネル固有のペイロードメッセージを伝達するために使用されます。
This document specifies a YANG module [RFC7950] for representing DOTS telemetry message types (Section 11.1). All parameters in the payload of the DOTS signal channel are mapped to CBOR types as specified in Section 12. As a reminder, Section 3 of [RFC9132] defines the rules for mapping YANG-modeled data to CBOR.
このドキュメントは、DOTSテレメトリメッセージタイプを表すためのYangモジュール[RFC7950]を指定します（セクション11.1）。DOTS信号チャネルのペイロードのすべてのパラメーターは、セクション12で指定されているCBORタイプにマッピングされます。リマインダーとして、[RFC9132]のセクション3は、YangモデルデータをCBORにマッピングするためのルールを定義します。
The DOTS telemetry module (Section 11.1) is not intended to be used via the Network Configuration Protocol (NETCONF) / RESTCONF for DOTS server management purposes. It serves only to provide a data model and encoding following [RFC8791]. Server deviations (Section 5.6.3 of [RFC7950]) are strongly discouraged, as the peer DOTS agent does not have the means to retrieve the list of deviations and thus interoperability issues are likely to be encountered.
DOTSテレメトリモジュール（セクション11.1）は、DOTSサーバー管理の目的でネットワーク構成プロトコル（NetConf） / RESTCONFを介して使用することを意図していません。[RFC8791]に続くデータモデルとエンコードを提供するためだけに機能します。ピアドットエージェントには逸脱のリストを取得する手段がないため、相互運用性の問題が発生する可能性が高いため、サーバーの逸脱（[RFC7950]のセクション5.6.3）は強く落胆しています。
The DOTS telemetry module (Section 11.1) uses "enumerations" rather than "identities" to define units, samples, and intervals because otherwise the namespace identifier "ietf-dots-telemetry" must be included when a telemetry attribute is included (e.g., in a mitigation efficacy update). The use of "identities" is thus suboptimal from the standpoint of message compactness, as message compactness is one of the key requirements for DOTS signal channel messages.
DOTSテレメトリモジュール（セクション11.1）は、「アイデンティティ」ではなく「列挙」を使用してユニット、サンプル、および間隔を定義します。緩和効果の更新）。したがって、メッセージのコンパクトさはドット信号チャネルメッセージの重要な要件の1つであるため、「アイデンティティ」の使用はメッセージコンパクトさの観点から最適です。
The DOTS telemetry module (Section 11.1) includes some lists for which no "key" statement is included. This behavior is compliant with [RFC8791]. The reason for not including these keys is that they are not included in the message body of DOTS requests; such keys are included as mandatory Uri-Paths in requests (Sections 7 and 8). Otherwise, whenever a "key" statement is used in the module, the same definition as the definition provided in Section 7.8.2 of [RFC7950] is assumed.
DOTSテレメトリモジュール（セクション11.1）には、「キー」ステートメントが含まれていないリストが含まれています。この動作は[RFC8791]に準拠しています。これらのキーを含めない理由は、それらがドットリクエストのメッセージ本文に含まれていないためです。このようなキーは、要求において必須のURI-Pathとして含まれています（セクション7および8）。それ以外の場合、モジュールで「キー」ステートメントが使用される場合はいつでも、[RFC7950]のセクション7.8.2で提供されている定義と同じ定義が想定されます。
Some parameters (e.g., low-percentile values) may be associated with different YANG types (e.g., decimal64 and yang:gauge64). To easily distinguish the types of these parameters while using meaningful names, the following suffixes are used:
いくつかのパラメーター（例：低極性値）は、異なるYangタイプ（例：Decimal64およびYang：Gauge64）に関連付けられている場合があります。意味のある名前を使用しながらこれらのパラメーターのタイプを簡単に区別するために、次の接尾辞が使用されます。
+========+==============+==================+
| Suffix | YANG Type | Example |
+========+==============+==================+
| -g | yang:gauge64 | low-percentile-g |
+--------+--------------+------------------+
| -c | container | connection-c |
+--------+--------------+------------------+
| -ps | per second | connection-ps |
+--------+--------------+------------------+
Table 1: Suffixes and YANG Types
表1：接尾辞とヤンの種類
The full tree diagram of the DOTS telemetry module can be generated using the "pyang" tool [PYANG]. That tree is not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for the reader's convenience.
「Pyang」ツール[Pyang]を使用して、DOTSテレメトリモジュールの完全な図を生成できます。その木は長すぎるため、ここには含まれていません（[RFC8340]のセクション3.3）。代わりに、読者の利便性のためにサブツリーが提供されます。
In order to optimize the data exchanged over the DOTS signal channel, this document specifies a second YANG module ("ietf-dots-mapping"; see Section 11.2) that augments the DOTS data channel [RFC8783]. This augmentation can be used during 'idle' time to share the attack mapping details (Section 8.1.5). DOTS clients can use tools, e.g., the YANG Library [RFC8525], to retrieve the list of features and deviations supported by the DOTS server over the data channel.
DOTS信号チャネルで交換されたデータを最適化するために、このドキュメントは、DOTSデータチャネル[RFC8783]を増強する2番目のYangモジュール（「IETF-DOTS-MAPTIN」を参照）を指定します。この増強は、攻撃マッピングの詳細（セクション8.1.5）を共有するために、「アイドル」時間中に使用できます。DOTSクライアントは、ツール、たとえばYang Library [RFC8525]を使用して、データチャネルを介してDOTSサーバーによってサポートされる機能と逸脱のリストを取得できます。
Following the rules in Section 4.4.1 of [RFC9132], a unique identifier is generated by a DOTS client to prevent request collisions ('cuid').
[RFC9132]のセクション4.4.1のルールに従って、要求衝突を防ぐためにDOTSクライアントによって一意の識別子が生成されます（「CUID」）。
As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cuid' to be returned in a response message body.
リマインダーとして、[RFC9132]のセクション4.4.1.3は、「CUID」が応答メッセージ本文で返されることを禁じます。
DOTS gateways may be located between DOTS clients and servers. The considerations elaborated in Section 4.4.1 of [RFC9132] must be followed. In particular, the 'cdid' attribute is used to unambiguously identify a DOTS client domain.
ドットゲートウェイは、ドットクライアントとサーバーの間に配置される場合があります。[RFC9132]のセクション4.4.1で詳しく説明されている考慮事項に従う必要があります。特に、「CDID」属性を使用して、DOTSクライアントドメインを明確に識別します。
As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if present) to be returned in a response message body.
リマインダーとして、[RFC9132]のセクション4.4.1.3は、「CDID」（存在する場合）を応答メッセージ本文で返します。
Uri-Path parameters and attributes with empty values MUST NOT be present in a request. The presence of such an empty value renders the entire containing message invalid.
空の値を持つURI-PATHパラメーターと属性をリクエストに存在しないでください。このような空の値の存在は、含まれるメッセージ全体を無効にします。
The DOTS server follows the same considerations discussed in Section 4.5.3 of [RFC9132] for managing DOTS telemetry configuration freshness and notifications.
DOTSサーバーは、[RFC9132]のセクション4.5.3で説明されている同じ考慮事項に従って、DOTSテレメトリーの構成の鮮度と通知を管理します。
Likewise, a DOTS client may control the selection of configuration and non-configuration data nodes when sending a GET request by means of the 'c' (content) Uri-Query option and following the procedure specified in Section 4.4.2 of [RFC9132]. These considerations are not reiterated in the following sections.
同様に、DOTSクライアントは、「C」（コンテンツ）URI-Queryオプションを使用してGETリクエストを送信するときに、[RFC9132]のセクション4.4.2で指定された手順に従うときに、構成および非構成データノードの選択を制御できます。。これらの考慮事項は、次のセクションでは繰り返されません。
The authoritative references for validating telemetry messages exchanged over the DOTS signal channel are Sections 7, 8, and 9 together with the mapping table provided in Section 12. The structure of telemetry message bodies is represented as a YANG data structure (Section 11.1).
DOTS信号チャネルで交換されたテレメトリメッセージを検証するための権威ある参照は、セクション7、8、および9とともにセクション12に記載されているマッピングテーブルです。テレメトリメッセージボディの構造は、Yangデータ構造として表されます（セクション11.1）。
Examples are provided for illustration purposes. This document does not aim to provide a comprehensive list of message examples.
例は、イラストの目的で提供されています。このドキュメントは、メッセージ例の包括的なリストを提供することを目的としていません。
JSON encoding of YANG-modeled data is used to illustrate the various telemetry operations. To ease readability, parameter names and their JSON types are thus used in the examples rather than their CBOR key values and CBOR types following the mappings in Section 12. These conventions are inherited from [RFC9132].
Yangモデル化データのJSONエンコードは、さまざまなテレメトリ操作を説明するために使用されます。読みやすさを容易にするために、パラメーター名とそのJSONタイプは、セクション12のマッピングに続くCBORキー値とCBORタイプではなく、例で使用されます。これらの規則は[RFC9132]から継承されます。
The examples use Enterprise Number 32473, which is defined for documentation use; see [RFC5612].
例では、ドキュメントの使用のために定義されているエンタープライズ番号32473を使用しています。[RFC5612]を参照してください。
As discussed in Section 4.2 of [RFC9132], each DOTS operation is indicated by a path suffix that indicates the intended operation. The operation path is appended to the path prefix to form the URI used with a CoAP request to perform the desired DOTS operation. The following telemetry path suffixes are defined (Table 2):
[RFC9132]のセクション4.2で説明したように、各ドット操作は、意図した動作を示すパスサフィックスで示されています。操作パスは、PATHプレフィックスに追加され、COAPリクエストで使用されるURIを形成して目的のDOTS操作を実行します。次のテレメトリパスの接尾辞が定義されています（表2）：
+=================+================+===========+
| Operation | Operation Path | Details |
+=================+================+===========+
| Telemetry Setup | /tm-setup | Section 7 |
+-----------------+----------------+-----------+
| Telemetry | /tm | Section 8 |
+-----------------+----------------+-----------+
Table 2: DOTS Telemetry Operations
表2：ドットテレメトリー操作
Consequently, the "ietf-dots-telemetry" YANG module defined in Section 11.1 defines a data structure to represent new DOTS message types called 'telemetry-setup' and 'telemetry'. The tree structure is shown in Figure 1. More details are provided in Sections 7 and 8 about the exact structure of 'telemetry-setup' and 'telemetry' message types.
したがって、セクション11.1で定義された「IETF-DOTS-TELEMETRY」Yangモジュールは、「テレメトリーセットアップ」と「テレメトリー」と呼ばれる新しいドットメッセージタイプを表すデータ構造を定義します。ツリー構造を図1に示します。詳細は、「テレメトリセットアップ」および「テレメトリ」メッセージタイプの正確な構造についてセクション7および8に記載されています。
structure dots-telemetry:
+-- (telemetry-message-type)?
+--:(telemetry-setup)
| ...
| +-- telemetry* []
| ...
| +-- (setup-type)?
| +--:(telemetry-config)
| | ...
| +--:(pipe)
| | ...
| +--:(baseline)
| ...
+--:(telemetry)
...
Figure 1: New DOTS Message Types (YANG Tree Structure)
図1：新しいドットメッセージタイプ（ヤンツリー構造）
DOTS implementations MUST support the Observe Option [RFC7641] for 'tm' (Section 8).
ドットの実装は、「TM」（セクション8）の観察オプション[RFC7641]をサポートする必要があります。
In reference to Figure 1, a DOTS telemetry setup message MUST include only telemetry-related configuration parameters (Section 7.1), information about DOTS client domain pipe capacity (Section 7.2), or information about the telemetry traffic baseline (Section 7.3). As such, requests that include a mix of telemetry configuration, pipe capacity, and traffic baseline information MUST be rejected by DOTS servers with a 4.00 (Bad Request) Response Code.
図1を参照すると、DOTSテレメトリセットアップメッセージには、テレメトリー関連の構成パラメーター（セクション7.1）、DOTSクライアントドメインパイプ容量に関する情報（セクション7.2）、またはテレメトリートラフィックベースラインに関する情報のみを含める必要があります。そのため、テレメトリー構成、パイプ容量、トラフィックベースライン情報の組み合わせを含むリクエストは、4.00（悪い要求）応答コードを備えたDOTSサーバーによって拒否される必要があります。
A DOTS client can reset all installed DOTS telemetry setup configuration data following the considerations detailed in Section 7.4.
DOTSクライアントは、セクション7.4で詳述されている考慮事項に従って、インストールされているすべてのDOTSテレメトリセットアップ構成データをリセットできます。
A DOTS server may detect conflicts when processing requests related to DOTS client domain pipe capacity or telemetry traffic baseline information with requests from other DOTS clients of the same DOTS client domain. More details are included in Section 7.5.
DOTSサーバーは、同じDOTSクライアントドメインの他のDOTSクライアントからの要求を使用して、DOTSクライアントドメインパイプ容量またはテレメトリートラフィックベースライン情報に関連するリクエストを処理するときに競合を検出する場合があります。詳細については、セクション7.5に含まれています。
Telemetry setup configuration is bound to a DOTS client domain. DOTS servers MUST NOT expect DOTS clients to send regular requests to refresh the telemetry setup configuration. Any available telemetry setup configuration is valid until the DOTS server ceases to service a DOTS client domain. DOTS servers MUST NOT reset 'tsid' because a session failed with a DOTS client. DOTS clients update their telemetry setup configuration upon change of a parameter that may impact attack mitigation.
テレメトリのセットアップ構成は、DOTSクライアントドメインにバインドされています。DOTSサーバーは、DOTSクライアントがテレメトリーセットアップの構成を更新するために定期的なリクエストを送信することを期待してはなりません。利用可能なテレメトリセットアップ構成は、DOTSサーバーがDOTSクライアントドメインのサービスをやめるまで有効です。ドットサーバーは、セッションがDOTSクライアントで失敗したため、「TSID」をリセットしてはなりません。DOTSクライアントは、攻撃緩和に影響を与える可能性のあるパラメーターの変更時に、テレメトリセットアップ構成を更新します。
DOTS telemetry setup configuration request and response messages are marked as Confirmable messages (Section 2.1 of [RFC7252]).
DOTSテレメトリセットアップ構成要求と応答メッセージは、確認可能なメッセージとしてマークされています（[RFC7252]のセクション2.1）。
DOTS telemetry uses several percentile values to provide a picture of a traffic distribution overall, as opposed to just a single snapshot of observed traffic at a single point in time. Modeling raw traffic flow data as a distribution and describing that distribution entails choosing a measurement period that the distribution will describe, and a number of sampling intervals, or "buckets", within that measurement period. Traffic within each bucket is treated as a single event (i.e., averaged), and then the distribution of buckets is used to describe the distribution of traffic over the measurement period. A distribution can be characterized by statistical measures (e.g., mean, median, and standard deviation) and also by reporting the value of the distribution at various percentile levels of the data set in question (e.g., "quartiles" that correspond to 25th, 50th, and 75th percentiles). More details about percentile values and their computation are found in Section 11.3 of [RFC2330].
Dots Telemetryは、いくつかのパーセンタイル値を使用して、単一の時点で観測されたトラフィックの単一のスナップショットとは対照的に、全体的なトラフィック分布の画像を提供します。生のトラフィックフローデータを分布としてモデル化し、分布が分布が記述する測定期間と、その測定期間内に多数のサンプリング間隔（バケット」を選択することを伴うことを記述することが必要です。各バケット内のトラフィックは、単一のイベント（つまり、平均化）として扱われ、バケットの分布を使用して、測定期間にわたるトラフィックの分布を記述します。分布は、統計的測定（平均、中央値、標準偏差など）、および問題のデータセットのさまざまなパーセンタイルレベルでの分布の値を報告することを特徴とすることができます（例：25、50に対応する「四分位数」、および75パーセンタイル）。パーセンタイル値とその計算の詳細については、[RFC2330]のセクション11.3に記載されています。
DOTS telemetry uses up to three percentile values, plus the overall peak, to characterize traffic distributions. Which percentile thresholds are used for these "low-percentile", "mid-percentile", and "high-percentile" values is configurable. Default values are defined in Section 7.1.2.
Dots Telemetryは、最大3パーセンタイルの値と全体的なピークを使用して、トラフィック分布を特徴付けます。これらの「低能力」、「中濃度」、および「高濃度」値に使用されるパーセンタイルのしきい値は、構成可能です。デフォルト値は、セクション7.1.2で定義されています。
A DOTS client can negotiate with its server(s) a set of telemetry configuration parameters to be used for telemetry. Such parameters include:
DOTSクライアントは、テレメトリに使用するテレメトリー構成パラメーターのセットをサーバーと交渉できます。このようなパラメーターには以下が含まれます。
* Percentile-related measurement parameters. In particular, 'measurement-interval' defines the period during which percentiles are computed, while 'measurement-sample' defines the time distribution for measuring values that are used to compute percentiles.
* パーセンタイル関連の測定パラメーター。特に、「測定間存在」は、パーセンタイルが計算される期間を定義し、「測定サンプル」はパーセンタイルを計算するために使用される値を測定する時間分布を定義します。
* Measurement units.
* 測定単位。
* Acceptable percentile values.
* 許容可能なパーセンタイル値。
* Telemetry notification interval.
* テレメトリー通知間隔。
* Acceptable server-originated telemetry.
* 許容可能なサーバー発生テレメトリ。
A GET request is used to obtain acceptable and current telemetry configuration parameters on the DOTS server. This request may include a 'cdid' Uri-Path when the request is relayed by a DOTS gateway. An example of such a GET request (without a gateway) is depicted in Figure 2.
GETリクエストは、DOTSサーバーで許容可能な現在のテレメトリ構成パラメーターを取得するために使用されます。このリクエストには、要求がドットゲートウェイによって中継された場合、「cdid」uri-pathが含まれる場合があります。このようなGETリクエストの例（ゲートウェイなし）を図2に示します。
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 2: GET to Retrieve the Current and Acceptable DOTS Telemetry Configuration
図2：現在および許容可能なドットテレメトリ構成を取得してください
Upon receipt of such a request, and assuming that no error is encountered when processing the request, the DOTS server replies with a 2.05 (Content) response that conveys the telemetry parameters that are acceptable to the DOTS server, any pipe information (Section 7.2), and the current baseline information (Section 7.3) maintained by the DOTS server for this DOTS client. The tree structure of the response message body is provided in Figure 3.
そのような要求を受信し、要求の処理時にエラーが発生しないと仮定すると、DOTSサーバーは、DOTSサーバー、パイプ情報に許容できるテレメトリパラメーターを伝える2.05（コンテンツ）応答で応答します（セクション7.2）、およびこのDOTSクライアントのDOTSサーバーによって維持されている現在のベースライン情報（セクション7.3）。応答メッセージ本文のツリー構造を図3に示します。
DOTS servers that support the capability of sending telemetry information to DOTS clients prior to or during a mitigation (Section 9.2) set 'server-originated-telemetry' under 'max-config-values' to 'true' ('false' is used otherwise). If 'server-originated-telemetry' is not present in a response, this is equivalent to receiving a response with 'server-originated-telemetry' set to 'false'.
緩和前または緩和中にテレメトリー情報をDOTSクライアントに送信する機能をサポートするドットサーバー（セクション9.2）は、「Max-Config-Values」の下で「サーバーオリジネートテレメトリ」を「True」に設定します（それ以外の場合は「False」が使用されます。）。「サーバーオリジネートテレメトリー」が応答に存在しない場合、これは「false」に設定された「サーバーオリジネートテレメトリ」を使用して応答を受信することに相当します。
structure dots-telemetry:
+-- (telemetry-message-type)?
+--:(telemetry-setup)
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-config-values
| | | +-- measurement-interval? interval
| | | +-- measurement-sample? sample
| | | +-- low-percentile? percentile
| | | +-- mid-percentile? percentile
| | | +-- high-percentile? percentile
| | | +-- server-originated-telemetry? boolean
| | | +-- telemetry-notify-interval? uint16
| | +-- min-config-values
| | | +-- measurement-interval? interval
| | | +-- measurement-sample? sample
| | | +-- low-percentile? percentile
| | | +-- mid-percentile? percentile
| | | +-- high-percentile? percentile
| | | +-- telemetry-notify-interval? uint16
| | +-- supported-unit-classes
| | | +-- unit-config* [unit]
| | | +-- unit unit-class
| | | +-- unit-status boolean
| | +-- supported-query-type* query-type
| +-- telemetry* []
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- tsid? uint32
| +-- (setup-type)?
| +--:(telemetry-config)
| | +-- current-config
| | +-- measurement-interval? interval
| | +-- measurement-sample? sample
| | +-- low-percentile? percentile
| | +-- mid-percentile? percentile
| | +-- high-percentile? percentile
| | +-- unit-config* [unit]
| | | +-- unit unit-class
| | | +-- unit-status boolean
| | +-- server-originated-telemetry? boolean
| | +-- telemetry-notify-interval? uint16
| +--:(pipe)
| | ...
| +--:(baseline)
| ...
+--:(telemetry)
...
Figure 3: Telemetry Configuration Tree Structure
図3：テレメトリー構成ツリー構造
When both 'min-config-values' and 'max-config-values' attributes are present, the values carried in 'max-config-values' attributes MUST be greater than or equal to their counterparts in 'min-config-values' attributes.
「min-config-values」と「max-config-values」属性の両方が存在する場合、「max-config-values」属性に掲載される値は、「min-config-values」のカウンターパート以上でなければなりません。属性。
A PUT request is used to convey the configuration parameters for the telemetry data (e.g., low-, mid-, or high-percentile values). For example, a DOTS client may contact its DOTS server to change the default percentile values used as the baseline for telemetry data. Figure 3 lists the attributes that can be set by a DOTS client in such a PUT request. An example of a DOTS client that modifies all percentile reference values is shown in Figure 4.
PUTリクエストは、テレメトリデータの構成パラメーターを伝えるために使用されます（たとえば、低、中央、または高セントリの値）。たとえば、DOTSクライアントはDOTSサーバーに連絡して、テレメトリデータのベースラインとして使用されるデフォルトのパーセンタイル値を変更する場合があります。図3に、このようなプットリクエストでDOTSクライアントが設定できる属性を示します。すべてのパーセンタイル参照値を変更するDOTSクライアントの例を図4に示します。
Note: The payload of the message depicted in Figure 4 is CBOR- encoded as indicated by setting the Content-Format entry to "application/dots+cbor" (Section 10.3 of [RFC9132]). However, and for the sake of better readability, the example (and other similar figures depicting a DOTS telemetry message body) follows the conventions set in Section 5.6: use the JSON names and types defined in Section 12.
注：図4に描かれているメッセージのペイロードは、コンテンツフォーマットエントリを「アプリケーション/ドットCBOR」に設定することで示されているようにcbor-エンコードされています（[RFC9132]のセクション10.3）。ただし、より良い読みやすさのために、例（およびドットテレメトリメッセージ本体を描いた他の同様の図）は、セクション5.6：セクション12で定義されているJSON名とタイプを使用して設定された規則に従います。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"current-config": {
"low-percentile": "5.00",
"mid-percentile": "65.00",
"high-percentile": "95.00"
}
}
]
}
}
Figure 4: PUT to Convey the DOTS Telemetry Configuration, Depicted as per Section 5.6
図4：セクション5.6に従って描かれているドットテレメトリー構成を伝えるために置かれます
'cuid' is a mandatory Uri-Path parameter for PUT requests.
「CUID」は、PUTリクエストのための必須のURI-PATHパラメーターです。
The following additional Uri-Path parameter is defined:
次の追加のURI-PATHパラメーターが定義されています。
tsid: The Telemetry Setup Identifier is an identifier for the DOTS telemetry setup configuration data represented as an integer. This identifier MUST be generated by DOTS clients. 'tsid' values MUST increase monotonically whenever new configuration parameters (not just for changed values) need to be conveyed by the DOTS client.
TSID：Telemetryセットアップ識別子は、整数として表されるDOTS Telemetryセットアップ構成データの識別子です。この識別子は、DOTSクライアントによって生成される必要があります。「TSID」値は、DOTSクライアントによって新しい構成パラメーター（変化した値だけでなく）を伝える必要がある場合は、単調に増加する必要があります。
The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' rollover MUST also be followed for 'tsid' rollover.
[MID]ロールオーバーの[RFC9132]のセクション4.4.1で指定された手順には、「TSID」ロールオーバーにも従う必要があります。
This is a mandatory attribute. 'tsid' MUST appear after 'cuid' in the Uri-Path options.
これは必須の属性です。URI-Pathオプションに「CUID」の後に「TSID」が表示されなければなりません。
'cuid' and 'tsid' MUST NOT appear in the PUT request message body.
「CUID」と「TSID」は、Put Request Message Bodyに表示されてはなりません。
At least one configurable attribute MUST be present in the PUT request.
PUTリクエストには、少なくとも1つの構成可能な属性が存在する必要があります。
A PUT request with a higher numeric 'tsid' value overrides the DOTS telemetry configuration data installed by a PUT request with a lower numeric 'tsid' value. To avoid maintaining a long list of 'tsid' requests for requests carrying telemetry configuration data from a DOTS client, the lower numeric 'tsid' MUST be automatically deleted and no longer be available at the DOTS server.
高い数値「TSID」値を持つPUTリクエストは、低い数値「TSID」値を持つPUTリクエストによってインストールされたDOTSテレメトリー構成データをオーバーライドします。DOTSクライアントからテレメトリー構成データを運ぶリクエストの「TSID」要求の長いリストを維持することを避けるために、低い数値「TSID」を自動的に削除し、DOTSサーバーで使用できなくなる必要があります。
The DOTS server indicates the result of processing the PUT request using the following Response Codes:
DOTSサーバーは、次の応答コードを使用してPUTリクエストを処理した結果を示します。
* If the request is missing a mandatory attribute, does not include 'cuid' or 'tsid' Uri-Path parameters, or contains one or more invalid or unknown parameters, a 4.00 (Bad Request) Response Code MUST be returned in the response.
* 要求に必須属性が欠落している場合、「CUID」または「TSID」URI-PATHパラメーターが含まれていない場合、または1つ以上の無効または不明なパラメーターが含まれている場合、応答に4.00（悪い要求）応答コードを返す必要があります。
* If the DOTS server does not find the 'tsid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the configuration parameters, then a 2.01 (Created) Response Code MUST be returned in the response.
* DOTSサーバーがその構成データのPUT要求で伝達された「TSID」パラメーター値を見つけられず、DOTSサーバーが構成パラメーターを受け入れた場合、2.01（作成）応答コードを応答で返す必要があります。
* If the DOTS server finds the 'tsid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the updated configuration parameters, a 2.04 (Changed) Response Code MUST be returned in the response.
* DOTSサーバーが構成データのPUTリクエストで伝達された「TSID」パラメーター値を見つけた場合、DOTSサーバーが更新された構成パラメーターを受け入れた場合、応答で2.04（変更）応答コードを返す必要があります。
* If any of the enclosed configurable attribute values are not acceptable to the DOTS server (Section 7.1.1), a 4.22 (Unprocessable Entity) Response Code MUST be returned in the response.
* 囲まれた構成可能な属性値のいずれかがDOTSサーバーに受け入れられない場合（セクション7.1.1）、応答で4.22（処理不可能なエンティティ）応答コードを返す必要があります。
The DOTS client may retry and send the PUT request with updated attribute values acceptable to the DOTS server.
DOTSクライアントは、DOTSサーバーに受け入れられる更新された属性値を使用して、プットリクエストを再試行して送信できます。
By default, low-percentile (10th percentile), mid-percentile (50th percentile), high-percentile (90th percentile), and peak (100th percentile) values are used to represent telemetry data. Nevertheless, a DOTS client can disable some percentile types (low, mid, high). In particular, setting 'low-percentile' to "0.00" indicates that the DOTS client is not interested in receiving low-percentiles. Likewise, setting 'mid-percentile' (or 'high-percentile') to the same value as 'low-percentile' (or 'mid-percentile') indicates that the DOTS client is not interested in receiving mid-percentiles (or high-percentiles). For example, a DOTS client can send the request depicted in Figure 5 to inform the server that it is interested in receiving only high-percentiles. This assumes that the client will only use that percentile type when sharing telemetry data with the server.
デフォルトでは、テレメトリデータを表すために、低粒子（10パーセンタイル）、ミッドセントリ（50パーセンタイル）、高セントリ（90パーセンタイル）、ピーク（100パーセンタイル）値を使用します。それにもかかわらず、DOTSクライアントはいくつかのパーセンタイルタイプ（低、中、高）を無効にすることができます。特に、「低頻度」を「0.00」に設定すると、DOTSクライアントが低能力を受信することに関心がないことがわかります。同様に、「中程度のセクタイル」（または「高濃度」）を「低能力」（または「中程度」）と同じ値に設定することは、DOTSクライアントが中程度のセントル（または高い）を受信することに関心がないことを示しています。-CERTILES）。たとえば、DOTSクライアントは、図5に示されているリクエストを送信して、高容量のみを受信することに関心があることをサーバーに通知できます。これは、クライアントがサーバーとテレメトリデータを共有するときにそのパーセンタイルタイプのみを使用することを前提としています。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=124"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"current-config": {
"low-percentile": "0.00",
"mid-percentile": "0.00",
"high-percentile": "95.00"
}
}
]
}
}
Figure 5: PUT to Disable Low- and Mid-Percentiles, Depicted as per Section 5.6
図5：セクション5.6に従って描写されている低穴および中央部の中央部と中央部の無効化を無効にする
DOTS clients can also configure the unit class(es) to be used for traffic-related telemetry data among the following supported unit classes: packets per second, bits per second, and bytes per second. Supplying both bits per second and bytes per second unit classes is allowed for a given set of telemetry data. However, receipt of conflicting values is treated as invalid parameters and rejected with a 4.00 (Bad Request) Response Code.
DOTSクライアントは、次のサポートされているユニットクラスの間で、トラフィック関連のテレメトリデータに使用するユニットクラス（ES）を構成することもできます。1秒あたりのビットと1秒あたりのバイトクラスの両方を供給すると、特定のテレメトリデータセットが許可されます。ただし、競合する値の受領は無効なパラメーターとして扱われ、4.00（悪い要求）応答コードで拒否されます。
DOTS clients that are interested in receiving pre-or-ongoing-mitigation telemetry ('pre-or-ongoing-mitigation') information from a DOTS server (Section 9.2) MUST set 'server-originated-telemetry' to 'true'. If 'server-originated-telemetry' is not present in a PUT request, this is equivalent to receiving a request with 'server-originated-telemetry' set to 'false'. An example of a request to enable pre-or-ongoing-mitigation telemetry from DOTS servers is shown in Figure 6.
DOTSサーバー（セクション9.2）から事前またはソングミチゲーションテレメトリ（「事前またはソングミチゲーション」）の情報を受信することに関心のあるDOTSクライアントは、「サーバーに起因するテレメトリ」を「True」に設定する必要があります。「Server-Originated-Telemetry」がPUTリクエストに存在しない場合、これは「Server-Originated-Telemetry」が「False」に設定されているリクエストを受信することと同等です。DOTSサーバーからの事前またはソング緩和のテレメトリを有効にするリクエストの例を図6に示します。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=125"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"current-config": {
"server-originated-telemetry": true
}
}
]
}
}
Figure 6: PUT to Enable Pre-or-Ongoing-Mitigation Telemetry from the DOTS Server, Depicted as per Section 5.6
図6：セクション5.6に従って描写されているDOTSサーバーからの事前またはソング緩和テレメトリを有効にするためにPUT
A DOTS client may issue a GET message with a 'tsid' Uri-Path parameter to retrieve the current DOTS telemetry configuration. An example of such a request is depicted in Figure 7.
DOTSクライアントは、「TSID」URI-PATHパラメーターを使用してGETメッセージを発行して、現在のDOTSテレメトリ構成を取得できます。このような要求の例を図7に示します。
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"
Figure 7: GET to Retrieve the Current DOTS Telemetry Configuration
図7：現在のドットテレメトリー構成を取得してください
If the DOTS server does not find the 'tsid' Uri-Path value conveyed in the GET request in its configuration data for the requesting DOTS client, it MUST respond with a 4.04 (Not Found) error Response Code.
DOTSサーバーが、要求するDOTSクライアントの構成データのGETリクエストで伝達された「TSID」URI-PATH値を見つけられない場合、4.04（発見されていない）エラー応答コードで応答する必要があります。
A DELETE request is used to delete the installed DOTS telemetry configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri-Path parameters for such DELETE requests.
削除要求を使用して、インストールされているドットテレメトリー構成データを削除します（図8）。「CUID」と「TSID」は、このような削除要求のための必須のURI-PATHパラメーターです。
Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"
Figure 8: Deleting the Telemetry Configuration
図8：テレメトリー構成の削除
The DOTS server resets the DOTS telemetry configuration back to the default values and acknowledges a DOTS client's request to remove the DOTS telemetry configuration using a 2.02 (Deleted) Response Code. A 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter value conveyed in the DELETE request does not exist in its configuration data before the request.
DOTSサーバーは、DOTSテレメトリ構成をデフォルト値に戻し、2.02（削除）応答コードを使用してDOTSテレメトリ構成を削除するDOTSクライアントの要求を確認します。削除要求に伝えられた「TSID」パラメーター値が、リクエスト前に構成データに存在しない場合でも、2.02（削除）応答コードが返されます。
Section 7.4 discusses the procedure to reset all DOTS telemetry setup configuration data.
セクション7.4では、すべてのDOTSテレメトリセットアップ構成データをリセットする手順について説明します。
A DOTS client can communicate to the DOTS server(s) its DOTS client domain pipe information. The tree structure of the pipe information is shown in Figure 9.
DOTSクライアントは、DOTSサーバーにDOTSクライアントドメインパイプ情報と通信できます。パイプ情報のツリー構造を図9に示します。
structure dots-telemetry:
+-- (telemetry-message-type)?
+--:(telemetry-setup)
| ...
| +-- telemetry* []
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- tsid? uint32
| +-- (setup-type)?
| +--:(telemetry-config)
| | ...
| +--:(pipe)
| | +-- total-pipe-capacity* [link-id unit]
| | +-- link-id nt:link-id
| | +-- capacity uint64
| | +-- unit unit
| +--:(baseline)
| ...
+--:(telemetry)
...
Figure 9: Pipe Tree Structure
図9：パイプツリー構造
A DOTS client domain pipe is defined as a list of limits on (incoming) traffic volume ('total-pipe-capacity') that can be forwarded over ingress interconnection links of a DOTS client domain. Each of these links is identified with a 'link-id' [RFC8345].
DOTSクライアントドメインパイプは、DOTSクライアントドメインのイングレス相互接続リンク上で転送できる（「入力）トラフィックボリューム（「合計パイプ容量」）の制限のリストとして定義されます。これらの各リンクは、「Link-ID」[RFC8345]で識別されます。
The unit used by a DOTS client when conveying pipe information is captured in the 'unit' attribute. The DOTS client MUST auto-scale so that the appropriate unit is used. That is, for a given unit class, the DOTS client uses the largest unit that gives a value greater than one. As such, only one unit per unit class is allowed.
パイプ情報を伝えるときにDOTSクライアントが使用するユニットは、「ユニット」属性でキャプチャされます。DOTSクライアントは、適切なユニットが使用されるように自動スケールする必要があります。つまり、特定のユニットクラスでは、DOTSクライアントは、1より大きい値を提供する最大のユニットを使用します。そのため、許可されているユニットクラスごとに1つのユニットのみが許可されています。
Considerations similar to those specified in Section 7.1.2 are followed, with one exception:
セクション7.1.2で指定されているものと同様の考慮事項に従って、1つの例外を除きます。
* The relative order of two PUT requests carrying DOTS client domain pipe attributes from a DOTS client is determined by comparing their respective 'tsid' values. If these two requests have overlapping 'link-id' and 'unit' settings, the PUT request with a higher numeric 'tsid' value will override the request with a lower numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be automatically deleted and no longer be available.
* ドットクライアントドメインパイプ属性を運ぶ2つのプット要求の相対順序は、それぞれの「TSID」値を比較することによって決定されます。これらの2つの要求に「Link-ID」と「ユニット」設定が重複している場合、より高い数値の「TSID」値を持つPUTリクエストは、低い数値「TSID」値でリクエストをオーバーライドします。オーバーラップされた低数値「TSID」は自動的に削除され、使用できなくなる必要があります。
DOTS clients SHOULD minimize the number of active 'tsid's used for pipe information. In order to avoid maintaining a long list of 'tsid's for pipe information, it is RECOMMENDED that DOTS clients include in any request to update information related to a given link the information regarding other links (already communicated using a lower 'tsid' value). By doing so, this update request will override these existing requests and hence optimize the number of 'tsid' requests per DOTS client.
DOTSクライアントは、パイプ情報に使用されるアクティブな 'TSIDの数を最小限に抑える必要があります。パイプ情報の「TSID」の長いリストを維持することを避けるために、DOTSクライアントは、特定のリンクに関連する情報を更新するリクエストに、他のリンクに関する情報を更新することをお勧めします（既に「TSID」値を使用して通信しています）。そうすることで、この更新要求はこれらの既存の要求をオーバーライドし、したがって、ドットクライアントごとの「TSID」要求の数を最適化します。
Note: This assumes that all link information can fit in one single message.
注：これは、すべてのリンク情報が1つのメッセージに収まることを前提としています。
As an example of configuring pipe information, a DOTS client managing a single-homed domain (Figure 10) can send a PUT request (shown in Figure 11) to communicate the capacity of "link1" used to connect to its ISP.
パイプ情報の構成の例として、単一給屋ドメインを管理するDOTSクライアント（図10）は、ISPに接続するために使用される「link1」の容量を通信するために、プット要求（図11を参照）を送信できます。
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--'
Figure 10: Single-Homed DOTS Client Domain
図10：シングルホームドットクライアントドメイン
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=126"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"total-pipe-capacity": [
{
"link-id": "link1",
"capacity": "500",
"unit": "megabit-ps"
}
]
}
]
}
}
Figure 11: Example of a PUT Request to Convey Pipe Information (Single-Homed), Depicted as per Section 5.6
図11：セクション5.6に従って描かれているパイプ情報を伝えるためのプットリクエストの例（単一給料）
DOTS clients may be instructed to signal a link aggregate instead of individual links. For example, a DOTS client that manages a DOTS client domain having two interconnection links with an upstream ISP (Figure 12) can send a PUT request (shown in Figure 13) to communicate the aggregate link capacity with its ISP. Signaling individual or aggregate link capacity is deployment specific.
DOTSクライアントは、個々のリンクではなくリンク集計を信号するように指示される場合があります。たとえば、上流のISPとの2つの相互接続リンクを持つDOTSクライアントドメインを管理するDOTSクライアント（図12）は、ISPと集約リンク容量を通信するPutリクエスト（図13を参照）を送信できます。シグナリング個別または骨材リンク容量は展開固有です。
,--,--,--. ,--,--,--.
,-' `-.===== ,-' `-.
( DOTS Client ) ( ISP#C )
`-. Domain ,-'====== `-. ,-'
`--'--'--' `--'--'--'
Figure 12: DOTS Client Domain with Two Interconnection Links
図12：2つの相互接続リンクを備えたDOTSクライアントドメイン
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin"
Uri-Path: "tsid=896"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"total-pipe-capacity": [
{
"link-id": "aggregate",
"capacity": "700",
"unit": "megabit-ps"
}
]
}
]
}
}
Figure 13: Example of a PUT Request to Convey Pipe Information (Aggregated Link), Depicted as per Section 5.6
図13：セクション5.6に従って描かれているパイプ情報を伝えるためのプット要求の例（集約リンク）
Now consider that the DOTS client domain was upgraded to connect to an additional ISP (e.g., ISP#B in Figure 14); the DOTS client can inform a DOTS server that is not hosted with ISP#A and ISP#B domains about this update by sending the PUT request depicted in Figure 15. This request also includes information related to "link1" even if that link is not upgraded. Upon receipt of this request, the DOTS server removes the request with 'tsid=126' and updates its configuration base to maintain two links (link1 and link2).
ここで、DOTSクライアントドメインがアップグレードされて追加のISPに接続されたことを考慮してください（たとえば、図14のISP＃B）。DOTSクライアントは、図15に描かれたPutリクエストを送信することにより、この更新に関するISP＃AおよびISP＃BドメインでホストされていないDOTSサーバーに通知できます。アップグレード。このリクエストを受け取ると、DOTSサーバーは「TSID = 126」でリクエストを削除し、その構成ベースを2つのリンク（LINK1とLINK2）を維持するように更新します。
,--,--,--.
,-' `-.
( ISP#B )
`-. ,-'
`--'--'--'
||
|| link2
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--'
Figure 14: Multihomed DOTS Client Domain
図14：マルチホームドットクライアントドメイン
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=127"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"total-pipe-capacity": [
{
"link-id": "link1",
"capacity": "500",
"unit": "megabit-ps"
},
{
"link-id": "link2",
"capacity": "500",
"unit": "megabit-ps"
}
]
}
]
}
}
Figure 15: Example of a PUT Request to Convey Pipe Information (Multihomed), Depicted as per Section 5.6
図15：セクション5.6に従って描かれているパイプ情報を伝えるためのプットリクエストの例（マルチホーム）
A DOTS client can delete a link by sending a PUT request with the 'capacity' attribute set to "0" if other links are still active for the same DOTS client domain. For example, if a DOTS client domain re-homes (that is, it changes its ISP), the DOTS client can inform its DOTS server about this update (e.g., from the network configuration in Figure 10 to the network configuration shown in Figure 16) by sending the PUT request depicted in Figure 17. Upon receipt of this request, and assuming that no error is encountered when processing the request, the DOTS server removes "link1" from its configuration bases for this DOTS client domain. Note that if the DOTS server receives a PUT request with a 'capacity' attribute set to "0" for all included links, it MUST reject the request with a 4.00 (Bad Request) Response Code. Instead, the DOTS client can use a DELETE request to delete all links (Section 7.2.3).
DOTSクライアントは、同じDOTSクライアントドメインに対して他のリンクがまだアクティブである場合、「容量」属性を「0」に設定したPUTリクエストを送信することにより、リンクを削除できます。たとえば、DOTSクライアントドメインの再ホーム（つまり、ISPが変更されます）の場合、DOTSクライアントはこの更新についてDOTSサーバーに通知できます（たとえば、図10のネットワーク構成から図16に示すネットワーク構成まで）図17に描かれたプット要求を送信することにより、この要求を受け取ると、リクエストの処理時にエラーが発生しないと仮定すると、DOTSサーバーは、このDOTSクライアントドメインの構成ベースから「link1」を削除します。DOTSサーバーが、含まれているすべてのリンクに対して「容量」属性が「0」に設定されたPUTリクエストを受信する場合、4.00（悪い要求）応答コードでリクエストを拒否する必要があることに注意してください。代わりに、DOTSクライアントは削除要求を使用して、すべてのリンクを削除できます（セクション7.2.3）。
,--,--,--. ,-' `-. ( ISP#B ) `-. ,-' `--'--'--' || || link2 ,--,--,--. ,-' `-. ( DOTS Client ) `-. Domain ,-' `--'--'--'
、 - 、 - 、 - 。、 - '` - 。（ISP＃B） ` - 。、 - '` - ' - '-- '||||link2、 - 、 - 、 - 。、 - '` - 。（ドットクライアント） ` - 。ドメイン、 - '` - '---'
Figure 16: Multihomed DOTS Client Domain
図16：マルチホームドットクライアントドメイン
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=128"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"total-pipe-capacity": [
{
"link-id": "link1",
"capacity": "0",
"unit": "megabit-ps"
},
{
"link-id": "link2",
"capacity": "500",
"unit": "megabit-ps"
}
]
}
]
}
}
Figure 17: Example of a PUT Request to Convey Pipe Information (Multihomed), Depicted as per Section 5.6
図17：セクション5.6に従って描かれているパイプ情報を伝えるためのプットリクエストの例（マルチホーム）
A GET request with a 'tsid' Uri-Path parameter is used to retrieve the specific information related to an installed DOTS client domain pipe. The same procedure as that defined in Section 7.1.3 is followed.
「TSID」URI-PATHパラメーターを使用したGETリクエストは、インストールされているDOTSクライアントドメインパイプに関連する特定の情報を取得するために使用されます。セクション7.1.3で定義されているものと同じ手順に従います。
To retrieve all pipe information bound to a DOTS client, the DOTS client proceeds as specified in Section 7.1.1.
DOTSクライアントにバインドされたすべてのパイプ情報を取得するために、DOTSクライアントはセクション7.1.1で指定されているとおりに進行します。
A DELETE request is used to delete the specific information related to an installed DOTS client domain pipe. The same procedure as that defined in Section 7.1.4 is followed.
削除要求を使用して、インストールされているDOTSクライアントドメインパイプに関連する特定の情報を削除するために使用されます。セクション7.1.4で定義されているものと同じ手順に従います。
A DOTS client can communicate to its DOTS server(s) its normal traffic baseline and connection capacity:
DOTSクライアントは、通常のトラフィックベースラインと接続容量をDOTSサーバーに通信できます。
Total traffic normal baseline: Total traffic normal baseline data provides the percentile values representing the total traffic normal baseline. It can be represented for a target using 'total-traffic-normal'.
総トラフィック通常のベースライン：総トラフィック通常のベースラインデータは、トラフィックの合計ベースラインを表すパーセンタイル値を提供します。「総トラフィックノーマル」を使用して、ターゲットに表現できます。
The traffic normal per-protocol ('total-traffic-normal-per-protocol') baseline is represented for a target and is transport-protocol specific.
トラフィック通常のプロトコル（「総トラフィックノーマルあたりプロトコル」）ベースラインは、ターゲットに表され、輸送プロトコル固有です。
The traffic normal per-port-number ('total-traffic-normal-per-port') baseline is represented for each port number bound to a target.
ターゲットにバインドされた各ポート番号に対して、トラフィック通常のポート番号（「総トラフィックノーマルあたりのポート」）ベースラインが表されます。
If the DOTS client negotiated percentile values and units (Section 7.1), these negotiated parameters will be used instead of the default parameters. For each unit class used, the DOTS client MUST auto-scale so that the appropriate unit is used.
DOTSクライアントがパーセンタイル値とユニットを交渉した場合（セクション7.1）、これらのネゴシエートされたパラメーターはデフォルトのパラメーターの代わりに使用されます。使用するユニットクラスごとに、DOTSクライアントは、適切なユニットが使用されるように自動スケールする必要があります。
Total connection capacity: If the target is susceptible to resource-consuming DDoS attacks, the following optional attributes for the target per transport protocol are useful for detecting resource-consuming DDoS attacks:
総接続容量：ターゲットがリソースを消費するDDOS攻撃の影響を受けやすい場合、輸送プロトコルごとのターゲットの次のオプション属性は、リソースを消費するDDOS攻撃の検出に役立ちます。
* The maximum number of simultaneous connections that are allowed to the target.
* ターゲットに許可される同時接続の最大数。
* The maximum number of simultaneous connections that are allowed to the target per client.
* クライアントごとにターゲットに許可される同時接続の最大数。
* The maximum number of simultaneous embryonic connections that are allowed to the target. The term "embryonic connection" refers to a connection whose connection handshake is not finished. Embryonic connections are only possible in connection-oriented transport protocols like TCP or the Stream Control Transmission Protocol (SCTP) [RFC9260].
* ターゲットに許可される同時胚接続の最大数。「胚接続」という用語は、接続の握手が終了しない接続を指します。胚接続は、TCPやストリーム制御伝送プロトコル（SCTP）[RFC9260]などの接続指向輸送プロトコルでのみ可能です。
* The maximum number of simultaneous embryonic connections that are allowed to the target per client.
* クライアントごとにターゲットに許可される同時胚接続の最大数。
* The maximum number of connections allowed per second to the target.
* ターゲットに許可される接続の最大数。
* The maximum number of connections allowed per second to the target per client.
* クライアントごとにターゲットに1秒あたりに許可される接続の最大数。
* The maximum number of requests (e.g., HTTP/DNS/SIP requests) allowed per second to the target.
* ターゲットに許可されているリクエストの最大数（http/dns/sipリクエストなど）。
* The maximum number of requests allowed per second to the target per client.
* クライアントごとにターゲットに1秒あたりの許可されているリクエストの最大数。
* The maximum number of outstanding partial requests allowed to the target. Attacks relying upon partial requests create a connection with a target but do not send a complete request (e.g., an HTTP request).
* ターゲットに許可される未解決の部分リクエストの最大数。部分的なリクエストに依存する攻撃は、ターゲットとの接続を作成しますが、完全なリクエストを送信しません（例：HTTPリクエスト）。
* The maximum number of outstanding partial requests allowed to the target per client.
* クライアントごとにターゲットに許可される未解決の部分リクエストの最大数。
The aggregate per transport protocol is captured in 'total-connection-capacity', while port-specific capabilities are represented using 'total-connection-capacity-per-port'.
トランスポートプロトコルごとの集合体は「合計接続容量」でキャプチャされ、ポート固有の機能は「合計接続容量 - ポート」を使用して表されます。
Note that a target resource is identified using the attributes 'target-prefix', 'target-port-range', 'target-protocol', 'target-fqdn', 'target-uri', or 'alias-name' as defined in Section 4.4.1.1 of [RFC9132].
ターゲットリソースは、属性「ターゲットプレフィックス」、「ターゲットポートレンジ」、「ターゲットプロトコール」、「ターゲット-FQDN」、「ターゲットウリ」、または定義された「エイリアス」を使用して識別されることに注意してください。[RFC9132]のセクション4.4.1.1。
The tree structure of the normal traffic baseline is shown in Figure 18.
通常の交通ベースラインのツリー構造を図18に示します。
structure dots-telemetry:
+-- (telemetry-message-type)?
+--:(telemetry-setup)
| ...
| +-- telemetry* []
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- tsid? uint32
| +-- (setup-type)?
| +--:(telemetry-config)
| | ...
| +--:(pipe)
| | ...
| +--:(baseline)
| +-- baseline* [id]
| +-- id uint32
| +-- target-prefix*
| | inet:ip-prefix
| +-- target-port-range* [lower-port]
| | +-- lower-port inet:port-number
| | +-- upper-port? inet:port-number
| +-- target-protocol* uint8
| +-- target-fqdn*
| | inet:domain-name
| +-- target-uri*
| | inet:uri
| +-- alias-name*
| | string
| +-- total-traffic-normal* [unit]
| | +-- unit unit
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| +-- total-traffic-normal-per-protocol*
| | [unit protocol]
| | +-- protocol uint8
| | +-- unit unit
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| +-- total-traffic-normal-per-port* [unit port]
| | +-- port inet:port-number
| | +-- unit unit
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| +-- total-connection-capacity* [protocol]
| | +-- protocol uint8
| | +-- connection? uint64
| | +-- connection-client? uint64
| | +-- embryonic? uint64
| | +-- embryonic-client? uint64
| | +-- connection-ps? uint64
| | +-- connection-client-ps? uint64
| | +-- request-ps? uint64
| | +-- request-client-ps? uint64
| | +-- partial-request-max? uint64
| | +-- partial-request-client-max? uint64
| +-- total-connection-capacity-per-port*
| [protocol port]
| +-- port
| | inet:port-number
| +-- protocol uint8
| +-- connection? uint64
| +-- connection-client? uint64
| +-- embryonic? uint64
| +-- embryonic-client? uint64
| +-- connection-ps? uint64
| +-- connection-client-ps? uint64
| +-- request-ps? uint64
| +-- request-client-ps? uint64
| +-- partial-request-max? uint64
| +-- partial-request-client-max? uint64
+--:(telemetry)
...
Figure 18: Telemetry Baseline Tree Structure
図18：テレメトリーベースラインツリー構造
A DOTS client can share one or multiple normal traffic baselines (e.g., aggregate or per-prefix baselines); each is uniquely identified within the DOTS client domain with an identifier ('id'). This identifier can be used to update a baseline entry, delete a specific entry, etc.
DOTSクライアントは、1つまたは複数の通常のトラフィックベースラインを共有できます（たとえば、集計またはPrefixベースラインあたり）。それぞれは、識別子（「ID」）を備えたDOTSクライアントドメイン内で一意に識別されます。この識別子は、ベースラインエントリを更新し、特定のエントリを削除するために使用できます。
Considerations similar to those specified in Section 7.1.2 are followed, with one exception:
セクション7.1.2で指定されているものと同様の考慮事項に従って、1つの例外を除きます。
* The relative order of two PUT requests carrying DOTS client domain baseline attributes from a DOTS client is determined by comparing their respective 'tsid' values. If these two requests have overlapping targets, the PUT request with a higher numeric 'tsid' value will override the request with a lower numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be automatically deleted and no longer be available.
* DOTSクライアントドメインのベースライン属性を運ぶ2つのプット要求の相対順序は、それぞれの「TSID」値を比較することによって決定されます。これらの2つの要求にターゲットが重複している場合、数値が高い「TSID」値が高いプット要求は、低い数値「TSID」値で要求をオーバーライドします。オーバーラップされた低数値「TSID」は自動的に削除され、使用できなくなる必要があります。
Two PUT requests from a DOTS client have overlapping targets if there is a common IP address, IP prefix, FQDN, URI, or alias name. Also, two PUT requests from a DOTS client have overlapping targets from the perspective of the DOTS server if the addresses associated with the FQDN, URI, or alias are overlapping with each other or with 'target-prefix'.
共通のIPアドレス、IPプレフィックス、FQDN、URI、またはエイリアス名がある場合、DOTSクライアントからの2つのPUTリクエストには、ターゲットが重複しています。また、FQDN、URI、またはエイリアスに関連付けられたアドレスが互いに重複している、または「ターゲットプレフィックス」と重複している場合、DOTSクライアントからの2つのPut Requestsは、DOTSサーバーの観点からターゲットを重複させます。
DOTS clients SHOULD minimize the number of active 'tsid's used for baseline information. In order to avoid maintaining a long list of 'tsid's for baseline information, it is RECOMMENDED that DOTS clients include in any request to update information related to a given target the information regarding other targets (already communicated using a lower 'tsid' value) (assuming that this information fits within one single datagram). This update request will override these existing requests and hence optimize the number of 'tsid' requests per DOTS client.
DOTSクライアントは、ベースライン情報に使用されるアクティブな 'TSIDの数を最小限に抑える必要があります。「ベースライン情報用のTSID」の長いリストを維持することを避けるために、DOTSクライアントは、特定のターゲットに関連する情報を更新するリクエストに、他のターゲットに関する情報を更新することをお勧めします（既に「TSID」値を使用して通信しています）（既に通信しています）（この情報が1つのデータグラムに適合していると仮定します）。この更新リクエストは、これらの既存のリクエストをオーバーライドするため、ドットクライアントごとの「TSID」リクエストの数を最適化します。
If no target attribute is included in the request, this is an indication that the baseline information applies for the DOTS client domain as a whole.
リクエストにターゲット属性が含まれていない場合、これはベースライン情報がDOTSクライアントドメイン全体に適用されることを示しています。
An example of a PUT request to convey the baseline information is shown in Figure 19.
ベースライン情報を伝えるためのPUTリクエストの例を図19に示します。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=129"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"baseline": [
{
"id": 1,
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"total-traffic-normal": [
{
"unit": "megabit-ps",
"peak-g": "60"
}
]
}
]
}
]
}
}
Figure 19: PUT to Convey DOTS Traffic Baseline Information, Depicted as per Section 5.6
図19：セクション5.6に従って描かれているドットトラフィックベースライン情報を伝える
The DOTS client may share protocol-specific baseline information (e.g., TCP and UDP) as shown in Figure 20.
DOTSクライアントは、図20に示すように、プロトコル固有のベースライン情報（TCPやUDPなど）を共有できます。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=130"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry-setup": {
"telemetry": [
{
"baseline": [
{
"id": 1,
"target-prefix": [
"2001:db8:6401::1/128",
"2001:db8:6401::2/128"
],
"total-traffic-normal-per-protocol": [
{
"unit": "megabit-ps",
"protocol": 6,
"peak-g": "50"
},
{
"unit": "megabit-ps",
"protocol": 17,
"peak-g": "10"
}
]
}
]
}
]
}
}
Figure 20: PUT to Convey DOTS Traffic Baseline Information (2), Depicted as per Section 5.6
図20：セクション5.6に従って描かれているドットトラフィックベースライン情報（2）を伝える
The normal traffic baseline information should be updated to reflect legitimate overloads (e.g., flash crowds) to prevent unnecessary mitigation.
不必要な緩和を防ぐために、正当な過負荷（フラッシュクラウドなど）を反映するために、通常のトラフィックベースライン情報を更新する必要があります。
A GET request with a 'tsid' Uri-Path parameter is used to retrieve a specific installed DOTS client domain's baseline traffic information. The same procedure as that defined in Section 7.1.3 is followed.
「TSID」URI-PATHパラメーターを使用したGETリクエストを使用して、特定のインストールされたDOTSクライアントドメインのベースライントラフィック情報を取得します。セクション7.1.3で定義されているものと同じ手順に従います。
To retrieve all baseline information bound to a DOTS client, the DOTS client proceeds as specified in Section 7.1.1.
DOTSクライアントにバインドされたすべてのベースライン情報を取得するために、DOTSクライアントはセクション7.1.1で指定されているとおりに進行します。
A DELETE request is used to delete the installed DOTS client domain's normal traffic baseline information. The same procedure as that defined in Section 7.1.4 is followed.
削除要求を使用して、インストールされているDOTSクライアントドメインの通常のトラフィックベースライン情報を削除します。セクション7.1.4で定義されているものと同じ手順に従います。
Upon bootstrapping (or reboot or any other event that may alter the DOTS client setup), a DOTS client MAY send a DELETE request to set the telemetry parameters to default values. Such a request does not include any 'tsid' parameters. An example of such a request is depicted in Figure 21.
ブートストラップ（または再起動またはDOTSクライアントのセットアップを変更する可能性のあるその他のイベント）を使用すると、DOTSクライアントは削除要求を送信してテレメトリパラメーターをデフォルト値に設定する場合があります。このようなリクエストには、「TSID」パラメーターは含まれていません。このような要求の例を図21に示します。
Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 21: Deleting the Telemetry Configuration
図21：テレメトリー構成の削除
A DOTS server may detect conflicts between requests conveying pipe and baseline information received from DOTS clients of the same DOTS client domain. 'conflict-information' is used to report the conflict to the DOTS client, following guidelines for conflict handling similar to those discussed in Section 4.4.1 of [RFC9132]. The conflict cause can be set to one of these values:
DOTSサーバーは、同じDOTSクライアントドメインのDOTSクライアントから受け取ったパイプとベースライン情報を伝える要求との間の競合を検出する場合があります。「紛争情報」は、紛争をDOTSクライアントに報告するために使用されます。これは、[RFC9132]のセクション4.4.1で説明されているものと同様の競合処理のガイドラインに従って使用されます。競合の原因は、これらの値のいずれかに設定できます。
1: Overlapping targets (Section 4.4.1 of [RFC9132]).
1：オーバーラップターゲット（[RFC9132]のセクション4.4.1）。
5: Overlapping pipe scope (see Section 13).
5：パイプスコープの重複（セクション13を参照）。
There are two broad types of DDoS attacks: bandwidth-consuming attacks and target-resource-consuming attacks. This section outlines the set of DOTS telemetry attributes (Section 8.1) that covers both types of attacks. The objective of these attributes is to allow for the complete knowledge of attacks and the various particulars that can best characterize attacks.
DDOS攻撃には、帯域幅を消費する攻撃とターゲットリソースを消費する攻撃の2つの幅広いタイプの攻撃があります。このセクションでは、両方のタイプの攻撃をカバーするドットテレメトリ属性のセット（セクション8.1）の概要を説明します。これらの属性の目的は、攻撃の完全な知識と、攻撃を最もよく特徴付けることができるさまざまな詳細を可能にすることです。
The "ietf-dots-telemetry" YANG module (Section 11.1) defines the data structure of a new message type called 'telemetry'. The tree structure of the 'telemetry' message type is shown in Figure 22.
「IETF-Dots-Telemetry」Yangモジュール（セクション11.1）は、「Telemetry」と呼ばれる新しいメッセージタイプのデータ構造を定義しています。「テレメトリー」メッセージタイプのツリー構造を図22に示します。
structure dots-telemetry:
+-- (telemetry-message-type)?
+--:(telemetry-setup)
| ...
| +-- telemetry* []
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- tsid? uint32
| +-- (setup-type)?
| +--:(telemetry-config)
| | ...
| +--:(pipe)
| | ...
| +--:(baseline)
| ...
+--:(telemetry)
+-- pre-or-ongoing-mitigation* []
+-- (direction)?
| +--:(server-to-client-only)
| +-- tmid? uint32
+-- target
| ...
+-- total-traffic* [unit]
| ...
+-- total-traffic-protocol* [unit protocol]
| ...
+-- total-traffic-port* [unit port]
| ...
+-- total-attack-traffic* [unit]
| ...
+-- total-attack-traffic-protocol* [unit protocol]
| ...
+-- total-attack-traffic-port* [unit port]
| ...
+-- total-attack-connection-protocol* [protocol]
| ...
+-- total-attack-connection-port* [protocol port]
| ...
+-- attack-detail* [vendor-id attack-id]
...
Figure 22: Telemetry Message Type Tree Structure
図22：テレメトリーメッセージタイプツリー構造
The pre-or-ongoing-mitigation telemetry attributes are indicated by the path suffix '/tm'. '/tm' is appended to the path prefix to form the URI used with a CoAP request to signal the DOTS telemetry. Pre-or-ongoing-mitigation telemetry attributes as specified in Section 8.1 can be signaled between DOTS agents.
事前またはソング緩和のテレメトリ属性は、パスサフィックス「/TM」で示されています。'/tm'は、PATHプレフィックスに追加され、DOTSテレメトリを信号するCOAP要求で使用されるURIを形成します。セクション8.1で指定されているように、前線緩和測定テレメトリ属性は、DOTSエージェント間でシグナルを受けることができます。
Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS client or a DOTS server.
ドットクライアントまたはDOTSサーバーによって、前ソング緩和のテレメトリ属性が送信される場合があります。
DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to mitigation requests associated with the resources under attack. In particular, a telemetry PUT request sent after a mitigation request may include a reference to that mitigation request ('mid-list') as shown in Figure 23. An example illustrating request correlation by means of 'target-prefix' is shown in Figure 24.
DOTSエージェントは、攻撃中のリソースに関連付けられた緩和要求に、事前またはソングの緩和テレメトリデータを緩和リクエストに結合する必要があります。特に、図23に示すように、緩和リクエストの後に送信されたテレメトリのリクエストが緩和要求の後に送信されたリクエストには、その軽減要求（「中リスト」）への参照が含まれる場合があります。24。
Much of the pre-or-ongoing-mitigation telemetry data uses a unit that falls under the unit class that is configured following the procedure described in Section 7.1.2. When generating telemetry data to send to a peer, the DOTS agent MUST auto-scale so that one or more appropriate units are used.
事前またはソング緩和のテレメトリデータの多くは、セクション7.1.2で説明した手順に従って構成されているユニットクラスに該当するユニットを使用します。テレメトリデータを生成してピアに送信する場合、DOTSエージェントは1つ以上の適切なユニットが使用されるように自動スケールする必要があります。
+-----------+ +-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|==============Mitigation Request (mid)==============>|
| |
|==============Telemetry (mid-list{mid})=============>|
| |
Figure 23: Example of Request Correlation Using 'mid'
図23：「MID」を使用した要求相関の例
+-----------+ +-----------+
|DOTS client| |DOTS server|
+-----------+ +-----------+
| |
|<===============Telemetry (target-prefix)============|
| |
|========Mitigation Request (target-prefix)==========>|
| |
Figure 24: Example of Request Correlation Using 'target-prefix'
図24：「Target-Prefix」を使用した要求相関の例
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetry-notify-interval' (Section 7.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [RFC9177]), this rate-limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification.
DOTSエージェントは、「Telemetry-Notify-interval」（セクション7.1）ごとに、前またはソング緩和のテレメトリ通知を同じピアに同じピアに送信してはなりません。ブロックのような転送メカニズム（[RFC9177]など）を使用してテレメトリ通知が送信される場合、このレート制限ポリシーは、これらの個々のブロックを個別の通知と見なすのではなく、単一の通知として考慮する必要があります。
DOTS pre-or-ongoing-mitigation telemetry request and response messages MUST be marked as Non-confirmable messages (Section 2.1 of [RFC7252]).
ドット前または音を緩和するテレメトリリクエストと応答メッセージは、コンファイル不可能なメッセージとしてマークする必要があります（[RFC7252]のセクション2.1）。
Section 3 discusses the motivation for using the DOTS telemetry attributes. These attributes are specified in the following subsections.
セクション3では、DOTSテレメトリ属性を使用する動機について説明します。これらの属性は、次のサブセクションで指定されています。
A target resource (Figure 25) is identified using the attributes 'target-prefix', 'target-port-range', 'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation request ('mid-list').
ターゲットリソース（図25）は、属性「ターゲットプレフィックス」、「ターゲットポートレンジ」、「ターゲットプロトコル」、「ターゲット-FQDN」、「ターゲットウリ」、「エイリアス名」、「ターゲットプロトコール」、「エイリアス名」を使用して識別されます。または緩和要求へのポインター（「ミッドリスト」）。
+--:(telemetry)
+-- pre-or-ongoing-mitigation* []
+-- (direction)?
| +--:(server-to-client-only)
| +-- tmid? uint32
+-- target
| +-- target-prefix* inet:ip-prefix
| +-- target-port-range* [lower-port]
| | +-- lower-port inet:port-number
| | +-- upper-port? inet:port-number
| +-- target-protocol* uint8
| +-- target-fqdn* inet:domain-name
| +-- target-uri* inet:uri
| +-- alias-name* string
| +-- mid-list* uint32
+-- total-traffic* [unit]
| ...
+-- total-traffic-protocol* [unit protocol]
| ...
+-- total-traffic-port* [unit port]
| ...
+-- total-attack-traffic* [unit]
| ...
+-- total-attack-traffic-protocol* [unit protocol]
| ...
+-- total-attack-traffic-port* [unit port]
| ...
+-- total-attack-connection-protocol* [protocol]
| ...
+-- total-attack-connection-port* [protocol port]
| ...
+-- attack-detail* [vendor-id attack-id]
...
Figure 25: Target Tree Structure
図25：ターゲットツリー構造
At least one of the attributes 'target-prefix', 'target-fqdn', 'target-uri', 'alias-name', or 'mid-list' MUST be present in the target definition.
属性の少なくとも1つは、「Target-Prefix」、「Target-FQDN」、「Target-URI」、「Alias-Name」、または「Mid-List」がターゲット定義に存在する必要があります。
If the target is susceptible to bandwidth-consuming attacks, the attributes representing the percentile values of the 'attack-id' attack traffic are included.
ターゲットが帯域幅を消費する攻撃の影響を受けやすい場合、「攻撃ID」攻撃トラフィックのパーセンタイル値を表す属性が含まれています。
If the target is susceptible to resource-consuming DDoS attacks, the attributes defined in Section 8.1.4 are applicable for representing the attack.
ターゲットがリソースを消費するDDOS攻撃の影響を受けやすい場合、セクション8.1.4で定義されている属性は、攻撃を表すために適用できます。
At least the 'target' attribute and one other pre-or-ongoing-mitigation attribute MUST be present in the DOTS telemetry message.
少なくとも「ターゲット」属性と他の1つの前ソングまたはソングミチゲーション属性が、DOTSテレメトリーメッセージに存在する必要があります。
The 'total-traffic' attribute (Figure 26) conveys the percentile values (including peak and current observed values) of the total observed traffic. More fine-grained information about the total traffic can be conveyed in the 'total-traffic-protocol' and 'total-traffic-port' attributes.
「総トラフィック」属性（図26）は、観測された総トラフィックのパーセンタイル値（ピークおよび現在の観測値を含む）を伝えます。総トラフィックに関するよりきめ細かい情報は、「総トラフィックプロトコル」および「トータルトラフィックポート」属性で伝えることができます。
The 'total-traffic-protocol' attribute represents the total traffic for a target and is transport-protocol specific.
「Total-Truffic-Protocol」属性は、ターゲットの合計トラフィックを表し、輸送プロトコル固有です。
The 'total-traffic-port' attribute represents the total traffic for a target per port number.
「Total-Truffic-Port」属性は、ポート番号ごとのターゲットの合計トラフィックを表します。
+--:(telemetry)
+-- pre-or-ongoing-mitigation* []
+-- (direction)?
| +--:(server-to-client-only)
| +-- tmid? uint32
+-- target
| ...
+-- total-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-traffic-protocol* [unit protocol]
| +-- protocol uint8
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-traffic-port* [unit port]
| +-- port inet:port-number
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-traffic* [unit]
| ...
+-- total-attack-traffic-protocol* [unit protocol]
| ...
+-- total-attack-traffic-port* [unit port]
| ...
+-- total-attack-connection-protocol* [protocol]
| ...
+-- total-attack-connection-port* [protocol port]
| ...
+-- attack-detail* [vendor-id attack-id]
...
Figure 26: Total Traffic Tree Structure
図26：総トラフィックツリー構造
The 'total-attack-traffic' attribute (Figure 27) conveys the total observed attack traffic. More fine-grained information about the total attack traffic can be conveyed in the 'total-attack-traffic-protocol' and 'total-attack-traffic-port' attributes.
「Total-Attack-Traffic」属性（図27）は、観測された攻撃トラフィック全体を伝えます。攻撃トラフィックの総トラフィックに関するより微調整された情報は、「Total-Attack-Traffic-Protocol」および「Total-Attack-Traffic-Port」属性で伝えることができます。
The 'total-attack-traffic-protocol' attribute represents the total attack traffic for a target and is transport-protocol specific.
「Total-Attack-Traffic-Protocol」属性は、ターゲットの合計攻撃トラフィックを表し、トランスポートプロトコル固有です。
The 'total-attack-traffic-port' attribute represents the total attack traffic for a target per port number.
「Total-Attack-Traffic-Port」属性は、ポート番号ごとにターゲットの総攻撃トラフィックを表します。
+--:(telemetry)
+-- pre-or-ongoing-mitigation* []
+-- (direction)?
| +--:(server-to-client-only)
| +-- tmid? uint32
+-- target
| ...
+-- total-traffic* [unit]
| ...
+-- total-traffic-protocol* [unit protocol]
| ...
+-- total-traffic-port* [unit port]
| ...
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-traffic-protocol* [unit protocol]
| +-- protocol uint8
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-traffic-port* [unit port]
| +-- port inet:port-number
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-connection-protocol* [protocol]
| ...
+-- total-attack-connection-port* [protocol port]
| ...
+-- attack-detail* [vendor-id attack-id]
...
Figure 27: Total Attack Traffic Tree Structure
図27：総攻撃トラフィックツリー構造
If the target is susceptible to resource-consuming DDoS attacks, the 'total-attack-connection-protocol' attribute is used to convey the percentile values (including peak and current observed values) of various attributes related to the total attack connections. The following optional sub-attributes for the target per transport protocol are included to represent the attack characteristics:
ターゲットがリソースを消費するDDOS攻撃の影響を受けやすい場合、「Total-Attack-Connection-Protocol」属性を使用して、総攻撃接続に関連するさまざまな属性のパーセンタイル値（ピークおよび現在の観測値を含む）を伝達します。攻撃特性を表すために、輸送プロトコルごとのターゲットの次のオプションのサブアトリビュートが含まれています。
* The number of simultaneous attack connections to the target.
* ターゲットへの同時攻撃接続の数。
* The number of simultaneous embryonic connections to the target.
* ターゲットへの同時胚接続の数。
* The number of attack connections per second to the target.
* ターゲットの1秒あたりの攻撃接続の数。
* The number of attack requests per second to the target.
* ターゲットの攻撃要求の数。
* The number of attack partial requests to the target.
* ターゲットへの部分的な要求の数。
The total attack connections per port number are represented using the 'total-attack-connection-port' attribute.
ポート番号ごとの合計攻撃接続は、「Total-Attack-Connection-Port」属性を使用して表されます。
+--:(telemetry)
+-- pre-or-ongoing-mitigation* []
+-- (direction)?
| +--:(server-to-client-only)
| +-- tmid? uint32
+-- target
| ...
+-- total-traffic* [unit]
| ...
+-- total-traffic-protocol* [unit protocol]
| ...
+-- total-traffic-port* [unit port]
| ...
+-- total-attack-traffic* [unit]
| ...
+-- total-attack-traffic-protocol* [unit protocol]
| ...
+-- total-attack-traffic-port* [unit port]
| ...
+-- total-attack-connection-protocol* [protocol]
| +-- protocol uint8
| +-- connection-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- embryonic-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- connection-ps-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- request-ps-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- partial-request-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-connection-port* [protocol port]
| +-- protocol uint8
| +-- port inet:port-number
| +-- connection-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- embryonic-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- connection-ps-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- request-ps-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- partial-request-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id]
...
Figure 28: Total Attack Connections Tree Structure
図28：総攻撃接続ツリー構造
This attribute (depicted in Figure 29) is used to signal a set of details characterizing an attack. The following sub-attributes describing the ongoing attack can be signaled as attack details:
この属性（図29に示す）は、攻撃を特徴付ける一連の詳細を知らせるために使用されます。進行中の攻撃を説明する次のサブアトリビュートは、攻撃の詳細として信号を送ることができます。
vendor-id: Vendor ID. This parameter represents a security vendor's enterprise number as registered in the IANA "Private Enterprise Numbers" registry [Private-Enterprise-Numbers].
ベンダーID：ベンダーID。このパラメーターは、IANAの「プライベートエンタープライズ番号」レジストリ[Private-Enterprise-Numbers]に登録されているセキュリティベンダーのエンタープライズ番号を表します。
attack-id: Unique identifier assigned for the attack by a vendor. This parameter MUST be present, independently of whether 'attack-description' is included or not.
Attack-ID：ベンダーによる攻撃に割り当てられた一意の識別子。このパラメーターは、「攻撃記述」が含まれているかどうかとは無関係に、存在する必要があります。
description-lang: Indicates the language tag that is used for the text that is included in the 'attack-description' attribute. This attribute is encoded following the rules in Section 2.1 of [RFC5646]. The default language tag is "en-US".
Description-Lang：「Attack-Description」属性に含まれるテキストに使用される言語タグを示します。この属性は、[RFC5646]のセクション2.1のルールに従ってエンコードされます。デフォルトの言語タグは「en-us」です。
attack-description: Textual representation of the attack description. This description is related to the class of attack rather than a specific instance of it. Natural Language Processing techniques (e.g., word embedding) might provide some utility in mapping the attack description to an attack type. Textual representation of an attack solves two problems: it avoids the need to (a) create mapping tables manually between vendors and (b) standardize attack types that keep evolving.
攻撃記述：攻撃の説明のテキスト表現。この説明は、特定のインスタンスではなく、攻撃のクラスに関連しています。自然言語処理技術（例：単語の埋め込み）は、攻撃の説明を攻撃タイプにマッピングする際に何らかのユーティリティを提供する可能性があります。攻撃のテキスト表現は、2つの問題を解決します。（a）ベンダー間で手動でマッピングテーブルを作成し、（b）進化を続ける攻撃タイプを標準化する必要性を回避します。
attack-severity: Attack severity level. This attribute takes one of the values defined in Section 3.12.2 of [RFC7970].
攻撃の重度：攻撃の重大度。この属性は、[RFC7970]のセクション3.12.2で定義されている値の1つを取得します。
start-time: The time the attack started. The attack's start time is expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 of [RFC8949]). The CBOR encoding is modified so that the leading tag 1 (epoch-based date/time) MUST be omitted.
開始時間：攻撃が始まった時。攻撃の開始時間は、1970-01-01T00：00Z（[RFC8949]のセクション3.4.2）に比べて数秒で表されます。CBORエンコーディングは変更されているため、リーディングタグ1（エポックベースの日付/時刻）を省略する必要があります。
end-time: The time the attack ended. The attack's end time is expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 of [RFC8949]). The CBOR encoding is modified so that the leading tag 1 (epoch-based date/time) MUST be omitted.
終了時間：攻撃が終了した時間。攻撃の終了時間は、1970-01-01T00：00Z（[RFC8949]のセクション3.4.2）に比べて数秒で表されます。CBORエンコーディングは変更されているため、リーディングタグ1（エポックベースの日付/時刻）を省略する必要があります。
source-count: A count of sources involved in the attack targeting the victim.
ソースカウント：被害者を標的とする攻撃に関与するソースのカウント。
top-talker: A list of attack sources that are involved in an attack and that are generating an important part of the attack traffic. The top talkers are represented using 'source-prefix'.
トップトーカー：攻撃に関与し、攻撃トラフィックの重要な部分を生成している攻撃ソースのリスト。トップトーカーは、「ソースプレフィックス」を使用して表されます。
'spoofed-status' indicates whether a top talker is a spoofed IP address (e.g., reflection attacks) or not. If no 'spoofed-status' data node is included, this means that the spoofing status is unknown.
「スプーフィングされたステータス」は、トップトーカーがスプーフィングされたIPアドレス（例：反射攻撃）であるかどうかを示します。「スプーフィングされたステータス」データノードが含まれていない場合、これはスプーフィングステータスが不明であることを意味します。
If the target is being subjected to a bandwidth-consuming attack, a statistical profile of the attack traffic from each of the top talkers is included ('total-attack-traffic'; see Section 8.1.3).
ターゲットが帯域幅を消費する攻撃にさらされている場合、各トップトーカーからの攻撃トラフィックの統計的プロファイルが含まれています（「合計攻撃者」。セクション8.1.3を参照）。
If the target is being subjected to a resource-consuming DDoS attack, the same attributes as those defined in Section 8.1.4 are applicable for characterizing the attack on a per-talker basis.
ターゲットがリソースを消費するDDOS攻撃にさらされている場合、セクション8.1.4で定義されている属性と同じ属性が、トーカーごとの攻撃を特徴付けるために適用できます。
+--:(telemetry)
+-- pre-or-ongoing-mitigation* []
+-- (direction)?
| +--:(server-to-client-only)
| +-- tmid? uint32
+-- target
| ...
+-- total-traffic* [unit]
| ...
+-- total-traffic-protocol* [unit protocol]
| ...
+-- total-traffic-port* [unit port]
| ...
+-- total-attack-traffic* [unit]
| ...
+-- total-attack-traffic-protocol* [unit protocol]
| ...
+-- total-attack-traffic-port* [unit port]
| ...
+-- total-attack-connection-protocol* [protocol]
| ...
+-- total-attack-connection-port* [protocol port]
| ...
+-- attack-detail* [vendor-id attack-id]
+-- vendor-id uint32
+-- attack-id uint32
+-- description-lang? string
+-- attack-description? string
+-- attack-severity? attack-severity
+-- start-time? uint64
+-- end-time? uint64
+-- source-count
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- top-talker
+-- talker* [source-prefix]
+-- spoofed-status? boolean
+-- 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
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-connection-protocol*
[protocol]
+-- protocol uint8
+-- connection-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- embryonic-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- connection-ps-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- request-ps-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- partial-request-c
+-- low-percentile-g? yang:gauge64
+-- mid-percentile-g? yang:gauge64
+-- high-percentile-g? yang:gauge64
+-- peak-g? yang:gauge64
+-- current-g? yang:gauge64
Figure 29: Attack Details Tree Structure
図29：攻撃の詳細ツリー構造
In order to optimize the size of telemetry data conveyed over the DOTS signal channel, DOTS agents MAY use the DOTS data channel [RFC8783] to exchange vendor-specific attack mapping details (that is, {vendor identifier, attack identifier} ==> textual representation of the attack description). As such, DOTS agents do not have to convey an attack description systematically in their telemetry messages over the DOTS signal channel. Refer to Section 8.1.6.
DOTS信号チャネルで伝達されるテレメトリデータのサイズを最適化するために、DOTSエージェントはDOTSデータチャネル[RFC8783]を使用してベンダー固有の攻撃マッピングの詳細を交換することができます（つまり、{ベンダー識別子、攻撃識別子} ==>テキスト攻撃の説明の表現）。そのため、DOTSエージェントは、DOTS信号チャネル上のテレメトリメッセージで攻撃の説明を体系的に伝える必要はありません。セクション8.1.6を参照してください。
Multiple mappings for different vendor identifiers may be used; the DOTS agent transmitting telemetry information can elect to use one or more vendor mappings even in the same telemetry message.
さまざまなベンダー識別子の複数のマッピングを使用できます。テレメトリー情報を送信するDOTSエージェントは、同じテレメトリメッセージでも1つ以上のベンダーマッピングを使用することを選択できます。
Note: It is possible that a DOTS server is making use of multiple DOTS mitigators, each from a different vendor. How telemetry information and vendor mappings are exchanged between DOTS servers and DOTS mitigators is outside the scope of this document.
注：DOTSサーバーは、それぞれ異なるベンダーからの複数のDOTSマイチゲーターを使用している可能性があります。テレメトリ情報とベンダーマッピングがドットサーバーとドットマッピングの間で交換される方法は、このドキュメントの範囲外です。
DOTS clients and servers may be provided with mappings from different vendors and so have their own different sets of vendor attack mappings. A DOTS agent MUST accept receipt of telemetry data with a vendor identifier that is different than the identifier it uses to transmit telemetry data. Furthermore, it is possible that the DOTS client and DOTS server are provided by the same vendor but the vendor mapping tables are at different revisions. The DOTS client SHOULD transmit telemetry information using any vendor mapping(s) that it provided to the DOTS server (e.g., using a POST as depicted in Figure 30), and the DOTS server SHOULD use any vendor mappings(s) provided to the DOTS client when transmitting telemetry data to the peer DOTS agent.
DOTSクライアントとサーバーには、さまざまなベンダーのマッピングが提供される場合があるため、ベンダーの攻撃マッピングの独自のセットがあります。DOTSエージェントは、テレメトリデータを送信するために使用する識別子とは異なるベンダー識別子を使用して、テレメトリデータの受信を受け入れる必要があります。さらに、DOTSクライアントとDOTSサーバーは同じベンダーによって提供される可能性がありますが、ベンダーマッピングテーブルは異なる改訂版にあります。DOTSクライアントは、DOTSサーバーに提供されたベンダーマッピングを使用してテレメトリ情報を送信する必要があります（例：図30に描かれている投稿を使用）、DOTSサーバーはDOTSに提供されるベンダーマッピングを使用する必要があります。クライアントテレメトリデータをピアドットエージェントに送信するとき。
POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-mapping:vendor-mapping": {
"vendor": [
{
"vendor-id": 345,
"vendor-name": "mitigator-c",
"last-updated": "1629898958",
"attack-mapping": [
{
"attack-id": 1,
"attack-description":
"Include a description of this attack"
},
{
"attack-id": 2,
"attack-description":
"Again, include a description of the attack"
}
]
}
]
}
}
Figure 30: POST to Install Vendor Attack Mapping Details
図30：ベンダー攻撃のマッピングの詳細をインストールするための投稿
The "ietf-dots-mapping" YANG module defined in Section 11.2 augments the "ietf-dots-data-channel" module [RFC8783]. The tree structure of the "ietf-dots-mapping" module is shown in Figure 31.
セクション11.2で定義されている「IETF-DOTS-MAPTS」Yangモジュールは、「IETF-DOTS-DATA-CHANNEL」モジュール[RFC8783]を補強しています。「IETF-Dots-Mapps」モジュールのツリー構造を図31に示します。
module: ietf-dots-mapping
augment /data-channel:dots-data/data-channel:dots-client:
+--rw vendor-mapping {dots-telemetry}?
+--rw vendor* [vendor-id]
+--rw vendor-id uint32
+--rw vendor-name? string
+--rw description-lang? string
+--rw last-updated uint64
+--rw attack-mapping* [attack-id]
+--rw attack-id uint32
+--rw attack-description string
augment /data-channel:dots-data/data-channel:capabilities:
+--ro vendor-mapping-enabled? boolean {dots-telemetry}?
augment /data-channel:dots-data:
+--ro vendor-mapping {dots-telemetry}?
+--ro vendor* [vendor-id]
+--ro vendor-id uint32
+--ro vendor-name? string
+--ro description-lang? string
+--ro last-updated uint64
+--ro attack-mapping* [attack-id]
+--ro attack-id uint32
+--ro attack-description string
Figure 31: Vendor Attack Mapping Tree Structure
図31：ベンダー攻撃マッピングツリー構造
A DOTS client sends a GET request over the DOTS data channel to retrieve the capabilities supported by a DOTS server as per Section 7.1 of [RFC8783]. This request is meant to assess whether the capability of sharing vendor attack mapping details is supported by the server (i.e., check the value of 'vendor-mapping-enabled').
DOTSクライアントは、[RFC8783]のセクション7.1に従って、DOTSサーバーによってサポートされている機能を取得するために、DOTSデータチャネル上でGETリクエストを送信します。この要求は、ベンダー攻撃マッピングの詳細を共有する機能がサーバーによってサポートされているかどうかを評価することを目的としています（つまり、「ベンダーマッピング対応」の値を確認します）。
If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send a GET request to retrieve the DOTS server's vendor attack mapping details. An example of such a GET request is shown in Figure 32.
「ベンダーマッピング対応」が「true」に設定されている場合、DOTSクライアントはGETリクエストを送信して、DOTSサーバーのベンダー攻撃マッピングの詳細を取得することができます。このようなGETリクエストの例を図32に示します。
GET /restconf/data/ietf-dots-data-channel:dots-data\
/ietf-dots-mapping:vendor-mapping HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Figure 32: GET to Retrieve the Vendor Attack Mappings of a DOTS Server
図32：ドットサーバーのベンダー攻撃マッピングを取得してください
A DOTS client can retrieve only the list of vendors supported by the DOTS server. It does so by setting the "depth" parameter (Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in Figure 33. An example of a response body received from the DOTS server as a response to such a request is illustrated in Figure 34.
DOTSクライアントは、DOTSサーバーでサポートされているベンダーのリストのみを取得できます。これは、図33に示すように、「深さ」パラメーター（[RFC8040]のセクション4.8.2）をGETリクエストの「3」に設定することで行います。リクエストを図34に示します。
GET /restconf/data/ietf-dots-data-channel:dots-data\
/ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Figure 33: GET to Retrieve the Vendors List Used by a DOTS Server
図33：DOTSサーバーが使用しているベンダーリストを取得してください
{
"ietf-dots-mapping:vendor-mapping": {
"vendor": [
{
"vendor-id": 32473,
"vendor-name": "mitigator-s",
"last-updated": "1629898758",
"attack-mapping": []
}
]
}
}
Figure 34: Response Message Body to a GET to Retrieve the Vendors List Used by a DOTS Server
図34：DOTSサーバーで使用されているベンダーリストを取得するための回答メッセージ本文
The DOTS client repeats the above procedure regularly (e.g., once a week) to update the DOTS server's vendor attack mapping details.
DOTSクライアントは、上記の手順を定期的に繰り返し（たとえば、週に1回）、DOTSサーバーのベンダー攻撃マッピングの詳細を更新します。
If the DOTS client concludes that the DOTS server does not have any reference to the specific vendor attack mapping details, the DOTS client uses a POST request to install its vendor attack mapping details. An example of such a POST request is depicted in Figure 30.
DOTSクライアントが、DOTSサーバーに特定のベンダー攻撃マッピングの詳細に言及していないと結論付けている場合、DOTSクライアントはPOSTリクエストを使用してベンダー攻撃マッピングの詳細をインストールします。このような投稿要求の例を図30に示します。
The DOTS server indicates the result of processing the POST request using the status-line. A "201 Created" status-line MUST be returned in the response if the DOTS server has accepted the vendor attack mapping details. If the request is missing a mandatory attribute or contains an invalid or unknown parameter, a "400 Bad Request" status-line MUST be returned by the DOTS server in the response. The error-tag is set to "missing-attribute", "invalid-value", or "unknown-element" as a function of the encountered error.
DOTSサーバーは、ステータスラインを使用してPOSTリクエストを処理した結果を示します。DOTSサーバーがベンダー攻撃マッピングの詳細を受け入れた場合、「201」のステータスラインを応答で返す必要があります。要求に必須属性が欠落している場合、または無効または不明なパラメーターが含まれている場合、「400リクエスト」ステータスラインを応答内のDOTSサーバーによって返す必要があります。エラータグは、遭遇したエラーの関数として「不足アトリブ」、「無効値」、または「未知の要素」に設定されます。
If the request is received via a server-domain DOTS gateway but the DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' is expected to be supplied, the DOTS server MUST reply with a "403 Forbidden" status-line and the error-tag "access-denied". Upon receipt of this message, the DOTS client MUST register (Section 5.1 of [RFC8783]).
リクエストがサーバードメインのドットゲートウェイを介して受信されますが、ドットサーバーはこの「CUID」の「CDID」を維持しない場合、「CDID」が提供されると予想される場合、DOTSサーバーは「403禁止」で返信する必要があります。ステータスラインとエラータグ「アクセス - 除去」。このメッセージを受け取ると、DOTSクライアントは登録する必要があります（[RFC8783]のセクション5.1）。
The DOTS client uses the PUT request to modify its vendor attack mapping details maintained by the DOTS server (e.g., add a new mapping entry, update an existing mapping).
DOTSクライアントは、PUTリクエストを使用して、DOTSサーバーによって維持されているベンダー攻撃マッピングの詳細を変更します（たとえば、新しいマッピングエントリを追加し、既存のマッピングを更新します）。
A DOTS client uses a GET request to retrieve its vendor attack mapping details as maintained by the DOTS server (Figure 35).
DOTSクライアントは、GETリクエストを使用して、DOTSサーバーによって維持されているように、ベンダー攻撃マッピングの詳細を取得します（図35）。
GET /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=dz6pHjaADkaFTbjr0JGBpw\
/ietf-dots-mapping:vendor-mapping?\
content=all HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details
図35：インストールされているベンダー攻撃マッピングの詳細を取得する
When conveying attack details in DOTS telemetry messages (Sections 8.2, 8.3, and 9), DOTS agents MUST NOT include the 'attack-description' attribute unless the corresponding attack mapping details were not previously shared with the peer DOTS agent.
DOTSテレメトリメッセージ（セクション8.2、8.3、および9）で攻撃の詳細を伝える場合、DOTSエージェントは、対応する攻撃マッピングの詳細が以前にピアドットエージェントと共有されていなかった場合を除き、「攻撃説明」属性を含めてはなりません。
DOTS clients use PUT requests to signal pre-or-ongoing-mitigation telemetry to DOTS servers. An example of such a request is shown in Figure 36.
DOTSクライアントは、Put Requestsを使用して、ドットサーバーに事前またはソングミチゲーションテレメトリを信号します。このような要求の例を図36に示します。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"total-attack-traffic-protocol": [
{
"protocol": 17,
"unit": "megabit-ps",
"mid-percentile-g": "900"
}
],
"attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"start-time": "1608336568",
"attack-severity": "high"
}
]
}
]
}
}
Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry, Depicted as per Section 5.6
図36：セクション5.6に従って描かれている、事前またはソング緩和のテレメトリを送信する
'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.
「CUID」は、ドットプットリクエストの必須のURI-PATHパラメーターです。
The following additional Uri-Path parameter is defined:
次の追加のURI-PATHパラメーターが定義されています。
tmid: The Telemetry Identifier is an identifier for the DOTS pre-or-ongoing-mitigation telemetry data represented as an integer. This identifier MUST be generated by DOTS clients. 'tmid' values MUST increase monotonically whenever a DOTS client needs to convey a new set of pre-or-ongoing-mitigation telemetry data.
TMID：Telemetry Identifierは、整数として表されるDOTS Pre-Ongoing緩和テレメトリデータの識別子です。この識別子は、DOTSクライアントによって生成される必要があります。「TMID」値は、DOTSクライアントが新しいソングミチゲーションテレメトリデータの新しいセットを伝える必要がある場合は、単調に増加する必要があります。
The procedure specified in Section 4.4.1 of [RFC9132] for 'mid' rollover MUST be followed for 'tmid' rollover.
[MID]ロールオーバーの[RFC9132]のセクション4.4.1で指定された手順には、「TMID」ロールオーバーに従う必要があります。
This is a mandatory attribute. 'tmid' MUST appear after 'cuid' in the Uri-Path options.
これは必須の属性です。「tmid」は、URI-Pathオプションに「CUID」の後に表示される必要があります。
'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
「CUID」と「TMID」は、Put Request Message Bodyに表示されてはなりません。
At least the 'target' attribute and another pre-or-ongoing-mitigation attribute (Section 8.1) MUST be present in the PUT request. If only the 'target' attribute is present, this request is handled as per Section 8.3.
少なくとも「ターゲット」属性と別の前または音の緩和属性（セクション8.1）は、PUTリクエストに存在する必要があります。「ターゲット」属性のみが存在する場合、この要求はセクション8.3に従って処理されます。
The relative order of two PUT requests carrying DOTS pre-or-ongoing-mitigation telemetry from a DOTS client is determined by comparing their respective 'tmid' values. If these two requests have an overlapping 'target', the PUT request with a higher numeric 'tmid' value will override the request with a lower numeric 'tmid' value. The overlapped lower numeric 'tmid' MUST be automatically deleted and no longer be available.
DOTSクライアントからのドットまたはソングミチゲーションのテレメトリを運ぶ2つのプット要求の相対順序は、それぞれの「tmid」値を比較することで決定されます。これらの2つの要求に「ターゲット」が重複する場合、数値が高い「TMID」値が高いPUTリクエストは、低い数値「TMID」値でリクエストをオーバーライドします。オーバーラップされた低数値「tmid」は自動的に削除され、使用できなくなる必要があります。
The DOTS server indicates the result of processing a PUT request using CoAP Response Codes. In particular, the 2.04 (Changed) Response Code is returned if the DOTS server has accepted the pre-or-ongoing-mitigation telemetry. The 5.03 (Service Unavailable) Response Code is returned if the DOTS server has erred. The 5.03 Response Code uses the Max-Age Option to indicate the number of seconds after which to retry.
DOTSサーバーは、COAP応答コードを使用してPUTリクエストを処理した結果を示します。特に、DOTSサーバーが事前またはソング緩和のテレメトリを受け入れた場合、2.04（変更）応答コードが返されます。DOTSサーバーがエラーになった場合、5.03（サービスなし）応答コードが返されます。5.03応答コードは、最大年齢オプションを使用して、再試行してから秒数を示します。
How long a DOTS server maintains a 'tmid' as active or logs the enclosed telemetry information is implementation specific. Note that if a 'tmid' is still active, then logging details are updated by the DOTS server as a function of the updates received from the peer DOTS client.
DOTSサーバーは、アクティブまたはログを記録するために「TMID」を維持する期間であり、囲まれたテレメトリ情報が実装固有です。「TMID」がまだアクティブな場合、Peer DOTSクライアントから受信した更新の関数として、ログの詳細がDOTSサーバーによって更新されることに注意してください。
A DOTS client that lost the state of its active 'tmid's or has to set 'tmid' back to zero (e.g., crash or restart) MUST send a GET request to the DOTS server to retrieve the list of active 'tmid' values. The DOTS client may then delete 'tmid's that should not be active anymore (Figure 37). Sending a DELETE with no 'tmid' indicates that all 'tmid's must be deactivated (Figure 38).
アクティブな「tmid」の状態を失ったか、「tmid」をゼロに戻す必要があるドットクライアント（たとえば、クラッシュまたは再起動）は、アクティブな「tmid」値のリストを取得するためにDOTSサーバーにGETリクエストを送信する必要があります。DOTSクライアントは、もはやアクティブではない「TMID」を削除できます（図37）。「tmid」なしで削除を送信すると、すべての 'tmidを非アクティブ化する必要があることがわかります（図38）。
Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123"
Figure 37: Deleting Specific Pre-or-Ongoing-Mitigation Telemetry Information
図37：特定の前またはソング緩和のテレメトリ情報の削除
Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 38: Deleting All Pre-or-Ongoing-Mitigation Telemetry Information
図38：すべての事前またはソング緩和のテレメトリ情報を削除します
The pre-or-ongoing-mitigation data (attack details in particular) can also be signaled from DOTS servers to DOTS clients. For example, a DOTS server co-located with a DDoS detector can collect monitoring information from the target network, identify a DDoS attack using statistical analysis or deep learning techniques, and signal the attack details to the DOTS client.
前ソングまたはソングの緩和データ（特に攻撃の詳細）は、DOTSサーバーからDOTSクライアントに合図することもできます。たとえば、DDOS検出器と共同住宅されたDOTSサーバーは、ターゲットネットワークから監視情報を収集し、統計分析またはディープラーニング技術を使用してDDOS攻撃を特定し、攻撃の詳細をDOTSクライアントに通知することができます。
The DOTS client can use the attack details to decide whether to trigger a DOTS mitigation request or not. Furthermore, the security operations personnel at the DOTS client domain can use the attack details to determine the protection strategy and select the appropriate DOTS server for mitigating the attack.
DOTSクライアントは、攻撃の詳細を使用して、DOTS緩和リクエストをトリガーするかどうかを決定できます。さらに、DOTSクライアントドメインのセキュリティオペレーション担当者は、攻撃の詳細を使用して保護戦略を決定し、攻撃を軽減するための適切なDOTSサーバーを選択できます。
In order to receive pre-or-ongoing-mitigation telemetry notifications from a DOTS server, a DOTS client MUST send a PUT (followed by a GET) with the target filter. An example of such a PUT request is shown in Figure 39. In order to avoid maintaining a long list of such requests, it is RECOMMENDED that DOTS clients include all targets in the same request (assuming that this information fits within one single datagram). DOTS servers may be instructed to restrict the number of pre-or-ongoing-mitigation requests per DOTS client domain. The pre-or-ongoing-mitigation requests MUST be maintained in an active state by the DOTS server until a DELETE request is received from the same DOTS client to clear this pre-or-ongoing-mitigation telemetry or when the DOTS client is considered inactive (e.g., Section 3.5 of [RFC8783]).
DOTSサーバーから事前またはソング緩和のテレメトリ通知を受信するには、DOTSクライアントはターゲットフィルターでプット（GETが続く）を送信する必要があります。このようなPUTリクエストの例を図39に示します。そのようなリクエストの長いリストを維持することを避けるために、DOTSクライアントに同じ要求にすべてのターゲットを含めることをお勧めします（この情報が1つのデータグラムに適合すると仮定します）。DOTSサーバーは、ドットクライアントドメインごとに、前または音の緩和リクエストの数を制限するように指示される場合があります。同じDOTSクライアントから削除リクエストが受信され、この前またはソングミチゲーションのテレメトリをクリアするか、DOTSクライアントが非アクティブと見なされているときに、削除要求が削除要求が受信されるまで、ドットサーバーによってアクティブな状態で維持リクエストを維持する必要があります（例：[RFC8783]のセクション3.5）。
The relative order of two PUT requests carrying DOTS pre-or-ongoing-mitigation telemetry from a DOTS client is determined by comparing their respective 'tmid' values. If these two requests have an overlapping 'target', the PUT request with a higher numeric 'tmid' value will override the request with a lower numeric 'tmid' value. The overlapped lower numeric 'tmid' MUST be automatically deleted and no longer be available.
DOTSクライアントからのドットまたはソングミチゲーションのテレメトリを運ぶ2つのプット要求の相対順序は、それぞれの「tmid」値を比較することで決定されます。これらの2つの要求に「ターゲット」が重複する場合、数値が高い「TMID」値が高いPUTリクエストは、低い数値「TMID」値でリクエストをオーバーライドします。オーバーラップされた低数値「tmid」は自動的に削除され、使用できなくなる必要があります。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=567"
Content-Format: "application/dots+cbor"
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"target": {
"target-prefix": [
"2001:db8::/32"
]
}
}
]
}
}
Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry, Depicted as per Section 5.6
図39：セクション5.6に従って描かれている、事前またはソング緩和のテレメトリを要求する
DOTS clients of the same domain can ask to receive pre-or-ongoing-mitigation telemetry bound to the same target without being considered to be "overlapping" and in conflict.
同じドメインのDOTSクライアントは、同じターゲットにバインドされた前または音の緩和テレメトリを、「重複」と紛争と見なされることなく、同じターゲットにバインドされたテレメトリを受信するように求めることができます。
Once the PUT request to instantiate request state on the server has succeeded, the DOTS client issues a GET request to receive ongoing telemetry updates. The client uses the Observe Option, set to "0" (register), in the GET request to receive asynchronous notifications carrying pre-or-ongoing-mitigation telemetry data from the DOTS server. The GET request can specify a specific 'tmid' (Figure 40) or omit the 'tmid' (Figure 41) to receive updates on all active requests from that client.
サーバー上のリクエスト状態をインスタンス化するためのPUTリクエストが成功すると、DOTSクライアントは継続的なテレメトリの更新を受信するためのGETリクエストを発行します。クライアントは、DOTSサーバーからの前またはソングミチゲーションのテレメトリデータを運ぶ非同期通知を受信するために、GETリクエストで「0」（登録）に設定されたObserveオプションを使用します。GETリクエストは、特定の「TMID」（図40）を指定するか、「TMID」（図41）を省略して、そのクライアントからのすべてのアクティブなリクエストの更新を受信します。
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=567"
Observe: 0
Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'
図40：特定の「TMID」のテレメトリー非同期通知を購読してください
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0
Figure 41: GET to Subscribe to Telemetry Asynchronous Notifications for All 'tmid's
図41：すべての 'tmidのテレメトリー非同期通知を購読してください
The DOTS client can use a filter to request a subset of the asynchronous notifications from the DOTS server by indicating one or more Uri-Query options in its GET request. A Uri-Query option can include the following parameters to restrict the notifications based on the attack target: 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' (content) (Section 5.4). Furthermore:
DOTSクライアントは、フィルターを使用して、GETリクエストで1つ以上のURIクエリオプションを示すことにより、DOTSサーバーから非同期通知のサブセットを要求できます。uri-queryオプションには、攻撃ターゲットに基づいて通知を制限するための次のパラメーターを含めることができます：「ターゲットプレフィックス」、「ターゲットポート」、「ターゲットプロトコル」、「ターゲット-fqdn」、「ターゲットウリ」、「Alias-Name」、「Mid」、および「C」（コンテンツ）（セクション5.4）。さらに：
* If more than one Uri-Query option is included in a request, these options are interpreted in the same way as when multiple target attributes are included in a message body (Section 4.4.1 of [RFC9132]).
* 複数のURIクエリオプションがリクエストに含まれている場合、これらのオプションは、複数のターゲット属性がメッセージ本文に含まれている場合と同じ方法で解釈されます（[RFC9132]のセクション4.4.1）。
* If multiple values of a query parameter are to be included in a request, these values MUST be included in the same Uri-Query option and separated by a "," character without any spaces.
* クエリパラメーターの複数の値をリクエストに含める場合、これらの値は同じURI-Queryオプションに含まれ、スペースのない「、」文字で区切る必要があります。
* Range values (i.e., a contiguous inclusive block) can be included for the 'target-port', 'target-protocol', and 'mid' parameters by indicating the two boundary values separated by a "-" character.
* 範囲値（つまり、隣接する包括的なブロック）は、「 - 」文字で区切られた2つの境界値を示すことにより、「ターゲットポート」、「ターゲットプロトコル」、および「MID」パラメーターに含めることができます。
* Wildcard names (i.e., a name with the leftmost label is the "*" character) can be included in 'target-fqdn' or 'target-uri' parameters. DOTS clients MUST NOT include a name in which the "*" character is included in a label other than the leftmost label. "*.example.com" is an example of a valid wildcard name that can be included as a value of the 'target-fqdn' parameter in a Uri-Query option.
* ワイルドカード名（つまり、左端のラベルを持つ名前は「*」文字です）は、「ターゲット-FQDN」または「ターゲットウリ」パラメーターに含めることができます。DOTSクライアントには、「*」文字が左端のラベル以外のラベルに含まれる名前を含めるべきではありません。「*.example.com」は、URI-Queryオプションの「Target-FQDN」パラメーターの値として含めることができる有効なワイルドカード名の例です。
DOTS clients may also filter out the asynchronous notifications from the DOTS server by indicating information about a specific attack source. To that aim, a DOTS client may include 'source-prefix', 'source-port', or 'source-icmp-type' in a Uri-Query option. The same considerations (ranges, multiple values) specified for target attributes apply for source attributes. Special care SHOULD be taken when using these filters, as their use may cause some attacks to be hidden from the requesting DOTS client (e.g., if the attack changes its source information).
DOTSクライアントは、特定の攻撃ソースに関する情報を示すことにより、DOTSサーバーからの非同期通知を除外することもできます。その目的のために、DOTSクライアントには、URI-Queryオプションに「Source-Prefix」、「Source-Port」、または「Source-ICMPタイプ」が含まれます。ターゲット属性に指定された同じ考慮事項（範囲、複数の値）は、ソース属性に適用されます。これらのフィルターを使用する場合は、特別な注意を払う必要があります。なぜなら、それらの使用により、いくつかの攻撃が要求するDOTSクライアントから隠される可能性があるため（たとえば、攻撃がソース情報を変更した場合）。
Requests with invalid query types (e.g., not supported, malformed) received by the DOTS server MUST be rejected with a 4.00 (Bad Request) Response Code.
DOTSサーバーが受信した無効なクエリタイプ（サポートされていない、奇形）を使用した要求は、4.00（悪い要求）応答コードで拒否される必要があります。
An example of a request to subscribe to asynchronous telemetry notifications regarding UDP traffic is shown in Figure 42. This filter will be applied for all 'tmid's.
UDPトラフィックに関する非同期テレメトリ通知を購読するリクエストの例を図42に示します。このフィルターは、すべての 'TMIDに適用されます。
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "target-protocol=17"
Observe: 0
Figure 42: GET Request to Receive Telemetry Asynchronous Notifications Filtered Using Uri-Query
図42：URI-Queryを使用してフィルタリングされたテレメトリー非同期通知を受信するリクエストを取得する
The DOTS server will send asynchronous notifications to the DOTS client when an attack event is detected, following considerations similar to those discussed in Section 4.4.2.1 of [RFC9132]. An example of a pre-or-ongoing-mitigation telemetry notification is shown in Figure 43.
DOTSサーバーは、[RFC9132]のセクション4.4.2.1で説明したものと同様の考慮事項に従って、攻撃イベントが検出されたときに、DOTSクライアントに非同期通知を送信します。前または音を立てる緩和のテレメトリ通知の例を図43に示します。
{
"ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": [
{
"tmid": 567,
"target": {
"target-prefix": [
"2001:db8::1/128"
]
},
"target-protocol": [
17
],
"total-attack-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "900"
}
],
"attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"start-time": "1618339785",
"attack-severity": "high"
}
]
}
]
}
}
Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notification from the DOTS Server, Depicted as per Section 5.6
図43：セクション5.6に従って描写されているドットサーバーからの前またはソングの緩和前のテレメトリ通知のメッセージ本文
A DOTS server sends the aggregate data for a target using the 'total-attack-traffic' attribute. The aggregate assumes that Uri-Query filters are applied on the target. The DOTS server MAY include more fine-grained data when needed (that is, 'total-attack-traffic-protocol' and 'total-attack-traffic-port'). If a port filter (or protocol filter) is included in a request, 'total-attack-traffic-protocol' (or 'total-attack-traffic-port') conveys the data with the port (or protocol) filter applied.
DOTSサーバーは、「Total-Attack-Traffic」属性を使用して、ターゲットの集約データを送信します。集合体は、URI-Queryフィルターがターゲットに適用されると想定しています。DOTSサーバーには、必要に応じて、より微調整されたデータが含まれる場合があります（つまり、「Total-Attack-Traffic-Protocol」および「Total-Attack-Traffic-Port」）。ポートフィルター（またはプロトコルフィルター）がリクエストに含まれている場合、「Total-Attack-Traffic-Protocol」（または「Total-Attack-Traffic-Port」）は、ポート（またはプロトコル）フィルターを適用してデータを伝達します。
A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., 'top-talker') for all targets of a domain or, when justified, send specific information (e.g., 'top-talker') for a specific target.
DOTSサーバーは、ドメインのすべてのターゲットに対して、事前またはソングミチゲーションデータ（「トップトーカー」など）を集約するか、正当化された場合、特定のターゲットに特定の情報（「トップトーカー」など）を送信する場合があります。
The DOTS client may log pre-or-ongoing-mitigation telemetry data with an alert sent to an administrator or a network controller. The DOTS client may send a mitigation request if the attack cannot be handled locally.
DOTSクライアントは、管理者またはネットワークコントローラーに送信されたアラートを使用して、前またはソングの緩和テレメトリデータを記録できます。DOTSクライアントは、攻撃をローカルで処理できない場合、緩和リクエストを送信する場合があります。
A DOTS client that is not interested in receiving pre-or-ongoing-mitigation telemetry data for a target sends a DELETE request similar to the DELETE request depicted in Figure 37.
ターゲットの事前またはソングミチゲーションテレメトリデータを受信することに関心がないDOTSクライアントは、図37に示す削除要求と同様の削除要求を送信します。
9.1. From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS Telemetry Attributes
9.1. ドットクライアントからドットサーバーまで：緩和効果ドットテレメトリー属性
The mitigation efficacy telemetry attributes can be signaled from DOTS clients to DOTS servers as part of the periodic mitigation efficacy updates to the server (Section 4.4.3 of [RFC9132]).
緩和有効性テレメトリ属性は、サーバーへの定期的な緩和効果の更新の一部として、DOTSクライアントからDOTSサーバーに合図することができます（[RFC9132]のセクション4.4.3）。
Total attack traffic: The overall attack traffic as observed from the DOTS client's perspective during an active mitigation. See Figure 27.
総攻撃トラフィック：アクティブな緩和中のDOTSクライアントの視点から観察される全体的な攻撃トラフィック。図27を参照してください。
Attack details: The overall attack details as observed from the DOTS client's perspective during an active mitigation. See Section 8.1.5.
攻撃の詳細：アクティブな緩和中のDOTSクライアントの視点から観察される全体的な攻撃の詳細。セクション8.1.5を参照してください。
The "ietf-dots-telemetry" YANG module (Section 11.1) augments the 'mitigation-scope' message type defined in the "ietf-dots-signal-channel" module [RFC9132] so that these attributes can be signaled by a DOTS client in a mitigation efficacy update (Figure 44).
「IETF-DOTS-TELEMETRY」YANGモジュール（セクション11.1）は、「IETF-DOTS-SIGNAL-CHANNEL」モジュール[RFC9132]で定義された「緩和スコープ」メッセージタイプを拡張し、これらの属性をDOTSクライアントによって信号することができます緩和効果の更新で（図44）。
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope:
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id]
+-- vendor-id uint32
+-- attack-id uint32
+-- attack-description? string
+-- attack-severity? attack-severity
+-- start-time? uint64
+-- end-time? uint64
+-- source-count
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- top-talker
+-- talker* [source-prefix]
+-- spoofed-status? boolean
+-- 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
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-connection
+-- connection-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- embryonic-c
| ...
+-- connection-ps-c
| ...
+-- request-ps-c
| ...
+-- partial-request-c
...
Figure 44: Telemetry Efficacy Update Tree Structure
図44：テレメトリーの有効性がツリー構造を更新します
In order to signal telemetry data in a mitigation efficacy update, it is RECOMMENDED that the DOTS client have already established a DOTS telemetry setup session with the server in 'idle' time. Such a session is primarily meant to assess whether the peer DOTS server supports telemetry extensions and to thus prevent message processing failure (Section 3.1 of [RFC9132]).
緩和有効性の更新でテレメトリデータを信号するために、DOTSクライアントは、「アイドル」時間にサーバーとのDOTSテレメトリセットアップセッションをすでに確立していることをお勧めします。このようなセッションは、主にピアドットサーバーがテレメトリー拡張をサポートしているかどうかを評価し、メッセージ処理の障害を防ぐためのものです（[RFC9132]のセクション3.1）。
An example of an efficacy update with telemetry attributes is depicted in Figure 45.
テレメトリー属性を使用した有効性の更新の例を図45に示します。
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
If-Match:
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"alias-name": [
"https1",
"https2"
],
"attack-status": "under-attack",
"ietf-dots-telemetry:total-attack-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "900"
}
]
}
]
}
}
Figure 45: Example of Mitigation Efficacy Update with Telemetry Attributes, Depicted as per Section 5.6
図45：セクション5.6に従って描写されるテレメトリー属性による緩和効果の更新の例
9.2. From DOTS Servers to DOTS Clients: Mitigation Status DOTS Telemetry Attributes
9.2. ドットサーバーからドットクライアントまで：緩和ステータスドットテレメトリー属性
The mitigation status telemetry attributes can be signaled from the DOTS server to the DOTS client as part of the periodic mitigation status update (Section 4.4.2 of [RFC9132]). In particular, DOTS clients can receive asynchronous notifications of the attack details from DOTS servers using the Observe Option defined in [RFC7641].
緩和状態のテレメトリ属性は、定期的な軽減ステータスの更新の一部として、DOTSサーバーからDOTSクライアントにシグナルを作成できます（[RFC9132]のセクション4.4.2）。特に、DOTSクライアントは、[RFC7641]で定義された観察オプションを使用して、DOTSサーバーから攻撃の詳細の非同期通知を受信できます。
In order to make use of this feature, DOTS clients MUST establish a telemetry session with the DOTS server in 'idle' time and MUST set the 'server-originated-telemetry' attribute to 'true'.
この機能を利用するには、DOTSクライアントは「アイドル」時間にDOTSサーバーとのテレメトリセッションを確立し、「サーバーオリジネートテレメトリ」属性を「True」に設定する必要があります。
DOTS servers MUST NOT include telemetry attributes in mitigation status updates sent to DOTS clients for telemetry sessions in which the 'server-originated-telemetry' attribute is set to 'false'.
DOTSサーバーは、「サーバーオリジネートテレメトリー」属性が「False」に設定されているテレメトリセッションのために、DOTSクライアントに送信される緩和ステータスの更新にテレメトリ属性を含めるべきではありません。
As defined in [RFC8612], the actual mitigation activities can include several countermeasure mechanisms. The DOTS server signals the current operational status of relevant countermeasures. A list of attacks detected by these countermeasures MAY also be included. The same attributes as those defined in Section 8.1.5 are applicable for describing the attacks detected and mitigated at the DOTS server domain.
[RFC8612]で定義されているように、実際の緩和活動にはいくつかの対策メカニズムが含まれます。DOTSサーバーは、関連する対策の現在の運用ステータスを信号します。これらの対策によって検出された攻撃のリストも含めることができます。セクション8.1.5で定義されている属性と同じ属性は、DOTSサーバードメインで検出および緩和された攻撃を説明するために適用できます。
The "ietf-dots-telemetry" YANG module (Section 11.1) augments the 'mitigation-scope' message type defined in the "ietf-dots-signal-channel" module [RFC9132] with telemetry data as depicted in Figure 46.
「IETF-DOTS-TELEMETRY」Yangモジュール（セクション11.1）は、図46に示すように、「Mitigation-Scope」メッセージタイプを「IETF-DOTS-SIGNAL-CHANNEL」モジュール[RFC9132]でテレメトリデータを使用して補強します。
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope:
+-- (direction)?
| +--:(server-to-client-only)
| +-- total-traffic* [unit]
| | +-- unit unit
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- total-attack-connection
| +-- connection-c
| | +-- low-percentile-g? yang:gauge64
| | +-- mid-percentile-g? yang:gauge64
| | +-- high-percentile-g? yang:gauge64
| | +-- peak-g? yang:gauge64
| | +-- current-g? yang:gauge64
| +-- embryonic-c
| | ...
| +-- connection-ps-c
| | ...
| +-- request-ps-c
| | ...
| +-- partial-request-c
| ...
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- attack-detail* [vendor-id attack-id]
+-- vendor-id uint32
+-- attack-id uint32
+-- attack-description? string
+-- attack-severity? attack-severity
+-- start-time? uint64
+-- end-time? uint64
+-- source-count
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- top-talker
+-- talker* [source-prefix]
+-- spoofed-status? boolean
+-- 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
+-- total-attack-traffic* [unit]
| +-- unit unit
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- total-attack-connection
+-- connection-c
| +-- low-percentile-g? yang:gauge64
| +-- mid-percentile-g? yang:gauge64
| +-- high-percentile-g? yang:gauge64
| +-- peak-g? yang:gauge64
| +-- current-g? yang:gauge64
+-- embryonic-c
| ...
+-- connection-ps-c
| ...
+-- request-ps-c
| ...
+-- partial-request-c
...
Figure 46: DOTS Server-to-Client Mitigation Status Telemetry Tree Structure
図46：ドットサーバーからクライアントへの緩和ステータステレメトリーツリー構造
Figure 47 shows an example of an asynchronous notification of attack mitigation status from the DOTS server. This notification signals both the mid-percentile value of processed attack traffic and the peak count of unique sources involved in the attack.
図47は、DOTSサーバーからの攻撃緩和ステータスの非同期通知の例を示しています。この通知は、処理された攻撃トラフィックの中央部の中央値と、攻撃に関与する一意のソースのピーク数の両方を示しています。
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 12332,
"mitigation-start": "1507818434",
"alias-name": [
"https1",
"https2"
],
"lifetime": 1600,
"status": "attack-successfully-mitigated",
"bytes-dropped": "134334555",
"bps-dropped": "43344",
"pkts-dropped": "333334444",
"pps-dropped": "432432",
"ietf-dots-telemetry:total-attack-traffic": [
{
"unit": "megabit-ps",
"mid-percentile-g": "752"
}
],
"ietf-dots-telemetry:attack-detail": [
{
"vendor-id": 32473,
"attack-id": 77,
"source-count": {
"peak-g": "12683"
}
}
]
}
]
}
}
Figure 47: Response Body of a Mitigation Status with Telemetry Attributes, Depicted as per Section 5.6
図47：セクション5.6に従って描写されるテレメトリ属性を使用した緩和状態の応答本体
DOTS clients can filter out the asynchronous notifications from the DOTS server by indicating one or more Uri-Query options in its GET request. A Uri-Query option can include the following parameters: 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', and 'c' (content) (Section 5.4). The considerations discussed in Section 8.3 MUST be followed to include multiple query values, ranges ('target-port', 'target-protocol'), and wildcard names ('target-fqdn', 'target-uri').
DOTSクライアントは、GETリクエストで1つ以上のURIクエリオプションを示すことにより、DOTSサーバーからの非同期通知をフィルタリングできます。URI-queryオプションには、「ターゲットプレフィックス」、「ターゲットポート」、「ターゲットプロトコール」、「ターゲット-FQDN」、「ターゲットウリ」、「エイリアス」、および「c」という次のパラメーターを含めることができます。'（コンテンツ）（セクション5.4）。セクション8.3で説明した考慮事項には、複数のクエリ値、範囲（ターゲットポート」、「ターゲットプロトコル」）、およびワイルドカード名（「ターゲット-FQDN」、「ターゲットウリ」）を含むために、従う必要があります。
An example of a request to subscribe to asynchronous notifications bound to the "https1" alias is shown in Figure 48.
「https1」エイリアスにバインドされた非同期通知を購読するリクエストの例を図48に示します。
Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332"
Uri-Query: "target-alias=https1"
Observe: 0
Figure 48: GET Request to Receive Asynchronous Notifications Filtered Using Uri-Query
図48：URI-Queryを使用してフィルタリングされた非同期通知を受信するリクエストを取得する
If the target query does not match the target of the enclosed 'mid' as maintained by the DOTS server, the latter MUST respond with a 4.04 (Not Found) error Response Code. The DOTS server MUST NOT add a new Observe entry if this query overlaps with an existing Observe entry. In such a case, the DOTS server replies with a 4.09 (Conflict) Response Code.
ターゲットクエリがDOTSサーバーによって維持されている囲まれた「MID」のターゲットと一致しない場合、後者は4.04（見つからない）エラー応答コードで応答する必要があります。このクエリが既存の観察エントリと重複する場合、DOTSサーバーは新しい観察エントリを追加してはなりません。そのような場合、DOTSサーバーは4.09（競合）応答コードで応答します。
A list of common CoAP errors that are implemented by DOTS servers is provided in Section 9 of [RFC9132]. The following additional error cases apply for the telemetry extension:
DOTSサーバーによって実装される一般的なCOAPエラーのリストは、[RFC9132]のセクション9に記載されています。テレメトリー拡張には、次の追加のエラーケースが適用されます。
* 4.00 (Bad Request) is returned by the DOTS server when the DOTS client has sent a request that violates the DOTS telemetry extension.
* 4.00（悪い要求）は、DOTSクライアントがDOTSテレメトリー拡張に違反するリクエストを送信したときにDOTSサーバーによって返されます。
* 4.04 (Not Found) is returned by the DOTS server when the DOTS client is requesting a 'tsid' or 'tmid' that is not valid.
* 4.04（発見されていない）は、DOTSクライアントが無効になっていない「TSID」または「TMID」を要求しているときにDOTSサーバーによって返されます。
* 4.00 (Bad Request) is returned by the DOTS server when the DOTS client has sent a request with invalid query types (e.g., not supported, malformed).
* 4.00（悪い要求）は、DOTSクライアントが無効なクエリタイプ（サポートされていない、奇形）でリクエストを送信したときにDOTSサーバーによって返されます。
* 4.04 (Not Found) is returned by the DOTS server when the DOTS client has sent a request with a target query that does not match the target of the enclosed 'mid' as maintained by the DOTS server.
* 4.04（発見されていない）は、DOTSクライアントがDOTSサーバーによって維持されている囲まれた「MID」のターゲットと一致しないターゲットクエリを使用してリクエストを送信したときにDOTSサーバーによって返されます。
As indicated in Section 9 of [RFC9132], an additional plaintext diagnostic payload (Section 5.5.2 of [RFC7252]) to help with troubleshooting is returned in the body of the response.
[RFC9132]のセクション9に示されているように、トラブルシューティングを支援するための追加のプレーンテキスト診断ペイロード（[RFC7252]のセクション5.5.2）が応答の本体で返されます。
This module uses types defined in [RFC6991] and [RFC8345]. It also reuses a grouping from [RFC8783].
このモジュールは、[RFC6991]および[RFC8345]で定義されたタイプを使用します。また、[RFC8783]のグループを再利用します。
<CODE BEGINS> file "ietf-dots-telemetry@2022-06-20.yang"
module ietf-dots-telemetry {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
prefix dots-telemetry;
import ietf-dots-signal-channel {
prefix dots-signal;
reference
"RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification";
}
import ietf-dots-data-channel {
prefix data-channel;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies,
Section 6.2";
}
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: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Konda, Tirumaleswar Reddy.K <mailto:kondtir@gmail.com>"; description "This module contains YANG definitions for the signaling of DOTS telemetry data exchanged between a DOTS client and a DOTS server by means of the DOTS signal channel.
著者：konda、tirumaleswar reddy.k <mailto：kondtir@gmail.com> "; description"このモジュールには、DOTSクライアントとDOTSサーバーの間で交換されたDOTSテレメトリーデータのシグナル伝達のYang定義が含まれています。
Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2022 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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 Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている修正されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9244; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンは、RFC 9244の一部です。完全な法的通知については、RFC自体を参照してください。」;
revision 2022-06-20 {
description
"Initial revision.";
reference
"RFC 9244: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry";
}
typedef attack-severity {
type enumeration {
enum none {
value 1;
description
"No effect on the DOTS client domain.";
}
enum low {
value 2;
description
"Minimal effect on the DOTS client domain.";
}
enum medium {
value 3;
description
"A subset of DOTS client domain resources is
out of service.";
}
enum high {
value 4;
description
"The DOTS client domain is under extremely severe
conditions.";
}
enum unknown {
value 5;
description
"The impact of the attack is not known.";
}
}
description
"Enumeration for attack severity.";
reference
"RFC 7970: The Incident Object Description Exchange
Format Version 2, Section 3.12.2";
}
typedef unit-class {
type enumeration {
enum packet-ps {
value 1;
description
"Packets per second (pps).";
}
enum bit-ps {
value 2;
description
"Bits per second (bps).";
}
enum byte-ps {
value 3;
description
"Bytes per second (Bps).";
}
}
description
"Enumeration to indicate which unit class is used.
These classes are supported: pps, bps, and Bps.";
}
typedef unit {
type enumeration {
enum packet-ps {
value 1;
description
"Packets per second (pps).";
}
enum bit-ps {
value 2;
description
"Bits per second (bps).";
}
enum byte-ps {
value 3;
description
"Bytes per second (Bps).";
}
enum kilopacket-ps {
value 4;
description
"Kilo packets per second (kpps).";
}
enum kilobit-ps {
value 5;
description
"Kilobits per second (kbps).";
}
enum kilobyte-ps {
value 6;
description
"Kilobytes per second (kBps).";
}
enum megapacket-ps {
value 7;
description
"Mega packets per second (Mpps).";
}
enum megabit-ps {
value 8;
description
"Megabits per second (Mbps).";
}
enum megabyte-ps {
value 9;
description
"Megabytes per second (MBps).";
}
enum gigapacket-ps {
value 10;
description
"Giga packets per second (Gpps).";
}
enum gigabit-ps {
value 11;
description
"Gigabits per second (Gbps).";
}
enum gigabyte-ps {
value 12;
description
"Gigabytes per second (GBps).";
}
enum terapacket-ps {
value 13;
description
"Tera packets per second (Tpps).";
}
enum terabit-ps {
value 14;
description
"Terabits per second (Tbps).";
}
enum terabyte-ps {
value 15;
description
"Terabytes per second (TBps).";
}
enum petapacket-ps {
value 16;
description
"Peta packets per second (Ppps).";
}
enum petabit-ps {
value 17;
description
"Petabits per second (Pbps).";
}
enum petabyte-ps {
value 18;
description
"Petabytes per second (PBps).";
}
enum exapacket-ps {
value 19;
description
"Exa packets per second (Epps).";
}
enum exabit-ps {
value 20;
description
"Exabits per second (Ebps).";
}
enum exabyte-ps {
value 21;
description
"Exabytes per second (EBps).";
}
enum zettapacket-ps {
value 22;
description
"Zetta packets per second (Zpps).";
}
enum zettabit-ps {
value 23;
description
"Zettabits per second (Zbps).";
}
enum zettabyte-ps {
value 24;
description
"Zettabytes per second (ZBps).";
}
}
description
"Enumeration to indicate which unit is used.
Only one unit per unit class is used owing to
unit auto-scaling.";
}
typedef interval {
type enumeration {
enum 5-minutes {
value 1;
description
"5 minutes.";
}
enum 10-minutes {
value 2;
description
"10 minutes.";
}
enum 30-minutes {
value 3;
description
"30 minutes.";
}
enum hour {
value 4;
description
"Hour.";
}
enum day {
value 5;
description
"Day.";
}
enum week {
value 6;
description
"Week.";
}
enum month {
value 7;
description
"Month.";
}
}
description
"Enumeration to indicate the overall measurement period.";
}
typedef sample {
type enumeration {
enum second {
value 1;
description
"One-second measurement period.";
}
enum 5-seconds {
value 2;
description
"5-second measurement period.";
}
enum 30-seconds {
value 3;
description
"30-second measurement period.";
}
enum minute {
value 4;
description
"One-minute measurement period.";
}
enum 5-minutes {
value 5;
description
"5-minute measurement period.";
}
enum 10-minutes {
value 6;
description
"10-minute measurement period.";
}
enum 30-minutes {
value 7;
description
"30-minute measurement period.";
}
enum hour {
value 8;
description
"One-hour measurement period.";
}
}
description
"Enumeration to indicate the sampling period.";
}
typedef percentile {
type decimal64 {
fraction-digits 2;
}
description
"The nth percentile of a set of data is the
value at which n percent of the data is below it.";
}
typedef query-type {
type enumeration {
enum target-prefix {
value 1;
description
"Query based on target prefix.";
}
enum target-port {
value 2;
description
"Query based on target port number.";
}
enum target-protocol {
value 3;
description
"Query based on target protocol.";
}
enum target-fqdn {
value 4;
description
"Query based on target FQDN.";
}
enum target-uri {
value 5;
description
"Query based on target URI.";
}
enum target-alias {
value 6;
description
"Query based on target alias.";
}
enum mid {
value 7;
description
"Query based on mitigation identifier (mid).";
}
enum source-prefix {
value 8;
description
"Query based on source prefix.";
}
enum source-port {
value 9;
description
"Query based on source port number.";
}
enum source-icmp-type {
value 10;
description
"Query based on ICMP type.";
}
enum content {
value 11;
description
"Query based on the 'c' (content) Uri-Query option,
which is used to control the selection of configuration
and non-configuration data nodes.";
reference
"RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel
Specification, Section 4.4.2";
}
}
description
"Enumeration of support for query types that can be used
in a GET request to filter out data. Requests with
invalid query types (e.g., not supported, malformed)
received by the DOTS server are rejected with
a 4.00 (Bad Request) Response Code.";
}
grouping telemetry-parameters { description "A grouping that includes a set of parameters that are used to prepare the reported telemetry data.
Telemetry-Parametersのグループ化{説明 "報告されたテレメトリデータの準備に使用されるパラメーターのセットを含むグループ化。
The grouping indicates a measurement interval,
a measurement sample period, and
low-percentile/mid-percentile/high-percentile values.";
leaf measurement-interval {
type interval;
description
"Defines the period during which percentiles are
computed.";
}
leaf measurement-sample {
type sample;
description
"Defines the time distribution for measuring
values that are used to compute percentiles.
The measurement sample value must be less than the
measurement interval value.";
}
leaf low-percentile {
type percentile;
default "10.00";
description
"Low-percentile. If set to '0', this means that
the use of low-percentile values is disabled.";
}
leaf mid-percentile {
type percentile;
must '. >= ../low-percentile' {
error-message
"The mid-percentile must be greater than
or equal to the low-percentile.";
}
default "50.00";
description
"Mid-percentile. If set to the same value as
'low-percentile', this means that the use of
mid-percentile values is disabled.";
}
leaf high-percentile {
type percentile;
must '. >= ../mid-percentile' {
error-message
"The high-percentile must be greater than
or equal to the mid-percentile.";
}
default "90.00";
description
"High-percentile. If set to the same value as
'mid-percentile', this means that the use of
high-percentile values is disabled.";
}
}
grouping percentile-and-peak {
description
"Generic grouping for percentile and peak values.";
leaf low-percentile-g {
type yang:gauge64;
description
"Low-percentile value.";
}
leaf mid-percentile-g {
type yang:gauge64;
description
"Mid-percentile value.";
}
leaf high-percentile-g {
type yang:gauge64;
description
"High-percentile value.";
}
leaf peak-g {
type yang:gauge64;
description
"Peak value.";
}
}
grouping percentile-peak-and-current {
description
"Generic grouping for percentile and peak values.";
uses percentile-and-peak;
leaf current-g {
type yang:gauge64;
description
"Current value.";
}
}
grouping unit-config {
description
"Generic grouping for unit configuration.";
list unit-config {
key "unit";
description
"Controls which unit classes are allowed when sharing
telemetry data.";
leaf unit {
type unit-class;
description
"Can be 'packet-ps', 'bit-ps', or 'byte-ps'.";
}
leaf unit-status {
type boolean;
mandatory true;
description
"Enable/disable the use of the measurement unit class.";
}
}
}
grouping traffic-unit {
description
"Grouping of traffic as a function of the
measurement unit.";
leaf unit {
type unit;
description
"The traffic can be measured using unit classes:
'packet-ps', 'bit-ps', or 'byte-ps'. DOTS agents
auto-scale to the appropriate units (e.g., 'megabit-ps',
'kilobit-ps').";
}
uses percentile-and-peak;
}
grouping traffic-unit-all {
description
"Grouping of traffic as a function of the measurement unit,
including current values.";
uses traffic-unit;
leaf current-g {
type yang:gauge64;
description
"Current observed value.";
}
}
grouping traffic-unit-protocol {
description
"Grouping of traffic of a given transport protocol as
a function of the measurement unit.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>.
For example, this parameter contains 6 for TCP,
17 for UDP, 33 for the Datagram Congestion Control
Protocol (DCCP), or 132 for the Stream Control
Transmission Protocol (SCTP).";
}
uses traffic-unit;
}
grouping traffic-unit-protocol-all {
description
"Grouping of traffic of a given transport protocol as
a function of the measurement unit, including current
values.";
uses traffic-unit-protocol;
leaf current-g {
type yang:gauge64;
description
"Current observed value.";
}
}
grouping traffic-unit-port {
description
"Grouping of traffic bound to a port number as
a function of the measurement unit.";
leaf port {
type inet:port-number;
description
"Port number used by a transport protocol.";
}
uses traffic-unit;
}
grouping traffic-unit-port-all {
description
"Grouping of traffic bound to a port number as
a function of the measurement unit, including
current values.";
uses traffic-unit-port;
leaf current-g {
type yang:gauge64;
description
"Current observed value.";
}
}
grouping total-connection-capacity {
description
"Total connection capacities for various types of
connections, as well as overall capacity. These data nodes
are useful for detecting resource-consuming DDoS attacks.";
leaf connection {
type uint64;
description
"The maximum number of simultaneous connections that
are allowed to the target server.";
}
leaf connection-client {
type uint64;
description
"The maximum number of simultaneous connections that
are allowed to the target server per client.";
}
leaf embryonic {
type uint64;
description
"The maximum number of simultaneous embryonic connections
that are allowed to the target server. The term
'embryonic connection' refers to a connection whose
connection handshake is not finished. Embryonic
connections are only possible in connection-oriented
transport protocols like TCP or SCTP.";
}
leaf embryonic-client {
type uint64;
description
"The maximum number of simultaneous embryonic connections
that are allowed to the target server per client.";
}
leaf connection-ps {
type uint64;
description
"The maximum number of new connections allowed per second
to the target server.";
}
leaf connection-client-ps {
type uint64;
description
"The maximum number of new connections allowed per second
to the target server per client.";
}
leaf request-ps {
type uint64;
description
"The maximum number of requests allowed per second
to the target server.";
}
leaf request-client-ps {
type uint64;
description
"The maximum number of requests allowed per second
to the target server per client.";
}
leaf partial-request-max {
type uint64;
description
"The maximum number of outstanding partial requests
that are allowed to the target server.";
}
leaf partial-request-client-max {
type uint64;
description
"The maximum number of outstanding partial requests
that are allowed to the target server per client.";
}
}
grouping total-connection-capacity-protocol {
description
"Total connection capacity per protocol. These data nodes
are useful for detecting resource-consuming DDoS attacks.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
uses total-connection-capacity;
}
grouping connection-percentile-and-peak {
description
"A set of data nodes that represent the attack
characteristics.";
container connection-c {
uses percentile-and-peak;
description
"The number of simultaneous attack connections to
the target server.";
}
container embryonic-c {
uses percentile-and-peak;
description
"The number of simultaneous embryonic connections to
the target server.";
}
container connection-ps-c {
uses percentile-and-peak;
description
"The number of attack connections per second to
the target server.";
}
container request-ps-c {
uses percentile-and-peak;
description
"The number of attack requests per second to
the target server.";
}
container partial-request-c {
uses percentile-and-peak;
description
"The number of attack partial requests to
the target server.";
}
}
grouping connection-all {
description
"Total attack connections, including current values.";
container connection-c {
uses percentile-peak-and-current;
description
"The number of simultaneous attack connections to
the target server.";
}
container embryonic-c {
uses percentile-peak-and-current;
description
"The number of simultaneous embryonic connections to
the target server.";
}
container connection-ps-c {
uses percentile-peak-and-current;
description
"The number of attack connections per second to
the target server.";
}
container request-ps-c {
uses percentile-peak-and-current;
description
"The number of attack requests per second to
the target server.";
}
container partial-request-c {
uses percentile-peak-and-current;
description
"The number of attack partial requests to
the target server.";
}
}
grouping connection-protocol {
description
"Total attack connections.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
uses connection-percentile-and-peak;
}
grouping connection-port {
description
"Total attack connections per port number.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
leaf port {
type inet:port-number;
description
"Port number.";
}
uses connection-percentile-and-peak;
}
grouping connection-protocol-all {
description
"Total attack connections per protocol, including current
values.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
uses connection-all;
}
grouping connection-protocol-port-all {
description
"Total attack connections per port number, including current
values.";
leaf protocol {
type uint8;
description
"The transport protocol.
Values are taken from the IANA 'Protocol Numbers'
registry:
<https://www.iana.org/assignments/protocol-numbers/>.";
}
leaf port {
type inet:port-number;
description
"Port number.";
}
uses connection-all;
}
grouping attack-detail {
description
"Various details that describe the ongoing
attacks that need to be mitigated by the DOTS server.
The attack details need to cover well-known and common
attacks (such as a SYN flood) along with new emerging or
vendor-specific attacks.";
leaf vendor-id {
type uint32;
description
"The Vendor ID is a security vendor's Private Enterprise
Number as registered with IANA.";
reference
"IANA: Private Enterprise Numbers
(https://www.iana.org/assignments/enterprise-numbers/)";
}
leaf attack-id {
type uint32;
description
"Unique identifier assigned by the vendor for the attack.";
}
leaf description-lang {
type string {
pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
+ '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
+ '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
+ '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
+ '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
+ '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
+ '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
+ '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
+ '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
+ '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
+ '|[Ii]-[Hh][Aa][Kk]|'
+ '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
+ '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
+ '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
+ '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
+ '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
+ '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
+ '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
+ '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
+ '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
+ '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
+ '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
+ '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
+ '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
+ '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))';
}
default "en-US";
description
"Indicates the language tag that is used for
'attack-description'.";
reference
"RFC 5646: Tags for Identifying Languages, Section 2.1";
}
leaf attack-description {
type string;
description
"Textual representation of the attack description.
Natural Language Processing techniques (e.g.,
word embedding) might provide some utility in mapping
the attack description to an attack type.";
}
leaf attack-severity {
type attack-severity;
description
"Severity level of an attack. How this level is
determined is implementation specific.";
}
leaf start-time {
type uint64;
description
"The time the attack started. The start time is
represented in seconds relative to
1970-01-01T00:00:00Z.";
}
leaf end-time {
type uint64;
description
"The time the attack ended. The end time is represented
in seconds relative to 1970-01-01T00:00:00Z.";
}
container source-count {
description
"Indicates the count of unique sources involved
in the attack.";
uses percentile-and-peak;
leaf current-g {
type yang:gauge64;
description
"Current observed value.";
}
}
}
grouping talker {
description
"Defines generic data related to top talkers.";
leaf spoofed-status {
type boolean;
description
"When set to 'true', it indicates whether this address
is spoofed.";
}
leaf source-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifying the attacker(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 type range. When only 'lower-type' is
present, it represents a single ICMP type.";
leaf lower-type {
type uint8;
description
"Lower ICMP type of the ICMP type range.";
}
leaf upper-type {
type uint8;
must '. >= ../lower-type' {
error-message
"The upper ICMP type must be greater than
or equal to the lower ICMP type.";
}
description
"Upper type of the ICMP type range.";
}
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic issued from this source.";
uses traffic-unit-all;
}
}
grouping top-talker-aggregate {
description
"An aggregate of top attack sources. This aggregate is
typically used when included in a mitigation request.";
list talker {
key "source-prefix";
description
"Refers to a top talker that is identified by an IPv4
or IPv6 prefix identifying the attacker(s).";
uses talker;
container total-attack-connection {
description
"Total attack connections issued from this source.";
uses connection-all;
}
}
}
grouping top-talker {
description
"Top attack sources with detailed per-protocol
structure.";
list talker {
key "source-prefix";
description
"Refers to a top talker that is identified by an IPv4
or IPv6 prefix identifying the attacker(s).";
uses talker;
list total-attack-connection-protocol {
key "protocol";
description
"Total attack connections issued from this source.";
uses connection-protocol-all;
}
}
}
grouping baseline {
description
"Grouping for the telemetry baseline.";
uses data-channel:target;
leaf-list alias-name {
type string;
description
"An alias name that points to an IP resource.
An IP resource can be a router, a host,
an Internet of Things (IoT) object, a server, etc.";
}
list total-traffic-normal {
key "unit";
description
"Total traffic normal baselines.";
uses traffic-unit;
}
list total-traffic-normal-per-protocol {
key "unit protocol";
description
"Total traffic normal baselines per protocol.";
uses traffic-unit-protocol;
}
list total-traffic-normal-per-port {
key "unit port";
description
"Total traffic normal baselines per port number.";
uses traffic-unit-port;
}
list total-connection-capacity {
key "protocol";
description
"Total connection capacity.";
uses total-connection-capacity-protocol;
}
list total-connection-capacity-per-port {
key "protocol port";
description
"Total connection capacity per port number.";
leaf port {
type inet:port-number;
description
"The target port number.";
}
uses total-connection-capacity-protocol;
}
}
grouping pre-or-ongoing-mitigation {
description
"Grouping for the telemetry data.";
list total-traffic {
key "unit";
description
"Total traffic.";
uses traffic-unit-all;
}
list total-traffic-protocol {
key "unit protocol";
description
"Total traffic per protocol.";
uses traffic-unit-protocol-all;
}
list total-traffic-port {
key "unit port";
description
"Total traffic per port number.";
uses traffic-unit-port-all;
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic.";
uses traffic-unit-all;
}
list total-attack-traffic-protocol {
key "unit protocol";
description
"Total attack traffic per protocol.";
uses traffic-unit-protocol-all;
}
list total-attack-traffic-port {
key "unit port";
description
"Total attack traffic per port number.";
uses traffic-unit-port-all;
}
list total-attack-connection-protocol {
key "protocol";
description
"Total attack connections.";
uses connection-protocol-all;
}
list total-attack-connection-port {
key "protocol port";
description
"Total attack connections per target port number.";
uses connection-protocol-port-all;
}
list attack-detail {
key "vendor-id attack-id";
description
"Provides a set of attack details.";
uses attack-detail;
container top-talker {
description
"Lists the top attack sources.";
uses top-talker;
}
}
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:mitigation-scope"
+ "/dots-signal:scope" {
description
"Extends mitigation scope with telemetry update data.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a mitigation message
sent from the server to the client.";
list total-traffic {
key "unit";
description
"Total traffic.";
uses traffic-unit-all;
}
container total-attack-connection {
description
"Total attack connections.";
uses connection-all;
}
}
}
list total-attack-traffic {
key "unit";
description
"Total attack traffic.";
uses traffic-unit-all;
}
list attack-detail {
key "vendor-id attack-id";
description
"Attack details.";
uses attack-detail;
container top-talker {
description
"Top attack sources.";
uses top-talker-aggregate;
}
}
}
sx:structure dots-telemetry {
description
"Main structure for DOTS telemetry messages.";
choice telemetry-message-type {
description
"Can be 'telemetry-setup' or telemetry data.";
case telemetry-setup {
description
"Indicates that the message is about telemetry setup.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a telemetry message
sent from the server to the client.";
container max-config-values {
description
"Maximum acceptable configuration values.";
uses telemetry-parameters;
leaf server-originated-telemetry {
type boolean;
default "false";
description
"Indicates whether the DOTS server can be
instructed to send pre-or-ongoing-mitigation
telemetry. If set to 'false' or the data node
is not present, this is an indication that
the server does not support this capability.";
}
leaf telemetry-notify-interval {
type uint16 {
range "1 .. 3600";
}
units "seconds";
must '. >= ../../min-config-values'
+ '/telemetry-notify-interval' {
error-message
"The value must be greater than or equal
to the 'telemetry-notify-interval' value in
the 'min-config-values' attribute";
}
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
container min-config-values {
description
"Minimum acceptable configuration values.";
uses telemetry-parameters;
leaf telemetry-notify-interval {
type uint16 {
range "1 .. 3600";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
container supported-unit-classes {
description
"Supported unit classes and default activation
status.";
uses unit-config;
}
leaf-list supported-query-type {
type query-type;
description
"Indicates which query types are supported by
the server. If the server does not announce
the query types it supports, the client will
be unable to use any of the potential
'query-type' values to reduce the returned data
content from the server.";
}
}
}
list telemetry {
description
"The telemetry data per DOTS client. The keys
of the list are 'cuid' and 'tsid', but these keys are
not represented here because these keys are conveyed
as mandatory Uri-Paths in requests. Omitting keys
is compliant with RFC 8791.";
reference
"RFC 8791: YANG Data Structure Extensions";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a telemetry
message sent from the server to the client.";
leaf tsid {
type uint32;
description
"A client-assigned identifier for the DOTS
telemetry setup data.";
}
}
}
choice setup-type {
description
"Can be a mitigation configuration, a pipe capacity,
or a baseline message.";
case telemetry-config {
description
"Used to set telemetry parameters such as setting
low-, mid-, and high-percentile values.";
container current-config {
description
"Current telemetry configuration values.";
uses telemetry-parameters;
uses unit-config;
leaf server-originated-telemetry {
type boolean;
description
"Used by a DOTS client to enable/disable
whether it requests pre-or-ongoing-mitigation
telemetry from the DOTS server.";
}
leaf telemetry-notify-interval {
type uint16 {
range "1 .. 3600";
}
units "seconds";
description
"Minimum number of seconds between successive
telemetry notifications.";
}
}
}
case pipe {
description
"Total pipe capacity of a DOTS client domain.";
list total-pipe-capacity {
key "link-id unit";
description
"Total pipe capacity of a DOTS client domain.";
leaf link-id {
type nt:link-id;
description
"Identifier of an interconnection link of
the DOTS client domain.";
}
leaf capacity {
type uint64;
mandatory true;
description
"Pipe capacity. This attribute is mandatory
when 'total-pipe-capacity' is included in a
message.";
}
leaf unit {
type unit;
description
"The traffic can be measured using unit
classes: packets per second (pps), bits per
second (bps), and/or bytes per second
(Bps).
For a given unit class, the DOTS agents
auto-scale to the appropriate units (e.g.,
'megabit-ps', 'kilobit-ps').";
}
}
}
case baseline {
description
"Traffic baseline information related to a DOTS
client domain.";
list baseline {
key "id";
description
"Traffic baseline information related to a DOTS
client domain.";
leaf id {
type uint32;
must '. >= 1';
description
"An identifier that uniquely identifies a
baseline entry communicated by a
DOTS client.";
}
uses baseline;
}
}
}
}
}
case telemetry {
description
"Telemetry information.";
list pre-or-ongoing-mitigation {
description
"Pre-or-ongoing-mitigation telemetry per DOTS client.
The keys of the list are 'cuid' and 'tmid', but these
keys are not represented here because these keys are
conveyed as mandatory Uri-Paths in requests.
Omitting keys is compliant with RFC 8791.";
reference
"RFC 8791: YANG Data Structure Extensions";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a telemetry
message sent from the server to the client.";
leaf tmid {
type uint32;
description
"A client-assigned identifier for the DOTS
telemetry data.";
}
}
}
container target {
description
"Indicates the target. At least one of the
attributes 'target-prefix', 'target-fqdn',
'target-uri', 'alias-name', or 'mid-list'
must be present in the target definition.";
uses data-channel:target;
leaf-list alias-name {
type string;
description
"An alias name that points to a resource.";
}
leaf-list mid-list {
type uint32;
description
"Reference to a list of associated mitigation
requests.";
reference
"RFC 9132: Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal Channel
Specification, Section 4.4.1";
}
}
uses pre-or-ongoing-mitigation;
}
}
}
}
}
<CODE ENDS>
<CODE BEGINS> file "ietf-dots-mapping@2022-06-20.yang"
module ietf-dots-mapping {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
prefix dots-mapping;
import ietf-dots-data-channel {
prefix data-channel;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Jon Shallow <mailto:supjps-ietf@jpshallow.com>"; description "This module contains YANG definitions for the sharing of DDoS attack mapping details between a DOTS client and a DOTS server by means of the DOTS data channel.
著者：Jon Shallow <Mailto：supjps-ietf@jpshallow.com> ";説明"このモジュールには、DOTSデータチャネルを使用してDOTSクライアントとDOTSサーバー間のDDOS攻撃マッピングの詳細を共有するためのYang定義が含まれています。
Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2022 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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 Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている修正されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9244; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンは、RFC 9244の一部です。完全な法的通知については、RFC自体を参照してください。」;
revision 2022-06-20 {
description
"Initial revision.";
reference
"RFC 9244: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry";
}
feature dots-telemetry {
description
"This feature indicates that DOTS telemetry data can be
shared between DOTS clients and servers.";
}
grouping attack-mapping {
description
"A set of information used for sharing vendor attack mapping
information with a peer.";
list vendor {
key "vendor-id";
description
"Vendor attack mapping information related to the
client/server.";
leaf vendor-id {
type uint32;
description
"The Vendor ID is a security vendor's Private Enterprise
Number as registered with IANA.";
reference
"IANA: Private Enterprise Numbers
(https://www.iana.org/assignments/enterprise-numbers/)";
}
leaf vendor-name {
type string;
description
"The name of the vendor (e.g., company A).";
}
leaf description-lang {
type string {
pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
+ '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
+ '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
+ '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
+ '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
+ '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
+ '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
+ '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
+ '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
+ '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
+ '|[Ii]-[Hh][Aa][Kk]|'
+ '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
+ '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
+ '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
+ '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
+ '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
+ '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
+ '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
+ '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
+ '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
+ '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
+ '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
+ '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
+ '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
+ '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))';
}
default "en-US";
description
"Indicates the language tag that is used for
'attack-description'.";
reference
"RFC 5646: Tags for Identifying Languages, Section 2.1";
}
leaf last-updated {
type uint64;
mandatory true;
description
"The time the mapping table was updated. It is
represented in seconds relative to
1970-01-01T00:00:00Z.";
}
list attack-mapping {
key "attack-id";
description
"Attack mapping details.";
leaf attack-id {
type uint32;
description
"Unique identifier assigned by the vendor for the
attack.";
}
leaf attack-description {
type string;
mandatory true;
description
"Textual representation of the attack description.
Natural Language Processing techniques (e.g.,
word embedding) might provide some utility in
mapping the attack description to an attack type.";
}
}
}
}
augment "/data-channel:dots-data/data-channel:dots-client" {
if-feature "dots-telemetry";
description
"Augments the data channel with a vendor attack
mapping table of the DOTS client.";
container vendor-mapping {
description
"Used by DOTS clients to share their vendor
attack mapping information with DOTS servers.";
uses attack-mapping;
}
}
augment "/data-channel:dots-data/data-channel:capabilities" {
if-feature "dots-telemetry";
description
"Augments the DOTS server capabilities with a
parameter to indicate whether they can share
attack mapping details.";
leaf vendor-mapping-enabled {
type boolean;
config false;
description
"Indicates that the DOTS server supports sharing
attack vendor mapping details with DOTS clients.";
}
}
augment "/data-channel:dots-data" {
if-feature "dots-telemetry";
description
"Augments the data channel with a vendor attack
mapping table of the DOTS server.";
container vendor-mapping {
config false;
description
"Includes the list of vendor attack mapping details
that will be shared with DOTS clients upon request.";
uses attack-mapping;
}
}
}
<CODE ENDS>
All DOTS telemetry parameters in the payload of the DOTS signal channel MUST be mapped to CBOR types as shown in Table 3:
ドット信号チャネルのペイロードのすべてのドットテレメトリーパラメーターは、表3に示すようにCBORタイプにマッピングする必要があります。
Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the contents of Table 3.
注：実装者は、Yang-to-cborエンコーディングスキームによって提供されるマッピング出力が表3の内容に沿っていることを確認する必要があります。
+======================+==============+======+=============+========+
|Parameter Name |YANG Type |CBOR |CBOR Major | JSON |
| | |Key |Type & | Type |
| | | |Information | |
+======================+==============+======+=============+========+
|tsid |uint32 |128 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|telemetry |list |129 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|low-percentile |decimal64 |130 |6 tag 4 [-2, | String |
| | | |integer] | |
+----------------------+--------------+------+-------------+--------+
|mid-percentile |decimal64 |131 |6 tag 4 [-2, | String |
| | | |integer] | |
+----------------------+--------------+------+-------------+--------+
|high-percentile |decimal64 |132 |6 tag 4 [-2, | String |
| | | |integer] | |
+----------------------+--------------+------+-------------+--------+
|unit-config |list |133 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|unit |enumeration |134 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|unit-status |boolean |135 |7 bits 20 | False |
| | | +-------------+--------+
| | | |7 bits 21 | True |
+----------------------+--------------+------+-------------+--------+
|total-pipe-capacity |list |136 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|link-id |string |137 |3 text string| String |
+----------------------+--------------+------+-------------+--------+
|pre-or-ongoing- |list |138 |4 array | Array |
|mitigation | | | | |
+----------------------+--------------+------+-------------+--------+
|total-traffic-normal |list |139 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|low-percentile-g |yang:gauge64 |140 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|mid-percentile-g |yang:gauge64 |141 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|high-percentile-g |yang:gauge64 |142 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|peak-g |yang:gauge64 |143 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|total-attack-traffic |list |144 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|total-traffic |list |145 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|total-connection- |list |146 |4 array | Array |
|capacity | | | | |
+----------------------+--------------+------+-------------+--------+
|connection |uint64 |147 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|connection-client |uint64 |148 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|embryonic |uint64 |149 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|embryonic-client |uint64 |150 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|connection-ps |uint64 |151 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|connection-client-ps |uint64 |152 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|request-ps |uint64 |153 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|request-client-ps |uint64 |154 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|partial-request-max |uint64 |155 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|partial-request- |uint64 |156 |0 unsigned | String |
|client-max | | | | |
+----------------------+--------------+------+-------------+--------+
|total-attack- |container |157 |5 map | Object |
|connection | | | | |
+----------------------+--------------+------+-------------+--------+
|connection-c |container |158 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|embryonic-c |container |159 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|connection-ps-c |container |160 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|request-ps-c |container |161 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|attack-detail |list |162 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|id |uint32 |163 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|attack-id |uint32 |164 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|attack-description |string |165 |3 text string| String |
+----------------------+--------------+------+-------------+--------+
|attack-severity |enumeration |166 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|start-time |uint64 |167 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|end-time |uint64 |168 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|source-count |container |169 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|top-talker |container |170 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|spoofed-status |boolean |171 |7 bits 20 | False |
| | | +-------------+--------+
| | | |7 bits 21 | True |
+----------------------+--------------+------+-------------+--------+
|partial-request-c |container |172 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|total-attack- |list |173 |4 array | Array |
|connection-protocol | | | | |
+----------------------+--------------+------+-------------+--------+
|baseline |list |174 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|current-config |container |175 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|max-config-values |container |176 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|min-config-values |container |177 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|supported-unit-classes|container |178 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|server-originated- |boolean |179 |7 bits 20 | False |
|telemetry | | +-------------+--------+
| | | |7 bits 21 | True |
+----------------------+--------------+------+-------------+--------+
|telemetry-notify- |uint16 |180 |0 unsigned | Number |
|interval | | | | |
+----------------------+--------------+------+-------------+--------+
|tmid |uint32 |181 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|measurement-interval |enumeration |182 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|measurement-sample |enumeration |183 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|talker |list |184 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|source-prefix |inet:ip-prefix|185 |3 text string| String |
+----------------------+--------------+------+-------------+--------+
|mid-list |leaf-list |186 |4 array | Array |
| +--------------+------+-------------+--------+
| |uint32 | |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|source-port-range |list |187 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|source-icmp-type-range|list |188 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|target |container |189 |5 map | Object |
+----------------------+--------------+------+-------------+--------+
|capacity |uint64 |190 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|protocol |uint8 |191 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|total-traffic-normal- |list |192 |4 array | Array |
|per-protocol | | | | |
+----------------------+--------------+------+-------------+--------+
|total-traffic-normal- |list |193 |4 array | Array |
|per-port | | | | |
+----------------------+--------------+------+-------------+--------+
|total-connection- |list |194 |4 array | Array |
|capacity-per-port | | | | |
+----------------------+--------------+------+-------------+--------+
|total-traffic-protocol|list |195 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|total-traffic-port |list |196 |4 array | Array |
+----------------------+--------------+------+-------------+--------+
|total-attack-traffic- |list |197 |4 array | Array |
|protocol | | | | |
+----------------------+--------------+------+-------------+--------+
|total-attack-traffic- |list |198 |4 array | Array |
|port | | | | |
+----------------------+--------------+------+-------------+--------+
|total-attack- |list |199 |4 array | Array |
|connection-port | | | | |
+----------------------+--------------+------+-------------+--------+
|port |inet:port- |200 |0 unsigned | Number |
| |number | | | |
+----------------------+--------------+------+-------------+--------+
|supported-query-type |leaf-list |201 |4 array | Array |
| +--------------+------+-------------+--------+
| | | |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|vendor-id |uint32 |202 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |container |203 |5 map | Object |
|telemetry:telemetry- | | | | |
|setup | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |list |204 |4 array | Array |
|telemetry:total- | | | | |
|traffic | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |list |205 |4 array | Array |
|telemetry:total- | | | | |
|attack-traffic | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |container |206 |5 map | Object |
|telemetry:total- | | | | |
|attack-connection | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |list |207 |4 array | Array |
|telemetry:attack- | | | | |
|detail | | | | |
+----------------------+--------------+------+-------------+--------+
|ietf-dots- |container |208 |5 map | Object |
|telemetry:telemetry | | | | |
+----------------------+--------------+------+-------------+--------+
|current-g |yang:gauge64 |209 |0 unsigned | String |
+----------------------+--------------+------+-------------+--------+
|description-lang |string |210 |3 text string| String |
+----------------------+--------------+------+-------------+--------+
|lower-type |uint8 |32771 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
|upper-type |uint8 |32772 |0 unsigned | Number |
+----------------------+--------------+------+-------------+--------+
Table 3: YANG/JSON Mapping Parameters to CBOR
表3：CborへのYang/JSONマッピングパラメーター
This specification registers the following comprehension-optional parameters in the IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
この仕様は、IANA「Dots Signal Channel Cborキー値」レジストリ[キーマップ]の次の理解 - オプションパラメーターを登録します。
+======================+==========+=======+============+===========+
| Parameter Name | CBOR Key | CBOR | Change | Reference |
| | Value | Major | Controller | |
| | | Type | | |
+======================+==========+=======+============+===========+
| tsid | 128 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| telemetry | 129 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| low-percentile | 130 | 6tag4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| mid-percentile | 131 | 6tag4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| high-percentile | 132 | 6tag4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| unit-config | 133 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| unit | 134 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| unit-status | 135 | 7 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-pipe-capacity | 136 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| link-id | 137 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| pre-or-ongoing- | 138 | 4 | IESG | RFC 9244 |
| mitigation | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic-normal | 139 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| low-percentile-g | 140 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| mid-percentile-g | 141 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| high-percentile-g | 142 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| peak-g | 143 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-attack-traffic | 144 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-traffic | 145 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-connection- | 146 | 4 | IESG | RFC 9244 |
| capacity | | | | |
+----------------------+----------+-------+------------+-----------+
| connection | 147 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-client | 148 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| embryonic | 149 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| embryonic-client | 150 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-ps | 151 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-client-ps | 152 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| request-ps | 153 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| request-client-ps | 154 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| partial-request-max | 155 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| partial-request- | 156 | 0 | IESG | RFC 9244 |
| client-max | | | | |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 157 | 5 | IESG | RFC 9244 |
| connection | | | | |
+----------------------+----------+-------+------------+-----------+
| connection-c | 158 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| embryonic-c | 159 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| connection-ps-c | 160 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| request-ps-c | 161 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-detail | 162 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| id | 163 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-id | 164 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-description | 165 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| attack-severity | 166 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| start-time | 167 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| end-time | 168 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-count | 169 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| top-talker | 170 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| spoofed-status | 171 | 7 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| partial-request-c | 172 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 173 | 4 | IESG | RFC 9244 |
| connection-protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| baseline | 174 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| current-config | 175 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| max-config-values | 176 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| min-config-values | 177 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| supported-unit- | 178 | 5 | IESG | RFC 9244 |
| classes | | | | |
+----------------------+----------+-------+------------+-----------+
| server-originated- | 179 | 7 | IESG | RFC 9244 |
| telemetry | | | | |
+----------------------+----------+-------+------------+-----------+
| telemetry-notify- | 180 | 0 | IESG | RFC 9244 |
| interval | | | | |
+----------------------+----------+-------+------------+-----------+
| tmid | 181 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| measurement-interval | 182 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| measurement-sample | 183 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| talker | 184 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-prefix | 185 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| mid-list | 186 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-port-range | 187 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| source-icmp-type- | 188 | 4 | IESG | RFC 9244 |
| range | | | | |
+----------------------+----------+-------+------------+-----------+
| target | 189 | 5 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| capacity | 190 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| protocol | 191 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-traffic- | 192 | 4 | IESG | RFC 9244 |
| normal-per-protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic- | 193 | 4 | IESG | RFC 9244 |
| normal-per-port | | | | |
+----------------------+----------+-------+------------+-----------+
| total-connection- | 194 | 4 | IESG | RFC 9244 |
| capacity-per-port | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic- | 195 | 4 | IESG | RFC 9244 |
| protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| total-traffic-port | 196 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 197 | 4 | IESG | RFC 9244 |
| traffic-protocol | | | | |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 198 | 4 | IESG | RFC 9244 |
| traffic-port | | | | |
+----------------------+----------+-------+------------+-----------+
| total-attack- | 199 | 4 | IESG | RFC 9244 |
| connection-port | | | | |
+----------------------+----------+-------+------------+-----------+
| port | 200 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| supported-query-type | 201 | 4 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| vendor-id | 202 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 203 | 5 | IESG | RFC 9244 |
| telemetry:telemetry- | | | | |
| setup | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 204 | 4 | IESG | RFC 9244 |
| telemetry:total- | | | | |
| traffic | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 205 | 4 | IESG | RFC 9244 |
| telemetry:total- | | | | |
| attack-traffic | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 206 | 5 | IESG | RFC 9244 |
| telemetry:total- | | | | |
| attack-connection | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 207 | 4 | IESG | RFC 9244 |
| telemetry:attack- | | | | |
| detail | | | | |
+----------------------+----------+-------+------------+-----------+
| ietf-dots- | 208 | 5 | IESG | RFC 9244 |
| telemetry:telemetry | | | | |
+----------------------+----------+-------+------------+-----------+
| current-g | 209 | 0 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
| description-lang | 210 | 3 | IESG | RFC 9244 |
+----------------------+----------+-------+------------+-----------+
Table 4: Registered DOTS Signal Channel CBOR Key Values
表4：登録ドット信号チャネルCBORキー値
Per this document, IANA has assigned a new code from the "DOTS Signal Channel Conflict Cause Codes" registry [Cause].
このドキュメントに従って、IANAは「DOTS信号チャネル競合がコード」レジストリ[原因]から新しいコードを割り当てています。
+======+===================+========================+===========+
| Code | Label | Description | Reference |
+======+===================+========================+===========+
| 5 | overlapping-pipes | Overlapping pipe scope | RFC 9244 |
+------+-------------------+------------------------+-----------+
Table 5: Registered DOTS Signal Channel Conflict Cause Code
表5：登録ドット信号チャネルの競合がコードを引き起こす
Per this document, IANA has registered the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
このドキュメントに従って、IANAは「IETF XMLレジストリ」[RFC3688]内の「NS」サブレジストリに次のURIを登録しています。
URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
uri：urn：ietf：params：xml：ns：yang：ietf-dots-telemetry登録者の連絡先：iesg。XML：n/a;要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:ietf-dots-mapping Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
uri：urn：ietf：params：xml：ns：yang：ietf-dots-mapping登録者の連絡先：iesg。XML：n/a;要求されたURIはXMLネームスペースです。
Per this document, IANA has registered the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.
このドキュメントによると、IANAは「Yang Module Names」Subregistry [RFC6020]に「Yangパラメーター」レジストリ内に次のYangモジュールを登録しています。
Name: ietf-dots-telemetry
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
Maintained by IANA: N
Prefix: dots-telemetry
Reference: RFC 9244
Name: ietf-dots-mapping
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
Maintained by IANA: N
Prefix: dots-mapping
Reference: RFC 9244
The security considerations for the DOTS signal channel protocol are discussed in Section 11 of [RFC9132]. The following discusses the security considerations that are specific to the DOTS signal channel extension defined in this document.
DOTS信号チャネルプロトコルのセキュリティに関する考慮事項については、[RFC9132]のセクション11で説明します。以下は、このドキュメントで定義されているドット信号チャネル拡張に固有のセキュリティに関する考慮事項について説明します。
The DOTS telemetry information includes DOTS client network topology, DOTS client domain pipe capacity, normal traffic baseline and connection capacity, and threat and mitigation information. Such information is sensitive; it MUST be protected at rest by the DOTS server domain to prevent data leakage. Note that sharing this sensitive data with a trusted DOTS server does not introduce any new significant considerations other than the need for the aforementioned protection. Such a DOTS server is already trusted to have access to that kind of information by being in the position to observe and mitigate attacks.
DOTSテレメトリ情報には、DOTSクライアントネットワークトポロジ、DOTSクライアントドメインパイプ容量、通常のトラフィックベースラインと接続容量、脅威と緩和情報が含まれます。そのような情報は敏感です。データの漏れを防ぐために、DOTSサーバードメインによって安静時に保護する必要があります。この機密データを信頼できるDOTSサーバーと共有しても、前述の保護の必要性以外の新しい重要な考慮事項は導入されないことに注意してください。このようなDOTSサーバーは、攻撃を観察し、軽減する立場にあることにより、そのような情報にアクセスできるとすでに信頼されています。
DOTS clients are typically considered to be trusted devices by the DOTS client domain. DOTS clients may be co-located on network security services (e.g., firewall devices), and a compromised security service potentially can do a lot more damage to the network than just the DOTS client component. This assumption differs from the often-held view (often referred to as the "zero-trust model") that devices are untrusted. A compromised DOTS client can send fake DOTS telemetry data to a DOTS server to mislead the DOTS server. This attack can be prevented by monitoring and auditing DOTS clients to detect misbehavior and to deter misuse, and by only authorizing the DOTS client to convey DOTS telemetry information for specific target resources (e.g., an application server is authorized to exchange DOTS telemetry for its IP addresses but a DDoS mitigator can exchange DOTS telemetry for any target resource in the network). As a reminder, this is a variation of dealing with compromised DOTS clients as discussed in Section 11 of [RFC9132].
DOTSクライアントは通常、DOTSクライアントドメインによって信頼できるデバイスであると見なされます。 DOTSクライアントは、ネットワークセキュリティサービス（ファイアウォールデバイスなど）に共同住宅されている場合があり、侵害されたセキュリティサービスは、DOTSクライアントコンポーネントよりも多くのダメージを与える可能性があります。この仮定は、デバイスが信頼されていないことが多いビュー（しばしば「ゼロトラストモデル」と呼ばれることが多い）とは異なります。侵害されたDOTSクライアントは、DOTSサーバーを誤解させるために、偽のドットテレメトリデータをDOTSサーバーに送信できます。この攻撃は、DOTSクライアントを監視および監査して不正行為を検出し、誤用を阻止し、DOTSクライアントに特定のターゲットリソースに対してDOTSテレメトリー情報を伝えることを許可することで防ぐことができます（たとえば、アプリケーションサーバーは、IPとDOTSテレメトリーを交換することを許可されます。アドレスは、DDOS Mitigatorがネットワーク内の任意のターゲットリソースとドットテレメトリを交換できます）。リマインダーとして、これは[RFC9132]のセクション11で説明したように、妥協したDOTSクライアントを扱うことのバリエーションです。
DOTS servers must be capable of defending themselves against DoS attacks from compromised DOTS clients. The following non-comprehensive list of mitigation techniques can be used by a DOTS server to handle misbehaving DOTS clients:
DOTSサーバーは、DOTSクライアントからのDOS攻撃から身を守ることができなければなりません。次の非包括的な緩和手法のリストは、DOTSサーバーがDOTSの誤ったドットクライアントを処理するために使用できます。
* The probing rate (defined in Section 4.5 of [RFC9132]) can be used to limit the average data rate to the DOTS server.
* プロービングレート（[RFC9132]のセクション4.5で定義）を使用して、平均データレートをDOTSサーバーに制限できます。
* Rate-limiting DOTS telemetry, including packets with new 'tmid' values from the same DOTS client, defends against DoS attacks that would result in varying the 'tmid' to exhaust DOTS server resources. Likewise, the DOTS server can enforce a quota and time limit on the number of active pre-or-ongoing-mitigation telemetry data items (identified by 'tmid') from the DOTS client.
* 同じDOTSクライアントからの新しい「TMID」値を持つパケットを含むレート制限ドットテレメトリは、DOS攻撃を防御し、「TMID」がDOTSサーバーリソースを排出するように変化します。同様に、DOTSサーバーは、DOTSクライアントからのアクティブな前またはソング緩和テレメトリデータ項目（「TMID」で識別）の数のクォータと時間制限を実施できます。
Note also that the telemetry notification interval may be used to rate-limit the pre-or-ongoing-mitigation telemetry notifications received by a DOTS client domain.
また、Telemetry通知間隔を使用して、DOTSクライアントドメインによって受信された前またはソング緩和のテレメトリ通知を評価するために使用できることに注意してください。
The security considerations for the DOTS data channel protocol are discussed in Section 10 of [RFC8783]. The following discusses the security considerations that are specific to the DOTS data channel extension defined in this document.
DOTSデータチャネルプロトコルのセキュリティに関する考慮事項については、[RFC8783]のセクション10で説明します。以下は、このドキュメントで定義されているDOTSデータチャネル拡張に固有のセキュリティに関する考慮事項について説明します。
All data nodes defined in the YANG module specified in Section 11.2 that can be created, modified, and deleted (i.e., config true, which is the default) are considered sensitive. Write operations to these data nodes without proper protection can have a negative effect on network operations. Appropriate security measures are recommended to prevent illegitimate users from invoking DOTS data channel primitives as discussed in [RFC8783]. Nevertheless, an attacker who can access a DOTS client is technically capable of undertaking various attacks, such as:
セクション11.2で指定されたYangモジュールで定義されているすべてのデータノードは、作成、変更、削除（つまり、デフォルトである構成）に敏感と見なされます。適切な保護なしにこれらのデータノードに操作を書き込むことは、ネットワーク操作に悪影響を与える可能性があります。[RFC8783]で説明されているように、違法なユーザーがDOTSデータチャネルプリミティブを呼び出すのを防ぐために、適切なセキュリティ対策が推奨されます。それにもかかわらず、DOTSクライアントにアクセスできる攻撃者は、次のようなさまざまな攻撃を実施することができます。
* Communicating invalid attack mapping details to the server ('/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping'), which will mislead the server when correlating attack details.
* 無効な攻撃マッピングの詳細をサーバーに通知する（ '/data-channel：dots-data/data-channel：dots-client/dots-telemetry：vendor-mapping'）。
Some of the readable data nodes in the YANG module specified in Section 11.2 may be considered sensitive. It is thus important to control read access to these data nodes. These are the data nodes and their sensitivity:
セクション11.2で指定されているYangモジュールの読み取り可能なデータノードの一部は、感度が高いと見なされる場合があります。したがって、これらのデータノードへの読み取りアクセスを制御することが重要です。これらはデータノードとその感度です。
* '/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping' can be misused to infer the DDoS protection technology deployed in a DOTS client domain.
* '/data-channel：dots-data/data-channel：dots-client/dots-telemetry：ベンダーマッピング'は、DOTSクライアントドメインに展開されているDDOS保護技術を推測するために誤用できます。
* '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be used by a compromised DOTS client to leak the attack detection capabilities of the DOTS server. This is a variation of the compromised DOTS client attacks discussed in Section 14.1.
* '/data-channel：dots-data/dots-telemetry：ベンダーマッピング'は、DOTSサーバーの攻撃検出機能をリークするために、侵害されたDOTSクライアントが使用できます。これは、セクション14.1で説明されているクライアント攻撃の侵害のバリエーションです。
[Private-Enterprise-Numbers] IANA, "Private Enterprise Numbers", <https://www.iana.org/assignments/enterprise-numbers/>.
[private-enterprise-numbers] iana、「プライベートエンタープライズ番号」、<https://www.iana.org/assignments/enterprise-numbers/>。
[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レジストリ」、BCP 81、RFC 3688、DOI 10.17487/RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、編およびM.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487/RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[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 -Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語、RFC 6020、DOI 10.17487/RFC6020、2010年10月、<https：//www.rfc -editor。org/info/rfc6020>。
[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。、 "Common Yang Data型"、RFC 6991、DOI 10.17487/RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「制約付きアプリケーションプロトコル（COAP）」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https：//www.rfc-editor。org/info/rfc7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「制約付きアプリケーションプロトコル（COAP）のリソースの観察」、RFC 7641、DOI 10.17487/RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C。およびZ. Shelby、ed。、「制約付きアプリケーションプロトコル（COAP）のブロックごとの転送」、RFC 7959、DOI 10.17487/RFC7959、2016年8月、<https：//www.rfc-editor.org/info/rfc7959>。
[RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC7970] DanyliW、R。、「インシデントオブジェクト説明交換フォーマットバージョン2」、RFC 7970、DOI 10.17487/RFC7970、2016年11月、<https://www.rfc-editor.org/info/rfc7970>
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RestConf Protocol」、RFC 8040、DOI 10.17487/RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040>。
[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>。
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8345] Clemm、A.、Medved、J.、Varga、R.、Bahadur、N.、Ananthakrishnan、H。、およびX. Liu、「ネットワークトポロジのヤンデータモデル」、RFC 8345、DOI 10.17487/RFC8345555555555555555、2018年3月、<https://www.rfc-editor.org/info/rfc8345>。
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8783] Boucadair、M.、ed。およびT. Reddy.K、ed。、「分散拒否拒否オープン脅威シグナル伝達（DOT）データチャネル仕様」、RFC 8783、DOI 10.17487/RFC8783、2020年5月、<https：//www.rfc-editor。org/info/rfc8783>。
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8791] Bierman、A.、Björklund、M.、およびK. Watsen、「Yang Data Structure Extensions」、RFC 8791、DOI 10.17487/RFC8791、2020年6月、<https：//www.rfc-editor.org/info/rfc8791>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C。and P. Hoffman、「Concise binary Object Lepressation（CBOR）」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/RFC8949>。
[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。、Ed。、Shallow、J.、およびT. Reddy.K、「分散拒否拒否オープン脅威シグナル伝達（DOT）シグナルチャネル仕様」、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.K, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Work in Progress, Internet-Draft, draft-ietf-dots-multihoming-13, 26 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-13>.
[dots-multihoming] Boucadair、M.、Reddy.K、T。、およびW. Pan、「分散型管理オープン脅威シグナル伝達（DOTS）のためのマルチホーミング展開の考慮事項」、進行中の作業、インターネット - ドラフト、ドラフト-ITETF-DOTS-MULTIHOMING-13、2022年4月26日、<https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-13>。
[DOTS-Robust-Blocks] Boucadair, M. and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission", Work in Progress, Internet-Draft, draft-ietf-dots-robust-blocks-03, 11 February 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-robust-blocks-03>.
[Dots-Robust-blocks] Boucadair、M。and J. Shallow、「分散拒否拒否オープン脅威シグナル伝達（DOTS）信号チャネル構成の堅牢なブロック伝送の属性」、進行中の作業、インターネットドラフト、ドラフト-ITF-dots-robust-blocks-03、2022年2月11日、<https://datatracker.ietf.org/doc/html/draft-ietf-dots--bust-blocks-03>。
[DOTS-Telemetry-Specs] Doron, E., Reddy, T., Andreasen, F., Xia, L., and K. Nishizuka, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Specifications", Work in Progress, Internet-Draft, draft-doron-dots-telemetry-00, 30 October 2016, <https://datatracker.ietf.org/doc/html/ draft-doron-dots-telemetry-00>.
[Dots-Telemetry-Specs] Doron、E.、Reddy、T.、Andreasen、F.、Xia、L。、およびK. Nishizuka、「分散拒否オープンオープン脅威シグナル伝達（DOT）テレメトリー仕様」、作業進行中、インターネットドラフト、Draft-Doron-Dots-Telemetry-00、2016年10月30日、<https://datatracker.ietf.org/doc/html/ draft-doron-dots-telemetry-00>。
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", <https://www.iana.org/assignments/dots/>.
[key-map] iana、「Dots Chanchen Cborキー値」、<https://www.iana.org/assignments/dots/>。
[PYANG] "pyang", commit dad5c68, April 2022, <https://github.com/mbj4668/pyang>.
[pyang] "pyang"、dad5c68をコミット、2022年4月、<https://github.com/mbj4668/pyang>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、DOI 10.17487/RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。
[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] Handley、M.、Ed。、Ed。、Rescorla、E.、ed。、およびIAB、「インターネット拒否権に関する考慮事項」、RFC 4732、DOI 10.17487/RFC4732、2006年12月、<https：// www。rfc-editor.org/info/rfc4732>。
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC5612] Eronen、P。およびD. Harrington、「ドキュメント使用のためのエンタープライズ番号」、RFC 5612、DOI 10.17487/RFC5612、2009年8月、<https://www.rfc-editor.org/info/rfc5612>
[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。and L. Berger、ed。、「Yang Tree Diagrams」、BCP 215、RFC 8340、DOI 10.17487/RFC8340、2018年3月、<https://www.rfc-editor.org/info/RFC8340>。
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.
[RFC8525] Bierman、A.、Bjorklund、M.、Schoenwaelder、J.、Watsen、K。、およびR. Wilton、 "Yang Library"、RFC 8525、doi 10.17487/RFC8525、2019年3月、<https：// wwwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8525>。
[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 Open Threat Signaling（DOTS）要件」、RFC 8612、DOI 10.17487/RFC8612、2019年5月、<https：//www.rfc-editor.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 Open Threat Signaling（DOTS）Architecture」、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] Dobbins、R.、Migault、D.、Moskowitz、R.、Teague、N.、Xia、L。、およびK. Nishizuka、「DDOSオープン脅威シグナル伝達のユースケース」、RFC 8903、DOI 10.17487/RFC89030303、2021年5月、<https://www.rfc-editor.org/info/rfc8903>。
[RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata, "Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel", RFC 9133, DOI 10.17487/RFC9133, September 2021, <https://www.rfc-editor.org/info/rfc9133>.
[RFC9133] Nishizuka、K.、Boucadair、M.、Reddy.K、T.、およびT. Nagata、「分散拒否拒否オープン脅威シグナル伝達（DOT）シグナルチャネルを使用したフィルタリングルールの制御」、RFC 9133、doi10.17487/rfc9133、2021年9月、<https://www.rfc-editor.org/info/rfc9133>。
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission", RFC 9177, DOI 10.17487/RFC9177, March 2022, <https://www.rfc-editor.org/info/rfc9177>.
[RFC9177] Boucadair、M。and J. Shallow、「制約付きアプリケーションプロトコル（COAP）堅牢な伝送をサポートするブロックワイズトランスファーオプション」、RFC 9177、DOI 10.17487/RFC9177、2022年3月、<https：//www.rfc-editor.org/info/rfc9177>。
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9260] Stewart、R.、Tüxen、M。、およびK. Nielsen、「Stream Control Transmission Protocol」、RFC 9260、DOI 10.17487/RFC9260、2022年6月、<https://www.rfc-editor.org/info/rfc9260>。
Acknowledgments
謝辞
The authors would like to thank Flemming Andreasen, Liang Xia, and Kaname Nishizuka, coauthors of [DOTS-Telemetry-Specs], and everyone who had contributed to that document.
著者は、[ドットテレメトリーの種]の共著者であるLiang Xia、Liang Xia、Kaname Nishizuka、およびその文書に貢献したすべての人に感謝したいと思います。
Thanks to Kaname Nishizuka, Yuhei Hayashi, and Tom Petch for comments and review.
コメントとレビューをしてくれたカナメ・ニシツカ、林井ゆえ、トム・ペティに感謝します。
Special thanks to Jon Shallow and Kaname Nishizuka for their implementation and interoperability work.
Jon ShallowとKaname Nishizukaの実装と相互運用性の作業に感謝します。
Many thanks to Jan Lindblad for the yangdoctors review, Nagendra Nainar for the opsdir review, James Gruessing for the artart review, Michael Scharf for the tsv-art review, Ted Lemon for the int-dir review, and Robert Sparks for the gen-art review.
Yangdoctors ReviewのJan Lindblad、Opsdir ReviewのNagendra Nainar、Artart ReviewのJames Gruessing、TSV-Art ReviewのMichael Scharf、Int-Dir ReviewのTed Lemon、Gen-ArtのRobert Sparksに感謝します。レビュー。
Thanks to Benjamin Kaduk for the detailed AD review.
詳細な広告レビューをしてくれたBenjamin Kadukに感謝します。
Thanks to Roman Danyliw, Éric Vyncke, Francesca Palombini, Warren Kumari, Erik Kline, Lars Eggert, and Robert Wilton for the IESG review.
IESGレビューのために、Roman Danyliw、エリックヴィンケ、フランチェスカパロビニ、ウォーレンクマリ、エリッククライン、ラースエガート、ロバートウィルトンに感謝します。
Contributors
貢献者
The following individuals have contributed to this document:
次の個人がこの文書に貢献しています。
Li Su CMCC Email: suli@chinamobile.com
li su cmccメール：suli@chinamobile.com
Pan Wei Huawei Email: william.panwei@huawei.com
Pan Wei Huaweiメール：william.panwei@huawei.com
Authors' Addresses
著者のアドレス
Mohamed Boucadair (editor) Orange 35000 Rennes France Email: mohamed.boucadair@orange.com
Mohamed Boucadair（編集者）Orange 35000 Rennes Franceメール：mohamed.boucadair@orange.com
Tirumaleswar Reddy.K (editor) Akamai Embassy Golf Link Business Park Bangalore 560071 Karnataka India Email: kondtir@gmail.com
Tirumaleswar Reddy.K（編集者）アカマイ大使館ゴルフリンクビジネスパークバンガロール560071カルナタカインドメール：kondtir@gmail.com
Ehud Doron Radware Ltd. Raoul Wallenberg Street Tel-Aviv 69710 Israel Email: ehudd@radware.com
Ehud Doron Radware Ltd. Raoul Wallenberg Street Tel-Aviv 69710 ISRAELメール：ehudd@radware.com
Meiling Chen CMCC 32 Xuanwumen West Street Beijing 100053 China Email: chenmeiling@chinamobile.com
Meiling Chen CMCC 32 Xuanwumen West Street Beijing 100053 China Email：chenmeiling@chinamobile.com
Jon Shallow United Kingdom Email: supjps-ietf@jpshallow.com
Jon Shallow United Kingdom Email：supjps-ietf@jpshallow.com