Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets
Extracted elements (22)
BFD Echo mode is sufficient to verify Path MTU for directly connected single-hop systems, but for multihop BFD (RFC 5883) this guarantee does not hold, motivating the need for a padded-PDU approach to Path MTU verification over multiple hops.
BFD encapsulation for multihop sessions is a simple UDP packet, and the BFD specification is silent on the length of the encapsulation carrying the BFD PDU. While the BFD PDU is typically exactly the UDP payload size, this is not required, which creates the possibility that the transport protocol length may be larger than the contained BFD PDU — the basis for this mechanism.
The padding payload is set to zero rather than arbitrary data to avoid leaking local uninitialized memory contents from the sender's implementation.
Implementations that do not support large BFD packets may either discard the padded packets or improperly reject them during validation. In either case the BFD state machine behaves as if no Control packets are received, and if large BFD packets are enabled on an Up session whose remote peer cannot support them, the session will go Down.
In ECMP or LAG environments, BFD Control packets may only traverse currently-up member links, so BFD with Large Packets cannot guarantee all component links have been tested. A BFD session may be Up while some traffic is dropped on specific component links with misconfigured MTUs.
Once a BFD Large Packets session is Up, if the Path MTU drops below the tested MTU the session goes Down. Conversely, if the Path MTU increases, the BFD session continues unaffected — the mechanism only ensures the minimally acceptable MTU is usable.
The BFD Large Packets mechanism can also be applied to Seamless BFD (S-BFD) as defined in RFC 7880.
To test bidirectional Path MTU, bfd.PaddedPduSize must be configured on each side of the BFD session. Without consistent configuration on both sides, BFD with Large Packets may only correctly determine unidirectional connectivity at the tested MTU.
The contents of the additional padding payload MUST be zero. This avoids leaking local uninitialized data from the sender.
The contents of the additional padding payload SHOULD NOT be validated by the receiver.
The Don't Fragment bit (RFC 791 Section 2.3) of the IP payload MUST be set when using IPv4 encapsulation, to ensure Path MTU verification works as intended.
The minimum size of bfd.PaddedPduSize MUST NOT be smaller than 24 or 26 bytes, as permitted by the BFD element of procedure in Section 6.8.6 of RFC 5880.
When multiple BFD clients desire to test the same BFD endpoints using different bfd.PaddedPduSize parameters, implementations SHOULD select the largest bfd.PaddedPduSize parameter from the configured sessions.
A new BFD variable bfd.PaddedPduSize is defined: the BFD transport protocol payload size (in bytes) is increased to this value. The minimum size MUST NOT be smaller than 24 or 26 bytes as permitted by BFD procedure. The contents of the additional payload MUST be zero.
The 'bfd-large-common' YANG grouping provides a 'pdu-size' leaf (type padded-pdu-size, conditional on 'padding' feature) that configures the padded PDU size for an Asynchronous mode BFD session. By default no additional padding is added.
The YANG module 'ietf-bfd-large' defines a 'padding' feature statement and a 'padded-pdu-size' typedef (uint16, range 24..65535, units bytes) used to configure per-session PDU padding. It augments BFD YANG modules for single-hop, multihop, LAG, and MPLS session types.
IANA has registered the URI 'urn:ietf:params:xml:ns:yang:ietf-bfd-large' in the 'ns' subregistry of the 'IETF XML Registry' (RFC 3688).
IANA has registered the YANG module 'ietf-bfd-large' (prefix: bfdl, namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-large) in the 'YANG Module Names' registry (RFC 6020).
On-path attackers that can selectively drop BFD packets, including those with large MTUs, can cause BFD sessions to go Down. This document does not change the underlying security considerations of the BFD protocol or its encapsulations.
The 'ietf-bfd-large' YANG module must be accessed via YANG-based management protocols (NETCONF, RESTCONF) using a secure transport layer (SSH, TLS, QUIC) with mutual authentication. NACM (RFC 8341) provides access control for NETCONF/RESTCONF users.
The 'pdu-size' YANG data node is writable and sensitive: changing it for a session in the Up state may cause the session to go Down. Operators must be mindful that multiple BFD clients may rely on the status of a given BFD session when changing this value.
The padded BFD PDU consists of the standard BFD Control packet (minimum 24 or 26 bytes) followed by zero-filled padding bytes up to bfd.PaddedPduSize. The total transport protocol (UDP) payload length equals bfd.PaddedPduSize; padding bytes MUST be zero and SHOULD NOT be validated by the receiver.