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

Zhuangshunwan <zhuangshunwan@huawei.com> Mon, 11 November 2019 13:02 UTC

Return-Path: <zhuangshunwan@huawei.com>
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 49D311200FA; Mon, 11 Nov 2019 05:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level:
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
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 DjGSX5j7w96z; Mon, 11 Nov 2019 05:02:28 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30F412004D; Mon, 11 Nov 2019 05:02:27 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E48353AC0B940FE7FCED; Mon, 11 Nov 2019 13:02:25 +0000 (GMT)
Received: from lhreml721-chm.china.huawei.com (10.201.108.72) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Nov 2019 13:02:24 +0000
Received: from lhreml721-chm.china.huawei.com (10.201.108.72) by lhreml721-chm.china.huawei.com (10.201.108.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 11 Nov 2019 13:02:24 +0000
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml721-chm.china.huawei.com (10.201.108.72) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Mon, 11 Nov 2019 13:02:23 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Mon, 11 Nov 2019 21:02:10 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Zhuangshunwan <zhuangshunwan@huawei.com>, Robert Raszuk <robert@raszuk.net>, "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "wangaj3@chinatelecom.cn" <wangaj3@chinatelecom.cn>, "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification
Thread-Index: AQHVmIZOMrzOqtXY3EeOBTzJrtzJz6eF5xsAgAAHOSA=
Date: Mon, 11 Nov 2019 13:02:10 +0000
Message-ID: <19AB2A007F56DB4E8257F949A2FB9858E5D623BE@NKGEML515-MBX.china.huawei.com>
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> <CAOj+MME_DGDP4JvKHC7uL_UJy2bSw_QcV_hgnsHi5dvV9MS4GQ@mail.gmail.com> <19AB2A007F56DB4E8257F949A2FB9858E5D6231B@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5D6231B@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.202.166]
Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858E5D623BENKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nG3VyOq4j8jVfM35Dn4zkIoL02I>
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 13:02:31 -0000

Hi,

Per my understanding of the existing types defined in that section, it does not preclude the extensions of new types with new behaviors.

Thanks,
Shunwan

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Zhuangshunwan
Sent: Monday, November 11, 2019 8:41 PM
To: Robert Raszuk <robert@raszuk.net>;; Wanghaibo (Rainsword) <rainsword.wang@huawei.com>;
Cc: idr-chairs@ietf.org; wangaj3@chinatelecom.cn; idr@ietf. org <idr@ietf.org>;
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Hi Robert,

The sentence you quoted simply says that the existing type can perform such behavior, and not “Must” or “Should”.

Thanks,
Shunwan


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, November 11, 2019 7:50 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>; idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

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<mailto: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<mailto:jhaas@pfrc.org>]
Sent: Saturday, November 9, 2019 1:11 AM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>; idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>; Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>; idr@ietf. org <idr@ietf.org<mailto: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<mailto: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<mailto:jhaas@pfrc.org>]
> Sent: Friday, November 8, 2019 1:38 AM
> To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
> Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>;
> Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>; idr@ietf. org <idr@ietf.org<mailto: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<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr