Re: [Sidrops] draft-sidrops-rpkimaxlen

Di Ma <madi@rpstir.net> Thu, 11 March 2021 07:34 UTC

Return-Path: <madi@rpstir.net>
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 61FA83A1412 for <sidrops@ietfa.amsl.com>; Wed, 10 Mar 2021 23:34:45 -0800 (PST)
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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Wtjf1JIJdUcS for <sidrops@ietfa.amsl.com>; Wed, 10 Mar 2021 23:34:41 -0800 (PST)
Received: from out20-99.mail.aliyun.com (out20-99.mail.aliyun.com [115.124.20.99]) (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 D30053A140F for <sidrops@ietf.org>; Wed, 10 Mar 2021 23:34:40 -0800 (PST)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1949752|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.706208-0.00279167-0.291001; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047212; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.JjNU4dl_1615448074;
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.JjNU4dl_1615448074) by smtp.aliyun-inc.com(10.147.43.95); Thu, 11 Mar 2021 15:34:34 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <BYAPR11MB32073F176C7DDB3D26EDA2A4C0919@BYAPR11MB3207.namprd11.prod.outlook.com>
Date: Thu, 11 Mar 2021 15:34:33 +0800
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3B25842-51A0-4CBD-8602-E5DE4ABCCFA7@rpstir.net>
References: <SN6PR0901MB236677B37676FFB11A22B14D84780@SN6PR0901MB2366.namprd09.prod.outlook.com> <alpine.WNT.2.00.1902240047270.4012@mw-x1> <SN6PR0901MB23662F6907DD092EA0EC988184790@SN6PR0901MB2366.namprd09.prod.outlook.com> <alpine.WNT.2.00.1902241416230.4012@mw-x1> <SN6PR0901MB2366DDDAB75A1619AD5A952E847A0@SN6PR0901MB2366.namprd09.prod.outlook.com> <alpine.WNT.2.00.1902250951230.4012@mw-x1> <BYAPR11MB32073F176C7DDB3D26EDA2A4C0919@BYAPR11MB3207.namprd11.prod.outlook.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5i7LWWQjJW9VX3JPxgr7sdGq7Eo>
Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen
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: Thu, 11 Mar 2021 07:34:45 -0000

Jakob,

> 2021年3月10日 21:07,Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org> 写道:
> 
> I agree that a hijack is made easier when a ROA exists without a corresponding BGP advertisement.
> 
> Implementing DDOS and RTBH as indicated in the draft is difficult without the ROAs for the required BGP announcements. As indicated in the draft, creating and distributing the ROAs required for RTBH and DDOS scrubbers is time consuming.
> 
> Note that these ROAs are not required throughout the entire BGP space, the world.
> These ROAs are only needed near the AS requiring these services, thus distributing them
> around the entire world, just for some local RTBH implementation is disruptive to the
> rest of the world.
> 
> To help with these "limited distribution ROAs" that are required quickly, and in
> a smaller space than the entire BGP space, I propose to invent a new BGP address
> family to publish them. Using BGP to publish a ROA enables fast distribution
> and allows to limit the distribution to only those ASes that need it.

As I am maintaining RPSTIR the RP Software, I have been working on a feedback mechanism to enable RP to learn from BGP announcements to establish local/neighbor view. In the context of RPKI, I see those ASes sharing the same one RP are local. 

I think your proposed "limited distribution ROAs”  is going to help create local/neighbor view. 

Granted, we may have the ROA validation by RP not the router itself and should work on the interface between them.

> 
> Anybody want to help me write a draft?

Count me in if you think an RP implementor can help. 

Di