[standards-jig] A Proposal to the DTCP/JOBS/PASS madness
Dave Smith
dizzyd at jabber.org
Fri Dec 13 10:52:46 CST 2002
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings,
I did some thinking last nite and have an idea on how we can deal with
some of the outstanding issues facing the community. Let me now present
my case..
Concepts:
1.) Jabber needs a standardized way to establish a socket between
peers, whether it be direct or proxied.
2.) We should avoid inventing new wire protocols if at all possible
3.) TCP/IP makes no guarantees around identity of either end; as such,
any authentication mechanism we use does not necessarily need to be on
the actual direct or proxied socket -- authentication could happen
out-of-band (i.e. via a existing Jabber connection) and still be
sufficient.
Proposal:
There are three actors in this proposal.
A1.) Initiator -- a Jabber entity wishing to establish a TCP/IP
connection to another entity
A2.) Target -- the entity the Initiator is attempting to establish a
connection with
A3.) Proxy -- a Jabber entity which is not NAT/Firewalled and is
willing to be a middleman for the Initiator and Target's bytestream
There is one use case:
Goal: Establish a connection from the Target to the Initiator
Primary Flow:
PF1.) Initiator wishes to establish a connection to the Target
PF2.) Initiator sends its IP/port in a IQ/set to Target, accompanied by
a stream ID [A1]
<iq type='set' to='Target'>
<query xmlns='whoknows' sid='ABDE'>
<connection jid='Initiator' ip='127.0.0.1' port='5086'/>
<connection jid='Conn1' ip='28.84.2.1' port='3948'/>
</query>
</iq>
PF3.) Target connects to a provided connection[A2][A5]
PF4.) Target sends IQ/set to the JID of the connection it is connected
to for identification purposes
NOTE: The Target provides the IP/port of the _peer_ it is connected
to with a stream ID
<iq type='set' to='Conn1'>
<query xmlns='whoknows' sid='ABDE'>
<endpoint ip='...' port='...'/>
</query>
</iq>
PF5.) Target send IQ/result to Initiator w/ indication of what
connection was used
<iq type='result' to='Initiator'>
<query xmlns='whoknows' sid='ABDE'>
<connection jid='Inititator'/>
</query>
</iq>
PF6.) Initiator recieves IQ/set from PF4 [A6]
PF7.) Inititator sends IQ/result in response to PF4
PF7.) Target and Initiator are clear to send.
PF8.) Use Case Ends.
Alternates:
A1.) Initiator is NAT / Firewalled
A1.1) Initiator sends IQ/set with no <connection> elements
A1.2) Target returns IQ error
A1.3) Target may choose to take role of Inititator and go to PF1 to
propose alternative connections. The Target MUST continue to use the
same stream id.
A2.) Target is unable to connect to any of the provided IP/ports
A2.1) Target returns IQ/error
A2.2) GO TO PF1.
Target may take role of Initiator and go to PF1 to propose
alternative connections. The Target MUST continue to use the same
stream id.
A4.) Target recieves IQ/error from PF4
A4.1) Target closes connection
A4.2) Use Case Ends Unsuccessfully
A5.) Target does not wish to establish a connection with the Inititator
A5.1) Target returns IQ/error
A5.2) UCE Unsuccessfully
A6.) Target has connected to a Proxy (unknowingly)
A6.1) Proxy recieves IQ/set from PF4
A6.2) Proxy matches IQ/set with a connected socket
A6.3) Inititator recieves IQ/result from PF5
A6.4) Initiator connects to proxy and sends corresponds IQ/set as the
Target did in PF4
A6.5) Proxy recieves IQ/set from Inititator
A6.6) Proxy matches IQ/set with a connected socket
A6.7) Proxy matches the stream ids of the two sockets
A6.8) Proxy sends IQ/result to both Target and Initiator indicating
they are clear to send
A6.9) GO TO PF7
Sample Exchanges:
ClientA (Inititator) -> ClientB (Target) : Direct
==============================================================
ClientA:
<iq type='set' to='ClientB'>
<query xmlns='whoknows' sid='A01'>
<connection jid='ClientA' ip='192.168.4.1' port='4000'/>
</query>
</iq>
ClientB: (establishes connection)
<iq type='set' to='ClientA'>
<query xmlns='whoknows' sid='A01'>
<endpoint ip='192.168.4.1' port='4094'/> <!-- The port of the peer
that ClientB is actually hooked up to -->
</query>
</iq>
<iq type='result' to='ClientA'>
<query xmlns='whoknows' sid='A01'>
<connection jid='ClientA'/>
</query>
</iq>
ClientA:
<iq type='result' to='ClientB'>
<query xmlns='whoknows'/>
</iq>
Connection established.
ClientA (Inititator) -> ClientB (Target) : via ProxyA (proxy)
==============================================================
ClientA:
<iq type='set' to='ClientB'>
<query xmlns='whoknows' sid='A01'>
<connection jid='ClientA' ip='192.168.4.1' port='4000'/>
<connection jid='ProxyA' ip='23.12.12.1' port='4000'/>
</query>
</iq>
ClientB: (establishes connection to 23.12.12.1)
<iq type='set' to='ProxyA'>
<query xmlns='whoknows' side='A01'>
<endpoint ip='23.12.12.1' port='4959'/>
</query>
</iq>
<iq type='result to='ClientA'>
<query xmlns='whoknows' sid='A01'>
<connection jid='ProxyA'/>
</query>
</iq>
ClientA: recieves iq/result; establishes connection to 23.12.12.1)
<iq type='set' to='ProxyA'>
<query xmlns='whoknows' side='A01'>
<endpoint ip='23.12.12.1' port='4954'/>
</query>
</iq>
ProxyA: recieves both IQ/set from ClientA & ClientB; matches two
connections
<iq type='result' to='ClientA'>
<query xmlns='whoknows'/>
</iq>
<iq type='result' to='ClientB'>
<query xmlns='whoknows'/>
</iq>
Connection Established.
Other comments:
==============================================================
* This methodolgy does not require _ANY_ wire protocol on the p2p/proxy
connections. We're using Jabber as it should be used. This allows us to
be able to pass the IP/port off to a entirely different process and it
can speak whatever protocol is appropriate
Comments?
Diz
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta
iQA/AwUBPfoQXmDRN3IVRx7DEQKRxwCfaJRQGVwqZNMpFrBj50sps8HmUwkAnj/u
C/L5JFqO7xw/ZcXcclxc5l58
=BSTb
-----END PGP SIGNATURE-----
More information about the Standards-JIG
mailing list