f



How socks 5 udp associate works.

Hi,

I wrote a little tutorial to help socks 5 implementators and especially
socks 5 server implementators
to implement socks 5 udp support correctly.

RFC 1928 seems to be mis-interpreted or mis-understood by some socks 5
server implementators.

http://www.faqs.org/rfcs/rfc1928.html

Below is how socks 5 udp associate works:

First some basic information.

A socks 5 client or socks 5 server does not need to use any tricks like ip
address
spoofing or udp port spoofing etc... this is completely not needed.

Everytime this tutorial mentions "to:" it means the following:

The destination address of the ip header is set to the ip address of the
destination object (to:)
The destination port of the udp header is set to the udp port of the
destination object (to:)

The source address of the ip header is set to the ip address of the source
object (the: )
The source port of the udp header is set to the udp port of the source
object (the: )

The source client:

+--------------------------+
| Normal UDP Source Client |
+--------------------------+
| ip address S             |
+--------------------------+
| udp port S               |
+--------------------------+

The socks 5 clients:

+--------------------+
| Socks 5 TCP Client |
+--------------------+
| ip address A       |
+--------------------+
| tcp port A         |
+--------------------+

+--------------------+
| Socks 5 UDP Client |
+--------------------+
| ip address B       |
+--------------------+
| udp port B         |
+--------------------+

Note:

The TCP client program/process and the UDP client program/process could be
located
on the same machine/computer or on different machines/computers.

Therefore ip address A and ip adress B could be the same or different.

TCP port A and UDP port B could be the same by coincidence or could be
different as well.

Server implementations should assume that both clients are on different
machines.
This allows maximum flexibility.

The socks 5 servers:

+--------------------+
| Socks 5 TCP Server |
+--------------------+
| ip address C       |
+--------------------+
| tcp listen port C  |
+--------------------+

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+
| ip address D             |
+--------------------------+
| tcp listen port D        |
+--------------------------+
| udp listen port D        |
+--------------------------+
+---------------------+
| UDP Association 1   |
+---------------------+
| bound ip address R  |
+---------------------+
| bound udp port R    |
+---------------------+
| client ip address B |
+---------------------+
| client udp port B   |
+---------------------+
+---------------------+
| UDP Association 2   |
+---------------------+
| bound ip address ?  |
+---------------------+
| bound udp port ?    |
+---------------------+
| client ip address ? |
+---------------------+
| client udp port ?   |
+---------------------+

etc

Note:

The socks 5 server and the socks 5 relay server could be located on
the same machine/computer or on different machines/computers.

Therefore ip address C and ip address D can be the same or different.
Therefore tcp port C and tcp port D can be the same or different.

The relay server might be integrated into the socks 5 server and might not
even
exist.

There could even be multiple relay servers which are controlled by a single
socks 5 server.

Client implementations should assume all servers are on different machines.
This allows maximum flexibility.

The destination client(s):

+-------------------------------+
| Normal UDP Destination Client |
+-------------------------------+
| ip address T                  |
+-------------------------------+
| udp port T                    |
+-------------------------------+

There could be multiple destinations.

The number of destinations is irrelevant since the udp packets contain a
source address
and source port and a destination address and a destination port.

When a remote host sends a packet back to the relay address the destination
port matches
the associated source port.

This allows the relay server to easily tell to which client the packet
should go to.

Socks 5 udp support is complex but also very flexible.

The specification however is not so clear and is mis-interpreted by some
socks 5 implementators.

Because of the poor specification and the complexity of socks 5 it can best
be explained
with a example below:

Socks 5 udp support is supposed to work like this:


*** Step 1 *** Socks version and methods request ***:

The:

+----------------------+
| Socks 5 TCP Client   |
+----------------------+

sends tcp message:

+--------------------------------+
| socks 5 version/method request |
+--------------------------------+
| Version (1 byte): 5            |
+--------------------------------+
| Methods (1 byte): 2            |
+--------------------------------+
| Method 0 (1 byte): 0           |
+--------------------------------+
| Method 1 (1 byte): 2           |
+--------------------------------+

This message contains which socks version is desired.
This message contains how many methods the client supports
This message contains each method that it supports.

