Hi Jeff, Ping!
> On Jul 26, 2021, at 4:25 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > Hi Jeff, > > >> On Jul 26, 2021, at 7:48 AM, Jeffrey Haas <jh...@pfrc.org >> <mailto:jh...@pfrc.org>> 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 mjethanand...@gmail.com
