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

Dave Smith dizzyd at jabber.org
Fri Dec 13 16:52:46 UTC 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 mailing list