tunnel
Click on the red underlined text to get to the source
...
The TUNNEL profile provides a mechanism for cooperating BEEP peers to
form an application-layer ...
... form an application-layer tunnel. The peers exchange "tunnel"
elements that specify a source route ...
... being stripped off and used to decide the next hop. The innermost,
empty "tunnel" element tells the final destination that it is,
...
... 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 ...
... SASL,
then instruct the proxy to tunnel to an information service
restricted to managers. Since each proxy ...
... identity of the
next proxy being requested, it can refuse to tunnel connections if
inadequate levels of authorization ...
... 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 ...
... <------- greeting -------->
--- start TUNNEL [1] ---->
----- xport connect ------>
<-------- greeting -------->
...
... <-------- greeting -------->
---- start TUNNEL [2] ---->
<---------- ok ------------
<------- ok -------------- [3]
...
... TUNNEL element looks like this:
<tunnel/>
[3] At this point, immediately after sending the <ok/> element ...
... <----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
...
... <------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
...
... tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' port='10290'>
<tunnel ...
... 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
...
... tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel ...
... 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.
...
... 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
...
... tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' svc='_telnet._tcp'>
</tunnel ...
... TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
</tunnel ...
... tunnel fqdn='final.example.com' srv='_telnet._tcp'>
</tunnel>
Note the lack of an innermost no-attribute <tunnel> element ...
... <----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
...
... <------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
...
... TUNNEL element looks like this:
<tunnel profile="http://xml.resource/org/profiles/SEP2"/>
Note the lack of an innermost no-attribute <tunnel ...
... tunnel profile="http://xml.resource/org/profiles/SEP2"/>
Note the lack of an innermost no-attribute <tunnel> element.
...
... tunnel fqdn="proxy2.example.com" port="604">
<tunnel profile="http://xml.resource/org/profiles/SEP2"/>
</tunnel ...
... tunnel profile="http://xml.resource/org/profiles/SEP2"/>
</tunnel>
based on local configuration, then processes the new
element ...
... 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 ...
... element, looking up the
appropriate address and port, and forwards the <tunnel/>
element to the final machine.
...
... <----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
...
... <------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
...
... <tunnel endpoint="operator console">
</tunnel>
Note the lack of an innermost no-attribute <tunnel> element ...
... <tunnel endpoint="operator console">
</tunnel>
to proxy2.
...
... 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 ...
... element, looking up the
appropriate address and port, and forwards the <tunnel/>
element to the final machine.
...
... The only element defined in this profile is the "tunnel" element. It
is described in the following DTD ...
... 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 ...
... connection established as
an initiator is closed. If there is a nested "tunnel" element, and
the server that has been contacted does not offer a BEEP ...
... BEEP greeting, or
the BEEP greeting offered does not include the TUNNEL profile, then
this too is treated as an error: the initiating transport connection
...
... is closed, and an error is returned.
If there is a nested "tunnel" element, and the identified server is
contacted and offers a BEEP ...
... element, and the identified server is
contacted and offers a BEEP greeting including the TUNNEL profile,
then the outermost element from the "tunnel ...
... TUNNEL profile,
then the outermost element from the "tunnel" element received is
stripped off, a new TUNNEL ...
... tunnel" element received is
stripped off, a new TUNNEL channel is started on the initiating
session ...
... proxy has passed the "tunnel" element on the TUNNEL channel,
it awaits an "error" or an "ok" element ...
... 3] of BEEP. The attributes on the
"tunnel" element may need to be extended to handle other transport
layers.
...
... the session, the semantics for the TUNNEL profile are ill-defined.
The TUNNEL profile MUST NOT be advertised in any greetings after
...
... semantics for the TUNNEL profile are ill-defined.
The TUNNEL profile MUST NOT be advertised in any greetings after
transport security has been negotiated.
...
... IANA for use with this
profile. Hence, the "srv" attribute "_tunnel._tcp" MAY be used as a
default for finding the appropriate address for tunneling ...
...
This section lists the three-digit error codes the TUNNEL profile may
generate.
...
... (E.g., next hop could be contacted, but
malformed greeting or no TUNNEL profile advertised.)
553 Parameter invalid
...
... discussion of this.
However, the intent of the TUNNEL profile is to allow bidirectional
contact between two machines normally separated by a firewall ...
... contact between two machines normally separated by a firewall. Since
TUNNEL allows this connection between BEEP peers, and BEEP ...
... offer a range of services with appropriate greetings, the TUNNEL
profile should be configured with care. It is reasonable to strictly
limit the hosts and services ...
... services that a proxy is allowed to contact. It
is also reasonable to limit the use of the TUNNEL profile to
authorized users, as identified by a SASL profile ...
... TLS profile in an end-to-end manner after a TUNNEL
has been established will prevent intermediate proxies from observing
...
... attack can also be thwarted by requiring
a SASL identification before allowing a TUNNEL channel to be
started, but this can have higher overhead ...
... http://iana.org/beep/TUNNEL ...
... http://iana.org/beep/TUNNEL ...
... A single well-known port, 604, is allocated by the IANA to the TUNNEL
profile.
Protocol Number ...