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

[Mahesh Jethanandani <[e-mail]>]

Hi Jeff,

Ping!

> On Jul 26, 2021, at 4:25 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
> Hi Jeff,
> 
> 
>> On Jul 26, 2021, at 7:48 AM, Jeffrey Haas <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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.
>> :-)
> 
> 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
[e-mail]