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]>
Sent: Wednesday, October 1, 2025 5:50 PM
To: Mahesh Jethanandani <[email protected]>
Cc: [email protected]; [email protected]; rtg-bfd@ietf. org
<[email protected]>; [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]>
