Subject: Re: Other Socket Tunnels (Was: New draft Possibilities)

From: Ben Harris <[email-masked]>
Date: Wed, 31 Aug 2005 19:29:48 +0100 (BST)

In article <015301c5ae4d$7cb18250$6c051fac@lighthammer> you write:
>> I was just wondering if there has ever been any
>> thought put to making a draft of a UDP tunnel like the
>> TCP forwarding function.
>>
>I was tossing this idea along with unix domain sockets/windows named pipes
>and thought it might make more sense to define a generic "socket tunnel"
>session or subsystem.  Something like:
>
>   byte      SSH_MSG_CHANNEL_OPEN
>   string    "direct-socket"
>   string    socket type name (e.g. "udp","unix","named-pipe")
>   uint32    sender channel
>   uint32    initial window size
>   uint32    maximum packet size

The extra name in there breaks the format of SSH_MSG_CHANNEL_OPEN.  Since
you don't have any data specific to "direct-socket" apart from that name, it
would be better to just make it part of the channel type (so "direct-udpip",
"direct-unix", "direct-named-pipe").

-- 
Ben Harris

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 31 Aug 2005 13:26:18 -0600

>   string    socket type name (e.g. "udp","unix","named-pipe")

(I'm not commenting on which would be better... just
that both are legal.)

Thanks,

Joseph

---

From: "Timo J. Rinne" <[email-masked]>
Date: Wed, 31 Aug 2005 23:03:54 +0300

Hi

Since transporting datagrams over tcp tunnel is never performance 
efficient but can be useful for some other purpose (e.g. forwarding DNS 
in certain situations) I find it somewhat questionable if it's a good 
idea to define a channel type for this kind of use.  UDP protocols often 
also need some other processing in addition to just forwarding.  For 
example some kind of application gateway would be needed for protocols 
using portmapper.

I made some tests a couple years ago with simple datagram forwarding 
sybsystem that implemented UDP forwarding over normal secsh subsystem 
channel.  For DNS and NFS results were OK, however I never got to it 
ehough to make portmapper support so that NFS could have been run 
without considerable hand work.  Anyways, it worked more or less nicely 
and took maybe 4 hours to implement.  In addition to subsystem program 
only thing needed was a configuration change to secure shell server.

In my opinion, subsystems in secure shell protocol exist for just this 
kind of use and implementing this stuff as channel types don't sound 
like very good idea.  It is also worth mentioning that generic datagrams 
don't necessarily map directly to secure shell transport protocol 
packets so there will most likely be need of some kind of encapsulation 
for those datagrams before they would be sent as channel data.  This 
encapsulation could as well be on subsystem level.

Should someone be interested, I can probably release my subsystem 
protocol proto.

//Rinne

---

From: der Mouse <[email-masked]>
Date: Wed, 31 Aug 2005 23:52:41 -0400 (EDT)

>> The extra name in there breaks the format of SSH_MSG_CHANNEL_OPEN.
>> Since you don't have any data specific to "direct-socket" apart from
>> that name, it would be better to just make it part of the channel
>> type (so "direct-udpip", "direct-unix", "direct-named-pipe").
> Alternatively, the following format works: [type name at end]
> (I'm not commenting on which would be better... just that both are
> legal.)

In case anyone cares what I think - I'd prefer one channel type with a
subtype field ("direct-socket" with "udp", "named-pipe", etc).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B