Skip to main content

Secure BFD Sequence Numbers
draft-ietf-bfd-secure-sequence-numbers-09

Document Type Active Internet-Draft (bfd WG)
Authors Mahesh Jethanandani , Sonal Agarwal , Ashesh Mishra , Ankur Saxena , Alan DeKok
Last updated 2022-03-29
Replaces draft-sonal-bfd-secure-sequence-numbers
Stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats plain text html xml htmlized pdfized bibtex
Stream WG state Held by WG
Other - see Comment Log
Document shepherd Reshad Rahman
Shepherd write-up Show Last changed 2020-06-14
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to Reshad Rahman <rrahman@cisco.com>
draft-ietf-bfd-secure-sequence-numbers-09
Network Working Group                                    M. Jethanandani
Internet-Draft                                            Kloud Services
Updates: 5880 (if approved)                                   S. Agarwal
Intended status: Standards Track                      Cisco Systems, Inc
Expires: 30 September 2022                                     A. Mishra
                                                            O3b Networks
                                                               A. Saxena
                                                       Ciena Corporation
                                                                A. Dekok
                                                     Network RADIUS SARL
                                                           29 March 2022

                      Secure BFD Sequence Numbers
               draft-ietf-bfd-secure-sequence-numbers-09

Abstract

   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.

Status of This Memo

   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 Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jethanandani, et al.    Expires 30 September 2022               [Page 1]
Internet-Draft        Securing next sequence number           March 2022

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Meticulous Keyed ISAAC  . . . . . . . . . . . . . . . . . . .   3
   4.  Meticulous Keyed FNV1A  . . . . . . . . . . . . . . . . . . .   5
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Seeding and Operation of ISAAC  . . . . . . . . . . . . .   7
     5.2.  Secret Key  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  Seeding ISAAC . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Meticulous Keyed ISAAC Authentication . . . . . . . . . . . .   9
   7.  Meticulous Keyed FNV1A Authentication . . . . . . . . . . . .  10
     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

   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.

Jethanandani, et al.    Expires 30 September 2022               [Page 2]
Internet-Draft        Securing next sequence number           March 2022

   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.

2.  Requirements Language

   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].

3.  Meticulous Keyed ISAAC

   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

Jethanandani, et al.    Expires 30 September 2022               [Page 3]
Internet-Draft        Securing next sequence number           March 2022

      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.

   Auth Len

      The length of the Authentication Section, in bytes.  For
      Meticulous Keyed ISAAC 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 ISAAC
      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 pseudo-
      random-number-generator (PRNG).  It is used to identify and
      distinguish "streams" of random numbers which are generated by
      ISAAC.

   Auth-Key

      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.

      Note that the Auth-Key here does not include any summary or hash
      of the packet.  The packet itself is completely unauthenticated.

   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.

Jethanandani, et al.    Expires 30 September 2022               [Page 4]
Internet-Draft        Securing next sequence number           March 2022

   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".

4.  Meticulous Keyed FNV1A

   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

      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.

Jethanandani, et al.    Expires 30 September 2022               [Page 5]
Internet-Draft        Securing next sequence number           March 2022

   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

Jethanandani, et al.    Expires 30 September 2022               [Page 6]
Internet-Draft        Securing next sequence number           March 2022

   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.

Jethanandani, et al.    Expires 30 September 2022               [Page 7]
Internet-Draft        Securing next sequence number           March 2022

   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.

Jethanandani, et al.    Expires 30 September 2022               [Page 8]
Internet-Draft        Securing next sequence number           March 2022

   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

Jethanandani, et al.    Expires 30 September 2022               [Page 9]
Internet-Draft        Securing next sequence number           March 2022

      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

Jethanandani, et al.    Expires 30 September 2022              [Page 10]
Internet-Draft        Securing next sequence number           March 2022

   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.

Jethanandani, et al.    Expires 30 September 2022              [Page 11]
Internet-Draft        Securing next sequence number           March 2022

      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

Jethanandani, et al.    Expires 30 September 2022              [Page 12]
Internet-Draft        Securing next sequence number           March 2022

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

9.  Security Considerations

   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.

Jethanandani, et al.    Expires 30 September 2022              [Page 13]
Internet-Draft        Securing next sequence number           March 2022

   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?

Jethanandani, et al.    Expires 30 September 2022              [Page 14]
Internet-Draft        Securing next sequence number           March 2022

   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
   reviews of and suggestions for the document.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

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]
              Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia,
              "Optimizing BFD Authentication", Work in Progress,
              Internet-Draft, draft-ietf-bfd-optimizing-authentication-
              13, 1 August 2021, <https://www.ietf.org/archive/id/draft-
              ietf-bfd-optimizing-authentication-13.txt>.

   [ISAAC]    Jenkins, R. J., "ISAAC",
              http://www.burtleburtle.net/bob/rand/isaac.html, 1996.

Authors' Addresses

Jethanandani, et al.    Expires 30 September 2022              [Page 15]
Internet-Draft        Securing next sequence number           March 2022

   Mahesh Jethanandani
   Kloud Services
   Email: mjethanandani@gmail.com

   Sonal Agarwal
   Cisco Systems, Inc
   170 W. Tasman Drive
   San Jose, CA 95070
   United States of America
   Email: agarwaso@cisco.com
   URI:   www.cisco.com

   Ashesh Mishra
   O3b Networks
   Email: mishra.ashesh@gmail.com

   Ankur Saxena
   Ciena Corporation
   3939 North First Street
   San Jose, CA 95134
   United States of America
   Email: ankurpsaxena@gmail.com

   Alan DeKok
   Network RADIUS SARL
   100 Centrepointe Drive #200
   Ottawa ON K2G 6B1
   Canada
   Email: aland@freeradius.org

Jethanandani, et al.    Expires 30 September 2022              [Page 16]