RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (4)

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Note: This RFC has been updated by RFC 7419, RFC 7880, RFC 8562

Source of RFC: bfd (rtg)

Errata ID: 2530
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Mach Chen
Date Reported: 2010-09-24
Verifier Name: Adrian Farrel
Date Verified: 2010-09-26

Section 4.3 says:

Sequence Number

      The sequence number for this packet.  For Keyed MD5
      Authentication, this value is incremented occasionally.  For
      Meticulous Keyed MD5 Authentication, this value is incremented for
      each successive packet transmitted for a session.  This provides
      protection against replay attacks.

It should say:

Sequence Number

      The sequence number for this packet.  For Keyed MD5
      Authentication, this value is incremented (by one) occasionally.  For
      Meticulous Keyed MD5 Authentication, this value is incremented by one for
      each successive packet transmitted for a session.  This provides
      protection against replay attacks.

Notes:

This change clarifies the amount by which the sequence number is incremented.

Errata ID: 7082
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Glebs Ivanovskis
Date Reported: 2022-08-12
Verifier Name: John Scudder
Date Verified: 2022-09-06

Section 6.7.3 says:

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.

It should say:

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://mailarchive.ietf.org/arch/msg/rtg-bfd/lDxFfNpqo4kwuNEUY0AbjMBb8JU/

(See also https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ngf3Chmpy_EqNPlmuMZOslayy2E/)

Errata ID: 7083
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Glebs Ivanovskis
Date Reported: 2022-08-12
Verifier Name: John Scudder
Date Verified: 2022-09-06

Section 6.7.4 says:

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.

Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field.  If
the SHA1 hash of the entire BFD Control packet is equal to the
received value of the Auth Key/Hash field, the received packet
MUST be accepted.  Otherwise (the hash does not match the Auth
Key/Hash field), the received packet MUST be discarded.

It should say:

Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field.  If
the SHA1 hash of the entire BFD Control packet is not equal to the
received value of the Auth Key/Hash 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/Hash 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://mailarchive.ietf.org/arch/msg/rtg-bfd/lDxFfNpqo4kwuNEUY0AbjMBb8JU/

(See also https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ngf3Chmpy_EqNPlmuMZOslayy2E/)

Errata ID: 6926
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Glebs Ivanovskis
Date Reported: 2022-04-06
Verifier Name: RFC Editor
Date Verified: 2022-04-07

Section 6.8.6 says:

Set bfd.RemoteState to the value of the State (Sta) field.

It should say:

Set bfd.RemoteSessionState to the value of the State (Sta) field.

Notes:

The variable bfd.RemoteState is not defined in section 6.8.1 and is only mentioned once in the entire document. It is likely a typo and a similarly named bfd.RemoteSessionState was meant instead.

Status: Held for Document Update (3)

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Note: This RFC has been updated by RFC 7419, RFC 7880, RFC 8562

Source of RFC: bfd (rtg)

Errata ID: 5205
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Dave Katz
Date Reported: 2017-12-14
Held for Document Update by: Alvaro Retana
Date Held: 2018-03-14

Section 6.8.4 says:

If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the
remote system, and bfd.SessionState is Init or Up, the session has
gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired).

It should say:

If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the
remote system, the session has
gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired).

Notes:

This is based on an email I received from Anil Kumar of Nokia (anil.kumar_t_v@nokia.com).

The language as originally written made a session timeout a no-op when in Down state. This was a gratuitous attempt to avoid a null state transition, but had the side effect of not setting the diag code (and otherwise is no different).

This turns out to be problematic in the case where system "A" signals AdminDown, causing system "B" to respond with Down state. If the link then fails, the existing verbiage implies that "B" will not report the detection timeout, even locally.

If the link fails in a unidirectional manner (such that "B" is deaf), B will give no indication of a timeout in its outgoing Control packets back to A (which can in fact hear them).

Making the suggested change should ensure that the diagnostic code is always set to Detection Time Expired when Control packets stop arriving, even if the far end system was previously reporting AdminDown.

Errata ID: 7240
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Jeffrey Haas
Date Reported: 2022-11-06
Held for Document Update by: John Scudder
Date Held: 2023-03-10

Section 6.8.1 says:

   bfd.LocalDiag

      The diagnostic code specifying the reason for the most recent
      change in the local session state.  This MUST be initialized to
      zero (No Diagnostic).

It should say:

No proposed changes are offered here. See the notes for further discussion.

Notes:

RFC 5880 at various points calls out setting the value of bfd.LocalDiag as part of state transitions. The text defining the feature calls for it to be initialized to zero. Discussion on the WG mailing list following the filing of the initial version of this erratum revealed two things:

First, the text of the RFC is correct, complete, and reflects the authors’ intention at the time of writing, which really WAS that the value should only be initialized to zero but not reset to zero at any other time.

Second, by not emphasizing this point, the spec although formally speaking unambiguous, left space for implementors to exercise their intuitions and creativity. As a result, several implementations are reported to reset this value to zero when the session transitions back to Up.

The discussion is archived at https://mailarchive.ietf.org/arch/msg/rtg-bfd/yEOx2LTO51zq1he6vChUOVJySqM/ . If a new version of RFC 5880 is prepared in the future, this question should be reopened as part of that process. It would also be possible to offer a standards track document to update RFC 5880 in this respect if WG consensus can be found for a new approach.

Errata ID: 4410
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Liu Lin
Date Reported: 2015-07-07
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 6.8.4 says:

If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set), the session
has gone down

It should say:

If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set),and without 
receiving a BFD Control packet with the Final (F) bit set from the
remote system, the session has gone down

Notes:

If has received BFD Control packet with the Final (F) bit set from the
remote system, the session will not gone down

Status: Rejected (1)

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Note: This RFC has been updated by RFC 7419, RFC 7880, RFC 8562

Source of RFC: bfd (rtg)

Errata ID: 6818
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2022-01-15
Rejected by: John Scudder
Date Rejected: 2022-05-09

Section 6.7.2 says:

      If the Auth Len field is not equal to the length of the password
      selected by the key ID, plus three, the packet MUST be discarded.

It should say:

      If the Auth Len field is not match to the length of the password
      selected by the key ID, plus three, the packet MUST be discarded.

Notes:

The value of the Auth Len field is the length of the password plus 3.
--VERIFIER NOTES--
https://mailarchive.ietf.org/arch/msg/rtg-bfd/ukbCzkS8NkTWdXEPvB9mlFtIiSQ/

This erratum proposes changing “is not equal” to “is not match”. As far as I can tell would make the text less, not more, precise.

Report New Errata



Advanced Search