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

[Reshad Rahman <[e-mail]>]

Hi Mahesh,

 

Inline <RR>.

 

From: Rtg-bfd <[e-mail]> on behalf of Mahesh Jethanandani <[e-mail]>
Date: Wednesday, March 10, 2021 at 3:02 PM
To: Reshad Rahman <reshad=[e-mail]>
Cc: "rtg-bfd@ietf. org" <[e-mail]>
Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt

 

Hi Reshad,

 

See inline with [mj]



On Mar 9, 2021, at 7:28 PM, Reshad Rahman <reshad=[e-mail]> wrote:

 

Hi Sonal,

 

Thanks for the update. But I believe not all comments from ~2 weeks ago (see attached) have been addressed. E.g. use of “symmetric algorithm” and “shared secret key” (as opposed to using variations of the same term).

 

[mj] I looked at the use of the word “shared” in the draft, and there are four instances.I believe in two of those cases it is being used to indicate that the key has to be shared between the sender the receiver, i.e. as an adjective to the word key.  Do you have another way to suggest similar text?

<RR> My comment in the email was “For the key, the terms “symmetric key”, “shared secret key” and “shared key” are used, settle on one for clarity (I believe it should be “shared key” or “shared secret”?)”.

So, I’m ok with the use of shared, but I would like less variations in the terms used (where possible), to avoid potential confusion. E.g “symmetric key”, “shared secret key”, “shared key” all refer to the same thing in this document, why use different terms? But maybe this is common practice for these terms.

 

 

 

The two other instances where it is still being used, in Section 3 with this line:

 

The result is computed, using a shared key, on the sequence number.
 

and then later in the same section with this line:

 

   Upon receiving the BFD Control packet, the receiver decrypts the
   ciphertext using the same provisioned shared key to produce the
   received sequence number.
 

we could change it to say “shared symmetric key”.

 

 Also, section 4 headline is still “Impact of using a hash”, but the text has been changed (hash -> cyphertext) here.

 

[mj]. Agree. We can change the header to say “Impact of using ciphertext in-lieu of sequence number”.

 

Would these changes address the remaining comments?

<RR> Yes.

 

Thanks,

Reshad.



 

Regards,

Reshad.

 

From: Rtg-bfd <[e-mail]> on behalf of Sonal Agarwal <[e-mail]>
Date: Monday, March 8, 2021 at 2:40 PM
To: <[e-mail]>
Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt

 

Hi all,

 

Version 8 of the draft addresses all Shepherd comments.

 

Regards,

Sonal.

 

 

On Mon, Mar 8, 2021 at 11:16 AM <[e-mail]> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF.

        Title           : Secure BFD Sequence Numbers
        Authors         : Mahesh Jethanandani
                          Sonal Agarwal
                          Ashesh Mishra
                          Ankur Saxena
                          Alan DeKok
        Filename        : draft-ietf-bfd-secure-sequence-numbers-08.txt
        Pages           : 6
        Date            : 2021-03-08

Abstract:
   This document describes a security enhancement for the sequence
   number used in BFD control packets.  This document updates RFC 5880.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-08
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



<Mail Attachment.eml>

 

Mahesh Jethanandani

[e-mail]