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

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> 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.
>
> 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 <[e-mail]> wrote:
>
> 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 <
> [e-mail]> 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.
>>
>> > On Oct 11, 2018, at 4:25 PM, [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           : 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/
>> >
>>
>> Mahesh Jethanandani
>> [e-mail]
>>
>>
>>
>>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>