RFC 6545 - Real-time Inter-network Defense (RID) 日本語訳

URL : https://tools.ietf.org/html/rfc6545
タイトル : RFC 6545 - リアルタイムの間のネットワーク防衛（RID）
翻訳編集 : 自動生成

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)

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で取得することができます。

著作権表示

著作権（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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

           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

1. Introduction

1. はじめに

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, 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.

入射処理は、良性の構成問題、ITインシデント、サービスレベルアグリーメント（SLA）に違反、システム妥協、社会工学フィッシング攻撃、またはdenial-であるか否かを、検出、報告、識別、およびインシデントの緩和を含みます等（DoS）攻撃、サービスの入射が検出された場合、応答は、単にレポートを提出含んでいてもよい、入射のソース、解像度/緩和のためのSPへの要求、またはソースを見つけるための要求への通知。より困難な例の一つは、場所を取るために更なる行動の可能性を、ネットワークを介して繰り返し上流の攻撃トラフィックをトレースする能力を必要とし、ここで攻撃の発生源が不明であることです。ターゲットや被害者のシステムとソースまたは攻撃システムとの間でアクティブなセッションの正確な記録が可能です例では、ソースは特定しやすいです。

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間の関連情報を通信する方法を提供することを目的とします。インシデントは、RIDがセキュリティ以外のITインシデントの間、またはプロバイダ内の通信を可能にする情報技術（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メッセージングは、XMLセキュリティ、プライバシー、およびRIDスキーマに設定されたポリシー情報を利用しています。 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 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.

他のCSIRTとの連携は、厳密に技術的な問題ではありません。数多くの手続き、信頼、および情報を共有する体制を妨げる可能性がある法的な考慮事項があります。 RIDは、その情報を共有するための独自のポリシーを適用しなければならない組織で使用できる情報やオプションを提供します。組織はRIDプロトコルとIODEFを使用するための方針と手順を開発する必要があります。

1.1. Changes from

1.1. からの変更点

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.

[RFC6045]は情報として公開されたまま、oこの文書では、標準化過程です。

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:

編集は、RIDのこの更新されたバージョンに反映oを主に情報提供の説明に改善されています。説明は、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スキーマのバージョンがインクリメントされました。スキーマは、1つのDataWithHandlingRequirements列挙を追加するために、AcrossNationalBoundaries領域列挙を除去するために、正当化属性に追加の列挙を含むように、エラッタを確認含むように、新しいReportSchemaクラスを使用RIDPolicyクラスのRIDに包まIODEF [RFC5070]を含むように変更されていますTrafficTypesで、とに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名より正確そのメッセージ・タイプの機能を表すために、肯定応答と交換しました。テキストは、メッセージを照会し、レポートに応答して、このメッセージの使用の可能性に留意することが明らかになりました。属性は、言語サポートのための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.

TraceRequest及び調査メッセージoを自動化するために必要な機能に応じてのMsgTypeを設定する必要のある単一のメッセージに集約されています。メッセージの説明は、所望の機能に応じて例外ままのMsgType、を除いて同一でした。 MsgTypeための列挙の両方がそれぞれの要求であるので、「調査」は現在、「InvestigationRequest」です。コンテンツは、指定された要求のタイプにIODEF文書内で変えることができます。

o The IncidentQuery message description name and MsgType enumeration value in the schema have been changed to the more generic name of 'Query'.

IncidentQueryメッセージの記述名とスキーマ内のMsgType列挙値O「クエリ」のより一般的な名前に変更されました。

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.

IODEFとIODEF-RIDスキーマ内の制約属性：Oガイダンスは、具体的にIODEF、データマーカに基づいて機密性を提供するために一貫性の実装とXML暗号化を使用することを確実にするために改善されています。属性も指導にも適用されるIODEF拡張スキーマ、中に存在することができます。追加のガイダンスと制限がXMLの要件のために追加されました。

o All of the normative text from the Security Considerations section has been moved to a new section, Security Requirements.

O Security Considerations部からの規範的なテキストのすべてが新しいセクション、セキュリティ要件に移動されました。

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 RIDスキーマは、セクション5に提示される順序は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デジタル署名と暗号化の使用に関する厳格な指針との相互運用性を向上させるために提供されています。

1.2. Normative and Informative

1.2. 規範的で有益

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を実装するために必要とされます。

1.3. Terminology

1.3. 用語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. Characteristics of Incidents

インシデントの2.特徴

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）に違反、システム妥協、ワームまたはトロイの木馬感染、または一または複数のソースサービス拒否攻撃、良性の構成の問題として定義することができます。セキュリティインシデントを追跡の目的は、ソースを識別するために、または可能な限りインシデントの原点に近いネットワーク上の点を見つけることであってもよいです。入射トレースを停止または望ましくない挙動を緩和または同定問題を修正するために、攻撃のソース（S）を同定するために用いることができます。 RIDメッセージは、報告またはインシデントの任意のタイプを調査し、入射又は近いソースへのポイントのソースが既知であるか、識別されたときにアクションが取られるべきを可能にするために、エンティティ間で通信することができます。緩和を達成する方法は、フィルタリングまたは近いソースへのトラフィックをレート制限、またはホストまたはネットワークをオフラインにする、構成の問題の修復を含むことができます。ケアも捜査に関係する各SPで、攻撃トラフィックをRID通信に関わるシステムが虐待を受けていないことを確認するために、攻撃トラフィックがある場合は、実際に、決定する際に適切な分析を使用するように注意する必要があります。

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またはHTTPリクエストのDNSサーバなどのビジネスに不可欠なサービスを、であるため、ブロックすることはできません有効な宛先サービスを含めることができます。

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.

インシデントのソース（S）は、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を詳細に入射し、入射の特性（それが進化するように）、入射履歴、およびインシデントの解像度及び報告を容易にするために、インシデントの通信を使用することができます。

3. Communication between CSIRTs and Service Providers

CSIRTとサービスプロバイダの間3.コミュニケーション

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 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.

サービスプロバイダ間のネットワークアクセスポイントを横断することができるセキュリティ関連の事故に応答するときのCSIRTとのSPとの間の通信を促進することが不可欠です。このインターサービスプロバイダセキュリティインシデントの通信に関与する緊急性の結果として、相互作用を容易にする代わりに、効果的なシステムが存在しなければなりません。この通信政策や方法は、単一障害点を回避するために、複数の通信手段を関与させるべきです。メール事件、パケットトレース、などしかし、電子メールがタイムリーに受信されていないか、または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].

コンソーシアムは、フェデレーションまたはIODEF-RID XML文書の安全な輸送を促進する合意された政策と通信プロトコルとのRID通信プロトコルに参加することに同意し、サービスプロバイダまたはのCSIRTのグループで構成されてできました。 RIDメッセージのための交通は、[RFC6546]で指定されています。

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の目標の1つは、他のネットワークの機器へのアクセスを許可する必要性を防ぐためです。 RIDは、コンソーシアムまたは隣接ネットワーク内の他のプロバイダへの入射処理情報の通信を可能にする標準的なメッセージング・メカニズムを提供します。上記第三者が小さいプロバイダを介して入射処理およびおそらくトレースバックを容易にするのを助けるために、この技術的な解決策に使用することができます。 RIDメッセージングメカニズムは、通信が安全で攻撃を受けたネットワークの状態によって影響を受けないことを保証するために、論理的または物理的なアウトオブバンドネットワークであってもよいです。 2つの管理方法は、ネットワークの完全な管理を維持するために、より大きなプロバイダのニーズに対応するだろう、とサードパーティのオプションでは、インシデントハンドリング操作を実行するために必要な人材が不足している小さなプロバイダに利用可能である可能性があります。第一の方法は、ネットワークを介して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などの外部支援グループの連絡先情報が含まれている必要があります）または調査の国の政府機関を支援する他の。

3.1. Inter-Service-Provider RID Messaging

3.1. インターサービス・プロバイダRIDメッセージング

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は、トラフィックの上流のソースを決定するために、ネットワークを介してトレースを発行します。謝辞と結果のメッセージは、リクエストのステータスと結果を通信するために使用されています。「InvestigationRequest」に設定オプションを使用して要求メッセージは、入射調査を支援する任意の当事者に送信することができます。 InvestigationRequestは近い筋に問題のあるトラフィックを軽減または停止し、二国間関係やコンソーシアムの相互接続を利用しています。ルートはInvestigationRequestの場合において既知の送信元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.

RID通信の起源の3連絡先情報。連絡先情報は、自律システム番号（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.ネットワークパス情報は、トレースを永続からネットワークを介して任意のルーティングのループを防ぐために。パスに独自の情報が含まれている「TraceRequest」に設定RIDシステムはのMsgTypeでリクエストを受信した場合、トレースは中止しなければならないと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 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プロトコルの使用は、事前に承認、認可のみを目的としなければなりません。それぞれの二国間ピアのピアリング契約を通じて確立または合意されたコンソーシアムのガイドライングローバル使用ポリシーの両方に記載されたガイドラインを遵守するために、各参加当事者の責任です。そのような政策の目的は、システムの乱用を避けるためです。ポリシーは、コンソーシアムや、参加エンティティによって開発されなければなりません。グローバルポリシーは、それがもとで動作し、ドメインに依存することができます。例えば、インターネットなどの政府のネットワークや商用ネットワークは、個々の懸念に対処するために別のガイドラインに準拠します。プライバシーの問題は、インターネットなどの公衆網に考慮されなければなりません。プライバシーの問題は、参加事業体が合意しなければならない他の要件とともに、セキュリティ要件のセクションで説明されています。

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システムは、ユーザの入力を必要とするか、または自動的にトレースを続けるのいずれかに設定可能でなければなりません。この機能は、「InvestigationRequest」または「TraceRequest」に設定要求メッセージを続行する前に、利用可能なリソースを評価するために、ネットワーク管理を可能にします。（IODEFで提供）信頼格付けが低い場合、それはInvestigationRequest 'または「TraceRequest」に設定されたオプションを使用して要求を続行するために、プロバイダの最善の利益にないかもしれません。信頼評価システムの乱用を避けるために使用される割合を選択するための仕様に準拠する必要があります。要求は、開始CSIRTから認可された個人によって発行されたピアリングやSLAを介して確立政策ガイドラインに記載されている必要があります。

3.2. RID Communication Topology

3.2. RID通信トポロジ

The most basic topology for communicating RID systems is a direct connection or a bilateral relationship as illustrated below.

RIDシステムを通信するための最も基本的なトポロジーは、直接接続、または以下に示すような二国間の関係です。

            ___________                                  __________
            |         |                                  |        |
            |  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, 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.

コンソーシアムのモデルの中で、いくつかのトポロジは、合意して使用される可能性があります。一つは、コンソーシアムのメンバーのピアリング関係国間のネットワークを活用します。 RIDのためのピアは、ルーティングピアのものと一致し、論理ネットワークの境界が使用されます。このアプローチは、ソースが不明である反復トレースのために必要な場合があります。モデルは、上の図のように見えます。しかしながら、形成された二国間の関係の相互接続の広範な数が存在してもよいです。また、コンソーシアムのモデルの中で、RIDメッセージを渡すためにネットワークの統合されたメッシュを確立することが有用であり得ます。ソースアドレスが既知である場合に有益であり得る、とのSPとの間の直接通信が可能でない場合、相互接続は、攻撃トラフィックのソースに最も近い上流のピアに到達するために高速経路を提供することができます。例を以下に示します。

       _______                     _______                     _______
       |     |                     |     |                     |     |
     __| 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や組織へのインシデント情報を配信するサービスプロバイダを含むことができます。

4. Message Formats

4.メッセージフォーマット

4.1. RID Data Types

4.1. RIDデータ型

RID is derived from the IODEF data model and inherits all of the data types defined in the IODEF model. One data type is added by RID: BOOLEAN.

RIDは、IODEFデータモデルに由来し、IODEFモデルで定義されたデータ型のすべてを継承しています。 BOOLEAN：一つのデータ型は、RIDによって追加されます。

4.1.1. Boolean

4.1.1. ブーリアン

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.

[XMLスキーマ]スキーマ内：Booleanデータ型は、「ブールXS」として実装されます。「1」または「真」TRUEおよび「0」または「false」またはFALSE：[XMLSCHEMA]でブールのための2つの語彙表現があることに注意してください。

4.2. RID Message Types

4.2. RIDメッセージタイプ

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.

