[Openswan dev] NAT-T patch

[David McCullough]

Jivin Paul Wouters lays it down ...
> On Wed, 20 May 2009, David McCullough wrote:
>
>> but the L2TP version:
>>
>> 	UDP_ENCAP_L2TPINUDP
>>
>> doesn't.  When XFRM is in the kernel,  xfrm4_udp_encap_rcv does almost
>> exactly, line for line, what klips26_udp_encap_rcv does.  When XRM is not in
>> the kernel you get an empty function stub, so basically,  klips needs to
>> provide it's own version of xfrm4_udp_encap_rcv,  and that is
>> klips26_udp_encap_rcv.
>
> I had thought we could just load one of the xfrm modules that dealt with
> this, that was seperate enough from the esp4 module to not interfere with us.
> I thought the whole l2tp addition cause them to seperate xfrm4_udp_encap_rcv
> from the IPsec code.

Most of the devices we ship use klips exclusively,  so there is no CONFIG_XFRM.
I have some platforms the use both,  but yes we do not have both stacks
loaded at the same time.

It's possible we could make klips provide the same interface as net_key
so that it can operate below some portion of the exiting net_key bits,
though I think getting the packets at the earlier stage makes it easy
for klips to continue to operate as it does now.

>> Had a quick look at what L2TP is doing.  It still has it's own encap_rcv
>> function.  Not as heavy as the ipsec versions for some reason,  but it is
>> doing everything in a similar way to xfrm and now klips.
>
> Then the next question is, can we deal with that in one pass, so that if
> we use ipsec+l2tp, that we can decap the l2tp data packets as well (and
> send the l2tp control packets to userland for processing)

I am not an L2TP expert at all,  so please correct me if I am wrong.

There looks to be all the kernel level support for L2TP in 2.6.29,  so is
L2TP using it's own drivers or the kernel ones ?  Is this even that same
L2TP stack we are talking about or a user mode stack of sorts ?

If the desire is to get KLIPS to interact more nicely with L2TP user space,
and not change NETKEY or the kernel L2TP code,  then I guess we could do
something there that won't require kernel patches.  After all,  after ipsec
is done we could easily see that we have an L2TP packet.

If thats not the goal,  I am all for throwing it back at the kernel stack
and letting it take it's course.

Sorry, I would like to know more about L2TP (or sure enough I will be forced
to at some stage),  but so far it has avoided me :-)

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org