[BXXPwg] BEEP "Session Broker" Profile: Necessary and Useful?

john d. beatty jbeatty@gonesilent.com
Tue, 10 Jul 2001 09:18:11 -0700


This is a multi-part message in MIME format.
--------------020501010608050602080504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I've been working on a BEEP "Session Broker Profile" that aims to define 
a profile that can be used to broker BEEP session creation for peers 
that are not directly addressable/reachable because of NATs and 
firewalls, and I'd appreciate some community feedback. The goal is to 
establish a direct-as-possible BEEP session between two peers in both 
the single NAT/firewall and double NAT/firewall scenarios.  This profile 
provides for "reverse connections" in the single NAT/firewall case and 
"tunnelled connections" in the double NAT/firewall case via an 
intermediary "session broker" peer.

I have attached the beginning of an I-D defining the profile (of course, 
it hasn't been filed with IETF or anything--this is less formal than it 
looks!).  Please note that this is a rough first draft that only 
includes the rationale and a sampling of examples.

My guess is that some people are going to say "just use APEX" to do 
asynch messaging between firewalled/NATted peers.  While I agree that 
asynch messaging is certainly very useful, I believe the concept of 
establishing optimal BEEP sessions in the land of NATs and firewalls is 
also a useful concept, esp. for applications needing high-volume data 
transfer.  In fact, I believe this profile is orthogonal to APEX; it 
could actually be used to establish BEEP sessions between APEX peers. 
 The other thing that people might say is "use the TUNNEL profile".  I 
believe what the TUNNEL does is define a BEEP proxy that lives in a 
demilitarized zone in an enterprise (i.e., it's analogous to an HTTP 
proxy).  Note that I actually do leverage the TUNNEL profile for the 
double NAT/firewall scenario.

