Les,
> On Sep 5, 2025, at 12:01 AM, Les Ginsberg (ginsberg) <[email protected]> > wrote: [Note, reordering your sentences.] > This draft, however, introduces a completely different use of the > authentication section – one that has nothing to do with security – rather > with evaluating the performance (or lack thereof) of the BFD connection. That is a fair observation. The contents here are not authentication. > Up to now Authentication section has been used to encode security > information. It is “intuitively obvious” that if this is only done in one > direction the intent of authentication – to verify that both peers are > trustworthy – cannot be done in a unidirectional fashion. I think the security property you're looking for is mutual authentication. > That use case does not demand bidirectional advertisement. Unidirectional > sending of this information could still be useful. > But this would violate RFC 5880. I think RFC 5880 is a bit sloppy around this point. What we see in section 6.7 is the following text: : 6.7. Authentication : : An optional Authentication Section MAY be present in the BFD Control : packet. In its generic form, the purpose of the Authentication : Section is to carry all necessary information, based on the : authentication type in use, to allow the receiving system to : determine the validity of the received packet. The exact mechanism : depends on the authentication type in use, but in general the : transmitting system will put information in the Authentication : Section that vouches for the packet's validity, and the receiving : system will examine the Authentication Section and either accept the : packet for further processing or discard it. Here, we have text talking about checking the validity of a packet. That part is inherently unidirectional. The A-bit is used to signal that we're doing this. : : The same authentication type, and any keys or other necessary : information, obviously must be in use by the two systems. The : negotiation of authentication type, key exchange, etc., are all : outside the scope of this specification and are expected to be : performed by means outside of the protocol. The YANG module (RFC 9314) and common implementation certainly supports this text. Interestingly, the protocol's procedures isn't in the shape that requires this. Since the authentication operation is inherently unidirectional, it's possible for a pair of implementations to have authentication configured for send and for receive, separately. This could be different authentication modes (or none) with different keys. That's not what we see deployed though, and the text above does support the idea that this behavior is inherently bidirectionally deployed. > > I am not suggesting that anything in the draft even hints at a unidirectional > use case. I am simply pointing out that a naïve implementor might think > unidirectional enablement is not forbidden. Mention that this is not allowed > under RFC 5880 rules could help to avoid such a violation. Can you wave in the general direction where in the draft you think such a consideration belongs? -- Jeff
