Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

[Jeffrey Haas <[e-mail]>]

On Fri, Apr 09, 2021 at 12:18:18PM +0200, Robert Raszuk wrote:
> All,
> 
> Yes recent comments seems to align with my concern/observations.
> 
> There are two points which make the draft unclear/muddy:
> 
> 1.  A claim that if you use direct BGP sessions between the ultimate single
> target node and controller the proposal makes sense.

It is deployed reality, Robert.  Your like or dislike of it isn't helpful
here.

Since it's not secret sauce but it's not in any readily accessible online
documentation, Arbor Network's flowspec mitigation mechanism - which was a
core operator contributor for the design of flowspec - supports it as a
common deployment mode.  This is broadly because:
- Many flowspec router implementations didn't do selective implementation of
  the rules on their interfaces, and imposed forwarding impact where it
  wasn't helping to mitigate the attack.
- In many cases, attacks can be mitigated on a subset of interfaces in a
  region, or a subset of interfaces by role (peer, customer, etc.)
- The two of these together was a motivator for the flowspec interface-set
  feature.
- The blast radius of flowspec bugs, partially due to the encoding rules,
  was high enough that limiting it to subsets of the network was risk
  mitigation.

The use case for distribution of rules via parallel route reflector
infrastructure is more common, especially for transit service providers.

The use case for customer injected flowspec routes, which complicates the
security model in the RFC, is almost universally avoided at this point.

The motivation to note the targeted peering option is it illustrates
immediately a basis case for issues in incremental deployment of the
feature.  The iterative case is clear from there and observed to be the
non-targeted case.

> 2. The intention of this draft is actually to signal filtering
> capabilities and not BGP control plane parsing capabilities.

The opposite is the intention.  Incremental deployment for parsing is what
you cannot do today.  The side effect of the procedure is that a device may
choose what it is willing to accept.  This is no different than policy.

It's perhaps worth emphasizing at this point that my employer has a backlog
of feature requests for additional filtering on flowspec routes.  At some
point, filtering will become a more broadly deployed behavior with, or
without this capability.  

Part of the motivation for section 5 is to get written down into a draft a
common narrative I have to explain about flowspec deployment - if your rules
are not independent, filtering can have unexpected or nasty behaviors.
Caveat operator.

As features for flowspec gain deployment, islands of selective support are
going to happen.  Switch hardware may implement L2 filtering, while line
cards for core routers may not have support for it.  Data center edge will
need different filtering criteria than network edge.  SD-WAN and 5G
deployments will have different filtering.

The era of a single flooding scope for flowspec routes is not long for this
world.  While my draft was intended to motivate that discussion and that
discussion has been woefully absent from the plethora of extensions we've
had adopted by IDR, the implications will have to be dealt with.  Is my
draft intended to be a broad fix for that?  No.

> Ad 1 -  Yes it does but to me this is a very corner case of how BGP (a p2mp
> protocol) is supposed to work at scale.

You'll also find much work in the spring Working Group to your dislike then.

> Ad 2 -  Jeff agreed to ack that explicitly in the draft leaving option to
> at least enforce by cfg to only signal what BGP can parse. But I am not
> sure if there is a wider agreement that this is good enough.

The point of the proposal is to offer an option that addresses incremental
deployment of new flowspec features without requiring a flowspec v2.  You
are encouraged to offer alternative proposals, if you have any.

-- Jeff