Network Working Group B. Feinstein
Request for Comments: 4767 SecureWorks, Inc.
Category: Experimental G. Matthews
CSC/NASA Ames Research Center
March 2007
The Intrusion Detection Exchange Protocol (IDXP)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF.
このメモは、侵入検知交換プロトコル（IDXP）、侵入検知エンティティ間でデータを交換するためのアプリケーションレベルのプロトコルを記述する。 IDXPはコネクション指向のプロトコルを介して相互認証、整合性、および機密性をサポートしています。プロトコルはIDMEFメッセージ、非構造化テキスト、およびバイナリデータの交換を提供します。 IDMEFメッセージ要素はRFC 4765に記述されている、「侵入検知メッセージ交換フォーマット（IDMEF）」、IETFの侵入検知交換フォーマットワーキンググループ（IDWG）の仲間ドキュメント。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Purpose ....................................................3
1.2. Profiles ...................................................3
1.3. Terminology ................................................3
2. The Model .......................................................4
2.1. Connection Provisioning ....................................4
2.2. Data Transfer ..............................................6
2.3. Connection Teardown ........................................7
2.4. Trust Model ................................................8
3. The IDXP Profile ................................................8
3.1. IDXP Profile Overview ......................................8
3.2. IDXP Profile Identification and Initialization .............9
3.3. IDXP Profile Message Syntax ................................9
3.4. IDXP Profile Semantics .....................................9
3.4.1. The IDXP-Greeting Element ..........................10
3.4.2. The Option Element .................................11
3.4.3. The IDMEF-Message Element ..........................12
4. IDXP Options ...................................................12
4.1. The channelPriority Option ................................13
4.2. The streamType Option .....................................14
5. Fulfillment of IDWG Communications Protocol Requirements .......16
5.1. Reliable Message Transmission .............................16
5.2. Interaction with Firewalls ................................16
5.3. Mutual Authentication .....................................16
5.4. Message Confidentiality ...................................17
5.5. Message Integrity .........................................17
5.6. Per-Source Authentication .................................17
5.7. Denial of Service .........................................18
5.8. Message Duplication .......................................18
6. Extending IDXP .................................................18
7. IDXP Option Registration Template ..............................19
8. Initial Registrations ..........................................19
8.1. Registration: The IDXP Profile ............................19
8.2. Registration: The System (Well-Known) TCP Port
Number for IDXP ...........................................19
8.3. Registration: The channelPriority Option ..................20
8.4. Registration: The streamType Option .......................20
9. The DTDs .......................................................20
9.1. The IDXP DTD ..............................................20
9.2. The channelPriority Option DTD ............................22
9.3. The streamType DTD ........................................23
10. Reply Codes ...................................................24
11. Security Considerations .......................................25
11.1. Use of the TUNNEL Profile ................................25
11.2. Use of Underlying Security Profiles ......................25
12. IANA Considerations ...........................................25
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................26
14. Acknowledgements ..............................................26
IDXP is specified, in part, as a Blocks Extensible Exchange Protocol (BEEP) [4] "profile". BEEP is a generic application protocol framework for connection-oriented, asynchronous interactions. Features such as authentication and confidentiality are provided through the use of other BEEP profiles. Accordingly, many aspects of IDXP (e.g., confidentiality) are provided within the BEEP framework.
IDXP、ブロック拡張交換プロトコル（BEEP）[4]「プロファイル」として、部分的には、指定されています。 BEEPは、コネクション型、非同期相互作用のための汎用アプリケーション・プロトコル・フレームワークです。認証や機密性などの機能は、他のBEEPプロファイルの使用を通じて提供されます。従って、IDXP（例えば、機密性）の多くの側面は、BEEPフレームワーク内に設けられています。
IDXP provides for the exchange of IDMEF [2] messages, unstructured text, and binary data between intrusion detection entities. Addressing the security-sensitive nature of exchanges between intrusion detection entities, underlying BEEP security profiles should be used to offer IDXP the required set of security properties. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements. See Section 11 for a discussion of security considerations.
IDXPはIDMEF [2]のメッセージ、非構造化テキスト、および侵入検知エンティティ間のバイナリデータの交換を提供します。 BEEPセキュリティプロファイルがIDXPにセキュリティプロパティの必要なセットを提供するために使用されるべき基礎となる、侵入検知エンティティ間の交換のセキュリティに敏感な性質に対処します。 IDXPがIDWG通信プロトコルの要件を満たす方法についての説明は、第5章を参照してください。セキュリティの考慮事項の議論については、セクション11を参照してください。
IDXP is primarily intended for the exchange of data created by intrusion detection entities. IDMEF [2] messages should be used for the structured representation of this intrusion detection data, although IDXP may be used to exchange unstructured text and binary data.
IDXPは、主に、侵入検知エンティティによって作成されたデータの交換を目的としています。 IDXPは、非構造化テキストおよびバイナリデータを交換するために使用することができるIDMEF [2]メッセージは、この侵入検出データの構造化表現に使用されるべきです。
There are several BEEP profiles discussed, the first of which we define in this memo:
議論し、いくつかのBEEPプロフィール、我々はこのメモで定義された最初のがあります。
The IDXP Profile
IDXPプロフィール
The TUNNEL Profile [3]
TUNNELプロフィール[3]
The Simple Authentication and Security Layer (SASL) Family of Profiles (see Section 4.1 of [4])
簡易認証セキュリティー層プロファイルの（SASL）ファミリー（[4]のセクション4.1を参照してください）
The TLS Profile (see Section 3.1 of [4])
TLSプロファイル（セクション3.1 [4]を参照）
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 BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
Throughout this memo, the terms "analyzer" and "manager" are used in the context of the Intrusion Detection Message Exchange Requirements [5]. In particular, Section 2.2 of [5] defines a collection of intrusion detection terms.
このメモ全体を通して、用語「アナライザ」および「管理」は、[5]侵入検知メッセージ交換要件の文脈で使用されます。特に、セクション2.2 [5]侵入検知用語の集合を定義します。
The terms "peer", "initiator", "listener", "client", and "server", and the characters "I", "L", "C", and "S" are used in the context of BEEP [4]. In particular, Section 2.1 of BEEP discusses the roles that a BEEP peer may perform.
用語「ピア」、「開始」、「リスナー」、「クライアント」および「サーバ」、及び文字「I」、「L」、「C」、および「S」は[BEEPの文脈で使用されています4]。具体的には、BEEPのセクション2.1は、BEEPピアが実行することができる役割を論じています。
The term "Document Type Definition" is abbreviated as "DTD" and is defined in Section 2.8 of the Extensible Markup Language (XML) [7].
用語「文書型定義」が「DTD」と略記されており、拡張マークアップ言語（XML）の2.8節で定義されている[7]。
Note that the term "proxy" is specific to IDXP and does not exist in the context of BEEP. The term "intrusion detection" is abbreviated as "ID".
用語「プロキシ」はIDXPに固有のものであり、BEEPのコンテキスト内に存在しないことに注意してください。用語「侵入検知」を「ID」と略記されます。
Intrusion detection entities using IDXP to transfer data are termed IDXP peers. Peers can exist only in pairs, and these pairs communicate over a single BEEP session with one or more BEEP channels opened for transferring data. Peers are either managers or analyzers, as defined in Section 2.2 of [5].
データを転送するIDXPを使用して侵入検知エンティティはIDXPピアと呼ばれています。ピアはペアでのみ存在することができ、そしてこれらの対は、一つ以上のBEEPチャネルを有する単一BEEPセッションを介して通信データを転送するために開かれました。 [5]のセクション2.2で定義されるようにピアが、管理者又はアナライザのいずれかです。
The relationship between analyzers and managers is potentially many-to-many. That is, an analyzer MAY communicate with many managers; similarly, a manager MAY communicate with many analyzers. Likewise, the relationship between different managers is potentially many-to-many, so that a manager MAY receive the alerts sent by a large number of analyzers by receiving them through intermediate managers. Analyzers MUST NOT establish IDXP exchanges with other analyzers.
アナライザや経営者との間の関係は、潜在的に多対多です。つまり、アナライザは、多くの管理者と通信することができます。同様に、管理者は、多くのアナライザと通信することができます。マネージャは、中間マネージャを介してそれらを受信することにより、分析装置の大多数によって送信されたアラートを受信できるように、同様に、異なる管理者の関係は、潜在的に多対多です。アナライザは、他のアナライザとIDXP交換を確立してはなりません。
An IDXP peer wishing to establish IDXP communications with another IDXP peer does so by opening a BEEP channel, which may entail initiating a BEEP session. A BEEP security profile offering the required security properties SHOULD initially be negotiated (see Section 11 for a discussion of security considerations). Following the successful negotiation of the BEEP security profile, IDXP greetings are exchanged and connection provisioning proceeds.
別のIDXPピアとIDXP通信を確立することを望むIDXPピアがBEEPセッションを開始伴い得るBEEPチャネルを開くことによってそうします。必要なセキュリティプロパティを提供BEEPセキュリティプロファイルは、最初に交渉されるべきである（セキュリティ上の考慮事項についての説明は、セクション11を参照）。 BEEPセキュリティプロファイルの成功の交渉の後、IDXPの挨拶を交換し、接続のプロビジョニングが進行しています。
In the following sequence, the peer 'Alice' initiates an IDXP exchange with the peer 'Bob'.
以下の配列において、ピアは「アリス」は、ピア 'ボブとIDXP交換を開始します。
Alice Bob
---------------- xport connect(1) ------------------>
<-------------------- greeting ---------------------->
<-------------start security profile(2) ------------->
<-------------------- greeting ---------------------->
<------------------ start IDXP(3) ------------------->
Notes:
ノート：
(1) 'Alice' initiates a transport connection to 'Bob', triggering the exchange of BEEP greeting messages.
（1）「アリスは」BEEPグリーティングメッセージの交換をトリガする、「ボブ」へのトランスポート接続を開始します。
(2) Both entities negotiate the use of a BEEP security profile.
（2）両方のエンティティは、BEEPセキュリティプロファイルの使用を交渉します。
(3) Both entities negotiate the use of the IDXP profile.
（3）両方のエンティティはIDXPプロファイルの使用を交渉します。
In between a pair of IDXP peers may be an arbitrary number of proxies. A proxy may be necessary for administrative reasons, such as running on a firewall to allow restricted access. Another use might be one proxy per company department, which forwards data from the analyzer peers in the department onto a company-wide manager peer.
IDXPピアの対の間でプロキシの任意の数であってもよいです。プロキシは、このような制限されたアクセスを許可するようにファイアウォール上で実行されているなどの管理上の理由のために必要があるかもしれません。別の用途では、全社的な管理ピアに部門のアナライザピアからデータを転送し、会社の部門ごとに、プロキシ、かもしれません。
A BEEP tuning profile MAY be used to create an application-layer tunnel that transparently forwards data over a chain of proxies. The TUNNEL profile [3] SHOULD be used for this purpose; see [3] for more detail concerning the options available to set up an application-layer tunnel using TUNNEL, and see Section 11.1 for a discussion of TUNNEL-related security considerations. TUNNEL MUST be offered as a tuning profile for the creation of application-layer tunnels. The TUNNEL profile MUST offer the use of some form of SASL authentication (see Section 4.1 of [4]). Once a tunnel has been created, a BEEP security profile offering the required security properties SHOULD be negotiated, followed by negotiation of the IDXP profile.
BEEPチューニングプロファイルは透過プロキシのチェーンを介してデータを転送するアプリケーション層のトンネルを作成するために使用され得ます。 TUNNELプロファイルは、[3]この目的のために使用されるべきです。トンネルを使用して、アプリケーション層のトンネルを設定するために利用可能なオプションに関する詳細については[3]を参照し、トンネル関連のセキュリティ問題の議論については、セクション11.1を参照してください。トンネルは、アプリケーション層のトンネルを作成するためのチューニングプロファイルとして提供されなければなりません。 TUNNELプロファイルはSASL認証の何らかの形（[4]のセクション4.1を参照）の使用を提供しなければなりません。トンネルが作成されたら、必要なセキュリティの特性を提供するBEEPセキュリティプロファイルはIDXPプロファイルの交渉が続き、交渉されるべきです。
The following sequence shows how TUNNEL might be used to create an application-layer tunnel through which IDXP would operate. A peer 'Alice' initiates the creation of a BEEP session using the IDXP profile with the entity 'Bob' by first contacting 'proxy1'. In the greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is selected, and subsequently the use of the TUNNEL profile is extended to reach through 'proxy2' to 'Bob'.
以下のシーケンスは、トンネルIDXPが動作する、それを通してアプリケーション層のトンネルを作成するために使用する方法を示しています。ピア・アリスは、「最初の「PROXY1」を接触させることによって、エンティティ 'ボブとIDXPプロファイルを使用してBEEPセッションの作成を開始します。 「アリス」と「PROXY1」との間の挨拶交換では、トンネルプロファイルが選択され、そしてその後TUNNELプロファイルの使用は、「ボブ」に「PROXY2」を介して到達するように拡張されます。
Alice proxy1 proxy2 Bob
-- xport connect -->
<---- greeting ----->
-- start TUNNEL --->
- xport connect(1) ->
<----- greeting ----->
--- start TUNNEL --->
--- xport connect -->
<----- greeting ----->
--- start TUNNEL --->
<----- <ok>(2) ------
<------- <ok> -------
<------ <ok> -------
<------------------------- greeting -------------------------->
<------------------ start security profile ------------------->
<------------------------- greeting -------------------------->
<------------------------ start IDXP ------------------------->
Notes:
ノート：
(1) Instead of immediately acknowledging the request from 'Alice' to start TUNNEL, 'proxy1' attempts to establish use of TUNNEL with 'proxy2'. 'proxy2' also delays its acknowledgment to 'proxy1'.
（1）の代わりに、すぐにトンネルを開始するために「アリスからの要求を認めると、「PROXY1」「はPROXY2」とのトンネルの使用を確立しようと試みます。 「PROXY2」も「PROXY1」にその確認応答を遅らせます。
(2) 'Bob' acknowledges the request from 'proxy2' to start TUNNEL, and this acknowledgment propagates back to 'Alice' so that a TUNNEL application-layer tunnel is established from 'Alice' to 'Bob'.
（2）「ボブ」はトンネルを開始するために「PROXY2」からの要求を確認し、この確認応答は、トンネルアプリケーション層のトンネルが「ボブ」に「アリスから確立されるように、「アリス」に戻って伝播します。
Between a pair of ID entities communicating over a BEEP session, one or more BEEP channels MAY be opened using the IDXP profile. If desired, additional BEEP sessions MAY be established to offer additional channels using the IDXP profile. However, in most situations additional channels using the IDXP profile SHOULD be opened within an existing BEEP session, as opposed to provisioning a new BEEP session containing the additional channels using the IDXP profile.
BEEPセッションを介して通信IDエンティティのペアの間、一つ以上のBEEPチャンネルがIDXPプロファイルを使用して開くことができます。必要に応じて、追加のBEEPセッションはIDXPプロファイルを使用して追加のチャネルを提供するために確立することができます。 IDXPプロファイルを使用して追加のチャネルを含む新しいBEEPセッションのプロビジョニングとは対照的に、しかし、ほとんどの状況でIDXPプロファイルを使用して、追加のチャネルは、既存のBEEPセッション内で開かれるべきです。
Peers assume the role of client or server on a per-channel basis, with one acting as the client and the other as the server. A peer's role of client or server is determined independent of whether the peer assumed the role of initiator or listener during the BEEP session establishment. Clients and servers act as sources and sinks, respectively, for exchanging data.
ピアは1つのクライアントとして動作し、サーバなどの他に、チャネルごとにクライアントまたはサーバの役割を担います。クライアントまたはサーバーのピアの役割は、ピアがBEEPセッションの確立時に、イニシエータまたはリスナーの役割を引き受けたかどうかの決定は無関係です。クライアントとサーバーは、データを交換するために、それぞれ、ソースとシンクとして機能します。
In a simple case, an analyzer peer sends data to a manager peer. For example,
単純なケースでは、アナライザピアが管理ピアにデータを送信します。例えば、
+----------+ +----------+
| | | |
| |****** BEEP session ******| |
| | | |
| Analyzer | ----- IDXP profile ----> | Manager |
| (Client) | | (Server) |
| | | |
| |**************************| |
| | | |
+----------+ +----------+
Use of multiple BEEP channels in a BEEP session facilitates categorization and prioritization of data sent between IDXP peers. For example, a manager 'M1', sending alert data to another manager, 'M2', may choose to open a separate channel to exchange different categories of alerts. 'M1' would act as the client on each of these channels, and manager 'M2' can then process and act on the incoming alerts based on their respective channel categorizations. See Section 4 for more detail on how to incorporate categorization and/or prioritization into channel creation.
BEEPセッションに複数のBEEPチャンネルの使用はIDXPピア間で送信されるデータの分類と優先順位付けを容易にします。例えば、別のマネージャ、「M2」に警告データを送信マネージャ「M1」は、アラートの異なるカテゴリを交換するために別個のチャネルを開くことを選択することができます。 「M1」は、これらのチャネルの各々にクライアントとして作用する、およびマネージャ「M2」は、プロセスおよびそれらのそれぞれのチャネル分類に基づいて、着信通知に作用することができます。チャネルの作成に分類および/または優先順位付けを組み込む方法についての詳細は第4章を参照してください。
+----------+ +----------+
| | | |
| |*************** BEEP session ***************| |
| | | |
| | -- IDXP profile, network-based alerts ---> | |
| Manager | | Manager |
| M1 | ---- IDXP profile, host-based alerts ----> | M2 |
| (Client) | | (Server) |
| | ------ IDXP profile, other alerts -------> | |
| | | |
| |********************************************| |
| | | |
+----------+ +----------+
An IDXP peer may choose to close an IDXP channel under many different circumstances (e.g., an error in processing has occurred). To close a channel, the peer sends a "close" element (see Section 2.3.1.3 of [4]) on channel zero indicating which channel is being closed. An IDXP peer may also choose to close an entire BEEP session by sending a "close" element indicating that channel zero is to be closed.
IDXPピアは、多くの異なる状況下でIDXPチャネルを閉鎖することを選択することができる（例えば、処理中にエラーが発生しました）。チャネルを閉じるために、ピアは、「クローズ」要素を閉鎖されているチャネルを示すチャネル上でゼロ（[4]のセクション2.3.1.3を参照）を送信します。 IDXPピアは、チャネルゼロ閉鎖されるべきであることを示す「クローズ」要素を送信することによって、全体BEEPセッションを終了することを選択することができます。
Section 2.3.1.3 of [4] offers a more complete discussion of the circumstances under which a BEEP peer is permitted to close a channel and the mechanisms for doing so.
[4]のセクション2.3.1.3は、BEEPピアがそうするためのチャネルおよび機構を閉鎖することを許可される状況のより完全な説明を提供します。
It is anticipated that due to the overhead of provisioning an application-layer tunnel and/or a BEEP security profile, BEEP sessions containing IDXP channels will be long-lived. In addition, the repeated overhead of IDXP channel provisioning (i.e., the exchange of IDXP greetings) may be avoided by keeping IDXP channels open even while data is not actively being exchanged on them. These are recommendations and, as such, IDXP peers may choose to close and re-provision BEEP sessions and/or IDXP channels as they see fit.
それにより、アプリケーション層のトンネルおよび/またはBEEPセキュリティプロファイルをプロビジョニングのオーバーヘッドに、IDXPチャネルを含むBEEPセッションが長寿命であることが予想されます。また、IDXPチャネルプロビジョニングの繰り返しオーバーヘッド（すなわち、IDXP挨拶の交換）は、データを積極的に上で交換されていない間もオープンIDXPチャネルを維持することによって回避することができます。これらは、彼らが合うようになど、IDXPピアが閉鎖することを選択し、再プロビジョニングBEEPセッションおよび/またはIDXPチャンネルがあり、お薦めですと。
In our model, trust is placed exclusively in the IDXP peers. Proxies are always assumed to be untrustworthy. A BEEP security profile is used to establish end-to-end security between pairs of IDXP peers, doing away with the need to place trust in any intervening proxies. Only after successful negotiation of the underlying security profile are IDXP peers to be trusted. Only BEEP security profiles offering at least the protections required by Section 5 of [5] should be used to secure a BEEP session containing channels using the IDXP profile. See Section 3 of [4] for the registration of the TLS profile, an example of a BEEP security profile meeting the requirements of Section 5 of [5]. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements.
我々のモデルでは、信頼はIDXPピアに独占的に配置されます。プロキシは常に信頼できないと仮定されます。 BEEPセキュリティプロファイルは、任意の介在プロキシに信頼を置く必要で離れて行って、IDXPピアのペア間のエンドツーエンドのセキュリティを確立するために使用されます。唯一の基礎となるセキュリティプロファイルの成功の交渉の後、信頼するIDXPピアがあります。セクション5で必要とされる少なくとも保護を提供するだけBEEPセキュリティプロファイルは、[5] IDXPプロファイルを使用してチャネルを含むBEEPセッションを安全にするために使用されるべきです。 TLSプロファイルの登録、BEEPセキュリティプロファイル会議の例[5]のセクション5の要件のために[4]のセクション3を参照。 IDXPがIDWG通信プロトコルの要件を満たす方法についての説明は、第5章を参照してください。
The IDXP profile provides a mechanism for exchanging information between intrusion detection entities. A BEEP tuning profile MAY be used to create an application-layer tunnel that transparently forwards data over a chain of proxies. The TUNNEL profile [3] SHOULD be used for this purpose; see [3] for more detail concerning the options available to set up an application-layer tunnel using TUNNEL, and see Section 11.1 for a discussion of TUNNEL-related security considerations. TUNNEL MUST be offered as a tuning profile for the creation of application-layer tunnels. The TUNNEL profile MUST offer the use of some form of SASL authentication (see Section 4.1 of [4]). The TLS profile SHOULD be used to provide the required combination of mutual-authentication, integrity, and confidentiality for the IDXP profile. For further discussion of application-layer tunnel and security issues, see Sections 2.1 and 11.
IDXPプロファイルは、侵入検知エンティティ間で情報を交換するためのメカニズムを提供します。 BEEPチューニングプロファイルは透過プロキシのチェーンを介してデータを転送するアプリケーション層のトンネルを作成するために使用され得ます。 TUNNELプロファイルは、[3]この目的のために使用されるべきです。トンネルを使用して、アプリケーション層のトンネルを設定するために利用可能なオプションに関する詳細については[3]を参照し、トンネル関連のセキュリティ問題の議論については、セクション11.1を参照してください。トンネルは、アプリケーション層のトンネルを作成するためのチューニングプロファイルとして提供されなければなりません。 TUNNELプロファイルはSASL認証の何らかの形（[4]のセクション4.1を参照）の使用を提供しなければなりません。 TLSプロファイルはIDXPプロファイルの相互認証、整合性、および機密性の必要な組み合わせを提供するために使用されるべきです。アプリケーション層のトンネルとセキュリティ問題の詳細な説明については、セクション2.1および11を参照。
The IDXP profile supports several elements of interest:
IDXPプロファイルは、関心のあるいくつかの要素をサポートしています。
o The "IDXP-Greeting" element identifies an analyzer or manager at one end of a BEEP channel to the analyzer or manager at the other end of the channel.
○「IDXP-挨拶」要素は、チャネルの他端にアナライザまたはマネージャにBEEPチャンネルの一端にアナライザまたはマネージャを識別する。
o The "Option" element is used to convey optional channel parameters between peers during the exchange of "IDXP-Greeting" elements. This element is OPTIONAL.
O「オプション」要素は「IDXP-挨拶」要素の交換中にピア間の任意のチャネルパラメータを伝えるために使用されます。この要素はオプションです。
o The "IDMEF-Message" element carries the structured information to be exchanged between the peers.
○「IDMEF - メッセージ」要素は、ピア間で交換される構造化された情報を運びます。
The IDXP profile is identified as
IDXPプロファイルは次のように識別されます
http://idxp.org/beep/profile
ｈっｔｐ：／／いｄｘｐ。おｒｇ／べえｐ／ｐろふぃぇ
in the BEEP "profile" element during channel creation.
チャネルの作成中にBEEP「プロファイル」要素インチ
During channel creation, "IDXP-Greeting" elements MUST be mutually exchanged between the peers. An "IDXP-Greeting" element MAY be contained within the corresponding "profile" element in the BEEP "start" element. Including an "IDXP-Greeting" element in the initial "start" element has exactly the same semantics as passing it as the first "MSG" message on the channel. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "IDXP-Greeting" element and includes the resulting response in the reply. This response will be an "ok" element or an "error" element. The choice of which element is returned is dependent on local provisioning of the peer.
チャネルの作成時に、「IDXP-挨拶」の要素が相互にピア間で交換されなければなりません。 「IDXP-挨拶」要素は、BEEP「開始」要素に対応する「プロファイル」要素内に含まれていてもよいです。最初の「スタート」要素の「IDXP-挨拶」要素を含めると、チャネル上の最初の「MSG」メッセージとして渡すとまったく同じ意味を持っています。チャネルの作成が成功した場合、対応する応答を送信する前に、BEEPピアは「IDXP-挨拶」要素を処理し、応答で得られた応答とを含みます。この応答は、「OK」要素または「エラー」の要素となります。要素が返されるの選択は、ピアのローカルプロビジョニングに依存しています。
BEEP messages in the profile MUST have a MIME Content-Type [8] of "text/xml", "text/plain", or "application/octet-stream". The syntax of the individual elements is specified in Section 9.1 of this document and Section 4 of [2].
プロファイルのBEEPのメッセージは、[8] "text / xmlで"、 "text / plainの"、または "アプリケーション/オクテットストリーム" のMIMEのContent-Typeのを持っていなければなりません。個々の要素の構文は、このドキュメントのセクション9.1およびセクション4で指定されている[2]。
Each BEEP peer issues the "IDXP-Greeting" element using "MSG" messages. The "IDXP-Greeting" element MAY contain one or more "Option" sub-elements, conveying optional channel parameters. Each BEEP peer then issues "ok" in "RPY" messages or "error" in "ERR" messages. (See Section 2.3.1 of [4] for the definitions of the "error" and "ok" elements.) An "error" element MAY be issued within a "RPY" message when piggy-backed within a BEEP "profile" element. See Section 3.4.1 for an example of an "error" element being issued within a "RPY" message. Based on the respective client/server roles negotiated during the exchange of "IDXP-Greeting" elements, the client sends data using "MSG" messages. Depending on the MIME Content-Type, this data may be an "IDMEF-Message" element, plain text, or binary. The server then issues "ok" in "RPY" messages or "error" in "ERR" messages.
各BEEPピアは、「MSG」メッセージを使用して「IDXP-挨拶」要素を発行します。 「IDXP-挨拶」要素は、オプションのチャネルパラメータを搬送する、1つ以上の「オプション」サブ要素を含んでいてもよいです。各BEEPピアは、「ERR」メッセージで「RPY」メッセージや「エラー」で「OK」を発行します。 （「エラー」の定義と「OK」の要素のための[4]のセクション2.3.1を参照。）場合ピギーバックBEEP内の「プロファイル」の要素「エラー」要素が「RPY」メッセージ内に発行することができます。 「RPY」メッセージ以内に発行された「エラー」要素の例については、セクション3.4.1を参照してください。 「IDXP-挨拶」要素の交換中にネゴシエートそれぞれのクライアント/サーバーの役割に基づいて、クライアントは、「MSG」メッセージを使用してデータを送信します。 MIMEのContent-Typeのに応じて、このデータは、「IDMEF・メッセージ」要素、プレーンテキスト、またはバイナリかもしれません。その後、サーバーは、「ERR」メッセージで「RPY」メッセージや「エラー」で「OK」を発行します。
The "IDXP-Greeting" element serves to identify the analyzer or manager at one end of the BEEP channel to the analyzer or manager at the other end of the channel. The "IDXP-Greeting" element MUST include the role of the peer on the channel (client or server) and the Uniform Resource Identifier (URI) [6] of the peer. In addition, the "IDXP-Greeting" element MAY include the fully qualified domain name (see [9]) of the peer. One or more "Option" sub-elements MAY be present.
「IDXP-挨拶」要素は、チャネルの他端にアナライザまたはマネージャにBEEPチャネルの一端にアナライザやマネージャを識別するのに役立ちます。 「IDXP-挨拶」要素は、ピアのチャネル（クライアントまたはサーバ）上のピアの役割およびユニフォームリソース識別子（URI）[6]を含まなければなりません。また、「IDXP-挨拶」要素は、ピアの（[9]参照）の完全修飾ドメイン名を含むかもしれません。 1つ以上の「オプション」のサブ要素が存在してもよいです。
An "IDXP-Greeting" element MAY be sent by either peer at any time. The peer receiving the "IDXP-Greeting" MUST respond with an "ok" (indicating acceptance), or an "error" (indicating rejection). A peer's identity and role on a channel and any optional channel parameters are, in effect, specified by the most recent "IDXP-Greeting" it sent that was answered with an "ok".
「IDXP-挨拶」要素は、任意の時点でいずれかのピアによって送られるかもしれません。ピアは「IDXP-挨拶」が「OK」（指示受付）で応答しなければならない、又は（拒絶を示す）「エラー」を受信します。ピアのアイデンティティと役割チャネル上およびオプションのチャネルパラメータは、実際には、最新の「IDXP-挨拶」、それはそれは、「OK」と答えた送らによって指定されています。
An "IDXP-Greeting" may be rejected (with an "error" element) under many circumstances. These include, but are not limited to, authentication failure, lack of authorization to connect under the specified role, the negotiation of an inadequate cipher suite, or the presence of a channel option that must be understood but was unrecognized.
「IDXP-挨拶」は、多くの状況下で（「エラー」要素で）拒否されてもよいです。これらには、指定されたロール、不適切な暗号スイートの交渉、または理解したが、認識されていないだったしなければならないチャネルオプションの存在下に接続するための認証失敗、認証の欠如が、これらに限定されません。
For example, a successful creation with an embedded "IDXP-Greeting" might look like this:
例えば、埋め込まれた「IDXP-挨拶」で成功作成は次のようになります。
I: MSG 0 10 . 1592 187 I: Content-Type: text/xml I: I: <start number='1'> I: <profile uri='http://idxp.org/beep/profile'> I: <![CDATA[ <IDXP-Greeting uri='http://example.com/alice' I: role='client' /> ]]> I: </profile> I: </start> I: END L: RPY 0 10 . 1865 91
I：MSG 0 10。 1592 187 I：のContent-Type：text / xmlでI：I：<番号を開始= '1'> I：<プロファイルのuri = 'のhttp：//idxp.org/beep/profile'>私は<[CDATA [！ <IDXP-挨拶のuri = 'のhttp：//example.com/alice' I：役割= 'クライアント' />]]> I：</プロフィール> I </スタート> I：ENDのL：RPY 0 10。 1865年91
L: Content-Type: text/xml L: L: <profile uri='http://idxp.org/beep/profile'> L: <![CDATA[ <ok /> ]]> L: </profile> L: END L: MSG 0 11 . 1956 61 L: Content-Type: text/xml L: L: <IDXP-Greeting uri='http://example.com/bob' role='server' /> L: END I: RPY 0 11 . 1779 7 I: Content-Type: text/xml I: I: <ok /> I: END
L：コンテンツタイプ：text / xmlでL：L：<プロファイルのuri = 'のhttp：//idxp.org/beep/profile'> L：<！[CDATA [<OK />]]> L：</プロフィール> L：ENDのL：MSG 0 11。 1956年61 L：コンテンツタイプ：text / xmlでL：L：<IDXP-挨拶のuri = 'のhttp：//example.com/bobの役割= 'サーバー'/> L：END I：RPY 0 11。 1779年7 I：のContent-Type：text / xmlでI：I：<OK /> I：END
A creation with an embedded "IDXP-Greeting" that fails might look like this:
次のようになります。失敗した組み込み「IDXP-挨拶」で作成：
I: MSG 0 10 . 1776 185 I: Content-Type: text/xml I: I: <start number='1'> I: <profile uri='http://idxp.org/beep/profile'> I: <![CDATA[ <IDXP-Greeting uri='http://example.com/eve' I: role='client' /> ]]> I: </profile> I: </start> I: END L: RPY 0 10 . 1592 182 L: Content-Type: text/xml L: L: <profile uri='http://idxp.org/beep/profile'> L: <![CDATA[ L: <error code='530'>'http://example.com/eve' must first L: negotiate the TLS profile</error> ]]> L: </profile> L: END
I：MSG 0 10。 1776 185 I：のContent-Type：text / xmlでI：I：<番号を開始= '1'> I：<プロファイルのuri = 'のhttp：//idxp.org/beep/profile'>私は<[CDATA [！ <IDXP-挨拶のuri = 'のhttp：//example.com/eve' I：役割は= 'クライアント' />]]> I：</プロフィール> I </スタート> I：ENDのL：RPY 0 10。 1592 182 L：コンテンツタイプ：text / xmlでのL：L：<プロファイルのuri = 'のhttp：//idxp.org/beep/profile'> L <！[CDATA [L：<エラーコード= '530'> 'http://example.com/eve' しなければならない最初のL：TLSプロファイルを交渉</エラー>]]> L </プロフィール> L：END
If present, the "Option" element MUST be contained within an "IDXP-Greeting" element. An individual "IDXP-Greeting" element MAY contain one or more "Option" sub-elements. Each "Option" element within an "IDXP-Greeting" element represents a request to enable an IDXP option on the channel being negotiated. See Section 4 for a complete description of IDXP options and the "Option" element.
存在する場合、「オプション」要素は「IDXP-挨拶」要素内に含まれなければなりません。個々の「IDXP-挨拶」要素は、1つまたは複数の「オプション」のサブ要素を含んでいてもよいです。 「IDXP-挨拶」要素内の各「オプション」要素は、ネゴシエートされたチャネル上のIDXPオプションを有効にするための要求を表しています。 IDXPオプションの完全な説明と、「オプション」の要素については、セクション4を参照してください。
The "IDMEF-Message" element carries the information to be exchanged between the peers. See Section 4 of [2] for the definition of this element.
「IDMEF・メッセージ」要素は、ピア間で交換される情報を運びます。この要素の定義については、[2]のセクション4を参照してください。
IDXP provides a service for the reliable exchange of data between intrusion detection entities. Options are used to alter the semantics of the service.
IDXPは、侵入検知エンティティ間のデータの信頼性の交換のためのサービスを提供しています。オプションは、サービスのセマンティクスを変更するために使用されています。
The specification of an IDXP option MUST define
IDXPオプションの仕様を定義しなければなりません
o the identity of the option;
オプションの身元O;
o what content, if any, is contained within the option; and
Oどのようなコンテンツがあれば、オプションの中に含まれています。そして
o the processing rules for the option.
オプションの処理ルールO。
An option registration template (see Section 7) organizes this information.
オプションの登録テンプレート（セクション7を参照）、この情報を整理します。
An "Option" element is contained within an "IDXP-Greeting" element. The "IDXP-Greeting" element itself MAY contain one or more "Option" elements. The "Option" element has several attributes and contains arbitrary content:
「オプション」の要素は、「IDXP-挨拶」要素内に含まれています。 「IDXP-挨拶」要素自体は、1つ以上の「オプション」の要素を含むかもしれません。 「オプション」の要素は、いくつかの属性を持っており、任意のコンテンツが含まれています。
o the "internal" and the "external" attributes, exactly one of which MUST be present, uniquely identify the option;
;「内部」及び「外部」丁度のいずれかのオプションを識別する一意に存在していなければなりません、属性O
o the "mustUnderstand" attribute, whose presence is OPTIONAL and whose default value is "false", specifies whether the option, if unrecognized, MUST cause an error in processing to occur; and
その存在はオプションであり、デフォルト値は「偽」です「のmustUnderstand」属性、O、認識されていない場合、このオプションは、処理中にエラーが発生する原因となる必要があるかどうかを指定します。そして
o the "localize" attribute, whose presence is OPTIONAL, specifies one or more language tokens, each identifying a desirable language tag to be used if textual diagnostics are returned to the originator.
Oその存在OPTIONALである「局在化」属性は、テキストの診断が元に戻された場合、望ましい言語タグを識別するそれぞれが使用する、一つ以上の言語のトークンを指定します。
The value of the "internal" attribute is the IANA-registered name for the option. If the "internal" attribute is not present, then the value of the "external" attribute is a URI or URI with a fragment-identifier. Note that a relative-URI value is not allowed.
「内部」属性の値は、オプションのIANA登録名です。 「内部」属性が存在しない場合は、「外部」属性の値は、フラグメント識別子とURI又はURIです。相対URI値が許可されていないことに注意してください。
The "mustUnderstand" attribute specifies whether the peer may ignore the option if it is unrecognized. If the value of the "mustUnderstand" attribute is "true", and if the peer does not recognize the option, then an error in processing has occurred. When absent, the value of the "mustUnderstand" attribute is defined to be "false".
「のmustUnderstand」属性は、それが認識されない場合、ピアはオプションを無視するかどうかを指定します。 「のmustUnderstand」属性の値が「真」であり、ピアがオプションを認識しない場合は、処理中にエラーが発生した場合。場合は不在、「のmustUnderstand」属性の値が「偽」であると規定されています。
Section 8.3 contains the IDXP option registration for the "channelPriority" option. This option contains a "channelPriority" element (see Section 9.2).
8.3節では、「channelPriority」オプションのIDXPオプションの登録が含まれています。このオプションは、「channelPriority」要素（9.2項を参照）が含まれています。
By default, IDXP does not place any requirements on how peers should manage multiple IDXP channels. The "channelPriority" option provides a way for peers using multiple IDXP channels to request relative priorities for each channel. When sending an "IDXP-Greeting" element during the provisioning of an IDXP channel, the originating peer MAY request that the remote peer assign a priority to the channel by including an "Option" element containing a "channelPriority" element.
デフォルトでは、IDXPは、ピアは、複数のIDXPチャネルを管理する方法上の任意の要件を置いていません。 「channelPriority」オプションは、各チャンネルの相対的な優先度を要求する複数IDXPチャネルを使用して、ピアの方法を提供します。 IDXPチャネルのプロビジョニング中に「IDXP-グリーティング」要素を送信する際、発信ピアは、リモートピアが「channelPriority」要素を含む「オプション」要素を含むことによって、チャネルに優先度を割り当てることを要求することができます。
The "channelPriority" element has one attribute named "priority", of range 0..2147483647. This attribute is REQUIRED. Not coincidentally, this is the maximum range of possible BEEP channel numbers. 0 is defined to represent the highest priority, with relative priority decreasing as the "priority" value ascends.
「channelPriority」要素は、範囲0 2147483647の「優先順位」という名前の属性を持っています。この属性は必須です。偶然ではなく、これは可能BEEPチャンネル番号の最大範囲です。 0は、相対的な優先度が「優先」値の上昇につれて減少して、最高の優先順位を表すように定義されています。
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, an analyzer successfully requests that a manager assign a priority to the channel:
例えば、チャネルのプロビジョニング中「IDXP-挨拶」エレメントの交換の際に、アナライザは正常マネージャがチャネルに優先順位を割り当てることを要求します。
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
C: MSG 1 17 . 1984 165 C: Content-Type: text/xml C: C: <IDXP-Greeting uri='http://example.com/alice' role='client'> C: <Option internal='channelPriority'> C: <channelPriority priority='0' /> C: </Option> C: </IDXP-Greeting> C: END S: RPY 1 17 . 2001 7 S: Content-Type: text/xml S: S: <ok /> S: END
C：MSG 1 17。 1984 165 C：のContent-Type：text / xmlでのC：C：<IDXP-挨拶のuri = 'のhttp：//example.com/aliceの役割= 'クライアント'> C：<オプション内部= 'channelPriority'> C： <channelPriority優先= '0' /> C </オプション> C </ IDXP-挨拶> C：ENDのS：RPY 1 17。 2001年7 S：コンテンツタイプ：text / xmlでのS：S：<OK /> S：END
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, a manager unsuccessfully requests that an analyzer assign a priority to the channel:
例えば、チャネルのプロビジョニング中「IDXP-挨拶」エレメントの交換の際に、マネージャが失敗アナライザは、チャネルに優先順位を割り当てることを要求します。
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
S: MSG 1 17 . 1312 194 S: Content-Type: text/xml S: S: <IDXP-Greeting uri='http://example.com/bob' role='server'> S: <Option internal='channelPriority' mustUnderstand='true'> S: <channelPriority priority='2147483647' /> S: </Option> S: </IDXP-Greeting> S: END C: ERR 1 17 . 451 68 C: Content-Type: text/xml C: C: <error code='504'>'channelPriority' option was unrecognized</error> C: END
S：MSG 1 17。 1312 194 S：コンテンツタイプ：text / xmlでS：S：<IDXP-挨拶のuri = 'のhttp：//example.com/bobの役割は= 'サーバー'> S：<オプション内部= 'channelPriority' のmustUnderstand =」真 '> S <channelPriority優先度=' 2147483647' /> S </オプション> S </ IDXP-挨拶> S：ENDのC：1 17 ERR。 451 68 C：のContent-Type：text / xmlでのC：C：END：<エラーコード= '504'> 'channelPriority' オプションは認識されていない</エラー> Cました
Section 8.4 contains the IDXP option registration for the "streamType" option. This option contains a "streamType" element (see Section 9.3).
8.4節では、「streamType」オプションのIDXPオプションの登録が含まれています。このオプションは、「streamType」の要素（9.3項を参照）が含まれています。
By default, IDXP provides no explicit method for categorizing channels. The "streamType" option provides a way for peers to request that a channel be categorized as a particular stream type. When sending an "IDXP-Greeting" element during the provisioning of an IDXP channel, the originating peer MAY request that the remote peer assign a stream type to the channel by including an "Option" element containing a "streamType" element.
デフォルトでは、IDXPはチャンネルを分類するための明示的な方法を提供していません。 「streamType」オプションは、ピアは、チャネルが特定のストリームタイプとして分類することを要求するための方法を提供します。 IDXPチャネルのプロビジョニング中に「IDXP-グリーティング」要素を送信する際、発信ピアは、リモートピアが「streamType」要素を含む「オプション」要素を含むことによって、チャネルのストリームタイプを割り当てることを要求することができます。
The "streamType" element has one attribute named "type", with the possible values of "alert", "heartbeat", or "config". This attribute is REQUIRED. A value of "alert" indicates that the channel should be categorized as being used for the exchange of ID alerts. A value of "heartbeat" indicates that the channel should be categorized as being used for the exchange of heartbeat messages such as the "Heartbeat" element (see Section 4 of [2]). A value of "config" indicates that the channel should be categorized as being used for the exchange of configuration messages.
「streamType」の要素は、「警告」、「ハートビート」、または「設定」の可能な値を持つ「タイプ」という名前の属性を持っています。この属性は必須です。 「警告」の値は、チャネルIDアラートの交換に使用されるものとして分類されるべきであることを示します。 「ハートビート」の値は、チャネルは、「ハートビート」要素（[2]のセクション4を参照）のように、ハートビートメッセージの交換に使用されるものとして分類されるべきであることを示します。 「設定」の値は、チャネル設定メッセージの交換に使用されるものとして分類されるべきであることを示します。
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, an analyzer successfully requests that a manager assign a stream type to the channel:
例えば、チャネルのプロビジョニング中「IDXP-挨拶」エレメントの交換の際に、アナライザは正常マネージャがチャネルにストリームタイプを割り当てることを要求します。
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
C: MSG 1 21 . 1963 155 C: Content-Type: text/xml C: C: <IDXP-Greeting uri='http://example.com/alice' role='client'> C: <Option internal='streamType'> C: <streamType type='alert' /> C: </Option> C: </IDXP-Greeting> C: END S: RPY 1 21 . 1117 7 S: Content-Type: text/xml S: S: <ok /> S: END
C：MSG 1 21。 1963 155 C：のContent-Type：text / xmlでのC：C：<IDXP-挨拶のuri = 'のhttp：//example.com/aliceの役割= 'クライアント'> C：<オプション内部= 'streamType'> C： <streamType型= '警告' /> C </オプション> C </ IDXP-挨拶> C：ENDのS：RPY 1 21。 1117年7 S：コンテンツタイプ：text / xmlでのS：S：<OK /> S：END
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, a manager unsuccessfully requests that an analyzer assign a stream type to the channel:
例えば、チャネルのプロビジョニング中「IDXP-挨拶」エレメントの交換の際に、マネージャが失敗アナライザは、チャネルにストリームタイプを割り当てることを要求します。
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
S: MSG 1 21 . 1969 176 S: Content-Type: text/xml S: S: <IDXP-Greeting uri='http://example.com/bob' role='server'> S: <Option internal='streamType' mustUnderstand='true'> S: <streamType type='config' /> S: </Option> S: </IDXP-Greeting> S: END C: ERR 1 21 . 1292 63 C: Content-Type: text/xml C: C: <error code='504'>'streamType' option was unrecognized</error> C: END
S：MSG 1 21。 1969 176 S：コンテンツタイプ：text / xmlでS：S：<IDXP-挨拶のuri = 'のhttp：//example.com/bobの役割は= 'サーバー'> S：<オプション内部= 'streamType' のmustUnderstand =」真 '> S <streamTypeタイプ=' 設定」/> S </オプション> S </ IDXP-挨拶> S：ENDのC：1 21 ERR。 1292は、63 C：のContent-Type：text / xmlでのC：C：END：<エラーコード= '504'> 'streamType' オプションは認識されていない</エラー> Cました
The following lists each of the communications protocol requirements established in Section 5 of [5] and, for each requirement, describes the manner in which it is fulfilled. IDXP itself does not fulfill each of the communications protocol requirements, but instead relies on the underlying BEEP protocol and a variety of BEEP profiles.
次のリスト[5]のセクション5で確立された通信プロトコルの要件のそれぞれは、各要件のために、それが満たされている方法を記載しています。 IDXP自体は、通信プロトコルの各要件を満たすが、代わりに基本的なBEEPプロトコルとBEEPプロファイルのさまざまな依存しません。
"The [protocol] MUST support reliable transmission of messages." See Section 5.1 of [5].
「[プロトコル]は、メッセージの信頼性の高い伝送をサポートしなければなりません。」 [5]のセクション5.1を参照してください。
IDXP operates over BEEP, which operates only over reliable connection-oriented transport protocols (e.g., TCP). In addition, BEEP peers communicate using a simple request-response protocol, which provides end-to-end reliability between peers.
IDXPは、信頼性の高い接続指向のトランスポートプロトコル（例えば、TCP）で動作BEEP、上で動作します。また、BEEPピアは、ピア間のエンドツーエンドの信頼性を提供する単純な要求 - 応答プロトコルを使用して通信します。
"The [protocol] MUST support transmission of messages between ID components across firewall boundaries without compromising security." See Section 5.2 of [5].
「[プロトコル]は、セキュリティを損なうことなく、ファイアウォール境界を越えIDコンポーネント間のメッセージの転送をサポートしなければなりません。」 [5]のセクション5.2を参照してください。
The TUNNEL profile [3] MUST be offered as an option for creation of application-layer tunnels to allow operation across firewalls. The TUNNEL profile SHOULD be used to provide an application-layer tunnel. The ability to authenticate hosts during the creation of an application-layer tunnel MUST be provided by the mechanism chosen to create such tunnels. A firewall may therefore be configured to authenticate all hosts attempting to tunnel into the protected network. If the TUNNEL profile is used, SASL (see Section 4.1 of [4]) MUST be offered as a mechanism by which hosts can be authenticated.
TUNNELプロファイルは、[3]ファイアウォールを介し操作を可能にするアプリケーション層のトンネルを作成するためのオプションとして提供されなければなりません。 TUNNELプロファイルは、アプリケーション層のトンネルを提供するために使用されるべきです。アプリケーション層のトンネルの作成時にホストを認証する能力は、このようなトンネルを作成するために選択された機構によって提供されなければなりません。ファイアウォールは、従って、保護されたネットワークにトンネルを試みるすべてのホストを認証するように構成されてもよいです。 TUNNELプロファイルが使用される場合、SASLは、ホストを認証することができるメカニズムとして提供されなければならない（[4]のセクション4.1を参照します）。
"The [protocol] MUST support mutual authentication of the analyzer and the manager to each other." See Section 5.3 of [5].
「[プロトコル]はアナライザ、互いにマネージャの相互認証をサポートしなければなりません。」 [5]のセクション5.3を参照してください。
IDXP supports mutual authentication of the peers through the use of an appropriate underlying BEEP security profile. The TLS profile and members of the SASL family of profiles (see Section 4.1 of [4]) are examples of security profiles that may be used to authenticate the identity of communicating ID components. TLS MUST be offered as a mechanism to provide mutual authentication, and TLS SHOULD be used to provide mutual authentication.
IDXPは、適切な基盤となるBEEPセキュリティプロファイルを使用してピアの相互認証をサポートしています。 TLSプロファイルとプロファイルのSASLファミリーのメンバーは、IDコンポーネントを通信の身元を認証するために使用することができるセキュリティプロファイルの例である（[4]のセクション4.1を参照します）。 TLSは、相互認証を提供するためのメカニズムとして提供されなければならない、及びTLSは、相互認証を提供するために使用されるべきです。
"The [protocol] MUST support confidentiality of the message content during message exchange. The selected design MUST be capable of supporting a variety of encryption algorithms and MUST be adaptable to a wide variety of environments." See Section 5.4 of [5].
「[プロトコル]は、メッセージ交換中にメッセージ内容の機密性をサポートしなければならない。選択された設計は、暗号化アルゴリズムの多様をサポートすることができるなければならず、さまざまな環境に適応していなければなりません。」 [5]のセクション5.4を参照してください。
IDXP supports confidentiality through the use of an appropriate underlying BEEP security profile. The TLS profile is an example of a security profile that offers confidentiality. The TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a mechanism to provide confidentiality, and TLS with this cipher suite SHOULD be used to provide confidentiality. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral Diffie-Hellman (DHE) with DSS signatures for key exchange and triple DES (Data Encryption Standard) (3DES) and cipher-block chaining (CBC) for encryption. Stronger cipher suites are optional.
IDXPは、適切な基盤となるBEEPセキュリティプロファイルを使用して機密性をサポートしています。 TLSプロファイルは、機密性を提供するセキュリティプロファイルの一例です。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートとTLSのプロファイルは、機密性を提供するためのメカニズムとして提供されなければならない、及びTLSは、この暗号スイートと機密性を提供するために使用されるべきです。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、暗号化のための鍵交換およびトリプルDES（データ暗号化標準）（3DES）と暗号ブロック連鎖（CBC）のためのDSS署名とはかないディフィー - ヘルマン（DHE）を使用します。より強力な暗号スイートはオプションです。
"The [protocol] MUST ensure the integrity of the message content. The selected design MUST be capable of supporting a variety of integrity mechanisms and MUST be adaptable to a wide variety of environments." See Section 5.5 of [5].
「[プロトコル]は、メッセージの内容の完全性を確実にしなければなりません。選択された設計は、整合性の種々の機構をサポートすることが可能でなければならなくて、環境の広範囲に適応していなければなりません。」 [5]のセクション5.5を参照してください。
IDXP supports message integrity through the use of an appropriate underlying BEEP security profile. The TLS profile and members of the SASL family of profiles (see Section 4.1 of [4]) are examples of security profiles that offer message integrity. The TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a mechanism to provide integrity, and TLS with this cipher suite SHOULD be used to provide integrity. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses the Secure Hash Algorithm (SHA) for integrity protection using a keyed message authentication code. Stronger cipher suites are optional.
IDXPは、適切な基盤となるBEEPセキュリティプロファイルを使用してメッセージの整合性をサポートしています。 TLSプロファイルとプロファイルのSASLファミリーのメンバーは、メッセージの整合性を提供するセキュリティプロファイルの例です（[4]のセクション4.1を参照します）。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートとTLSプロファイルが整合性を提供するためのメカニズムとして提供されなければならない、とTLSは、この暗号スイートとの整合性を提供するために使用されるべきです。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、鍵付きメッセージ認証コードを使用して完全性保護のためのセキュアハッシュアルゴリズム（SHA）を使用します。より強力な暗号スイートはオプションです。
"The [protocol] MUST support separate authentication keys for each sender." See Section 5.6 of [5].
「[プロトコル]は、各送信者に対して個別の認証鍵をサポートしなければなりません。」 [5]のセクション5.6を参照してください。
IDXP supports separate authentication keys for each sender (i.e., per-source authentication) through the use of an appropriate underlying BEEP security profile. The TLS profile is an example of a security profile that supports per-source authentication through the mutual authentication of public-key certificates. TLS MUST be offered as a mechanism to provide per-source authentication, and TLS SHOULD be used to provide per-source authentication.
IDXPは、適切な基礎となるBEEPセキュリティプロファイルの使用を介して、各送信者に対して個別の認証鍵（すなわち、毎ソース認証）をサポートします。 TLSプロファイルは、公開鍵証明書の相互認証を通じてごとのソースの認証をサポートしているセキュリティプロファイルの一例です。 TLSごとのソースの認証を提供するためのメカニズムとして提供されなければならない、とTLSごとのソースの認証を提供するために使用されるべきです。
"The [protocol] SHOULD resist protocol denial-of-service attacks." See Section 5.7 of [5].
「[プロトコル]は、プロトコル、サービス拒否攻撃を耐えなければなりません。」 [5]のセクション5.7を参照してください。
IDXP supports resistance to denial of service (DoS) attacks through the use of an appropriate underlying BEEP security profile. BEEP peers offering the IDXP profile MUST offer the use of TLS with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite, and SHOULD use TLS with that cipher suite. To resist DoS attacks it is helpful to discard traffic arising from a non-authenticated source. BEEP peers MUST support the use of authentication in conjunction with any mechanism used to create application-layer tunnels. In particular, the use of some form of SASL authentication (see Section 4.1 of [4]) MUST be offered to provide authentication in the use of the TUNNEL profile. See Section 7 of [3] for a discussion of security considerations in the use of the TUNNEL profile.
IDXPは、適切な基盤となるBEEPセキュリティプロファイルを使用してサービス拒否（DoS）攻撃の拒否に対する抵抗性をサポートしています。 IDXPプロファイルを提供するBEEPピアはTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートとTLSの使用を提供しなければならない、とその暗号スイートとTLSを使用すべきです。抵抗するDoS攻撃は、非認証ソースから発生するトラフィックを破棄すると便利です攻撃します。 BEEPピアは、アプリケーション層のトンネルを作成するために使用される任意の機構と組み合わせて認証の使用をサポートしなければなりません。具体的には、SASL認証の何らかの形態の使用は、トンネルプロファイルの使用時に認証を提供するために提供されなければならない（[4]のセクション4.1を参照します）。 TUNNELプロファイルの使用におけるセキュリティの考慮事項の議論のための[3]のセクション7を参照してください。
"The [protocol] SHOULD resist malicious duplication of messages." See Section 5.8 of [5].
「[プロトコル]はメッセージの悪質な重複を耐えなければなりません」。 [5]のセクション5.8を参照してください。
IDXP supports resistance to malicious duplication of messages (i.e., replay attacks) through the use of an appropriate underlying BEEP security profile. The TLS profile is an example of a security profile offering resistance to replay attacks. The TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite MUST be offered as a mechanism to provide resistance against replay attacks, and TLS with this cipher suite SHOULD be used to provide resistance against replay attacks. The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses cipher-block chaining (CBC) to ensure that even if a message is duplicated the cipher-text duplicate will produce a very different plain-text result. Stronger cipher suites are optional.
IDXPは、適切な基盤となるBEEPセキュリティプロファイルを使用して、メッセージの悪質な重複（すなわち、リプレイ攻撃）に対する耐性をサポートしています。 TLSプロファイルは、リプレイ攻撃に対する耐性を提供するセキュリティプロファイルの一例です。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートとTLSのプロファイルは、リプレイ攻撃に対する耐性を提供するためのメカニズムとして提供されなければならない、この暗号スイートとTLSは、リプレイ攻撃に対する耐性を提供するために使用されるべきです。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、メッセージが複製されても暗号文の重複が非常に異なるプレーンテキスト結果を生成することを保証するために、暗号ブロック連鎖（CBC）を使用します。より強力な暗号スイートはオプションです。
The specification of IDXP options (see Section 4) is the preferred method of extending IDXP. In order to extend IDXP, an IDXP option SHOULD be documented in an RFC and MUST be registered with the IANA (see Section 7). IDXP extensions that cannot be expressed as IDXP options MUST be documented in an RFC.
IDXPオプションの仕様（セクション4を参照）IDXPを拡張する好ましい方法です。 IDXPを拡張するために、IDXPオプションはRFCに文書化されるべきであり、IANA（セクション7参照）に登録されなければなりません。 IDXPオプションとして表現することはできませんIDXP拡張はRFCで文書化されなければなりません。
When an IDXP option is registered, the following information is supplied:
IDXPオプションが登録されている場合は、次の情報が提供されます。
Option Identification: specify the NMTOKEN or the URI that authoritatively identifies this option.
オプションの同定：NMTOKENや権威には、このオプションを識別するURIを指定します。
Contains: specify the XML content that is contained within the "Option" element.
含まれています：「オプション」の要素内に含まれているXMLコンテンツを指定します。
Processing Rules: specify the processing rules associated with the option.
処理ルール：オプションに関連した処理規則を指定します。
Contact Information: specify the postal and electronic contact information for the author(s) of the option.
お問い合わせ先：オプションの作者のために郵便や電子連絡先情報を指定します。
Profile identification: http://idxp.org/beep/profile
プロフィール識別：http://idxp.org/beep/profile
Messages exchanged during channel creation: "IDXP-Greeting"
メッセージは、チャネルの作成中に交換：「IDXP-挨拶します」
Messages starting one-to-one exchanges: "IDXP-Greeting", "IDMEF-Message"
1対1の交換を開始するメッセージ：「IDXP-挨拶」、「IDMEF-のメッセージ」
Messages in positive replies: "ok"
正の返信でメッセージ：「OK」
Messages in negative replies: "error"
負の返信でメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message syntax: see Section 3.3
メッセージ構文：3.3節を参照してください
Message semantics: see Section 3.4
メッセージの意味：3.4節を参照してください
Contact information: see the "Authors' Addresses" section of this memo
連絡先情報：このメモの「著者のアドレス」を参照してください
Protocol Number: 603
プロトコル番号：603
Message Formats, Types, Opcodes, and Sequences: see Section 3.3
メッセージフォーマット、タイプ、オペコード、およびシーケンス：3.3節を参照してください
Functions: see Section 3.4
機能：3.4節を参照してください
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの利用：なし
Proposed Name: Intrusion Detection Exchange Protocol
提案名前：侵入検知交換プロトコル
Short name: idxp
短い名前：idxp
Contact Information: see the "Authors' Addresses" section of this memo
お問い合わせ先：このメモの「著者のアドレス」を参照してください
Option Identification: channelPriority
オプション識別：channelPriority
Contains: channelPriority (see Section 9.2)
含まれています：channelPriorityを（9.2節を参照してください）
Processing Rules: see Section 4.1
処理ルールは：セクション4.1を参照してください
Contact Information: see the "Authors' Addresses" section of this memo
お問い合わせ先：このメモの「著者のアドレス」を参照してください
Option Identification: streamType
オプション識別：streamType
Contains: streamType (see Section 9.3)
含まれています：streamType（セクション9.3を参照してください）
Processing Rules: see Section 4.2
ルールの処理：第4.2節を参照してください
Contact Information: see the "Authors' Addresses" section of this memo
お問い合わせ先：このメモの「著者のアドレス」を参照してください
The following is the DTD defining the valid elements for the IDXP profile.
次はIDXPプロファイルの有効な要素を定義するDTDです。
<!-- DTD for the IDXP Profile
<！ - DTD IDXPさんのプロフィール
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC 4767 IDXP v1.0//EN">
<！ENTITY％IDXP PUBLIC " - // IETF // DTD RFC 4767 IDXP v1.0を// EN">
%IDXP; -->
％IDXP; - >
<!-- Includes -->
<！ - 含みます - >
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">
<！ENTITY％のBEEP PUBLIC " - // IETF // DTD BEEP // EN">
%BEEP;
％ビープ;
<!ENTITY % IDMEF-Message PUBLIC "-//IETF//DTD RFC 4765 IDMEF v1.0//EN">
<！ENTITY％のIDMEF-のメッセージPUBLIC " - // IETF // DTD RFC 4765 IDMEF v1.0を// EN">
%IDMEF;
％IDMEF;
<!-- Profile Summary
<！ - プロファイルの概要
BEEP profile http://idxp.org/beep/profile
BEEPプロファイルhttp://idxp.org/beep/profile
role MSG RPY ERR ==== === === === I or L IDXP-Greeting ok error C IDMEF-Message ok error -->
役割MSG RPY ERR ==== === === === IまたはL IDXP-挨拶OKエラーC IDMEF-のメッセージOKエラー - >
<!-- Entity Definitions
<！ - エンティティ定義
entity syntax/reference example
====== ================ =======
an authoritative identification
URI see RFC 3986 [6] http://example.com
a fully qualified domain name FQDN see RFC 1034 [9] www.example.com -->
完全修飾ドメイン名FQDNは、RFC 1034を参照してください[9] www.example.com - >
<!ENTITY % URI "CDATA"> <!ENTITY % FQDN "CDATA">
<！ENTITY％URI "CDATA"> <！ENTITY％FQDN "CDATA">
<!-- The IDXP-Greeting element declares the role and identity of the peer issuing it, on a per-channel basis. The IDXP-Greeting element may contain one or more Option sub-elements. -->
<！ - IDXP-挨拶要素は、チャネルごとに、それを発行したピアの役割とアイデンティティを宣言します。 IDXP-グリーティング要素は、1つ以上のオプションのサブ要素が含まれていてもよいです。 - >
<!ELEMENT IDXP-Greeting (Option*)> <!ATTLIST IDXP-Greeting uri %URI; #REQUIRED role (client|server) #REQUIRED fqdn %FQDN; #IMPLIED>
<！ELEMENT IDXP-挨拶（オプション*）> <ATTLIST IDXP-挨拶URI％URI！。 #REQUIRED役割（クライアント|サーバー）#REQUIRED FQDN％FQDN; #IMPLIED>
<!-- The Option element conveys an IDXP channel option. Note that the %LOCS entity is imported from the BEEP Channel Management DTD. -->
<！ - オプション要素はIDXPチャネルオプションを伝えます。 ％のLOCSエンティティはBEEPチャンネル管理DTDからインポートされることに注意してください。 - >
<!ELEMENT Option (ANY)> <!ATTLIST Option internal NMTOKEN "" external %URI; "" mustUnderstand (true|false) "false" localize %LOCS; "i-default">
<！ELEMENTオプション（ANY）> <！ATTLISTオプション内部NMTOKEN "" 外部％URI; "" のmustUnderstand（真|偽）が "偽" ％LOCSをローカライズします。 「私は、デフォルトの」>
<!-- The IDMEF-Message element conveys the intrusion detection information that is exchanged. This element is defined in the idmef-message.dtd -->
<！ - IDMEF-message要素が交換され、侵入検知情報を伝えます。この要素はIDMEF-message.dtdで定義されています - >
<!-- End of DTD -->
<！ - DTDの終わり - >
The following is the DTD defining the valid elements for the channelPriority option.
次はchannelPriorityオプションの有効な要素を定義するDTDです。
<!-- DTD for the channelPriority IDXP option, as of 2002-01-08
<！ - 2002-01-08のようchannelPriority IDXPオプションのDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % IDXP-channelPriority PUBLIC "-//IETF//DTD RFC 4767 IDXP-channelPriority v1.0//EN">
<！ENTITY％のIDXP-channelPriority PUBLIC " - // IETF // DTD RFC 4767 IDXP-channelPriority v1.0を// EN">
%IDXP-channelPriority; -->
％IDX-チャネル優先; - >
<!-- Entity Definitions
<！ - エンティティ定義
entity syntax/reference example
====== ================ =======
a priority number PRIORITY 0..2147483647 1 -->
優先順位番号PRIORITY 0 2147483647 1 - >
<!ENTITY % PRIORITY "CDATA">
<！ENTITY％を優先 "CDATA">
<!ELEMENT channelPriority EMPTY> <!ATTLIST channelPriority priority %PRIORITY #REQUIRED>
<！ELEMENT channelPriority EMPTY> <！ATTLIST channelPriority優先％のPRIORITY #REQUIRED>
<!-- End of DTD -->
<！ - DTDの終わり - >
The following is the DTD defining the valid elements for the streamType option.
以下は、streamTypeオプションの有効な要素を定義するDTDです。
<!-- DTD for the streamType IDXP option, as of 2002-01-08
<！ - 2002-01-08のようstreamType IDXPオプションのDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % IDXP-streamType PUBLIC "-//IETF//DTD RFC 4767 IDXP-streamType v1.0//EN">
<！ENTITY％のIDXP-streamType PUBLIC " - // IETF // DTD RFC 4767 IDXP-streamType v1.0を// EN">
%IDXP-streamType; -->
％IDXP-streamType。 - >
<!-- Entity Definitions
<！ - エンティティ定義
entity syntax/reference example
====== ================ =======
a stream type
STYPE (alert | heartbeat | config) "alert"
-->
<!ENTITY % STYPE (alert|heartbeat|config)>
<！ENTITY％以下のSTYPE（警告|ハートビート|設定）>
<!ELEMENT streamType EMPTY> <!ATTLIST streamType type %STYPE #REQUIRED>
<！ELEMENT streamType EMPTY> <！ATTLIST streamTypeタイプ％STYPE #REQUIRED>
<!-- End of DTD -->
<！ - DTDの終わり - >
This section lists the three-digit error codes the IDXP profile may generate.
このセクションでは、IDXPプロファイルが生成する3桁のエラーコードを示します。
code meaning ==== ======= 421 Service not available (e.g., the peer does not have sufficient resources)
コードの意味==== ======= 421サービス利用できない（例えば、ピアが十分なリソースを持っていません）
450 Requested action not taken (e.g., DNS lookup failed or connection could not be established. See also 550.)
取られていない450要求されたアクション（例えば、DNSルックアップが失敗したか、接続が確立できませんでした。また、550参照）
454 Temporary authentication failure
454一時的な認証失敗
500 General syntax error (e.g., poorly-formed XML)
500一般的な構文エラー（例えば、不完全に形成されたXML）
501 Syntax error in parameters (e.g., non-valid XML)
パラメータ501構文エラー（例えば、非有効XML）
504 Parameter not implemented
504パラメータ実装されていません
530 Authentication required
530認証が必要
534 Authentication mechanism insufficient (e.g., cipher suite too weak, sequence exhausted)
不十分534認証機構（例えば、暗号スイート弱すぎる、配列排出）
535 Authentication failure
535認証失敗
537 Action not authorized for user
537アクションユーザに対して権限がありません
550 Requested action not taken (e.g., peer could be contacted, but malformed greeting or no IDXP profile advertised)
取らない550要求されたアクション（例えば、ピアが連絡することができるが、不正な形式の挨拶または全くIDXPプロファイルがアドバタイズ）
553 Parameter invalid
無効なパラメータ553
554 Transaction failed (e.g., policy violation)
554トランザクションが失敗した（例えば、ポリシー違反）
The IDXP profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal. Refer to Section 9 of [4] for a discussion of this. It is strongly recommended that those wanting to use the IDXP profile initially negotiate a BEEP security profile between the peers that offers the required security properties. The TLS profile SHOULD be used to provide for transport security. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements.
IDXPプロファイルは、BEEPのプロファイルです。 BEEPでは、トランスポート・セキュリティ、ユーザ認証、およびデータ交換が直交しています。この議論のために[4]のセクション9を参照。それは強くIDXPプロファイルを使用したい人は、最初に必要なセキュリティのプロパティを提供していますピア間BEEPセキュリティプロファイルを交渉することをお勧めです。 TLSプロファイルは、トランスポートセキュリティを提供するために使用されるべきです。 IDXPがIDWG通信プロトコルの要件を満たす方法についての説明は、第5章を参照してください。
See Section 2.4 for a discussion of the trust model.
信頼モデルの議論については、2.4節を参照してください。
See Section 5 for IDXP's requirements on application-layer tunneling and the TUNNEL profile specifically. See Section 7 of [3] for a discussion of the security considerations inherent in the use of the TUNNEL profile.
特にアプリケーション層のトンネルとトンネルプロファイルにIDXPの要件については、セクション5を参照してください。 TUNNELプロファイルの使用に固有のセキュリティ上の考慮事項の議論のための[3]のセクション7を参照してください。
At present, the TLS profile is the only BEEP security profile known to meet all of the requirements set forth in Section 5 of [5]. When securing a BEEP session with the TLS profile, the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite offers an acceptable level of security. See Section 5 for a discussion of how IDXP fulfills the IDWG communications requirements through the use of an underlying security profile.
現時点では、TLSプロファイルは、[5]のセクション5に記載された要件のすべてを満たすことが知られている唯一のBEEPセキュリティプロファイルです。 TLSプロファイルをBEEPセッションを確保すると、TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、セキュリティの許容レベルを提供しています。 IDXPは、基本的なセキュリティプロファイルを使用してIDWG通信要件を満たす方法についての議論については、セクション5を参照してください。
The IANA registered "idxp" as a TCP port number as specified in Section 8.2.
8.2節で指定されるようにIANAはTCPポート番号として「idxp」を登録しました。
The IANA maintains a list of:
IANAは、のリストを維持します。
IDXP options, see Section 7.
IDXPオプションは、セクション7を参照してください。
For this list, the IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. As a courtesy to developers of non-standards track IDXP options, the mailing list idxp-discuss@lists.idxp.org may be used to solicit commentary.
このリストは、IESGは、IANAが割り当てを行う前に仕様を検討するために、指定の専門家を割り当てるための責任があります。非標準規格の開発者への礼儀はIDXPオプションを追跡すると、メーリングリストidxp-discuss@lists.idxp.orgは解説を勧誘するために使用することができます。
IANA made the registrations specified in Sections 8.3 and 8.4.
IANAはセクション8.3と8.4で指定された登録をしました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, March 2007.
[2]禁ずる、H.、カレー、D.、およびB.ファインスタイン、 "侵入検知メッセージ交換フォーマット（IDMEF）"、RFC 4765、2007年3月。
[3] New, D., "The TUNNEL Profile", RFC 3620, October 2003.
[3]新しい、D.、 "トンネルのプロフィール"、RFC 3620、2003年10月。
[4] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[4]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[5] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange Requirements", RFC 4766, March 2007.
[5]ウッド、M.とM. Erlinger、 "侵入検知メッセージ交換の要件"、RFC 4766、2007年3月。
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[6]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[7]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、W3C REC-xmlの、2000年10月、<HTTP：/ /www.w3.org/TR/REC-xml>。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[8]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[9] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[9] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
The authors gratefully acknowledge the contributions of Darren New, Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, John C. C. White, and Paul Osterwald.
作者は感謝しダレン新、マーシャルT.ローズ、ロイ・ポロック、ティムBuchheim、マイク・Erlinger、ジョン・C. C.ホワイト、そしてポール・Osterwaldの貢献を認めます。
Authors' Addresses
著者のアドレス
Benjamin S. Feinstein SecureWorks, Inc. PO Box 95007 Atlanta, GA 30347 US
ベンジャミン・S.ファインスタインSecureWorksの、株式会社私書箱95007アトランタ、GA 30347米国
Phone: +1 404 327-6339 Email: bfeinstein@acm.org URI: http://www.secureworks.com/
電話：+1 404 327-6339 Eメール：bfeinstein@acm.org URI：http://www.secureworks.com/
Gregory A. Matthews CSC/NASA Ames Research Center
グレゴリーA.マシューズCSC / NASAエイムズ研究センター
EMail: gmatthew@nas.nasa.gov URI: http://www.nas.nasa.gov/
電子メール：gmatthew@nas.nasa.gov URI：http://www.nas.nasa.gov/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。