From: Leonard Crestez <firstname.lastname@example.org> To: Francesco Ruggeri <email@example.com> Cc: David Ahern <firstname.lastname@example.org>, Eric Dumazet <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Herbert Xu <email@example.com>, Hideaki YOSHIFUJI <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, David Ahern <firstname.lastname@example.org>, Yuchung Cheng <email@example.com>, Mat Martineau <firstname.lastname@example.org>, Christoph Paasch <email@example.com>, Priyaranjan Jha <firstname.lastname@example.org>, Kuniyuki Iwashima <email@example.com>, Menglong Dong <firstname.lastname@example.org>, open list <email@example.com>, firstname.lastname@example.org, netdev <email@example.com>, Salam Noureddine <firstname.lastname@example.org>, Bob Gilligan <email@example.com>, Dmitry Safonov <firstname.lastname@example.org> Subject: Re: [RFC] tcp: Initial support for RFC5925 auth option Date: Wed, 28 Jul 2021 09:49:10 +0300 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CA+HUmGgwvn7uPfoKqy1extwEksAXOcTf2trDX8dcYGtdeppebQ@mail.gmail.com> On 7/27/21 11:23 PM, Francesco Ruggeri wrote: > On Tue, Jul 27, 2021 at 11:06 AM Leonard Crestez <firstname.lastname@example.org> 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
prev parent reply other threads:[~2021-07-28 6:50 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 2021-07-27 20:23 ` Francesco Ruggeri 2021-07-28 6:49 ` Leonard Crestez [this message]
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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC] tcp: Initial support for RFC5925 auth option' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).