Network Working Group D. New
Request for Comments: 3620 October 2003
Category: Standards Track
Network Working Group D. New
Request for Comments: 3620 October 2003
Category: Standards Track
The TUNNEL Profile
隧道剖面图
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.
本备忘录描述了一个Blocks Extensible Exchange Protocol（BEEP）配置文件，该配置文件允许BEEP对等方充当应用层代理。它允许授权用户通过防火墙访问服务。
Table of Contents
目录
1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 One-Hop Example. . . . . . . . . . . . . . . . . . . . . . 3
2.2 Two-Hop Example. . . . . . . . . . . . . . . . . . . . . . 4
2.3 Failed Set-Up Example. . . . . . . . . . . . . . . . . . . 5
2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . 5
2.5 Profile Example. . . . . . . . . . . . . . . . . . . . . . 6
2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . 8
3. Message Syntax. . . . . . . . . . . . . . . . . . . . . . . . 9
4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Reply Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . 16
A.2 Registration: A System (Well-Known) TCP
port number for TUNNEL . . . . . . . . . . . . . . . . . . 16
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 One-Hop Example. . . . . . . . . . . . . . . . . . . . . . 3
2.2 Two-Hop Example. . . . . . . . . . . . . . . . . . . . . . 4
2.3 Failed Set-Up Example. . . . . . . . . . . . . . . . . . . 5
2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . 5
2.5 Profile Example. . . . . . . . . . . . . . . . . . . . . . 6
2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . 8
3. Message Syntax. . . . . . . . . . . . . . . . . . . . . . . . 9
4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Reply Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . 16
A.2 Registration: A System (Well-Known) TCP
port number for TUNNEL . . . . . . . . . . . . . . . . . . 16
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
The TUNNEL profile provides a mechanism for cooperating BEEP peers to form an application-layer tunnel. The peers exchange "tunnel" elements that specify a source route, with the outermost element being stripped off and used to decide the next hop. The innermost, empty "tunnel" element tells the final destination that it is, indeed, the final destination. The term "proxy" is used to refer any of the BEEP peers other than the initiator and the final destination.
隧道配置文件提供了一种机制，用于协作BEEP对等点以形成应用层隧道。对等点交换指定源路由的“隧道”元素，最外层的元素被剥离并用于决定下一跳。最里面的空“tunnel”元素告诉最终目的地它确实是最终目的地。术语“代理”用于指除发起方和最终目的地之外的任何BEEP对等方。
In one use of this profile, a BEEP peer implementing the TUNNEL profile is co-resident with a firewall. An initiating machine inside the firewall makes a connection to the proxy, then ask that proxy to make a connection to an endpoint outside the firewall. Once this connection is established, the proxy tells the outside endpoint that it will be tunneling. If the outside machine agrees, the proxy "gets out of the way," simply passing octets transparently, and both the initiating and terminating machines perform a "tuning reset," not unlike the way starting a TLS negotiation discards cached session state and starts anew.
在该配置文件的一次使用中，实现隧道配置文件的BEEP对等机与防火墙共存。防火墙内的发起计算机连接到代理，然后要求该代理连接到防火墙外的端点。一旦建立了此连接，代理将通知外部端点它将进行隧道传输。如果外部机器同意，代理“让路”，只是透明地传递八位字节，启动和终止机器都执行“调优重置”，这与启动TLS协商丢弃缓存会话状态并重新启动的方式不同。
Another use for this profile is to limit connections to outside servers based on the user identity negotiated via SASL. For example, a manager may connect to a proxy, authenticate herself with SASL, then instruct the proxy to tunnel to an information service restricted to managers. Since each proxy knows the identity of the next proxy being requested, it can refuse to tunnel connections if inadequate levels of authorization have been established. It is also possible to use the TUNNEL profile to anonymize the true source of a BEEP connection, in much the way a NAT translates IP addresses. However, detailed discussion of such uses is beyond the scope of this document.
此配置文件的另一个用途是根据通过SASL协商的用户身份限制到外部服务器的连接。例如，经理可以连接到代理，使用SASL对自己进行身份验证，然后指示代理通过隧道连接到仅限经理使用的信息服务。由于每个代理都知道被请求的下一个代理的身份，因此如果建立的授权级别不足，它可以拒绝隧道连接。也可以使用隧道配置文件来匿名化BEEP连接的真正来源，就像NAT转换IP地址一样。然而，对此类用途的详细讨论超出了本文件的范围。
Once both endpoint machines are connected, the tunneling proxy machine does no further interpretation of the data. In particular, it does not look for any BEEP framing. The two endpoint machines may therefore negotiate TLS between them, passing certificates appropriate to the endpoints rather than the proxy, with the assurance that even the proxy cannot access the information exchanged.
一旦连接了两个端点机器，隧道代理机器就不会进一步解释数据。特别是，它不寻找任何蜂鸣音帧。因此，两个端点机器可以在它们之间协商TL，传递适合端点而不是代理的证书，并保证即使代理也无法访问交换的信息。
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]中的描述进行解释。
While the semantics described in Section 4 may seem complex, the results are actually relatively simple. A few examples will show the operation and use of this profile. In these examples, the machine attempting to establish the connection is named "initial", while the intermediate proxies are "proxy1" or "proxy2", and the machine with the service that "initial" wishes to access is called "final". The examples also assume that the BEEP framework [2] is implemented on top of TCP [3], or some other mapping where one transport connection carries all channels.
虽然第4节中描述的语义可能看起来很复杂，但结果实际上相对简单。几个示例将显示此配置文件的操作和使用。在这些示例中，尝试建立连接的机器名为“initial”，而中间代理为“proxy1”或“proxy2”，具有“initial”希望访问的服务的机器称为“final”。这些示例还假设BEEP框架[2]是在TCP[3]或某个其他映射上实现的，其中一个传输连接承载所有通道。
A simple one-hop connection through a single proxy is illustrated first.
首先说明了通过单个代理的简单单跳连接。
initial proxy1 final
----- xport connect ----->
<------- greeting -------->
--- start TUNNEL [1] ---->
----- xport connect ------>
<-------- greeting -------->
---- start TUNNEL [2] ---->
<---------- ok ------------
<------- ok -------------- [3]
<------------- greeting [4]-------------------------->
initial proxy1 final
----- xport connect ----->
<------- greeting -------->
--- start TUNNEL [1] ---->
----- xport connect ------>
<-------- greeting -------->
---- start TUNNEL [2] ---->
<---------- ok ------------
<------- ok -------------- [3]
<------------- greeting [4]-------------------------->
Notes:
笔记：
[1] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='604'>
<tunnel/>
</tunnel>
[1] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='604'>
<tunnel/>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel/>
[2] The TUNNEL element looks like this:
<tunnel/>
[3] At this point, immediately after sending the <ok/> element, proxy1 starts passing octets transparently. It continues to do so until either transport connection is closed, after which it closes the other.
[3] 此时，在发送<ok/>元素之后，proxy1立即开始透明地传递八位字节。它将继续执行此操作，直到其中一个传输连接关闭，然后关闭另一个传输连接。
[4] This greeting may include the TLS profile, allowing initial and final to communicate without proxy1 understanding or interfering without being caught.
[4] 此问候语可能包括TLS配置文件，允许初始和最终通信，而无需proxy1理解或干扰，而不会被捕获。
The second example shows the initiator connecting to its proxy, that proxy connecting to another, and finally that second proxy finding a service outside.
第二个示例显示了启动器连接到其代理，该代理连接到另一个代理，最后第二个代理在外部查找服务。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
笔记：
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
</tunnel>
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
[3] The TUNNEL element looks like this:
<tunnel/>
[3] The TUNNEL element looks like this:
<tunnel/>
[4] Proxy2 starts passing octets transparently after sending the <ok/>.
[4] Proxy2在发送<ok/>后开始透明地传递八位字节。
[5] Proxy1 starts passing octets transparently after sending the <ok/>.
[5] Proxy1在发送<ok/>后开始透明地传递八位字节。
The third example shows the initiator connecting through two proxys, the second proxy attempting to connect to the specified service and finding the destination is not a BEEP server. (Of course, specifying the telnet service can be expected to lead to this error.) The same would result if the destination did not support the TUNNEL profile.
第三个示例显示了启动器通过两个代理进行连接，第二个代理尝试连接到指定的服务并查找目标不是BEEP服务器。（当然，指定telnet服务可能会导致此错误。）如果目标不支持隧道配置文件，也会产生同样的结果。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
----- xport close ---->
<---- <error> -------
--- xport close ---->
<---- <error> ------
--- xport close ---> [3]
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
----- xport close ---->
<---- <error> -------
--- xport close ---->
<---- <error> ------
--- xport close ---> [3]
Notes:
笔记：
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
</tunnel>
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
[3] This close is optional. "Initial" may also send another <tunnel> element, attempting to contact a different server, for example.
[3] 此关闭是可选的。“Initial”还可能发送另一个<tunnel>元素，例如，试图联系不同的服务器。
This example shows the initiator connecting through two proxys, the second proxy attempting to connect to the specified service and accepting that the destination is not a BEEP server. The difference at the protocol level is two-fold: The "initial" machine does not include the innermost "tunnel" element, and the final proxy ("proxy2") therefore does not expect a BEEP greeting.
此示例显示启动器通过两个代理进行连接，第二个代理尝试连接到指定的服务，并接受目标不是BEEP服务器。协议级别上的差异有两个方面：“初始”机器不包括最里面的“隧道”元素，因此最终代理（“proxy2”）不需要发出蜂鸣音。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
<------ <ok> ------- [3]
<----- login: ------ [4]
<------ <ok> --------- [3]
<----- login: -------- [4] [5]
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
<------ <ok> ------- [3]
<----- login: ------ [4]
<------ <ok> --------- [3]
<----- login: -------- [4] [5]
Notes:
笔记：
[1] The TUNNEL element looks like this: <tunnel fqdn='proxy2.example.com' port='604'> <tunnel fqdn='final.example.com' svc='_telnet._tcp'> </tunnel> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[1] 隧道元素如下所示：<TUNNEL fqdn='proxy2.example.com'port='604'><TUNNEL fqdn='final.example.com'svc=''u telnet.\u tcp'></TUNNEL></TUNNEL>注意缺少最里面的no属性<TUNNEL>元素。
[2] The TUNNEL element looks like this: <tunnel fqdn='final.example.com' srv='_telnet._tcp'> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[2] TUNNEL元素如下所示：<TUNNEL fqdn='final.example.com'srv=''\u telnet.\u tcp'></TUNNEL>注意，缺少最里面的no属性<TUNNEL>元素。
[3] Each proxy starts transparently forwarding octets after this <ok>.
[3] 每个代理在此<ok>之后开始透明地转发八位字节。
[4] Each proxy forwards any data it received from the final host, even if that data arrived before the <ok> was sent.
[4] 每个代理转发它从最终主机收到的任何数据，即使该数据在<ok>发送之前到达。
[5] After receiving the "ok" message, the "initial" peer can expect raw, non-BEEP data to be sent to and received from the "final" machine.
[5] 在接收到“ok”消息后，“初始”对等方可以期望原始的、非蜂鸣的数据被发送到“final”机器并从中接收。
This example shows the initiator connecting through two proxys. The initial machine knows there is a server offering the SEP2 profile somewhere beyond proxy1, but it need not know where. Proxy1 has been locally configured to know that all SEP2 servers are beyond proxy2. Proxy2 has been locally configured to chose "final" as the server of choice for SEP2 services. Note that "final" does not necessarily need to offer the requested profile in its initial greeting.
此示例显示启动器通过两个代理进行连接。最初的机器知道在proxy1之外的某个地方有一台服务器提供SEP2配置文件，但它不需要知道在哪里。Proxy1已在本地配置为知道所有SEP2服务器都在proxy2之外。Proxy2已在本地配置为选择“final”作为SEP2服务的首选服务器。请注意，“final”不一定需要在其初始问候语中提供所请求的概要文件。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
笔记：
[1] The TUNNEL element looks like this: <tunnel profile="http://xml.resource/org/profiles/SEP2"/> Note the lack of an innermost no-attribute <tunnel> element.
[1] 隧道元素如下所示：<TUNNEL profile=”http://xml.resource/org/profiles/SEP2“/>请注意缺少最里面的no attribute<tunnel>元素。
[2] Proxy1 maps this to <tunnel fqdn="proxy2.example.com" port="604"> <tunnel profile="http://xml.resource/org/profiles/SEP2"/> </tunnel> based on local configuration, then processes the new element, stripping off the outer element and routing <tunnel profile="http://xml.resource/org/profiles/SEP2"/> to proxy2.
[2] Proxy1将此映射到<tunnel fqdn=“proxy2.example.com”port=“604”><tunnel profile=”http://xml.resource/org/profiles/SEP2“/></tunnel>基于本地配置，然后处理新元素，剥离外部元素并布线<tunnel profile=”http://xml.resource/org/profiles/SEP2“/>到proxy2。
[3] Proxy2 receives the TUNNEL element with simply the SEP2 URI specified. Local provisioning maps this to <tunnel fqdn='final.example.com' srv='_beep._tcp'> <tunnel/> </tunnel> Note the presence of an innermost no-attribute <tunnel> element. Proxy2 then strips the outermost element, looking up the appropriate address and port, and forwards the <tunnel/> element to the final machine.
[3] Proxy2只接收指定了SEP2 URI的隧道元素。本地配置将此映射到<tunnel fqdn='final.example.com'srv=''\u beep.\u tcp'><tunnel/></tunnel>注意，存在最里面的no attribute<tunnel>元素。Proxy2然后剥离最外层的元素，查找适当的地址和端口，并将<tunnel/>元素转发给最终的机器。
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[4] Proxy2在此<ok>之后开始透明地转发八位字节。
[5] Proxy1 starts transparently forwarding octets after this <ok>.
[5] Proxy1在此<ok>之后开始透明地转发八位字节。
This example shows the initiator connecting through two proxys. The initial machine knows there is a server known as "operator console" somewhere beyond proxy1, but it needs not know where. Proxy1 has been locally configured to know that "operator console" is beyond proxy2. Proxy2 has been locally configured to use "final" as "operator console". This example is almost identical to the previous example, except that "endpoint" is intended to route to a particular server, while "profile" is intended to route to a particular service. Otherwise, these two attributes are very similar.
此示例显示启动器通过两个代理进行连接。最初的机器知道在proxy1之外的某个地方有一个名为“操作员控制台”的服务器，但它不需要知道在哪里。Proxy1已在本地配置为知道“操作员控制台”在proxy2之外。Proxy2已在本地配置为使用“最终”作为“操作员控制台”。此示例与上一个示例几乎相同，只是“端点”用于路由到特定服务器，而“概要文件”用于路由到特定服务。否则，这两个属性非常相似。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
笔记：
[1] The TUNNEL element looks like this: <tunnel endpoint="operator console"> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[1] TUNNEL元素如下所示：<TUNNEL endpoint=“operator console”></TUNNEL>注意缺少最里面的no属性<TUNNEL>元素。
[2] Proxy1 maps this to <tunnel fqdn="proxy2.example.com" port="604"> <tunnel endpoint="operator console"> </tunnel> </tunnel> based on local configuration, then processes the new element, stripping off the outer element and routing <tunnel endpoint="operator console"> </tunnel> to proxy2.
[2] Proxy1基于本地配置将此映射到<tunnel fqdn=“proxy2.example.com”port=“604”><tunnel endpoint=“operator console”></tunnel></tunnel>，然后处理新元素，剥离外部元素并将<tunnel endpoint=“operator console”></tunnel>路由到proxy2。
[3] Proxy2 receives the TUNNEL element with simply the endpoint specified. Local provisioning maps this to <tunnel fqdn='final.example.com' srv='_beep._tcp'> <tunnel/> </tunnel> Note the presence of an innermost no-attribute <tunnel> element. Proxy2 then strips the outermost element, looking up the appropriate address and port, and forwards the <tunnel/> element to the final machine.
[3] Proxy2只接收指定端点的隧道元素。本地配置将此映射到<tunnel fqdn='final.example.com'srv=''\u beep.\u tcp'><tunnel/></tunnel>注意，存在最里面的no attribute<tunnel>元素。Proxy2然后剥离最外层的元素，查找适当的地址和端口，并将<tunnel/>元素转发给最终的机器。
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[4] Proxy2在此<ok>之后开始透明地转发八位字节。
[5] Proxy1 starts transparently forwarding octets after this <ok>.
[5] Proxy1在此<ok>之后开始透明地转发八位字节。
The only element defined in this profile is the "tunnel" element. It is described in the following DTD, with additional limitations as described afterwards.
此配置文件中定义的唯一元素是“隧道”元素。下面的DTD中对其进行了描述，后面介绍了其他限制。
<!-- DTD for the TUNNEL Profile, as of 2001-02-03
<!-- 隧道剖面的DTD，自2001-02-03起
Refer to this DTD as:
将此DTD称为：
<!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" "">
%TUNNEL;
-->
<!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" "">
%TUNNEL;
-->
<!-- TUNNEL messages
<!-- 隧道消息
role MSG RPY
====== === ===
I or L TUNNEL +: ok
-: error
-->
role MSG RPY
====== === ===
I or L TUNNEL +: ok
-: error
-->
<!ELEMENT tunnel (tunnel?)>
<!ATTLIST tunnel
fqdn CDATA #IMPLIED
ip4 CDATA #IMPLIED
ip6 CDATA #IMPLIED
port CDATA #IMPLIED
srv CDATA #IMPLIED
profile CDATA #IMPLIED
endpoint CDATA #IMPLIED
>
<!ELEMENT tunnel (tunnel?)>
<!ATTLIST tunnel
fqdn CDATA #IMPLIED
ip4 CDATA #IMPLIED
ip6 CDATA #IMPLIED
port CDATA #IMPLIED
srv CDATA #IMPLIED
profile CDATA #IMPLIED
endpoint CDATA #IMPLIED
>
The format of the "fqdn" attribute is a fully qualified domain name, such as "proxy.example.com". The format of the "ip4" attribute is four sets of decimal numbers separated by periods, such as "10.23.34.45". The format of the "ip6" attribute is as specified in RFC2373 [4]. The format of the "port" attribute is a decimal number between one and 65535, inclusive. The format of the "srv" attribute is a pair of identifiers each starting with an underline and separated by a period, such as "_sep._tcp". The format of the "profile" attribute is a URI [5]. The format of the "endpoint" attribute is any string that may appear as an attribute value.
“fqdn”属性的格式是完全限定的域名，例如“proxy.example.com”。“ip4”属性的格式是四组由句点分隔的十进制数字，如“10.23.34.45”。“ip6”属性的格式如RFC2373[4]所述。“端口”属性的格式是一个介于1和65535（含1和65535）之间的十进制数。“srv”属性的格式是一对标识符，每个标识符以下划线开头，并以句点分隔，如“\u sep.\u tcp”。“profile”属性的格式是URI[5]。“endpoint”属性的格式是任何可能显示为属性值的字符串。
The only allowable combinations of attributes are as follows:
唯一允许的属性组合如下所示：
o fqdn + port;
o fqdn+端口；
o fqdn + srv;
o fqdn+srv；
o fqdn + srv + port;
o fqdn+srv+端口；
o ip4 + port;
o ip4+端口；
o ip6 + port;
o ip6+端口；
o profile, but only on the innermost element;
o 轮廓，但仅在最里面的元素上；
o endpoint, but only on the innermost element; or,
o 端点，但仅在最里面的元素上；或
o no attributes, but only on the innermost element.
o 没有属性，但仅在最里面的元素上。
When a TUNNEL channel is started, the listener expects a "tunnel" element from the initiator, either in the "start" element on channel zero or on the new channel created. As usual, if it arrives on channel zero, it is processed before the reply is returned.
当隧道通道启动时，侦听器希望发起者提供一个“隧道”元素，无论是在通道0上的“开始”元素中，还是在创建的新通道上。通常，如果它到达通道0，则在返回应答之前对其进行处理。
In either case, the outermost "tunnel" element is examined. If it has no attributes, then this peer is hosting the BEEP service that the initiator wishes to use. In this case, the listener performs a tuning reset:
在任何一种情况下，都要检查最外层的“隧道”元素。如果没有属性，则该对等方承载发起方希望使用的BEEP服务。在这种情况下，侦听器执行调整重置：
o All channels, including channel zero, are implicitly closed.
o 所有通道（包括通道零）均隐式关闭。
o Any previously cached information about the BEEP session is discarded.
o 任何以前缓存的关于BEEP会话的信息都将被丢弃。
o A new plaintext greeting is sent.
o 发送新的明文问候语。
If the outermost element has a "port" attribute and an "fqdn" attribute but no "srv" attribute, then "fqdn" is looked up as an A record via DNS for translation to an IP number. An "ip4" attribute is interpreted as the dotted-quad representation of an IPv4 address. An "ip6" attribute is interpreted as a text representation of an IPv6 address. In each of these cases, a transport connection is established to the so-identified server. If the outermost element has a "srv" attribute, the concatenation of the "srv" attribute and the "fqdn" attribute (with a period between) is looked up in the DNS for a SRV record [6], and the appropriate server is contacted; if that lookup fails and a "port" attribute is present, the connection is attempted as if the "srv" attribute were not specified.
如果最外层的元素具有“端口”属性和“fqdn”属性，但没有“srv”属性，则通过DNS将“fqdn”作为a记录进行查找，以转换为IP号。“ip4”属性被解释为IPv4地址的虚线四元表示。“ip6”属性被解释为IPv6地址的文本表示。在每种情况下，都会建立到所标识的服务器的传输连接。如果最外层的元素具有“srv”属性，则在DNS中查找“srv”属性和“fqdn”属性的串联（间隔为一个句点），以查找srv记录[6]，并联系相应的服务器；如果查找失败且存在“端口”属性，则会尝试连接，就像未指定“srv”属性一样。
Alternately, if the outermost element has a "profile" attribute, then it must have no nested elements. The proxy processing this element is responsible for determining the appropriate routing to reach a peer serving the BEEP profile indicated by the URI in the attribute's value. Rather than source routing, this provides a hop-by-hop routing mechanism to a desired service.
或者，如果最外层的元素具有“profile”属性，则它必须没有嵌套元素。处理此元素的代理负责确定适当的路由，以到达为属性值中的URI指示的BEEP配置文件提供服务的对等方。这提供了到所需服务的逐跳路由机制，而不是源路由。
Similarly, if the outermost element has an "endpoint" attribute, then it must have no nested elements. The proxy processing this element is responsible for determining the appropriate routing to reach a peer indicated by the value of the "endpoint" attribute. Rather than source routing, this provides a hop-by-hop routing mechanism to a desired machine. There are no restrictions on how machines are identified.
类似地，如果最外层的元素具有“endpoint”属性，则它必须没有嵌套元素。处理此元素的代理负责确定适当的路由，以到达由“endpoint”属性值指示的对等方。这提供了到所需机器的逐跳路由机制，而不是源路由。对如何识别机器没有任何限制。
Then, if the outermost element has no nested elements, but it does have attributes other than "profile" or "endpoint", then this peer is the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP" example above.) In this case, as soon as the final underlying transport connection is established, an "ok" element is returned over the listening session, and the tunneling of data starts. No BEEP greeting (or indeed any data) from the final hop is expected. Starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more=".") of the RPY carrying the "ok" element, the proxy begins copying octets directly and without any interpretation between the two underlying transport connections.
然后，如果最外层的元素没有嵌套的元素，但它有除“profile”或“endpoint”以外的属性，那么这个对等元素就是最后的BEEP-hop。（这对应于上面“非蜂鸣”示例中的“proxy2”）。在这种情况下，一旦建立了最终的底层传输连接，侦听会话就会返回一个“ok”元素，数据隧道就会开始。不需要来自最后一个跃点的哔哔声问候（或任何数据）。从带有“ok”元素的RPY的完成标志集（more=“.”）的帧的结束（CR）（LF）尾部后面的八位字节开始，代理开始直接复制八位字节，而不在两个底层传输连接之间进行任何解释。
If the identified server cannot be contacted, an "error" element is returned over the listening channel and any connection established as an initiator is closed. If there is a nested "tunnel" element, and the server that has been contacted does not offer a BEEP greeting, or the BEEP greeting offered does not include the TUNNEL profile, then this too is treated as an error: the initiating transport connection is closed, and an error is returned.
如果无法联系已标识的服务器，则通过侦听通道返回“error”元素，并关闭作为启动器建立的任何连接。如果存在嵌套的“tunnel”元素，并且已联系的服务器不提供蜂鸣问候语，或者提供的蜂鸣问候语不包括隧道配置文件，则这也将被视为错误：启动的传输连接关闭，并返回错误。
If there is a nested "tunnel" element, and the identified server is contacted and offers a BEEP greeting including the TUNNEL profile, then the outermost element from the "tunnel" element received is stripped off, a new TUNNEL channel is started on the initiating session, and the stripped (inner) element is sent to start the next hop. In this case, the peer is considered a "proxy" (meaning that the next paragraph is applicable).
如果存在嵌套的“tunnel”元素，并且与标识的服务器联系并提供包括隧道配置文件的蜂鸣问候语，则从接收到的“tunnel”元素中剥离最外层的元素，在发起会话时启动新的隧道通道，并发送剥离的（内部）元素以启动下一跳。在这种情况下，对等方被视为“代理”（意味着下一段适用）。
Once the proxy has passed the "tunnel" element on the TUNNEL channel, it awaits an "error" or an "ok" element in response. If it receives an "error" element, it closes the initiated session and its underlying transport connection. It then passes the "error" element unchanged back on the listening session. If, on the other hand, it receives an "ok" element, it passes the "ok" element back on the listening session. Starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more=".") of the RPY carrying the "ok" element, the proxy begins copying octets directly and without any interpretation between the two underlying transport connections.
一旦代理通过隧道通道上的“tunnel”元素，它将等待“error”或“ok”元素的响应。如果接收到“error”元素，它将关闭启动的会话及其底层传输连接。然后，它将“error”元素原封不动地传递回侦听会话。另一方面，如果它接收到一个“ok”元素，它会将该“ok”元素传递回侦听会话。从带有“ok”元素的RPY的完成标志集（more=“.”）的帧的结束（CR）（LF）尾部后面的八位字节开始，代理开始直接复制八位字节，而不在两个底层传输连接之间进行任何解释。
While the BEEP Framework [2] is used, the attributes described are sufficient for the TCP mapping [3] of BEEP. The attributes on the "tunnel" element may need to be extended to handle other transport layers.
在使用BEEP框架[2]时，所描述的属性足以用于BEEP的TCP映射[3]。“tunnel”元素上的属性可能需要扩展以处理其他传输层。
In a mapping where multiple underlying transport connections are used, once the "ok" element is passed, all channels are closed, including channel zero. Thus, only the underlying transport connection initially established remains, and all other underlying transport connections for the session should be closed as well.
在使用多个底层传输连接的映射中，一旦传递了“ok”元素，所有通道都将关闭，包括通道0。因此，只保留最初建立的底层传输连接，会话的所有其他底层传输连接也应关闭。
If a transport security layer (such as TLS) has been negotiated over the session, the semantics for the TUNNEL profile are ill-defined. The TUNNEL profile MUST NOT be advertised in any greetings after transport security has been negotiated.
如果已在会话上协商传输安全层（如TLS），则隧道配置文件的语义定义不正确。运输安全协商后，不得在任何问候语中公布隧道概况。
An SRV identifier of "_tunnel" is reserved by IANA for use with this profile. Hence, the "srv" attribute "_tunnel._tcp" MAY be used as a default for finding the appropriate address for tunneling into a particular domain.
IANA保留了一个SRV标识符“_tunnel”，用于此配置文件。因此，“srv”属性“_tunnel._tcp”可以用作查找隧道到特定域的适当地址的默认值。
System port number 604 has been allocated by the IANA for TUNNEL.
IANA已为隧道分配了系统端口号604。
This section lists the three-digit error codes the TUNNEL profile may generate.
本节列出了隧道纵断面可能产生的三位错误代码。
code meaning
==== =======
421 Service not available
(E.g., the proxy does not have sufficient resources.)
code meaning
==== =======
421 Service not available
(E.g., the proxy does not have sufficient resources.)
450 Requested action not taken (E.g., DNS lookup failed or connection could not be established. See too 550.)
450未采取请求的操作（例如，DNS查找失败或无法建立连接。请参阅550。）
500 General syntax error (E.g., poorly-formed XML)
500一般语法错误（例如，格式错误的XML）
501 Syntax error in parameters (E.g., non-valid XML, letters in "ip4" attribute, etc.)
501参数中的语法错误（例如，无效XML、“ip4”属性中的字母等）
504 Parameter not implemented
504参数未实现
530 Authentication required
530需要身份验证
534 Authentication mechanism insufficient (E.g., too weak, sequence exhausted, etc.)
534身份验证机制不足（例如，太弱、序列用尽等）
537 Action not authorized for user
537未授权用户执行的操作
538 Encryption already enabled (E.g., TLS already negotiated, or a SASL that provides encryption already negotiated.)
538已启用加密（例如，TLS已协商，或提供加密的SASL已协商。）
550 Requested action not taken (E.g., next hop could be contacted, but malformed greeting or no TUNNEL profile advertised.)
550未采取请求的操作（例如，可以联系下一个跃点，但问候语格式不正确或没有公布隧道配置文件。）
553 Parameter invalid
553参数无效
554 Transaction failed (E.g., policy violation)
554事务失败（例如，违反策略）
Note that the 450 error code is appropriate when the destination machine could not be contacted, while the 550 error code is appropriate when the destination machine could be contacted but the next phase of the protocol could not be negotiated. It is suggested that the beginning of any reply from the destination machine be included as part of the CDATA text of the error element, for debugging purposes.
请注意，450错误代码适用于无法联系目标机器的情况，而550错误代码适用于可以联系目标机器但无法协商协议的下一阶段的情况。出于调试目的，建议将来自目标计算机的任何回复的开头作为错误元素的CDATA文本的一部分。
The TUNNEL profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal. Refer to Section 8 of [2] for a discussion of this.
隧道剖面是一个BEEP剖面。在BEEP中，传输安全、用户身份验证和数据交换是正交的。有关此问题的讨论，请参阅[2]第8节。
However, the intent of the TUNNEL profile is to allow bidirectional contact between two machines normally separated by a firewall. Since TUNNEL allows this connection between BEEP peers, and BEEP peers can offer a range of services with appropriate greetings, the TUNNEL profile should be configured with care. It is reasonable to strictly limit the hosts and services that a proxy is allowed to contact. It is also reasonable to limit the use of the TUNNEL profile to authorized users, as identified by a SASL profile.
然而，隧道配置文件的目的是允许通常由防火墙分隔的两台机器之间的双向接触。由于隧道允许BEEP对等点之间的这种连接，并且BEEP对等点可以提供一系列带有适当问候语的服务，因此应小心配置隧道配置文件。严格限制代理可以接触的主机和服务是合理的。如SASL配置文件所示，将隧道配置文件的使用限制为授权用户也是合理的。
Negotiation of a TLS profile in an end-to-end manner after a TUNNEL has been established will prevent intermediate proxies from observing or modifying the cleartext information exchanged, but only if TLS certificates are properly configured during the negotiation. The proxy could mount a "man in the middle" attack if public key infrastructure is not deployed.
隧道建立后，以端到端的方式协商TLS配置文件将阻止中间代理观察或修改交换的明文信息，但前提是协商期间正确配置了TLS证书。如果未部署公钥基础设施，代理可能发起“中间人”攻击。
In some environments, it is undesirable to expose the names of machines on one side of a firewall in unencrypted messages on the other side of that firewall. In this case, source routing (using the "fqdn", "ip4", "ip6", "port" and "srv" attributes) can route a connection to the firewall proxy, with an innermost "profile" or "endpoint" attribute which the firewall proxy understands. Local provisioning can allow a proxy to translate a particular "profile" or "endpoint" element into a new source route to reach the desired service. This can prevents two attacks:
在某些环境中，不希望在防火墙另一侧的未加密消息中公开防火墙一侧的计算机名称。在这种情况下，源路由（使用“fqdn”、“ip4”、“ip6”、“端口”和“srv”属性）可以将连接路由到防火墙代理，其中最内层的“配置文件”或“端点”属性是防火墙代理能够理解的。本地资源调配允许代理将特定的“概要文件”或“端点”元素转换为新的源路由，以达到所需的服务。这可以防止两种攻击：
o Attackers sniffing packets on one side of the firewall cannot see IP addresses or FQDNs of machines on the other side of the firewall; and,
o 在防火墙一侧嗅探数据包的攻击者无法看到防火墙另一侧计算机的IP地址或FQDN；和
o Attackers cannot exhaustively attempt to connect to many FQDNs or IP addresses via source routing and use the error messages as an indication of whether the queried machine exists. For this attack to be prevented, the proxy must allow only "profile" or "endpoint" connections, always refusing to even attempt source-routed connections. This latter attack can also be thwarted by requiring a SASL identification before allowing a TUNNEL channel to be started, but this can have higher overhead.
o 攻击者无法完全尝试通过源路由连接到多个FQDN或IP地址，并使用错误消息指示查询的计算机是否存在。要防止此攻击，代理必须仅允许“配置文件”或“端点”连接，始终拒绝尝试源路由连接。在允许启动隧道通道之前，还可以通过要求SASL标识来阻止后一种攻击，但这可能会带来更高的开销。
[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] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[3] Rose，M.“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[4] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[6] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
The IANA has registered the profiles specified in this section and has selected an IANA-specific URI: "http://iana.org/beep/TUNNEL".
IANA已注册本节中指定的配置文件，并已选择IANA特定的URI:“http://iana.org/beep/TUNNEL".
Profile identification: http://iana.org/beep/TUNNEL
Profile identification: http://iana.org/beep/TUNNEL
Message exchanged during channel creation: "tunnel"
通道创建期间交换的消息：“隧道”
Messages starting one-to-one exchanges: "tunnel"
开始一对一交换的消息：“隧道”
Messages in positive replies: "ok"
正面回复中的消息：“确定”
Messages in negative replies: "error"
否定回复中的消息：“错误”
Messages in one-to-many exchanges: None.
一对多交换中的消息：无。
Message syntax: See Section 3 of this document.
消息语法：请参阅本文档第3节。
Message semantics: See Section 4 of this document.
消息语义：参见本文档第4节。
Contact information: See the Author's Address appendix of this document.
联系方式：见本文件附录作者地址。
Any extensions to this protocol MUST be documented in a Standards track RFC.
本协议的任何扩展必须记录在标准跟踪RFC中。
A single well-known port, 604, is allocated by the IANA to the TUNNEL profile.
IANA将一个已知的端口604分配给隧道配置文件。
Protocol Number: TCP
协议编号：TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.
消息格式、类型、操作码和序列：见第3节。
Functions: See Section 4.
功能：见第4节。
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: TUNNEL Profile
建议名称：隧道剖面图
Short name: tunnel
简称：隧道
Contact Information: See the "Authors' Addresses" section of this memo
联系方式：参见本备忘录的“作者地址”部分
The author gratefully acknowledges the contributions of Marshall Rose, Greg Matthews, and Ben Feinstein.
作者感谢马歇尔·罗斯、格雷格·马修斯和本·范斯坦的贡献。
Inspiration for this profile comes from the Intrusion Detection Working Group of the IETF.
此概要文件的灵感来自IETF的入侵检测工作组。
Author's Address
作者地址
Darren New 5390 Caminito Exquisito San Diego, CA 92130 US
美国加利福尼亚州圣地亚哥Darren New 5390 Caminito Exquisito 92130
Phone: +1 858 350 9733
EMail: dnew@san.rr.com
Phone: +1 858 350 9733
EMail: dnew@san.rr.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。