IETF Logo Mail Archive

Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022

Ties de Kock <tdekock@ripe.net> Thu, 10 March 2022 11:22 UTC

Return-Path: <tdekock@ripe.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 9E7C63A099D for <sidrops@ietfa.amsl.com>; Thu, 10 Mar 2022 03:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 UdTVtakjawSC for <sidrops@ietfa.amsl.com>; Thu, 10 Mar 2022 03:22:29 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 442A83A0064 for <sidrops@ietf.org>; Thu, 10 Mar 2022 03:22:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=ltKXGUKVEPTBCVZP5nESd79AhJ4/wFFB3FFwmWaL3Sg=; b=TFNlJaNCvEkOLn1HtoE+kS4A x9fokOVb37zU3yoxJaRnLGMi+vVyDWHcyqjYTzT6/0OJAzcZKxvqbHamVciP+g4XllPXKhgY0S917 QLX13Bz+9zJNGGMQkNlpl083vs2hNhB4L0k+DD+YjznE2sBl+6kzwRW5LnYOqLdB55SDJqMTAnja1 FHnFuniBIHMis/bJNER9ETlSdItkUCVL69p/3q0v+5OhUgeVrCQSk94IjvwOCIdiDCGlkV0vinQZN XBDpp2P6rNi9V6MFazsRP09chUYlefOTEoH1/S4ypqdSuKrGKD1KExJDMdQlSfZR0D4t5Pii891ea WY6+6tDTCQ==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:34532) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1nSGsD-00096q-QG; Thu, 10 Mar 2022 12:22:25 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1nSGsD-0007y4-Lb; Thu, 10 Mar 2022 12:22:25 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <m235jqa2fk.wl-randy@psg.com>
Date: Thu, 10 Mar 2022 12:22:24 +0100
Cc: Tim Bruijnzeels <tim@nlnetlabs.nl>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D46FDA88-15E2-4EC6-BE07-0A1A93038B64@ripe.net>
References: <BYAPR18MB26961DE9F15501CCA12ECCF1C13D9@BYAPR18MB2696.namprd18.prod.outlook.com> <851649A5-9075-4956-8B57-E51F612DF6BD@nlnetlabs.nl> <m235jqa2fk.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1d0a0755a557439d275e2278114af00b5
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xfLbl5mmFAK6DpXyxEOBpvfgNDM>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022
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, 10 Mar 2022 11:22:35 -0000


> On 10 Mar 2022, at 04:53, Randy Bush <randy@psg.com> wrote:
> 
>> This is an issue if, per Randy's example, the entire ROA is withdrawn first,
>> the RPs fetches and revalidates and sends withdraws for VRPs to the router,
>> and then the new ROA is published later, validated, etc
> 
> no need.  CA publishes old an new ROAs.  RP fetches both and processes
> sequentially.  oups!
> 
> and now we can expect to hear folk suggest that the RP should swallow
> and digest the entire ROA set (think of the scale of this a few more
> years out), reconcile it all, and only then send the reconciled VRPs
> to the router.  if the current state of RP software is any indication,
> i would not want to bet my routing on this.

I checked two (StayRTR, routinator) implementations for their behaviour and
they handle this case properly: only the delta in the VRPs after a complete
update is transmitted. If not, imo, that's a bug.

I agree with the information in the draft for de-aggregating VRPs especially for
CAs that do not form one system with their parent CA. In the case where the
parent CA is not under your control, you may not want to have fate-sharing for
all your VRPs.

The risk is mostly there w.r.t. overclaiming, it may be good to spell that out.

-Ties

v2.23.0 | Report a Bug | By Email