[standards-jig] DTCP Relay (proxy)

Jan Niehusmann jan at gondor.com
Thu Dec 12 12:53:08 UTC 2002

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

I write this mail to sum up a discussion I had with Justin:

- I agree that the sequencing changes are a bad idea. They remove a
  major advantage of DTCP, and require additional negotiation on higher
  protocol levels. That would lead to duplication of work at these higher

- There may be a better alternative to Justins relay proposal. There
  already is a JEP specifying relay functionality, namely JEP-0003,
  Even with unmodified DTCP, the one peer of the communication may
  decide to contact a PASS proxy instead of opening a local port, and
  request a connection on that PASS port. This would work without
  support on the other peer. So we agreed implementing relay behaviour
  using PASS is good for three reasons:
  - it is optional, and a DTCP implementation not implementing PASS
    could still connect to an implementation using PASS. No need to the
    DTCP protocol needed.
  - it uses an existing JEP and doesn't invent the wheel once again
  - it provides a transparent channel, and therefore allows end-to-end
    SSL encryption naturally

But then, DTCP through PASS has one major disadvantage: If both a direct
connection and a PASS connection are possible, the direct connection
should be prefered. But with the current DTCP proposal, one can't 
implement such preferences. That is because only one peer knows which 
<host/> should be prefered, but the other peer is the one who initiates
the connections.
Therefore, we propose the follwing change to the JEP: Instead of using
arbitrary order, the given <host/>s should be tried in the order they
where sent in the <iq/>. It's still allowed to try more than one host at
the same time, but it's not allowed to reverse the order of hosts.
If more than one host is tried at the same time, it's up to the other
peer (the one that knows which connection is 'cheaper') to accept the
direct connection and refuse the PASSed one.

To summarize, this proposal allows relayed DTCP connections with minimal
changes to the current DTCP JEP, by use of the already existing PASS
protocol. Clients that don't want to bother with PASS can safely ignore
it, and a relayed connections are possible as soon as one of the clients
supports PASS.


More information about the Standards mailing list