Re: [Sidrops] [WG ADOPTION] Adoption call: draft-timbru-sidrops-publication-server-bcp - ENDS 02/08/2024

Job Snijders <job@fastly.com> Wed, 07 February 2024 17:27 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 9D691C14F601 for <sidrops@ietfa.amsl.com>; Wed, 7 Feb 2024 09:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 6f4wjaUN0Xp6 for <sidrops@ietfa.amsl.com>; Wed, 7 Feb 2024 09:27:42 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D3DC6C14F699 for <sidrops@ietf.org>; Wed, 7 Feb 2024 09:27:34 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-511612e0c57so1585084e87.2 for <sidrops@ietf.org>; Wed, 07 Feb 2024 09:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1707326851; x=1707931651; darn=ietf.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8TGVY2g8a8xN+OXU7IzYQEBau7ZfvoqVo5Bdu6P8Mgo=; b=jiVHLTVBUD/puD4gyhZ1uWV7ezUnNc2hQ3W3oUgjto0jJ3WS2o/60/A0x4LcnKTeKu ZePt+DzDM1kity+pc8x56FeIS8iWE/OQz+SKuAjSF9VPFK2kdJmzBLoThIcV+ESKqEf8 g3oCztlJSWCk3JXFFmiTOdlXLOL4wAhwg+60o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707326851; x=1707931651; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8TGVY2g8a8xN+OXU7IzYQEBau7ZfvoqVo5Bdu6P8Mgo=; b=nfNLTBVOmuKtWyNpeYtcpyCVclBqviFU3Z3jwZsuFtZZjw2QAMlhOSLllwj9QOtJ0h jLBzAxlQUUZ9MOV/R8budIIP524ulzePICQX5dVs8kA2EzFBzgvWtKuQ27ECVJlUEGrp 0tYTCBAGXrcH+ZAFfYQCQMdPgN3EkKGEBKybaYxsX8+VjovBRXaK6fMTcUlASCKDuk5R X/a2D9XzraXsDpDUsjQeic2p7dqALwsIFJgpIEf3OGrULICo9fSIQeadfEsng/an5v4m YYhNNx8dmE7wvH+LiE/8gOoa80VXa8rnxcHTOs75phL7fxOaOZh8qur0ZCHLhgaHFocO VSRQ==
X-Gm-Message-State: AOJu0YzDYrjKw6Bw5VanwrNoAxsNJ7R5yb6INDMfo2dilwFeRdLnwvDw 1ivTb+ja9pMRQGaaHac0koTReSVdk+zQJQDnGLn+I+2WXSNpQlc6t2ZI1Uo0VWU=
X-Google-Smtp-Source: AGHT+IF5FiRcReg9PVtdc5m5L58G4hw+5RIICH9RswtCGTGBl9joZwVli5VrLD9pwUD+0KURfWu9ag==
X-Received: by 2002:a19:a418:0:b0:511:4eb4:c4ed with SMTP id q24-20020a19a418000000b005114eb4c4edmr4357719lfc.45.1707326851425; Wed, 07 Feb 2024 09:27:31 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCUzfWnrw8Ue2pssFUPtQKt6bqXgPa+0wV+7GgSvMK9h2iuHGMp+36RtEAPqrnOsewnQvcVMNEq+4Do6bxmKmw==
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id h1-20020a1709063c0100b00a372b38380csm986881ejg.13.2024.02.07.09.27.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 09:27:31 -0800 (PST)
Date: Wed, 07 Feb 2024 18:27:29 +0100
From: Job Snijders <job@fastly.com>
To: Lukas Tribus <lukas@ltri.eu>
Cc: IETF SIDRops <sidrops@ietf.org>
Message-ID: <ZcO9gTKNRgS-mDia@snel>
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> <CACC_My9V8MPQFwkW01Y6B=T-RO5dqb6C0Z21oyTXPVzU9w+ZoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACC_My9V8MPQFwkW01Y6B=T-RO5dqb6C0Z21oyTXPVzU9w+ZoQ@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/wO56LacsYYz6NcFHGM_gCSLrvEY>
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: Wed, 07 Feb 2024 17:27:47 -0000

On Wed, Feb 07, 2024 at 06:01:04PM +0100, Lukas Tribus wrote:
> Maybe only slightly related, but any thoughts on using multiple CDN's ?
> 
> In a TAL file we specify a https and a rsync destination, can multiple
> https destinations be specified?
> 
> Like:
> https://rpki.ripecdn1.net/ta/ripe-ncc-ta.cer
> https://rpki.ripecdn2.net/ta/ripe-ncc-ta.cer
> https://rpki.ripecdn3.net/ta/ripe-ncc-ta.cer
> rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
> 
> I'd guess that using one FQDN/TLD per CDN would be simpler (cheaper)
> to implement (for the PP) as opposed to a "same FQDN/TLD multi-CDN"
> setup, but it sounds like it would not actually work today?

The TAL file is used at a stage before the RRDP protocol comes into
play. The HTTPS/rsync URLs in a TAL point to a 1 kilobyte file (the
Trust Anchor certificate). RFC 8630 section 2.2 permits one or more
URIs. The example you offered is valid syntax in the TAL file format.

The TA operator can use one or more A / AAAA DNS entries to distribute
the load across multiple endpoints. An example:

    $ grep https /etc/rpki/arin.tal
    https://rrdp.arin.net/arin-rpki-ta.cer

    $ dig A rrdp.arin.net +short
    199.71.0.149
    199.5.26.149
    199.212.0.149

    $ dig AAAA rrdp.arin.net +short
    2001:500:31::149
    2001:500:13::149
    2001:500:a9::149

RRDP can come into play when this self-signed Trust Anchor is
downloaded, parsed and validated:

$ openssl x509 -in arin-rpki-ta.cer -inform DER -text -noout \
  | grep -A3 'Subject Information Access'
            Subject Information Access:
                CA Repository - URI:rsync://rpki.arin.net/repository/arin-rpki-ta/
                RPKI Manifest - URI:rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft
                RPKI Notify - URI:https://rrdp.arin.net/notification.xml

The 'RPKI Notify' accessMethod (id-ad-rpkiNotify) is the entrypoint into
RRDP. This element points to the RRDP Notification file.

RFC 8182 section 3.2 permits only once instance of id-ad-rpkiNotify. So
within the current RRDP specification, multiple different FQDNs /
multiple RRDP Notification files can't be done.

Kind regards,

Job