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

[Reshad Rahman <[e-mail]>]

 Hi Jeff,
    On Tuesday, February 6, 2024, 08:41:12 AM EST, Jeffrey Haas <[e-mail]> wrote:  
 
 Reshad,


On Feb 5, 2024, at 4:18 PM, Reshad Rahman <reshad=[e-mail]> wrote:
 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.

Related notes from those conversations for the mailing list:
- A poll mechanism to test for a new behavior where the possibility exists for the poll packets to be lost means you have to be mindful of Detect Mult (permitted number of lost packets) and timers.  For example, a one packet poll is enough to probe if the packet isn't lost in either direction.  In case of loss, you don't want to do the poll for Detect Mult packets because if the drop is the result, the session goes down.
Mitigations may include temporarily changing the Detect Mult.
- One mitigation for the repeatedly bouncing sessions is to have the BFD session keep state.  If the implementation switches to optimized mode and the session drops, don't permit the session to automatically restart if it does this after more than X tries.  Require the operator to clear the state?
<RR2> Requiring operator to clear the state is fine in e.g. a lab environment. But in a prod env where opt-auth could be enabled on 1 side by mistake, I'd rather we find a way to handle that automatically in the protocol.
Other questions on section 2: - In paragraph 2, does this new procedure of accepting unauthenticated packets on a receiver apply even if opt-auth is disabled on the receiver (but is a supported feature)?- It would be interesting to walkthrough the sequence to upgrade a BFD session from Auth to opt-auth. Both ends can not be configured simultaneously, so I *think* this answers my question above.
Would an early review e.g. by ops, help to catch issues?


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.

We're looking for consistency in configuration.
If optimized procedures require another mechanism to be chosen for the optimized Up side of things, and that's done via the keychain, you need a valid keychain entry.
Further, properties such as "when is this valid" and other keychain properties are still valid.




     identity null {
       base key-chain:crypto-algorithm;<RR> null-auth to be consistent with no-auth (assuming we keep NULL auth)?

If we don't change the name, sure.


       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?

This is a headache elsewhere in YANG modules.  While the units clause lets us be clear that leaf A and leaf B aren't directly comparable if they don't share the units, it still trips people up.
That said, it's also not forbidden.  re-auth on the interval of seconds seems reasonable to me.
And, as I mentioned in a prior thread, the 60 second value that's been chosen is rather arbitrary.

<RR> Mention that value of 0 means that we don't do periodic reauth with strong authentication.

We could probably do that, especially in support of ISAAC procedures.



       leaf up-auth-type {<RR> Since this points to a key-chain, rename to something like opt-auth-key-chain?

Also reasonable.  The move to the "opt" name token in the draft is largely over the most recent discussion.

         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?

The optimized procedures require meticulous authentication.  The NULL and ISAAC methods use this mode to prevent PITM.  If you don't regularly increment the numbers, you're defining the interval in which the "attack" (silly as it is to some people) can happen.



         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?

What wording would you prefer for "select this type for this mode"?
<RR2> I am just not groking the "in case of optimized auth". Ignore if it's just me.IIUC, based on the other thread, NULL auth will be removed from the description below?
Regards,Reshad.

            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