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

[Tom Parkin <tparkin@katalix.com>]

[-- Attachment #1: Type: text/plain, Size: 3027 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]