Internet Engineering Task Force (IETF) A. Mortensen
Request for Comments: 8612 Arbor Networks
Category: Informational T. Reddy
ISSN: 2070-1721 McAfee
R. Moskowitz
Huawei
May 2019
Internet Engineering Task Force (IETF) A. Mortensen
Request for Comments: 8612 Arbor Networks
Category: Informational T. Reddy
ISSN: 2070-1721 McAfee
R. Moskowitz
Huawei
May 2019
DDoS Open Threat Signaling (DOTS) Requirements
DDoS开放威胁信令（DOTS）要求
Abstract
摘要
This document defines the requirements for the Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.
本文档定义了分布式拒绝服务（DDoS）开放威胁信号（DOTS）协议的要求，该协议支持对DDoS攻击的协调响应。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8612.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8612.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . 7
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13
2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 16
3. Congestion Control Considerations . . . . . . . . . . . . . . 17
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 17
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . 7
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13
2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 16
3. Congestion Control Considerations . . . . . . . . . . . . . . 17
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 17
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Distributed Denial-of-Service (DDoS) attacks afflict networks connected to the Internet, plaguing network operators at service providers and enterprises around the world. High-volume attacks saturating inbound links are now common as attack scale and frequency continue to increase.
分布式拒绝服务（DDoS）攻击困扰着连接到Internet的网络，困扰着全球服务提供商和企业的网络运营商。随着攻击规模和频率的不断增加，使入站链路饱和的高容量攻击现在很常见。
The prevalence and impact of these DDoS attacks has led to an increased focus on coordinated attack response. However, many enterprises lack the resources or expertise to operate on-premise attack mitigation solutions themselves, or are constrained by local bandwidth limitations. To address such gaps, service providers have begun to offer on-demand traffic scrubbing services, which are designed to separate the DDoS attack traffic from legitimate traffic and forward only the latter.
这些DDoS攻击的普遍性和影响导致人们越来越关注协调的攻击响应。然而，许多企业缺乏资源或专业知识来操作本地攻击缓解解决方案，或者受到本地带宽限制的限制。为了解决这些差距，服务提供商已经开始提供按需流量清理服务，该服务旨在将DDoS攻击流量与合法流量分开，并仅转发后者。
Today, these services offer proprietary interfaces for subscribers to request attack mitigation. Such proprietary interfaces tie a subscriber to a service and limit the abilities of network elements that would otherwise be capable of participating in attack mitigation. As a result of signaling interface incompatibility,
如今，这些服务为用户提供专有接口，以请求攻击缓解。此类专有接口将订户与服务联系起来，并限制了网络元素的能力，否则这些元素将能够参与攻击缓解。由于信号接口不兼容，
attack responses may be fragmented or otherwise incomplete, leaving operators in the attack path unable to assist in the defense.
攻击响应可能支离破碎或不完整，使攻击路径中的操作员无法协助防御。
A standardized method to coordinate a real-time response among involved operators will increase the speed and effectiveness of DDoS attack mitigation and reduce the impact of these attacks. This document describes the required characteristics of protocols that enable attack response coordination and mitigation of DDoS attacks.
协调相关运营商之间实时响应的标准化方法将提高DDoS攻击缓解的速度和有效性，并降低这些攻击的影响。本文档描述了支持攻击响应协调和DDoS攻击缓解的协议所需的特征。
DDoS Open Threat Signaling (DOTS) communicates the need for defensive action in anticipation of or in response to an attack, but it does not dictate the implementation of these actions. The DOTS use cases are discussed in [DOTS-USE], and the DOTS architecture is discussed in [DOTS-ARCH].
DDoS开放式威胁信号（DOTS）传达了在预期攻击或响应攻击时采取防御行动的需要，但并不指示这些行动的实施。DOTS用例在[DOTS-use]中讨论，DOTS体系结构在[DOTS-ARCH]中讨论。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
These capitalized words are used to signify the requirements for the DOTS protocols design.
这些大写单词用于表示DOTS协议设计的要求。
This document adopts the following terms:
本文件采用以下术语：
DDoS: A distributed denial-of-service attack in which traffic originating from multiple sources is directed at a target on a network. DDoS attacks are intended to cause a negative impact on the availability and/or functionality of an attack target. Denial-of-service considerations are discussed in detail in [RFC4732].
DDoS：一种分布式拒绝服务攻击，其中来自多个来源的流量指向网络上的一个目标。DDoS攻击旨在对攻击目标的可用性和/或功能造成负面影响。[RFC4732]中详细讨论了拒绝服务注意事项。
DDoS attack target: A network-connected entity that is the target of a DDoS attack. Potential targets include (but are not limited to) network elements, network links, servers, and services.
DDoS攻击目标：作为DDoS攻击目标的网络连接实体。潜在目标包括（但不限于）网元、网络链路、服务器和服务。
DDoS attack telemetry: Collected measurements and behavioral characteristics defining the nature of a DDoS attack.
DDoS攻击遥测：收集定义DDoS攻击性质的度量和行为特征。
Countermeasure: An action or set of actions focused on recognizing and filtering out specific types of DDoS attack traffic while passing legitimate traffic to the attack target. Distinct countermeasures can be layered to defend against attacks combining multiple DDoS attack types.
对策：将合法流量传递给攻击目标的同时，重点识别和过滤特定类型的DDoS攻击流量的一项或一组行动。可以分层采取不同的对策，以抵御结合多种DDoS攻击类型的攻击。
Mitigation: A set of countermeasures enforced against traffic destined for the target or targets of a detected or reported DDoS attack, where countermeasure enforcement is managed by an entity in the network path between attack sources and the attack target. Mitigation methodology is out of scope for this document.
缓解措施：针对目的地为检测到或报告的DDoS攻击的一个或多个目标的流量实施的一组对策，其中对策实施由攻击源和攻击目标之间的网络路径中的实体管理。缓解方法超出了本文件的范围。
Mitigator: An entity, typically a network element, capable of performing mitigation of a detected or reported DDoS attack. The means by which this entity performs these mitigations and how they are requested of it are out of scope for this document. The mitigator and DOTS server receiving a mitigation request are assumed to belong to the same administrative entity.
缓解者：能够对检测到或报告的DDoS攻击执行缓解的实体，通常为网元。该实体执行这些缓解措施的方式以及如何向其提出要求超出了本文件的范围。假定缓解器和接收缓解请求的DOTS服务器属于同一管理实体。
DOTS client: A DOTS-aware software module responsible for requesting attack response coordination with other DOTS-aware elements.
DOTS客户端：一个DOTS感知软件模块，负责请求与其他DOTS感知元素的攻击响应协调。
DOTS server: A DOTS-aware software module handling and responding to messages from DOTS clients. The DOTS server enables mitigation on behalf of the DOTS client, if requested, by communicating the DOTS client's request to the mitigator and returning selected mitigator feedback to the requesting DOTS client.
DOTS服务器：一个DOTS感知软件模块，处理和响应来自DOTS客户端的消息。DOTS服务器通过将DOTS客户端的请求传达给缓解者并将选定的缓解者反馈返回给请求的DOTS客户端，代表DOTS客户端启用缓解（如果请求）。
DOTS agent: Any DOTS-aware software module capable of participating in a DOTS signal or data channel. It can be a DOTS client, DOTS server, or, as a logical agent, a DOTS gateway.
DOTS代理：任何能够参与DOTS信号或数据通道的DOTS感知软件模块。它可以是DOTS客户端、DOTS服务器，或者作为逻辑代理的DOTS网关。
DOTS gateway: A DOTS-aware software module resulting from the logical concatenation of the functionality of a DOTS server and a DOTS client into a single DOTS agent. This functionality is analogous to a Session Initiation Protocol (SIP) [RFC3261] Back-to-Back User Agent (B2BUA) [RFC7092]. A DOTS gateway has a client-facing side, which behaves as a DOTS server for downstream clients, and a server-facing side, which performs the role of a DOTS client for upstream DOTS servers. Client-domain DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-domain DOTS gateways denote DOTS gateways that are in the DOTS server's domain. A DOTS gateway may terminate multiple discrete DOTS client connections and may aggregate these into one or more connections. DOTS gateways are described further in [DOTS-ARCH].
DOTS网关：DOTS感知软件模块，由DOTS服务器和DOTS客户端的功能逻辑连接到单个DOTS代理中而成。此功能类似于会话启动协议（SIP）[RFC3261]背对背用户代理（B2BUA）[RFC7092]。DOTS网关有一个面向客户端（作为下游客户端的DOTS服务器）和一个面向服务器（作为上游DOTS服务器的DOTS客户端）。客户端域DOTS网关是DOTS客户端域中的DOTS网关，而服务器域DOTS网关表示DOTS服务器域中的DOTS网关。DOTS网关可终止多个离散的DOTS客户端连接，并可将这些连接聚合为一个或多个连接。DOTS网关将在[DOTS-ARCH]中进一步描述。
Signal channel: A bidirectional, mutually authenticated communication channel between DOTS agents that is resilient even in conditions leading to severe packet loss such as a volumetric DDoS attack causing network congestion.
信号通道：DOTS代理之间的双向、相互认证的通信通道，即使在导致严重数据包丢失的情况下（如导致网络拥塞的大量DDoS攻击）也具有弹性。
DOTS signal: A status/control message transmitted over the authenticated signal channel between DOTS agents, used to indicate the client's need for mitigation or to convey the status of any requested mitigation.
DOTS信号：通过DOTS代理之间的认证信号通道传输的状态/控制消息，用于指示客户对缓解措施的需求或传达任何请求缓解措施的状态。
Heartbeat: A message transmitted between DOTS agents over the signal channel, used as a keep-alive and to measure peer health.
心跳：通过信号通道在DOTS代理之间传输的消息，用作保持活动状态和测量同伴健康的信号。
Data channel: A bidirectional, mutually authenticated communication channel between two DOTS agents used for infrequent but reliable bulk exchange of data not easily or appropriately communicated through the signal channel. Reliable bulk data exchange may not function well or at all during attacks causing network congestion. The data channel is not expected to operate in such conditions.
数据通道：两个DOTS代理之间的双向、相互认证的通信通道，用于不频繁但可靠的数据批量交换，不容易或不适当地通过信号通道进行通信。在导致网络拥塞的攻击期间，可靠的批量数据交换可能无法正常工作或根本无法正常工作。数据通道预计不会在这种情况下运行。
Filter: A specification of a matching network traffic flow or set of flows. The filter will typically have a policy associated with it, e.g., rate-limiting or discarding matching traffic [RFC4949].
过滤器：匹配网络流量或流量集的规范。过滤器通常会有一个与其相关联的策略，例如，速率限制或丢弃匹配流量[RFC4949]。
Drop-list: A list of filters indicating sources from which traffic should be blocked regardless of traffic content.
下拉列表：一个过滤器列表，指示无论流量内容如何，都应阻止来自哪个来源的流量。
Accept-list: A list of filters indicating sources from which traffic should always be allowed regardless of contradictory data gleaned in a detected attack.
接受列表：一个过滤器列表，指示无论在检测到的攻击中收集到的数据是否相互矛盾，都应始终允许来自哪些源的流量。
Multihomed DOTS client: A DOTS client exchanging messages with multiple DOTS servers, each in a separate administrative domain.
多宿主DOTS客户端：DOTS客户端与多个DOTS服务器交换消息，每个服务器位于单独的管理域中。
The expected layout and interactions amongst DOTS entities is described in the DOTS Architecture [DOTS-ARCH].
DOTS体系结构[DOTS-ARCH]中描述了DOTS实体之间的预期布局和交互。
The goal of the DOTS requirements specification is to specify the requirements for DOTS signal channel and data channel protocols that have different application and transport-layer requirements. This section describes the required features and characteristics of the DOTS protocols.
DOTS需求规范的目标是指定具有不同应用和传输层需求的DOTS信号通道和数据通道协议的需求。本节介绍DOTS协议所需的功能和特点。
The goal of DOTS protocols is to enable and manage mitigation on behalf of a network domain or resource that is or may become the focus of a DDoS attack. An active DDoS attack against the entity controlling the DOTS client need not be present before establishing a communication channel between DOTS agents. Indeed, establishing a relationship with peer DOTS agents during normal network conditions provides the foundation for a more rapid attack response against future attacks, as all interactions setting up DOTS, including any
DOTS协议的目标是代表当前或可能成为DDoS攻击焦点的网络域或资源启用和管理缓解措施。在DOTS代理之间建立通信通道之前，无需存在针对控制DOTS客户端的实体的主动DDoS攻击。事实上，在正常网络条件下与对等点代理建立关系，为未来攻击提供更快速的攻击响应的基础，因为所有交互建立点，包括任何点。
business or service-level agreements, are already complete. Reachability information of peer DOTS agents is provisioned to a DOTS client using a variety of manual or dynamic methods. Once a relationship between DOTS agents is established, regular communication between DOTS clients and servers enables a common understanding of the DOTS agents' health and activity.
业务或服务级别协议已完成。对等DOTS代理的可达性信息使用各种手动或动态方法提供给DOTS客户端。一旦建立了DOTS代理之间的关系，DOTS客户端和服务器之间的定期通信就能够对DOTS代理的健康和活动有一个共同的了解。
The DOTS protocol must, at a minimum, make it possible for a DOTS client to request aid mounting a defense against a suspected attack. This defense could be coordinated by a DOTS server and include signaling within or between domains as requested by local operators. DOTS clients should similarly be able to withdraw aid requests. DOTS requires no justification from DOTS clients for requests for help, nor do DOTS clients need to justify withdrawing help requests; the decision is local to the DOTS clients' domain. Multihomed DOTS clients must be able to select the appropriate DOTS server(s) to which a mitigation request is to be sent. The method for selecting the appropriate DOTS server in a multihomed environment is out of scope for this document.
DOTS协议必须至少使DOTS客户端能够请求援助，以针对可疑攻击进行防御。这种防御可以由DOTS服务器协调，包括本地运营商请求的域内或域之间的信令。DOTS客户端同样应该能够撤回援助请求。DOTS不要求DOTS客户为请求帮助提供理由，也不要求DOTS客户为撤回帮助请求提供理由；该决定是DOTS客户领域的本地决定。多宿主DOTS客户端必须能够选择要向其发送缓解请求的适当DOTS服务器。在多主机环境中选择适当的DOTS服务器的方法超出了本文档的范围。
DOTS protocol implementations face competing operational goals when maintaining this bidirectional communication stream. On the one hand, DOTS must include measures to ensure message confidentiality, integrity, authenticity, and replay protection to keep the protocols from becoming additional vectors for the very attacks it is meant to help fight off. On the other hand, the protocol must be resilient under extremely hostile network conditions, providing continued contact between DOTS agents even as attack traffic saturates the link. Such resiliency may be developed several ways, but characteristics such as small message size, asynchronous notifications, redundant message delivery, and minimal connection overhead (when possible, given local network policy) will tend to contribute to the robustness demanded by a viable DOTS protocol. Operators of peer DOTS-enabled domains may enable either quality-of-service or class-of-service traffic tagging to increase the probability of successful DOTS signal delivery, but DOTS does not require such policies be in place and should be viable in their absence.
在维护这种双向通信流时，DOTS协议实现面临着相互竞争的操作目标。一方面，DOTS必须包括确保消息机密性、完整性、真实性和重播保护的措施，以防止协议成为攻击的额外载体，而这些攻击正是DOTS旨在帮助抵御的。另一方面，协议必须在极端恶劣的网络条件下具有弹性，即使攻击流量使链路饱和，也能在DOTS代理之间提供持续的联系。这种弹性可以通过多种方式开发，但诸如小消息大小、异步通知、冗余消息传递和最小连接开销（如果可能，给定本地网络策略）等特性将有助于提高可行DOTS协议所需的健壮性。对等DOTS启用域的运营商可以启用服务质量或服务流量类别标记，以提高DOTS信号成功交付的概率，但DOTS不要求此类政策到位，并且在没有此类政策的情况下应该是可行的。
The DOTS server and client must also have some standardized method of defining the scope of any mitigation, as well as managing other mitigation-related configurations.
DOTS服务器和客户端还必须有一些标准化的方法来定义任何缓解措施的范围，以及管理其他缓解措施相关的配置。
Finally, DOTS should be sufficiently extensible to meet future needs in coordinated attack defense, although this consideration is necessarily superseded by the other operational requirements.
最后，DOTS应具有足够的可扩展性，以满足未来协同攻击防御的需求，尽管这一考虑因素必然会被其他作战需求所取代。
GEN-001 Extensibility: Protocols and data models developed as part of DOTS MUST be extensible in order to keep DOTS adaptable to proprietary DDoS defenses. Future extensions MUST be backward compatible. Implementations of older protocol versions MUST ignore optional information added to DOTS messages as part of newer protocol versions. Implementations of older protocol versions MUST reject DOTS messages carrying mandatory information as part of newer protocol versions.
GEN-001可扩展性：作为DOTS一部分开发的协议和数据模型必须可扩展，以使DOTS适应专有DDoS防御。将来的扩展必须向后兼容。较旧协议版本的实现必须忽略作为较新协议版本的一部分添加到DOTS消息中的可选信息。较旧协议版本的实现必须拒绝包含强制信息的DOTS消息作为较新协议版本的一部分。
GEN-002 Resilience and Robustness: The signaling protocol MUST be designed to maximize the probability of signal delivery even under the severely constrained network conditions caused by attack traffic. Additional means to enhance the resilience of DOTS protocols, including when multiple DOTS servers are provisioned to the DOTS clients, SHOULD be considered. The protocol MUST be resilient, that is, continue operating despite message loss and out-of-order or redundant message delivery. In support of signaling protocol robustness, DOTS signals SHOULD be conveyed over transport and application protocols not susceptible to head-of-line blocking. These requirements are at SHOULD strength to handle middle-boxes and firewall traversal.
GEN-002弹性和鲁棒性：信令协议必须设计为即使在攻击流量造成的严重受限网络条件下，也能最大限度地提高信号传递的概率。应考虑增强DOTS协议弹性的其他方法，包括向DOTS客户端提供多个DOTS服务器。协议必须具有弹性，也就是说，即使消息丢失、无序或冗余消息传递，协议仍能继续运行。为了支持信令协议的健壮性，DOTS信号应通过传输和应用协议进行传输，而不易受到线路头阻塞的影响。这些要求在处理中间盒和防火墙穿越时应具有足够的强度。
GEN-003 Bulk Data Exchange: Infrequent bulk data exchange between DOTS agents can also significantly augment attack response coordination, permitting such tasks as population of drop- or accept-listed source addresses, address or prefix group aliasing, exchange of incident reports, and other hinting or configuration supplementing attack responses.
GEN-003批量数据交换：DOTS代理之间不频繁的批量数据交换也可以显著增强攻击响应协调，允许执行诸如删除或接受列出的源地址、地址或前缀组别名、事件报告交换以及其他提示或配置补充攻击响应等任务。
As the resilience requirements for the DOTS signal channel mandate a small signal message size, a separate, secure data channel utilizing a reliable transport protocol MUST be used for bulk data exchange. However, reliable bulk data exchange may not be possible during attacks causing network congestion.
由于DOTS信号通道的弹性要求要求小信号消息大小，因此必须使用使用可靠传输协议的独立、安全的数据通道进行批量数据交换。但是，在导致网络拥塞的攻击期间，可能无法进行可靠的批量数据交换。
GEN-004 Mitigation Hinting: DOTS clients may have access to attack details that can be used to inform mitigation techniques. Example attack details might include locally collected fingerprints for an on-going attack, or anticipated or active attack focal points based on other threat intelligence. DOTS clients MAY send mitigation hints derived from attack details to DOTS servers, with the full understanding that the DOTS server MAY ignore mitigation hints. Mitigation hints MUST be transmitted across the signal channel, as the data channel may not be functional during an attack. DOTS-server handling of mitigation hints is implementation-specific.
GEN-004缓解提示：DOTS客户端可以访问可用于通知缓解技术的攻击详细信息。示例攻击详细信息可能包括正在进行的攻击的本地收集指纹，或基于其他威胁情报的预期或主动攻击焦点。DOTS客户端可能会向DOTS服务器发送源自攻击详细信息的缓解提示，并完全理解DOTS服务器可能会忽略缓解提示。缓解提示必须通过信号通道传输，因为数据通道在攻击期间可能不起作用。DOTS服务器对缓解提示的处理是特定于实现的。
GEN-005 Loop Handling: In certain scenarios, typically involving misconfiguration of DNS or routing policy, it may be possible for communication between DOTS agents to loop. Signal and data channel implementations should be prepared to detect and terminate such loops to prevent service disruption.
GEN-005循环处理：在某些情况下，通常涉及DNS或路由策略的错误配置，DOTS代理之间的通信可能会循环。信号和数据通道的实现应准备好检测和终止此类环路，以防止服务中断。
SIG-001 Use of Common Transport Protocols: DOTS MUST operate over common, widely deployed and standardized transport protocols. While connectionless transport such as the User Datagram Protocol (UDP) [RFC768] SHOULD be used for the signal channel, the Transmission Control Protocol (TCP) [RFC793] MAY be used if necessary due to network policy or middlebox capabilities or configurations.
SIG-001通用传输协议的使用：DOTS必须在通用、广泛部署和标准化的传输协议上运行。虽然信号通道应使用用户数据报协议（UDP）[RFC768]等无连接传输，但由于网络策略或中间箱功能或配置的原因，如有必要，可使用传输控制协议（TCP）[RFC793]。
SIG-002 Sub-MTU Message Size: To avoid message fragmentation and the consequently decreased probability of message delivery over a congested link, signaling protocol message size MUST be kept under the signaling Path Maximum Transmission Unit (PMTU), including the byte overhead of any encapsulation, transport headers, and transport- or message-level security. If the total message size exceeds the PMTU, the DOTS agent MUST split the message into separate messages; for example, the list of mitigation scope types could be split into multiple lists and each list conveyed in a new message.
SIG-002子MTU消息大小：为了避免消息碎片，从而降低拥塞链路上消息传递的概率，信令协议消息大小必须保持在信令路径最大传输单元（PMTU）以下，包括任何封装、传输头的字节开销，以及传输或消息级别的安全性。如果总消息大小超过PMTU，DOTS代理必须将消息拆分为单独的消息；例如，缓解范围类型的列表可以分为多个列表，每个列表在新消息中传递。
DOTS agents can attempt to learn PMTU using the procedures discussed in [IP-FRAG-FRAGILE]. If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater as specified in [RFC8200]. If IPv4 support on legacy or otherwise unusual networks is a consideration and the PMTU is unknown, DOTS implementations MAY assume a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes as discussed in [RFC791] and [RFC1122].
DOTS代理可以尝试使用[IP-FRAG-BRAIL]中讨论的程序学习PMTU。如果无法找到PMTU，DOTS代理必须假定PMTU为1280字节，因为IPv6要求互联网中的每个链路都具有1280个八位字节或更大的MTU，如[RFC8200]中所述。如果考虑在传统网络或其他不寻常网络上支持IPv4，并且PMTU未知，则DOTS实现可能会假定IPv4数据报的PMTU为576字节，因为每个IPv4主机必须能够接收长度等于576字节的数据包，如[RFC791]和[RFC1122]中所述。
SIG-003 Bidirectionality: To support peer health detection, to maintain an active signal channel, and to increase the probability of signal delivery during an attack, the signal channel MUST be bidirectional, with client and server transmitting signals to each other at regular intervals regardless of any client request for mitigation. The bidirectional signal channel MUST support unidirectional messaging to enable notifications between DOTS agents.
SIG-003双向性：为了支持对等健康检测，维护活动信号通道，并在攻击期间增加信号传递的概率，信号通道必须是双向的，客户机和服务器定期相互发送信号，而不管客户机是否请求缓解。双向信号通道必须支持单向消息传递，以启用DOTS代理之间的通知。
SIG-004 Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. These keep-alives serve to maintain any on-path NAT or Firewall bindings to avoid cryptographic handshake for new mitigation requests. The heartbeat interval during active mitigation could be negotiable based on NAT/Firewall characteristics. Absent information about the NAT/Firewall characteristics, DOTS agents need to ensure its on-path NAT or Firewall bindings do not expire, by using the keep-alive frequency discussed in Section 3.5 of [RFC8085].
SIG-004信道健康监测：DOTS代理必须支持通过信号信道交换心跳消息，以监测信道健康状况。这些keep-alives用于维护任何路径NAT或防火墙绑定，以避免新缓解请求的加密握手。主动缓解期间的心跳间隔可以根据NAT/防火墙特性协商。如果没有关于NAT/防火墙特性的信息，DOTS代理需要使用[RFC8085]第3.5节中讨论的保持活动频率，确保其路径NAT或防火墙绑定不会过期。
To support scenarios in which loss of heartbeat is used to trigger mitigation, and to keep the channel active, DOTS servers MUST solicit heartbeat exchanges after successful mutual authentication. When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load.
为了支持心跳丢失用于触发缓解的场景，并保持通道处于活动状态，DOTS服务器必须在成功的相互身份验证后请求心跳交换。当DOTS代理交换心跳并且没有激活缓解请求时，任一代理都可能请求更改心跳速率。例如，当活动DOTS客户端未请求缓解时，DOTS服务器可能希望降低心跳频率或停止心跳交换，以控制负载。
Following mutual authentication, a signal channel MUST be considered active until a DOTS agent explicitly ends the session. When no attack traffic is present, the signal channel MUST be considered active until either DOTS agent fails to receive heartbeats from the other peer after a mutually agreed upon retransmission procedure has been exhausted. Peer DOTS agents MUST regularly send heartbeats to each other while a mitigation request is active. Because heartbeat loss is much more likely during volumetric attack, DOTS agents SHOULD avoid signal channel termination when mitigation is active and heartbeats are not received by either DOTS agent for an extended period. The exception circumstances to terminating the signal channel session during active mitigation are discussed below:
在相互认证之后，在DOTS代理明确结束会话之前，信号通道必须被视为活动的。当不存在攻击通信量时，信号信道必须被认为是活动的，直到双方商定的重传过程结束后，任一DOTS代理无法接收来自另一对等方的心跳。当缓解请求处于活动状态时，对等DOTS代理必须定期向彼此发送心跳信号。因为在体积攻击期间心跳丢失的可能性更大，所以当缓解处于活动状态且任一DOTS代理在较长时间内未接收到心跳时，DOTS代理应避免信号通道终止。在主动缓解期间终止信号通道会话的例外情况如下所述：
* To handle a possible DOTS server restart or crash, the DOTS clients MAY attempt to establish a new signal channel session but MUST continue to send heartbeats on the current session so that the DOTS server knows the session is still alive. If the new session is successfully established, the DOTS client can terminate the current session.
* 要处理可能的DOTS服务器重启或崩溃，DOTS客户端可能会尝试建立新的信号通道会话，但必须在当前会话上继续发送心跳信号，以便DOTS服务器知道会话仍处于活动状态。如果成功建立新会话，DOTS客户端可以终止当前会话。
* DOTS servers are assumed to have the ability to monitor the attack, using feedback from the mitigator and other available sources, and MAY use the absence of attack traffic and lack of client heartbeats as an indication the signal channel is defunct.
* 假定DOTS服务器能够使用来自缓解器和其他可用来源的反馈来监控攻击，并且可以使用缺少攻击流量和客户端心跳作为信号通道失效的指示。
SIG-005 Channel Redirection: In order to increase DOTS operational flexibility and scalability, DOTS servers SHOULD be able to redirect DOTS clients to another DOTS server at any time. DOTS clients MUST NOT assume the redirection target DOTS server shares security state with the redirecting DOTS server. DOTS clients are free to attempt abbreviated security negotiation methods supported by the protocol, such as DTLS session resumption, but MUST be prepared to negotiate new security state with the redirection target DOTS server. The redirection DOTS server and redirecting DOTS server MUST belong to the same administrative domain.
SIG-005通道重定向：为了提高DOTS操作灵活性和可扩展性，DOTS服务器应能够随时将DOTS客户端重定向到另一个DOTS服务器。DOTS客户端不得假定重定向目标DOTS服务器与重定向DOTS服务器共享安全状态。DOTS客户端可以自由尝试协议支持的简化安全协商方法，如DTLS会话恢复，但必须准备好与重定向目标DOTS服务器协商新的安全状态。重定向DOTS服务器和重定向DOTS服务器必须属于同一管理域。
Due to the increased likelihood of packet loss caused by link congestion during an attack, DOTS servers SHOULD NOT redirect while mitigation is enabled during an active attack against a target in the DOTS client's domain.
由于攻击期间链路拥塞导致数据包丢失的可能性增加，因此在对DOTS客户端域中的目标进行主动攻击期间启用缓解措施时，DOTS服务器不应重定向。
SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST be able to request scoped mitigation from DOTS servers. DOTS servers MUST send status to the DOTS clients about mitigation requests. If a DOTS server rejects an authorized request for mitigation, the DOTS server MUST include a reason for the rejection in the status message sent to the client.
SIG-006缓解请求和状态：授权的DOTS客户端必须能够从DOTS服务器请求范围内的缓解。DOTS服务器必须向DOTS客户端发送缓解请求的状态。如果DOTS服务器拒绝授权的缓解请求，则DOTS服务器必须在发送给客户端的状态消息中包含拒绝的原因。
DOTS servers MUST regularly send mitigation status updates to authorized DOTS clients that have requested and been granted mitigation. If unreliable transport is used for the signal channel protocol, due to the higher likelihood of packet loss during a DDoS attack, DOTS servers need to send the mitigation status multiple times at regular intervals following the data transmission guidelines discussed in Section 3.1.3 of [RFC8085].
DOTS服务器必须定期将缓解状态更新发送给已请求并被授予缓解的授权DOTS客户端。如果信号通道协议使用不可靠传输，由于DDoS攻击期间数据包丢失的可能性较高，DOTS服务器需要按照[RFC8085]第3.1.3节中讨论的数据传输指南，定期多次发送缓解状态。
When DOTS client-requested mitigation is active, DOTS server status messages MUST include the following mitigation metrics:
当DOTS客户端请求的缓解措施处于活动状态时，DOTS服务器状态消息必须包括以下缓解措施：
* Total number of packets blocked by the mitigation
* 缓解措施阻止的数据包总数
* Current number of packets per second blocked
* 每秒阻止的当前数据包数
* Total number of bytes blocked
* 阻止的总字节数
* Current number of bytes per second blocked
* 每秒阻止的当前字节数
DOTS clients MAY take these metrics into account when determining whether to ask the DOTS server to cease mitigation.
在确定是否要求DOTS服务器停止缓解时，DOTS客户端可能会考虑这些指标。
A DOTS client MAY withdraw a mitigation request at any time regardless of whether mitigation is currently active. The DOTS server MUST immediately acknowledge a DOTS client's request to stop mitigation.
DOTS客户端可随时撤回缓解请求，无论缓解当前是否处于活动状态。DOTS服务器必须立即确认DOTS客户端停止缓解的请求。
To protect against route or DNS flapping caused by a client rapidly toggling mitigation, and to dampen the effect of oscillating attacks, DOTS servers MAY allow mitigation to continue for a limited period after acknowledging a DOTS client's withdrawal of a mitigation request. During this period, DOTS server status messages SHOULD indicate that mitigation is active but terminating. DOTS clients MAY reverse the mitigation termination during this active-but-terminating period with a new mitigation request for the same scope. The DOTS server MUST treat this request as a mitigation lifetime extension (see SIG-007).
为了防止客户端快速切换缓解措施导致的路由或DNS抖动，并抑制振荡攻击的影响，DOTS服务器可在确认DOTS客户端撤回缓解请求后，允许缓解措施在有限的时间内继续进行。在此期间，DOTS服务器状态消息应指示缓解措施处于活动状态，但正在终止。DOTS客户端可在此活动但终止的期间，通过针对相同范围的新缓解请求，撤销缓解终止。DOTS服务器必须将此请求视为缓解生存期延长（参见SIG-007）。
The initial active-but-terminating period is both implementation-and deployment-specific, but SHOULD be sufficiently long enough to absorb latency incurred by route propagation. If a DOTS client refreshes the mitigation before the active-but-terminating period elapses, the DOTS server MAY increase the active-but-terminating period up to a maximum of 300 seconds (5 minutes). After the active-but-terminating period elapses, the DOTS server MUST treat the mitigation as terminated, as the DOTS client is no longer responsible for the mitigation.
初始活动但终止的周期是特定于实现和部署的，但应该足够长，足以吸收路由传播引起的延迟。如果DOTS客户端在活动但终止的时间段过去之前刷新缓解，则DOTS服务器可将活动但终止的时间段最多增加300秒（5分钟）。在活动但终止的时段过后，DOTS服务器必须将缓解视为已终止，因为DOTS客户端不再负责缓解。
SIG-007 Mitigation Lifetime: DOTS servers MUST support mitigations for a negotiated time interval and MUST terminate a mitigation when the lifetime elapses. DOTS servers also MUST support renewal of mitigation lifetimes in mitigation requests from DOTS clients, allowing clients to extend mitigation as necessary for the duration of an attack.
SIG-007缓解生命周期：DOTS服务器必须支持协商时间间隔内的缓解，并且必须在生命周期结束时终止缓解。DOTS服务器还必须支持更新来自DOTS客户端的缓解请求中的缓解生存期，允许客户端在攻击持续期间根据需要延长缓解时间。
DOTS servers MUST treat a mitigation terminated due to lifetime expiration exactly as if the DOTS client originating the mitigation had asked to end the mitigation, including the active-but-terminating period, as described above in SIG-005.
DOTS服务器必须将因生存期到期而终止的缓解措施完全视为发起缓解措施的DOTS客户端已要求终止缓解措施，包括上述SIG-005中所述的活动但终止期。
DOTS clients MUST include a mitigation lifetime in all mitigation requests.
DOTS客户端必须在所有缓解请求中包含缓解生存期。
DOTS servers SHOULD support indefinite mitigation lifetimes, enabling architectures in which the mitigator is always in the traffic path to the resources for which the DOTS client is requesting protection. DOTS clients MUST be prepared to not be granted mitigations with indefinite lifetimes. DOTS servers MAY refuse mitigations with indefinite lifetimes for policy reasons. The reasons themselves are out of scope for this document. If the
DOTS服务器应支持无限缓解生存期，从而支持缓解器始终位于DOTS客户端请求保护的资源的通信路径中的体系结构。DOTS客户必须做好不被授予无限期缓解措施的准备。由于策略原因，DOTS服务器可能会拒绝寿命不确定的缓解措施。原因本身超出了本文件的范围。如果
DOTS server does not grant a mitigation request with an indefinite mitigation lifetime, it MUST set the lifetime to a value that is configured locally. That value MUST be returned in a reply to the requesting DOTS client.
DOTS服务器不授予具有无限缓解生存期的缓解请求，它必须将生存期设置为本地配置的值。该值必须在答复请求的DOTS客户端时返回。
SIG-008 Mitigation Scope: DOTS clients MUST indicate desired mitigation scope. The scope type will vary depending on the resources requiring mitigation. All DOTS agent implementations MUST support the following required scope types:
SIG-008缓解范围：DOTS客户必须指明所需的缓解范围。范围类型将因需要缓解的资源而异。所有DOTS代理实现必须支持以下所需的作用域类型：
* IPv4 prefixes [RFC4632]
* IPv4前缀[RFC4632]
* IPv6 prefixes [RFC4291] [RFC5952]
* IPv6前缀[RFC4291][RFC5952]
* Domain names [RFC1035]
* 域名[RFC1035]
The following mitigation scope type is OPTIONAL:
以下缓解范围类型是可选的：
* Uniform Resource Identifiers [RFC3986]
* 统一资源标识符[RFC3986]
DOTS servers MUST be able to resolve domain names and (when supported) URIs. How name resolution is managed on the DOTS server is implementation-specific.
DOTS服务器必须能够解析域名和（受支持时）URI。如何在DOTS服务器上管理名称解析取决于具体的实现。
DOTS agents MUST support mitigation scope aliases, allowing DOTS clients and servers to refer to collections of protected resources by an opaque identifier created through the data channel, direct configuration, or other means. Domain name and URI mitigation scopes may be thought of as a form of scope alias in which the addresses to which the domain name or URI resolve represent the full scope of the mitigation.
DOTS代理必须支持缓解范围别名，允许DOTS客户端和服务器通过通过数据通道、直接配置或其他方式创建的不透明标识符引用受保护资源的集合。域名和URI缓解作用域可以被认为是作用域别名的一种形式，其中域名或URI解析到的地址代表缓解的全部作用域。
If there is additional information available narrowing the scope of any requested attack response, such as targeted port range, protocol, or service, DOTS clients SHOULD include that information in client mitigation requests. DOTS clients MAY also include additional attack details. DOTS servers MAY ignore such supplemental information when enabling countermeasures on the mitigator.
如果有其他信息可用于缩小任何请求的攻击响应的范围，如目标端口范围、协议或服务，则DOTS客户端应在客户端缓解请求中包含该信息。DOTS客户端还可能包括其他攻击详细信息。在缓解措施上启用对策时，DOTS服务器可能会忽略此类补充信息。
As an active attack evolves, DOTS clients MUST be able to adjust as necessary the scope of requested mitigation by refining the scope of resources requiring mitigation.
随着主动攻击的发展，DOTS客户端必须能够根据需要通过细化需要缓解的资源范围来调整请求缓解的范围。
A DOTS client may obtain the mitigation scope through direct provisioning or through implementation-specific methods of discovery. DOTS clients MUST support at least one mechanism to obtain mitigation scope.
DOTS客户端可以通过直接供应或通过特定于实现的发现方法获得缓解范围。DOTS客户端必须至少支持一种机制才能获得缓解范围。
SIG-009 Mitigation Efficacy: When a mitigation request is active, DOTS clients MUST be able to transmit a metric of perceived mitigation efficacy to the DOTS server. DOTS servers MAY use the efficacy metric to adjust countermeasures activated on a mitigator on behalf of a DOTS client.
SIG-009缓解效能：当缓解请求激活时，DOTS客户端必须能够向DOTS服务器传输感知缓解效能的度量。DOTS服务器可使用效能指标代表DOTS客户端调整缓解措施上激活的应对措施。
SIG-010 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests and SHALL notify the DOTS clients in conflict. The notification MUST indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request.
SIG-010冲突检测和通知：由单个管理实体控制的多个DOTS客户端可能会由于配置错误、操作员错误或DOTS客户端受损而发送冲突缓解请求。同一管理域中的DOTS服务器试图接受冲突请求，可能会翻动网络路由或DNS信息，从而使试图参与DOTS客户端攻击响应的网络降级。单个管理域中的DOTS服务器应检测此类冲突请求，并通知冲突中的DOTS客户端。通知必须指明冲突的性质和范围，例如，冲突缓解请求中的重叠前缀范围。
SIG-011 Network Address Translator Traversal: DOTS clients may be deployed behind a Network Address Translator (NAT) and need to communicate with DOTS servers through the NAT. DOTS protocols MUST therefore be capable of traversing NATs.
SIG-011网络地址转换器穿越：DOTS客户端可能部署在网络地址转换器（NAT）后面，需要通过NAT与DOTS服务器通信。因此，DOTS协议必须能够穿越NAT。
If UDP is used as the transport for the DOTS signal channel, all considerations in "Middlebox Traversal Guidelines" in [RFC8085] apply to DOTS. Regardless of transport, DOTS protocols MUST follow established best common practices established in BCP 127 for NAT traversal [RFC4787] [RFC6888] [RFC7857].
如果将UDP用作DOTS信号通道的传输，则[RFC8085]中“中间盒遍历指南”中的所有注意事项均适用于DOTS。无论传输如何，DOTS协议必须遵循BCP 127中建立的NAT穿越最佳通用实践[RFC4787][RFC6888][RFC7857]。
The data channel is intended to be used for bulk data exchanges between DOTS agents. Unlike the signal channel, the data channel is not expected to be constructed to deal with attack conditions. As the primary function of the data channel is data exchange, a reliable transport is required in order for DOTS agents to detect data delivery success or failure.
数据通道用于DOTS代理之间的批量数据交换。与信号信道不同的是，数据信道预计不会被构造来处理攻击条件。由于数据通道的主要功能是数据交换，因此需要可靠的传输，以便DOTS代理检测数据传输的成功或失败。
The data channel provides a protocol for DOTS configuration and management. For example, a DOTS client may submit to a DOTS server a collection of prefixes it wants to refer to by alias when requesting mitigation, to which the server would respond with a success status and the new prefix group alias, or an error status and message in the event the DOTS client's data channel request failed.
数据通道为DOTS配置和管理提供协议。例如，DOTS客户端可以向DOTS服务器提交请求缓解时它想通过别名引用的前缀集合，如果DOTS客户端的数据通道请求失败，服务器将以成功状态和新前缀组别名或错误状态和消息响应该前缀集合。
DATA-001 Reliable transport: Messages sent over the data channel MUST be delivered reliably in the order sent.
DATA-001可靠传输：通过数据通道发送的消息必须按照发送顺序可靠地发送。
DATA-003 Resource Configuration: To help meet the general and signal channel requirements in Sections 2.1 and 2.2, DOTS server implementations MUST provide an interface to configure resource identifiers, as described in SIG-008. DOTS server implementations MAY expose additional configurability. Additional configurability is implementation-specific.
DATA-003资源配置：为了帮助满足第2.1节和第2.2节中的一般和信号通道要求，DOTS服务器实施必须提供一个接口来配置资源标识符，如SIG-008所述。DOTS服务器实现可能会公开额外的可配置性。额外的可配置性是特定于实现的。
DATA-004 Policy Management: DOTS servers MUST provide methods for DOTS clients to manage drop- and accept-lists of traffic destined for resources belonging to a client.
DATA-004策略管理：DOTS服务器必须为DOTS客户端提供方法，以管理发送给属于客户端的资源的流量的删除和接受列表。
For example, a DOTS client should be able to create a drop- or accept-list entry, retrieve a list of current entries from either list, update the content of either list, and delete entries as necessary.
例如，DOTS客户端应该能够创建下拉列表条目或接受列表条目，从任一列表中检索当前条目的列表，更新任一列表的内容，并根据需要删除条目。
How a DOTS server authorizes DOTS client management of drop- and accept-list entries is implementation-specific.
DOTS服务器如何授权DOTS客户机管理拖放和接受列表条目是特定于实现的。
DOTS must operate within a particularly strict security context, as an insufficiently protected signal or data channel may be subject to abuse, enabling or supplementing the very attacks DOTS purports to mitigate.
DOTS必须在特别严格的安全环境下运行，因为未充分保护的信号或数据通道可能会被滥用，从而启用或补充DOTS声称要缓解的攻击。
SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate each other before a DOTS signal or data channel is considered valid. The method of authentication is not specified in this document but should follow current IETF best practices [RFC7525] with respect to any cryptographic mechanisms to authenticate the remote peer.
SEC-001对等相互认证：在认为DOTS信号或数据通道有效之前，DOTS代理必须相互认证。本文件中未规定认证方法，但应遵循现行IETF最佳实践[RFC7525]中关于认证远程对等方的任何加密机制。
SEC-002 Message Confidentiality, Integrity, and Authenticity: DOTS protocols MUST take steps to protect the confidentiality, integrity, and authenticity of messages sent between client and server. While specific transport- and message-level security options are not specified, the protocols MUST follow current IETF best practices [RFC7525] for encryption and message authentication. Client-domain DOTS gateways are more trusted than DOTS clients, while server-domain DOTS gateways and DOTS servers share the same level of trust. A security mechanism at the transport layer (TLS or DTLS) is thus adequate to provide security between peer DOTS agents.
SEC-002消息机密性、完整性和真实性：DOTS协议必须采取措施保护客户端和服务器之间发送的消息的机密性、完整性和真实性。虽然未指定特定的传输和消息级安全选项，但协议必须遵循当前IETF加密和消息身份验证最佳实践[RFC7525]。客户端域DOTS网关比DOTS客户端更受信任，而服务器域DOTS网关和DOTS服务器共享相同级别的信任。因此，传输层（TLS或DTLS）的安全机制足以在对等点代理之间提供安全性。
In order for DOTS protocols to remain secure despite advancements in cryptanalysis and traffic analysis, DOTS agents MUST support secure negotiation of the terms and mechanisms of protocol
为了使DOTS协议在密码分析和流量分析方面保持安全，DOTS代理必须支持协议条款和机制的安全协商
security, subject to the interoperability and signal message size requirements in Section 2.2.
安全性，符合第2.2节中的互操作性和信号消息大小要求。
While the interfaces between downstream DOTS server and upstream DOTS client within a DOTS gateway are implementation-specific, those interfaces nevertheless MUST provide security equivalent to that of the signal channels bridged by gateways in the signaling path. For example, when a DOTS gateway consisting of a DOTS server and DOTS client is running on the same logical device, the two DOTS agents could be implemented within the same process security boundary.
虽然DOTS网关内的下游DOTS服务器和上游DOTS客户端之间的接口是特定于实现的，但这些接口必须提供与信令路径中网关桥接的信号通道等效的安全性。例如，当由DOTS服务器和DOTS客户端组成的DOTS网关在同一逻辑设备上运行时，两个DOTS代理可以在同一进程安全边界内实现。
SEC-003 Data Privacy and Integrity: Transmissions over the DOTS protocols are likely to contain operationally or privacy-sensitive information or instructions from the remote DOTS agent. Theft, modification, or replay of message transmissions could lead to information leaks or malicious transactions on behalf of the sending agent (see Section 4). Consequently, data sent over the DOTS protocols MUST be encrypted using secure transports (TLS or DTLS). DOTS servers MUST enable means to prevent leaking operationally or privacy-sensitive data. Although administrative entities participating in DOTS may detail what data may be revealed to third-party DOTS agents, such considerations are not in scope for this document.
SEC-003数据隐私和完整性：通过DOTS协议的传输可能包含来自远程DOTS代理的操作或隐私敏感信息或指令。窃取、修改或重播消息传输可能导致信息泄漏或代表发送代理进行恶意交易（见第4节）。因此，通过DOTS协议发送的数据必须使用安全传输（TLS或DTL）进行加密。DOTS服务器必须能够防止操作或隐私敏感数据泄漏。尽管参与DOTS的管理实体可能会详细说明哪些数据可能会透露给第三方DOTS代理，但此类考虑不在本文件的范围内。
SEC-004 Message Replay Protection: To prevent a passive attacker from capturing and replaying old messages, and thereby potentially disrupting or influencing the network policy of the receiving DOTS agent's domain, DOTS protocols MUST provide a method for replay detection and prevention.
SEC-004消息重播保护：为了防止被动攻击者捕获和重播旧消息，从而可能中断或影响接收DOTS代理域的网络策略，DOTS协议必须提供重播检测和预防方法。
Within the signal channel, messages MUST be uniquely identified such that replayed or duplicated messages can be detected and discarded. Unique mitigation requests MUST be processed at most once.
在信号通道内，必须对消息进行唯一标识，以便可以检测并丢弃重播或重复的消息。唯一的缓解请求最多只能处理一次。
SEC-005 Authorization: DOTS servers MUST authorize all messages from DOTS clients that pertain to mitigation, configuration, filtering, or status.
SEC-005授权：DOTS服务器必须授权来自DOTS客户端的与缓解、配置、筛选或状态相关的所有消息。
DOTS servers MUST reject mitigation requests with scopes that the DOTS client is not authorized to manage.
DOTS服务器必须拒绝DOTS客户端无权管理的范围内的缓解请求。
Likewise, DOTS servers MUST refuse to allow creation, modification, or deletion of scope aliases and drop- or accept-lists when the DOTS client is unauthorized.
同样，当DOTS客户端未经授权时，DOTS服务器必须拒绝创建、修改或删除作用域别名和下拉列表或接受列表。
The modes of authorization are implementation-specific.
授权模式是特定于实现的。
A well-structured DOTS data model is critical to the development of successful DOTS protocols.
结构良好的DOTS数据模型对于开发成功的DOTS协议至关重要。
DM-001 Structure: The data-model structure for the DOTS protocol MAY be described by a single module or be divided into related collections of hierarchical modules and submodules. If the data model structure is split across modules, those distinct modules MUST allow references to describe the overall data model's structural dependencies.
DM-001结构：DOTS协议的数据模型结构可由单个模块描述，或分为层次模块和子模块的相关集合。如果数据模型结构跨模块划分，则这些不同的模块必须允许引用来描述整个数据模型的结构依赖关系。
DM-002 Versioning: To ensure interoperability between DOTS protocol implementations, data models MUST be versioned. How the protocols represent data-model versions is not defined in this document.
DM-002版本控制：为了确保DOTS协议实现之间的互操作性，必须对数据模型进行版本控制。本文档中未定义协议如何表示数据模型版本。
DM-003 Mitigation Status Representation: The data model MUST provide the ability to represent a request for mitigation and the withdrawal of such a request. The data model MUST also support a representation of currently-requested mitigation status, including failures and their causes.
DM-003缓解状态表示：数据模型必须能够表示缓解请求和撤销请求。数据模型还必须支持当前请求的缓解状态的表示，包括故障及其原因。
DM-004 Mitigation Scope Representation: The data model MUST support representation of a requested mitigation's scope. As mitigation scope may be represented in several different ways, per SIG-008, the data model MUST include extensible representation of mitigation scope.
DM-004缓解范围表示：数据模型必须支持请求缓解范围的表示。根据SIG-008，缓解范围可能以几种不同的方式表示，因此数据模型必须包括缓解范围的可扩展表示。
DM-005 Mitigation Lifetime Representation: The data model MUST support representation of a mitigation request's lifetime, including mitigations with no specified end time.
DM-005缓解生命周期表示：数据模型必须支持缓解请求生命周期的表示，包括没有指定结束时间的缓解。
DM-006 Mitigation Efficacy Representation: The data model MUST support representation of a DOTS client's understanding of the efficacy of a mitigation enabled through a mitigation request.
DM-006缓解效果表示：数据模型必须支持DOTS客户对通过缓解请求启用的缓解效果的理解的表示。
DM-007 Acceptable Signal Loss Representation: The data model MUST be able to represent the DOTS agent's preference for acceptable signal loss when establishing a signal channel. Measurements of loss might include, but are not restricted to, number of consecutive missed heartbeat messages, retransmission count, or request timeouts.
DM-007可接受信号损失表示：数据模型必须能够表示DOTS代理在建立信号通道时对可接受信号损失的偏好。丢失的度量可能包括但不限于连续丢失的心跳消息数、重传计数或请求超时。
DM-008 Heartbeat Interval Representation: The data model MUST be able to represent the DOTS agent's preferred heartbeat interval, which the client may include when establishing the signal channel, as described in SIG-003.
DM-008心跳间隔表示：数据模型必须能够表示DOTS代理的首选心跳间隔，如SIG-003所述，客户机在建立信号通道时可能包括该间隔。
DM-009 Relationship to Transport: The DOTS data model MUST NOT make any assumptions about specific characteristics of any given transport into the data model, but instead represent the fields in the model explicitly.
DM-009与传输的关系：DOTS数据模型不得对数据模型中任何给定传输的特定特性做出任何假设，而是明确表示模型中的字段。
As part of a protocol expected to operate over links affected by DDoS attack traffic, the DOTS signal channel MUST NOT contribute significantly to link congestion. To meet the signal channel requirements above, DOTS signal channel implementations SHOULD support connectionless transports. However, some connectionless transports, when deployed naively, can be a source of network congestion, as discussed in [RFC8085]. Signal channel implementations using such connectionless transports, such as UDP, therefore MUST include a congestion control mechanism.
作为预期在受DDoS攻击流量影响的链路上运行的协议的一部分，DOTS信号信道不得对链路拥塞造成重大影响。为满足上述信号通道要求，DOTS信号通道实现应支持无连接传输。然而，如[RFC8085]中所讨论的，一些无连接传输在未经部署的情况下可能会造成网络拥塞。因此，使用UDP等无连接传输的信号通道实现必须包括拥塞控制机制。
Signal channel implementations using an IETF standard congestion-controlled transport protocol (like TCP) may rely on built-in transport congestion control support.
使用IETF标准拥塞控制传输协议（如TCP）的信号通道实现可能依赖于内置的传输拥塞控制支持。
As specified in DATA-001, the data channel requires reliable, in-order message delivery. Data channel implementations using an IETF standard congestion-controlled transport protocol may rely on the transport implementation's built-in congestion control mechanisms.
如DATA-001所述，数据通道需要可靠、有序的消息传递。使用IETF标准拥塞控制传输协议的数据信道实现可能依赖于传输实现的内置拥塞控制机制。
This document informs future protocols under development and so does not have security considerations of its own. However, operators should be aware of potential risks involved in deploying DOTS. DOTS agent impersonation and signal blocking are discussed here. Additional DOTS security considerations may be found in [DOTS-ARCH] and DOTS protocol documents.
本文件通知了正在开发的未来协议，因此没有其自身的安全考虑。然而，运营商应意识到部署DOTS所涉及的潜在风险。这里讨论了DOTS代理模拟和信号阻塞。更多DOTS安全注意事项可在[DOTS-ARCH]和DOTS协议文件中找到。
Impersonation of either a DOTS server or a DOTS client could have catastrophic impact on operations in either domain. If an attacker has the ability to impersonate a DOTS client, that attacker can affect policy on the network path to the DOTS client's domain up to and including instantiation of drop-lists blocking all inbound traffic to networks for which the DOTS client is authorized to request mitigation.
模拟DOTS服务器或DOTS客户端可能会对任一域中的操作产生灾难性影响。如果攻击者能够模拟DOTS客户端，则该攻击者可以影响到DOTS客户端域的网络路径上的策略，直至并包括删除列表的实例化，阻止到DOTS客户端有权请求缓解的网络的所有入站流量。
Similarly, an impersonated DOTS server may be able to act as a sort of malicious DOTS gateway, intercepting requests from the downstream DOTS client and modifying them before transmission to the DOTS server to inflict the desired impact on traffic to or from the DOTS client's domain. Among other things, this malicious DOTS gateway might receive and discard mitigation requests from the DOTS client, ensuring no requested mitigation is ever applied.
类似地，模拟的DOTS服务器可以充当一种恶意的DOTS网关，拦截来自下游DOTS客户端的请求，并在传输到DOTS服务器之前对其进行修改，以对进出DOTS客户端域的流量造成所需的影响。除此之外，此恶意DOTS网关可能会接收和丢弃来自DOTS客户端的缓解请求，从而确保不会应用任何请求的缓解。
To detect misuse, as detailed in Section 2.4, DOTS implementations require mutual authentication of DOTS agents in order to make agent impersonation more difficult. However, impersonation may still be possible as a result of credential theft, implementation flaws, or DOTS agents being compromised.
如第2.4节所述，为了检测误用，DOTS实现需要DOTS代理的相互身份验证，以使代理模拟更加困难。但是，由于凭证被盗、实现缺陷或DOTS代理被破坏，模拟仍然是可能的。
To detect compromised DOTS agents, DOTS operators should carefully monitor and audit DOTS agents to detect misbehavior and deter misuse while employing best current practices to secure network communications to reduce attack surface.
为了检测受损的DOTS代理，DOTS运营商应仔细监控和审计DOTS代理，以检测不当行为并阻止误用，同时采用当前最佳做法保护网络通信，以减少攻击面。
Blocking communication between DOTS agents has the potential to disrupt the core function of DOTS, which is to request mitigation of active or expected DDoS attacks. The DOTS signal channel is expected to operate over congested inbound links, and, as described in Section 2.2, the signal channel protocol must be designed for minimal data transfer to reduce the incidence of signal loss.
阻止DOTS代理之间的通信可能会破坏DOTS的核心功能，即请求缓解活动或预期的DDoS攻击。DOTS信号通道预计将在拥挤的入站链路上运行，如第2.2节所述，信号通道协议必须设计为最小数据传输，以减少信号丢失的发生率。
This document has no IANA actions.
本文档没有IANA操作。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<https://www.rfc-editor.org/info/rfc768>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<https://www.rfc-editor.org/info/rfc791>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<https://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，DOI 10.17487/RFC4632，2006年8月<https://www.rfc-editor.org/info/rfc4632>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.，Ed.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，DOI 10.17487/RFC4787，2007年1月<https://www.rfc-editor.org/info/rfc4787>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<https://www.rfc-editor.org/info/rfc5952>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6888]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，DOI 10.17487/RFC6888，2013年4月<https://www.rfc-editor.org/info/rfc6888>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7857]Penno，R.，Perreault，S.，Boucadair，M.，Ed.，Sivakumar，S.，和K.Naito，“网络地址转换（NAT）行为要求的更新”，BCP 127，RFC 7857，DOI 10.17487/RFC7857，2016年4月<https://www.rfc-editor.org/info/rfc7857>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<https://www.rfc-editor.org/info/rfc8085>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[DOTS-ARCH] Mortensen, A., Ed., Reddy, T., Ed., Andreasen, F., Teague, N., and R. Compton, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Work in Progress, draft-ietf-dots-architecture-13, April 2019.
[DOTS-ARCH]Mortensen，A.，Ed.，Reddy，T.，Ed.，Andreasen，F.，Teague，N.，和R.Compton，“分布式拒绝服务开放威胁信号（DOTS）体系结构”，正在进行的工作，草案-ietf-DOTS-Architecture-132019年4月。
[DOTS-USE] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Work in Progress, draft-ietf-dots-use-cases-17, January 2019.
[DOTS-USE]Dobbins，R.，Migault，D.，Fouant，S.，Moskowitz，R.，Teague，N.，Xia，L.，和K.Nishizuka，“DDoS开放威胁信号的使用案例”，正在进行中的工作，草案-ietf-DOTS-USE-cases-172019年1月。
[IP-FRAG-FRAGILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", Work in Progress, draft-ietf-intarea-frag-fragile-10, May 2019.
[IP-FRAG-易碎品]博尼卡，R.，贝克，F.，休斯顿，G.，兴登，R.，特罗安，O.，和F.冈特，“IP碎片视为易碎品”，正在进行的工作，草案-ietf-intarea-FRAG-易碎品-10，2019年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <https://www.rfc-editor.org/info/rfc7092>.
[RFC7092]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理的分类”，RFC 7092，DOI 10.17487/RFC7092，2013年12月<https://www.rfc-editor.org/info/rfc7092>.
[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.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，DOI 10.17487/RFC4732，2006年12月<https://www.rfc-editor.org/info/rfc4732>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<https://www.rfc-editor.org/info/rfc4949>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
Acknowledgments
致谢
Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner, Robert Sparks, Brian Weis, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Suresh Krishnan, Ben Campbell, Mirja Kuehlewind, and Jon Shallow for their careful reading and feedback.
感谢罗曼·达尼略、马特·理查森、乔·图奇、斯科特·布拉德纳、罗伯特·斯帕克斯、布赖恩·维斯、本杰明·卡杜克、埃里克·雷斯科拉、阿尔瓦罗·雷塔纳、苏雷什·克里希南、本·坎贝尔、米莉亚·库勒温德和乔恩·肖普的仔细阅读和反馈。
Contributors
贡献者
Mohamed Boucadair Orange
穆罕默德·布卡达尔橙
mohamed.boucadair@orange.com
穆罕默德。boucadair@orange.com
Flemming Andreasen Cisco Systems, Inc.
弗莱明·安德里森思科系统公司。
fandreas@cisco.com
fandreas@cisco.com
Dave Dolson Sandvine
戴夫·道森·桑文
ddolson@sandvine.com
ddolson@sandvine.com
Authors' Addresses
作者地址
Andrew Mortensen Arbor Networks 2727 S. State St. Ann Arbor, MI 48104 United States of America
安德鲁·莫滕森·阿伯网络美国密苏里州圣安阿伯南州2727号，邮编：48104
Email: andrewmortensen@gmail.com
Email: andrewmortensen@gmail.com
Tirumaleswar Reddy McAfee Embassy Golf Link Business Park Bangalore, Karnataka 560071 India
印度卡纳塔克邦班加罗尔Tirumaleswar Reddy McAfee大使馆高尔夫链接商务园560071
Email: TirumaleswarReddy_Konda@McAfee.com
Email: TirumaleswarReddy_Konda@McAfee.com
Robert Moskowitz Huawei Oak Park, MI 42837 United States of America
美国密歇根州华为橡树园罗伯特·莫斯科维茨邮编：42837
Email: rgm@htt-consult.com
Email: rgm@htt-consult.com