[Openswan dev] NAT-T patch
David_Mccullough at securecomputing.com
Wed May 20 23:09:59 EDT 2009
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 :)
David McCullough, david_mccullough at securecomputing.com, Ph:+61 734352815
McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org
More information about the Dev