< draft-ietf-bfd-secure-sequence-numbers-08.txt   draft-ietf-bfd-secure-sequence-numbers-09.txt >
Network Working Group M. Jethanandani Network Working Group M. Jethanandani
Internet-Draft Kloud Services Internet-Draft Kloud Services
Updates: 5880 (if approved) S. Agarwal Updates: 5880 (if approved) S. Agarwal
Intended status: Standards Track Cisco Systems, Inc Intended status: Standards Track Cisco Systems, Inc
Expires: September 9, 2021 A. Mishra Expires: 30 September 2022 A. Mishra
O3b Networks O3b Networks
A. Saxena A. Saxena
Ciena Corporation Ciena Corporation
A. Dekok A. Dekok
Network RADIUS SARL Network RADIUS SARL
March 8, 2021 29 March 2022
Secure BFD Sequence Numbers Secure BFD Sequence Numbers
draft-ietf-bfd-secure-sequence-numbers-08 draft-ietf-bfd-secure-sequence-numbers-09
Abstract Abstract
This document describes a security enhancement for the sequence This document describes two new BFD Authentication mechanism,
number used in BFD control packets. This document updates RFC 5880. Meticulous Keyed ISAAC, and Meticulous Keyed FNV1A. These mechanisms
can be used to authenticate BFD packets, and secure the sequence
number exchange, with less CPU time cost than using MD5 or SHA1, with
the tradeoff of decreased security. This document updates RFC 5880.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2021. This Internet-Draft will expire on 30 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Theory of operation . . . . . . . . . . . . . . . . . . . . . 2 3. Meticulous Keyed ISAAC . . . . . . . . . . . . . . . . . . . 3
4. Impact of using a hash . . . . . . . . . . . . . . . . . . . 4 4. Meticulous Keyed FNV1A . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Seeding and Operation of ISAAC . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Secret Key . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Seeding ISAAC . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 5 6. Meticulous Keyed ISAAC Authentication . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 5 7. Meticulous Keyed FNV1A Authentication . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Calculation of the FNV-1a Digest . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Re-Use of keys . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
BFD [RFC5880] section 6.7 describes the use of monotonically BFD [RFC5880] defines a number of authentication mechanisms,
incrementing 32-bit sequence numbers for use in authentication of BFD including Simple Password (Section 6.7.2), and various other methods
packets. While this method protects against simple replay attacks, based on MD5 and SHA1 hashes. The benefit of using cryptographic
the monotonically incrementing sequence numbers are predictable and hashes is that they are secure. The downside to cryptographic hashes
vulnerable to more complex attack vectors. This document proposes is that they are expensive and time consuming on resource-constrained
the use of non-monotonically-incrementing sequence numbers in the BFD hardware.
authentication section to enhance the security of BFD sessions.
Specifically, the document presents a method to generate pseudo- When BFD packets are unauthenticated, it is possible for an attacker
random sequence numbers on the frame by algorithmically hashing to forge, modify, and/or replay packets on a link. These attacks
monotonically increasing sequence numbers. Since the monotonically have a number of side effects. They can cause parties to believe
increasing sequence number does not appear on the wire, it is that a link is down, or they can cause parties to believe that the
difficult for a third party to launch a replay attack. link is up when it is, in fact, down. The goal of these methods is
to prevent spoofing of the BFD session by someone who could guess the
next sequence number. We therefore define simple and fast Auth Type
methods which allow parties to detect and prevent both spoofed
sequence numbers, and spoofed packets.
This document proposes the use of Authentication methods which
provides meticulous keying, but which have less impact on resource
constrained systems. The algorithms chosen are ISAAC [ISAAC], which
is a fast cryptographic random number generator, and FNV-1a FNV1A
[FNV1A] which is a fast (but non-cryptographic) hash. ISAAC has been
subject to significant cryptanalysis in the past thirty years, and
has not yet been broken. Similarly, FNV-1a is fast, and while not
cryptographically secure, it is has good hashing properties.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Theory of operation 3. Meticulous Keyed ISAAC
Instead of inserting a monotonically, sometimes occasionally, If the Authentication Present (A) bit is set in the header, and the
increasing sequence number in BFD control packets, the ciphertext State (Sta) field equals 3 (Up), and the Authentication Type field
result from a symmetric key algorithm operation (Symmetric-key contains TB1 (Meticulous Keyed ISAAC), the Authentication Section has
algorithms require both the sender and the recipient of a message to the following format:
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
[I-D.ietf-bfd-optimizing-authentication], the sequence number used in
computing an authenticated packet would be this new computed
ciphertext. Even though the BFD Authentication
[I-D.ietf-bfd-optimizing-authentication] sequence number is
independent of this enhancement, it would benefit by using the
computed ciphertext.
As currently defined in BFD [RFC5880], a BFD packet with 0 1 2 3
authentication will undergo the following steps, where: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth-Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[O]: original RFC 5880 packet with monotonically increasing sequence Auth Type
number The Authentication Type, which in this case is TB1 (Meticulous
Keyed ISAAC). If the State (Sta) field value is not 3 (Up), then
Meticulous Keyed ISAAC MUST NOT be used.
[S]: pseudo random sequence number Auth Len
[A]: Authentication The length of the Authentication Section, in bytes. For
Meticulous Keyed ISAAC authentication, the length is 16.
Sender Receiver Auth Key ID
[O] [S] [A] ------------- [A] [S] [O] The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously.
This document proposes that for enhanced security in sequence number Reserved
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 This byte MUST be set to zero on transmit, and ignored on receipt.
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. BFD
[RFC5880] mentions that received sequence number should be between
(bfd.RcvAuthSeq(+1) to bfd.RcvAuthSeq+(3*Detect Mult) inclusive.
Note: The first sequence number can be obtained using the same
principles stated in BFD [RFC5880] i.e. (using bfd.AuthSeqKnown and
bfd.RcvAuthSeq)
K: symmetric key
S: sequence number Sequence Number
S': encrypted sequence number OR ciphertext result The sequence number for this packet. For Meticulous Keyed ISAAC
Authentication, this value is incremented for each successive
packet transmitted for a session. This provides protection
against replay attacks.
O: original RFC 5880 packet with monotonically increasing sequence Seed
number
f(S, K) = S', where f is a symmetric encryption algorithm A 32-bit (4 octet) seed which is used in conjunction with the
shared key in order to configure and initialize the ISAAC pseudo-
random-number-generator (PRNG). It is used to identify and
distinguish "streams" of random numbers which are generated by
ISAAC.
f(S', K) = S, where f is a symmetric decryption algorithm Auth-Key
Sender Receiver This field carries the 32-bit (4 octet) ISAAC output which is
associated with the Sequence Number. The ISAAC PRNG MUST be
configured and initialized as given in section TBD.
[O] [S'] [A] -------- [A] [S] [O] Note that the Auth-Key here does not include any summary or hash
of the packet. The packet itself is completely unauthenticated.
The above diagram describes how the sender encrypts and receiver The purpose of this method is to secure the sequence number exchange,
decrypts the sequence number. The sender starts by taking the and to both detect and prevent spoofing of sequence numbers. In some
monotonically increasing (but non linear) sequence number and cases, it is acceptable to not authenticate the entire packet, in
encrypting it using a symmetric encryption algorithm. The resulting which case this method may be used.
ciphertext replaces the sequence number. As per BFD [RFC5880], 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 When the receiving party receives a BFD packet with an expected
authentication. On successful authentication, it decrypts the sequence number, and the correct corresponding ISAAC output, it knows
ciphertext with the same key used to encrypt it, in order to obtain that only the authentic sending party could have sent that message.
the original sequence number. If it is greater than the previously The sending party is therefore alive/up, and intended to send the
received monotonically increasing sequence number, then the receiver message.
knows it's a valid sequence number.
4. Impact of using a hash While the rest of the contents of the BFD packet are unauthenticated
and may be modified by an attacker, the same is true of stronger Auth
Types, such as MD5 or SHA1. The Auth Type methods are not designed
to prevent such attacks. Instead, they are designed to prevent an
attacker from spoofing identities, and an attacker from artificially
keeping a session "Up".
Under this proposal, every packet's sequence number is encoded in 4. Meticulous Keyed FNV1A
ciphertext. Therefore, there is some impact on the system and its
performance while doing encryption/decryption. As security measures
go, this enhancement greatly increases the security of the packet
with or without authentication of the entire packet.
5. IANA Considerations If the Authentication Present (A) bit is set in the header, and the
State (Sta) field equals 3 (Up), and the Authentication Type field
contains TB2 (Meticulous Keyed FNV1A), the Authentication Section has
the following format:
This document makes no request of IANA. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
The Authentication Type, which in this case is TB2 (Meticulous
Keyed FNV1A). If the State (Sta) field value is not 3 (Up), then
Meticulous Keyed FNV1A MUST NOT be used.
Auth Len
The length of the Authentication Section, in bytes. For
Meticulous Keyed FNV1A authentication, the length is 16.
Auth Key ID
The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously.
Reserved
This byte MUST be set to zero on transmit, and ignored on receipt.
Sequence Number
The sequence number for this packet. For Meticulous Keyed FNV1A
Authentication, this value is incremented for each successive
packet transmitted for a session. This provides protection
against replay attacks.
Seed
A 32-bit (4 octet) seed which is used in conjunction with the
shared key in order to configure and initialize the ISAAC PRNG.
It is also used to identify and distinguish "streams" of random
numbers which are generated by ISAAC.
Digest
This field carries the 32-bit (4 octet) FNV1A digest associated
with the Sequence Number. The ISAAC PRNG MUST be configured and
initialized as given in section TBD.
Note that the ISAAC PRNG output is still used with this
authentication type. The FNV1A hash is fast, but it is not
secure. In order to reach an acceptable level of security with
FNV1A, we use ISAAC to generate secure per-packet "signing keys".
These per-packet keys are then used with FNV1A in order to perform
a keyed of hash the packet, and therefore create the Digest.
5. Operation
BFD requires fast and reasonably secure authentication of messages
which are exchanged. Methods using MD5 or SHA1 are CPU intensive,
and can negatively impact systems with limited CPU power.
We use ISAAC here as a way to generate an infinite stream of pseudo-
random numbers. With Meticulous Keyed ISAAC, these numbers are used
as a signal that the sending party is authentic. That is, only the
sending party can generate the numbers. Therefore if the receiving
party sees a correct number, then only the sending party could have
generated that number. The sender is therefore authentic, even if
the packet contents are not necessarily trusted.
Note that since the packets are not signed with this authentication
type, the Meticulous Keyed ISAAC method MUST NOT be used to signal
BFD state changes. For BFD state changes, and a more optimized way
to authenticate packets, please refer to BFD Authentication
[I-D.ietf-bfd-optimizing-authentication]. Instead, the packets
containing Meticulous Keyed ISAAC are only a signal that the sending
party is still alive, and that the sending party is authentic. That
is, these Auth Type methods must only be used when
bfd.SessionState=Up, and the State (Sta) field equals 3 (Up).
If slightly more security is desired, the packets can be
authenticated via the Meticulous Keyed FNV1A method. This method is
similar to the Meticulous Keyed ISAAC authentication type, except
that the FNV-1A hash function is used to hash a combination of the
packet, and per-packet ISAAC pseudo-random number. If the receiving
party is able to validate the hash, then the receiver knows both that
the sender is authentic, and that the packet contents have likely not
been modified.
As this hash function is not very secure, this method can be used
only in situations where the Meticulous Keyed ISAAC method can be
used. The Meticulous Keyed FNV1A method MUST NOT be used to signal
BFD state changes.
5.1. Seeding and Operation of ISAAC
The ISAAC PRNG state is initialized with the 32-bit Seed, followed by
the secret key, and then the rest of the state is filled with zeros.
The internal state of ISAAC is 1024 bytes, so the secret key is
limited to 1020 bytes in length.
The origin of the Seed field is discussed later in this document.
For now, we note that each time a new Seed is used, the
bfd.XmitAuthSeq value MUST be set to zero.
Once the state has been initialized, the standard ISAAC initial
mixing function is run. Once his operation has been performed, ISAAC
will be able to produce 256 random numbers at near-zero cost. When
all 256 numbers are consumed, the ISAAC mixing function is run, which
then results in another set of 256 random numbers
ISAAC can be thought of here as producing an infinite stream of
numbers, based on a secret key, where the numbers are produced in
"pages" of 256 32-bit vlaues. This property of ISAAC allows for
essentially zero-cost "seeking" within a page. The expensive
operation of mixing is performed only once per 256 packets, which
means that most BFD packet exchanges can be fast and efficient.
The Sequence number is used to "seek" within a the stream of 32-bit
numbers produced by ISAAC. The sending party increments the Sequence
Number on every packet sent, to indicate to the receiving party where
it is in the sequence.
The receiving party can then look at the Sequence Number to determine
which particular PRNG value is being used in the packet. The
Sequence Number thus permits the two parties to synchronise if/when a
packet or packets are lost. Incrementing the Sequence Number for
every packet also prevents the re-use of any individual pseudo-random
number which was derived from ISAAC.
The Sequence Number can increment without bounds, though it can wrap
once it reaches the limit of the 32-bit counter field. ISAAC has a
cycle length of 2^8287, so there is no issue with using more than
2^32 values from it.
The result of the above operation is an infinite series of numbers
which are unguessable, and which can be used to authenticate the
sending party.
5.2. Secret Key
For interoperability, the management interface by which the key is
configured MUST accept ASCII strings, and SHOULD also allow for the
configuration of any arbitrary binary string in hexadecimal form.
Other configuration methods MAY be supported.
The secret Key is mixed with the Seed before being used in ISAAC. If
instead ISAAC was initialized without a Seed, then an attacker could
pre-compute ISAAC states for many keys, and perform an off-line
dictionary attack. The addition of the Seed makes these attacks
infeasable.
As a result, it is safe to use the same secret Key for the Auth Types
defined here, and also for other Auth Types.
5.3. Seeding ISAAC
The value of the Seed field SHOULD be derived from a secure source.
Exactly how this can be done is outside of the scope of this
document.
The Seed value SHOULD remain the same for the duration of a BFD
session. The Seed value MAY change when the BFD state changes.
If the sending party changes its Seed value, bfd.XmitAuthSeq value
MUST be set to zero, otherwise the receiving party would be unable to
synchronize its sequence of numbers produced by the ISAAC generator.
There is no way to signal or negotiate Seed changes. The receiving
party MUST remember the current Seed value, and then detect if the
Seed changes. Note that the Seed value MUST NOT change unless
sending party has signalled a BFD state change with a a packet that
is authenticated using a more secure Auth Type method.
6. Meticulous Keyed ISAAC Authentication
In this method of authentication, one or more secret keys (with
corresponding key IDs) are configured in each system. One of the
keys is used to seed the ISAAC PRNG. The output of ISAAC (I) is used
to signal that the sender is authentic. To help avoid replay
attacks, a sequence number is also carried in each packet. For
Meticulous Keyed ISAAC, the sequence number is incremented on every
packet.
The receiving system accepts the packet if the key ID matches one of
the configured Keys, the Auth-Key derived from the selected Key,
Seed, and Sequence Number matches the Auth-Key carried in the packet,
and the sequence number is strictly greater than the last sequence
number received (modulo wrap at 2^32)
Transmission Using Meticulous Keyed ISAAC Authentication
The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC).
The Auth Len field MUST be set to 16. The Auth Key ID field MUST
be set to the ID of the current authentication key. The Sequence
Number field MUST be set to bfd.XmitAuthSeq.
The Seed field MUST be set to the value of the current seed used
for this sequence.
The Auth-Key field MUST be set to the output of ISAAC, which
depends on the secret Key, the current Seed, and the Sequence
Number.
For Meticulous Keyed ISAAC, bfd.XmitAuthSeq MUST be incremented on
each packet, in a circular fashion (when treated as an unsigned
32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by
more than one for a packet.
Receipt using Meticulous Keyed ISAAC Authentication
If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (TBD2 for
Meticulous Keyed ISAAC), then the received packet MUST be
discarded.
If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 16, the packet MUST be
discarded.
If the Seed field does not match the current Seed value, the
packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Meticulous Keyed FNV1A, if the sequence number lies outside of the
range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult)
inclusive (when treated as an unsigned 32-bit circular number
space) the received packet MUST be discarded.
Calculate the current expected output of ISAAC, which depends on
the secret Key, the current Seed, and the Sequence Number. If the
value does not matches the Auth-Key field, then the packet MUST be
discarded.
Note that in some cases, calculating the expected output of ISAAC
will result in the creation of a new "page" of 256 numbers. This
process will irreversible, and will destroy the current "page".
As a result, if the generation of a new output will create a new
"page", the receiving party MUST save a copy of the entire ISAAC
state before proceeding with this calculation. If the outputs
match, then the saved copy can be discarded, and the new ISAAC
state is used. If the outputs do not match, then the saved copy
MUST be restored, and the modified copy discarded.
7. Meticulous Keyed FNV1A Authentication
Where slightly more security is needed, the sender can use Meticulous
Keyed FNV1A. In this method, each packet is signed with a non-
cryptographic hash, FNV-1a [FNV1A]. This hash is reasonably fast, it
has good distribution, and collisions are rare. However, it is
linear, and potentially reversible. In addition, its output is only
32 bits, and it is not cryptographically strong.
In this methods of authentication, one or more secret keys (with
corresponding key IDs) are configured in each system. One of the
keys is included in an FNV1A digest calculated over the outgoing BFD
Control packet, but the Key itself is not carried in the packet. To
help avoid replay attacks, a sequence number is also carried in each
packet. For Meticulous Keyed FNV1A, the sequence number is
incremented on every packet.
The receiving system accepts the packet if the key ID matches one of
the configured Keys, an FNV-1a digest including the selected key
matches the digest carried in the packet, and the sequence number is
strictly greater than the last sequence number received (modulo wrap
at 2^32)
Transmission Using Meticulous Keyed FNV1A Authentication
The Auth Type field MUST be set to TBD2 (Meticulous Keyed FNV1A).
The Auth Len field MUST be set to 16. The Auth Key ID field MUST
be set to the ID of the current authentication key. The Sequence
Number field MUST be set to bfd.XmitAuthSeq.
The Digest field MUST be set to the value of the FNV-1a digest, as
described below.
For Meticulous Keyed FNV1A, bfd.XmitAuthSeq MUST be incremented on
each packet, in a circular fashion (when treated as an unsigned
32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by
more than one for a packet.
Receipt Using Meticulous Keyed FNV1A Authentication
If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (TBD2 for
Meticulous Keyed FNV1A), then the received packet MUST be
discarded.
If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 16, the packet MUST be
discarded.
If the Seed field does not match the current Seed value, the
packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Meticulous Keyed FNV1A, if the sequence number lies outside of the
range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult)
inclusive (when treated as an unsigned 32-bit circular number
space) the received packet MUST be discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, and bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field.
Replace the contents of the Digest field with zeros, and calculate
the FNV-1a digest as described below. If the calculated FNV-1a
digest is equal to the received value of the Digest field, the
received packet MUST be accepted. Otherwise (the digest does not
match the Digest field), the received packet MUST be discarded.
7.1. Calculation of the FNV-1a Digest
Unlike other authentication mechanisms, the user-supplied key is not
placed into the Auth Key / Digest field, and the packet hashed. As
FNV-1a is not a cryptographic hash, such a process would simplify the
process for an attacker to "crack" the key.
Instead, for a particular packet "P", and ISAAC pseudo-random number
"I", the FNV1A digest "D" is calculated as shown below, where "+"
indicates concatenation.
D = FNV1A(I + P + I)
Where "+" denotes concatentation. We also note that the Digest field
of the packet MUST be initialized to all zeroes before this
calculation is performed
The calculated value "D" is then inserted into the packet in the
Digest field, and the packet is sent as normal. The receiving party
reverses this operation in order to validate the packet.
8. IANA Considerations
This document asks that IANA allocate a new entry in the "BFD
Authentication Types" registry.
Address - TBD1
BFD Authentication Type Name - Meticulous Keyed ISAAC
Reference - this document
Address - TBD2
BFD Authentication Type Name - Meticulous Keyed FNV1A
Reference - this document
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 9. Security Considerations
In a symmetric key algorithm, the key is shared between the two The security of this proposal depends strongly on the length of the
systems. Distribution of this key to all the systems at the same secret, and the entropy of the key. It is RECOMMENDED that the key
time can be quite a cumbersome task. BFD sessions running a fast be 16 octets in length or more.
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 security of this proposal depends strongly on ISAAC. This
(the decrypted sequence number will not be in sequence). The generator has been analyzed and has not been broken. Research shows
behavior of the session, when such a packet is detected, is based on few other CSRNGs which are as simple and as fast as ISAAC. For
the implementation. A flood of such malicious packets may cause a example, many other generators are based on AES, which is infeasibe
BFD session to be operationally down. for resource constrained systems.
The symmetric algorithm and key size will determine the difficulty The security of this proposal depends on the strength of the FNV-1a
for an attacker to decipher the key from the transmitted BFD frames. hash algorithm. Folding the output of ISAAC into the hash limits the
The sequential nature of the payload (sequence numbers) simplifies ability of an attacker to reverse the hash, or to perform off-line
the decoding of the key. It is, therefore, recommended to use longer dictionary attacks. Even if one particular 32-bit per-packet key is
keys or more secure symmetric algorithms. found via brute force, that information will be useless, as the next
packet will use a different key. And since ISAAC is secure,
knowledge of one particular key will give an attacker no ability to
predict the next key.
7. Acknowledgements In a keyed 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.
This method allows the BFD end-points to detect a malicious packet,
as the calculated hash value will not match the value found in the
packet. 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.
As noted earlier with Meticulous Keyed FNV1A, each packet is
associated with a unique, per-packet key. This process means that
even if an observer sees the Auth-Key, or the FNV-1a hash for one
packet, the only information gained will be a key which is never be
re-used, and will therefore be useless to an attacker. Further, even
if the attacker can "crack" a sequence of packets to obtain a stream
of keys, the cryptographic nature of ISAAC makes it impossible for
the attacker to derive the input key which is used to "seed" the
ISAAC state.
The particular method of hashing was chosen because of the non-
cryptographic amd reversible nature of the FNV-1a hash. If the
digest had been calculated any other way, then an attacker would have
significantly less work to do in order to "crack" the hash. In short
the per-packet key protects the hash, and and hash protects the per-
packet key.
We believe that this construction is reasonably secure, given the
constraints. If cryptographic security is desired, then implementors
can use MD5 or SHA1 authentication mechanisms
9.1. Spoofing
When Meticulous Keyed ISAAC is used, it is possible for an attacker
who can see the packets to observe a particular Auth Key value, and
then copy it to a different packet as a "man-in-the-middle" attack.
However, the usefulness of such an attack is limited by the
requirements that these packets must not signal state changes in the
BFD session, and that the key changes on every packet.
Performing such an attack would require an attacker to have the
following information and capabilities:
This is man-in-the-middle active attack.
The attacker has the contents of a stable packet
The attacker has managed to deduce the ISAAC key and knows which
per-packet key is being used.
The attack is therefore limited to keeping the BFD session up when it
would otherwise drop.
However, the usual actual attack which we are protecting BFD from is
availability. That is, the attacker is trying to shut down then
connection when the attacked parties are trying to keep it up. As a
result, the attacks here seem to be irrelevant in practice.
9.2. Re-Use of keys
The strength of the Auth-Type methods is significantly different
between the strong one like SHA-1 and ISAAC. While ISAAC has had
cryptanalysis, and has not been shown to be broken, that analysis is
limited. The question then is whether or not it is safe to use the
same key for both Auth Type methods (SHA1 and ISAAC), or should we
require different keys for each method?
If we recommend different keys, then it is possible for the two keys
to be configured differently on each side of a BFD lin. For example.
the strong key can be properly provisioned, which allows to the BFD
state machine to advance to Up, Then, when we switch to the weaker
Auth Type which uses a different key, that key may not match, and the
session will immediatly drop.
We believe that the use of the same key is acceptable, as the Auth
Types which use ISAAC also depend on a Seed. The use of the Seed
increases the difficulty of breaking the key, and makes off-line
dictionary attacks infeasible.
10. Acknowledgements
The authors would like to thank Jeff Haas and Reshad Rahman for their The authors would like to thank Jeff Haas and Reshad Rahman for their
reviews of and suggestions for the document. reviews of and suggestions for the document.
8. References 11. References
8.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
8.2. Informative References 11.2. Informative References
[FNV1A] Noll, L. C., "FNV-1a",
http://www.isthe.com/chongo/tech/comp/fnv/index.html#FNV-
1a, 2013.
[I-D.ietf-bfd-optimizing-authentication] [I-D.ietf-bfd-optimizing-authentication]
Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia,
"Optimizing BFD Authentication", draft-ietf-bfd- "Optimizing BFD Authentication", Work in Progress,
optimizing-authentication-11 (work in progress), July Internet-Draft, draft-ietf-bfd-optimizing-authentication-
2020. 13, 1 August 2021, <https://www.ietf.org/archive/id/draft-
ietf-bfd-optimizing-authentication-13.txt>.
Authors' Addresses [ISAAC] Jenkins, R. J., "ISAAC",
http://www.burtleburtle.net/bob/rand/isaac.html, 1996.
Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Kloud Services Kloud Services
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Sonal Agarwal Sonal Agarwal
Cisco Systems, Inc Cisco Systems, Inc
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95070 San Jose, CA 95070
USA United States of America
Email: agarwaso@cisco.com Email: agarwaso@cisco.com
URI: www.cisco.com URI: www.cisco.com
Ashesh Mishra Ashesh Mishra
O3b Networks O3b Networks
Email: mishra.ashesh@gmail.com Email: mishra.ashesh@gmail.com
Ankur Saxena Ankur Saxena
Ciena Corporation Ciena Corporation
3939 North First Street 3939 North First Street
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: ankurpsaxena@gmail.com Email: ankurpsaxena@gmail.com
Alan DeKok Alan DeKok
Network RADIUS SARL Network RADIUS SARL
100 Centrepointe Drive #200 100 Centrepointe Drive #200
Ottowa, ON K2G 6B1 Ottawa ON K2G 6B1
Canada Canada
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 50 change blocks. 
153 lines changed or deleted 599 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/