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

Network Working Group                                           A. Dekok
Internet-Draft                                       Network RADIUS SARL
Updates: 5880 (if approved)                              M. Jethanandani
Intended status: Standards Track                          Kloud Services
Expires: 12 April 2024                                        S. Agarwal
                                                      Cisco Systems, Inc
                                                               A. Mishra
                                                            O3b Networks
                                                               A. Saxena
                                                       Ciena Corporation
                                                         10 October 2023

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

Abstract

   This document describes a new BFD Authentication mechanism,
   Meticulous Keyed ISAAC.  This mechanism can be used to authenticate
   BFD packets with less CPU time cost than using MD5 or SHA1, with the
   tradeoff of decreased security.  This mechanism cannot be used to
   signal state changes, but it can be used as an authenticated signal
   to maintain a session in the the "Up" state.  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 12 April 2024.

Copyright Notice

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

Dekok, et al.             Expires 12 April 2024                 [Page 1]
Internet-Draft        Securing next sequence number         October 2023

   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.  Updating RFC 5880 . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Meticulous Keyed ISAAC  . . . . . . . . . . . . . . . . . . .   4
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Seeding and Operation of ISAAC  . . . . . . . . . . . . .   6
     5.2.  Secret Key  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Seeding ISAAC . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Meticulous Keyed ISAAC Authentication . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     8.1.  Spoofing  . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.2.  Re-Use of keys  . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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.

   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 this specification
   is to use a simple method to prevent spoofing of the BFD session
   being "Up".  We therefore define a fast Auth Type method which allows
   parties securely signal that they are still in the Up state.

Dekok, et al.             Expires 12 April 2024                 [Page 2]
Internet-Draft        Securing next sequence number         October 2023

   This document proposes the use of an Authentication method which
   provides meticulous keying, but which has less impact on resource
   constrained systems.  The algorithm chosen is a seeded pseudo-random
   number generator named ISAAC [ISAAC].  ISAAC has been subject to
   significant cryptanalysis in the past thirty years, and has not yet
   been broken.  It requires only a few CPU operations per generated
   32-bit number, can take a large secret key as a seed, and it has an
   extremely long period.  These properties make it ideal for use in
   BFD.

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.  Updating RFC 5880

   Some of the state variables in Bidirectional Forward Detection
   [RFC5880] (Section 6.8.1), are related to the authentication type
   being used for a particular session.  However, the definitions given
   in Bidirectional Forward Detection [RFC5880] are specific to Keyed
   MD5 or SHA1 Authentication, which limit their utility for new
   authentication types.  This specification updates the definition of
   some of the state variables as given below.

   These updated definitions are entirely compatible with the
   definitions given in Bidirectional Forward Detection [RFC5880]
   (Section 6.8.1), and require no changes to existing configurations or
   implementations.  Instead, the updated definitions clarify that the
   state variables apply to the current authentication type, no matter
   what it is.

   These updated definitions also mean that Authentication Sections
   SHOULD include a Sequence Number field.  Where a Sequence Number is
   not used (as with Simple Password) the variables bfd.RcvAuthSeq and
   bfd.XmitAuthSeq MUST be set to zero.

   bfd.AuthType

      The authentication type in use for this session, as defined in
      RFC5880 section 4.1, or zero if no authentication is in use.  Once
      set. the value of this variable MUST NOT change during a session.
      That is, if either end of a connection wishes to change the
      authentication type, it MUST tear down the current session and
      start a new one.

   bfd.RcvAuthSeq

Dekok, et al.             Expires 12 April 2024                 [Page 3]
Internet-Draft        Securing next sequence number         October 2023

      A 32-bit unsigned integer containing the last sequence number for
      the current Authentication Section that was received.  The initial
      value is unimportant.

   bfd.XmitAuthSeq

      Where the Authentication Section includes a Sequence Number, this
      variable MUST be initialized to a 32-bit value taken from a secure
      source.  In the case of ISAAC, the derivation is given below in
      Section 4.  For other methods, the 32-bit value is usually taken
      from a secure random number generator.

   bfd.AuthSeqKnown

      Set to 1 if the next expected Authentication Section has a
      sequence number which is known, or 0 if it is not known.  This
      variable MUST be initialized to zero.

      This variable MUST be set to zero after no packets have been
      received on this session for at least twice the Detection Time.
      This ensures that the sequence number can be resynchronized if the
      remote system restarts.

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

      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.

Dekok, et al.             Expires 12 April 2024                 [Page 4]
Internet-Draft        Securing next sequence number         October 2023

   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 different "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, below.

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

   When the receiving party receives a BFD packet with an expected
   sequence number and the correct corresponding ISAAC output in the
   Auth Key field, it knows that only the authentic sending party could
   have sent that message.  The sending party is therefore "Up", and is
   the only one who could have sent the message.

Dekok, et al.             Expires 12 April 2024                 [Page 5]
Internet-Draft        Securing next sequence number         October 2023

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

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

5.1.  Seeding and Operation of ISAAC

   The ISAAC PRNG state is initialized using the 32-bit Seed and the
   secret key, as defined below.

   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.  The Seed MUST be changed
   when a BFD session transitions into the "Up" state.  In order to
   prevent continuous rekeying, the Seed MUST NOT be changed while a
   session is in the "Up" state.

   Once the state has been initialized, the standard ISAAC initial
   mixing function is run.  Once this 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

