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

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Tue, 05 November 2019 08:11 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 342821200DB for <idr@ietfa.amsl.com>; Tue, 5 Nov 2019 00:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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_BLOCKED=0.001] 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 3lzkLrov5uN2 for <idr@ietfa.amsl.com>; Tue, 5 Nov 2019 00:11:29 -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 66515120133 for <idr@ietf.org>; Tue, 5 Nov 2019 00:11:29 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F248F6CEB1A333DFB3DF for <idr@ietf.org>; Tue, 5 Nov 2019 08:11:27 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 08:11:22 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Tue, 5 Nov 2019 16:11:13 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Robert Raszuk <robert@raszuk.net>, "wangaj3@chinatelecom.cn" <wangaj3@chinatelecom.cn>, Zhuangshunwan <zhuangshunwan@huawei.com>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: Destination-IP-Origin-AS Filter for BGP Flow Specification
Thread-Index: AQHVkzhgbTLi2TlKoUev/Znja6jzI6d8OJtQ
Date: Tue, 05 Nov 2019 08:11:12 +0000
Message-ID: <1E61161D6E31D849BEA887261DB609348C9A97E0@nkgeml514-mbx.china.huawei.com>
References: <CAOj+MMHLFxe94chd1woN74KeJy3UQa2mfSjXjrE7uudPBDw6KQ@mail.gmail.com>
In-Reply-To: <CAOj+MMHLFxe94chd1woN74KeJy3UQa2mfSjXjrE7uudPBDw6KQ@mail.gmail.com>
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: multipart/alternative; boundary="_000_1E61161D6E31D849BEA887261DB609348C9A97E0nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mn3WsO7Y_BTVrtIt6Pup2wyPvqA>
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: Tue, 05 Nov 2019 08:11:34 -0000

Hi Robert,

    Thanks for your comments.

1. Flowspec is mainly used inside an operator, so the risk is controllable unless the device that generate the Flowspec rule is compromised.
But if this happens, the existing Flowspec rules are enough for hackers to do anything.
Also we can control which peer can support this function.

2. Forwarding does not need to spread a rule into multiple rules.
When matching a rule, the packet needs to obtain its Origin-AS according to the Dest IP in the FIB table, and then use this Origin-AS to perform rule matching. Of course, this action will bring some performance loss.

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.


Regards,
Haibo

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Tuesday, November 5, 2019 1:50 AM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; wangaj3@chinatelecom.cn; Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: idr@ietf. org <idr@ietf.org>
Subject: Destination-IP-Origin-AS Filter for BGP Flow Specification


Dear Authors of draft-wang-idr-flowspec-dip-origin-as-filter

After reading this document with interest I am scared !

You have constructed a fantastic tool to hijack traffic to any AS or for that matter balckhole it completely with surgical precision.

Yet the draft does not say a word about validation of such filters. In fact it describes use cases where validation would not be done as no destination IP address would be present at all. Section 4 just illustrates DST ASN + SRC IP.

Technically you highlight the value of the proposal by stating that R1 needs to install only one rule in the data plane:


 Using the method defining in this draft, the ISP AS64597 needs to

   setup only one "Destination Origin AS + Source Prefix" rule in Router

   R1 as following:



     +--------------+--------------+-------------------------+

     | Destination  | Source Prefix| Redirect to IP Nexthop  |

     | IP Origin AS |              |                         |

     +--------------+--------------+-------------------------+

     |  64598       | IP Prefix 61 |       R3                |

     +--------------+--------------+-------------------------+



     Figure 3: Steering the Traffic Using Origin AS and Source Prefix

Well packets do not carry ASNs so that may be a bit tricky for the data plane.

I assume you mean that router will explode given Dst ASN into all atomic BGP destination announcements either by BGP AS_PATH match or by RIR/RPKI lookup. So effectively one such control plane rule may result in 100s of not 1000s of data plane match rules.

And at the end you state:

5.  Security Considerations

   No new security issues are introduced to the BGP protocol by this
   specification.

IMHO this proposal both on security and technical grounds should not proceed any further.

Many Thx,
Robert.