archive mirror
 help / color / mirror / Atom feed
From: Francesco Ruggeri <>
To: Leonard Crestez <>
Cc: David Ahern <>,
	Eric Dumazet <>,
	"David S. Miller" <>,
	Herbert Xu <>,
	Hideaki YOSHIFUJI <>,
	Jakub Kicinski <>,
	David Ahern <>,
	Yuchung Cheng <>,
	Mat Martineau <>,
	Christoph Paasch <>,
	Priyaranjan Jha <>,
	Kuniyuki Iwashima <>,
	Menglong Dong <>,
	open list <>,, netdev <>,
	Salam Noureddine <>,
	Bob Gilligan <>,
	Dmitry Safonov <>
Subject: Re: [RFC] tcp: Initial support for RFC5925 auth option
Date: Tue, 27 Jul 2021 13:23:49 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jul 27, 2021 at 11:06 AM Leonard Crestez <> wrote:
> On 7/27/21 6:05 AM, Francesco Ruggeri wrote:
> > Hi Leonard,
> >
> > thanks for taking on this task!
> >
> >> I'm especially interested in feedback regarding ABI and testing.
> >
> > I noticed that the TCP connection identifier is not part of the
> > representation of the MKT (tcp_authopt_key_info).
> > This could cause some issues if, for example 2 MKTs with different
> > <remote IP, remote TCP port> in the TCP connection identifier but same
> > KeyID (recv_id) are installed on a socket. In that case
> > tcp_authopt_inbound_key_lookup() may not pick the correct MKT for the
> > connection. Matching incoming segments only based on recv_id may not
> > comply with the RFC.
> > I think there may be other cases where TCP connection identifiers may
> > be needed to resolve conflicts, but I have to look at your patch in
> > more detail.
> The RFC doesn't specify what the "tcp connection identifier" needs to
> contains so for this first version nothing was implemented.
> Looking at MD5 support in linux the initial commit only supported
> binding keys to addresses and only relatively support was added for
> address prefixes and interfaces. Remote ports still have no effect.
> I think adding explicit address binding for TCP-AO would be sufficient,
> this can be enhanced later. The most typical usecase for TCP auth is to
> connect with a BGP peer with a fixed IP address.
> As far as I understand this only actually matters for SYN packets where
> you want a single listen socket to accept client using overlapping
> keyids. For an active connection userspace can only add keys for the
> upcoming destination.

The RFC does not seem to put any restrictions on the MKTs used with a
TCP connection, except that every segment must match at most one MKT,
where the matching is done on the socket pair and for incoming
segments on the KeyID, and for outgoing segments by designating a
desired MKT.
If I understand what you suggest for the initial commit, socket pair
matching would not be done, and user level (together with out-of-band
coordination between peers) would be responsible for making sure that
the segments' socket pairs are consistent with the implied socket
pairs of the MKTs on the socket. Failure to do that would be
considered a misconfiguration and would result in undefined behavior.
Is that correct?
Even if the MKT's socket pair is not used in the initial commit, would
it help having it in the API, to avoid future incompatibilities with
user level? Or would it be understood that user level code using the
initial commit may have to change with future commits?

  reply	other threads:[~2021-07-27 20:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 11:24 Leonard Crestez
2021-07-19 16:00 ` Kuniyuki Iwashima
2021-07-19 21:37   ` Leonard Crestez
2021-07-19 21:40 ` David Ahern
2021-07-27  3:05   ` Francesco Ruggeri
2021-07-27 18:05     ` Leonard Crestez
2021-07-27 20:23       ` Francesco Ruggeri [this message]
2021-07-28  6:49         ` Leonard Crestez

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC] tcp: Initial support for RFC5925 auth option' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).