On Tue, Jul 27, 2021 at 11:06 AM Leonard Crestez <cdleonard@xxxxxxxxx> 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?