So, my questions are:
 - What do people think of premise and goals of this Session Broker profile?
 - Has anyone been working on something similar? (I'm pretty new to BEEP)

There are a number of issues in the details of the profile, but I'd like 
to have a high-level discussion first to make sure that lower-level 
discussions would be worthwhile.  I do have a number of lower-level 
questions, primarily around service provisioning, authentication, 
authorization, etc. Those details are somewhat overlooked in my draft.

john

--------------020501010608050602080504
Content-Type: text/plain;
 name="draft-jbeatty-beep-session-broker-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-jbeatty-beep-session-broker-00.txt"



Network Working Group                                          J. Beatty
Internet-Draft                                    Sun Microsystems, Inc.
Expires: January 8, 2002                                   July 10, 2001


                      BEEP Session Broker Profile
                  draft-jbeatty-beep-session-broker-00

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 January 8, 2002.

Copyright Notice

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

Abstract

   This memo describes a BEEP profile that allows an intermediary peer
   to broker BEEP session establishment between two peers that are not
   directly reachable or addressable with respect to each other due to
   firewalls or NAT gateways.

1. Rationale

   The BEEP [1] Session Broker profile provides a mechanism for two BEEP
   peers to establish a BEEP session with each other when either or both
   peers are not directly reachable with respect to each other.  This is
   a common scenario on the Internet as peers are frequently behind
   either a firewall or a Network Address Translating (NAT) gateway.  To



Beatty                   Expires January 8, 2002                [Page 1]

Internet-Draft         BEEP Session Broker Profile             July 2001


   aid in BEEP session establishment, we name a third peer to be an
   intermediary to broker session establishment, and possibly relay all
   traffic in the "double NAT/firewall" sceniaro.  The goal is to
   provide as direct of a connection between two peers as possible for
   peer-to-peer computing.

   Given two peers, Peer A and Peer B, where Peer A wishes to establish
   a BEEP session with Peer B, there are three cases to consider:

   o  Peer B is directly reachable from Peer A.  In this case, Peer B
      has a public IP address, or Peer A and Peer B are on the same
      private network, and Peer B is not firewalled to BEEP connections.
      Peer A is free to establish a BEEP session with Peer B as normal;
      the BEEP Session Broker profile is not needed.

   o  Peer B is not reachable from Peer A, but Peer A is directly
      reachable from Peer B.  This case is commonly referred to as the
      "single NAT/firewall" case.  In this case, Peer B establishes a
      "broker relationship" with some Peer C such that Peer B initiates
      and maintains a persistent BEEP session with Peer C.  When Peer A
      wants to establish a session with Peer B, it establishes a session
      with Peer C (if one is not pre-existing) and sends a "broker-
      splice-request" element.  Peer C sends a "broker-splice-complete"
      element to Peer B with Peer A's network address, at which point
      Peer B establishes a BEEP session with Peer A.  This is called the
      "brokered-spliced" session-establishment method.

   o  Peer B is not reachable from Peer A, and Peer A is not reachable
      from Peer B.  This case is commonly referred to as the "double
      NAT/firewall" scenario.  In this scenario, Peer B establishes a
      "broker relationship" with some Peer C such that Peer B initiates
      and maintains a persistent BEEP session with Peer C.  When Peer A
      wants to establish a session with Peer B, it establishes a session
      (if one is not pre-existing) with Peer C and sends a "TUNNEL"
      element conforming to draft-ietf-idwg-beep-tunnel-01 [2], with the
      endpoint attribute specified as Peer B's unique "peer id".  Peer C
      sends a "broker-tunnel-callback-request" element to Peer B, at
      which point Peer B establishes a new BEEP session with Peer C and
      sends a "broker-tunnel-callback-complete" element, at which point
      Peer C sets up a tunnel between Peer A and Peer B.  This is called
      the "brokered-tunnelled" session-establishment method.

   Note that in the first two cases, Peer A must have become privy to
   the broker relationship that Peer B established with Peer C.  How
   Peer A became privy to this knowledge is outside the scope of this
   document.

   Also note that Peer A must have special knowledge about its



Beatty                   Expires January 8, 2002                [Page 2]

Internet-Draft         BEEP Session Broker Profile             July 2001


   reachability from Peer B in order to decide whether to send a
   "broker-splice-request" element or a "TUNNEL" element to Peer C.  How
   Peer B determines this is outside the scope of this document.

   When a peer establishes a broker relationship with another peer, a
   unique peer ID for the brokered peer must be agreed upon.  Peer A
   must know Peer B's peer ID when it sends either the "broker-splice-
   request" or "broker-relay-request".  How Peer A became privy to Peer
   B's peer ID is outside the scope of this document.

2. Examples

   The first two example show account provisioning and sign-in
   functionality.  The next two examples show the actual BEEP Session
   Brokering functionality.

2.1 Session Broker Service Provisioning

   In this example, we show Peer B provisioning a Session Broker
   relationship with Peer C.  This is a one-time operation.  (TODO:
   there will also be a broker-unregister)

   Peer B                     Peer C
     ------ xport connect ------>
    <------- greeting ---------->
     --- broker-register [1] --->
    <----------- ok -------------

   Notes:

   [1] The broker-register element looks like this:
   <broker-register pid="1234567890" />

2.2 Signing in to a Broker Peer

    After a peer establishes a relationship with a broker, it needs to
   log in to initialize the broker control session.  Note that in the
   following example, the BEEP session that was used for session
   provisioning could be used for signing in.  This example presumes
   that the peer had already provisioned Session Broker service.  (TODO:
   Add notes about authentication/authorization)

   Peer B                     Peer C
     ------ xport connect ------>
    <------- greeting ---------->
     ---- broker-login [1] ----->
    <----------- ok -------------




Beatty                   Expires January 8, 2002                [Page 3]

Internet-Draft         BEEP Session Broker Profile             July 2001


   Notes:

   [1] The broker-login element looks like this:
   <broker-login pid="1234567890" />

2.3 Brokered-Spliced Session Establishment

    The broker-splice-request element is used when Peer A is directly
   accessible from Peer B.  In this example, Peer B has already
   established a BEEP session with Peer C and performed a broker-login
   as in the example above.  In this example, there are three separate
   TCP connections, signified by a series of -'s, ='s, and ~'s,
   respectively.

   Peer A                      Peer C                           Peer B
      ------ xport connect -------->
     <------ greeting ------------->
      -- broker-splice-request[1] ->
                                   === broker-splice-complete[2] ==>
     <--------- ok ----------------
     <~~~~~~~~~~~~~~~~~~~~~ xport connect ~~~~~~~~~~~~~~~~~~~~~~~~~
     <~~~~~~~~~~~~~~~~~~~~~~~~ greeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~>


   Notes:

   [1] The broker-splice-request element looks like this:
   <broker-splice-request pid="1234567890" addr="128.187.2.21:9800"/>

   [2] The broker-splice-complete element looks like this:
   <broker-splice-complete pid="1234567890" addr="128.187.2.21:9800">




















Beatty                   Expires January 8, 2002                [Page 4]

Internet-Draft         BEEP Session Broker Profile             July 2001


2.4 Brokered-Tunnelled Session Establishment

    The TUNNEL element is used when Peer A is not directly accessible
   from Peer B.  In this example, Peer B has already established a BEEP
   session with Peer C and performed a broker-login as in the example
   above.  In this example, there are three separate TCP connections,
   signified by a series of -'s, ='s, and ~'s, respectively.  The
   brokered session is signified by the last line.  ("greeting").  Note
   that the BEEP TUNNEL profile is used to set up this connection.

   Peer A                     Peer C                            Peer B
      ------ xport connect ------>
     <------ greeting ----------->
      --- start TUNNEL[1] ------->
                                 === broker-tunnel-request[2] ====>
                                 <~~~~~~ xport connect ~~~~~~~~~~~
                                 <~~~~~~ greeting ~~~~~~~~~~~~~~~~>
                                 <~~~ broker-tunnel-complete[3] ~~
                                 ~~~~~~ start TUNNEL[4] ~~~~~~~~~~>
                                 <~~~~~~~~~~ ok ~~~~~~~~~~~~~~~~~~
                                 <========== ok ==================
     <---------- ok -------------
     <----------------------- greeting ~~~~~~~~~~~~~~~~~~~~~~~~~~>


   Notes:

   [1] The TUNNEL element looks like this:
   <tunnel endpoint="1234567890"/>

   [2] The broker-tunnel-request element looks like this:
   <broker-tunnel-request id="1234"/>

   [3] The broker-tunnel-request element looks like this:
   <broker-tunnel-complete id="1234"/>

   [4] The TUNNEL element looks like this:
   <tunnel endpoint="1234567890"/>

3. Message Syntax

   TODO

4. Message Semantics

   TODO

References



Beatty                   Expires January 8, 2002                [Page 5]

Internet-Draft         BEEP Session Broker Profile             July 2001


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

   [2]  New, D., "The TUNNEL Profile", draft-ietf-idwg-beep-tunnel-01
        (work in progress), February 2001.


Author's Address

   John D. Beatty
   Sun Microsystems, Inc.
   600 Townsend
   Suite 349-E
   San Francisco, CA  94103
   US

   EMail: jbeatty@jxta.org
   URI:   http://www.jxta.org

Appendix A. Typeset Information

   This document written in XML using the xml2rfc engine and the RFC
   2629 DTD, written by M.  T.  Rose.




























Beatty                   Expires January 8, 2002                [Page 6]

Internet-Draft         BEEP Session Broker Profile             July 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Beatty                   Expires January 8, 2002                [Page 7]


--------------020501010608050602080504--