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

From: "john d. beatty" <[email-masked]>
Date: Tue, 10 Jul 2001 09:18:11 -0700

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

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: [email-masked]
   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]

---

From: "john d. beatty" <[email-masked]>
Date: Tue, 10 Jul 2001 17:20:18 -0700

Thanks for the excellent feedback, Darren. I believe I'm in agreement 
with your idea about using the TUNNEL profile with some extra 
configuration and a bit of extension.  I had originally considered 
trying to extend the TUNNEL profile, but originally decided against for 
a couple of reasons, which I hint at inline below.  But overall, I think 
trying to use the TUNNEL profile is the way to go.

Inline below I explain some of my rationale (esp. for the persistent 
connections), and expand on some of the issues with extending the TUNNEL 
profile.

I'll work up some examples in the next day or so on how the extended 
TUNNEL profile might work.

thanks again,
john

Darren New wrote:

>"john d. beatty" wrote:
>It's unclear to me why there needs to be a "callback" or "brokered
>tunnel" here. Why would A, B, and C not just use the TUNNEL profile,
>with B establishing a new session with C each time the previous session
>gets a TUNNEL <start>
>
>
>In other words, in this case, I would have the following steps:
>
>1) B establishes one or more BEEP sessions to C. 
>   B advertises that it'll serve TUNNEL on each of these sessions. 
>2) B uses SASL to identify itself to C over all sessions.
>3) A establishes a connection+session with C.
>4) A requests that C tunnel to B with TUNNEL <start>.
>5) C picks one of the sessions already open to B and
>   sends a TUNNEL <start>.
>6) B accepts that <start> and sends a new greeting to A, etc.
>7) B, if the load is acceptable and etc, establishes a new session
>   with C in order to accept more TUNNEL requests from outside.
>
>Note that this requires no new profiles. It's simply a matter of
>configuration. SASL is used for identification in the broker-login sense
>(which one would assume is a good idea if one is in a situation where
>one is using NAT or firewall to start with). And of course one can use
>SASL/ANONYMOUS if one doesn't care after all.
>
>The trick is that while B initiates the session, C can <start> the
>TUNNEL to B (at A's request).
>
I like this.  Simpler, cleaner.  The only advantage that I see with the 
"one persistent session" from B to C that I was proposing is that the 
session could be used for multiple things, including asynch message 
relaying (ala APEX).

>Note too that this is effective even if A is behind multiple firewalls
>(say, departmental and corporate), while it's not clear to me how the
>brokering profile addresses such things.
>
The session brokering profile would be used in conjunction with the 
TUNNEL profile if Peer A was behind multiple firewalls.  It's just 
trying to connect to C.

>In addition, the interaction between TLS and the various brokering modes
>would need to be explored. Actually, in general, I think a lot of
>security implications would need to be explored. :-) For example,
>imagine a DoS attack consisting of my machines making a bunch of
>connections to 3rd party machines, and telling their brokers to all
>connect back to your server.
>
Right.  This is an issue of whether the TUNNEL profile is used, or this 
Session Broker profile is used.  All the normal anti-DoS measures would 
need to be built-in to the peer providing tunnelling services.

>This is a case that TUNNEL addresses only with the inefficiency of C
>continuing to forward packets. However, I think it would be easier to
>extend TUNNEL to handle this efficiently than it would be to design and
>implement an entirely new profile.
>
Agreed.

>For this case, A is asking B to set up an outgoing session. I think a
>better way of handling this would be to have an extra attribute on the
>TUNNEL argument (call it "originator"), which would specify that the
>address on that element is actually the originator. If B can establish a
>connection back to A at that address, it does so, and rejects the TUNNEL
><start> with an appropriate error code that means "Look for a new
>incoming connection from me." If B cannot establish a connection back to
>A at that address, then it accepts the TUNNEL <start> and passes packets
>through C. If the attribute is set on an element that is not the
>innermost element, B would be expected to use TUNNEL to get back to A. 
>(This is getting complicated, yes. :-)
>
>This organization has the benefit that A doesn't need to know whether B
>can call out to A or not. A merely advertises that it's willing to
>accept connections. B can decide what the appropriate method of contact
>is, whether to accept the TUNNEL through C, or to try to establish a
>reverse-connection back to A. (As far as I can see, the primary
>differences are that C is taken out of the loop for better efficiency,
>and A can tell B to call back a *different* server.)
>
It is more efficient if A knows at least something about its 
reachability so various peers don't have to keep trying to figure it 
out.  There's no reliable way for B to tell whether the address for A is 
going to work or not. I'm thinking about using some simple peer 
introspection mechanism that is a simple reachability test that A can 
used to test itself. The complicated part comes because peers operate on 
various address spaces (essentially one public network and many private 
networks).  Let me think about some ways to extend the TUNNEL profile.

