Thinking about UDP and tunneling

[Randall Stewart]

On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote:

>>>
>> Its not new, its the same ip header..
>> Its just you go into the mbuf chain and take out
>> the udp header...
>
> well you can't do that at the socket buffer becasue you've discarded
> the IP header. It may not even be in the mbufs you have. (though it's
> unlikely). After you've processed the UDP part the IP part is gone so
> you'd need to intercept the packet way earlier and then do your
> own UDP processing, (or maybe attach the IP header onto it with a
> tag).
>
>

One would definitely  have to do some work in udp_input() not a lot from
what I can tell... but it would take some work.

Maybe  good course is to use the socket(9) stuff, but add an option
that can set a "by-pass function" if the socket is udp... right
after you establish the INP the packet goes to, if the function is
set, you engage the bypass...

>>>
>>>
>>>> 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...
>>>> Netgraph would have to be watching every UDP packet always..
>>>
>>> just those that go to that ksocket.  we hook on at the socketbuf  
>>> point.
>> Hmm sounds plausible..
>
> what you are suggesting is UDP header injection, between the  
> existing IP header and existing SCTP header, then on reception,  
> stripping it out.
>
>
> We'd have to do  a bit of hacking to do that.. it's kind of 'unusual'

You need to take a look at some of the activities in tsvwg and the  
transport area
open area meeting in the IETF. Not counting Jonathan's Rosenburgs IAB  
presentation
an IETF or two ago claiming that "all new transports must tunnel via  
UDP". This
seems to be a more and more common theme in the IETF.

Now I personally do not agree that new transports cannot be deployed  
without UDP
tunneling.. however there will always be the need for this IMO.. since  
you will
often have NAT's that don't know about the new transport "yet"...  
Jonathan (and others
claims is that the "yet" is really a "never".. here I disagree).

Having infrastructure so we can do UDP tunneling of a new transport  
easily is IMO
a good idea.

Netgraph, looks interesting.. but I am afraid is not in GENERIC.. so  
you end up with
a solution that only sometimes works. What I am thinking is a clean  
way to have
kernel sockets(9) extended a bit so that we can better support  
tunneling input...

Let me chew on this a while and come up with a working solution ...  
using socket(9) as
much as possible... I think a couple of tweaks will be needed.. but I  
think its quite
feasible and will be a benefit for not just SCTP but also DCCP and  
some of the other
transports on the horizon...


R


>
>
> in-kernel UDP encapsulation is easy but we don't have header  
> injection..
>
> I can see how one would do it
> but I was wrong before, you'd need to do some work.
>
>> R
>>>
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)