```
```

```
```
mjethanandani@gmail.com

```
```

```
```
Cisco Systems, Inc
170 W. Tasman Drive
San Jose
CA
`95070`

USA
agarwaso@cisco.com
www.cisco.com
O3b Networks
```
```

```
```
mishra.ashesh@gmail.com

```
```

```
```
Ciena Corporation
3939 North First Street
San Jose
CA
`95134`

USA
ankurpsaxena@gmail.com
Network RADIUS SARL
100 Centrepointe Drive #200
Ottowa
ON
`K2G 6B1`

Canada
aland@freeradius.org
This document describes a security enhancement for the sequence
number used in BFD control packets. This document updates RFC 5880.

```
```
BFD section 6.7 describes the use of
monotonically incrementing 32-bit sequence numbers for use in
authentication of BFD packets. While this method protects against simple
replay attacks, the monotonically incrementing sequence numbers are
predictable and vulnerable to more complex attack vectors. This document
proposes the use of non-monotonically-incrementing sequence numbers in
the BFD authentication section to enhance the security of BFD sessions.
Specifically, the document presents a method to generate pseudo-random
sequence numbers on the frame by algorithmically hashing monotonically
increasing sequence numbers. Since the monotonically increasing sequence
number does not appear on the wire, it is difficult for a third party to
launch a replay attack.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 .
Instead of inserting a monotonically, sometimes occasionally,
increasing sequence number in BFD control packets, the ciphertext result
from a symmetric key algorithm operation (Symmetric-key algorithms
require both the sender and the recipient of a message to have the same
shared secret key) is inserted. The result is computed, using a shared
key, on the sequence number. That ciphertext result is then inserted
into the sequence number field of the packet. In case of BFD
Authentication , the sequence number used in computing an
authenticated packet would be this new computed ciphertext. Even though
the BFD
Authentication sequence number is independent of this
enhancement, it would benefit by using the computed ciphertext.
As currently defined in BFD , a BFD
packet with authentication will undergo the following steps, where:
[O]: original RFC 5880 packet with monotonically increasing sequence
number
[S]: pseudo random sequence number
[A]: Authentication
This document proposes that for enhanced security in sequence number
encoding, the sender would identify a symmetric key algorithm that would
create a 32 bit ciphertext. The symmetric key is provisioned securely on
the sender and receiver of the BFD session. The mechanism of
provisioning such a key is outside the scope of this document. This key
SHOULD be different from the symmetric key used to to authenticate the
packet. Instead of sending the sequence number, the sender encrypts the
sequence number using it as input to the symmetric algorithm to produce
the ciphertext, which is then inserted in place of the sequence
number.
Upon receiving the BFD Control packet, the receiver decrypts the
ciphertext using the same provisioned shared key to produce the received
sequence number. It compares the received sequence number against the
expected sequence number. The mechanism used for comparing is an
implementation detail (implementations may pre-calculate the expected
sequence number, or decrypt the received sequence number before
comparing against expected value). To tolerate dropped frames, the
receiver MUST compare the received sequence number against the current
expected sequence number (previous received sequence number + 1) and N
subsequent expected sequence numbers (where N is greater than or equal
to the detect multiplier). Note: The first sequence number can be
obtained using the same logic as used in determining Local Discriminator
value for the session or by using a random number.
K: symmetric key
S: sequence number
S': encrypted sequence number OR ciphertext result
O: original RFC 5880 packet with monotonically increasing sequence
number
f(S, K) = S', where f is a symmetric encryption algorithm
f(S', K) = S, where f is a symmetric decryption algorithm
The above diagram describes how the sender encrypts and receiver
decrypts the sequence number. The sender starts by taking the
monotonically increasing (but non linear) sequence number and encrypting
it using a symmetric encryption algorithm. The resulting ciphertext
replaces the sequence number. As per BFD ,
it then calculates the hash for the entire packet and appends the hash
value to the end of the packet, before transmitting it.
The receiver hashes the entire packet as part of receiver
authentication. On successful authentication, it decrypts the ciphertext
with the same key used to encrypt it, in order to obtain the original
sequence number. If it is greater than the previously received
monotonically increasing sequence number, then the receiver knows it's a
valid sequence number.
Under this proposal, every packet’s sequence number is encoded
in ciphertext. Therefore, there is some impact on the system and its
performance while encryption/decryption. As security measures go, this
enhancement greatly increases the security of the packet with or without
authentication of the entire packet.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
In a symmetric key algorithm, the key is shared between the two systems.
Distribution of this key to all the systems at the same time can be quite a
cumbersome task. BFD sessions running a fast rate will require these keys to
be refreshed often, which poses a further challenge. Therefore, it is difficult
to change the keys during the operation of a BFD session without affecting the
stability of the BFD session. Therefore, it is recommended to administratively
disable the BFD session before changing the keys. If the keys are not changed
frequently, an attacker can try to guess the key to launch a replay attack.
This method allows the BFD end-points to detect a malicious packet (the decrypted
sequence number will not be in sequence). The behavior of the session, when such a
packet is detected, is based on the implementation. A flood of such malicious packets
may cause a BFD session to be operationally down.
The symmetric algorithm and key size will determine the difficulty for an attacker
to decipher the key from the transmitted BFD frames. The sequential nature of the
payload (sequence numbers) simplifies the decoding of the key. It is, therefore,
recommended to use longer keys or more secure symmetric algorithms.
The authors would like to thank Jeff Hass and Reshad Rahman for their reviews
of and suggestions for the document.

```
```