[要約] RFC 6045は、リアルタイムのインターネットネットワーク防御（RID）に関する標準化されたプロトコルです。その目的は、異なるセキュリティシステム間でのリアルタイムの情報共有と協調を可能にし、インターネット上の攻撃に対する効果的な防御を実現することです。
Internet Engineering Task Force (IETF) K. Moriarty
Request for Comments: 6045 EMC
Category: Informational November 2010
ISSN: 2070-1721
Real-time Inter-network Defense (RID)
リアルタイムのネットワーク間防御（RID）
Abstract
概要
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
システムの妥協、ワーム、ウイルス、フィッシングインシデント、サービス拒否などのネットワークセキュリティインシデントは、通常、人間とシステムの両方のサービス、データ、リソースの損失をもたらします。ネットワークプロバイダーとコンピューターセキュリティインシデント対応チームは、攻撃が発生する前に、セキュリティインシデントとツールと手順を実施しているためのセキュリティインシデントの通信とトレースを支援する準備ができている必要があります。リアルタイムのネットワーク間防衛（RID）は、既存の検出、トレース、ソース識別、および完全なインシデント処理ソリューションの緩和メカニズムを統合しながら、インシデント処理データの共有を促進するプロアクティブなネットワーク間通信方法の概要を説明します。通信システムでこれらの機能を組み合わせることで、ネットワーク上のより高いセキュリティレベルを達成する方法が得られます。インシデントを処理するためのポリシーガイドラインが推奨され、セキュリティの推奨事項と考慮事項を使用してコンソーシアムによって合意できます。
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here.
RIDは国際的な研究コミュニティ内での使用を発見しましたが、他のセクターでは広く採用されていません。この出版物は、それを採用したコミュニティと、現在リアルタイムのネットワーク間防衛のためのソリューションを検討しているコミュニティに仕様を提供しています。この仕様は、ここで指定されているデータ要素と構造を活用することにより、さまざまなトランスポートまたはメッセージ形式が必要なソリューションの開発を加速する場合があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6045.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6045で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Normative and Informative ..................................6
1.2. Terminology ................................................6
1.3. Attack Types and RID Messaging .............................6
2. RID Integration with Network Provider Technologies ..............8
3. Characteristics of Attacks ......................................9
3.1. Integrating Trace Approaches ..............................11
3.2. Superset of Packet Information for Traces .................11
4. Communication between Network Providers ........................12
4.1. Inter-Network Provider RID Messaging ......................14
4.2. RID Network Topology ......................................16
4.3. Message Formats ...........................................17
4.3.1. RID Data Types .....................................17
4.3.1.1. Boolean ...................................17
4.3.2. RID Messages and Transport .........................18
4.3.3. IODEF-RID Schema ...................................19
4.3.3.1. RequestStatus Class .......................21
4.3.3.2. IncidentSource Class ......................23
4.3.3.3. RIDPolicy Class ...........................24
4.3.4. RID Namespace ......................................29
4.4. RID Messages ..............................................29
4.4.1. TraceRequest .......................................29
4.4.2. RequestAuthorization ...............................30
4.4.3. Result .............................................31
4.4.4. Investigation Request ..............................33
4.4.5. Report .............................................35
4.4.6. IncidentQuery ......................................36
4.5. RID Communication Exchanges ...............................37
4.5.1. Upstream Trace Communication Flow ..................39
4.5.1.1. RID TraceRequest Example ..................40
4.5.1.2. RequestAuthorization Message Example ......44
4.5.1.3. Result Message Example ....................44
4.5.2. Investigation Request Communication Flow ...........47
4.5.2.1. Investigation Request Example .............48
4.5.2.2. RequestAuthorization Message Example ......50
4.5.3. Report Communication ...............................51
4.5.3.1. Report Example ............................51
4.5.4. IncidentQuery Communication Flow ...................54
4.5.4.1. IncidentQuery Example .....................54
5. RID Schema Definition ..........................................55
6. Security Considerations ........................................60
6.1. Message Transport .........................................62
6.2. Message Delivery Protocol - Integrity and Authentication ..63
6.3. Transport Communication ...................................63
6.4. Authentication of RID Protocol ............................64
6.4.1. Multi-Hop TraceRequest Authentication ..............65
6.5. Consortiums and Public Key Infrastructures ................66
6.6. Privacy Concerns and System Use Guidelines ................67
7. IANA Considerations ............................................72
8. Summary ........................................................72
9. References .....................................................73
9.1. Normative References ......................................73
9.2. Informative References ....................................74
Acknowledgements ..................................................75
Sponsor Information ...............................................75
Incident handling involves the detection, reporting, identification, and mitigation of an attack, whether it be a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack. When an attack is detected, the response may include simply filing a report, notification to the source of the attack, a request for mitigation, or the request to locate the source. One of the more difficult cases is that in which the source of an attack is unknown, requiring the ability to trace the attack traffic iteratively upstream through the network for the possibility of any further actions to take place. In cases when accurate records of an active session between the victim system and the attacker or source system are available, the source is easy to identify. The problem of tracing incidents becomes more difficult when the source is obscured or spoofed, logs are deleted, and the number of sources is overwhelming. If the source of an attack is known or identified, it may be desirable to request actions be taken to stop or mitigate the effects of the attack.
インシデントハンドリングには、システムの妥協、社会的に設計されたフィッシング攻撃、またはサービス拒否（DOS）攻撃であろうと、攻撃の検出、報告、識別、および緩和が含まれます。攻撃が検出された場合、回答には、単にレポートの提出、攻撃のソースへの通知、緩和の要求、またはソースを見つけるための要求が含まれます。より困難なケースの1つは、攻撃の原因が不明であることであり、それ以上のアクションが発生する可能性のために、ネットワークを介して攻撃トラフィックを繰り返し上流に追跡する能力を必要とすることです。被害者システムと攻撃者またはソースシステムの間のアクティブなセッションの正確な記録が利用可能な場合、ソースは簡単に識別できます。ソースが不明瞭またはスプーフィングされ、ログが削除され、ソースの数が圧倒されると、事故を追跡する問題がより困難になります。攻撃の原因が既知または特定されている場合、攻撃の影響を停止または軽減するためにアクションを要求することが望ましい場合があります。
Current approaches to mitigating the effects of security incidents are aimed at identifying and filtering or rate-limiting packets from attackers who seek to hide the origin of their attack by source address spoofing from multiple locations. Measures can be taken at network provider (NP) edge routers providing ingress, egress, and broadcast filtering as a recommended best practice in [RFC2827].
セキュリティインシデントの効果を緩和するための現在のアプローチは、複数の場所からのスプーフィングによるソースアドレスによる攻撃の起源を隠そうとする攻撃者からのパケットを特定してフィルタリングまたはレート制限パケットを特定することを目的としています。[RFC2827]の推奨ベストプラクティスとして、侵入、出口、ブロードキャストフィルタリングを提供するネットワークプロバイダー（NP）エッジルーターで測定を行うことができます。
Network providers have devised solutions, in-house or commercial, to trace attacks across their backbone infrastructure to either identify the source on their network or on the next upstream network in the path to the source. Techniques such as collecting packets as traffic traverses the network have been implemented to provide the capability to trace attack traffic after an incident has occurred. Other methods use packet-marking techniques or flow-based traffic analysis to trace traffic across the network in real time. The single-network trace mechanisms use similar information across the individual networks to trace traffic. Problems may arise when an attempt is made to have a trace continued through the next upstream network since the trace mechanism and management may vary.
ネットワークプロバイダーは、社内または商用のソリューションを考案し、バックボーンインフラストラクチャ全体で攻撃を追跡して、ネットワークまたはソースへのパスの次のアップストリームネットワーク上のソースを特定しました。トラフィックをトラバースするパケットを収集するなどの手法は、インシデントが発生した後に攻撃トラフィックを追跡する機能を提供するためにネットワークを実装しています。他の方法では、パケットマークテクニックまたはフローベースのトラフィック分析を使用して、ネットワーク全体のトラフィックをリアルタイムで追跡します。単一ネットワークトレースメカニズムは、個々のネットワーク全体で同様の情報を使用してトラフィックを追跡します。トレースのメカニズムと管理が異なる可能性があるため、次のアップストリームネットワークを介してトレースを継続する試みが行われたときに問題が発生する可能性があります。
In the case in which the traffic traverses multiple networks, there is currently no established communication mechanism for continuing the trace. If the next upstream network has been identified, a phone call might be placed to contact the network administrators in an attempt to have them continue the trace. A communication mechanism is needed to facilitate the transfer of information to continue traces accurately and efficiently to upstream networks. The communication mechanism described in this paper, Real-time Inter-network Defense (RID), takes into consideration the information needed by various single-network trace implementations and the requirement for network providers to decide if a TraceRequest should be permitted to continue. The data in RID messages is represented in an Extensible Markup Language (XML) [XML1.0] document using the Incident Object Description Exchange Format (IODEF) and RID. By following this model, integration with other aspects of the network for incident handling is simplified. Finally, methods are incorporated into the communication system to indicate what actions need to be taken closest to the source in order to halt or mitigate the effects of the attack at hand. RID is intended to provide a method to communicate the relevant information between Computer Security Incident Response Teams (CSIRTs) while being compatible with a variety of existing and possible future detection tracing and response approaches.
トラフィックが複数のネットワークを通過する場合、現在、トレースを継続するための確立された通信メカニズムはありません。次のアップストリームネットワークが特定されている場合、電話がかかるように電話をかけて、トレースを継続させるためにネットワーク管理者に連絡する可能性があります。アップストリームネットワークに正確かつ効率的にトレースを継続するために情報の転送を容易にするためには、通信メカニズムが必要です。このペーパーで説明されている通信メカニズムであるリアルタイムのネットワーク間防衛（RID）は、さまざまな単一ネットワークトレースの実装に必要な情報と、ネットワークプロバイダーがTraceRequestを継続できるかどうかを決定するための要件を考慮しています。RIDメッセージのデータは、インシデントオブジェクト説明交換形式（IODEF）およびRIDを使用して、拡張可能なマークアップ言語（XML）[XML1.0]ドキュメントで表されます。このモデルに従うことにより、インシデント処理のためのネットワークの他の側面との統合が簡素化されます。最後に、通信システムにメソッドが組み込まれて、手元の攻撃の影響を停止または軽減するために、ソースに最も近いアクションを使用する必要があることを示します。RIDは、さまざまな既存および可能な将来の検出トレースおよび応答アプローチと互換性がある間、コンピューターセキュリティインシデント対応チーム（CSIRT）間で関連情報を伝える方法を提供することを目的としています。
At this point, RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here.
この時点で、RIDは国際的な研究コミュニティ内での使用を発見しましたが、他のセクターでは広く採用されていません。この出版物は、それを採用したコミュニティと、現在リアルタイムのネットワーク間防衛のためのソリューションを検討しているコミュニティに仕様を提供しています。この仕様は、ここで指定されているデータ要素と構造を活用することにより、さまざまなトランスポートまたはメッセージ形式が必要なソリューションの開発を加速する場合があります。
Security and privacy considerations are of high concern since potentially sensitive information may be passed through RID messages. RID messaging takes advantage of XML security and privacy policy information set in the RID schema. The RID schema acts as an XML envelope to support the communication of IODEF documents for exchanging or tracing information regarding security incidents. RID messages are encapsulated for transport, which is defined in a separate document [RFC6046]. The authentication, integrity, and authorization features each layer has to offer are used to achieve a necessary level of security.
セキュリティとプライバシーの考慮事項は、潜在的に機密情報がRIDメッセージを通過する可能性があるため、大きな関心事です。RID Messagingは、RIDスキーマに設定されたXMLセキュリティとプライバシーポリシー情報を利用しています。RIDスキーマは、セキュリティインシデントに関する情報を交換または追跡するためにIODEFドキュメントの通信をサポートするXMLエンベロープとして機能します。RIDメッセージは輸送用にカプセル化されており、これは別のドキュメント[RFC6046]で定義されています。必要なレベルのセキュリティを実現するために、各レイヤーが提供する認証、整合性、および認証機能を使用します。
The XML schema [XMLschema] and transport requirements contained in this document are normative; all other information provided is intended as informative. More specifically, the following sections of this document are intended as informative: Sections 1, 2, and 3; and the sub-sections of 4 including the introduction to 4, 4.1, and 4.2. The following sections of this document are normative: The sub-sections of 4 including 4.3, 4.4, and 4.5; Section 5; and Section 6.
このドキュメントに含まれるXMLスキーマ[XMLSchema]と輸送要件は規範的です。提供される他のすべての情報は、有益なものとして意図されています。より具体的には、このドキュメントの次のセクションは、有益なものとして意図されています。セクション1、2、および3。4、4.1、および4.2の紹介を含む4のサブセクション。このドキュメントの次のセクションは規範的です。4.3、4.4、および4.5を含む4のサブセクション。セクション5;およびセクション6。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
RID messaging is intended for use in coordinating incident handling to locate the source of an attack and stop or mitigate the effects of the attack. The attack types include system or network compromises, denial-of-service attacks, or other malicious network traffic. RID is essentially a messaging system coordinating attack detection, tracing mechanisms, and the incident handling responses to locate the source of traffic. If a source address is spoofed, a more detailed trace of a packet (RID TraceRequest) would be required to locate the true source. If the source address is valid, the incident handling may only involve the use of routing information to determine what network provider is closest to the source (RID Investigation request) and can assist with the remediation. The type of RID message used to locate a source is determined by the validity of the source address. RID message types are discussed in Section 4.3.
RIDメッセージングは、攻撃のソースを見つけて攻撃の影響を停止または軽減するために、インシデント処理の調整に使用することを目的としています。攻撃の種類には、システムまたはネットワークの妥協、サービス拒否攻撃、またはその他の悪意のあるネットワークトラフィックが含まれます。RIDは、基本的に、攻撃の検出、トレースメカニズム、およびトラフィックのソースを見つけるためのインシデント処理応答を調整するメッセージングシステムです。ソースアドレスがスプーフィングされている場合、真のソースを見つけるには、より詳細なパケット（RID TracereQuest）が必要になります。ソースアドレスが有効な場合、インシデント処理には、ルーティング情報の使用のみが含まれて、どのネットワークプロバイダーがソースに最も近いか（RID調査リクエスト）を決定し、修復を支援できます。ソースを見つけるために使用されるRIDメッセージのタイプは、ソースアドレスの有効性によって決定されます。RIDメッセージタイプについては、セクション4.3で説明します。
DoS [DoS] attacks are characterized by large amounts of traffic destined for particular Internet locations and can originate from a single or multiple sources. An attack from multiple sources is known as a distributed denial-of-service (DDoS) attack. Because DDoS attacks can originate from multiple sources, tracing such an attack can be extremely difficult or nearly impossible. Many TraceRequests may be required to accomplish the task and may require the use of dedicated network resources to communicate incident handling information to prevent a DoS attack against the RID system and network used for tracing and remediation. Provisions are suggested to reduce the load and prevent the same trace from occurring twice on a single-network backbone discussed in Section 4 on communication between NPs. The attacks can be launched from systems across the Internet unified in their efforts or by compromised systems enlisted as "zombies" that are controlled by servers, thereby providing anonymity to the controlling server of the attack. This scenario may require multiple RID traces, one to locate the zombies and an additional one to locate the controlling server. DDoS attacks do not necessarily spoof the source of an attack since there are a large number of source addresses, which make it difficult to trace anyway. DDoS attacks can also originate from a single system or a subset of systems that spoof the source address in packet headers in order to mask the identity of the attack source. In this case, an iterative trace through the upstream networks in the path of the attack traffic may be required.
DOS [DOS]攻撃は、特定のインターネットの場所に向けた大量のトラフィックによって特徴付けられ、単一または複数のソースから発生する可能性があります。複数のソースからの攻撃は、分散されたサービス拒否（DDOS）攻撃として知られています。DDOS攻撃は複数のソースから発生する可能性があるため、このような攻撃を追跡することは非常に困難な場合やほとんど不可能です。タスクを達成するために多くのトレーセンスが必要になる場合があり、トレースと修復に使用されるRIDシステムとネットワークに対するDOS攻撃を防ぐために、インシデント処理情報を伝えるための専用ネットワークリソースの使用が必要になる場合があります。NP間の通信に関するセクション4で議論されている単一ネットワークバックボーンで同じトレースが2回発生するのを防ぐために、負荷を減らし、同じトレースが発生するのを防ぐための規定が提案されています。攻撃は、インターネット全体のシステムから統一されたシステムから、またはサーバーによって制御される「ゾンビ」として登録された侵害されたシステムによって開始でき、それにより攻撃の制御サーバーに匿名性を提供します。このシナリオでは、複数のシナリオが必要になる場合があります。1つはゾンビを見つけるために、さらには制御サーバーを見つけるための追加のシナリオが必要になる場合があります。DDOS攻撃は、多数のソースアドレスがあるため、必ずしも攻撃のソースを押し上げるとは限りません。DDOS攻撃は、攻撃ソースのアイデンティティをマスクするために、パケットヘッダーのソースアドレスを押し付ける単一のシステムまたはシステムのサブセットに由来することもあります。この場合、攻撃トラフィックの経路で上流のネットワークを通る反復トレースが必要になる場合があります。
RID traces may also be used to locate a system used in an attack to compromise another system. Compromising a system can be accomplished through one of many attack vectors, using various techniques from a remote host or through local privilege escalation attempts. The attack may exploit a system or application level vulnerability that may be the result of a design flaw or a configuration issue. A compromised system, as described above, can be used to later attack other systems. A single RID Investigation request may be used in this case since it is probable that the source address is valid. Identifying the sources of system compromises may be difficult since an attacker may access the compromised system from various sources. The attacker may also take measures to hide their tracks by deleting log files or by accessing the system through a series of compromised hosts. Iterative RID traces may be required for each of the compromised systems used to obscure the source of the attack. If the source address is valid, an Investigation request may be used in lieu of a full RID TraceRequest.
また、RIDトレースを使用して、攻撃で使用されるシステムを見つけて別のシステムを侵害する場合があります。システムを妥協することは、リモートホストからのさまざまな手法またはローカル特権エスカレーションの試みを使用して、多くの攻撃ベクトルの1つを通じて達成できます。攻撃は、設計上の欠陥または構成の問題の結果である可能性のあるシステムまたはアプリケーションレベルの脆弱性を活用する場合があります。上記のように、侵害されたシステムは、後で他のシステムを攻撃するために使用できます。ソースアドレスが有効である可能性が高いため、この場合、単一のRID調査要求が使用される場合があります。攻撃者がさまざまなソースから侵害されたシステムにアクセスする可能性があるため、システムの侵害の原因を特定することは困難な場合があります。攻撃者は、ログファイルを削除するか、一連の侵害されたホストを介してシステムにアクセスすることにより、トラックを非表示にするための対策を講じることもできます。攻撃の原因を不明瞭にするために使用される侵害されたシステムのそれぞれに、反復的なRIDトレースが必要になる場合があります。ソースアドレスが有効な場合、完全なRID TraceRequestの代わりに調査リクエストを使用できます。
Once an attack has been reported, CSIRTs may want to query other CSIRTs if they have detected an attack or simply report that one has taken place. The Report message can be used to file a report without an action taken, and an IncidentQuery can be used to ask if an attack has been seen by another CSIRT.
攻撃が報告されると、CSIRTは攻撃を検出した場合、他のCSIRTSを照会するか、単に発生したことを報告したい場合があります。レポートメッセージは、アクションを実行せずにレポートを提出するために使用できます。また、インシデントクエリを使用して、攻撃が別のCSIRTに見られたかどうかを尋ねることができます。
System compromises may result from other security incident types such as worms, Trojans, or viruses. It is often the case that an incident goes unreported even if valid source address information is available because it is difficult to take any action to mitigate or stop the attack. Incident handling is a difficult task for an NP and even at some client locations due to network size and resource limitations.
システムの妥協は、ワーム、トロイの木馬、ウイルスなどの他のセキュリティインシデントタイプに起因する場合があります。多くの場合、攻撃を緩和または停止するためにアクションを実行することが困難であるため、有効なソースアドレス情報が利用可能であっても、インシデントが報告されていない場合があります。インシデントハンドリングは、NPにとって、およびネットワークのサイズとリソースの制限により、一部のクライアントの場所でも困難なタスクです。
For the purpose of this document, a network provider (NP) shall be defined as a backbone infrastructure manager of a network. The network provider's Computer Security Incident Response Team shall be referred to as the CSIRT. The backbone may be that of an organization providing network (Internet or private) access to commercial, personal, government, or educational institutions, or the backbone provider of the connected network. The connected network provider is an extension meant to include Intranet and Extranet providers as well as instances such as a business or educational institute's private network.
このドキュメントの目的のために、ネットワークプロバイダー（NP）は、ネットワークのバックボーンインフラストラクチャマネージャーとして定義されます。ネットワークプロバイダーのコンピューターセキュリティインシデント対応チームは、CSIRTと呼ばれます。バックボーンは、商業、個人、政府、または教育機関、または接続されたネットワークのバックボーンプロバイダーへのネットワーク（インターネットまたはプライベート）アクセスを提供する組織のバックボーンです。コネクテッドネットワークプロバイダーは、イントラネットとエクストラネットプロバイダー、およびビジネスや教育機関のプライベートネットワークなどのインスタンスを含むことを目的とした拡張機能です。
NPs typically manage and monitor their networks through a centralized network management system (NMS). The acronym "NMS" will be used to generically represent management systems on a network used for the management of network resources. An incident handling system (IHS) is used to communicate RID messages and may be integrated with an NMS as well as other components of the network. The components of the network that may be integrated through the RID messaging system include attack or event detection, network tracing, and network devices to stop the effects of an attack.
NPは通常、集中ネットワーク管理システム（NMS）を介してネットワークを管理および監視します。頭字語「NMS」は、ネットワークリソースの管理に使用されるネットワーク上の管理システムを一般的に表すために使用されます。インシデントハンドリングシステム（IHS）は、RIDメッセージの通信に使用され、NMSおよびネットワークの他のコンポーネントと統合される場合があります。RIDメッセージングシステムを介して統合される可能性のあるネットワークのコンポーネントには、攻撃またはイベント検出、ネットワークトレース、ネットワークデバイスが含まれ、攻撃の影響を停止します。
The detection of security incidents may rely on manual reporting, automated intrusion detection tools, and variations in traffic types or levels on a network. Intrusion detection systems (IDSs) may be integrated into the IHS to create IODEF documents or RID messages to facilitate security incident handling. Detection of a security incident is outside the scope of this paper; however, it should be possible to integrate detection methods with RID messaging.
セキュリティインシデントの検出は、手動報告、自動侵入検知ツール、およびネットワーク上のトラフィックタイプまたはレベルの変動に依存する場合があります。侵入検知システム（IDSS）をIHSに統合して、IODEFドキュメントを作成したり、セキュリティインシデント処理を容易にしたりするメッセージをRIDする場合があります。セキュリティインシデントの検出は、このペーパーの範囲外です。ただし、検出方法をRIDメッセージングと統合することが可能です。
RID messaging in an IHS is intended to be flexible in order to accommodate various traceback systems currently in use as well as those that may evolve with technology. RID is intended to communicate the necessary information needed by a trace mechanism to the next upstream NP in the path of a trace. Therefore, a RID message must carry the superset of data required for all tracing systems. If possible, the trace may need to inspect packets to determine a pattern, which could assist reverse path identification. This may be accomplished by inspecting packet header information such as the source and destination IP addresses, ports, and protocol flags to determine if there is a way to distinguish the packets being traced from other packets. A description of the incident along with any available automated trace data should trigger an alert to the NP's CSIRT for further investigation. The various technologies used to trace traffic across a network are described in Section 3.1.
IHSでのRIDメッセージングは、現在使用されているさまざまなトレースバックシステムと、テクノロジーで進化する可能性のあるさまざまなトレースバックシステムに対応するために柔軟にすることを目的としています。RIDは、トレースメカニズムによって必要な情報を、トレースの経路で次の上流NPに伝えることを目的としています。したがって、RIDメッセージは、すべてのトレースシステムに必要なデータのスーパーセットを運ぶ必要があります。可能であれば、パターンを決定するためにパケットを検査する必要がある場合があります。これにより、逆パスの識別を支援できます。これは、ソースおよび宛先IPアドレス、ポート、プロトコルフラグなどのパケットヘッダー情報を検査して、他のパケットから追跡されているパケットを区別する方法があるかどうかを判断することで実現できます。インシデントの説明と利用可能な自動トレースデータとともに、さらなる調査のためにNPのCSIRTへのアラートをトリガーするはずです。ネットワーク全体のトラフィックを追跡するために使用されるさまざまなテクノロジーについては、セクション3.1で説明しています。
Another area of integration is the ability to mitigate or stop attack traffic once a source has been located. Any automated solution should consider the possible side effects to the network. A change control process or a central point for configuration management might be used to ensure that the security of the network and necessary functionality are maintained and that equipment configuration changes are documented. Automated solutions may depend upon the capabilities and current configuration management solutions on a particular network. The solutions may be based on HTTP/TLS (Transport Layer Security) or an appropriate protocol defined in the transport specification.
統合のもう1つの領域は、ソースが配置されたら、トラフィックを緩和または停止する機能です。自動化されたソリューションは、ネットワークへの可能な副作用を考慮する必要があります。変更制御プロセスまたは構成管理の中心的なポイントを使用して、ネットワークのセキュリティと必要な機能が維持され、機器の構成の変更が文書化されるようにすることができます。自動化されたソリューションは、特定のネットワーク上の機能と現在の構成管理ソリューションに依存する場合があります。ソリューションは、HTTP/TLS（輸送層のセキュリティ）または輸送仕様で定義されている適切なプロトコルに基づいている場合があります。
The goal of tracing a security incident may be to identify the source or to find a point on the network as close to the origin of the incident as possible. A security incident may be defined as a system compromise, a worm or Trojan infection, or a single- or multiple-source denial-of-service attack. Incident tracing can be used to identify the source(s) of an attack in order to halt or mitigate the undesired behavior. The communication system, RID, described in this paper can be used to trace any type of security incident and allows for actions to be taken when the source of the attack or a point closer to the source is known or has been identified. The purpose of tracing an attack would be to halt or mitigate the effects of the attack through methods such as filtering or rate-limiting the traffic close to the source or by using methods such as taking the host or network offline. Care must also be taken to ensure that the system is not abused and to use proper analysis in determining if attack traffic is, in fact, attack traffic at each NP along the path of a trace.
セキュリティインシデントを追跡するという目標は、ソースを特定するか、ネットワーク上のポイントを可能な限りインシデントの起源に近づけることです。セキュリティインシデントは、システムの妥協、ワームまたはトロイの木馬感染、または単一または複数のソースの拒否攻撃として定義される場合があります。インシデントトレースを使用して、望ましくない動作を停止または軽減するために、攻撃のソースを識別できます。このペーパーで説明されている通信システムは、あらゆる種類のセキュリティインシデントを追跡するために使用でき、攻撃のソースまたはソースに近いポイントが既知または特定されている場合、アクションを実行できます。攻撃をトレースする目的は、ソースの近くのトラフィックのフィルタリングやレート制限などの方法、またはホストやネットワークをオフラインにするなどのメソッドを使用して、攻撃の影響を停止または軽減することです。また、システムが乱用されないことを確認し、実際に攻撃トラフィックがトレースの経路に沿って各NPでトラフィックを攻撃するかどうかを判断する際に適切な分析を使用するように注意する必要があります。
Tracing security incidents can be a difficult task since attackers go to great lengths to obscure their identity. In the case of a security incident, the true source might be identified through an existing established connection to the attacker's point of origin. However, the attacker may not connect to the compromised system for a long period of time after the initial compromise or may access the system through a series of compromised hosts spread across the network. Other methods of obscuring the source may include targeting the host with the same attack from multiple sources using both valid and spoofed source addresses. This tactic can be used to compromise a machine and leave the difficult task of locating the true origin for the administrators. Security incidents, including DDoS attacks, can be difficult or nearly impossible to trace because of the nature of the attack. Some of the difficulties in tracing attacks include the following: o the attack originates from multiple sources;
攻撃者は自分のアイデンティティを曖昧にするためにかなりの時間を費やすため、セキュリティインシデントを追跡することは困難な作業になる可能性があります。セキュリティインシデントの場合、真のソースは、攻撃者の原産地との既存の確立された接続を通じて特定される可能性があります。ただし、攻撃者は、最初の妥協後に侵害されたシステムに長期間接続したり、ネットワーク全体に広がる一連の妥協したホストを介してシステムにアクセスしたりすることができます。ソースを不明瞭にする他の方法には、有効なソースアドレスとスプーフィングされたソースアドレスの両方を使用して、複数のソースから同じ攻撃でホストをターゲットにすることが含まれます。この戦術は、マシンを妥協し、管理者の真の起源を見つけるという難しいタスクを残すために使用できます。DDOS攻撃を含むセキュリティインシデントは、攻撃の性質のために追跡するのが難しいか、ほとんど不可能です。トレース攻撃の難しさには、次のものが含まれます。o攻撃は複数のソースに由来します。
o the attack may include various types of traffic meant to consume server resources, such as a SYN flood attack without a significant increase in bandwidth utilization;
o 攻撃には、帯域幅の使用率が大幅に増加することなくSyn洪水攻撃など、サーバーリソースを消費するためのさまざまなタイプのトラフィックが含まれる場合があります。
o the type of traffic could include valid destination services, which cannot be blocked since they are essential services to business, such as DNS servers at an NP or HTTP requests sent to an organization connected to the Internet;
o トラフィックの種類には、NPでのDNSサーバーやインターネットに接続された組織に送信されたHTTPリクエストなど、ビジネスにとって不可欠なサービスであるためブロックすることはできない有効な宛先サービスが含まれます。
o the attack may utilize varying types of packets including TCP, UDP, ICMP, or other IP protocols;
o 攻撃は、TCP、UDP、ICMP、またはその他のIPプロトコルを含むさまざまな種類のパケットを利用する場合があります。
o the attack may be from "zombies", which then require additional searches to locate a controlling server as the true origin of the attack;
o 攻撃は「ゾンビ」からのものである可能性があり、その後、攻撃の真の起源として制御サーバーを見つけるために追加の検索が必要です。
o the attack may use a very small number of packets from any particular source, thus making a trace after the fact nearly impossible.
o 攻撃は、特定のソースから非常に少数のパケットを使用する可能性があるため、事実がほぼ不可能になった後に痕跡をかけることがあります。
If the source(s) of the attack cannot be determined from IP address information or tracing the increased bandwidth utilization, it may be possible to trace the traffic based on the type of packets seen by the client. In the case of packets with spoofed source addresses, it is no longer a trivial task to identify the source of an attack. In the case of an attack using valid source addresses, methods such as the traceroute utility can be used to fairly accurately identify the path of the traffic between the source and destination of an attack. If the true source has been identified, actions should be taken to halt or mitigate the effects of the attack by reporting the incident to the NP or the upstream NP closest to the source. In the case of a spoofed source address, other methods can be used to trace back to the source of an attack. The methods include packet filtering, packet hash comparisons, IP marking techniques, ICMP traceback, and packet flow analysis. As in the case of attack detection, tracing traffic across a single network is a function that can be used with RID in order to provide the network with the ability to trace spoofed traffic to the source, while RID provides all the necessary information to accommodate the approach used on any single network to accomplish this task. RID can also be used to report attack traffic close to the source where the IP address used was determined to be valid or simply to report that an incident occurred.
攻撃のソースがIPアドレス情報や帯域幅の使用率の増加を追跡できない場合、クライアントが見たパケットの種類に基づいてトラフィックをトレースすることができる場合があります。スプーフィングされたソースアドレスを備えたパケットの場合、攻撃のソースを識別することはもはや些細なタスクではありません。有効なソースアドレスを使用した攻撃の場合、Tracerouteユーティリティなどのメソッドを使用して、攻撃のソースと宛先の間のトラフィックのパスをかなり正確に識別できます。真のソースが特定されている場合、NPまたはソースに最も近い上流のNPにインシデントを報告することにより、攻撃の影響を停止または軽減するための行動を取るべきです。スプーフィングされたソースアドレスの場合、他の方法を使用して攻撃のソースに戻ることができます。この方法には、パケットフィルタリング、パケットハッシュ比較、IPマーキングテクニック、ICMPトレースバック、パケットフロー分析が含まれます。攻撃検出の場合のように、単一のネットワークを横切るトラフィックをトレースすることは、ネットワークにスプーフィングされたトラフィックをソースにトレースする機能を提供するためにRIDで使用できる関数です。このタスクを達成するために任意の単一のネットワークで使用されるアプローチ。また、RIDを使用して、使用されたIPアドレスが有効であると判断されたソースに近い攻撃トラフィックを報告するか、単にインシデントが発生したことを報告することもできます。
There have been many separate research initiatives to solve the problem of tracing upstream packets to detect the true source of attack traffic. Upstream packet tracing is currently confined to the borders of a network or an NP's network. Traces require access to network equipment and resources, thus potentially limiting a trace to a specific network. Once a trace reaches the boundaries of a network, the network manager or NP adjacent in the upstream trace must be contacted in order to continue the trace. NPs have been working on individual solutions to accomplish upstream tracing within their own network environments. The tracing mechanisms implemented thus far have included proprietary or custom solutions requiring specific information such as IP packet header data, hash values of the attack packets, or marked packets. Hash values are used to compare a packet against a database of packets that have passed through the network as described in "Hash-Based IP Traceback" [HASH-IPtrace]. Other research solutions involve marking packets as explained in "ICMP Traceback Messages" [ICMPtrace], "Practical network support for IP traceback" [NTWK-IPtrace], the IP Flow Information eXport (IPFIX) protocol [RFC3917], and IP marking [IPtrace]. The single-network traceback solutions were considered in developing RID to determine the information needed to accomplish an inter-network trace where different solutions may be in place.
攻撃トラフィックの真のソースを検出するために上流パケットを追跡する問題を解決するための多くの個別の研究イニシアチブがありました。アップストリームパケットトレースは現在、ネットワークまたはNPのネットワークの境界に限定されています。トレースには、ネットワーク機器とリソースへのアクセスが必要であるため、特定のネットワークにトレースを制限する可能性があります。トレースがネットワークの境界に達すると、トレースを継続するために、上流トレースのネットワークマネージャーまたはNPに接触する必要があります。NPは、独自のネットワーク環境内で上流トレースを達成するために個々のソリューションに取り組んできました。これまでに実装されたトレースメカニズムには、IPパケットヘッダーデータ、攻撃パケットのハッシュ値、またはマークされたパケットなどの特定の情報を必要とする独自のソリューションまたはカスタムソリューションが含まれています。ハッシュ値は、「ハッシュベースのIPトレースバック」[Hash-Prace]で説明されているように、ネットワークを通過したパケットのデータベースとパケットを比較するために使用されます。その他の研究ソリューションには、「ICMPトレースバックメッセージ」[ICMPTRACE]、「IP TraceBackの実用的なサポート」[NTWK-IPTRACE]、IPフロー情報エクスポート（IPFIX）プロトコル[RFC3917]、およびIPマーク[IPTrace [IPTrace）で説明されているように、パケットのマークが含まれます。]。単一ネットワークのトレースバックソリューションは、さまざまなソリューションが導入される可能性のあるネットワーク間トレースを達成するために必要な情報を決定するために、RIDの開発で考慮されました。
In order for network traffic to be traced across a network, an example packet from the attack must be sent along with the TraceRequest or Investigation request. According to the research for hash-based IP traceback, all of the non-changing fields of an IP header along with 8 bytes of payload are required to provide enough information to uniquely trace the path of a packet. The non-changing fields of the packet header and the 8 bytes of payload are the superset of data required by most single-network tracing systems used; limiting the shared data to the superset of the packet header and 8 bytes of payload prevents the need for sharing potentially sensitive information that may be contained in the data portion of a packet.
ネットワークトラフィックをネットワーク全体で追跡するには、攻撃からのパケットの例をTraceRequestまたは調査リクエストとともに送信する必要があります。ハッシュベースのIPトレースバックの研究によると、パケットのパスを一意にトレースするのに十分な情報を提供するには、8バイトのペイロードとともに、IPヘッダーの非変更フィールドと8バイトのペイロードが必要です。パケットヘッダーの非変更フィールドとペイロードの8バイトは、使用されるほとんどの単一ネットワークトレースシステムに必要なデータのスーパーセットです。共有データをパケットヘッダーのスーパーセットと8バイトのペイロードに制限することで、パケットのデータ部分に含まれる可能性のある機密情報を共有する必要性が妨げられます。
The RecordItem class in the IODEF is used to store a hexadecimal formatted packet including all packet header information plus 8 bytes of payload, or the entire packet contents. The above trace systems do not require a full packet, but it may be useful in some cases, so the option is given to allow a full packet to be included in the data model.
IODEFのRecordItemクラスは、すべてのパケットヘッダー情報と8バイトのペイロード、またはパケットコンテンツ全体を含む16進形式のパケットを保存するために使用されます。上記のトレースシステムには完全なパケットは必要ありませんが、場合によっては役立つ場合があるため、完全なパケットをデータモデルに含めることができるようにオプションが与えられます。
If a subset of a packet is used, the research presented in "Hash-Based IP Traceback" [HASH-IPtrace] provides guidelines to establish a minimum requirement for distinguishing packets. The full packet and content SHOULD be provided, but the minimum requirement MUST be provided. The research from [HASH-IPtrace] found that the first 28 invariant bytes of a packet (masked IP header plus the first 8 bytes of the payload) are sufficient to differentiate almost all non-identical IPv4 packets. RID requires the first 28 invariant bytes of an IPv4 packet in order to perform a trace. RID requires the first 48 invariant bytes for an IPv6 packet in order to distinguish the packet in a trace. Reference [HASH-IPtrace] for additional details.
パケットのサブセットが使用されている場合、「ハッシュベースのIPトレースバック」[Hash-Prace]に示されている調査は、パケットを区別するための最小要件を確立するためのガイドラインを提供します。完全なパケットとコンテンツを提供する必要がありますが、最小要件を提供する必要があります。[Hash-Iprace]の調査では、パケットの最初の28の不変バイト（マスクされたIPヘッダーとペイロードの最初の8バイト）が、ほぼすべての非同一のIPv4パケットを区別するのに十分であることがわかりました。RIDは、トレースを実行するために、IPv4パケットの最初の28の不変バイトを必要とします。RIDは、トレースでパケットを区別するために、IPv6パケットの最初の48の不変バイトを必要とします。詳細については、[Hash-Prace]を参照してください。
The input mechanism for packets to be traced should be flexible to allow intrusion detection systems or packet sniffers to provide the information. The system creating the RID message should also use the packet information to populate the Incident class information in order to avoid human error and also allow a system administrator to override the automatically populated information.
トレースするパケットの入力メカニズムは、侵入検知システムまたはパケットスニファーが情報を提供できるように柔軟にする必要があります。また、RIDメッセージを作成するシステムは、人為的エラーを回避し、システム管理者が自動的に人口の多い情報をオーバーライドできるように、インシデントクラス情報を入力するためにパケット情報を使用する必要があります。
Note: The Introduction, and Sub-sections 4.1 and 4.2, are informative, with the exception of references to IODEF/RID Transport [RFC6046]. Sub-sections 4.3, 4.4, and 4.5 are normative.
注：IODEF/RIDトランスポート[RFC6046]への参照を除き、導入およびサブセクション4.1および4.2は有益です。サブセクション4.3、4.4、および4.5は規範的です。
Expediting the communication between CSIRTs is essential when responding to a security-related incident, which may cross network access points (Internet backbones) between providers. As a result of the urgency involved in this inter-NP security incident communication, there must be an effective system in place to facilitate the interaction. This communication policy or system should involve multiple means of communication to avoid a single point of failure. Email is one way to transfer information about the incident, packet traces, etc. However, email may not be received in a timely fashion or be acted upon with the same urgency as a phone call or other communication mechanism.
CSIRT間の通信を促進することは、プロバイダー間でネットワークアクセスポイント（インターネットバックボーン）を越える可能性があるセキュリティ関連のインシデントに対応する場合に不可欠です。このNP間のセキュリティインシデントコミュニケーションに関与する緊急性の結果として、相互作用を促進するための効果的なシステムが存在する必要があります。このコミュニケーションポリシーまたはシステムには、単一の障害点を回避するために、複数のコミュニケーション手段を伴う必要があります。電子メールは、インシデント、パケットトレースなどに関する情報を転送する1つの方法です。ただし、電子メールはタイムリーに受信したり、電話やその他の通信メカニズムと同じ緊急で行動することはできません。
Each NP should dedicate a phone number to reach a member of their respective CSIRT. The phone number could be dedicated to inter-NP incident communications and must be a hotline that provides a 24x7 live response. The phone line should reach someone who would have the authority, expertise, and the means to expedite the necessary action to investigate the incident. This may be a difficult policy to establish at smaller NPs due to resource limitations, so another solution may be necessary. An outside group may be able to serve this function if given the necessary access to the NP's network. The outside resource should be able to mitigate or alleviate the financial limitations and any lack of experienced resource personnel.
各NPは、それぞれのcsirtのメンバーに連絡するために電話番号を捧げる必要があります。電話番号は、NP Intering Inciding Communicationsに専念する可能性があり、24時間365日のライブ応答を提供するホットラインでなければなりません。電話回線は、権限、専門知識、および事件を調査するために必要な訴訟を促進する手段を持つ人に到達する必要があります。これは、リソースの制限により、より小さなNPで確立するのが難しいポリシーである可能性があるため、別のソリューションが必要になる場合があります。NPのネットワークへの必要なアクセスが与えられた場合、外部グループはこの機能を提供できる場合があります。外部のリソースは、財政的な制限と経験豊富なリソース担当者の不足を軽減または軽減できるはずです。
A technical solution to trace traffic across a single NP may include homegrown or commercial systems for which RID messaging must accommodate the input requirements. The IHS used on the NP's backbone by the CSIRT to coordinate the trace across the single network requires a method to accept and process RID messages and relay TraceRequests to the system, as well as to wait for responses from the system to continue the RID request process as appropriate. In this scenario, each NP would maintain its own RID/IHS and integrate with a management station used for network monitoring and analysis. An alternative for NPs lacking sufficient resources may be to have a neutral third party with access to the NP's network resources who could be used to perform the incident handling functions. This could be a function of a central organization operating as a CSIRT for the Internet as a whole or within a consortium that may be able to provide centralized resources. Consortiums would consist of a group of NPs and/or CSIRTs that agree to participate in the RID communication protocol with an agreed-upon policy and communication protocol facilitating the secure transport of IODEF/RID XML documents. Transport for RID messages is specified in the IODEF/RID Transport [RFC6046] document.
単一のNPでトラフィックを追跡するための技術的なソリューションには、RIDメッセージングが入力要件に対応する必要がある自家製または商用システムが含まれる場合があります。CSIRTによってNPのバックボーンで使用されているIHSは、単一のネットワーク全体のトレースを調整するために使用されるIHSには、メッセージを受け入れて処理する方法が必要です。適切に。このシナリオでは、各NPは独自のRID/IHSを維持し、ネットワークの監視と分析に使用される管理ステーションと統合します。十分なリソースを欠くNPの代替案は、インシデント処理機能を実行するために使用できるNPのネットワークリソースにアクセスできる中立の第三者を持つことです。これは、集中リソースを提供できる可能性のあるコンソーシアム全体またはコンソーシアム内のCSIRTとして動作する中央組織の機能である可能性があります。コンソーシアムは、IODEF/RID XMLドキュメントの安全な輸送を促進する合意されたポリシーとコミュニケーションプロトコルを使用して、RID通信プロトコルに参加することに同意するNPおよび/またはCSIRTのグループで構成されます。RIDメッセージのトランスポートは、IODEF/RID Transport [RFC6046]ドキュメントで指定されています。
One goal of RID is to prevent the need to permit access to other networks' equipment through the use of a standard messaging mechanism to enable IHSs to communicate incident handling information to other networks in a consortium or in neighboring networks. The third party mentioned above may be used in this technical solution to assist in facilitating incident handling and possibly traceback through smaller NPs. The RID messaging mechanism may be a logical or physical out-of-band network to ensure that the communication is secure and unaffected by the state of the network under attack. The two management methods would accommodate the needs of larger NPs to maintain full management of their network, and the third-party option could be available to smaller NPs who lack the necessary human resources to perform incident handling operations. The first method enables the individual NPs to involve their network operations staff to authorize the continuance of a trace or other necessary response to a RID communication request through their network via a notification and alerting system. The out-of-band logical solution for messaging may be permanent virtual circuits configured with a small amount of bandwidth dedicated to RID communications between NPs.
RIDの目標の1つは、IHSSがコンソーシアムまたは近隣のネットワークの他のネットワークにインシデント処理情報を通信できるようにするために、標準メッセージングメカニズムを使用して他のネットワークの機器へのアクセスを許可する必要性を防ぐことです。上記の第三者は、この技術的なソリューションで使用され、インシデント処理の促進と、より小さなNPを介したトレースバックを支援することができます。RIDメッセージングメカニズムは、通信が攻撃中のネットワークの状態によって安全で影響を受けないようにするための論理的または物理的な帯域外ネットワークである可能性があります。2つの管理方法は、ネットワークの完全な管理を維持するためのより大きなNPのニーズに対応し、インシデント処理操作を実行するために必要な人材を欠いている小規模なNPが利用できる可能性があります。最初の方法により、個々のNPSがネットワーク運用スタッフに関与し、通知とアラートシステムを介してネットワークを介したRID通信要求に対するトレースまたはその他の必要な応答の継続を承認することができます。メッセージング用のバンド外の論理ソリューションは、NP間の通信をRIDする専用の少量の帯域幅で構成された永続的な仮想回路である場合があります。
The network used for the communication should consist of out-of-band or protected channels (direct communication links) or encrypted channels dedicated to the transport of RID messages. The communication links would be direct connections between network peers who have agreed-upon use and abuse policies through the use of a consortium. Consortiums might be linked through policy comparisons and additional agreements to form a larger web or iterative network of peers that correlates to the traffic paths available over the larger web of networks. The maintenance of the individual links is the responsibility of the two network peers hosting the link. Contact information, IP addresses of RID systems, and other information must be coordinated between bilateral peers by a consortium and may use existing databases, such as the Routing Arbiter. The security, configuration, and Confidence rating schemes of the RID messaging peers must be negotiated by peers and must meet certain overall requirements of the fully connected network (Internet, government, education, etc.) through the peering and/or a consortium-based agreement.
通信に使用されるネットワークは、帯域外または保護されたチャネル（直接通信リンク）またはRIDメッセージの輸送専用の暗号化されたチャネルで構成する必要があります。通信リンクは、コンソーシアムの使用を通じて使用されているネットワークピアと乱用ポリシーの間の直接的な接続です。コンソーシアムは、ポリシーの比較と追加の契約を通じてリンクされ、より大きなネットワークのWebで利用可能なトラフィックパスに相関する、より大きなWebまたは反復的なピアネットワークを形成する可能性があります。個々のリンクのメンテナンスは、リンクをホストする2つのネットワークピアの責任です。連絡先情報、RIDシステムのIPアドレス、およびその他の情報は、コンソーシアムによって二国間ピア間で調整する必要があり、ルーティングアービターなどの既存のデータベースを使用する場合があります。RIDメッセージングピアのセキュリティ、構成、および信頼評価スキームは、ピアによって交渉する必要があり、ピアリングおよび/またはコンソーシアムベースのコンソーシアムベースを通じて、完全に接続されたネットワーク（インターネット、政府、教育など）の特定の全体的な要件を満たす必要があります。合意。
RID messaging established with clients of an NP may be negotiated in a contract as part of a value-added service or through a service level agreement (SLA). Further discussion is beyond the scope of this document and may be more appropriately handled in network peering or service level agreements.
NPのクライアントと確立されたRIDメッセージングは、付加価値サービスの一部として、またはサービスレベル契約（SLA）を通じて契約で交渉される場合があります。さらなる議論は、このドキュメントの範囲を超えており、ネットワークピアリングまたはサービスレベルの契約でより適切に処理される可能性があります。
Procedures for incident handling need to be established and well known by anyone that may be involved in incident response. The procedures should also contain contact information for internal escalation procedures, as well as for external assistance groups such as a CSIRT, CERT Coordination Center (CERT/CC), Global Information Assurance Certification (GIAC), and the FBI or other assisting government organization in the country of the investigation.
インシデント処理の手順は、インシデント対応に関与している可能性のある人が確立し、よく知られている必要があります。この手順には、内部エスカレーション手順、およびCSIRT、CERT COODRININAGN CENTER（CERT/CC）、Global Information Assurance Certification（GIAC）、FBIまたはその他の政府組織などの外部支援グループの連絡先情報も含める必要があります。調査の国。
In order to implement a messaging mechanism between RID communication systems or IHSs, a standard protocol and format is required to ensure inter-operability between vendors. The messages would have to meet several requirements in order to be meaningful as they traverse multiple networks. RID provides the framework necessary for communication between networks involved in the incident handling, possible traceback, and mitigation of a security incident. Several message types described in Section 4.3 are necessary to facilitate the handling of a security incident. The message types include the Report, IncidentQuery, TraceRequest, RequestAuthorization, Result, and the Investigation request message. The Report message is used when an incident is to be filed on a RID system or associated database, where no further action is required. An IncidentQuery message is used to request information on a particular incident. A TraceRequest message is used when the source of the traffic may have been spoofed. In that case, each network provider in the upstream path who receives a TraceRequest will issue a trace across the network to determine the upstream source of the traffic. The RequestAuthorization and Result messages are used to communicate the status and result of a TraceRequest or Investigation request. The Investigation request message would only involve the RID communication systems along the path to the source of the traffic and not the use of network trace systems. The Investigation request leverages the bilateral relationships or a consortium's interconnections to mitigate or stop problematic traffic close to the source. Routes could determine the fastest path to a known source IP address in the case of an Investigation request. A message sent between RID systems for a TraceRequest or an Investigation request to stop traffic at the source through a bordering network would require the information enumerated below:
RID通信システムまたはIHSSの間にメッセージングメカニズムを実装するには、ベンダー間の相互運用性を確保するために標準的なプロトコルと形式が必要です。メッセージは、複数のネットワークを通過するため、意味のある要件を満たす必要があります。RIDは、インシデントハンドリング、可能性のあるトレースバック、およびセキュリティインシデントの緩和に関与するネットワーク間の通信に必要なフレームワークを提供します。セクション4.3で説明するいくつかのメッセージタイプは、セキュリティインシデントの処理を促進するために必要です。メッセージの種類には、レポート、IncissQuery、Tracerequest、RequestAuthorization、結果、および調査要求メッセージが含まれます。レポートメッセージは、インシデントがRIDシステムまたは関連データベースに提出される場合に使用されますが、それ以上のアクションは必要ありません。インシデントクエリメッセージは、特定のインシデントに関する情報を要求するために使用されます。トラフィックのソースがスプーフィングされている可能性がある場合、TraceRequestメッセージが使用されます。その場合、TraceRequestを受信する上流のパスにある各ネットワークプロバイダーは、ネットワーク全体にトレースを発行して、トラフィックの上流のソースを決定します。RequestAuthorizationおよび結果メッセージは、Tracerequestまたは調査リクエストのステータスと結果を伝えるために使用されます。調査要求メッセージには、ネットワークトレースシステムの使用ではなく、トラフィックのソースへのパスに沿ったRID通信システムのみが含まれます。調査要求は、ソースの近くで問題のあるトラフィックを緩和または停止するために、二国間関係またはコンソーシアムの相互接続を活用します。ルートは、調査リクエストの場合に既知のソースIPアドレスへの最速のパスを決定できます。TraceRequestのRIDシステム間で送信されたメッセージまたは境界ネットワークを介してソースでトラフィックを停止するための調査リクエストには、以下に列挙されている情報が必要です。
1. Enough information to enable the network administrators to make a decision about the importance of continuing the trace.
1. ネットワーク管理者がトレースを継続することの重要性について決定できるようにするのに十分な情報。
2. The incident or IP packet information needed to carry out the trace or investigation.
2. トレースまたは調査を実行するために必要なインシデントまたはIPパケット情報。
3. Contact information of the origin of the RID communication. The contact information could be provided through the Autonomous System Number (ASN) [RFC1930] or Network Information Center (NIC) handle information listed in the Registry for Internet Numbers or other Internet databases.
3. RID通信の起源の連絡先情報。連絡先情報は、自律システム番号（ASN）[RFC1930]またはネットワーク情報センター（NIC）を介して提供できます。
4. Network path information to help prevent any routing loops through the network from perpetuating a trace. If a RID system receives a TraceRequest containing its own information in the path, the trace must cease and the RID system should generate an alert to inform the network operations staff that a tracing loop exists.
4. ネットワークパス情報は、ネットワークを介したルーティングループがトレースを永続させるのを防ぐのに役立ちます。RIDシステムがパスに独自の情報を含むTraceRequestを受信した場合、トレースは停止する必要があり、RIDシステムは、トレースループが存在することをネットワーク運用スタッフに通知するためのアラートを生成する必要があります。
5. A unique identifier for a single attack. This identifier should be used to correlate traces to multiple sources in a DDoS attack.
5. 単一の攻撃のための一意の識別子。この識別子は、DDOS攻撃の複数のソースとトレースを相関させるために使用する必要があります。
Use of the communication network and the RID protocol must be for pre-approved, authorized purposes only. It is the responsibility of each participating party to adhere to guidelines set forth in both a global use policy for this system and one established through the peering agreements for each bilateral peer or agreed-upon consortium guidelines. The purpose of such policies is to avoid abuse of the system; the policies shall be developed by a consortium of participating entities. The global policy may be dependent on the domain it operates under; for example, a government network or a commercial network such as the Internet would adhere to different guidelines to address the individual concerns. Privacy issues must be considered in public networks such as the Internet. Privacy issues are discussed in the Security Considerations section, along with other requirements that must be agreed upon by participating entities.
通信ネットワークとRIDプロトコルの使用は、事前に承認された許可された目的のみでなければなりません。このシステムのグローバルな使用ポリシーと、各二国間ピアまたは合意されたコンソーシアムガイドラインのピアリング契約を通じて確立されたものの両方に定められたガイドラインを遵守することは、各参加当事者の責任です。このようなポリシーの目的は、システムの乱用を避けることです。ポリシーは、参加エンティティのコンソーシアムによって開発されるものとします。グローバルポリシーは、動作するドメインに依存する可能性があります。たとえば、政府ネットワークやインターネットなどの商業ネットワークは、個々の懸念に対処するためにさまざまなガイドラインを遵守します。プライバシーの問題は、インターネットなどのパブリックネットワークで考慮する必要があります。プライバシーの問題については、セキュリティ上の考慮事項セクションと、参加エンティティが合意しなければならない他の要件について説明します。
RID requests must be legitimate security-related incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system would include a request to rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business.
RIDリクエストは、妨害や検閲などの目的に使用されていない正当なセキュリティ関連のインシデントでなければなりません。このようなシステムの不正行為の例には、インターネット上のユーザー間で情報が共有されるのを防ぐための正当なトラフィックをレートリミットするリクエスト（オンラインバージョンの論文へのアクセスを制限する）または競合他社の製品からのアクセスを制限するために、仕事。
The RID system should be configurable to either require user input or automatically continue traces. This feature would enable a network manager to assess the available resources before continuing a trace. A trace initiated from a TraceRequest may cause adverse effects on a network. If the Confidence rating is low, it may not be in the NP's best interest to continue the trace. The Confidence ratings must adhere to the specifications for selecting the percentage used to avoid abuse of the system. TraceRequests must be issued by authorized individuals from the initiating network, set forth in policy guidelines established through peering or SLA.
RIDシステムは、ユーザー入力を必要とするか、トレースを自動的に継続するように構成可能である必要があります。この機能により、ネットワークマネージャーは、トレースを継続する前に利用可能なリソースを評価できます。TraceRequestから開始されたトレースは、ネットワークに悪影響を与える可能性があります。信頼評価が低い場合、トレースを継続することはNPの最大の利益にならない可能性があります。信頼評価は、システムの乱用を避けるために使用される割合を選択するための仕様に準拠する必要があります。TraceRequestsは、PearingまたはSLAを通じて確立されたポリシーガイドラインに記載されている、開始ネットワークの認可された個人によって発行されなければなりません。
The most basic topology for communicating RID systems would be a direct connection or a bilateral relationship as illustrated below.
RIDシステムを通信するための最も基本的なトポロジーは、以下に示すように、直接的な接続または二国間関係です。
___________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | NP Border | |________|
-------------
Figure 1. Direct Peer Topology
図1.直接ピアトポロジ
Within the consortium model, several topologies might be agreed upon and used. One would leverage bilateral network peering relationships of the members of the consortium. The peers for RID would match that of routing peers, and the logical network borders would be used. This approach may be necessary for an iterative trace where the source is unknown. The model would look like the above diagram; however, there may be an extensive number of interconnections of bilateral relationships formed. Also within a consortium model, it may be useful to establish an integrated mesh of networks to pass RID messages. This may be beneficial when the source address is known, and an interconnection may provide a faster route to reach the closest upstream peer to the source of the attack traffic. An example is illustrated below.
コンソーシアムモデル内では、いくつかのトポロジーが合意され、使用される場合があります。コンソーシアムのメンバーの二国間ネットワークのピアリング関係を活用します。RIDのピアはルーティングピアのそれと一致し、論理ネットワークの境界線が使用されます。このアプローチは、ソースが不明な繰り返しトレースに必要になる場合があります。モデルは上記の図のように見えます。ただし、形成された二国間関係の相互接続が豊富にある場合があります。また、コンソーシアムモデル内では、RIDメッセージを渡すためにネットワークの統合メッシュを確立することが有用かもしれません。これは、ソースアドレスが既知である場合に有益である可能性があり、相互接続が攻撃トラフィックのソースに最も近い上流のピアに到達するためのより速いルートを提供する場合があります。例を以下に示します。
_______ _______ _______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | NP Border | |_____| | NP Border | |_____|
| ------------- ------------- |
|_______________________________________________________|
Direct connection to network that is not an immediate network peer
即時のネットワークピアではないネットワークへの直接接続
Figure 2. Mesh Peer Topology
図2.メッシュピアトポロジ
By using a fully meshed model in a consortium, broadcasting RID requests would be possible, but not advisable. By broadcasting a request, RID peers that may not have carried the attack traffic on their network would be asked to perform a trace for the potential of decreasing the time in which the true source was identified. As a result, many networks would have utilized unnecessary resources for a TraceRequest that may have also been unnecessary.
コンソーシアムで完全にメッシュ化されたモデルを使用することにより、放送のRIDリクエストは可能ですが、お勧めできません。リクエストを放送することにより、ネットワーク上の攻撃トラフィックを携帯していない可能性のあるRIDピアは、真のソースが特定された時間を減らす可能性についてトレースを実行するように求められます。その結果、多くのネットワークは、不要なトレーセンスのために不必要なリソースを利用していたでしょう。
Section 4.3.2 describes the six RID message types, which are based on the IODEF model [RFC5070]. The messages are generated and received on RID communication systems on the NP's network. The messages may originate from IODEF messages from intrusion detection servers, CSIRTs, analysts, etc. A RID message uses the IODEF framework with the RID extension, which is encapsulated for transport [RFC6046]. Each RID message type, along with an example, is described in the following sections. The IODEF-RID schema is introduced in Section 4.3.3 to support the RID message types in Section 4.3.2.
セクション4.3.2では、IODEFモデル[RFC5070]に基づいた6つのRIDメッセージタイプについて説明します。メッセージは生成され、NPのネットワーク上のRID通信システムで受信されます。メッセージは、侵入検知サーバー、CSIRTS、アナリストなどからのIODEFメッセージに由来する場合があります。RIDメッセージは、輸送用にカプセル化されたRID拡張機能を備えたIODEFフレームワークを使用します[RFC6046]。各RIDメッセージタイプと例とともに、次のセクションで説明します。IODEF-RIDスキーマは、セクション4.3.3のセクション4.3.3に導入されており、セクション4.3.2のRIDメッセージタイプをサポートしています。
RID is derived from the IODEF data model and inherits all of the data types defined in the IODEF model. One data type is added by RID: BOOLEAN.
RIDはIODEFデータモデルから派生し、IODEFモデルで定義されているすべてのデータ型を継承します。1つのデータ型がRID：Booleanによって追加されます。
A boolean value is represented by the BOOLEAN data type.
ブール値は、ブールデータ型で表されます。
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema.
ブールデータ型は、スキーマで「xs：boolean」[xmlschema]として実装されています。
The six RID message types follow:
6つのRIDメッセージタイプが次のとおりです。
1. TraceRequest. This message is sent to the RID system next in the upstream trace. It is used to initiate a TraceRequest or to continue a TraceRequest to an upstream network closer to the source address of the origin of the security incident. The TraceRequest would trigger a traceback on the network to locate the source of the attack traffic.
1. TraceRequest。このメッセージは、上流トレースの次のRIDシステムに送信されます。これは、TraceRequestを開始したり、セキュリティインシデントの起源のソースアドレスに近いアップストリームネットワークへのTraceRequestを継続するために使用されます。TraceRequestは、ネットワーク上のトレースバックをトリガーして、攻撃トラフィックのソースを見つけます。
2. RequestAuthorization. This message is sent to the initiating RID system from each of the upstream NPs' RID systems to provide information on the request status in the current network.
2. RequestAuthorization。このメッセージは、現在のネットワークの要求ステータスに関する情報を提供するために、上流のNPS RIDシステムのそれぞれから開始RIDシステムに送信されます。
3. Result. This message is sent to the initiating RID system through the network of RID systems in the path of the trace as notification that the source of the attack was located. The Result message is also used to provide the notification of actions taken for an Investigation request.
3. 結果。このメッセージは、攻撃のソースが配置されたという通知として、トレースのパスにあるRIDシステムのネットワークを介して開始システムに送信されます。結果メッセージは、調査リクエストのために取られたアクションの通知を提供するためにも使用されます。
4. Investigation. This message type is used when the source of the traffic is believed not to be spoofed. The purpose of the Investigation request message is to leverage the existing peer relationships in order to notify the network provider closest to the source of the valid traffic of a security-related incident for any necessary actions to be taken.
4. 調査。このメッセージタイプは、トラフィックのソースがスプーフィングされていないと考えられている場合に使用されます。調査要求メッセージの目的は、必要なアクションを実行するためにセキュリティ関連のインシデントの有効なトラフィックのソースに最も近いネットワークプロバイダーに通知するために、既存のピア関係を活用することです。
5. Report. This message is used to report a security incident, for which no action is requested. This may be used for the purpose of correlating attack information by CSIRTs, statistics and trending information, etc.
5. 報告書。このメッセージは、セキュリティインシデントを報告するために使用されますが、アクションは要求されません。これは、攻撃情報をCSIRT、統計、トレンド情報などによって相関させる目的で使用できます。
6. IncidentQuery. This message is used to request information about an incident or incident type from a trusted RID system. The response is provided through the Report message.
6. インシデントクエリ。このメッセージは、信頼できるRIDシステムからインシデントタイプまたはインシデントタイプに関する情報を要求するために使用されます。応答は、レポートメッセージを通じて提供されます。
When a system receives a RID message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the RIDPolicy class. The RIDPolicy class may also be used by the transport protocol to facilitate the communication of security incident data to trace, investigate, query, or report information regarding security incidents.
システムがRIDメッセージを受信した場合、メッセージのタイプを決定し、それに応じて解析できる必要があります。メッセージタイプは、Ridpolicyクラスで指定されています。Ridpolicyクラスは、輸送プロトコルで使用され、セキュリティインシデントデータの通信を促進し、セキュリティインシデントに関する情報を追跡、調査、質問、または報告することもできます。
There are three classes included in the RID extension required to facilitate RID communications. The RequestStatus class is used to indicate the approval status of a TraceRequest or Investigation request; the IncidentSource class is used to report whether or not a source was found and to identify the source host(s) or network(s); and the RIDPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used.
RID通信を促進するために必要なRID拡張機能には、3つのクラスが含まれています。RequestStatusクラスは、TraceRequestまたは調査リクエストの承認ステータスを示すために使用されます。IncidentSourceクラスは、ソースが見つかったかどうかを報告し、ソースホストまたはネットワークを識別するために使用されます。また、Ridpolicyクラスは、合意されたポリシーに関する情報を提供し、使用されている通信メッセージのタイプを指定します。
The RID schema acts as an envelope for the IODEF schema to facilitate RID communications. The intent in maintaining a separate schema and not using the AdditionalData extension of IODEF is the flexibility of sending messages between RID hosts. Since RID is a separate schema that includes the IODEF schema, the RID information acts as an envelope, and then the RIDPolicy class can be easily extracted for use by the transport protocol. The security requirements of sending incident information across the network include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating out this data from the IODEF extension removes the need for decrypting and parsing the entire IODEF and RID document to determine how it should be handled at each RID host.
RIDスキーマは、IODEFスキーマの封筒として機能し、RID通信を促進します。IODEFの追加のDATA拡張機能を使用しないことを目的としているのは、RIDホスト間でメッセージを送信する柔軟性です。RIDはIODEFスキーマを含む個別のスキーマであるため、RID情報はエンベロープとして機能し、その後、輸送プロトコルで使用するためにRidpolicyクラスを簡単に抽出できます。ネットワーク全体でインシデント情報を送信するセキュリティ要件には、暗号化の使用が含まれます。Ridpolicy情報を暗号化する必要はないため、IODEF拡張からこのデータを分離すると、IODEF全体を復号化および解析し、各RIDホストでの処理方法を決定する必要があります。
The purpose of the RIDPolicy class is to specify the message type for the receiving host, facilitate the policy needs of RID, and provide routing information in the form of an IP address of the destination RID system.
Ridpolicyクラスの目的は、受信ホストのメッセージタイプを指定し、RIDのポリシーニーズを促進し、宛先RIDシステムのIPアドレスの形でルーティング情報を提供することです。
The policy information and guidelines are discussed in Section 6.6. The policy is defined between RID peers and within or between consortiums. The RIDPolicy is meant to be a tool to facilitate the defined policies. This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document.
ポリシー情報とガイドラインについては、セクション6.6で説明します。このポリシーは、RIDピア間およびコンソーシアム内またはコンソーシアム間で定義されています。Ridpolicyは、定義されたポリシーを促進するためのツールであることを意図しています。これは、クライアント、ピア、コンソーシアム、および/または地域の間のポリシーセットに従って使用する必要があります。このドキュメントで指定されているように、セキュリティ、プライバシー、および機密性を考慮する必要があります。
The RID schema is defined as follows:
RIDスキーマは次のように定義されています。
+------------------+
| RID |
+------------------+
| ANY |
| |<>---{0..1}----[ RIDPolicy ]
| ENUM restriction |
| ENUM type |<>---{0..1}----[ RequestStatus ]
| STRING meaning |
| |<>---{0..1}----[ IncidentSource ]
+------------------+
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.
ゼロまたは1。Ridpolicyクラスは、すべてのメッセージタイプで使用され、ピア、コンソーシアム、または連合間の政策契約を促進し、メッセージを適切にルーティングします。
RequestStatus
RequestStatus
Zero or One. The RequestStatus class is used only in RequestAuthorization messages to report back to the originating RID system if the trace will be continued by each RID system that received a TraceRequest in the path to the source of the traffic.
ゼロまたは1。RequestStatusクラスは、Request Authorizationメッセージでのみ使用され、トラフィックのソースへのパスでトレイセレックを受け取った各RIDシステムによってトレースが継続される場合、発信元のRIDシステムに報告します。
IncidentSource
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.
ゼロまたは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 [RFC6046], as that information should be as small as possible and may not be encrypted. The RequestStatus message MUST be able to stand alone without the need for an IODEF document to facilitate the communication, limiting the data transported to the required elements per [RFC6046].
リストされた3つのクラスのそれぞれは、RIDクラスに含まれる唯一のクラスである可能性があるため、ゼロまたは1つのクラスのオプションです。場合によっては、輸送プロトコル[RFC6046]が使用する場合、RID定義の唯一のクラスである場合があります。その情報は可能な限り小さく、暗号化されない可能性があるためです。RequestStatusメッセージは、[RFC6046]ごとに必要な要素に輸送されたデータを制限し、通信を促進するためにIODEFドキュメントを必要とせずに単独でスタンドラングできる必要があります。
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 4. The RequestStatus Class
図4. RequestStatusクラス
The RequestStatus class has five attributes:
RequestStatusクラスには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.
オプション。列挙。この属性は、送信者が受信者が付着することを期待する開示ガイドラインを示します。このガイドラインは、ドキュメントの受信者の選択であるため、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。
AuthorizationStatus
AuthorizationStatus
REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a TraceRequest in the current network.
必要。列挙。リストされている値は、現在のネットワークのTraceRequestのステータスの要求CSIRTへの応答を提供するために使用されます。
1. Approved. The trace was approved and will begin in the current NP.
1. 承認済み。トレースは承認され、現在のNPで開始されます。
2. Denied. The trace was denied in the current NP. The next closest NP can use this message to filter traffic from the upstream NP using the example packet to help mitigate the effects of the attack as close to the source as possible. The RequestAuthorization message must be passed back to the originator and a Result message used from the closest NP to the source to indicate actions taken in the IODEF History class.
2. 拒否された。トレースは現在のNPで拒否されました。次に最も近いNPは、このメッセージを使用して、サンプルパケットを使用して上流のNPからのトラフィックをフィルタリングして、可能な限りソースに近い攻撃の影響を軽減するのに役立ちます。RequestAuthorizationメッセージは、Originatorに渡す必要があり、IODEF Historyクラスで実行されたアクションを示すために、最も近いNPからソースに使用された結果メッセージが必要です。
3. Pending. Awaiting approval; a timeout period has been reached, which resulted in this Pending status and RequestAuthorization message being generated.
3. 保留中。承認待ち;タイムアウト期間に達したため、この保留中のステータスと要求の承認メッセージが生成されました。
4. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
4. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
Justification
正当化
OPTIONAL. ENUM. Provides a reason for a Denied or Pending message.
オプション。列挙。拒否または保留中のメッセージの理由を提供します。
1. SystemResource. A resource issue exists on the systems that would be involved in the request.
1. 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 IP packet failed to validate.
3. Authenticationorigin。IPパケットの元の要求者のデタッチされたデジタル署名は、検証に失敗しました。
4. Encryption. Unable to decrypt the request.
4. 暗号化。リクエストを復号化できません。
5. Other. There were other reasons this request could not be processed.
5. 他の。この要求を処理できない他の理由がありました。
6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
6. ext-value。この属性を拡張するために使用されるエスケープ値。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.
オプション。ストリング。AuthorizationStatus属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
Justification-ext
正当化 - 伸び
OPTIONAL. STRING. A means by which to extend the Justification attribute. See IODEF [RFC5070], Section 5.1.
オプション。ストリング。正当化属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
The IncidentSource class is an aggregate class in the RID class.
Incidentsourceクラスは、RIDクラスの集計クラスです。
+-------------------+
| IncidentSource |
+-------------------+
| |
| ENUM restriction |
| |<>-------------[ SourceFound ]
| |
| |<>---{0..*}----[ Node ]
| |
+-------------------+
Figure 5. The IncidentSource Class
図5. Incidentsourceクラス
The elements that constitute the IncidentSource class follow:
インシデントソースクラスを構成する要素は次のとおりです。
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.
一。ブール。ソースクラスは、ソースが識別されたかどうかを示します。ソースが識別された場合、このクラスのノード要素にリストされます。
True. Source of incident was identified. False. Source of incident was not identified.
真実。インシデントの原因が特定されました。間違い。インシデントの原因は特定されていません。
Node
ノード
One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages.
一。ノードクラスは、ホストまたはネットワークデバイスを識別するために使用されます。この場合、RIDメッセージの通信システムを識別します。
The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16.
このクラスの基本定義は、IODEF仕様[RFC5070]、セクション3.16から再利用されます。
The IncidentSource class has one attribute:
IncidentSourceクラスには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.
オプション。列挙。この属性は、送信者が受信者が付着することを期待する開示ガイドラインを示します。このガイドラインは、ドキュメントの受信者の選択であるため、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。
The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6046].
Ridpolicyクラスは、RIDメッセージの配信を促進し、輸送文書の輸送用にも参照されます[RFC6046]。
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
+------------------------+
Figure 6. The RIDPolicy Class
図6. Ridpolicyクラス
The aggregate elements that constitute the RIDPolicy class are as follows:
Ridpolicyクラスを構成する集約要素は次のとおりです。
Node
ノード
One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages.
一。ノードクラスは、ホストまたはネットワークデバイスを識別するために使用されます。この場合、RIDメッセージの通信システムを識別します。
The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16.
このクラスの基本定義は、IODEF仕様[RFC5070]、セクション3.16から再利用されます。
IncidentID
incapsid
Zero or one. Global reference pointing back to the IncidentID defined in the IODEF data model. The IncidentID includes the name of the CSIRT, an incident number, and an instance of that incident. The instance number is appended with a dash separating the values and is used in cases for which it may be desirable to group incidents. Examples of incidents that may be grouped would be botnets, DDoS attacks, multiple hops of compromised systems found during an investigation, etc.
ゼロまたは1。IODEFデータモデルで定義されているIncissidIDを指すグローバル参照。IncisidIDには、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.
1つまたは多く。必要。属性「領域」の値は、トレースを承認する前に検討が必要なポリシー領域を決定するために使用されます。ポリシーリージョンには、地域、コンソーシアム、またはネットワークを横断する際に可能なすべてのポリシーに関する考慮事項に適合するために、属性リストから複数の選択を含めることができます。
region
領域
One. ENUM.
一。列挙。
1. ClientToNP. An enterprise network initiated the request.
1. clienttonp。エンタープライズネットワークがリクエストを開始しました。
2. NPToClient. An NP passed a RID request to a client or an enterprise attached network to the NP based on the service level agreements.
2. nptoclient。NPは、サービスレベルの契約に基づいて、クライアントまたはエンタープライズ接続ネットワークへのNPへのRIDリクエストを渡しました。
3. IntraConsortium. A trace that should have no restrictions within the boundaries of a consortium with the agreed-upon use and abuse guidelines.
3. コンソーシアム内。合意された使用および乱用ガイドラインを備えたコンソーシアムの境界内に制限がないはずの痕跡。
4. PeerToPeer. A trace that should have no restrictions between two peers but may require further evaluation before continuance beyond that point with the agreed-upon use and abuse guidelines.
4. ピアツーピア。2人のピア間に制限がないが、合意された使用と乱用ガイドラインでその点を超えて継続する前にさらに評価が必要になる場合がある痕跡。
5. BetweenConsortiums. A trace that should have no restrictions between consortiums that have established agreed-upon use and abuse guidelines.
5. betweenconsortiums。合意された使用と乱用ガイドラインを確立したコンソーシアムの間に制限を持たないはずの痕跡。
6. AcrossNationalBoundaries. This selection must be set if the trace type is anything but a trace of attack traffic with malicious intent. This must also be set if the traffic request is based upon regulations of a specific nation that would not apply to all nations. This is different from the "BetweenConsortiums" setting since it may be possible to have multiple nations as members of the same consortium, and this option must be selected if the traffic is of a type that may have different restrictions in other nations.
6. 国家国家。トレースタイプが悪意のある意図を持つ攻撃トラフィックの痕跡以外のものである場合、この選択を設定する必要があります。これは、交通要求がすべての国に適用されない特定の国の規制に基づいている場合にも設定する必要があります。これは、同じコンソーシアムのメンバーとして複数の国を持つことが可能である可能性があるため、「betweenconsortiums」の設定とは異なります。このオプションは、トラフィックが他の国に異なる制限を持つ可能性のあるタイプの場合は選択する必要があります。
7. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
7. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
TrafficType
交換します
One or many. REQUIRED. The values for the attribute "type" are meant to assist in determining if a trace is appropriate for the NP receiving the request to continue the trace. Multiple values may be selected for this element; however, where possible, it should be restricted to one value that would most accurately describe the traffic type.
1つまたは多く。必要。属性「タイプ」の値は、トレースがトレースを継続するリクエストを受信するのに適しているかどうかを判断するのを支援することを目的としています。この要素に対して複数の値を選択できます。ただし、可能であれば、トラフィックタイプを最も正確に説明する1つの値に制限する必要があります。
type
タイプ
One. ENUM.
一。列挙。
1. Attack. This option should only be selected if the traffic is related to a network-based attack. The type of attack MUST also be listed in more detail in the IODEF Method and Impact classes for further clarification to assist in determining if the trace can be continued ([RFC5070], Sections 3.9 and 3.10.1).
1. 攻撃。このオプションは、トラフィックがネットワークベースの攻撃に関連している場合にのみ選択する必要があります。また、攻撃のタイプは、IODEFメソッドとインパクトクラスにさらに詳細にリストされ、さらに説明して、トレースを継続できるかどうかを判断するのに役立つ必要があります（[RFC5070]、セクション3.9および3.10.1）。
2. Network. This option MUST only be selected when the trace is related to NP network traffic or routing issues.
2. 通信網。このオプションは、トレースがNPネットワークトラフィックまたはルーティングの問題に関連している場合にのみ選択する必要があります。
3. Content. This category MUST be used only in the case in which the request is related to the content and regional restrictions on accessing that type of content exist. This is not malicious traffic but may include determining what sources or destinations accessed certain materials available on the Internet, including, but not limited to, news, technology, or inappropriate content.
3. コンテンツ。このカテゴリは、リクエストがコンテンツとそのタイプのコンテンツへのアクセスに関する地域の制限に関連している場合にのみ使用する必要があります。これは悪意のあるトラフィックではありませんが、ニュース、テクノロジー、または不適切なコンテンツを含むがこれらに限定されない、インターネット上で利用可能な特定の資料にアクセスしたソースまたは目的地を決定することが含まれる場合があります。
4. OfficialBusiness. This option MUST be used if the traffic being traced is requested or is affiliated with any government or other official business request. This would be used during an investigation by government authorities or other government traces to track suspected criminal or other activities.
4. 公式ビジネス。このオプションは、トレースされているトラフィックが要求されている場合、または政府またはその他の公式ビジネスリクエストと提携している場合は、使用する必要があります。これは、政府当局または他の政府の痕跡による調査中に使用され、疑わしい刑事またはその他の活動を追跡します。
5. Other. If this option is selected, a description of the traffic type MUST be provided so that policy decisions can be made to continue or stop the trace. The information should be provided in the IODEF message in the Expectation class or in the History class using a HistoryItem log.
5. 他の。このオプションが選択されている場合、トレースを継続または停止するためにポリシー決定を行うことができるように、トラフィックタイプの説明を提供する必要があります。情報は、HistoryItemログを使用して、期待クラスのIODEFメッセージまたは履歴クラスで提供する必要があります。
6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
6. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
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.
オプション。列挙。この属性は、送信者が受信者が付着することを期待する開示ガイドラインを示します。このガイドラインは、ドキュメントの受信者の選択であるため、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。
MsgType
msgtype
REQUIRED. ENUM. The type of RID message sent. The six types of messages are described in Section 4.3.2 and can be noted as one of the six selections below.
必要。列挙。送信されたRIDメッセージのタイプ。6種類のメッセージはセクション4.3.2で説明されており、以下の6つの選択のいずれかとして記録できます。
1. TraceRequest. This message may be used to initiate a TraceRequest or to continue a TraceRequest to an upstream network closer to the source address of the origin of the security incident.
1. TraceRequest。このメッセージは、TraceRequestを開始したり、セキュリティインシデントの起源のソースアドレスに近いアップストリームネットワークへのTraceRequestを継続するために使用できます。
2. RequestAuthorization. This message is sent to the initiating RID system from each of the upstream RID systems to provide information on the request status in the current network.
2. RequestAuthorization。このメッセージは、現在のネットワークの要求ステータスに関する情報を提供するために、各上流の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システムを介して開始システムに送信されることを示しています。
4. Investigation. This message type is used when the source of the traffic is believed to be valid. The purpose of the Investigation request is to leverage the existing peer or consortium relationships in order to notify the NP closest to the source of the valid traffic that some event occurred, which may be a security-related incident.
4. 調査。このメッセージタイプは、トラフィックのソースが有効であると考えられている場合に使用されます。調査要求の目的は、一部のイベントが発生した有効なトラフィックのソースに最も近いNPに通知するために、既存のピアまたはコンソーシアムの関係を活用することです。これは、セキュリティ関連のインシデントである可能性があります。
5. Report. This message is used to report a security incident, for which no action is requested in the IODEF Expectation class. This may be used for the purpose of correlating attack information by CSIRTs, statistics and trending information, etc.
5. 報告書。このメッセージは、IODEFの期待クラスではアクションが要求されていないセキュリティインシデントを報告するために使用されます。これは、攻撃情報をCSIRT、統計、トレンド情報などによって相関させる目的で使用できます。
6. IncidentQuery. This message is used to request information from a trusted RID system about an incident or incident type.
6. インシデントクエリ。このメッセージは、インシデントタイプまたはインシデントタイプに関する信頼できるRIDシステムから情報を要求するために使用されます。
Additionally, there is an extension attribute to add new enumerated values:
さらに、新しい列挙値を追加するための拡張属性があります。
- ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
- ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
MsgDestination
msgdestination
REQUIRED. ENUM. The destination required at this level may either be the RID messaging system intended to receive the request, or, in the case of an Investigation request, the source of the incident. In the case of an Investigation request, the RID system that can help stop or mitigate the traffic may not be known, and the message may have to traverse RID messaging systems by following the routing path to the RID system closest to the source of the attack traffic. The Node element lists either the RID system or the IP address of the source, and the meaning of the value in the Node element is determined by the MsgDestination element.
必要。列挙。このレベルで必要な宛先は、リクエストを受け取ることを目的としたRIDメッセージングシステム、または調査リクエストの場合、インシデントのソースのいずれかです。調査リクエストの場合、トラフィックの停止または軽減に役立つRIDシステムはわからない場合があり、攻撃のソースに最も近いRIDシステムへのルーティングパスに従ってRIDメッセージングシステムを通過する必要がある場合があります。トラフィック。ノード要素は、ソースのRIDシステムまたはIPアドレスのいずれかをリストし、ノード要素の値の意味はMSGDestination要素によって決定されます。
1. RIDSystem. The address listed in the Node element of the RIDPolicy class is the next upstream RID system that will receive the RID message.
1. リッジシステム。Ridpolicyクラスのノード要素にリストされているアドレスは、RIDメッセージを受信する次のアップストリームRIDシステムです。
2. SourceOfIncident. The address listed in the Node element of the RIDPolicy class is the incident source. The IP address is used to determine the path of RID systems that will be used to find the closest RID system to the source of an attack in which the IP address used by the source is believed to be valid and an Investigation request message is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial trace or Investigation request, not the source used in a Result message.
2. IncidentのSource。Ridpolicyクラスのノード要素にリストされているアドレスは、インシデントソースです。IPアドレスは、ソースで使用されるIPアドレスが有効であると考えられており、調査リクエストメッセージが使用される攻撃のソースに最も近いRIDシステムを見つけるために使用されるRIDシステムのパスを決定するために使用されます。これは、Incidentsourceクラスと混同しないでください。ここで定義された値は、結果メッセージで使用されるソースではなく、初期トレースまたは調査要求からのものであるためです。
3. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
3. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
MsgType-ext
msgtype-ext
OPTIONAL. STRING. A means by which to extend the MsgType attribute. See IODEF [RFC5070], Section 5.1.
オプション。ストリング。MSGType属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
MsgDestination-ext
MSG Destination-ETC
OPTIONAL. STRING. A means by which to extend the MsgDestination attribute. See IODEF [RFC5070], Section 5.1.
オプション。ストリング。msgdestination属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
The RID schema declares a namespace of "iodef-rid-1.0" and registers it per [XMLnames]. Each IODEF-RID document MUST use the "iodef-rid-1.0" namespace in the top-level element RID-Document. It can be referenced as follows:
RIDスキーマは、「iodef-rid-1.0」の名前空間を宣言し、[xmlnames]ごとに登録します。各IODEF-RIDドキュメントは、トップレベルの要素RIDドキュメントの「IODEF-RID-1.0」名前空間を使用する必要があります。次のように参照できます。
<RID-Document
version="1.00" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xsi:schemaLocation=http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.0.xsd">
The IODEF model is followed as specified in [RFC5070] for each of the RID message types. The RID schema is used in combination with IODEF documents to facilitate RID communications. Each message type varies slightly in format and purpose; hence, the requirements vary and are specified for each. All classes, elements, attributes, etc., that are defined in the IODEF-Document are valid in the context of a RID message; however, some listed as optional in IODEF are mandatory for RID as listed for each message type. The IODEF model MUST be fully implemented to ensure proper parsing of all RID messages.
IODEFモデルは、RIDメッセージタイプのそれぞれについて[RFC5070]で指定されているように追跡されます。RIDスキーマは、IODEFドキュメントと組み合わせて使用され、RID通信を促進します。各メッセージタイプの形式と目的はわずかに異なります。したがって、要件は異なり、それぞれに対して指定されます。IODEF-Documentで定義されているすべてのクラス、要素、属性などは、RIDメッセージのコンテキストで有効です。ただし、IODEFでオプションとしてリストされているものは、各メッセージタイプにリストされているRIDに必須です。IODEFモデルは、すべてのRIDメッセージを適切に解析するために完全に実装する必要があります。
Note: The implementation of the RID system may obtain some of the information needed to fill in the content required for each message type automatically from packet input to the system or default information such as that used in the EventData class.
注：RIDシステムの実装により、各メッセージタイプに必要なコンテンツをパケット入力からシステムまたはイベントDataクラスで使用しているようなデフォルト情報に自動的に入力するために必要な情報の一部が取得される場合があります。
Description: This message or document is sent to the network management station next in the upstream trace once the upstream source of the traffic has been identified.
説明：このメッセージまたはドキュメントは、トラフィックの上流のソースが特定されたら、上流トレースのネットワーク管理ステーションに送信されます。
The following information is required for TraceRequest messages and is provided through:
Tracerequestメッセージには次の情報が必要であり、次のことを介して提供されます。
RID Information:
情報を削除：
RIDPolicy RID message type, IncidentID, and destination policy information
Ridpolicy RIDメッセージタイプ、IncisidID、および宛先ポリシー情報
IODEF Information:
IODEF情報：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
インシデント識別子（インシデントクラス、IncisisID）。トレース番号 - 単一のインシデントの複数のトレースに使用されます。注意する必要があります。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring an upstream TraceRequest in RID.
システムクラスは、攻撃で使用されているソース情報と宛先情報の両方をリストするために使用され、トラフィックがスプーフィングされているかどうかを記録する必要があるため、RIDで上流のトレイケーストが必要です。
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".
ネストされたRIDシステムのパス情報。IODEFEventDataを使用してTRACEで使用されているリクエストオリジネーターから始まり、カテゴリを「インフラストラクチャ」に設定します。
Event, Record, and RecordItem classes to include example packets and other information related to the incident. Note: Event information included here requires a second instance of EventData in addition to that used to convey NP path contact information.
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットやその他の情報を含めるためのクラス。注：ここに含まれるイベント情報には、NPパスの連絡先情報を伝えるために使用されるものに加えて、EventDataの2番目のインスタンスが必要です。
Standards for encryption and digital signatures [RFC3275], [XMLsig]:
暗号化およびデジタル署名の標準[RFC3275]、[XMLSIG]：
Digital signature from initiating RID system, passed to all systems in upstream trace using XML digital signature.
RIDシステムを開始したデジタル署名は、XMLデジタル署名を使用して上流トレースのすべてのシステムに渡されました。
A DDoS attack can have many sources, resulting in multiple traces to locate the sources of the attack. It may be valid to continue multiple traces for a single attack. The path information would enable the administrators to determine if the exact trace had already passed through a single network. The Incident Identifier must also be used to identify multiple TraceRequests from a single incident. If a single TraceRequest results in divergent paths of TraceRequests, a separate instance number MUST be used under the same IncidentID. The IncidentID instance number of IODEF can be used to correlate related incident data that is part of a larger incident.
DDOS攻撃には多くのソースがある可能性があり、その結果、攻撃のソースを見つけるための複数の痕跡が発生する可能性があります。単一の攻撃に対して複数のトレースを継続することは有効です。パス情報により、管理者は正確なトレースがすでに単一のネットワークを通過しているかどうかを判断できます。インシデント識別子は、単一のインシデントから複数のトレイセレケストを識別するためにも使用する必要があります。単一のTraceRequestがTraceRequestsの発散パスをもたらす場合、同じIncisidIDの下で個別のインスタンス番号を使用する必要があります。IDESISIDインスタンスのIODEFの数を使用して、より大きなインシデントの一部である関連するインシデントデータを相関させることができます。
Description: This message is sent to the initiating RID system from the next upstream NP's RID system to provide information on the request status in the current network.
説明：このメッセージは、次のアップストリームNPのRIDシステムから開始RIDシステムに送信され、現在のネットワークのリクエストステータスに関する情報を提供します。
The following information is required for RequestAuthorization messages and is provided through:
次の情報は、リクエストアソート化メッセージに必要であり、次のことを介して提供されます。
RID Information:
情報を削除：
RIDPolicy RID message type, IncidentID, and destination policy information
Ridpolicy RIDメッセージタイプ、IncisidID、および宛先ポリシー情報
Status of TraceRequest RequestStatus class in RID schema
Rid SchemaのTraceRequest RequestStatusクラスのステータス
Standards for encryption and digital signatures [RFC3275], [XMLsig]:
暗号化およびデジタル署名の標準[RFC3275]、[XMLSIG]：
Digital signature of responding NP for authenticity of Trace Status Message, from the NP creating this message using XML digital signature.
XML Digital Signatureを使用してこのメッセージを作成したNPから、TRACEステータスメッセージの信頼性のためのNPの応答のデジタル署名。
A message is sent back to the initiating RID system of the trace as status notification. This message verifies that the next RID system in the path has received the message from the previous system in the path. This message also verifies that the trace is now continuing, has stopped, or is pending in the next upstream RID system. The Pending status would be automatically generated after a 2-minute timeout without system-predefined or administrator action taken to approve or disapprove the trace continuance. If a Request is denied, the originator and sending peer (if they are not the same) MUST both receive the message. This enables the sending peer the option to take action to stop or mitigate the traffic as close to the source as possible.
メッセージが、ステータス通知としてトレースのredシステムを開始するように送信されます。このメッセージは、パス内の次のRIDシステムがパスの以前のシステムからメッセージを受信したことを確認します。また、このメッセージは、トレースが継続している、停止している、または次の上流のRIDシステムで保留中であることを確認します。保留中のステータスは、トレースの継続を承認または不承認にするために取られたシステム処理または管理者アクションなしで2分間のタイムアウトの後に自動的に生成されます。リクエストが拒否された場合、オリジネーターとピアの送信（それらが同じではない場合）は両方ともメッセージを受信する必要があります。これにより、送信中のピアが、可能な限りソースに近いトラフィックを停止または軽減するためのアクションを実行するオプションを可能にします。
Description: This message indicates that the trace or investigation has been completed and provides the result. The Result message includes information on whether or not a source was found and the source information through the IncidentSource class. The Result information MUST go back to the originating RID system that began the investigation or trace. An NP may use any number of incident handling data sources to ascertain the true source of an attack. All of the possible information sources may or may not be readily tied into the RID communications system.
説明：このメッセージは、トレースまたは調査が完了したことを示し、結果を提供します。結果メッセージには、ソースが見つかったかどうかに関する情報と、Incidentsourceクラスを通じてソース情報が含まれています。結果情報は、調査またはトレースを開始した発信元のRIDシステムに戻る必要があります。NPは、攻撃の真のソースを確認するために、任意の数のインシデント処理データソースを使用する場合があります。考えられる情報源はすべて、RID通信システムに容易に結び付けられる場合とそうでない場合があります。
The following information is required for Result messages and will be provided through:
結果メッセージには次の情報が必要であり、以下を通じて提供されます。
RID Information:
情報を削除：
RIDPolicy RID message type, IncidentID, and destination policy information
Ridpolicy RIDメッセージタイプ、IncisidID、および宛先ポリシー情報
Incident Source The IncidentSource class of the RID schema is used to note if a source was identified and provide the source address(es).
インシデントソースRIDスキーマのインシデントソースクラスを使用して、ソースが識別されたかどうかに注意し、ソースアドレスを提供します。
IODEF Information:
IODEF情報：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
インシデント識別子（インシデントクラス、IncisisID）。トレース番号 - 単一のインシデントの複数のトレースに使用されます。注意する必要があります。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring an upstream TraceRequest in RID.
システムクラスは、攻撃で使用されているソース情報と宛先情報の両方をリストするために使用され、トラフィックがスプーフィングされているかどうかを記録する必要があるため、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 NP listed is the NP that located the source of the traffic (the NP sending the Result message).
ネストされたRIDシステムのパス情報。IODEFEventDataを使用してTRACEで使用されているリクエストオリジネーターから始まり、カテゴリを「インフラストラクチャ」に設定します。リストされている最後のNPは、トラフィックのソースを見つけたNPです（結果メッセージの送信NP）。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional). Note: Event information included here requires a second instance of EventData in addition to that used to convey NP path contact information.
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットとその他の情報を含める（オプション）。注：ここに含まれるイベント情報には、NPパスの連絡先情報を伝えるために使用されるものに加えて、EventDataの2番目のインスタンスが必要です。
Standards for encryption and digital signatures [RFC3275]:
暗号化とデジタル署名の基準[RFC3275]：
Digital signature of source NP for authenticity of Result Message, from the NP creating this message using XML digital signature.
XML Digital Signatureを使用してこのメッセージを作成するNPから、結果メッセージの信頼性のためのソースNPのデジタル署名。
A message is sent back to the initiating RID system to notify the associated CSIRT that the source has been located. The actual source information may or may not be included, depending on the policy of the network in which the client or host is attached. Any action taken by the NP to act upon the discovery of the source of a trace should be included. The NP may be able to automate the adjustment of filters at their border router to block outbound access for the machine(s) discovered as a part of the attack. The filters may be comprehensive enough to block all Internet access until the host has taken the appropriate action to resolve any security issues or to rate-limit the ingress traffic as close to the source as possible.
メッセージは、ソースが配置されていることを関連するCSIRTに通知するために、Initiating RIDシステムに送信されます。クライアントまたはホストが添付されているネットワークのポリシーに応じて、実際のソース情報は含まれている場合と含まれない場合があります。NPが取ったアクションは、トレースのソースの発見に基づいて行動する必要があります。NPは、ボーダールーターでのフィルターの調整を自動化して、攻撃の一部として発見されたマシンのアウトバウンドアクセスをブロックできる場合があります。フィルターは、ホストがセキュリティの問題を解決したり、イングレストラフィックを可能な限りソースに近づけたりするために適切なアクションを実行するまで、すべてのインターネットアクセスをブロックするのに十分包括的である可能性があります。
Security and privacy considerations discussed in Section 6 MUST be taken into account.
セクション6で説明したセキュリティとプライバシーの考慮事項を考慮する必要があります。
Note: The History class has been expanded in IODEF to accommodate all of the possible actions taken as a result of a RID TraceRequest or Investigation request using the "iodef:atype", or action type, attribute. The History class should be used to note all actions taken close to the source of a trace or incident using the most appropriate option for the type of action along with a description. The "atype" attribute in the Expectation class can also be used to request an appropriate action when a TraceRequest or Investigation request is made.
注：「IODEF：ATYPE」またはアクションタイプの属性を使用して、RID TracereQuestまたは調査要求の結果として実行されるすべての可能なアクションに対応するために、履歴クラスがIODEFで拡張されました。履歴クラスは、説明とともにアクションの種類に最も適切なオプションを使用して、トレースまたはインシデントのソースに近いすべてのアクションを記録するために使用する必要があります。予想クラスの「Atype」属性を使用して、Tracerequestまたは調査リクエストが行われたときに適切なアクションを要求することもできます。
Description: This message type is used when the source of the traffic is believed not to be spoofed. The purpose of the Investigation request message is to leverage the existing bilateral peer relationships in order to notify the network provider closest to the source of the valid traffic that some event occurred, which may be a security-related incident.
説明：このメッセージタイプは、トラフィックのソースがスプーフィングされていないと考えられている場合に使用されます。調査要求メッセージの目的は、一部のイベントが発生した有効なトラフィックのソースに最も近いネットワークプロバイダーに通知するために、既存の二国間ピア関係を活用することです。これは、セキュリティ関連のインシデントである可能性があります。
The following information is required for Investigation request messages and is provided through:
調査リクエストメッセージには次の情報が必要であり、以下を介して提供されます。
RID Information:
情報を削除：
RID Policy RID message type, IncidentID, and destination policy information
RIDポリシーをRIDメッセージタイプ、IncisidID、および宛先ポリシー情報
IODEF Information:
IODEF情報：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
インシデント識別子（インシデントクラス、IncisisID）。トレース番号 - 単一のインシデントの複数のトレースに使用されます。注意する必要があります。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring an upstream TraceRequest in RID.
システムクラスは、攻撃で使用されているソース情報と宛先情報の両方をリストするために使用され、トラフィックがスプーフィングされているかどうかを記録する必要があるため、RIDで上流のトレイケーストが必要です。
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".
ネストされたRIDシステムのパス情報。IODEFEventDataを使用してTRACEで使用されているリクエストオリジネーターから始まり、カテゴリを「インフラストラクチャ」に設定します。
Event, Record, and RecordItem classes to include example packets and other information related to the incident. Note: Event information included here requires a second instance of EventData in addition to that used to convey NP path contact information.
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットやその他の情報を含めるためのクラス。注：ここに含まれるイベント情報には、NPパスの連絡先情報を伝えるために使用されるものに加えて、EventDataの2番目のインスタンスが必要です。
Standards for encryption and digital signatures [RFC3275]:
暗号化とデジタル署名の基準[RFC3275]：
Digital signature from initiating RID system, passed to all systems in upstream trace using XML digital signature.
RIDシステムを開始したデジタル署名は、XMLデジタル署名を使用して上流トレースのすべてのシステムに渡されました。
Security considerations would include the ability to encrypt [XMLencrypt] the contents of the Investigation request message using the public key of the destination RID system. The incident number would increase as if it were a TraceRequest message in order to ensure uniqueness within the system. The relaying peers would also append their Autonomous System (AS) or RID system information as the request message was relayed along the web of network providers so that the Result message could utilize the same path as the set of trust relationships for the return message, thus indicating any actions taken. The request would also be recorded in the state tables of both the initiating and destination NP RID systems. The destination NP is responsible for any actions taken as a result of the request in adherence to any service level agreements or internal policies. The NP should confirm that the traffic actually originated from the suspected system before taking any action and confirm the reason for the request. The request may be sent directly to a known RID system or routed by the source address of the attack using the message destination of RIDPolicy, SourceOfIncident.
セキュリティ上の考慮事項には、宛先RIDシステムの公開キーを使用して、調査要求メッセージの内容を暗号化する機能が含まれます。インシデント数は、システム内の一意性を確保するために、まるでTraceRequestメッセージであるかのように増加します。リレーンピアは、リクエストメッセージがネットワークプロバイダーのWebに沿って中継されたため、自律システム（AS）またはRIDシステム情報を追加して、結果メッセージがリターンメッセージの信頼関係のセットと同じパスを利用できるようにするため、実行されたアクションを示します。リクエストは、開始および宛先NP RIDシステムの両方の状態表に記録されます。宛先NPは、サービスレベルの契約または内部ポリシーを順守する要求の結果として取られたアクションについて責任を負います。NPは、行動を起こす前にトラフィックが実際に疑わしいシステムから発生したことを確認し、要求の理由を確認する必要があります。リクエストは、既知のRIDシステムに直接送信されるか、Ridpolicyのメッセージ宛先であるSource of incidentを使用して攻撃のソースアドレスによってルーティングされる場合があります。
Note: All intermediate parties must be able to view RIDPolicy information in order to properly direct RID messages.
注：すべての中間関係者は、メッセージを適切に指示するために、リッピング情報を表示できる必要があります。
Description: This message or document is sent to a RID system to provide a report of a security incident. This message does not require any actions to be taken, except to file the report on the receiving RID system or associated database.
説明：このメッセージまたはドキュメントは、セキュリティインシデントのレポートを提供するためにRIDシステムに送信されます。このメッセージは、受信RIDシステムまたは関連データベースに関するレポートを提出することを除き、アクションを実行する必要はありません。
The following information is required for Report messages and will be provided through:
レポートメッセージには次の情報が必要であり、以下を通じて提供されます。
RID Information:
情報を削除：
RID Policy RID message type, IncidentID, and destination policy information
RIDポリシーをRIDメッセージタイプ、IncisidID、および宛先ポリシー情報
The following data is recommended if available and can be provided through:
利用可能な場合は次のデータを推奨し、次のように提供できます。
IODEF Information:
IODEF情報：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
インシデント識別子（インシデントクラス、IncisisID）。トレース番号 - 単一のインシデントの複数のトレースに使用されます。注意する必要があります。
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.
システムクラスは、攻撃で使用されるソース情報と宛先情報の両方をリストするために使用されます。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional).
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットとその他の情報を含める（オプション）。
Standards for encryption and digital signatures [RFC3275]:
暗号化とデジタル署名の基準[RFC3275]：
Digital signature from initiating RID system, passed to all systems receiving the report using XML digital signature.
RIDシステムの開始からのデジタル署名は、XMLデジタル署名を使用してレポートを受信するすべてのシステムに渡されました。
Security considerations would include the ability to encrypt [XMLencrypt] the contents of the Report message using the public key of the destination RID system. Senders of a Report message should note that the information may be used to correlate security incident information for the purpose of trending, pattern detection, etc., and may be shared with other parties unless otherwise agreed upon with the receiving RID system. Therefore, sending parties of a Report message may obfuscate or remove destination addresses or other sensitive information before sending a Report message. A Report message may be sent either to file an incident report or in response to an IncidentQuery, and data sensitivity must be considered in both cases. The NP path information is not necessary for this message, as it will be communicated directly between two trusted RID systems.
セキュリティ上の考慮事項には、宛先RIDシステムの公開キーを使用して、レポートメッセージの内容を暗号化する機能が含まれます。レポートメッセージの送信者は、情報がトレンド、パターン検出などを目的としてセキュリティインシデント情報を相関させるために使用される可能性があることに注意する必要があり、受信RIDシステムと特に合意されていない限り、他の関係者と共有される場合があります。したがって、レポートメッセージのパーティの送信は、レポートメッセージを送信する前に、宛先アドレスまたはその他の機密情報を難読化または削除する場合があります。レポートメッセージは、インシデントレポートを提出するか、インシデントクエリに応じて送信される場合があり、どちらの場合もデータの感度を考慮する必要があります。NPパス情報は、このメッセージには2つの信頼できるRIDシステム間で直接伝達されるため、必要ありません。
Description: The IncidentQuery message is used to request incident information from a trusted RID system. The request can include the incident number, if known, or detailed information about the incident. If the incident number is known, the Report message containing the incident information can easily be returned to the trusted requestor using automated methods. If an example packet or other unique information is included in the IncidentQuery, the return report may be automated; otherwise, analyst intervention may be required.
説明：IncissQueryメッセージは、信頼できるRIDシステムからインシデント情報を要求するために使用されます。リクエストには、既知の場合、インシデント番号、またはインシデントに関する詳細情報を含めることができます。インシデント番号がわかっている場合、インシデント情報を含むレポートメッセージは、自動化された方法を使用して信頼できる要求者に簡単に返すことができます。インシデントクエリにパケットまたはその他のユニークな情報の例が含まれている場合、返品レポートが自動化される場合があります。それ以外の場合、アナリストの介入が必要になる場合があります。
The following information must be used for an IncidentQuery message and is provided through:
次の情報は、インシデントクエリメッセージに使用する必要があり、以下を通じて提供されます。
RID Information:
情報を削除：
RID Policy RID message type, IncidentID, and destination policy information
RIDポリシーをRIDメッセージタイプ、IncisidID、および宛先ポリシー情報
IODEF Information (optional):
IODEF情報（オプション）：
Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID). Trace number - used for multiple traces of a single incident; must be noted.
インシデント識別子（インシデントクラス、IncisisID）。トレース番号 - 単一のインシデントの複数のトレースに使用されます。注意する必要があります。
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.
システムクラスは、攻撃で使用されるソース情報と宛先情報の両方をリストするために使用されます。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional).
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットとその他の情報を含める（オプション）。
Standards for encryption and digital signatures [RFC3275]:
暗号化とデジタル署名の基準[RFC3275]：
Digital signature from initiating RID system, passed to all systems receiving the IncidentQuery using XML digital signature. If a packet is not included, the signature may be based on the RIDPolicy class.
RIDシステムを開始したデジタル署名は、XMLデジタル署名を使用してIncissQueryを受信するすべてのシステムに渡されました。パケットが含まれていない場合、署名はRidpolicyクラスに基づいている場合があります。
The proper response to the IncidentQuery message is a Report message. Multiple incidents may be returned for a single query if an incident type is requested. In this case, the receiving system would send an IODEF document containing multiple incidents or all instances of an incident. The system sending the reply may pre-set a limit to the number of documents returned in one report. The recommended limit is 5, to prevent the documents from becoming too large. Other transfer methods may be suited better than RID for large transfers of data. The Confidence rating may be used in the IncidentQuery message to select only incidents with an equal or higher Confidence rating than what is specified. This may be used for cases when information is gathered on a type of incident but not on specifics about a single incident. Source and Destination Information may not be needed if the IncidentQuery is intended to gather data about a specific type of incident as well.
IncissQueryメッセージに対する適切な応答は、レポートメッセージです。インシデントタイプが要求されている場合、単一のクエリに対して複数のインシデントが返される場合があります。この場合、受信システムは、複数のインシデントまたはインシデントのすべてのインスタンスを含むIODEFドキュメントを送信します。返信を送信するシステムは、1つのレポートで返されるドキュメントの数に制限を事前に設定する場合があります。推奨される制限は5です。ドキュメントが大きくなりすぎないようにします。他の転送方法は、大量のデータを削除するよりも適している場合があります。信頼評価は、IncidesQueryメッセージで使用され、指定されているものよりも等しいまたはそれ以上の信頼評価のインシデントのみを選択できます。これは、インシデントの種類で情報が収集されたが、単一のインシデントに関する詳細ではない場合に使用できます。インシデントクエリが特定のタイプのインシデントに関するデータを収集することを意図している場合、ソースおよび宛先情報は必要ない場合があります。
The following section outlines the communication flows for RID and also provides examples of messages. The proper response to a TraceRequest is a RequestAuthorization message. The RequestAuthorization message lets the requestor know if the trace will continue through the next upstream network. If there is a problem with the request, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message MUST be sent to the requestor and the downstream peer (if they are not one and the same) providing the reason why the message could not be processed. Assuming that the trace continued, additional TraceRequests with the response of a RequestAuthorization message would occur passing the request upstream in the path to the source of the traffic related to the incident. Once a source is found, a Result message is sent to the originator of the trace, as determined by the NP path information provided through the document instance of EventData, where contact is set to "infrastructure". The NP path information is also used when sending the RequestAuthorization messages to the first entry (the trace originator) and the last nested entry (the downstream peer). The Result message is encrypted
次のセクションでは、RIDの通信フローの概要を説明し、メッセージの例も提供します。TraceRequestへの適切な応答は、要求の承認メッセージです。RequestAuthorizationメッセージにより、リクエストターは、次のアップストリームネットワークを介してトレースが続くかどうかを知ることができます。デジタル署名の検証やリクエストの復号化など、リクエストに問題がある場合は、リクエストアソート化メッセージをリクエスターとダウンストリームピアに送信する必要があります（それらが1つでない場合）。メッセージを処理できませんでした。トレースが続くと仮定すると、要求の承認メッセージの応答を伴う追加のトレイセレスは、インシデントに関連するトラフィックのソースへのパスの上流のリクエストを通過します。ソースが見つかったら、結果メッセージがトレースの発信元に送信されます。これは、連絡先が「インフラストラクチャ」に設定されているEventDataのドキュメントインスタンスを介して提供されるNPパス情報によって決定されます。NPパス情報は、最初のエントリ（Trace Originator）と最後のネストされたエントリ（下流のピア）にRequestAuthorizationメッセージを送信するときにも使用されます。結果メッセージは暗号化されます
[XMLencrypt] for the originator providing information about the incident source and any actions taken. If the originator fails to decrypt or authenticate the Result message, a RequestAuthorization message is sent in response; otherwise, no return message is sent. If a RequestAuthorization message is sent with the RequestStatus set to Denied, a downstream peer receiving this message may choose to take action to stop or mitigate the traffic at that point in the network, as close to the source as possible. If the downstream peer chooses this option, it would send a Result message to the trace originator.
[xmlencrypt]インシデントソースと取られたアクションに関する情報を提供するオリジナル者のために。オリジネーターが結果メッセージの復号化または認証に失敗した場合、RequestAuthorizationメッセージがそれに応じて送信されます。それ以外の場合、返品メッセージは送信されません。RequestAuthorizationメッセージが拒否されるように設定されたRequestAuthorizationメッセージが送信された場合、このメッセージを受け取る下流のピアが、可能な限りソースに近いネットワーク内のその時点で停止または軽減するためのアクションを実行することを選択できます。ダウンストリームピアがこのオプションを選択した場合、結果メッセージがTrace Originatorに送信されます。
Note: For each example listed below, [RFC5735] addresses were used. Assume that each IP address listed is actually a separate network range held by different NPs. Addresses were used from /27 network ranges.
注：以下にリストする各例で、[RFC5735]アドレスが使用されました。リストされている各IPアドレスは、実際には異なるNPが保持している個別のネットワーク範囲であると仮定します。アドレスは /27ネットワーク範囲から使用されました。
The diagram below outlines the RID TraceRequest communication flow between RID systems on different networks tracing an attack.
以下の図は、攻撃をトレースするさまざまなネットワーク上のRIDシステム間のRID TraceRequest通信フローの概要を示しています。
Attack Dest NP-1 NP-2 NP-3 Attack Src
攻撃Dest NP-1 NP-2 NP-3攻撃SRC
1. Attack | Attack reported | detected
1. 攻撃|攻撃が報告されました|検出されました
2. Initiate trace
2. トレースを開始します
3. Locate origin through upstream NP
3. 上流のNPを介してオリジンを見つけます
4. o---TraceRequest----->
4. o --- tracerequest ----->
5. Trace Initiated
5. トレースが開始されました
6. <-RequestAuthorization-o
6. <-requestauthorization-o
7. Locate origin through upstream NP
7. 上流のNPを介してオリジンを見つけます
8. o---TraceRequest--->
8. o --- tracerequest --->
9. Trace Initiated
9. トレースが開始されました
10. <----------RequestAuthorization----o
<---RequestAuth---o
11. Locate attack source on network X
11. ネットワークxの攻撃ソースを見つけます
12. <------------Result----------------o
Figure 7. TraceRequest Communication Flow
図7. TraceRequest通信フロー
Before a trace is initiated, the RID system should verify if an instance of the trace or a similar request is not active. The traces may be resource intensive; therefore, providers need to be able to detect potential abuse of the system or unintentional resource drains. Information such as the Source and Destination Information, associated packets, and the incident may be desirable to maintain for a period of time determined by administrators.
トレースが開始される前に、RIDシステムは、トレースまたは同様のリクエストのインスタンスがアクティブでないかどうかを確認する必要があります。トレースはリソース集中的なものである可能性があります。したがって、プロバイダーは、システムの潜在的な乱用または意図しないリソース排水を検出できる必要があります。ソースや宛先情報、関連するパケット、インシデントなどの情報は、管理者が決定する期間維持することが望ましい場合があります。
The communication flow demonstrates that a RequestAuthorization message is sent to both the downstream peer and the original requestor. If a TraceRequest is denied, the downstream peer has the option to take an action and respond with a Result message. The originator of the request may follow up with the downstream peer of the NP involved using an Investigation request to ensure that an action is taken if no response is received. Nothing precludes the originator of the request from initiating a new TraceRequest bypassing the NP that denied the request, if a trace is needed beyond that point. Another option may be for the initiator to send an Investigation request to an NP upstream of the NP that denied the request if enough information was gathered to discern the true source of the attack traffic from the incident handling information.
通信フローは、リクエストアソート化メッセージが下流のピアと元のリクエスターの両方に送信されることを示しています。TraceRequestが拒否された場合、下流のピアにはアクションを実行し、結果メッセージで応答するオプションがあります。リクエストの創始者は、調査要求を使用して、回答が受信されない場合にアクションが実行されることを確認するために、NPの下流のピアをフォローアップすることができます。そのポイントを超えてトレースが必要な場合、要求を拒否したNPをバイパスする新しいトレイセレケストを開始することを要求の創始者を排除するものはありません。別のオプションは、イニシエーターが、インシデント処理情報から攻撃トラフィックの真のソースを識別するのに十分な情報が収集された場合、要求を拒否したNPのNPに調査要求をNPに送信することです。
The example listed is of a TraceRequest based on the incident report example from the IODEF document. The RID extension classes were included as appropriate for a TraceRequest message using the RIDPolicy class. The example given is that of a CSIRT reporting a DoS attack in progress to the upstream NP. The request asks the next NP to continue the trace and have the traffic mitigated closer to the source of the traffic.
リストされている例は、IODEFドキュメントのインシデントレポートの例に基づいたTracerequestのものです。RidPolicyクラスを使用したTraceRequestメッセージに適したRID拡張クラスが含まれていました。与えられた例は、上流のNPに進行中のDOS攻撃を報告するCSIRTの例です。この要求は、次のNPにトレースを継続し、トラフィックをトラフィックのソースに近づけるように要求します。
In the following example, use of [XMLsig] to generate digital signatures does not currently provide digest algorithm agility, as [XMLsig] only supports SHA-1. A future version of [XMLsig] may support additional digest algorithms to support digest algorithm agility.
次の例では、[XMLSIG]を生成して[XMLSIG]を使用して、[XMLSIG]はSHA-1のみをサポートするため、Digest Algorithm Agilityは現在提供されていません。[XMLSIG]の将来のバージョンは、Digest Algorithm Agilityをサポートする追加のダイジェストアルゴリズムをサポートする場合があります。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="TraceRequest"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>38765</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2001-09-14T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream NP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
<!-- Digital signature accompanied by above RID and IODEF -->
<Envelope xmlns="urn:envelope"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0">
<iodef:IODEF-Document>
<iodef:Incident>
<iodef:EventData>
<iodef:Record>
<iodef:RecordData>
<iodef:RecordItem type="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
</iodef:Incident>
</iodef:IODEF-Document>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315#WithComments"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm=
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>KiI5+6SnFAs429VNwsoJjHPplmo=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg==
</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j
QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5
Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs
HifTyYdnj+roGzy4o09YntYD8zneQ7lw==</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</Envelope>
The example RequestAuthorization message is in response to the TraceRequest message listed above. The NP that received the request is responding to approve the trace continuance in their network.
requestAuthorizationメッセージの例は、上記のTraceRequestメッセージに応じています。リクエストを受け取ったNPは、ネットワーク内のトレースの継続を承認するために応答しています。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID>
The example Result message is in response to the TraceRequest listed above. This message type only comes after a RequestAuthorization within the TraceRequest flow of messages. It may be a direct response to an Investigation request. This message provides information about the source of the attack and the actions taken to mitigate the traffic.
結果メッセージの例は、上記のTraceRequestに応答します。このメッセージタイプは、メッセージのTraceRequestフロー内での要求の承認の後にのみ発生します。これは、調査リクエストへの直接的な回答かもしれません。このメッセージは、攻撃の原因とトラフィックを軽減するために取られたアクションに関する情報を提供します。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Result"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node>
</iodef-rid:IncidentSource>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Admin-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.3
</iodef:ContactName>
<iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
</iodef:EventData>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>38765</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream NP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-NP3">
CSIRT-FOR-NP3#3291-1
</iodef:IncidentID>
<iodef:Description>
Host rate-limited for 24 hours
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
The diagram below outlines the RID Investigation request communication flow between RID systems on different networks for a security incident with a known source address. The proper response to an Investigation request is a Result message. If there is a problem with the request, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed.
以下の図は、既知のソースアドレスを備えたセキュリティインシデントのために、さまざまなネットワーク上のRIDシステム間のRID調査要求の通信フローの概要を示しています。調査要求に対する適切な応答は、結果メッセージです。デジタル署名の検証やリクエストの復号化など、リクエストに問題がある場合、リクエストアソート化メッセージがリクエスターに送信されます。RequestAuthorizationメッセージは、メッセージを処理できない理由を提供する必要があります。
Attack Dest NP-1 NP-2 Attack Src
攻撃DEST NP-1 NP-2攻撃SRC
1. Attack | Attack reported | detected
1. 攻撃|攻撃が報告されました|検出されました
2. Determine source of security incident
2. セキュリティインシデントのソースを決定します
3. o---Investigation---->
3. o ---調査---->
4. Research incident and determine appropriate actions to take
4. 事件を調査し、適切な行動を決定する
5. <-------Result-------o
Figure 8. Investigation Communication Flow
図8.調査通信フロー
The following example only includes the RID-specific details. The IODEF and security measures are similar to the TraceRequest information, with the exception that the source is known and the receiving RID system is known to be close to the source. The source known is indicated in the IODEF document, which allows for incident sources to be listed as spoofed, if appropriate.
次の例には、RID固有の詳細のみが含まれています。IODEFとセキュリティ対策は、ソースが既知であり、受信RIDシステムがソースに近いことが知られていることを除いて、TraceRequest情報に似ています。既知のソースは、IODEFドキュメントに示されています。これにより、必要に応じて、インシデントソースをスプーフィングとしてリストすることができます。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Investigation"
MsgDestination="SourceOfIncident">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="other">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="recon"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>41421</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>80</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="investigate">
<iodef:Description>
Investigate whether source has been compromised
</iodef:Description>
</iodef:Expectation>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:Description>
Investigation request sent to NP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
The example RequestAuthorization message is in response to the Investigation request listed above. The NP that received the request was unable to validate the digital signature used to authenticate the sending RID system.
requestAuthorizationメッセージの例は、上記の調査要求に応じています。リクエストを受け取ったNPは、送信RIDシステムの認証に使用されるデジタル署名を検証することができませんでした。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="RequestAuthorization"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Denied"
Justification="Authentication"/>
</iodef-rid:RID>
4.5.3. Report Communication
The diagram below outlines the RID Report communication flow between RID systems on different networks.
以下の図は、さまざまなネットワーク上のRIDシステム間のRIDレポート通信フローの概要を示しています。
NP-1 NP-2
NP-1 NP-2
1. Generate incident information and prepare Report message
1. インシデント情報を生成し、レポートメッセージを準備します
2. o-------Report------->
2. o -------レポート------->
3. File report in database
3. データベースのファイルレポート
Figure 9. Report Communication Flow
図9.通信フローを報告します
The Report communication flow is used to provide information on specific incidents detected on the network. Incident information may be shared between CSIRTs or participating RID hosts using this format. When a report is received, the RID system must verify that the report has not already been filed. The incident number and incident data, such as the hexadecimal packet and incident class information, can be used to compare with existing database entries. The Report message typically does not have a response. If there is a problem with the Report message, such as a failure to validate the digital signature [RFC3275] or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed.
レポート通信フローは、ネットワークで検出された特定のインシデントに関する情報を提供するために使用されます。このフォーマットを使用して、CSIRTまたは参加しているRIDホスト間でインシデント情報を共有できます。レポートが受信された場合、RIDシステムは、レポートがまだ提出されていないことを確認する必要があります。16進パケットやインシデントクラス情報などのインシデント番号とインシデントデータを使用して、既存のデータベースエントリと比較できます。レポートメッセージには通常、応答がありません。レポートメッセージに問題がある場合、デジタル署名の検証[RFC3275]やリクエストを復号化するなど、RequestAuthorizationメッセージが要求者に送信されます。RequestAuthorizationメッセージは、メッセージを処理できない理由を提供する必要があります。
The following example only includes the RID-specific details. This report is an unsolicited Report message that includes an IPv4 packet. The IODEF document and digital signature would be similar to the TraceRequest information.
次の例には、RID固有の詳細のみが含まれています。このレポートは、IPv4パケットを含む未承諾レポートメッセージです。IODEFドキュメントとデジタル署名は、TraceRequest情報に似ています。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<!-- IODEF-Document accompanied by the above RID -->
<iodef:IODEF-Document version="1.00"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident restriction="need-to-know" purpose="reporting">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
<iodef:Description>Host illicitly accessed admin account
</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="high" completion="succeeded"
type="admin"/>
<iodef:Confidence rating="high"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>32821</iodef:port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service>
<iodef:port>22</iodef:port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem>
<iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:Description>
Incident report sent to NP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
4.5.4. IncidentQuery Communication Flow
The diagram below outlines the RID IncidentQuery communication flow between RID systems on different networks.
以下の図は、異なるネットワーク上のRIDシステム間のRIDインシデントクエリ通信フローの概要を示しています。
NP-1 NP-2
NP-1 NP-2
1. Generate a request for information on a specific incident number or incident type
1. 特定のインシデント番号またはインシデントタイプに関する情報のリクエストを生成する
2. o---IncidentQuery--->
2. o --- IncissQuery --->
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. インシデント番号またはタイプおよびファイルレポートによるリクエストへの関連レポート。
Figure 10. IncidentQuery Communication Flow
図10.インシデントクエリ通信フロー
The IncidentQuery message communication receives a response of a Report message. If the Report message is empty, the responding host did not have information available to share with the requestor. The incident number and responding RID system, as well as the transport, assist in the association of the request and response since a report can be filed and is not always solicited. If there is a problem with the IncidentQuery message, such as a failure to validate the digital signature or decrypt the request, a RequestAuthorization message is sent to the requestor. The RequestAuthorization message should provide the reason why the message could not be processed.
IncissQueryメッセージ通信は、レポートメッセージの応答を受信します。レポートメッセージが空の場合、応答するホストには、リクエスターと共有できる情報がありませんでした。インシデント番号と応答RIDシステム、およびトランスポートは、レポートを提出することができ、常に勧誘されるとは限らないため、要求と対応の関連付けを支援します。デジタル署名の検証やリクエストの復号化など、IncisityQueryメッセージに問題がある場合、RequestAuthorizationメッセージがリクエスターに送信されます。RequestAuthorizationメッセージは、メッセージを処理できない理由を提供する必要があります。
The IncidentQuery request may be received in several formats as a result of the type of query being performed. If the incident number is the only information provided, the IODEF document and IP packet data may not be needed to complete the request. However, if a type of incident is requested, the incident number remains NULL, and the 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パケット情報を提供し、受信RIDシステムの比較に使用して（a）レポートメッセージを生成できます。
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="IncidentQuery"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#210-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="http://www.iana.org/assignments/xml-registry/
schema/iodef-rid-1.0.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!-- ****************************************************************
*********************************************************************
*** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, August 2006 ***
*** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. ***
*********************************************************************
-->
<!--RID acts as an envelope for IODEF documents to support the exchange
of messages-->
<!--
====== Real-Time Inter-network Defense - RID ======
==== Suggested definition for RID messaging ======
-->
<xs:annotation>
<xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
</xs:annotation>
<xs:element name="RID" type="iodef-rid:RIDType"/>
<xs:complexType name="RIDType">
<xs:sequence>
<xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
<xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
<xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--Used in RequestAuthorization Message for RID-->
<xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>
<xs:complexType name="RequestStatusType">
<xs:attribute name="AuthorizationStatus" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Approved"/>
<xs:enumeration value="Denied"/>
<xs:enumeration value="Pending"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-AuthorizationStatus"
type="xs:string" use="optional"/>
<xs:attribute name="Justification">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="SystemResource"/>
<xs:enumeration value="Authentication"/>
<xs:enumeration value="AuthenticationOrigin"/>
<xs:enumeration value="Encryption"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Justification"
type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<!--Incident Source Information for Result Message-->
<xs:element name="IncidentSource" type="iodef-rid:IncidentSourceType"/>
<xs:complexType name="IncidentSourceType">
<xs:sequence>
<xs:element ref="iodef-rid:SourceFound"/>
<xs:element ref="iodef:Node" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<xs:element name="SourceFound" type="xs:boolean"/>
<!--
====== Real-Time Inter-network Defense Policy - RIDPolicy ======
====== Definition for RIDPolicy for messaging
-->
<xs:annotation>
<xs:documentation>RID Policy used for transport of
messages</xs:documentation>
</xs:annotation>
<!-- RIDPolicy information with setting information listed in RID
documentation -->
<xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>
<xs:complexType name="RIDPolicyType">
<xs:sequence>
<xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
<xs:element ref="iodef:IncidentID" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="MsgType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="TraceRequest"/>
<xs:enumeration value="RequestAuthorization"/>
<xs:enumeration value="Result"/>
<xs:enumeration value="Investigation"/>
<xs:enumeration value="Report"/>
<xs:enumeration value="IncidentQuery"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
<xs:attribute name="MsgDestination" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="RIDSystem"/>
<xs:enumeration value="SourceOfIncident"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgDestination" type="xs:string"
use="optional"/>
</xs:complexType>
<xs:element name="PolicyRegion">
<xs:complexType>
<xs:attribute name="region" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="ClientToNP"/>
<xs:enumeration value="NPToClient"/>
<xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/>
<xs:enumeration value="AcrossNationalBoundaries"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-region"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="TrafficType" default="Attack">
<xs:complexType>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Attack"/>
<xs:enumeration value="Network"/>
<xs:enumeration value="Content"/>
<xs:enumeration value="OfficialBusiness"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
6. Security Considerations
Communication between NPs' RID systems must be protected. RID has many security considerations built into the design of the protocol, several of which are described in the following sub-sections. For a complete view of security, considerations need to include the availability, confidentiality, and integrity concerns for the transport, storage, and exchange of information.
NPSのRIDシステム間の通信は保護する必要があります。RIDには、プロトコルの設計に組み込まれた多くのセキュリティに関する考慮事項があり、そのいくつかは以下のサブセクションで説明されています。セキュリティの完全な見方をするには、考慮事項を含める必要があります。
When considering the transport of RID messages, an out-of-band network, either logical or physical, would prevent outside attacks against RID communication. An out-of-band connection would be ideal, but not necessarily practical. Authenticated encrypted tunnels between RID systems MUST be used to provide confidentiality, integrity, authenticity, and privacy for the data. Trust relationships are based on consortiums and established trust relationships of public key infrastructure (PKI) cross-certifications of consortiums. By using RIDPolicy information, TLS, and the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], RID takes advantage of existing security standards. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized, and that the messages meet policy and privacy guidelines and maintain integrity.
RIDメッセージの輸送を考慮すると、論理的または物理的な帯域外ネットワークが、RID通信に対する外部攻撃を防ぎます。バンド外の接続が理想的ですが、必ずしも実用的ではありません。RIDシステム間の認証された暗号化されたトンネルを使用して、データに機密性、整合性、信頼性、プライバシーを提供する必要があります。信頼関係は、コンソーシアムと公開キーインフラストラクチャ（PKI）の信頼関係に基づいており、コンソーシアムの相互認証があります。Ridpolicy情報、TLS、および暗号化のXMLセキュリティ機能を使用することにより、Digital Signatures [RFC3275]、[XMLSIG]のXMLセキュリティ機能は、RIDが既存のセキュリティ基準を活用します。標準は、メッセージが安全で認証され、承認されていることを保証する明確な方法を提供し、メッセージがポリシーとプライバシーのガイドラインを満たし、整合性を維持することを保証します。
As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] are used in the following cases:
このドキュメントの関連セクションで指定されているように、XMLデジタル署名[RFC3275]およびXML暗号化[XMLENCRYPT]は、次の場合に使用されます。
XML Digital Signature
XMLデジタル署名
o The originator of the TraceRequest or Investigation request MUST use a detached signature to sign at least one of the original IP packets included in the RecordItem class data to provide authentication to all upstream participants in the trace of the origin. All IP packets provided by the originator may be signed, and additional packets added by upstream peers in the trace may be signed by the peer adding the data, while maintaining the IP packet and detached signature from the original requestor. This signature MUST be passed to all recipients of the TraceRequest.
o TraceRequestまたは調査リクエストのオリジネーターは、分離した署名を使用して、RecordItemクラスデータに含まれる元のIPパケットの少なくとも1つに署名して、すべての上流の参加者にオリジンのトレースに認証を提供する必要があります。オリジネーターが提供するすべてのIPパケットに署名され、上流のピアがトレースに追加する追加のパケットは、IPパケットを維持しながら、ピアが元のリクエスト装置からデタッチされた署名を維持しながら、ピアによって署名される場合があります。この署名は、TraceRequestのすべての受信者に渡す必要があります。
o For all message types, the full IODEF/RID document MUST be signed using an enveloped signature by the sending peer to provide authentication and integrity to the receiving RID system.
o すべてのメッセージタイプについて、完全なIODEF/RIDドキュメントは、受信RIDシステムに認証と整合性を提供するために、送信ピアによる封筒の署名を使用して署名する必要があります。
XML Encryption
XML暗号化
o The IODEF/RID document may be encrypted to provide an extra layer of security between peers so that the message is not only encrypted for the transport, but also while stored. This behavior would be agreed upon between peers or a consortium, or determined on a per-message basis, depending on security requirements. It should be noted that there are cases for transport where the RIDPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6046].
o IODEF/RIDドキュメントを暗号化して、ピア間でセキュリティの追加レイヤーを提供する場合があり、メッセージが輸送用に暗号化されるだけでなく、保存中にも暗号化されます。この振る舞いは、ピアまたはコンソーシアムの間で合意されるか、セキュリティ要件に応じて、1人あたりベースで決定されます。輸送文書[RFC6046]に詳述されているように、輸送クラスを明確なテキストで提示する必要がある場合は、輸送の場合があることに注意する必要があります。
o An Investigation request, or any other message type that may be relayed through RID systems other than the intended destination as a result of trust relationships, may be encrypted for the intended recipient. This may be necessary if the RID network is being used for message transfer, the intermediate parties do not need to have knowledge of the request contents, and a direct communication path does not exist. In that case, the RIDPolicy class is used by intermediate parties and is maintained in clear text.
o 調査リクエスト、または信頼関係の結果として意図した目的地以外のRIDシステムを介して中継される可能性のあるその他のメッセージタイプは、意図した受信者のために暗号化される場合があります。これは、RIDネットワークがメッセージ転送に使用されている場合、中間当事者は要求コンテンツの知識を持つ必要がなく、直接通信パスが存在しない場合に必要になる場合があります。その場合、Ridpolicyクラスは中間者によって使用され、明確なテキストで維持されます。
o The action taken in the Result message may be encrypted using the key of the request originator. In that case, the intermediate parties can view the RIDPolicy information and know the trace has been completed and do not need to see the action. If the use of encryption were limited to sections of the message, the History class information would be encrypted. Otherwise, it is RECOMMENDED to encrypt the entire IODEF/RID document, using an enveloped signature, for the originator of the request. The existence of the Result message for an incident would tell any intermediate parties used in the path of the incident investigation that the incident handling has been completed.
o 結果メッセージで実行されるアクションは、リクエストオリジネーターのキーを使用して暗号化される場合があります。その場合、中間当事者はリッピング情報を表示し、トレースが完了したことを知ることができ、アクションを確認する必要はありません。暗号化の使用がメッセージのセクションに制限されていた場合、履歴クラス情報が暗号化されます。それ以外の場合は、リクエストのオリジネーターに対して、封筒の署名を使用して、IODEF/RIDドキュメント全体を暗号化することをお勧めします。インシデントの結果メッセージの存在は、インシデント調査の経路で使用された中間当事者に、インシデント処理が完了したことを伝えるでしょう。
The formation of policies is a very important aspect of using a messaging system like RID to exchange potentially sensitive information. Many considerations should be involved for peering parties, and some guidelines to protect the data, systems, and transport are covered in this section. Policies established should provide guidelines for communication methods, security, and fall-back procedures.
ポリシーの形成は、潜在的に機密情報を交換するために、ridのようなメッセージングシステムを使用することの非常に重要な側面です。ピアリングパーティーには多くの考慮事項が含まれるべきであり、このセクションでは、データ、システム、および輸送を保護するためのいくつかのガイドラインについて説明します。確立されたポリシーは、コミュニケーション方法、セキュリティ、およびフォールバック手順に関するガイドラインを提供する必要があります。
The security considerations for the storage and exchange of information in RID messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect client information during an investigation. RID Policy is a necessary tool for listing the requirements of messages to provide a method to categorize data elements for proper handling. Controls are also provided for the sending entity to protect messages from third parties through XML encryption.
RIDメッセージングにおける情報の保管と交換に関するセキュリティ上の考慮事項には、調査中にクライアント情報を保護する義務に加えて、地域、地域、または国家規制の遵守が含まれる場合があります。RIDポリシーは、適切な処理のためにデータ要素を分類する方法を提供するためのメッセージの要件をリストするための必要なツールです。また、XML暗号化を介してサードパーティからのメッセージを保護するための送信エンティティ向けのコントロールも提供されています。
RID provides a method to exchange incident handling request and Report messages to peer networks. Network administrators, who have the ability to base the decision on the available resources and other factors of their network, maintain control of incident investigations within their own network. Thus, RID provides the ability for participating networks to manage their own security controls, leveraging the information listed in RIDPolicy.
RIDは、インシデント処理要求を交換し、ピアネットワークにメッセージをレポートする方法を提供します。ネットワークの利用可能なリソースやその他の要因に基づいて決定を下すことができるネットワーク管理者は、独自のネットワーク内のインシデント調査の制御を維持します。したがって、RIDは、Ridpolicyにリストされている情報を活用して、参加ネットワークが独自のセキュリティ制御を管理する機能を提供します。
The transport specifications are fully defined in a separate document [RFC6046]. The specified transport protocols MUST use encryption to provide an additional level of security and integrity, while supporting mutual authentication through bi-directional certificate usage. Any subsequent transport method defined should take advantage of existing standards for ease of implementation and integration of RID systems. Session encryption for the transport of RID messages is enforced in the transport specification. The privacy and security considerations are addressed fully in RID to protect sensitive portions of documents and provide a method to authenticate the messages. Therefore, RID messages do not rely on the security provided by the transport layer alone. The encryption requirements and considerations for RID are discussed at the beginning of Section 6 of this document.
輸送仕様は、別のドキュメント[RFC6046]で完全に定義されています。指定された輸送プロトコルは、暗号化を使用して追加のレベルのセキュリティと整合性を提供する必要があり、双方向の証明書の使用を通じて相互認証をサポートする必要があります。定義された後続の輸送方法は、RIDシステムの実装と統合の容易さのために既存の標準を活用する必要があります。RIDメッセージの輸送用のセッション暗号化は、輸送仕様で実施されます。プライバシーとセキュリティの考慮事項は、ドキュメントの機密部分を保護し、メッセージを認証する方法を提供するために、RIDで完全に対処されます。したがって、RIDメッセージは、輸送層のみが提供するセキュリティに依存しません。RIDの暗号化の要件と考慮事項については、このドキュメントのセクション6の開始について説明します。
XML security functions such as the digital signature [RFC3275] and encryption [XMLencrypt] provide a standards-based method to encrypt and digitally sign RID messages. RID messages specify system use and privacy guidelines through the RIDPolicy class. A public key infrastructure (PKI) provides the base for authentication and authorization, encryption, and digital signatures to establish trust relationships between members of a RID consortium or a peering consortium.
デジタル署名[RFC3275]や暗号化[XMLENCRYPT]などのXMLセキュリティ関数は、RIDメッセージを暗号化およびデジタル署名する標準ベースの方法を提供します。RIDメッセージは、Ridpolicyクラスを通じてシステムの使用とプライバシーガイドラインを指定します。公開キーインフラストラクチャ（PKI）は、RIDコンソーシアムまたはピアリングコンソーシアムのメンバー間の信頼関係を確立するための認証と承認、暗号化、およびデジタル署名のベースを提供します。
XML security functions such as the digital signature [RFC3275] and encryption [XMLencrypt] can be used within the contents of the message for privacy and security in cases for which certain elements must remain encrypted or signed as they traverse the path of a trace. For example, the digital signature on a TraceRequest can be used to verify the identity of the trace originator. The use of the XML security features in RID messaging is in accordance with the specifications for the IODEF model; however, the use requirements may differ since RID also incorporates communication of security incident information.
デジタル署名[RFC3275]や暗号化[XMLENCRYPT]などのXMLセキュリティ関数は、特定の要素がトレースの経路を通過するときに暗号化または署名されたままでなければならない場合に、プライバシーとセキュリティのメッセージの内容内で使用できます。たとえば、TraceRequestのデジタル署名を使用して、トレースオリジネーターのIDを検証できます。RIDメッセージングでのXMLセキュリティ機能の使用は、IODEFモデルの仕様に従っています。ただし、REDにはセキュリティインシデント情報の通信も組み込まれているため、使用要件は異なる場合があります。
The RID protocol must be able to guarantee delivery and meet the necessary security requirements of a state-of-the-art protocol. In order to guarantee delivery, TCP should be considered as the underlying protocol within the current network standard practices.
RIDプロトコルは、配信を保証し、最先端のプロトコルの必要なセキュリティ要件を満たすことができなければなりません。配信を保証するために、TCPは現在のネットワーク標準プラクティス内の基礎となるプロトコルと見なされるべきです。
Security considerations must include the integrity, authentication, privacy, and authorization of the messages sent between RID communication systems or IHSs. The communication between RID systems must be authenticated and encrypted to ensure the integrity of the messages and the RID systems involved in the trace. Another concern that needs to be addressed is authentication for a request that traverses multiple networks. In this scenario, systems in the path of the multi-hop TraceRequest need to authorize a trace from not only their neighbor network, but also from the initiating RID system as discussed in Section 6.4. Several methods can be used to ensure integrity and privacy of the communication.
セキュリティ上の考慮事項には、RID通信システムまたはIHSSの間で送信されたメッセージの整合性、認証、プライバシー、および許可を含める必要があります。RIDシステム間の通信を認証および暗号化する必要があります。これは、メッセージの整合性とトレースに含まれるRIDシステムを確保する必要があります。対処する必要があるもう1つの懸念は、複数のネットワークを通過するリクエストに対する認証です。このシナリオでは、マルチホップTraceRequestのパスにあるシステムは、近隣ネットワークだけでなく、セクション6.4で説明したように、開始RIDシステムからのトレースを承認する必要があります。コミュニケーションの完全性とプライバシーを確保するために、いくつかの方法を使用できます。
The transport mechanism selected MUST follow the defined transport protocol [RFC6046] when using RID messaging to ensure consistency among the peers. Consortiums may vary their selected transport mechanisms and thus must decide upon a mutual protocol to use for transport when communicating with peers in a neighboring consortium using RID. RID systems MUST implement and deploy HTTPS as defined in the transport document [RFC6046] and optionally support other protocols such as the Blocks Extensible Exchange Protocol (BEEP). RID, the XML security functions, and transport protocols must properly integrate with a public key infrastructure (PKI) managed by the consortium or one managed by a trusted entity. For the Internet, an example of an existing effort that could be leveraged to provide the supporting PKI could be the American Registry for Internet Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI hierarchy. Security and privacy considerations related to consortiums are discussed in Sections 6.5 and 6.6.
選択された輸送メカニズムは、RIDメッセージングを使用してピア間の一貫性を確保する場合、定義された輸送プロトコル[RFC6046]に従う必要があります。コンソーシアムは、選択された輸送メカニズムを異なる場合があるため、RIDを使用して近隣のコンソーシアムのピアと通信する際に、輸送に使用するための相互プロトコルを決定する必要があります。RIDシステムは、トランスポートドキュメント[RFC6046]で定義されているようにHTTPSを実装および展開し、オプションでブロック拡張可能な交換プロトコル（BEEP）などの他のプロトコルをサポートする必要があります。XMLセキュリティ関数、および輸送プロトコルは、コンソーシアムが管理する公開キーインフラストラクチャ（PKI）または信頼できるエンティティが管理する公開キーインフラストラクチャ（PKI）と適切に統合する必要があります。インターネットの場合、サポートPKIを提供するために活用できる既存の取り組みの例は、インターネット番号（ARIN）のアメリカのレジストリと地域のインターネット登録登録簿（RIR）PKI階層です。コンソーシアムに関連するセキュリティとプライバシーの考慮事項については、セクション6.5および6.6で説明します。
Out-of-band communications dedicated to NP interaction for RID messaging would provide additional security as well as guaranteed bandwidth during a denial-of-service attack. For example, an out-of-band channel may consist of logical paths defined over the existing network. Out-of-band communications may not be possible between all network providers, but should be considered to protect the network management systems used for RID messaging. Methods to protect the data transport may also be provided through session encryption.
RIDメッセージング用のNP相互作用に特化したバンド外通信は、サービス拒否攻撃中に追加のセキュリティと保証された帯域幅を提供します。たとえば、バンド外チャネルは、既存のネットワーク上で定義された論理パスで構成されている場合があります。すべてのネットワークプロバイダー間で帯域外の通信は不可能かもしれませんが、RIDメッセージングに使用されるネットワーク管理システムを保護するために考慮する必要があります。データ輸送を保護する方法は、セッション暗号化を介して提供される場合があります。
In order to address the integrity and authenticity of messages, transport encryption MUST be used to secure the traffic sent between RID systems. Systems with predefined relationships for RID would include those who peer within a consortium with agreed-upon appropriate use regulations and for peering consortiums. Trust relationships may also be defined through a bridged or hierarchical PKI in which both peers belong.
メッセージの整合性と信頼性に対処するには、輸送暗号化を使用して、RIDシステム間で送信されるトラフィックを保護する必要があります。RIDの事前定義された関係を持つシステムには、合意された適切な使用規制と皮をむいたコンソーシアムを備えたコンソーシアム内で覗く人が含まれます。信頼関係は、両方のピアが属する橋渡しまたは階層的なPKIを介して定義される場合があります。
Systems used to send authenticated RID messages between networks MUST use a secured system and interface to connect to a border network's RID systems. Each connection to a RID system MUST meet the security requirements agreed upon through the consortium regulations, peering, or SLAs. The RID system MUST only listen for and send RID messages on the designated port, which also MUST be over an encrypted tunnel meeting the minimum requirement of algorithms and key lengths established by the consortium, peering, or SLA. The selected cryptographic algorithms for symmetric encryption, digital signatures, and hash functions MUST meet minimum security levels of the times. The encryption strength MUST adhere to import and export regulations of the involved countries for data exchange.
ネットワーク間で認証されたRIDメッセージを送信するために使用されるシステムは、セキュリティ済みのシステムとインターフェイスを使用して、Border NetworkのRIDシステムに接続する必要があります。RIDシステムへの各接続は、コンソーシアム規制、ピアリング、またはSLAを通じて合意されたセキュリティ要件を満たす必要があります。RIDシステムは、指定されたポートでRIDメッセージをリッスンして送信する必要があります。これは、コンソーシアム、ピアリング、またはSLAによって確立されたアルゴリズムの最小要件とキー長の要件を満たす暗号化されたトンネルを超えている必要があります。対称暗号化、デジタル署名、およびハッシュ関数のための選択された暗号化アルゴリズムは、時間の最小セキュリティレベルを満たす必要があります。暗号化強度は、データ交換のために、関係国の規制を輸入および輸出することを遵守する必要があります。
In order to ensure the authenticity of the RID messages, a message authentication scheme is used to secure the protocol. XML security functions utilized in RID require a trust center such as a PKI for the distribution of credentials to provide the necessary level of security for this protocol. Layered transport protocols also utilize encryption and rely on a trust center. Public key certificate pairs issued by a trusted Certification Authority (CA) MAY be used to provide the necessary level of authentication and encryption for the RID protocol. The CA used for RID messaging must be trusted by all involved parties and may take advantage of similar efforts, such as the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI to network providers. The PKI used for authentication would also provide the necessary certificates needed for encryption used for the RID transport protocol [RFC6046].
RIDメッセージの信頼性を確保するために、メッセージ認証スキームを使用してプロトコルを保護します。RIDで利用されるXMLセキュリティ関数には、このプロトコルに必要なレベルのセキュリティを提供するために、資格情報の分布のためにPKIなどの信託センターが必要です。階層化された輸送プロトコルは、暗号化を利用し、信託センターに依存します。信頼できる認証機関（CA）によって発行された公開鍵の証明書ペアを使用して、RIDプロトコルに必要なレベルの認証と暗号化を提供することができます。RIDメッセージングに使用されるCAは、すべての関係者によって信頼されている必要があり、インターネット2フェデレートPKIやARIN/RIRの取り組みなど、ネットワークプロバイダーにPKIを提供する同様の努力を利用することができます。認証に使用されるPKIは、RID輸送プロトコル[RFC6046]に使用される暗号化に必要な必要な証明書も提供します。
The use of pre-shared keys may be considered for authentication. If this option is selected, the specifications set forth in "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST be followed.
事前に共有キーの使用は、認証のために考慮される場合があります。このオプションが選択されている場合、「輸送層セキュリティ（TLS）の事前に共有キー暗号網」に記載されている仕様[RFC4279]に従う必要があります。
Hosts receiving a RID message MUST be able to verify that the sender of the request is valid and trusted. Using digital signatures on a hash of the RID message with an X.509 version 3 certificate issued by a trusted party MUST be used to authenticate the request. The X.509 version 3 specifications as well as the digital signature specifications and path validation standards set forth in [RFC5280] MUST be followed in order to interoperate with a PKI designed for similar purposes. The IODEF specification MUST be followed for digital signatures to provide the authentication and integrity aspects required for secure messaging between network providers. The use of digital signatures in RID XML messages MUST follow the World Wide Web Consortium (W3C) recommendations for signature syntax and processing when either the XML encryption [XMLencrypt] or digital signature [XMLsig], [RFC3275] is used within a document. Transport specifications are detailed in a separate document [RFC6046].
RIDメッセージを受信するホストは、リクエストの送信者が有効で信頼されていることを確認できる必要があります。信頼できる当事者によって発行されたX.509バージョン3証明書を使用して、RIDメッセージのハッシュにデジタル署名を使用することを使用して、リクエストを認証する必要があります。X.509バージョン3の仕様と、[RFC5280]に記載されているデジタル署名仕様とパス検証標準に従って、同様の目的で設計されたPKIと相互運用する必要があります。IODEF仕様には、ネットワークプロバイダー間の安全なメッセージングに必要な認証と整合性の側面を提供するために、IODEF仕様に従う必要があります。XML暗号化[XMLENCRYPT]またはデジタル署名[XMLSIG]、[RFC3275]、[RFC3275]、[RFC3275]のいずれかがドキュメント内で使用される場合、署名の構文と処理に関するWorld Wide Webコンソーシアム（W3C）の推奨事項に従う必要があります。輸送仕様は、別のドキュメント[RFC6046]で詳しく説明されています。
It might be helpful to define an extension to the authentication scheme that uses attribute certificates [RFC5755] in such a way that an application could automatically determine whether human intervention is needed to authorize a request; however, the specification of such an extension is out of scope for this document.
リクエストを承認するために人間の介入が必要かどうかをアプリケーションが自動的に判断できるように、属性証明書[RFC5755]を使用する認証スキームの拡張機能を定義することが役立つ場合があります。ただし、このような拡張機能の仕様は、このドキュメントの範囲外です。
Bilateral trust relations between network providers ensure the authenticity of requests for TraceRequests from immediate peers in the web of networks formed to provide the traceback capability. A network provider several hops into the path of the RID trace must trust the information from its own trust relationships as well as the previous trust relationships in the downstream path. For practical reasons, the NPs may want to prioritize incident handling events based upon the immediate peer for a TraceRequest, the originator, and the listed Confidence rating for the incident. In order to provide a higher assurance level of the authenticity of the TraceRequest, the originating RID system is included in the TraceRequest along with contact information and the information of all RID systems in the path the trace has taken. This information is provided through the IODEF EventData class nesting the list of systems and contacts involved in a trace, while setting the category attribute to "infrastructure".
ネットワークプロバイダー間の二国間信頼関係は、トレースバック機能を提供するために形成されたネットワークのWebの即時仲間からのトレースレクエストの要求の信頼性を確保します。ネットワークプロバイダーは、RIDトレースのパスへのいくつかのホップが、それ自体の信頼関係からの情報と、下流のパスでの以前の信頼関係から信頼する必要があります。実際的な理由から、NPSは、TraceRequest、Originator、およびインシデントのリストされた信頼評価のための即時のピアに基づいて、インシデント処理イベントに優先順位を付けたい場合があります。TraceRequestの信頼性のより高い保証レベルを提供するために、TraceRequestには、連絡先情報と、トレースが取ったパス内のすべてのRIDシステムの情報とともにTracereQuestに含まれています。この情報は、「インフラストラクチャ」にカテゴリ属性を設定しながら、トレースに関与するシステムと連絡先のリストをネストするIODEF EventDataクラスを通じて提供されます。
A second measure MUST be taken to ensure the identity of the originating RID system. The originating RID system MUST include a digital signature in the TraceRequest sent to all systems in the upstream path. The digital signature from the RID system is performed on the RecordItem class of the IODEF following the XML digital signature specifications from W3C [XMLsig] using a detached signature. The signature MUST be passed to all parties that receive a TraceRequest, and each party MUST be able to perform full path validation on the digital signature. Full path validation verifies the chaining relationship to a trusted root and also performs a certificate revocation check. In order to accommodate that requirement, the IP packet in the RecordItem data MUST remain unchanged as a request is passed along between providers and is the only element for which the signature is applied. If additional packets are included in the document at upstream peers, the initial packet MUST still remain with the detached signature. The subsequent packets may be signed by the peer adding the incident information for the investigation. A second benefit to this requirement is that the integrity of the filter used is ensured as it is passed to subsequent NPs in the upstream trace of the packet. The trusted PKI also provides the keys used to digitally sign the RecordItem class for TraceRequests to meet the requirement of authenticating the original request. Any host in the path of the trace should be able to verify the digital signature using the trusted PKI.
発信元のRIDシステムのアイデンティティを確保するために、2番目の測定値を取る必要があります。起源のRIDシステムには、上流パスのすべてのシステムに送信されるTracereQuestにデジタル署名を含める必要があります。RIDシステムからのデジタル署名は、Depched Signatureを使用してW3C [XMLSIG]からのXMLデジタル署名仕様に続くIODEFのRecordITEMクラスで実行されます。署名は、TraceRequestを受け取るすべての関係者に渡す必要があり、各当事者はデジタル署名でフルパス検証を実行できる必要があります。フルパス検証は、信頼できるルートとのチェーン関係を検証し、証明書の取り消しチェックも実行します。その要件に対応するために、記録データのIPパケットは、プロバイダー間でリクエストが渡され、署名が適用される唯一の要素であるため、変更されていないままでなければなりません。アップストリームピアのドキュメントに追加のパケットが含まれている場合、最初のパケットはまだ分離された署名にとどまる必要があります。後続のパケットは、調査のためにインシデント情報を追加するピアによって署名される場合があります。この要件の2番目の利点は、パケットの上流トレースでその後のNPに渡されると、使用されるフィルターの整合性が確保されることです。また、信頼できるPKIは、元のリクエストを認証する要件を満たすために、TraceRequestsのRecordItemクラスにデジタル的に署名するために使用されるキーを提供します。トレースのパスにあるホストは、信頼できるPKIを使用してデジタル署名を検証できる必要があります。
In the case in which an enterprise network using RID sends a TraceRequest to its provider, the signature from the enterprise network MUST be included in the initial request. The NP may generate a new request to send upstream to members of the NP consortium to continue the trace. If the original request is sent, the originating NP, acting on behalf of the enterprise network under attack, MUST also digitally sign, with an enveloped signature, the full IODEF document to assure the authenticity of the TraceRequest. An NP that offers RID as a service may be using its own PKI to secure RID communications between its RID system and the attached enterprise networks. NPs participating in the trace MUST be able to determine the authenticity of RID requests.
RIDを使用したエンタープライズネットワークがTracerequestをプロバイダーに送信する場合、エンタープライズネットワークからの署名を最初の要求に含める必要があります。NPは、NPコンソーシアムのメンバーにアップストリームを送信して、トレースを継続するという新しいリクエストを生成する場合があります。元のリクエストが送信された場合、攻撃中のエンタープライズネットワークに代わって行動する発信元のNPは、封筒の署名である完全なIODEFドキュメントでデジタル的に署名する必要があります。サービスとしてRIDを提供するNPは、独自のPKIを使用して、RIDシステムと添付のエンタープライズネットワーク間のRID通信を保護する場合があります。トレースに参加するNPは、RIDリクエストの信頼性を決定できる必要があります。
Consortiums of NPs are an ideal way to establish a communication web of trust for RID messaging. The consortium could provide centralized resources, such as a PKI, and established guidelines for use of the RID protocol. The consortium would also assist in establishing trust relationships between the participating NPs to achieve the necessary level of cooperation and experience-sharing among the consortium entities. This may be established through PKI certificate policy [RFC3647] reviews to determine the appropriate trust levels between organizations or entities. The consortium may also be used for other purposes to better facilitate communication among NPs in a common area (Internet, region, government, education, private networks, etc.).
NPSのコンソーシアムは、RIDメッセージングのための信頼のコミュニケーションウェブを確立する理想的な方法です。コンソーシアムは、PKIなどの集中リソースを提供し、RIDプロトコルを使用するための確立されたガイドラインを提供できます。コンソーシアムはまた、参加しているNP間の信頼関係を確立して、コンソーシアムエンティティ間の必要なレベルの協力と経験共有を達成するのに役立ちます。これは、PKI証明書ポリシー[RFC3647]レビューを通じて確立され、組織またはエンティティ間の適切な信頼レベルを決定することができます。コンソーシアムは、他の目的にも使用され、共通エリア（インターネット、地域、政府、教育、民間ネットワークなど）のNP間のコミュニケーションをより促進することもできます。
Using a PKI to distribute certificates used by RID systems provides an already established method to link trust relationships between NPs of consortiums that would peer with NPs belonging to a separate consortium. In other words, consortiums could peer with other consortiums to enable communication of RID messages between the participating NPs. The PKI along with Memorandums of Agreement could be used to link border directories to share public key information in a bridge, a hierarchy, or a single cross-certification relationship.
PKIを使用してRIDシステムで使用される証明書を配布すると、別のコンソーシアムに属するNPと覗くコンソーシアムのNP間の信頼関係をリンクするためのすでに確立された方法が提供されます。言い換えれば、コンソーシアムは他のコンソーシアムと覗き込んで、参加しているNP間のRIDメッセージのコミュニケーションを可能にすることができます。PKIは、覚書と同意の覚書を使用して、ボーダーディレクトリをリンクして、橋の公開情報、階層、または単一の相互認定関係を共有することができます。
Consortiums also need to establish guidelines for each participating NP to adhere to. The RECOMMENDED guidelines include:
コンソーシアムは、参加している各NPが順守するためのガイドラインを確立する必要もあります。推奨されるガイドラインには以下が含まれます。
o Physical and logical practices to protect RID systems;
o RIDシステムを保護するための物理的および論理的実践。
o Network and application layer protection for RID systems and communications;
o RIDシステムと通信のためのネットワークおよびアプリケーション層の保護。
o Proper use guidelines for RID systems, messages, and requests; and
o RIDシステム、メッセージ、およびリクエストの適切な使用ガイドライン。と
o A PKI to provide authentication, integrity, and privacy.
o 認証、整合性、プライバシーを提供するPKI。
The functions described for a consortium's role would parallel that of a PKI federation. The PKI federations that currently exist are responsible for establishing security guidelines and PKI trust models. The trust models are used to support applications to share information using trusted methods and protocols.
コンソーシアムの役割について説明した機能は、PKI連合の役割と並行します。現在存在するPKI連合は、セキュリティガイドラインとPKIトラストモデルの確立に責任があります。信頼モデルは、信頼できる方法とプロトコルを使用して情報を共有するためのアプリケーションをサポートするために使用されます。
A PKI can also provide the same level of security for communication between an end entity (enterprise, educational, or government customer network) and the NP. The PKI may be a subordinate CA or in the CA hierarchy from the NP's consortium to establish the trust relationships necessary as the request is made to other connected networks.
PKIは、最終エンティティ（企業、教育、または政府の顧客ネットワーク）とNPとの間のコミュニケーションに同じレベルのセキュリティを提供することもできます。PKIは、他の接続されたネットワークにリクエストが行われるにつれて必要な信頼関係を確立するために、NPのコンソーシアムのCA階層にある下位CAまたはCA階層にある場合があります。
Privacy issues raise many concerns when information-sharing is required to achieve the goal of stopping or mitigating the effects of a security incident. The RIDPolicy class is used to automate the enforcement of the privacy concerns listed within this document. The privacy and system use concerns that MUST be addressed in the RID system and other integrated components include the following:
プライバシーの問題は、セキュリティインシデントの影響を停止または緩和するという目標を達成するために情報共有が必要な場合、多くの懸念を引き起こします。Ridpolicyクラスは、このドキュメントにリストされているプライバシーの懸念の施行を自動化するために使用されます。プライバシーとシステムは、RIDシステムおよびその他の統合コンポーネントで対処する必要がある懸念を使用します。
Network Provider Concerns:
ネットワークプロバイダーの懸念：
o Privacy of data monitored and/or stored on IDSs for attack detection.
o 攻撃検出のためにIDSSに監視および/または保存されたデータのプライバシー。
o Privacy of data monitored and stored on systems used to trace traffic across a single network.
o 単一のネットワーク全体のトラフィックを追跡するために使用されるシステムに監視および保存されたデータのプライバシー。
Customer Attached Networks Participating in RID with NP:
NPでRIDに参加している顧客添付ネットワーク：
o Customer networks may include an enterprise, educational, government, or other attached networks to an NP participating in RID and MUST be made fully aware of the security and privacy considerations for using RID.
o 顧客ネットワークには、RIDに参加するNPへの企業、教育、政府、またはその他の添付ネットワークが含まれる場合があり、RIDを使用するためのセキュリティとプライバシーの考慮事項を完全に認識する必要があります。
o Customers MUST know the security and privacy considerations in place by their NP and the consortium of which the NP is a member.
o 顧客は、NPとNPがメンバーであるコンソーシアムにより、セキュリティとプライバシーの考慮事項を実施する必要があります。
o Customers MUST understand that their data can and will be sent to other NPs in order to complete a trace unless an agreement stating otherwise is made in the service level agreements between the customer and NP.
o 顧客は、顧客とNPの間のサービスレベル契約で特に契約が行われない限り、トレースを完了するために、データが他のNPに送信され、他のNPに送信されることを理解する必要があります。
Parties Involved in the Attack:
攻撃に関与する当事者：
o Privacy of the identity of a host involved in an attack.
o 攻撃に関与するホストのアイデンティティのプライバシー。
o Privacy of information such as the source and destination used for communication purposes over the monitored or RID connected network(s).
o 監視またはRID接続ネットワーク上の通信目的で使用されるソースや目的地などの情報のプライバシー。
o Protection of data from being viewed by intermediate parties in the path of an Investigation request MUST be considered.
o 調査要求の道における中間当事者によって見られることからのデータの保護を考慮する必要があります。
Consortium Considerations:
コンソーシアムの考慮事項：
o System use restricted to security incident handling within the local region's definitions of appropriate traffic for the network monitored and linked via RID in a single consortium also abiding by the consortium's use guidelines.
o コンソーシアムの使用ガイドラインを順守する単一のコンソーシアムでRIDを介して監視およびリンクされたネットワークの適切なトラフィックの地域地域の定義内でのセキュリティインシデント処理に制限されたシステムの使用。
o System use prohibiting the consortium's participating NPs from inappropriately tracing non-attack traffic to locate sources or mitigate traffic unlawfully within the jurisdiction or region.
o コンソーシアムの参加NPが不適切に非攻撃トラフィックを追跡してソースを見つけたり、管轄権または地域内でトラフィックを違法に緩和することを禁止するシステムの使用。
Inter-Consortium Considerations:
コンソーシア間の考慮事項：
o System use between peering consortiums MUST also adhere to any government communication regulations that apply between those two regions, such as encryption export and import restrictions. This may include consortiums that are categorized as "BetweenConsortiums" or "AcrossNationalBoundaries".
o ピアリングコンソーシアム間のシステムの使用は、暗号化の輸出や輸入制限など、これら2つの地域間に適用される政府のコミュニケーション規制を遵守する必要があります。これには、「betweenconsortiums」または「国家国家」に分類されるコンソーシアムが含まれる場合があります。
o System use between consortiums MUST NOT request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements.
o コンソーシアム間のシステムの使用は、法律またはコンソーシアム間契約によって意図および許可されている範囲を超えて、トラフィックトレースとアクションを要求してはなりません。
o System use between consortiums classified as "AcrossNationalBoundaries" MUST respect national boundary issues and limit requests to appropriate system use and not to achieve their own agenda to limit or restrict traffic that is otherwise permitted within the country in which the peering consortium resides.
o 「全国的債券」に分類されたコンソーシアム間のシステムの使用は、国家境界の問題を尊重し、適切なシステムの使用への要求を制限し、ピアリングコンソーシアムが存在する国内で許可されているトラフィックを制限または制限する独自のアジェンダを達成する必要はありません。
The security and privacy considerations listed above are for the consortiums, NPs, and enterprises to agree upon. The agreed-upon policies may be facilitated through use of the RIDPolicy class. Some privacy considerations are addressed through the RID guidelines for encryption and digital signatures as described at the beginning of Section 6.
上記のセキュリティとプライバシーの考慮事項は、コンソーシアム、NPS、および企業が同意することです。合意されたポリシーは、Ridpolicyクラスを使用することにより促進される場合があります。いくつかのプライバシーに関する考慮事項は、セクション6の開始で説明されているように、暗号化とデジタル署名に関するRIDガイドラインを通じて対処されています。
RID is useful in determining the true source of a packet that traverses multiple networks or to communicate security incidents and automate the response. The information obtained from the trace may determine the identity of the source host or the network provider used by the source of the traffic. It should be noted that the trace mechanism used across a single-network provider may also raise privacy concerns for the clients of the network. Methods that may raise concern include those that involve storing packets for some length of time in order to trace packets after the fact. Monitoring networks for intrusions and for tracing capabilities also raises concerns for potentially sensitive valid traffic that may be traversing the monitored network. IDSs and single-network tracing are outside of the scope of this document, but the concern should be noted and addressed within the use guidelines of the network. Some IDSs and single-network trace mechanisms attempt to properly address these issues. RID is designed to provide the information needed by any single-network trace mechanism. The provider's choice of a single trace mechanism depends on resources, existing solutions, and local legislation. Privacy concerns in regard to the single-network trace must be dealt with at the client-to-NP level and are out of scope for RID messaging.
RIDは、複数のネットワークを通過するパケットの真のソースを決定したり、セキュリティインシデントを通信して応答を自動化するのに役立ちます。トレースから取得した情報は、トラフィックのソースで使用されるソースホストまたはネットワークプロバイダーのIDを決定する場合があります。単一ネットワークプロバイダー全体で使用されるトレースメカニズムは、ネットワークのクライアントにプライバシーの懸念を引き起こす可能性があることに注意する必要があります。懸念を引き起こす可能性のある方法には、事実の後にパケットを追跡するために、ある程度の長さのパケットを保存することを含むものが含まれます。侵入やトレース機能の監視ネットワークは、監視されているネットワークを通過する可能性のある潜在的に敏感な有効なトラフィックに対する懸念をもたらします。IDSSと単一ネットワークのトレースは、このドキュメントの範囲外ですが、ネットワークの使用ガイドライン内で懸念を記録し、対処する必要があります。一部のIDSSおよび単一ネットワークトレースメカニズムは、これらの問題に適切に対処しようとします。RIDは、単一ネットワークのトレースメカニズムに必要な情報を提供するように設計されています。単一のトレースメカニズムのプロバイダーの選択は、リソース、既存のソリューション、およびローカル法に依存します。単一ネットワークのトレースに関するプライバシーの懸念は、クライアントからNPレベルで対処する必要があり、RIDメッセージングの範囲外です。
The identity of the true source of an attack packet being traced through RID could be sensitive. The true identity listed in a Result message can be protected through the use of encryption [XMLencrypt] enveloping the IODEF document and RID Result information, using the public encryption key of the originating NP. Alternatively, the action taken may be listed without the identity being revealed to the originating NP. The ultimate goal of the RID communication system is to stop or mitigate attack traffic, not to ensure that the identity of the attack traffic is known to involved parties. The NP that identifies the source should deal directly with the involved parties and proper authorities in order to determine the guidelines for the release of such information, if it is regarded as sensitive. In some 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を通してトレースされている攻撃パケットの真のソースのアイデンティティは、敏感になる可能性があります。結果メッセージにリストされている真のアイデンティティは、暗号化[XMLENCRYPT]を使用してIODEFドキュメントを包み込み、結果情報をRIDすることで保護できます。あるいは、採用されたアクションは、IDが発生するNPに明らかにされることなくリストされる場合があります。RID通信システムの究極の目標は、攻撃トラフィックを停止または軽減することであり、攻撃トラフィックの身元が関係者に対して知られていることを保証することではありません。情報源を特定するNPは、そのような情報のリリースのガイドラインを敏感であると見なされる場合、関係者および適切な当局と直接対処する必要があります。状況によっては、攻撃で使用されるシステムは未知のソースによって危険にさらされ、他のシステムを攻撃するために使用されます。そのような状況では、ビジネスまたは組織の評判が危機にatしている可能性があり、結果メッセージで報告された唯一の追加情報である可能性があります。セキュリティインシデントが、大規模なDDOS攻撃の一部で使用されるゾンビシステムなどの軽微なインシデントである場合、修正されるまでシステムが十分になるまでネットワークから外れていることを確認してください。この決定は、システムユーザーとコンソーシアムに委ねられ、適切なデータを適切な技術オプションを提供するための適切な技術オプションを提供することであることを考慮して、共有される適切なデータを決定します。テキストの説明には、知らない攻撃者の評判を保護し、追加の調査の必要性を防ぐために、事件の詳細を含める必要があります。地方、州、または国の法律は、特定のセキュリティインシデントに対する適切な報告訴訟を決定する場合があります。
Privacy becomes an issue whenever sensitive data traverses a network. For example, if an attack occurred between a specific source and destination, then every network provider in the path of the trace would become aware that the cyber attack occurred. In a targeted attack, it may not be desirable that information about two nation states that are battling a cyber war would become general knowledge to all intermediate parties. However, it is important to allow the traces to take place in order to halt the activity since the health of the networks in the path could also be at stake during the attack. This provides a second argument for allowing the Result message to only include an action taken and not the identity of the offending host. In the case of an Investigation request, where the originating NP is aware of the NP that will receive the request for processing, the free-form text areas of the document could be encrypted [XMLencrypt] using the public key of the destination NP to ensure that no other NP in the path can read the contents. The encryption would be accomplished through the W3C [XMLencrypt] specification for encrypting an element.
機密データがネットワークを横断するたびに、プライバシーが問題になります。たとえば、特定のソースと宛先の間で攻撃が発生した場合、トレースのパスにあるすべてのネットワークプロバイダーは、サイバー攻撃が発生したことに気付くようになります。ターゲットを絞った攻撃では、サイバー戦争と戦っている2つの国家に関する情報がすべての中間当事者にとって一般的な知識になることは望ましくないかもしれません。ただし、パス内のネットワークの健康状態も攻撃中に危険にさらされる可能性があるため、アクティビティを停止するために痕跡を行うことが重要です。これは、結果メッセージに、問題のあるホストの身元ではなく、撮影されたアクションのみを含めるようにするための2番目の引数を提供します。調査要求の場合、NPが処理のリクエストを受け取るNPを認識している場合、ドキュメントのフリーフォームテキスト領域は、宛先NPの公開鍵を使用して[XMLENCRYPT]暗号化して、確実に暗号化できます。パス内の他のNPが内容を読み取ることができないこと。暗号化は、要素を暗号化するためのW3C [XMLENCRYPT]仕様を介して達成されます。
In some situations, all network traffic of a nation may be granted through a single network provider. In that situation, options must support sending Result messages from a downstream peer of that network provider. That option provides an additional level of abstraction to hide the identity and the NP of the identified source of the traffic. Legal action may override this technical decision after the trace has taken place, but that is out of the technical scope of this document.
状況によっては、国のすべてのネットワークトラフィックは、単一のネットワークプロバイダーを通じて付与される場合があります。そのような状況では、オプションはそのネットワークプロバイダーの下流のピアから結果メッセージの送信をサポートする必要があります。そのオプションは、識別されたトラフィックのソースのIDとNPを隠すための追加レベルの抽象化を提供します。法的措置は、トレースが行われた後にこの技術的決定を無効にする可能性がありますが、それはこの文書の技術的範囲から外れています。
Privacy concerns when using an Investigation request to request action close to the source of valid attack traffic needs to be considered. Although the intermediate NPs may relay the request if there is no direct trust relationship to the closest NP to the source, the intermediate NPs do not require the ability to see the contents of the packet or the text description field(s) in the request. This message type does not require any action by the intermediate RID systems, except to relay the packet to the next NP in the path. Therefore, the contents of the request may be encrypted for the destination system. The intermediate NPs would only need to know how to direct the request to the manager of the ASN in which the source IP address belongs.
プライバシーの懸念は、有効な攻撃トラフィックのソースに近いアクションを要求するために調査リクエストを使用する場合の懸念を考慮する必要があります。中間NPは、ソースに最も近いNPとの直接的な信頼関係がない場合、リクエストを中継する場合がありますが、中間NPは、リクエストでパケットまたはテキスト説明フィールドを見る機能を必要としません。このメッセージタイプは、パスのパスの次のNPにパケットを中継することを除いて、中間RIDシステムによるアクションを必要としません。したがって、リクエストの内容は、宛先システム用に暗号化される場合があります。中間NPは、ソースIPアドレスが属するASNのマネージャーにリクエストを指示する方法を知る必要があります。
Traces must be legitimate security-related incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system would include a request to block or rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business.
痕跡は、妨害や検閲などの目的には使用されていない正当なセキュリティ関連のインシデントでなければなりません。このようなシステムの不正行為の例には、インターネット上のユーザー間で情報が共有されるのを防ぐための正当なトラフィックをブロックまたはレートに制限する要求が含まれます（オンラインバージョンの論文へのアクセスを制限する）または競合他社の製品からのアクセスを制限するためにビジネスを妨害します。
Intra-consortium RID communications raise additional issues, especially when the peering consortiums reside in different regions or nations. TraceRequests and requested actions to mitigate traffic must adhere to the appropriate use guidelines and yet prevent abuse of the system. First, the peering consortiums MUST identify the types of traffic that can be traced between the borders of the participating NPs of each consortium. The traffic traced should be limited to security-incident-related traffic. Second, the traces permitted within one consortium if passed to a peering consortium may infringe upon the peering consortium's freedom of information laws. An example would be a consortium in one country permitting a trace of traffic containing objectionable material, outlawed within that country. The RID trace may be a valid use of the system within the confines of that country's network border; however, it may not be permitted to continue across network boundaries where such content is permitted under law. By continuing the trace in another country's network, the trace and response could have the effect of improperly restricting access to data. A continued trace into a second country may break the laws and regulations of that nation. Any such traces MUST cease at the country's border.
特にピアリングコンソーシアムがさまざまな地域や国に存在する場合、Consortium Intry RID Communicationsは追加の問題を提起します。トラフィックを緩和するためのトレーセレケストと要求されたアクションは、適切な使用ガイドラインに準拠している必要がありますが、システムの乱用を防ぐ必要があります。第一に、ピアリングコンソーシアムは、各コンソーシアムの参加NPの境界の間に追跡できるトラフィックの種類を特定する必要があります。トレースされたトラフィックは、セキュリティに関連するトラフィックに限定する必要があります。第二に、ピアリングコンソーシアムに渡された場合、1つのコンソーシアム内で許可されている痕跡は、ピアリングコンソーシアムの情報公開法を侵害する可能性があります。例は、その国内で禁止されている、好ましくない資料を含む交通の痕跡を許可する1つの国のコンソーシアムです。RIDトレースは、その国のネットワーク国境の範囲内のシステムの有効な使用である可能性があります。ただし、法律の下でそのようなコンテンツが許可されているネットワーク境界を越えて継続することは許可されない場合があります。他の国のネットワークのトレースを継続することにより、トレースと応答は、データへのアクセスを不適切に制限する効果をもたらす可能性があります。第二国への継続的な痕跡は、その国の法律と規制を破るかもしれません。そのような痕跡は、国の国境で止まらなければなりません。
The privacy concerns listed in this section address issues among the trusted parties involved in a trace within an NP, a RID consortium, and peering RID consortiums. Data used for RID communications must also be protected from parties that are not trusted. This protection is provided through the authentication and encryption of documents as they traverse the path of trusted servers. Each RID system MUST perform a bi-directional authentication when sending a RID message and use the public encryption key of the upstream or downstream peer to send a message or document over the network. This means that the document is decrypted and re-encrypted at each RID system via TLS over the transport protocol [RFC6046]. The RID messages may be decrypted at each RID system in order to properly process the request or relay the information. Today's processing power is more than sufficient to handle the minimal burden of encrypting and decrypting relatively small typical RID messages.
このセクションに記載されているプライバシーの懸念は、NP、Rid Consortium、Peering Ridコンソーシアム内の痕跡に関与する信頼できる当事者の問題に対処しています。RID通信に使用されるデータは、信頼されていない当事者からも保護する必要があります。この保護は、信頼できるサーバーの経路を横断する際のドキュメントの認証と暗号化を通じて提供されます。各RIDシステムは、RIDメッセージを送信するときに双方向認証を実行し、上流または下流のピアのパブリック暗号化キーを使用して、ネットワーク上にメッセージまたはドキュメントを送信する必要があります。これは、ドキュメントが輸送プロトコル[RFC6046]を介してTLSを介して各RIDシステムで復号化され、再クリックされることを意味します。RIDメッセージは、要求を適切に処理するか、情報をリレーするために、各RIDシステムで復号化される場合があります。今日の処理能力は、暗号化と比較的小さな典型的なRIDメッセージの最小限の負担を処理するのに十分すぎるほどです。
This document uses URNs to describe XML namespaces and XML schemas [XMLschema] conforming to a registry mechanism described in [RFC3688].
このドキュメントでは、urnsを使用して、XMLネームスペースとXMLスキーマ[XMLSchema]を記述し、[RFC3688]に記載されているレジストリメカニズムに準拠しています。
Registration request for the iodef-rid namespace:
iodef-ridネームスペースの登録リクエスト：
URI: urn:ietf:params:xml:ns:iodef-rid-1.0
Registrant Contact: See the "Author's Address" section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: None. Namespace URIs do not represent an XML specification.
XML：なし。名前空間URIはXML仕様を表していません。
Registration request for the iodef-rid XML schema:
IODEF-RID XMLスキーマの登録リクエスト：
URI: urn:ietf:params:xml:schema:iodef-rid-1.0
Registrant Contact: See the "Author's Address" section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: See Section 5, "RID Schema Definition", of this document.
XML：このドキュメントのセクション5「RIDスキーマ定義」を参照してください。
Security incidents have always been difficult to trace as a result of the spoofed sources, resource limitations, and bandwidth utilization problems. Incident response is often slow even when the IP address is known to be valid because of the resources required to notify the responsible party of the attack and then to stop or mitigate the attack traffic. Methods to identify and trace attacks near real time are essential to thwarting attack attempts. Network providers need policies and automated methods to combat the hacker's efforts. NPs need automated monitoring and response capabilities to identify and trace attacks quickly without resource-intensive side effects. Integration with a centralized communication system to coordinate the detection, tracing, and identification of attack sources on a single network is essential. RID provides a way to integrate NP resources for each aspect of attack detection, tracing, and source identification and extends the communication capabilities among network providers. The communication is accomplished through the use of flexible IODEF XML-based documents passed between IHSs or RID systems. A TraceRequest or Investigation request is communicated to an upstream NP and may result in an upstream trace or in an action to stop or mitigate the attack traffic. The messages are communicated among peers with security inherent to the RID messaging scheme provided through existing standards such as XML encryption and digital signatures. Policy information is carried in the RID message itself through the use of the RIDPolicy. RID provides the timely communication among NPs, which is essential for incident handling.
セキュリティインシデントは、スプーフィングされたソース、リソースの制限、帯域幅の利用の問題の結果として、常に追跡するのが困難でした。攻撃の責任者に通知し、攻撃トラフィックを停止または軽減するために必要なリソースのためにIPアドレスが有効であることが知られている場合でも、インシデント応答が遅くなることがよくあります。攻撃をリアルタイムに近づけて追跡する方法は、攻撃の試みを妨害するために不可欠です。ネットワークプロバイダーは、ハッカーの取り組みに対抗するためのポリシーと自動化された方法が必要です。NPは、リソース集約的な副作用なしに攻撃を迅速に識別および追跡するための自動監視と応答機能が必要です。単一のネットワーク上の攻撃ソースの検出、追跡、および識別を調整するための集中通信システムとの統合が不可欠です。RIDは、攻撃検出、トレース、ソースの識別の各側面にNPリソースを統合する方法を提供し、ネットワークプロバイダー間の通信機能を拡張します。通信は、IHSSまたはRIDシステム間で渡された柔軟なIODEF XMLベースのドキュメントを使用することで達成されます。TraceRequestまたは調査のリクエストは、上流のNPに通知され、上流のトレースまたは攻撃トラフィックを停止または軽減するアクションにつながる可能性があります。メッセージは、XML暗号化やデジタル署名などの既存の標準を通じて提供されるRIDメッセージングスキームに固有のセキュリティを持つピア間で伝えられます。ポリシー情報は、Ridpolicyを使用してRIDメッセージ自体に伝えられます。RIDは、NP間のタイムリーな通信を提供します。これは、インシデント処理に不可欠です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、RFC 3275、2002年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279] Eronen、P.、ed。、およびH. Tschofenig、ed。、「輸送層セキュリティのための事前共有キーシファースーツ（TLS）」、RFC 4279、2005年12月。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070] Danyliw、R.、Meijer、J。、およびY. Demchenko、「インシデントオブジェクト説明交換形式」、RFC 5070、2007年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5755] Farrell、S.、Housley、R。、およびS. Turner、「認証のためのインターネット属性証明書プロファイル」、RFC 5755、2010年1月。
[RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-Time Inter-Network Defense (RID) Messages," RFC 6046, November 2010.
[RFC6046] Moriarty、K。およびB. Trammell、「リアルタイム間のネットワーク間防衛（RID）メッセージの輸送」、RFC 6046、2010年11月。
[XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)". W3C Recommendation. T. Bray, E. Maler, J. Paoli, and C.M. Sperberg-McQueen. October 2000. http://www.w3.org/TR/2000/REC-xml-20001006.
[XML1.0]「拡張可能なマークアップ言語（XML）1.0（第2版）」。W3Cの推奨。T.ブレイ、E。マラー、J。パオリ、およびC.M.Sperberg-mcqueen。2000年10月。http：//www.w3.org/tr/2000/rec-xml-20001006。
[XMLnames] "Namespaces in XML 1.0 (Third Edition)". W3C Recommendation. T. Bray, D. Hollander, A. Layman, R. Tobin, H. Thompson. December 2009. http://www.w3.org/TR/REC-xml-names/.
[XMLNames]「XML 1.0の名前空間（第3版）」。W3Cの推奨。T.ブレイ、D。ホランダー、A。レイマン、R。トービン、H。トンプソン。2009年12月。http：//www.w3.org/tr/rec-xml-names/。
[XMLencrypt] "XML Encryption Syntax and Processing". W3C Recommendation. T. Imamura, B. Dillaway, and E. Simon. December 2002. http://www.w3.org/TR/xmlenc-core/.
[XMLENCRYPT]「XML暗号化構文と処理」。W3Cの推奨。T.イマムラ、B。ディラウェイ、E。サイモン。2002年12月。http：//www.w3.org/tr/xmlenc-core/。
[XMLschema] "XML Schema". E. Van der Vlist. O'Reilly. 2002.
[xmlschema] "xml schema"。E. van der Vlist。オライリー。2002年。
[XMLsig] "XML-Signature Syntax and Processing (Second Edition)". W3C Recommendation. M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon. June 2008. http://www.w3.org/TR/xmldsig-core/#sec-Design.
[XMLSIG]「XML-Signature構文と処理（第2版）」。W3Cの推奨。M.バルテル、J。ボイヤー、B。フォックス、B。ラマッキア、E。サイモン。2008年6月。http：//www.w3.org/tr/xmldsig-core/#sec-design。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930] Hawkinson、J。およびT. Bates、「自律システムの作成、選択、登録に関するガイドライン（AS）」、BCP 6、RFC 1930、1996年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C。、およびS. Wu、「インターネットX.509公開キーインフラストラクチャ証明書ポリシーと認証慣行フレームワーク」、RFC 3647、2003年11月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[IPtrace] "Advanced and Authenticated Marking Schemes for IP Traceback". D. Song and A. Perrig. IEEE INFOCOM 2001.
[IPTrace]「IP Traceback用の高度で認証されたマーキングスキーム」。D.ソングとA.ペリグ。IEEE INFOCOM 2001。
[HASH-IPtrace] "Hash-Based IP Traceback". A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, S. Kent, and W. Strayer. SIGCOMM'01. August 2001.
[Hash-Iprace]「ハッシュベースのIPトレースバック」。A. Snoeren、C。Partridge、L。Sanchez、C。Jones、F。Tchakountio、S。Kent、およびW. Strayer。Sigcomm'01。2001年8月。
[ICMPtrace] Bellovin, S., Leech, M., and T. Taylor, "ICMP Traceback Messages", Work in Progress, February 2003.
[ICMPTRACE] Bellovin、S.、Leech、M。、およびT. Taylor、「ICMP Tracebackメッセージ」、2003年2月、Work in Progress。
[NTWK-IPtrace] "Practical network support for IP traceback". S. Savage, D. Wetherall, A. Karlin, and T. Anderson. SIGCOMM'00. August 2000.
[NTWK-IPTRACE]「IP Tracebackの実用的なネットワークサポート」。S.サベージ、D。ウェザル、A。カーリン、T。アンダーソン。sigcomm'00。2000年8月。
[DoS] "Trends in Denial of Service Attack Technology". K. Houle, G. Weaver, N. Long, and R. Thomas. CERT Coordination Center. October 2001.
[DOS]「サービス拒否攻撃技術の傾向」。K. Houle、G。Weaver、N。Long、およびR. Thomas。証明書調整センター。2001年10月。
Acknowledgements
謝辞
Many thanks to coworkers and the Internet community for reviewing and commenting on the document as well as providing recommendations to simplify and secure the protocol: Robert K. Cunningham, Ph.D, Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, and Sandra G. Dykes, Ph.D.
ドキュメントをレビューしてコメントし、プロトコルを簡素化および保護するための推奨事項を提供してくれた同僚とインターネットコミュニティに感謝します：Robert K. Cunningham、Ph.D、Cynthia D. Mclain、Dr。WilliamStreilein、Iljitsch Van Beijnum、スティーブ・ベロビン、ユーリ・デムチェンコ、ジャン・フランソワ・モーフィン、スティーブン・ノースカット、ジェフリー・シラー、ブライアン・トゥルメル、ローマン・ダニリウ、トニー・タウバー、サンドラ・G・ダイクス博士
Sponsor Information
スポンサー情報
This work was sponsored by the Air Force under Air Force Contract FA8721-05-C-0002, while working at MIT Lincoln Laboratory.
この作業は、MITリンカーン研究所で働いている間、空軍契約FA8721-05-C-0002の下で空軍によって後援されました。
"Opinions, interpretations, conclusions, and recommendations are those of the author and are not necessarily endorsed by the United States Government".
「意見、解釈、結論、勧告は著者のものであり、必ずしも米国政府によって承認されているわけではありません」。
Author's Address
著者の連絡先
Kathleen M. Moriarty RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 US
Kathleen M. Moriarty RSA、EMCのセキュリティ部門174 Middlesex Turnpike Bedford、MA 01730 US
EMail: Moriarty_Kathleen@EMC.com