Tip

This is the documentation for the 20.10 version. Looking for the documentation of the latest version? Have a look here.

BFD Session Authentication

TNSR supports SHA1 and meticulous SHA1 authentication. In either mode, a secret key is used to create a hash of the outgoing packets. The key itself is not sent in the packets, only the hash and the ID of the key.

A sequence number is used to help avoid replay attacks. With SHA1, this sequence number is incremented occasionally. With meticulous SHA1, the sequence number is incremented on every packet.

The receiving peer will check for a key matching the given ID and then compare a hash of the BFD payload against the hash sent by the peer. If it matches and the sequence number is valid, the packet is accepted.

Define BFD Keys

There are two keys defined for each BFD session:

conf-key-id:

The Configuration Key ID. An unsigned 32-bit integer which identifies an internal unique key in TNSR. Neither the key itself nor this ID are ever communicated to peers. The secret component of this key must be generated outside of TNSR. It is a group of 1 to 20 hex pair values, such as 4a40369b4df32ed0652b548400.

bfd-key-id:

The BFD key ID. An unsigned 8-bit integer (0-255) which is the key ID carried in BFD packets, used for verifying authentication.

Warning

Both conf-key-id and bfd-key-id must be specified, or neither can be present.

To define a new configuration key ID:

tnsr(config)# bfd conf-key-id <conf-key-id>
tnsr(config-bfd-key)# authentication type (keyed-sha1|meticulous-keyed-sha1)
tnsr(config-bfd-key)# secret < (<hex-pair>)[1-20] >

For example:

tnsr(config)# bfd conf-key-id 123456789
tnsr(config-bfd-key)# authentication type meticulous-keyed-sha1
tnsr(config-bfd-key)# secret 4a40369b4df32ed0652b548400

Setup BFD Authentication

Authentication will only be active if both the bfd-key-id and conf-key-id are defined for a BFD session.

An additional delayed keyword is also supported for BFD session which tells BFD to hold off any authentication action when receiving BFD messages until a peer attempts to authenticate or uses new credentials.

Warning

Only one host can have the delayed option enabled, otherwise credentials will never update as both peers will be waiting on the other one to act first.

Warning

BFD implementations vary, so authentication changes may disrupt live BFD sessions. The best practice to avoiding disruption when operating with third party BFD implementations is to set delayed on the TNSR side.

When adding authentication to an existing BFD session, or changing active authentication settings, make the changes first on the node with delayed set then configure the peer to match.

To activate authentication, add the chosen identifiers to a BFD session:

tnsr(config)# bfd session <bfd-session>
tnsr(config-bfd)# bfd-key-id <bfd-key-id>
tnsr(config-bfd)# conf-key-id <conf-key-id>
tnsr(config-bfd)# delayed (true|false)
tnsr(config-bfd)# exit

For example:

tnsr(config)# bfd session otherrouter
tnsr(config-bfd)# bfd-key-id 123
tnsr(config-bfd)# conf-key-id 123456789
tnsr(config-bfd)# delayed false
tnsr(config-bfd)# exit

View BFD Keys

To view a list of keys and their types, use the show bfd keys command:

tnsr# show bfd keys
Conf Key  Type                  Use Count
--------- --------------------- ----------
123456789 meticulous-keyed-sha1 1
234567890 keyed-sha1            0

To view only one specific key, pass its ID to the same command:

tnsr# show bfd keys conf-key-id 123456789
Conf Key  Type                  Use Count
--------- --------------------- ----------
123456789 meticulous-keyed-sha1 1