Jeff -
(Just back from vacation - hence the delay in responding.)
Thanx for your response.
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.
If the A bit is set, the packet MUST be authenticated under the
rules of section 6.7, based on the authentication type in use
(bfd.AuthType). This may cause the packet to be discarded.
<end snip>
I think it is entirely reasonable for an implementation based on these rules to
discard BFD packets when only one side is sending authentication – regardless
of authentication type.
The nuances you discuss below that suggest “well maybe an implementation might
make exceptions …” are not something that can be counted on to be interoperable.
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.
Les
> -----Original Message-----
> From: Jeffrey Haas <[email protected]>
> Sent: Monday, September 8, 2025 12:39 PM
> To: Les Ginsberg (ginsberg) <[email protected]>
> Cc: Mahesh Jethanandani <[email protected]>; drafts-expert-
> [email protected]; [email protected]; rtg-bfd@ietf. org <rtg-
> [email protected]>; [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
