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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200116192827.GB25654@linux.home>
Date:   Thu, 16 Jan 2020 20:28:27 +0100
From:   Guillaume Nault <gnault@...hat.com>
To:     Tom Parkin <tparkin@...alix.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 12:31:43PM +0000, Tom Parkin wrote:
> On  Thu, Jan 16, 2020 at 11:34:47 +1300, Ridge Kennedy wrote:
> > In the past it was possible to create multiple L2TPv3 sessions with the
> > same session id as long as the sessions belonged to different tunnels.
> > The resulting sessions had issues when used with IP encapsulated tunnels,
> > but worked fine with UDP encapsulated ones. Some applications began to
> > rely on this behaviour to avoid having to negotiate unique session ids.
> > 
> > Some time ago a change was made to require session ids to be unique across
> > all tunnels, breaking the applications making use of this "feature".
> > 
> > This change relaxes the duplicate session id check to allow duplicates
> > if both of the colliding sessions belong to UDP encapsulated tunnels.
> 
> I appreciate what you're saying with respect to buggy applications,
> however I think the existing kernel code is consistent with RFC 3931,
> which makes session IDs unique for a given LCCE.
> 
> Given how the L2TP data packet headers work for L2TPv3, I'm assuming
> that sessions in UDP-encapsulated tunnels work even if their session
> IDs clash because the tunnel sockets are using distinct UDP ports
> which will effectively separate the data traffic into the "correct"
> tunnel.  Obviously the same thing doesn't apply for IP-encap.
> 
> 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.

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