Bidirectional Forwarding Detection (BFD)
updated by
Extracted elements (29)
BFD is designed to be implemented in the forwarding plane rather than the control plane. This decouples the protocol from the fate of the routing engine and makes it compatible with graceful restart mechanisms. Implementing BFD in the control engine is permitted but may prevent detection of certain forwarding-plane failures.
Demand mode was introduced to reduce overhead in deployments with a very large number of BFD sessions or when the Echo function is used symmetrically. The tradeoff is that Detection Times are driven by implementation heuristics rather than the BFD protocol itself, and Demand mode must not be used when the path round-trip time exceeds the desired Detection Time.
There is no discovery mechanism in BFD; sessions are established based on the needs of the application using BFD (e.g., an OSPF neighbor discovered via Hello). This avoids adding another discovery layer and keeps BFD a simple liveness-detection service decoupled from higher-layer routing logic.
Enabling or disabling authentication on a live BFD session may cause the session to fail in a simple implementation, because the packet acceptance rules require both systems to be synchronized (within the Detection Time) on whether authentication is 'in use.' Implementations SHOULD allow the authentication state to change at most once without external intervention to prevent attackers from toggling authentication by sending crafted packets.
A system MUST NOT transmit BFD Control packets at an interval less than the larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval (minus jitter). The transmit interval MUST be recalculated whenever either of these values changes.
A system taking the Active role MUST send BFD Control packets regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets until it has received a BFD packet and thus learned the remote system's discriminator value. At least one system MUST take the Active role.
BFD Control packets MUST be jittered on a per-packet basis by up to 25% (interval reduced by a random value of 0–25%) to avoid self-synchronization. When bfd.DetectMult is 1, the interval MUST be between 75% and 90% of the negotiated interval to ensure the Detection Time does not pass before the next packet arrives.
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up, and MUST NOT be transmitted unless the last received BFD Control packet contains a nonzero Required Min Echo RX Interval. The Echo packet payload is a local matter but SHOULD include some form of authentication since Echo packets may be spoofed.
bfd.LocalDiscr SHOULD be set to a random (but still unique) value to improve security. bfd.XmitAuthSeq MUST be initialized to a random 32-bit value. bfd.AuthSeqKnown MUST be initialized to zero.
Demand mode is activated by a system setting the Demand (D) bit; the receiving system ceases periodic BFD Control transmission. The Demand (D) bit MUST NOT be set unless bfd.DemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up. A Poll Sequence MUST be initiated whenever the Demand bit value changes.
Each system MUST choose a unique, nonzero opaque discriminator value (bfd.LocalDiscr) for each BFD session. Once the remote system echoes the discriminator back in the Your Discriminator field, all subsequent packets MUST be demultiplexed based on Your Discriminator alone, allowing source address and interface to change without losing session association.
For Keyed MD5/SHA1 reception, if bfd.AuthSeqKnown is 1, received sequence numbers outside the window [bfd.RcvAuthSeq, bfd.RcvAuthSeq+(3*DetectMult)] MUST be discarded. For Meticulous variants the window is [bfd.RcvAuthSeq+1, bfd.RcvAuthSeq+(3*DetectMult)]. bfd.AuthSeqKnown MUST be reset to zero after no packets are received for at least twice the Detection Time.
If bfd.DesiredMinTxInterval is increased while the session is Up, the actual transmission interval MUST NOT change until the Poll Sequence has terminated, ensuring the remote system updates its Detection Time before the interval increases. Symmetrically, if bfd.RequiredMinRxInterval is reduced, the previous value MUST be used for the remote Detection Time calculation until the Poll Sequence terminates.
If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded. Conversely, if the A bit is clear and authentication is in use, the packet MUST also be discarded. This enforces that authentication state is consistent between sender and receiver.
Implementations supporting authentication MUST support both Keyed SHA1 and Meticulous Keyed SHA1 authentication. Simple Password, Keyed MD5, and Meticulous Keyed MD5 are optional. The use of MD5-based authentication is strongly discouraged.
In Asynchronous mode, the local Detection Time equals the Detect Mult received from the remote system multiplied by the agreed remote transmit interval (max of bfd.RequiredMinRxInterval and last received Desired Min TX Interval). If the Detection Time passes without receiving a BFD Control packet while in Init or Up state, the session MUST be set to Down with Diag=1.
When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to at least one second (1,000,000 microseconds) to keep bandwidth consumed by non-Up sessions negligible. When the Echo function is active, bfd.RequiredMinRxInterval SHOULD likewise be set to at least one second.
When receiving a BFD Control packet, the version MUST be 1, the Length field MUST be at least 24 (or 26 if A bit is set) and must not exceed the encapsulating payload, Detect Mult MUST be nonzero, the M bit MUST be zero, and My Discriminator MUST be nonzero; packets failing any of these checks MUST be discarded.
A Poll Sequence is initiated by setting the Poll (P) bit in outgoing BFD Control packets; the remote system MUST immediately reply with the Final (F) bit set, independent of its periodic schedule. The Poll Sequence terminates upon receipt of a packet with the Final bit set. A packet MUST NOT have both P and F set simultaneously.
Authentication Type values in the Auth Type field: 0=Reserved, 1=Simple Password, 2=Keyed MD5, 3=Meticulous Keyed MD5, 4=Keyed SHA1, 5=Meticulous Keyed SHA1; values 6–255 reserved for future use.
Diagnostic codes (5-bit Diag field) indicate the reason for the most recent session state change: 0=No Diagnostic, 1=Control Detection Time Expired, 2=Echo Function Failed, 3=Neighbor Signaled Session Down, 4=Forwarding Plane Reset, 5=Path Down, 6=Concatenated Path Down, 7=Administratively Down, 8=Reverse Concatenated Path Down; values 9–31 reserved.
IANA maintains the BFD Diagnostic Codes registry (values 0–31; 0–8 defined in this document, 9–31 reserved) and the BFD Authentication Types registry (values 0–255; 0–5 defined in this document, 6–255 reserved). Both registries are created by this document.
BFD authentication using Simple Password provides only weak protection and is subject to eavesdropping. Keyed MD5 is strongly discouraged due to known vulnerabilities. Implementations MUST support Keyed SHA1 / Meticulous Keyed SHA1. Without Meticulous keying, sequence numbers increment only occasionally, leaving larger windows for replay attacks; Meticulous variants increment on every packet for stronger protection.
BFD packets are subject to spoofing and denial-of-service attacks that could cause false session failures or prevent failure detection. Using the randomized discriminator value and cryptographic authentication (SHA1) mitigates spoofing. The use of BFD without authentication in environments where packets could be injected is explicitly noted as a security risk.
BFD defines four session states: Down (session not established or just created), Init (remote is communicating but session not yet Up), Up (session established, connectivity working), and AdminDown (administratively disabled). Transitions are driven by the received State field and Detection Timer expiration; a three-way handshake is required for both establishment and teardown.
The BFD Control packet mandatory section is 24 bytes: 3-bit Version, 5-bit Diag, 2-bit State, flags (P, F, C, A, D, M), 8-bit Detect Mult, 8-bit Length, 32-bit My Discriminator, 32-bit Your Discriminator, 32-bit Desired Min TX Interval (microseconds), 32-bit Required Min RX Interval (microseconds), and 32-bit Required Min Echo RX Interval (microseconds). An optional Authentication Section follows when the A bit is set.
The Keyed MD5 / Meticulous Keyed MD5 Authentication Section is fixed at 24 bytes: Auth Type (2 or 3), Auth Len (24), Auth Key ID, Reserved (zero), 32-bit Sequence Number, and a 16-byte Auth Key/Digest field holding the MD5 digest computed over the entire packet.
The Keyed SHA1 / Meticulous Keyed SHA1 Authentication Section is fixed at 28 bytes: Auth Type (4 or 5), Auth Len (28), Auth Key ID, Reserved (zero), 32-bit Sequence Number, and a 20-byte Auth Key/Hash field holding the SHA1 hash computed over the entire packet.
The Simple Password Authentication Section contains Auth Type (1), Auth Len (password length + 3), Auth Key ID (1 byte), and Password (1–16 bytes binary string). The Auth Len field must equal the password length plus three.