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

[Mahesh Jethanandani <[e-mail]>]

Hi Alan,

Since you asked what can be done to move this document forward, I went digging to find out what was the last communication about it. Here is one of the last e-mail exchange we had on the subject. While the procedure of how sequence numbers could be secured was clear, there were lingering questions on how it would fit within the framework of existing specification and what was the overlap with optimizing authentication.

> On Aug 31, 2021, at 11:12 AM, Jeffrey Haas <[e-mail]> wrote:
> 
> Mahesh,
> 
> Sorry for long delay.
> 
> On Mon, Jul 26, 2021 at 04:25:25PM -0700, Mahesh Jethanandani wrote:
>>> On Jul 26, 2021, at 7:48 AM, Jeffrey Haas <[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.
> 
> I agree.
> 
>> 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.
> 
> Since this mechanism is intended to work along with
> optimizing-authentication, which implies that we'll be using existing
> authentication mechanisms, how would this be carried?
> 
> A core detail we're dealing with is establishing the expected sequence
> number to run through our hash.  Consider the text from RFC 5880, §6.7.3
> for keyed MD5:
> 
> :     If bfd.AuthSeqKnown is 1, examine the Sequence Number field.  For
> :     Keyed MD5, if the sequence number lies outside of the range of
> :     bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
> :     treated as an unsigned 32-bit circular number space), the received
> :     packet MUST be discarded.  For Meticulous Keyed MD5, if the
> :     sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
> :     bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
> :     unsigned 32-bit circular number space) the received packet MUST be
> :     discarded.
> :
> :     Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
> :     1, and bfd.RcvAuthSeq MUST be set to the value of the received
> :     Sequence Number field.
> 
> Until the implementation is ready to accept sequence numbers, the
> authentication sequence number is unknown.  To use the secure sequence
> number procedures, we have to enter a state where the sequence number is
> known and then we can switch over to the new procedure.

This was one of the questions that we have not addressed in the document. More on it below. I do not know if this overlaps with the seeding of ISAAC question, which we marked as outside the scope of the document.

> 
>> 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.
> 
> Please make sure the text discusses how that interacts with the
> authenticated packets.  For example, if that authentication over the
> expected sequence number or the computed hash?
> 
> But see below for some alternative thinking.
> 
>> 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.
> 
> This works for the case where we're having a series of next expected packets
> that do NOT differ from the prior ones aside from sequence number.  That's
> the case we're trying to cover in the optimizing-authentication draft.
> 
> One possibility to consider is that the core use-case for secure sequence
> numbers is to protect in cases where NULL auth was intended to be used.  If
> the the procedure for secure sequence numbers is only intended to cover that
> use case, standard authenticated packets could use clear-text sequence
> numbers.  This provides an entraining step where the sequence numbers are
> known.  Once we're not authenticating the packets and would otherwise shift
> to NULL auth, we move specifically to secure-seq-auth and apply the
> procedures to those packets only.  
> 
> When a state change is necessary, this is indicated by moving to the prior
> expected authentication per optimizing-authentication.

I like this suggestion. We could limit the use of secure-sequence-number when NULL is intended to be used, whereas authenticated packets could use clear-text sequence numbers.

> 
>> 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?
> 
> I think we're starting to get there.
> 
> And please note: We really do need a reference light-weight hash function to
> use in this draft before we can publish as an RFC, or perhaps a suite of
> them identified by a registry.  

I am assuming the light-weight hash function you have specified in -09 version of this draft satisfies this requirement.

> 
> If the text above about how we arrive at commonly understood sequence
> numbers seems reasoanble to the draft authors, we can discuss how we encode
> this in the BFD PDU.  Perhaps as one or more auth types that aren't the NULL
> auth type.

I am not clear on how using some other auth type will work. Is the idea to use some other auth mechanism to arrive at a commonly understood sequence number before switching to using secure-sequence-number with NULL auth?

Thanks.

> 
> -- Jeff


Mahesh Jethanandani
[e-mail]