Re: [RFC] tcp: Initial support for RFC5925 auth option

[Leonard Crestez]

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.

OK