Resolving lingering issues with BFD authentication drafts
Jeffrey Haas <jhaas@pfrc.org> Fri, 23 February 2024 21:32 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE28C14F605 for <rtg-bfd@ietfa.amsl.com>; Fri, 23 Feb 2024 13:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbkKKt5v6L8Z for <rtg-bfd@ietfa.amsl.com>; Fri, 23 Feb 2024 13:32:48 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 48F55C14F5FE for <rtg-bfd@ietf.org>; Fri, 23 Feb 2024 13:32:47 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id E904A1E28C; Fri, 23 Feb 2024 16:32:46 -0500 (EST)
Date: Fri, 23 Feb 2024 16:32:46 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: rtg-bfd@ietf.org, Reshad Rahman <reshad@yahoo.com>
Subject: Resolving lingering issues with BFD authentication drafts
Message-ID: <20240223213246.GA15208@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/jXc9TRX3vowYy7J0Tzju5Vk-JD0>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Feb 2024 21:32:50 -0000
Here's an attempt to provide a path to resolve the lingering issues in the authentication drafts. Core lingering issues: - The NULL auth method is attackable, but still potentially useful for the stability procedures. - The optimization procedures currently can have BFD go Up with the initial stronger authentication, then go down once the optimized mode kicks in. Right now, the text doesn't place any bounds on how long it might be until the optimized procedures are initiated once the session moves to Up. The issue here is less about bouncing the BFD session, but the impact on BFD clients. Possible ways to address these: For BFD optimization: - We remove no-authentication and NULL-authentication as methods for the optimized session. This leaves us solely with one defined method that both provides good enough security. It also leaves us room to add other authentications in the future that have similar properties. - Optimized authentication should kick in ASAP when we are in the Up state. I believe this means that we send out at least Detect Mult packets in the strong mechanism and then switch to the optimized mechanism. This bounds the amount of time when we're not running in optimized mode. - BFD clients that are expecting optimized authentication SHOULD NOT convey to their clients that the session is in the Up state until we've successfully switched over to the optimized mechanism. While this seems contrary to BFD behavior, it's no different than any of the existing "holddown" procedures clients like BGP can implement to ensure that BFD is stable for long enough before using the session. This is also not the length of time such features want. BGP BFD holddown is in the multiples of seconds time frame. I believe we want something that is within two Detection Intervals once the session is Up. + It should be noted we already require sending out this number of Up packets in the strong mode for entraining ISAAC. However, I'm not sure if our procedures are clear on that point. To be audited. - How does a client tell that "we are expecting optimized authentication"? We define parallel authentication code points for the procedure. Today, our strong meticulous features are currently meticulous md5 and sha1; code points 5 and 3, respectively. We allocate two new code points, "ISAAC-optimized meticulous sha-1" and "ISAAC-optimized meticulous md5". When these code points are used, the expectation is the strong cipher is used to get the session to the Up state, and the session expects to transition to ISAAC afterwards. Thus, we no longer have the opportunity for an implementation that doesn't support optimization to have the session half transition to up using the strong mode and fail once the switch attempts to a mode it doesn't understand. - We might want to consider having the shared secret used for both strong and optimized mode. While we've had discussion that we might not want to do this, having a common shared secret means that misconfiguration stops being the operational consideration that drives the most likely reasons for failure of the transition to optimized authentication. + This can be a SHOULD for the above reasons. + If the operator does not want to use the same shared secret, that's still fine. It just means they're accepting the potential additional fragility. - The NULL auth mechanism is moved out of the optimized draft into the stability draft. For BFD stability: - The NULL auth method is pulled into this document. - The NULL auth's procedures are slightly updated such that the sequence number SHOULD NOT be used for authentication. Effectively, it transitions to a counter. This avoids the ability to use it for attacking the protocol as noted in prior discussion. - The NULL auth security properties are no worse at that point than no authentication. - Existing meticulous methods can be used as well - no change. - ISAAC can be used when optimized mode is in use. No change. + ISAAC mode cannot be used alone. Its procedures for entraining the sequence numbers currently mean it can't be the only authentication. Lingering cleanup: - The IANA considerations and the YANG definitions need to be readjusted based on where we move things. Thoughts? -- Jeff -
- Resolving lingering issues with BFD authenticatio… Jeffrey Haas
- Re: Resolving lingering issues with BFD authentic… Reshad Rahman
- Re: Resolving lingering issues with BFD authentic… Jeffrey Haas
- Re: Resolving lingering issues with BFD authentic… Reshad Rahman
- Re: Resolving lingering issues with BFD authentic… Jeffrey Haas