Re: [Sidrops] [WG ADOPTION] Adoption call: draft-timbru-sidrops-publication-server-bcp - ENDS 02/08/2024
Claudio Jeker <cjeker@diehard.n-r-g.com> Thu, 08 February 2024 09:34 UTC
Return-Path: <cjeker@diehard.n-r-g.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 4C1BCC18DB8E for <sidrops@ietfa.amsl.com>; Thu, 8 Feb 2024 01:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 EI7rYYCQeeTK for <sidrops@ietfa.amsl.com>; Thu, 8 Feb 2024 01:34:53 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35915C151707 for <sidrops@ietf.org>; Thu, 8 Feb 2024 01:34:51 -0800 (PST)
Received: (qmail 40681 invoked by uid 1000); 8 Feb 2024 09:34:48 -0000
Date: Thu, 08 Feb 2024 10:34:48 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Cc: Tim Bruijnzeels <tbruijnzeels@ripe.net>, Ties de Kock <tdekock@ripe.net>, Russ Housley <housley@vigilsec.com>, IETF SIDRops <sidrops@ietf.org>
Message-ID: <ZcSgOOlIHTMtdcvF@diehard.n-r-g.com>
References: <87h6j1kug1.wl-morrowc@ops-netman.net> <B60D7B39-FA81-45AF-BCBD-2784F91B43C3@vigilsec.com> <ZcFNNfrkMFxKf5hN@snel> <BBE2320C-4525-4713-B4AF-3F00ECD4228A@ripe.net> <ZcIuI7lS1OtOW_xT@snel> <EFFA95AA-F07D-490B-BEC3-0446ED2D3AA2@ripe.net> <ZcJmeFCmU9Txsk7M@snel> <ZcJulgLqKapjnvYn@snel>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZcJulgLqKapjnvYn@snel>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ojOdYfzvm9YPcc8eixDkKEsO9To>
Subject: Re: [Sidrops] [WG ADOPTION] Adoption call: draft-timbru-sidrops-publication-server-bcp - ENDS 02/08/2024
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: Thu, 08 Feb 2024 09:34:58 -0000
On Tue, Feb 06, 2024 at 06:38:30PM +0100, Job Snijders wrote: > Dear all, > > On the topic of the publication best practises, it might be good to > strongly recommend that RRDP notification file, delta files, and > snapshot file all be hosted on the same FQDN. But, AFAIK, the RRDP > specification doesn't actually require this. > > This 'same origin' check was added back in 2021 to rpki-client to guard > against notification files pointing to giant files on open source > mirrors or towards other people's (large) RRDP snapshots. > > Since 2021, the global RPKI publication ecosystem appears to naturally > comply with this informal expectation, as in, the check doesn't appear > to cause friction. > > Thoughts? I strongly agree that all RRDP files MUST be served from the same FQDN. As you mentioned rpki-client already enforces this and I would use language much stronger than "strongly recommend" for this. The RRDP specification should have used relative path names in the notification.xml file but that ship has sailed. Allowing cross-origin URI in notification.xml is just asking for trouble. -- :wq Claudio
- [Sidrops] [WG ADOPTION] Adoption call: draft-timb… Chris Morrow
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Tim Bruijnzeels
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Russ Housley
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Di Ma
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Job Snijders
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Ties de Kock
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Hollyman, Michael
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Job Snijders
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Job Snijders
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Tim Bruijnzeels
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Job Snijders
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Tim Bruijnzeels
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Job Snijders
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Lukas Tribus
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Ties de Kock
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Job Snijders
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Ties de Kock
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Claudio Jeker
- Re: [Sidrops] [WG ADOPTION] Adoption call: draft-… Tim Bruijnzeels
- [Sidrops] Re: [WG ADOPTION] Adoption call: draft-… Job Snijders
- [Sidrops] Re: [WG ADOPTION] Adoption call: draft-… Tim Bruijnzeels
- [Sidrops] Re: [WG ADOPTION] Adoption call: draft-… Christopher Morrow