Network Working Group                                             D. New
Internet-Draft                                          December 5, 2002
Expires: June 5, 2003


                           The TUNNEL Profile
                     draft-ietf-idwg-beep-tunnel-05

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 5, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo describes a BEEP profile that allows a BEEP peer to serve
   as an application-layer proxy.  It allows authorized users to access
   services through a firewall.












New                       Expires June 5, 2003                  [Page 1]


Internet-Draft               TUNNEL Profile                December 2002


Table of Contents

   1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1 One-Hop Example  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2 Two-Hop Example  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.3 Failed Set-Up Example  . . . . . . . . . . . . . . . . . . . .  6
   2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . . .  7
   2.5 Profile Example  . . . . . . . . . . . . . . . . . . . . . . .  8
   2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Message Semantics  . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
       Normative References . . . . . . . . . . . . . . . . . . . . . 18
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
   A.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . . . 19
   A.2 Registration: The System (Well-Known) TCP port number for
       TUNNEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   C.  Changes from Previous Version  . . . . . . . . . . . . . . . . 22
   C.1 Changes since -04  . . . . . . . . . . . . . . . . . . . . . . 22
   C.2 Changes since -03  . . . . . . . . . . . . . . . . . . . . . . 22
   C.3 Changes since -02  . . . . . . . . . . . . . . . . . . . . . . 22
   C.4 Changes since -01  . . . . . . . . . . . . . . . . . . . . . . 22
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23























New                       Expires June 5, 2003                  [Page 2]


Internet-Draft               TUNNEL Profile                December 2002


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 RFC 2119 [1].







New                       Expires June 5, 2003                  [Page 3]


Internet-Draft               TUNNEL Profile                December 2002


2. Examples

   While the semantics described in Section 4 may seem complex, the
   results are actually relatively simple.  A few examples will show the
   operation and use of this profile.  In these examples, the machine
   attempting to establish the connection is named "initial", while the
   intermediate proxies are "proxy1" or "proxy2", and the machine with
   the service that "initial" wishes to access is called "final".  The
   examples also assume that the BEEP framework [2] is implemented on
   top of TCP [3], or some other mapping where one transport connection
   carries all channels.

2.1 One-Hop Example

   A simple one-hop connection through a single proxy is illustrated
   first.

     initial                   proxy1                     final
        ----- xport connect ----->
       <------- greeting -------->
        --- start TUNNEL [1] ---->
                                  ----- xport connect ------>
                                 <-------- greeting -------->
                                  ---- start TUNNEL [2] ---->
                                 <---------- ok ------------
       <------- ok -------------- [3]
       <------------- greeting [4]-------------------------->

   Notes:
     [1] The TUNNEL element looks like this:
         <tunnel fqdn='final.example.com' port='10288'>
           <tunnel/>
         </tunnel>

     [2] The TUNNEL element looks like this:
         <tunnel/>

     [3] At this point, immediately after sending the <ok/>
         element, proxy1 starts passing octets transparently.
         It continues to do so until either transport connection
         is closed, after which it closes the other.

     [4] This greeting may include the TLS profile, allowing
         initial and final to communicate without proxy1
         understanding or interfering without being caught.






New                       Expires June 5, 2003                  [Page 4]


Internet-Draft               TUNNEL Profile                December 2002


2.2 Two-Hop Example

   The second example shows the initiator connecting to its proxy, that
   proxy connecting to another, and finally that second proxy finding a
   service outside.

   initial             proxy1                proxy2                 final
     --- xport connect -->
    <---- greeting ------>
     --start TUNNEL [1]-->
                          -- xport connect --->
                         <----- greeting ----->
                          --start TUNNEL [2]-->
                                               --- xport  connect --->
                                              <------- greeting ----->
                                               ---start TUNNEL [3]--->
                                              <-------- ok ----------
                         <------- ok --------- [4]
    <------- ok --------- [5]
    <-------------------------- greeting ---------------------------->

   Notes:
     [1] The TUNNEL element looks like this:
         <tunnel fqdn='proxy2.example.com' port='10288'>
           <tunnel fqdn='final.example.com' port='10290'>
             <tunnel/>
           </tunnel>
         </tunnel>

     [2] The TUNNEL element looks like this:
           <tunnel fqdn='final.example.com' port='10290'>
             <tunnel/>
           </tunnel>

     [3] The TUNNEL element looks like this:
             <tunnel/>

     [4] Proxy2 starts passing octets transparently after
         sending the <ok/>.

     [5] Proxy1 starts passing octets transparently after
         sending the <ok/>.









