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 <mjethanand...@gmail.com> > 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.