以下に記載する5つのRIDメッセージタイプを実装する必要があります。 RIDメッセージはIODEF [RFC5070]及び[RFC6546]で指定されるように輸送用にカプセル化されなければならないRID文書、両方を使用します。メッセージが生成され、RIDの通信のための指定されたシステム上で受信されています。各RIDメッセージタイプは、例えばと共に、以下のセクションに記載されています。 IODEF-RIDスキーマを説明RIDメッセージタイプをサポートするために、セクション5で導入されています。

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.要求。要求（「InvestigationRequest」または「TraceRequest」）が必要とされる場合、このメッセージタイプは、使用されます。（「InvestigationRequest」に設定）要求メッセージの目的は、必要なアクションが取られるため、セキュリティ関連のインシデントの有効なトラフィックのソースに最も近いSPを通知するために既存のピア関係を活用することです。（「TraceRequest」に設定）要求は、トラフィックが「TraceRequest」へのMsgTypeを設定することにより、ソースを見つけるために、ネットワークを介して繰り返し追跡しなければならないときに使用されます。「InvestigationRequest」の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 also be used by the transport protocol to facilitate the communication of security incident data to trace, investigate, query, or report information regarding security incidents.

アプリケーションがRIDメッセージを受信すると、メッセージのタイプを判別し、それに応じてそれを解析することができなければなりません。メッセージタイプがRIDPolicyクラスで指定されています。 RIDPolicyクラスは、追跡調査、照会、またはセキュリティインシデントに関する情報を報告するために、セキュリティインシデントデータの通信を容易にするために、トランスポートプロトコルによって使用されてもよいです。

5. IODEF-RID Schema

5. IODEF-RIDスキーマ

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拡張に含まれる3つのクラスがあります。 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のAdditionalData拡張を使用しないで意図は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ドキュメントからこのデータを分離することは、各RIDホストでどのように処理すべきかを決定するためにIODEF文書を復号化し、解析するための必要性を除去し、暗号化する必要はありません。

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.

セキュリティ要件およびポリシーガイドラインは、ポリシーがRIDピア間および内またはコンソーシアム間で定義された第9節で議論されています。 RIDPolicyは、定義されたポリシーを容易にするためのツールであることを意味しています。これは、クライアント、ピア、コンソーシアム、および/または領域の間に設定されたポリシーに従って使用されなければなりません。この文書で指定されているセキュリティ、プライバシー、機密性を考えなければなりません。

The RID schema is defined as follows:

次のようにRIDスキーマが定義されています。

           +------------------+
           |        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.

0または1。 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.

0または1。 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.

0または1。 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].

3つのリストされたクラスの各々は、RIDクラスに含まれる唯一のクラス、ゼロまたは1つのために、従ってオプションであってもよいです。トランスポートプロトコル[RFC6546]で使用される場合、その情報ができるだけ小さくあるべきであり、暗号化されなくてもよいようにいくつかのケースでは、RIDPolicyは、RID定義で唯一のクラスであるかもしれ。 RequestStatusメッセージは、[RFC6546]あたりの必要な要素に伝送されるデータを制限し、通信を容易にするためにIODEF文書を必要とせずに単独で立つことができなければなりません。

The RID class has one attribute:

RIDクラスは、1つの属性があります。

lang

のみ

One. REQUIRED. ENUM. A valid language code per [RFC5646] constrained by the definition of "xs:language" inherited from [XML1.0].

1。必須。 ENUM。 [XML1.0]から継承された：「言語XS」の定義により制約[RFC5646]あたりの有効な言語コード。

5.1. RIDPolicy Class

5.1. RIDPolicyクラス

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 ]
          +------------------------+

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.

1。 Nodeクラスは、RIDメッセージを通信システムを識別するために、この場合には、ホストまたはネットワーク機器を識別するために使用され、そして使用はMsgDestination属性によって決定されます。このクラスの基本定義は、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.

ゼロまたは1つ。バックIODEFデータモデルで定義されIncidentIDを指すグローバル参照。 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.

一つまたは多数。必須。属性「地域」の値は、トレースが承認される前に、政策領域は考慮が必要かもしれないものを決定するために使用されています。 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.

一つまたは多数。必須。 ENUM。属性領域は、インシデント情報の予想される共有範囲を識別するために使用されます。領域は、領域内にあるか、そのようなサービスプロバイダへコンソーシアム又はクライアントのもののような既存の関係によって定義されてもよいです。

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. SPToClient。 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. IntraConsortium。合意された使用や乱用ガイドラインにコンソーシアムの境界内に制限はありません必要があるインシデント情報。コンソーシアムは設立メンバーと、そのグループ内の共有に固有の信頼関係と明確に定義されたグループです。コンソーシアムは、典型的には、事前に共有することができるデータの種類を定義するデータを保護するだけでなく、契約上の合意を確立した上で期待を定義します。コンソーシアムの例としては、業界に焦点を当てた共有コミュニティ（金融、政府、研究、教育、など）や、クロス業界の共有コミュニティ（共有グループを形成するローカル近接内のインスタンスのために、組織）を含んでいてもよいです。

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。 2つのピア間の制限はありませんべきであるが、合意された使用や乱用ガイドラインにそのポイントを超えて継続する前に、さらなる評価が必要な場合がありインシデント情報。 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. BetweenConsortiums。合意された使用や乱用のガイドラインを確立しているコンソーシアムとの間に制限はありません必要があるインシデント情報。 BetweenConsortiumsは、二つのコンソーシアム（上記IntraConsortiumで定義されるように）共有のデータを用いています。 BetweenConsortiumsを共有することができるデータの種類は、データが取り扱われ、保護されるべきかの期待に沿ったそれらの契約および契約で識別されなければなりません。

6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

6. EXT-値。この属性を拡張するために使用するエスケープ値。 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.

一つまたは多数。必須。属性「タイプ」の値は、トレースは、トレースを継続する要求を受信SPに適しているかどうかを判断するのに役立つことを意味しています。複数の値は、この要素のために選択することができます。ただし、可能な場合、それは最も正確トラフィックタイプを記述する1つの値に制限する必要があります。

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.

一つまたは多数。必須。 ENUM。属性タイプは、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. DataWithHandlingRequirements。データは、データの種類や場所、それが存在に基づいて取り扱い、保護のための追加の制限を有していてもよく、共有、および処理する場合、このオプションは使用されています。規制又は法的規制は、データまたは場所が起源の、場所、地域または国に基づいて変えることができる特定の種類のデータに課されてもよいです。 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. AudienceRestriction。このオプションは、メッセージが制限された聴衆によって見られるはずのデータが含まれていることを示すために使用されます。それは応答時間が遅くなる可能性があるので、この設定は、通常の事件やレポート作成のために使用すべきではありません。コンテンツは、ビジネス関連の通知または要求であってもよいです。このオプションは、レポートや事件がサプライチェーンに影響を与えた場合の援助を要求するために、ビジネスパートナーによって使用されるかもしれません。コンテンツは規制上の義務、法的（電子情報開示）、または管理の注意を必要とする他のユースケースに関連している場合は、このオプションを使用することもできます。

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.その他。このオプションが選択されている場合は政策決定は調査を継続または停止させることができるように、トラフィックタイプの説明が提供されなければなりません。情報はHistoryItemログを使用して期待クラスや歴史の授業でIODEFメッセージ内で提供されるべきです。これはまた、情報セキュリティ関連の事故以外の入射のタイプのために使用することができます。

7. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

7. EXT-値。この属性を拡張するために使用するエスケープ値。 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.

0または1。 ReportSchemaクラスはRIDエンベロープに含まれるフルIODEFスキーマを必要とするメッセージの種類によって使用されています。指定レビュアーによって承認され、RIDで使用するためのIANAによって登録された場合、代替のスキーマが含まれていてもよいです。

The RIDPolicy class has five attributes:

RIDPolicyクラスには、5つの属性があります。

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.

オプション。 ENUM。この属性は、送信者は受信者が付着する予定先の開示ガイドラインを示します。それはそれを尊重するために、文書の受信者の選択であるため、このガイドラインには、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。

MsgType

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'.

1。必須。 ENUM。 RIDメッセージのタイプを送信しました。メッセージの5つのタイプは、セクション4.2に記載されており、要求が「InvestigationRequest」または「TraceRequest」のいずれかに設定されている以下の6つの選択肢の一つとして注目され得ます。

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. TraceRequest。この要求メッセージはTraceRequestを開始するか、近いセキュリティインシデントの起源のソースアドレスに上流ネットワークへTraceRequestを継続するために使用されてもよいです。

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. InvestigationRequest。トラフィックの送信元が有効であると考えられているときに、この要求メッセージタイプが使用されています。 InvestigationRequestの目的は、セキュリティ関連の事故であってもよい、いくつかのイベントが発生した有効なトラフィックのソースに最も近い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.

EXT-値。この属性を拡張するために使用するエスケープ値。 IODEF [RFC5070]、セクション5.1を参照してください。

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.

1。必須。 ENUM。このレベルで必要な宛先のどちらかのMsgTypeが「InvestigationRequest」、インシデントのソースに設定して要求の場合、要求を受信し、又はように意図RIDメッセージングシステムであってもよいです。 InvestigationRequestの場合には、トラフィックを停止または軽減することができるRIDシステムが知られていないかもしれない、そしてメッセージは、最も近い攻撃トラフィックのソースにRIDシステムへのルーティング経路に従うことによってRIDメッセージングシステムを横断する必要がある可能性があり。 Node要素は、RIDシステムまたはソースのIPアドレスのいずれかを一覧表示し、ノード要素の値の意味はMsgDestination要素によって決定されます。

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. SourceOfIncident。 Node要素のアドレス要素は、入射元のIPアドレスが含まれており、NodeクラスののNodeName要素が使用されていません。このオプションを選択すると、IPアドレスが必要です。 IPアドレスが送信元によって使用されるIPアドレスが有効であると考えられている攻撃のソースとMsgDestinationとRequestメッセージに最も近いRIDシステムを見つけるために使用されるRID通信を受け入れるシステムの経路を決定するために使用されます「InvestigationRequest」に設定使用されています。ここで定義された値は、最初の要求（「InvestigationRequest」または「TraceRequest」）、ない結果メッセージに使用されるソースからのものであるので、これは、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. EXT-値。この属性を拡張するために使用するエスケープ値。すべての拡張機能は、RIDPolicyのNode要素の内容と意味を指定しなければなりません。拡張性に、IODEF [RFC5070]、セクション5.1を参照してください。ノードクラスのNodeName要素を拡張することによって使用されている場合、ノード名国際化ドメイン名（IDN）を含んでいてもよいです。適用される要件については、セクション11を参照してください。すべての拡張機能は、ノード識別の主な手段として、NodeクラスのAddress要素にIPアドレスを使用する必要があります。

MsgType-ext

MsgType-EXT

OPTIONAL. STRING. A means by which to extend the MsgType attribute. See IODEF [RFC5070], Section 5.1.

オプション。 STRING。 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

オプション。 STRING。 MsgDestination属性を拡張する手段。 IODEF [RFC5070]、セクション5.1を参照してください。

5.1.1. ReportSchema

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     ]
          |                         |
          +-------------------------+

Figure 5: The ReportSchema Class

図5：ReportSchemaクラス

The elements that constitute the ReportSchema class are as follows:

次のようにReportSchemaクラスを構成する要素は次のとおりです。

XMLDocument

XMLDocumentの

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.

1。 ExtensionTypeクラス：XMLDocumentのは、IODEFによって定義された完全なXML文書です。このクラスは、データ型が「XML」に設定されていると意味がXML文書を含めるように「XML」に設定されている[RFC5070]、セクション5、のガイドラインに従います。

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.

0または1。 URL。 XML文書のXMLスキーマへの参照が含まれています。スキーマ内の：URLのデータタイプは「anyURIのXS」として、セクション2.15、[RFC5070]で定義されています。 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クラスが取り外さまたはエンベロープ署名を含むようにこの要素を有効にします。このクラスは、データ型が「XML」に設定されていると意味がXML文書を含めるように「XML」に設定されている[RFC5070]第5節のガイドラインに従います。メッセージの発信元を確認するか、エンベロープ署名を含むようにIODEF文書内RecordItemクラス：この要素はIODEFに基づく分離署名をカプセル化するために使用されます。他のスキーマではなくIODEFの使用している場合は、それらを分離署名は、この目的のために提供されている場合に使用するどのようなクラスについてのガイダンスを提供しなければなりません。

The ReportSchema class has four attributes:

ReportSchemaクラスは、4つの属性があります。

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.

オプション。 1。バージョン属性は、指定されたXMLスキーマのバージョン番号です。そのスキーマは、IODEFの承認バージョンまたはRIDで使用するためのIANAに登録されたスキーマでなければなりません。 IODEF以外のスキーマを管理するためのIANAレジストリは、セクション12で指定されています。

ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

EXT-値。この属性を拡張するために使用するエスケープ値。 IODEF [RFC5070]、セクション5.1を参照してください。

ext-Version

EXT-バージョン

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.

オプション。 1。 EXT-Version属性には、付属のXMLスキーマのバージョン番号です。 IODEFまたはバージョンのために列挙されたリストに追加されているIANA登録スキーマ以外のスキーマが含まれている場合、この属性は使用されています。

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.

