[secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13

Magnus Nyström <magnusn@gmail.com> Mon, 03 May 2021 04:43 UTC

Return-Path: <magnusn@gmail.com>
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 569393A1FE7; Sun, 2 May 2021 21:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIsCbgpZQymZ; Sun, 2 May 2021 21:43:52 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EF33A2007; Sun, 2 May 2021 21:43:51 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id h6so2889763ila.7; Sun, 02 May 2021 21:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=btUViEUvaBwwBlkVa+8frP3qUOJklz2Z63BlAzwRE84=; b=dHnG89lM8uBjDVxC33nO8S3zP3rKu5+l5x8DMytZaKDVDR08TYYaWyibQplBfHy1r+ mTKRja/8C2JrAxmMmXUAWxngcb2pfe6AZFf9OaAxfHmWIghUM2u+wcnkYOjIC4cshBOc HcUvD0l/aQiSObi66FpHdcNTa/iGosHDQsi+nb8JgHAYwz1DqbMPRJ/Gtn3YOWRi0Wab QYYbRm9gC1/NuKBpgtGjNsrWGXD05laHORt4F5O8ya9K7J9fzNqDEPRTBPVFBVg9AyUn DMZ4PAhGqhav10VOjn7LAjM8ItXx6IELmMWLsaKCMXo8wLrnNIRG86qbmfMVU31gT3Kh Tvyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=btUViEUvaBwwBlkVa+8frP3qUOJklz2Z63BlAzwRE84=; b=pfnPzR/Aa1FxFWl8KZFyfXkFA1qHr+X22bQ2SejS7HqdkLpXOjKUVkvev+s9UCC2fw 0dTazNRWejf9q7xT0MI/ryp/5K6I8rx63oBvN+prTze0qv8BHV/1dU429RzIXnqJgTFr 0J51DGDNBhqJ/YCSMbCFQ6mwxlX2EOJXh1RQ0u+7XQcd+QwVdXfbkOunxxVv4oI1gYcM 5QKAZb4ENDPAnFW/NgZ0eeWIasTgxNy2PBveMQpMRAu4KlzrkSIOslpL8+GZRG+q93Ed LD5qa2huCy7Ql65vA4Gc2stccVT9vYsTay99Dz9QknK8kHrnzxJl4J+lpZ2HZHUh6I3e kJJw==
X-Gm-Message-State: AOAM530qPkFYrYl1j2z2gquwEv6+ce8sqaRIRpxqMSlm5YxMyudAh5rh DyLxDcgRCQo/2/nQclJ1ByiiUnR5UtoNIJKAPstJyOc5noU=
X-Google-Smtp-Source: ABdhPJy141mMg89dBghpS977BPL0SaIPy2cKMGarMle8cmiV2z71z5Oi083haFGpYDwlfgzhBaltphjPxXvbmFJaC+g=
X-Received: by 2002:a92:8e4f:: with SMTP id k15mr14015516ilh.16.1620017029313; Sun, 02 May 2021 21:43:49 -0700 (PDT)
MIME-Version: 1.0
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com> <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com> <CADajj4ZTBoCHo2=RJhYFNMi+5L5JJwc_EqBkeyYUUfYsVk-vVw@mail.gmail.com>
In-Reply-To: <CADajj4ZTBoCHo2=RJhYFNMi+5L5JJwc_EqBkeyYUUfYsVk-vVw@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Sun, 2 May 2021 21:43:38 -0700
Message-ID: <CADajj4aN=cr-sxjMrmiSxsptwpOZWcH73dWhrtPrruahEQcNJg@mail.gmail.com>
To: secdir@ietf.org, draft-ietf-idr-bgp-flowspec-oid@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008ffb8605c1659b4a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/cXLfoahYLzvWRotWkFvIybgl_J0>
Subject: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 04:43:57 -0000

 I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document describes "a modification to the validation procedure defined
for the dissemination
of BGP Flow Specifications." More specifically. the memo describes a
mechanism which relaxes  the existing validation rule that requires Flow
Specifications to be originating from the originator of the best-match
unicast route, and now allows such specifications to be originated within
the same AS as the validator. As a result. the Security Considerations
section does call out: "The original AS_PATH validation rule ([RFC4271]
section 6.3 <https://tools.ietf.org/html/rfc4271#section-6.3>) becomes
hereby optional (section 4.2
<https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-13#section-4.2>).
If that original rule is actually not enforced it may introduce some
security risks. A peer (or a client of a route server peer) in AS X could
advertise a rogue Flow Specification route...." and "If t[the originator of
a rule] is known for a fact not to be a route server, that optional rule
SHOULD be enforced for Flow Specification routes."

It is not clear to me how a validator would now "for a fact" that a peer
isn't a route server, and thus that it would have to enforce the
now-optional path validation rule. It seems some clarity on this would be
good such that implementations have less of a risk of accepting flow
specifications from unauthorized parties, even if they are on the same AS.

Editorial:

   - "Let's consider the particular case where the Flow Specification is
   originated in any location within the same autonomous system than the
   speaker performing the validation (for example by a centralized BGP route
   controller), and the best-match unicast route is originated in another
   autonomous system." - should the word "than" be replaced with "that" here?
   - In the security considerations section, "becomes hereby optional"
   could probably be simplified to "becomes optional" or similar, and
   "actually" could be removed.


Thanks,
-- Magnus