Hi Les, Playing catch-up here.
Trimming the text down to this one point. > On Sep 21, 2025, at 5:46 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > So, what I am suggesting is a new section – such as: > > Deployment Considerations > > RFC 5880 Section 6.8.6 requires that both sides have consistent enablement of > authentication. While the use case for the NULL auth type defined in > this document could be of value even when enabled only in one direction, such > usage would not be backwards compatible with the packet reception rules > as defined in RFC 5880. Therefore, unidirectional enablement of NULL auth > type MUST NOT be done. > > I welcome input from you and the authors. [mj] Aș Jeff pointed out in his e-mail below, RFC 5880 is sloppy about the requirement of enabling authentication in both directions. If anything, authentication is talked about only in the unidirectional sense. Therefore, to say that enabling authentication in one direction is somehow a violation of RFC 5880, and therefore "unidirectional enablement of NULL auth type MUST NOT be done”, is a very strong stance to take. I would prefer to say that: The use case for NULL auth type defined in this document does not require it to be enabled in both directions. However, to enable the packet receptions rules both sender and receiver of these packets will require to coordinate on a shared key that will be used in the session. The same key can be used by the receiver to enable the feature defined in this document towards the sender and make it bidirectional. Cheers. > > Les > > > > > -----Original Message----- > > From: Jeffrey Haas <[email protected] <mailto:[email protected]>> > > Sent: Monday, September 8, 2025 12:39 PM > > To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>> > > Cc: Mahesh Jethanandani <[email protected] > > <mailto:[email protected]>>; drafts-expert- > > [email protected] <mailto:[email protected]>; [email protected] > > <mailto:[email protected]>; rtg-bfd@ietf. org <rtg- > > [email protected] <mailto:[email protected]>>; > > [email protected] > > <mailto:[email protected]> > > Subject: Re: [IANA #1426750] expert review for draft-ietf-bfd-stability > > (bfd- > > parameters) > > > > Les, > > > > > > > On Sep 5, 2025, at 12:01 AM, Les Ginsberg (ginsberg) > > <[email protected] <mailto:[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 Mahesh Jethanandani [email protected]
