Require BFD Authentication (where BFD is used) (Level 2, Scorable)

Description:

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.

NOTE – 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.

NOTE - Both BFD peers must be configured with the same keys otherwise the BFD link may be declared down resulting in a reconvergence. Because it is not possible to configure both ends

62 | P a g e

of an existing BFD link simultaneously you may need to use Loose Authentication Checking as a transitional step.

Remediation:

If you have deployed BFD, authentication can be configured by issuing the following commands.

First set the authentication algorithm and keychain from the [edit protocols <routing protocol> interface <interface name> bfd-liveness-detection] hierarchy:

[edit protocols <routing protocol> interface <interface name> bfd- liveness-detection]

user@host#set authentication algorithm <algorithm> user@host#set authentication keychain <key chain name>

<algorithm> can be one of keyed-md5, keyed-sha-1, meticulous-keyed-md5 or

meticulous-keyed-sha-1. The final option is recommended for its additional

robustness, but the other options with the exception of simple-password may also be used where NSR or compatibility requirements dictate.

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 name> key <key number> secret <key>

The <key number> parameter needs to be the same across all routers in the area and is there to provide a method for transitioning from old to new keys.

Audit:

Enter the following command from the [edit protocols <routing protocol> interface <interface name> bfd-liveness-detection] hierarchy:

[edit protocols <routing protocol> interface <interface name> bfd- liveness-detection]

user@host#show | match authentication | except loose | count

The above command should return 2.

Default Value:

63 | P a g e

References:

1. Overview of BFD Authentication for OSPF, JUNOS Software Routing Protocols Configuration Guide, Juniper Networks

4.7 <Protocol> bfd-liveness-detection

Some security settings are configured in exactly the same way across all supported routing protocols. One of these is Bidirectional Forwarding Detection (BFD), which is configured under the [edit protocols <protocol> bfd-liveness-detection] hierarchy where < protocol> is one of isis, bgp, ospf, static , rip, pim or another protocol with BFD support.

4.7.1 Require BFD Authentication (where BFD is used) (Level 2, Scorable)

Description:

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.

NOTE – 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.

NOTE - Both BFD peers must be configured with the same keys 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.

Remediation:

If you have deployed BFD, authentication can be configured by issuing the following commands.

First set the authentication algorithm and keychain from the [edit protocols <protocol> interface <interface name> bfd-liveness-detection] hierarchy:

64 | P a g e

[edit protocols <protocol> interface <interface name> bfd-liveness- detection]

user@host#set authentication algorithm <algorithm> user@host#set authentication keychain <key chain name>

<algorithm> can be one of keyed-md5, keyed-sha-1, meticulous-keyed-md5 or

meticulous-keyed-sha-1. The final option is recommended for its additional

robustness, but the other options with the exception of simple-password may also be used where NSR or compatibility requirements dictate.

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 name> key <key number> secret <key>

The <key number> parameter needs to be the same across all routers in the area and is there to provide a method for transitioning from old to new keys.

Audit:

Enter the following command from the [edit protocols <protocol> interface <interface name> bfd-liveness-detection] hierarchy:

[edit protocols <protocol> interface <interface name> bfd-liveness- detection]

user@host#show | match authentication | except loose | count

The above command should return 2.

Default Value:

No BFD is configured by default.

References:

1. Overview of BFD Authentication for OSPF, JUNOS Software Routing Protocols Configuration Guide, Juniper Networks