オプション。 1。 XMLSchemaID属性が識別子で、定義された名前空間は[XMLNAMES]、XML文書のXMLスキーマの含ま。 XMLSchemaIDとバージョンは、XMLDocumentの要素のフォーマットを指定します。のみ許可される値、IODEFの名前空間[RFC5070]が含まれる "URN：IETF：のparams：XML：NS：IODEF-1.0" を、IODEFの将来IETF認可のバージョン、および任意の名前空間はIANAの管理対象リストに含まRIDで使用するために登録されたスキーマ。 IODEF以外のスキーマを管理するためのIANAレジストリは、セクション12で指定されています。

ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.

EXT-値。この属性を拡張するために使用するエスケープ値。 IODEF [RFC5070]、セクション5.1を参照してください。

ext-XMLSchemaID

EXT-XMLSchemaID

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.

オプション。 1。 EXT-XMLSchemaID属性XML文書のXMLスキーマの識別子（定義された名前空間）が含まれています。 EXT-XMLSchemaIDとEXT-バージョンのXMLDocument要素のフォーマットを指定し、含まれるスキーマは、IODEFバージョン1.0またはXMLSchemaIDための列挙されたリストに追加されているIANAに登録スキーマでない場合に使用されます。

5.2. RequestStatus

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       |
                       |                                |
                       +--------------------------------+

Figure 6: The RequestStatus Class

図6：RequestStatusクラス

The RequestStatus class has five attributes:

RequestStatusクラスには、5つの属性があります。

restriction

制限

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.

1。必須。 ENUM。列挙された値が要求する要求の状況の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からのトラフィックをフィルタリングするために、このメッセージを使用することができます。謝辞メッセージが発信元に戻さなければならず、結果メッセージはIODEF歴史の授業で行われたアクションを示すために、ソースに近いSPから使用する必要があります。

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. EXT-値。この属性を拡張するために使用するエスケープ値。 IODEF [RFC5070]、セクション5.1を参照してください。

Justification

正当化

OPTIONAL. ENUM. Provides a reason for a Denied or Pending message.

オプション。 ENUM。拒否または保留中のメッセージの理由を提供します。

1. SystemResource. A resource issue exists on the systems that would be involved in the request.

1. SystemResource。リソースの問題は、リクエストに関与していることでしょうシステム上に存在します。

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. AuthenticationOrigin。 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. UnrecognizedFormat。提供文書のフォーマットが認識されませんでした。

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. CannotProcess。文書を処理できませんでした。理由は、法的または政策決定を含んでいてもよいです。決議は法的または政策の問題を解決するために、このプロトコルの外の通信が必要な場合があります。解決されるまで、それ以上のメッセージが送信されるべきではありません。

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. EXT-値。この属性を拡張するために使用するエスケープ値。 IODEF [RFC5070]、セクション5.1を参照してください。

AuthorizationStatus-ext

AuthorizationStatus-EXT

OPTIONAL. STRING. A means by which to extend the AuthorizationStatus attribute. See IODEF [RFC5070], Section 5.1.

オプション。 STRING。 AuthorizationStatus属性を拡張する手段。 IODEF [RFC5070]、セクション5.1を参照してください。

Justification-ext

正当化-EXT

OPTIONAL. STRING. A means by which to extend the Justification attribute. See IODEF [RFC5070], Section 5.1.

オプション。 STRING。正当化属性を拡張する手段。 IODEF [RFC5070]、セクション5.1を参照してください。

5.3. IncidentSource

The IncidentSource class is an aggregate class in the RID class.

IncidentSourceクラスはRIDクラスの集約クラスです。

          +-------------------+
          | 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.

1。 BOOLEAN。ソースが確認された場合はSourceクラスを示します。ソースが確認された場合は、このクラスのNode要素にリストされています。

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クラスは、入射の一部として識別されるシステムを識別するために使用されます。この要素を使用する場合は、Node要素のアドレス要素は、システムのIPアドレスを含まなければなりません。 NodeクラスののNodeName要素を使用する場合は、チェックが実行されたとき、それはそのIPアドレスに解決することを確認するためにチェックされているDNSドメイン名が含まれています。 NodeNameのための国際化の考慮事項については、このドキュメントのセクション11を参照してください。 IODEF（[RFC5070]、セクション3.16）からこのクラスのベース定義は、他の識別子を含むように拡張することができます。

The IncidentSource class has one attribute:

IncidentSourceクラスは、1つの属性があります。

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.

オプション。 ENUM。この属性は、送信者は、それはそれを尊重するために、文書の受信者の選択があるので、adhere.Thisガイドラインに受信者が本当のセキュリティを提供していない期待していたに開示ガイドラインを示します。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。

5.4. RID Name Spaces

5.4. RID名前空間

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スキーマは "：IETF：のparams：XML：NS：URN 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-ドキュメントバージョン= "2.0" LANG = "EN-US" のxmlns：IODEF-RID = "壷：IETF：のparams：XML：NS：IODEF-RID-2.0" のxmlns：XSI = "のhttp：// WWWを。 w3c.org/2001/XMLSchema-instance」XSI：のschemaLocation = "壷：IETF：のparams：XML：NS：IODEF-RID-2.0.xsd">

5.5. Encoding

5.5. エンコーディング

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）が必要です。すべてのXMLデータ符号化規則や制約にRID準拠しています。

The XML declaration with no character encoding will read as follows:

次のように無文字エンコーディングを持つXML宣言が読み込まれます。

<?xml version="1.0" encoding="UTF-8"?>

<？xml version = "1.0" エンコード= "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で特別な意味を持ち、その実体参照と同等でエスケープしなければならない：「＆」、「<」、「>」、「\」」（ダブルクォーテーション）、および「'」（アポストロフィ）これらのエンティティ。参照は、 "＆＃038;"、 "＆LT;"、 "＆GT;"、 "＆QUOT;"、および "'は、" それぞれ。

5.6. Including IODEF or Other XML Documents

5.6. IODEFまたは他のXML文書を含みます

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 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:

CSIRTの変更活動をサポートするために、RIDスキーマはIODEF又は他のデータモデルを含むことができます。 IODEFは、のCSIRTのニーズに沿って進化するスキーマを可能にも拡張可能です。このセクションでは、RIDを使用して確立されたセキュリティと信頼関係を活用するためにIODEFのXML文書または他のXML文書を含める方法について説明します。新しいデータを追加するRIDスキーマへの変更を必要としないように、これらの技術は設計されています。このアプローチはまた、唯一の、閉じたコンソーシアムに関連する民間のXML文書の交換をサポートしています。 XML文書はRIDPolicyクラスでReportSchemaクラスを介して含めることができます。 XMLDocumentの属性は、フルIODEFまたは他のXML文書を含めることができるようするために「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".

「IETF：paramsは：XML：NS：IODEF-1.0 URN」1含まれるスキーマは、IODEFのための宣言された名前空間として、別の名前空間を定義しなければなりません。

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.

パーサは、それが理解していない付属のXMLドキュメントを検出すると2は、含まれる文書は無視（及び処理されていない）が、ドキュメントの残りの部分が処理されなければならないれなければなりません。パーサは、彼らが名前空間宣言を通じて何の処理ロジックを持っていないそのための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.

それはRIDスキーマ内に既にあるので、URLは、必要に応じてIODEFのために含まれ、そしてのschemaLocationが定義されます。

5.6.1. Including XML Documents in RID

5.6.1. RIDのXML文書を含みます

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（Uniform Resource Identifier）、及び名前空間を含まなければなりません。以下はIODEFを超える追加のスキーマに必要な情報の例を提供します。

Example Name (XXXX)

例名（XXXX）

Schema Name: XXXX_1.1 Version: 1.1 Namespace: <registered namespace> Specification URI: http://www.example.com/XXXX

スキーマ名：XXXX_1.1バージョン：1.1名前空間：<登録済み名前空間>仕様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クラスのバージョン属性は、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値が取り込まれます。

6. RID Messages

6. RIDメッセージ

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スキーマは、RIDの通信を容易にするためにIODEF文書との組み合わせで使用されています。各メッセージタイプは、形式及び目的にわずかに変化します。したがって、要件が異なり、それぞれに指定されています。 IODEF-文書で定義されているすべてのクラス、要素、属性などは、RIDメッセージのコンテキストで有効です。各メッセージタイプにリストされているようしかし、IODEFにオプションとして記載され、いくつかは、RIDのために必須です。 IODEFモデルは完全にそれらのメッセージの適切な解析を保証するために、IODEFペイロードを含んRIDメッセージのために実装しなければなりません。

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のクラスで使用されるようなデフォルト値から各メッセージタイプのために必要な内容を記入する能力を自動化することができます。

6.1. Request

6.1. 要求

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 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:

説明：このメッセージタイプは、コンピュータのセキュリティ調査の支援を要求するために使用されます。調査依頼は、（事件はリクエストが送信されたにSPネットワーク上で発信されている可能性が）科学捜査を支援し、調査を継続することができ、他の当事者に向けることができる、またはANからのトラフィックを追跡するためにSPに向けることができます未知のソース。 MsgType有する要求メッセージは、セキュリティ関連の事故であってもよい、いくつかのイベントが発生し、有効なトラフィックのソースに最も近いSPを通知するために、既存の二国間のピア関係を活用することができる「InvestigationRequest」に設定しました。 MsgTypeが「TraceRequest」に設定して要求メッセージは、悪意のあるトラフィックのソースを見つけるために、ネットワークを介してトレースバックするために上流のピアに送信されてもよいです。以下の情報は、要求メッセージに必要であり、次のようなデータ構造を介して提供されています。

RID Information:

RID情報：

RIDPolicy

RID message type, IncidentID, and destination policy information

RIDメッセージタイプ、IncidentID、および宛先ポリシー情報

IODEF Information:

IODEF情報：

Timestamps (DetectTime, StartTime, EndTime, ReportTime).

タイムスタンプ（DetectTime、のStartTime、終了時間、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.

Systemクラスには、送信元と宛先の両方をリストするために使用されます。

Expectation class should be used to request any specific actions to be taken close to the source.

期待クラスは、近い筋に取られる特定のアクションを要求するために使用する必要があります。

Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to 'infrastructure'.

「インフラ」に設定されたカテゴリでIODEF EventDataのを使用して、トレースに使用する要求元で始まるネストされたRIDシステムのパス情報。

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.

イベントは、録音、及びRecordItemクラスは、例えば、パケットおよびインシデントに関連する他の情報を含むことができます。注意：ここに含まイベント情報はSPパスの連絡先情報を伝えるために使用されたものに加えて、EventDataの2番目のインスタンスが必要です。

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または署名要素のインスタンスに配置されRecordItemエントリをデタッチXMLデジタル署名を使用して要求を受信するすべてのシステムに渡さRIDメッセージを、送信プロバイダシステムを開始からのデジタル署名。

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.

Signature要素のインスタンスに配置されたIODEF文書にエンベロープXMLデジタル署名を使用してこのメッセージを作成CSIRTまたはプロバイダから、RIDメッセージの信憑性のためのCSIRTまたはSPを送信するデジタル署名。

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] Requestメッセージの内容を暗号化する機能が含まれます。インシデント番号は要求メッセージはシステム内の一意性を確保するために「InvestigationRequest」または「TraceRequest」に設定MsgDestinationを持っているかどうかを増加させます。中継ピアはまた、自律システム（AS）を追加または要求メッセージとしてパス情報を使用してRIDシステム情報は、SPSを介して中継されました。これは、応答（結果メッセージ）取られた行動を示す、リターン・メッセージの同じパスとの信頼関係を利用することができます。要求は、両方の開始および宛先SP RIDシステムの状態テーブルに記録されています。先SPは、任意のサービスレベル契約またはポリシーの遵守に要求の結果として取られた行動の原因です。 SPは、トラフィックが実際にどんな行動をとる前に疑いのシステムに由来することを確認し、要求の理由を確認する必要があります。リクエストは「SourceOfIncident」に設定既知のRIDシステムに直接送信又はRIDPolicyのMsgDestinationを用いた攻撃のソースアドレスによりルーティングすることができます。注：TraceRequestにおける任意の中間当事者は、適切に直接RIDメッセージために、応答メッセージ・タイプの情報をRIDPolicy表示できなければなりません。

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インスタンス番号は、より大きな入射の一部である関連するインシデントデータを相関させるために使用することができます。

6.2. Acknowledgement

6.2. 了承

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.

説明：確認応答はまた、任意のメッセージタイプにステータスを提供するために、メッセージが何らかの理由で処理できなかった場合は正当化を提供するために使用されます。このメッセージは、現在のSPにおいて要求ステータスに関する情報を提供するために、RID通信を受け入れるために指定次の上流プロバイダのアプリケーションまたはシステムから開始RIDシステムに送信されます。

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:

RequestStatusクラス：

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.

エンベロープXMLデジタル署名を使用してこのメッセージを作成CSIRTまたはプロバイダから、トレースステータスメッセージの信憑性のための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システムに保留されていることを確認します。 Pending状態は自動的にトレース継続を承認または却下するために、システムの定義済みまたは管理者の操作なしで2分のタイムアウト後に生成されます。要求が拒否された場合は、発信元と送信側ピアは、（それらが同じでない場合）の両方のメッセージを受信する必要があります。これは、できるだけ元に近いトラフィックを停止または軽減するための行動を取るためのオプションで送信ピアを提供します。