Dekok, et al.             Expires 12 April 2024                 [Page 6]
Internet-Draft        Securing next sequence number         October 2023

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

   Each system sending BFD packets chooses its own seed, and generates
   its own sequence of pseudo-random numbers using ISAAC, and place
   those values into the Auth Key field.  Each system receiving BFD
   packets runs a separate pseudo-random number generator, and verifies
   that the received packets contain the expected Auth Key.

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, as
   described below.  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.

Dekok, et al.             Expires 12 April 2024                 [Page 7]
Internet-Draft        Securing next sequence number         October 2023

   The Secret Key MUST be at least eight (8) octets in length, and
   SHOULD NOT be more than 128 octets in length.

   As a result, it is believed to be safe to use the same secret Key for
   the Auth Types defined here, and also for other Auth Types.  However,
   it is RECOMMENDED to use differnet secret Keys for each Auth Type.

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 MUST remain the same for the duration of a BFD
   session.  The Seed value MUST change when the BFD state changes.

   The string used to initialize the ISAAC PRNG is taken from the
   following structure:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Seed                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Your Discriminator                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Secret Key ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the "Your Discriminator" field is taken from the BFD packet
   defined in RFC5880 Section 4.1 [RFC5880].  This field is taken from
   the respective values used by a sending system.  For recieving
   systems, the field are taken from the received packet.  The length of
   the Secret Key MUST be 1016 octets or less.

   The data is padded to 1024 octets using zeroes, and then is processed
   throught the "randinit()" function of ISAAC.  Pseudo-random numbers
   are then produced by calling the "isaac()" function.

   The following figure give Seed and Your-Discriminator as 32-bit hex
   values, and the Secret Key as an eleven-character string.  The
   subsequent figure shows the first eight Sequence numbers and
   corresponding Auth Key values which were generated using the above
   initial values.

Dekok, et al.             Expires 12 April 2024                 [Page 8]
Internet-Draft        Securing next sequence number         October 2023

   Seed    0x0bfd5eed
   Y-Disc  0x4002d15c
   Key     RFC5880June

   Sequence Auth Key
   00000000 739ba88a
   00000001 901e5075
   00000002 8e84991c
   00000003 93e534cd
   00000004 fc213b4b
   00000005 f78fc6e6
   00000006 3a44db86
   00000007 7dda6e6a

   Note that this construct requires that the "Your Discriminator" field
   not change during a session.  However, it does allow the "My
   Discriminator" field to change as permitted by RFC5880 Section 6.3
   [RFC5880]

   This construct provides for 64 bits of entropy, of which 32 bits is
   controlled by each party in a BFD session.  For security, each
   implemention SHOULD randomize their discrimator fields at the start
   of a session, as discussed in RFC5880 Section 10 [RFC5880].

   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

Dekok, et al.             Expires 12 April 2024                 [Page 9]
Internet-Draft        Securing next sequence number         October 2023

      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 ISAAC, 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

Dekok, et al.             Expires 12 April 2024                [Page 10]
Internet-Draft        Securing next sequence number         October 2023

      "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, or cached for
      later use.

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

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

8.  Security Considerations

   The security of this proposal depends strongly on the length of the
   Secret Key, and on its entropy.  It is RECOMMENDED that the key be 16
   octets in length or more.

   The dependency on the Secret Key for security is mitigated through
   the use of two 32-bit random numbers, with one generated by each
   party to a BFD session.  An attacker cannot simply perform an off-
   line brute-force dictionary attack to discover the key.  Instead, any
   analysis has to include the particular 64 bits of entropy used for a
   particular session.  As a result, dictionary attacks are more
   difficult than they would be if the PRNG generator depended on
   nothing more than the Secret Key.

   The security of this proposal depends strongly on ISAAC.  This
   generator has been analyzed for almost three decades, and has not
   been broken.  Research shows that there are 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.

   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 may
   require these keys to be refreshed often, which poses a further
   challenge.  Therefore, it is difficult to change the keys during the

Dekok, et al.             Expires 12 April 2024                [Page 11]
Internet-Draft        Securing next sequence number         October 2023

   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.

   That is, while the Auth Key ID field provides for the use of multiple
   keys simultaneously, there is no way for each party to signal which
   Key IDs are supported.

   The Auth Type method defined here 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.

8.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 Auth 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.

Dekok, et al.             Expires 12 April 2024                [Page 12]
Internet-Draft        Securing next sequence number         October 2023

8.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
   Type defined for ISAAC depend on 64 bits of random data.  The use of
   this randomness increases the difficulty of breaking the key, and
   makes off-line dictionary attacks infeasible.

9.  Acknowledgements

   The authors would like to thank Jeff Haas and Reshad Rahman for their
   reviews of and suggestions for the document.

10.  References

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

10.2.  Informative References

   [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://datatracker.ietf.org/doc/html/
              draft-ietf-bfd-optimizing-authentication-13>.

Dekok, et al.             Expires 12 April 2024                [Page 13]
Internet-Draft        Securing next sequence number         October 2023

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

Authors' Addresses

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

   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

Dekok, et al.             Expires 12 April 2024                [Page 14]