Version 5 means Socks version 5 is desired.
Method 0 means no authentication is supported.
Method 2 means username/password authentication is supported.

to:

+--------------------+
| Socks 5 TCP Server |
+--------------------+

*** Step 2 *** Socks version and selected method reply ***:

The:

+--------------------+
| Socks 5 TCP Server |
+--------------------+

selects a method from the received message and transmits the selected method
back:

send tcp message:

+-----------------------------------+
| socks 5 version / selected method |
+-----------------------------------+
| version (1 byte): 5               |
+-----------------------------------+
| method (1 byte): 0                |
+-----------------------------------+

In this example the socks 5 server has selected method 0 which means no
authentication
is required.

to:

+--------------------+
| Socks 5 TCP Client |
+--------------------+

*** Step 3 *** UDP Associate request ***:

The:

+--------------------+
| Socks 5 TCP Client |
+--------------------+

Has received the tcp message and understands that no authentication is
required and can
therefore immediatly send an udp associate message via TCP.

Sends tcp message:

+--------------------------------------+
| socks 5 udp associate request        |
+--------------------------------------+
| version (1 byte): 5                  |
+--------------------------------------+
| command (1 byte): 3                  |
+--------------------------------------+
| reserved (1 byte): 0                 |
+--------------------------------------+
| address type (1 byte): 1             |
+--------------------------------------+
| ipv4 address (4 bytes): ip address B |
+--------------------------------------+
| udp port (2 bytes): udp port B       |
+--------------------------------------+

Version 5 means socks version 5.
Command 3 means "udp associate command"
Reversed 0 means nothing and is reserved for future use.
Address Type 1 means ip version 4 address (which is 4 bytes)
ipv4 address contains the ip address of the udp client.
udp port contains the udp port of the udp client.

To:

+--------------------+
| Socks 5 TCP Server |
+--------------------+

*** Step 4 *** UDP Associate, udp client information ***:

The:

+--------------------+
| Socks 5 TCP Server |
+--------------------+

transmits the following information as a minimum:

+--------------------------------------+
| socks 5 udp associate request        |
+--------------------------------------+
| ipv4 address (4 bytes): ip address B |
+--------------------------------------+
| udp port (2 bytes): udp port B       |
+--------------------------------------+

to:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

How this is done is unspecified. Both servers can be integrated or seperate.
Server implementators are free to choose any technique.


*** Step 5 *** UDP Association, creation ***:

The:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

internally opens an udp socket on an arbitrary/free udp port. Because the
client
most know the ip address and udp port of this socket the relay server has to
retrieve
this information from the newly opened socket. This could mean that the
socket
has to be "bind-ed" to an interface ip address. The udp port can be
retrieved
after it is bound.

The bound interface ip address and the bound interface udp port and the
client ip
address and client udp port is then stored in a record/structure/table and
is added
to it's list/table/array of associations.

+---------------------+
| udp association 1   |
+---------------------+
| bound ip address R  |
+---------------------+
| bound udp port R    |
+---------------------+
| client ip address B |
+---------------------+
| client udp port B   |
+---------------------+

This information is transmitted back

to:

+--------------------+
| Socks 5 TCP Server |
+--------------------+

How this is done is again unspecified and server implementators are free to
choose
any method.

*** Step 6 *** UDP Associate Reply, Bound/Relay information ***

The:

+--------------------+
| Socks 5 TCP Server |
+--------------------+

send a tcp message:

+-----------------------------------------+
| socks 5 udp associate reply             |
+-----------------------------------------+
| version (1 byte): 5                     |
+-----------------------------------------+
| command/reply (1 byte): 0               |
+-----------------------------------------+
| reserved (1 byte): 0                    |
+-----------------------------------------+
| address type (1 byte): 1                |
+-----------------------------------------+
| ipv4 address (4 bytes): bound address R |
+-----------------------------------------+
| udp port (2 bytes): bound port R        |
+-----------------------------------------+

The reply has the same structure as the request.

Command/Reply 0 means success.

The bound address R can also be called the "Relay Address".
The bound port R can also be called the "Relay Port".

