Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Robert Raszuk <robert@raszuk.net> Mon, 11 November 2019 11:50 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 24B901200BA for <idr@ietfa.amsl.com>; Mon, 11 Nov 2019 03:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 wpfazv__xjEW for <idr@ietfa.amsl.com>; Mon, 11 Nov 2019 03:50:29 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 85A941200DB for <idr@ietf.org>; Mon, 11 Nov 2019 03:50:29 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id i19so10879447qki.2 for <idr@ietf.org>; Mon, 11 Nov 2019 03:50:29 -0800 (PST)
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=f4a/zU81/TDd+qcw6QDCpU2S5E/jZg/VYmxc1PY8N9Y=; b=OYTNWQ2rB9r7Cm1NJR3h+/BtnntvatKk8g40q7Nj3QAvrdxavEvD+Hh34baXbPF6JR v4/CAXcDJrIlCQY31owX/CKwLgNP/Tc69Uu5pLX0rYMcMmKx0rMri/hUnWrRZEHmQLfb ITMxnqZilJQm4fvIwCv8qHVPK57g2x2YGGukN9UV3iT/9Y9WCew6koVr2KBnaFV9I13O gayc5PQFVeshK4pIR7h3h3IvjhUvPyuMyhFS4Tfg9LIJdaRTbeL6aecwHdSyzHjil1B+ pAxgYyrxt+Tx7LFagCXfY0/h52KfVFB1d6NIrFaHAkVVAR94zsfUA4DnSQ86BhCIHFvc cCDg==
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=f4a/zU81/TDd+qcw6QDCpU2S5E/jZg/VYmxc1PY8N9Y=; b=aR0DKnuRyxadz6EJKlA5Mx1IfSGijQ4qpI57vOvKcTAcW2GkRAXN5Jx2I15k0kP8mT IQh0S0VwXfXKCmuVBxF+oo+hxspHFDa/EVR5M+7ieqPIur1CIw7lhwz1wlzFSLtgzm1T ONrYgdrTP03X1+AjHHlwpcj1ytdmrJ76nmnIddsqBw8JT/Mj2GkKpn11ejpWYta3oErC d0nelwr95fRl4jAbgosf5i6mnlwyTSOeswoQ1JEzF6aQZ4NhAhL64EweTodn/2G8/kx2 0AvS5wd1M1ZTSKg4hXSoeg8jkFikzpXd1K8fBSoYoPbBxBXMC95Q6RfoZSPBT6OSGk4G oYsA==
X-Gm-Message-State: APjAAAUPefALZxc1tiI5cMUjId/abx9KckvY/qnt/ygZcCbGitZXrM/N tbNheqW9rvYLFCsi9cD7d48BTvjr//LFr6rqvZfXFA==
X-Google-Smtp-Source: APXvYqw0Im2UCd1g9DvVoW4Y8g5AyuJ6+zyx7hdHu1lFK5regHkAQBf/72YjrPmgE4/Jbmn/bze9lB85Tk15PYtxUiw=
X-Received: by 2002:a05:620a:485:: with SMTP id 5mr183168qkr.134.1573473028089; Mon, 11 Nov 2019 03:50:28 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMHLFxe94chd1woN74KeJy3UQa2mfSjXjrE7uudPBDw6KQ@mail.gmail.com> <1E61161D6E31D849BEA887261DB609348C9A97E0@nkgeml514-mbx.china.huawei.com> <20191107173733.GR3277@pfrc.org> <1E61161D6E31D849BEA887261DB609348C9AA9E5@nkgeml514-mbx.china.huawei.com> <092F40A2-3FD5-4712-8147-D71DAAA86A6D@pfrc.org> <1E61161D6E31D849BEA887261DB609348C9BF7D5@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <1E61161D6E31D849BEA887261DB609348C9BF7D5@nkgeml514-mbx.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 11 Nov 2019 12:50:20 +0100
Message-ID: <CAOj+MME_DGDP4JvKHC7uL_UJy2bSw_QcV_hgnsHi5dvV9MS4GQ@mail.gmail.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "wangaj3@chinatelecom.cn" <wangaj3@chinatelecom.cn>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e750d6059710bcd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1CswQOAIsJXnRCdXhLWwEJ0SU3w>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification
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: Mon, 11 Nov 2019 11:50:32 -0000

