Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 25 Jul 2021 21:26:46 -0700

[Putting the thread on the BFD mailing list]

Hi Jeff/Alan,

I wanted to understand the changes the authors need to make to move the draft forward.

On this thread <https://mailarchive.ietf.org/arch/msg/rtg-bfd/jw1aH07S363k41OCbBDUk2INmRE/>, @Jeff stated that you were looking for clarity on the following statement.

   Note: The first sequence number can
   be obtained using the same logic as used in determining Local
   Discriminator value for the session or by using a random number.
For which I believe the consensus is the suggestion from Alan below to add an authentication section in the first packet that carries the nonce. Right?

See inline for more.

> On Apr 6, 2021, at 3:09 AM, Alan DeKok <[email-masked]> wrote:
> 
> On Apr 5, 2021, at 3:08 PM, Jeffrey Haas <[email-masked]> wrote:
>> BFD needs an increasing sequencing number.  But we also are trying to
>> get replay protection.  What that means is that we likely don't want to
>> start at sequence 1 every time - or we need to have a nonce to make sure we
>> don't get a replay if we do.  
>> 
>> The protocol currently doesn't carry anything to use as a nonce.
> 
>  Maybe add an authentication section in the first packet, which can then carry a nonce?
> 
>> As written (see section 3), it's written as a reversible operation, which
>> would be reasonable from a symmetric bit of crypto.  But if we're using a
>> hash, I don't believe we get that property.  Instead, we have to know what
>> we're expecting in each side and have the next k values computed, where k is
>> in the window of the BFD Detect Multiplier (lost packets maximum).
> 
>  Yes.
> 
>> Somewhere in between draft-06 and -07, the text started moving toward
>> "symmetric key algorithm" from hash, probably as part of the clarification
>> requests for how the mechanism worked.  Likely my request, and I failed to
>> remember that we wanted fast hash rather than reversible.
> 
>  It depends on what the goals are, I guess.  A cryptographic random number generator is likely to be much faster than a reversible encryption method, especially on constrained CPUs.  But random number generators aren't reversible, which is also a useful property.
> 
>  The main issue with a strong hash function is that it's a hash, and isn't intended to generate sequences of numbers.

What I understand from this discussion is that the WG feels that rather than symmetric key algorithm, a hash should be used for computing the ciphertext (if that is the correct term for computed hash?) that will be inserted in the sequence number field, and the other end will compare the computed hash against the next k values it has computed on the expected sequence numbers within the window of BFD Detect Multiplier. Did I get that right?

Inserting this from the same thread.

> 
>>> If so, getting some text would help a bunch.
>> 
>>  I'll see what I can do.
> 
> That'd be great.

Alan, could you help us with the text here.

> 
>> That was my impression.  Complexity might be worthwhile as long as the memory
>> is constrained.  This is going onto linecards with the CPUs that would
>> embarass a lot of people, after all.
> 
>  The Blake3 code isn't trivial, and doesn't seem to have fixed-size memory requirements, unlike MD5 / SHA.
> 
>  Looking around, we also have https://tools.ietf.org/html/rfc8937, which recommends against directly using the output of a PRNG.  It recommends instead a fairly complex scheme, which isn't applicable here.  But perhaps we could do something similar.
> 
>  My suggestion would be to do something vaguely like what RFC 8937 suggests, but with weaker / faster algorithms.
> 
>  We could use ISAAC to securely generate a sequence of random numbers.  The first packets exchanged could contain an authentication section with a nonce.  ISAAC would be seeded with a secret key and a nonce, and would generate a stream of 32-bit cryptographically strong pseudo-random numbers.
> 
>  We could use this output directly, but we might want to go a step further.  We could add a fast hash function to further hide the output of the random number generator, and also get authentication of the packet contents.
> 
>  i.e. for a packet P, set My-Discriminator to zero, take the random number X from Isaac, and then calculate Hash(X, P).  The output is a 32-bit number which can go into the discriminator field.
> 
>  The other end can set the discriminator to zero, calculate the hash, and then see if the packet has been authenticated.  The benefit here is that it's authenticating not just the particular sequence from the random number generator.  It is also authenticating the packet.  And, because the packet contains Your-Discriminator, the has would authenticate the entire sequence of packets.  Which seems a desirable property.
> 
>  Either option would be imperfect, but fast and reasonably secure.

Not clear on whether we are now trying to define how the nonce should be calculated, and if that is not getting into implementation level details. 

Thanks.

>  Alan DeKok.

Mahesh Jethanandani
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Jul 2021 08:08:03 -0400

On Jul 26, 2021, at 12:26 AM, Mahesh Jethanandani <[email-masked]> wrote:
> On this thread, @Jeff stated that you were looking for clarity on the following statement.
> 

  I think that makes sense.

  Yes. 

> Not clear on whether we are now trying to define how the nonce should be calculated, and if that is not getting into implementation level details. 

  If the secure sequence numbers are based on a particular algorithm, then that algorithm should be documented.

  If we have a fast hash and CSPRNG, we can combine the two to get secure sequence numbers.  Plus, we may also leverage this to get the entire packet signed, which might be a desirable property.

  Alan DeKok.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Jul 2021 10:14:55 -0400

Alan, Mahesh,

Let's go back to base expectations.

Right now, the base BFD specification leverages HMAC MD5 or SHA-1 for its
security.  The security mechanism is on every packet.  Prior measurements
have shown that for the desired protocol rates for failure detection that
even those older mechanisms are enough of a CPU hit that people don't care
to run them.

There is a push by the security community to deprecate those mechanisms for
various SHA-2 mechanisms which would simply make the problem worse.

