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

[Jeffrey Haas <[e-mail]>]

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





On Mon, Jul 26, 2021 at 08:08:03AM -0400, Alan DeKok wrote:
> On Jul 26, 2021, at 12:26 AM, Mahesh Jethanandani <[e-mail]> wrote:
> > I wanted to understand the changes the authors need to make to move the draft forward.
> > 
> > On this thread, @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?
> 
>   I think that makes sense.
> 
> > 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?
> 
>   Yes. 
> 
> >>  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. 
> 
>   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.