[standards-jig] DTCP Relay (proxy)

Justin Karneges justin-jdev at affinix.com
Thu Dec 12 09:05:17 UTC 2002

Hi Dave,

> ---- Sequencing of connection establishment and negotiation ----
> 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:

After implementing DTCP multiple times (as each draft changed), I can say that 
the latest spec is the simplest to implement when weighed against its 
capability.  An entity already needs to act as both a server and client, and 
in my experience, doing them at the same time or separate makes very little 
difference in the implementation.  The difference it does make is in 
performance, either by requiring extra steps or steps that must wait for 
others to complete.

Making it so only the target connects to the initiator reduces the capability 
of DTCP down to that of IRC's DCC, where the initiator must always be able to 
accept connections.  Though DTCP is supposed to be simple, it was also 
intentionally designed to be at least more capable than DCC.

My goal was to have the capability of the AIM direct connect protocol, which 
allows a connection to be made, regardless of who initiates it, so as long as 
one of the peers can accept a connection.  Under your premise, this would 
mean that after DTCP fails in one direction, the target would need to 
initiate a return request that might fare better.  This brings is back to the 
active/passive design of the older DTCP spec, where it might take up to two 
iq-set/results before you have a connection.

Such extra negotiation complicates higher level applications.  Take File 
Transfer, for instance.  Should it have to detail this strange DTCP procedure 
of "try one way, then try the other" ?  The DTCP protocol should already have 
this provision built-in, hence my merging of active/passive in the later 

If you're suggesting that there not be such secondary attempts or reverse 
connections, then I think we'd be missing out on a lot of potential.  This is 
one of the primary problems I have with iq:oob.  Please don't drag me back 
there. :)

> determination of who should initiate can be done via a protocol such as
> Disco and/or Feature-Neg.

Disco/F-Neg is not enough to determine who can accept a connection.  In the 
world of NAT, the only way is trial-and-error.

> ----  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

Alright, at least this is kind of cool.  I like transparency.

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

I'm not sure I agree with this though, as this extra "creation" step is a high 
price to pay for transparency.

> 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?

It would be nice to have SSL across the proxy, which is something that 
DTCP-Relay does not address (currently).

> 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 think you're right that the use of SSL is necessary for a secure 
authentication.  However, this is already the case with the current protocol, 
I believe.

> 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?

Overall, I'm not in agreement with your proposals, though mainly just with the 
first section.  I do agree that SSL over proxy needs to be addressed.

Glad to see some discussion on the list.


More information about the Standards mailing list