New                       Expires June 5, 2003                  [Page 5]


Internet-Draft               TUNNEL Profile                December 2002


2.3 Failed Set-Up Example

   The third example shows the initiator connecting through two proxys,
   the second proxy attempting to connect to the specified service and
   finding the destination is not a BEEP server.  (Of course, specifying
   the telnet 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
     --- xport connect -->
    <---- greeting ------>
     --start TUNNEL [1]-->
                          --- xport connect -->
                         <----- greeting ----->
                          --start TUNNEL [2]-->
                                               ---- xport connect --->
                                              <------- login: -------
                                               ----- xport close ---->
                         <---- <error> -------
                          --- xport close ---->
    <---- <error> ------
     --- xport close ---> [3]

   Notes:
     [1] The TUNNEL element looks like this:
         <tunnel fqdn='proxy2.example.com' port='10288'>
           <tunnel fqdn='final.example.com' srv='_telnet._tcp'>
             <tunnel/>
           </tunnel>
         </tunnel>

     [2] The 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.












New                       Expires June 5, 2003                  [Page 6]


Internet-Draft               TUNNEL Profile                December 2002


2.4 Non-BEEP Example

   This example shows the initiator connecting through two proxys, the
   second proxy attempting to connect to the specified service and
   accepting that the destination is not a 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
   ("proxy2") therefore does not expect a BEEP greeting.

   initial             proxy1                proxy2                 final
     --- xport connect -->
    <---- greeting ------>
     --start TUNNEL [1]-->
                          --- xport connect -->
                         <----- greeting ----->
                          --start TUNNEL [2]-->
                                               ---- xport connect --->
                                              <------- login: -------
                          <------ <ok> ------- [3]
                          <----- login: ------ [4]
    <------ <ok> --------- [3]
    <----- login: -------- [4] [5]


   Notes:
     [1] The TUNNEL element looks like this:
         <tunnel fqdn='proxy2.example.com' port='10288'>
           <tunnel fqdn='final.example.com' svc='_telnet._tcp'>
           </tunnel>
         </tunnel>
         Note the lack of an innermost no-attribute <tunnel> element.

     [2] The TUNNEL element looks like this:
           <tunnel fqdn='final.example.com' srv='_telnet._tcp'>
           </tunnel>
         Note the lack of an innermost no-attribute <tunnel> element.

     [3] Each proxy starts transparently forwarding octets after this <ok>.

     [4] Each proxy forwards any data it received from the final host,
         even if that data arrived before the <ok> was sent.

     [5] After receiving the "ok" message, the "initial" peer can expect
         raw, non-BEEP data to be sent to and received from the "final"
         machine.






New                       Expires June 5, 2003                  [Page 7]


Internet-Draft               TUNNEL Profile                December 2002


2.5 Profile Example

   This example shows the initiator connecting through two proxys.  The
   initial machine knows there is a server offering the SEP2 profile
   somewhere beyond proxy1, but it need not know where.  Proxy1 has been
   locally configured to know that all SEP2 servers are beyond proxy2.
   Proxy2 has been locally configured to chose "final" as the server of
   choice for SEP2 services.  Note that "final" does not necessarily
   need to offer the requested profile in its initial greeting.

   initial             proxy1                proxy2                 final
     --- xport connect -->
    <---- greeting ------>
     --start TUNNEL [1]-->
                          -- xport connect --->
                         <----- greeting ----->
                          --start TUNNEL [2]-->
                                               --- xport  connect --->
                                              <------- greeting ----->
                                               ---start TUNNEL [3]--->
                                              <-------- ok ----------
                         <------- ok --------- [4]
    <------- ok --------- [5]
    <-------------------------- greeting ---------------------------->


   Notes:
     [1] The TUNNEL element looks like this:
           <tunnel profile="http://xml.resource/org/profiles/SEP2"/>
         Note the lack of an innermost no-attribute <tunnel> element.

     [2] Proxy1 maps this to
           <tunnel fqdn="proxy2.example.com" port="10288">
             <tunnel profile="http://xml.resource/org/profiles/SEP2"/>
           </tunnel>
         based on local configuration, then processes the new
         element, stripping off the outer element and routing
           <tunnel profile="http://xml.resource/org/profiles/SEP2"/>
         to proxy2.

     [3] Proxy2 receives the TUNNEL element with simply the SEP2
         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, looking up the
         appropriate address and port, and forwards the <tunnel/>



New                       Expires June 5, 2003                  [Page 8]


Internet-Draft               TUNNEL Profile                December 2002


         element to the final machine.

     [4] Proxy2 starts transparently forwarding octets after this <ok>.

     [5] Proxy1 starts transparently forwarding octets after this <ok>.


2.6 Endpoint Example

   This example shows the initiator connecting through two proxys.  The
   initial machine knows there is a server known as "operator console"
   somewhere beyond proxy1, but it need not know where.  Proxy1 has been
   locally configured to know that "operator console" is beyond proxy2.
   Proxy2 has been locally configured to use "final" as "operator
   console".  This example is almost identical to the previous example,
   except that "endpoint" is intended to route to a particular server,
   while "profile" is intended to route to a particular service.
   Otherwise, these two attributes are very similar.

   initial             proxy1                proxy2                 final
     --- xport connect -->
    <---- greeting ------>
     --start TUNNEL [1]-->
                          -- xport connect --->
                         <----- greeting ----->
                          --start TUNNEL [2]-->
                                               --- xport  connect --->
                                              <------- greeting ----->
                                               ---start TUNNEL [3]--->
                                              <-------- ok ----------
                         <------- ok --------- [4]
    <------- ok --------- [5]
    <-------------------------- greeting ---------------------------->


   Notes:
     [1] The TUNNEL element looks like this:
           <tunnel endpoint="operator console">
           </tunnel>
         Note the lack of an innermost no-attribute <tunnel> element.

     [2] Proxy1 maps this to
           <tunnel fqdn="proxy2.example.com" port="10288">
             <tunnel endpoint="operator console">
             </tunnel>
           </tunnel>
         based on local configuration, then processes the new
         element, stripping off the outer element and routing



New                       Expires June 5, 2003                  [Page 9]


Internet-Draft               TUNNEL Profile                December 2002


           <tunnel endpoint="operator console">
           </tunnel>
         to proxy2.

     [3] Proxy2 receives the TUNNEL element with simply the 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, looking up the
         appropriate address and port, and forwards the <tunnel/>
         element to the final machine.

     [4] Proxy2 starts transparently forwarding octets after this <ok>.

     [5] Proxy1 starts transparently forwarding octets after this <ok>.


































New                       Expires June 5, 2003                 [Page 10]


Internet-Draft               TUNNEL Profile                December 2002


3. Message Syntax

   The only element defined in this profile is the "tunnel" element.  It
   is described in the following DTD, with additional limitations as
   described afterwards.



   <!--
     DTD for the TUNNEL Profile, as of 2001-02-03

     Refer to this DTD as:

       <!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN"
                  "">
       %TUNNEL;
     -->

   <!--
     TUNNEL messages

        role           MSG                 RPY
       ======          ===                 ===
       I or L          TUNNEL              +: ok
                                           -: error
     -->

   <!ELEMENT tunnel      (tunnel?)>
   <!ATTLIST tunnel
             fqdn         CDATA    #IMPLIED
             ip4          CDATA    #IMPLIED
             ip6          CDATA    #IMPLIED
             port         CDATA    #IMPLIED
             srv          CDATA    #IMPLIED
             profile      CDATA    #IMPLIED
             endpoint     CDATA    #IMPLIED
             >

   The format of the "fqdn" attribute is a fully qualified domain name,
   such as "proxy.example.com".  The format of the "ip4" attribute is
   four sets of decimal numbers separated by periods, such as
   "10.23.34.45".  The format of the "ip6" attribute is as specified in
   RFC2373 [4].  The format of the "port" attribute is a decimal number
   between one and 65535, inclusive.  The format of the "srv" attribute
   is a pair of identifiers each starting with an underline and
   separated by a period, such as "_sep._tcp".  The format of the
   "profile" attribute is a URI [5].  The format of the "endpoint"
   attribute is any string that may appear as an attribute value.



New                       Expires June 5, 2003                 [Page 11]


Internet-Draft               TUNNEL Profile                December 2002


   The only allowable combinations of attributes are as follows:

   o  fqdn + port;

   o  fqdn + srv;

   o  fqdn + srv + port;

   o  ip4  + port;

   o  ip6  + port;

   o  profile, but only on the innermost element;

   o  endpoint, but only on the innermost element; or,

   o  no attributes, but only on the innermost element.


































New                       Expires June 5, 2003                 [Page 12]


Internet-Draft               TUNNEL Profile                December 2002


4. Message Semantics

   When a TUNNEL channel is started, the listener expects a "tunnel"
   element from the initiator, either in the "start" element on channel
   zero or on the new channel created.  As usual, if it arrives on
   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 the BEEP service that
   the initiator wishes to use.  In this case, the listener performs a
   tuning reset:

   o  All channels, including channel zero, are implicitly closed.

   o  Any previously cached information about the BEEP session is
      discarded.

   o  A new plaintext greeting is sent.

   If the outermost element has a "port" attribute and an "fqdn"
   attribute but no "srv" attribute, then "fqdn" is looked up as an A
   record via DNS, translated to an IP number.  An "ip4" attribute is
   interpreted as the dotted-quad representation of an IPv4 address.  An
   "ip6" attribute is interpreted as a text representation of an IPv6
   address.  In each of these cases, a transport connection is
   established to the so-identified server.  If the outermost element
   has a "srv" attribute, the concatenation of the "srv" attribute and
   the "fqdn" attribute (with a period between) is looked up in the DNS
   for a SRV record [6], and the appropriate server is contacted; if
   that lookup fails and a "port" attribute is present, the connection
   is attempted as if the "srv" attribute were not specified.

   Alternately, if the outermost element has a "profile" attribute, then
   it must have no nested elements.  The proxy processing this element
   is responsible for determining the appropriate routing to reach a
   peer serving the BEEP profile indicated by the URI in the attribute's
   value.  Rather than source routing, this provides a hop-by-hop
   routing mechanism to a desired service.

   Similarly, if the outermost element has an "endpoint" attribute, then
   it must have no nested elements.  The proxy processing this element
   is responsible for determining the appropriate routing to reach a
   peer indicated by the value of the "endpoint" attribute.  Rather than
   source routing, this provides a hop-by-hop routing mechanism to a
   desired machine.  There are no restrictions on how machines are
   identified.





New                       Expires June 5, 2003                 [Page 13]


Internet-Draft               TUNNEL Profile                December 2002


   Then, if the outermost element has no nested elements, but it does
   have attributes other than "profile" or "endpoint", then this peer is
   the final BEEP hop.  (This corresponds to "proxy2" in the "Non-BEEP"
   example above.) In this case, as soon as the final underlying
   transport connection is established, an "ok" element is returned over
   the listening session, and the tunneling of data starts.  No BEEP
   greeting (or indeed any data) from the final hop is expected.
   Starting with the octet following the END(CR)(LF) trailer of the
   frame with the completion flag set (more=".") of the RPY carrying the
   "ok" element, the proxy begins copying octets directly and without
   any interpretation between the two underlying transport connections.

   If the identified server cannot be contacted, an "error" element is
   returned over the listening channel and any 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 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 greeting including the TUNNEL profile,
   then the outermost element from the "tunnel" element received is
   stripped off, a new TUNNEL channel is started on the initiating
   session, and the stripped (inner) element is sent to start the next
   hop.  In this case, the peer is considered a "proxy" (meaning that
   the next paragraph is applicable).

   Once the proxy has passed the "tunnel" element on the TUNNEL channel,
   it awaits an "error" or an "ok" element in response.  If it receives
   an "error" element, it closes the initiated session and it's
   underlying transport connection.  It then passes the "error" element
   unchanged back on the listening session.  If, on the other hand, it
   receives an "ok" element, it passes the "ok" element back on the
   listening session.  Starting with the octet following the END(CR)(LF)
   trailer of the frame with the completion flag set (more=".") of the
   RPY carrying the "ok" element, the proxyy begins copying octets
   directly and without any interpretation between the two underlying
   transport connections.












New                       Expires June 5, 2003                 [Page 14]


Internet-Draft               TUNNEL Profile                December 2002


5. Provisioning

   While the BEEP Framework [2] is used, the attributes described are
   sufficient for the TCP mapping [3] of BEEP.  The attributes on the
   "tunnel" element may need to be extended to handle other transport
   layers.

   In a mapping where multiple underlying transport connections are
   used, once the "ok" element is passed, all channels are closed,
   including channel zero.  Thus, only the underlying transport
   connection initially established remains, and all other underlying
   transport connections for the session should be closed as well.

   If a transport security layer (such as TLS) has been negotiated over
   the session, the semantics for the TUNNEL profile are ill-defined.
   The TUNNEL profile MUST NOT be advertised in any greetings after
   transport security has been negotiated.

   An SRV identifier of "_tunnel" is reserved by 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 into a
   particular domain.





























New                       Expires June 5, 2003                 [Page 15]


Internet-Draft               TUNNEL Profile                December 2002


6. Reply Codes

   This section lists the three-digit error codes the TUNNEL profile may
   generate.

      code   meaning
      ====   =======
       421   Service not available
             (E.g., the proxy does not have sufficient resources.)

       450   Requested action not taken
             (E.g., DNS lookup failed or connection could not
              be established. See too 550.)

       500   General syntax error (E.g., poorly-formed XML)

       501   Syntax error in parameters
             (E.g., non-valid XML, letters in "ip4" attribute, etc.)

       504   Parameter not implemented

       530   Authentication required

       534   Authentication mechanism insufficient
             (E.g., too weak, sequence exhausted, etc.)

       537   Action not authorized for user

       538   Encryption already enabled
             (E.g., TLS already negotiated, or a SASL that
              provides encryption already negotiated.)

       550   Requested action not taken
             (E.g., next hop could be contacted, but
              malformed greeting or no TUNNEL profile advertised.)

       553   Parameter invalid

       554   Transaction failed (E.g., policy violation)

   Note that the 450 error code is appropriate when the destination
   machine could not be contacted, while the 550 error code is
   appropriate when the destination machine could be contacted but the
   next phase of the protocol could not be negotiated.  It is suggested
   that the beginning of any reply from the destination machine be
   included as part of the CDATA text of the error element, for
   debugging purposes.




New                       Expires June 5, 2003                 [Page 16]


Internet-Draft               TUNNEL Profile                December 2002


7. Security Considerations

   The TUNNEL profile is a profile of BEEP.  In BEEP, transport
   security, user authentication, and data exchange are orthogonal.
   Refer to Section 8 of [2] for a discussion of this.

   However, the intent of the TUNNEL profile is to allow bidirectional
   contact between two machines normally separated by a firewall.  Since
   TUNNEL allows this connection between BEEP peers, and BEEP peers  can
   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 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.

   Negotiation of a TLS profile in an end-to-end manner after a TUNNEL
   has been established will prevent intermediate proxies from observing
   or modifying the cleartext information exchanged, but only if TLS
   certificates are properly configured during the negotiation.  The
   proxy could mount a "man in the middle" attack if public key
   infrastructure is not deployed.

   In some environments, it is undesirable to expose the names of
   machines on one side of a firewall in unencrypted messages on the
   other side of that firewall.  In this case, source routing (using the
   "fqdn", "ip4", "ip6", "port" and "srv" attributes) can route a
   connection to the firewall proxy, with an innermost "profile" or
   "endpoint" attribute which the firewall proxy understands.  Local
   provisioning can allow a  proxy to translate a particular "profile"
   or "endpoint" element into a new source route to reach the desired
   service.  This can prevents two attacks:

   o  Attackers sniffing packets on one side of the firewall cannot see
      IP addresses or FQDNs of machines on the other side of the
      firewall; and,

   o  Attackers cannot exhaustively attempt to connect to many FQDNs or
      IP addresses via source routing and use the error messages as an
      indication of whether the queried machine exists.  For this attack
      to be prevented, the proxy must allow only "profile" or "endpoint"
      connections, always refusing to even attempt source-routed
      connections.  This latter attack can also be thwarted by requiring
      a SASL identification before allowing a TUNNEL channel to be
      started, but this can have higher overhead.







New                       Expires June 5, 2003                 [Page 17]


Internet-Draft               TUNNEL Profile                December 2002


Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
        3080, March 2001.

   [3]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
        2001.

   [4]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [6]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.


Author's Address

   Darren New
   5390 Caminito Exquisito
   San Diego, CA  92130
   US

   Phone: +1 858 350 9733
   EMail: dnew@san.rr.com




















New                       Expires June 5, 2003                 [Page 18]


Internet-Draft               TUNNEL Profile                December 2002


Appendix A. IANA Considerations

A.1 Registration: BEEP Profile

   If the IESG approves this memo for publication, then the IANA
   registers the profiles specified in this section and selects an IANA-
   specific URI, e.g., "http://iana.org/beep/TUNNEL".

   Profile identification: http://xml.resource.org/profiles/TUNNEL

   Message exchanged during channel creation: "tunnel"

   Messages starting one-to-one exchanges: "tunnel"

   Messages in positive replies: "ok"

   Messages in negative replies: "error"

   Messages in one-to-many exchanges: None.

   Message syntax: See Section Section 3 of this document.

   Message semantics: See Section Section 4 of this document.

   Contact information: See the Author's Address appendix of this
      document.

   Any extensions to this protocol MUST be documented in a Standards
   track RFC."

A.2 Registration: The System (Well-Known) TCP port number for TUNNEL

   A single well-known port is allocated to the TUNNEL profile.  Upon
   allocation, Section 5 will be updated to reflect the correct
   allocated port.

   Protocol Number: TCP

   Message Formats, Types, Opcodes, and Sequences: See Section 3.

   Functions: See Section 4.

   Use of Broadcast/Multicast: none

   Proposed Name: TUNNEL Profile

   Short name: tunnel




New                       Expires June 5, 2003                 [Page 19]


Internet-Draft               TUNNEL Profile                December 2002


   Contact Information: See the "Authors' Addresses" section of this
      memo

















































New                       Expires June 5, 2003                 [Page 20]


Internet-Draft               TUNNEL Profile                December 2002


Appendix B. Acknowledgements

   The author gratefully acknowledges the contributions of  Marshall
   Rose, Greg Matthews, and Ben Feinstein.

   Inspiration for this profile comes from the Intrusion Detection
   Working Group of the IETF.












































New                       Expires June 5, 2003                 [Page 21]


Internet-Draft               TUNNEL Profile                December 2002



Appendix C. Changes from Previous Version

   The RFC editor is requested to remove this section and its entry in
   the table of contents before publication.

C.1 Changes since -04

   Added support for IPv6 address literals.

C.2 Changes since -03

   Added IESG suggested text regarding protocol extensions.

C.3 Changes since -02

   Addition of port number to elements with "srv" since srv is optional.
   Correction of minor typo's in that area.

   Renamed "References" section to "Normative References".

C.4 Changes since -01

   Reference to RFC 2119 added.

   Updated DTD identification headers.

   Minor typographical changes.
























New                       Expires June 5, 2003                 [Page 22]


Internet-Draft               TUNNEL Profile                December 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















New                       Expires June 5, 2003                 [Page 23]