6.3. Result

6.3. 結果

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クラスは、ソースが識別された場合、注意と送信元アドレス（ES）または他のノード情報を提供するために使用されます。

IODEF Information:

IODEF情報：

Timestamps (DetectTime, StartTime, EndTime, ReportTime).

タイムスタンプ（DetectTime、のStartTime、終了時間、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クラスは、このように「TraceRequest」に設定RID上流の要求に必要な、攻撃に使用される送信元と宛先の両方の情報を一覧表示するには、トラフィックが偽装されている場合に注意しなければならない使用されています。

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).

「インフラ」に設定されたカテゴリでIODEF EventDataのを使用して、トレースに使用する要求元で始まるネストされたRIDシステムのパス情報。記載されている最後の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.

例えば、パケット及び入射（オプション）に関連する他の情報を含むイベント、レコード、およびRecordItemクラス。注意：ここに含まイベント情報はSPパスの連絡先情報を伝えるために使用されたものに加えて、EventDataの2番目のインスタンスが必要です。

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.

エンベロープXMLデジタル署名を使用してこのメッセージを作成CSIRTまたはプロバイダからの結果メッセージの信憑性のためのソース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を通知するバック開始CSIRTまたはプロバイダのRIDシステムに送信されます。実際のソース情報は、またはクライアントまたはホストが接続されているネットワークのポリシーに応じて、含まれていてもいなくてもよいです。トレースのソースの発見に作用するSPで撮影した任意のアクションが含まれなければなりません。 SPは攻撃の一部として発見されたマシン（複数可）のためのアウトバウンドアクセスをブロックするために彼らの境界ルータでフィルタの調整を自動化することができるかもしれません。フィルタは、包括的で、ホストが任意のセキュリティ問題を解決するための適切な措置を取ったまで、すべてのインターネットアクセスをブロックすることがあります。 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.

注：「：ATYPE IODEF」、またはアクションの種類、属性歴史クラスが使用してRID要求の結果として採用可能なアクションのすべてに対応するためにIODEFに拡張されました。歴史の授業は、説明と一緒にアクションの種類に最も適したオプションを使用してトレースまたはインシデントの発生源に近い撮影したすべてのアクションを注意するために使用する必要があります。期待クラスの「ATYPE」属性も要求が行われたときに適切なアクションを要求するために使用することができます。

6.4. Report

6.4. 報告書

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

RIDPolicy 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).

タイムスタンプ（DetectTime、のStartTime、終了時間、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).

イベントは、記録、およびRecordItemクラスは、たとえばパケットと入射（オプション）に関連する他の情報を含むために使用されます。

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 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.

セキュリティ要件は、先RIDシステムの公開鍵を使用して、[XMLencrypt]レポートメッセージの内容を暗号化する機能が含まれます。報告メッセージの送信者は、情報が等傾向、パターン検出の目的のために、セキュリティインシデント情報を相関させるために使用することができ、そうでなければ受信RIDシステムに合意しない限り、他の関係者と共有することができることに注意すべきです。そのため、レポートメッセージの送信者がレポートメッセージを送信する前に宛先アドレスやその他の機密情報を難読化または削除することができます。レポート・メッセージは、インシデントレポートを提出するか、クエリに応答するか送信され、データの機密性は、両方のケースで考慮されなければなりません。それは、2つの信頼RIDシステム間で直接通信するようにSPパス情報は、このメッセージのために必要ではありません。

6.5. Query

6.5. 質問

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).

タイムスタンプ（DetectTime、のStartTime、終了時間、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).

イベントは、記録、およびRecordItemクラスは、たとえばパケットと入射（オプション）に関連する他の情報を含むために使用されます。

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文書を送信します。応答を送信システムは、1つのレポートで返される文書の数に上限をあらかじめ設定します。推奨制限が大きくなりすぎるからドキュメントを防ぐために、5です。他の転送方法は、大量のデータ転送のためのRIDより適してもよいです。自信の評価が指定されているものと同等以上の信頼格付けを持つインシデントのみを選択するようにQueryメッセージで使用することができます。情報は、インシデントの種類ではなく、単一の事件について詳細にまとめられているときにケースに使用することができます。クエリは、事件の特定のタイプに関するデータを収集するために意図されている場合送信元と送信先の情報が必要とされなくてもよいです。

7. RID Communication Exchanges

