Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
updated by
- rfc-8564 — Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)
Extracted elements (20)
The default BFD authentication is tied to IS-IS shared secret state to minimize configuration burden, consistent with TRILL's goal of operating with minimum configuration. Port and System IDs are included in the key derivation input to minimize reuse of the same key and improve resistance to cryptanalysis.
The TRILL BFD Echo frame's protocol-specific data area is entirely opaque and left to the originating RBridge's discretion. It is suggested to include System IDs, neighbor System ID, a session identifier, sequence count, and a MAC to allow the originator to authenticate the returned frame and confirm which neighbor echoed it.
TRILL IS-IS Hellos have a minimum failure-detection time of one second and are multicast-only, so some failures (e.g., those that affect unicast while passing multicast) cannot be detected via Hellos. BFD provides a low-overhead mechanism for rapid continuity testing on the TRILL data plane between neighbor RBridges.
If link aggregation (IEEE 802.1AX) presents a single logical interface to TRILL IS-IS, only a single TRILL BFD session can be established to another RBridge over that logical interface. Lower-layer OAM may run separately on individual aggregation components.
TRILL BFD provides OAM for the TRILL data plane, operating above link-technology-specific OAM such as Continuity Fault Management on Ethernet links. Coordination between link-layer OAM and TRILL BFD is outside the scope of this document.
Asynchronous and demand modes MUST be supported for BFD over TRILL. Implementation of the TRILL BFD Echo function is optional and can only be used for single-hop sessions.
Before generic BFD processing, received TRILL BFD Control frames SHOULD be checked: frames with the M bit set in the TRILL Header MUST be discarded (multi-destination BFD not yet defined). For one-hop (MH=0), the received hop count must be 0x3F (or 0x3E if already decremented); for multi-hop (MH=1), the hop count must not be less than a configurable value defaulting to 0x30.
If IS-IS authentication is in effect between neighbor RBridges, TRILL BFD Control frames sent between those RBridges MUST use BFD Meticulous Keyed SHA1 authentication (RFC 5880) by default, unless configured otherwise.
On returned TRILL BFD Echo frames, the M bit MUST be checked and the frame discarded if set. The hop count as received MUST be 0x3E (or 0x3D if already decremented), and the Channel Header MH bit MUST be one; otherwise, the frame is discarded.
One-hop TRILL BFD Control frames are sent between neighbor RBridges only if TRILL IS-IS has detected bidirectional connectivity (adjacency in 2-Way or Report state per RFC 7177) and both RBridges indicate BFD support via the BFD-Enabled TLV (RFC 6213).
One-hop TRILL BFD Control frames SHOULD be sent with high priority: Inner.VLAN tag priority 7, queued as maximum priority, and Outer.VLAN tag (if present) also set to priority 7.
The TRILL Header hop count in outgoing BFD packets MUST be set to the maximum value of 0x3F. For a single-hop session, if the received hop count is less than 0x3F and the RBridge Channel Header MH flag is zero, the packet MUST be discarded to prevent spoofing attacks.
TRILL BFD Echo frames SHOULD only be sent when: a TRILL BFD Control session is established, the peer indicates Echo support, the adjacency is in Report state, and the originator wishes to use this optional feature.
Within an RBridge campus, there is no more than one TRILL BFD Control session from RB1 to RB2 per RB1 TRILL port. Both sides of a session MUST take the Active role (sending initial BFD Control packets with a zero Your Discriminator), and any BFD packet from the remote machine with a zero Your Discriminator MUST be associated with the session bound to that remote system and interface.
A TRILL BFD Echo frame is a unicast RBridge Channel frame with both ingress and egress nicknames set to a nickname of the originating RBridge, causing normal TRILL forwarding to return it via the immediate neighbor. The RBridge Channel OAM protocol number for BFD Echo is 0x003.
BFD Echo authentication uses a separately derived key: HMAC-SHA256('TRILL BFD Echo' | originPortID | originSysID, IS-IS-shared-key), using different keying material from BFD Control authentication to limit key exposure.
The default BFD authentication key between neighbor RBridges is derived as HMAC-SHA256('TRILL BFD Control' | originPortID | originSysID, IS-IS-shared-key), where the 17-byte ASCII string is concatenated with the 2-byte Port ID and 6-byte IS-IS System ID in network byte order. Auth Type is 5 and Auth Len is 28.
TRILL BFD Control frames are unicast TRILL RBridge Channel frames carrying the BFD Control protocol-specific data as defined in Section 4.1 of RFC 5880. The RBridge Channel Protocol value for BFD Control is 0x002.
IANA allocated two RBridge Channel protocol numbers from the Standards Action range: BFD Control = 0x002 and BFD Echo = 0x003.
BFD over TRILL provides authentication via the BFD authentication facility but no encryption. Failure to check the TRILL Header M bit in BFD Control frames enables denial-of-service attacks using bogus multi-destination frames. Failure to check hop counts makes BFD Control frame spoofing easier; for stronger protection, BFD Authentication (RFC 5880) should be used.