Re: Regarding keyed MD5/SHA1 authentication for BFD (RFC 5880)

[Alan DeKok <[e-mail]>]

On Apr 25, 2022, at 6:23 AM, Gļebs Ivanovskis <[e-mail]> wrote:
> I have a question regarding the order of operations during receipt of BFD control packet using keyed MD5/SHA1 authentication. Both Section 6.7.3. "Keyed MD5 and Meticulous Keyed MD5 Authentication" and Section 6.7.4. "Keyed SHA1 and Meticulous Keyed SHA1 Authentication" (in parts "Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication" and "Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication" respectively) suggest that Sequence Number field of incoming control packet is examined prior to calculating any digest/hash. I have discovered that the order was the other way round in early drafts, but then was changed between versions 8 and 9, presumably followed by this comment:
> 
> If we check the sequence number after doing a MD5 digest verification, even if we get replayed packets, we will be doing the costly hash operations, thus wasting a lot of CPU and exposing ourselves to simple CPU exhaustion attacks.

  From a security point of view, the usual process is to verify packets first, and then use the contents of the packets.  This can be expensive from a CPU point of view, but it's the cost of being secure.

> Unfortunately, I couldn't find any discussion following this suggestion. I understand the motivation of making a "cheaper" Sequence Number check before doing more "expensive" digest/hash calculation, but the reordering of stages does not seem to be thought through very well. The text of RFC 5880 mandates implementations to act on received Sequence Number before validating digest/hash:
> 
> Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field.
> 
> and
> 
> Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field, and the received packet MUST be accepted.
> 
> This leaves the opportunity for unauthorized control packet to mess up session state variables, potentially leading to subsequent valid packets being dropped due to Sequence Number outside of expected range and BFD session being erroneously diagnosed as Down. Note that "and the received packet MUST be accepted" clause has been removed from MD5 part, but not from SHA1 part, requesting implementations to skip hash verification altogether if bfd.AuthSeqKnown is 0.

  It would be good to say that packets which fail authentication MUST NOT affect the BFD state.

> Is the sequence of operations described in Sections 6.7.3. and 6.7.4. correct?
> 
> In my opinion, as a minimum, the following changes need to be made:
> 
> 	• The "and the received packet MUST be accepted" clause needs to be removed from Section 6.7.4.
> 	• Sections 6.7.3. and 6.7.4. need to split examining incoming packet's Sequence Number (which can be done before digest/hash verification) and acting upon it (which has to happen after verification).

  That seems reasonable.

> Furthermore, I would like to suggest going back to original ordering with digest/hash verification being done before examining Sequence Number, because it simplifies the algorithm. I don't think that checking Sequence Number first provides much protection against CPU exhaustion attacks, because Sequence Numbers are transmitted in clear text and it wouldn't be that difficult for an attacker to come up with a valid Sequence Number to pass "cheap" check.

  Yes.

  The "secure sequence numbers" draft attempts to address these issues.

  Alan DeKok.