On 6/11/2024 7:03 AM, Jeffrey Haas wrote:
And again, sequence rollover for replay has the presumption that you're using exactly the same contents for the BFD PDU. The procedures for randomizing the Discriminators provide an appropriate nonce to prevent replay since the authentication data is computed over the entire BFD PDU.
I agree that if the discriminators change regularly and the change is enforced, then the rollover risks are addressed. However, I could not find text in either RFC5880 or draft-ietf-bfd-stability-13 that specifies how to do that.
RFC5880 specifies that "Your Discriminator" echoes the last value received from the peer. On reception, "Your Discriminator" is used to find the BFD session context, which implies that this is a somewhat stable value. As far as I can tell, "my discriminator" has no effect on receive processing, apart from being memorized and echoed in the next packets. If one just reads that text, it seems perfectly legit to keep the same value for a very long time. Changing the discriminator is permissible per section 6.3, but not mandated. The security considerations in section 9 suggest randomizing the discriminator at the beginning of a session, but do not mandate changing it during the session.
I think we are just missing something simple, like "the local discriminator MUST be changed to a new value after N packets have been sent", with N << 2^32. If I were implementing this I would pick a somewhat low value, to ensure that the code is used sometimes and that the behavior is verified.
-- Christian Huitema
