[Openswan dev] NAT-T patch

[David McCullough]

Jivin Paul Wouters lays it down ...
> On Thu, 21 May 2009, David McCullough wrote:
>
>> 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 ?
>
> I am not sure what you mean with "drivers" here. Normally l2tp is pure
> userspace. l2tp packets can be control packets (like IKE) or data packets
> (like ESP). The kernel l2tp driver (as far as I know) just checks to see
> if the current l2tp packet is a data packet. If so, it just removes the l2tp
> header and processing continues in the kernel (of a ppp packet i guess).
> This avoids the pushing l2tp to userland, decapsulate and then push it to ppp.

Ok,  so ignore me using drivers (although there are some there).
The flow above makes sense.

>> 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.
>
> Exactly, though I think we should be able to just call (or rely?) on the
> current l2tp kernel module? Eg can't we punt the decrypted l2tp packet to
> the l2tp decaps kernel hook function?

Thats depends a lot on the "exported" interfaces.

How is it currently done,  do we just send it through netif_rx and it finds
it's way to l2tp or is something else going on that needs patches ?

> The xl2tpd daemon supports the l2tp kernel module, though perhaps only via
> an older kernel patch. When the l2tp kernel patch got integrated, it changed
> a bit, and I'm not sure if xl2tpd still supports it.

So this older kernel patch it what you are trying to remove ?

Is xl2tpd meant to work with klips or doesn't it care ?

I think you could knock up a very small driver just to do the encap
stuff for l2tp so patchless operation should be possible.

It would also be possible to have klips use the same driver/code.

It may even be possible to get something generic like that merged upstream
if there was support and enough "deemed good" reasons for it to exist. I
am not sure klips support would be a "deemed good" reason ;-),
xl2tpd may be.

>> Sorry, I would like to know more about L2TP
>
> No you don't :)

Agreed ;-)

Cheers,
Davidm

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