Internet Engineering Task Force (IETF) K. Moriarty
Request for Comments: 6045 EMC
Category: Informational November 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Moriarty
Request for Comments: 6045 EMC
Category: Informational November 2010
ISSN: 2070-1721
Real-time Inter-network Defense (RID)
实时网络间防御（RID）
Abstract
摘要
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
网络安全事件，如系统泄露、蠕虫、病毒、网络钓鱼事件和拒绝服务，通常会导致服务、数据和人力及系统资源的损失。网络提供商和计算机安全事件响应团队需要配备并准备好在攻击发生之前，使用适当的工具和程序，协助沟通和跟踪安全事件。实时网络间防御（RID）概述了一种主动式网络间通信方法，以促进共享事件处理数据，同时集成现有的检测、跟踪、源识别和缓解机制，形成完整的事件处理解决方案。在通信系统中结合这些功能提供了一种在网络上实现更高安全级别的方法。建议处理事故的政策指南，并可由财团使用安全建议和注意事项达成一致。
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here.
RID已在国际研究界得到应用，但尚未在其他部门得到广泛采用。本出版物向采用该规范的社区以及目前正在考虑实时网络间防御解决方案的社区提供了该规范。该规范还可以通过利用此处指定的数据元素和结构，加速需要不同传输或消息格式的解决方案的开发。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6045.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6045.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Normative and Informative ..................................6
1.2. Terminology ................................................6
1.3. Attack Types and RID Messaging .............................6
2. RID Integration with Network Provider Technologies ..............8
3. Characteristics of Attacks ......................................9
3.1. Integrating Trace Approaches ..............................11
3.2. Superset of Packet Information for Traces .................11
4. Communication between Network Providers ........................12
4.1. Inter-Network Provider RID Messaging ......................14
4.2. RID Network Topology ......................................16
4.3. Message Formats ...........................................17
4.3.1. RID Data Types .....................................17
4.3.1.1. Boolean ...................................17
4.3.2. RID Messages and Transport .........................18
4.3.3. IODEF-RID Schema ...................................19
4.3.3.1. RequestStatus Class .......................21
4.3.3.2. IncidentSource Class ......................23
4.3.3.3. RIDPolicy Class ...........................24
4.3.4. RID Namespace ......................................29
4.4. RID Messages ..............................................29
4.4.1. TraceRequest .......................................29
4.4.2. RequestAuthorization ...............................30
4.4.3. Result .............................................31
4.4.4. Investigation Request ..............................33
4.4.5. Report .............................................35
4.4.6. IncidentQuery ......................................36
4.5. RID Communication Exchanges ...............................37
4.5.1. Upstream Trace Communication Flow ..................39
4.5.1.1. RID TraceRequest Example ..................40
4.5.1.2. RequestAuthorization Message Example ......44
4.5.1.3. Result Message Example ....................44
4.5.2. Investigation Request Communication Flow ...........47
4.5.2.1. Investigation Request Example .............48
4.5.2.2. RequestAuthorization Message Example ......50
4.5.3. Report Communication ...............................51
4.5.3.1. Report Example ............................51
4.5.4. IncidentQuery Communication Flow ...................54
4.5.4.1. IncidentQuery Example .....................54
5. RID Schema Definition ..........................................55
1. Introduction ....................................................4
1.1. Normative and Informative ..................................6
1.2. Terminology ................................................6
1.3. Attack Types and RID Messaging .............................6
2. RID Integration with Network Provider Technologies ..............8
3. Characteristics of Attacks ......................................9
3.1. Integrating Trace Approaches ..............................11
3.2. Superset of Packet Information for Traces .................11
4. Communication between Network Providers ........................12
4.1. Inter-Network Provider RID Messaging ......................14
4.2. RID Network Topology ......................................16
4.3. Message Formats ...........................................17
4.3.1. RID Data Types .....................................17
4.3.1.1. Boolean ...................................17
4.3.2. RID Messages and Transport .........................18
4.3.3. IODEF-RID Schema ...................................19
4.3.3.1. RequestStatus Class .......................21
4.3.3.2. IncidentSource Class ......................23
4.3.3.3. RIDPolicy Class ...........................24
4.3.4. RID Namespace ......................................29
4.4. RID Messages ..............................................29
4.4.1. TraceRequest .......................................29
4.4.2. RequestAuthorization ...............................30
4.4.3. Result .............................................31
4.4.4. Investigation Request ..............................33
4.4.5. Report .............................................35
4.4.6. IncidentQuery ......................................36
4.5. RID Communication Exchanges ...............................37
4.5.1. Upstream Trace Communication Flow ..................39
4.5.1.1. RID TraceRequest Example ..................40
4.5.1.2. RequestAuthorization Message Example ......44
4.5.1.3. Result Message Example ....................44
4.5.2. Investigation Request Communication Flow ...........47
4.5.2.1. Investigation Request Example .............48
4.5.2.2. RequestAuthorization Message Example ......50
4.5.3. Report Communication ...............................51
4.5.3.1. Report Example ............................51
4.5.4. IncidentQuery Communication Flow ...................54
4.5.4.1. IncidentQuery Example .....................54
5. RID Schema Definition ..........................................55
6. Security Considerations ........................................60
6.1. Message Transport .........................................62
6.2. Message Delivery Protocol - Integrity and Authentication ..63
6.3. Transport Communication ...................................63
6.4. Authentication of RID Protocol ............................64
6.4.1. Multi-Hop TraceRequest Authentication ..............65
6.5. Consortiums and Public Key Infrastructures ................66
6.6. Privacy Concerns and System Use Guidelines ................67
7. IANA Considerations ............................................72
8. Summary ........................................................72
9. References .....................................................73
9.1. Normative References ......................................73
9.2. Informative References ....................................74
Acknowledgements ..................................................75
Sponsor Information ...............................................75
6. Security Considerations ........................................60
6.1. Message Transport .........................................62
6.2. Message Delivery Protocol - Integrity and Authentication ..63
6.3. Transport Communication ...................................63
6.4. Authentication of RID Protocol ............................64
6.4.1. Multi-Hop TraceRequest Authentication ..............65
6.5. Consortiums and Public Key Infrastructures ................66
6.6. Privacy Concerns and System Use Guidelines ................67
7. IANA Considerations ............................................72
8. Summary ........................................................72
9. References .....................................................73
9.1. Normative References ......................................73
9.2. Informative References ....................................74
Acknowledgements ..................................................75
Sponsor Information ...............................................75
Incident handling involves the detection, reporting, identification, and mitigation of an attack, whether it be a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack. When an attack is detected, the response may include simply filing a report, notification to the source of the attack, a request for mitigation, or the request to locate the source. One of the more difficult cases is that in which the source of an attack is unknown, requiring the ability to trace the attack traffic iteratively upstream through the network for the possibility of any further actions to take place. In cases when accurate records of an active session between the victim system and the attacker or source system are available, the source is easy to identify. The problem of tracing incidents becomes more difficult when the source is obscured or spoofed, logs are deleted, and the number of sources is overwhelming. If the source of an attack is known or identified, it may be desirable to request actions be taken to stop or mitigate the effects of the attack.
事件处理涉及对攻击的检测、报告、识别和缓解，无论是系统危害、社会工程钓鱼攻击还是拒绝服务（DoS）攻击。当检测到攻击时，响应可能仅包括提交报告、通知攻击源、请求缓解或请求定位攻击源。更困难的情况之一是攻击源未知，需要能够通过网络迭代跟踪上游的攻击流量，以便采取任何进一步行动。当受害者系统与攻击者或源系统之间的活动会话的准确记录可用时，很容易识别源。当来源被隐藏或欺骗、日志被删除以及来源数量庞大时，跟踪事件的问题变得更加困难。如果已知或确定了攻击源，则可能需要请求采取措施来停止或减轻攻击的影响。
Current approaches to mitigating the effects of security incidents are aimed at identifying and filtering or rate-limiting packets from attackers who seek to hide the origin of their attack by source address spoofing from multiple locations. Measures can be taken at network provider (NP) edge routers providing ingress, egress, and broadcast filtering as a recommended best practice in [RFC2827].
当前缓解安全事件影响的方法旨在识别和过滤或限制来自攻击者的数据包，这些攻击者试图通过从多个位置进行源地址欺骗来隐藏其攻击来源。作为[RFC2827]中推荐的最佳实践，可在提供入口、出口和广播过滤的网络提供商（NP）边缘路由器处采取措施。
Network providers have devised solutions, in-house or commercial, to trace attacks across their backbone infrastructure to either identify the source on their network or on the next upstream network in the path to the source. Techniques such as collecting packets as traffic traverses the network have been implemented to provide the capability
网络提供商已设计出内部或商业解决方案，以跟踪其主干基础设施上的攻击，从而确定其网络上的源或到达源路径中的下一个上游网络上的源。在流量通过网络时收集数据包等技术已经实现，以提供这种能力
to trace attack traffic after an incident has occurred. Other methods use packet-marking techniques or flow-based traffic analysis to trace traffic across the network in real time. The single-network trace mechanisms use similar information across the individual networks to trace traffic. Problems may arise when an attempt is made to have a trace continued through the next upstream network since the trace mechanism and management may vary.
跟踪事件发生后的攻击流量。其他方法使用包标记技术或基于流的流量分析来实时跟踪网络上的流量。单网络跟踪机制使用单个网络中的类似信息来跟踪流量。当试图通过下一个上游网络继续跟踪时，可能会出现问题，因为跟踪机制和管理可能会有所不同。
In the case in which the traffic traverses multiple networks, there is currently no established communication mechanism for continuing the trace. If the next upstream network has been identified, a phone call might be placed to contact the network administrators in an attempt to have them continue the trace. A communication mechanism is needed to facilitate the transfer of information to continue traces accurately and efficiently to upstream networks. The communication mechanism described in this paper, Real-time Inter-network Defense (RID), takes into consideration the information needed by various single-network trace implementations and the requirement for network providers to decide if a TraceRequest should be permitted to continue. The data in RID messages is represented in an Extensible Markup Language (XML) [XML1.0] document using the Incident Object Description Exchange Format (IODEF) and RID. By following this model, integration with other aspects of the network for incident handling is simplified. Finally, methods are incorporated into the communication system to indicate what actions need to be taken closest to the source in order to halt or mitigate the effects of the attack at hand. RID is intended to provide a method to communicate the relevant information between Computer Security Incident Response Teams (CSIRTs) while being compatible with a variety of existing and possible future detection tracing and response approaches.
在流量穿越多个网络的情况下，目前没有用于继续跟踪的既定通信机制。如果已确定下一个上游网络，则可能会拨打电话与网络管理员联系，试图让他们继续跟踪。需要一种通信机制来促进信息的传输，以便准确有效地继续跟踪到上游网络。本文描述的通信机制实时网络间防御（RID）考虑了各种单一网络跟踪实现所需的信息以及网络提供商决定是否允许继续跟踪请求的要求。RID消息中的数据使用事件对象描述交换格式（IODEF）和RID以可扩展标记语言（XML）[XML1.0]文档表示。通过遵循此模型，可以简化与网络其他方面的集成，以进行事件处理。最后，将方法并入通信系统中，以指示需要在距离源最近的地方采取哪些行动，以便停止或减轻当前攻击的影响。RID旨在提供一种在计算机安全事件响应团队（CSIRT）之间传递相关信息的方法，同时与各种现有和可能的未来检测跟踪和响应方法兼容。
At this point, RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here.
目前，RID已在国际研究界得到应用，但尚未在其他部门得到广泛采用。本出版物向采用该规范的社区以及目前正在考虑实时网络间防御解决方案的社区提供了该规范。该规范还可以通过利用此处指定的数据元素和结构，加速需要不同传输或消息格式的解决方案的开发。
Security and privacy considerations are of high concern since potentially sensitive information may be passed through RID messages. RID messaging takes advantage of XML security and privacy policy information set in the RID schema. The RID schema acts as an XML envelope to support the communication of IODEF documents for exchanging or tracing information regarding security incidents. RID messages are encapsulated for transport, which is defined in a
由于潜在的敏感信息可能会通过RID消息传递，因此安全和隐私方面的考虑备受关注。RID消息传递利用RID模式中设置的XML安全和隐私策略信息。RID模式充当XML信封，支持IODEF文档的通信，以交换或跟踪有关安全事件的信息。RID消息是为传输而封装的，传输是在
separate document [RFC6046]. The authentication, integrity, and authorization features each layer has to offer are used to achieve a necessary level of security.
单独文件[RFC6046]。每个层必须提供的身份验证、完整性和授权功能用于实现必要的安全级别。
The XML schema [XMLschema] and transport requirements contained in this document are normative; all other information provided is intended as informative. More specifically, the following sections of this document are intended as informative: Sections 1, 2, and 3; and the sub-sections of 4 including the introduction to 4, 4.1, and 4.2. The following sections of this document are normative: The sub-sections of 4 including 4.3, 4.4, and 4.5; Section 5; and Section 6.
本文件中包含的XML模式[XMLschema]和传输要求是规范性的；提供的所有其他信息旨在提供信息。更具体地说，本文件的以下章节旨在提供信息：第1、2和3节；以及第4节的小节，包括第4节、第4.1节和第4.2节的介绍。本文件的以下章节为规范性章节：第4.3节、第4.4节和第4.5节；第5节；和第6节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
RID messaging is intended for use in coordinating incident handling to locate the source of an attack and stop or mitigate the effects of the attack. The attack types include system or network compromises, denial-of-service attacks, or other malicious network traffic. RID is essentially a messaging system coordinating attack detection, tracing mechanisms, and the incident handling responses to locate the source of traffic. If a source address is spoofed, a more detailed trace of a packet (RID TraceRequest) would be required to locate the true source. If the source address is valid, the incident handling may only involve the use of routing information to determine what network provider is closest to the source (RID Investigation request) and can assist with the remediation. The type of RID message used to locate a source is determined by the validity of the source address. RID message types are discussed in Section 4.3.
RID消息用于协调事件处理，以定位攻击源并停止或减轻攻击的影响。攻击类型包括系统或网络泄露、拒绝服务攻击或其他恶意网络流量。RID本质上是一个消息传递系统，协调攻击检测、跟踪机制和事件处理响应，以定位流量源。如果源地址是伪造的，则需要更详细的数据包跟踪（RID TRACEQUEST）来定位真正的源。如果源地址有效，则事件处理可能只涉及使用路由信息来确定哪个网络提供商距离源最近（RID调查请求），并可协助补救。用于定位源的RID消息的类型由源地址的有效性决定。RID消息类型在第4.3节中讨论。
DoS [DoS] attacks are characterized by large amounts of traffic destined for particular Internet locations and can originate from a single or multiple sources. An attack from multiple sources is known as a distributed denial-of-service (DDoS) attack. Because DDoS attacks can originate from multiple sources, tracing such an attack can be extremely difficult or nearly impossible. Many TraceRequests may be required to accomplish the task and may require the use of dedicated network resources to communicate incident handling information to prevent a DoS attack against the RID system and network used for tracing and remediation. Provisions are suggested
DoS[DoS]攻击的特点是以特定互联网位置为目的地的大量流量，可以来自单个或多个来源。来自多个来源的攻击称为分布式拒绝服务（DDoS）攻击。由于DDoS攻击可能来自多个来源，因此跟踪此类攻击可能非常困难或几乎不可能。完成该任务可能需要许多TraceRequest，并且可能需要使用专用网络资源来传递事件处理信息，以防止针对RID系统和用于跟踪和修复的网络的DoS攻击。建议作出规定
to reduce the load and prevent the same trace from occurring twice on a single-network backbone discussed in Section 4 on communication between NPs. The attacks can be launched from systems across the Internet unified in their efforts or by compromised systems enlisted as "zombies" that are controlled by servers, thereby providing anonymity to the controlling server of the attack. This scenario may require multiple RID traces, one to locate the zombies and an additional one to locate the controlling server. DDoS attacks do not necessarily spoof the source of an attack since there are a large number of source addresses, which make it difficult to trace anyway. DDoS attacks can also originate from a single system or a subset of systems that spoof the source address in packet headers in order to mask the identity of the attack source. In this case, an iterative trace through the upstream networks in the path of the attack traffic may be required.
减少负载并防止在第4节“NPs之间的通信”中讨论的单个网络主干上发生两次相同的跟踪。这些攻击可以从互联网上统一努力的系统发起，也可以由服务器控制的被列为“僵尸”的受损系统发起，从而为攻击的控制服务器提供匿名性。此场景可能需要多个RID跟踪，一个用于定位僵尸，另一个用于定位控制服务器。DDoS攻击不一定会欺骗攻击源，因为存在大量源地址，因此很难进行跟踪。DDoS攻击也可以源于单个系统或系统子集，这些系统通过欺骗数据包头中的源地址来掩盖攻击源的身份。在这种情况下，可能需要在攻击流量的路径中通过上游网络进行迭代跟踪。
RID traces may also be used to locate a system used in an attack to compromise another system. Compromising a system can be accomplished through one of many attack vectors, using various techniques from a remote host or through local privilege escalation attempts. The attack may exploit a system or application level vulnerability that may be the result of a design flaw or a configuration issue. A compromised system, as described above, can be used to later attack other systems. A single RID Investigation request may be used in this case since it is probable that the source address is valid. Identifying the sources of system compromises may be difficult since an attacker may access the compromised system from various sources. The attacker may also take measures to hide their tracks by deleting log files or by accessing the system through a series of compromised hosts. Iterative RID traces may be required for each of the compromised systems used to obscure the source of the attack. If the source address is valid, an Investigation request may be used in lieu of a full RID TraceRequest.
RID跟踪还可用于定位攻击中使用的系统，以危害另一个系统。通过使用远程主机的各种技术或通过本地权限提升尝试，可以通过多种攻击向量之一来破坏系统。该攻击可能利用系统或应用程序级漏洞进行攻击，该漏洞可能是由于设计缺陷或配置问题造成的。如上所述，受损系统可用于以后攻击其他系统。在这种情况下，可以使用单个RID调查请求，因为源地址可能有效。由于攻击者可能从各种来源访问受损系统，因此识别系统受损的来源可能很困难。攻击者还可能采取措施，通过删除日志文件或通过一系列受损主机访问系统来隐藏其踪迹。对于用于隐藏攻击源的每个受损系统，可能需要迭代RID跟踪。如果源地址有效，可以使用调查请求代替完整请求。
Once an attack has been reported, CSIRTs may want to query other CSIRTs if they have detected an attack or simply report that one has taken place. The Report message can be used to file a report without an action taken, and an IncidentQuery can be used to ask if an attack has been seen by another CSIRT.
一旦报告了攻击，CSIRT可能希望查询其他CSIRT是否检测到攻击，或者只是报告发生了攻击。报告消息可用于在不采取任何操作的情况下提交报告，意外查询可用于询问另一个CSIRT是否看到了攻击。
System compromises may result from other security incident types such as worms, Trojans, or viruses. It is often the case that an incident goes unreported even if valid source address information is available because it is difficult to take any action to mitigate or stop the attack. Incident handling is a difficult task for an NP and even at some client locations due to network size and resource limitations.
其他安全事件类型（如蠕虫、特洛伊木马或病毒）可能会导致系统受损。通常情况下，即使有效的源地址信息可用，事件也不会报告，因为很难采取任何措施来缓解或停止攻击。由于网络规模和资源限制，事件处理对于NP来说是一项困难的任务，甚至在某些客户端位置也是如此。
For the purpose of this document, a network provider (NP) shall be defined as a backbone infrastructure manager of a network. The network provider's Computer Security Incident Response Team shall be referred to as the CSIRT. The backbone may be that of an organization providing network (Internet or private) access to commercial, personal, government, or educational institutions, or the backbone provider of the connected network. The connected network provider is an extension meant to include Intranet and Extranet providers as well as instances such as a business or educational institute's private network.
在本文件中，网络提供商（NP）应定义为网络的主干基础设施管理器。网络提供商的计算机安全事件响应团队应称为CSIRT。主干网可以是向商业、个人、政府或教育机构提供网络（互联网或私人）接入的组织的主干网，也可以是连接网络的主干网提供商。连接网络提供商是一个扩展，旨在包括内联网和外联网提供商以及企业或教育机构的专用网络等实例。
NPs typically manage and monitor their networks through a centralized network management system (NMS). The acronym "NMS" will be used to generically represent management systems on a network used for the management of network resources. An incident handling system (IHS) is used to communicate RID messages and may be integrated with an NMS as well as other components of the network. The components of the network that may be integrated through the RID messaging system include attack or event detection, network tracing, and network devices to stop the effects of an attack.
NPs通常通过集中式网络管理系统（NMS）管理和监控其网络。首字母缩略词“NMS”一般用于表示网络上用于管理网络资源的管理系统。事件处理系统（IHS）用于传递RID消息，并可与NMS以及网络的其他组件集成。可通过RID消息传递系统集成的网络组件包括攻击或事件检测、网络跟踪以及用于停止攻击影响的网络设备。
The detection of security incidents may rely on manual reporting, automated intrusion detection tools, and variations in traffic types or levels on a network. Intrusion detection systems (IDSs) may be integrated into the IHS to create IODEF documents or RID messages to facilitate security incident handling. Detection of a security incident is outside the scope of this paper; however, it should be possible to integrate detection methods with RID messaging.
安全事件的检测可能依赖于手动报告、自动入侵检测工具以及网络上流量类型或级别的变化。入侵检测系统（IDSs）可集成到IHS中，以创建IODEF文档或RID消息，以便于安全事件处理。安全事件的检测超出了本文的范围；但是，应该可以将检测方法与RID消息传递集成在一起。
RID messaging in an IHS is intended to be flexible in order to accommodate various traceback systems currently in use as well as those that may evolve with technology. RID is intended to communicate the necessary information needed by a trace mechanism to the next upstream NP in the path of a trace. Therefore, a RID message must carry the superset of data required for all tracing systems. If possible, the trace may need to inspect packets to determine a pattern, which could assist reverse path identification. This may be accomplished by inspecting packet header information such as the source and destination IP addresses, ports, and protocol flags to determine if there is a way to distinguish the packets being traced from other packets. A description of the incident along with any available automated trace data should trigger an alert to the NP's CSIRT for further investigation. The various technologies used to trace traffic across a network are described in Section 3.1.
IHS中的RID消息传递旨在具有灵活性，以适应当前使用的各种回溯系统以及可能随技术发展而变化的系统。RID旨在将跟踪机制所需的必要信息传达给跟踪路径中的下一个上游NP。因此，RID消息必须携带所有跟踪系统所需的数据超集。如果可能，跟踪可能需要检查数据包以确定模式，这可能有助于反向路径识别。这可以通过检查分组报头信息（例如源和目的地IP地址、端口和协议标志）来实现，以确定是否有方法将正在跟踪的分组与其他分组区分开来。事件描述以及任何可用的自动跟踪数据应触发警报，通知NP的CSIRT进行进一步调查。第3.1节描述了用于跟踪网络流量的各种技术。
Another area of integration is the ability to mitigate or stop attack traffic once a source has been located. Any automated solution should consider the possible side effects to the network. A change control process or a central point for configuration management might be used to ensure that the security of the network and necessary functionality are maintained and that equipment configuration changes are documented. Automated solutions may depend upon the capabilities and current configuration management solutions on a particular network. The solutions may be based on HTTP/TLS (Transport Layer Security) or an appropriate protocol defined in the transport specification.
另一个集成领域是，一旦找到攻击源，就能够缓解或停止攻击流量。任何自动化解决方案都应该考虑到网络可能带来的副作用。变更控制流程或配置管理中心点可用于确保维护网络安全和必要功能，并记录设备配置变更。自动化解决方案可能取决于特定网络上的功能和当前配置管理解决方案。这些解决方案可以基于HTTP/TLS（传输层安全性）或传输规范中定义的适当协议。
The goal of tracing a security incident may be to identify the source or to find a point on the network as close to the origin of the incident as possible. A security incident may be defined as a system compromise, a worm or Trojan infection, or a single- or multiple-source denial-of-service attack. Incident tracing can be used to identify the source(s) of an attack in order to halt or mitigate the undesired behavior. The communication system, RID, described in this paper can be used to trace any type of security incident and allows for actions to be taken when the source of the attack or a point closer to the source is known or has been identified. The purpose of tracing an attack would be to halt or mitigate the effects of the attack through methods such as filtering or rate-limiting the traffic close to the source or by using methods such as taking the host or network offline. Care must also be taken to ensure that the system is not abused and to use proper analysis in determining if attack traffic is, in fact, attack traffic at each NP along the path of a trace.
跟踪安全事件的目标可能是确定来源或在网络上找到尽可能靠近事件来源的点。安全事件可定义为系统泄露、蠕虫或特洛伊木马感染或单源或多源拒绝服务攻击。事件跟踪可用于识别攻击源，以停止或缓解不希望发生的行为。本文描述的通信系统RID可用于跟踪任何类型的安全事件，并允许在已知或已识别攻击源或更接近攻击源的点时采取行动。跟踪攻击的目的是通过过滤或限制靠近源的流量，或使用使主机或网络离线等方法来停止或减轻攻击的影响。还必须注意确保系统不被滥用，并使用适当的分析来确定攻击流量是否实际上是沿着跟踪路径的每个NP处的攻击流量。
Tracing security incidents can be a difficult task since attackers go to great lengths to obscure their identity. In the case of a security incident, the true source might be identified through an existing established connection to the attacker's point of origin. However, the attacker may not connect to the compromised system for a long period of time after the initial compromise or may access the system through a series of compromised hosts spread across the network. Other methods of obscuring the source may include targeting the host with the same attack from multiple sources using both valid and spoofed source addresses. This tactic can be used to compromise a machine and leave the difficult task of locating the true origin for the administrators. Security incidents, including DDoS attacks, can be difficult or nearly impossible to trace because of the nature of the attack. Some of the difficulties in tracing attacks include the following:
追踪安全事件可能是一项困难的任务，因为攻击者竭尽全力掩盖其身份。在发生安全事件的情况下，可以通过与攻击者来源点的现有已建立连接来识别真实来源。但是，攻击者可能在初始入侵后的很长一段时间内无法连接到入侵系统，或者可能通过分布在网络上的一系列入侵主机访问系统。隐藏源的其他方法可能包括使用有效和伪造的源地址从多个源以具有相同攻击的主机为目标。这种策略可用于破坏机器，并将查找真实来源的困难任务留给管理员。由于攻击的性质，包括DDoS攻击在内的安全事件可能很难或几乎不可能追踪。追踪攻击的一些困难包括：
o the attack originates from multiple sources;
o 攻击来自多个来源；
o the attack may include various types of traffic meant to consume server resources, such as a SYN flood attack without a significant increase in bandwidth utilization;
o 该攻击可包括旨在消耗服务器资源的各种类型的通信量，例如在不显著增加带宽利用率的情况下的SYN洪水攻击；
o the type of traffic could include valid destination services, which cannot be blocked since they are essential services to business, such as DNS servers at an NP or HTTP requests sent to an organization connected to the Internet;
o 通信量的类型可以包括有效的目的地服务，不能阻止这些服务，因为它们是业务的基本服务，例如NP的DNS服务器或发送到连接到互联网的组织的HTTP请求；
o the attack may utilize varying types of packets including TCP, UDP, ICMP, or other IP protocols;
o 攻击可能利用不同类型的数据包，包括TCP、UDP、ICMP或其他IP协议；
o the attack may be from "zombies", which then require additional searches to locate a controlling server as the true origin of the attack;
o 攻击可能来自“僵尸”，然后需要进行额外搜索，以确定控制服务器是攻击的真正来源；
o the attack may use a very small number of packets from any particular source, thus making a trace after the fact nearly impossible.
o 攻击可能会使用来自任何特定来源的极少量数据包，因此几乎不可能跟踪事实。
If the source(s) of the attack cannot be determined from IP address information or tracing the increased bandwidth utilization, it may be possible to trace the traffic based on the type of packets seen by the client. In the case of packets with spoofed source addresses, it is no longer a trivial task to identify the source of an attack. In the case of an attack using valid source addresses, methods such as the traceroute utility can be used to fairly accurately identify the path of the traffic between the source and destination of an attack. If the true source has been identified, actions should be taken to halt or mitigate the effects of the attack by reporting the incident to the NP or the upstream NP closest to the source. In the case of a spoofed source address, other methods can be used to trace back to the source of an attack. The methods include packet filtering, packet hash comparisons, IP marking techniques, ICMP traceback, and packet flow analysis. As in the case of attack detection, tracing traffic across a single network is a function that can be used with RID in order to provide the network with the ability to trace spoofed traffic to the source, while RID provides all the necessary information to accommodate the approach used on any single network to accomplish this task. RID can also be used to report attack traffic close to the source where the IP address used was determined to be valid or simply to report that an incident occurred.
如果无法根据IP地址信息或跟踪增加的带宽利用率来确定攻击源，则可以根据客户端看到的数据包类型跟踪流量。对于具有伪造源地址的数据包，识别攻击源不再是一项简单的任务。在使用有效源地址进行攻击的情况下，可以使用traceroute实用程序等方法相当准确地识别攻击源和目标之间的通信路径。如果确定了真正的来源，则应采取行动，通过向NP或距离来源最近的上游NP报告事件来停止或减轻攻击的影响。对于伪造的源地址，可以使用其他方法追溯攻击源。这些方法包括包过滤、包散列比较、IP标记技术、ICMP回溯和包流分析。与攻击检测一样，跟踪单个网络上的流量是一项可与RID一起使用的功能，以便为网络提供跟踪伪造流量到源的能力，而RID提供所有必要的信息，以适应任何单个网络上用于完成此任务的方法。RID还可用于报告所用IP地址被确定为有效的源附近的攻击流量，或仅报告发生事件。
There have been many separate research initiatives to solve the problem of tracing upstream packets to detect the true source of attack traffic. Upstream packet tracing is currently confined to the borders of a network or an NP's network. Traces require access to network equipment and resources, thus potentially limiting a trace to a specific network. Once a trace reaches the boundaries of a network, the network manager or NP adjacent in the upstream trace must be contacted in order to continue the trace. NPs have been working on individual solutions to accomplish upstream tracing within their own network environments. The tracing mechanisms implemented thus far have included proprietary or custom solutions requiring specific information such as IP packet header data, hash values of the attack packets, or marked packets. Hash values are used to compare a packet against a database of packets that have passed through the network as described in "Hash-Based IP Traceback" [HASH-IPtrace]. Other research solutions involve marking packets as explained in "ICMP Traceback Messages" [ICMPtrace], "Practical network support for IP traceback" [NTWK-IPtrace], the IP Flow Information eXport (IPFIX) protocol [RFC3917], and IP marking [IPtrace]. The single-network traceback solutions were considered in developing RID to determine the information needed to accomplish an inter-network trace where different solutions may be in place.
有许多单独的研究计划来解决跟踪上游数据包以检测攻击流量的真正来源的问题。上游包跟踪目前仅限于网络或NP网络的边界。跟踪需要访问网络设备和资源，因此可能会将跟踪限制到特定网络。一旦跟踪到达网络边界，必须联系上游跟踪中相邻的网络管理器或NP以继续跟踪。NPs一直在研究各自的解决方案，以在自己的网络环境中完成上游跟踪。迄今为止实施的跟踪机制包括需要特定信息的专有或定制解决方案，例如IP分组报头数据、攻击分组的散列值或标记分组。散列值用于将数据包与通过网络的数据包数据库进行比较，如“基于散列的IP回溯”[Hash IPtrace]中所述。其他研究解决方案包括按照“ICMP回溯消息”[ICMPtrace]、“IP回溯的实际网络支持”[NTWK IPtrace]、IP流信息导出（IPFIX）协议[RFC3917]和IP标记[IPtrace]中的说明标记数据包。在开发RID时考虑了单网络回溯解决方案，以确定完成网络间跟踪所需的信息，其中可能存在不同的解决方案。
In order for network traffic to be traced across a network, an example packet from the attack must be sent along with the TraceRequest or Investigation request. According to the research for hash-based IP traceback, all of the non-changing fields of an IP header along with 8 bytes of payload are required to provide enough information to uniquely trace the path of a packet. The non-changing fields of the packet header and the 8 bytes of payload are the superset of data required by most single-network tracing systems used; limiting the shared data to the superset of the packet header and 8 bytes of payload prevents the need for sharing potentially sensitive information that may be contained in the data portion of a packet.
为了通过网络跟踪网络流量，必须将来自攻击的示例数据包与TraceRequest或调查请求一起发送。根据对基于散列的IP回溯的研究，IP报头的所有不变字段以及8字节的有效负载都需要提供足够的信息来唯一地追踪数据包的路径。数据包报头的不变字段和8字节的有效负载是所使用的大多数单网络跟踪系统所需的数据超集；将共享数据限制为分组报头的超集和8字节的有效载荷，防止了共享可能包含在分组的数据部分中的潜在敏感信息的需要。
The RecordItem class in the IODEF is used to store a hexadecimal formatted packet including all packet header information plus 8 bytes of payload, or the entire packet contents. The above trace systems do not require a full packet, but it may be useful in some cases, so the option is given to allow a full packet to be included in the data model.
IODEF中的RecordItem类用于存储十六进制格式的数据包，包括所有数据包头信息加上8字节的有效负载，或整个数据包内容。上述跟踪系统不需要完整的数据包，但在某些情况下可能有用，因此提供了允许在数据模型中包含完整数据包的选项。
If a subset of a packet is used, the research presented in "Hash-Based IP Traceback" [HASH-IPtrace] provides guidelines to establish a minimum requirement for distinguishing packets. The full packet and content SHOULD be provided, but the minimum requirement MUST be provided. The research from [HASH-IPtrace] found that the first 28 invariant bytes of a packet (masked IP header plus the first 8 bytes of the payload) are sufficient to differentiate almost all non-identical IPv4 packets. RID requires the first 28 invariant bytes of an IPv4 packet in order to perform a trace. RID requires the first 48 invariant bytes for an IPv6 packet in order to distinguish the packet in a trace. Reference [HASH-IPtrace] for additional details.
如果使用了数据包的一个子集，“基于散列的IP回溯”[Hash-IPtrace]中的研究为确定区分数据包的最低要求提供了指导。应提供完整的数据包和内容，但必须提供最低要求。[HASH IPtrace]的研究发现，数据包的前28个不变字节（屏蔽IP头加上有效负载的前8个字节）足以区分几乎所有不相同的IPv4数据包。RID需要IPv4数据包的前28个不变字节才能执行跟踪。RID需要IPv6数据包的前48个不变字节，以便区分跟踪中的数据包。有关更多详细信息，请参考[HASH IPtrace]。
The input mechanism for packets to be traced should be flexible to allow intrusion detection systems or packet sniffers to provide the information. The system creating the RID message should also use the packet information to populate the Incident class information in order to avoid human error and also allow a system administrator to override the automatically populated information.
要跟踪的数据包的输入机制应该灵活，以允许入侵检测系统或数据包嗅探器提供信息。创建RID消息的系统还应使用数据包信息填充事件类别信息，以避免人为错误，并允许系统管理员覆盖自动填充的信息。
Note: The Introduction, and Sub-sections 4.1 and 4.2, are informative, with the exception of references to IODEF/RID Transport [RFC6046]. Sub-sections 4.3, 4.4, and 4.5 are normative.
注：引言以及第4.1和4.2小节仅供参考，但对IODEF/RID传输[RFC6046]的引用除外。第4.3、4.4和4.5小节是规范性的。
Expediting the communication between CSIRTs is essential when responding to a security-related incident, which may cross network access points (Internet backbones) between providers. As a result of the urgency involved in this inter-NP security incident communication, there must be an effective system in place to facilitate the interaction. This communication policy or system should involve multiple means of communication to avoid a single point of failure. Email is one way to transfer information about the incident, packet traces, etc. However, email may not be received in a timely fashion or be acted upon with the same urgency as a phone call or other communication mechanism.
在响应与安全相关的事件时，加快CSIRT之间的通信至关重要，这可能会跨越提供商之间的网络接入点（Internet主干网）。由于NP间安全事件通信的紧迫性，必须有一个有效的系统来促进交互。该通信策略或系统应包括多种通信方式，以避免单点故障。电子邮件是传递有关事件、数据包跟踪等信息的一种方式。但是，电子邮件可能无法及时接收，也可能无法像电话或其他通信机制那样紧急处理。
Each NP should dedicate a phone number to reach a member of their respective CSIRT. The phone number could be dedicated to inter-NP incident communications and must be a hotline that provides a 24x7 live response. The phone line should reach someone who would have the authority, expertise, and the means to expedite the necessary action to investigate the incident. This may be a difficult policy to establish at smaller NPs due to resource limitations, so another solution may be necessary. An outside group may be able to serve this function if given the necessary access to the NP's network. The outside resource should be able to mitigate or alleviate the financial limitations and any lack of experienced resource personnel.
每个NP应指定一个电话号码，以便联系各自CSIRT的成员。该电话号码可以专用于NP之间的事件通信，并且必须是提供全天候实时响应的热线电话。电话线应与有权、有专业知识、有能力加快必要行动以调查事件的人取得联系。由于资源限制，这可能是一项难以在较小的核动力源上制定的政策，因此可能需要另一种解决方案。如果给予NP网络必要的访问权，外部团体可能能够履行这一职能。外部资源应能够缓解或减轻财务限制以及缺乏经验丰富的资源人员。
A technical solution to trace traffic across a single NP may include homegrown or commercial systems for which RID messaging must accommodate the input requirements. The IHS used on the NP's backbone by the CSIRT to coordinate the trace across the single network requires a method to accept and process RID messages and relay TraceRequests to the system, as well as to wait for responses from the system to continue the RID request process as appropriate. In this scenario, each NP would maintain its own RID/IHS and integrate with a management station used for network monitoring and analysis. An alternative for NPs lacking sufficient resources may be to have a neutral third party with access to the NP's network resources who could be used to perform the incident handling functions. This could be a function of a central organization operating as a CSIRT for the Internet as a whole or within a consortium that may be able to provide centralized resources. Consortiums would consist of a group of NPs and/or CSIRTs that agree to participate in the RID communication protocol with an agreed-upon policy and communication protocol facilitating the secure transport of IODEF/RID XML documents. Transport for RID messages is specified in the IODEF/RID Transport [RFC6046] document.
跨单个NP跟踪流量的技术解决方案可能包括国产或商用系统，RID消息必须满足这些系统的输入要求。CSIRT在NP主干上使用的IHS用于协调单个网络上的跟踪，需要一种方法来接受和处理RID消息，并将跟踪请求中继到系统，以及等待系统的响应以继续RID请求过程（视情况而定）。在这种情况下，每个NP将维护自己的RID/IHS，并与用于网络监控和分析的管理站集成。对于缺乏足够资源的核动力源，另一种选择可能是让一个中立的第三方访问核动力源的网络资源，该第三方可用于执行事件处理功能。这可能是作为整个互联网的CSIRT或在能够提供集中资源的联盟内运作的中央组织的功能。联合体将由一组同意参与RID通信协议的NPs和/或CSIRT组成，这些NPs和/或CSIRT具有促进IODEF/RID XML文档安全传输的商定政策和通信协议。RID消息的传输在IODEF/RID传输[RFC6046]文档中指定。
One goal of RID is to prevent the need to permit access to other networks' equipment through the use of a standard messaging mechanism to enable IHSs to communicate incident handling information to other networks in a consortium or in neighboring networks. The third party mentioned above may be used in this technical solution to assist in facilitating incident handling and possibly traceback through smaller NPs. The RID messaging mechanism may be a logical or physical out-of-band network to ensure that the communication is secure and unaffected by the state of the network under attack. The two management methods would accommodate the needs of larger NPs to maintain full management of their network, and the third-party option could be available to smaller NPs who lack the necessary human resources to perform incident handling operations. The first method enables the individual NPs to involve their network operations staff to authorize the continuance of a trace or other necessary response to a RID communication request through their network via a notification and alerting system. The out-of-band logical solution for messaging may be permanent virtual circuits configured with a small amount of bandwidth dedicated to RID communications between NPs.
RID的一个目标是防止需要通过使用标准消息传递机制来允许访问其他网络的设备，以使IHS能够将事件处理信息传递给联盟或相邻网络中的其他网络。上述第三方可用于本技术解决方案，以协助促进事件处理，并可能通过较小的NPs进行回溯。RID消息传递机制可以是逻辑或物理带外网络，以确保通信安全且不受受攻击网络状态的影响。这两种管理方法将满足大型核动力源对其网络进行全面管理的需要，对于缺乏必要人力资源来执行事故处理操作的小型核动力源，可采用第三方方案。第一种方法使各个NPs能够让其网络操作人员通过通知和警报系统授权通过其网络对RID通信请求的跟踪或其他必要响应的持续性。用于消息传递的带外逻辑解决方案可以是配置有少量专用于NPs之间RID通信的带宽的永久虚拟电路。
The network used for the communication should consist of out-of-band or protected channels (direct communication links) or encrypted channels dedicated to the transport of RID messages. The communication links would be direct connections between network peers who have agreed-upon use and abuse policies through the use of a consortium. Consortiums might be linked through policy comparisons
用于通信的网络应包括带外或受保护信道（直接通信链路）或专用于传输RID消息的加密信道。通信链路将是通过使用联合体同意使用和滥用政策的网络对等方之间的直接连接。可以通过政策比较将财团联系起来
and additional agreements to form a larger web or iterative network of peers that correlates to the traffic paths available over the larger web of networks. The maintenance of the individual links is the responsibility of the two network peers hosting the link. Contact information, IP addresses of RID systems, and other information must be coordinated between bilateral peers by a consortium and may use existing databases, such as the Routing Arbiter. The security, configuration, and Confidence rating schemes of the RID messaging peers must be negotiated by peers and must meet certain overall requirements of the fully connected network (Internet, government, education, etc.) through the peering and/or a consortium-based agreement.
以及额外的协议，以形成一个更大的对等网络或迭代网络，该对等网络与在更大的网络网络上可用的流量路径相关。单个链路的维护由承载该链路的两个网络对等方负责。联系信息、RID系统的IP地址和其他信息必须由联合体在双边对等方之间协调，并且可以使用现有数据库，如路由仲裁器。RID消息传递对等方的安全、配置和信心评级方案必须由对等方协商，并且必须通过对等和/或基于联盟的协议满足完全连接网络（互联网、政府、教育等）的某些总体要求。
RID messaging established with clients of an NP may be negotiated in a contract as part of a value-added service or through a service level agreement (SLA). Further discussion is beyond the scope of this document and may be more appropriately handled in network peering or service level agreements.
与NP客户端建立的RID消息传递可以作为增值服务的一部分在合同中协商，也可以通过服务级别协议（SLA）协商。进一步的讨论超出了本文档的范围，可以在网络对等协议或服务级别协议中进行更适当的处理。
Procedures for incident handling need to be established and well known by anyone that may be involved in incident response. The procedures should also contain contact information for internal escalation procedures, as well as for external assistance groups such as a CSIRT, CERT Coordination Center (CERT/CC), Global Information Assurance Certification (GIAC), and the FBI or other assisting government organization in the country of the investigation.
需要制定事件处理程序，并让可能参与事件响应的任何人熟知。程序还应包含内部上报程序的联系信息，以及外部援助小组的联系信息，如CSIRT、CERT协调中心（CERT/CC）、全球信息保障认证（GIAC）以及FBI或调查所在国的其他协助政府组织。
In order to implement a messaging mechanism between RID communication systems or IHSs, a standard protocol and format is required to ensure inter-operability between vendors. The messages would have to meet several requirements in order to be meaningful as they traverse multiple networks. RID provides the framework necessary for communication between networks involved in the incident handling, possible traceback, and mitigation of a security incident. Several message types described in Section 4.3 are necessary to facilitate the handling of a security incident. The message types include the Report, IncidentQuery, TraceRequest, RequestAuthorization, Result, and the Investigation request message. The Report message is used when an incident is to be filed on a RID system or associated database, where no further action is required. An IncidentQuery message is used to request information on a particular incident. A TraceRequest message is used when the source of the traffic may have been spoofed. In that case, each network provider in the upstream path who receives a TraceRequest will issue a trace across the network to determine the upstream source of the traffic. The RequestAuthorization and Result messages are used to communicate the
为了在RID通信系统或IHS之间实现消息传递机制，需要标准协议和格式来确保供应商之间的互操作性。消息必须满足几个要求，才能在穿越多个网络时具有意义。RID为参与事件处理、可能的回溯和安全事件缓解的网络之间的通信提供了必要的框架。第4.3节中描述的几种消息类型对于促进安全事件的处理是必要的。消息类型包括报告、IncidentQuery、TraceRequest、RequestAuthorization、结果和调查请求消息。报告消息用于将事件归档到RID系统或相关数据库时，无需进一步操作。IncidentQuery消息用于请求特定事件的信息。当流量源可能已被欺骗时，将使用TraceRequest消息。在这种情况下，接收TraceRequest的上游路径中的每个网络提供商将通过网络发出跟踪，以确定流量的上游来源。RequestAuthorization和Result消息用于与
status and result of a TraceRequest or Investigation request. The Investigation request message would only involve the RID communication systems along the path to the source of the traffic and not the use of network trace systems. The Investigation request leverages the bilateral relationships or a consortium's interconnections to mitigate or stop problematic traffic close to the source. Routes could determine the fastest path to a known source IP address in the case of an Investigation request. A message sent between RID systems for a TraceRequest or an Investigation request to stop traffic at the source through a bordering network would require the information enumerated below:
追踪请求或调查请求的状态和结果。调查请求消息将只涉及到沿通信源路径的RID通信系统，而不涉及使用网络跟踪系统。调查请求利用双边关系或联合体的互连来缓解或停止靠近源头的问题流量。在调查请求的情况下，路由可以确定到已知源IP地址的最快路径。在RID系统之间发送的用于TraceRequest的消息或通过边界网络停止源流量的调查请求需要以下列举的信息：
1. Enough information to enable the network administrators to make a decision about the importance of continuing the trace.
1. 足够的信息使网络管理员能够决定继续跟踪的重要性。
2. The incident or IP packet information needed to carry out the trace or investigation.
2. 执行跟踪或调查所需的事件或IP数据包信息。
3. Contact information of the origin of the RID communication. The contact information could be provided through the Autonomous System Number (ASN) [RFC1930] or Network Information Center (NIC) handle information listed in the Registry for Internet Numbers or other Internet databases.
3. RID通信来源的联系信息。联系信息可以通过自主系统号码（ASN）[RFC1930]或网络信息中心（NIC）处理互联网号码或其他互联网数据库注册表中列出的信息来提供。
4. Network path information to help prevent any routing loops through the network from perpetuating a trace. If a RID system receives a TraceRequest containing its own information in the path, the trace must cease and the RID system should generate an alert to inform the network operations staff that a tracing loop exists.
4. 网络路径信息有助于防止通过网络的任何路由循环永久化跟踪。如果RID系统接收到路径中包含其自身信息的TraceRequest，则跟踪必须停止，RID系统应生成警报，通知网络操作人员存在跟踪循环。
5. A unique identifier for a single attack. This identifier should be used to correlate traces to multiple sources in a DDoS attack.
5. 单个攻击的唯一标识符。此标识符应用于将跟踪与DDoS攻击中的多个源关联起来。
Use of the communication network and the RID protocol must be for pre-approved, authorized purposes only. It is the responsibility of each participating party to adhere to guidelines set forth in both a global use policy for this system and one established through the peering agreements for each bilateral peer or agreed-upon consortium guidelines. The purpose of such policies is to avoid abuse of the system; the policies shall be developed by a consortium of participating entities. The global policy may be dependent on the domain it operates under; for example, a government network or a commercial network such as the Internet would adhere to different guidelines to address the individual concerns. Privacy issues must be considered in public networks such as the Internet. Privacy issues are discussed in the Security Considerations section, along with other requirements that must be agreed upon by participating entities.
通信网络和RID协议的使用必须仅用于预先批准和授权的目的。各参与方有责任遵守本系统的全球使用政策中规定的指南，以及通过各双边对等方的对等协议或商定的联合体指南制定的指南。这些政策的目的是避免滥用该制度；政策应由参与实体的联合体制定。全球政策可能取决于其运营所在的领域；例如，政府网络或商业网络（如互联网）将遵循不同的准则来解决个人问题。在公共网络（如互联网）中必须考虑隐私问题。隐私问题在“安全注意事项”一节中讨论，以及必须由参与实体商定的其他要求。
RID requests must be legitimate security-related incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system would include a request to rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business.
RID请求必须是合法的安全相关事件，不得用于破坏或审查等目的。滥用该系统的一个例子是，要求对合法流量进行评级，以防止用户之间在互联网上共享信息（限制访问在线版本的论文），或限制访问竞争对手的产品，以破坏业务。
The RID system should be configurable to either require user input or automatically continue traces. This feature would enable a network manager to assess the available resources before continuing a trace. A trace initiated from a TraceRequest may cause adverse effects on a network. If the Confidence rating is low, it may not be in the NP's best interest to continue the trace. The Confidence ratings must adhere to the specifications for selecting the percentage used to avoid abuse of the system. TraceRequests must be issued by authorized individuals from the initiating network, set forth in policy guidelines established through peering or SLA.
RID系统应可配置为需要用户输入或自动继续跟踪。此功能使网络管理器能够在继续跟踪之前评估可用资源。从TraceRequest启动的跟踪可能会对网络造成不利影响。如果置信度较低，继续追踪可能不符合NP的最佳利益。置信度评级必须符合选择百分比的规范，以避免滥用系统。跟踪器请求必须由发起网络的授权人员发布，通过对等或SLA制定的政策指南中规定了这一点。
The most basic topology for communicating RID systems would be a direct connection or a bilateral relationship as illustrated below.
RID系统通信的最基本拓扑是直接连接或双边关系，如下所示。
___________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | NP Border | |________|
-------------
___________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | NP Border | |________|
-------------
Figure 1. Direct Peer Topology
图1。直接对等拓扑
Within the consortium model, several topologies might be agreed upon and used. One would leverage bilateral network peering relationships of the members of the consortium. The peers for RID would match that of routing peers, and the logical network borders would be used. This approach may be necessary for an iterative trace where the source is unknown. The model would look like the above diagram; however, there may be an extensive number of interconnections of bilateral relationships formed. Also within a consortium model, it may be useful to establish an integrated mesh of networks to pass RID messages. This may be beneficial when the source address is known, and an interconnection may provide a faster route to reach the closest upstream peer to the source of the attack traffic. An example is illustrated below.
在联合体模型中，可以商定并使用几种拓扑结构。一种是利用联合体成员的双边网络对等关系。RID的对等点将与路由对等点的对等点匹配，并且将使用逻辑网络边界。对于源未知的迭代跟踪，这种方法可能是必要的。该模型如上图所示；然而，双边关系可能会形成大量的相互联系。同样在联合体模型中，建立一个集成的网络网格来传递RID消息可能是有用的。当源地址已知时，这可能是有益的，并且互连可以提供更快的路由以到达攻击流量源最近的上游对等方。下面举例说明。
_______ _______ _______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | NP Border | |_____| | NP Border | |_____|
| ------------- ------------- |
|_______________________________________________________|
_______ _______ _______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | NP Border | |_____| | NP Border | |_____|
| ------------- ------------- |
|_______________________________________________________|
Direct connection to network that is not an immediate network peer
直接连接到非直接网络对等方的网络
Figure 2. Mesh Peer Topology
图2。网状对等拓扑
By using a fully meshed model in a consortium, broadcasting RID requests would be possible, but not advisable. By broadcasting a request, RID peers that may not have carried the attack traffic on their network would be asked to perform a trace for the potential of decreasing the time in which the true source was identified. As a result, many networks would have utilized unnecessary resources for a TraceRequest that may have also been unnecessary.
通过在联合体中使用全网格模型，广播RID请求是可能的，但不可取。通过广播请求，可能未在其网络上承载攻击流量的RID对等方将被要求执行跟踪，以减少识别真实来源的时间。因此，许多网络将利用不必要的资源来进行可能也不必要的TraceRequest。
Section 4.3.2 describes the six RID message types, which are based on the IODEF model [RFC5070]. The messages are generated and received on RID communication systems on the NP's network. The messages may originate from IODEF messages from intrusion detection servers, CSIRTs, analysts, etc. A RID message uses the IODEF framework with the RID extension, which is encapsulated for transport [RFC6046]. Each RID message type, along with an example, is described in the following sections. The IODEF-RID schema is introduced in Section 4.3.3 to support the RID message types in Section 4.3.2.
第4.3.2节描述了六种RID消息类型，它们基于IODEF模型[RFC5070]。消息在NP网络上的RID通信系统上生成和接收。消息可能来自入侵检测服务器、CSIRT、分析师等的IODEF消息。RID消息使用带有RID扩展的IODEF框架，该框架被封装用于传输[RFC6046]。以下各节将介绍每种RID消息类型以及一个示例。第4.3.3节介绍了IODEF-RID模式，以支持第4.3.2节中的RID消息类型。
RID is derived from the IODEF data model and inherits all of the data types defined in the IODEF model. One data type is added by RID: BOOLEAN.
RID派生自IODEF数据模型，并继承IODEF模型中定义的所有数据类型。一种数据类型由RID:BOOLEAN添加。
A boolean value is represented by the BOOLEAN data type.
布尔值由布尔数据类型表示。
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema.
布尔数据类型在模式中实现为“xs:BOOLEAN”[XMLschema]。
The six RID message types follow:
以下是六种RID消息类型：
1. TraceRequest. This message is sent to the RID system next in the upstream trace. It is used to initiate a TraceRequest or to continue a TraceRequest to an upstream network closer to the source address of the origin of the security incident. The TraceRequest would trigger a traceback on the network to locate the source of the attack traffic.
1. 追踪器测试。此消息将发送到上游跟踪中的下一个RID系统。它用于启动TraceRequest或继续对更靠近安全事件源地址的上游网络进行TraceRequest。TraceRequest将在网络上触发回溯，以定位攻击流量的来源。
2. RequestAuthorization. This message is sent to the initiating RID system from each of the upstream NPs' RID systems to provide information on the request status in the current network.
2. 请求授权。该消息从每个上游NPs的RID系统发送到发起RID系统，以提供当前网络中请求状态的信息。
3. Result. This message is sent to the initiating RID system through the network of RID systems in the path of the trace as notification that the source of the attack was located. The Result message is also used to provide the notification of actions taken for an Investigation request.
3. 后果此消息通过跟踪路径中的RID系统网络发送给发起RID系统，作为攻击源所在位置的通知。结果消息还用于提供针对调查请求所采取行动的通知。
4. Investigation. This message type is used when the source of the traffic is believed not to be spoofed. The purpose of the Investigation request message is to leverage the existing peer relationships in order to notify the network provider closest to the source of the valid traffic of a security-related incident for any necessary actions to be taken.
4. 调查当认为流量源未被欺骗时，使用此消息类型。调查请求消息的目的是利用现有的对等关系，以便通知最接近安全相关事件有效通信源的网络提供商，以便采取任何必要的措施。
5. Report. This message is used to report a security incident, for which no action is requested. This may be used for the purpose of correlating attack information by CSIRTs, statistics and trending information, etc.
5. 汇报此消息用于报告未请求任何操作的安全事件。这可用于通过CSIRT、统计和趋势信息等关联攻击信息。
6. IncidentQuery. This message is used to request information about an incident or incident type from a trusted RID system. The response is provided through the Report message.
6. 顺便问一下。此消息用于从受信任的RID系统请求有关事件或事件类型的信息。通过报告消息提供响应。
When a system receives a RID message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the RIDPolicy class. The RIDPolicy class may also be used by the transport protocol to facilitate the communication of security incident data to trace, investigate, query, or report information regarding security incidents.
当系统接收到RID消息时，它必须能够确定消息的类型并相应地解析它。消息类型在RIDPolicy类中指定。传输协议还可以使用RIDPolicy类来促进安全事件数据的通信，以跟踪、调查、查询或报告有关安全事件的信息。
There are three classes included in the RID extension required to facilitate RID communications. The RequestStatus class is used to indicate the approval status of a TraceRequest or Investigation request; the IncidentSource class is used to report whether or not a source was found and to identify the source host(s) or network(s); and the RIDPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used.
RID扩展中包括三个类，用于促进RID通信。RequestStatus类用于指示TraceRequest或调查请求的批准状态；IncidentSource类用于报告是否找到源，并识别源主机或网络；RIDPolicy类提供有关商定策略的信息，并指定正在使用的通信消息的类型。
The RID schema acts as an envelope for the IODEF schema to facilitate RID communications. The intent in maintaining a separate schema and not using the AdditionalData extension of IODEF is the flexibility of sending messages between RID hosts. Since RID is a separate schema that includes the IODEF schema, the RID information acts as an envelope, and then the RIDPolicy class can be easily extracted for use by the transport protocol. The security requirements of sending incident information across the network include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating out this data from the IODEF extension removes the need for decrypting and parsing the entire IODEF and RID document to determine how it should be handled at each RID host.
RID模式充当IODEF模式的信封，以方便RID通信。维护单独的模式而不使用IODEF的附加数据扩展的目的是在RID主机之间发送消息的灵活性。由于RID是包含IODEF模式的单独模式，因此RID信息充当信封，然后可以轻松提取RIDPolicy类以供传输协议使用。通过网络发送事件信息的安全要求包括使用加密。RIDPolicy信息不需要加密，因此将此数据从IODEF扩展中分离出来就无需解密和解析整个IODEF和RID文档，以确定在每个RID主机上应如何处理它。
The purpose of the RIDPolicy class is to specify the message type for the receiving host, facilitate the policy needs of RID, and provide routing information in the form of an IP address of the destination RID system.
RIDPolicy类的目的是指定接收主机的消息类型，方便RID的策略需求，并以目标RID系统的IP地址的形式提供路由信息。
The policy information and guidelines are discussed in Section 6.6. The policy is defined between RID peers and within or between consortiums. The RIDPolicy is meant to be a tool to facilitate the defined policies. This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document.
第6.6节讨论了政策信息和指南。该策略在RID对等方之间以及联盟内部或联盟之间定义。RIDPolicy是一种促进已定义策略的工具。这必须根据客户、同行、联盟和/或地区之间的政策设置使用。必须按照本文件的规定考虑安全性、隐私性和保密性。
The RID schema is defined as follows:
RID模式定义如下：
+------------------+
| RID |
+------------------+
| ANY |
| |<>---{0..1}----[ RIDPolicy ]
| ENUM restriction |
| ENUM type |<>---{0..1}----[ RequestStatus ]
| STRING meaning |
| |<>---{0..1}----[ IncidentSource ]
+------------------+
+------------------+
| RID |
+------------------+
| ANY |
| |<>---{0..1}----[ RIDPolicy ]
| ENUM restriction |
| ENUM type |<>---{0..1}----[ RequestStatus ]
| STRING meaning |
| |<>---{0..1}----[ IncidentSource ]
+------------------+
Figure 3. The RID Schema
图3。RID模式
The aggregate classes that constitute the RID schema in the iodef-rid namespace are as follows:
构成iodef RID命名空间中RID架构的聚合类如下所示：
RIDPolicy
里德政策
Zero or One. The RIDPolicy class is used by all message types to facilitate policy agreements between peers, consortiums, or federations, as well as to properly route messages.
零或一。所有消息类型都使用RIDPolicy类来促进对等方、联合体或联合体之间的策略协议，以及正确路由消息。
RequestStatus
请求状态
Zero or One. The RequestStatus class is used only in RequestAuthorization messages to report back to the originating RID system if the trace will be continued by each RID system that received a TraceRequest in the path to the source of the traffic.
零或一。RequestStatus类仅在RequestAuthorization消息中使用，以向发起的RID系统报告，前提是跟踪将由每个在到流量源的路径中接收到TraceRequest的RID系统继续。
IncidentSource
意外事故源
Zero or One. The IncidentSource class is used in the Result message only. The IncidentSource provides the information on the identified source host or network of an attack trace or investigation.
零或一。IncidentSource类仅在结果消息中使用。IncidentSource提供了有关攻击跟踪或调查的已识别源主机或网络的信息。
Each of the three listed classes may be the only class included in the RID class, hence the option for zero or one. In some cases, RIDPolicy MAY be the only class in the RID definition when used by the transport protocol [RFC6046], as that information should be as small as possible and may not be encrypted. The RequestStatus message MUST be able to stand alone without the need for an IODEF document to facilitate the communication, limiting the data transported to the required elements per [RFC6046].
列出的三个类中的每一个都可能是RID类中包含的唯一类，因此可以选择0或1。在某些情况下，当由传输协议[RFC6046]使用时，RIDPolicy可能是RID定义中的唯一类，因为该信息应尽可能小，并且可能不会被加密。RequestStatus消息必须能够独立运行，而不需要IODEF文档来促进通信，并根据[RFC6046]将数据传输到所需的元素。
The RequestStatus class is an aggregate class in the RID class.
RequestStatus类是RID类中的聚合类。
+--------------------------------+
| RequestStatus |
+--------------------------------+
| |
| ENUM restriction |
| ENUM AuthorizationStatus |
| ENUM Justification |
| STRING ext-AuthorizationStatus |
| STRING ext-Justification |
| |
+--------------------------------+
+--------------------------------+
| RequestStatus |
+--------------------------------+
| |
| ENUM restriction |
| ENUM AuthorizationStatus |
| ENUM Justification |
| STRING ext-AuthorizationStatus |
| STRING ext-Justification |
| |
+--------------------------------+
Figure 4. The RequestStatus Class
图4。RequestStatus类
The RequestStatus class has five attributes:
RequestStatus类有五个属性：
restriction
限制规定
OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
可选择的枚举。此属性表示发件人希望收件人遵守的披露准则。本指南不提供任何真正的安全性，因为它是由文档收件人选择的。此属性遵循与IODEF中使用的“限制”相同的准则。
AuthorizationStatus
授权状态
REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a TraceRequest in the current network.
必修的。枚举。列出的值用于响应当前网络中TraceRequest状态的请求CSIRT。
1. Approved. The trace was approved and will begin in the current NP.
1. 经核准的。跟踪已批准，将在当前NP中开始。
2. Denied. The trace was denied in the current NP. The next closest NP can use this message to filter traffic from the upstream NP using the example packet to help mitigate the effects of the attack as close to the source as possible. The RequestAuthorization message must be passed back to the originator and a Result message used from the closest NP to the source to indicate actions taken in the IODEF History class.
2. 否认。当前NP中的跟踪被拒绝。下一个最近的NP可以使用该消息，使用示例数据包过滤来自上游NP的流量，以帮助在尽可能靠近源的地方减轻攻击的影响。RequestAuthorization消息必须传递回发起人，结果消息用于从距离源最近的NP指示在IODEF历史类中采取的操作。
3. Pending. Awaiting approval; a timeout period has been reached, which resulted in this Pending status and RequestAuthorization message being generated.
3. 悬而未决的等待批准；已达到超时时间，导致生成此挂起状态和RequestAuthorization消息。
4. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
4. 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
Justification
正当理由
OPTIONAL. ENUM. Provides a reason for a Denied or Pending message.
可选择的枚举。提供拒绝或挂起消息的原因。
1. SystemResource. A resource issue exists on the systems that would be involved in the request.
1. 系统资源。请求中涉及的系统上存在资源问题。
2. Authentication. The enveloped digital signature [RFC3275] failed to validate.
2. 认证。封装的数字签名[RFC3275]无法验证。
3. AuthenticationOrigin. The detached digital signature for the original requestor on the IP packet failed to validate.
3. 认证来源。IP数据包上原始请求者的分离数字签名无法验证。
4. Encryption. Unable to decrypt the request.
4. 加密。无法解密该请求。
5. Other. There were other reasons this request could not be processed.
5. 另外无法处理此请求还有其他原因。
6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
6. 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
AuthorizationStatus-ext
授权状态分机
OPTIONAL. STRING. A means by which to extend the AuthorizationStatus attribute. See IODEF [RFC5070], Section 5.1.
可选择的一串扩展AuthorizationStatus属性的方法。见IODEF[RFC5070]，第5.1节。
Justification-ext
理由分机
OPTIONAL. STRING. A means by which to extend the Justification attribute. See IODEF [RFC5070], Section 5.1.
可选择的一串扩展“对正”属性的方法。见IODEF[RFC5070]，第5.1节。
The IncidentSource class is an aggregate class in the RID class.
IncidentSource类是RID类中的聚合类。
+-------------------+
| IncidentSource |
+-------------------+
| |
| ENUM restriction |
| |<>-------------[ SourceFound ]
| |
| |<>---{0..*}----[ Node ]
| |
+-------------------+
+-------------------+
| IncidentSource |
+-------------------+
| |
| ENUM restriction |
| |<>-------------[ SourceFound ]
| |
| |<>---{0..*}----[ Node ]
| |
+-------------------+
Figure 5. The IncidentSource Class
图5。IncidentSource类
The elements that constitute the IncidentSource class follow:
构成IncidentSource类的元素如下：
SourceFound
资源发现
One. BOOLEAN. The Source class indicates if a source was identified. If the source was identified, it is listed in the Node element of this class.
一布尔型。Source类指示是否标识了源。如果标识了源，则它将列在此类的节点元素中。
True. Source of incident was identified. False. Source of incident was not identified.
符合事实的确定了事件的来源。错误的事件来源尚未确定。
Node
节点
One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages.
一Node类用于标识主机或网络设备，在本例中用于标识传递RID消息的系统。
The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16.
此类的基本定义从IODEF规范[RFC5070]第3.16节中重新使用。
The IncidentSource class has one attribute:
IncidentSource类有一个属性：
restriction
限制规定
OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
可选择的枚举。此属性表示发件人希望收件人遵守的披露准则。本指南不提供任何真正的安全性，因为它是由文档收件人选择的。此属性遵循与IODEF中使用的“限制”相同的准则。
The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6046].
RIDPolicy类有助于RID消息的传递，并且在传输文档[RFC6046]中也被用于传输。
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
+------------------------+
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
+------------------------+
Figure 6. The RIDPolicy Class
图6。RIDPolicy类
The aggregate elements that constitute the RIDPolicy class are as follows:
构成RIDPolicy类的聚合元素如下所示：
Node
节点
One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages.
一Node类用于标识主机或网络设备，在本例中用于标识传递RID消息的系统。
The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16.
此类的基本定义从IODEF规范[RFC5070]第3.16节中重新使用。
IncidentID
包含
Zero or one. Global reference pointing back to the IncidentID defined in the IODEF data model. The IncidentID includes the name of the CSIRT, an incident number, and an instance of that incident. The instance number is appended with a dash separating the values and is used in cases for which it may be desirable to group incidents. Examples of incidents that may be grouped would be botnets, DDoS attacks, multiple hops of compromised systems found during an investigation, etc.
零或一。全局引用，指向IODEF数据模型中定义的Incided。IncidentID包括CSIRT的名称、事件编号和该事件的实例。实例编号附加有分隔值的破折号，用于可能需要对事件进行分组的情况。可分组的事件示例包括僵尸网络、DDoS攻击、调查期间发现的受损系统的多跳等。
PolicyRegion
政策区
One or many. REQUIRED. The values for the attribute "region" are used to determine what policy area may require consideration before a trace can be approved. The PolicyRegion may include
一个或多个。必修的。属性“region”的值用于确定在批准跟踪之前可能需要考虑的策略领域。政策区域可能包括
multiple selections from the attribute list in order to fit all possible policy considerations when crossing regions, consortiums, or networks.
从属性列表中进行多项选择，以便在跨越区域、联盟或网络时满足所有可能的策略考虑。
region
区域
One. ENUM.
一枚举。
1. ClientToNP. An enterprise network initiated the request.
1. 克林顿。企业网络发起了该请求。
2. NPToClient. An NP passed a RID request to a client or an enterprise attached network to the NP based on the service level agreements.
2. NPToClient。NP根据服务级别协议将RID请求传递给客户端或企业连接网络。
3. IntraConsortium. A trace that should have no restrictions within the boundaries of a consortium with the agreed-upon use and abuse guidelines.
3. 皮质内。按照约定的使用和滥用指南，在联合体边界内不应有任何限制的痕迹。
4. PeerToPeer. A trace that should have no restrictions between two peers but may require further evaluation before continuance beyond that point with the agreed-upon use and abuse guidelines.
4. PeerToPeer。在两个对等点之间不应有任何限制，但可能需要进一步评估，然后根据商定的使用和滥用指南继续进行。
5. BetweenConsortiums. A trace that should have no restrictions between consortiums that have established agreed-upon use and abuse guidelines.
5. 在球团之间。在已制定一致使用和滥用指南的联盟之间不应有任何限制的追踪。
6. AcrossNationalBoundaries. This selection must be set if the trace type is anything but a trace of attack traffic with malicious intent. This must also be set if the traffic request is based upon regulations of a specific nation that would not apply to all nations. This is different from the "BetweenConsortiums" setting since it may be possible to have multiple nations as members of the same consortium, and this option must be selected if the traffic is of a type that may have different restrictions in other nations.
6. 跨越国界。如果跟踪类型不是恶意攻击流量的跟踪，则必须设置此选择。如果交通请求基于某个特定国家的法规，而该法规不适用于所有国家，则也必须设置此项。这与“团体间”设置不同，因为可能有多个国家作为同一财团的成员，如果交通类型可能在其他国家有不同的限制，则必须选择此选项。
7. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
7. 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
TrafficType
流量类型
One or many. REQUIRED. The values for the attribute "type" are meant to assist in determining if a trace is appropriate for the NP receiving the request to continue the trace. Multiple values may be selected for this element; however, where possible, it should be restricted to one value that would most accurately describe the traffic type.
一个或多个。必修的。属性“type”的值用于帮助确定跟踪是否适合接收继续跟踪请求的NP。可为该元素选择多个值；但是，在可能的情况下，应将其限制为最准确描述交通类型的一个值。
type
类型
One. ENUM.
一枚举。
1. Attack. This option should only be selected if the traffic is related to a network-based attack. The type of attack MUST also be listed in more detail in the IODEF Method and Impact classes for further clarification to assist in determining if the trace can be continued ([RFC5070], Sections 3.9 and 3.10.1).
1. 袭击仅当流量与基于网络的攻击相关时，才应选择此选项。攻击类型还必须在IODEF方法和影响等级中更详细地列出，以便进一步澄清，以帮助确定是否可以继续跟踪（[RFC5070]，第3.9节和第3.10.1节）。
2. Network. This option MUST only be selected when the trace is related to NP network traffic or routing issues.
2. 网络只有当跟踪与NP网络流量或路由问题相关时，才必须选择此选项。
3. Content. This category MUST be used only in the case in which the request is related to the content and regional restrictions on accessing that type of content exist. This is not malicious traffic but may include determining what sources or destinations accessed certain materials available on the Internet, including, but not limited to, news, technology, or inappropriate content.
3. 所容纳之物只有在请求与内容相关且存在访问该类型内容的区域限制的情况下，才能使用该类别。这不是恶意流量，但可能包括确定哪些来源或目的地访问了互联网上的某些可用材料，包括但不限于新闻、技术或不适当的内容。
4. OfficialBusiness. This option MUST be used if the traffic being traced is requested or is affiliated with any government or other official business request. This would be used during an investigation by government authorities or other government traces to track suspected criminal or other activities.
4. 官方事务。如果所跟踪的流量被请求或与任何政府或其他官方业务请求相关，则必须使用此选项。这将在政府当局调查或其他政府追踪过程中用于追踪可疑的犯罪或其他活动。
5. Other. If this option is selected, a description of the traffic type MUST be provided so that policy decisions can be made to continue or stop the trace. The information should be provided in the IODEF message in the Expectation class or in the History class using a HistoryItem log.
5. 另外如果选择此选项，则必须提供通信量类型的说明，以便做出继续或停止跟踪的策略决策。应该在Expectation类或History类的IODEF消息中使用HistoryItem日志提供信息。
6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
6. 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
The RIDPolicy class has five attributes:
RIDPolicy类有五个属性：
restriction
限制规定
OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
可选择的枚举。此属性表示发件人希望收件人遵守的披露准则。本指南不提供任何真正的安全性，因为它是由文档收件人选择的。此属性遵循与IODEF中使用的“限制”相同的准则。
MsgType
MSG类型
REQUIRED. ENUM. The type of RID message sent. The six types of messages are described in Section 4.3.2 and can be noted as one of the six selections below.
必修的。枚举。发送的RID消息的类型。第4.3.2节中描述了六种类型的消息，可作为以下六种选择之一加以说明。
1. TraceRequest. This message may be used to initiate a TraceRequest or to continue a TraceRequest to an upstream network closer to the source address of the origin of the security incident.
1. 追踪器测试。该消息可用于发起追踪请求或继续追踪到更靠近安全事件源地址的上游网络。
2. RequestAuthorization. This message is sent to the initiating RID system from each of the upstream RID systems to provide information on the request status in the current network.
2. 请求授权。此消息从每个上游RID系统发送到发起RID系统，以提供当前网络中请求状态的信息。
3. Result. This message indicates that the source of the attack was located and the message is sent to the initiating RID system through the RID systems in the path of the trace.
3. 后果此消息表示攻击源已定位，并通过跟踪路径中的RID系统将消息发送到发起RID系统。
4. Investigation. This message type is used when the source of the traffic is believed to be valid. The purpose of the Investigation request is to leverage the existing peer or consortium relationships in order to notify the NP closest to the source of the valid traffic that some event occurred, which may be a security-related incident.
4. 调查当认为流量源有效时，使用此消息类型。调查请求的目的是利用现有的对等或联盟关系，以便通知最接近有效流量来源的NP发生了一些事件，可能是安全相关事件。
5. Report. This message is used to report a security incident, for which no action is requested in the IODEF Expectation class. This may be used for the purpose of correlating attack information by CSIRTs, statistics and trending information, etc.
5. 汇报此消息用于报告安全事件，在IODEF预期类中不请求任何操作。这可用于通过CSIRT、统计和趋势信息等关联攻击信息。
6. IncidentQuery. This message is used to request information from a trusted RID system about an incident or incident type.
6. 顺便问一下。此消息用于从受信任的RID系统请求有关事件或事件类型的信息。
Additionally, there is an extension attribute to add new enumerated values:
此外，还有一个扩展属性可用于添加新的枚举值：
- ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
- 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
MsgDestination
MsgDestination
REQUIRED. ENUM. The destination required at this level may either be the RID messaging system intended to receive the request, or, in the case of an Investigation request, the source of the incident. In the case of an Investigation request, the RID system that can help stop or mitigate the traffic may not be known, and the message may have to traverse RID messaging systems by following the routing path to the RID system closest to the source of the attack traffic. The Node element lists either the RID system or the IP address of the source, and the meaning of the value in the Node element is determined by the MsgDestination element.
必修的。枚举。该级别所需的目的地可以是用于接收请求的RID消息传递系统，或者在调查请求的情况下，可以是事件源。在调查请求的情况下，可能不知道可以帮助停止或缓解流量的RID系统，并且消息可能必须通过遵循到最接近攻击流量源的RID系统的路由路径来穿越RID消息传递系统。Node元素列出RID系统或源的IP地址，Node元素中值的含义由msgdestation元素确定。
1. RIDSystem. The address listed in the Node element of the RIDPolicy class is the next upstream RID system that will receive the RID message.
1. RIDSystem。RIDPolicy类的Node元素中列出的地址是将接收RID消息的下一个上游RID系统。
2. SourceOfIncident. The address listed in the Node element of the RIDPolicy class is the incident source. The IP address is used to determine the path of RID systems that will be used to find the closest RID system to the source of an attack in which the IP address used by the source is believed to be valid and an Investigation request message is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial trace or Investigation request, not the source used in a Result message.
2. 事故的根源。RIDPolicy类的Node元素中列出的地址是事件源。IP地址用于确定RID系统的路径，该路径将用于查找距离攻击源最近的RID系统，其中源使用的IP地址被认为是有效的，并且使用了调查请求消息。不要将其与IncidentSource类混淆，因为此处定义的值来自初始跟踪或调查请求，而不是结果消息中使用的源。
3. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
3. 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
MsgType-ext
MsgType ext
OPTIONAL. STRING. A means by which to extend the MsgType attribute. See IODEF [RFC5070], Section 5.1.
可选择的一串扩展MsgType属性的方法。见IODEF[RFC5070]，第5.1节。
MsgDestination-ext
MsgDestination ext
OPTIONAL. STRING. A means by which to extend the MsgDestination attribute. See IODEF [RFC5070], Section 5.1.
可选择的一串扩展MsgDestination属性的方法。见IODEF[RFC5070]，第5.1节。
The RID schema declares a namespace of "iodef-rid-1.0" and registers it per [XMLnames]. Each IODEF-RID document MUST use the "iodef-rid-1.0" namespace in the top-level element RID-Document. It can be referenced as follows:
RID模式声明了一个名称空间“iodef-RID-1.0”，并按照[XMLnames]注册它。每个IODEF-RID文档必须在顶级元素RID文档中使用“IODEF-RID-1.0”命名空间。可参考如下：
<RID-Document
version="1.00" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.0.xsd">
<RID-Document
version="1.00" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.0.xsd">
The IODEF model is followed as specified in [RFC5070] for each of the RID message types. The RID schema is used in combination with IODEF documents to facilitate RID communications. Each message type varies slightly in format and purpose; hence, the requirements vary and are specified for each. All classes, elements, attributes, etc., that are defined in the IODEF-Document are valid in the context of a RID message; however, some listed as optional in IODEF are mandatory for RID as listed for each message type. The IODEF model MUST be fully implemented to ensure proper parsing of all RID messages.
对于每种RID消息类型，遵循[RFC5070]中规定的IODEF模型。RID模式与IODEF文档结合使用，以促进RID通信。每种信息类型的格式和用途略有不同；因此，要求各不相同，并针对每种要求进行了规定。IODEF文档中定义的所有类、元素、属性等在RID消息上下文中有效；但是，在IODEF中列出的一些选项对于RID是必需的，因为每个消息类型都列出了这些选项。必须完全实现IODEF模型，以确保正确解析所有RID消息。
Note: The implementation of the RID system may obtain some of the information needed to fill in the content required for each message type automatically from packet input to the system or default information such as that used in the EventData class.
注意：RID系统的实现可能会从输入到系统的数据包或默认信息（如EventData类中使用的信息）中自动获取填写每种消息类型所需内容所需的一些信息。
Description: This message or document is sent to the network management station next in the upstream trace once the upstream source of the traffic has been identified.
描述：一旦确定了流量的上游来源，此消息或文档将发送到上游跟踪中的下一个网络管理站。
The following information is required for TraceRequest messages and is provided through:
TraceRequest消息需要以下信息，并通过以下方式提供：
RID Information:
RID信息：
RIDPolicy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
IODEF Information:
IODEF信息：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
事件标识符（事件类别，IncidentID）。跟踪编号-用于单个事件的多个跟踪；必须注意。
Confidence rating of security incident (Impact and Confidence class).
安全事件的信心评级（影响和信心等级）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring an upstream TraceRequest in RID.
System类用于列出攻击中使用的源和目标信息，并且必须注意流量是否被欺骗，因此需要RID中的上游TraceRequest。
Expectation class should be used to request any specific actions to be taken close to the source.
应该使用Expectation类来请求在源附近执行任何特定操作。
Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to "infrastructure".
嵌套RID系统的路径信息，从使用类别设置为“infrastructure”的IODEF EventData的跟踪中使用的请求发起人开始。
Event, Record, and RecordItem classes to include example packets and other information related to the incident. Note: Event information included here requires a second instance of EventData in addition to that used to convey NP path contact information.
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息。注意：除了用于传递NP路径联系信息的实例外，此处包含的事件信息还需要第二个EventData实例。
Standards for encryption and digital signatures [RFC3275], [XMLsig]:
加密和数字签名标准[RFC3275]，[XMLsig]：
Digital signature from initiating RID system, passed to all systems in upstream trace using XML digital signature.
来自启动RID系统的数字签名，使用XML数字签名传递到上游跟踪中的所有系统。
A DDoS attack can have many sources, resulting in multiple traces to locate the sources of the attack. It may be valid to continue multiple traces for a single attack. The path information would enable the administrators to determine if the exact trace had already passed through a single network. The Incident Identifier must also be used to identify multiple TraceRequests from a single incident. If a single TraceRequest results in divergent paths of TraceRequests, a separate instance number MUST be used under the same IncidentID. The IncidentID instance number of IODEF can be used to correlate related incident data that is part of a larger incident.
DDoS攻击可以有多个来源，从而产生多个跟踪来定位攻击来源。为一次攻击继续多个跟踪可能是有效的。路径信息将使管理员能够确定确切的跟踪是否已通过单个网络。事件标识符还必须用于识别单个事件中的多个跟踪程序。如果单个TraceRequest导致TraceRequest的路径不同，则必须在同一IncidentID下使用单独的实例号。IODEF的IncidentID实例号可用于关联作为较大事件一部分的相关事件数据。
Description: This message is sent to the initiating RID system from the next upstream NP's RID system to provide information on the request status in the current network.
描述：此消息从下一个上游NP的RID系统发送到发起RID系统，以提供当前网络中请求状态的信息。
The following information is required for RequestAuthorization messages and is provided through:
RequestAuthorization消息需要以下信息，并通过以下方式提供：
RID Information:
RID信息：
RIDPolicy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
Status of TraceRequest RequestStatus class in RID schema
RID架构中TraceRequestStatus类的状态
Standards for encryption and digital signatures [RFC3275], [XMLsig]:
加密和数字签名标准[RFC3275]，[XMLsig]：
Digital signature of responding NP for authenticity of Trace Status Message, from the NP creating this message using XML digital signature.
响应NP的数字签名用于跟踪状态消息的真实性，由NP使用XML数字签名创建此消息。
A message is sent back to the initiating RID system of the trace as status notification. This message verifies that the next RID system in the path has received the message from the previous system in the path. This message also verifies that the trace is now continuing, has stopped, or is pending in the next upstream RID system. The Pending status would be automatically generated after a 2-minute timeout without system-predefined or administrator action taken to approve or disapprove the trace continuance. If a Request is denied, the originator and sending peer (if they are not the same) MUST both receive the message. This enables the sending peer the option to take action to stop or mitigate the traffic as close to the source as possible.
消息作为状态通知发送回跟踪的初始RID系统。此消息验证路径中的下一个RID系统是否已从路径中的上一个系统接收到消息。此消息还验证跟踪是否正在继续、已停止或在下一个上游RID系统中处于挂起状态。挂起状态将在2分钟超时后自动生成，无需系统预定义或管理员采取措施来批准或不批准跟踪连续性。如果请求被拒绝，则发起人和发送对等方（如果不相同）必须同时接收消息。这使发送端可以选择在尽可能靠近源的地方采取措施来停止或缓解流量。
Description: This message indicates that the trace or investigation has been completed and provides the result. The Result message includes information on whether or not a source was found and the source information through the IncidentSource class. The Result information MUST go back to the originating RID system that began the investigation or trace. An NP may use any number of incident handling data sources to ascertain the true source of an attack. All of the possible information sources may or may not be readily tied into the RID communications system.
描述：此消息表示跟踪或调查已完成，并提供结果。结果消息包括有关是否找到源的信息以及IncidentSource类中的源信息。结果信息必须返回到开始调查或跟踪的原始RID系统。NP可以使用任意数量的事件处理数据源来确定攻击的真实来源。所有可能的信息源可能会也可能不会很容易地连接到RID通信系统中。
The following information is required for Result messages and will be provided through:
结果消息需要以下信息，并将通过以下方式提供：
RID Information:
RID信息：
RIDPolicy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
Incident Source The IncidentSource class of the RID schema is used to note if a source was identified and provide the source address(es).
Incident Source RID架构的IncidentSource类用于记录源是否已识别并提供源地址。
IODEF Information:
IODEF信息：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
事件标识符（事件类别，IncidentID）。跟踪编号-用于单个事件的多个跟踪；必须注意。
Confidence rating of security incident (Impact and Confidence class).
安全事件的信心评级（影响和信心等级）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring an upstream TraceRequest in RID.
System类用于列出攻击中使用的源和目标信息，并且必须注意流量是否被欺骗，因此需要RID中的上游TraceRequest。
History class "atype" attribute is used to note any actions taken.
历史类“atype”属性用于记录所采取的任何操作。
History class also notes any other background information including notes about the confidence level or rating of the result information.
历史课还记录任何其他背景信息，包括关于结果信息的置信度或评级的注释。
Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to "infrastructure". The last NP listed is the NP that located the source of the traffic (the NP sending the Result message).
嵌套RID系统的路径信息，从使用类别设置为“infrastructure”的IODEF EventData的跟踪中使用的请求发起人开始。最后列出的NP是定位流量源的NP（发送结果消息的NP）。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional). Note: Event information included here requires a second instance of EventData in addition to that used to convey NP path contact information.
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息（可选）。注意：除了用于传递NP路径联系信息的实例外，此处包含的事件信息还需要第二个EventData实例。
Standards for encryption and digital signatures [RFC3275]:
加密和数字签名标准[RFC3275]：
Digital signature of source NP for authenticity of Result Message, from the NP creating this message using XML digital signature.
源NP的数字签名用于验证结果消息的真实性，由NP使用XML数字签名创建此消息。
A message is sent back to the initiating RID system to notify the associated CSIRT that the source has been located. The actual source information may or may not be included, depending on the policy of the network in which the client or host is attached. Any action taken by the NP to act upon the discovery of the source of a trace should be included. The NP may be able to automate the adjustment of filters at their border router to block outbound access for the machine(s) discovered as a part of the attack. The filters may be comprehensive enough to block all Internet access until the host has taken the appropriate action to resolve any security issues or to rate-limit the ingress traffic as close to the source as possible.
一条消息被发送回发起RID系统，以通知相关联的CSIRT源已定位。实际的源信息可能包括，也可能不包括，这取决于客户端或主机所连接的网络的策略。应包括NP在发现痕迹来源时采取的任何行动。NP可能能够自动调整其边界路由器上的过滤器，以阻止作为攻击一部分发现的机器的出站访问。过滤器可能足够全面，以阻止所有互联网访问，直到主机采取适当措施解决任何安全问题或对尽可能靠近源的入口流量进行分级限制。
Security and privacy considerations discussed in Section 6 MUST be taken into account.
必须考虑第6节中讨论的安全和隐私注意事项。
Note: The History class has been expanded in IODEF to accommodate all of the possible actions taken as a result of a RID TraceRequest or Investigation request using the "iodef:atype", or action type, attribute. The History class should be used to note all actions taken close to the source of a trace or incident using the most appropriate option for the type of action along with a description. The "atype" attribute in the Expectation class can also be used to request an appropriate action when a TraceRequest or Investigation request is made.
注意：History类已在IODEF中展开，以容纳由于RID TraceRequest或调查请求而使用“IODEF:atype”或action type属性所采取的所有可能操作。应使用History类记录在跟踪或事件源附近采取的所有操作，使用操作类型的最合适选项以及描述。Expectation类中的“atype”属性也可用于在发出TraceRequest或调查请求时请求适当的操作。
Description: This message type is used when the source of the traffic is believed not to be spoofed. The purpose of the Investigation request message is to leverage the existing bilateral peer relationships in order to notify the network provider closest to the source of the valid traffic that some event occurred, which may be a security-related incident.
描述：当认为流量源未被欺骗时，使用此消息类型。调查请求消息的目的是利用现有的双边对等关系，以便通知最接近有效流量源的网络提供商发生了某些事件，这可能是安全相关事件。
The following information is required for Investigation request messages and is provided through:
调查请求消息需要以下信息，并通过以下方式提供：
RID Information:
RID信息：
RID Policy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
IODEF Information:
IODEF信息：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
事件标识符（事件类别，IncidentID）。跟踪编号-用于单个事件的多个跟踪；必须注意。
Confidence rating of security incident (Impact and Confidence class).
安全事件的信心评级（影响和信心等级）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring an upstream TraceRequest in RID.
System类用于列出攻击中使用的源和目标信息，并且必须注意流量是否被欺骗，因此需要RID中的上游TraceRequest。
Expectation class should be used to request any specific actions to be taken close to the source.
应该使用Expectation类来请求在源附近执行任何特定操作。
Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to "infrastructure".
嵌套RID系统的路径信息，从使用类别设置为“infrastructure”的IODEF EventData的跟踪中使用的请求发起人开始。
Event, Record, and RecordItem classes to include example packets and other information related to the incident. Note: Event information included here requires a second instance of EventData in addition to that used to convey NP path contact information.
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息。注意：除了用于传递NP路径联系信息的实例外，此处包含的事件信息还需要第二个EventData实例。
Standards for encryption and digital signatures [RFC3275]:
加密和数字签名标准[RFC3275]：
Digital signature from initiating RID system, passed to all systems in upstream trace using XML digital signature.
来自启动RID系统的数字签名，使用XML数字签名传递到上游跟踪中的所有系统。
Security considerations would include the ability to encrypt [XMLencrypt] the contents of the Investigation request message using the public key of the destination RID system. The incident number would increase as if it were a TraceRequest message in order to ensure uniqueness within the system. The relaying peers would also append their Autonomous System (AS) or RID system information as the request message was relayed along the web of network providers so that the Result message could utilize the same path as the set of trust relationships for the return message, thus indicating any actions taken. The request would also be recorded in the state tables of both the initiating and destination NP RID systems. The destination NP is responsible for any actions taken as a result of the request in adherence to any service level agreements or internal policies. The NP should confirm that the traffic actually originated from the suspected system before taking any action and confirm the
安全性考虑因素包括使用目标RID系统的公钥对调查请求消息的内容进行[XMLencrypt]加密的能力。为了确保系统内的唯一性，事件编号将增加，就像它是TraceRequest消息一样。中继对等方还将在请求消息沿着网络提供商的网络中继时附加其自治系统（AS）或RID系统信息，以便结果消息可以利用与返回消息的信任关系集相同的路径，从而指示所采取的任何操作。请求还将记录在发起和目标NP RID系统的状态表中。目标NP负责根据任何服务级别协议或内部策略，因请求而采取的任何行动。NP应在采取任何行动之前确认流量实际上来自可疑系统，并确认
reason for the request. The request may be sent directly to a known RID system or routed by the source address of the attack using the message destination of RIDPolicy, SourceOfIncident.
请求的理由。请求可以直接发送到已知的RID系统，也可以使用RIDPolicy的消息目的地SourceOfIncident通过攻击源地址路由。
Note: All intermediate parties must be able to view RIDPolicy information in order to properly direct RID messages.
注意：所有中间方必须能够查看RID策略信息，以便正确引导RID消息。
Description: This message or document is sent to a RID system to provide a report of a security incident. This message does not require any actions to be taken, except to file the report on the receiving RID system or associated database.
描述：此消息或文档发送到RID系统以提供安全事件报告。此消息不需要执行任何操作，只需要在接收RID系统或相关数据库上归档报告。
The following information is required for Report messages and will be provided through:
报告信息需要以下信息，并将通过以下方式提供：
RID Information:
RID信息：
RID Policy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
The following data is recommended if available and can be provided through:
如果可用，建议提供以下数据，并可通过以下方式提供：
IODEF Information:
IODEF信息：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
事件标识符（事件类别，IncidentID）。跟踪编号-用于单个事件的多个跟踪；必须注意。
Confidence rating of security incident (Impact and Confidence class).
安全事件的信心评级（影响和信心等级）。
System class is used to list both the Source and Destination Information used in the attack.
System类用于列出攻击中使用的源信息和目标信息。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional).
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息（可选）。
Standards for encryption and digital signatures [RFC3275]:
加密和数字签名标准[RFC3275]：
Digital signature from initiating RID system, passed to all systems receiving the report using XML digital signature.
来自启动RID系统的数字签名，使用XML数字签名传递给接收报告的所有系统。
Security considerations would include the ability to encrypt [XMLencrypt] the contents of the Report message using the public key of the destination RID system. Senders of a Report message should note that the information may be used to correlate security incident information for the purpose of trending, pattern detection, etc., and may be shared with other parties unless otherwise agreed upon with the receiving RID system. Therefore, sending parties of a Report message may obfuscate or remove destination addresses or other sensitive information before sending a Report message. A Report message may be sent either to file an incident report or in response to an IncidentQuery, and data sensitivity must be considered in both cases. The NP path information is not necessary for this message, as it will be communicated directly between two trusted RID systems.
安全性考虑因素包括使用目标RID系统的公钥对报告消息的内容进行[XMLencrypt]加密的能力。报告消息的发送者应注意，该信息可用于关联安全事件信息，以便进行趋势分析、模式检测等，并可与其他方共享，除非与接收RID系统另有约定。因此，报告消息的发送方可能会在发送报告消息之前混淆或删除目标地址或其他敏感信息。可以发送报告消息来提交事件报告或响应意外查询，在这两种情况下都必须考虑数据敏感性。此消息不需要NP路径信息，因为它将在两个受信任的RID系统之间直接通信。
Description: The IncidentQuery message is used to request incident information from a trusted RID system. The request can include the incident number, if known, or detailed information about the incident. If the incident number is known, the Report message containing the incident information can easily be returned to the trusted requestor using automated methods. If an example packet or other unique information is included in the IncidentQuery, the return report may be automated; otherwise, analyst intervention may be required.
描述：IncidentQuery消息用于从受信任的RID系统请求事件信息。请求可以包括事件编号（如果已知）或事件的详细信息。如果已知事件编号，则可以使用自动方法将包含事件信息的报告消息轻松返回给受信任的请求者。如果附带查询中包括示例数据包或其他唯一信息，则返回报告可以是自动的；否则，可能需要分析师干预。
The following information must be used for an IncidentQuery message and is provided through:
以下信息必须用于IncidentQuery消息，并通过以下方式提供：
RID Information:
RID信息：
RID Policy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
IODEF Information (optional):
IODEF信息（可选）：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
事件标识符（事件类别，IncidentID）。跟踪编号-用于单个事件的多个跟踪；必须注意。
Confidence rating of security incident (Impact and Confidence class).
安全事件的信心评级（影响和信心等级）。
System class is used to list both the Source and Destination Information used in the attack.
System类用于列出攻击中使用的源信息和目标信息。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional).
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息（可选）。
Standards for encryption and digital signatures [RFC3275]:
加密和数字签名标准[RFC3275]：
Digital signature from initiating RID system, passed to all systems receiving the IncidentQuery using XML digital signature. If a packet is not included, the signature may be based on the RIDPolicy class.
来自启动RID系统的数字签名，使用XML数字签名传递给接收IncidentQuery的所有系统。如果不包括数据包，则签名可以基于RIDPolicy类。
The proper response to the IncidentQuery message is a Report message. Multiple incidents may be returned for a single query if an incident type is requested. In this case, the receiving system would send an IODEF document containing multiple incidents or all instances of an incident. The system sending the reply may pre-set a limit to the number of documents returned in one report. The recommended limit is 5, to prevent the documents from becoming too large. Other transfer methods may be suited better than RID for large transfers of data. The Confidence rating may be used in the IncidentQuery message to select only incidents with an equal or higher Confidence rating than what is specified. This may be used for cases when information is gathered on a type of incident but not on specifics about a single incident. Source and Destination Information may not be needed if the IncidentQuery is intended to gather data about a specific type of incident as well.
对IncidentQuery消息的正确响应是报告消息。如果请求事件类型，则单个查询可能会返回多个事件。在这种情况下，接收系统将发送包含多个事件或事件的所有实例的IODEF文档。发送回复的系统可能会对一份报告中返回的文档数量预先设置限制。建议的限制为5，以防止文档过大。对于大型数据传输，其他传输方法可能比RID更适合。信心评级可在IncidentQuery消息中用于仅选择信心评级等于或高于指定值的事件。这可用于收集某类事件的信息，但不收集单个事件的具体信息的情况。如果IncidentQuery旨在收集关于特定类型事件的数据，则可能不需要源和目标信息。
The following section outlines the communication flows for RID and also provides examples of messages. The proper response to a TraceRequest is a RequestAuthorization message. The RequestAuthorization message lets the requestor know if the trace will continue through the next upstream network. If there is a problem with the request, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message MUST be sent to the requestor and the downstream peer (if they are not one and the same) providing the reason why the message could not be processed. Assuming that the trace continued, additional TraceRequests with the response of a RequestAuthorization message would occur passing the request upstream in the path to the source of the traffic related to the incident. Once a source is found, a Result message is sent to the originator of the trace, as determined by the NP path information provided through the document instance of EventData, where contact is set to "infrastructure". The NP path information is also used when sending the RequestAuthorization messages to the first entry (the trace originator) and the last nested entry (the downstream peer). The Result message is encrypted
下一节概述RID的通信流，并提供消息示例。对TraceRequest的正确响应是RequestAuthorization消息。RequestAuthorization消息让请求者知道跟踪是否将继续通过下一个上游网络。如果请求存在问题，例如验证数字签名或解密请求失败，则必须向请求者和下游对等方（如果它们不是一个且不相同）发送RequestAuthorization消息，提供无法处理消息的原因。假设跟踪继续进行，则会出现带有RequestAuthorization消息响应的其他TraceRequest，将请求在路径上游传递到与事件相关的流量源。一旦找到源，结果消息将发送给跟踪的发起人，由EventData文档实例提供的NP路径信息确定，其中contact设置为“infrastructure”。将RequestAuthorization消息发送到第一个条目（跟踪发起人）和最后一个嵌套条目（下游对等方）时，也会使用NP路径信息。结果消息是加密的
[XMLencrypt] for the originator providing information about the incident source and any actions taken. If the originator fails to decrypt or authenticate the Result message, a RequestAuthorization message is sent in response; otherwise, no return message is sent. If a RequestAuthorization message is sent with the RequestStatus set to Denied, a downstream peer receiving this message may choose to take action to stop or mitigate the traffic at that point in the network, as close to the source as possible. If the downstream peer chooses this option, it would send a Result message to the trace originator.
[XMLencrypt]用于提供有关事件源和所采取任何行动的信息的发起人。如果发端人未能解密或验证结果消息，则发送RequestAuthorization消息作为响应；否则，不会发送返回消息。如果发送RequestAuthorization消息时RequestStatus设置为Denied，则接收该消息的下游对等方可以选择在网络中尽可能靠近源的该点处采取措施停止或缓解流量。如果下游对等方选择此选项，它将向跟踪发起方发送结果消息。
Note: For each example listed below, [RFC5735] addresses were used. Assume that each IP address listed is actually a separate network range held by different NPs. Addresses were used from /27 network ranges.
注：对于下面列出的每个示例，使用了[RFC5735]地址。假设列出的每个IP地址实际上是由不同的NPs持有的一个单独的网络范围。使用的地址来自/27个网络范围。
The diagram below outlines the RID TraceRequest communication flow between RID systems on different networks tracing an attack.
下图概述了追踪攻击的不同网络上RID系统之间的RID TraceRequest通信流。
Attack Dest NP-1 NP-2 NP-3 Attack Src
攻击目标NP-1 NP-2 NP-3攻击Src
1. Attack | Attack reported | detected
1. 攻击|报告攻击|检测到
2. Initiate trace
2. 启动跟踪
3. Locate origin through upstream NP
3. 通过上游NP定位原点
4. o---TraceRequest----->
4. o---TraceRequest----->
5. Trace Initiated
5. 跟踪启动
6. <-RequestAuthorization-o
6. <-RequestAuthorization-o
7. Locate origin through upstream NP
7. 通过上游NP定位原点
8. o---TraceRequest--->
8. o---TraceRequest--->
9. Trace Initiated
9. 跟踪启动
10. <----------RequestAuthorization----o
<---RequestAuth---o
10. <----------RequestAuthorization----o
<---RequestAuth---o
11. Locate attack source on network X
11. 在网络X上定位攻击源
12. <------------Result----------------o
12. <------------Result----------------o
Figure 7. TraceRequest Communication Flow
图7。TraceRequest通信流
Before a trace is initiated, the RID system should verify if an instance of the trace or a similar request is not active. The traces may be resource intensive; therefore, providers need to be able to detect potential abuse of the system or unintentional resource drains. Information such as the Source and Destination Information, associated packets, and the incident may be desirable to maintain for a period of time determined by administrators.
在启动跟踪之前，RID系统应验证跟踪实例或类似请求是否未激活。这些痕迹可能是资源密集型的；因此，提供商需要能够检测系统的潜在滥用或无意的资源消耗。诸如源和目的地信息、相关分组和事件的信息可能需要在管理员确定的时间段内保持。
The communication flow demonstrates that a RequestAuthorization message is sent to both the downstream peer and the original requestor. If a TraceRequest is denied, the downstream peer has the option to take an action and respond with a Result message. The originator of the request may follow up with the downstream peer of the NP involved using an Investigation request to ensure that an action is taken if no response is received. Nothing precludes the originator of the request from initiating a new TraceRequest bypassing the NP that denied the request, if a trace is needed beyond that point. Another option may be for the initiator to send an Investigation request to an NP upstream of the NP that denied the request if enough information was gathered to discern the true source of the attack traffic from the incident handling information.
通信流表明RequestAuthorization消息被发送到下游对等方和原始请求方。如果TraceRequest被拒绝，则下游对等方可以选择采取操作并使用结果消息进行响应。请求的发起人可使用调查请求与所涉NP的下游对等方跟进，以确保在未收到响应时采取行动。如果需要超过该点的跟踪，则不排除请求的发起人绕过拒绝请求的NP发起新的TraceRequest。另一种选择是，如果收集了足够的信息以从事件处理信息中辨别攻击流量的真实来源，则发起方可以向拒绝请求的NP上游的NP发送调查请求。
The example listed is of a TraceRequest based on the incident report example from the IODEF document. The RID extension classes were included as appropriate for a TraceRequest message using the RIDPolicy class. The example given is that of a CSIRT reporting a DoS attack in progress to the upstream NP. The request asks the next NP to continue the trace and have the traffic mitigated closer to the source of the traffic.
所列示例是基于IODEF文档中的事件报告示例的TraceRequest示例。对于使用RIDPolicy类的TraceRequest消息，适当地包含了RID扩展类。给出的示例是CSIRT向上游NP报告正在进行的DoS攻击。该请求要求下一个NP继续跟踪，并在靠近流量源的地方缓解流量。
In the following example, use of [XMLsig] to generate digital signatures does not currently provide digest algorithm agility, as [XMLsig] only supports SHA-1. A future version of [XMLsig] may support additional digest algorithms to support digest algorithm agility.
在下面的示例中，使用[XMLsig]生成数字签名目前不能提供摘要算法灵活性，因为[XMLsig]只支持SHA-1。[XMLsig]的未来版本可能支持其他摘要算法，以支持摘要算法的灵活性。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="TraceRequest"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="TraceRequest"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>38765</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>38765</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2001-09-14T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream NP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2001-09-14T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream NP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<!-- Digital signature accompanied by above RID and IODEF -->
<!-- Digital signature accompanied by above RID and IODEF -->
<Envelope xmlns="urn:envelope"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0">
<iodef:IODEF-Document>
<iodef:Incident>
<iodef:EventData>
<iodef:Record>
<iodef:RecordData>
<iodef:RecordItem type="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
</iodef:Incident>
</iodef:IODEF-Document>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315#WithComments"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm=
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>KiI5+6SnFAs429VNwsoJjHPplmo=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg==
</SignatureValue>
<Envelope xmlns="urn:envelope"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0">
<iodef:IODEF-Document>
<iodef:Incident>
<iodef:EventData>
<iodef:Record>
<iodef:RecordData>
<iodef:RecordItem type="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
</iodef:Incident>
</iodef:IODEF-Document>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315#WithComments"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm=
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>KiI5+6SnFAs429VNwsoJjHPplmo=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg==
</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j
QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5
Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs
HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</Envelope>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j
QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5
Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs
HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</Envelope>
The example RequestAuthorization message is in response to the TraceRequest message listed above. The NP that received the request is responding to approve the trace continuance in their network.
示例RequestAuthorization消息响应上面列出的TraceRequest消息。收到请求的NP正在响应批准其网络中的跟踪连续性。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID>
The example Result message is in response to the TraceRequest listed above. This message type only comes after a RequestAuthorization within the TraceRequest flow of messages. It may be a direct response to an Investigation request. This message provides information about the source of the attack and the actions taken to mitigate the traffic.
示例结果消息是对上面列出的TraceRequest的响应。此消息类型仅在TraceRequest消息流中的RequestAuthorization之后出现。这可能是对调查请求的直接回应。此消息提供有关攻击源以及为缓解流量而采取的措施的信息。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Result"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node>
</iodef-rid:IncidentSource>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Result"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node>
</iodef-rid:IncidentSource>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Admin-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Admin-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.3
</iodef:ContactName>
<iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
</iodef:EventData>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>38765</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.3
</iodef:ContactName>
<iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
</iodef:EventData>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>38765</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream NP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-NP3">
CSIRT-FOR-NP3#3291-1
</iodef:IncidentID>
<iodef:Description>
Host rate-limited for 24 hours
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream NP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-NP3">
CSIRT-FOR-NP3#3291-1
</iodef:IncidentID>
<iodef:Description>
Host rate-limited for 24 hours
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
The diagram below outlines the RID Investigation request communication flow between RID systems on different networks for a security incident with a known source address. The proper response to an Investigation request is a Result message. If there is a
下图概述了具有已知源地址的安全事件在不同网络上的RID系统之间的RID调查请求通信流。对调查请求的正确响应是结果消息。如果有
problem with the request, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed.
请求出现问题，例如无法验证数字签名或解密请求，将向请求者发送请求授权消息。RequestAuthorization消息应提供无法处理消息的原因。
Attack Dest NP-1 NP-2 Attack Src
攻击目标NP-1 NP-2攻击Src
1. Attack | Attack reported | detected
1. 攻击|报告攻击|检测到
2. Determine source of security incident
2. 确定安全事件的来源
3. o---Investigation---->
3. o--调查-->
4. Research incident and determine appropriate actions to take
4. 调查事件并确定要采取的适当措施
5. <-------Result-------o
5. <-------Result-------o
Figure 8. Investigation Communication Flow
图8。通信流研究
The following example only includes the RID-specific details. The IODEF and security measures are similar to the TraceRequest information, with the exception that the source is known and the receiving RID system is known to be close to the source. The source known is indicated in the IODEF document, which allows for incident sources to be listed as spoofed, if appropriate.
以下示例仅包括RID特定的详细信息。IODEF和安全措施与TraceRequest信息类似，但已知源和接收RID系统靠近源的情况除外。IODEF文件中指出了已知的来源，如果合适，允许将事件来源列为伪造来源。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Investigation"
MsgDestination="SourceOfIncident">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Investigation"
MsgDestination="SourceOfIncident">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="other">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="recon"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>41421</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="investigate">
<iodef:Description>
Investigate whether source has been compromised
</iodef:Description>
</iodef:Expectation>
</iodef:EventData>
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="other">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="recon"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>41421</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="investigate">
<iodef:Description>
Investigate whether source has been compromised
</iodef:Description>
</iodef:Expectation>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:Description>
Investigation request sent to NP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:Description>
Investigation request sent to NP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
The example RequestAuthorization message is in response to the Investigation request listed above. The NP that received the request was unable to validate the digital signature used to authenticate the sending RID system.
示例RequestAuthorization消息响应上面列出的调查请求。接收请求的NP无法验证用于验证发送RID系统的数字签名。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Denied"
Justification="Authentication"/>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Denied"
Justification="Authentication"/>
</iodef-rid:RID>
The diagram below outlines the RID Report communication flow between RID systems on different networks.
下图概述了不同网络上RID系统之间的RID报告通信流。
NP-1 NP-2
NP-1 NP-2
1. Generate incident information and prepare Report message
1. 生成事件信息并准备报告消息
2. o-------Report------->
2. o------报告------->
3. File report in database
3. 数据库中的文件报告
Figure 9. Report Communication Flow
图9。报告通信流
The Report communication flow is used to provide information on specific incidents detected on the network. Incident information may be shared between CSIRTs or participating RID hosts using this format. When a report is received, the RID system must verify that the report has not already been filed. The incident number and incident data, such as the hexadecimal packet and incident class information, can be used to compare with existing database entries. The Report message typically does not have a response. If there is a problem with the Report message, such as a failure to validate the digital signature [RFC3275] or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed.
报告通信流用于提供有关在网络上检测到的特定事件的信息。可以使用此格式在CSIRT或参与的RID主机之间共享事件信息。收到报告后，RID系统必须验证报告是否尚未归档。事件编号和事件数据（如十六进制数据包和事件类信息）可用于与现有数据库条目进行比较。报告消息通常没有响应。如果报告消息存在问题，例如验证数字签名[RFC3275]或解密请求失败，则向请求者发送请求授权消息。RequestAuthorization消息应提供无法处理消息的原因。
The following example only includes the RID-specific details. This report is an unsolicited Report message that includes an IPv4 packet. The IODEF document and digital signature would be similar to the TraceRequest information.
以下示例仅包括RID特定的详细信息。此报告是包含IPv4数据包的未经请求的报告消息。IODEF文档和数字签名与TraceRequest信息类似。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="reporting">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
<iodef:Description>Host illicitly accessed admin account
</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="high" completion="succeeded"
type="admin"/>
<iodef:Confidence rating="high"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="reporting">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
<iodef:Description>Host illicitly accessed admin account
</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="high" completion="succeeded"
type="admin"/>
<iodef:Confidence rating="high"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>32821</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>22</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:Description>
Incident report sent to NP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<iodef:Service>
<iodef:port>32821</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>22</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:Description>
Incident report sent to NP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
The diagram below outlines the RID IncidentQuery communication flow between RID systems on different networks.
下图概述了不同网络上RID系统之间的RID IncidentQuery通信流。
NP-1 NP-2
NP-1 NP-2
1. Generate a request for information on a specific incident number or incident type
1. 生成关于特定事件编号或事件类型的信息请求
2. o---IncidentQuery--->
2. o---意外查询--->
3. Verify policy information and determine if matches exist for requested information
3. 验证策略信息，并确定所请求的信息是否存在匹配项
4. <-------Report------o
4. <-------Report------o
5. Associate report to request by incident number or type and file report(s).
5. 按事件编号或类型和文件报告将报告与请求关联。
Figure 10. IncidentQuery Communication Flow
图10。偶然查询通信流
The IncidentQuery message communication receives a response of a Report message. If the Report message is empty, the responding host did not have information available to share with the requestor. The incident number and responding RID system, as well as the transport, assist in the association of the request and response since a report can be filed and is not always solicited. If there is a problem with the IncidentQuery message, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed.
IncidentQuery消息通信接收报告消息的响应。如果报告消息为空，则响应主机没有可与请求者共享的信息。事件编号和响应RID系统以及运输系统有助于将请求和响应关联起来，因为可以提交报告，并且不总是征求报告。如果IncidentQuery消息存在问题，例如验证数字签名或解密请求失败，则向请求者发送RequestAuthorization消息。RequestAuthorization消息应提供无法处理消息的原因。
The IncidentQuery request may be received in several formats as a result of the type of query being performed. If the incident number is the only information provided, the IODEF document and IP packet data may not be needed to complete the request. However, if a type of incident is requested, the incident number remains NULL, and the
作为执行的查询类型的结果，可以以多种格式接收偶然查询请求。如果事件编号是提供的唯一信息，则完成请求可能不需要IODEF文档和IP数据包数据。但是，如果请求某一类型的事件，则事件编号保持为空，并且
IP packet data will not be included in the IODEF RecordItem class; the other incident information is the main source for comparison. In the case in which an incident number may not be the same between CSIRTs, the incident number and/or IP packet information can be provided and used for comparison on the receiving RID system to generate (a) Report message(s).
IP包数据将不包括在IODEF RecordItem类中；其他事件信息是比较的主要来源。在csirt之间的事件编号可能不相同的情况下，可以提供事件编号和/或IP分组信息，并用于在接收RID系统上进行比较，以生成（a）报告消息。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="IncidentQuery"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#210-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="IncidentQuery"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#210-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.0.xsd"/>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.0.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!-- ****************************************************************
*********************************************************************
*** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, August 2006 ***
*** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. ***
*********************************************************************
-->
<!-- ****************************************************************
*********************************************************************
*** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, August 2006 ***
*** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. ***
*********************************************************************
-->
<!--RID acts as an envelope for IODEF documents to support the exchange
of messages-->
<!--
====== Real-Time Inter-network Defense - RID ======
==== Suggested definition for RID messaging ======
-->
<!--RID acts as an envelope for IODEF documents to support the exchange
of messages-->
<!--
====== Real-Time Inter-network Defense - RID ======
==== Suggested definition for RID messaging ======
-->
<xs:annotation>
<xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
</xs:annotation>
<xs:element name="RID" type="iodef-rid:RIDType"/>
<xs:complexType name="RIDType">
<xs:sequence>
<xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
<xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
<xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:annotation>
<xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
</xs:annotation>
<xs:element name="RID" type="iodef-rid:RIDType"/>
<xs:complexType name="RIDType">
<xs:sequence>
<xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
<xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
<xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--Used in RequestAuthorization Message for RID-->
<!--Used in RequestAuthorization Message for RID-->
<xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>
<xs:complexType name="RequestStatusType">
<xs:attribute name="AuthorizationStatus" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Approved"/>
<xs:enumeration value="Denied"/>
<xs:enumeration value="Pending"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-AuthorizationStatus"
type="xs:string" use="optional"/>
<xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>
<xs:complexType name="RequestStatusType">
<xs:attribute name="AuthorizationStatus" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Approved"/>
<xs:enumeration value="Denied"/>
<xs:enumeration value="Pending"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-AuthorizationStatus"
type="xs:string" use="optional"/>
<xs:attribute name="Justification">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="SystemResource"/>
<xs:enumeration value="Authentication"/>
<xs:enumeration value="AuthenticationOrigin"/>
<xs:enumeration value="Encryption"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Justification"
type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<xs:attribute name="Justification">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="SystemResource"/>
<xs:enumeration value="Authentication"/>
<xs:enumeration value="AuthenticationOrigin"/>
<xs:enumeration value="Encryption"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Justification"
type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<!--Incident Source Information for Result Message-->
<!--Incident Source Information for Result Message-->
<xs:element name="IncidentSource" type="iodef-rid:IncidentSourceType"/>
<xs:complexType name="IncidentSourceType">
<xs:sequence>
<xs:element ref="iodef-rid:SourceFound"/>
<xs:element ref="iodef:Node" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<xs:element name="SourceFound" type="xs:boolean"/>
<xs:element name="IncidentSource" type="iodef-rid:IncidentSourceType"/>
<xs:complexType name="IncidentSourceType">
<xs:sequence>
<xs:element ref="iodef-rid:SourceFound"/>
<xs:element ref="iodef:Node" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<xs:element name="SourceFound" type="xs:boolean"/>
<!--
====== Real-Time Inter-network Defense Policy - RIDPolicy ======
====== Definition for RIDPolicy for messaging
-->
<!--
====== Real-Time Inter-network Defense Policy - RIDPolicy ======
====== Definition for RIDPolicy for messaging
-->
<xs:annotation>
<xs:documentation>RID Policy used for transport of
messages</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation>RID Policy used for transport of
messages</xs:documentation>
</xs:annotation>
<!-- RIDPolicy information with setting information listed in RID
documentation -->
<!-- RIDPolicy information with setting information listed in RID
documentation -->
<xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>
<xs:complexType name="RIDPolicyType">
<xs:sequence>
<xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
<xs:element ref="iodef:IncidentID" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="MsgType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="TraceRequest"/>
<xs:enumeration value="RequestAuthorization"/>
<xs:enumeration value="Result"/>
<xs:enumeration value="Investigation"/>
<xs:enumeration value="Report"/>
<xs:enumeration value="IncidentQuery"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
<xs:attribute name="MsgDestination" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="RIDSystem"/>
<xs:enumeration value="SourceOfIncident"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgDestination" type="xs:string"
use="optional"/>
</xs:complexType>
<xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>
<xs:complexType name="RIDPolicyType">
<xs:sequence>
<xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
<xs:element ref="iodef:IncidentID" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="MsgType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="TraceRequest"/>
<xs:enumeration value="RequestAuthorization"/>
<xs:enumeration value="Result"/>
<xs:enumeration value="Investigation"/>
<xs:enumeration value="Report"/>
<xs:enumeration value="IncidentQuery"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
<xs:attribute name="MsgDestination" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="RIDSystem"/>
<xs:enumeration value="SourceOfIncident"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgDestination" type="xs:string"
use="optional"/>
</xs:complexType>
<xs:element name="PolicyRegion">
<xs:complexType>
<xs:attribute name="region" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="ClientToNP"/>
<xs:enumeration value="NPToClient"/>
<xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/>
<xs:enumeration value="AcrossNationalBoundaries"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-region"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="TrafficType" default="Attack">
<xs:complexType>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Attack"/>
<xs:enumeration value="Network"/>
<xs:enumeration value="Content"/>
<xs:enumeration value="OfficialBusiness"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:element name="PolicyRegion">
<xs:complexType>
<xs:attribute name="region" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="ClientToNP"/>
<xs:enumeration value="NPToClient"/>
<xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/>
<xs:enumeration value="AcrossNationalBoundaries"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-region"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="TrafficType" default="Attack">
<xs:complexType>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Attack"/>
<xs:enumeration value="Network"/>
<xs:enumeration value="Content"/>
<xs:enumeration value="OfficialBusiness"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
Communication between NPs' RID systems must be protected. RID has many security considerations built into the design of the protocol, several of which are described in the following sub-sections. For a complete view of security, considerations need to include the availability, confidentiality, and integrity concerns for the transport, storage, and exchange of information.
必须保护NPs RID系统之间的通信。RID在协议的设计中内置了许多安全注意事项，以下小节将介绍其中的几个。为了全面了解安全性，需要考虑信息传输、存储和交换的可用性、机密性和完整性问题。
When considering the transport of RID messages, an out-of-band network, either logical or physical, would prevent outside attacks against RID communication. An out-of-band connection would be ideal, but not necessarily practical. Authenticated encrypted tunnels between RID systems MUST be used to provide confidentiality, integrity, authenticity, and privacy for the data. Trust relationships are based on consortiums and established trust relationships of public key infrastructure (PKI) cross-certifications of consortiums. By using RIDPolicy information, TLS, and the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], RID takes advantage of existing security standards. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized, and that the messages meet policy and privacy guidelines and maintain integrity.
在考虑RID消息的传输时，带外网络（逻辑或物理）将防止针对RID通信的外部攻击。带外连接是理想的，但不一定实用。RID系统之间经过身份验证的加密隧道必须用于为数据提供机密性、完整性、真实性和隐私。信任关系基于联合体和联合体公钥基础设施（PKI）交叉认证的已建立信任关系。RID通过使用RIDPolicy信息、TLS以及加密[XMLencrypt]和数字签名[RFC3275]、[XMLsig]的XML安全特性，利用了现有的安全标准。这些标准提供了明确的方法，以确保消息是安全的、经过身份验证和授权的，并且消息符合策略和隐私指导原则并保持完整性。
As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] are used in the following cases:
如本文件相关章节所述，XML数字签名[RFC3275]和XML加密[XMLencrypt]用于以下情况：
XML Digital Signature
XML数字签名
o The originator of the TraceRequest or Investigation request MUST use a detached signature to sign at least one of the original IP packets included in the RecordItem class data to provide authentication to all upstream participants in the trace of the origin. All IP packets provided by the originator may be signed, and additional packets added by upstream peers in the trace may be signed by the peer adding the data, while maintaining the IP packet and detached signature from the original requestor. This signature MUST be passed to all recipients of the TraceRequest.
o TraceRequest或调查请求的发起人必须使用分离的签名对RecordItem类数据中包含的至少一个原始IP数据包进行签名，以向发起人跟踪中的所有上游参与者提供身份验证。发起者提供的所有IP分组可以被签名，并且由跟踪中的上游对等方添加的附加分组可以由添加数据的对等方签名，同时保持IP分组和从原始请求者分离的签名。此签名必须传递给TraceRequest的所有收件人。
o For all message types, the full IODEF/RID document MUST be signed using an enveloped signature by the sending peer to provide authentication and integrity to the receiving RID system.
o 对于所有消息类型，发送对等方必须使用信封签名对完整的IODEF/RID文档进行签名，以向接收RID系统提供身份验证和完整性。
XML Encryption
XML加密
o The IODEF/RID document may be encrypted to provide an extra layer of security between peers so that the message is not only encrypted for the transport, but also while stored. This behavior would be agreed upon between peers or a consortium, or determined on a per-message basis, depending on security requirements. It should be noted that there are cases for transport where the RIDPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6046].
o 可以对IODEF/RID文档进行加密，以在对等方之间提供额外的安全层，从而使得消息不仅在传输时被加密，而且在存储时也被加密。这种行为将在对等方或联合体之间达成一致意见，或根据安全要求在每条消息的基础上确定。应注意的是，在某些运输情况下，RIDPolicy类需要以明文形式呈现，详见运输文件[RFC6046]。
o An Investigation request, or any other message type that may be relayed through RID systems other than the intended destination as a result of trust relationships, may be encrypted for the intended recipient. This may be necessary if the RID network is being used for message transfer, the intermediate parties do not need to have knowledge of the request contents, and a direct communication path does not exist. In that case, the RIDPolicy class is used by intermediate parties and is maintained in clear text.
o 调查请求或由于信任关系可能通过除预期目的地以外的RID系统中继的任何其他消息类型可针对预期接收者进行加密。如果RID网络用于消息传输，中间方不需要知道请求内容，并且不存在直接通信路径，则这可能是必要的。在这种情况下，RIDPolicy类由中间方使用，并以明文形式维护。
o The action taken in the Result message may be encrypted using the key of the request originator. In that case, the intermediate parties can view the RIDPolicy information and know the trace has been completed and do not need to see the action. If the use of encryption were limited to sections of the message, the History class information would be encrypted. Otherwise, it is RECOMMENDED to encrypt the entire IODEF/RID document, using an enveloped signature, for the originator of the request. The existence of the Result message for an incident would tell any intermediate parties used in the path of the incident investigation that the incident handling has been completed.
o 可以使用请求发起人的密钥对结果消息中采取的操作进行加密。在这种情况下，中间方可以查看RIDPolicy信息，并知道跟踪已完成，无需查看操作。如果加密的使用仅限于消息的部分，则历史类信息将被加密。否则，建议使用信封签名为请求的发起人加密整个IODEF/RID文档。事件结果消息的存在将告知事件调查路径中使用的任何中间方事件处理已完成。
The formation of policies is a very important aspect of using a messaging system like RID to exchange potentially sensitive information. Many considerations should be involved for peering parties, and some guidelines to protect the data, systems, and transport are covered in this section. Policies established should provide guidelines for communication methods, security, and fall-back procedures.
策略的形成是使用诸如RID之类的消息传递系统交换潜在敏感信息的一个非常重要的方面。对等方需要考虑很多因素，本节介绍了一些保护数据、系统和传输的指南。制定的政策应为通信方法、安全性和回退程序提供指导。
The security considerations for the storage and exchange of information in RID messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect client information during an investigation. RID Policy is a necessary tool for listing the requirements of messages to provide a method to categorize data elements for proper handling. Controls are also provided for the sending entity to protect messages from third parties through XML encryption.
RID消息中信息存储和交换的安全注意事项可能包括遵守当地、地区或国家法规，以及在调查期间保护客户信息的义务。RID策略是列出消息要求的必要工具，它提供了一种方法来对数据元素进行分类，以便进行适当的处理。还为发送实体提供控件，以通过XML加密保护来自第三方的消息。
RID provides a method to exchange incident handling request and Report messages to peer networks. Network administrators, who have the ability to base the decision on the available resources and other factors of their network, maintain control of incident investigations within their own network. Thus, RID provides the ability for participating networks to manage their own security controls, leveraging the information listed in RIDPolicy.
RID提供了一种向对等网络交换事件处理请求和报告消息的方法。网络管理员能够根据其网络的可用资源和其他因素做出决策，并在其网络内保持对事件调查的控制。因此，RID为参与网络提供了管理其自身安全控制的能力，利用RID策略中列出的信息。
The transport specifications are fully defined in a separate document [RFC6046]. The specified transport protocols MUST use encryption to provide an additional level of security and integrity, while supporting mutual authentication through bi-directional certificate usage. Any subsequent transport method defined should take advantage of existing standards for ease of implementation and integration of RID systems. Session encryption for the transport of RID messages is enforced in the transport specification. The privacy and security considerations are addressed fully in RID to protect sensitive portions of documents and provide a method to authenticate the messages. Therefore, RID messages do not rely on the security provided by the transport layer alone. The encryption requirements and considerations for RID are discussed at the beginning of Section 6 of this document.
运输规范在单独的文件[RFC6046]中有完整的定义。指定的传输协议必须使用加密来提供额外级别的安全性和完整性，同时通过双向证书使用支持相互身份验证。定义的任何后续传输方法应利用现有标准，以便于实施和集成RID系统。传输规范中强制执行RID消息传输的会话加密。RID充分考虑了隐私和安全问题，以保护文档的敏感部分，并提供一种验证消息的方法。因此，RID消息不单单依赖于传输层提供的安全性。RID的加密要求和注意事项将在本文件第6节开头讨论。
XML security functions such as the digital signature [RFC3275] and encryption [XMLencrypt] provide a standards-based method to encrypt and digitally sign RID messages. RID messages specify system use and privacy guidelines through the RIDPolicy class. A public key infrastructure (PKI) provides the base for authentication and authorization, encryption, and digital signatures to establish trust relationships between members of a RID consortium or a peering consortium.
数字签名[RFC3275]和加密[XMLencrypt]等XML安全功能提供了一种基于标准的方法来加密RID消息并对其进行数字签名。RID消息通过RIDPolicy类指定系统使用和隐私准则。公钥基础设施（PKI）为身份验证和授权、加密和数字签名提供了基础，以在RID联盟或对等联盟的成员之间建立信任关系。
XML security functions such as the digital signature [RFC3275] and encryption [XMLencrypt] can be used within the contents of the message for privacy and security in cases for which certain elements must remain encrypted or signed as they traverse the path of a trace. For example, the digital signature on a TraceRequest can be used to verify the identity of the trace originator. The use of the XML security features in RID messaging is in accordance with the specifications for the IODEF model; however, the use requirements may differ since RID also incorporates communication of security incident information.
在某些元素在穿越跟踪路径时必须保持加密或签名的情况下，可以在消息内容中使用XML安全功能，如数字签名[RFC3275]和加密[XMLencrypt]，以保护隐私和安全。例如，TraceRequest上的数字签名可用于验证跟踪发起人的身份。RID消息传递中XML安全特性的使用符合IODEF模型的规范；但是，使用要求可能有所不同，因为RID还包含安全事件信息的通信。
The RID protocol must be able to guarantee delivery and meet the necessary security requirements of a state-of-the-art protocol. In order to guarantee delivery, TCP should be considered as the underlying protocol within the current network standard practices.
RID协议必须能够保证交付，并满足最先进协议的必要安全要求。为了保证传输，TCP应被视为当前网络标准实践中的基础协议。
Security considerations must include the integrity, authentication, privacy, and authorization of the messages sent between RID communication systems or IHSs. The communication between RID systems must be authenticated and encrypted to ensure the integrity of the messages and the RID systems involved in the trace. Another concern that needs to be addressed is authentication for a request that traverses multiple networks. In this scenario, systems in the path of the multi-hop TraceRequest need to authorize a trace from not only their neighbor network, but also from the initiating RID system as discussed in Section 6.4. Several methods can be used to ensure integrity and privacy of the communication.
安全考虑必须包括RID通信系统或IHS之间发送的消息的完整性、身份验证、隐私和授权。RID系统之间的通信必须经过身份验证和加密，以确保跟踪中涉及的消息和RID系统的完整性。另一个需要解决的问题是对穿越多个网络的请求进行身份验证。在此场景中，多跳TraceRequest路径中的系统不仅需要授权来自其邻居网络的跟踪，还需要授权来自发起RID系统的跟踪，如第6.4节所述。有几种方法可用于确保通信的完整性和隐私性。
The transport mechanism selected MUST follow the defined transport protocol [RFC6046] when using RID messaging to ensure consistency among the peers. Consortiums may vary their selected transport mechanisms and thus must decide upon a mutual protocol to use for transport when communicating with peers in a neighboring consortium using RID. RID systems MUST implement and deploy HTTPS as defined in the transport document [RFC6046] and optionally support other protocols such as the Blocks Extensible Exchange Protocol (BEEP). RID, the XML security functions, and transport protocols must properly integrate with a public key infrastructure (PKI) managed by the consortium or one managed by a trusted entity. For the Internet, an example of an existing effort that could be leveraged to provide the supporting PKI could be the American Registry for Internet Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI hierarchy. Security and privacy considerations related to consortiums are discussed in Sections 6.5 and 6.6.
使用RID消息传递时，所选的传输机制必须遵循定义的传输协议[RFC6046]，以确保对等方之间的一致性。联盟可能会改变其选择的传输机制，因此在使用RID与相邻联盟中的对等方通信时，必须决定用于传输的共同协议。RID系统必须按照传输文档[RFC6046]中的定义实施和部署HTTPS，并可选地支持其他协议，如块可扩展交换协议（BEEP）。RID、XML安全功能和传输协议必须与联盟管理的公钥基础设施（PKI）或受信任实体管理的公钥基础设施（PKI）正确集成。就互联网而言，可以利用现有努力提供支持性PKI的一个例子是美国互联网号码注册处（ARIN）和区域互联网注册处（RIR）的PKI层次结构。第6.5节和第6.6节讨论了与财团相关的安全和隐私注意事项。
Out-of-band communications dedicated to NP interaction for RID messaging would provide additional security as well as guaranteed bandwidth during a denial-of-service attack. For example, an out-of-band channel may consist of logical paths defined over the existing network. Out-of-band communications may not be possible between all network providers, but should be considered to protect the network management systems used for RID messaging. Methods to protect the data transport may also be provided through session encryption.
专用于RID消息的NP交互的带外通信将在拒绝服务攻击期间提供额外的安全性和有保证的带宽。例如，带外信道可以由在现有网络上定义的逻辑路径组成。不可能在所有网络提供商之间进行带外通信，但应考虑保护用于RID消息传递的网络管理系统。还可以通过会话加密提供保护数据传输的方法。
In order to address the integrity and authenticity of messages, transport encryption MUST be used to secure the traffic sent between RID systems. Systems with predefined relationships for RID would include those who peer within a consortium with agreed-upon appropriate use regulations and for peering consortiums. Trust relationships may also be defined through a bridged or hierarchical PKI in which both peers belong.
为了解决消息的完整性和真实性问题，必须使用传输加密来保护RID系统之间发送的通信量。具有RID预定义关系的系统将包括那些在具有商定的适当使用规则的联盟内进行对等的系统，以及对等联盟的系统。信任关系也可以通过两个对等方都属于的桥接或分层PKI来定义。
Systems used to send authenticated RID messages between networks MUST use a secured system and interface to connect to a border network's RID systems. Each connection to a RID system MUST meet the security requirements agreed upon through the consortium regulations, peering, or SLAs. The RID system MUST only listen for and send RID messages on the designated port, which also MUST be over an encrypted tunnel meeting the minimum requirement of algorithms and key lengths established by the consortium, peering, or SLA. The selected cryptographic algorithms for symmetric encryption, digital signatures, and hash functions MUST meet minimum security levels of the times. The encryption strength MUST adhere to import and export regulations of the involved countries for data exchange.
用于在网络之间发送经过身份验证的RID消息的系统必须使用安全的系统和接口连接到边界网络的RID系统。与RID系统的每个连接必须满足通过联盟法规、对等或SLA商定的安全要求。RID系统必须仅在指定端口上侦听和发送RID消息，该端口还必须通过加密隧道，满足联合体、对等或SLA建立的算法和密钥长度的最低要求。为对称加密、数字签名和散列函数选择的加密算法必须满足时代的最低安全级别。加密强度必须遵守相关国家的数据交换进出口法规。
In order to ensure the authenticity of the RID messages, a message authentication scheme is used to secure the protocol. XML security functions utilized in RID require a trust center such as a PKI for the distribution of credentials to provide the necessary level of security for this protocol. Layered transport protocols also utilize encryption and rely on a trust center. Public key certificate pairs issued by a trusted Certification Authority (CA) MAY be used to provide the necessary level of authentication and encryption for the RID protocol. The CA used for RID messaging must be trusted by all involved parties and may take advantage of similar efforts, such as the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI to network providers. The PKI used for authentication would also provide the necessary certificates needed for encryption used for the RID transport protocol [RFC6046].
为了确保RID消息的真实性，使用消息认证方案来保护协议。RID中使用的XML安全功能需要一个信任中心（如PKI）来分发凭据，从而为该协议提供必要的安全级别。分层传输协议还利用加密并依赖于信任中心。由可信证书颁发机构（CA）颁发的公钥证书对可用于为RID协议提供必要级别的身份验证和加密。用于RID消息传递的CA必须得到所有相关方的信任，并且可以利用类似的努力，例如Internet2联合PKI或ARIN/RIR努力向网络提供商提供PKI。用于身份验证的PKI还将提供用于RID传输协议[RFC6046]的加密所需的必要证书。
The use of pre-shared keys may be considered for authentication. If this option is selected, the specifications set forth in "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST be followed.
可以考虑使用预共享密钥进行身份验证。如果选择此选项，则必须遵循“传输层安全（TLS）预共享密钥密码套件”[RFC4279]中规定的规范。
Hosts receiving a RID message MUST be able to verify that the sender of the request is valid and trusted. Using digital signatures on a hash of the RID message with an X.509 version 3 certificate issued by a trusted party MUST be used to authenticate the request. The X.509 version 3 specifications as well as the digital signature
接收RID消息的主机必须能够验证请求的发送方是否有效且可信。必须使用受信任方颁发的X.509版本3证书对RID消息的哈希使用数字签名来验证请求。X.509版本3规范以及数字签名
specifications and path validation standards set forth in [RFC5280] MUST be followed in order to interoperate with a PKI designed for similar purposes. The IODEF specification MUST be followed for digital signatures to provide the authentication and integrity aspects required for secure messaging between network providers. The use of digital signatures in RID XML messages MUST follow the World Wide Web Consortium (W3C) recommendations for signature syntax and processing when either the XML encryption [XMLencrypt] or digital signature [XMLsig], [RFC3275] is used within a document. Transport specifications are detailed in a separate document [RFC6046].
必须遵守[RFC5280]中规定的规范和路径验证标准，以便与为类似目的设计的PKI进行互操作。数字签名必须遵循IODEF规范，以提供网络提供商之间安全消息传递所需的身份验证和完整性方面。当在文档中使用XML加密[XMLencrypt]或数字签名[XMLsig]，[RFC3275]时，在RID XML消息中使用数字签名必须遵循万维网联盟（W3C）关于签名语法和处理的建议。运输规范详见单独的文件[RFC6046]。
It might be helpful to define an extension to the authentication scheme that uses attribute certificates [RFC5755] in such a way that an application could automatically determine whether human intervention is needed to authorize a request; however, the specification of such an extension is out of scope for this document.
定义使用属性证书[RFC5755]的认证方案的扩展可能会有帮助，这样应用程序可以自动确定是否需要人为干预来授权请求；但是，此类扩展的规范不在本文件的范围内。
Bilateral trust relations between network providers ensure the authenticity of requests for TraceRequests from immediate peers in the web of networks formed to provide the traceback capability. A network provider several hops into the path of the RID trace must trust the information from its own trust relationships as well as the previous trust relationships in the downstream path. For practical reasons, the NPs may want to prioritize incident handling events based upon the immediate peer for a TraceRequest, the originator, and the listed Confidence rating for the incident. In order to provide a higher assurance level of the authenticity of the TraceRequest, the originating RID system is included in the TraceRequest along with contact information and the information of all RID systems in the path the trace has taken. This information is provided through the IODEF EventData class nesting the list of systems and contacts involved in a trace, while setting the category attribute to "infrastructure".
网络提供商之间的双边信任关系确保了网络中直接对等方对TraceRequest的请求的真实性，该网络是为提供回溯功能而形成的。进入RID跟踪路径的网络提供商必须信任来自其自身信任关系以及下游路径中先前信任关系的信息。出于实际原因，NPs可能希望根据TraceRequest的直接对等方、发起人和列出的事件置信度，对事件处理事件进行优先级排序。为了对TraceRequest的真实性提供更高的保证级别，TraceRequest中包括原始RID系统以及联系人信息和跟踪路径中所有RID系统的信息。此信息通过IODEF EventData类提供，该类嵌套跟踪中涉及的系统和联系人列表，同时将category属性设置为“infrastructure”。
A second measure MUST be taken to ensure the identity of the originating RID system. The originating RID system MUST include a digital signature in the TraceRequest sent to all systems in the upstream path. The digital signature from the RID system is performed on the RecordItem class of the IODEF following the XML digital signature specifications from W3C [XMLsig] using a detached signature. The signature MUST be passed to all parties that receive a TraceRequest, and each party MUST be able to perform full path validation on the digital signature. Full path validation verifies the chaining relationship to a trusted root and also performs a certificate revocation check. In order to accommodate that requirement, the IP packet in the RecordItem data MUST remain
必须采取第二种措施来确保原始RID系统的身份。原始RID系统必须在发送到上游路径中所有系统的TraceRequest中包含数字签名。RID系统的数字签名在IODEF的RecordItem类上执行，遵循W3C[XMLsig]的XML数字签名规范，使用分离的签名。签名必须传递给接收TraceRequest的所有各方，并且各方必须能够对数字签名执行完整路径验证。完整路径验证验证与受信任根的链接关系，并执行证书吊销检查。为了满足这一要求，记录项数据中的IP数据包必须保持不变
unchanged as a request is passed along between providers and is the only element for which the signature is applied. If additional packets are included in the document at upstream peers, the initial packet MUST still remain with the detached signature. The subsequent packets may be signed by the peer adding the incident information for the investigation. A second benefit to this requirement is that the integrity of the filter used is ensured as it is passed to subsequent NPs in the upstream trace of the packet. The trusted PKI also provides the keys used to digitally sign the RecordItem class for TraceRequests to meet the requirement of authenticating the original request. Any host in the path of the trace should be able to verify the digital signature using the trusted PKI.
未更改，因为请求在提供者之间传递，并且是应用签名的唯一元素。如果在上游对等点的文档中包含其他数据包，则初始数据包仍必须保留分离的签名。随后的分组可由对等方签名，添加用于调查的事件信息。这一要求的第二个好处是，当所用过滤器传递到数据包上游跟踪中的后续NPs时，可确保其完整性。受信任的PKI还提供用于对TraceRequests的RecordItem类进行数字签名的密钥，以满足对原始请求进行身份验证的要求。跟踪路径中的任何主机都应该能够使用受信任的PKI验证数字签名。
In the case in which an enterprise network using RID sends a TraceRequest to its provider, the signature from the enterprise network MUST be included in the initial request. The NP may generate a new request to send upstream to members of the NP consortium to continue the trace. If the original request is sent, the originating NP, acting on behalf of the enterprise network under attack, MUST also digitally sign, with an enveloped signature, the full IODEF document to assure the authenticity of the TraceRequest. An NP that offers RID as a service may be using its own PKI to secure RID communications between its RID system and the attached enterprise networks. NPs participating in the trace MUST be able to determine the authenticity of RID requests.
在使用RID的企业网络向其提供商发送TraceRequest的情况下，来自企业网络的签名必须包含在初始请求中。NP可能会生成一个新的请求，向NP联盟的成员发送上游以继续跟踪。如果发送原始请求，则代表受攻击企业网络的发起NP还必须使用封装签名对完整的IODEF文档进行数字签名，以确保TraceRequest的真实性。将RID作为服务提供的NP可能正在使用其自己的PKI来保护其RID系统和连接的企业网络之间的RID通信。参与跟踪的NPs必须能够确定RID请求的真实性。
Consortiums of NPs are an ideal way to establish a communication web of trust for RID messaging. The consortium could provide centralized resources, such as a PKI, and established guidelines for use of the RID protocol. The consortium would also assist in establishing trust relationships between the participating NPs to achieve the necessary level of cooperation and experience-sharing among the consortium entities. This may be established through PKI certificate policy [RFC3647] reviews to determine the appropriate trust levels between organizations or entities. The consortium may also be used for other purposes to better facilitate communication among NPs in a common area (Internet, region, government, education, private networks, etc.).
NPs联盟是为RID消息传递建立信任通信网络的理想方式。联合体可以提供集中的资源，如PKI，并为RID协议的使用制定指导方针。联合体还将协助参与的核动力源之间建立信任关系，以实现联合体实体之间必要的合作和经验分享。这可以通过PKI证书策略[RFC3647]审核来确定组织或实体之间的适当信任级别。联合体也可用于其他目的，以更好地促进共同领域（互联网、地区、政府、教育、私人网络等）内核动力源之间的通信。
Using a PKI to distribute certificates used by RID systems provides an already established method to link trust relationships between NPs of consortiums that would peer with NPs belonging to a separate consortium. In other words, consortiums could peer with other consortiums to enable communication of RID messages between the
使用PKI分发RID系统使用的证书提供了一种已经建立的方法，用于链接联合体的NPs之间的信任关系，这些联合体的NPs将与属于单独联合体的NPs对等。换句话说，联合体可以与其他联合体进行对等，以实现各联合体之间的RID消息通信
participating NPs. The PKI along with Memorandums of Agreement could be used to link border directories to share public key information in a bridge, a hierarchy, or a single cross-certification relationship.
参与的核动力源。PKI和协议备忘录可用于链接边界目录，以在桥接、层次结构或单个交叉认证关系中共享公钥信息。
Consortiums also need to establish guidelines for each participating NP to adhere to. The RECOMMENDED guidelines include:
财团还需要为每个参与的NP制定指导方针。建议的准则包括：
o Physical and logical practices to protect RID systems;
o 保护RID系统的物理和逻辑实践；
o Network and application layer protection for RID systems and communications;
o RID系统和通信的网络和应用层保护；
o Proper use guidelines for RID systems, messages, and requests; and
o RID系统、消息和请求的正确使用指南；和
o A PKI to provide authentication, integrity, and privacy.
o 提供身份验证、完整性和隐私的PKI。
The functions described for a consortium's role would parallel that of a PKI federation. The PKI federations that currently exist are responsible for establishing security guidelines and PKI trust models. The trust models are used to support applications to share information using trusted methods and protocols.
为财团的角色所描述的功能将与PKI联盟的功能并行。目前存在的PKI联盟负责建立安全指南和PKI信任模型。信任模型用于支持应用程序使用受信任的方法和协议共享信息。
A PKI can also provide the same level of security for communication between an end entity (enterprise, educational, or government customer network) and the NP. The PKI may be a subordinate CA or in the CA hierarchy from the NP's consortium to establish the trust relationships necessary as the request is made to other connected networks.
PKI还可以为终端实体（企业、教育或政府客户网络）和NP之间的通信提供相同级别的安全性。PKI可以是从属CA，也可以是NP联盟的CA层次结构中的CA，以在向其他连接网络发出请求时建立必要的信任关系。
Privacy issues raise many concerns when information-sharing is required to achieve the goal of stopping or mitigating the effects of a security incident. The RIDPolicy class is used to automate the enforcement of the privacy concerns listed within this document. The privacy and system use concerns that MUST be addressed in the RID system and other integrated components include the following:
当需要共享信息以实现阻止或减轻安全事件影响的目标时，隐私问题会引起许多关注。RIDPolicy类用于自动执行本文档中列出的隐私问题。RID系统和其他集成组件中必须解决的隐私和系统使用问题包括：
Network Provider Concerns:
网络供应商关注的问题：
o Privacy of data monitored and/or stored on IDSs for attack detection.
o IDSs上监控和/或存储的用于攻击检测的数据的隐私。
o Privacy of data monitored and stored on systems used to trace traffic across a single network.
o 在用于跟踪单个网络流量的系统上监视和存储的数据的隐私。
Customer Attached Networks Participating in RID with NP:
使用NP参与RID的客户连接网络：
o Customer networks may include an enterprise, educational, government, or other attached networks to an NP participating in RID and MUST be made fully aware of the security and privacy considerations for using RID.
o 客户网络可能包括参与RID的NP的企业、教育、政府或其他连接网络，并且必须充分了解使用RID的安全和隐私注意事项。
o Customers MUST know the security and privacy considerations in place by their NP and the consortium of which the NP is a member.
o 客户必须了解其NP和NP所属联盟的安全和隐私注意事项。
o Customers MUST understand that their data can and will be sent to other NPs in order to complete a trace unless an agreement stating otherwise is made in the service level agreements between the customer and NP.
o 客户必须了解，他们的数据可以并且将被发送到其他NPs，以便完成跟踪，除非客户和NP之间的服务级别协议中另有规定。
Parties Involved in the Attack:
参与袭击的各方：
o Privacy of the identity of a host involved in an attack.
o 参与攻击的主机的身份隐私。
o Privacy of information such as the source and destination used for communication purposes over the monitored or RID connected network(s).
o 在受监控或RID连接的网络上用于通信目的的信息隐私，如源和目的地。
o Protection of data from being viewed by intermediate parties in the path of an Investigation request MUST be considered.
o 必须考虑在调查请求过程中保护数据不被中间方查看。
Consortium Considerations:
联合体考虑：
o System use restricted to security incident handling within the local region's definitions of appropriate traffic for the network monitored and linked via RID in a single consortium also abiding by the consortium's use guidelines.
o 系统使用仅限于在本地区对通过RID监控和链接的网络的适当流量的定义范围内的安全事件处理，该网络在单个财团中也遵守财团的使用指南。
o System use prohibiting the consortium's participating NPs from inappropriately tracing non-attack traffic to locate sources or mitigate traffic unlawfully within the jurisdiction or region.
o 系统使用禁止联合体参与的NPs不适当地跟踪非攻击流量，以在管辖区或区域内定位来源或非法缓解流量。
Inter-Consortium Considerations:
联合体间的考虑：
o System use between peering consortiums MUST also adhere to any government communication regulations that apply between those two regions, such as encryption export and import restrictions. This may include consortiums that are categorized as "BetweenConsortiums" or "AcrossNationalBoundaries".
o 对等联盟之间的系统使用还必须遵守适用于这两个地区的任何政府通信法规，如加密出口和进口限制。这可能包括被归类为“团体之间”或“跨越国界”的财团。
o System use between consortiums MUST NOT request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements.
o 联合体之间的系统使用不得请求超出法律或联合体间协议预期和允许范围的流量跟踪和行动。
o System use between consortiums classified as "AcrossNationalBoundaries" MUST respect national boundary issues and limit requests to appropriate system use and not to achieve their own agenda to limit or restrict traffic that is otherwise permitted within the country in which the peering consortium resides.
o 被归类为“跨越国界”的联盟之间的系统使用必须尊重国界问题，并将请求限制为适当的系统使用，而不是实现其自身议程，以限制或限制对等联盟所在国家内允许的通信量。
The security and privacy considerations listed above are for the consortiums, NPs, and enterprises to agree upon. The agreed-upon policies may be facilitated through use of the RIDPolicy class. Some privacy considerations are addressed through the RID guidelines for encryption and digital signatures as described at the beginning of Section 6.
以上列出的安全和隐私注意事项由财团、NPs和企业商定。可以通过使用RIDPolicy类来简化商定的策略。如第6节开头所述，通过RID加密和数字签名指南解决了一些隐私问题。
RID is useful in determining the true source of a packet that traverses multiple networks or to communicate security incidents and automate the response. The information obtained from the trace may determine the identity of the source host or the network provider used by the source of the traffic. It should be noted that the trace mechanism used across a single-network provider may also raise privacy concerns for the clients of the network. Methods that may raise concern include those that involve storing packets for some length of time in order to trace packets after the fact. Monitoring networks for intrusions and for tracing capabilities also raises concerns for potentially sensitive valid traffic that may be traversing the monitored network. IDSs and single-network tracing are outside of the scope of this document, but the concern should be noted and addressed within the use guidelines of the network. Some IDSs and single-network trace mechanisms attempt to properly address these issues. RID is designed to provide the information needed by any single-network trace mechanism. The provider's choice of a single trace mechanism depends on resources, existing solutions, and local legislation. Privacy concerns in regard to the single-network trace must be dealt with at the client-to-NP level and are out of scope for RID messaging.
RID可用于确定穿越多个网络的数据包的真实来源，或用于传达安全事件和自动响应。从跟踪中获得的信息可以确定源主机或流量源使用的网络提供商的身份。应该注意的是，跨单个网络提供商使用的跟踪机制也可能引起网络客户端的隐私问题。可能引起关注的方法包括那些涉及将数据包存储一段时间以便在事后跟踪数据包的方法。监控网络的入侵和跟踪功能也会引起对可能正在穿越监控网络的潜在敏感有效流量的关注。IDSs和单一网络跟踪不在本文档范围内，但应在网络使用指南中注意并解决该问题。一些IDS和单网络跟踪机制试图正确解决这些问题。RID旨在提供任何单一网络跟踪机制所需的信息。提供商对单一跟踪机制的选择取决于资源、现有解决方案和当地立法。有关单个网络跟踪的隐私问题必须在客户端到NP级别处理，并且不在RID消息传递的范围内。
The identity of the true source of an attack packet being traced through RID could be sensitive. The true identity listed in a Result message can be protected through the use of encryption [XMLencrypt] enveloping the IODEF document and RID Result information, using the public encryption key of the originating NP. Alternatively, the action taken may be listed without the identity being revealed to the originating NP. The ultimate goal of the RID communication system is to stop or mitigate attack traffic, not to ensure that the identity of the attack traffic is known to involved parties. The NP that identifies the source should deal directly with the involved parties and proper authorities in order to determine the guidelines for the release of such information, if it is regarded as sensitive. In some
通过RID跟踪的攻击数据包的真实来源的身份可能是敏感的。结果消息中列出的真实身份可以通过使用原始NP的公共加密密钥，使用封装IODEF文档和RID结果信息的加密[XMLencrypt]来保护。或者，可以列出所采取的行动，而不向发起NP透露身份。RID通信系统的最终目标是停止或减轻攻击流量，而不是确保相关方知道攻击流量的身份。识别信息来源的NP应直接与相关方和适当当局打交道，以确定此类信息的发布指南（如果此类信息被视为敏感信息）。在某些方面
situations, systems used in attacks are compromised by an unknown source and, in turn, are used to attack other systems. In that situation, the reputation of a business or organization may be at stake, and the action taken may be the only additional information reported in the Result message to the originating system. If the security incident is a minor incident, such as a zombie system used in part of a large-scale DDoS attack, ensuring the system is taken off the network until it has been fixed may be sufficient. The decision is left to the system users and consortiums to determine appropriate data to be shared given that the goal of the specification is to provide the appropriate technical options to remain compliant. The textual descriptions should include details of the incident in order to protect the reputation of the unknowing attacker and prevent the need for additional investigation. Local, state, or national laws may dictate the appropriate reporting action for specific security incidents.
在某些情况下，用于攻击的系统受到未知来源的危害，进而被用于攻击其他系统。在这种情况下，企业或组织的声誉可能会受到影响，所采取的行动可能是向发起系统报告的结果消息中唯一的附加信息。如果安全事件是一个小事件，例如大规模DDoS攻击中使用的僵尸系统，则确保系统脱离网络直到修复可能就足够了。鉴于规范的目标是提供适当的技术选项以保持合规性，决定权留给系统用户和联盟来确定要共享的适当数据。文本描述应包括事件细节，以保护未知攻击者的声誉，并防止需要进行额外调查。地方、州或国家法律可能规定针对特定安全事件的适当报告行动。
Privacy becomes an issue whenever sensitive data traverses a network. For example, if an attack occurred between a specific source and destination, then every network provider in the path of the trace would become aware that the cyber attack occurred. In a targeted attack, it may not be desirable that information about two nation states that are battling a cyber war would become general knowledge to all intermediate parties. However, it is important to allow the traces to take place in order to halt the activity since the health of the networks in the path could also be at stake during the attack. This provides a second argument for allowing the Result message to only include an action taken and not the identity of the offending host. In the case of an Investigation request, where the originating NP is aware of the NP that will receive the request for processing, the free-form text areas of the document could be encrypted [XMLencrypt] using the public key of the destination NP to ensure that no other NP in the path can read the contents. The encryption would be accomplished through the W3C [XMLencrypt] specification for encrypting an element.
每当敏感数据通过网络时，隐私就成为一个问题。例如，如果攻击发生在特定源和目标之间，则跟踪路径中的每个网络提供商都会意识到发生了网络攻击。在有针对性的攻击中，可能不希望有关正在进行网络战争的两个民族国家的信息成为所有中间方的常识。但是，重要的是允许跟踪发生，以便停止活动，因为在攻击期间，路径中网络的健康也可能受到威胁。这提供了第二个参数，用于允许结果消息仅包括已执行的操作，而不包括违规主机的标识。在调查请求的情况下，如果发起NP知道将接收处理请求的NP，则可以使用目标NP的公钥对文档的自由格式文本区域进行加密[XMLencrypt]，以确保路径中没有其他NP可以读取内容。加密将通过用于加密元素的W3C[XMLencrypt]规范来完成。
In some situations, all network traffic of a nation may be granted through a single network provider. In that situation, options must support sending Result messages from a downstream peer of that network provider. That option provides an additional level of abstraction to hide the identity and the NP of the identified source of the traffic. Legal action may override this technical decision after the trace has taken place, but that is out of the technical scope of this document.
在某些情况下，一个国家的所有网络流量都可以通过一个网络提供商授予。在这种情况下，选项必须支持从该网络提供商的下游对等方发送结果消息。该选项提供了额外的抽象级别，以隐藏已识别流量源的身份和NP。在跟踪发生后，法律行动可能会推翻此技术决定，但这超出了本文件的技术范围。
Privacy concerns when using an Investigation request to request action close to the source of valid attack traffic needs to be considered. Although the intermediate NPs may relay the request if
在使用调查请求请求接近有效攻击流量源的操作时，需要考虑隐私问题。尽管中间NPs可能会在以下情况下转发请求：
there is no direct trust relationship to the closest NP to the source, the intermediate NPs do not require the ability to see the contents of the packet or the text description field(s) in the request. This message type does not require any action by the intermediate RID systems, except to relay the packet to the next NP in the path. Therefore, the contents of the request may be encrypted for the destination system. The intermediate NPs would only need to know how to direct the request to the manager of the ASN in which the source IP address belongs.
与距离源最近的NP没有直接信任关系，中间NP不需要能够查看数据包的内容或请求中的文本描述字段。此消息类型不需要中间RID系统执行任何操作，除非将数据包中继到路径中的下一个NP。因此，可以针对目的地系统对请求的内容进行加密。中间NPs只需要知道如何将请求定向到源IP地址所属的ASN的管理器。
Traces must be legitimate security-related incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system would include a request to block or rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business.
追踪必须是合法的安全相关事件，不得用于破坏或审查等目的。滥用该系统的一个例子包括请求阻止或限制合法流量，以防止用户之间在互联网上共享信息（限制访问在线版本的论文），或限制访问竞争对手的产品，以破坏业务。
Intra-consortium RID communications raise additional issues, especially when the peering consortiums reside in different regions or nations. TraceRequests and requested actions to mitigate traffic must adhere to the appropriate use guidelines and yet prevent abuse of the system. First, the peering consortiums MUST identify the types of traffic that can be traced between the borders of the participating NPs of each consortium. The traffic traced should be limited to security-incident-related traffic. Second, the traces permitted within one consortium if passed to a peering consortium may infringe upon the peering consortium's freedom of information laws. An example would be a consortium in one country permitting a trace of traffic containing objectionable material, outlawed within that country. The RID trace may be a valid use of the system within the confines of that country's network border; however, it may not be permitted to continue across network boundaries where such content is permitted under law. By continuing the trace in another country's network, the trace and response could have the effect of improperly restricting access to data. A continued trace into a second country may break the laws and regulations of that nation. Any such traces MUST cease at the country's border.
联盟内部RID通信会引发其他问题，尤其是当对等联盟位于不同的地区或国家时。追踪器请求和请求的缓解流量的措施必须遵守适当的使用指南，同时防止系统被滥用。首先，对等联盟必须确定可在每个联盟的参与NPs边界之间追踪的流量类型。跟踪的流量应限于与安全事件相关的流量。第二，如果将一个联盟内允许的痕迹传递给对等联盟，可能会侵犯对等联盟的信息自由法。一个例子是，一个国家的一个财团允许跟踪含有不良物质的交通，这在该国是非法的。RID跟踪可能是该国网络边界范围内系统的有效使用；但是，如果法律允许此类内容，则可能不允许继续跨越网络边界。通过在另一个国家的网络中继续跟踪，跟踪和响应可能会产生不当限制数据访问的效果。继续追踪第二个国家可能会违反该国的法律法规。任何此类痕迹都必须在该国边境停止。
The privacy concerns listed in this section address issues among the trusted parties involved in a trace within an NP, a RID consortium, and peering RID consortiums. Data used for RID communications must also be protected from parties that are not trusted. This protection is provided through the authentication and encryption of documents as they traverse the path of trusted servers. Each RID system MUST perform a bi-directional authentication when sending a RID message and use the public encryption key of the upstream or downstream peer to send a message or document over the network. This means that the
本节中列出的隐私问题涉及NP、RID联盟和对等RID联盟中跟踪涉及的受信任方之间的问题。用于RID通信的数据也必须受到保护，以防不受信任的各方访问。这种保护是通过在文档穿过受信任服务器的路径时对文档进行身份验证和加密来提供的。每个RID系统在发送RID消息时必须执行双向身份验证，并使用上游或下游对等方的公共加密密钥通过网络发送消息或文档。这意味着
document is decrypted and re-encrypted at each RID system via TLS over the transport protocol [RFC6046]. The RID messages may be decrypted at each RID system in order to properly process the request or relay the information. Today's processing power is more than sufficient to handle the minimal burden of encrypting and decrypting relatively small typical RID messages.
在每个RID系统上，通过传输协议[RFC6046]通过TLS对文档进行解密和重新加密。可以在每个RID系统上解密RID消息，以便正确处理请求或中继信息。今天的处理能力足以处理加密和解密相对较小的典型RID消息的最小负担。
This document uses URNs to describe XML namespaces and XML schemas [XMLschema] conforming to a registry mechanism described in [RFC3688].
本文档使用URN来描述符合[RFC3688]中描述的注册表机制的XML名称空间和XML模式[XMLschema]。
Registration request for the iodef-rid namespace:
iodef rid命名空间的注册请求：
URI: urn:ietf:params:xml:ns:iodef-rid-1.0
URI: urn:ietf:params:xml:ns:iodef-rid-1.0
Registrant Contact: See the "Author's Address" section of this document.
注册人联系人：请参阅本文件的“作者地址”部分。
XML: None. Namespace URIs do not represent an XML specification.
XML：没有。命名空间URI不表示XML规范。
Registration request for the iodef-rid XML schema:
iodef rid XML架构的注册请求：
URI: urn:ietf:params:xml:schema:iodef-rid-1.0
URI: urn:ietf:params:xml:schema:iodef-rid-1.0
Registrant Contact: See the "Author's Address" section of this document.
注册人联系人：请参阅本文件的“作者地址”部分。
XML: See Section 5, "RID Schema Definition", of this document.
XML：参见本文档第5节“RID模式定义”。
Security incidents have always been difficult to trace as a result of the spoofed sources, resource limitations, and bandwidth utilization problems. Incident response is often slow even when the IP address is known to be valid because of the resources required to notify the responsible party of the attack and then to stop or mitigate the attack traffic. Methods to identify and trace attacks near real time are essential to thwarting attack attempts. Network providers need policies and automated methods to combat the hacker's efforts. NPs need automated monitoring and response capabilities to identify and trace attacks quickly without resource-intensive side effects. Integration with a centralized communication system to coordinate the detection, tracing, and identification of attack sources on a single network is essential. RID provides a way to integrate NP resources for each aspect of attack detection, tracing, and source
由于欺骗源、资源限制和带宽利用问题，安全事件一直难以追踪。即使已知IP地址有效，事件响应通常也很慢，因为通知责任方攻击、然后停止或缓解攻击流量所需的资源。近实时识别和跟踪攻击的方法对于挫败攻击企图至关重要。网络提供商需要策略和自动化方法来打击黑客的行为。核动力源需要自动监测和响应能力，以快速识别和跟踪攻击，而不会产生资源密集型副作用。与集中通信系统集成以协调单个网络上攻击源的检测、跟踪和识别至关重要。RID为攻击检测、跟踪和源的各个方面提供了一种集成NP资源的方法
identification and extends the communication capabilities among network providers. The communication is accomplished through the use of flexible IODEF XML-based documents passed between IHSs or RID systems. A TraceRequest or Investigation request is communicated to an upstream NP and may result in an upstream trace or in an action to stop or mitigate the attack traffic. The messages are communicated among peers with security inherent to the RID messaging scheme provided through existing standards such as XML encryption and digital signatures. Policy information is carried in the RID message itself through the use of the RIDPolicy. RID provides the timely communication among NPs, which is essential for incident handling.
识别并扩展网络提供商之间的通信能力。通过在IHSs或RID系统之间使用灵活的基于IODEF XML的文档来完成通信。TraceRequest或调查请求被传送到上游NP，并可能导致上游跟踪或停止或缓解攻击流量的行动。通过现有标准（如XML加密和数字签名）提供的RID消息传递方案所固有的安全性，在对等方之间传递消息。通过使用RIDPolicy，RID消息本身携带策略信息。RID提供NPs之间的及时通信，这对于事件处理至关重要。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake 3rd，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC 32752002年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.，Ed.，和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070]Danyliw，R.，Meijer，J.，和Y.Demchenko，“事件对象描述交换格式”，RFC 50702007年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5755]Farrell，S.，Housley，R.，和S.Turner，“用于授权的互联网属性证书配置文件”，RFC 57552010年1月。
[RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-Time Inter-Network Defense (RID) Messages," RFC 6046, November 2010.
[RFC6046]Moriarty，K.和B.Trammell，“实时网络间防御（RID）消息的传输”，RFC 60462010年11月。
[XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)". W3C Recommendation. T. Bray, E. Maler, J. Paoli, and C.M. Sperberg-McQueen. October 2000. http://www.w3.org/TR/2000/REC-xml-20001006.
[XML1.0]“可扩展标记语言（XML）1.0（第二版）”。W3C建议。T.布雷、E.马勒、J.保利和C.M.斯珀伯格·麦奎因。2000年10月。http://www.w3.org/TR/2000/REC-xml-20001006.
[XMLnames] "Namespaces in XML 1.0 (Third Edition)". W3C Recommendation. T. Bray, D. Hollander, A. Layman, R. Tobin, H. Thompson. December 2009. http://www.w3.org/TR/REC-xml-names/.
[XMLnames]“XML 1.0中的名称空间（第三版）”。W3C建议。T.布雷，D.霍兰德，A.外行，R.托宾，H.汤普森。2009年12月。http://www.w3.org/TR/REC-xml-names/.
[XMLencrypt] "XML Encryption Syntax and Processing". W3C Recommendation. T. Imamura, B. Dillaway, and E. Simon. December 2002. http://www.w3.org/TR/xmlenc-core/.
[XMLencrypt]“XML加密语法和处理”。W3C建议。T.Imamura、B.Dillaway和E.Simon。2002年12月。http://www.w3.org/TR/xmlenc-core/.
[XMLschema] "XML Schema". E. Van der Vlist. O'Reilly. 2002.
[XMLschema]“XML模式”。范德维斯特。奥雷利。2002
[XMLsig] "XML-Signature Syntax and Processing (Second Edition)". W3C Recommendation. M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon. June 2008. http://www.w3.org/TR/xmldsig-core/#sec-Design.
[XMLsig]“XML签名语法和处理（第二版）”。W3C建议。M.巴特尔、J.博耶、B.福克斯、B.拉马奇亚和E.西蒙。2008年6月。http://www.w3.org/TR/xmldsig-core/#sec-设计。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，BCP 6，RFC 1930，1996年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647]Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917]Quitek，J.，Zseby，T.，Claise，B.，和S.Zander，“IP流信息导出（IPFIX）的要求”，RFC 39172004年10月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[IPtrace] "Advanced and Authenticated Marking Schemes for IP Traceback". D. Song and A. Perrig. IEEE INFOCOM 2001.
[IPtrace]“IP回溯的高级认证标记方案”。D.宋和A.佩里格。IEEE信息通信2001。
[HASH-IPtrace] "Hash-Based IP Traceback". A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, S. Kent, and W. Strayer. SIGCOMM'01. August 2001.
[HASH IPtrace]“基于哈希的IP回溯”。A.斯诺伦、C.帕特里奇、L.桑切斯、C.琼斯、F.查科蒂奥、S.肯特和W.斯特莱尔。SIGCOMM'01。2001年8月。
[ICMPtrace] Bellovin, S., Leech, M., and T. Taylor, "ICMP Traceback Messages", Work in Progress, February 2003.
[ICMPtrace]Bellovin，S.，Leech，M.，和T.Taylor，“ICMP回溯信息”，正在进行的工作，2003年2月。
[NTWK-IPtrace] "Practical network support for IP traceback". S. Savage, D. Wetherall, A. Karlin, and T. Anderson. SIGCOMM'00. August 2000.
[NTWK IPtrace]“IP回溯的实用网络支持”。S.萨维奇、D.韦瑟拉尔、A.卡林和T.安德森。SIGCOMM'00。2000年8月。
[DoS] "Trends in Denial of Service Attack Technology". K. Houle, G. Weaver, N. Long, and R. Thomas. CERT Coordination Center. October 2001.
[DoS]“拒绝服务攻击技术的趋势”。K.霍尔、G.韦弗、N.朗和R.托马斯。CERT协调中心。2001年10月。
Acknowledgements
致谢
Many thanks to coworkers and the Internet community for reviewing and commenting on the document as well as providing recommendations to simplify and secure the protocol: Robert K. Cunningham, Ph.D, Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, and Sandra G. Dykes, Ph.D.
非常感谢同事和互联网社区对该文件进行审查和评论，并提供简化和保护该协议的建议：Robert K.Cunningham博士、Cynthia D.McLain博士、William Streilein博士、Iljitsch van Beijnum、Steve Bellovin、Yuri Demchenko、Jean-Francois Morfin、Stephen Northcutt、，杰弗里·席勒、布赖恩·特拉梅尔、罗曼·达尼略、托尼·陶伯和桑德拉·G·戴克斯博士。
Sponsor Information
赞助商信息
This work was sponsored by the Air Force under Air Force Contract FA8721-05-C-0002, while working at MIT Lincoln Laboratory.
这项工作由空军根据空军合同FA8721-05-C-0002赞助，当时在麻省理工学院林肯实验室工作。
"Opinions, interpretations, conclusions, and recommendations are those of the author and are not necessarily endorsed by the United States Government".
“意见、解释、结论和建议是作者的意见、解释、结论和建议，不一定得到美国政府的认可”。
Author's Address
作者地址
Kathleen M. Moriarty RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 US
Kathleen M.Moriarty RSA，EMC 174 Middlesex Turnpike Bedford的安全部门，马萨诸塞州，美国01730
EMail: Moriarty_Kathleen@EMC.com
EMail: Moriarty_Kathleen@EMC.com