The optimizing-authentication mechanism perhaps offers a way out of this by
saying we'll only provide that level of authentication on packets during
important state changes, and periodically on the regular stream of packets.

However, that leaves the protocol in a state where if it was totally
unauthenticated (the NULL authentication mechanism), an active attacker
could keep a session up when it was actually down.  (The severity of this
attack on operations is perhaps a different discussion, but it concerns
people in the security disciplines.)

The original idea for this proposal was there existed light-weight hash
functions that would provide reasonable and fast operations that could be
used for the periodic protocol transmissions that didn't require strong
authentication.

So, what is needed:
- A mechanism that can be used with the optimizing authentication extension.
- That is light weight enough to justify it as being better than existing
  HMAC MD5 for periodic transmissions.
- The value of which could be encoded in the BFD Authentication section.

Recall that the challenge around BFD is the protocol contains very little
content.  It will largely be cleartext.  And most difficult for the setup,
Discriminators are not always negotiated a priori, although some BFD forms
will do such negotiation using a bootstrapping protocol.

Requirements-wise, it's not necessarily required that the function in
question be "simple", only fast.

The procedure in draft-08 is rather muddled and unclear how it would
properly accomplish the general goals.  In particular, even in the absence
of a specific hash function as an input the procedure applied to the BFD
PDUs isn't terribly clear.

---

Here's what I think we're looking at, in general:

The "Mandatory Section" described in RFC 5880 is the first part of a BFD
packet.  This is followed by an optional "Authentication Section".

Section 4.4 provides an example of the Meticulous Keyed SHA1 packet.  This
contains a Sequence Number which is monotonically increasing as part of the
protocol operation.  For meticulous mode, it increases for each packet.

The hash over the packet and the expected sequence number along with the key
and any necessary nonce yields a value H.  This value, H, needs to go into
the BFD authentication section in some fashion for its extension.

The secure sequence number draft suggests that it goes into the sequence
number field that is transmitted in the packet.

Upon receipt, the BFD neighbor needs to verify the packet.  As currently
written, the secure sequence number draft seems to suggest a reversible
mechanism from which the hash packet may be reversed and the sequence number
determined.  This sequence number is required by the validation procedure
for BFD sessions.  It's my belief that the form of cryptographic hash
function we're discussing is a one-way function.

If it is a one-way function, the receiving procedure can't be to "reverse"
it.  At best, it can take the PDU as input, try the BFD Detection Multiplier
number (valid packet sequence window), then see if a hash that is computed
on the input PDU with the possible sequence numbers yields the received
sequence number, H, in the PDU.

This means that the benefit for the feature would require a function that
can be run on a window of packets for predicted inputs and generate the pool
of next expected sequence numbers.

Procedure would also need to be crafted for allowing the hashed values to be
switched to once the optimizing authentication procedure would have us
switch back to the NULL procedure.

-- Jeff

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Jul 2021 10:35:01 -0400

> - The value of which could be encoded in the BFD Authentication section.

  That should be possible.

  Yes.

  Yes.

  Yes.

  I think a cryptographic random number generator here is likely OK.  Those are usually simple, and fast.  The system can be seeded with a strong secret, or maybe hash of a secret and other information.

  My suggestion to calculate a hash over the packet is that it prevents certain kinds of attacks.  i.e. an attacker could take packet X, and sequence number Y, and put the two together, to spoof / forge state.

  Fixing that requires that the sequence number is somehow tied to a particular packet.

  Alan DeKok.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Jul 2021 10:48:26 -0400

Alan,

>   That should be possible.
[...]
>   Yes.
[...]
>   Fixing that requires that the sequence number is somehow tied to a particular packet.

I don't dispute that these things are possible.

What's being requested is that our specifications have some specificity and
a proposal be made for a suitable mechanism and how it integrates into BFD.
:-)

In any case, you've minimally confirmed that the current text in the
secure-sequence numbers draft is misleading in suggesting a reversible
operation.  The procedural text there thus needs work to incorporate the
points discussed.

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 26 Jul 2021 16:25:25 -0700

Hi Jeff,

> On Jul 26, 2021, at 7:48 AM, Jeffrey Haas <[email-masked]> wrote:
> 

Here are the set of changes that I propose we make to the draft to bring the specificity that you are requesting. For the introductory part of the document there is no reference to the method being applied to come up with a sequence number. It just states that the sequence number inserted is not the monotonically increasing sequence number. As such no changes are needed there.

The change therefore starts in Section 3 - Theory of operation. There are two changes that I see. One has to do with carrying of nonce in the first packet, and the other has to do with existing text in the section.

For the carrying of nonce in the first packet, Alan has already suggested adding the authentication section in the first packet. We will add text to that effect.

As far as the existing text in the section is concerned, we will replace reference to “symmetric key algorithm” and “symmetric algorithm” with “hash”. As a result, the sender will include a ciphertext that is a 32-bit hash computed using one of the algorithms Alan has suggested using a shared key (that is not necessarily symmetric) and inserted in-lieu of the sequence number of the packet. Yes, this draft is about obfuscation of the sequence number field of the packet, not the entire packet.  On reception of the BFD Control packet, the receiver instead of decrypting the ciphertext inserted in-place of the sequence number, will instead compare the ciphertext to pre-computed set of hashes using the same shared key, on the next k expected sequence numbers that are within the BFD Detect Multiplier range. If there is a match, the receiver will replace the ciphertext in the packet with the expected sequence number and pass the frame for further processing. In the case there is no match, it will drop the packet.

There are some similar updates to the Security Considerations section to replace “symmetric algorithm” with “hash”.

Are these set of changes enough to bring the specificity that you are looking for?

Thanks.

Mahesh Jethanandani
[email-masked]