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 <gregimir...@gmail.com> 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 <mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com>> 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, internet-dra...@ietf.org > > <mailto:internet-dra...@ietf.org> 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/ > > <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://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> > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-06 > > > > <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 > > <http://tools.ietf.org/>. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> > > > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > > > Mahesh Jethanandani mjethanand...@gmail.com
