Re: [Technical Errata Reported] RFC5880 (7082)

[Dave Katz <[e-mail]>]

Well, I can’t speak for Dave 2, and it has been a fair number of years since this was written, but speaking for Dave 1 only I don’t think my intentions were so clever as to be trying to do some CPU exhaustion avoidance.  Instead, to me it looks like a structural bug, driven by trying to complete the AuthSeqKnown clause while writing prose.  Essentially a bit of code on the wrong side of the closing brace.

Looking at it now, modifying internal state based on a packet you’re rejecting due to authentication failure is obviously wrong, since it seems to be an easy DoS attack if you can somehow jump in at the right instant and break the sequence number.

—Dave


> On Sep 1, 2022, at 2:22 PM, John Scudder <[e-mail]> wrote:
> 
> Hi Folks,
> 
> I’  like to thank Glebs for the well-written and researched erratum. I’d like to engage the WG and authors before moving this one along.
> 
> AFAICT (and I am not as expert in the subject as some of you are), the erratum is correcting a legit bug in the spec. My concern is that as the submitter points out in https://mailarchive.ietf.org/arch/msg/rtg-bfd/lDxFfNpqo4kwuNEUY0AbjMBb8JU/, the bug appears to be there on purpose. Ish.
> 
> If we look at the IESG guidelines for processing of errata (https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/), 
> 
> “4. Technical items that have a clear resolution in line with the original intent should be classified as Verified. If the resolution is not clear or requires further discussion, the report should be classified as Hold for Document Update. In both cases, only items that are clearly wrong should be considered.”
> 
> Well that seems OK. But,
> 
> “5. Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should generally be Rejected. Significant clarifications should not be handled as errata reports and need to be discussed by the relevant technical community.”
> 
> It seems the currently documented design (check the sequence before checking the hash) was done on purpose, as Glebs documents, in order to gain some notional protection against a CPU exhaustion attack. It doesn’t seem likely that the repercussions were understood, though. If they were and the choice was made anyway, well that was the WG consensus and an erratum isn’t the right vehicle to fix it. If they weren’t… it’s a gray area, and given the nature of the bug, I’m inclined to verify the erratum.
> 
> On the balance I’m inclined to verify the erratum, since I have no evidence that the WG was indeed aware of the repercussions of the design choice. But, I’d like to invite comment from the WG and authors before I proceed.  
> 
> Thanks,
> 
> —John
> 
>> On Aug 12, 2022, at 10:11 AM, RFC Errata System <[e-mail]> wrote:
>> 
>> 
>> The following errata report has been submitted for RFC5880,
>> "Bidirectional Forwarding Detection (BFD)".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7082__;!!NEt6yMaO-gk!DTSk4TWBt9uqplNg1ca5Tb-mDREPCXJCXHdKoY5mlGGyc8nGY1xFUNZhgGKypL9eT_3W1HTSSNgYUSH4AsGJcg$
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Glebs Ivanovskis <[e-mail]>
>> 
>> Section: 6.7.3
>> 
>> Original Text
>> -------------
>> 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.
>> 
>> Replace the contents of the Auth Key/Digest field with the
>> authentication key selected by the received Auth Key ID field.  If
>> the MD5 digest of the entire BFD Control packet is equal to the
>> received value of the Auth Key/Digest field, the received packet
>> MUST be accepted.  Otherwise (the digest does not match the Auth
>> Key/Digest field), the received packet MUST be discarded.
>> 
>> Corrected Text
>> --------------
>> Replace the contents of the Auth Key/Digest field with the
>> authentication key selected by the received Auth Key ID field.  If
>> the MD5 digest of the entire BFD Control packet is not equal to the
>> received value of the Auth Key/Digest field, the received packet
>> MUST be discarded.
>> 
>> Otherwise, the packet MUST be accepted, bfd.AuthSeqKnown MUST be set to
>> 1, and bfd.RcvAuthSeq MUST be set to the value of the received
>> Sequence Number field.
>> 
>> Notes
>> -----
>> 1. Don't manipulate bfd.AuthSeqKnown and bfd.RcvAuthSeq before Auth Key/Digest check.
>> 2. Explicitly mention what bfd.AuthSeqKnown and bfd.RcvAuthSeq must be set to in both cases (bfd.AuthSeqKnown is 0 and bfd.AuthSeqKnown is 1).
>> 
>> Based on email exchange: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/rtg-bfd/lDxFfNpqo4kwuNEUY0AbjMBb8JU/__;!!NEt6yMaO-gk!DTSk4TWBt9uqplNg1ca5Tb-mDREPCXJCXHdKoY5mlGGyc8nGY1xFUNZhgGKypL9eT_3W1HTSSNgYUSEIW7r6RQ$
>> 
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --------------------------------------
>> RFC5880 (draft-ietf-bfd-base-11)
>> --------------------------------------
>> Title               : Bidirectional Forwarding Detection (BFD)
>> Publication Date    : June 2010
>> Author(s)           : D. Katz, D. Ward
>> Category            : PROPOSED STANDARD
>> Source              : Bidirectional Forwarding Detection
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>