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

Robert Raszuk <robert@raszuk.net> Fri, 09 April 2021 15:35 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 3AB6A3A2507 for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 08:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 Mn2mfL6eF9lN for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 08:35:07 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 2263E3A2503 for <idr@ietf.org>; Fri, 9 Apr 2021 08:35:07 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id r8so10284708lfp.10 for <idr@ietf.org>; Fri, 09 Apr 2021 08:35:06 -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=Zfa+N/HH+wemZYPmW9j9iDIqJbLw1m3j7NEovgrbfYY=; b=GRyU90CmjP4tRfEAQuR3DVXZ8Qj3hweUFBgC3hPwjE4MM37vXS3L638fDCRnJhF9mq 0ovUhKg8X9RBiv9ArG0QEs01dGNuF7kCoBq+blJvDoZ8aUvSdTsNMV4cpfN1x7AXcRub wuuA4YIObB5CL1YQ+R3syTrv3+HWnbEtM136ra4q94apINWvYDcI5TMpAWAQ9eeBZT1J 2WZIvRzVS/xYQ/Phqrsjz83QDYntJO7rdKx1/ibTbB8wn5Ytw06e7DKiMZ5hXjLM//0S pEkJOpM1hIQCX16I32JcfqwMJ41aHRPWemNQqS5ARzhlmc1b3XO3vLJE+4KapOeEYIFn bx3w==
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=Zfa+N/HH+wemZYPmW9j9iDIqJbLw1m3j7NEovgrbfYY=; b=L474lValGPBSaWqoKgxHem/enpZ1lXCeBnvV9BOk8hDILi/Z81UTbTClTTSYupVgdD K1AAizIrBlPEiYO+RCGErFu1E/bt6+nU66br6tH4+r1W7jMDi9rx+GKUM6Cy63yjnq+V PHrXKRsHS+6znKckPAbSXxkJ+xvAKN98bW8n8A3VTRRnlF2FmKiz/vMRMnRwqyFEq0a5 ynt1LptIfi7cu+Av9dUVamjrSNcWA+vDQhDAwKBk35+cxxIpbS0hJ1LVbDD6u+2xTchG ObHQa/bR/7gr2A6RAJvJS6pdmeCrwpfKwPUFfwvxa9VYisX9XGO6T4ko5oWMqZgAX5HS az+w==
X-Gm-Message-State: AOAM532wdGXTEDTCmYyfsEKNIJMQ9+dtgGq/F1uvO+DY+kTbYro27nHN 7j87j063GjURPrQHcPwqGKNivORWhMe8B9GQqA6rQw==
X-Google-Smtp-Source: ABdhPJwwKDhKlq8Y8MqHNhueMKjsWGu6aIgdwakUPaFsi/sTng/W6VqGyolO1UdUAhYV/dmrjLRzdMwnqx3NiV/1fRs=
X-Received: by 2002:a05:6512:118d:: with SMTP id g13mr10478630lfr.36.1617982504637; Fri, 09 Apr 2021 08:35:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMEmpMA9YOSU304mQed6o5gm1eUKbYNwyt88M5_E-7=woA@mail.gmail.com> <20210408004720.GF7355@pfrc.org> <CAOj+MMGukAL-fNpWh1yu=AHqnONPq9mCqqFGjK5pspFkHfn0UA@mail.gmail.com> <20210408104259.GH7355@pfrc.org> <BYAPR11MB3207F949DD2C8ECA0465CD1EC0739@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV1fxAXHjy7=bc5QGWi0Jt89330U93tp8Hs0wvj3wdy6og@mail.gmail.com> <8B262FE8-EEFB-44E4-8AD0-2EBD3348DEF2@cisco.com> <005b01d72cf3$4f39c4a0$edad4de0$@tsinghua.org.cn> <BYAPR11MB32077D9D69646B7181F72182C0739@BYAPR11MB3207.namprd11.prod.outlook.com> <CAOj+MMHi5kkze8HbBf8yL8E8zomaBzcPz1ciER8_JeB8h9VVsw@mail.gmail.com> <20210409154518.GC29502@pfrc.org>
In-Reply-To: <20210409154518.GC29502@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 9 Apr 2021 17:34:54 +0200
Message-ID: <CAOj+MMHzqVQnEnhxpY8UO_Xyv3GaQHmJz0-QAVLFNfi7NEeoHw@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, "Aseem Choudhary (asechoud)" <asechoud=40cisco.com@dmarc.ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000712a7505bf8be896"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nEwGgGHhJ4tVKAYk-oiFceioFGw>
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: Fri, 09 Apr 2021 15:35:12 -0000

Hi Jeff,

IDR WG and AD made a decision many months back that no new features you may
be referring to sitting in your backlog will be added to flowspec v1. Did
you miss that - I think so based on your replies.

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

I never said this is not a deployed reality on how BGP can be used.
However that deployment model was not  the intention of original flowspec
v1 to mitigate DDoS as close to the src .

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

Yes - any p2p information distribution like PCEP by BGP or BGP-LS are not
good fit to BGP-4 protocol (IMHO).

> The point of the proposal is to offer an option that addresses incremental
> deployment of new flowspec features without requiring a flowspec v2.

And that is the key src of my objection as I see what is being cooked here.
It is against already reached WG consensus. New features should go to FSv2
leaving FSv1 to do its original job.

Cheers,
R.



On Fri, Apr 9, 2021 at 5:22 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

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