Detections
Analytics

4.6.1 Ensure BFD Authentication is Set

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

BFD Peers should be authenticated.

 Rationale:
 Bidirectional Forwarding Detection (BFD) is a Forwarding Plane feature which allows more rapid detection of a failed neighbor then can be achieved through a routing protocols' normal detection mechanisms, providing faster reconvergence.
 If no authentication was used an attacker may replay or spoof BFD messages to destabilize a network and/or prevent proper reconvergence resulting in a Denial of Service. Several authentication mechanisms are supported for BFD ranging from plain text password, which should not be used, to meticulously keyed SHA1.
 The latter provides the strongest hashing algorithm and best replay protection, with the sequence number being updated on each packet, and it is this mechanism that should be used in most cases.
 However, if None Stop Routing (NSR) features are required; meticulously keyed SHA1 or MD5 should not be used as the BFD Sessions using these algorithms may fail when switching to the Backup Routing Engine.
 Both BFD peers must be configured with the same keys and method, otherwise the BFD link may be declared down resulting in a reconvergence. Because it is not possible to configure both ends of an existing BFD link simultaneously you may need to use Loose Authentication Checking as a transitional step by configuring the loose-check option.

 NOTE: BFD does not appear to be configured on the target. This check is not applicable.

Solution

If you have deployed BFD, authentication can be configured by issuing the following commands.
 First set the authentication algorithm and keychain from the appropriate [.* bfd-liveness-detection] hierarchy, in this example we are configuring BFD Authentication for OSPF Neighbors on Interface Ge-0/0/0.0:
 [edit protocols ospf interface ge-0/0/0.0 bfd-liveness-detection]
 user@host#set authentication algorithm <algorithm>
 user@host#set authentication key-chain <key-chain>
 Where:
 - <algorithm> is either keyed-md5, keyed-sha-1, meticulous-keyed-md5or meticulous-keyed-sha-1, which is preferred but is not compatible with NSR and other failover options.
 - <key-chain> is the name of a configured key-chain (see below).
 If a Key Chain is not already defined, you should create one by issuing the following command at the [edit security authentication-key-chains] hierarchy:
 [edit security authentication-key-chains]
 user@host#set key-chain <key-chain> key <key number> secret <key>
 Where:
 - <key-chain> is the name of the key-chain already configured for the BFD session
 - <key number> is the number to identify this key, used for key rollover
 - <key> is the Shared Secret Key
 The <algorithm> and <key> must be the same on all devices which will use the BFD session being configured.
 If the BFD Session is already in use, setting Authentication on one side before the other will cause the BFD Session (and the associated routes or adjacencies) to be declared down resulting in loss of traffic. To aide in rollout of BFD Authentication, JUNOS Devices can operate in a 'Loos Authentication Check' mode, whereby they will send Authentication information, but will not reject unauthenticated messages.
 This should be used in transition only and can be configured with the following command from the same [.* bfd-liveness-detection] hierarchy:
 [edit protocols ospf interface ge-0/0/0.0 bfd-liveness-detection]
 user@host#set authentication loose-check
 BFD may be configured at a wide variety of configuration hierarchies, for different Protocols, Routing Instances or even for Static Routes. The bfd-liveness-detection hierarchy is the same at each level it is used, so the Remediation Process is the same and should be applied at each hierarchy indicated in the Audit Procedure.

 Impact:
 BFD Authentication must be configured to use the same Key and Algorithm on all neighbors/peers with which the session will be used. A mismatch will result in the BFD session failing and related routes being declared unreachable.
 BFD Authentication with meticulous-keyed-sha-1 and meticulous-keyed-md5 algorithms should not be used in conjunction with NSR and GRES. Fail over between Routing Engines will cause Authentication to fail.

 Default Value:
 No BFD is configured by default.

See Also

https://workbench.cisecurity.org/files/2278

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6, CSCv7|11

Plugin: Juniper

Control ID: cfc6751c889953c8ddac40fb17b9a2a9274a688a1cb8393a5082c071ea432acf