>In other words, A really is tunneling to B via C, but the range of
>operations that A can invoke is very limited. Indeed, it is limited
>precisely to "call me back." Since TUNNEL already defines everything
>needed for addressing a peer behind a firewall, it would seem to make
>more sense to extend TUNNEL with a separate operation or parameter,
>rather than beginning an entirely new profile to do exactly what TUNNEL
>does, only with one more datum at the end.
>
>In addition, it seems kind of odd to me that A would be contacting B to
>say "call me up" with no indication of what B is supposed to do when it
>contacts A. Presumedly, a different TUNNEL identifier would have to be
>used at B for each service that A might provide. For example, A
>requesting that B call it back to get printer status would be different
>than A requesting that B call it back to establish an APEX relay-relay
>connection, since these are likely implemented in two different programs
>in B. Because of this, I'd expect another parameter in the TUNNEL
><start> for the callback case, namely the URI that the program doing the
>reverse connection should support. In this case, I would say that if the
>"originator" attribute says that the element describes the caller, then
>it may have an address *and* a "profile" attribute, indicating that B
>should attempt to contact A at that address, starting the indicated
>profile. (Implementation-wise, B might have to start a new program with
>that start-up information, or otherwise find an executable capable of
>dealing with the indicated profile, or reject the TUNNEL entirely if
>such a profile is not available at B.)
>
Good point.  I'd be more keen to use a unique ID rather than a URI, 
however, to reduce possibilities of collisions.

>Now, what we don't have if we only use TUNNEL is a registration by which
>B can inform C of its willingness to accept connections, and then have
>no sessions established with C until A requests C make such a
>connection. (I.e., we have no way for B to specify to C a mapping from
>B's endpoint identifier to B's address.) However, I assumed that would
>be a local configuration at C, rather than at B. That is, I had assumed
>that the SASL login would be sufficient to identify to C the
>configuration of B. Certainly if the point of the firewall is to
>restrict traffic to approved connections, the firewall is the
>appropriate place to configure such things.
>
Note that I do not want to make the assumption that C is within B's 
firewall or that B is addressable/reachable from C.  However, a nice 
optimization in the case that B is addressable/reachable from C is to 
obviate the need for the long-lived connection from B to C.  It does 
seems that some sort of account provisioning may be necessary to 
register an endpoint identifier.  It's possible that introspection 
services could be in-built to C that would determine reachability.

>Other comments on the specific draft proposals:
>
>2.1 vs 2.2 - What's the difference?
>
2.1 is account provisionining.  2.2 is saying "I'm willing to accept 
connections" (and also, "I'm offline/unwilling to accept connections")

>2.3 - Of course, you'll want more different forms for "addr". And what
>if B needs to use TUNNEL to get back to A? It looks like the channel
>between C and B is persistant, rather than being dropped after a single
>broker-splice-request?
>
>
>2.4 - What is the benefit of the ~~~ connection? Why not simply send the
>TUNNEL <start> over the === connection? B needs to establish a new
>connection with C in either case, so use the connection already
>established, and let B set up a new connection to C without A having to
>wait for it.
>
Looks like these are moot issues now.  However, on 2.4, the same thing 
applies: I was allowing for this persistent connection to be used for 
other things.

john

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: Darren New <[email-masked]>
Date: Tue, 10 Jul 2001 11:40:50 -0700

> includes the rationale and a sampling of examples.

I'll take a cut at making a few comments. Mind, I'm the author of
TUNNEL, so I might be a little nearsighted and/or biased. ;-)

>       the BEEP Session Broker profile is not needed.

We agree on this one. ;-)

Note that I've reversed the second and third case, as it makes it a
little easier to describe here. Hence, I talk about the case where both
A and B are firewalled next.

gets a TUNNEL <start>?

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
       San Diego, CA, USA (PST).  Cryptokeys on demand.
          Only a WIMP puts wallpaper on his desktop.

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 16 Jul 2001 11:11:13 -0700

hi. i suggest that the two of you have a private conversation as to what
minimal sets of mods to the tunnel profile are necessary to meet john's
requirements, and then you can send a note to the idwg mailing list
explaining what you want to do.

time is of the essence here, that wg would like to be closing up shop
soon...

thanks,

/mtr

---

From: Ben Feinstein <[email-masked]>
Date: Thu, 26 Jul 2001 09:39:54 -0700 (PDT)

> time is of the essence here, that wg would like to be closing up shop
<> thanks,