Les, To try to shorten this conversation, let's work from the presumption that the cited section summarizes as "if the a-bit is present on a PDU from some sender, you had been have authentication configured on your side as the receiver". I suspect it'll make you happier.
As we know, implementations can break the rules all they like. However, that's not what is ever being recommended here. Your original criticism was: "This could lead a naïve implementor to believe that it would be acceptable to enable this only in one direction (since no actual authentication check is performed)." The NULL authentication mechanism is encoded in the authentication field. Thus, as you note, stock RFC 5880 behaviors apply. And, as you also note, no actual authentication is being done - we're just leveraging the field. This is intentional. Since we're not actually making the recommendation to change the generic authentication procedures in RFC 5880, there's no need for additional text saying "don't break this rule that we're not asking you to break". Among other things, it'd be nudging us further out of experimental land. The fact that this procedure provides no authentication and some implementation may choose to use NULL auth unidirectionally is up to consenting implementations that are violating the specific terms of RFC 5880. Such consenting implementations would likely be okay with zero authentication, which is already the most commonly deployed profile for BFD today. -- Jeff > On Oct 6, 2025, at 12:05 AM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > Mahesh – > > I double checked and there are existing implementations that follow RFC 5880 > Section 6.8.6 strictly. > I suspect most implementations do this. > > This raises the question as to when it might be safe to enable this extension > and how to do so safely. > > My original comment was to suggest that some text be added to the document > saying that in order to avoid interoperability issues one way enablement of > NULL authentication should not be done. > > Your response below is quite different – it describes how enablement in one > direction could be used to automate bidirectional enablement. But this still > ignores the very real possibility that if the peer is a legacy implementation > the effect of one way enablement will be to bring the session down. > Implementors may then wonder what are the proper procedures to introduce use > of this extension. > > If you are going to allow one way enablement I think the document – which is > currently silent on this issue - needs to say much more than what you propose. > > Les > > From: Les Ginsberg (ginsberg) <[email protected] > <mailto:[email protected]>> > Sent: Wednesday, October 1, 2025 5:50 PM > To: Mahesh Jethanandani <[email protected] > <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; rtg-bfd@ietf. org <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Subject: RE: [IANA #1426750] expert review for draft-ietf-bfd-stability > (bfd-parameters) > > Mahesh – > > RFC 5880 Section 6.8.6 states: > > <snip> > > If the A bit is set and no authentication is in use (bfd.AuthType > is zero), the packet MUST be discarded. > > If the A bit is clear and authentication is in use (bfd.AuthType > is nonzero), the packet MUST be discarded. > <end snip> > > I don’t know how you (or Jeff 😊 ) can interpret that to mean it is OK to have > authentication enabled in one direction only. > > Again, my comment is non-blocking – so you can do what you like. But my > concern is that you will hit an interoperability problem someday from a > legacy implementation (which made a very reasonable interpretation of the > above from the base spec) when it encounters an implementation which supports > the stability draft. > I think it is prudent (and polite) to point out this possibility. > > Les > > > From: Mahesh Jethanandani <[email protected] > <mailto:[email protected]>> > Sent: Wednesday, October 1, 2025 4:45 PM > To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>> > Cc: Jeffrey Haas <[email protected] <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; rtg-bfd@ietf. org <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Subject: Re: [IANA #1426750] expert review for draft-ietf-bfd-stability > (bfd-parameters) > > 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] > <mailto:[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] <mailto:[email protected]>
