[Jingle] SOCKS5 Jingle Transport

Dirk Meyer dmeyer at tzi.de
Thu May 28 08:04:44 CDT 2009


Hi,

sorry for being away most of the time lately, I hope I will have time to
answer some mails and update some XEPs the next weeks. A PhD thesis sort
of keeps you busy. :(

Anyway, Klaus implemented XEP-0260 and run into some problems we
discussed and tried to solve. Before I update the XEP, I want to discuss
our ideas here in case we missed something.

1. To get the best possible transport method, we need some sort of
   priorities. If the initiator has the proxy as second streamhost, it
   is very likely to happen that the responder connects to it before the
   initiator had a change to try all non-proxy based streamshosts from
   the responder. So we propose either priority or a type attribute with
   type in direct, teredo, proxy, etc.

2. Why does the streamhost has a jid attribute? The responder will
   _never_ connect to it. A simple unique id is all we need. The id MUST
   be unique for initiator and responder. The responder MUST NOT
   announce a streamhost with the same id. Two streamhost MUST NOT have
   the same id to know what worked when streamhost-used is send. If we
   use the jid, two streamhosts with the same jid (e.g. IPv4 and IPv6)
   look the same. Example from XEP-0261:

        <streamhost
            jid='juliet at capulet.lit/balcony'
            host='192.169.1.10'
            port='6539'/>
        <streamhost
            jid='juliet at capulet.lit/balcony'
            host='134.102.201.180'
            port='16453'/>
        <streamhost
            jid='juliet at capulet.lit/balcony'
            host='2001:638:708:30c9:219:d1ff:fea4:a17d'
            port='6539'/>

   If I send streamhost-used with jid juliet at capulet.lit/balcony you
   have no idea what streamhost I used.

3. Since the initiator connects to the responder and the other way
   around, we have some deadlock situations in the draft. Therefore we
   propose:

   a. A client MUST either send streamhost-used or
      streamhost-error. Unless both clients send one of these messages
      the negotiation is not finished.

   b. If both send streamhost-used the streamhost with the best priority
      is used. If it is the same, the message from the initiator wins.

4. Now the funny part we missed completely: when can I send data? Let us
   assume we play XTLS. This means the initiator will start the TLS
   handshake once the SOCKS5 stream is up and running. And let's assume
   the responder has the better streamhost we want to use. After
   streamhost-used message exchange both know that. If it is a proxy,
   the responder has to contact the streamhost to activate it. The
   initiator has no way of knowing when the responder did this. We need
   a streamhost-activated message or something like this if we use a
   proxy. BTW, we know that if use a proxy if we use the type attribute
   in the streamhost.

I guess that's it and I did not miss something. Comments?

BTW, any reason why XEP-0260 is called "Jingle SOCKS5 Bytestreams
Transport _Method_" and XEP-0261 only "Jingle In-Band Bytestreams
Transport"?


Dirk

-- 
In some cultures what I do would be considered normal.



More information about the Jingle mailing list