From: Guillaume Nault <gnault@redhat.com>
To: Tom Parkin <tparkin@katalix.com>
Cc: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>,
netdev@vger.kernel.org
Subject: Re: [PATCH net] l2tp: Allow duplicate session creation with UDP
Date: Thu, 16 Jan 2020 20:05:56 +0100 [thread overview]
Message-ID: <20200116190556.GA25654@linux.home> (raw)
In-Reply-To: <20200116131223.GB4028@jackdaw>
On Thu, Jan 16, 2020 at 01:12:24PM +0000, Tom Parkin wrote:
> On Thu, Jan 16, 2020 at 13:38:54 +0100, Guillaume Nault wrote:
> > Well, I think we have a more fundamental problem here. By adding
> > L2TPoUDP sessions to the global list, we allow cross-talks with L2TPoIP
> > sessions. That is, if we have an L2TPv3 session X running over UDP and
> > we receive an L2TP_IP packet targetted at session ID X, then
> > l2tp_session_get() will return the L2TP_UDP session to l2tp_ip_recv().
> >
> > I guess l2tp_session_get() should be dropped and l2tp_ip_recv() should
> > look up the session in the context of its socket, like in the UDP case.
> >
> > But for the moment, what about just not adding L2TP_UDP sessions to the
> > global list? That should fix both your problem and the L2TP_UDP/L2TP_IP
> > cross-talks.
> >
> > diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> > index f82ea12bac37..f70fea8d093d 100644
> > --- a/net/l2tp/l2tp_core.c
> > +++ b/net/l2tp/l2tp_core.c
> > @@ -316,7 +316,7 @@ int l2tp_session_register(struct l2tp_session *session,
> > goto err_tlock;
> > }
> >
> > - if (tunnel->version == L2TP_HDR_VER_3) {
> > + if (tunnel->encap == L2TP_ENCAPTYPE_IP) {
> > pn = l2tp_pernet(tunnel->l2tp_net);
> > g_head = l2tp_session_id_hash_2(pn, session->session_id);
> >
> > @@ -1587,8 +1587,8 @@ void __l2tp_session_unhash(struct l2tp_session *session)
> > hlist_del_init(&session->hlist);
> > write_unlock_bh(&tunnel->hlist_lock);
> >
> > - /* For L2TPv3 we have a per-net hash: remove from there, too */
> > - if (tunnel->version != L2TP_HDR_VER_2) {
> > + /* For IP encap we have a per-net hash: remove from there, too */
> > + if (tunnel->encap == L2TP_ENCAPTYPE_IP) {
> > struct l2tp_net *pn = l2tp_pernet(tunnel->l2tp_net);
> > spin_lock_bh(&pn->l2tp_session_hlist_lock);
> > hlist_del_init_rcu(&session->global_hlist);
> >
>
> I agree with you about the possibility for cross-talk, and I would
> welcome l2tp_ip/ip6 doing more validation. But I don't think we should
> ditch the global list.
>
> As per the RFC, for L2TPv3 the session ID should be a unique
> identifier for the LCCE. So it's reasonable that the kernel should
> enforce that when registering sessions.
>
I had never thought that the session ID could have global significance
in L2TPv3, but maybe that's because my experience is mostly about
L2TPv2. I haven't read RFC 3931 in detail, but I can't see how
restricting the scope of sessions to their parent tunnel would conflict
with the RFC.
> When you're referring to cross-talk, I wonder whether you have in mind
> normal operation or malicious intent? I suppose it would be possible
> for someone to craft session data packets in order to disrupt a
> session.
>
What makes me uneasy is that, as soon as the l2tp_ip or l2tp_ip6 module
is loaded, a peer can reach whatever L2TPv3 session exists on the host
just by sending an L2TP_IP packet to it.
I don't know how practical it is to exploit this fact, but it looks
like it's asking for trouble.
> For normal operation, you just need to get the wrong packet on the
> wrong socket to run into trouble of course. In such a situation
> having a unique session ID for v3 helps you to determine that
> something has gone wrong, which is what the UDP encap recv path does
> if the session data packet's session ID isn't found in the context of
> the socket that receives it.
Unique global session IDs might help troubleshooting, but they also
break some use cases, as reported by Ridge. At some point, we'll have
to make a choice, or even add a knob if necessary.
next prev parent reply other threads:[~2020-01-16 19:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 22:34 [PATCH net] l2tp: Allow duplicate session creation with UDP Ridge Kennedy
2020-01-16 12:31 ` Tom Parkin
2020-01-16 19:28 ` Guillaume Nault
2020-01-16 21:05 ` Tom Parkin
2020-01-17 13:43 ` Guillaume Nault
2020-01-17 18:59 ` Tom Parkin
2020-01-18 17:18 ` Guillaume Nault
2020-01-16 12:38 ` Guillaume Nault
2020-01-16 13:12 ` Tom Parkin
2020-01-16 19:05 ` Guillaume Nault [this message]
2020-01-16 21:23 ` Tom Parkin
2020-01-16 21:50 ` Ridge Kennedy
2020-01-17 13:18 ` Tom Parkin
2020-01-17 14:25 ` Guillaume Nault
2020-01-17 19:19 ` Tom Parkin
2020-01-18 19:13 ` Guillaume Nault
2020-01-20 15:09 ` Tom Parkin
2020-01-21 16:35 ` Guillaume Nault
2020-01-22 11:55 ` James Chapman
2020-01-25 11:57 ` Guillaume Nault
2020-01-27 9:25 ` James Chapman
2020-01-29 11:44 ` Guillaume Nault
2020-01-30 10:28 ` James Chapman
2020-01-30 22:34 ` Guillaume Nault
2020-01-31 8:12 ` James Chapman
2020-01-31 12:49 ` Guillaume Nault
2020-01-31 9:55 ` Tom Parkin
2020-01-31 12:50 ` Guillaume Nault
2020-01-17 16:36 ` Guillaume Nault
2020-01-17 19:29 ` Tom Parkin
2020-01-18 17:52 ` Guillaume Nault
2020-01-20 11:47 ` Tom Parkin
2020-01-16 21:26 ` Ridge Kennedy
2020-01-31 12:58 ` Guillaume Nault
2020-02-03 23:29 ` Ridge Kennedy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200116190556.GA25654@linux.home \
--to=gnault@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ridge.kennedy@alliedtelesis.co.nz \
--cc=tparkin@katalix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.