netdev - Re: [PATCH net] l2tp: Allow duplicate session creation with UDP

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:   Thu, 16 Jan 2020 21:05:01 +0000
From:   Tom Parkin <tparkin@...alix.com>
To:     Guillaume Nault <gnault@...hat.com>
Cc:     Ridge Kennedy <ridge.kennedy@...iedtelesis.co.nz>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] l2tp: Allow duplicate session creation with UDP

On  Thu, Jan 16, 2020 at 20:28:27 +0100, Guillaume Nault wrote:
> On Thu, Jan 16, 2020 at 12:31:43PM +0000, Tom Parkin wrote:
> > However, there's nothing to prevent user space from using the same UDP
> > port for multiple tunnels, at which point this relaxation of the RFC
> > rules would break down again.
> > 
> Multiplexing L2TP tunnels on top of non-connected UDP sockets might be
> a nice optimisation for someone using many tunnels (like hundred of
> thouthands), but I'm afraid the rest of the L2TP code is not ready to
> handle such load anyway. And the current implementation only allows
> one tunnel for each UDP socket anyway.

TBH I was thinking more of the case where multiple sockets are bound and
connected to the same address/port (SO_REUSEADDR).  There's still a
1:1 mapping of tunnel:socket, but it's possible to have packets for tunnel
A arrive on tunnel B's socket and vice versa.

It's a bit of a corner case, I grant you.

> > Since UDP-encap can also be broken in the face of duplicated L2TPv3
> > session IDs, I think its better that the kernel continue to enforce
> > the RFC.
> How is UDP-encap broken with duplicate session IDs (as long as a UDP
> socket can only one have one tunnel associated with it and that no
> duplicate session IDs are allowed inside the same tunnel)?
> 
> It all boils down to what's the scope of a session ID. For me it has
> always been the parent tunnel. But if that's in contradiction with
> RFC 3931, I'd be happy to know.

For RFC 2661 the session ID is scoped to the tunnel.  Section 3.1
says:

  "Session ID indicates the identifier for a session within a tunnel."

Control and data packets share the same header which includes both the
tunnel and session ID with 16 bits allocated to each.  So it's always
possible to tell from the data packet header which tunnel the session is
associated with.

RFC 3931 changed the scheme.  Control packets now include a 32-bit
"Control Connection ID" (analogous to the Tunnel ID).  Data packets
have a session header specific to the packet-switching network in use:
the RFC describes schemes for both IP and UDP, both of which employ a
32-bit session ID.  Section 4.1 says:

  "The Session ID alone provides the necessary context for all further
  packet processing"

Since neither UDP nor IP encapsulated data packets include the control
connection ID, the session ID must be unique to the LCCE to allow
identification of the session.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)