Hi Alan, you've suggested It would be good to say that packets which fail authentication MUST NOT affect the BFD state.
I think that a BFD Control message that failed validation, and I consider authentication is a part of the validation process, MUST be discarded. If the number of consecutively discarded packets causes the associated with the BFD session Detection Timer expiration, then the state of this BFD session MUST be changed to Down. Thus, I think that packets that failed authentication affect the BFD state in the same manner as packets that failed any other step of the validation process. Regards, Greg On Wed, Apr 27, 2022 at 12:14 PM Alan DeKok <al...@deployingradius.com> wrote: > On Apr 25, 2022, at 6:23 AM, Gļebs Ivanovskis <gl...@mikrotik.com> 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. > >
