IETF Logo Mail Archive

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

Randy Bush <randy@psg.com> Thu, 10 March 2022 03:53 UTC

Return-Path: <randy@psg.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 77CA93A0B60 for <sidrops@ietfa.amsl.com>; Wed, 9 Mar 2022 19:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 wc1NbfEz_G7m for <sidrops@ietfa.amsl.com>; Wed, 9 Mar 2022 19:53:24 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4A2293A115D for <sidrops@ietf.org>; Wed, 9 Mar 2022 19:53:23 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from <randy@psg.com>) id 1nS9rb-0001is-RP; Thu, 10 Mar 2022 03:53:20 +0000
Date: Wed, 09 Mar 2022 19:53:19 -0800
Message-ID: <m235jqa2fk.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
In-Reply-To: <851649A5-9075-4956-8B57-E51F612DF6BD@nlnetlabs.nl>
References: <BYAPR18MB26961DE9F15501CCA12ECCF1C13D9@BYAPR18MB2696.namprd18.prod.outlook.com> <851649A5-9075-4956-8B57-E51F612DF6BD@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/CGn08ybzSfFsEVEnmHXlZvUK7KQ>
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 03:53:27 -0000

> 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.

randy

v2.23.0 | Report a Bug | By Email