Subject: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

From: [email-masked]
Date: Mon, 13 Jul 2020 12:07:25 -0700

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           : Optimizing BFD Authentication
        Authors         : Mahesh Jethanandani
                          Ashesh Mishra
                          Ankur Saxena
                          Manav Bhatia
	Filename        : draft-ietf-bfd-optimizing-authentication-10.txt
	Pages           : 8
	Date            : 2020-07-13

Abstract:
   This document describes an optimization to BFD Authentication as
   described in Section 6.7 of BFD RFC 5880.  This document updates RFC
   5880.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-10
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-10

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: Mahesh Jethanandani <[email-masked]>
Date: Mon, 13 Jul 2020 13:56:14 -0700

This version of the draft addresses some of the shepherd comments. Welcome any feedback.

> On Jul 13, 2020, at 12:07 PM, [email-masked] wrote:
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jul 2020 20:48:57 -0400

Mahesh,

While reviewing version -10, I had the following questions:

For the state machine changes, in the Init->Init state, we have NULL auth.
While this is a "boring" transition, it's also happening at a very slow part
of the state machine; timers should be once a second.  Is there a strong
argument to use NULL here?

In section 3:
:   Sequence Number: The sequence number for this packet.  Implementation
:   may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD
:   [RFC5880], or secure sequence numbers as defined in Secure BFD
:   Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers].

In the core BFD spec, it distinguishes between occasional and meticulous
modes and uses different code points to determine what you do.  I suspect
your intent is that we always use meticulous mode here?

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 20 Jul 2020 18:28:46 -0700

Hi Jeff,

> On Jul 20, 2020, at 5:48 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
> 

Not particularly. The reason to choose NULL was because of the (limited) impact it would have. But if the WG feels otherwise, I can change it to Auth.

> your intent is that we always use meticulous mode here?

Yes, the intent was meticulous. I can clarify that.

Mahesh Jethanandani
[email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 22 Jul 2020 23:10:41 +0000

Mahesh, thanks for addressing my comments. 

I will update the shepherd write-up based on my comments below.

General: both "BFD control packet" and "BFD packet" are used. I think we should stick to "BFD control packet".
General: s/BFD Control packet/BFD control packet/

Introduction, next-to last paragraph. Instead of "The interval of this non-state change frame can be...", I'd suggest "The interval of these BFD packets can be..." or "The interval of the BFD packets without a significant change can be...". Anyway remove "frame" as previously discussed and avoid use of "non-state change" now that you've defined what a significant change is.

Section 1.2. The new table could be incorrectly interpreted as having 1 entry. Suggest changing this to bullet form would make it clearer.

Section 1.2 introduces the term "configured interval" but section 2 uses the term "configured period". Also for the description, what about "interval at which BFD control packets are authenticated in the UP state". 
Also wondering if instead we should have a new bfd.AuthUpStateInterval state variable (see 6.8.1 of RFC5880) since having this value may not always be configured (implementation specific)?

Section 2. Replace  "frame" by "packet" or "BFD control packet"  as appropriate.

Section 2. Thanks for modifying the table as per our discussions. Regarding adding AdminDown to the table, I believe I misled you. Our discussion was based on "what happens if we're UP and receive a packet which says AdminDown"? As per 6.2 of RFC5880, the receiver would go to DOWN state. However the rows/columns in the table are for the local state (new and old), and not for state in received packet. Since we can't go to AdminDown state or leave AdmnDown state based on a packet received, AdminDown state should be removed from this table . I think it'd be good to add a reference to the BFD FSM (6.8.2 of RFC5880) in the paragraph before the table.

Section 2. For configured period (or whatever we decide to call it) add a reference to section 1.2.

Section 4. s/to to/to/

Regards,
Reshad.

On 2020-07-13, 4:56 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" <[email-masked] on behalf of [email-masked]> wrote:

    Mahesh Jethanandani
    [email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 23 Jul 2020 01:01:36 +0000

Hi Mahesh and Jeff,

On 2020-07-20, 9:29 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Jeff,

    Not particularly. The reason to choose NULL was because of the (limited) impact it would have. But if the WG feels otherwise, I can change it to Auth.
<RR> I don't have a strong opinion on this yet. But if we change INIT->INIT to be Auth, we should be consistent and change Down->Down to Auth too?

Regards,
Reshad.

    Mahesh Jethanandani
    [email-masked]

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 23 Jul 2020 08:01:01 +0530

GIven that there isnt a huge advantage in using Auth during INIT -> INIT
and Down -> Down we should probably stick to NULL for the sake of
simplicity. Unless, somebody finds a problem with using NULL.

Cheers, Manav

On Thu, Jul 23, 2020 at 6:32 AM Reshad Rahman (rrahman) <rrahman=
[email-masked]> wrote:

> Hi Mahesh and Jeff,
>
> On 2020-07-20, 9:29 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Jeff,
>
>     Not particularly. The reason to choose NULL was because of the
> (limited) impact it would have. But if the WG feels otherwise, I can change
> it to Auth.
> <RR> I don't have a strong opinion on this yet. But if we change
> INIT->INIT to be Auth, we should be consistent and change Down->Down to
> Auth too?
>
> Regards,
> Reshad.
>
>     >
>     > In section 3:
>     >>>         Filename        :
> draft-ietf-bfd-optimizing-authentication-10.txt
>     >>>         Pages           : 8
>     >>>         Date            : 2020-07-13
>     >>>
>     >>> Abstract:

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 23 Jul 2020 10:10:24 -0400

Manav,

> simplicity. Unless, somebody finds a problem with using NULL.

Part of the reason I flagged this point is that I expect commentary during
IESG review.  This conversation was the forcing function to determine "no,
we think extra authentication here is really useless even with slower
timers".

-- Jeff

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 23 Jul 2020 20:19:26 +0530

Hi Jeff,

I am sorry I dont understand this point.

I would like to stick to NULL because it's less prone to
implementation/inter-op bugs where you dont need to keep changing the kind
of auth you use depending upon where you are in your finite state machine
(FSM). And moreover, doing an AUTH adds no security to the protocol.

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 23 Jul 2020 11:56:32 -0400

Manav,

> (FSM). And moreover, doing an AUTH adds no security to the protocol.

The premise of the draft is that more expensive ciphers are expensive 
AT RATE  AND SCALE.  

Init and Down sessions are 1pps.

The rate portion of the argument is no longer a point of concern.

I agree that it adds no additional security per our analysis.  However, I
expect this dialog to happen with the security ADs.  Their typical answer is
"if you could secure it, you should".

If they don't start this conversation, we're done. :-)

-- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 23 Jul 2020 15:53:03 +0000

They most likely will (

    -- Jeff

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 23 Jul 2020 21:28:49 +0530

I would respond to that if saying "Only secure it, if you need to" :-)

Cheers, Manav

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Jul 2020 12:14:11 -0700

Hi Reshad,

Thanks for combing through the changes.

> On Jul 22, 2020, at 4:10 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 

Done.

> Introduction, next-to last paragraph. Instead of "The interval of this non-state change frame can be...", I'd suggest "The interval of these BFD packets can be..." or "The interval of the BFD packe…

Done.

> Section 1.2. The new table could be incorrectly interpreted as having 1 entry. Suggest changing this to bullet form would make it clearer.

Ok.

> Also wondering if instead we should have a new bfd.AuthUpStateInterval state variable (see 6.8.1 of RFC5880) since having this value may not always be configured (implementation specific)?

Changed all “configured period” to “configured interval” and updated the description.

> Section 2. Replace  "frame" by "packet" or "BFD control packet"  as appropriate.

Ok.

> Section 2. Thanks for modifying the table as per our discussions. Regarding adding AdminDown to the table, I believe I misled you. Our discussion was based on "what happens if we're UP and receive…

You mean Section 6.2 of RFC 5880.

> Section 2. For configured period (or whatever we decide to call it) add a reference to section 1.2.

Done.

Will post the draft with these changes shortly.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 28 Jul 2020 03:04:15 +0000

Hi Mahesh,

Yes indeed that's what I meant.

Regards,
Reshad.