On Jan 17, 2024, at 11:23 AM, Jeffrey Haas wrote:
> Alternatively, if the ISAAC page is maintained with the sequence number no
> matter what on the presumption that we will eventually move back to ISAAC,
> there's no issues.
>
> Noting that we do not have procedure to permit a new seed to be ex
Alan,
On Jan 17, 2024, at 11:19 AM, Alan DeKok wrote:
> Perhaps then this text. Which both refers to the other draft, and then also
> says how such a switch impacts ISAAC.
>
> It is RECOMMENDED that implementations periodically use a
> strong Auth Type for packets which maintain the
On Jan 17, 2024, at 11:13 AM, Jeffrey Haas wrote:
> I'd recommend this specific text be dropped from the secure sequence number
> document. The expected procedure for doing the periodic stronger
> authentication is part of the optimizing BFD text.
Sure. My concern is that this document shou
Alan,
> On Jan 17, 2024, at 10:18 AM, Alan DeKok wrote:
>
> OK, I've pushed my latest set of changes which address all open concerns.
In that push:
+ It is RECOMMENDED that implementations periodically use a
+ strong Auth Type for packets which maintain the session in an Up
+ s
I've pushed fixes which seem to work.
> On Jan 17, 2024, at 10:28 AM, Mahesh Jethanandani
> wrote:
>
> And let me fix the XML if it is still broken
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>> On Jan 17, 2024, at 7:18 AM, Alan DeKok wrote:
>>
>> OK, I've pushed my latest se
And let me fix the XML if it is still broken
Mahesh Jethanandani
mjethanand...@gmail.com
> On Jan 17, 2024, at 7:18 AM, Alan DeKok wrote:
>
> OK, I've pushed my latest set of changes which address all open concerns.
OK, I've pushed my latest set of changes which address all open concerns.
On Jan 17, 2024, at 9:40 AM, Jeffrey Haas wrote:
> 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.
Yes. I'll add some text.
>>
>>
Alan,
> On Jan 16, 2024, at 6:47 PM, Alan DeKok wrote:
>
> On Jan 16, 2024, at 12:00 PM, Jeffrey Haas 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 simpl
On Jan 16, 2024, at 12:00 PM, Jeffrey Haas 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
th
Alan,
> On Jan 16, 2024, at 11:47 AM, Alan DeKok wrote:
> On Jan 16, 2024, at 11:28 AM, Jeffrey Haas wrote:
>> Option 2:
>> Each side changing to ISAAC authentication knows that lost packets could be
>> a problem. The draft says the window we need to keep around is 3*Detect
>> Mult as part o
On Jan 16, 2024, at 11:28 AM, Jeffrey Haas wrote:
> We're in agreement.
> There is one additional corner case to deal with. Here's the scenario:
... lost packets ...
> Option 2:
> Each side changing to ISAAC authentication knows that lost packets could be a
> problem. The draft says th
Alan,
> On Jan 15, 2024, at 7:25 PM, Alan DeKok wrote:
> On Jan 15, 2024, at 6:22 PM, Jeffrey Haas wrote:
>> 1. We learn the Seed for this session for the first time. This somewhat
>> argues we need a bfd.MetKeyIsaacKnown variable. We require it to not
>> change. Note that it's critical that
On Jan 15, 2024, at 6:22 PM, Jeffrey Haas wrote:
>
> Authors,
>
> Feedback on version -12:
Thanks. I'll check these and hopefully push a PR tomorrow. I just want to
comment on one suggestion below.
> RFC 5880 defines
> :bfd.XmitAuthSeq
> :
> : A 32-bit unsigned integer contain
Authors,
Feedback on version -12:
: Auth-Key
:
: This field carries the 32-bit (4 octet) ISAAC output which is associated
: with the Sequence Number. The ISAAC PRNG MUST be configured and initialized
: as given in section TBD, below.
Fill in the TBD.
: While the rest of the contents of the BFD
15 matches
Mail list logo
