The TUNNEL Profile
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (25)
Once both endpoint machines are connected, the tunneling proxy does no further interpretation, including no BEEP framing. This allows the two endpoints to negotiate TLS between themselves with certificates appropriate to the endpoints rather than the proxy, ensuring the proxy cannot access exchanged information even though it relays the bytes.
The 'profile' attribute routes to a particular service (identified by BEEP profile URI) while the 'endpoint' attribute routes to a particular named machine; these provide hop-by-hop routing via local provisioning rather than source routing, allowing proxies to resolve logical names to concrete addresses without exposing topology to the initiator.
Using 'profile' or 'endpoint' attributes instead of source-routing attributes (fqdn/ip4/ip6/port/srv) prevents two attacks: attackers on one side of a firewall cannot see addresses of machines on the other side, and cannot use source-routing exhaustion with error-message probing to map internal hosts. The proxy must refuse all source-routed connections for the second prevention to hold.
In a BEEP mapping where multiple underlying transport connections are used, once the 'ok' element is passed all channels including channel zero are closed, leaving only the initially established transport connection; all other transport connections for the session must be closed.
To tunnel to a non-BEEP final endpoint, the initiator omits the innermost no-attribute 'tunnel' element. The final proxy then does not expect a BEEP greeting from the destination and returns 'ok' as soon as the transport connection is established, forwarding any data received from the final host (even data arriving before 'ok' was sent).
Any extensions to the TUNNEL profile MUST be documented in a Standards Track RFC, as stated in the IANA registration.
The SRV identifier '_tunnel' is reserved by IANA; the 'srv' attribute value '_tunnel._tcp' MAY be used as a default for finding the appropriate address for tunneling into a particular domain.
The TUNNEL profile MUST NOT be advertised in any greetings after transport security (such as TLS) has been negotiated over the session, because the semantics for the TUNNEL profile are ill-defined in that context.
Error handling: if the identified server cannot be contacted, an 'error' element is returned and any initiated connection is closed. If the destination does not offer a BEEP greeting or does not advertise the TUNNEL profile, this is also treated as an error; the beginning of any reply from the destination SHOULD be included as CDATA for debugging.
If the outermost 'tunnel' element has a 'profile' attribute with no nested elements, the proxy is responsible for determining hop-by-hop routing to a peer serving the BEEP profile identified by the URI; source routing is not used, and local provisioning maps the URI to a concrete next hop.
If the outermost 'tunnel' element has an 'endpoint' attribute with no nested elements, the proxy performs hop-by-hop routing to a peer identified by the endpoint string value via local provisioning; there are no restrictions on how machines are identified.
If the outermost 'tunnel' element has an 'srv' attribute, the concatenation of 'srv' and 'fqdn' (with a period) is looked up as a DNS SRV record to find the server. If SRV lookup fails and a 'port' attribute is present, the connection falls back to a direct address lookup as if 'srv' were absent.
The TUNNEL profile allows BEEP peers to act as application-layer proxies by exchanging nested 'tunnel' elements that specify a source route. Each proxy strips the outermost element and uses it to determine the next hop; the innermost empty 'tunnel' element signals the final destination.
The TUNNEL profile defines a set of reply codes for error conditions, including: 421 (service unavailable), 450 (destination unreachable/DNS failure), 530 (authentication required), 537 (action not authorized), 538 (encryption already enabled), 550 (destination reachable but TUNNEL not supported), and 554 (policy violation).
Transparent octet forwarding begins immediately after a proxy sends or receives the 'ok' RPY frame: starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more='.'), the proxy copies octets between the two underlying transport connections without any interpretation.
When the outermost 'tunnel' element has attributes but no nested child and the attributes are not 'profile' or 'endpoint', this peer is the final BEEP hop. It establishes the transport connection to the target and immediately returns 'ok' and begins transparent forwarding without expecting a BEEP greeting from the final host.
When the outermost 'tunnel' element has no attributes, the receiving peer is the final BEEP destination and performs a tuning reset: all channels including channel zero are implicitly closed, previously cached session information is discarded, and a new plaintext greeting is sent.
This document allocates well-known TCP port 604 to the TUNNEL profile. The SRV name '_tunnel' is also reserved by IANA for use with this profile.
This document registers the BEEP profile 'http://iana.org/beep/TUNNEL' with IANA. The profile exchanges 'tunnel' messages, replies with 'ok' (positive) or 'error' (negative), and has no one-to-many messages.
Attackers can use source routing with error messages as an oracle to determine whether internal machines exist. This attack is prevented either by requiring the proxy to allow only 'profile' or 'endpoint' connections (refusing source-routed connections entirely), or by requiring SASL authentication before allowing a TUNNEL channel to be started (at higher overhead).
Negotiating TLS end-to-end after a TUNNEL connection prevents intermediate proxies from observing or modifying cleartext, but only if TLS certificates are properly configured. Without public key infrastructure deployment, a proxy can mount a man-in-the-middle attack.
The TUNNEL profile should be configured with care because it allows bidirectional contact between machines separated by a firewall. It is reasonable to strictly limit the hosts and services a proxy is allowed to contact, and to restrict use to authorized users identified by a SASL profile.
When a proxy receives a 'tunnel' element with a nested child: (1) it connects to the identified next hop, (2) starts a TUNNEL channel, (3) forwards the stripped inner element, (4) awaits 'ok' or 'error', (5) on 'ok' relays it back and enters transparent forwarding; on 'error' closes the initiated session and relays the error.
The only allowable attribute combinations on a 'tunnel' element are: fqdn+port; fqdn+srv; fqdn+srv+port; ip4+port; ip6+port; 'profile' alone (innermost only); 'endpoint' alone (innermost only); or no attributes (innermost only). Any other combination is invalid.
The 'tunnel' element is defined by a DTD with optional attributes: 'fqdn' (FQDN string), 'ip4' (dotted-quad), 'ip6' (RFC 2373 text), 'port' (1–65535 decimal), 'srv' (underscore-prefixed pair), 'profile' (URI), and 'endpoint' (any string). It may contain a single optional nested 'tunnel' child element.