Internet Engineering Task Force (IETF) K. Moriarty
Request for Comments: 6545 EMC
Obsoletes: 6045 April 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Moriarty
Request for Comments: 6545 EMC
Obsoletes: 6045 April 2012
Category: Standards Track
ISSN: 2070-1721
Real-time Inter-network Defense (RID)
实时网络间防御（RID）
Abstract
摘要
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. Service 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. This document obsoletes RFC 6045.
安全事件，如系统泄露、蠕虫、病毒、网络钓鱼事件和拒绝服务，通常会导致服务、数据和人力及系统资源的损失。服务提供商和计算机安全事件响应团队需要配备设备，并随时准备在攻击发生之前，使用适当的工具和程序，协助沟通和跟踪安全事件。实时网络间防御（RID）概述了一种主动式网络间通信方法，以促进共享事件处理数据，同时集成现有的检测、跟踪、源识别和缓解机制，形成完整的事件处理解决方案。在通信系统中结合这些功能提供了一种在网络上实现更高安全级别的方法。建议处理事故的政策指南，并可由财团使用安全建议和注意事项达成一致。本文件淘汰RFC 6045。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6545.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6545.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Changes from RFC 6045 ......................................5
1.2. Normative and Informative ..................................6
1.3. Terminology ................................................7
2. Characteristics of Incidents ....................................7
3. Communication between CSIRTs and Service Providers ..............8
3.1. Inter-Service-Provider RID Messaging ......................10
3.2. RID Communication Topology ................................12
4. Message Formats ................................................13
4.1. RID Data Types ............................................13
4.1.1. Boolean ............................................13
4.2. RID Message Types .........................................14
5. IODEF-RID Schema ...............................................15
5.1. RIDPolicy Class ...........................................17
5.1.1. ReportSchema .......................................23
5.2. RequestStatus .............................................26
5.3. IncidentSource ............................................28
5.4. RID Name Spaces ...........................................29
5.5. Encoding ..................................................29
5.6. Including IODEF or Other XML Documents ....................29
5.6.1. Including XML Documents in RID .....................30
6. RID Messages ...................................................31
6.1. Request ...................................................31
6.2. Acknowledgement ...........................................33
6.3. Result ....................................................34
6.4. Report ....................................................36
6.5. Query .....................................................38
7. RID Communication Exchanges ....................................39
7.1. Upstream Trace Communication Flow .........................40
7.1.1. RID TraceRequest Example ...........................43
7.1.2. Acknowledgement Message Example ....................47
1. Introduction ....................................................3
1.1. Changes from RFC 6045 ......................................5
1.2. Normative and Informative ..................................6
1.3. Terminology ................................................7
2. Characteristics of Incidents ....................................7
3. Communication between CSIRTs and Service Providers ..............8
3.1. Inter-Service-Provider RID Messaging ......................10
3.2. RID Communication Topology ................................12
4. Message Formats ................................................13
4.1. RID Data Types ............................................13
4.1.1. Boolean ............................................13
4.2. RID Message Types .........................................14
5. IODEF-RID Schema ...............................................15
5.1. RIDPolicy Class ...........................................17
5.1.1. ReportSchema .......................................23
5.2. RequestStatus .............................................26
5.3. IncidentSource ............................................28
5.4. RID Name Spaces ...........................................29
5.5. Encoding ..................................................29
5.6. Including IODEF or Other XML Documents ....................29
5.6.1. Including XML Documents in RID .....................30
6. RID Messages ...................................................31
6.1. Request ...................................................31
6.2. Acknowledgement ...........................................33
6.3. Result ....................................................34
6.4. Report ....................................................36
6.5. Query .....................................................38
7. RID Communication Exchanges ....................................39
7.1. Upstream Trace Communication Flow .........................40
7.1.1. RID TraceRequest Example ...........................43
7.1.2. Acknowledgement Message Example ....................47
7.1.3. Result Message Example .............................47
7.2. Investigation Request Communication Flow ..................50
7.2.1. Investigation Request Example ......................51
7.2.2. Acknowledgement Message Example ....................53
7.3. Report Communication Flow .................................54
7.3.1. Report Example .....................................54
7.4. Query Communication Flow ..................................56
7.4.1. Query Example ......................................57
8. RID Schema Definition ..........................................58
9. Security Requirements ..........................................62
9.1. XML Digital Signatures and Encryption .....................62
9.2. Message Transport .........................................66
9.3. Public Key Infrastructure .................................67
9.3.1. Authentication .....................................68
9.3.2. Multi-Hop Request Authentication ...................69
9.4. Consortiums and Public Key Infrastructures ................70
9.5. Privacy Concerns and System Use Guidelines ................71
9.6. Sharing Profiles and Policies .............................76
10. Security Considerations .......................................77
11. Internationalization Issues ...................................77
12. IANA Considerations ...........................................78
13. Summary .......................................................80
14. References ....................................................80
14.1. Normative References .....................................80
14.2. Informative References ...................................82
Appendix A. Acknowledgements ......................................84
7.1.3. Result Message Example .............................47
7.2. Investigation Request Communication Flow ..................50
7.2.1. Investigation Request Example ......................51
7.2.2. Acknowledgement Message Example ....................53
7.3. Report Communication Flow .................................54
7.3.1. Report Example .....................................54
7.4. Query Communication Flow ..................................56
7.4.1. Query Example ......................................57
8. RID Schema Definition ..........................................58
9. Security Requirements ..........................................62
9.1. XML Digital Signatures and Encryption .....................62
9.2. Message Transport .........................................66
9.3. Public Key Infrastructure .................................67
9.3.1. Authentication .....................................68
9.3.2. Multi-Hop Request Authentication ...................69
9.4. Consortiums and Public Key Infrastructures ................70
9.5. Privacy Concerns and System Use Guidelines ................71
9.6. Sharing Profiles and Policies .............................76
10. Security Considerations .......................................77
11. Internationalization Issues ...................................77
12. IANA Considerations ...........................................78
13. Summary .......................................................80
14. References ....................................................80
14.1. Normative References .....................................80
14.2. Informative References ...................................82
Appendix A. Acknowledgements ......................................84
Organizations require help from other parties to identify incidents, mitigate malicious activity targeting their computing resources, and to gain insight into potential threats through the sharing of information. This coordination might entail working with a service provider (SP) to filter attack traffic, working with an SP to resolve a configuration issue that is unintentionally causing problems, contacting a remote site to take down a bot network, or sharing watch-lists of known malicious IP addresses in a consortium. The term "SP" is to be interpreted as any type of service provider or Computer Security Incident Response Team (CSIRT) that may be involved in RID communications.
组织需要其他各方的帮助，以识别事件、减轻针对其计算资源的恶意活动，并通过信息共享深入了解潜在威胁。这种协调可能需要与服务提供商（SP）合作以过滤攻击流量，与SP合作以解决无意中导致问题的配置问题，联系远程站点以关闭机器人网络，或在联盟中共享已知恶意IP地址的监视列表。术语“SP”应解释为可能参与RID通信的任何类型的服务提供商或计算机安全事件响应团队（CSIRT）。
Incident handling involves the detection, reporting, identification, and mitigation of an incident, whether it be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to an SP for resolution/mitigation,
事件处理涉及事件的检测、报告、识别和缓解，无论是良性配置问题、it事件、违反服务水平协议（SLA）、系统泄露、社会工程钓鱼攻击或拒绝服务（DoS）攻击等。当检测到事件时，响应可能包括提交报告、通知事件来源、请求SP解决/缓解，
or a 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 target or victim system and the source or attacking system are available, the source is easy to identify.
或者请求查找源。更困难的情况之一是攻击源未知，需要能够通过网络迭代跟踪上游的攻击流量，以便采取任何进一步行动。当目标或受害者系统与源或攻击系统之间的活动会话的准确记录可用时，源很容易识别。
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. RID provides a secure method to communicate incident information, enabling the exchange of Incident Object Description and Exchange Format (IODEF) [RFC5070] Extensible Markup Language (XML) documents. RID considers security, policy, and privacy issues related to the exchange of potentially sensitive information, enabling SPs or organizations the options to make appropriate decisions according to their policies. RID includes provisions for confidentiality, integrity, and authentication.
实时网络间防御（RID）概述了一种主动式网络间通信方法，以促进共享事件处理数据，同时集成现有的检测、跟踪、源识别和缓解机制，形成完整的事件处理解决方案。RID提供了一种安全的方法来传递事件信息，支持事件对象描述和交换格式（IODEF）[RFC5070]可扩展标记语言（XML）文档的交换。RID考虑与潜在敏感信息交换相关的安全、策略和隐私问题，使SP或组织能够根据其策略做出适当决策。RID包括保密性、完整性和身份验证的规定。
The data in RID messages is represented in an XML [XML1.0] document using the IODEF and RID. By following this model, integration with other aspects for incident handling is simplified. 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 incident or attack at hand. RID is intended to provide a method to communicate the relevant information between CSIRTs while being compatible with a variety of existing and possible future detection-tracing and response approaches. Incidents may be extended to include Information Technology (IT) incidents, where RID enables the communication between or within providers for non-security IT incidents.
RID消息中的数据使用IODEF和RID在XML[XML1.0]文档中表示。通过遵循此模型，简化了与事件处理其他方面的集成。这些方法被纳入通信系统中，以指示需要在距离源最近的地方采取哪些行动，以停止或减轻当前事件或攻击的影响。RID旨在提供一种在CSIRT之间通信相关信息的方法，同时兼容各种现有的和可能的未来检测跟踪和响应方法。事件可以扩展到包括信息技术（IT）事件，其中RID支持供应商之间或供应商内部的非安全IT事件通信。
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, privacy, and policy information set in the RID schema. The RID schema defines communication-specific metadata to support the communication of IODEF documents for exchanging or tracing information regarding incidents. RID messages are encapsulated for transport, which is defined in a separate document [RFC6546]. The authentication, integrity, and authorization features that RID and RID transport offer are used to achieve a necessary level of security.
由于潜在的敏感信息可能会通过RID消息传递，因此安全和隐私方面的考虑备受关注。RID消息传递利用RID模式中设置的XML安全性、隐私和策略信息。RID模式定义特定于通信的元数据，以支持IODEF文档的通信，以交换或跟踪有关事件的信息。RID消息是为传输而封装的，它在单独的文档[RFC6546]中定义。RID和RID传输提供的身份验证、完整性和授权功能用于实现必要的安全级别。
Coordinating with other CSIRTs is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information. RID provides
与其他CSIRT的协调严格来说不是一个技术问题。有许多程序、信任和法律考虑因素可能会阻止组织共享信息。RID提供
information and options that can be used by organizations who must then apply their own policies for sharing information. Organizations must develop policies and procedures for the use of the RID protocol and IODEF.
组织可以使用的信息和选项，这些组织必须应用自己的信息共享策略。组织必须制定使用RID协议和IODEF的政策和程序。
This document contains the following changes with respect to its predecessor [RFC6045]:
本文件包含对其前身[RFC6045]的以下更改：
o This document is Standards Track, while [RFC6045] was published as Informational.
o 本文档是标准跟踪，而[RFC6045]是作为参考发布的。
o This document obsoletes [RFC6045] and moves it to Historic status.
o 本文档废弃[RFC6045]并将其移至历史状态。
o This document refers to the updated RID transport specification [RFC6546], where appropriate.
o 本文件适用于更新的RID传输规范[RFC6546]。
o Edits reflected in this updated version of RID are primarily improvements to the informational descriptions. The descriptions have been updated to clarify that IODEF and RID can be used for all types of incidents and are not limited to network security incidents. The language has been updated to change the focus from attacks to incidents, where appropriate. The term "network provider" has been replaced with the more generic term of "service provider". Several introductory informational sections have been removed as they are not necessary for the implementation of the protocol. The sections include:
o 此更新版本的RID中反映的编辑主要是对信息性描述的改进。这些说明已更新，以澄清IODEF和RID可用于所有类型的事件，且不限于网络安全事件。该语言已经更新，以便在适当情况下将重点从攻击转向事件。术语“网络提供商”已被更通用的术语“服务提供商”取代。几个介绍性信息部分已被删除，因为它们不是协议实施所必需的。这些章节包括：
* 1.3. Attack Types and RID Messaging,
* 1.3. 攻击类型和RID消息，
* 2. RID Integration with Network Provider Technologies,
* 2.RID与网络提供商技术的集成，
* 3.1. Integrating Trace Approaches, and
* 3.1. 集成跟踪方法，以及
* 3.2. Superset of Packet Information for Traces.
* 3.2. 跟踪数据包信息的超集。
o An option for a star topology has been included in an informational section to meet current use-case requirements of those who provide reports on incident information.
o 信息部分包含了星形拓扑的选项，以满足提供事件信息报告者的当前用例要求。
o The schema version was incremented. The schema has changed to include IODEF [RFC5070] enveloped in RID in the RIDPolicy class using the new ReportSchema class, to include one verified erratum, to include additional enumerations in the Justification attribute, to remove the AcrossNationalBoundaries region enumeration, to add the DataWithHandlingRequirements enumeration in TrafficTypes, and to change the name of the RequestAuthorization MsgType to
o 架构版本已增加。架构已更改，使用新的ReportSchema类将RID中封装的IODEF[RFC5070]包括在RIDPolicy类中，以包括一个已验证的勘误表，以在对正属性中包括其他枚举，以删除CrossNationalBounders区域枚举，在TrafficTypes中添加DataWithHandlingRequirements枚举，并将RequestAuthorization MsgType的名称更改为
Acknowledgement. Additional text has been provided to clarify definitions of enumerated values for some attributes. The RequestAuthorization name was replaced with Acknowledgement to more accurately represent the function of that message type. Text was clarified to note the possible use of this message in response to Query and Report messages. The attributes were fixed in the schema to add 'lang' at the RID class level for language support.
确认提供了补充文本，以澄清某些属性枚举值的定义。RequestAuthorization名称替换为Acknowledge，以更准确地表示该消息类型的功能。对文本进行了澄清，以说明在响应查询和报告消息时可能使用此消息。模式中的属性已修复，以便在RID类级别添加“lang”以获得语言支持。
o The TraceRequest and Investigation messages have been collapsed into a single message with the requirement to set the MsgType according to the functionality required for automation. The message descriptions were identical with the exception of the MsgType, which remains an exception depending on the desired function. Since both of the enumerations for MsgType are each a Request, 'Investigation' is now 'InvestigationRequest'. Content may vary within the IODEF document for the type of Request specified.
o TraceRequest和调查消息已折叠为一条消息，要求根据自动化所需的功能设置MsgType。消息描述与MsgType的异常相同，MsgType仍然是一个异常，具体取决于所需的函数。由于MsgType的两个枚举都是一个请求，“调查”现在是“调查请求”。对于指定的请求类型，IODEF文档中的内容可能会有所不同。
o The IncidentQuery message description name and MsgType enumeration value in the schema have been changed to the more generic name of 'Query'.
o 架构中的IncidentQuery消息描述名称和MsgType枚举值已更改为更通用的名称“Query”。
o Guidance has been improved to ensure consistent implementations and use of XML encryption to provide confidentiality based on data markers, specifically the iodef:restriction attribute in the IODEF and IODEF-RID schemas. The attribute may also be present in IODEF extension schemas, where the guidance also applies. Additional guidance and restrictions have been added for XML requirements.
o 已经改进了指南，以确保XML加密的一致实现和使用，从而基于数据标记（特别是iodef和iodef-RID模式中的iodef:restriction属性）提供机密性。该属性也可能出现在IODEF扩展模式中，指南也适用于该模式。为XML需求增加了额外的指导和限制。
o All of the normative text from the Security Considerations section has been moved to a new section, Security Requirements.
o “安全注意事项”一节中的所有规范性文本已移至新的一节“安全要求”。
o The order in which the RID schema is presented in Section 5 has been changed to match the order in the IODEF-RID schema.
o 第5节中RID模式的显示顺序已更改，以匹配IODEF-RID模式中的顺序。
o Additional text has been provided to explain the content and interactions between entities in the examples.
o 提供了额外的文本来解释示例中实体之间的内容和交互。
o Additional references have been provided to improve interoperability with stricter guidance on the use of XML digital signatures and encryption.
o 还提供了其他参考资料，以通过更严格的XML数字签名和加密使用指南提高互操作性。
Sections 1, 2, 3, and 12 provide helpful background information and considerations. RID systems participating in a consortium are REQUIRED to fully implement Sections 4, 5, 6, 7, 8, 9, 10, and 11 to prevent interoperability concerns.
第1、2、3和12节提供了有用的背景信息和注意事项。要求参与联合体的RID系统全面实施第4、5、6、7、8、9、10和11节，以防止互操作性问题。
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]中所述进行解释。
An incident may be defined as a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), system compromise, a worm or Trojan infection, or a single- or multiple-source denial-of-service attack. 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. Incident tracing can be used to identify the source(s) of an attack in order to halt or mitigate the undesired behavior or to correct an identified issue. RID messages can be communicated between entities to report or investigate any type of incident and allow for actions to be taken when the source of the incident or a point closer to the source is known or has been identified. Methods to accomplish mitigation may include remediation of a configuration issue, filtering or rate-limiting the traffic close to the source, or taking the host or network offline. Care must also be taken to ensure that the systems involved in the RID communications are not abused and to use proper analysis in determining if attack traffic is, in fact, attack traffic at each SP involved in the investigation.
事件可定义为良性配置问题、IT事件、违反服务级别协议（SLA）、系统泄露、蠕虫或特洛伊木马感染或单源或多源拒绝服务攻击。跟踪安全事件的目标可能是确定来源或在网络上找到尽可能靠近事件来源的点。事件跟踪可用于识别攻击源，以停止或缓解不希望的行为或纠正已识别的问题。RID消息可以在实体之间进行通信，以报告或调查任何类型的事件，并允许在已知或已识别事件源或接近事件源的点时采取行动。完成缓解的方法可能包括修复配置问题、过滤或限制靠近源的流量或使主机或网络脱机。还必须注意确保RID通信中涉及的系统不被滥用，并使用适当的分析来确定攻击流量是否实际上是调查中涉及的每个SP的攻击流量。
Investigating 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. Attackers use many techniques, which can vary between individuals or even organized groups of attackers. Through analysis, the techniques may be grouped into indicators of compromise to be shared via IODEF and RID, further assisting with the improvement of detection capabilities. Security incidents, including distributed denial-of-service (DDoS) attacks, can be difficult or nearly impossible to trace because of the nature of the attack. Some of the difficulties in investigating attacks include the following:
调查安全事件可能是一项艰巨的任务，因为攻击者竭尽全力掩盖其身份。在发生安全事件的情况下，可以通过与攻击者来源点的现有已建立连接来识别真实来源。但是，攻击者可能在初始入侵后的很长一段时间内无法连接到入侵系统，或者可能通过分布在网络上的一系列入侵主机访问系统。隐藏源的其他方法可能包括使用有效和伪造的源地址从多个源以具有相同攻击的主机为目标。这种策略可用于破坏机器，并将查找真实来源的困难任务留给管理员。攻击者使用多种技术，这些技术可能因个人或甚至有组织的攻击者群体而异。通过分析，可将这些技术分组为可通过IODEF和RID共享的折衷指标，进一步协助提高检测能力。由于攻击的性质，包括分布式拒绝服务（DDoS）攻击在内的安全事件可能很难或几乎不可能追踪。调查袭击的一些困难包括：
o the incident or attack originates from multiple sources;
o 事件或攻击来自多个来源；
o the incident may leverage social-engineering techniques or other methods to gain access to resources and intellectual property using what appears to be legitimate access methods such as outbound web sessions from user systems;
o 事件可能利用社会工程技术或其他方法，使用看似合法的访问方法（如用户系统的出站web会话）访问资源和知识产权；
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 SP or HTTP requests sent to an organization connected to the Internet;
o 通信量的类型可以包括有效的目的地服务，不能阻止，因为它们是业务的基本服务，例如SP上的DNS服务器或发送到连接到Internet的组织的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" or large botnets, 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 攻击可能使用来自任何特定来源的极少量数据包，因此几乎不可能在事后进行跟踪；
o the indicators of a compromise may be difficult to detect.
o 妥协的迹象可能很难发现。
If the source(s) of an incident cannot be determined from IP address information, it may be possible to trace the traffic based on characteristics of the incident such as tracing the increased bandwidth utilization or the type of packets seen by the client. In the case of packets with spoofed source addresses, it is not a trivial task to identify the source of an attack.
如果无法根据IP地址信息确定事件的来源，则可以基于事件的特征（例如跟踪增加的带宽利用率或客户端看到的数据包类型）来跟踪流量。对于具有伪造源地址的数据包，识别攻击源并非易事。
IODEF, any extensions to IODEF, and RID can be used to detail an incident, characteristics of the incident (as it evolves), the incident history, and communications of the incident to facilitate the resolution and reporting of the incident.
IODEF、IODEF的任何扩展和RID可用于详细说明事件、事件特征（随着事件的发展）、事件历史和事件的通信，以促进事件的解决和报告。
Expediting the communication between CSIRTs and SPs is essential when responding to a security-related incident, which may cross network access points between service providers. As a result of the urgency involved in this inter-service-provider security incident communication, there must be an effective system in place to facilitate the interaction. This communication policy or method should involve multiple means of communication to avoid a single
在响应可能跨越服务提供商之间的网络接入点的安全相关事件时，加快CSIRT和SP之间的通信至关重要。由于这种服务提供商间安全事件通信涉及的紧迫性，必须有一个有效的系统来促进交互。该沟通策略或方法应包括多种沟通方式，以避免单一的
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 like RID.
故障点。电子邮件是传递有关事件、数据包跟踪等信息的一种方式。但是，电子邮件可能无法及时接收，或与电话或其他通信机制（如RID）一样紧急处理。
A technical solution to trace traffic across a single SP may include homegrown or commercial systems for which RID messaging must accommodate the input requirements. The incident-handling system used on the SP's backbone by the CSIRT to coordinate the trace across the single network requires a method to accept, process, and relay RID messages 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 service provider maintains its own system capable of communicating via RID and integrates with a management station used for monitoring and analysis. An alternative for providers lacking sufficient resources may be to have a neutral third party with access to the provider'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 countries as a whole or within a consortium that may be able to provide centralized resources.
跨单个SP跟踪流量的技术解决方案可能包括国产或商用系统，RID消息必须满足这些系统的输入要求。CSIRT在SP主干上使用的事件处理系统用于协调单个网络中的跟踪，需要一种方法来接受、处理RID消息并将其中继到系统，以及等待系统的响应以继续RID请求过程（视情况而定）。在此场景中，每个服务提供商都维护自己的系统，该系统能够通过RID进行通信，并与用于监控和分析的管理站集成。对于缺乏足够资源的供应商，另一种选择可能是让一个中立的第三方访问供应商的网络资源，该第三方可用于执行事件处理功能。这可能是一个中央组织的职能，该组织作为一个CSIRT为整个国家运作，或在一个能够提供集中资源的财团内运作。
Consortiums could consist of a federation or a group of service providers or CSIRTs that agrees 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 [RFC6546].
联盟可以由一个联盟或一组服务提供商或CSIRT组成，这些服务提供商或CSIRT同意使用商定的策略和通信协议参与RID通信协议，以促进IODEF-RID XML文档的安全传输。[RFC6546]中指定了RID消息的传输。
One goal of RID is to prevent the need to permit access to other networks' equipment. RID provides a standard messaging mechanism to enable the communication of incident-handling information to other providers 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 providers. 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 providers to maintain full management of their network, and the third-party option could be available to smaller providers who lack the necessary human resources to perform incident-handling operations. The first method enables the individual providers to involve (via a notification and alerting system) their network operations staff to authorize the continuance of a trace or other necessary response to a RID communication request through their network.
RID的一个目标是防止需要允许访问其他网络的设备。RID提供了一种标准的消息传递机制，可以将事件处理信息传递给联合体或相邻网络中的其他提供商。上述第三方可用于本技术解决方案，以协助促进事件处理，并可能通过较小的供应商进行追溯。RID消息传递机制可以是逻辑或物理带外网络，以确保通信安全且不受受攻击网络状态的影响。这两种管理方法将满足大型供应商对其网络进行全面管理的需要，对于缺乏必要人力资源来执行事故处理操作的小型供应商，可以使用第三方选项。第一种方法使各个提供商能够（通过通知和警报系统）让其网络操作人员通过其网络授权继续跟踪或对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 (virtual or physical) between peers who have agreed-upon use and abuse policies through a consortium. Consortiums might be linked through policy comparisons 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 or is based on regions and logical groups. 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消息的加密信道。通信链路将是通过联盟商定使用和滥用政策的对等方之间的直接连接（虚拟或物理）。联盟可以通过策略比较和附加协议进行链接，以形成一个更大的对等网络或迭代网络，该对等网络与更大的网络网络上可用的流量路径相关，或基于区域和逻辑组。联系信息、RID系统的IP地址和其他信息必须由联合体在双边对等方之间协调，并且可以使用现有数据库，如路由仲裁器。RID消息传递对等方的安全、配置和信心评级方案必须由对等方协商，并且必须通过对等和/或基于联盟的协议满足完全连接网络（互联网、政府、教育等）的某些总体要求。
RID messaging established with clients of an provider 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 peering or service level agreements.
与提供商的客户端建立的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 U.S. Federal Bureau of Investigations (FBI) or other assisting government organization in the country of the investigation.
需要制定事件处理程序，并让可能参与事件响应的任何人熟知。该程序还应包含内部上报程序以及外部援助小组的联系信息，如CSIRT、CERT协调中心（CERT/CC）、全球信息保障认证（GIAC）和美国联邦调查局（FBI）或调查所在国的其他协助政府组织。
RID provides a protocol and format that ensures interoperability between vendors for the implementation of an incident messaging mechanism. The messages should 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.2 are necessary to facilitate the handling of a security incident. The message types include the Report, Query, Request, Acknowledgement, and Result message.
RID提供了一种协议和格式，可确保供应商之间的互操作性，以实现事件消息传递机制。这些消息应该满足几个要求，以便在穿越多个网络时具有意义。RID为参与事件处理、可能的回溯和安全事件缓解的网络之间的通信提供了必要的框架。第4.2节中描述的几种消息类型对于促进安全事件的处理是必要的。消息类型包括报告、查询、请求、确认和结果消息。
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.
报告消息用于将事件归档到RID系统或相关数据库时，无需进一步操作。
A Query message is used to request information on a particular incident. A Request message with options set to 'TraceRequest' is used when the source of the traffic may have been spoofed. In that case, each SP in the upstream path who receives this Request will issue a trace across the network to determine the upstream source of the traffic. The Acknowledgement and Result messages are used to communicate the status and result of a Request. The Request message with options set to 'InvestigationRequest' may be sent to any party assisting in an incident investigation. The InvestigationRequest 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 InvestigationRequest. A Request message (set to 'TraceRequest' or 'InvestigationRequest') sent between RID systems to stop traffic at the source through a bordering network requires the information enumerated below:
查询消息用于请求有关特定事件的信息。当流量源可能已被欺骗时，使用选项设置为“TraceRequest”的请求消息。在这种情况下，接收此请求的上游路径中的每个SP将通过网络发出跟踪，以确定流量的上游来源。确认和结果消息用于传达请求的状态和结果。选项设置为“调查请求”的请求消息可发送给协助事件调查的任何一方。调查请求利用双边关系或联合体的互连来缓解或停止靠近源头的问题流量。在调查请求的情况下，路由可以确定到已知源IP地址的最快路径。在RID系统之间发送的请求消息（设置为“TraceRequest”或“InvestigationRequest”），用于通过边界网络在源处停止通信，需要以下列举的信息：
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 Request with MsgType set to 'TraceRequest' that contains 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系统接收到MsgType设置为“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 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 or 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
通信网络和RID协议的使用必须仅用于预先批准和授权的目的。各参与方有责任遵守通过对等协议为各双边对等方制定的全球使用政策或商定的联合体指南中规定的指南。这些政策的目的是避免滥用该制度；政策应由联合体或参与实体制定。全球政策可能取决于其运营所在的领域；例如，政府网络或商业网络，如互联网
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 Requirements section, along with other requirements that must be agreed upon by participating entities.
将遵循不同的指导方针来解决个人问题。在公共网络（如互联网）中必须考虑隐私问题。隐私问题在“安全要求”一节中讨论，以及必须由参与实体商定的其他要求。
RID requests must be legitimate incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system includes 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 enables a network manager to assess the available resources before continuing a Request message set to 'InvestigationRequest' or 'TraceRequest'. If the Confidence rating (provided in IODEF) is low, it may not be in the provider's best interest to continue the Request with options set to 'InvestigationRequest' or 'TraceRequest'. The Confidence ratings must adhere to the specifications for selecting the percentage used to avoid abuse of the system. Requests must be issued by authorized individuals from the initiating CSIRT, set forth in policy guidelines established through peering or a SLA.
RID系统应可配置为需要用户输入或自动继续跟踪。此功能使网络管理器能够在继续将请求消息设置为“调查请求”或“跟踪请求”之前评估可用资源。如果信心评级（在IODEF中提供）较低，则在选项设置为“调查请求”或“追踪请求”的情况下继续请求可能不符合提供者的最佳利益。置信度评级必须符合选择百分比的规范，以避免滥用系统。请求必须由发起CSIRT的授权人员发出，这在通过对等或SLA建立的策略指南中有所规定。
The most basic topology for communicating RID systems is a direct connection or a bilateral relationship as illustrated below.
RID系统通信的最基本拓扑是直接连接或双边关系，如下所示。
___________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | SP Border | |________|
-------------
___________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | SP 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 looks 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,
在联合体模型中，可以商定并使用几种拓扑结构。一种是利用联合体成员的双边网络对等关系。RID的对等点将与路由对等点的对等点匹配，并且将使用逻辑网络边界。对于源未知的迭代跟踪，这种方法可能是必要的。模型如上图所示；然而，双边关系可能会形成大量的相互联系。同样在联合体模型中，建立一个集成的网络网格来传递RID消息可能是有用的。当源地址已知时，这可能是有益的，
and an interconnection may provide a faster route to reach the closest upstream peer to the source of the attack traffic if direct communication between SPs is not possible. An example is illustrated below.
并且，如果SP之间不可能直接通信，则互连可提供更快的路由以到达距离攻击流量源最近的上游对等方。下面举例说明。
_______ _______ _______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | SP Border | |_____| | SP Border | |_____|
| ------------- ------------- |
|_______________________________________________________|
_______ _______ _______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | SP Border | |_____| | SP 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 Request that may have also been unnecessary.
通过在联合体中使用全网格模型，广播RID请求是可能的，但不可取。通过广播请求，可能未在其网络上承载攻击流量的RID对等方将被要求执行跟踪，以减少识别真实来源的时间。因此，许多网络将利用不必要的资源来处理可能也不必要的请求。
A star topology may be desirable in instances where a peer may be a provider of incident information. This requires trust relationships to be established between the provider of information and each of the consumers of that information. Examples may include country-level CSIRTs or service providers distributing incident information to organizations.
在对等方可能是事件信息提供者的情况下，星形拓扑可能是可取的。这需要在信息提供者和该信息的每个消费者之间建立信任关系。示例可能包括国家级CSIRT或向组织分发事件信息的服务提供商。
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. Note that there are two lexical representations for boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or FALSE.
布尔数据类型在模式中实现为“xs:BOOLEAN”[XMLschema]。请注意，[XMLschema]中的布尔值有两种词汇表示法：'1'或'true'表示true，'0'或'false'或false。
The five RID message types described below MUST be implemented. RID messages uses both the IODEF [RFC5070] and RID document, which MUST be encapsulated for transport as specified in [RFC6546]. The messages are generated and received on designated systems for RID communications. Each RID message type, along with an example, is described in the following sections. The IODEF-RID schema is introduced in Section 5 to support the described RID message types.
必须实现下面描述的五种RID消息类型。RID消息同时使用IODEF[RFC5070]和RID文档，必须按照[RFC6546]中的规定对其进行封装以进行传输。消息在指定的RID通信系统上生成和接收。以下各节将介绍每种RID消息类型以及一个示例。第5节介绍了IODEF-RID模式，以支持所描述的RID消息类型。
1. Request. This message type is used when a request ('InvestigationRequest' or 'TraceRequest') is needed. The purpose of the Request message (set to 'InvestigationRequest') is to leverage the existing peer relationships in order to notify the SP closest to the source of the valid traffic of a security-related incident for any necessary actions to be taken. The Request (set to 'TraceRequest') is used when the traffic has to be traced iteratively through networks to find the source by setting the MsgType to 'TraceRequest'. The 'InvestigationRequest' MsgType is used for all other Request messages.
1. 要求此消息类型在需要请求（“调查请求”或“跟踪请求”）时使用。请求消息（设置为“调查请求”）的目的是利用现有的对等关系，以便将安全相关事件的有效通信量通知离源最近的SP，以便采取任何必要的措施。当必须通过网络迭代跟踪流量以通过将MsgType设置为“TraceRequest”来查找源时，使用请求（设置为“TraceRequest”）。“调查请求”MsgType用于所有其他请求消息。
2. Acknowledgement. This message is sent to the initiating RID system from each of the upstream provider's RID systems to provide information on the status of a Request. The Acknowledgement is also used to provide a reason why a Request, Report, or Query was not accepted.
2. 确认此消息从每个上游提供商的RID系统发送到发起RID系统，以提供请求状态的信息。确认还用于提供请求、报告或查询未被接受的原因。
3. Result. The Result message is used to provide a final report and the notification of actions taken for a Request. This message is sent to the initiating CSIRT through the network of RID systems in the path of the trace as notification that the source of the attack was located.
3. 后果结果消息用于提供最终报告和针对请求采取的操作通知。此消息通过跟踪路径中的RID系统网络发送给发起CSIRT，作为攻击源所在位置的通知。
4. 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, sharing incident information, statistics and trending information, etc.
4. 汇报此消息用于报告未请求任何操作的安全事件。这可用于通过CSIRT关联攻击信息、共享事件信息、统计数据和趋势信息等。
5. Query. This message is used to request information about an incident or incident type from a trusted system communicating via RID. The response is provided through the Report message.
5. 查询此消息用于从通过RID通信的受信任系统请求有关事件或事件类型的信息。通过报告消息提供响应。
When an application 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
当应用程序收到RID消息时，它必须能够确定消息的类型并相应地对其进行解析。消息类型在RIDPolicy类中指定。RIDPolicy类可以
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.
传输协议还可以使用这些数据来促进安全事件数据的通信，以跟踪、调查、查询或报告有关安全事件的信息。
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 Request message; 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类用于指示请求消息的批准状态；IncidentSource类用于报告是否找到源，并识别源主机或网络；RIDPolicy类提供有关商定策略的信息，并指定正在使用的通信消息的类型。
The RID schema defines communication-specific metadata to support the exchange of incident information in an IODEF document. 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 and RID messages include both the RID and IODEF documents, the RID message acts as an envelope in that policy and security defined at the RID message layer are applied to both documents. One reason for maintaining separate schemas is for flexibility, where the RIDPolicy class can be easily extracted for use in the RID message and by the transport protocol.
RID模式定义特定于通信的元数据，以支持IODEF文档中事件信息的交换。维护单独的模式而不使用IODEF的附加数据扩展的目的是在RID主机之间发送消息的灵活性。由于RID是一个单独的模式，并且RID消息同时包含RID和IODEF文档，因此RID消息在该策略中充当信封，RID消息层定义的安全性将应用于这两个文档。维护单独模式的一个原因是为了灵活性，在这种情况下，可以轻松提取RIDPolicy类以用于RID消息和传输协议。
The security requirements of sending incident information between entities include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating out this data from the IODEF XML document removes the need for decrypting and parsing the IODEF document to determine how it should be handled at each RID host.
在实体之间发送事件信息的安全要求包括使用加密。RIDPolicy信息不需要加密，因此将这些数据从IODEF XML文档中分离出来就不需要解密和解析IODEF文档，以确定在每个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 security requirements and policy guidelines are discussed in Section 9. The policy is defined between RID peers and within or between consortiums. 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.
第9节讨论了安全要求和政策指南。该策略在RID对等方之间以及联盟内部或联盟之间定义。RIDPolicy是一种促进已定义策略的工具。这必须根据客户、同行、联盟和/或地区之间的政策设置使用。必须按照本文件的规定考虑安全性、隐私性和保密性。
The RID schema is defined as follows:
RID模式定义如下：
+------------------+
| RID |
+------------------+
| |
| ENUM lang |<>---{0..1}----[ RIDPolicy ]
| |
| |<>---{0..1}----[ RequestStatus ]
| |
| |<>---{0..1}----[ IncidentSource ]
+------------------+
+------------------+
| RID |
+------------------+
| |
| ENUM lang |<>---{0..1}----[ RIDPolicy ]
| |
| |<>---{0..1}----[ RequestStatus ]
| |
| |<>---{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 Acknowledgement messages. The message reports back to the CSIRT or SP in the Acknowledgement message to provide status on a Request or if an error or problem occurs with the receipt or processing of a Report, Query, or Result message.
零或一。RequestStatus类仅在确认消息中使用。该消息在确认消息中向CSIRT或SP报告，以提供请求状态，或者在接收或处理报告、查询或结果消息时出现错误或问题。
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 [RFC6546], 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 [RFC6546].
列出的三个类中的每一个都可能是RID类中包含的唯一类，因此可以选择0或1。在某些情况下，当由传输协议[RFC6546]使用时，RIDPolicy可能是RID定义中的唯一类，因为该信息应尽可能小，并且可能不会被加密。RequestStatus消息必须能够独立运行，而不需要IODEF文档来促进通信，从而将传输的数据限制在[RFC6546]要求的元素中。
The RID class has one attribute:
RID类有一个属性：
lang
朗
One. REQUIRED. ENUM. A valid language code per [RFC5646] constrained by the definition of "xs:language" inherited from [XML1.0].
一必修的。枚举。符合[RFC5646]的有效语言代码，受从[XML1.0]继承的“xs:language”定义的约束。
The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6546]. The RIDPolicy Class includes the ability to embed an IODEF document or XML documents that conform to schemas other than IODEF in the ReportSchema element.
RIDPolicy类有助于RID消息的传递，并且在传输文档[RFC6546]中也被用于传输。RIDPolicy类能够在ReportSchema元素中嵌入符合除IODEF之外的模式的IODEF文档或XML文档。
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
| |<>---{0..1}----[ ReportSchema ]
+------------------------+
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
| |<>---{0..1}----[ ReportSchema ]
+------------------------+
Figure 4: The RIDPolicy Class
图4：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, and the usage is determined by the MsgDestination attribute. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. See Section 11 of this document for Internationalization considerations.
一Node类用于标识主机或网络设备，在本例中用于标识传递RID消息的系统，其使用情况由msgdestation属性确定。此类的基本定义从IODEF规范[RFC5070]第3.16节中重新使用。国际化注意事项见本文件第11节。
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 include botnets, polymorphic attacks, 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 multiple selections from the attribute list in order to fit all possible policy considerations when crossing regions, consortiums, or networks.
一个或多个。必修的。属性“region”的值用于确定在批准跟踪之前可能需要考虑的策略领域。PolicyRegion可以包括属性列表中的多个选择，以便在跨越区域、联盟或网络时满足所有可能的策略考虑。
region
区域
One or many. REQUIRED. ENUM. The attribute region is used to identify the expected sharing range of the incident information. The region may be within a region or defined by existing relationships such as those of a consortium or a client to a service provider.
一个或多个。必修的。枚举。属性区域用于标识事件信息的预期共享范围。该区域可以位于某个区域内，也可以由现有关系定义，如联合体或客户与服务提供商的关系。
1. ClientToSP. A client initiated the request to their service provider (SP). A client may be an individual, enterprise, or other type of entity (government, commercial, education, etc.). An SP may be a network, telecommunications, infrastructure, or other type of SP where a client-to-vendor relationship has been established. The client-to-vendor relationship will typically have established contracts or agreements to define expectations and trust relationships.
1. ClientToSP。客户端向其服务提供商（SP）发起了请求。客户可以是个人、企业或其他类型的实体（政府、商业、教育等）。SP可以是网络、电信、基础设施或其他类型的SP，其中已建立了客户到供应商的关系。客户与供应商的关系通常会建立合同或协议，以定义期望和信任关系。
2. SPToClient. An SP initiated a RID request or report to a client. A client may be an individual, enterprise, or other type of entity (government, commercial, education, etc.). An SP may be a network, telecommunications, infrastructure, or other type of SP where a client-to-vendor relationship has been established. The client-to-vendor relationship will typically have established contracts or agreements to define expectations and trust relationships.
2. 间谍客户。SP向客户端发起RID请求或报告。客户可以是个人、企业或其他类型的实体（政府、商业、教育等）。SP可以是网络、电信、基础设施或其他类型的SP，其中已建立了客户到供应商的关系。客户与供应商的关系通常会建立合同或协议，以定义期望和信任关系。
3. IntraConsortium. Incident information that should have no restrictions within the boundaries of a consortium with the agreed-upon use and abuse guidelines. A consortium is a well-defined group with established members and trust relationships specific to sharing within that group. A consortium would typically define the types of data that can be shared in advance, define the expectations on protecting that data, as well as have established contractual agreements. Examples of consortiums may include industry-focused sharing communities (financial, government, research and education, etc.) or cross industry sharing communities (for instance, organizations within local proximity that form a sharing group).
3. 皮质内。按照约定的使用和滥用指南，在联合体范围内不应有任何限制的事件信息。联合体是一个定义明确的集团，拥有特定于该集团内部共享的既定成员和信任关系。联合体通常会定义可以提前共享的数据类型，定义对保护该数据的期望，以及建立合同协议。联合体的示例可能包括以行业为中心的共享社区（金融、政府、研究和教育等）或跨行业共享社区（例如，在当地附近形成共享组的组织）。
4. PeerToPeer. Incident information 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. PeerToPeer communications may involve any two individuals or entities that decide to share information directly with each other.
4. PeerToPeer。事件信息在两个对等方之间不应有任何限制，但可能需要进一步评估，然后才能根据商定的使用和滥用指南继续使用。对等通信可能涉及决定彼此直接共享信息的任何两个个人或实体。
5. BetweenConsortiums. Incident information that should have no restrictions between consortiums that have established agreed-upon use and abuse guidelines. BetweenConsortiums is used when two consortiums (as defined in IntraConsortium above) share data. The types of data that can be shared BetweenConsortiums should be identified in their agreements and contracts along with expectations on how that data should be handled and protected.
5. 在球团之间。已制定一致使用和滥用指南的联合体之间不应有任何限制的事件信息。当两个财团（定义见上文Cortium）共享数据时，使用BetweenCortium。各团体之间可以共享的数据类型应在其协议和合同中加以确定，并说明应如何处理和保护这些数据。
6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
6. 外部值。用于扩展此属性的转义值。见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 SP 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 most accurately describes the traffic type.
一个或多个。必修的。属性“type”的值用于帮助确定跟踪是否适合接收继续跟踪请求的SP。可为该元素选择多个值；但是，在可能的情况下，应将其限制为最准确描述流量类型的一个值。
type
类型
One or many. REQUIRED. ENUM. The attribute type is used to identify the type of information included in the RID message or the type of incident.
一个或多个。必修的。枚举。属性类型用于标识RID消息中包含的信息类型或事件类型。
1. Attack. This option SHOULD only be selected if the traffic is related to an information security incident or 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 network traffic or routing issues.
2. 网络只有当跟踪与网络流量或路由问题相关时，才必须选择此选项。
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 be used for determining what sources or destinations accessed certain materials available on the Internet, including, but not limited to, news, technology, or inappropriate content.
3. 所容纳之物只有在请求与内容相关且存在访问该类型内容的区域限制的情况下，才能使用该类别。这不是恶意流量，但可用于确定哪些来源或目的地访问了互联网上的某些可用材料，包括但不限于新闻、技术或不适当的内容。
4. DataWithHandlingRequirements. This option is used when data shared may have additional restrictions for handling, protection, and processing based on the type of data and where it resides. Regulatory or legal restrictions may be imposed on specific types of data that could vary based on the location, region or nation, of the data or where it originated. The IODEF document, as well as any extensions, included with the RID message should indicate the specific restrictions to be considered. The use of this enumeration flag is not legally binding.
4. 具有处理要求的数据。当共享的数据根据数据类型及其所在位置可能对处理、保护和处理有其他限制时，使用此选项。可能会对特定类型的数据施加监管或法律限制，这些限制可能因数据的位置、地区或国家或来源而有所不同。RID消息中包含的IODEF文档以及任何扩展都应指明要考虑的特定限制。此枚举标志的使用不具有法律约束力。
5. AudienceRestriction. This option is used to indicate that the message contains data that should be viewed by a restricted audience. This setting should not be used for normal incidents or reporting as it could slow response times. The content may be a business-relevant notification or request. This option MAY be used by a business partner to report or request assistance if an incident has affected a supply chain. This option may also be used if the content is relevant to regulatory obligations, legal (eDiscovery), or other use cases that require management attention.
5. 听力限制。此选项用于指示消息包含应被受限受众查看的数据。此设置不应用于正常事件或报告，因为它可能会减慢响应时间。内容可以是与业务相关的通知或请求。如果事件影响了供应链，业务合作伙伴可以使用此选项报告或请求协助。如果内容与监管义务、法律（eDiscovery）或其他需要管理层注意的用例相关，也可以使用此选项。
6. 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 investigation. The information should be provided in the IODEF message in the Expectation class or in the History class using a HistoryItem log. This may also be used for incident types other than information-security-related incidents.
6. 另外如果选择此选项，则必须提供交通类型的说明，以便做出继续或停止调查的政策决定。应该在Expectation类或History类的IODEF消息中使用HistoryItem日志提供信息。这也可用于信息安全相关事件以外的事件类型。
7. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
7. 外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
ReportSchema
报表模式
Zero or One. The ReportSchema class is used by the message types that require the full IODEF schema to be included in the RID envelope. Alternate schemas may be included if approved by the Designated Reviewer and registered by IANA for use with RID.
零或一。ReportSchema类由需要在RID信封中包含完整IODEF架构的消息类型使用。如果指定审核人批准并由IANA注册以与RID一起使用，则可包括备用模式。
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类型
One. REQUIRED. ENUM. The type of RID message sent. The five types of messages are described in Section 4.2 and can be noted as one of the six selections below, where a Request is set to either 'InvestigationRequest' or 'TraceRequest'.
一必修的。枚举。发送的RID消息的类型。第4.2节描述了这五种类型的消息，可将其作为以下六种选择之一，其中请求设置为“调查请求”或“追踪请求”。
1. TraceRequest. This Request 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. Acknowledgement. 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. InvestigationRequest. This Request message type is used when the source of the traffic is believed to be valid. The purpose of the InvestigationRequest is to leverage the existing peer or consortium relationships in order to notify the SP closest to the source of the valid traffic that some event occurred, which may be a security-related incident.
4. 调查请求。当认为流量源有效时，使用此请求消息类型。调查请求的目的是利用现有的对等或联盟关系，以便通知最接近有效流量来源的SP发生了某些事件，可能是安全相关事件。
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, gathering statistics and trending information, etc.
5. 汇报此消息用于报告IODEF预期类中未请求任何操作的安全事件。这可用于通过CSIRT关联攻击信息、收集统计数据和趋势信息等。
6. Query. 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
One. 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 a Request with MsgType set to 'InvestigationRequest', the source of the incident. In the case of an InvestigationRequest, 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消息传递系统，或者，如果请求的MsgType设置为“调查请求”，则可能是事件源。在调查请求的情况下，可能不知道可帮助停止或缓解流量的RID系统，并且消息可能必须通过遵循到最接近攻击流量源的RID系统的路由路径来穿越RID消息传递系统。Node元素列出RID系统或源的IP地址，Node元素中值的含义由msgdestation元素确定。
1. RIDSystem. The IP address of the next upstream system accepting RID communications is REQUIRED and is listed in the Node element of the RIDPolicy class. If NodeName element of the Node class is used, it contains a DNS domain name. The originating RID system is required to check that this domain name resolves to the IP address to which the RID message is sent. This check may be performed in advance of sending the message and the result saved for future use with additional RID messages.
1. RIDSystem。需要接受RID通信的下一个上游系统的IP地址，该地址列在RIDPolicy类的Node元素中。如果使用节点类的NodeName元素，则它包含DNS域名。发起RID系统需要检查此域名是否解析为RID消息发送到的IP地址。可以在发送消息之前执行此检查，并将结果与其他RID消息一起保存以备将来使用。
2. SourceOfIncident. The Address element of the Node element contains the IP address of the incident source, and the NodeName element of the Node class is not used. The IP address is REQUIRED when this option is selected. The IP address is used to determine the path of systems accepting RID communications 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 a Request message with MsgDestination set to 'InvestigationRequest' is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial Request ('InvestigationRequest' or 'TraceRequest'), not the source used in a Result message.
2. 事故的根源。Node元素的Address元素包含事件源的IP地址，不使用Node类的NodeName元素。选择此选项时，需要IP地址。IP地址用于确定接受RID通信的系统的路径，该通信将用于查找距离攻击源最近的RID系统，其中源使用的IP地址被认为是有效的，并且使用MsgDestination设置为“调查请求”的请求消息。不要将其与IncidentSource类混淆，因为此处定义的值来自初始请求（“调查请求”或“跟踪请求”），而不是结果消息中使用的源。
3. ext-value. An escape value used to extend this attribute. All extensions shall specify the contents and meaning of the Node element of RIDPolicy. See IODEF [RFC5070], Section 5.1, on extensibility. If the NodeName element of the Node class is used by an extension, NodeName may contain an Internationalized Domain Name (IDN); see Section 11 for applicable requirements. All extensions SHOULD use an IP address in the Address element of the Node class as the primary means of Node identification.
3. 外部值。用于扩展此属性的转义值。所有扩展应规定RIDPolicy节点元素的内容和含义。关于可扩展性，参见IODEF[RFC5070]，第5.1节。如果节点类的NodeName元素由扩展使用，NodeName可能包含国际化域名（IDN）；适用要求见第11节。所有扩展都应在节点类的address元素中使用IP地址作为节点标识的主要手段。
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 ReportSchema class is an aggregate class in the RIDPolicy class. The IODEF schema is the approved schema for inclusion in RID messages via the ReportSchema class.
ReportSchema类是RIDPolicy类中的聚合类。IODEF模式是通过ReportSchema类批准包含在RID消息中的模式。
+-------------------------+
| ReportSchema |
+-------------------------+
| |
| ENUM Version |
| STRING ext-Version |<>---{1}-------[ XMLDocument ]
| ENUM XMLSchemaID |
| STRING ext-XMLSchemaID |<>---{0..1}----[ URL ]
| |
| |<>---{0..*}----[ Signature ]
| |
+-------------------------+
+-------------------------+
| ReportSchema |
+-------------------------+
| |
| ENUM Version |
| STRING ext-Version |<>---{1}-------[ XMLDocument ]
| ENUM XMLSchemaID |
| STRING ext-XMLSchemaID |<>---{0..1}----[ URL ]
| |
| |<>---{0..*}----[ Signature ]
| |
+-------------------------+
Figure 5: The ReportSchema Class
图5:ReportSchema类
The elements that constitute the ReportSchema class are as follows:
构成ReportSchema类的元素如下所示：
XMLDocument
XML文档
One. The XMLDocument is a complete XML document defined by the iodef:ExtensionType class. This class follows the guidelines in [RFC5070], Section 5, where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document.
一XMLDocument是由iodef:ExtensionType类定义的完整XML文档。此类遵循[RFC5070]第5节中的指导原则，其中数据类型设置为“xml”，含义设置为“xml”，以包含xml文档。
URL
统一资源定位地址
Zero or One. URL. A reference to the XML schema of the XML document included. The URL data type is defined in [RFC5070], Section 2.15, as "xs:anyURI" in the schema. The schemaLocation for IODEF is already included in the RID schema, so this is not necessary to include a URL for IODEF documents. The list of registered schemas for inclusion will be maintained by IANA.
零或一。网址。包含对XML文档的XML模式的引用。URL数据类型在[RFC5070]第2.15节中定义为模式中的“xs:anyURI”。IODEF的schemaLocation已包含在RID架构中，因此不必包含IODEF文档的URL。IANA将维护要包含的已注册架构列表。
Signature
签名
Zero to many. The Signature uses the iodef:ExtensionType class to enable this element to contain a detached or enveloped signature. This class follows the guidelines in [RFC5070] Section 5 where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document. This element is used to encapsulate the detached signature based on the iodef: RecordItem class within the IODEF document to verify the originator of the message or to include the enveloped signature. If other schemas are used instead of IODEF, they MUST provide guidance on what class to use if a detached signature is provided for this purpose.
零对多。签名使用iodef:ExtensionType类使该元素能够包含分离或封装的签名。此类遵循[RFC5070]第5节中的指导原则，其中数据类型设置为“xml”，含义设置为“xml”，以包含xml文档。此元素用于在iodef文档中封装基于iodef:RecordItem类的分离签名，以验证消息的原始发件人或包含封装的签名。如果使用其他模式而不是IODEF，则它们必须提供关于在为此目的提供分离签名时使用哪个类的指导。
The ReportSchema class has four attributes:
ReportSchema类有四个属性：
Version
版本
OPTIONAL. One. The Version attribute is the version number of the specified XML schema. That schema must be an approved version of IODEF or a schema registered with IANA for use with RID. The IANA registry for managing schemas other than IODEF is specified in Section 12.
可选择的一Version属性是指定XML架构的版本号。该模式必须是IODEF的批准版本，或者是在IANA注册的用于RID的模式。第12节指定了用于管理IODEF以外的模式的IANA注册表。
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
ext-Version
外部版本
OPTIONAL. One. The ext-Version attribute is the version number of the included XML schema. This attribute is used if a schema other than IODEF or an IANA-registered schema that has been added to the enumerated list for Version is included.
可选择的一ext Version属性是包含的XML架构的版本号。如果包含IODEF以外的架构或已添加到版本枚举列表的IANA注册架构，则使用此属性。
XMLSchemaID
XMLSchemaID
OPTIONAL. One. The XMLSchemaID attribute is the identifier, the defined namespace [XMLNames], of the XML schema of the XML document included. The XMLSchemaID and Version specify the format of the XMLDocument element. The only permitted values, include the namespace for IODEF [RFC5070], "urn:ietf:params:xml:ns:iodef-1.0", any future IETF-approved versions of IODEF, and any namespace included in the IANA-managed list of registered schemas for use with RID. The IANA registry for managing schemas other than IODEF is specified in Section 12.
可选择的一XMLSchemaID属性是包含的XML文档的XML模式的标识符，即定义的命名空间[XMLNames]。XMLSchemaID和Version指定XMLDocument元素的格式。唯一允许的值包括IODEF的名称空间[RFC5070]、“urn:ietf:params:xml:ns:IODEF-1.0”、任何未来ietf批准的IODEF版本，以及IANA管理的注册架构列表中包含的任何名称空间，以便与RID一起使用。第12节指定了用于管理IODEF以外的模式的IANA注册表。
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
外部值。用于扩展此属性的转义值。见IODEF[RFC5070]，第5.1节。
ext-XMLSchemaID
extxmlschemaid
OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier (defined namespace) of the XML schema of the XML document included. The ext-XMLSchemaID and ext-Version specify the format of the XMLDocument element and are used if the included schema is not IODEF version 1.0 or an IANA-registered schema that has been added to the enumerated list for XMLSchemaID.
可选择的一ext XMLSchemaID属性是包含的XML文档的XML模式的标识符（定义的命名空间）。ext XMLSchemaID和ext Version指定XMLDocument元素的格式，如果包含的架构不是IODEF 1.0版或已添加到XMLSchemaID枚举列表中的IANA注册架构，则使用ext XMLSchemaID和ext Version。
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 6: The RequestStatus Class
图6: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
授权状态
One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query.
一必修的。枚举。列出的值用于向请求CSIRT提供请求、报告或查询状态的响应。
1. Approved. The trace was approved and will begin in the current SP.
1. 经核准的。跟踪已批准，将在当前SP中开始。
2. Denied. The trace was denied in the current SP. The next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class.
2. 否认。跟踪在当前SP中被拒绝。下一个最近的SP可以使用此消息过滤来自上游SP的流量，使用示例数据包帮助尽可能靠近源减轻攻击的影响。必须将确认消息传回发起人，并且必须从距离源最近的SP使用结果消息，以指示在IODEF历史记录类中采取的操作。
3. Pending. Awaiting approval; a timeout period has been reached, which resulted in this Pending status and Acknowledgement message being generated.
3. 悬而未决的等待批准；已达到超时时间，导致生成此挂起状态和确认消息。
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 RecordItem entry failed to validate.
3. 认证来源。RecordItem条目上原始请求者的分离数字签名无法验证。
4. Encryption. The recipient was unable to decrypt the request, report, or query.
4. 加密。收件人无法解密请求、报告或查询。
5. UnrecognizedFormat. The format of the provided document was unrecognized.
5. 无法识别的格式。无法识别所提供文档的格式。
6. CannotProcess. The document could not be processed. Reasons may include legal or policy decisions. Resolution may require communication outside of this protocol to resolve legal or policy issues. No further messages SHOULD be sent until resolved.
6. 无法处理。无法处理该文档。原因可能包括法律或政策决定。解决可能需要本协议之外的沟通来解决法律或政策问题。在解决之前，不应再发送任何消息。
7. Other. There were other reasons this request could not be processed.
7. 另外无法处理此请求还有其他原因。
8. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
8. 外部值。用于扩展此属性的转义值。见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 7: The IncidentSource Class
图7: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
节点
Zero or many. The Node class is used to identify a system identified as part of an incident. If this element is used, the Address element of the Node element MUST contain the IP address of the system. If the NodeName element of the Node class is used, it contains a DNS domain name that has been checked to ensure that it resolved to that IP address when the check was performed. See Section 11 of this document for internationalization considerations for NodeName. The base definition of this class from the IODEF ([RFC5070], Section 3.16) can be expanded to include other identifiers.
零或多。节点类用于标识被标识为事件一部分的系统。如果使用此元素，则Node元素的Address元素必须包含系统的IP地址。如果使用节点类的NodeName元素，则它包含一个DNS域名，该域名已被检查，以确保在执行检查时将其解析为该IP地址。有关NodeName的国际化注意事项，请参见本文档第11节。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 RID schema declares a namespace of "urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per [RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0" namespace in the top-level element RID-Document. It can be referenced as follows:
RID模式声明了一个名称空间“urn:ietf:params:xml:ns:iodef-RID-2.0”，并根据[RFC3688]注册它。每个IODEF-RID文档必须在顶级元素RID文档中使用“IODEF-RID-2.0”命名空间。可参考如下：
<RID-Document version="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
<RID-Document version="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
RID documents MUST begin with an XML declaration and MUST specify the XML version used; also, the use of UTF-8 encoding is REQUIRED ([RFC3470], Section 4.4). RID conforms to all XML data encoding conventions and constraints.
RID文档必须以XML声明开头，并且必须指定使用的XML版本；此外，还需要使用UTF-8编码（[RFC3470]，第4.4节）。RID符合所有XML数据编码约定和约束。
The XML declaration with no character encoding will read as follows:
没有字符编码的XML声明将如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
The following characters have special meaning in XML and MUST be escaped with their entity reference equivalent: "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). These entity references are "&", "<", ">", """, and "'", respectively.
以下字符在XML中具有特殊含义，必须使用其实体引用等效项进行转义：“&”、“<”、“>”、“\”（双引号）和“'”（撇号）。这些实体引用是“&；“，”<；“，”>；“，”；“、和”&apos；“分别。
In order to support the changing activity of CSIRTS, the RID schema can include an IODEF or other data model. The IODEF is also extensible, enabling the schemas to evolve along with the needs of CSIRTs. This section discusses how to include the IODEF XML document or other XML documents to leverage the security and trust
为了支持CSIRT不断变化的活动，RID模式可以包括IODEF或其他数据模型。IODEF也是可扩展的，使模式能够随着CSIRT的需求而发展。本节讨论如何包含IODEF XML文档或其他XML文档以利用安全性和信任
relationships established through the use of RID. These techniques are designed so that adding new data will not require a change to the RID schema. This approach also supports the exchange of private XML documents relevant only to a closed consortium. XML documents can be included through the ReportSchema class in the RIDPolicy class. The XMLDocument attribute is set to 'xml' to allow for the inclusion of full IODEF or other XML documents. The following guidelines MUST be followed:
通过使用RID建立的关系。这些技术的设计使得添加新数据不需要更改RID模式。这种方法还支持仅与封闭联盟相关的私有XML文档的交换。XML文档可以通过RIDPolicy类中的ReportSchema类包含。XMLDocument属性设置为“xml”，以允许包含完整的IODEF或其他xml文档。必须遵循以下准则：
1. The included schema MUST define a separate namespace, such as the declared namespace for IODEF of "urn:ietf:params:xml:ns:iodef-1.0".
1. 包含的模式必须定义一个单独的名称空间，例如为IODEF声明的名称空间“urn:ietf:params:xml:ns:IODEF-1.0”。
2. When a parser encounters an included XML document it does not understand, the included document MUST be ignored (and not processed), but the remainder of the document MUST be processed. Parsers will be able to identify the XML documents for which they have no processing logic through the namespace declaration. Parsers that encounter an unrecognized element in a namespace that they do support SHOULD reject the document as a syntax error.
2. 当解析器遇到它不理解的包含的XML文档时，必须忽略（不处理）包含的文档，但必须处理文档的其余部分。解析器将能够通过名称空间声明识别它们没有处理逻辑的XML文档。如果解析器在其支持的命名空间中遇到无法识别的元素，则应将文档作为语法错误拒绝。
3. Implementations SHOULD NOT download schemas at runtime due to the security implications, and included documents MUST NOT be required to provide a resolvable location of their schema.
3. 由于安全问题，实现不应该在运行时下载模式，并且不需要包含的文档来提供模式的可解析位置。
The examples included in Section 7 demonstrate how an IODEF document is included. The included schema of IODEF is represented in ReportSchema as follows:
第7节中包含的示例演示了如何包含IODEF文档。包含的IODEF架构在ReportSchema中表示如下：
Version: "1.0"
版本：“1.0”
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"
URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"
The URL is optionally included for IODEF since it is already in the RID schema, and the schemaLocation is defined.
IODEF可以选择包含URL，因为它已经在RID模式中，并且已定义模式位置。
XML schemas may be registered for inclusion in a RID message. This may include schemas other than IODEF or updated versions of IODEF. The registered IANA information for additional schemas MUST include the specification name, version, specification Uniform Resource Identifier (URI), and namespace. The following provides an example of the necessary information for additional schemas beyond IODEF.
可以注册XML架构以包含在RID消息中。这可能包括IODEF或IODEF更新版本以外的模式。其他模式的注册IANA信息必须包括规范名称、版本、规范统一资源标识符（URI）和命名空间。下面提供了IODEF之外的其他模式的必要信息示例。
Example Name (XXXX)
示例名称（XXXX）
Schema Name: XXXX_1.1
Version: 1.1
Namespace: <registered namespace>
Specification URI: http://www.example.com/XXXX
Schema Name: XXXX_1.1
Version: 1.1
Namespace: <registered namespace>
Specification URI: http://www.example.com/XXXX
The version attribute of the ReportSchema class is populated with the approved versions of IODEF or any additional schemas registered by IANA; see Section 12.
ReportSchema类的version属性由IODEF的批准版本或IANA注册的任何其他模式填充；见第12节。
The XMLSchemaID of the ReportSchema class is populated with the namespace of the included schema. The attribute enumeration values include the namespace for IODEF and any schema registered by IANA; see Section 12.
ReportSchema类的XMLSchemaID由包含的架构的名称空间填充。属性枚举值包括IODEF的名称空间和IANA注册的任何模式；见第12节。
The URL element of the ReportSchema class is populated with the Specification URI value of the included schema.
ReportSchema类的URL元素由包含的模式的规范URI值填充。
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 for RID messages that include IODEF payloads to ensure proper parsing of those messages.
对于每种RID消息类型，遵循[RFC5070]中规定的IODEF模型。RID模式与IODEF文档结合使用，以促进RID通信。每种信息类型的格式和用途略有不同；因此，要求各不相同，并针对每种要求进行了规定。IODEF文档中定义的所有类、元素、属性等在RID消息上下文中有效；但是，在IODEF中列出的一些选项对于RID是必需的，因为每个消息类型都列出了这些选项。对于包含IODEF有效负载的RID消息，必须完全实现IODEF模型，以确保正确解析这些消息。
Note: The implementation of RID may automate the ability to fill in the content required for each message type from packet input, incident data, situational awareness information, or default values such as those used in the EventData class.
注意：RID的实现可以自动从数据包输入、事件数据、态势感知信息或默认值（如EventData类中使用的值）填充每种消息类型所需的内容。
Description: This message type is used to request assistance in a computer security investigation. The investigation request may be directed to another party that can assist with forensics and continue the investigation (the incident may have originated on the SP network to which the Request was sent), or it may be directed to an SP to trace the traffic from an unknown source. The Request message with MsgType set to 'InvestigationRequest' may leverage the existing bilateral peer relationships in order to notify the SP closest to the source of the valid traffic that some event occurred, which may be a
描述：此消息类型用于在计算机安全调查中请求协助。可以将调查请求发送给能够协助取证并继续调查的另一方（事件可能起源于请求发送到的SP网络），也可以发送给SP以跟踪未知来源的流量。MsgType设置为“调查请求”的请求消息可以利用现有的双边对等关系，以便通知最接近有效流量源的SP发生了某些事件，这可能是一个错误
security-related incident. A Request message with the MsgType set to 'TraceRequest' may be sent to an upstream peer to trace back through the network to locate the source of malicious traffic. The following information is REQUIRED for Request messages and is provided through the following data structures:
与安全有关的事件。MsgType设置为“TraceRequest”的请求消息可发送至上游对等方，以便通过网络回溯以定位恶意流量的来源。请求消息需要以下信息，并通过以下数据结构提供：
RID Information:
RID信息：
RIDPolicy
里德政策
RID message type, IncidentID, and destination policy information
RID消息类型、IncidentID和目标策略信息
IODEF Information:
IODEF信息：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID).
事件标识符（事件类别，IncidentID）。
Confidence rating of security incident (Impact and Confidence class).
安全事件的信心评级（影响和信心等级）。
System class is used to list both the Source and Destination.
系统类用于列出源和目标。
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 SP path contact information.
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息。注意：此处包含的事件信息需要EventData的第二个实例，而不是用于传递SP path联系人信息的实例。
Standards for encryption and digital signatures [RFC3275] [XMLsig] [XMLencrypt]:
加密和数字签名标准[RFC3275][XMLsig][XMLencrypt]：
Digital signature from initiating CSIRT or provider system sending the RID message, passed to all systems receiving the Request using a detached XML digital signature on a RecordItem entry, placed in an instance of the Signature element.
发起CSIRT或提供程序系统发送RID消息的数字签名，通过记录项条目上分离的XML数字签名传递给接收请求的所有系统，放置在签名元素的实例中。
Digital signature of sending CSIRT or SP for authenticity of the RID message, from the CSIRT or provider creating this message using an enveloped XML digital signature on the IODEF document, placed in an instance of the Signature element.
从CSIRT或提供者发送CSIRT或SP以确保RID消息的真实性的数字签名，该CSIRT或提供者使用IODEF文档上的封装XML数字签名创建此消息，并将其放置在签名元素的实例中。
XML encryption as required by policy, agreements, and data markers.
策略、协议和数据标记要求的XML加密。
Security requirements include the ability to encrypt [XMLencrypt] the contents of the Request message using the public key of the destination RID system. The incident number increases whether the Request message has the MsgDestination set to 'InvestigationRequest' or 'TraceRequest' in order to ensure uniqueness within the system. The relaying peers also append their Autonomous System (AS) or RID system information using the path information as the Request message was relayed through SPs. This enables the response (Result message) to utilize the same path and trust relationships for the return message, indicating any actions taken. The request is recorded in the state tables of both the initiating and destination SP RID systems. The destination SP is responsible for any actions taken as a result of the request in adherence to any service level agreements or policies. The SP MUST confirm that the traffic actually originated from the suspected system before taking any action and confirm the 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 MsgDestination of RIDPolicy set to 'SourceOfIncident'. Note: Any intermediate parties in a TraceRequest MUST be able to view RIDPolicy information of responding message types in order to properly direct RID messages.
安全要求包括使用目标RID系统的公钥对请求消息的内容进行[XMLencrypt]加密的能力。无论请求消息的MsgDestination设置为“调查请求”还是“跟踪请求”，事件编号都会增加，以确保系统内的唯一性。当请求消息通过SPs中继时，中继节点还使用路径信息附加其自治系统（AS）或RID系统信息。这使响应（结果消息）能够利用返回消息的相同路径和信任关系，指示所采取的任何操作。该请求记录在发起SP RID系统和目标SP RID系统的状态表中。目标SP负责根据任何服务级别协议或策略对请求采取的任何操作。SP必须在采取任何行动之前确认流量实际上来自可疑系统，并确认请求的原因。请求可以直接发送到已知的RID系统，也可以使用设置为“SourceOfIncident”的MsgDestination of RIDPolicy通过攻击源地址路由。注意：TraceRequest中的任何中间方都必须能够查看响应消息类型的策略信息，以便正确引导RID消息。
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 enables the administrators to determine if the exact trace already passed through a single network. The Incident Identifier must also be used to identify multiple Requests from a single incident. If a single Request results in divergent paths of Requests, 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攻击可以有多个来源，从而产生多个跟踪来定位攻击来源。为一次攻击继续多个跟踪可能是有效的。路径信息使管理员能够确定确切的跟踪是否已通过单个网络。事件标识符还必须用于识别来自单个事件的多个请求。如果单个请求导致请求路径不同，则必须在同一IncidentID下使用单独的实例号。IODEF的IncidentID实例号可用于关联作为较大事件一部分的相关事件数据。
Description: The Acknowledgement is also used to provide a status to any message type and to provide a Justification if the message could not be processed for any reason. This message is sent to the initiating RID system from the next upstream provider's application or system designated for accepting RID communications to provide information on the request status in the current SP.
说明：确认还用于向任何消息类型提供状态，并在消息因任何原因无法处理时提供理由。此消息从下一个上游提供商的应用程序或指定用于接受RID通信的系统发送到发起RID系统，以提供有关当前SP中请求状态的信息。
The following information is REQUIRED for Acknowledgement messages and is provided through the following data structures:
确认消息需要以下信息，并通过以下数据结构提供：
RID Information:
RID信息：
RIDPolicy
里德政策
RID message type, IncidentID, and destination policy information
RID消息类型、IncidentID和目标策略信息
RequestStatus class:
请求状态类：
Status of Request
请求的状态
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
加密和数字签名标准[RFC3275]、[XMLsig]、[XMLencrypt]：
Digital signature of responding CSIRT or provider for authenticity of Trace Status Message, from the CSIRT or provider creating this message using an enveloped XML digital signature.
响应CSIRT或提供者的数字签名，用于跟踪状态消息的真实性，来自使用封装XML数字签名创建此消息的CSIRT或提供者。
XML encryption as required by policy, agreements, and data markers.
策略、协议和数据标记要求的XML加密。
A message is sent back to the initiating CSIRT or provider's system; it accepts RID communications 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 CSIRT or provider's RID system. The Pending status is automatically generated after a 2-minute timeout without system-predefined or administrator action 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 provides the sending peer with the option to take action to stop or mitigate the traffic as close to the source as possible.
将消息发送回发起CSIRT或提供商的系统；它接受跟踪的RID通信作为状态通知。此消息验证路径中的下一个RID系统是否已从路径中的上一个系统接收到消息。此消息还验证跟踪现在是否在下一个上游CSIRT或提供商的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 is provided through the IncidentSource class. The Result information MUST go back to the originating RID system that began the investigation or trace. A provider 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系统。提供商可以使用任意数量的事件处理数据源来确定攻击的真实来源。所有可能的信息源可能会也可能不会很容易地连接到RID通信系统中。
The following information is REQUIRED for Result messages and will be provided through the following data structures:
结果消息需要以下信息，并将通过以下数据结构提供：
RID Information:
RID信息：
RIDPolicy
里德政策
RID message type, IncidentID, and destination policy information
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) or other Node information.
RID模式的IncidentSource类用于记录源是否已识别，并提供源地址或其他节点信息。
IODEF Information:
IODEF信息：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID).
事件标识符（事件类别，IncidentID）。
Trace number is used for multiple traces of a single incident; it MUST be included if the response is specific to an instance of an incident.
跟踪编号用于单个事件的多个跟踪；如果响应是特定于事件实例的，则必须包括该响应。
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 in RID an upstream Request set to 'TraceRequest'.
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 SP listed is the SP that located the source of the traffic (the provider sending the Result message).
嵌套RID系统的路径信息，从使用类别设置为“infrastructure”的IODEF EventData的跟踪中使用的请求发起人开始。列出的最后一个SP是定位流量源的SP（发送结果消息的提供商）。
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 SP path contact information.
事件、记录和记录项类，包括示例数据包和与事件相关的其他信息（可选）。注意：此处包含的事件信息需要EventData的第二个实例，而不是用于传递SP path联系人信息的实例。
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
加密和数字签名标准[RFC3275]、[XMLsig]、[XMLencrypt]：
Digital signature of source CSIRT or provider for authenticity of Result message, from the CSIRT or provider creating this message using an enveloped XML digital signature.
源CSIRT或提供者的数字签名，用于验证结果消息的真实性，来自使用封装XML数字签名创建此消息的CSIRT或提供者。
XML encryption as required by policy, agreements, and data markers.
策略、协议和数据标记要求的XML加密。
A message is sent back to the initiating CSIRT or provider's RID system to notify the 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 SP to act upon the discovery of the source of a trace should be included. The SP 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 and block all Internet access until the host has taken the appropriate action to resolve any security issues. The SP may be limited in their options for filtering due to agreements or other restrictions resulting in less comprehensive filters, such as rate-limiting the ingress traffic as close to the source as possible.
一条消息被发送回发起CSIRT或提供者的RID系统，以通知CSIRT已找到源。实际的源信息可能包括，也可能不包括，这取决于客户端或主机所连接的网络的策略。应包括SP为发现跟踪源而采取的任何行动。SP可能能够自动调整其边界路由器上的过滤器，以阻止作为攻击一部分发现的机器的出站访问。过滤器可能是全面的，在主机采取适当措施解决任何安全问题之前，会阻止所有Internet访问。由于协议或其他限制，SP的过滤选项可能会受到限制，从而导致不太全面的过滤器，例如尽可能靠近源的速率限制入口流量。
Security and privacy requirements discussed in Section 9 MUST be taken into account.
必须考虑第9节中讨论的安全和隐私要求。
Note: The History class has been expanded in IODEF to accommodate all of the possible actions taken as a result of a RID 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 Request is made.
注意：History类已在IODEF中展开，以容纳由于使用“IODEF:atype”或action type属性的RID请求而采取的所有可能操作。应使用History类记录在跟踪或事件源附近采取的所有操作，使用操作类型的最合适选项以及描述。Expectation类中的“atype”属性也可用于在发出请求时请求适当的操作。
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 the following data structures:
报告消息需要以下信息，并将通过以下数据结构提供：
RID Information:
RID信息：
RIDPolicy RID message type, IncidentID, and destination policy information
RID策略RID消息类型、IncidentID和目标策略信息
The following data is RECOMMENDED if available and can be provided through the following data structures:
如果可用，建议使用以下数据，并可通过以下数据结构提供：
IODEF Information:
IODEF信息：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID).
事件标识符（事件类别，IncidentID）。
Trace number is used for multiple traces of a single incident; it MUST be included if the Report is specific to an instance of an incident.
跟踪编号用于单个事件的多个跟踪；如果报告是针对某一事件的实例，则必须包括该报告。
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 are used to include example packets and other information related to the incident (optional).
事件、记录和记录项类用于包括示例数据包和与事件相关的其他信息（可选）。
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
加密和数字签名标准[RFC3275]、[XMLsig]、[XMLencrypt]：
Digital signature from initiating RID system, passed to all systems receiving the report using an enveloped XML digital signature, placed in an instance of the Signature element.
来自启动RID系统的数字签名，使用封装的XML数字签名传递给接收报告的所有系统，放置在签名元素的实例中。
XML encryption as required by policy, agreements, and data markers.
策略、协议和数据标记要求的XML加密。
Security requirements 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
安全要求包括能够使用目标RID系统的公钥对报告消息的内容进行[XMLencrypt]加密。报告消息的发送者应注意，该信息可用于关联安全事件信息，以便进行趋势分析、模式检测等，并可与其他方共享，除非与接收RID系统另有约定。因此，向缔约方发送报告
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 to respond to a Query, and data sensitivity must be considered in both cases. The SP path information is not necessary for this message, as it will be communicated directly between two trusted RID systems.
在发送报告消息之前，消息可能会混淆或删除目标地址或其他敏感信息。可以发送报告消息来提交事件报告或响应查询，在这两种情况下都必须考虑数据敏感性。此消息不需要SP路径信息，因为它将在两个受信任的RID系统之间直接通信。
Description: The Query 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 Query, the return report may be automated; otherwise, analyst intervention may be required.
描述：查询消息用于从受信任的RID系统请求事件信息。请求可以包括事件编号（如果已知）或事件的详细信息。如果已知事件编号，则可以使用自动方法将包含事件信息的报告消息轻松返回给受信任的请求者。如果查询中包括示例数据包或其他唯一信息，则返回报告可能是自动的；否则，可能需要分析师干预。
The following information is REQUIRED for a Query message and is provided through the following data structures:
查询消息需要以下信息，并通过以下数据结构提供：
RID Information:
RID信息：
RIDPolicy
里德政策
RID message type, IncidentID, and destination policy information
RID消息类型、IncidentID和目标策略信息
IODEF Information (optional):
IODEF信息（可选）：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
时间戳（检测时间、开始时间、结束时间、报告时间）。
Incident Identifier (Incident class, IncidentID).
事件标识符（事件类别，IncidentID）。
Trace number is used for multiple traces of a single incident; it MUST be included if the Query is an instance of an incident.
跟踪编号用于单个事件的多个跟踪；如果查询是事件的实例，则必须包含它。
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 are used to include example packets and other information related to the incident (optional).
事件、记录和记录项类用于包括示例数据包和与事件相关的其他信息（可选）。
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
加密和数字签名标准[RFC3275]、[XMLsig]、[XMLencrypt]：
Digital signature from the CSIRT or SP initiating the RID message, passed to all systems receiving the Query using an enveloped XML digital signature, placed in an instance of the Signature element.
来自发起RID消息的CSIRT或SP的数字签名，使用封装的XML数字签名传递给接收查询的所有系统，放置在签名元素的实例中。
XML encryption as required by policy, agreements, and data markers.
策略、协议和数据标记要求的XML加密。
The proper response to the Query 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 sends an IODEF document containing multiple incidents or all instances of an incident. The system sending the reply may preset 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 better suited than RID for large transfers of data. The Confidence rating may be used in the Query 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 Query is intended to gather data about a specific type of incident.
对查询消息的正确响应是报告消息。如果请求事件类型，则单个查询可能会返回多个事件。在这种情况下，接收系统发送包含多个事件或事件的所有实例的IODEF文档。发送回复的系统可能会对一份报告中返回的文档数量设置限制。建议的限制为5，以防止文档过大。对于大型数据传输，其他传输方法可能比RID更适合。可在查询消息中使用置信度等级，仅选择置信度等级等于或高于指定值的事件。这可用于收集某类事件的信息，但不收集单个事件的具体信息的情况。如果查询旨在收集有关特定类型事件的数据，则可能不需要源和目标信息。
The following section outlines the communication flows for RID and also provides examples of messages.
下一节概述RID的通信流，并提供消息示例。
The possible set of message exchanges include:
可能的消息交换集包括：
o Request: Asynchronous Request for assistance and/or action to be taken, MAY involve multiple systems and iterative Requests
o 请求：异步请求协助和/或采取行动，可能涉及多个系统和迭代请求
MsgType set to 'InvestigationRequest' or 'TraceRequest'
MsgType设置为“调查请求”或“跟踪请求”
Possible responses:
可能的答复：
+ Acknowledgement (OPTIONAL for InvestigationRequest)
+ 确认（调查请求可选）
+ Result (REQUIRED unless Acknowledgement was set to 'no')
+ 结果（需要，除非确认设置为“否”）
+ Report (OPTIONAL; zero or more; Report can be sent unsolicited)
+ 报告（可选；零份或多份；报告可主动发送）
o Query: Synchronous request for information
o 查询：同步信息请求
MsgType set to 'Query'
MsgType设置为“查询”
Possible responses:
可能的答复：
+ Acknowledgement (OPTIONAL if yes; REQUIRED if no Report will be sent)
+ 确认（如果是可选；如果不发送报告则需要）
+ Report (REQUIRED unless Acknowledgement was set to 'no')
+ 报告（必需，除非确认设置为“否”）
o Report: Asynchronous information report; may be pushed to systems or may be a response to a Query
o 报表：异步信息报表；可以推送到系统，也可以是对查询的响应
MsgType set to 'Report'
MsgType设置为“报告”
Possible responses:
可能的答复：
+ Acknowledgement (OPTIONAL)
+ 确认（可选）
Processing considerations for the IODEF document and any IODEF included elements or attributes MUST follow the guidelines specified in [RFC5070], Section 4. [RFC3023] and [RFC3470] specify requirements and best practices for the use of XML in IETF application protocols. RID and IODEF documents MUST be well-formed (see [RFC3470], Section 4.1) and MUST be validated against the appropriate schema. Internal or external DTD subsets are prohibited in RID; see [RFC3023], Section 3.
IODEF文档和任何包含IODEF的元素或属性的处理注意事项必须遵循[RFC5070]第4节中规定的指南。[RFC3023]和[RFC3470]规定了在IETF应用协议中使用XML的要求和最佳实践。RID和IODEF文件必须格式良好（见[RFC3470]，第4.1节），并且必须根据适当的模式进行验证。RID中禁止使用内部或外部DTD子集；参见[RFC3023]，第3节。
Comments can be ignored by conform ant processors for RID or IODEF documents (see [RFC3470], Section 4.6) and are included below for informational purposes only. The first example demonstrates the use of a detached digital signature. Subsequent examples do not include the detached signature required for some message types. The signature is applied after the message is created as demonstrated in the first example.
对于RID或IODEF文档，conform ant processors可以忽略注释（参见[RFC3470]，第4.6节），下面的注释仅供参考。第一个示例演示了分离数字签名的使用。后续示例不包括某些消息类型所需的分离签名。如第一个示例所示，在创建消息后应用签名。
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 SPs. Addresses were used from /27 network ranges.
注：对于下面列出的每个示例，使用了[RFC5735]地址。假设列出的每个IP地址实际上是由不同SP持有的一个单独的网络范围。使用的地址来自/27个网络范围。
The diagram below outlines the RID Request communication flow for a TraceRequest between RID systems on different networks tracing an attack. The Request message with MsgDestination set to
The diagram below outlines the RID Request communication flow for a TraceRequest between RID systems on different networks tracing an attack. The Request message with MsgDestination set totranslate error, please retry
'TraceRequest' is represented in the diagram by "TraceRequest". SP-1, SP-2, and SP-3 represent service providers that are involved in the example trace communication flow.
“TraceRequest”在图中用“TraceRequest”表示。SP-1、SP-2和SP-3表示示例跟踪通信流中涉及的服务提供商。
Attack Dest SP-1 SP-2 SP-3 Attack Src
攻击目标SP-1 SP-2 SP-3攻击Src
1. Attack | Attack reported | detected
1. 攻击|报告攻击|检测到
2. Initiate trace
2. 启动跟踪
3. Locate origin through upstream SP
3. 通过上游SP定位原点
4. o---TraceRequest----->
4. o---TraceRequest----->
5. Trace Initiated
5. 跟踪启动
6. <---Acknowledgement--o
6. <---Acknowledgement--o
7. Locate origin through upstream SP
7. 通过上游SP定位原点
8. o---TraceRequest--->
8. o---TraceRequest--->
9. Trace Initiated
9. 跟踪启动
10. <----------Acknowledgement----o
<-Acknowledgement-o
10. <----------Acknowledgement----o
<-Acknowledgement-o
11. Locate attack source on network X
11. 在网络X上定位攻击源
12. <------------Result----------------o
12. <------------Result----------------o
13. o- - - - -Acknowledgement- - - - - >
13. o---确认--->
Figure 8: TraceRequest Communication Flow
图8:TraceRequest通信流
Before a trace is initiated, the RID system should verify that 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
在启动跟踪之前，RID系统应验证跟踪实例或类似请求是否处于非活动状态。这些痕迹可能是资源密集型的；因此，提供商需要能够检测系统的潜在滥用或无意资源
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.
排水管。诸如源和目的地信息、相关分组和事件的信息可能需要在管理员确定的时间段内保持。
The communication flow demonstrates that an Acknowledgement message is sent to both the downstream peer and the original requestor. If a Request in a traceback 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 SP involved using a Request with the MsgType set to 'InvestigationRequest' to ensure that an action is taken if no response is received. Nothing precludes the originator of the request from initiating a new Request with the MsgType set to 'TraceRequest' thereby bypassing the SP that denied the request, if a trace is needed beyond that point. Another option may be for the initiator to send an 'InvestigationRequest' to an SP upstream of the SP that denied the request. This action assumes enough information was gathered to discern the true source of the attack traffic from the incident-handling information.
通信流表明确认消息被发送到下游对等方和原始请求方。如果回溯中的请求被拒绝，则下游对等方可以选择采取操作并使用结果消息进行响应。请求的发起人可使用MsgType设置为“调查请求”的请求，与相关SP的下游对等方跟进，以确保在未收到响应时采取行动。如果需要超过该点的跟踪，则不排除请求发起人启动MsgType设置为“TraceRequest”的新请求，从而绕过拒绝请求的SP。另一个选项可能是发起人向拒绝请求的SP上游的SP发送“调查请求”。此操作假定收集了足够的信息，以便从事件处理信息中辨别攻击流量的真实来源。
The proper response to a TraceRequest is an Acknowledgement message. The Acknowledgement 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, an Acknowledgement 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 an Acknowledgement message would occur, thereby 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 SP path information provided through the document instance of EventData, where contact is set to 'infrastructure'. The SP path information is also used when sending the Acknowledgement messages to the first entry (the trace originator) and the last nested entry (the downstream peer). The Result message is encrypted [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, an Acknowledgement message is sent in response; otherwise, no return message is sent. The final Acknowledgement to the Result message is depicted as optional in the diagram above. If an Acknowledgement 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.
对TraceRequest的正确响应是确认消息。确认消息让请求者知道跟踪是否将继续通过下一个上游网络。如果请求存在问题，例如验证数字签名或解密请求失败，则必须向请求者和下游对等方（如果它们不是一个且不相同）发送确认消息，提供无法处理消息的原因。假设跟踪继续进行，则会发生具有确认消息响应的附加跟踪请求，从而将请求在路径上游传递到与事件相关的流量源。找到源后，将向跟踪的发起人发送一条结果消息，该消息由通过EventData的文档实例提供的SP路径信息确定，其中contact设置为“infrastructure”。向第一个条目（跟踪发起人）和最后一个嵌套条目（下游对等方）发送确认消息时，也会使用SP路径信息。结果消息是加密的[XMLencrypt]，供发端人提供有关事件源和所采取的任何行动的信息。如果发端人未能解密或验证结果消息，则发送确认消息作为响应；否则，不会发送返回消息。在上图中，对结果消息的最终确认被描述为可选的。如果发送确认消息时RequestStatus设置为Denied，则接收该消息的下游对等方可选择在网络中尽可能靠近源的该点处采取措施停止或缓解流量。如果下游对等方选择此选项，它将向跟踪发起方发送结果消息。
The example listed is of a Request message with MsgDestination set to 'TraceRequest' based on the incident report example from the IODEF document. The RID classes were included as appropriate for a Request message of this type using the RIDPolicy class. The example given is that of a CSIRT reporting a DoS attack in progress to the upstream SP. The request asks the next SP to continue the trace and have the traffic mitigated closer to the source of the traffic. The example Request message is the first step of a TraceRequest as depicted in the previous diagram, where 'Attack Dest' is represented by 192.0.2.67 (and SP-1). The 'Attack Src' is later identified in the Result message example as 192.0.2.37 and initially as tracing closer to 192.0.2.35. SP-1 is identified in the Request as CSIRT-FOR-OUR-DOMAIN, and SP-2 is identified in the RID document for the Request as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node class. SP-3 is later used in the Result message and the administrator is identified as 'Admin-contact@10.1.1.2' as they searched for 192.0.2.35; the administrator may be different than the constituency contact (an additional Request with MsgDestination set to 'TraceRequest' occurred between SP-2 to SP-3 that is not included). SP-3 is the service provider for 192.0.2.32/27 and was able to take the action to rate-limit their traffic. The SP-1, SP-2, and SP-3 information would be replaced with the appropriate (and valid) email and other contact information in real usages. The Node class enables multiple methods to identify a system, such as a fully qualified domain name or the IP address to be provided for the SP. Any mapping of existing relationships from the SP Node information to the name, contact, digital signature verification information and other identifying or trust information is provided at the application layer to support end users of the incident management system. A packet is provided in this example to enable any traces to be performed by SP-2 and SP-3 to perform traces to the attack source before taking the requested action to 'rate-limit' the traffic. The subnet of 192.0.2.0 uses a 27-bit mask in the examples below.
所列示例是基于IODEF文档中的事件报告示例，将MSGDestation设置为“TraceRequest”的请求消息。使用RIDPolicy类将RID类适当地包含在此类请求消息中。给出的示例是一个CSIRT向上游SP报告正在进行的DoS攻击。该请求要求下一个SP继续跟踪，并在靠近流量源的地方缓解流量。示例请求消息是TraceRequest的第一步，如上图所示，其中“攻击目标”由192.0.2.67（和SP-1）表示。“攻击Src”稍后在结果消息示例中标识为192.0.2.37，最初标识为接近192.0.2.35的跟踪。SP-1在请求中被标识为CSIRT-FOR-OUR-DOMAIN，SP-2在请求的RID文档中被标识为使用节点类的“MsgDestination”as 192.0.2.3中的“RIDSystem”。SP-3稍后用于结果消息，管理员被标识为“管理员”-contact@10.1.1.2当他们搜索192.0.2.35时；管理员可能不同于选区联系人（在SP-2到SP-3之间发生了MSGDESTIONATION设置为“TraceRequest”的附加请求，但未包括在内）。SP-3是192.0.2.32/27的服务提供商，能够采取措施限制流量。在实际使用中，SP-1、SP-2和SP-3信息将替换为适当（且有效）的电子邮件和其他联系信息。Node类支持多种方法来标识系统，例如为SP提供的完全限定的域名或IP地址。SP节点信息到名称、联系人、，在应用层提供数字签名验证信息和其他识别或信任信息，以支持事件管理系统的最终用户。本例中提供了一个数据包，使SP-2和SP-3能够在采取请求的措施“速率限制”流量之前，对攻击源执行任何跟踪。在下面的示例中，192.0.2.0的子网使用27位掩码。
In the following example, use of [XMLsig] to generate digital signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of [XMLsig] supports additional digest algorithms. Reference [RFC4051] for URIs intended for use with XML digital signatures, encryption, and canonicalization. SHA-1 SHOULD NOT be used; see [RFC6194] for further details.
在以下示例中，使用[XMLsig]生成数字签名遵循[XMLsig]1.0的指导。[XMLsig]的1.1版支持其他摘要算法。参考[RFC4051]，了解用于XML数字签名、加密和规范化的URI。不应使用SHA-1；有关更多详细信息，请参见[RFC6194]。
Note: Due to the limit of 72 characters per line, some line breaks were added in the examples and schemas in this document.
注意：由于每行72个字符的限制，本文档中的示例和模式中添加了一些换行符。
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<iodef-rid:RID lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
<iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
<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-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en">
<iodef:Incident purpose="traceback" restriction="need-to-know">
<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 completion="failed" severity="low"
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 ip_protocol="6">
<iodef:Port>38765</iodef:Port>
</iodef:Service>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<iodef-rid:RID lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
<iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
<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-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en">
<iodef:Incident purpose="traceback" restriction="need-to-know">
<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 completion="failed" severity="low"
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 ip_protocol="6">
<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 ip_protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="rate-limit-host" severity="high">
<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 action="rate-limit-host">
<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 SP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
<!-- Start of detached XML signature included in RID -->
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="rate-limit-host" severity="high">
<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 action="rate-limit-host">
<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 SP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
<!-- Start of detached XML signature included in RID -->
<iodef-rid:Signature dtype="xml" meaning="xml">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
Id="dsig-123456">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
Filter="intersect">
//dsig:Signature[@Id = 'dsig-123456']/
ancestor::iodef-rid:ReportSchema/
iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
iodef:RecordItem[1]</XPath></Transform></Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>
NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
</DigestValue>
</Reference></SignedInfo>
<SignatureValue>
lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq
BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6
LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy
Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9
MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==
</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>
z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV
h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F
n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86
uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT
gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</iodef-rid:Signature>
<iodef-rid:Signature dtype="xml" meaning="xml">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
Id="dsig-123456">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
Filter="intersect">
//dsig:Signature[@Id = 'dsig-123456']/
ancestor::iodef-rid:ReportSchema/
iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
iodef:RecordItem[1]</XPath></Transform></Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>
NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
</DigestValue>
</Reference></SignedInfo>
<SignatureValue>
lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq
BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6
LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy
Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9
MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==
</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>
z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV
h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F
n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86
uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT
gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</iodef-rid:Signature>
<!-- End of detached XML signature included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- End of detached XML signature included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
The example Acknowledgement message is in response to the Request message listed above. The SP that received the request is responding to approve the trace continuance in their network.
示例确认消息响应上面列出的请求消息。收到请求的SP正在响应批准其网络中的跟踪连续性。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Acknowledgement"
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 lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Acknowledgement"
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 Request listed above. This message type only comes after an Acknowledgement within the Request flow of messages where a TraceRequest is in progress. It may be a direct response to a Request with the MsgType set to 'InvestigationRequest'. This message provides information about the source of the attack and the actions taken to mitigate the traffic. The Result message is typically the last message in a Request flow; however, an Acknowledgement MAY follow if there are any issues receiving or processing the Result.
示例结果消息响应上面列出的请求。此消息类型仅在TraceRequest正在进行的消息请求流中的确认之后出现。它可能是对MsgType设置为“调查请求”的请求的直接响应。此消息提供有关攻击源以及为缓解流量而采取的措施的信息。结果消息通常是请求流中的最后一条消息；但是，如果在接收或处理结果时存在任何问题，则可能会出现确认。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.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-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.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-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<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-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<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 ip_protocol="6">
<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 ip_protocol="6">
<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: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 ip_protocol="6">
<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 ip_protocol="6">
<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 action="rate-limit-host">
<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 SP 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-SP3">
CSIRT-FOR-SP3#3291-1
</iodef:IncidentID>
<iodef:Description>
Host rate-limited for 24 hours
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</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:History>
<iodef:HistoryItem action="rate-limit-host">
<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 SP 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-SP3">
CSIRT-FOR-SP3#3291-1
</iodef:IncidentID>
<iodef:Description>
Host rate-limited for 24 hours
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</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>
The diagram below outlines a RID Request communication flow between RID systems on different networks for a security incident with a known source address. Therefore, MsgDestination is set to 'InvestigationRequest' for the Request message and is included in the diagram below as "Investigation". The proper response to a Request with the MsgDestination set to 'InvestigationRequest' is a Result message. If there is a problem with the Request, such as a failure to validate the digital signature or decrypt the Request, an Acknowledgement message is sent to the requestor. The Acknowledgement message should provide the reason why the message could not be processed.
下图概述了具有已知源地址的安全事件在不同网络上的RID系统之间的RID请求通信流。因此，请求消息的MsgDestination设置为“调查请求”，并作为“调查”包含在下图中。对MsgDestination设置为“调查请求”的请求的正确响应是结果消息。如果请求存在问题，例如验证数字签名或解密请求失败，则向请求者发送确认消息。确认消息应提供无法处理消息的原因。
Attack Dest SP-1 SP-2 Attack Src
攻击目标SP-1 SP-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 9: Investigation Request Communication Flow
图9：调查请求通信流
The following example only includes the RID-specific details. The IODEF and security measures are similar to the TraceRequest, with the exception that the source is known, the receiving RID system is known to be close to the source, and the MsgDestination is set to 'InvestigationRequest'. 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系统靠近来源，并且MsgDestination设置为“调查请求”。IODEF文件中指出了已知的来源，如果合适，允许将事件来源列为伪造来源。
This flow does not include a Result message because the request is denied as shown in the Acknowledgement response.
此流不包括结果消息，因为请求被拒绝，如确认响应中所示。
SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is identified by 192,0.2.98. In this example, SP-2 is the service provider for systems on the 192.0.2.32/27 subnet. The contact for the host 192.0.2.35 is known at the start of the request as 'Constituency-contact@10.1.1.2'.
SP-1由CERT-FOR-OUR-DOMAIN和192.0.2.67表示。SP-2由192,0.2.98确定。在此示例中，SP-2是192.0.2.32/27子网上系统的服务提供商。主机192.0.2.35的联系人在请求开始时称为“选民”-contact@10.1.1.2'.
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="InvestigationRequest"
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-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="InvestigationRequest"
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-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<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 ip_protocol="6">
<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 ip_protocol="6">
<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:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<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 ip_protocol="6">
<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 ip_protocol="6">
<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 action="block-host">
<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 SP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
</iodef:Description>
</iodef:Expectation>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="block-host">
<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 SP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
The example Acknowledgement message is in response to the Request listed above. The SP that received the request was unable to validate the digital signature used to authenticate the sending RID system.
示例确认消息响应上面列出的请求。接收请求的SP无法验证用于验证发送RID系统的数字签名。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Acknowledgement"
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 lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Acknowledgement"
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 SPs.
下图概述了不同SP上RID系统之间的RID报告通信流。
SP-1 SP-2
SP-1 SP-2
1. Generate incident information and prepare Report message
1. 生成事件信息并准备报告消息
2. o-------Report------->
2. o------报告------->
3. File report in database
3. 数据库中的文件报告
Figure 10: Report Communication Flow
图10：报告通信流
The Report communication flow is used to provide information on incidents. Incident information may be shared between CSIRTs or other entities 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, an Acknowledgement message is sent to the requestor. The Acknowledgement message should provide the reason why the message could not be processed.
报告通信流用于提供有关事件的信息。事件信息可以使用此格式在CSIRT或其他实体之间共享。收到报告后，RID系统必须验证报告是否尚未归档。事件编号和事件数据（如十六进制数据包和事件类信息）可用于与现有数据库条目进行比较。报告消息通常没有响应。如果报告消息存在问题，例如验证数字签名[RFC3275]或解密请求失败，则向请求者发送确认消息。确认消息应提供无法处理消息的原因。
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 is similar to the Request example with MsgDestination set to 'TraceRequest'.
以下示例仅包括RID特定的详细信息。此报告是包含IPv4数据包的未经请求的报告消息。IODEF文档和数字签名与请求示例类似，msgdestation设置为“TraceRequest”。
This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at 192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an attack that took place.
此示例是从SP-1（CERT-FOR-OUR-DOMAIN，192.0.2.67）发送到SP-2（192.0.2.130）的消息，用于提供所发生攻击的信息。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.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:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.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-Document included in RID -->
<iodef-rid:ReportSchema>
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<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 ip_protocol="6">
<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 ip_protocol="6">
<iodef:Port>22</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema>
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<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 ip_protocol="6">
<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 ip_protocol="6">
<iodef:Port>22</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="rate-limit-host">
<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 SP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
</iodef:Flow>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="rate-limit-host">
<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 SP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
The diagram below outlines the RID Query communication flow between RID systems on different networks.
下图概述了不同网络上RID系统之间的RID查询通信流。
SP-1 SP-2
SP-1 SP-2
1. Generate a request for information on a specific incident number or incident type
1. 生成关于特定事件编号或事件类型的信息请求
2. o-------Query------->
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 11: Query Communication Flow
图11：查询通信流
The Query 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 Query message, such as a failure to validate the digital signature or decrypt the request, an Acknowledgement message is sent to the requestor. The Acknowledgement message should provide the reason why the message could not be processed.
与请求者共享可用信息。事件编号和响应RID系统以及运输系统有助于将请求和响应关联起来，因为可以提交报告，并且不总是征求报告。如果查询消息存在问题，例如验证数字签名或解密请求失败，则向请求者发送确认消息。确认消息应提供无法处理消息的原因。
The Query 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 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).
根据执行的查询类型，可以以多种格式接收查询请求。如果事件编号是提供的唯一信息，则完成请求可能不需要IODEF文档和IP数据包数据。但是，如果请求一种类型的事件，则事件编号保持为空，并且IP数据包数据将不包括在IODEF RecordItem类中；其他事件信息是比较的主要来源。在csirt之间的事件编号可能不相同的情况下，可以提供事件编号和/或IP分组信息，并用于在接收RID系统上进行比较，以生成（a）报告消息。
This query is sent to 192.0.2.3, inquiring about the incident with the identifier CERT-FOR-OUR-DOMAIN#210-1. The Report will be provided to the requestor identified and verified through the authentication and digital signature information provided in the RID message. An example Report is provided above.
此查询发送到192.0.2.3，查询标识符CERT-FOR-OUR-DOMAIN#210-1的事件。报告将提供给通过RID消息中提供的身份验证和数字签名信息识别和验证的请求者。上面提供了一个示例报告。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Query"
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 lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Query"
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-2.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-2.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-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"/>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.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-2.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-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"/>
<!-- ****************************************************************
*********************************************************************
*** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, April 2012 ***
*** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. ***
*********************************************************************
-->
<!--RID messages act as an envelope for IODEF and RID documents
to support the exchange of incident information-->
<!--
====== Real-Time Inter-network Defense - RID ======
==== Suggested definition for RID messaging ======
<!-- ****************************************************************
*********************************************************************
*** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, April 2012 ***
*** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. ***
*********************************************************************
-->
<!--RID messages act as an envelope for IODEF and RID documents
to support the exchange of incident information-->
<!--
====== 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:attribute name="lang"
type="xs:language" use="required"/>
</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:attribute name="lang"
type="xs:language" use="required"/>
</xs:complexType>
<!--Used in Acknowledgement Message for RID-->
<!--Used in Acknowledgement 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: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="UnrecognizedFormat"/>
<xs:enumeration value="CannotProcess"/>
<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: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="UnrecognizedFormat"/>
<xs:enumeration value="CannotProcess"/>
<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:element ref="iodef-rid:ReportSchema" 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="Acknowledgement"/>
<xs:enumeration value="Result"/>
<xs:enumeration value="InvestigationRequest"/>
<xs:enumeration value="Report"/>
<xs:enumeration value="Query"/>
<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"
<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:element ref="iodef-rid:ReportSchema" 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="Acknowledgement"/>
<xs:enumeration value="Result"/>
<xs:enumeration value="InvestigationRequest"/>
<xs:enumeration value="Report"/>
<xs:enumeration value="Query"/>
<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:attribute name="restriction" type="iodef:restriction-type"/>
</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="ClientToSP"/>
<xs:enumeration value="SPToClient"/>
<xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/>
<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">
<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="DataWithHandlingRequirements"/>
<xs:enumeration value="AudienceRestriction"/>
<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>
<!--Used to include an enveloped XML document in RID-->
<xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
<xs:complexType name="ReportSchemaType">
<xs:sequence>
<xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
maxOccurs="1"/>
use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</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="ClientToSP"/>
<xs:enumeration value="SPToClient"/>
<xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/>
<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">
<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="DataWithHandlingRequirements"/>
<xs:enumeration value="AudienceRestriction"/>
<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>
<!--Used to include an enveloped XML document in RID-->
<xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
<xs:complexType name="ReportSchemaType">
<xs:sequence>
<xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
maxOccurs="1"/>
<xs:element ref="iodef-rid:URL" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="iodef-rid:Signature" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Version"
type="xs:string" use="optional"/>
<xs:attribute name="XMLSchemaID" use="optional">
<xs:simpleType>
<xs:restriction base="xs:anyURI">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-XMLSchemaID"
type="xs:string" use="optional"/>
</xs:complexType>
<xs:element name="XMLDocument"
type="iodef:ExtensionType"/>
<xs:element name="URL"
type="xs:anyURI"/>
<xs:element name="Signature"
type="iodef:ExtensionType"/>
</xs:schema>
<xs:element ref="iodef-rid:URL" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="iodef-rid:Signature" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Version"
type="xs:string" use="optional"/>
<xs:attribute name="XMLSchemaID" use="optional">
<xs:simpleType>
<xs:restriction base="xs:anyURI">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-XMLSchemaID"
type="xs:string" use="optional"/>
</xs:complexType>
<xs:element name="XMLDocument"
type="iodef:ExtensionType"/>
<xs:element name="URL"
type="xs:anyURI"/>
<xs:element name="Signature"
type="iodef:ExtensionType"/>
</xs:schema>
RID leverages existing security standards and data markings in RIDPolicy to achieve the required levels of security for the exchange of incident information. The use of standards includes TLS and the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275] [XMLsig]. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized; meet policy and privacy guidelines; and maintain integrity. XML
RID利用RIDPolicy中现有的安全标准和数据标记来实现事件信息交换所需的安全级别。标准的使用包括TLS和加密[XMLencrypt]和数字签名[RFC3275][XMLsig]的XML安全特性。这些标准提供了明确的方法，以确保消息安全、经过身份验证和授权；符合政策和隐私准则；保持诚信。XML
Signature Best Practices [XMLSigBP] should be referenced by implementers for information on improving security to mitigate attacks.
实现者应参考签名最佳实践[XMLSigBP]，以获取有关提高安全性以减轻攻击的信息。
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 a Request MUST use a detached signature to sign at least one of the original elements contained in the RecordItem class to provide authentication to all upstream participants in the trace or those involved in the investigation. All instances of RecordItem provided by the originator may be individually signed, and additional RecordItem entries by upstream peers in the trace or investigation may be signed by the peer adding the data, while maintaining the original RecordItem entry(s) and detached signature(s) from the original requestor. It is important to note that the data is signed at the RecordItem level. Since multiple RecordItems may exist within an IODEF document and may originate from different sources, the signature is applied at the RecordItem level to enable the use of an XML detached signature. Exclusive canonicalization [XMLCanon] is REQUIRED for the detached signature and not the references, as the XML document generated is then included in the RID message within the Signature element of the ReportSchema class. This signature MUST be passed to all recipients of the Request message.
o 请求的发起人必须使用分离的签名对RecordItem类中包含的至少一个原始元素进行签名，以向跟踪中的所有上游参与者或参与调查的参与者提供身份验证。发起人提供的所有记录项实例都可以单独签名，追踪或调查中上游对等方的其他记录项条目可以由添加数据的对等方签名，同时保留原始记录项条目和原始请求者的分离签名。需要注意的是，数据是在记录项级别签名的。由于一个IODEF文档中可能存在多个记录项，并且这些记录项可能来自不同的源，因此在记录项级别应用签名，以支持使用XML分离的签名。分离的签名而不是引用需要独占规范化[XMLCanon]，因为生成的XML文档随后包含在ReportSchema类的signature元素内的RID消息中。此签名必须传递给请求消息的所有收件人。
o If a Request does not include a RecordItem entry, a timestamp MUST be used to ensure there is data to be signed for the multi-hop authentication use case. The DateTime element of the iodef: RecordData class ([RFC5070], Section 3.19.1) is used for this purpose.
o 如果请求不包括RecordItem条目，则必须使用时间戳来确保多跳身份验证用例中有要签名的数据。iodef:RecordData类（[RFC5070]，第3.19.1节）的DateTime元素用于此目的。
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. The signature is placed in an instance of the Signature element.
o 对于所有消息类型，发送对等方必须使用信封签名对完整的IODEF-RID文档进行签名，以向接收RID系统提供身份验证和完整性。签名放置在签名元素的实例中。
o XML Signature Best Practices [XMLSigBP] guidance SHOULD be followed to prevent or mitigate security risks. Examples include the recommendation to authenticate a signature prior to processing (executing potentially dangerous operations) and the recommendation to limit the use of URIs since they may enable cross-site scripting attacks or access to local information.
o 应遵循XML签名最佳实践[XMLSigBP]指南，以防止或减轻安全风险。示例包括在处理（执行潜在危险的操作）之前对签名进行身份验证的建议，以及限制URI使用的建议，因为URI可能导致跨站点脚本攻击或访问本地信息。
o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to specify the portion of the XML document to be signed. XPath is used to specify a location within an XML document. Best practice recommendations for using XPath [XMLSigBP] SHOULD be referenced to reduce the risk of denial-of-service attacks. The use of XSLT transforms MUST be restricted according to security guidance in [XMLSigBP].
o 必须遵循XML路径语言（XPath）2.0[XMLPath]来指定要签名的XML文档部分。XPath用于指定XML文档中的位置。应参考使用XPath[XMLSigBP]的最佳实践建议，以降低拒绝服务攻击的风险。必须根据[XMLSigBP]中的安全指南限制XSLT转换的使用。
XML Encryption
XML加密
o The IODEF-RID document MAY be encrypted to provide an extra layer of security between peers so that not only the message is encrypted for transport. 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 [RFC6546].
o 可以对IODEF-RID文档进行加密，以在对等方之间提供额外的安全层，从而不仅对消息进行加密以进行传输。这种行为将在对等方或联合体之间达成一致意见，或根据安全要求在每条消息的基础上确定。应注意的是，在某些运输情况下，需要以明文形式呈现RIDPolicy类，详见运输文件[RFC6546]。
o A Request, or any other message type that may be relayed through RID systems before reaching the intended destination as a result of trust relationships, MAY be encrypted specifically 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 as such, RIDPolicy is maintained in clear text.
o 由于信任关系，在到达预期目的地之前，可以通过RID系统中继的请求或任何其他消息类型可以专门针对预期接收者进行加密。如果RID网络用于消息传输，中间方不需要知道请求内容，并且不存在直接通信路径，则这可能是必要的。在这种情况下，RIDPolicy类由中间方使用，因此，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 and use 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文档，并为请求的发起人使用信封签名。事件结果消息的存在将告知事件调查路径中使用的任何中间方事件处理已完成。
o The iodef:restriction attribute sets expectations for the privacy of an incident and is defined in Section 3.2 of RFC 5070. Following the guidance for XML encryption in the Security Requirements section, the iodef:restriction attribute can be set in any of the RID classes to define restrictions and encryption requirements for the exchange of incident information. The restriction options enable encryption capabilities for the
o iodef:restriction属性设置了对事件隐私的期望，并在RFC 5070第3.2节中定义。按照“安全要求”部分中的XML加密指南，可以在任何RID类中设置iodef:restriction属性，以定义事件信息交换的限制和加密要求。“限制”选项可为应用程序启用加密功能
complete exchange of an IODEF document (including any extensions), within specific classes of IODEF, or IODEF extensions, where more limited restrictions are desired. The restriction attribute is contained in each of the RID classes and MUST be used in accordance with confidentiality expectations for either sections of the IODEF document or the complete IODEF document. Consortiums and organizations should consider this guidance when creating exchange policies.
在需要更多限制的特定IODEF类或IODEF扩展中，完成IODEF文档（包括任何扩展）的交换。限制属性包含在每个RID类中，并且必须根据IODEF文档或完整IODEF文档的任何部分的保密要求使用。在创建Exchange策略时，联合体和组织应考虑此指导。
o Expectations based on how restriction is set:
o 基于限制设置方式的期望：
* If restriction is set to 'private', the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient. See Section 9.3 for a discussion on public key infrastructure (PKI) and other security requirements.
* 如果限制设置为“private”，则必须使用XML加密和收件人的公钥为收件人加密类或文档。有关公钥基础设施（PKI）和其他安全要求的讨论，请参见第9.3节。
* If restriction is set to 'need-to-know', the class or document MUST be encrypted to ensure only those with need-to-know access can decrypt the data. The document can either be encrypted for each individual for which access is intended or be encrypted with a single group key. The method used SHOULD adhere to any certificate policy and practices agreements between entities for the use of RID. A group key in this instance refers to a single key (symmetric) that is used to encrypt the block of data. The users with need-to-know access privileges may be given access to the shared key via a secure distribution method, for example, providing access to the symmetric key encrypted with each of the user's public keys.
* 如果限制设置为“需要知道”，则必须对类或文档进行加密，以确保只有具有需要知道访问权限的人才能解密数据。文档可以针对每个要访问的个人进行加密，也可以使用单个组密钥进行加密。所使用的方法应遵守实体之间关于RID使用的任何证书策略和实践协议。此实例中的组密钥指用于加密数据块的单个密钥（对称）。具有需要知道访问权限的用户可以通过安全分发方法被授予对共享密钥的访问权，例如，提供对使用每个用户的公钥加密的对称密钥的访问权。
* If restriction is set to 'public', the class or document MUST be sent in clear text. This setting can be critical if certain sections of a document or an entire document are to be shared without restrictions. This provides flexibility within an incident to share certain information freely where appropriate.
* 如果限制设置为“公共”，则类或文档必须以明文形式发送。如果要无限制地共享文档的某些部分或整个文档，则此设置可能非常重要。这在事件中提供了灵活性，可以在适当的情况下自由共享某些信息。
* If restriction is set to 'default', the information can be shared according to an information disclosure policy pre-arranged by the communicating parties.
* 如果限制设置为“默认”，则可以根据通信方预先安排的信息披露策略共享信息。
o Expectations based on placement of the restriction setting:
o 基于限制设置位置的期望：
* If restriction is set within one of the RID classes, the restriction applies to the entire IODEF document.
* 如果在某个RID类中设置了限制，则该限制将应用于整个IODEF文档。
* If restriction is set within individual IODEF classes, the restriction applies to the specific IODEF class and the children of that class.
* 如果在单个IODEF类中设置了限制，则该限制将应用于特定IODEF类及其子类。
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. See Sections 9.4 and 9.5 for additional information on consortiums and PKI considerations.
策略的形成是使用诸如RID之类的消息传递系统交换潜在敏感信息的一个非常重要的方面。对等方需要考虑很多因素，本节介绍了一些保护数据、系统和传输的指南。制定的政策应为通信方法、安全性和回退程序提供指导。有关联合体和PKI注意事项的更多信息，请参见第9.4节和第9.5节。
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. RIDPolicy 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消息中信息存储和交换的安全注意事项可能包括遵守当地、地区或国家法规，以及在调查期间保护客户信息的义务。RIDPolicy是列出消息要求的必要工具，它提供了一种方法来对数据元素进行分类，以便进行适当的处理。还为发送实体提供控件，以通过XML加密保护来自第三方的消息。
RID provides a method to exchange incident-handling requests and Report messages between entities. Administrators have the ability to base decisions on the available resources and other factors of their network and 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策略中列出的信息。
RID is used to transfer or exchange XML documents in an IODEF format or using another IANA-registered format. Implementations SHOULD NOT download schemas at runtime due to the security implications, and included documents MUST NOT be required to provide a resolvable location of their schema.
RID用于以IODEF格式或使用其他IANA注册格式传输或交换XML文档。由于安全问题，实现不应该在运行时下载模式，并且不需要包含的文档来提供模式的可解析位置。
A transport specification is defined in a separate document [RFC6546]. The specified transport protocols MUST use encryption to provide an additional level of security and integrity, while supporting mutual authentication through bidirectional 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 to 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 messages are discussed in Section 9.1 of this document.
运输规范在单独的文件[RFC6546]中定义。指定的传输协议必须使用加密来提供额外级别的安全性和完整性，同时通过双向证书使用支持相互身份验证。定义的任何后续传输方法应利用现有标准，以便于实施和集成RID系统。传输规范中强制执行RID消息传输的会话加密。RID充分考虑了隐私和安全问题，以保护文档的敏感部分，并提供一种验证消息的方法。因此，RID消息不单单依赖于传输层提供的安全性。本文件第9.1节讨论了RID消息的加密要求和注意事项。
Consortiums may vary their selected transport mechanisms and thus 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 [RFC6546] and optionally MAY support other protocols such as the Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would need to be defined to enable support for other transport protocols.
联盟可以改变其选择的传输机制，从而在使用RID与相邻联盟中的对等方通信时决定用于传输的共同协议。RID系统必须实现和部署传输文档[RFC6546]中定义的HTTPS，并且可以选择支持其他协议，如块可扩展交换协议（BEEP）[RFC3080]。需要定义绑定以支持其他传输协议。
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 listen for and send RID messages on only 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建立的算法和密钥长度的最低要求。为对称加密、数字签名和散列函数选择的加密算法必须满足时代的最低安全级别。加密强度必须遵守相关国家的数据交换进出口法规。
Out-of-band communications dedicated to SP 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 practical or possible between service providers, but provisions should be considered to protect the incident management systems used for RID messaging. Methods to protect the data transport may also be provided through session encryption.
专用于RID消息的SP交互的带外通信将在拒绝服务攻击期间提供额外的安全性和有保证的带宽。例如，带外信道可以由在现有网络上定义的逻辑路径组成。服务提供商之间的带外通信可能不实用，也不可能实现，但应考虑保护用于RID消息传递的事件管理系统的规定。还可以通过会话加密提供保护数据传输的方法。
It is RECOMMENDED that RID, the XML security functions, and transport protocols properly integrate with a PKI managed by the consortium, federate PKIs within a consortium, or use a PKI managed by a trusted third party. Entities MAY use shared keys as an alternate solution, although this may limit the ability to validate certificates and could introduce risk. For the Internet, a few examples of existing efforts that could be leveraged to provide the supporting PKI include the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued certificates, or approved issuers of Extended Validation (EV) Certificates. Security and privacy considerations related to consortiums are discussed in Sections 9.4 and 9.5.
建议RID、XML安全功能和传输协议与联盟管理的PKI正确集成，在联盟内联合PKI，或使用受信任的第三方管理的PKI。实体可以使用共享密钥作为替代解决方案，尽管这可能会限制验证证书的能力，并可能带来风险。对于互联网，可以利用现有努力提供支持性PKI的几个例子包括区域互联网注册中心（RIR）的PKI层次结构、供应商颁发的证书或经批准的扩展验证（EV）证书颁发者。第9.4节和第9.5节讨论了与财团相关的安全和隐私注意事项。
The use of PKI between entities or by a consortium SHOULD adhere to any applicable certificate policy and practices agreements for the use of RID. [RFC3647] specifies a commonly used format for
实体之间或联合体使用PKI应遵守RID使用的任何适用证书政策和实践协议。[RFC3647]指定了用于
certificate policy (CP) and certification practices statements (CPS). Systems with predefined relationships for RID include those who peer directly or through a consortium with agreed-upon appropriate use agreements. The agreements to trust other entities may be based on assurance levels that could be determined by a comparison of the CP, CPS, and/or RID operating procedures. The initial comparison of policies and the ability to audit controls provide a baseline assurance level for entities to form and maintain trust relationships. Trust relationships may also be defined through a bridged or hierarchical PKI in which both peers belong. If shared keys or keys issued from a common CA are used, the verification of controls to determine the assurance level to trust other entities may be limited to the RID policies and operating procedures.
证书政策（CP）和认证实践声明（CP）。具有RID预定义关系的系统包括那些直接或通过具有商定的适当使用协议的联合体进行同行的系统。信任其他实体的协议可能基于可通过比较CP、CP和/或RID操作程序确定的保证水平。政策的初步比较和审计控制的能力为实体形成和维持信任关系提供了一个基线保证水平。信任关系也可以通过两个对等方都属于的桥接或分层PKI来定义。如果使用共享密钥或公共CA颁发的密钥，则确定信任其他实体的保证级别的控制验证可能仅限于RID策略和操作程序。
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 service providers. The PKI used for authentication also provides the necessary certificates needed for encryption used for the RID transport protocol [RFC6546].
RID中使用的XML安全功能需要一个信任中心（如PKI）来分发凭据，从而为该协议提供必要的安全级别。分层传输协议还利用加密并依赖于信任中心。由可信证书颁发机构（CA）颁发的公钥证书对可用于为RID协议提供必要级别的身份验证和加密。用于RID消息传递的CA必须得到所有相关方的信任，并且可以利用类似的努力，例如Internet2联合PKI或ARIN/RIR努力向服务提供商提供PKI。用于身份验证的PKI还提供用于RID传输协议[RFC6546]的加密所需的必要证书。
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 specifications and path validation standards set forth in [RFC5280] MUST be followed in order to interoperate with a PKI designed for similar purposes. Full path validation verifies the chaining relationship to a trusted root and also performs a certificate revocation check. 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.
接收RID消息的主机必须能够验证请求的发送方是否有效且可信。必须使用受信任方颁发的X.509版本3证书对RID消息的哈希使用数字签名来验证请求。必须遵守X.509第3版规范以及[RFC5280]中规定的数字签名规范和路径验证标准，以便与为类似目的设计的PKI进行互操作。完整路径验证验证与受信任根的链接关系，并执行证书吊销检查。在文档中使用XML加密[XMLencrypt]或数字签名[XMLsig][RFC3275]时，在RID XML消息中使用数字签名必须遵循万维网联盟（W3C）关于签名语法和处理的建议。
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]的认证方案的扩展可能会有帮助，这样应用程序可以自动确定是否需要人为干预来授权请求；但是，此类扩展的规范不在本文件的范围内。
The use of pre-shared keys may be considered for authentication at the transport layer. If this option is selected, the specifications set forth in "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST be followed. Transport specifications are detailed in a separate document [RFC6546].
可以考虑在传输层使用预共享密钥进行身份验证。如果选择此选项，则必须遵循“传输层安全（TLS）预共享密钥密码套件”[RFC4279]中规定的规范。运输规范详见单独的文件[RFC6546]。
The use of multi-hop authentication in a Request is used when a Request is sent to multiple entities or SPs in an iterative manner. Multi-hop authentication is REQUIRED in Requests that involve multiple SPs where Requests are forwarded iteratively through peers. Bilateral trust relationships MAY be used between peers; multi-hop authentication MUST be used for cases where the originator of a message is authenticated several hops into the message flow.
当请求以迭代方式发送到多个实体或SP时，将使用请求中的多跳身份验证。在涉及多个SP的请求中需要多跳身份验证，其中请求通过对等方迭代转发。对等方之间可以使用双边信任关系；多跳身份验证必须用于消息的发起人在消息流中经过几跳身份验证的情况。
For practical reasons, SPs may want to prioritize incident-handling events based upon the immediate peer for a Request, the originator of a request, and the listed Confidence rating for the incident. In order to provide a higher assurance level of the authenticity of a Request, the originating RID system is included in the Request 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, which nests the list of systems and contacts involved in a trace, while setting the category attribute to "infrastructure".
出于实际原因，SPs可能希望根据请求的直接对等方、请求的发起人以及列出的事件置信度，对事件处理事件进行优先级排序。为了对请求的真实性提供更高的保证级别，原始RID系统与联系人信息以及跟踪路径中所有RID系统的信息一起包含在请求中。此信息通过IODEF EventData类提供，该类嵌套跟踪中涉及的系统和联系人列表，同时将category属性设置为“infrastructure”。
To provide multi-hop authentication, the originating RID system MUST include a digital signature in the Request 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 Request, and each party MUST be able to perform full path validation on the digital signature [RFC5280]. In order to accommodate that requirement, the RecordItem data MUST remain unchanged as a request is passed along between providers and is the only element for which the signature is applied. If additional RecordItems are included in the document at upstream peers, the initial RecordItem entry MUST still remain with the detached signature. The subsequent RecordItem elements may be signed by the peer adding the incident information for the investigation. A second
为了提供多跳认证，原始RID系统必须在发送到上游路径中所有系统的请求中包含数字签名。RID系统的数字签名在IODEF的RecordItem类上执行，遵循W3C[XMLsig]的XML数字签名规范，使用分离的签名。签名必须传递给接收请求的所有各方，并且各方必须能够对数字签名执行完整路径验证[RFC5280]。为了满足这一要求，在提供者之间传递请求时，RecordItem数据必须保持不变，并且它是应用签名的唯一元素。如果上游对等方的文档中包含其他记录项，则初始记录项条目必须保留分离的签名。后续记录项元素可由同行签署，添加事件信息用于调查。一秒钟
benefit to this requirement is that the integrity of the filter used is ensured as it is passed to subsequent SPs in the upstream trace of the incident. The trusted PKI also provides the keys used to digitally sign the RecordItem class for a Request 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.
这一要求的好处是，当所用过滤器传递给事件上游跟踪中的后续SP时，可确保其完整性。可信PKI还提供用于对请求的RecordItem类进行数字签名的密钥，以满足对原始请求进行身份验证的要求。跟踪路径中的任何主机都应该能够使用受信任的PKI验证数字签名。
In the case in which an enterprise using RID sends a Request to its provider, the signature from the enterprise MUST be included in the initial request. The SP may generate a new request to send upstream to members of the SP consortium to continue the investigation. If the original request is sent, the originating SP, 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 Request. An SP 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. SPs participating in the trace MUST be able to determine the authenticity of RID requests.
在使用RID的企业向其提供商发送请求的情况下，来自企业的签名必须包含在初始请求中。SP可能会生成一个新的请求，向SP财团成员发送上游请求，以继续调查。如果发送原始请求，则代表受攻击企业网络的发起SP还必须使用信封签名对完整的IODEF文档进行数字签名，以确保请求的真实性。作为服务提供RID的SP可能正在使用其自己的PKI来保护其RID系统和连接的企业网络之间的RID通信。参与跟踪的SP必须能够确定RID请求的真实性。
Consortiums are an ideal way to establish a communication web of trust for RID messaging. It should be noted that direct relationships may be ideal for some communications, such as those between a provider of incident information and a subscriber of the incident reports. The consortium could provide centralized resources, such as a PKI, and established guidelines and control requirements for use of RID. The consortium may assist in establishing trust relationships between the participating SPs 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 SPs in a common area (Internet, region, government, education, private networks, etc.).
联盟是为RID消息建立信任通信网络的理想方式。应注意的是，对于某些通信来说，直接关系可能是理想的，例如事件信息提供者和事件报告订阅者之间的通信。联合体可以提供集中的资源，如PKI，并为RID的使用制定指导方针和控制要求。联合体可协助在参与的SP之间建立信任关系，以实现联合体实体之间必要的合作和经验共享。这可以通过PKI证书策略[RFC3647]审核来确定组织或实体之间的适当信任级别。联合体也可用于其他目的，以更好地促进公共区域内SP之间的通信（互联网、地区、政府、教育、专用网络等）。
Using a PKI to distribute certificates used by RID systems provides an already established method to link trust relationships between consortiums that peer with SPs belonging to a separate consortium. In other words, consortiums could peer with other consortiums to enable communication of RID messages between the participating SPs. 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分发RID系统使用的证书提供了一种已经建立的方法来链接与属于单独联盟的SP对等的联盟之间的信任关系。换句话说，联盟可以与其他联盟进行对等，以实现参与SP之间RID消息的通信。PKI和协议备忘录可用于链接边界目录，以在桥接、层次结构或单个交叉认证关系中共享公钥信息。
Consortiums also need to establish guidelines for each participating SP to adhere to. The RECOMMENDED guidelines include:
财团还需要为每个参与的SP制定指导方针。建议的准则包括：
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, certificate policy, and certification practices statement to provide authentication, integrity, and privacy.
o 提供身份验证、完整性和隐私的PKI、证书策略和证书实践声明。
The functions described for a consortium's role parallel those 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 SP.
PKI还可以为最终实体（企业、教育或政府客户网络）与SP之间的通信提供相同级别的安全性。
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 for the system communicating RID messages and other integrated components include the following:
当需要共享信息以实现阻止或减轻安全事件影响的目标时，隐私问题会引起许多关注。RIDPolicy类用于自动执行本文档中列出的隐私问题。传输RID消息的系统和其他集成组件的隐私和系统使用问题包括：
Service Provider Concerns:
服务提供者关注的问题：
o Privacy of data monitored and/or stored on Intrusion Detection Systems (IDSs) for attack detection.
o 用于攻击检测的入侵检测系统（IDSs）上监控和/或存储的数据的隐私。
o Privacy of data monitored and stored on systems used to trace traffic across a single network.
o 在用于跟踪单个网络流量的系统上监视和存储的数据的隐私。
o Privacy of incident information stored on incident management systems participating in RID communications.
o 参与RID通信的事件管理系统上存储的事件信息的隐私。
Customer Attached Networks Participating in RID with SP:
使用SP参与RID的客户连接网络：
o Customer networks may include enterprise, educational, government, or other networks attached to an SP participating in RID. Customers should review data handling policies to understand how
o 客户网络可能包括与参与RID的SP相连的企业、教育、政府或其他网络。客户应查看数据处理策略，以了解如何
data will be protected by a service provider. This information will enable customers to decide what types of data at what sensitivity level can be shared with service providers. This information could be used at the application layer to establish sharing profiles for entities and groups; see Section 9.6.
数据将由服务提供商保护。此信息将使客户能够决定在何种敏感度级别上可以与服务提供商共享何种类型的数据。该信息可在应用层用于建立实体和组的共享配置文件；见第9.6节。
o Customers should request information on the security and privacy considerations in place by their SP and the consortium of which the SP is a member. Customers should understand if their data were to be forwarded, how it might be sanitized and how it will be protected. In advance of sharing data with their SP, customers should also understand if limitations can be placed on how it will be used.
o 客户应要求其SP和SP所属的联合体提供有关安全和隐私注意事项的信息。客户应该了解他们的数据是否要转发，如何对其进行消毒，以及如何对其进行保护。在与其SP共享数据之前，客户还应了解是否可以限制数据的使用方式。
o Customers should be aware that their data can and will be sent to other SPs in order to complete a trace unless an agreement stating otherwise is made in the service level agreements between the customer and SP. Customers considering privacy options may limit the use of this feature if they do not want the data forwarded.
o 客户应该知道，他们的数据可以也将被发送到其他SP以完成跟踪，除非客户和SP之间的服务级别协议中另有规定。如果客户不希望转发数据，考虑隐私选项的客户可能会限制此功能的使用。
Parties Involved in the Attack:
参与袭击的各方：
o Privacy of the identity of a host involved in an attack or any indicators of compromise.
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 Request request should be considered.
o 应考虑保护数据不被请求路径中的中间方查看。
Consortium Considerations:
联合体考虑：
o System use restrictions for security incident handling within the local region's definitions of appropriate traffic. When participating in a consortium, appropriate use guidelines should be agreed upon and entered into contracts.
o 在本地区适当流量的定义范围内，系统对安全事件处理使用限制。当参与联合体时，应商定适当的使用指南并签订合同。
o System use prohibiting the consortium's participating SPs from inappropriately tracing traffic to locate sources or mitigate traffic unlawfully within the jurisdiction or region.
o 系统使用禁止联合体参与的SP不适当地跟踪交通，以定位来源或在管辖区或区域内非法缓解交通。
Inter-Consortium Considerations:
联合体间的考虑：
o System use between peering consortiums should consider any government communication regulations that apply between those two regions, such as encryption export and import restrictions.
o 对等联盟之间的系统使用应该考虑在这两个区域之间应用的任何政府通信规则，例如加密导出和导入限制。
o System use between consortiums SHOULD NOT request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements.
o 联合体之间的系统使用不应请求超出法律或联合体间协议预期和允许范围的流量跟踪和行动。
o System use between consortiums should consider national boundary issues and request limits in their appropriate system use agreements. Appropriate use should include restrictions to prevent the use of the protocol for limiting or restricting 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, SPs, and enterprises to agree upon. The agreed-upon policies may be facilitated through use of the RIDPolicy class and application-layer options. Some privacy considerations are addressed through the RID guidelines for encryption and digital signatures as described in Section 9.1.
以上列出的安全和隐私注意事项由财团、SP和企业商定。可以通过使用RIDPolicy类和应用程序层选项来简化商定的策略。第9.1节所述的RID加密和数字签名指南解决了一些隐私问题。
RID is useful in determining the true source of an incident that traverses multiple networks or to communicate security incidents and automate the response. The information obtained from the investigation may determine the identity of the source host or the SP used by the source of the traffic. It should be noted that the trace mechanism used across a single SP 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-SP level and are out of scope for RID messaging.
RID有助于确定穿越多个网络的事件的真实来源，或传达安全事件并自动响应。从调查中获得的信息可以确定源主机或流量源使用的SP的身份。应注意，跨单个SP使用的跟踪机制也可能会引起网络客户端的隐私问题。可能引起关注的方法包括那些涉及将数据包存储一段时间以便在事后跟踪数据包的方法。监控网络的入侵和跟踪功能也会引起对可能正在穿越监控网络的潜在敏感有效流量的关注。IDSs和单一网络跟踪不在本文档范围内，但应在网络使用指南中注意并解决该问题。一些IDS和单网络跟踪机制试图正确解决这些问题。RID旨在提供任何单一网络跟踪机制所需的信息。提供商对单一跟踪机制的选择取决于资源、现有解决方案和当地立法。有关单个网络跟踪的隐私问题必须在客户端到SP级别处理，并且不在RID消息传递的范围内。
The identity of the true source of an attack 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 SP. Alternatively, the action taken may be listed without the identity being revealed to the originating SP. 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 SP that
通过RID追踪的攻击真正来源的身份可能很敏感。结果消息中列出的真实身份可以通过使用原始SP的公共加密密钥对IODEF文档和RID结果信息进行加密[XMLencrypt]来保护。或者，可以列出所采取的行动，而不向发起SP透露身份。RID通信系统的最终目标是停止或缓解攻击流量，而不是确保相关方知道攻击流量的身份。SP认为
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 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 SP in the path of the trace becomes 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 a Request or Report, where the originating SP is aware of the SP 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 SP to ensure that no other SP in the path can read the contents. The encryption is accomplished through the W3C [XMLencrypt] specification for encrypting an element.
每当敏感数据通过网络时，隐私就成为一个问题。例如，如果攻击发生在特定源和目标之间，则跟踪路径中的每个SP都会意识到发生了网络攻击。在有针对性的攻击中，可能不希望有关正在进行网络战争的两个民族国家的信息成为所有中间方的常识。但是，重要的是允许跟踪发生，以便停止活动，因为在攻击期间，路径中网络的健康也可能受到威胁。这提供了第二个参数，用于允许结果消息仅包括已执行的操作，而不包括违规主机的标识。对于请求或报告，如果发起SP知道将接收处理请求的SP，则可以使用目标SP的公钥对文档的自由格式文本区域进行加密[XMLencrypt]，以确保路径中的其他SP无法读取内容。加密是通过W3C[XMLencrypt]规范来完成的，该规范用于加密元素。
In some situations, all network traffic of a nation may be granted through a single SP. In that situation, options must support sending Result messages from a downstream peer of that SP. That option provides an additional level of abstraction to hide the identity and the SP 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.
在某些情况下，一个国家的所有网络流量都可以通过单个SP授予。在这种情况下，选项必须支持从该SP的下游对等方发送结果消息。该选项提供额外的抽象级别，以隐藏已识别流量源的身份和SP。在跟踪发生后，法律行动可能会推翻此技术决定，但这超出了本文件的技术范围。
Privacy concerns when using an Request message to request action close to the source of valid attack traffic need to be considered. Although the intermediate SPs may relay the request if there is no direct trust relationship to the closest SP to the source, the intermediate SPs 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 SP in the path. Therefore, the contents of the request may be encrypted for the destination system. The intermediate SPs only need to know how to direct the request to the manager of the ASN in which the source IP address belongs.
当使用请求消息请求接近有效攻击流量源的操作时，需要考虑隐私问题。尽管中间SP在与距离源最近的SP没有直接信任关系的情况下可以中继请求，但中间SP不需要能够查看请求中的数据包内容或文本描述字段。此消息类型不需要中间RID系统执行任何操作，只需将数据包中继到路径中的下一个SP即可。因此，可以针对目的地系统对请求的内容进行加密。中间SP只需要知道如何将请求定向到源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 includes 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. Request messages and requested actions to mitigate or stop 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 SPs 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通信会引发其他问题，尤其是当对等联盟位于不同的地区或国家时。缓解或停止流量的请求消息和请求操作必须遵守适当的使用指南，同时防止系统被滥用。首先，对等联盟必须确定可在每个联盟的参与SP边界之间追踪的流量类型。跟踪的流量应限于与安全事件相关的流量。第二，一个联盟内允许的痕迹，如果传递给对等联盟，可能会侵犯对等联盟的信息自由法。一个例子是，一个国家的一个财团允许跟踪含有不良物质的交通，这在该国是非法的。RID跟踪可能是该国网络边界范围内系统的有效使用；但是，如果法律允许此类内容，则可能不允许继续跨越网络边界。通过在另一个国家的网络中继续跟踪，跟踪和响应可能会产生不当限制数据访问的效果。继续追踪第二个国家可能会违反该国的法律法规。任何此类痕迹都必须在该国边境停止。
The privacy concerns listed in this section address issues among the trusted parties involved in a trace within an SP, 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
本节列出的隐私问题解决了SP、RID联盟和对等RID联盟中跟踪涉及的受信任方之间的问题。用于RID通信的数据也必须受到保护，以防不受信任的各方访问。这种保护是通过对文档进行身份验证和加密来提供的
they traverse the path of trusted servers and through the local security controls in place for the incident management systems. Each RID system MUST perform a bidirectional 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 document is decrypted and re-encrypted at each RID system via TLS over a transport protocol such as [RFC6546]. 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系统在发送RID消息时必须执行双向身份验证，并使用上游或下游对等方的公共加密密钥通过网络发送消息或文档。这意味着文档在每个RID系统上通过TLS通过传输协议（如[RFC6546]）进行解密和重新加密。可以在每个RID系统上解密RID消息，以便正确处理请求或中继信息。今天的处理能力足以处理加密和解密相对较小的典型RID消息的最小负担。
The application layer can be used to establish workflows and rulesets specific to sharing profiles for entities or consortiums. The profiles can leverage sharing agreements to restrict data types or classifications of data that are shared. The level of information or classification of data shared with any entity may be based on protection levels offered by the receiving entity and periodic validation of those controls. The profile may also indicate how far information can be shared according to the entity and data type. The profile may also indicate whether requests to share data from an entity must go directly to that entity.
应用程序层可用于建立特定于实体或联盟共享配置文件的工作流和规则集。配置文件可以利用共享协议来限制共享数据的数据类型或分类。与任何实体共享的信息级别或数据分类可基于接收实体提供的保护级别以及这些控制的定期验证。配置文件还可以指示根据实体和数据类型可以共享信息的程度。配置文件还可以指示来自实体的共享数据请求是否必须直接发送给该实体。
In some cases, pre-defined sharing profiles will be possible. These include any use case where an agreement is in place in advance of sharing. Examples may be between clients and SPs, entities such as partners, or consortiums. There may be other cases when sharing profiles may not be established in advance, such as an organization dealing with an incident who requires assistance from an entity that it has not worked with before. An organization may want to establish sharing profiles specific to possible user groups to prepare for possible incident scenarios. The user groups could include business partners, industry peers, service providers, experts not part of a service provider, law enforcement, or regulatory reporting bodies.
在某些情况下，可以使用预定义的共享配置文件。这些包括在共享之前达成协议的任何用例。例如，客户与SP、合作伙伴等实体或联合体之间。在其他情况下，可能无法提前建立共享配置文件，例如处理事件的组织需要从未与之合作过的实体的帮助。组织可能希望建立特定于可能的用户组的共享配置文件，以便为可能的事件场景做好准备。用户组可以包括业务合作伙伴、行业同行、服务提供商、不属于服务提供商的专家、执法机构或监管报告机构。
Workflows to approve transactions may be specific to sharing profiles and data types. Application developers should include capabilities to enable these decision points for users of the system.
批准交易的工作流可能特定于共享配置文件和数据类型。应用程序开发人员应包括为系统用户启用这些决策点的功能。
Any expectations between entities to preserve the weight and admissibility of evidence should be handled at the policy and agreement level. A sharing profile may include notes or an indicator for approvers in workflows to reflect if such agreements exist.
实体之间对保留证据的重要性和可采性的任何期望都应在政策和协议层面上处理。共享配置文件可能包括工作流中审批人的注释或指标，以反映是否存在此类协议。
RID has many security requirements and considerations built into the design of the protocol, several of which are described in the Security Requirements section. For a complete view of security, considerations include the availability, confidentiality, and integrity concerns for the transport, storage, and exchange of information.
RID在协议设计中有许多安全需求和考虑因素，其中一些在安全需求部分中进行了描述。要全面了解安全性，需要考虑信息传输、存储和交换的可用性、机密性和完整性问题。
Protected tunnels between systems accepting RID communications are used to provide confidentiality, integrity, authenticity, and privacy for the data at the transport layer. Encryption and digital signatures are also used at the IODEF document level through RID options to provide confidentiality, integrity, authenticity, privacy and traceability of the document contents at the application layer. Trust relationships are based on PKI and the comparison/validation of security controls for the incident management systems communicating via RID. Trust levels can be established in cross-certification processes where entities compare PKI policies that include the specific management and handling of an entity's PKI and certificates issued under that policy. [RFC3647] defines an Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework that may be used in the comparison of policies to establish trust levels and agreements between entities, an entity and a consortium, and consortiums. The agreements SHOULD consider key management practices including the ability to perform path validation on certificates [RFC5280], key distribution techniques [RFC2585], and Certificate Authority and Registration Authority management practices.
接受RID通信的系统之间的受保护隧道用于在传输层为数据提供机密性、完整性、真实性和隐私。还通过RID选项在IODEF文档级别使用加密和数字签名，以在应用层提供文档内容的机密性、完整性、真实性、隐私性和可追溯性。信任关系基于PKI和通过RID通信的事件管理系统的安全控制比较/验证。可以在交叉认证过程中建立信任级别，其中实体比较PKI策略，其中包括对实体PKI的特定管理和处理以及根据该策略颁发的证书。[RFC3647]定义了一个Internet X.509公钥基础设施证书策略和认证实践框架，可用于比较策略，以建立实体、实体和联合体以及联合体之间的信任级别和协议。协议应考虑关键的管理实践，包括对证书[RCF5280]、密钥分发技术[RCF2585 ]和证书颁发机构和注册机构管理实践进行路径验证的能力。
The agreements between entities SHOULD also include a common understanding of the usage of RID security, policy, and privacy options discussed in both the Security Requirements and Security Considerations sections. The formality, requirements, and complexity of the agreements for the certificate policy, practices, supporting infrastructure, and the use of RID options SHOULD be decided by the entities or consortiums creating those agreements.
实体之间的协议还应包括对RID安全、策略和隐私选项使用的共同理解，这些选项在安全要求和安全注意事项部分都有讨论。证书政策、实践、支持基础设施和RID选项使用协议的形式、要求和复杂性应由创建这些协议的实体或联盟决定。
The Node class identifies a host or network device. This document reuses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class. If they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels
Node类标识主机或网络设备。本文件重用了IODEF规范[RFC5070]第3.16节中节点的定义。然而，该文档没有明确说明节点名是否可以是国际化域名（IDN）。RID系统必须将NodeName类视为域名插槽[RFC5890]。RID系统应支持NodeName类中的IDN。如果他们这样做，则必须使用域名的UTF-8表示，即所有域名的标签都必须是U型标签
expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891].
以UTF-8或NR-LDH标签[RFC5890]表示；不得使用A标签。通过RID进行通信的应用程序可以通过使用A标签的Punycode编码[RFC3492]在A标签和U标签之间进行转换，如应用程序中国际化域名的协议规范[RFC5891]所述。
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-2.0
URI: urn:ietf:params:xml:ns:iodef-rid-2.0
Registrant Contact: IESG.
注册人联系人：IESG。
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-2.0
URI: urn:ietf:params:xml:schema:iodef-rid-2.0
Registrant Contact: IESG.
注册人联系人：IESG。
XML: See Section 8, "RID Schema Definition", of this document.
XML：参见本文档第8节“RID模式定义”。
The following registry has been created and is now managed by IANA:
以下注册表已创建，现在由IANA管理：
Name of the registry: "XML Schemas Exchanged via RID"
注册表名称：“通过RID交换的XML模式”
Namespace details: A registry entry for an XML Schema Transferred via RID consists of:
命名空间详细信息：通过RID传输的XML架构的注册表项包括：
Schema Name: A short string that represents the schema referenced. This value is for reference only in the table. The version of the schema MUST be included in this string to allow for multiple versions of the same specification to be in the registry.
架构名称：表示所引用架构的短字符串。此值仅供表中参考。架构的版本必须包含在此字符串中，以允许同一规范的多个版本位于注册表中。
Version: The version of the registered XML schema. The version is a string that SHOULD be formatted as numbers separated by a '.' (period) character.
版本：已注册XML架构的版本。版本是一个字符串，其格式应为以“.”（句点）字符分隔的数字。
Namespace: The namespace of the referenced XML schema. This is represented in the RID ReportSchema class in the XMLSchemaID attribute as an enumerated value is represented by a URN or URI.
名称空间：引用的XML架构的名称空间。这在XMLSchemaID属性的RID ReportSchema类中表示为枚举值，由URN或URI表示。
Specification URI: A URI [RFC3986] from which the registered specification can be obtained. The specification MUST be publicly available from this URI.
规范URI：可以从中获得注册规范的URI[RFC3986]。规范必须从此URI公开可用。
Reference: The reference to the document that describes the schema.
引用：对描述架构的文档的引用。
Information that must be provided to assign a new value: The above list of information.
分配新值必须提供的信息：上述信息列表。
Fields to record in the registry: Schema Name, Version, Namespace, Specification URI, Reference
要在注册表中记录的字段：架构名称、版本、命名空间、规范URI、引用
Initial registry contents: See Section 5.6.1.
初始注册表内容：见第5.6.1节。
Allocation Policy: Expert Review [RFC5226] and Specification Required [RFC5226].
分配政策：专家评审[RFC5226]和所需规范[RFC5226]。
The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to retrieve the XML schema specification from the provided URI in order to check the public availability of the specification and verify the correctness of the URI. An important responsibility of the Designated Expert is to ensure that the XML schema is appropriate for use in RID.
如果存在任何此类工作组，指定专家应咨询MILE（托管事件轻量交换）工作组或其继任者（例如，通过电子邮件发送至工作组的邮件列表）。指定的专家将从提供的URI中检索XML模式规范，以检查规范的公共可用性并验证URI的正确性。指定专家的一项重要职责是确保XML模式适合在RID中使用。
The following registry has been created and is now managed by IANA:
以下注册表已创建，现在由IANA管理：
Name of the registry: "RID Enumeration List"
注册表名称：“RID枚举列表”
The registry is intended to enable enumeration value additions to attributes in the iodef-rid XML schema.
注册表用于在iodef rid XML模式中为属性添加枚举值。
Fields to record in the registry: Attribute Name, Attribute Value, Description, Reference
要在注册表中记录的字段：属性名称、属性值、描述、引用
Initial registry content: none.
初始注册表内容：无。
Allocation Policy: Expert Review [RFC5226]
分配政策：专家评审[RFC5226]
The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to review the request and validate the appropriateness of the enumeration for the attribute. If a specification is associated with the request, it MUST be reviewed by the Designated Expert.
如果存在任何此类工作组，指定专家应咨询MILE（托管事件轻量交换）工作组或其继任者（例如，通过电子邮件发送至工作组的邮件列表）。指定专家应审查请求并验证属性枚举的适当性。如果规范与请求相关，则必须由指定专家进行审查。
Security incidents have always been difficult to trace as a result of 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. SPs need policies and automated methods to combat the hacker's efforts. SPs 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 SP resources for each aspect of attack detection, tracing, and source identification and extends the communication capabilities among SPs. The communication is accomplished through the use of flexible IODEF XML-based documents passed between incident-handling systems or RID systems. A Request is communicated to an upstream SP 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 SPs, which is essential for incident handling.
由于欺骗源、资源限制和带宽利用问题，安全事件始终难以跟踪。即使已知IP地址有效，事件响应通常也很慢，因为通知责任方攻击、然后停止或缓解攻击流量所需的资源。近实时识别和跟踪攻击的方法对于挫败攻击企图至关重要。SP需要策略和自动化方法来打击黑客的行为。SP需要自动监控和响应功能，以快速识别和跟踪攻击，而不会产生资源密集型副作用。与集中通信系统集成以协调单个网络上攻击源的检测、跟踪和识别至关重要。RID为攻击检测、跟踪和源识别的各个方面提供了一种集成SP资源的方法，并扩展了SP之间的通信能力。通过在事件处理系统或RID系统之间使用灵活的基于IODEF XML的文档来完成通信。请求被传送到上游SP，并可能导致上游跟踪或停止或缓解攻击流量的操作。通过现有标准（如XML加密和数字签名）提供的RID消息传递方案所固有的安全性，在对等方之间传递消息。通过使用RIDPolicy，RID消息本身携带策略信息。RID提供SP之间的及时通信，这对于事件处理至关重要。
[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月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，2002年3月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年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月。
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051]Eastlake，D.，“额外的XML安全统一资源标识符（URI）”，RFC4051，2005年4月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[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月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012.
[RFC6546]Trammell，B.，“通过HTTP/TLS传输实时网络间防御（RID）消息”，RFC 6546，2012年4月。
[XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C Recommendation XML 1.0, November 2008, <http://www.w3.org/TR/xml/>.
[XML1.0]Bray，T.，Maler，E.，Paoli，J.，Sperberg McQueen，C.，和F.Yergeau，“可扩展标记语言（XML）1.0”，W3C建议XML 1.0，2008年11月<http://www.w3.org/TR/xml/>.
[XMLCanon] Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0, December 2001, <http://www.w3.org/TR/xml-c14n>.
[XMLCanon]Boyer，J.，“规范XML 1.0”，W3C建议1.0，2001年12月<http://www.w3.org/TR/xml-c14n>.
[XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, December 2010, <http://www.w3.org/TR/xpath20/>.
[XMLPath]Berglund，A.，Boag，S.，Chamberlin，D.，Fernandez，M.，Kay，M.，Robie，J.，和J.Simeon，“XML模式第1部分：结构”，W3C建议第二版，2010年12月<http://www.w3.org/TR/xpath20/>.
[XMLSigBP] Hirsch, F. and P. Datta, "XML-Signature Best Practices", W3C Recommendation, August 2011, <http://www.w3.org/TR/xmldsig-bestpractices/>.
[XMLSigBP]Hirsch，F.和P.Datta，“XML签名最佳实践”，W3C建议，2011年8月<http://www.w3.org/TR/xmldsig-bestpractices/>.
[XMLencrypt] Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax and Processing", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLencrypt]Imaura，T.，Dillaway，B.，和E.Simon，“XML加密语法和处理”，W3C建议，2002年12月<http://www.w3.org/TR/xmlenc-core/>.
[XMLschema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[XMLschema]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构”，W3C建议第二版，2004年10月<http://www.w3.org/TR/xmlschema-1/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. Simon, "XML-Signature Syntax and Processing", W3C Recommendation Second Edition, June 2008, <http://www.w3.org/TR/xmldsig-core/>.
[XMLsig]Bartel，M.，Boyer，J.，Fox，B.，LaMaccia，B.，和E.Simon，“XML签名语法和处理”，W3C建议第二版，2008年6月<http://www.w3.org/TR/xmldsig-core/>.
[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月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[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月。
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010.
[RFC6045]Moriarty，K.，“实时网络间防御（RID）”，RFC 60452010年11月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 61942011年3月。
[XMLNames] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation , December 2009, <http://www.w3.org/TR/xml-names/>.
[XMLNames]Bray，T.，Hollander，D.，Layman，A.，Tobin，R.，和H.Thomson，“XML 1.0中的名称空间（第三版）”，W3C建议，2009年12月<http://www.w3.org/TR/xml-names/>.
Many thanks to colleagues and the Internet community for reviewing and commenting on the document as well as providing recommendations to improve, simplify, and secure the protocol: Steve Bellovin, David Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin, Stephen Northcutt, Damir Rajnovic, Tony Rutkowski, Peter Saint-Andre, Jeffrey Schiller, Robert Sparks, William Streilein, Richard Struse, Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and David Waltermire.
非常感谢各位同事和互联网社区对该文件进行审查和评论，并提供改进、简化和保护该协议的建议：史蒂夫·贝洛文、大卫·布莱克、哈罗德·布斯、保罗·西孔斯基、罗伯特·K·坎宁安、罗曼·达尼略、尤里·德麦克亨科、桑德拉·G·戴克斯、斯蒂芬·法雷尔、凯瑟琳·古迪埃、，辛西娅·麦克莱恩、托马斯·米勒、让·弗朗索瓦·莫芬、斯蒂芬·诺思卡特、达米尔·拉吉诺维奇、托尼·鲁特考斯基、彼得·圣安德烈、杰弗里·席勒、罗伯特·斯帕克斯、威廉·斯特里林、理查德·斯特劳斯、托尼·托伯、布赖恩·特拉梅尔、肖恩·特纳、伊尔吉奇·范·贝伊南和大卫·沃尔特米尔。
Author's Address
作者地址
Kathleen M. Moriarty EMC Corporation 176 South Street Hopkinton, MA United States
Kathleen M.Moriarty EMC Corporation美国马萨诸塞州霍普金顿南街176号
EMail: Kathleen.Moriarty@emc.com
EMail: Kathleen.Moriarty@emc.com