[standards-jig] DTCP Relay (proxy)

Dave Smith dizzyd at jabber.org
Thu Dec 12 05:46:36 UTC 2002

Hash: SHA1

On Wednesday, Dec 11, 2002, at 15:49 America/Denver, Justin Karneges 

> One concern with DTCP is that it does not have a provision for 
> utilizing a
> proxy on the server to defeat the "double-NAT" case.  Normally I would
> consider this to be better left to an extension or separate proposal, 
> however
> I took a stab at it anyway and it seems it would be very easy for DTCP 
> to
> support a simple proxying mechanism.

Yes! Excellent!

I have two issues remaining with this JEP:

- ---- Sequencing of connection establishment and negotiation ----

Having both clients try and blindly connect to each other without any 
further negotiation is certainly a simple approach, but I fear it will 
not scale very far and introduces complexity in implementation due to 
the fact that "clients that are listening for connections must be ready 
for anything." The whole point of protocol is to reduce the number of 
states a network can exist in to something manageable. In this 
particular case, trying to propose a solution which deals with either 
or both clients connecting to each other can be hairy, at best.

To this end my first proposal is that we remove the idea that both 
clients try and connect to each other. That is to say, only the Target 
will attempt to connect to the Initiator; never vice-versa. This 
dramatically reduces the number of states that we have to keep track 
of. So the new process flow will be:

1.) Initiator sends IQ to Target w/ list of ips/ports
2.) For each provided ip/port pair:
	Target attempts to connect to the ip/port
	If connection fails:
		Try next ip/port
		Continue to step 4.
3.) If connection is not established:
	Return IQ error to Initiator
4.) Send IQ result to Initiator indicating connection has been 

Given that DTCP is meant to be a generic protocol, this works nicely. 
Selecting the Initiator and Target roles can be abstracted to a 
higher-level protocol (such as file transfer). All negotiation and 
determination of who should initiate can be done via a protocol such as 
Disco and/or Feature-Neg. After all, it doesn't really matter who 
initiated the connection once the connection is established -- it's 
supposed to be a bi-directional stream, right? :)

Things brings me to my second issue...

- ----  Bytestream Protocol ----

With a little slight of hand we can make it transparent to the Target 
as to whether or not they are actually connecting directly to the 
Initiator (p2p) or to a proxy. When the Target connects to the 
Initiator (or a proxy, thereof) the protocol would be modified to look 
something like:

CONNECT\0<key>\0<initiator jid>\0<target jid>\0

Side note: Why use \0 (NULL) as a delimiter? Because it's an invalid 
character in a JID. :)

If the Target is clear to receive or transmit data on the connection it 
would receive a corresponding:


At this point the connection is ready. Alternatively, it can receive an 
error, followed by having the socket closed by the accepting party:


Now, the slight of hand that I mentioned here is that with the CONNECT 
statement there is sufficient information in that statement for a proxy 
to match up a Initiator with a Target. Of course, in order for that to 
work correctly, the Inititator must connect to the proxy first using 
something like:

CREATE\0<key>\0<inititator jid>\0<target jid>\0

Which informs the proxy to the start listening for a CONNECT command 
with the matching key and jids. (We won't get into authentication 
here). Once a corresponding CONNECT has come in from the Target, the 
proxy would send an OK command to the Target and Initiator (in any 
order). From that point on, the bytes are passed between the two 
bytestreams by the proxy without any interpretation. Only AFTER this 
has happened should the STARTTLS command be executed (always by the 
Target?) -- this will allow the two parties to establish a (relatively) 
secure connection even with a middleman. My theory here is that this 
doesn't make breaking SSL any harder than it already is -- we're simply 
helping the man in the middle intercept the communications easier -- 
but SSL is supposed to deal with that, right?

The simpler case here is that the Target connected directly to the 
Initiator -- in this case, the Initiator obviously doesn't have to do 
anything but signal OK to the Target and start processing.

Interestingly enough, I think this also solves my issues with 
authentication in this protocol. If a user wishes to establish an 
authenticated connection, they can do so using SSL's certificate 
system. *ponder*. I'll have to think about that one a bit.

I guess that's about it. The sequencing changes and protocol changes 
allow for simplicity, flexibility (in the p2p/proxy protocol), and 
security (using SSL). Comments?


Version: PGP 8.0 (Build 349) Beta


More information about the Standards mailing list