UDP / ssh

[cazze]

Hi,

i have a general question about ssh tunnels. I think i know the answer, but would like to check what you all think about it. I hope my english will be good enough to put something comprehensible down

I have two applications communicating with eachother over a UDP stream. I use UDP for the speed of it.
My application was always running on an intranet and security was not very important. Now, i need to port it to the internet and thats where the security of it becomes a must.
My first id was to put the communication over secure socket layers. But then i am not longer working with UDP but with TCP. I think i can't handle it for speed reasons.
So the second thing that came in my mind was the use of a ssh-tunnel between 2 devices and blow my UDP traffic over it.
Now how would my UDP stream behave over the tunnel? Like a TCP stream?

Regards,

kammicazze
_________________
Required: Windows 95 or better, so i installed Linux!!!

[tuxmin]

You cannot use ssh to tunnel UPD... it's designed tor TCP only.
Have a look at this
http://www.winton.org.uk/zebedee/
or use a VPN solution like PPTP or OpenVPN.


Alex!!!
_________________
ALT-F4

[OPelerin]

From network standpoint TCP get many build-in flow control mechanism that are very useful

TCP window will always try to burst to port speed and get nice in case of congestion.



Since UDP rely on layer 7 protocol to get congestion avoidance - retransmissions -... UDP based flows are not so interesting as it can be from first look


An ethernet frame can transport 1500 bytes

20 bytes are minimum required for IP header

20 bytes are minimum required for TCP header


----> 15600 bytes of payload....


If you run on UDP , the UDP header is only 8 Bytes


---> If you are using large frames , the difference is only 8 bytes on a total of 1500.... almost nothing.



TCP is insecure, but udp is by default even more insecure since it allow spoofing 'by default'

TCP flow mechanisms are working not that bad

RFC 2001

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

RFC 3742

http://www.faqs.org/rfcs/rfc3742.html
_________________
Olivier PELERIN

[CriminalMastermind]

well, it kind of depends on the situation, but you could just tunnel you data over IPSec. i don't know what kind of overhead that adds, or if it is a viable solution in this situation. just figured i'd throw it out there.
_________________
"I can picture a perfect world that knows of no war... and I can picture me attacking that world, because they'd never expect it."

[cazze]

Thx for the fast replies.

@tuxmin:
thx for the great link. I wasn't aware of this product. I will investigate this further. Do you think it will take multicast packets too?

@OPelerin:
It is true for the overhead of a 1500 bytes packet you don't have to leave TCP for UDP. My first statement was not clear enough about the sort of data i transmit. I transmit about 144 bytes every 20ms. The most important thing is the delay between the send and the receive of the packet. You can see it as a clock sending its seconds to a client.
If i transmit TCP packets and the connection is hanging for 5 seconds, my packets will be buffered and when the connection is good again, the TCP connection will begin to transmit my buffer. In the example of the clock from above, i don't have any use anymore of the seconds i was sending who are arriving to late at the client. The only packet who is interresting that time is the last one. With the buffer of the unusefull packets, i will lose even more time for the last packet i was sending, because TCP was resending the buffered ones.

But that all leaves my question open, how will my UDP stream behave over a zebede or ipsec tunnel, if the host stalls for 5 seconds, will my data be retransmit using the TCP behavior of the tunnel or will the packets be dropped using the behaviour of my UDP data?

kammicazze
_________________
Required: Windows 95 or better, so i installed Linux!!!

[tuxmin]

I never tried zebedee, can't tell you how it performs with multicast.
But here come some theory that might help you:
As zebedee uses UDP for transport there will be no retransmits. And this is normally desired for encapsulating tunnels. Maybe you have wondered why there are no VPN solutions out there that use TCP for transport. Read here for details.
Sending UPD over UDP adds a slight chance of extra package losses. But as you normally connect two LANs via a tunnel this has no impact as LANs tend to loose very little packages. It is left to the encapsulated TCP to retransmit lost packages.
[Edit]
It makes no sense to retransmit an encapsulated UPD package as it will always arrive out of order and thus be useless.
[/Edit]

Hth, Alex!!!
_________________
ALT-F4

[cazze]

thx tuxmin. You were realy a help

kammicazze
_________________
Required: Windows 95 or better, so i installed Linux!!!