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] [day] [month] [year] [list]

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

James Chapman wrote:
> 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.

rtnl_link really doesn't seem to be the best fit for this. It
*could* be used for PPP device management, but since a userspace
daemon is required anyways, it wouldn't be much of a benefit.

> 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?

Yes, thanks a lot.


--
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