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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
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
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.
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.
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.
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.
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].
2. Examples
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.
2.1 One-Hop Example
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]-------------------------->
Notes:
[1] The TUNNEL element looks like this:
<tunnel fqdn=’final.example.com’ port=’604’>
<tunnel/>
</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.
[4] This greeting may include the TLS profile, allowing initial and
final to communicate without proxy1 understanding or interfering
without being caught.
2.2 Two-Hop Example
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 ---------------------------->
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>
[2] The TUNNEL element looks like this:
<tunnel fqdn=’final.example.com’ port=’10290’>
<tunnel/>
</tunnel>
[3] The TUNNEL element looks like this:
<tunnel/>
[4] Proxy2 starts passing octets transparently after sending the
<ok/>.
[5] Proxy1 starts passing octets transparently after sending the
<ok/>.
2.3 Failed Set-Up Example
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.
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>
[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.
2.4 Non-BEEP Example
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.
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.
[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.
[3] Each proxy starts transparently forwarding octets after this
<ok>.
[4] Each proxy forwards any data it received from the final host,
even if that data arrived before the <ok> was sent.
[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.
2.5 Profile Example
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.
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.
[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.
[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.
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[5] Proxy1 starts transparently forwarding octets after this <ok>.
2.6 Endpoint Example
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.
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.
[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.
[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.
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[5] Proxy1 starts transparently forwarding octets after this <ok>.
3. Message Syntax
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 for the TUNNEL Profile, as of 2001-02-03
Refer to this DTD as:
<!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" "">
%TUNNEL;
-->
<!--
TUNNEL messages
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
>
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.
The only allowable combinations of attributes are as follows:
o fqdn + port;
o fqdn + srv;
o fqdn + srv + port;
o ip4 + port;
o ip6 + port;
o profile, but only on the innermost element;
o endpoint, but only on the innermost element; or,
o no attributes, but only on the innermost element.
4. Message Semantics
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.
In either case, the outermost "tunnel" element is examined. If it
has no attributes, then this peer is hosting the BEEP service that