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>
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 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
> mjethanand...@gmail.com
>
>
>
>
