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

[Robert Raszuk <[e-mail]>]

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
components.

Kind regards,
Robert

On Tue, Apr 27, 2021 at 8:11 PM Jeffrey Haas <[e-mail]> 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 [e-mail] -----
>
> Date: Tue, 27 Apr 2021 10:47:36 -0700
> From: [e-mail]
> To: [e-mail]
> 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:
> https://datatracker.ietf.org/doc/draft-haas-idr-flowspec-term-order/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-haas-idr-flowspec-term-order-00
> https://datatracker.ietf.org/doc/html/draft-haas-idr-flowspec-term-order-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> ----- End forwarded message -----
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>