Re: [Sidrops] draft-sidrops-rpkimaxlen

Di Ma <madi@rpstir.net> Thu, 11 March 2021 15:15 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 AA1C73A109D for <sidrops@ietfa.amsl.com>; Thu, 11 Mar 2021 07:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lClytcQkZmWP for <sidrops@ietfa.amsl.com>; Thu, 11 Mar 2021 07:15:33 -0800 (PST)
Received: from out20-14.mail.aliyun.com (out20-14.mail.aliyun.com [115.124.20.14]) (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 5ECE63A1094 for <sidrops@ietf.org>; Thu, 11 Mar 2021 07:15:30 -0800 (PST)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.100022|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.735849-0.00268867-0.261462; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047192; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.JjYkZM7_1615475720;
Received: from 192.168.3.3(mailfrom:madi@rpstir.net fp:SMTPD_---.JjYkZM7_1615475720) by smtp.aliyun-inc.com(10.147.41.178); Thu, 11 Mar 2021 23:15:20 +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: <CAKr6gn3RuYQ3Z5SrgWohe18Hjoh=QqJiTRd1N5wd47r6s0owqQ@mail.gmail.com>
Date: Thu, 11 Mar 2021 23:15:19 +0800
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <278925A4-91B9-4B8F-B4CC-6F72B77462B3@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> <D3B25842-51A0-4CBD-8602-E5DE4ABCCFA7@rpstir.net> <CAKr6gn3RuYQ3Z5SrgWohe18Hjoh=QqJiTRd1N5wd47r6s0owqQ@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/PveYg0o-FNo3LwELUdND0TrbiLQ>
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 15:15:37 -0000

Interesting.

AS0 ROA is yet another thing we can take into consideration.

Di

> 2021年3月11日 23:07,George Michaelson <ggm@algebras.org> 写道:
> 
> Is there a role for use of AS0 ROA, to "punch out" the elements
> between /len and /maxlen, that are not "wanted" in routing?
> 
> Is there a role for short-life AS0 ROA, to mark the "emergency use"
> more specifics, So they can come live on the time for the AS0 to die
> out or be repudiated, but not have to be announced until needed?
> 
> (C/F Randy: George: stop inventing things we don't need) also (C/F
> this may not actually be a new thought bubble)\
> 
> -G
> 
> On Thu, Mar 11, 2021 at 5:34 PM Di Ma <madi@rpstir.net> wrote:
>> 
>> 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
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops