From tdekock@ripe.net Tue Jan 16 05:54:18 2024 Return-Path: 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 3D09FC14F5FF for ; Tue, 16 Jan 2024 05:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (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 3aUR5eYMvX2n for ; Tue, 16 Jan 2024 05:54:13 -0800 (PST) Received: from mail-mx-2.ripe.net (mail-mx-2.ripe.net [IPv6:2001:67c:2e8:11::c100:1312]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 BF4B5C14F5E7 for ; Tue, 16 Jan 2024 05:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Message-Id:To:Date:Subject:Mime-Version:Content-Type:From:CC ; bh=iNZ9yv73HsuX7c4QvSDAGE4NLhn7IE1ZcV8vXqanu/o=; b=df5qPQCzdbOnzHs+17dKqCn6 Q7dY8Q+FK9+cXasNxLCKNe9sR0ZVYnDV45dN9FWmoBc8vItRtPH/110QEJbyQa2mGKE0eyDvX9wkv tnJrulkJGKU8Ve+2014BmhUCOc5m8RLA1kPVRFjDRco0ilOO7Bi6xUvv3DuNA4p1HZbaP9+1LFcia f1IxiC53btqV5kyee6J7dt2QTMuPP9Nu1rwAemI64KCIgX6D8ECEQLJXYdQKVRcb7zaCxG0tcWOAP CXPm7lkiMwmZVMq71jD2Gt+xDEj4gYo4lSPXgLLmsRMAqQn1v5FEZW44PdrsNy3vH2cnJLnCYlrdR IHrWQF+F/Q==; Received: from imap-01.ripe.net ([2001:67c:2e8:23::c100:170e]:57700) by mail-mx-2.ripe.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1rPjtL-00GP2d-2C for sidrops@ietf.org; Tue, 16 Jan 2024 13:54:11 +0000 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by imap-01.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1rPjtL-000W3a-21 for sidrops@ietf.org; Tue, 16 Jan 2024 13:54:11 +0000 From: Ties de Kock Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Date: Tue, 16 Jan 2024 14:54:01 +0100 References: <874C815E-DBDE-415F-B7EC-A3F7883F599B@ripe.net> To: SIDR Operations WG In-Reply-To: <874C815E-DBDE-415F-B7EC-A3F7883F599B@ripe.net> Message-Id: <2960298C-8934-4B29-8D61-311558816E57@ripe.net> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1fcf13bc13e54a0362544475030defaed Archived-At: Subject: Re: [Sidrops] RIPE NCC RPKI pilot for ASPA objects X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2024 13:54:18 -0000 We have updated the ASPA profile in the RIPE NCC localcert[1] pilot = environment to the current profile (17) [2]. The changes to the data model in the = new profile required us to make some changes to the API. This change aims to release an API that creates objects according to the = new profile. We will likely introduce other changes to the API (e.g. = changing aspaConfigurations to a map keyed by customer AS) later. Kind regards, Ties ---- # ASPA configuration API The ASPA configuration can only be retrieved and updated in this pilot environment using the RPKI Management API[2]. We updated the two API = endpoints below for the new ASPA profile: ## Retrieve the current ASPA configuration API endpoint: `GET /api/rpki/aspa` Returns a JSON representation of your current ASPA configuration and an `entityTag`. This `entityTag` describes the current version of the configuration. Example response body: { "entityTag": "\"FVK87llN+bGmQTqumtJ4TCeUZHYu02Zo1xiHLOM3FFg=3D\"", "aspaConfigurations": [{ "customerAsn": "AS2121", "providers": [ "AS2123", "AS3333" ] }] } ## Update the ASPA configuration API endpoint: `PUT /api/rpki/aspa` Atomically replaces the current ASPA configuration with the provided configuration. You must provide the `entityTag` of your current = configuration in the `ifMatch` field of the request body. If the provided tag no longer = matches, you will get an `HTTP 412 precondition failed` [5] response. This = mechanism prevents conflicting updates of the ASPA configuration. After the configuration is updated, the RIPE NCC RPKI system will update = the ASPA CMS objects and publish them to the RIPE NCC RPKI repositories. = This process usually takes less than 30 minutes but may be slower, with a = long tail up to the time limit described in our CPS. Example request body: { "entityTag": "\"FVK87llN+bGmQTqumtJ4TCeUZHYu02Zo1xiHLOM3FFg=3D\"", "aspaConfigurations": [{ "customerAsn": "AS2121", "providers": [ "AS3333" ] }] } Note: it is also possible to use the HTTP `ETag`[6] response header and `If-Match`[7] request header instead of the JSON object fields. ## ASPA configuration JSON The ASPA configuration JSON has the following format. All fields are required: `aspaConfigurations`: a (possibly empty) list of ASPA configuration objects with two fields: customerAsn and providers. `customerAsn`: the ASN of the customer for which you model the = providers. This ASN must be part of your certified resources. `providers`: a non-empty list of strings for providers, consisting of = the ASN of the provider prefixed with =E2=80=9CAS=E2=80=9D (e.g. "AS3333"). > On 21 Nov 2022, at 15:00, Erik Rozendaal wrote: >=20 > ASPA (Autonomous System Provider Authorisation[1]) is a new RPKI > object type and the first additional object type supported by the RIPE > NCC RPKI software since its original introduction. ASPA is currently > in draft status, and we implemented draft version 11 of the object > profile [2]. >=20 > We built this ASPA pilot to help the community advance the work in the > IETF SIDR Operations (SIDROPS)working group. The initial version runs > in the RIPE NCC localcert[3] pilot environment, and we plan to make it > available in the production environment soon after the ASPA proposal > reaches RFC status. >=20 > Below you can find the description of the RIPE NCC RPKI ASPA > configuration API. Please contact us at sw-enhancements@ripe.net if > you have any questions or problems. >=20 > # ASPA configuration API >=20 > The ASPA configuration can only be retrieved and updated in this pilot > environment using the RPKI Management API[4]. We added two new API > endpoints for ASPA: >=20 > ## Retrieve the current ASPA configuration >=20 > API endpoint: `GET /api/rpki/aspa` >=20 > Returns a JSON representation of your current ASPA configuration and > an `entityTag`. This `entityTag` describes the current version of the > configuration. >=20 > Example response body: >=20 > { > "entityTag": "\"PUwiLtHQSA9LqD5mvUW3Rp7WqPCsS28p/5a52N9AcS8=3D\"", > "aspaConfigurations": [{ > "customerAsn": "AS64496", > "providers": [ > { "providerAsn": "AS64500", "afiLimit": "ANY" } > ] > }] > } >=20 > ## Update the ASPA configuration >=20 > API endpoint: `PUT /api/rpki/aspa` >=20 > Atomically replaces the current ASPA configuration with the provided > configuration. You must provide the `entityTag` of your current > configuration in the `ifMatch` field. If the provided tag no longer > matches, you will get an `HTTP 412 precondition failed`[5] > response. This mechanism prevents conflicting updates of the ASPA > configuration. >=20 > After the configuration is updated, the RIPE NCC RPKI system will > update the ASPA CMS objects and publish them to the RIPE NCC RPKI > repositories. This process usually takes less than 30 minutes but may > be slower, with a long tail up to the time limit described in our CPS. >=20 > Example request body: >=20 > { > "ifMatch": "\"PUwiLtHQSA9LqD5mvUW3Rp7WqPCsS28p/5a52N9AcS8=3D\"", > "aspaConfigurations": [{ > "customerAsn": "AS64496", > "providers": [ > { "providerAsn":"AS64500", "afiLimit": "IPv4" } > ] > }] > } >=20 > Note: it is also possible to use the HTTP `ETag`[6] response header > and `If-Match`[7] request header instead of the JSON object fields. >=20 > ## ASPA configuration JSON >=20 > The ASPA configuration JSON has the following format. All fields are > required: >=20 > `aspaConfigurations`: a (possibly empty) list of ASPA configuration > objects with two fields: customerAsn and providers. >=20 > `customerAsn`: your ASN, which must be part of your certified > resources. >=20 > `providers`: a non-empty list of objects with two fields: > `providerAsn` and `afiLimit`. >=20 > `providerAsn`: the ASN of the authorised provider or internet exchange > point route server. >=20 > `afiLimit`: one of `ANY`, `IPv4`, or `IPv6` (case sensitive) to limit > the kind of traffic that is authorised. >=20 > # References >=20 > [1]: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/ > [2]: = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification= > [3]: = https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-tes= t-environment > [4]: = https://www.ripe.net/support/documentation/developer-documentation/rpki-ma= nagement-api > [5]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412 > [6]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag > [7]: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops