Re: PPP-over-L2TP kernel support, new patch for review

[James Chapman <jchapman@katalix.com>]

Although Ben and I are both working on L2TP projects, I think we're
targetting two totally different usage scenarios.

Time for some ASCII art...

1. ISP scenario

               +----+
            ---+ D  |
            ---| S  |      +--------+              +-------+
            ---| L  |======|  LAC   |==============| LNS   |
            ---| A  |      |        |              |       |
            ---| M  |      +--------+              +-------+
            ---|    |
            ---|    |
            ---|    |
               +----+
     thousands       PPPoA           each PPP session
     of PPP          or              tunneled thru
     clients         PPPoE           L2TP session to LNS


2. VPN scenario

           +---+                                  +------+
           |LAC+----------------------------------|      |
           +---+                                  |      |
           +---+                                  |      |
           |LAC+----------------------------------| LNS  |
           +---+                                  |      |
           +---+                                  |      |
           |LAC+----------------------------------|      |
           +---+                                  |      |
                                                  +------+
        PPP client                               Terminates
        in each LAC.                             multiple tunnels
        Typically 1
        session per tunnel

Ben is addressing the ISP case, where client PPP sessions are
terminated only temporarily at the LAC while it authenticates the PPP
users to decide how to tunnel them. Each PPP session is then tunneled
straight through the LAC via an L2TP session (inside an L2TP tunnel)
to the LNS. Scalability is important here, which Ben has addressed.

I'm addressing the VPN case, where multiple clients (M$ L2TP/IPSEC
or rp-l2tp/openl2tp clients) connect to an enterprise VPN server.
Current solutions involve userspace pty hacks in the datapath,
shunting data in and out of pppd ttys. The proposed driver moves the
datapath into the kernel where it should be. The driver integrates
with existing PPP and IPSEC kernel subsystems and will handle
hundreds of sessions today.

The biggest difference in our approaches is that Martijn and I use a
PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel
socket while Ben uses a new AF_L2TP tunnel socket and no separate
socket per session. Both have their merits.

If I can put the case for our driver, Linux really needs a good VPN
solution. I know of two companies that run their offices with Linux
servers yet they both retain a Microsoft server _only_ to provide VPN
access to off-site workers. Including this driver in the kernel will
enable us to build binary packages for OpenL2TP and perhaps other L2TP
solutions like rp-l2tp would be updated to use it too. Being able to
handle hundreds (not thousands) of sessions is more than adequate
in this case.

Where do we go from here then? Perhaps both approaches are equally
valid and could even co-exist in the Linux kernel distribution?

/james

Quoting Benjamin LaHaise <bcrl@kvack.org>:

> > - Architecture seems to be using char devices for communication with
> >   the kernel and all the PPP datapath is handled by custom virtual
> >   net_devices; the generic PPP kernel code isn't used as far as I can
> >   tell. Unfortunately it is very old (linux-2.0 era I think) but Ben
> >   has probably updated it.
>
> I've updated it.  The current build is at http://www.kvack.org/~bcrl/babylon/
> and is 1.6-pre3-bcrl8.

[snip]