netdev - Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Feb 2009 09:55:05 +0000
From:	James Chapman <jchapman@...alix.com>
To:	Patrick McHardy <kaber@...sh.net>
CC:	Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

Patrick McHardy wrote:
> James Chapman wrote:
>> Herbert Xu wrote:
>>> James Chapman <jchapman@...alix.com> wrote:
>>>> This patch series implements L2TPv3. It replaces the existing pppol2tp
>>>> driver with a number of separate drivers, namely:-
>>>>
>>>> l2tp_core    - L2TP driver core. Always required.
>>>> l2tp_ppp     - L2TP PPP
>>>> l2tp_eth     - L2TPv3 ethernet pseudowire
>>>> l2tp_ip      - L2TPv3 IP encapsulation
>>>> l2tp_netlink - L2TPv3 netlink API
>>> Have you thought by using the rtnl_link_ops interface instead
>>> of your own netlink API?
>>
>> I did, yes. I decided against it only because I didn't want to cause
>> confusion with what I perhaps wrongly perceive as an API for managing
>> net devices. In the L2TPv3 case, there might not be a netdev directly
>> associated with a newlink API call, for example. I've no problem with
>> switching the code to use it if it is preferred.
> 
> From a quick look, it seems you're (also) managing sessions, for
> which rtnl_link might not be the best choice. Could you give a
> short overview of the operations you need to be able to perform?

Sure.

Userspace needs to create, delete, modify and query L2TP tunnel and
session contexts in the kernel. Tunnels are associated with a tunnel
socket (UDP or L2TPIP) and can carry multiple sessions. Session contexts
differ according to type; they are associated with a pppol2tp socket and
implicit ppp netdev in the case of PPP pseudowires, or an ethernet
netdev in the case of ethernet pseudowires. Other pseudowires may be
added in the future for ATM, Frame Relay etc.

In the existing L2TPv2 driver, only PPP is supported by L2TPv2 so the
management of session contexts is done through [gs]etsockopt and ioctl
on the pppol2tp socket. Since in L2TPv3, there might not be a socket for
a session (i.e. in the case of ethernet), we need a new API to manage
the tunnel and session contexts in the kernel.

The extra L2TPv3 configuration parameters of tunnels also required a
more extensive API for creating tunnel contexts. In L2TPv2, tunnel
contexts were automatically created when the first session on that
tunnel was created. In L2TPv3, this isn't possible because the tunnel
creation parameters aren't known by the session. Therefore, the API was
changed to require that userspace create an L2TPv3 tunnel context in the
kernel separately, before creating sessions on it.

Is that enough detail?

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html