[要約] RFC 4767は、侵入検知交換プロトコル（IDXP）に関する規格であり、異なる侵入検知システム間で情報を交換するためのプロトコルを定義しています。その目的は、異なるベンダーの侵入検知システム間での情報共有と協調を促進することです。
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)
侵入検知交換プロトコル（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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メッセージ要素は、IETFの侵入検知交換形式ワーキンググループ（IDWG）のコンパニオンドキュメントであるRFC 4765「侵入検出メッセージ交換形式（IDMEF）」で説明されています。
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は、接続指向の非同期相互作用のための一般的なアプリケーションプロトコルフレームワークです。認証や機密性などの機能は、他のビーププロファイルを使用して提供されます。したがって、IDXPの多くの側面（たとえば、機密性）がビープフレームワーク内で提供されます。
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]メッセージ、非構造化テキスト、および侵入検知エンティティ間のバイナリデータの交換を提供します。侵入検知エンティティ間の交換のセキュリティに敏感な性質に対処するために、基礎となるビープセキュリティプロファイルを使用して、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.
There are several BEEP profiles discussed, the first of which we define in this memo:
議論されているいくつかのビーププロファイルがありますが、このメモで定義する最初のプロファイルは次のとおりです。
The IDXP Profile
IDXPプロファイル
The TUNNEL Profile [3]
トンネルプロファイル[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プロファイル（[4]のセクション3.1を参照）
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]のコンテキストで使用されます。特に、[5]のセクション2.2は、侵入検知項のコレクションを定義しています。
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」という用語は、ビープ音のコンテキストで使用されます。4]。特に、ビープ音のセクション2.1では、ビープピアが実行できる役割について説明しています。
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に固有であり、ビープ音のコンテキストには存在しないことに注意してください。「侵入検出」という用語は、「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ピアと呼ばれます。ピアはペアでのみ存在することができ、これらのペアは、データを転送するために開いた1つ以上のビープ音チャネルと1つのビープ音セッションで通信します。ピアは、[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ピアは、ビープ音を開始することを伴う可能性のあるビープチャネルを開くことでそうします。必要なセキュリティプロパティを提供するビープセキュリティプロファイルは、最初に交渉する必要があります（セキュリティに関する考慮事項については、セクション11を参照してください）。ビープセキュリティプロファイルの交渉が成功した後、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) 「アリス」は「ボブ」への輸送接続を開始し、ビープ音の挨拶メッセージの交換を引き起こします。
(2) Both entities negotiate the use of a BEEP security profile.
(2) 両方のエンティティは、ビープセキュリティプロファイルの使用を交渉します。
(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ピアのペアの間には、任意の数のプロキシがあります。制限付きアクセスを許可するためにファイアウォールで実行するなど、管理上の理由にプロキシが必要になる場合があります。別の用途は、会社の部門ごとに1つのプロキシであり、部門のアナライザーピアからのデータを全社的なマネージャーピアに転送します。
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.
ビープチューニングプロファイルを使用して、プロキシのチェーンよりもデータを透過的に転送するアプリケーション層トンネルを作成できます。トンネルプロファイル[3]は、この目的のために使用する必要があります。トンネルを使用してアプリケーション層トンネルをセットアップするために利用可能なオプションに関する詳細については、[3]を参照してください。トンネル関連のセキュリティに関する考慮事項については、セクション11.1を参照してください。トンネルは、アプリケーション層トンネルを作成するためのチューニングプロファイルとして提供する必要があります。トンネルプロファイルは、何らかの形のSASL認証の使用を提供する必要があります（[4]のセクション4.1を参照）。トンネルが作成されたら、必要なセキュリティプロパティを提供するビープセキュリティプロファイルを交渉し、その後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プロファイルを使用してビープセッションの作成を開始します。「Alice」と「Proxy1」の間の挨拶交換では、トンネルプロファイルが選択され、その後、トンネルプロファイルの使用が拡張され、「Proxy2」から「BOB」から「」に到達します。
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.
ビープセッションで通信するIDエンティティのペア間で、IDXPプロファイルを使用して1つ以上のビープ音チャネルを開くことができます。必要に応じて、IDXPプロファイルを使用して追加のチャネルを提供するために、追加のビープセッションを確立することができます。ただし、ほとんどの状況では、IDXPプロファイルを使用して追加のチャネルを含む新しいビープセッションをプロビジョニングするのではなく、IDXPプロファイルを使用した追加のチャネルを既存のビープセッション内で開く必要があります。
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つはクライアントとして、もう1つはサーバーとして動作します。クライアントまたはサーバーのピアの役割は、ビープセッションの確立中にピアがイニシエーターまたはリスナーの役割を引き受けたかどうかとは無関係に決定されます。クライアントとサーバーは、データを交換するために、それぞれソースとシンクとして機能します。
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.
ビープセッションで複数のビープチャネルを使用すると、IDXPピア間で送信されたデータの分類と優先順位付けが容易になります。たとえば、マネージャー「M1」が別のマネージャー「M2」にアラートデータを送信すると、異なるカテゴリのアラートを交換するために別のチャネルを開くことを選択できます。「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ピアは、チャネルゼロが閉じていることを示す「閉じる」要素を送信することにより、ビープ音セッション全体を閉じることを選択することもできます。
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は、ビープ音のピアがチャネルを閉じることが許可されている状況とそのためのメカニズムについて、より完全な議論を提供します。
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.
アプリケーション層トンネルおよび/またはビープセキュリティプロファイルのプロビジョニングのオーバーヘッドにより、IDXPチャンネルを含むビープセッションが長寿命になると予想されます。さらに、データが積極的に交換されていない場合でも、IDXPチャネルを開いたままにしておくことにより、IDXPチャネルプロビジョニングの繰り返しオーバーヘッド（つまり、IDXPの挨拶の交換）は回避できます。これらは推奨事項であり、そのため、IDXPピアは、ビープ音セッションおよび/または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.
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プロファイルは、侵入検知エンティティ間で情報を交換するメカニズムを提供します。ビープチューニングプロファイルを使用して、プロキシのチェーンよりもデータを透過的に転送するアプリケーション層トンネルを作成できます。トンネルプロファイル[3]は、この目的のために使用する必要があります。トンネルを使用してアプリケーション層トンネルをセットアップするために利用可能なオプションに関する詳細については、[3]を参照してください。トンネル関連のセキュリティに関する考慮事項については、セクション11.1を参照してください。トンネルは、アプリケーション層トンネルを作成するためのチューニングプロファイルとして提供する必要があります。トンネルプロファイルは、何らかの形の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.
o 「IDXP-Greeting」要素は、ビープ音チャネルの一方の端にあるアナライザーまたはマネージャーを、チャンネルのもう一方の端のアナライザーまたはマネージャーに識別します。
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.
o 「idmef-message」要素には、ピア間で交換される構造化された情報が搭載されています。
The IDXP profile is identified as
IDXPプロファイルはとして識別されます
http://idxp.org/beep/profile
in the BEEP "profile" element during channel creation.
チャネル作成中のビープ音の「プロファイル」要素。
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-Greeting」要素は、ピア間で相互に交換する必要があります。「IDXP-Greeting」要素は、BEEP「Start」要素の対応する「プロファイル」要素内に含まれる場合があります。最初の「開始」要素に「idxp-greeting」要素を含めると、チャネル上の最初の「msg」メッセージとまったく同じセマンティクスが渡されます。チャネル作成が成功した場合、対応する返信を送信する前に、ビープピアは「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].
プロファイル内のビープメッセージには、「テキスト/XML」、「テキスト/プレーン」、または「アプリケーション/オクテットストリーム」のMIMEコンテンツタイプ[8]が必要です。個々の要素の構文は、このドキュメントのセクション9.1と[2]のセクション4で指定されています。
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.
各ビープピアは、「MSG」メッセージを使用して「IDXP-Greeting」要素を発行します。「idxp-greeting」要素には、1つ以上の「オプション」サブエレメントが含まれる場合があり、オプションのチャネルパラメーターを伝達します。各ビープピアは、「RPY」メッセージで「OK」または「ERR」メッセージで「エラー」を発行します。（[エラー]および「OK」要素の定義については、[4]のセクション2.3.1を参照してください。）「エラー」要素は、ビープ音のプロファイル「プロファイル」要素内で貯金箱に包まれたときに「rpy」メッセージ内で発行される場合があります。。「rpy」メッセージ内で発行されている「エラー」要素の例については、セクション3.4.1を参照してください。「IDXPグリート」要素の交換中に交渉されたそれぞれのクライアント/サーバーの役割に基づいて、クライアントは「MSG」メッセージを使用してデータを送信します。MIMEコンテンツタイプに応じて、このデータは「idmef-message」要素、プレーンテキスト、またはバイナリである場合があります。サーバーは、「RPY」メッセージで「OK」または「ERR」メッセージで「エラー」を発行します。
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-Greeting」要素は、ビープチャネルの一方の端にあるアナライザーまたはマネージャーを、チャネルのもう一方の端のアナライザーまたはマネージャーに識別するのに役立ちます。「idxp-greeting」要素には、ピアのチャネル（クライアントまたはサーバー）でのピアの役割（クライアントまたはサーバー）と均一なリソース識別子（URI）[6]を含める必要があります。さらに、「IDXP-Greeting」要素には、ピアの完全に適格なドメイン名（[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-greeting」要素は、いつでもピアによって送信される場合があります。「IDXPグリート」を受け取るピアは、「OK」（受け入れを示す）または「エラー」（拒否を示す）で応答する必要があります。チャネル上のピアの身元と役割とオプションのチャネルパラメーターは、実際には、「OK」と回答された最新の「IDXPグリート」によって指定されます。
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-Greeting」は（「エラー」要素を使用して）拒否される場合があります。これらには、認証障害、指定された役割の下で接続する許可の欠如、不十分な暗号スイートの交渉、または理解する必要があるが認識されていないチャネルオプションの存在が含まれますが、これらに限定されません。
For example, a successful creation with an embedded "IDXP-Greeting" might look like this:
たとえば、埋め込まれた「idxp-greeting」を備えた成功した作成は次のようになるかもしれません。
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
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
A creation with an embedded "IDXP-Greeting" that fails might look like this:
失敗する「idxp-greeting」が埋め込まれた作成は、次のように見えるかもしれません。
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
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-greeting」要素内に含める必要があります。個々の「idxp-greeting」要素には、1つ以上の「オプション」サブエレメントが含まれる場合があります。「IDXP-Greeting」要素内の各「オプション」要素は、ネゴシエートされているチャネル上の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-MESSAGE」要素には、ピア間で交換される情報が含まれています。この要素の定義については、[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-greeting」要素内に含まれています。「idxp-greeting」要素自体には、1つ以上の「オプション」要素が含まれる場合があります。「オプション」要素にはいくつかの属性があり、任意のコンテンツが含まれています。
o the "internal" and the "external" attributes, exactly one of which MUST be present, uniquely identify the option;
o 「内部」と「外部」属性は、そのうちの1つが存在する必要があり、オプションを一意に識別します。
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
o 存在がオプションであり、デフォルト値が「false」である「必須」属性は、オプションが認識されていない場合、処理のエラーを引き起こす必要があるかどうかを指定します。と
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 存在がオプションである「ローカライズ」属性は、1つ以上の言語トークンを指定し、それぞれがテキスト診断がオリジネーターに返される場合に使用される望ましい言語タグを識別します。
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".
「必須」属性は、ピアが認識されていない場合、ピアがオプションを無視する可能性があるかどうかを指定します。「必須」属性の値が「真」である場合、ピアがオプションを認識しない場合、処理のエラーが発生しました。不在の場合、「必須」属性の値は「false」と定義されます。
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-Greeting」要素を送信する場合、発信するピアは、「チャネルプリアリティ」要素を含む「オプション」要素を含めることにより、リモートピアにチャネルの優先度を割り当てることを要求する場合があります。
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の「優先度」という名前の1つの属性があります。この属性が必要です。偶然ではありませんが、これは可能なビープチャネル番号の最大範囲です。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-Greeting」要素を交換している間、アナライザーは、マネージャーがチャネルの優先順位を割り当てることを正常に要求します。
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
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:
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
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-Greeting」要素を送信する場合、発信中のピアは、リモートピアが「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」要素には、「タイプ」という名前の1つの属性があり、「アラート」、「ハートビート」、または「config」の値があります。この属性が必要です。「アラート」の値は、チャネルがIDアラートの交換に使用されるものとして分類されるべきであることを示します。「ハートビート」の値は、「ハートビート」要素などのハートビートメッセージの交換にチャネルを分類する必要があることを示しています（[2]のセクション4を参照）。「config」の値は、構成メッセージの交換に使用されるものとしてチャネルを分類する必要があることを示します。
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-Greeting」要素を交換している間、アナライザーは、マネージャーがストリームタイプをチャネルに割り当てることを正常に要求します。
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
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:
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
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自体は、各通信プロトコルの要件を満たすのではなく、基礎となるビーププロトコルとさまざまなビーププロファイルに依存しています。
"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など）でのみ動作します。さらに、ビープピアは、ピア間のエンドツーエンドの信頼性を提供する単純なリクエスト応答プロトコルを使用して通信します。
"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.
トンネルプロファイル[3]は、ファイアウォール全体の動作を可能にするために、アプリケーション層トンネルを作成するためのオプションとして提供する必要があります。トンネルプロファイルは、アプリケーション層トンネルを提供するために使用する必要があります。アプリケーション層トンネルの作成中にホストを認証する機能は、そのようなトンネルを作成するために選択されたメカニズムによって提供される必要があります。したがって、ファイアウォールは、保護されたネットワークへのトンネルを試みるすべてのホストを認証するように構成できます。トンネルプロファイルを使用する場合、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は、適切な基礎となるビープ音セキュリティプロファイルを使用して、ピアの相互認証をサポートします。TLSプロファイルとSASLプロファイルファミリーのメンバー（[4]のセクション4.1を参照）は、通信IDコンポーネントのアイデンティティを認証するために使用できるセキュリティプロファイルの例です。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は、適切な基礎となるビープ音セキュリティプロファイルを使用して、機密性をサポートします。TLSプロファイルは、機密性を提供するセキュリティプロファイルの例です。TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Cipherスイートを使用したTLSプロファイルは、機密性を提供するメカニズムとして提供する必要があります。この暗号スイートでTLSを使用して機密性を提供する必要があります。TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA CIPHESスイートは、キーエクスチェンジおよびトリプルDES（データ暗号化標準）（3DE）および暗号ブロックチェーン（CBC）のためのDSS署名を備えたEphemeral Diffie-Hellman（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.
"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は、適切な基礎となるビープセキュリティプロファイルを使用して、各送信者の個別の認証キー（つまり、ソースごとの認証）をサポートします。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は、適切な基礎となるビープ音セキュリティプロファイルを使用して、サービス拒否（DOS）攻撃に対する抵抗をサポートします。IDXPプロファイルを提供するビープピアは、TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA CIPHESスイートでTLSの使用を提供する必要があり、その暗号スイートでTLSを使用する必要があります。DOSの攻撃に抵抗するには、認識されていないソースから生じるトラフィックを破棄することが役立ちます。ビープピアは、アプリケーション層トンネルの作成に使用されるあらゆるメカニズムと組み合わせて、認証の使用をサポートする必要があります。特に、トンネルプロファイルの使用に認証を提供するために、何らかの形のSASL認証（[4]のセクション4.1を参照）の使用を提供する必要があります。トンネルプロファイルの使用におけるセキュリティに関する考慮事項の議論については、[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は、適切な基礎となるビープセキュリティプロファイルを使用して、メッセージの悪意のある複製（つまり、リプレイ攻撃）に対する抵抗をサポートします。TLSプロファイルは、リプレイ攻撃に対する抵抗を提供するセキュリティプロファイルの例です。TLS_DHE_DSS_WITH_3DES_EDE_EDE_CBC_SHA Cipherスイートを使用したTLSプロファイルは、リプレイ攻撃に対する抵抗を提供するメカニズムとして提供する必要があります。TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA CIPHES SUITEは、Cipher-Block Chaining（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-greeting」
Messages starting one-to-one exchanges: "IDXP-Greeting", "IDMEF-Message"
1対1の交換を開始するメッセージ：「idxp-greeting」、「idmef-message」
Messages in positive replies: "ok"
肯定的な返信のメッセージ：「OK」
Messages in negative replies: "error"
否定的な返信のメッセージ：「エラー」
Messages in one-to-many exchanges: none
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 Use of Broadcast/Multicast: none
機能：セクション3.4の使用/マルチキャストの使用：なし
Proposed Name: Intrusion Detection Exchange Protocol
提案された名前：侵入検知交換プロトコル
Short name: idxp
短い名前：idxp
Contact Information: see the "Authors' Addresses" section of this memo
連絡先情報：このメモの「著者のアドレス」セクションを参照してください
Option Identification: 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
<！-IDXPプロファイルのDTD
Refer to this DTD as:
このDTDを次のように参照してください。
<!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC 4767 IDXP v1.0//EN">
%IDXP; -->
％IDXP; - >
<!-- Includes -->
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">
%BEEP;
％ビープ;
<!ENTITY % IDMEF-Message PUBLIC "-//IETF//DTD RFC 4765 IDMEF v1.0//EN">
<！entity％idmef-message public " - // ietf // dtd rfc 4765 idmef v1.0 // en">
%IDMEF;
％idmef;
<!-- Profile Summary
<！ - プロファイルの概要
BEEP profile http://idxp.org/beep/profile
ビーププロファイルhttp://idxp.org/beep/profile
role MSG RPY ERR
==== === === ===
I or L IDXP-Greeting ok error
C IDMEF-Message ok error
-->
<!-- 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">
<!-- 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>
<!-- The Option element conveys an IDXP channel option. Note that the %LOCS entity is imported from the BEEP Channel Management DTD. -->
<！ - オプション要素は、IDXPチャネルオプションを伝達します。％locsエンティティは、ビープチャネル管理DTDからインポートされていることに注意してください。 - >
<!ELEMENT Option (ANY)>
<!ATTLIST Option
internal NMTOKEN ""
external %URI; ""
mustUnderstand (true|false) "false"
localize %LOCS; "i-default">
<!-- 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 -->
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; -->
％IDXP-CHANNELPRIORITY; - >
<!-- Entity Definitions
<！ - エンティティ定義
entity syntax/reference example
====== ================ =======
a priority number PRIORITY 0..2147483647 1 -->
優先数の優先度0..2147483647 1->
<!ENTITY % PRIORITY "CDATA">
<!ELEMENT channelPriority EMPTY>
<!ATTLIST channelPriority
priority %PRIORITY #REQUIRED>
<!-- End of 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)>
<!ELEMENT streamType EMPTY>
<!ATTLIST streamType
type %STYPE #REQUIRED>
<!-- End of 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)
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
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
534 Authentication mechanism insufficient (e.g., cipher suite too weak, sequence exhausted)
534認証メカニズムが不十分です（たとえば、暗号スイートが弱すぎる、シーケンスが使い果たされました）
535 Authentication failure
535認証障害
537 Action not authorized for user
550 Requested action not taken (e.g., peer could be contacted, but malformed greeting or no IDXP profile advertised)
553 Parameter invalid
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プロファイルはビープ音のプロファイルです。ビープ音では、輸送セキュリティ、ユーザー認証、およびデータ交換は直交です。これについての議論については、[4]のセクション9を参照してください。IDXPプロファイルを使用したい人は、最初に必要なセキュリティプロパティを提供するピア間のビープセキュリティプロファイルをネゴシエートすることを強くお勧めします。TLSプロファイルは、輸送セキュリティを提供するために使用する必要があります。IDXPがIDWG通信プロトコルの要件をどのように満たすかについての議論については、セクション5を参照してください。
See Section 2.4 for a discussion of the trust model.
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.
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に記載されているすべての要件を満たすことで知られている唯一のビープセキュリティプロファイルです。TLSプロファイルでビープセッションを保護する場合、TLS_DHE_DSS_WITH_WITH_WITH_WITH_EDES_EDE_CBC_SHA CIPHESスイートは、許容可能なレベルのセキュリティを提供します。基礎となるセキュリティプロファイルを使用して、IDXPがIDWG通信要件をどのように満たすかについての議論については、セクション5を参照してください。
The IANA registered "idxp" as a TCP port number as specified in Section 8.2.
IANAは、セクション8.2で指定されているように、「IDXP」をTCPポート番号として登録しました。
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-ディスク@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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, March 2007.
[2] Debar、H.、Curry、D。、およびB. Feinstein、「侵入検知メッセージ交換形式（IDMEF）」、RFC 4765、2007年3月。
[3] New, D., "The TUNNEL Profile", RFC 3620, October 2003.
[3] New、D。、「トンネルプロファイル」、RFC 3620、2003年10月。
[4] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[4] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[5] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange Requirements", RFC 4766, March 2007.
[5] Wood、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Bray、T.、Paoli、J.、Sperberg-Mcqueen、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]
[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.
著者は、Darren New、Marshall T. Rose、Roy Pollock、Tim Buchheim、Mike Erlinger、John C. C. White、Paul Osterwaldの貢献に感謝しています。
Authors' Addresses
著者のアドレス
Benjamin S. Feinstein SecureWorks, Inc. PO Box 95007 Atlanta, GA 30347 US
Benjamin S. Feinstein Secureworks、Inc。PO Box 95007 Atlanta、GA 30347 US
Phone: +1 404 327-6339
Email: 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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。