Re: Secdir early review of draft-ietf-bfd-stability-13

Jeffrey Haas <jhaas@pfrc.org> Fri, 14 June 2024 16:38 UTC

Return-Path: <jhaas@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 7C2F9C151981; Fri, 14 Jun 2024 09:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 R_u4T7PYdLhQ; Fri, 14 Jun 2024 09:38:24 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BB277C14CF15; Fri, 14 Jun 2024 09:38:23 -0700 (PDT)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id 14C481E039; Fri, 14 Jun 2024 12:38:23 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: Secdir early review of draft-ietf-bfd-stability-13
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <979a261d-a703-49d4-b701-a349a79fe52a@huitema.net>
Date: Fri, 14 Jun 2024 12:38:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <193E333B-E00B-4EF7-BDB8-242BEC7AB34E@pfrc.org>
References: <171782249784.25815.7552423038264617535@ietfa.amsl.com> <20240610162206.GA1459@pfrc.org> <1813362471.3032669.1718293563050@mail.yahoo.com> <979a261d-a703-49d4-b701-a349a79fe52a@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3696.120.41.1.8)
Message-ID-Hash: YJ6V3GXXBWNWNRBD5JTNZNR75DFVP2FG
X-Message-ID-Hash: YJ6V3GXXBWNWNRBD5JTNZNR75DFVP2FG
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-bfd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Reshad Rahman <reshad@yahoo.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-bfd-stability.all@ietf.org" <draft-ietf-bfd-stability.all@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection" <rtg-bfd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/yYcBm66Lpo1z4LzvVduI9zRD4uM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-bfd-owner@ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Subscribe: <mailto:rtg-bfd-join@ietf.org>
List-Unsubscribe: <mailto:rtg-bfd-leave@ietf.org>

Christian, Reshad,


> On Jun 13, 2024, at 12:41 PM, Christian Huitema <huitema@huitema.net> wrote:
> On 6/13/2024 8:46 AM, Reshad Rahman wrote:
>> <RR> Was there any consideration to change the procedure to increment the loss count so that if we get 1-3-2-4, we increment loss count when we receive 3 (2 is deemed lost) but not when we receive 2 (2 < 3 so that means out of order). Also when we receive 2, since 2 < 3 (OOO) if we don't update bfd.RcvAuthSeq, then when we receive 4 we won't increment loss count. So it'd be counted as 1 loss.
> 
> Or, you could use the same "windowed" process as used with the authenticated modes. But the security issue is obvious.
> 
> The current specification for loss detection with NULL auth is almost stateless. A spoofed packet does increase the loss counter, but the next packet restores the state to what it needed to be. Adopting your proposed rule or the windowed rule will make it stateful. A spoofed packet would increment bfd.RcvAuthSeq, and could cause lots of "good" packets to be ignored.

Exactly this.  The minimal state kept would cause the highest number in the rolling sequence number space to cause the lost packets to "latch" vs. the highest seen sequence number.  Under attack or bug conditions, this would be problematic due to the lack of authentication.


> 
> This brings back my argument against using NULL authentication. I would prefer to not see it used at all, but barring that you could at a minimum have a warning in the security section. RFC 5880 says that "BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links (so long as there is some return path, of course)."

We're not changing that behavior for BFD.  The lack of security in the NULL auth is exactly why we removed it from being an acceptable mechanism for the optimized authentication procedures.  In that circumstance, it harmed security rather than helped it.  Thus, it remains only as a mechanism to provide a non-cryptographic mechanism for sequence loss.

> I understand that the risk of using NULL auth appears limited if the endpoints are connected by direct physical links, and maybe also if tunnels are protected by IPSEC. But the risks are obvious for multihop routed paths, tunnels without authentication, and probably virtual circuits or MPLS Label Switched Paths as well. So, if you cannot swallow a blanket ban on NULL auth, at a minimum you should have some MUST NOT specifications for any path in which packets can be injected by third parties.

This is true for plain BFD, and authentication is available and operationally recommended under such situations.

That said, this revisits and attempts to relitigate long-shipped RFCs rather than discuss this specific mechanism.

> 
> With a precaution like that in place, you could use the same windowed procedure for all authentication types, including NULL. That would probably simplify implementations.

Sadly, the windowing procedures are harmful for NULL or anything else without a signature over the payload.  Thus, we didn't recommend them.



-- Jeff