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

Jeffrey Haas <jhaas@pfrc.org> Tue, 11 June 2024 19:11 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13692C1CAF32; Tue, 11 Jun 2024 12:11:12 -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 XWiBEOkKqvKZ; Tue, 11 Jun 2024 12:11:11 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3EBC1840DF; Tue, 11 Jun 2024 12:11:10 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id BBBEC1E28C; Tue, 11 Jun 2024 15:11:09 -0400 (EDT)
Date: Tue, 11 Jun 2024 15:11:09 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christian Huitema <huitema@huitema.net>
Message-ID: <20240611191109.GE4085@pfrc.org>
References: <171782249784.25815.7552423038264617535@ietfa.amsl.com> <20240610162206.GA1459@pfrc.org> <869fbb88-c236-4cc9-b5e2-457556681eda@huitema.net> <20240611140357.GC4085@pfrc.org> <0cb9d396-58c1-4d7e-aa42-0ffd24ea4bec@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0cb9d396-58c1-4d7e-aa42-0ffd24ea4bec@huitema.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-ID-Hash: GVTCE7VPYEWS4NPXK2V5TNYHRQQMLD7V
X-Message-ID-Hash: GVTCE7VPYEWS4NPXK2V5TNYHRQQMLD7V
X-MailFrom: jhaas@slice.pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: secdir@ietf.org, draft-ietf-bfd-stability.all@ietf.org, rtg-bfd@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [secdir] Re: Secdir early review of draft-ietf-bfd-stability-13
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SraQZRDJS9OEuqgDup7mKKsZVa8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Christian,

On Tue, Jun 11, 2024 at 11:36:13AM -0700, Christian Huitema wrote:
> On 6/11/2024 7:03 AM, Jeffrey Haas wrote:
> >And again, sequence rollover for replay has the presumption that you're
> >using exactly the same contents for the BFD PDU.  The procedures for
> >randomizing the Discriminators provide an appropriate nonce to prevent
> >replay since the authentication data is computed over the entire BFD PDU.
> 
> I agree that if the discriminators change regularly and the change
> is enforced, then the rollover risks are addressed. However, I could
> not find text in either RFC5880 or draft-ietf-bfd-stability-13 that
> specifies how to do that.

As you note:

> RFC5880 specifies that "Your Discriminator" echoes the last value
> received from the peer. On reception, "Your Discriminator" is used
> to find the BFD session context, which implies that this is a
> somewhat stable value. As far as I can tell, "my discriminator" has
> no effect on receive processing, apart from being memorized and
> echoed in the next packets. If one just reads that text, it seems
> perfectly legit to keep the same value for a very long time.
> Changing the discriminator is permissible per section 6.3, but not
> mandated. The security considerations in section 9 suggest
> randomizing the discriminator at the beginning of a session, but do
> not mandate changing it during the session.

The local discriminator is not regularly changed, but does have the ability
to change over the course of the session.

RFC 5880 notes in different sections:

:    Note that it is permissible for a system to change its discriminator
:    during a session without affecting the session state, since only that
:    system uses its discriminator for demultiplexing purposes (by having
:    the other system reflect it back).  The implications on an
:    implementation for changing the discriminator value is outside the
:    scope of this specification.

:    If both systems randomize their Local Discriminator values at the
:    beginning of a session, replay attacks may be further mitigated,
:    regardless of the authentication type in use.  Since the Local
:    Discriminator may be changed at any time during a session, this
:    mechanism may also help mitigate attacks.

If the timer is negotiated to 10ms send rate, we're looking at 497 days
before we're going to wrap the counter.

We're not going to provide more protection than that.  Again, if BFD and the
interface it's running on stays up that long without interruption, we should
be proud of the developers and network operator.

> I think we are just missing something simple, like "the local
> discriminator MUST be changed to a new value after N packets have
> been sent", with N << 2^32. If I were implementing this I would pick
> a somewhat low value, to ensure that the code is used sometimes and
> that the behavior is verified.

You're not missing anything.  It was perceived that the time for rotation
was good enough.

Thanks again for your scrutiny.

-- Jeff