[standards-jig] A Proposal to the DTCP/JOBS/PASS madness

Justin Karneges justin-jdev at affinix.com
Sat Dec 14 01:48:31 UTC 2002


> [X] I'm not sure if I got that correct. You may have meant that
> target tells to the initiator his own ip and port he used for the TCP
> connection. But that would not work, because if target is behind NAT,
> he does not know the ip or port the initator would see.

Since I can't think of an immediate solution to that problem, I decided to see 
what I could change to DTCP to make it better fit the bill.  Let me share it:

First, we change the handshake to use HTTP, similar to Matthew's idea for 
JOBS.  Most of the ideas taken below were done by simply modifying his JOBS 
example without verifying the HTTP RFC, and so they may be wrong.

As before, the initiator requests a DTCP session with the target, specifying 
the Proxy host as one of the choices.

When the target connects to the Proxy via TCP, the initiator JID is encoded as 
base64 and sent as the hostname of an HTTP CONNECT request.  The target JID 
is specified using a custom header.

-- Target to Proxy:
  CONNECT anVzdGluQGFuZGJpdC5uZXQvUHNp HTTP/1.1
  DTCP-client: dizzyd at jabber.org/Nitro

The Proxy, rather than actually connecting to that host as TCP (like a normal 
HTTP proxy), should decode it to a JID and send an iq:

  <iq type="set" to="justin at andbit.net/Psi" id="proxy_1">
    <query xmlns="dtcp#proxy">
      <from>dizzyd at jabber.org/Nitro</from>
      <proxykey>watermelon</proxykey>
    </query>
  </iq>

'watermelon' is a unique key to reference this session.  The initiator then 
connects to the Proxy:

-- Initiator to Proxy:
  CONNECT watermelon HTTP/1.1

-- Proxy to initiator:
  HTTP/1.1 100 Continue

Then the proxy sends the original request received from the target, so that 
either side can proceed as if there were no proxy.

-- Proxy to initiator:
  CONNECT anVzdGluQGFuZGJpdC5uZXQvUHNp HTTP/1.1
  DTCP-client: dizzyd at jabber.org/Nitro

At this point, the connections are bridged.  Further communication will be 
described as between the initiator and target.

-- Initiator to target:
  HTTP/1.1 200 OK

HTTP CONNECT was a success.  TLS would happen now if it were decided 
beforehand.

-- Target to initiator:
  GET / HTTP/1.1

-- Initiator to target:
  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: DTCP

-- Target to initiator:
  GET / HTTP/1.1
  Authorize: DTCP key=[DTCP_initiator_key]

-- Initiator to target:
  HTTP/1.1 200 OK
  DTCP-key: [DTCP_target_key]

At this point, the channel is bridged.

The other change needed is that SSL/TLS must be decided upon during the Jabber 
negotiation instead of the 'starttls' method.  This could be done with a 
simple <ssl/> element in the request.  If the iq-result contains <ssl/> also, 
then both sides MUST use SSL.  If missing from the iq-result, then it MUST 
NOT be used.

-Justin



More information about the Standards mailing list