Thinking about UDP and tunneling

[Bjoern A. Zeeb]

On Wed, 19 Nov 2008, Randall Stewart wrote:

Hi,

[UDP tunneling of "foo"]

I am not following this thread at all but the
 	transport_udp_input(mbuf, offset)
jumped into my eyes.

> Not sure what netgraph does... what is wanted is this in comes
>
> +-----+
> | IP  |
> +-----+
> | UDP |
> +-----+
...
> +-----+
>
> Ideally it runs into UDP via ip_input()
> and comes down to where it would append() to the socket.
>
> What you want in this case is the whole mbuf chain to be sent
> to the transport_udp_input(m, offset) function
>
> This changes the above to
> +-----+
> | IP  |
> +-----+
...
> +-----+
>
> And sends it into the transport_input() (same one called by ip_input).
>
> This then makes a clean and easy way to have "tunneled UDP" transport 
> protocols
> work in kernel. The input side looks the same. Output is pretty easy.. easy 
> to
> drop a UDP header in out output...


So I see things like this spring here and there and people start
introducing more hacks on top of hacks on top of hacks these days to
cicumvent dumb NAT setups. Right. No.

So why the heck not use one of the dozend possibilities that you can
find on rfc-editor.org to encapsulate whatever you want into UDP in a
well defined protocol way rather than introducing yet another
UDP-encap for yet another protocol?

Stuffing X into UDP means having a policy to identify the next ULP
possibly by port combinations, identify out of sequence data, identify
randomly forged pakets insert into your stream, fragemation, \ldots
\ldots \ldots possibly handshake all this first by the means of the ULP,
\ldots \ldots \ldots  reinventing the wheel over and over again.

Ignore my 0.02CAD.

/bz

-- 
Bjoern A. Zeeb
If you have a hammer, everything looks like a nail.