Network Working Group B. Feinstein
Request for Comments: 4767 SecureWorks, Inc.
Category: Experimental G. Matthews
CSC/NASA Ames Research Center
March 2007
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）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
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
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配置文件提供身份验证和机密性等功能。因此，在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]消息、非结构化文本和二进制数据的交换。针对入侵检测实体之间交换的安全敏感性质，应使用底层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主要用于交换入侵检测实体创建的数据。IDMEF[2]消息应用于此入侵检测数据的结构化表示，尽管IDXP可用于交换非结构化文本和二进制数据。
There are several BEEP profiles discussed, the first of which we define in this memo:
我们讨论了几个BEEP配置文件，第一个在本备忘录中定义：
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
在本备忘录中，术语“analyzer”和“manager”用于入侵检测消息交换要求[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”在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）[7]的第2.8节中定义。
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对等体。对等点只能成对存在，并且这些对等点通过一个蜂鸣会话与一个或多个为传输数据而打开的蜂鸣通道进行通信。同级人员是经理或分析人员，如[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安全配置文件（有关安全注意事项的讨论，请参阅第11节）。成功协商BEEP安全配置文件后，将交换IDXP问候语并继续进行连接设置。
In the following sequence, the peer 'Alice' initiates an IDXP exchange with the peer 'Bob'.
在以下序列中，对等方“Alice”与对等方“Bob”发起IDXP交换。
Alice Bob
---------------- xport connect(1) ------------------>
<-------------------- greeting ---------------------->
<-------------start security profile(2) ------------->
<-------------------- greeting ---------------------->
<------------------ start IDXP(3) ------------------->
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) “Alice”启动到“Bob”的传输连接，触发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对等点之间，可以是任意数量的代理。出于管理原因，可能需要代理，例如在防火墙上运行以允许受限访问。另一个用途可能是每个公司部门一个代理，它将数据从部门中的analyzer对等方转发到公司范围内的manager对等方。
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调优配置文件可用于创建应用层隧道，该隧道通过代理链透明地转发数据。为此，应使用隧道剖面[3]；有关使用隧道设置应用层隧道的可用选项的更多详细信息，请参见[3]，有关隧道相关安全注意事项的讨论，请参见第11.1节。隧道必须作为创建应用层隧道的调优配置文件提供。隧道剖面必须提供某种形式的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将通过其运行的应用程序层隧道。对等“Alice”通过首先联系“proxy1”，使用IDXP配置文件和实体“Bob”启动BEEP会话的创建。在“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 ------------------------->
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没有立即确认“Alice”发出的启动隧道的请求，而是尝试使用“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) “Bob”确认来自“proxy2”的启动隧道的请求，此确认会传播回“Alice”，以便从“Alice”到“Bob”建立隧道应用层隧道。
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实体之间，可以使用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.
对等点在每个通道上承担客户机或服务器的角色，其中一个作为客户机，另一个作为服务器。对等方作为客户端或服务器的角色取决于该对等方在BEEP会话建立过程中是否担任发起方或侦听方的角色。客户端和服务器分别充当交换数据的源和汇。
In a simple case, an analyzer peer sends data to a manager peer. For example,
在一个简单的情况下，analyzer对等向manager对等发送数据。例如
+----------+ +----------+
| | | |
| |****** BEEP session ******| |
| | | |
| Analyzer | ----- IDXP profile ----> | Manager |
| (Client) | | (Server) |
| | | |
| |**************************| |
| | | |
+----------+ +----------+
+----------+ +----------+
| | | |
| |****** 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 -------> | |
| | | |
| |********************************************| |
| | | |
+----------+ +----------+
+----------+ +----------+
| | | |
| |*************** 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对等方还可以通过发送一个“close”（关闭）元素来选择关闭整个蜂鸣音会话，该元素指示通道0将关闭。
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问候语）。这些都是建议，因此，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]第5节要求的保护的BEEP安全配置文件才能用于保护包含使用IDXP配置文件的频道的BEEP会话。有关TLS配置文件的注册，请参见[4]第3节，这是一个符合[5]第5节要求的BEEP安全配置文件示例。有关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调优配置文件可用于创建应用层隧道，该隧道通过代理链透明地转发数据。为此，应使用隧道剖面[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问候语”元素将蜂鸣声通道一端的分析仪或管理器标识为通道另一端的分析仪或管理器。
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 “Option”元素用于在交换“IDXP问候”元素期间在对等方之间传递可选信道参数。此元素是可选的。
o The "IDMEF-Message" element carries the structured information to be exchanged between the peers.
o “IDMEF消息”元素携带要在对等方之间交换的结构化信息。
The IDXP profile is identified as
IDXP配置文件被标识为
http://idxp.org/beep/profile
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问候”元素必须在对等方之间相互交换。“IDXP问候”元素可能包含在蜂鸣“开始”元素中相应的“profile”元素中。在初始“start”元素中包含“IDXP Greeting”元素与在通道上传递第一条“MSG”消息的语义完全相同。如果频道创建成功，则在发送相应的回复之前，BEEP对等方将处理“IDXP问候”元素，并在回复中包含结果响应。此响应将是“ok”元素或“error”元素。返回哪个元素的选择取决于对等方的本地配置。
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消息必须具有“text/xml”、“text/plain”或“application/octet stream”的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
每个哔哔声对等方使用“MSG”消息发出“IDXP问候”元素。“IDXP问候语”元素可能包含一个或多个“选项”子元素，传递可选的频道参数。然后，每个蜂鸣节点在“RPY”消息中发出“ok”，或在“ERR”消息中发出“error”。（有关“错误”和“正常”要素的定义，请参见[4]第2.3.1节。）“错误”要素可在
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.
当piggy在一个BEEP“profile”元素中返回时，会显示一条“RPY”消息。有关“RPY”消息中发出的“错误”元素的示例，请参见第3.4.1节。根据在交换“IDXP问候”元素期间协商的各个客户机/服务器角色，客户机使用“MSG”消息发送数据。根据MIME内容类型，此数据可能是“IDMEF消息”元素、纯文本或二进制。然后，服务器在“RPY”消息中发出“ok”，或在“ERR”消息中发出“error”。
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问候语”元素用于将蜂鸣声通道一端的分析仪或管理器标识给通道另一端的分析仪或管理器。“IDXP问候语”元素必须包括通道（客户端或服务器）上对等方的角色以及对等方的统一资源标识符（URI）[6]。此外，“IDXP问候语”元素可能包括对等方的完全限定域名（参见[9]）。可能存在一个或多个“选项”子元素。
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”（表示接受）或“error”（表示拒绝）回应。实际上，对等方在通道上的身份和角色以及任何可选通道参数由其发送的最新“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: <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
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问候语”的创建失败可能如下所示：
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: <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.
如果存在，“Option”元素，则必须包含在“IDXP Greeting”元素中。单个“IDXP问候语”元素可能包含一个或多个“选项”子元素。“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问候语”元素本身可能包含一个或多个“选项”元素。“Option”元素具有多个属性并包含任意内容：
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
o “mustUnderstand”属性的存在是可选的，默认值为“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 “localize”属性（其存在是可选的）指定一个或多个语言标记，每个标记标识在将文本诊断返回给发起人时要使用的理想语言标记。
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.
“internal”属性的值是选项的IANA注册名称。如果“internal”属性不存在，“external”属性的值是一个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
“mustUnderstand”属性指定对等方是否可以忽略无法识别的选项。如果“mustUnderstand”属性的值为“true”，并且对等方没有
recognize the option, then an error in processing has occurred. When absent, the value of the "mustUnderstand" attribute is defined to be "false".
识别该选项，则处理过程中发生错误。当不存在时，“mustUnderstand”属性的值被定义为“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选项注册。该选项包含“信道优先级”元素（见第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”元素的“Option”元素来为信道分配优先级。
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”元素有一个名为“priority”的属性，范围为0..2147483647。此属性是必需的。并非巧合，这是可能的蜂鸣声通道号的最大范围。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> ------------------------
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-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:
例如，在通道供应期间交换“IDXP问候语”元素期间，管理器请求分析器为通道分配优先级失败：
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
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: 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问候”元素时，发起对等方可请求远程对等方通过包括包含“streamType”元素的“Option”元素向信道分配流类型。
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”元素有一个名为“type”的属性，可能值为“alert”、“heartbeat”或“config”。此属性是必需的。值“alert”表示通道应分类为用于交换ID警报。“heartbeat”的值表示通道应分类为用于交换心跳消息，如“heartbeat”元素（参见[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问候语”元素期间，分析器成功请求管理器为通道分配流类型：
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
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-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:
例如，在通道供应期间交换“IDXP问候”元素期间，管理器请求分析器为通道分配流类型失败：
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
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: 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本身并不满足每个通信协议要求，而是依赖于底层的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通过BEEP运行，BEEP仅通过可靠的面向连接的传输协议（例如TCP）运行。此外，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.
隧道配置文件[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通过使用适当的底层BEEP安全配置文件支持对等方的相互身份验证。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通过使用适当的基础BEEP安全配置文件来支持机密性。TLS配置文件是提供机密性的安全配置文件的一个示例。必须提供带有TLS\u DHE\u DSS\u和\u 3DES\u EDE\u CBC\u SHA密码套件的TLS配置文件作为提供机密性的机制，并且应使用带有此密码套件的TLS提供机密性。TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA密码套件使用带DSS签名的瞬时Diffie Hellman（DHE）进行密钥交换，使用三重DES（数据加密标准）（3DES）和密码块链（CBC）进行加密。更强的密码套件是可选的。
"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\u DHE\u DSS\u和\u 3DES\u EDE\u CBC\u 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
IDXP通过使用适当的基础BEEP安全配置文件，为每个发送者支持单独的身份验证密钥（即，每个源身份验证）。TLS配置文件是安全配置文件的一个示例，它通过公钥证书的相互身份验证支持每源身份验证。TLS必须作为一种机制提供给每个源
authentication, and TLS SHOULD be used to provide per-source authentication.
应使用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与TLS_DHE_DSS_与_3DES_EDE_CBC_SHA密码套件的使用，并且应将TLS与该密码套件一起使用。为了抵抗DoS攻击，丢弃来自未经身份验证的源的流量是很有帮助的。BEEP对等方必须支持将身份验证与用于创建应用层隧道的任何机制结合使用。特别是，必须提供某种形式的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支持通过使用适当的底层BEEP安全配置文件来抵抗恶意消息复制（即重播攻击）。TLS配置文件是提供抗重放攻击的安全配置文件的一个示例。必须提供带有TLS_DHE_DSS_和_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.
包含：指定包含在“Option”元素中的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
Profile identification: http://idxp.org/beep/profile
Messages exchanged during channel creation: "IDXP-Greeting"
频道创建期间交换的消息：“IDXP问候语”
Messages starting one-to-one exchanges: "IDXP-Greeting", "IDMEF-Message"
开始一对一交换的消息：“IDXP问候语”、“IDMEF消息”
Messages in positive replies: "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
功能：见第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
选项标识：信道优先级
Contains: channelPriority (see Section 9.2)
包含：信道优先级（见第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">
<!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC 4767 IDXP v1.0//EN">
%IDXP; -->
%IDXP；-->
<!-- Includes -->
<!-- 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-Message PUBLIC
"-//IETF//DTD RFC 4765 IDMEF v1.0//EN">
%IDMEF;
%IDMEF；
<!-- Profile Summary
<!-- 简介摘要
BEEP profile http://idxp.org/beep/profile
BEEP profile http://idxp.org/beep/profile
role MSG RPY ERR
==== === === ===
I or L IDXP-Greeting ok error
C IDMEF-Message ok error
-->
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
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 Greeting元素根据每个通道声明发布它的对等方的角色和标识。IDXP问候语元素可能包含一个或多个选项子元素。-->
<!ELEMENT IDXP-Greeting (Option*)>
<!ATTLIST IDXP-Greeting
uri %URI; #REQUIRED
role (client|server) #REQUIRED
fqdn %FQDN; #IMPLIED>
<!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. -->
<!-- Option元素传递IDXP通道选项。请注意，%LOCS实体是从BEEP通道管理DTD导入的。-->
<!ELEMENT Option (ANY)>
<!ATTLIST Option
internal NMTOKEN ""
external %URI; ""
mustUnderstand (true|false) "false"
localize %LOCS; "i-default">
<!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消息元素传递交换的入侵检测信息。此元素在idmef-message.dtd中定义-->
<!-- End of 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
<!-- channelPriority IDXP选项的DTD，自2002-01-08起
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
====== ================ =======
entity syntax/reference example
====== ================ =======
a priority number PRIORITY 0..2147483647 1 -->
优先级编号优先级0..2147483647 1-->
<!ENTITY % PRIORITY "CDATA">
<!ENTITY % PRIORITY "CDATA">
<!ELEMENT channelPriority EMPTY>
<!ATTLIST channelPriority
priority %PRIORITY #REQUIRED>
<!ELEMENT channelPriority EMPTY>
<!ATTLIST channelPriority
priority %PRIORITY #REQUIRED>
<!-- End of DTD -->
<!-- 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 syntax/reference example
====== ================ =======
a stream type
STYPE (alert | heartbeat | config) "alert"
-->
<!ENTITY % STYPE (alert|heartbeat|config)>
<!ENTITY % STYPE (alert|heartbeat|config)>
<!ELEMENT streamType EMPTY>
<!ATTLIST streamType
type %STYPE #REQUIRED>
<!ELEMENT streamType EMPTY>
<!ATTLIST streamType
type %STYPE #REQUIRED>
<!-- End of DTD -->
<!-- End of DTD -->
This section lists the three-digit error codes the IDXP profile may generate.
本节列出了IDXP配置文件可能生成的三位错误代码。
code meaning
==== =======
421 Service not available
(e.g., the peer does not have sufficient resources)
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
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节。有关隧道剖面使用中固有的安全考虑因素的讨论，请参见[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\u DHE\u DSS\u和\u 3DES\u EDE\u CBC\u SHA密码套件提供了可接受的安全级别。有关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-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] 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 47652007年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 30802001年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）：通用语法”，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（第二版）”，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] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年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.
作者衷心感谢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.美国佐治亚州亚特兰大市邮政信箱95007，邮编30347
Phone: +1 404 327-6339
Email: bfeinstein@acm.org
URI: http://www.secureworks.com/
Phone: +1 404 327-6339
Email: bfeinstein@acm.org
URI: http://www.secureworks.com/
Gregory A. Matthews CSC/NASA Ames Research Center
Gregory A.Matthews CSC/NASA艾姆斯研究中心
EMail: gmatthew@nas.nasa.gov
URI: http://www.nas.nasa.gov/
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。