IETF Logo Mail Archive

[Sidrops] Re: [GROW] Peering API Discovery

Tim Bruijnzeels <tbruijnzeels@ripe.net> Fri, 23 August 2024 08:45 UTC

Return-Path: <tbruijnzeels@ripe.net>
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 75B70C14F61F for <sidrops@ietfa.amsl.com>; Fri, 23 Aug 2024 01:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=ripe.net
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 9EPoK29MZLhh for <sidrops@ietfa.amsl.com>; Fri, 23 Aug 2024 01:45:53 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862BDC14F60A for <sidrops@ietf.org>; Fri, 23 Aug 2024 01:45:53 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a8677ae5a35so207982266b.0 for <sidrops@ietf.org>; Fri, 23 Aug 2024 01:45:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripe.net; s=google1; t=1724402752; x=1725007552; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5aH7adFLamkdcmj59v5XvF28JJLixUUIc1v/c430Kl8=; b=nbMXm8c7cDDIvTGgGV8YOqJk5JcXiWclw52dKH8JEwTk1Y38DlCwy95KebutkJ8Kr7 DyrBy6acy9zndXj4O8fjZYkthYnwp+Ub2Aaz6MkjZR+9MSpnUBgBM/dVJkIZi0oH9T77 AE90P17/71OkmKK7XKYCDpSyExmq6jijzpgoelPmSARVVi2RIKI2ul6tgOzbMo62q3CZ 3I0Xda/vDMJktVg2OwCaj/Qt1V/WXrXWs9xuW15Q0roPTdvSvhC1Pc+4Oq/PBxkvemAL x6Y3TWj2rVHkcHjuu4Oa/3QxyQh4Us8hz0oeTIx2PpLKVtDqHDCOqwbGZdlaD8biB0vV LwYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724402752; x=1725007552; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5aH7adFLamkdcmj59v5XvF28JJLixUUIc1v/c430Kl8=; b=e9y+n8n+RR9af7dNBSpCL6CAmBvncinV9MZUSFcXA7QX+LpQNwklfFjHtq1h0NlTOT 8+KKvpZi5BhxkKqL47l7/2uAlECFhKpNp7bPRc+Ni9gwOERDNHKMfaobo2ZgxWabAxro xkVY2PmCLzod4zIwxeRtGNKkGLCM+iTlzbBzpUH2YudNfLQt24K/frjaem0VKxl3lpJl epN0Hr0EqV8ypdS9u4GmY8HJKS0w7Ax2oIsg0lc5+iXMxi8C/8MbZ0Rfeq3g2ELJu17u ggTdnWly3sU3Koe7zJpB5SCt6ZWR+T0CjYnpABNw5wJp98fdQyOhYhXjbe6sU9AU8t1Q z5OQ==
X-Forwarded-Encrypted: i=1; AJvYcCWoUZzLDJUshQDnu0pi89KhcDLN9szjtgtyFcOBK8JO1ULe53FjVVBOo1TC8hEWxh1C68O/RLim@ietf.org
X-Gm-Message-State: AOJu0YyszubsympD6cNaLfThUX/n1ng10Pn5m5wPv3X1YfekZdxlEx4r /fxQeJvgpGzyQrdoGmO+TXaX2g3XTe4PhR+ke+WI0459DqBmFifGsI8G3gXa8QA=
X-Google-Smtp-Source: AGHT+IHEnk8kWlTNt4aMzDRoMe+6Sf5Z9s9NzzDNPCQnhckFDxJL3HtL/xtsvPD+kam7434fZ4c9iw==
X-Received: by 2002:a17:906:f597:b0:a7a:8c8d:40ac with SMTP id a640c23a62f3a-a86a518bd82mr91030866b.4.1724402751816; Fri, 23 Aug 2024 01:45:51 -0700 (PDT)
Received: from smtpclient.apple (2a02-a46d-1a37-0-3141-1b40-aa5d-6afa.fixed6.kpn.net. [2a02:a46d:1a37:0:3141:1b40:aa5d:6afa]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a868f28f122sm227018266b.49.2024.08.23.01.45.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2024 01:45:51 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
From: Tim Bruijnzeels <tbruijnzeels@ripe.net>
In-Reply-To: <CAMEWqGs_ezX7StSZQ8RfBCYnhQXieMH9S9n8xWwB4m1wk1uWNA@mail.gmail.com>
Date: Fri, 23 Aug 2024 10:45:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C460416D-EEDB-4DBD-8606-00AF8ED9BDC3@ripe.net>
References: <CAMEWqGuteXVkJdXfn3Ls4+kFXQ+ZTDFvT23Y7O8iKNJhFfOwng@mail.gmail.com> <BB5B0F75-E4FB-40FB-9A5A-6DB9A9B31FDD@ripe.net> <Zr326KAHIudi-gdh@snel> <E537098A-7502-415C-966E-B64EF5C83DD8@ripe.net> <CAMEWqGs_ezX7StSZQ8RfBCYnhQXieMH9S9n8xWwB4m1wk1uWNA@mail.gmail.com>
To: Q Misell <q@as207960.net>
X-Mailer: Apple Mail (2.3776.700.51)
Message-ID-Hash: WWBRIDLMDRF24GMIVP7AVV4YYA5R47QD
X-Message-ID-Hash: WWBRIDLMDRF24GMIVP7AVV4YYA5R47QD
X-MailFrom: tbruijnzeels@ripe.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Job Snijders <job@fastly.com>, grow@ietf.org, sidrops@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Sidrops] Re: [GROW] Peering API Discovery
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/8r22XyvqKnxGKWjuD9cKvkxJJds>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>

Hi Q, all,

> On 16 Aug 2024, at 11:11, Q Misell <q@as207960.net> wrote:
> 
> > But it’s still not clear to me what the challenge would look like.
> 
> It might help to look over my attempt at defining this in my PR: https://github.com/bgp/draft-ietf-peering-api/pull/30
> 

At a glance… yes something like this would help to make it more clear.

As for the proposed mechanism - I don’t get the full picture yet, and have
not had the time to really dive into it. Generally speaking I think it may also
need an RSC signed by the server to prove its holdership of its ASN. And
you probably need to allow for some time to get an RSC signed by an RPKI
CA (i.e. perhaps don’t expect synchronous signing). Furthermore, you
likely want to use RSCs for an initial handshake only but use some other
token later (but I think this is what OAuth2 will do anyway).

More importantly though, rather than wanting to express a strong opinion
at this point about *how* this should work, I think it’s important *that* this
is specified clearly. Yes, I can wait for a future version of the document :)

Tim

v2.46.0 | Report a Bug | By Email | System Status