archive mirror
 help / color / mirror / Atom feed
From: Leonard Crestez <>
To: Francesco Ruggeri <>, David Ahern <>
Cc: 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 21:05:59 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

> It would be helpful if you could split your patch into smaller
> incremental chunks.


  reply	other threads:[~2021-07-27 18:06 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 [this message]
2021-07-27 20:23       ` Francesco Ruggeri
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).