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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

I think we are talking a bit in parallel spaces.

Yes you are absolutely right that the capabilities work well for
targeted flowspec (or any other AF) sessions. I was hesitating to include
such a disclaimer in last email but considered this obvious. I know some
customers like to use flowspec in that way. However this is not
what flowspec was (at least originally) proposed for.

I never said that draft enforces symmetry between BGP speakers.

My point is very simple.

You say: "So, it's a filter against NLRI that have unsupported component
types."

I say: There is a significant difference between hardware support of a
given filtering type and BGP ability to recognize it. And that is not
reflected in the draft. Worse both are made equal.

The deployment I am worried about is that lack of hardware support or
perhaps even configuration protecting router to dynamically install some
filters will trigger no capability to be sent hence in spite of software
fully capable of parsing the entire "new" NLRI such BGP UPDATE will not be
received. If not received it will not be propagated to peers (say EBGP
peers) hence the end effect of flowspec will be broken.

If you like to do this in v2 pls do ... but please do not break v1.

Again my concern does not apply in 1:1 config push with flowspec. It only
applies to truly distributed flowspec information dissemination especially
from any egress detecting attack to as close to attack source(s).

Thx,
R.


On Thu, Apr 8, 2021 at 12:10 AM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
> On Wed, Apr 07, 2021 at 08:27:06PM +0200, Robert Raszuk wrote:
> > > Not a single BGP flowspec implementation implemented the "opaque"
> property
> > > in RFC 5575.  Not one.  And it was the strong motivation to remove that
> > > text
> > > in RFC 8955.
> >
> >
> > This is the crux.
> >
> > The way I read the current draft is that you are putting an equal sign
> into
> > supported filtering and advertised capability.
> >
> > That is not what I would do.
>
> It's also not what the draft does.
>
> :    A BGP Speaker that has received the BGP Flowspec Capability Bits
> :    Capability MUST NOT transmit a BGP Flowspec encoded NLRI that
> :    contains a component types that is not present in the received bit-
> :    string.
> :
> :    A BGP Speaker that has received a BGP Flowspec related AFI/SAFI
> :    without this Capability MUST treat the absence as equivalent to
> :    having received the Capability Bits covered by the base specification
> :    for its defining RFC, [RFC8955] or [RFC8956].
>
> So, it's a filter against NLRI that have unsupported component types.
>
> It does not require that the capabilities are identical between two BGP
> Speakers.
>
> Nor does it require the capabilities to be symmetric between two BGP
> Speakers.
>
> > While subject to separate discussion perhaps it is ok to expect BGP to
> > parse NLRI and validate the types it carries. I am fine with that. But
> this
> > is a control plane. This has nothing to do with platform capabilities to
> > actually perform filtering on such types. That is also an easy software
> > upgrade across the network.
>
> Section 4 already points out that understanding and willingness to use
> a compoonent type are not identical.
>
> > Even if platform does not support given filtering the bgp speaker will
> > accept the update and advertise it further. Mission accomplished.
> Flowspec
> > is not broken and has a chance to work downstream.
>
> It's pre-broken, which is why we're having this discussion.
>
> The two common deployment mechanisms are targeted BGP sessions to
> individual
> routers - usually with NO_ADVERTISE, or distribution via standard BGP
> propagation including route reflectors.
>
> Presume a new filtering component, X, not in the set 1..14 of current
> supported components.
>
> A targeted session from a controller still needs to know whether it can
> send
> X or not to a given router.  If you don't know this a priori, the first
> NLRI
> with X contained in it will drop the session.
>
> If a controller injects an NLRI containing X into a network that doesn't
> understand it, it will propagate through the routers (e.g. route
> reflection)
> that understand it. It will then hit the router that doesn't - and that
> session drops.
>
> There is no current way to safely do distribution of a new component X in a
> hop by hop distributed domain without knowing the entire domain is safe.
> This is just the recursive step of knowing that it's safe to one single
> router.
>
> Sure, you could know it via provisioning.  The penalty for guessing wrong
> or
> mis-deployment is rough.
>
> > Contrary to the above what's being cooked here is severely breaking the
> > flowspec propagation chain to hardware capabilities (as most of the
> > filtering will likely occur in hardware at decent rates).
>
> I don't understand this point.
>
> Consider contrasting it against the text in Section 5 which already talks
> about the considerations for filtering.
>
> -- Jeff
>
> >
> > Now I wonder what is your take on this point ?
> >
> > Thx,
> > Robert.
>