Thinking about UDP and tunneling

[Randall Stewart]

On Nov 19, 2008, at 4:20 PM, Maksim Yevmenkin wrote:

> On 11/19/08, Julian Elischer <julian at elischer.org> wrote:
>> Randall Stewart wrote:
>>
>>>
>>> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote:
>>>
>>>
>>>> Randall Stewart wrote:
>>>>
>>>>> Dear All:
>>>>> I have been contemplating UDP and tunneling. One of the
>>>>> things that is a nice feature in MacOS is the ability of
>>>>> a kernel module/extension to open a kernel level socket
>>>>> and have the mbuf chain that arrives for that port be passed
>>>>> in via a function.
>>>>>
>>>>
>>>> define "kernel level" and "mbuf chain that arrives [...] passed  
>>>> in via a
>> function"
>>>>
>>>>
>>>>
>>>>
>>>>> We use this in our MacOS version of the SCTP stack to do the
>>>>> UDP de-tunneling of SCTP packets. This is becoming a more and
>>>>> more common thing i.e. having transport protocols like SCTP and  
>>>>> DCCP
>>>>> be tunneled over UDP to get by NAT's.... this actually sucks that
>>>>> this is necessary .. but it is what it is....
>>>>>
>>>>
>>>> I do that using netgraph..
>>>> set a point ot point ng_iface and hook the other end to
>>>> a netgraph ksocket which is bound/connaected where you want.
>>>>
>>>> "just works"
>>>>
>>>>
>>>>> So, I am contemplating adding a similar sort of feature...  
>>>>> basically
>>>>> provide an interface in UDP that a consumer (such as SCTP or DCCP)
>> could
>>>>> use to "bind" a port and get UDP packets directly.
>>>>> What do you all think of the idea?
>>>>>
>>>>
>>>> Well netgraph allows you to do it already
>>>>
>>>
>>>
>>> Not sure what netgraph does... what is wanted is this in comes
>>>
>>>
>>> +-----+
>>> | IP  |
>>> +-----+
>>> | UDP |
>>> +-----+
>>> | Oth |
>>> | tra |
>>> | por |
>>> | t h |
>>> | ead |
>>> | er  |
>>> | and |
>>> | dat |
>>> | a.  |
>>> +-----+
>>>
>>
>>
>> Othtra port header and data.?
>
> i think it means: "other transport port header and data", that is take
> a complete sctp/etc. datagram and stuff in inside udp datagram as
> payload.
>
>>
>>>
>>>
>>> Ideally it runs into UDP via ip_input()
>>> and comes down to where it would append() to the socket.
>>>
>>
>> At this point, netgraph grabs it and passes the mbufs wherever you  
>> tell it
>> to pass them.
>>
>>
>>>
>>> What you want in this case is the whole mbuf chain to be sent
>>> to the transport_udp_input(m, offset) function
>>>
>>
>> cd /sys
>> root at trafmon1:grep transport_udp_input net*/*
>> root at trafmon1:grep transport_udp_input net*/*/*
>>
>>
>>
>>
>>>
>>> This changes the above to
>>> +-----+
>>> | IP  |
>>> +-----+
>>> | Oth |
>>> | tra |
>>> | por |
>>> | t h |
>>> | ead |
>>> | er  |
>>> | and |
>>> | dat |
>>> | a.  |
>>> +-----+
>>>
>>
>>
>> where does the new IP header information come from?
>>
>>
>>>
>>> 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.
>
> that's right. basically, use ng_ksocket(4). that would be your tunnel
> (outer) endpoint which you would bind to udp protocol, given address
> and port. now everything that remote tunnel (outer) endpoint will send
> via udp (payload) will end up in ng_ksocket(4) node and will be sent
> out to ksocket's hook.  you can connect whatever you want to that
> hook. either move payload back into userspace, or use another ng node,
> or just inject the data directly into sctp/etc. input routine. reverse
> path is the same. playload comes from the hook and gets sent out via
> udp


Ok, let me go read the ng_ man..

I would not use the reverse path.. the ability to send
encap'd udp packets is already in sctp.. after all all you
are doing is dropping an extra header on it.. SCTP (and other
transports) will want to control the way the IP header looks.. at
least if they are multi-homed... so I don't think one would
want to do output via ng.. just getting the data in is all
thats missing in FreeBSD..

As long as netgraph is in generic this may work..

R


>
>
>>>
>>> seems to me easier to bind a kernel level socket with some option
>>> to call an input function....
>>>
>>> R
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>> That also reminds me.. who owns the ipfw code.. we actually
>>>>> have SCTP nat support that Jason But has done that we need to
>>>>> get in...
>>>>> I would be more than glad to shepherd this in if the owner
>>>>> of the code does not have the time...
>>>>> R
>

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