[standards-jig] DTCP Relay (proxy)
justin-jdev at affinix.com
Thu Dec 12 09:05:17 UTC 2002
> ---- 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
> 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 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