On 11.08.2021 16:42, David Ahern wrote:
On 8/11/21 2:29 AM, Leonard Crestez wrote:
On 8/10/21 11:41 PM, Dmitry Safonov wrote:
Hi Leonard,
On Tue, 10 Aug 2021 at 02:50, Leonard Crestez <cdleonard@xxxxxxxxx>
wrote:
[..]
+/* Representation of a Master Key Tuple as per RFC5925 */
+struct tcp_authopt_key_info {
+ struct hlist_node node;
+ /* Local identifier */
+ u32 local_id;
There is no local_id in RFC5925, what's that?
An MKT is identified by (send_id, recv_id), together with
(src_addr/src_port, dst_addr/dst_port).
Why introducing something new to already complicated RFC?
It was there to simplify user interface and initial implementation.
But it seems that BGP listeners already needs to support multiple
keychains for different peers so identifying the key by (send_id,
recv_id, binding) is easier for userspace to work with. Otherwise they
need to create their own local_id mapping internally.
any proposed simplification needs to be well explained and how it
relates to the RFC spec.
The local_id only exists between userspace and kernel so it's not really
covered by the RFC.
There are objections to this and it seems to be unhelpful for userspace
zo I will replace it with match by binding.
BTW: another somewhat dubious simplification is that I offloaded the RFC
requirement to never add overlapping keys to userspace. So if userspace
adds keys with same recvid that match the same TCP 4-tuple then
connections will just start failing.
It's arguably fine to allow userspace misconfiguration to cause failures.
--
Regards,
Leonard
