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

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Mon, 11 November 2019 07:21 UTC

Return-Path: <rainsword.wang@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 D2658120817; Sun, 10 Nov 2019 23:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OPHITtDcfdd4; Sun, 10 Nov 2019 23:21:35 -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 24B5E120814; Sun, 10 Nov 2019 23:21:35 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C541A691475AEC56A77E; Mon, 11 Nov 2019 07:21:31 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Nov 2019 07:21:31 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Mon, 11 Nov 2019 15:21:18 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
CC: Robert Raszuk <robert@raszuk.net>, "wangaj3@chinatelecom.cn" <wangaj3@chinatelecom.cn>, Zhuangshunwan <zhuangshunwan@huawei.com>, "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification
Thread-Index: AQHVkzhgbTLi2TlKoUev/Znja6jzI6d8OJtQgAM+6oCAAQ4XsIAAfNoAgASWWOA=
Date: Mon, 11 Nov 2019 07:21:17 +0000
Message-ID: <1E61161D6E31D849BEA887261DB609348C9BF7D5@nkgeml514-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>
In-Reply-To: <092F40A2-3FD5-4712-8147-D71DAAA86A6D@pfrc.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.142]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5k8mvlYq6cOGdu-FNLPvBYwaLgE>
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 07:21:38 -0000

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