IETF Logo Mail Archive

Re: [Idr] some questions from {RC, LC, EC} analysis presentation in GROW

Zhuangshunwan <zhuangshunwan@huawei.com> Tue, 10 August 2021 03:25 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 EB0F63A2456; Mon, 9 Aug 2021 20:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 ZxS2_fRaJ5lW; Mon, 9 Aug 2021 20:25:42 -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 F05883A2454; Mon, 9 Aug 2021 20:25:41 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GkJH80ySDz6DKg3; Tue, 10 Aug 2021 11:25:08 +0800 (CST)
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 10 Aug 2021 05:25:38 +0200
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 10 Aug 2021 11:25:36 +0800
Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2176.012; Tue, 10 Aug 2021 11:25:36 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Michel Py <michel@arneill-py.sacramento.ca.us>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
CC: IDR <idr@ietf.org>, GROW WG <grow@ietf.org>
Thread-Topic: some questions from {RC, LC, EC} analysis presentation in GROW
Thread-Index: AQHXiHXG0T0iPqYYLk6NCjnOwJ+5gatinG8AgADwG9OAB9cbw4AAmMdAgAAKoVCAABO+4A==
Date: Tue, 10 Aug 2021 03:25:36 +0000
Message-ID: <8d059a2771644b43bf2780e2a8c1bea7@huawei.com>
References: <SA1PR09MB8142ADE02512DB13887086AC84F09@SA1PR09MB8142.namprd09.prod.outlook.com>, <76c169816a174f4c8907af0e8b64b932@huawei.com>, <SA1PR09MB8142D8366448EDD90909FDEC84F19@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB8142699ECB6700439DC4D32A84F69@SA1PR09MB8142.namprd09.prod.outlook.com> <a618abaf2b1f41419aabd03c8b16aa20@huawei.com> <F04ED1585899D842B482E7ADCA581B84A9BD196E@newserver.arneill-py.local>
In-Reply-To: <F04ED1585899D842B482E7ADCA581B84A9BD196E@newserver.arneill-py.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.152.178]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RB865GhiR8awbDyIFNSDpX_jCuc>
Subject: Re: [Idr] some questions from {RC, LC, EC} analysis presentation in GROW
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, 10 Aug 2021 03:25:48 -0000

Hi Michel,

Thank you for your valuable information!
Per the experience of RFC 7999, maybe it is better to use 65535:888 to implement the function of ASN:888？

Regards,
Shunwan

-----Original Message-----
From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] 
Sent: Tuesday, August 10, 2021 10:28 AM
To: Zhuangshunwan <zhuangshunwan@huawei.com>; Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>
Cc: IDR <idr@ietf.org>; GROW WG <grow@ietf.org>
Subject: RE: some questions from {RC, LC, EC} analysis presentation in GROW

> Zhuangshunwan wrote :
> then if other communities "ASN:666" are widespread in the wild

They are.

I am the operator of one of the largest ASN:666 BGP blacklist feeds; in the past, I have opposed the standardization of ASN:666 because the text was too vague.
Long story made short : there is not enough separation between source-based BGP backlists and destination-based ones.

As of now, it appears to me that destination-based ASN:666 communities are becoming a de-facto standard; which means that my own source-based ASN:666 BGP feed needs to adopt another community.

I suggest that, if some standardization effort is to take place again, the ASN:666 scheme is used for destination-based BGP blacklist feeds, and that the ASN:888 scheme is used for source-based BGP backlist feeds.
In there, I am happy to follow the lead of Team Cymru in their bogon BGP feed, which is the origin of all BGP blacklist feeds.
https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/

In other words : the :666 community shall be used when one wants to backlist one's own prefixes (possibly a /32), a destination-based backlist. While the :888 community shall be used when one wants to blacklist an IP address by the source, which means a high level of trust in the feed, as any contributor to said feed has potentially the ability to blacklist a source IP.

Respectfully submitted.

Michel.

v2.23.0 | Report a Bug | By Email