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

Job Snijders <job@fastly.com> Fri, 26 March 2021 21:57 UTC

Return-Path: <job@fastly.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 610F33A11CD for <sidrops@ietfa.amsl.com>; Fri, 26 Mar 2021 14:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
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 sXaxrHVDb4gZ for <sidrops@ietfa.amsl.com>; Fri, 26 Mar 2021 14:57:31 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7586B3A11A6 for <sidrops@ietf.org>; Fri, 26 Mar 2021 14:57:31 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id w3so10556696ejc.4 for <sidrops@ietf.org>; Fri, 26 Mar 2021 14:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qOhaMPNI2RNZE3nNWnCEHQgpotjXu1Rj0EAoZBX1Q+Q=; b=Mi3RoJgPlpofR9WZDzaScbByKI+q4LxU1Mrr+QhnckPXPFHTLUGixhcWJlsubHAO/Y IHgQeWJQ6o1PnPuvbmCyDcpv2yqTi1lgC/kjRlVcsjcLRGuEyxTs5wYa/MfPdFCZ6pqg ybrbCpY9YcHun9sc/GLB7viw+0ZRK9NaoxbNM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qOhaMPNI2RNZE3nNWnCEHQgpotjXu1Rj0EAoZBX1Q+Q=; b=Ob/GO/bY52IKpIiGiuYErIe/hrYPqwbPE7IOaxYjMW8S6nHM2vxrAi2gBctfVf4HOh GiPcYDnhyZY8o2vRB/46eXgezindOLjOCuZZZsSWvI5iN2cQ11mdo3DiRyrBUStQ8hD4 Gt/rWf0n8TGLBFlIfoGT99MMr0C1ohWPQ64je/RwojFn7Wf8yNAyfJSLVb7ykS/QNsYr eHbgPJQPtxAqzu93+Ii0MYJ9BkX3opWBm0qU9HTB8+7k/5KQpzowWl7kKr/HcOgZtoTB Cx+IOXpDGravMp2w6QJRX40ufmmSpZvfRkm/l4y7ohvvizgDN8WjWaxf7/IoQaNF+BWx io3Q==
X-Gm-Message-State: AOAM530OyJEZOKu5affE469ZN8wpqmyZDhSw28wTvyGtCLC0STvItAV2 NLVy/6TNhcRLhguaGfpYXkJ00A==
X-Google-Smtp-Source: ABdhPJxzDYHfhT51FxJnsLtLMtLu81UCbxU/9wuY3TfoaZ4sJYu74hcJfx4xrPhpYWhurjyxqOxclA==
X-Received: by 2002:a17:907:d1f:: with SMTP id gn31mr17311214ejc.536.1616795848362; Fri, 26 Mar 2021 14:57:28 -0700 (PDT)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id b21sm4313954ejv.13.2021.03.26.14.57.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Mar 2021 14:57:27 -0700 (PDT)
Date: Fri, 26 Mar 2021 22:57:26 +0100
From: Job Snijders <job@fastly.com>
To: Randy Bush <randy@psg.com>
Cc: Ties de Kock <tdekock@ripe.net>, SIDR Operations WG <sidrops@ietf.org>, Tim Bruijnzeels <tim@nlnetlabs.nl>
Message-ID: <YF5YxjxVVgjugJHQ@snel>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2tuoxst8t.wl-randy@psg.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/gaPZX6oM8FkzT2w9ZOGRlVkISu4>
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: Fri, 26 Mar 2021 21:57:38 -0000

reminder, this is the 'sidr operations group of 2020/2021'.

> copied from drl's. but those are arbitrary implementations, not
> protocol specifications.

I understand a desire to phrase ideas 'in the abstract' and talk about
protocols as a sequence of communication steps between 'autonomous
systems', rather than reference individual software processes by their
brand name. However, some in this working group are implementing without
any perspective on the entire inter-domain system, and they might
benefit from guidance spelled out in terms such as 'oneshot' and
'server' modes.

To complicate things further, in some RPKI ROV deployments the
'fetcher', 'validator', and 'RTR server' are conflated into a single
software process, which can muddy dialogue at times.

> > Validator implementations which are started in 'oneshot' mode
> > (rpki-client, 'routinator vrps', 'fort --mode=standalone') should
> > immediately try rsync when RRDP fails for one reason or another.
> > 
> > A 'oneshot' implementation should not insert a 'sleep' between a failed
> > rrdp fetch and an attempt to connect using rsync.
> 
> so you argue against ggm's jittered fallover delay?  maybe give us more
> of a hint as to the motivation here.

you hint here https://mailarchive.ietf.org/arch/msg/sidrops/LrNY0v3dy6WQDIrtzazHjhgygh0/

My observation is that unavailability of RRDP service indicates nothing
about the state and availability of a CA Repository's RSYNC service.

The only important thing for me (as Relying Party) is to only spend
bandwidth and CPU on fetching via RSYNC, iff I was NOT able to
successfully fetch from the CA's RRDP service.

Whether the RRDP or RSYNC fetch were successful or not, in the next
fetching event (which is expected to occur between 30 and 60 minutes
later) I should first try fetching from RRDP URIs discovered in the
objects fetched via RSYNC (or fetched via RRDP). If the RRDP fetching
process resulted in some kind of error (HTTP 404, 5xx, connection
refused, DNS problem, etc), I should try to fetch the data via RSYNC
service.

As the world's Relying Parties' software instances were not all booted
at the exact same moment, logically, the collective's fetch events are
not synchronized to any other particular minute of the hour. This is an
excellent characteristic of the existing global RPKI deployment! :)

In retrospect it seems it might have been a mistake to ever even hint
RRDP could be polled every minute.

[ process thought:
    We now have RFC 6481, RFC 8182, draft-ietf-sidrops-prefer-rrdp,
    draft-ietf-sidrops-rov-timing, and now these emails. Confusion might
    be growing instead of being reduced...

    ... would the working group perhaps benefit from a Finite State
    Machine (FSM) specification in which fetches via both RRDP and RSYNC
    protocols are described as events and various timers are also
    described? ]

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

Kind regards,

Job