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
- [Sidrops] I-D Action: draft-ietf-sidrops-prefer-r… internet-drafts
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Tim Bruijnzeels
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Ties de Kock
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Job Snijders
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Randy Bush
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Randy Bush
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Job Snijders
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Randy Bush
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Tim Bruijnzeels
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-pref… Job Snijders