| Internet-Draft | Securing next sequence number | March 2022 |
| Jethanandani, et al. | Expires 30 September 2022 | [Page] |
This document describes two new BFD Authentication mechanism, 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 September 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
BFD [RFC5880] defines a number of authentication mechanisms, including Simple Password (Section 6.7.2), and various other methods based on MD5 and SHA1 hashes. The benefit of using cryptographic hashes is that they are secure. The downside to cryptographic hashes is that they are expensive and time consuming on resource-constrained hardware.¶
When BFD packets are unauthenticated, it is possible for an attacker to forge, modify, and/or replay packets on a link. These attacks have a number of side effects. They can cause parties to believe that a link is down, or they can cause parties to believe that the 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.¶
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 [RFC2119].¶
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 TB1 (Meticulous Keyed ISAAC), the Authentication Section has the following format:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth-Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Auth Type¶
Auth Len¶
Auth Key ID¶
Reserved¶
Sequence Number¶
Seed¶
Auth-Key¶
The purpose of this method is to secure the sequence number exchange, and to both detect and prevent spoofing of sequence numbers. In some cases, it is acceptable to not authenticate the entire packet, in which case this method may be used.¶
When the receiving party receives a BFD packet with an expected sequence number, and the correct corresponding ISAAC output, it knows that only the authentic sending party could have sent that message. The sending party is therefore alive/up, and intended to send the message.¶
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".¶
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:¶
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¶
Auth Len¶
Auth Key ID¶
Reserved¶
Sequence Number¶
Seed¶
Digest¶
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.¶
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.¶
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.¶
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.¶
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¶
Receipt using Meticulous Keyed ISAAC 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¶
Receipt Using Meticulous Keyed FNV1A Authentication¶
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.¶
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 RFC.¶
The security of this proposal depends strongly on the length of the secret, and the entropy of the key. It is RECOMMENDED that the key be 16 octets in length or more.¶
The security of this proposal depends strongly on ISAAC. This generator has been analyzed and has not been broken. Research shows few other CSRNGs which are as simple and as fast as ISAAC. For example, many other generators are based on AES, which is infeasibe for resource constrained systems.¶
The security of this proposal depends on the strength of the FNV-1a hash algorithm. Folding the output of ISAAC into the hash limits the ability of an attacker to reverse the hash, or to perform off-line dictionary attacks. Even if one particular 32-bit per-packet key is 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.¶
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¶
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:¶
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.¶
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.¶
The authors would like to thank Jeff Haas and Reshad Rahman for their reviews of and suggestions for the document.¶