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

From: [email-masked]
Date: Mon, 08 Mar 2021 11:16:03 -0800

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/

---

From: Sonal Agarwal <[email-masked]>
Date: Mon, 8 Mar 2021 11:40:08 -0800

Hi all,

Version 8 of the draft addresses all Shepherd comments.

Regards,
Sonal.

---

From: Reshad Rahman <[email-masked]>
Date: Tue, 09 Mar 2021 22:28:03 -0500

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

Regards,

Reshad.

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

Hi all,

Regards,

Sonal.

Abstract:

Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers
From: Reshad Rahman <reshad=[email-masked]>
To: Mahesh Jethanandani <[email-masked]>, Jeffrey Haas <[email-masked]>
Cc: "rtg-bfd@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 23 Feb 2021 22:28:52 -0500
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>

Hi Mahesh,

Thanks for the response. 

Would it be possible to have an updated document when the gates reopen?  Please see inline.

From: Rtg-bfd <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Date: Tuesday, February 23, 2021 at 3:03 PM
To: Reshad Rahman <[email-masked]>, Jeffrey Haas <[email-masked]>
Cc: "rtg-bfd@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

Hi Reshad,

I never really received this e-mail, till Sonal forwarded it to me. 

<RR> You have to remove my name from the spam sender list 😊

Anyway, here are our responses to the comments you have provided. Please see inline with [mj].

Hi Sonal, authors,

Thanks for the document update. Main comments:

Hash has been replaced by symmetric algorithm, to be able to retrieve the sequence number at the receiving side, this is good. 
Section 3 mentions that the symmetric key is provisioned securely on sender and receiver, but there is no mention of provisioning of the algorithm/function. Also there is no mention of what algorithms to use, is this on purpose since what’s good today will not be recommended tomorrow? Should we at least say “do not use DES” or too obvious?
[mj] I believe this is a question for the WG, and maybe something we can bring up in the upcoming meeting, if it is not answered on the mailing list. Would the WG prefer that a (set of) algorithms MUST be defined to ensure interoperability, or is this something we should leave up to implementors/operators to agree? We are concerned what we define today might be obsoleted tomorrow.

<RR> it would be good to have an update on this document at the upcoming meeting. Having a MUST set of algorithms has the drawback you mentioned. Letting implementors/operators agree is fine but I think we still need a suggested list (as of 2021) for interop. And I believe we need some text in the document wrt provisioning the algorithm.

Was there any discussions/thoughts on using asymmetric encryption instead (I didn’t follow this document when it started)? It avoids the pain of having a shared secret. I’m not saying we should go with asymmetric, just wondering.
[mj] We chose symmetric because that is what 5880 talks about.

<RR> Good with me. I’ll defer to security experts.

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”?)
[mj] Ok. How about “shared secret key”?

<RR> Good.

For the algorithm, the terms “symmetric key algorithm”, “symmetric algorithm” , “symmetric encryption algorithm”, “symmetric decryption algorithm” are used. Again, pick 1 “symmetric algorithm”?).
[mj] Ok. We will pick “symmetric algorithm”.

<RR> Good.

The term “hash” is still used e.g. in section 4 header
[mj] That is deliberate. We use “hash” when we refer to the value that is calculated over the entire packet and appended as a value at the end of the packet. That is different from ciphertext, which is the value after applying the symmetric algorithm on the sequence number and inserted in-lieu of the sequence number before the hash is calculated.

<RR> Section 4 header still uses the term “hash” but the text in that section has been changed to “cyphertext”, I believe this is an oversight.

Security is not my expertise. Should we get a security review asap, as opposed to waiting for IESG review. Jeff/Martin?
[mj] It would not be a bad idea, although we do have a security expert as a co-author on the draft :-)

<RR> It would seem you’re covered then. 

Diagram chains are clearer now.
Sequence number validity as described at the bottom of page 3 and on P4 (at the end of section 3). RFC5880 sections 6.7.3 and 6.7.4 describe that received sequence number should be between bfd.RcvAuthSeq(+1) to bfd.RcvAuthSeq+(3*Detect Mult) inclusive. I don’t see why this has to be changed for secure sequence numbers.
[mj] We will just refer to 5880.

<RR> Good.

Jeff’s comment regarding “The first sequence number can be obtained…” in section 3. I believe the text is incorrect. RFC5880 sections 6.7.3 and 6.7.4 explain how the first sequence number is obtained (using bfd.AuthSeqKnown and bfd.RcvAuthSeq).
[mj] Ditto.

<RR> Good.

Regards,

Reshad.

Nits:

Section 4: s/”while encryption/decryption”/”while doing encryption/decryption”/

[mj] Ok.

What does “non linear” mean in “monotonically increasing (but non linear) sequence number”?
[mj] A monotonically increasing number is just that, an increasing number, but it does not have to be linear. See the diagram below. That is why the mention of non-linear.

Section 7: s/Jeff Hass/Jeff Haas/

[mj] Will fix :-). Thanks

Regards,

Reshad.

Mahesh Jethanandani

[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 10 Mar 2021 12:02:09 -0800

Hi Reshad,

See inline with [mj]

> On Mar 9, 2021, at 7:28 PM, Reshad Rahman <reshad=[email-masked]> 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?

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 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-07>.

[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?

>  
> Regards,
> Reshad.
>  
> From: Rtg-bfd <[email-masked] <mailto:[email-masked]>> on behalf of Sonal Agarwal <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
> On Mon, Mar 8, 2021 at 11:16 AM <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/>
>> 
>> https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-08 <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 <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-08>
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-08 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-08>
>> 
>> 
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
> <Mail Attachment.eml>

Mahesh Jethanandani
[email-masked]

---

From: Reshad Rahman <[email-masked]>
Date: Wed, 10 Mar 2021 22:56:49 -0500

Hi Mahesh,

Inline <RR>.

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

Hi Reshad,

See inline with [mj]

Hi Sonal,

<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.

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

<RR> Yes.

Thanks,

Reshad.

Regards,

Reshad.

Hi all,

Regards,

Sonal.

Abstract:

<Mail Attachment.eml>

Mahesh Jethanandani

[email-masked]