The TUNNEL Profile
RFC 3620
Document | Type |
RFC - Proposed Standard
(October 2003; No errata)
Updated by RFC 8553
|
|
---|---|---|---|
Author | Darren New | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3620 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Steven Bellovin | ||
Send notices to | <stuart@silicondefense.com> |
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 thisShow full document text