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, internet-dra...@ietf.org 
<internet-dra...@ietf.org> 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


  

Reply via email to