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

From: [email-masked]
Date: Thu, 11 Oct 2018 16:25:52 -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-06.txt
	Pages           : 7
	Date            : 2018-10-11

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

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-06
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-06

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

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: Thu, 11 Oct 2018 16:31:32 -0700

This version of the draft addresses comments received at IETF 102 as part of LC. At this point, the authors believe that this document, along with draft-ietf-bfd-secure-sequence-numbers and draft-ietf-bfd-stability are ready for IESG.

Thanks.

> On Oct 11, 2018, at 4:25 PM, [email-masked] wrote:
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 13 Oct 2018 13:10:44 -0700

Hi Mahesh, Authors, et. al,
thank you for your thoughtful consideration of the discussion in Montreal.
I've checked the changes in the new version and I think that the agreement
we've reached was not merely recommend that the authenticated BFD Control
packets be sent as series of at least Detect Multiplier packets but
require, i.e., make it mandatory for both periodic and state change modes.
Here's the quote from the minutes:
    Jeff Haas: one possibility is to send detect multiplier number of
consecutive authenticated packets, then the session will go down if
authentication packets fail validation.
    Greg Mirsky: does that require use of P/F procedure?
    Jeff Haas: P/F is not needed, we send consecutive authenticated packets
    Mahesh Jethanandani: we can make that change.
    Reshad Rahman: is there a need to do the same for state change?
    Mahesh Jethanandani: every state change packet has to be authenticated.
    Jeff Haas: for pedantic reasons, when making the state change we should
do the same. On P/F sequence we should do    this for the new multiplier if
it’s longer. We’ll take this back to the mailing list.
Thus I suggest to consider changes along the following:
OLD TEXT:
 To detect a Man In the Middle (MITM)
   attack, it is also proposed that a non-state change frame be
   authenticated occasionally.  The interval of this non-state change
   frame can be configured depending on the detect multiplier and the
   capability of the system.  As an example, this could be equal to the
   detect multiplier number of packets.
NEW TEXT:
  To detect a Man In the Middle (MITM)
   attack, it is also proposed that a non-state change set of authenticated
frames be
   sent occasionally.  The number of consecutively transmitted
authenticated BFD control packets in the set
   MUST be not lesser than the value of the Detect Multiplier and the
interval between such non-state change
   set of frames can be configured depending on the
   capability of the system.
If acceptable, similar change should be made to the following text:
   Authenticating a small subset of these frames, for example, a detect
   multiplier number of packets per configured period, significantly
   reduces the computational demand for the system while maintaining
   security of the session across the configured authentication periods.
to change from recommendation "for example" to stronger normative language.

Regards,
Greg

On Thu, Oct 11, 2018 at 4:31 PM Mahesh Jethanandani <[email-masked]>
wrote:

> This version of the draft addresses comments received at IETF 102 as part
> of LC. At this point, the authors believe that this document, along with
> draft-ietf-bfd-secure-sequence-numbers and draft-ietf-bfd-stability are
> ready for IESG.
>
> Thanks.
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 15 Oct 2018 10:26:11 -0700

Hi Greg,

But all packets that indicate a state change are authenticated. That has been the original premise of the draft, with or without a Detect Multiplier.

For example, we say in Section 1

   This document proposes that only BFD frames that signal a state
   change in BFD be authenticated.

The only question was with a steady stream, and no state change, how many authenticated packets needed to be sent to thwart a MITM attack. 

Cheers.

> On Oct 13, 2018, at 1:10 PM, Greg Mirsky <[email-masked]> wrote:
> 
> thank you for your thoughtful consideration of the discussion in Montreal. I've checked the changes in the new version and I think that the agreement we've reached was not merely recommend that the authenticated BFD Control packets be sent as series of at least Detect Multiplier packets but require, i.e., make it mandatory for both periodic and state change modes. Here's the quote from the minutes:
>     Jeff Haas: one possibility is to send detect multiplier number of consecutive authenticated packets, then the session will go down if authentication packets fail validation.
>     Jeff Haas: for pedantic reasons, when making the state change we should do the same. On P/F sequence we should do    this for the new multiplier if it’s longer. We’ll take this back to the mailing list.
>    attack, it is also proposed that a non-state change set of authenticated frames be
>    sent occasionally.  The number of consecutively transmitted authenticated BFD control packets in the set
>    MUST be not lesser than the value of the Detect Multiplier and the interval between such non-state change
> On Thu, Oct 11, 2018 at 4:31 PM Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> > On Oct 11, 2018, at 4:25 PM, [email-masked] <mailto:[email-masked]> wrote:
> > 
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/>
> > 
> > https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-06 <https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-06>
> > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-06 <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-06>
> > 
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-06>
> > 
> > 
> > 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/>
> > 
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Oct 2018 21:24:59 -0700

Hi Mahesh,
thank you for your quick response. The comment regarding the state change,
as I understand from the minutes, came from Jeff.
Yes, the question was about the periodic authentication in Up state. I
believe that at the meeting WG arrived at a very good solution and we've
agreed to make the appropriate changes in the document. I don't think that
the current version reflects the WG decision that in Up state authenticated
BFD control packets are transmitted periodically in sets of not less than
Detect Multiplier.

Regards,
Greg

On Mon, Oct 15, 2018 at 10:26 AM Mahesh Jethanandani <
[email-masked]> wrote:

> Hi Greg,
>
> But *all* packets that indicate a state change are authenticated. That
> has been the original premise of the draft, with or without a Detect
> Multiplier.
>
> The only question was with a steady stream, and no state change, how many
> authenticated packets needed to be sent to thwart a MITM attack.
>
> Cheers.
>
>
>     Jeff Haas: for pedantic reasons, when making the state change we
> should do the same. On P/F sequence we should do    this for the new
> multiplier if it’s longer. We’ll take this back to the mailing list.
> On Thu, Oct 11, 2018 at 4:31 PM Mahesh Jethanandani <
> [email-masked]> wrote:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Oct 2018 12:10:26 -0400

Mahesh,

> BFD control packets are transmitted periodically in sets of not less than

I think the text is very close to what we'd likely want.  Here's the text in
the current draft:

:    Most frames transmitted on a BFD session are BFD CC UP frames.
:    Authenticating a small subset of these frames, for example, a detect
:    multiplier number of packets per configured period, significantly
:    reduces the computational demand for the system while maintaining
:    security of the session across the configured authentication periods.

Given BFD procedures, I believe we'd normally want to transmit at *least*
Detect Multiplier number of packets to ensure that the remote site has seen it.

How about the following text?

Most frames transmitted on a BFD session are BFD CC UP frames.
Authenticating a small subset of these frames, significantly
reduces the computational demand for the system while maintaining
security of the session across the configured authentication periods.
A minimum of Detect Multiplier packets MUST be transmitted per configured
periodic authentication interval.  This ensures that the BFD session should
see at least one authenticated packet during that interval.

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 29 Oct 2018 10:33:37 -0700

Hi Jeff,

> On Oct 29, 2018, at 9:10 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Mahesh,
> 

Ok. Will update and post once the submission window opens up.

Mahesh Jethanandani
[email-masked]