Secure BFD Sequence
NumbersCisco Systems, Inc170 West Tasman DriveSan JoseCA95070USAmjethanandani@gmail.comCisco Systems, Inc170 W. Tasman DriveSan JoseCA95070USAagarwaso@cisco.comwww.cisco.comO3b Networksmishra.ashesh@gmail.comCiena Corporation3939 North First StreetSan JoseCA95134USAankurpsaxena@gmail.comNetwork RADIUS SARL100 Centrepointe Drive #200OttowaONK2G 6B1Canadaaland@networkradious.comThis document describes a security enhancements for the BFD
packet’s sequence number.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.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
BFD authentication TLVs 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. Further security may be introduced by
resetting un-encrypted sequence to a random value when the 32-bit
sequence number rolls-over.Instead of monotonically increasing the sequence number or even
occasionally monotonically increasing the sequence number, the next
sequence number is generated by computing a hash on what would have been
the next sequence number using a shared key. That computed hash 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 hash. Even though the
BFD
Authentication sequence number is independent of this
enhancement, it would benefit by using the computed hash.A normal BFD packet with authentication will undergo the following
steps, where:[O]: original RFC 5880 packet with monotonically increasing sequence
number[S]: psuedo random sequence number[A]: AuthenticationIn order to encode a sequence number, the sender would identify a
hash algorithm (symmetric) that would create a 32 bit hash. The hashing
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 draft. Instead of using the sequence number, the sender encodes
the sequence number with the hashing key to produce a hash.Upon receiving the BFD Control packet, the receiver 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 hashed 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 seuqence
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 the My Discriminator value.k: hashing keys: sequence numberO: original RFC 5880 packet with monotonically increasing sequence
numberR: remainder of packetH1: hash of sH2: hash of entire packetA: H2 + insertion in packethash(s, k) = H1hash((H1 + R), k) = H2hash’((Packet - H2), k) == H2 ? Good packet : bad packethash’(H1, k) == s ? Good sequence number : bad sequence
numberUnder this proposal, every packet’s sequence number is encoded
within a hash. Therefore there is some impact on the system and its
performance while encoding/decoding the hash. 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.