Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas <[e-mail]>]

Alan,


> On Jan 16, 2024, at 6:47 PM, Alan DeKok <[e-mail]> wrote:
> 
> On Jan 16, 2024, at 12:00 PM, Jeffrey Haas <[e-mail]> wrote:
>> This means the two scenarios we have during the first transition to ISAAC in the face of packet loss are:
>> 1. It's on "this" page.
>> 2. It's on the prior page.
> 
>  The simple solution to page issues is to just require that there be no more than 255 lost packets allowed.  That way the current packet is always in the first page of derived ISAAC values.

I've reviewed the relevant text for the "search" and think it's correct.  A possible tweak:

      <t>If a calculated key at index "I" does match the Auth Key in
      the packet, then the bfd.MetKeyIsaacRcvAuthIndex field is
      initialized to this value.  THe bfd.MetKeyIsaacRcvAuthBase field
      is then initialized to contain the value of bfd.RcvAuthSeq,
      minus the value of bfd.MetKeyIsaacRcvAuthIndex.  This process
      allows the pseudo-random stream to be re-synchronized in the
      event of lost packets.</t>

Effectively, bfd.MetKeyIsaacRcvAuthBase is the sequence number at which ISAAC was first found valid.  This may be a lost packet. Working this into the text may help clarify this scenario for implementors.

> 
>  For now, I've largely reworked the text.  The new text is at:  https://github.com/mjethanandani/bfd-secure-sequence-numbers/tree/v14-alan

Thanks.  These comments are against the current snapshot at that repository.  Note that the repository doesn't currently compile so I'm reviewing this via the .xml.

A thought about the receiving mode:

        <t>Note that in some cases, calculating the expected output of
        ISAAC will result in the creation of a new "page" of 256
        numbers.  This process will irreversible, and will destroy the
        current "page".  As a result, if the generation of a new
        output will create a new "page", the receiving party MUST save
        a copy of the entire ISAAC state before proceeding with this
        calculation.  If the outputs match, then the saved copy can be
        discarded, and the new ISAAC state is used.  If the outputs do
        not match, then the saved copy MUST be restored, and the
        modified copy discarded, or cached for later use.</t>

Similar to our prior discussion about determining the first sequence number of synchronizing ISAAC page 0, we can observe that we should only generate the next page of the ISAAC table if the received sequence number is in the expected range for an Up session.  

This means that on an attack where the attacker is generating a sequence number greater than the actual sequence number, we generate at most the next table, which will eventually be valid for an Up session.  Those invalid packets will not validate, but can at most cause us to do the work "early".

The related requirement would be that we have the "current" page associated with the most recently valid sequence number, and one possible pending "next" page.

      <t>bfd.MetKeyIsaacRcvKeyKnown</t>
        <li>A boolean value which indicates whether or not the system
        knows the receive key for the Meticulous Keyed ISAAC Auth Type
        method.  The initial value is "false".  This value is changed
        to "true" when a party sees that the other party has started
        to use the Meticulous Keyed ISAAC Auth Type method.</li>

I think this changes to true the first time we see an _acceptable_ ISAAC authenticated PDU.  I.e. we're not permitting the local state to be set and spoiled by invalid inputs.



> 
>  The reworked text doesn't address all of your review, but it does go into great detail into how to initialize and operate meticulous keyed ISAAC.  If defines a large number of variables specific to this Auth Type method.  That may seem surprising, but I think that the resulting text was made clearer.
> 
>  The document still needs updates to address the other comments in your review, but it's late here, and the bulk of the work seems to be done.  I'll do more tomorrow, in order to get this off of my plate.

This is very close to done.  Thanks for helping drive this to conclusion. 

-- Jeff