Re: [Idr] A proposal to add sequencing to BGP Flowspec v1

Robert Raszuk <> Tue, 27 April 2021 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47B5D3A1E80 for <>; Tue, 27 Apr 2021 12:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V4PR-Q49QxLD for <>; Tue, 27 Apr 2021 12:44:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 079D53A1E2A for <>; Tue, 27 Apr 2021 12:44:23 -0700 (PDT)
Received: by with SMTP id a25so56268392ljm.11 for <>; Tue, 27 Apr 2021 12:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Obp2o2fNFKMUwFeS5ztq7RsVCz6TFKDdOI3px0wyUP0=; b=cBSJGCCr5159AkK3RIgj9Y7bhxUQ3aprSmTvIVlqWzB9YUvrKg4NHZ5swTB5pU7oGZ YjyM7/I27LF5zVvYp+zdi1vOyyx1FNnKA/QEu2F8HhGziBjm2pDaZjY/6pnQIQBZU8xj zBXOTM3/7cEvDqhxWup+HUh2uv6uQI84cKQCMpXYY0D1T3FAeQfRbWih8LPzOTQLvYjH 82yRio/n0AYFsjM9gz84ZBGYNW+6nGbe16QKMWEbu2KLCmj9hgHygiT1dLu05QRc3b1v L2Hc2UXQ7lIPevSH+W/RkVe4TOcFP214+k8pPIRFKBc3XsT9W2ac3Wy62Omsd3HdtuZW ME4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Obp2o2fNFKMUwFeS5ztq7RsVCz6TFKDdOI3px0wyUP0=; b=OCbXcJkvJdDzOUGPEuxKtr+lkS011AphsY/nY8/nmXjalU480Toqdf8MjASBWZIN60 n84fzmuiJRhI1Nn+zCss15DdtVmIr2AYdDyttiu8PV+ihGl3/OHecJ10P5uuO/7NlwKj DDBziRQUd/unKTFGj891blusgoEyczSNMuTWnoAkSa45lmXyUnH5d/slvEwKzs6659Nw plI/JxTg7cfoOsgr89ua7P9YoAL0L3N4i8aZPE8HmSzYO5PC3frC1qp2sl+OxzKCkPHb ZrrI4a9U4ZH+UVd6AK78i4btfhMHbhVjNREldG1sX9RWBNnx3kwCgMGBMvBYw+IqaQaz 8hhw==
X-Gm-Message-State: AOAM5329831kBul/SEU8O49o4i3XDAiy6XmetB2uZD6DcKq+PYN6aJpU z2gX5Er/jNF/7COtsqfKZL9EDp9S8LYn6x0shmVY+Q==
X-Google-Smtp-Source: ABdhPJzvpRT32ZnihDtwwLu15het2UiKS19TpOdrp67x+KEe4GevDR9+rangPgkJYh9CxrzglOKxNtS5EyrR+mnmZMQ=
X-Received: by 2002:a2e:6a05:: with SMTP id f5mr17485899ljc.23.1619552660741; Tue, 27 Apr 2021 12:44:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Tue, 27 Apr 2021 21:44:10 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="00000000000009f00305c0f97dbf"
Archived-At: <>
Subject: Re: [Idr] A proposal to add sequencing to BGP Flowspec v1
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Apr 2021 19:44:34 -0000

Dear WG,

As someone who has spent a substantial amount of time on FlowSpec
definition I recommend that we leave Flowspec v1 alone and all the
subsequent extensions should aim to go into Flowspec v2.

Reason #1 - Flowspec v1 intends to address a missing gap and offer
mitigation of DDoS attacks as close to the src. The more stuff we load onto
it we will effectively kill this use case. Sure network are evolving but
last time I checked typical DDoS protection today is blackholing entire
destination at best within an ASN and phone/email to adjacent NOCs to do
the same there. This is stone age. While I am not claiming that we should
keep Flowspec v1 forever I am also not able to see alternative dynamic
protocol signalling for DDoS mitigation. Till then I recommend we keep
FlowSpec v1 as is and alive. When better signalling is defined we can
deprecate it.

Reason #2 - Most modern Flowspec extensions turn BGP into configuration
push protocol. Worse, they ride on the p2mp spray distribution model to
push configuration into p2p fashion. That is misuse of BGP in its
fundamental roots. We have netconf, configuration management and bunch of
other tools to do this job, but just for convenience and new RFC glory we
see endless proposals in this space popping up. If this can not be stopped
let's at least contain it and mitigate damage to other BGP useful

Kind regards,

On Tue, Apr 27, 2021 at 8:11 PM Jeffrey Haas <> wrote:

> [Speaking as an individual contributor.]
> IDR,
> As a Working Group, we set out to finish Flowspec v1's -bis document before
> taking up the work for Flowspec v2.  We finished the -bis work in RFC 8955.
> It's been several years since the conversations we had that motivated
> Flowspec v2.  Sue had submitted a proposal that was intended to capture the
> thinking of the Working Group at the time.  There were three high order
> pieces of work to be done:
> 1. Address parsing issues by moving to an explicit length field.  (PCEP
> adopted this idea when they embedded Flowspec in their protocol to leverage
> our encodings.)
> 2. Provide for explicit sequencing of terms.  This was motivated by there
> being a need for other firewall-like applications to have ordering
> different
> than those provided by the default sort function.
> 3. Provide for a better way to manage Flowspec actions, especially when
> they may have interactions based on ordering.
> draft-haas-flowspec-capability-bits was submitted to try to address the
> first issue incrementally for Flowspec v1.  It's gotten good discussion.
> Below, please see a proposal that attempts to incrementally address the
> explicit sequencing problem.
> Why not wait to do this in Flowspec v2, you might ask?  It's certainly an
> option.  I will offer two initial points of consideration why we might want
> to consider this proposal:
> - We now have multiple BGP Flowspec features that share more history in the
>   format of v1 (especially after the -bis work) than they do with v2.  This
>   includes extensions for nvo3, l2vpn.  If those features will want to
>   leverage explicit sequencing, they either need to wait on v2, or update
>   after v2 has come into being.
> - This proposal is also compatible with those additional drafts.
> We look forward to your feedback.
> -- Jeff (for the authors)
> ----- Forwarded message from -----
> Date: Tue, 27 Apr 2021 10:47:36 -0700
> From:
> To:
> Subject: I-D Action: draft-haas-idr-flowspec-term-order-00.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>         Title           : BGP Flowspec Explicit Term Ordering
>         Authors         : Jeffrey Haas
>                           Susan Hares
>                           Sven Maduschke
>         Filename        : draft-haas-idr-flowspec-term-order-00.txt
>         Pages           : 7
>         Date            : 2021-04-27
> Abstract:
>    BGP Flowspec (RFC 8955) provides a mechanism for matching traffic
>    flows.  The ordering of the Flow Specifications defined by that RFC
>    is provided by a sorting function that uses the contents of the
>    received BGP NLRI; that NLRI does not contain an explicit ordering
>    component.  The RFC's sorting function permits for origination of
>    Flowspec NLRI from multiple BGP Speakers and is generally appropriate
>    for mitigating distributed denial-of-service (DDoS) attacks.
>    There are circumstances where the implicit RFC 8955 sorting order is
>    not appropriate.  This document defines a mechanism that permits
>    individual Flowspec NLRI to influence their sort order.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or
> ----- End forwarded message -----
> _______________________________________________
> Idr mailing list