Subject: [BEEPwg] Callback Profile

From: "Eamon O'Tuathail" <[email-masked]>
Date: Thu, 22 Aug 2002 17:08:23 +0100

Is there a need for a callback profile, where an initiator peer asks the
listener peer to initiate a new session between the same two peers.
(i.e. peer A wishes peer B to initiate a session to peer A, but peer A
needs to tell peer B to do this - hence the callback profile). 

The motivation would be firstly to enhance security in certain
environments (a highly secure peer may only permit incoming connections
to request a callback, but expose no other functionality [apart from the
tuning profiles] to them), and secondly to work in environments when
there are business/technical restrictions on the number and direction of
open connections. 

A peer running on Windows XP Home can only maintain five simultaneous
incoming connections, and a peer running on Windows XP Professional can
only have 10 simultaneous incoming connections. 
[see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314882]
There are no restrictions on Windows 2000 Server or Windows .NET Server
on the number of incoming connections. For all the versions of Windows
mentioned, there are no restrictions on the number of outgoing
connections. 

One expensive option is to set up a traditional Windows client-server
network, which usually involves Windows Domains. This requires you to
buy 
Windows XP Professional for machines that only act as client (XP Home
will not suffice for Windows Domains), buy the Windows Server product
for machines that might have more than 10 incoming connections, and buy
a "Client Access License" for each client to permit it to access a
server. (you Linux guys can stop laughing now).

A much better option is to just put Windows XP Home on all the machines,
and using the callback profile arrange them as required - maybe point to
point, or maybe hub-and-spoke [if one peer exposes a service that many
other wish to use]. 

How would a callback profile work?
==================================
1) A peer [we call it the provider peer] that provides a popular service
or a high-security service based on BEEP would list the Callback Profile
in its Greeting message. Depending on local configuration this could be
the initial greeting message, or the one after the tuning reset
following TLS setup; also authentication may be required. 

2) A peer wishing to use the remote service [the user peer] would
establish a connection to the provider peer, configure security as
appropriate, and upon detecting the Callback Profile in the Greeting
message, would create a channel based on this profile. 

3) The user peer sends a single message on the callback channel to the
provider peer identifying the transport mapping details to use for the
callback - e.g. transport mapping type [RFC 3081, SCTP, multiple TCP
connections] and addressing [for RFC 3081, IP address and port to use].

4) The existing session is shut down. 

5) The provider peer initiates a session with the user peer based on the
addressing information provided. After that, it works just as normal. 

My questions:
=============

Anyone see any problems with this approach?

Anyone got a better solution?

Anyone got a good reference to security issues that have been uncovered
with other types of callback usage - e.g. ftp. 

An alternative to the callback profile in BEEP would be a simple UDP
message, but I would have security concerns about that. 

Eamon

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: "Paul Andrews" <[email-masked]>
Date: Thu, 22 Aug 2002 12:44:48 -0400

My reading of the Microsoft note is that this only applies to Microsoft
network services, not to arbitrary TCP connections. i.e. a single XP Home
machine can support 5 other remote machines where each remote machine can
perform any number of remote disk mounts, printer shares etc.

Have you tried just opening lots of BEEP connections to a peer running on an
XP machine?

To address one issue more directly: Opening a separate connection for
callbacks won't work if you're going through a NATing router (like the
little Linksys router I'm using at home at the moment).

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eamon O'Tuathail
> Sent: Thursday, August 22, 2002 12:08 PM
> To: [email-masked]
> Subject: [BEEPwg] Callback Profile
>
>
>

---

From: Gabe Wachob <[email-masked]>
Date: Thu, 22 Aug 2002 09:55:53 -0700 (PDT)

> mentioned, there are no restrictions on the number of outgoing

I think those numbers apply to netbios connections, not TCP connections.
While not personally testing this, I'm told that people routinely drop
servers on XP Pro and have > 100 simultaneous incoming TCP connections. If
this is true (and I do believe it is), this support bulletin is extremely
poorly written.

Are you seeing this limit behavior in practice?

	-Gabe

-- 
Gabe Wachob                       [email-masked]
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

---

From: Gabe Wachob <[email-masked]>
Date: Thu, 22 Aug 2002 11:05:20 -0700 (PDT)

I think there would be a lot of use for/interest in a rendezvous profile.
There is the tunnel profile but I don't think it address the "dual NAT"
problem (ie two parties, each behind NATs, trying to make connections).

This is an issue that goes beyond BEEP, of course.

	-Gabe

---

From: james woodyatt <[email-masked]>
Date: Thu, 22 Aug 2002 15:18:34 -0700

> This is an issue that goes beyond BEEP, of course.

I think both the Callback profile and the Rendezvous profile are 
actively BAD ideas.  I say this as a guy whose day job is maintaining 
the firmware in a NAT routing home Internet gateway appliance device.

I think that there are already plenty of good security mechanisms 
defined in the BEEP core; there is no additional security benefit to be 
had by employing a Callback profile.  If you don't believe me, then I 
recommend taking the idea immediately to your nearest friendly 
neighborhood Security Area specialist, and see how far you can go with 
it.  Consider this: the listener doesn't have to offer any profiles in 
its greeting message to initiators.  It can instead expect the 
initiator to offer the first tuning profile in its greeting.

Also, you should see draft-iab-unsaf-considerations-02.txt for a good 
description of the set of problems in this Rendezvous profile you are 
suggesting.  (I contributed section C.2 of that document.)

I've only seen one protocol for unilaterally fixing the public 
addresses of multiple peers in different private address realms that 
didn't make me want to wretch violently.  The latest version of it is 
described in draft-ietf-ngtrans-shipworm-07.txt, and it's used for 
establishing IPv6 connectivity by tunneling over UDP/IPv4.  The reason 
I make an exception for it is that it is clearly intended to let IPv6 
treat IPv4/NAT like the damage it is and route around it.

Please please please do not try to advance either of these ideas a 
Internet standards.

--james

---

From: Kevin Kress <[email-masked]>
Date: 22 Aug 2002 16:34:48 -0700

From what I have read the Callback and Rendezvous profiles both could be
created without even giving a thought to NAT.  NAT breaks 99% of what
the net is for anyway (he says through his NATed firewall).  In general
I try to ignore NAT in hopes that it will go away (ie IPv6 will be
used).  I think this is a case where ignoring NAT is the right thing to
do, both profiles can exist above that layer and allow the protocol
binding to handle all that nastiness.

As for security, I think both profiles have uses outside the strict
security realm.  An example Gabe mentioned was using the Rendezvous
Profile to allow anonymous connections.  Someone else mentioned the
callback being used for loadbalencing.

just my 2c

--Kevin