7. 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は「InvestigationRequest」または「TraceRequest」に設定しました

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は、要素や属性を含めるための処理の考慮事項は、第4節[RFC3023]と[RFC3470]は要件とIETFアプリケーションプロトコルでXMLを使用するためのベストプラクティスを指定して、[RFC5070]で指定されたガイドラインに従わなければなりません。 RIDとIODEF文書は、十分に形成されなければならない（[RFC3470]、セクション4.1を参照）、適切なスキーマに対して検証されなければなりません。内部または外部DTDサブセットは、RIDで禁止されています。 [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文書のための準拠アリプロセッサによって無視することができます（[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ネットワークの範囲から使用されました。

7.1. Upstream Trace Communication Flow

7.1. 上流のトレース通信フロー

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

以下の図は、攻撃をトレースする異なるネットワーク上のRIDシステム間TraceRequestためRID要求通信の流れを概説します。 MsgDestinationと要求メッセージはに設定しました

'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

Destは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----->

5. Trace Initiated

5.トレース開始

    6.              <---Acknowledgement--o

7. Locate origin through upstream SP

7.上流SPを通じて起源を見つけ

    8.                              o---TraceRequest--->

9. Trace Initiated

9.トレース開始

    10.             <----------Acknowledgement----o
                                     <-Acknowledgement-o

11. Locate attack source on network X

11.ネットワークX上の攻撃元を見つけて

    12.             <------------Result----------------o

13. o- - - - -Acknowledgement- - - - - >

１３。おーーーーーあｃｋのｗぇｄげめんｔーーーーー＞

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 drains. Information such as the Source and Destination Information, associated packets, and the incident may be desirable to maintain for a period of time determined by administrators.

トレースが開始される前に、RIDシステムは、トレースのインスタンスまたは同様の要求がアクティブでないことを確認する必要があります。トレースは資源集約することができます。そのため、プロバイダは、システムまたは意図しないリソースドレインの潜在的な虐待を検出できるようにする必要があります。そのようなソースおよび宛先情報などの情報、関連するパケット、およびインシデントは、管理者によって決定される時間の間維持することが望ましい場合があります。

The communication flow demonstrates that 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.

通信フローは、肯定応答メッセージは、下流ピアと元の要求者の両方に送信されることを示します。トレースバックで要求が拒否された場合、下流ピアは行動を取ると結果のメッセージで応答するためのオプションがあります。 SPの下流ピアとフォローアップすることができる要求の発信元は、応答が受信されない場合、アクションがとられることを確実にするために「InvestigationRequest」に設定のMsgTypeで要求を使用して関与します。何も、それによってトレースが、その点を超えて必要とされている場合は、要求を拒否したSPをバイパス「TraceRequest」に設定のMsgTypeで新しい要求を開始からの要求の発信元を排除しません。別のオプションは、要求を拒否されたSPの上流SPに「InvestigationRequest」を送信するために、イニシエータためのものであってもよいです。このアクションは、十分な情報がインシデントハンドリング情報から攻撃トラフィックの真のソースを識別するために収集された前提としています。

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に適切な応答は、肯定応答メッセージです。確認応答メッセージは、トレースが次のアップストリームネットワークを通じて継続する場合は、要求者が知ることができます。このようなデジタル署名を検証または要求を復号化に失敗として要求に問題がある場合（これらは、同一でない場合）、肯定応答メッセージは、理由を提供要求者と下流のピアに送信する必要がありますメッセージを処理できませんでした。トレースが継続すると仮定すると、肯定応答メッセージの応答と追加TraceRequestsが発生することにより、インシデントに関連するトラフィックのソースへのパスの上流要求を渡します。ソースが検出されると接点が「インフラストラクチャ」に設定されているEventDataの、のドキュメント・インスタンスを介して設けられたSPの経路情報によって決定されるように、結果メッセージは、トレースの発信者に送信されます。最初のエントリ（トレース元）と最後のネストされたエントリ（下流ピア）に応答メッセージを送信するときにSPパス情報も使用されます。結果メッセージは、入射ソースについての情報を提供するための発信[XMLencrypt】暗号化され、任意の行動を取ります。発信者が結果メッセージを復号化または認証に失敗した場合は、確認応答メッセージが応答して送信されます。そうでない場合は、ノーリターンメッセージは送信されません。結果メッセージの最終的な確認は、上記の図ではオプションとして示されています。肯定応答メッセージが送信される場合RequestStatus拒否に設定して、このメッセージを受信した下流ピアはできるだけソースの近くに、ネットワーク内のその時点でトラフィックを停止または軽減するために行動を取ることを選択してもよいです。下流ピアは、このオプションを選択した場合、それはトレース元に結果メッセージを送信します。

7.1.1. RID TraceRequest Example

7.1.1. RID TraceRequest例

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.

MsgDestinationがIODEF文書から入射報告例に基づい「TraceRequest」に設定して記載されている例では、要求メッセージです。 RIDクラスはRIDPolicyクラスを使用して、このタイプの要求メッセージに応じて含まれていました。所与の例では、CSIRTの上流SPに進行中のDoS攻撃を報告することです。要求は、トレースを継続し、トラフィックが近いトラフィックの送信元に軽減持つように次のSPを要求します。例えば、要求メッセージは、「アタック取引先」は192.0.2.67（及びSP-1）で表される前の図に示されるようTraceRequestの最初のステップです。「アタックSrcのは」後で192.0.2.37および192.0.2.35当初に近いトレースなどとして結果メッセージの例で識別されます。 SP-1は、CSIRT-FOR-OUR-DOMAINとして要求において識別され、SP-2は、Nodeクラスを使用して、192.0.2.3として「MsgDestination」で「RIDSystem」として要求に対してRID文書内で識別されます。 SP-3は、後に結果メッセージで使用され、管理者は、彼らが192.0.2.35検索として「Admin-contact@10.1.1.2」として識別されます。管理者は、選挙の接触とは異なっていてもよい（MsgDestination有する追加要求が「TraceRequest」に設定SP-3は含まれていないとSP-2との間に発生しました）。 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はダイジェスト追加のアルゴリズムをサポートしています。 XMLデジタル署名、暗号化、および正規化での使用を意図URIのリファレンス[RFC4051]。 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-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" エンコード= "UTF-8" スタンドアロン= "なし"？> <IODEF-RID：LANG = "EN-US" のxmlnsをRID：IODEF-RID = "壷：IETF：のparams：XML： NS：IODEF-RID-2.0" のxmlns：IODEF = "壷：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領域= "IntraConsortium" /> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.3 </ IODEF：アドレス> </ IODEF：ノード> <IODEF-RID：TrafficTypeタイプ= "アタック" /> <IODEF：IncidentID名= "CERT-FOR-OUR-DOMAINは"> CERT-FOR-OUR-DOMAIN＃207-1は、</ IODEF：！IncidentID> < - IODEF-文書はRIDに含まれて - > <IODEF-RID：ReportSchemaバージョン=」 1.0 "> <IODEF-RID：XMLDocumentのDTYPE =" XML」の意味= "XML"> <IODEF-ドキュメントのlang = "EN"> <IODEF：インシデントの目的= "トレースバック" 制限= "知っておくべき"> < IODEF：IncidentID名= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN＃207-1 </ IODEF：IncidentID> <IODEF：DetectTime> 2004-02-02T22：49：24 + 00：00 </ IO DEF：DetectTime> <IODEF：のStartTime> 2004-02-02T22：19：24 + 00：00 </ IODEF：のStartTime> <IODEF：ReportTime> 2004-02-02T23：20：24 + 00：00 </ IODEF。 ReportTime> <IODEF：DoS攻撃に関与説明>ホスト</ IODEF：説明> <IODEF：評価> <IODEF：インパクト完了= "失敗" 重要度= "低" タイプ= "ドス" /> </ IODEF：アセスメント> <IODEF：連絡先役割= "生みの親" タイプ= "組織"> <IODEF：[担当> 192.0.2.35のための選挙接触</ IODEF：[担当> <IODEF：メール> Constituency-contact@192.0.2.35 </ IODEF：メール> </ IODEF：連絡先> <IODEF：EventDataの> <IODEF：フロー> <IODEF：Systemカテゴリ= "ソース"> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.35 </ IODEF ：アドレス> </ IODEF：ノード> <IODEF：サービスIP_PROTOCOL = "6"> <IODEF：ポート> 38765 </ IODEF：ポート> </ IODEF：サービス>

              </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：署名DTYPE = "XML" の意味= "XML"> <署名のxmlns = "http://www.w3.org/2000/09/xmldsig#" ID = "DSIG-123456"> <たSignedInfo> <CanonicalizationMethodにアルゴリズム= "http://www.w3.org/2001/10/xml-exc-c14n#" /> <のSignatureMethodアルゴリズム= "http://www.w3.org/2001/04/xmldsig-more ＃RSA-SHA256 "/> <参考URI =" "> <トランスフォーム> <変換アルゴリズム=" http://www.w3.org/2001/10/xml-exc-c14n# "/> <変換アルゴリズム=" 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-トランス= "http://www.w3.org/2002/06/xmldsig-filter2" フィルタ= ""> // DSIGを交差：署名【@Id = 'DSIG-123456'] /祖先:: IODEF-RID：ReportSchema / IODEF-RID：たXMLDocument / IODEF-文献[1] / IODEF：インシデント[1] / IODEF：EventDataの[1] / IODEF：レコード[1] / IODEF：たRecordData [1] / IODEF：RecordItem [1] </ XPathの> </変換> </トランスフォーム> <DigestMethodアルゴリズム= "http://www.w3.org/2001/04/xmlenc# SHA256" /> <DigestValue> NQuIhPjdZuZJnPi / hW62dwJT1dR + vqcZV8mp emCVN5g = </ DigestValue> </リファレンス> </た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> <弾性率> z8adrX9m0S8OxIxN + fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3 / dMs2a4diIxyGLV h0r86QXWH / W6T2IC2ny + HI + jWRwXrvgTY3ZAFgePvz2OdRhVN / cUbOto4Pa4I2mVZWW + / Q0F n7YpqPBDDxlGq / xyFPuYq / 4y7Y +あ+ vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86 uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i / DqnFgxfmdg3oru + YeiEPVRY8hyQpYbtgryveZOHT gnCHmS / 53U9jSS0cyb / ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw == </弾性率> <指数> AQAB </指数> </ RSAKeyValue> </です。KeyValue> </のKeyInfo> </署名> </ IODEF-RID：署名>

</iodef-rid:ReportSchema> </iodef-rid:RIDPolicy> </iodef-rid:RID>

<！ - デタッチXML署名の終わりには、RIDに含まれて - > </ IODEF-RID：ReportSchema> </ IODEF-RID：RIDPolicy> </ IODEF-RID：RID>

7.1.2. Acknowledgement Message Example

7.1.2. 謝辞メッセージの例

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：IODEF-RID = "URN：IETF：paramsは：XML：NS：IODEF-RID-2.0" のxmlns：IODEF = "URN：IETF：paramsは：XML：NS：IODEFのlang = "EN" のxmlnsをRID -1.0 "> <IODEF-RID：RIDPolicyのMsgType =" 確認」MsgDestination = "RIDSystem"> <IODEF-RID：PolicyRegion地域= "IntraConsortium" /> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに" > 192.0.2.67 </ IODEF：アドレス> </ IODEF：ノード> <IODEF-RID：TrafficTypeタイプ= "アタック" /> <IODEF：IncidentID名= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR -domain＃207-1 </ IODEF：IncidentID> </ IODEF-RID：RIDPolicy> <IODEF-RID：RequestStatus AuthorizationStatus = "承認済み" /> </ IODEF-RID：RID>

7.1.3. Result Message Example

7.1.3. メッセージの例を結果

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が進行中であるメッセージの要求フロー内の謝辞の後に来ます。それはInvestigationRequest 'に設定のMsgTypeとのリクエストに直接応答することがあります。このメッセージは、攻撃やトラフィックを軽減するために取られた行動のソースに関する情報を提供します。結果メッセージは通常、要求フローの最後のメッセージです。検索結果を受け取るか、または処理するすべての問題がある場合はしかし、謝辞に従うことができます。

</iodef:Node> <iodef-rid:TrafficType type="Attack"/> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN#207-1 </iodef:IncidentID>  <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：ノード> <IODEF-RID：TrafficTypeタイプ= "アタック" /> <IODEF：IncidentID名= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN＃207-1 </ IODEF： IncidentID> < - IODEF-DocumentはRIDに含まれて - > <IODEF-RID：！ReportSchemaバージョン= "1.0"> <IODEF-RID：XMLDocumentのDTYPE = "XML" の意味= "XML"> <IODEF：IODEF-ドキュメントLANG = "EN"> <IODEF：インシデント制限= "知っておくべき" 目的= "トレースバック"> <IODEF：IncidentID名= "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：説明> DoS攻撃に関与ホスト</ IODEF：説明> <IODEF：アセスメント> <IODEF：影響の重大度は= "低" 完了= "失敗" タイプ= "ドス" /> </ IODEF：アセスメント> <IODEF：連絡先の役割= "生みの親" タイプは、= "組織"> <IODEF：[担当> Constituency- 192.0.2.35のための連絡先</ IODEF：[担当> <IODEF：メール> Constituency-contact@192.0.2.35 </ IODEF：エマIL> </ IODEF：連絡先> <IODEF：EventDataの> <IODEF：連絡先の役割= "管理者" タイプ= "組織"> <IODEF：[担当> 192.0.2.35 </ IODEFのAdmin接触：[担当> <IODEF：メール> Admin-contact@10.1.1.2 </ IODEF：メール> </ IODEF：連絡先> <IODEF：フロー> <IODEF：Systemカテゴリ= "中間"> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.35 </ IODEF：アドレス> </ IODEF：ノード> </ IODEF：システム> </ IODEF：フロー> <IODEF：EventDataの> <IODEF：連絡先役割=" 管理者」タイプ= "組織"> < [担当> <IODEF：メール> Admin-contact@192.0.2.3 </ IODEF：メール> </ IODEF：連絡先> <IODEF：フロー> <IODEF：システムIODEF：192.0.2.3 </ IODEFのために担当者名>管理者接触カテゴリ=「中間」>

              <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>  </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：歴史> <IODEF：HistoryItemアクションは= "レート制限ホスト"> <IODEF：日時> 2004-02-02T22：53：01 + 00：00 </ IODEF：日時> <IODEF：IncidentID名=」 CSIRT-FOR-OUR-DOMAIN」> CSIRT-FOR-OUR-DOMAIN＃207-1 </ IODEF：IncidentID> <IODEF：説明> 192.0.2.35に近い次の上流SPに送信される通知</ IODEF：説明> </ IODEF：HistoryItem> <IODEF：HistoryItemアクション= "レート制限ホスト"> <IODEF：日時> 2004-02-02T23：07：21 + 00：00 </ IODEF：日時> <IODEF：IncidentID名= "CSIRT -for-SP3" > CSIRT-FOR-SP3＃3291から1 </ IODEF：IncidentID> <IODEF：説明>ホスト・レートが制限された24時間</ IODEF：説明> </ IODEF：HistoryItem> </ IODEF：歴史> </ IODEF：インシデント> </ IODEF：IODEF-ドキュメント> </ IODEF-RID：！のXMLDocument> < - IODEF - ドキュメントの最後には、RIDに含まれて - > </ IODEF-RID：ReportSchema> </ iodef-駆除：RIDPolicyを> <IODEF-RID：IncidentSource> <IODEF-RID：SourceFound>真</ IODEF-RID：SourceFound> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.37 </ IODEF ：アドレス> </ IODEF：ノード> </ IODEF-RID：IncidentSource> </ IODEF-RI D：RID>

7.2. Investigation Request Communication Flow

7.2. 調査依頼の通信フロー

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は、要求メッセージの「InvestigationRequest」に設定され、「調査」として以下の図に含まれています。「InvestigationRequest」に設定MsgDestinationで要求に適切な応答は、結果メッセージです。このようなデジタル署名を検証またはリクエストを復号化する障害などの要求、に問題がある場合、確認メッセージが要求者に送信されます。確認応答メッセージは、メッセージを処理できなかった理由を提供する必要があります。

Attack Dest SP-1 SP-2 Attack Src

攻撃DestはSP-1 SP-2攻撃のSrc

1. Attack | Attack reported | detected

1.攻撃|アタック報告|検出されました

2. Determine source of security incident

2.セキュリティインシデントのソースを決定します

       3.              o---Investigation---->

4. Research incident and determine appropriate actions to take

4.研究の事件と取るべき適切なアクションを決定

       5.              <-------Result-------o

Figure 9: Investigation Request Communication Flow

図9：調査依頼の通信フロー

7.2.1. Investigation Request Example

7.2.1. 調査要求例

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「はInvestigationRequest」に設定されています。適切な場合、偽装として入射光源を可能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のための接触を「Constituency-contact@10.1.1.2」としてリクエストの開始時に知られています。

<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN#208-1 </iodef:IncidentID>  <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名前は= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN＃208-1は、</ IODEF：IncidentID> <！ - IODEF-DocumentはRIDに含まれて - > <IODEF-RID ：ReportSchemaバージョン= "1.0"> <IODEF-RID：XMLDocumentのDTYPE = "XML" の意味= "XML"> <IODEF：IODEF-ドキュメントのlang = "EN"> <IODEF：インシデント制限= "知る必要性"目的= "その他"> <IODEF：IncidentID名= "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：終了時間> 2004-02-05T08：13： 33 + 00：00 </ IODEF：終了時間> <IODEF：ReportTime> 2004-02-05T08：13：35 + 00：00 </ IODEF：ReportTime> <IODEF：説明> DoS攻撃に関与する宿主</ IODEF：概要> <IODEF：評価> <IODEF：インパクトの重大度は= "低" 完了= "失敗" タイプ= "偵察" /> </ IODEF：アセスメント> <IODEF：連絡先の役割= "生みの親" タイプ= "組織"> <IODEF ：[担当> 192.0.2.35 </ IODEFのための選挙接触：[担当> <IODEF：メール> Constituency-contact@10.1.1.2 </ IODEF：エマIL> </ IODEF：連絡先> <IODEF：EventDataの> <IODEF：フロー> <IODEF：Systemカテゴリ= "ソース"> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.35 </ IODEF：アドレス> </ IODEF：ノード> <IODEF：サービスIP_PROTOCOL = "6"> <IODEF：ポート> 41421 </ IODEF：ポート> </ IODEF：サービス> </ IODEF：システム> <IODEF：Systemカテゴリ= "ターゲット"> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.67 </ IODEF：アドレス> </ IODEF：ノード> <IODEF：サービスIP_PROTOCOL = "6"> <IODEF：ポート> 80 </ IODEF：ポート> </ IODEF：サービス> </ IODEF：システム> </ IODEF：フロー> <IODEF：期待の重大度= "高" アクション= "調査"> <IODEF：説明>ソースがあるかどうかを調査危険にさらされて

</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>  </iodef-rid:ReportSchema> </iodef-rid:RIDPolicy> </iodef-rid:RID>

</ IODEF：概要> </ IODEF：期待> </ IODEF：EventDataの> <IODEF：歴史> <IODEF：HistoryItemアクション= "ブロック・ホスト"> <IODEF：日時> 2004-02-05T08：19：01+ 0：00 </ IODEF：日時> <IODEF：IncidentID名= "CSIRT-FOR-OUR-DOMAIN"> CSIRT-FOR-OUR-DOMAIN＃208-1 </ IODEF：IncidentID> <IODEF：説明>送られた調査依頼192.0.2.35のためのSPへの</ IODEF：説明> </ IODEF：HistoryItem> </ IODEF：歴史> </ IODEF：インシデント> </ IODEF：IODEF-ドキュメント> </ IODEF-RID：のXMLDocument> <！ - IODEF - ドキュメントの最後にはRIDに含まれて - > </ IODEF-RID：ReportSchema> </ IODEF-RID：RIDPolicy> </ IODEF-RID：RID>

7.2.2. Acknowledgement Message Example

7.2.2. 謝辞メッセージの例

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：IODEF-RID = "URN：IETF：paramsは：XML：NS：IODEF-RID-2.0" のxmlns：IODEF = "URN：IETF：paramsは：XML：NS：IODEFのlang = "EN" のxmlnsをRID -1.0 "> <IODEF-RID：RIDPolicyのMsgType =" 確認」MsgDestination = "RIDSystem"> <IODEF-RID：PolicyRegion地域= "IntraConsortium" /> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに" > 192.0.2.67 </ IODEF：アドレス> </ IODEF：ノード> <IODEF-RID：TrafficTypeタイプ= "アタック" /> <IODEF：IncidentID名= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR -domain＃208-1 </ IODEF：IncidentID> </ IODEF-RID：RIDPolicy> <IODEF-RID：RequestStatus AuthorizationStatus = "拒否されました" 正当化= "認証" /> </ IODEF-RID：RID>

7.3. Report Communication Flow

7.3. レポートの通信フロー

The diagram below outlines the RID Report communication flow between RID systems on different SPs.

以下の図は、異なるSP上のRIDシステム間RIDレポート通信フローを概説します。

SP-1 SP-2

1. Generate incident information and prepare Report message

1.インシデント情報を生成し、報告メッセージを準備

        2.              o-------Report------->

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]を検証または要求を復号化する故障報告メッセージに問題がある場合、確認メッセージが要求者に送信されます。確認応答メッセージは、メッセージを処理できなかった理由を提供する必要があります。

7.3.1. Report Example

7.3.1. レポートの例

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文書と電子署名は「TraceRequest」に設定MsgDestinationと要求例と同様です。

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.

この例では、行われた攻撃に情報提供を目的と192.0.2.130でSP-2には、192.0.2.67でSP-1、CERT-FOR-OUR-DOMAINから送信されたメッセージです。

<iodef-rid:TrafficType type="Attack"/> <iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN#209-1 </iodef:IncidentID>  <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タイプ= "アタック" /> <IODEF：IncidentID名= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR-DOMAIN＃209-1 </ IODEF：IncidentID> <！ - IODEF-DocumentはRIDに含まれて - > <IODEF-RID：ReportSchema> <IODEF-RID：XMLDocumentのDTYPE = "XML" の意味= "XML"> <IODEF：IODEF-ドキュメントのlang = "EN"> <IODEF：インシデント制限= "報告" = "知る必要性" 目的> <IODEF：IncidentID名= "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：終了時間> 2004-02-05T10：35：00 + 00：00 </ IODEF：終了時間> <IODEF：ReportTime> 2004-02-05T10：27：38 + 00：00 </ IODEF：ReportTime> <IODEF：概要>ホスト不正アクセス管理者アカウント</ IODEF：説明> <IODEF：評価> <IODEF：インパクトの重大度は= "高" 完了= "成功" タイプは、= "管理者" /> <IODEF：信頼格付け= "高" /> </ IODEF：評価> <IODEF：連絡先役割= "生みの親" タイプ= "組織"> <IODEF：192.0.2のための担当者名>選挙接触0.35 </ IODEF：[担当> <IODEF：メール> Constituency-contact@10.1.1.2 </ IODEF：メール> </ IODEF：連絡先> <IODEF：EventDataの> <IODEF：フロー> <IODEF：Systemカテゴリ= "ソース"> <IODEF：ノード> <IODEF：住所カテゴリ=" のIPv4-addrに "> 192.0.2.35 </ IODEF：アドレス> </ IODEF：ノード> <IODEF：サービスIP_PROTOCOL =" 6" > <IODEF：ポート> 32821 </ IODEF：ポート> </ IODEF：サービス> </ IODEF：システム> <IODEF：Systemカテゴリ= "ターゲット"> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに"> 192.0.2.67 </ IODEF：アドレス> </ IODEF：ノード> <IODEF：サービスIP_PROTOCOL = "6"> <IODEF：ポート> 22 </ IODEF：ポート> </ IODEF：サービス> </ IODEF：システム>

</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>  </iodef-rid:ReportSchema> </iodef-rid:RIDPolicy> </iodef-rid:RID>

</ IODEF：フロー> </ IODEF：EventDataの> <IODEF：歴史> <IODEF：HistoryItemアクション= "レート制限ホスト"> <IODEF：日時> 2004-02-05T10：28：00 + 00：00 < / IODEF：日時> <IODEF：IncidentID名= "CSIRT-FOR-OUR-DOMAIN"> CSIRT-FOR-OUR-DOMAIN＃209-1 </ IODEF：192.0のためにSPに送信された説明>インシデントレポート：IncidentID> <IODEF .2.35 </ IODEF：説明> </ IODEF：HistoryItem> </ IODEF：歴史> </ IODEF：インシデント> </ IODEF：IODEF-ドキュメント> </ IODEF-RID：のXMLDocument> <！ - IODEF-の終わり文書は、RIDに含まれて - > </ IODEF-RID：ReportSchema> </ IODEF-RID：RIDPolicy> </ IODEF-RID：RID>

7.4. Query Communication Flow

7.4. クエリの通信フロー

The diagram below outlines the RID Query communication flow between RID systems on different networks.

以下の図は、異なるネットワーク上のRIDシステム間RIDクエリ通信フローを概説します。

SP-1 SP-2

1. Generate a request for information on a specific incident number or incident type

1.特定の入射番号またはインシデントの種類に関する情報の要求を生成します

        2.              o-------Query------->

3. Verify policy information and determine if matches exist for requested information

3.ポリシー情報を確認し、一致が要求された情報のために存在するかどうかを判断

        4.              <-------Report------o

5. Associate report to request by incident number or type and file report(s).

5.関連付けレポートは、インシデント数またはタイプとファイルレポート（S）で要求します。

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.

Queryメッセージの通信は、レポートメッセージの応答を受け取ります。レポートメッセージが空の場合、応答のホストは、要求者と共有するために利用可能な情報を持っていませんでした。レポートを提出することができ、常に要請されていないため、入射数と応答RIDシステム、並びに輸送は、要求と応答の関連付けを助けます。そのようなデジタル署名を検証したり、要求を解読する障害などクエリメッセージに問題がある場合、確認メッセージが要求者に送信されます。確認応答メッセージは、メッセージを処理できなかった理由を提供する必要があります。

7.4.1. Query Example

7.4.1. クエリの例

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パケットデータは、要求を完了するために必要とされなくてもよいです。インシデントの種類が要求された場合は、インシデント数がNULLのままであり、IPパケットデータは、IODEF RecordItemクラスに含まれないであろう。他のインシデント情報は、比較のための主要な供給源です。事件番号のCSIRT間で同じではない可能性がある場合には、インシデント番号及び/又はIPパケット情報は、（a）は、報告メッセージ（S）を生成する受信RIDシステム上の比較のために提供して使用することができます。

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.

このクエリは、識別子CERT-FOR-OUR-DOMAIN＃210-1との事件についてのお問い合わせ、192.0.2.3に送信されます。レポートは、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：IODEF-RID = "URN：IETF：paramsは：XML：NS：IODEF-RID-2.0" のxmlns：IODEF = "URN：IETF：paramsは：XML：NS：IODEFのlang = "EN" のxmlnsをRID -1.0 "> <IODEF-RID：RIDPolicyのMsgType =" Query」のMsgDestination = "RIDSystem"> <IODEF-RID：PolicyRegion地域= "PeerToPeer" /> <IODEF：ノード> <IODEF：住所カテゴリ= "のIPv4-addrに" > 192.0.2.3 </ IODEF：アドレス> </ IODEF：ノード> <IODEF-RID：TrafficTypeタイプ= "アタック" /> <IODEF：IncidentID名= "CERT-FOR-OUR-DOMAIN"> CERT-FOR-OUR -domain＃210-1 </ IODEF：IncidentID> </ IODEF-RID：RIDPolicy> </ IODEF-RID：RID>

8. RID Schema Definition

8. 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" エンコード= "UTF-8"？> <XS：スキーマのxmlns：IODEF-RID = "壷：IETF：のparams：XML：NS：IODEF-RID-2.0" のxmlns：IODEF = "壷：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 = "壷：IETF：のparams：XML：NS：IODEF-RID-2.0" のelementFormDefault = "資格" attributeFormDefaultは= "非修飾">は、<XS：インポートの名前空間=" 壷：IETF：のparams：XML：NS ：IODEF-1.0" のschemaLocation = "http://www.iana.org/assignments/xml-registry/schema/ IODEF-1.0.xsd" /> <XS：インポート名前空間= "http://www.w3.org / 2000/09 / XMLDSIG位」のschemaLocation = "http://www.w3.org/TR/xmldsig-core/ XMLDSIG-コアschema.xsd" />

<!-- ====== Real-Time Inter-network Defense - RID ====== ==== Suggested definition for RID messaging ======

<！ - ********************************************** ****************** ******************************** ************************************* ***リアルタイムのネットワーク間の防衛 - RID XMLスキーマ*** ***名前空間 - IODEF-RID、2012年4月*** ***名前空間がIODEFの輸送をサポートするために定義されて*** ***インシデント情報を交換するための文書。 *** *********************************************** ********************** - > <！ - RIDメッセージは、インシデント情報の交換をサポートするためにIODEFやRID文書用封筒として機能 - > <！ - ======リアルタイムインターネットワーク防衛 - RID ====== ==== RIDメッセージングのための推奨定義======

-->

ーー＞

<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：注釈> <XS：ドキュメント> IODEFのためのXMLスキーマラッパー</ XS：ドキュメンテーション> </ XS：注釈> <XS：要素名= "RID" タイプ= "IODEF-RID：RIDType" /> <XS： complexTypeの名= "RIDType"> <XS：シーケンス> <XS：要素REF = "IODEF-RID：RIDPolicy" のminOccurs = "0" /> <XS：要素REF = "IODEF-RID：RequestStatus" のminOccurs = "0" /> <XS：要素REF = "IODEF-RID：IncidentSource" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "LANG" タイプ= "XS：言語" 使用= "必要" / > </ XS：complexTypeの>

<！ - 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：要素名= "RequestStatus" タイプは、= "IODEF-RID：RequestStatusType" /> <XS：complexTypeの名前= "RequestStatusType"> <XS：属性名= "AuthorizationStatus" 使用= "必要"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：whiteSpaceの値= "崩壊" /> <XS：列挙値= "承認済み" /> <XS：列挙値= "拒否" /> <XS：列挙値= "保留" /> <XS：列挙値= "EXT-値" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "EXT-AuthorizationStatus" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "正当化"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：whiteSpaceの値= "崩壊" /> <XS：列挙値= "SystemResource" /> <XS：列挙値= "認証" /> <XS：列挙値= "AuthenticationOrigin" /> <XS：列挙値= "暗号化" /> <XS：列挙値= "UnrecognizedFormat" /> <XS：列挙値= "CannotProcess" /> <XS：列挙値= "その他" /> <XS：列挙値= "EXT-値" /> </ XS：制限> </ XS：単純> </ X S：属性> <XS：属性名= "EXT-正当化" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "制限" タイプ= "IODEF：制限型" /> < / XS：complexTypeの>

<！ - 結果メッセージのためのインシデントソース情報 - >

<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：要素名= "IncidentSource" タイプ= "IODEF-RID：IncidentSourceType" /> <XS：complexTypeの名= "IncidentSourceType"> <XS：シーケンス> <XS：要素REF = "IODEF-RID：SourceFound" /> <XS：要素REF = "IODEF：ノード" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：属性名= "制限" タイプ= "IODEF：制限型" /> < / XS：complexTypeの> <XS：要素名= "SourceFound" タイプ= "XS：ブール値" />

<！ - ======リアルタイム間のネットワーク防衛政策 - RIDPolicy ====== ======メッセージングのためのRIDPolicyための定義 - >

<xs:annotation> <xs:documentation>RID Policy used for transport of messages</xs:documentation> </xs:annotation>

<XS：注釈> <XS：ドキュメント>メッセージの転送に使用RIDポリシー</ XS：ドキュメンテーション> </ XS：注釈>

<！ - RIDマニュアルに記載されている情報を設定してRIDPolicy情報 - >

<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：要素名= "RIDPolicy" タイプ= "IODEF-RID：RIDPolicyType" /> <XS：complexTypeの名前= "RIDPolicyType"> <XS：シーケンス> <XS：要素REF = "IODEF-RID：PolicyRegion" のmaxOccurs = "無制限" /> <XS：要素REF = "IODEF：ノード" /> <XS：要素REF = "IODEF-RID：TrafficType" のmaxOccurs = "無制限" /> <XS：要素REF = "IODEF：IncidentID" minOccurs属性= "0" /> <XS：要素REF = "IODEF-RID：ReportSchema" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "のMsgType" 使用= "必要"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：whiteSpaceの値= "崩壊" /> <XS：列挙値= "TraceRequest" /> <XS：列挙値= "肯定応答" /> <XS：列挙値= "結果" /> <XS：列挙値= "InvestigationRequest" /> <XS：列挙値= "レポート" /> <XS：列挙値= "クエリ" /> <XS：列挙値= "EXT-値 "/> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名=" EXT-のMsgType」タイプ= "XS：文字列" 使用= "オプション" /> <XS： > <XS "必要" =名= "MsgDestination" 使用属性：単純> <XS：制限ベース= "XS： NMTOKEN "> <XS：whiteSpaceの値=" 崩壊 "/> <XS：列挙値=" RIDSystem "/> <XS：列挙値=" SourceOfIncident "/> <XS：列挙値=" EXT-値 "/> < / XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "EXT-MsgDestination" タイプ= "XS：文字列"

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>  <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 = "オプション" /> <使用：属性名= "制限" タイプ= "IODEF：制限型" /> </ XS：complexTypeの> <XS：要素名= "PolicyRegion"> <XS：complexTypeの> <XS ：属性名= "領域" 使用= "必要"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：whiteSpaceの値= "崩壊" /> <XS：列挙値= "ClientToSP" /> <XS：列挙値= "SPToClient" /> <XS：列挙値= "IntraConsortium" /> <XS：列挙値= "PeerToPeer" /> <XS：列挙値= "BetweenConsortiums" /> <XS：列挙値= "EXT-値" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "EXT-領域" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "TrafficType"> <XS：complexTypeの> <XS：単純> <：属性名= "タイプ" の使用は=> <XS "必要" XS：制限ベース= "XS：NMTOKEN"> <XS：whiteSpaceの値= "崩壊" /> <XS：列挙値= "アタック" /> <XS：列挙値= "ネットワーク" /> <XS：列挙値= "コンテンツ" /> <XS：列挙値= "DataWithHandlingRequirements" /> <XS：エンumeration値= "AudienceRestriction" /> <XS：列挙値= "その他" /> <XS：列挙値= "EXT-値" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "EXT型" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素> < - RIDに包まれたXML文書を含めるために使用！ - > <XS：要素名= "ReportSchema" タイプ= "IODEF-RID：ReportSchemaType" /> <XS：complexTypeの名前= "ReportSchemaType"> <XS：シーケンス> <XS：= "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：要素REF = "IODEF-RID：URL" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素REF = "IODEF-RID：署名" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "バージョン" 使用= "オプション"> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：whiteSpaceの値= "崩壊" /> < XS：列挙値= "1.0" /> <XS：列挙値= "EXT-値" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "EXT-バージョン」タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "XMLSchemaID" 使用= "オプション"> <XS：単純> <XS：制限ベース= "XS：anyURIの"> <XS ：whiteSpaceの値= "崩壊" /> <XS：列挙値= "URN：IETF：paramsは：XML：NS：IODEF-1.0" /> <XS：列挙値= "EXT-値" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "EXT-XMLSchemaID" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> <XS：要素名= "たXMLDocument" タイプ= "IODEF：ExtensionType" /> <XS：要素名= "URL" タイプ= "XS：anyURIの" /> <XS：要素名= "署名" タイプ= "IODEF：ExtensionType" /> </ XS：スキーマ>

9. Security Requirements

9.セキュリティ要件

9.1. XML Digital Signatures and Encryption

9.1. XMLデジタル署名と暗号化

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]暗号化のXMLセキュリティ機能とデジタル署名[RFC3275] [XMLsig]が含まれます。基準は、メッセージは、セキュアな認証され、かつ認可されていることを確認するために、明確な方法を提供すること。ポリシーとプライバシーガイドラインを満たしています。そして、の整合性を維持します。 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クラスに含まれる元の要素の少なくとも1つの署名に分離署名を使用しなければなりません。発信者によって提供さRecordItemのすべてのインスタンスを個別に署名することができる、元RecordItemエントリ（S）と分離署名（S）を維持しながらトレースまたは調査上流ピアによる追加RecordItemエントリは、データを追加すること、ピアによって署名されてもよいですオリジナルのリクエスタから。データがRecordItemレベルで署名されていることに注意することが重要です。複数RecordItemsがIODEF文書内に存在してもよく、異なる供給源に由来することができるので、署名はXML分離署名の使用を可能にするためにRecordItemレベルで適用されます。生成されたXML文書は、次にReportSchemaクラスの署名要素内RIDメッセージに含まれているように、排他的正規化は、[XMLCanon]は、分離署名はなく、参照のために必要とされます。このシグネチャは、要求メッセージのすべての受信者に渡さなければなりません。

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.

要求がRecordItemエントリが含まれていない場合、O、タイムスタンプは、マルチホップ認証ユースケースのために署名されるべきデータがあることを確認するために使用されなければなりません。 IODEFの日時要素：たRecordDataクラス（[RFC5070]、セクション3.19.1）が、この目的のために使用されます。

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]ガイダンスは、セキュリティリスクを防止または軽減するために続くべきである（SHOULD）。例としては、処理前の署名（潜在的に危険な動作を実行する）、それらは、クロスサイトスクリプティング攻撃またはローカル情報へのアクセスを可能にすることができるので、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]サービス拒否攻撃のリスクを軽減するために参照すべき使用するためのベストプラクティスの推奨事項。 XSLT変換の使用は[XMLSigBP]のセキュリティガイダンスに従って制限しなければなりません。

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文書では、ピア間のセキュリティの余分なレイヤを提供するために、暗号化されてもよいです。この動作は、セキュリティ要件に応じて、メッセージごとに、ピアまたはコンソーシアム間で合意、または決定されます。運送書類[RFC6546]で説明するようにRIDPolicyクラスは、クリアテキストで提示する必要があります輸送用ケースがあることに留意すべきです。

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 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.

制限は、セキュリティ要件のセクションでXML暗号化のための指針に従い事件のプライバシー保護のためのセットの期待を属性とRFC 5070のセクション3.2で定義され、IODEF：IODEF oを制限属性がRIDクラスのいずれかに設定することができますインシデント情報を交換するための制限や暗号化要件を定義します。制限オプションは、IODEFの特定のクラス内、またはより限定された制限が望まれているIODEFの拡張、（任意の拡張子を含む）IODEF文書の完全な交換のための暗号化機能を有効にします。制限属性は、RIDクラスの各々に含まれ、IODEF文書または完全IODEF文書のいずれかのセクションの機密性の期待に応じて使用されなければなりません。交換ポリシーを作成するときのコンソーシアムや団体は、このガイダンスを考慮すべきです。

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.

制限が「プライベート」に設定されている場合は*、クラスまたは文書は、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クラスの1つに設定されている場合は*、制限は全体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はRIDPolicyに記載された情報を活用し、独自のセキュリティコントロールを管理するためにネットワークを参加するための機能を提供します。

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文書を転送または交換するために使用されます。実装は、セキュリティ上の意味合いに、実行時にスキーマをダウンロードする必要はありません、と含まれた文書は、そのスキーマの解決可能な場所を提供するために必須ではありません。

9.2. Message Transport

9.2. メッセージトランスポート

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メッセージだけでは、トランスポート層によって提供されるセキュリティに依存しないでください。 RIDメッセージの暗号化の要件および考慮事項は、このドキュメントのセクション9.1で議論されています。

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システムは、ブロック拡張交換プロトコル（BEEP）[RFC3080]などの他のプロトコルをサポートするかもしれません必要に応じて実装し、運送書類[RFC6546]で定義されるようにHTTPSを展開しなければなりません。バインディングは、他のトランスポートプロトコルのサポートを有効にするために定義する必要があります。

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システムはまた、暗号化されたトンネル会議にわたって最小コンソーシアムによって確立されたアルゴリズムと鍵の長さの要件、ピアリング、またはSLAでなければならない、リッスンのみ指定されたポート上でRIDメッセージを送らなければなりません。対称暗号化、デジタル署名、ハッシュ関数の選択された暗号化アルゴリズムは、時間の最小セキュリティレベルを満たさなければなりません。暗号化強度は、データ交換のために、関係国の輸入と輸出規制を遵守しなければなりません。

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メッセージングに使用インシデント管理システムを保護するために考慮されるべきです。データ転送を保護するための方法もまた、セッションの暗号化を介して提供することができます。

9.3. Public Key Infrastructure

9.3. 公開鍵基盤

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）と認定実務ステートメント（CPS）。 RIDのために事前に定義された関係を持つシステムは、直接または合意された適切な使用契約にコンソーシアムを介してピア者を含みます。他のエンティティを信頼する契約はCP、CPS、及び/又は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は、すべての関係者から信頼されなければならないと、このようなインターネット2連合PKIやサービスプロバイダにPKIを提供するために、ARIN / RIRの努力と同様の努力、を利用することができます。認証に使用されるPKIはまた、RIDトランスポートプロトコル[RFC6546]のために使用される暗号化のために必要な必要な証明書を提供します。

9.3.1. Authentication

9.3.1. 認証

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].

