Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt

Tim Bruijnzeels <tim@nlnetlabs.nl> Mon, 29 March 2021 16:33 UTC

Return-Path: <tim@nlnetlabs.nl>
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 992263A1A49 for <sidrops@ietfa.amsl.com>; Mon, 29 Mar 2021 09:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 R1RJzzN8ANTP for <sidrops@ietfa.amsl.com>; Mon, 29 Mar 2021 09:33:25 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646F63A1A3F for <sidrops@ietf.org>; Mon, 29 Mar 2021 09:33:25 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id F3239600CD; Mon, 29 Mar 2021 16:33:21 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1617035600; bh=THoP72MNSrpawvbHcI/H53TuZt0SRscrSfcTWRx9xIk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DmrUsGPZ3f7AFGS9G6YY8Nj7LU2JwvUXy0fAOUDkTqzO9Hlrt+uT19I1r89IKJZsw lqD4s36PYJpbDnmYfJEussmRN+IexZkxQFmW9fL479nBnF2cdTkQ6AL2g4qEAxU/ZI 2tonqao+Vu8I6/O/PSmzmXJm2blixdLp4inZ6mfNBSgQcvlMZ5GdPhVXcfZwyscapK wVPeuttTEDvNNCdRgQ/h5y8cUJW6Xp5Y8AMvZ3e+jjyg55Udwb7RaWylmA5SG32bnG tqObqAPdPxKRznZ9SfA387vXBdMP5d0O6Jhx6mMY+IK4WnwQhAiKL5oPO3+Sx1Qkk6 TJ7Nybm1sbwmg==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m28s69s2v2.wl-randy@psg.com>
Date: Mon, 29 Mar 2021 18:33:17 +0200
Cc: Job Snijders <job@fastly.com>, SIDR Operations WG <sidrops@ietf.org>, Ties de Kock <tdekock@ripe.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0B7D2C0-4328-47D0-8788-108AC4A1D48D@nlnetlabs.nl>
References: <161403751321.2598.9484858333244233389@ietfa.amsl.com> <76D4E3AD-97BD-40D5-804C-3ED6B875044F@nlnetlabs.nl> <2B8DFACB-E2C6-48F6-B2DF-D762FCAF2384@ripe.net> <YF4Irln8qM4w8i3o@snel> <m2tuoxst8t.wl-randy@psg.com> <YF5YxjxVVgjugJHQ@snel> <m28s69s2v2.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/F_5fcnOVZyH7ZM-Jhi89wPusgAs>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt
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: Mon, 29 Mar 2021 16:33:31 -0000

Hi,

> On 27 Mar 2021, at 04:16, Randy Bush <randy@psg.com> wrote:
> 
>> Is the below the short summary people agree to?
>> 
>> 	- Try RRDP first
>> 	- Immediately fall back to RSYNC if RRDP didn't work
>> 	- Don't contact RRDP URIs more than once every 10 minutes
>> 	- Don't contact RSYNC URIs more than once every 30 minutes
>> 	- Don't contact RRDP or RSYNC URIs less than once ever 60 minutes
> 
> i certainly do not agree to that last line, and doubt you do
> 
> as far as the other numbers, see draft-ietf-sidrops-rpki-rov-timing for
> my current opinion.  but i am willing to listen.

@Job, can you elaborate why you believe that RRDP should not be contacted more frequently than once every 10 minutes?

The idea behind allowing more frequent checking IFF 'if-modified-since' is used (and quite possibly other relevant headers), is that: A) CDNs would not even blink, B) you have a chance of getting updates out more quickly - e.g. you issued a wrong ROA and want to correct it.

Are you worried about stampeding RPs in case they all check this frequently and then fall back together? I.e. there would be less of a spread? Because if this is the main reason, then I would argue that the fix would be to fall back more carefully, rather than tell people not to check RRDP as often.

Ultimately the timing between the RPs and the repositories are only one step in the chain. To get your updates from your intended changing of BGP to other validating routers at least the following steps are involved.
1- Let your RPKI CA update ROAs
2- Let your RPKI CA publish
3- Wait for RPs to synchronise RRDP/rsync
4- Have other routers pick up the changes RTR or other

Ideally I think you would want the whole chain of 1-4 to typically take an amount of time that is comparable to / acceptable wrt BGP convergence. The numbers above talk about step 3 in this chain. I think it's hard to say how much it can or should be optimized - also considering that the other steps take time. My gut feeling says that the 2 minute range for checking - when everything works - is about right. Don't get me wrong, I am not fundamentally opposed to 10 minutes, but I want to understand the reason.

As an aside:
Ultimately, as others have pointed out before me, the only real way to be sure that routers have all the information they need, when they need it would be to look into shipping relevant information in BGP itself. This deals with timing issues, and is much safer with regards to repo availability - the info is in the mesh and decentralized. Obviously this is not feasible in the short term as it's a great deal of work. We would need to define validation for relevant info possibly TLS like with relevant info, perhaps think RTR like integration so that BGP speakers can offload signing to a local signer, as well as validation (perhaps let them use both central repos for bootstrapping as well as updated info in BGP).. many, many discussion I am sure. Still, I think this would be a good path to consider long-term.

Back to now though.. and the more practical question: why 10 minutes?

Regards,

Tim