The TUNNEL Profile
RFC 3620

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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.

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

New                         Standards Track                     [Page 1]
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