事前共有キーを使用することは、トランスポート層での認証のために考慮されてもよいです。このオプションが選択されている場合は、[RFC4279]「トランスポート層セキュリティ（TLS）のために事前共有キー暗号の組み合わせ」に記載された仕様に従わなければなりません。トランスポート仕様は別の文書[RFC6546]に詳述されています。

9.3.2. Multi-Hop Request Authentication

9.3.2. マルチホップ要求認証

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".

実用上の理由から、SPは要求、要求の発信元、およびインシデントについて記載されている信頼の評価のための即時のピアに基づいてインシデントハンドリングイベントの優先順位を決定することをお勧めします。要求の真正性の高い保証レベルを提供するために、発信RIDシステムは、連絡先情報とトレースが取った経路内のすべてのRIDシステムの情報とともに要求に含まれています。「インフラ」へのカテゴリ属性を設定しながら、この情報は、トレースに関わるシステムや連絡先のリストをネストIODEF EventDataのクラスを介して提供されます。

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 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.

マルチホップ認証を提供するために、発信RIDシステムはアップストリームパスのすべてのシステムに送信された要求にデジタル署名を含まなければなりません。 RIDシステムからのデジタル署名は、分離署名を使用してW3C [XMLsig]からXMLデジタル署名仕様以下IODEFのRecordItemクラスに対して実行されます。署名は、要求を受信するすべての当事者に渡さなければならない、各当事者は、デジタル署名[RFC5280]に完全なパス検証を行うことができなければなりません。要求をプロバイダ間に沿って通過し、署名が適用されている唯一の要素であるように、その要求に対応するために、RecordItemデータは不変のままでなければなりません。追加RecordItems上流ピアで文書に含まれている場合、初期RecordItemエントリは依然として分離署名で維持されなければなりません。後続RecordItem要素は、調査のためにインシデント情報を追加すること、ピアによって署名されてもよいです。この要件の第2の利点は、それが入射の上流トレースに後続の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は、RIDシステムおよび接続されている企業ネットワークとの間のRIDの通信を確保するために、独自のPKIを使用してもよいです。トレースに参加するSPはRID要求の信憑性を決定できなければなりません。

