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

Robert Raszuk <robert@raszuk.net> Wed, 07 April 2021 22:30 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF5C3A2C62 for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 15:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_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=raszuk.net
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 wSF731NcQI2G for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 15:30:32 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 5446B3A2C61 for <idr@ietf.org>; Wed, 7 Apr 2021 15:30:32 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id v140so645057lfa.4 for <idr@ietf.org>; Wed, 07 Apr 2021 15:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L08/KFQ5Q4j2K/BffY/a5gGQq11tPEoSHlw+GL49rsg=; b=KL0Ag//m3xLSk6ZAIKXKrec+fhaZQYZTjr/7XZE3XTzKZuTYH7FRo2+DfBq3xGYKmV jy2HYDR+lJ1bO3ZwDaSuEBHIXeobR4iqU6DzjNT46KwvXOhYBzm8U5KOUg7tZYKP9Erf K59DKHJoJ0MYYUjjyqFsbol53miry+C8q7Q8T+DkviLR1GsIq5icr7M7yjJtK8J8VNd7 PX2NI3C4fRftzOTqglC7C3ChIChNySygDVFcTdyotyg3SSUPYKue0a+n6XNQJHCMLYm2 nGtJUiiEQr1eR7gdb64Pm4UakYcx1CK8U7UBT4FGczeVy6acX+Pbhua8p2xrjkMIi0fO yNNg==
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:cc; bh=L08/KFQ5Q4j2K/BffY/a5gGQq11tPEoSHlw+GL49rsg=; b=rrUn/EX03Dn6ifbJpuBNSQUwFn4AKLUhpuUWWmdWGb+n0ZHjLxv0Tt5hSG23uMEnKW jProznrfv5Yq8EQKcPosItBlszUhQpcy/Od3+ZlK/bALKsKYiNpteCx0+RgSdpS3yLjZ AOAl3wxMPAWrM/E4Z8QtoFnsuPI5LSpeyuCJ/Cv4a5nPnmO7skMeBUH4NB6XNF0e4l2d cSDIJ273g1apE1Vrw6dfc3RkuzdxISaMILjr8iS4FpzXzk+bxl5AIKP7mNrA8dkK7NZA BNToDtAMKOBOvo8JNIomrA2famGgQnMUMly77fWNSX+uT1Vkvpk+TxnWTlnZfFAHea61 6lOw==
X-Gm-Message-State: AOAM530KwqjE2PB434hbo0KO4puxCYNN3oEAllp706dkX7BOtGJ0S22S giKFsWipqs9KjhlV1u+B4/wpAe2Dr4+9zfICtmbFT2e9e40M1w==
X-Google-Smtp-Source: ABdhPJxAO4iCzCwJc7Zouiut6PW/GgTvyGbC2aJEdX/j1Mr+JUk//aKd3C7ZTuWTSAiZLWmpmrn0Fj+HZCJ+LoG5KQo=
X-Received: by 2002:ac2:491d:: with SMTP id n29mr3992949lfi.541.1617834628812; Wed, 07 Apr 2021 15:30:28 -0700 (PDT)
MIME-Version: 1.0
References: <000001d72569$3eace130$bc06a390$@ndzh.com> <CAOj+MMG0ONP5P4DxeaC4AEF8b_Ff43r5boQ6wL9EHHGAfVaK2w@mail.gmail.com> <20210407132506.GA7355@pfrc.org> <CAOj+MMFaJGk7-hif7Qm7Hp1=iThn5gyvmpp+UYY_q6PJEAVAPw@mail.gmail.com> <20210407223222.GD7355@pfrc.org>
In-Reply-To: <20210407223222.GD7355@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 8 Apr 2021 00:30:18 +0200
Message-ID: <CAOj+MMEmpMA9YOSU304mQed6o5gm1eUKbYNwyt88M5_E-7=woA@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005b257705bf697a3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iEuhOmsqe9ADLP7E4WUiCmd5-eU>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 22:30:38 -0000

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 <jhaas@pfrc.org> 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.
>