back

to:

+--------------------+
| Socks 5 TCP Client |
+--------------------+

*** Step 8 *** Relay Information ***:

The:

+--------------------+
| Socks 5 TCP Client |
+--------------------+

transmits the bound/relay address and bound/relay port as a minimum:

+-----------------------------------------+
| Relay information                       |
+-----------------------------------------+
| ipv4 address (4 bytes): bound address R |
+-----------------------------------------+
| udp port (2 bytes): bound port R        |
+-----------------------------------------+

to:

+--------------------+
| Socks 5 UDP Client |
+--------------------+

Again how this is done is unspecified. A socks 5 client implementator is
free
to choose any technique.


*** Step 9 *** Intercepting/Forwarding Source UDP Datagrams ***

The:

+--------------------+
| Socks 5 UDP Client |
+--------------------+

intercepts UDP datagrams from the

+-------------------+
| Normal UDP Client |
+-------------------+

and adds a UDP request header to the front of the packet:

( A better term would have been UDP forward header but it's
called a request header so be it ;) )

+-----------------------------------------------+
| udp request header                            |
+-----------------------------------------------+
| reserved (2 bytes): 0                         |
+-----------------------------------------------+
| fragment number (1 byte): 0                   |
+-----------------------------------------------+
| address type (1 byte): 1                      |
+-----------------------------------------------+
| ipv4 address (4 bytes): bound/relay address R |
+-----------------------------------------------+
| udp port (2 bytes): bound/relay port R        |
+-----------------------------------------------+
| payload (? bytes): udp payload                |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

and sends it

to:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

*** Step 9 *** Forwarding Intercepted Source UDP Datagrams ***

The:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

removes the udp request header from the packet at the front and

send the

+-----------------------------------------------+
| payload (? bytes): udp payload                |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

to:

+-------------------------------+
| Normal UDP Destination Client |
+-------------------------------+

*** Step 10 *** Normal UDP Destination Client receives payload and sends new
payload back ***

The:

+-------------------------------+
| Normal UDP Destination Client |
+-------------------------------+

receives the

+-----------------------------------------------+
| payload (? bytes): udp payload                |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

and replies with a new/another

+-----------------------------------------------+
| payload (? bytes): new udp payload            |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

and sends it back to the received udp datagram's source address and source
port
which happens to be

to:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

*** Step 10 *** Backwarding the Normal Destination Client new payload ***

The:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

receives the

+-----------------------------------------------+
| payload (? bytes): new udp payload            |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

from the

+-------------------------------+
| Normal UDP Destination Client |
+-------------------------------+

on the

+---------------------+
| bound ip address R  |
+---------------------+
| bound udp port R    |
+---------------------+

The:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

searches the UDP associations until it finds the assocation with bound udp
port R:

+---------------------+
| udp association 1   |
+---------------------+
| bound ip address R  |
+---------------------+
| bound udp port R    |
+---------------------+
| client ip address B |
+---------------------+
| client udp port B   |
+---------------------+

The:

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

now knows where to backward the new udp payload to,

(client ip address B and client ip port B)

and adds a udp request header in front of it

(a better term would be udp reply header but it's called udp request header,
which is just
the same structure)

+-----------------------------------------------+
| udp request header                            |
+-----------------------------------------------+
| reserved (2 bytes): 0                         |
+-----------------------------------------------+
| fragment number (1 byte): 0                   |
+-----------------------------------------------+
| address type (1 byte): 1                      |
+-----------------------------------------------+
| ipv4 address (4 bytes): ip address T         |
+-----------------------------------------------+
| udp port (2 bytes):udp port T                 |
+-----------------------------------------------+
| payload (? bytes): new udp payload            |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

Notice how the relay server should set ipv4 address to the received udp
datagram's source address
which is ip address T.

Notice how the relay server should set udp port to the received udp
datagram's source address
which is udp port T.

And sends it back

to:

+--------------------+
| Socks 5 UDP Client |
+--------------------+

*** Step 10 *** Backwarding the Normal Destination Client new payload ***

The:

+--------------------+
| Socks 5 UDP Client |
+--------------------+