9.4. Consortiums and Public Key Infrastructures

9.4. コンソーシアムと公開鍵インフラストラクチャ

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.

RIDシステムによって使用される証明書を配布するためにPKIを使用して別のコンソーシアムに属するの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;

RIDシステムを保護するための物理的および論理的な慣行O;

o Network- and application-layer protection for RID systems and communications;

RIDシステムと通信するためのネットワーク - Oおよびアプリケーション層保護;

o Proper use guidelines for RID systems, messages, and requests; and

RIDシステム、メッセージ、および要求のための適切な使用ガイドラインO;そして

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との間の通信のために同じレベルのセキュリティを提供することができます。

9.5. Privacy Concerns and System Use Guidelines

9.5. プライバシーの懸念やシステムの使用に関するガイドライン

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 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 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.

O顧客ネットワークは、企業、教育、政府、またはRIDに参加してSPに接続されている他のネットワークを含むこともできます。お客様は、データがサービスプロバイダによって保護される方法を理解するために、データの取り扱い方針を見直すべきです。この情報は、サービスプロバイダーと共有することができるか、感度レベルでのデータの種類を決定するために顧客を可能にします。この情報は、エンティティやグループの共有プロファイルを確立するために、アプリケーション層で使用することができ、セクション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).

そのような監視またはRID接続ネットワーク（複数可）を介した通信のために使用される送信元および宛先の情報のOプライバシー。

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.

不適切な情報源を見つけるか、不法に管轄や地域内のトラフィックを軽減するために、トラフィックをトレースからコンソーシアムの参加のSPを禁止Oシステムを使用。

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ピアリングコンソーシアム間のシステムの使用が、このような暗号化の輸出と輸入制限など、これらの2つの領域の間で適用される政府の通信規制を検討すべきです。

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.

コンソーシアム、SPS、および企業が合意するために、上記のセキュリティとプライバシーの考慮事項があります。合意された政策が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間で使用されるトレースメカニズムは、ネットワークのクライアントのためのプライバシーの問題を提起できることに留意すべきです。懸念を提起する方法は、事実の後にパケットをトレースするために、時間のいくつかの長さのためにパケットを格納関与するものが含まれます。侵入のためや能力をトレースするためのネットワークを監視することも監視ネットワークを通過することができる潜在的に敏感な有効なトラフィックのための懸念を提起します。 IDSは単一のネットワークトレースは、この文書の範囲外であるが、懸念が指摘し、ネットワークの使用ガイドラインの範囲内に対処する必要があります。いくつかの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 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.

