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
