Re: [Sidrops] Heads-up, almost all caches are about to follow draft-spaghetti-sidrops-rrdp-same-origin

Job Snijders <job@fastly.com> Sun, 14 April 2024 01:01 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 6AC00C14F60F for <sidrops@ietfa.amsl.com>; Sat, 13 Apr 2024 18:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74d2sQgcZZDq for <sidrops@ietfa.amsl.com>; Sat, 13 Apr 2024 18:01:02 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB7C14F5EA for <sidrops@ietf.org>; Sat, 13 Apr 2024 18:01:02 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a51969e780eso274237666b.3 for <sidrops@ietf.org>; Sat, 13 Apr 2024 18:01:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1713056460; x=1713661260; darn=ietf.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7DGfy6vycYrscwUE2C7wkeJr262gA6gqG8xLmcbljiQ=; b=pCHKyc/0DRcKqUPQxu0q2XubnxXKqGXWg2aordhR3eXhtZoWqw+UQ225rMxekhaeIs 2uGuBrxv5q75NH9bahwxNcokOYoQuzKkOmrIw0p5odgMvC9FPE4U7/jjYx5ki92M5vJm /XkSrivMkylCWUEcwmOJaxkIfneI1CpcFfk+U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713056460; x=1713661260; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7DGfy6vycYrscwUE2C7wkeJr262gA6gqG8xLmcbljiQ=; b=rVJ2ptriv1vTaZ6K2FQl3vokatgWQgv0A0lP00CSqg0HTosNQ04IIhnb0todRibp2a U9D7x+etB3aK8dGl4drNKdtkJgflEuSsj8bVWjqFJqT6Y2WkwuXIo+lYlYlpGVlfSDnN Cl+ERU5EPbHcVZH0palXRYibJ4JERzu0HqZA7CaLGt6jc6B9olqAsI9CPYPGcZDIammO p35RQ5EExxZZr4ZQkuOnfx4Tuk+4BUfrt0hWAxjJCJWybdwTBhkBlYj6nUaY4UlsOeXH GB0fXFBmrOb//Dar7pODNTaR0oaH9Co4RjmPf1yu62HcfUTD3oGXhspLITBlI0XOpTmE /OBA==
X-Gm-Message-State: AOJu0YwXF8Pi8HGvdbmmWWSpFeNoGHH8LS9EWBM0jHegtkYRvvzH4aFR jMNTI4MQBcliMGV4mQ+QFfntX0X2NgU+QxsZ5WJPJ0U8/T5nznnoLmPirPgA0kDNVXmjQikiS7l f0xJzxtNRbWYp3jGZDldoGOZ1gvsIMm1WcncV8PgTO7a7ABIIs3XiY22cC5i6mxHHthQkwCg29Q 1p1z4NL10b2ByZE9ysAWWWry9V
X-Google-Smtp-Source: AGHT+IHkIDMBIgQZycn4Yd/Yv0/dLurIKXYRa19pWUpLMCVTVWMsVdDw0ST07tmb0GwssITcivexag==
X-Received: by 2002:a17:907:972a:b0:a51:827d:c99b with SMTP id jg42-20020a170907972a00b00a51827dc99bmr4846360ejc.14.1713056459728; Sat, 13 Apr 2024 18:00:59 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id o7-20020a17090611c700b00a4672fb2a03sm3637876eja.10.2024.04.13.18.00.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Apr 2024 18:00:59 -0700 (PDT)
Date: Sun, 14 Apr 2024 03:00:57 +0200
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <ZhsqyZx615YUkMt2@snel>
References: <ZhgC8e6xzEIRGCUz@snel> <ZhhskMytIRytEHIP@TomH-498551.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZhhskMytIRytEHIP@TomH-498551.lan>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RQfoekE3Q1kmodE_D3Vz5ToTWSA>
Subject: Re: [Sidrops] Heads-up, almost all caches are about to follow draft-spaghetti-sidrops-rrdp-same-origin
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 14 Apr 2024 01:01:06 -0000

Dear Tom, SIDROPS,

On Fri, Apr 12, 2024 at 09:04:48AM +1000, Tom Harrison wrote:
> On Thu, Apr 11, 2024 at 05:34:09PM +0200, Job Snijders wrote:
> > This is an opportunity for RRDP Publishers and other stakeholders to
> > consider the implications and provide feedback on the problem &
> > choosen solution.
> 
> This appears to be a real problem, and the suggested solution makes
> sense.

Thanks

> The draft notes that "In the past 2.5 years no RRDP Repository Servers
> have employed cross-origin URIs in Update Notification Files".  Was
> there some record of cross-origin URIs being used in that way before
> that time, or is the period here just that for which relevant
> logs/records exist?

Good questions! Thank you for asking.

I based this assertion on data from http://www.rpkiviews.org. To be
precise: the rpki-client process execution log files contained in the
'josephine.sobornost.net' tarball archives. I parsed 68,160 unstructured
log files, dating from 06-Dec-2020 until 13-Apr-2024. Interpreting these
files requires some knowledge of the rpki-client program and its
evolution over the years. The data is there, but might not be trivially
accessible.

An important aspect to the 2.5 year retrospective timeframe is that in
October 2021 Claudio Jeker introduced a 'same-origin policy' check in
rpki-client (this check imposed on RRDP Update Notification File XML
content, but not on HTTP redirects). From an rpkiviews archive log
message parsing perspective, this meant that - from ~ October 2021
onwards, instantiations of 'cross-origin references' were detectable via
an error log message. Additionally, rpki-client always logged HTTP
redirects in 'verbose' mode, so those were captured for some years.

In short, the rpkiviews log files allow to retrospectively assess the
prevalence of cross-origin RRDP references & HTTP redirects in the
ecosystem. Some observations I'd like to share:

Case 1 - HTTP Redirects
=======================

TL;DR - Cross-Origin HTTP redirects are rarely used in practise.

For example, in the period 21-Dec-2022 - March 2024, the Fraunhofer
institute ran (multiple?) experiments, one instance where
https://rpki1.rpki-test.sit.fraunhofer.de/rrdp/notification.xml
redirected to per-request-unique destinations in the form of
https://[RANDOM-UUID].rpki.rpki-test.sit.fraunhofer.de/...  This would
be an example of cross-origin HTTP redirects, and violate the proposed
'same-origin policy', but this repository (as I understand it) exists
for academic purposes. I didn't count that into the "would cause
problems with non-compliance" bucket.

Two other repositories (FQDNs 'chloe.sobornost.net' & 'dev.tw') did or
currently do use redirects on the same FQDN origin, both instances are
compliant with the proposal at hand. 

I didn't see other manifestations of HTTP redirection in the log archive.

Case 2 - RRDP XML Cross-Origin URIs
===================================

TL;DR - Cross-Origin RRDP URI references are rarely used in practise.

As mentioned - in 2021, rpki-client as a validator blocked following
cross-origin URIs when present in RRDP XML. As far as I know this
(non-standard behaviour) hasn't caused any production CA any issues.
But, read on:

>From April 20th, 2022 until May 2nd, 2022 'rpki-rrdp.us-east-2.amazonaws.com'
briefly used cross-origin URIs in its RRDP data. As I understand it
(both from rpkiviews data and having talked to involved staff) this was
their first foray into self-publishing RPKI data. Once AWS staff became
aware that cross-origin URIs in RRDP XML caused an interopability issue
with rpki-client, the URI scheme was adjusted to be 'same origin'. I'm
counting this into the "testing my-first-rpki" bucket.

On July 13th, 2022 - for just a few hours - 'child.rov.koenvanhove.nl'
seemed to use cross-origin URI references. I count this towards the
"existed for academic purposes" bucket.

>From April 9th until 10th, 2023 'rpki.co' seemed to use cross-origin URI
references, might have been part of a migration of sorts. I don't know.

I didn't see other manifestations of cross-origin URIs RRDP in the log
archive.

Closing words
=============

I think a "same-origin policy" in RRDP helps everyone in the ecosystem.

Other vantage points might have different perspectives on HTTP redirects
and RRDP XML content. Should other 'vantage points archiving operators'
conclude very different observations, that would be super interesting to
me, and I'd love to compare notes.

Kind regards,

Job