Wanghaibo,

Flow spec 5575 and 5575bis limits to what can be used as match criteria to
IPv4/IPv6 IP layer and transport layer headers:

*"The following sections define component types and parameter encodings for
the IPv4 IP layer and transport layer headers."*

Your proposal can not proceed under FlowSpec umbrella as packet's target
ASN is not carried in any of the packet headers so it can not be applied as
a packet ACL.

If you want to continue with this extension let's use a different SAFI and
preferable a different name.

Thx,
R.


On Mon, Nov 11, 2019 at 8:21 AM Wanghaibo (Rainsword) <
rainsword.wang@huawei.com>; wrote:

> Hi Jeffrey,
>
>         Thanks for your suggestion.
>
>         Flowspec is intended to match only the message fields.
>         Our solution here is an enhancement to Flowspec, which can
> effectively reduce the space of the flowspec.
>
>         The rules here are also used in conjunction with the existing
> Flowspec rules, so using the new SAFI to describe it is not appropriate.
>         We can increase OPEN capability negotiation to enable when this
> feature is supported.
>
>
> Regards,
> Haibo
>
> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> Sent: Saturday, November 9, 2019 1:11 AM
> To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>;; idr-chairs@ietf.org
> Cc: Robert Raszuk <robert@raszuk.net>;; wangaj3@chinatelecom.cn;
> Zhuangshunwan <zhuangshunwan@huawei.com>;; idr@ietf. org <idr@ietf.org>;
> Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow
> Specification
>
> Haibo,
>
> Thanks for the expected clarification.
>
> To the chairs, as noted below the feature violates some fundamentals of
> flowspec architecture.  I'd strongly object to the feature being adopted
> without a new SAFI to get it out of the existing flowspec use cases.
>
> -- Jeff
>
>
> > On Nov 7, 2019, at 8:48 PM, Wanghaibo (Rainsword) <
> rainsword.wang@huawei.com>; wrote:
> >
> > Hi Jeffrey,
> >
> >       Flowspec is designed for security protection, but current usage is
> not limited to security protection,
> >    but also to optimize traffic. Using Flowspec to optimize traffic is
> safer and more reliable than send routes to router.
> >
> >    Our scenario here is for optimize traffic. The actions here are all
> performed on the routers. You need to perform a FIB lookup to get dest-as.
> >
> >    This does violate some of the current rules and introduces a certain
> performance penalty,
> >    but it can reduce the demand for Flowspec entry space, so you can use
> this rule in the appropriate scenario.
> >
> > Regards,
> > Haibo
> >
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> > Sent: Friday, November 8, 2019 1:38 AM
> > To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>;
> > Cc: Robert Raszuk <robert@raszuk.net>;; wangaj3@chinatelecom.cn;
> > Zhuangshunwan <zhuangshunwan@huawei.com>;; idr@ietf. org <idr@ietf.org>;
> > Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow
> > Specification
> >
> > Haibo,
> >
> > On Tue, Nov 05, 2019 at 08:11:12AM +0000, Wanghaibo (Rainsword) wrote:
> >> PS: Netflow is already supporting statistical traffic based on
> Dest-IP-Origin-AS, it already download Dest-IP-Origin-AS to FIB entry, this
> prosess can be reused.
> >
> >> From a forwarding perspective, this is the detail that bothers me.
> >
> > Flowspec right now is currently independent of FIB state.  It functions
> on the firewall layer, which is typically implemented prior to FIB.
> >
> > What this feature implies is something roughly like:
> > Packet comes in, hits rule to check dst-as.
> > dst-as lookup needs to happen as one of:
> > - communicate to BGP routing process. (not likely to scale)
> > - trigger a FIB lookup, check returned dst-as.  Violates pipelining in
> > many  architectures.
> > - Have the entire FIB's dst-as-map pushed into memory for firewall,
> > implement as a longest-match lookup on that collection.
> >
> > -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>