On 7/27/21 11:23 PM, Francesco Ruggeri wrote:
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?
All MKTs are assigned to individual sockets via setsockopt, there is no
sharing of keys. For an established connection the socket is already
determined by linux TCP stack based on addr/port so no further matching
on per-key address needs to be done.
The only interesting cases are:
1) Keys in SYN packets are possibly ambiguous. Current limitation is
that a server socket needs all key ids to be different and this is
indeed bad.
2) User is currently allowed to configure same keyid multiple times. RFC
does not allow this and behavior is undefined.
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?
The rules used to distinguish keys in SYN packets can be further
elaborated by extending the uapi tcp_authopt_key structure. Increasing
the size of a structure doesn't break ABI if you're careful with length
checks.
--
Regards,
Leonard
