Re: [Sidrops] Welcome your attention and any comments // FW: New Version Notification for draft-shen-sidrops-region-verification-00.txt

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Mon, 19 July 2021 09:29 UTC

Return-Path: <rainsword.wang@huawei.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E1A3A1784 for <sidrops@ietfa.amsl.com>; Mon, 19 Jul 2021 02:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 e_eemrIXZvJZ for <sidrops@ietfa.amsl.com>; Mon, 19 Jul 2021 02:29:51 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B3D3A1782 for <sidrops@ietf.org>; Mon, 19 Jul 2021 02:29:51 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GSxCy3RQSz6DH6c; Mon, 19 Jul 2021 17:21:02 +0800 (CST)
Received: from kwepeml100001.china.huawei.com (7.221.188.249) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 19 Jul 2021 11:29:47 +0200
Received: from kwepeml500001.china.huawei.com (7.221.188.162) by kwepeml100001.china.huawei.com (7.221.188.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 19 Jul 2021 17:29:45 +0800
Received: from kwepeml500001.china.huawei.com ([7.221.188.162]) by kwepeml500001.china.huawei.com ([7.221.188.162]) with mapi id 15.01.2176.012; Mon, 19 Jul 2021 17:29:45 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] Welcome your attention and any comments // FW: New Version Notification for draft-shen-sidrops-region-verification-00.txt
Thread-Index: Add0ZhKPVJhtlSHrRiuCmn+yfBxMAgE9x7sAAAOjnwAAw/3bsA==
Date: Mon, 19 Jul 2021 09:29:45 +0000
Message-ID: <263427e137a048a0bcd0e0ea87baa17f@huawei.com>
References: <90b532bfdef34d1a9769c3d25b24543c@huawei.com> <CAL9jLaYOppTBr78L+fJJ06iJyvnMw_B=eDcHDY+kqDaeQ68TZw@mail.gmail.com> <CAL9jLaYNwNYzFaZf4jt+CeYfeA-6R5rr2zOVb7UgVFdxfocAVw@mail.gmail.com>
In-Reply-To: <CAL9jLaYNwNYzFaZf4jt+CeYfeA-6R5rr2zOVb7UgVFdxfocAVw@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.153.118]
Content-Type: multipart/alternative; boundary="_000_263427e137a048a0bcd0e0ea87baa17fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yRrYCf9oL7L0TzsaWlOBY3MX7kM>
Subject: Re: [Sidrops] Welcome your attention and any comments // FW: New Version Notification for draft-shen-sidrops-region-verification-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2021 09:29:57 -0000

Hi Chrisopher,

Thanks for your comments.

Filtering is a common method. Before ROV and ASPA, routing policies are used to filter data. ROV and ASPA provide easy-to-use filtering methods.
Currently, ROV and ASPA technologies are deployed from the perspective of Internet service deployment.
The deployment progress depends on data completeness. The deployment of ROVs is also accelerating, and ASPA is still lacking.

In this case, we mainly consider how to strengthen the route defense on our own network.
For example, in scenario 1, ASPA can be used for protection, but the deployment progress of ASPA is insufficient.
In scenario 2, even though ASPA has been fully deployed, it cannot be protected.

So we looked at the solution on that basis.

Regards,
Haibo

From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Christopher Morrow
Sent: Friday, July 16, 2021 3:23 AM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
Cc: sidrops@ietf.org
Subject: Re: [Sidrops] Welcome your attention and any comments // FW: New Version Notification for draft-shen-sidrops-region-verification-00.txt

(for clarity, from a reading reader of the written words I wrote)

On Thu, Jul 15, 2021 at 1:38 PM Christopher Morrow <christopher.morrow@gmail.com<mailto:christopher.morrow@gmail.com>> wrote:
My reading of this, admittedly quickly, is that the draft says basically:
  "hey, you can do some leak prevention with ROA and some with ASPA, but these alone are not sufficient"


"hey, you can do some leak prevention with RouteOriginValidation (ROV, meaning using the RPKI/ROA data to validate origins of prefixes seen in the bgp stream)..."

I think I agree, except that in all cases so far we've always said:
  "You should keep RPKI data updated, and IRR data updated and filter your bgp peerings"

So, without filters there's not a clear way to prevent leaks... Does this draft basically need to say:
  "Hey, rpki is cool, but you still must filter!!"


"Hey, RPKI-based  ROV, ASPA are cool, but you still must filter!!"

apologies for being less than clear...as much as a complain about other people with their loose words you'd think I'd learn :(

and yes aspa may help you get better filters...

On Thu, Jul 8, 2021 at 10:05 PM Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>> wrote:
Hi All,

We have published a new draft of region verifcation recently.
https://datatracker.ietf.org/doc/draft-shen-sidrops-region-verification/

This is also introduced in the APNIC 50.
https://conference.apnic.net/50/assets/files/APCS790/BGP-Routing-Security-Region-based-Trust-Alliance-Validation.pdf

Welcome your comments and suggestions


Abstract:
   BGP routing security is becoming a major issue that affects the
   normal running of Internet services.  Currently, there are many
   solutions, including ROA authentication and ASPA authentication, to
   prevent route source hijacking, path hijacking, and route leaking.
   However, on an actual network, large ISPs with multiple ASes can use
   carefully constructed routes to bypass ROA and ASPA authentication to
   attack the target network.

   This document defines an region-based authentication method for large
   ISPs with many ASes to prevent traffic hijacking within ISPs.


_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<mailto:Sidrops@ietf.org>
https://www.ietf.org/mailman/listinfo/sidrops