Date:   Sat, 18 Jan 2020 18:18:45 +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 Fri, Jan 17, 2020 at 06:59:31PM +0000, Tom Parkin wrote:
> On  Fri, Jan 17, 2020 at 14:43:27 +0100, Guillaume Nault wrote:
> > On Thu, Jan 16, 2020 at 09:05:01PM +0000, Tom Parkin wrote:
> > > On  Thu, Jan 16, 2020 at 20:28:27 +0100, Guillaume Nault wrote:
> > > > 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.
> > 
> > Well my understanding was that the tunnel was implicitely given by the
> > UDP and IP headers. I don't think that multiplexing tunnels over the
> > same UDP connection made any sense with L2TPv2, and the kernel never
> > supported it natively (it might be possible with SO_REUSEPORT). Given
> > that the tunnel ID field was redundant with the lower headers, it made
> > sense to me that L2TPv3 dropped it (note that the kernel ignores the
> > L2TPv2 tunnel ID field on Rx). At least that was my understanding.
> > 
> > But as your quote says, the session ID _alone_ should provide all the
> > L2TP context. So I guess the spirit of the RFC is that there's a single
> > global namespace for session IDs. Now, practically speaking, I don't
> > see how scoped session IDs makes us incompatible, unless we consider
> > that a given session can be shared between several remote hosts (the
> > cross-talk case in my other email). Also, sharing a session over
> > several hosts would mean that L2TPv3 sessions aren't point-to-point,
> > which the control plane doesn't seem to take into account.
> 
> I think from your other emails in this thread that we're maybe in
> agreement already.
> 
> But just in case, I wanted to clarify that the session ID namespace
> is for a given LCCE (LAC or LNS in L2TPv2 parlance) per RFC 3931
> section 4.1 -- it's not truly "global".
> 
I meant global to a given host (LCCE or LAC/LNS), which for Linux
actually means global to a network namespace. I probably should have
been more precise in my previous emails, but everytime I talked about
"global" session IDs, I meant "global to the network namespace", and
when I talked about "scoped" session IDs, I meant that the ID was only
valid in the context of the UDP or L2TP_IP socket.

Powered by blists - more mailing lists