receives the udp request header and udp payload and removes the udp request
header.

The:

+--------------------+
| Socks 5 UDP Client |
+--------------------+

knows the ip address and ip port of the

+--------------------------+
| Normal UDP Source Client |
+--------------------------+

(which it got from the socks 5 tcp client, or
 stored it during interception of the udp datagrams
 or startup/settings)

and sends the

+-----------------------------------------------+
| payload (? bytes): new udp payload            |
|                                               |
|                                               |
|                                               |
+-----------------------------------------------+

to:

+--------------------------+
| Normal UDP Source Client |
+--------------------------+

*** Step 11 *** End result ***

The

+--------------------------+
| Normal UDP Source Client |
+--------------------------+

sends/receives many normal udp datagrams to/from the

+--------------------+
| Socks 5 UDP Client |
+--------------------+

which sends/receives many socks 5 udp request datagrams to/from

the

+--------------------------+
| Socks 5 UDP Relay Server |
+--------------------------+

which sends/receives many normal udp request datagrams to/from

the

+-------------------------------+
| Normal UDP Destination Client |
+-------------------------------+

*** Step 12 *** Termination ***

The

+--------------------+
| Socks 5 TCP Client |
+--------------------+

closes the TCP connection with the

+--------------------+
| Socks 5 TCP Server |
+--------------------+

which informs the udp relay server to close the associated
port and clean up the association.

The rest of the cleanup should be straight forward... etc, etc, etc ;)

*** Thez End ;) ***

By publishing this little example/tutorial I hope that many implementators
will update
their server implementations so that they function correctly and
comply/follow the specification
as it was ment to be ;)

If you believe this tutorial to be in error or mis-interpreted I will be
happy to discuss
it with you further =D

Bye,
  Skybuck Flying.


0
Skybuck
8/13/2005 7:58:05 PM
comp.protocols.tcp-ip 4448 articles. 0 followers. Post Follow

2 Replies
1556 Views

Similar Articles

[PageSpeed] 57

Skybuck Flying wrote:
> Hi,
> 
> I wrote a little tutorial to help socks 5 implementators and especially
> socks 5 server implementators
> to implement socks 5 udp support correctly.

What is wrong with the official documentation from http://www.socks.permeo.com/ ?

-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
0
Phil
8/15/2005 4:16:20 PM
"Phil Frisbie, Jr." <phil@hawksoft.com> wrote in message
news:od3Me.9262$p%3.37128@typhoon.sonic.net...
> Skybuck Flying wrote:
> > Hi,
> >
> > I wrote a little tutorial to help socks 5 implementators and especially
> > socks 5 server implementators
> > to implement socks 5 udp support correctly.
>
> What is wrong with the official documentation from
http://www.socks.permeo.com/ ?

Interesting question. That site didn't help me at all while developing my
socks 5 udp client.

I simply used rfc1928, implemented that, tested it, and walked into some
problems with free socks 5 servers... it was a confusing experience at
first... but now that might implementation is much more stable I can start
testing all those free socks 5 servers to see if those servers are truely at
fault or that my implementation was at fault or neither and simply a mis
understanding about these 0.0.0.0 relay addressess.

The rfc1928 mentions nothing about socks5 returning 0.0.0.0 addressess for
the relay server so that's where the confusion started mostly.

Now back to your question. I guess the answer for me (as a developer
programmer) is that that site has information overload/overkill... many
links, many documents, many bits and pieces scattered all over the place.

Very interesting how all those reference implementation didn't help me at
all... I don't bother to download them and look at this since it would take
longer to get the stuff working and analyze it then develop it from scratch
;)

So another fine lesson learned, note to myself: the idea/concept of a
reference implementation is not always the right way to demonstrate a
protocol ;)

So there you go. I believe that if the documentation/idea/concept/protocol
details are documented well enough nobody will need a reference
implementation ;)

However it would ofcourse be nice to have a binary reference implementation
to test interoperability.

That's enough for me for one post. If you don't agree don't bother replieing
because I don't give a shit =D

Bye,
  Skybuck.


0
Skybuck
8/15/2005 10:31:35 PM
Reply: