RFC 3620 (rfc3620) - Page 2 of 18

The TUNNEL Profile

RFC 3620                   The TUNNEL Profile               October 2003


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].







New                         Standards Track