RIDてトレースされている攻撃の真の源のアイデンティティは敏感である可能性があります。結果メッセージに記載されている真のアイデンティティは、元のSPの公開暗号鍵を使用して、IODEF文書とRID結果情報を包む[XMLencrypt]暗号化を使用して保護することができます。代替的に、実行されるアクションは、IDを元のSPに明らかにされることなく挙げられます。 RID通信システムの究極の目標は、攻撃トラフィックの識別は関係者に知られることを保証するのではなく、攻撃トラフィックを停止または軽減することです。ソースを識別するSPは、それが機密とみなされた場合、このような情報のリリースのための指針を決定するために、関係者との適切な当局と直接取引する必要があります。いくつかの状況では、攻撃に使用されるシステムは、未知のソースによって侵害されていると、今度は、他のシステムを攻撃するために使用されています。そのような状況では、企業や組織の評判が危機に瀕していてもよく、行われたアクションは、発信システムに結果メッセージで報告された唯一の追加情報であってもよいです。セキュリティインシデントは、このような大規模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は、サイバー攻撃が発生したことを認識するようになります。標的型攻撃では、サイバー戦争を戦っている2つの国民国家の情報はすべて、中間当事者に一般的な知識になることが望ましいではないかもしれません。パス内のネットワークの健康状態も攻撃中に絡んで可能性があるためしかし、トレースが活動を停止するために場所を取ることができるようにすることが重要です。これは、実行されたアクションではなく、問題のあるホストのIDが含まれるように結果メッセージを可能にするための第二引数を提供します。元のSPは、処理要求を受信するSPを認識している要求またはレポートの場合は、文書の自由形式のテキスト領域は[XMLencrypt]に先SPの公開鍵を使って暗号化することができパスには、他の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は、要求パケットの内容またはテキスト記述フィールド（複数可）を見る能力を必要としません。パス内の次のSPにパケットを中継することを除いて、このメッセージタイプは、中間RIDシステムによる任意のアクションを必要としません。したがって、要求の内容は、宛先システムのために暗号化されてもよいです。中間の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の境界の間でたどることができるトラフィックの種類を特定する必要があります。トレースされたトラフィックは、セキュリティインシデント関連のトラフィックに制限する必要があります。第二に、1つのコンソーシアム内許さトレースは、ピアリングコンソーシアムに渡された場合、ピアリングコンソーシアムの自由-の情報法律を侵害することがあります。例では、その国の中に非合法好ましくない材料を含むトラフィックのトレースを、許可一つの国におけるコンソーシアムだろう。 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 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.

SP内のトレースに関わる信頼できる関係者の間で、このセクションアドレスの問題に記載されているプライバシーの問題、RIDコンソーシアム、およびRIDコンソーシアムをピアリング。 RIDの通信に使用されるデータも信頼されていない関係者から保護されなければなりません。彼らはインシデント管理システムのための場所で信頼のサーバーやローカルセキュリティ制御を通るパスを横断するように、この保護は、文書の認証と暗号化を介して提供されます。各RIDシステムは、RIDメッセージを送信するとき、双方向認証を実行し、ネットワークを介してメッセージや文書を送信するために、上流または下流のピアの公開暗号化鍵を使用しなければなりません。この文書は、例えば、[RFC6546]のようなトランスポートプロトコル上でTLSを介して復号化し、各RIDシステムで再暗号化されることを意味します。 RIDメッセージは正しく要求を処理するか、情報を中継するために、各RID方式で復号化することができます。今日の処理能力は比較的小さく、典型的なRIDメッセージを暗号化および復号化の最小限の負担を処理するのに十分以上のものです。

9.6. Sharing Profiles and Policies

9.6. プロファイルとポリシーを共有

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.

証拠の重みと許容を維持するエンティティ間の任意の期待が政策との契約レベルで処理されなければなりません。共有プロファイルは、そのような契約が存在する場合に反映させるためにノートまたはワークフローにおける承認のためのインジケータを含むことができます。

10. Security Considerations

10.セキュリティの考慮事項

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]は信頼レベルとエンティティ、エンティティとコンソーシアム、およびコンソーシアム間の合意を確立するための政策の比較に使用することができるインターネットX.509公開鍵基盤証明書ポリシーと認証実践フレームワークを定義します。協定は、証明書[RFC5280]、鍵配布技術[RFC2585]、および認証局と登録機関管理の実践にパス検証を実行するための能力を含む鍵管理慣行を考慮すべきです。

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のオプションを使用すると、エンティティまたはそれらの協定を作成するコンソーシアムによって決定されるべきです。

11. Internationalization Issues

11.国際化の問題

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 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].

Nodeクラスは、ホストまたはネットワークデバイスを識別する。この文書は、IODEF仕様[RFC5070]、セクション3.16からのノードの定義を再利用します。しかし、その文書が明確にnodenameは国際化ドメイン名（IDN）ことができるかどうかを指定していませんでした。 RIDのシステムは、ドメイン名スロット[RFC5890]としてのNodeNameクラスを扱わなければなりません。 RIDのシステムはのNodeNameクラスでのIDNをサポートする必要があります。彼らがそうする場合、ドメイン名のUTF-8表現、すなわち、ドメイン名のラベルのすべてがUTF-8またはNR-LDHラベル[RFC5890]で表さU-ラベルでなければなりません、使用しなければなりません。 -ラベルを使用してはいけません。アプリケーション[RFC5891]での国際化ドメイン名のためのプロトコル仕様に記載されているようにRIDを介して通信するアプリケーションは、ラベルの[RFC3492]ピュニコード符号化を使用して、ラベルおよびU-ラベルとの間で変換することができます。

12. IANA Considerations

12. IANAの考慮事項

This document uses URNs to describe XML namespaces and XML schemas [XMLschema] conforming to a registry mechanism described in [RFC3688].

この文書では、[XMLSCHEMA] [RFC3688]に記載されたレジストリ・メカニズムに準拠するXML名前空間とXMLスキーマを記述するためのURNを使用します。

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：スキーマ：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"

レジストリの名称：「XMLスキーマは、RIDを介して交換」

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スキーマの名前空間。列挙値はURNまたはURIによって表されているように、これはXMLSchemaID属性にRID ReportSchemaクラスで表されています。

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.

指定エキスパートは、（例えば、ワーキング・グループのメーリングリストへの電子メールを経て）、そのようなWGが存在する場合（インシデント軽量取引管理）MILEワーキンググループまたはその後継者に相談することが期待されます。指定専門家は、仕様の公開状況を確認し、URIの正しさを検証するために提供さURIからXMLスキーマの仕様を取得することが期待されます。指定専門家の重要な責務は、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.

指定エキスパートは、（例えば、ワーキング・グループのメーリングリストへの電子メールを経て）、そのようなWGが存在する場合（インシデント軽量取引管理）MILEワーキンググループまたはその後継者に相談することが期待されます。指定エキスパートは、要求を確認し、属性の列挙の妥当性を検証するために期待されています。仕様は、要求に関連付けられている場合、それは指定の専門家によって審査されなければなりません。

13. Summary

13.まとめ

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の間でタイムリーなコミュニケーションを提供します。

14. References

14.参考文献

14.1. Normative References

14.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ホフマン、 "インターネットX.509公開鍵基盤運用プロトコル：FTPやHTTP"、RFC 2585、1999年5月。

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "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]イーストレーク、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、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]ホレンベック、S.、ローズ、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]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名の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]イーストレイク、D.、 "追加のXMLセキュリティユニフォームリソース識別子（URI）"、RFC 4051、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、RFC 4279 "トランスポート層セキュリティ（TLS）のための事前共有鍵暗号の組み合わせ"、2005年12月。

[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.

[RFC5070] Danyliw、R.、マイヤー、J.、およびY. Demchenko、 "インシデントオブジェクト説明交換フォーマット"、RFC 5070、2007年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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。

[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.

[RFC5646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、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]ファレル、S.、Housley氏、R.、およびS.ターナー、 "認可のためのインターネット属性証明書プロフィール"、RFC 5755、2010年1月。

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.

[RFC5890] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。

[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.

[RFC5891] Klensin、J.、 "アプリケーション（IDNA）で国際化ドメイン名：プロトコル"、RFC 5891、2010年8月。

[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012.

[RFC6546]トラメル、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]ブレイ、T.、MALER、E.、パオリ、J.、Sperberg-マックィーン、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]ボイヤー、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]ベルグルンド、A.、ボーグ、S.、チェン、D.、フェルナンデス、M.、ケイ、M.、Robie、J.、およびJ.シメオン、 "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]ハーシュ、F.およびP.ダッタ、 "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.サイモン、 "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]トンプソン、H.、ブナ、D.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C勧告第2版、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]バーテル、M.、ボイヤー、J.、フォックス、B.、LaMaccia、B.、およびE.サイモン、 "XML-署名構文と処理"、W3C勧告第2版、2008年6月、<のhttp：// www.w3.org/TR/xmldsig-core/>。

14.2. Informative References

14.2. 参考文献

[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]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年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.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、 "インターネット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]バーナーズ - リー、T.、フィールディング、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]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。

[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010.

[RFC6045]モリアーティ、K.、 "リアルタイムインターネットワーク防衛（RID）"、RFC 6045、2010年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]ポーク、T.、陳、L.、ターナー、S.、およびP.ホフマン、 "SHA-0およびSHA-1メッセージダイジェストアルゴリズムのためのセキュリティの考慮事項"、RFC 6194、2011年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]ブレイ、T.、オランダ、D.、素人、A.、トービン、R.、およびH.トムソン、 "XML 1.0での名前空間（第3版）"、W3C勧告、2009年12月、<のhttp：// www.w3.org/TR/xml-names/>。

Appendix A. Acknowledgements

付録A.謝辞

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.

見直しと文書でコメントと同様に、改善簡素化、およびプロトコルを確保するための勧告を提供するための同僚やインターネットコミュニティに感謝：スティーブBellovin氏、デビッド・ブラック、ハロルド・ブース、ポールCichonski、ロバート・K.カニンガム、ローマDanyliw、ユーリDemchenko、サンドラG.ダイクス、スティーブン・ファレル、キャサリンGoodier、シンシアD. McLain、トーマス・ミラー、ジャン=フランソワ・Morfin、スティーブン・ノースカット、ダミールRajnovic、トニーRutkowski、ピーター・サン・アンドレ、ジェフリーシラー、ロバートスパークス、ウィリアムStreilein、リチャードStruse、トニー・タウバー、ブライアン・トラメル、ショーン・ターナー、IljitschバンBeijnum、とDavid Waltermire。

Author's Address

著者のアドレス

Kathleen M. Moriarty EMC Corporation 176 South Street Hopkinton, MA United States

キャスリーンM.モリアーティEMCコーポレーション176サウスストリートホプキントン、MA、米国

EMail: Kathleen.Moriarty@emc.com

メールアドレス：Kathleen.Moriarty@emc.com

RFC 6545 - Real-time Inter-network Defense (RID) 日本語訳

1. Introduction

1. はじめに

1.1. Changes from

1.1. からの変更点

1.2. Normative and Informative

1.2. 規範的で有益

1.3. Terminology

1.3. 用語

2. Characteristics of Incidents

インシデントの2.特徴

3. Communication between CSIRTs and Service Providers

CSIRTとサービスプロバイダの間3.コミュニケーション

3.1. Inter-Service-Provider RID Messaging

3.1. インターサービス・プロバイダRIDメッセージング

3.2. RID Communication Topology

3.2. RID通信トポロジ

4. Message Formats

4.メッセージフォーマット

4.1. RID Data Types

4.1. RIDデータ型

4.1.1. Boolean

4.1.1. ブーリアン

4.2. RID Message Types

4.2. RIDメッセージタイプ

5. IODEF-RID Schema

5. IODEF-RIDスキーマ

5.1. RIDPolicy Class

5.1. RIDPolicyクラス

5.1.1. ReportSchema

5.1.1. ReportSchema

5.2. RequestStatus

5.2. RequestStatus

5.3. IncidentSource

5.3. IncidentSource

5.4. RID Name Spaces

5.4. RID名前空間

5.5. Encoding

5.5. エンコーディング

5.6. Including IODEF or Other XML Documents

5.6. IODEFまたは他のXML文書を含みます

5.6.1. Including XML Documents in RID

5.6.1. RIDのXML文書を含みます

6. RID Messages

6. RIDメッセージ

6.1. Request

6.1. 要求

6.2. Acknowledgement

6.2. 了承

6.3. Result

6.3. 結果

6.4. Report

6.4. 報告書

6.5. Query

6.5. 質問

7. RID Communication Exchanges

7. RID通信交換

7.1. Upstream Trace Communication Flow

7.1. 上流のトレース通信フロー

2. Initiate trace

2.トレースを開始

9. Trace Initiated

9.トレース開始

13. o- - - - -Acknowledgement- - - - - >

１３。 おー ー ー ー ーあｃｋのｗぇｄげめんｔー ー ー ー ー ＞

7.1.1. RID TraceRequest Example

7.1.1. RID TraceRequest例

7.1.2. Acknowledgement Message Example

7.1.2. 謝辞メッセージの例

7.1.3. Result Message Example

7.1.3. メッセージの例を結果

7.2. Investigation Request Communication Flow

7.2. 調査依頼の通信フロー

7.2.1. Investigation Request Example

7.2.1. 調査要求例

7.2.2. Acknowledgement Message Example

7.2.2. 謝辞メッセージの例

7.3. Report Communication Flow

7.3. レポートの通信フロー

3. File report in database

１３。おーーーーーあｃｋのｗぇｄげめんｔーーーーー＞