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

[Reshad Rahman <[e-mail]>]

 Hi,
I've provided some comments to the authors privately, sharing them here to restart/continue the discussion on the WG alias.
My main technical concern is in the changes to BFD auth mode: when transitioning to No auth for up packets, we don't know if the other end supports procedure changes from this document. So the other end could just drop the unauthenticated UP packets and the session will go down, eventually go back up, in a loop. The counter-argument which has been made is that this issue isn't new e.g. if one end is misconfigured for BFD auth, the session will not come up, so this boils down to being a typical config issue. I do agree partially, but I think the changes in this document can make things worse than usual in that the session will come up, go down very quickly and keep on ding that. We don't have any room left in the BFD header to indicate the desired behaviour. The only thing I could think of is to use Poll sequence with A=0 (on top of the expected A=1 packets), and transition to only A=0 if the Poll sequence succeeds (and the Poll sequence has to be for N packets where N is equal to "remote multiplier"). Jeff has pointed out that Xiao Min has suggested a similar solution in https://datatracker.ietf.org/doc/html/draft-xiao-bfd-padding-alteration-00.
In terms of editorial comment, I am now questioning the term NULL auth since we also use the term No auth. Suggestions: Meticulous sequence number, sequence number or something along those lines.
YANG comments/questions/suggestions:
     identity no-auth {
       base key-chain:crypto-algorithm;<RR> It is a bit odd to have a crypto algorithm which says none. I wonder if a boolean would have been better to indicate no-auth.
     identity null {
       base key-chain:crypto-algorithm;<RR> null-auth to be consistent with no-auth (assuming we keep NULL auth)?
       leaf reauth-interval {         when "../optimized-auth = 'true'";         type uint32;         units "microseconds";<RR> I think it's overkill to have this in microsecs. Other intervals use micro secs because we exchange timer values in micro secs. This value is not exchanged so we don't need microsecs. Or are you doing this for consistency?<RR> Mention that value of 0 means that we don't do periodic reauth with strong authentication.
       leaf up-auth-type {<RR> Since this points to a key-chain, rename to something like opt-auth-key-chain?         type key-chain:key-chain-ref;         must "(../optimized-auth = 'true') and " +              "(../bfd-ip-sh:meticulous = 'true')";<RR> Why the check for meticulous? Is the reasoning that for non-meticulous opt-auth isn't needed or is it something else?         description           "The authentication type that should be used once the            connection transitions to Up state. In case <RR> Why in case? Isn't this only for optimized auth?            of optimized auth, the choices are Reserved (or no             authentication), NULL Auth, or Meticulous Keyed ISAAC.";       }       description         "Augment the 'bfd' container to add attributes related to BFD <RR> The 'authentication' container? Same below          optimized authentication.";     }
Regards,Reshad.


    On Monday, February 5, 2024, 12:14:55 PM EST, [e-mail] <[e-mail]> wrote:  
 
 Internet-Draft draft-ietf-bfd-optimizing-authentication-14.txt is now
available. It is a work item of the Bidirectional Forwarding Detection (BFD)
WG of the IETF.

  Title:  Optimizing BFD Authentication
  Authors: Mahesh Jethanandani
            Ashesh Mishra
            Ankur Saxena
            Manav Bhatia
  Name:    draft-ietf-bfd-optimizing-authentication-14.txt
  Pages:  26
  Dates:  2024-02-05

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-14

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-optimizing-authentication-14

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts