Re: [Sidrops] RIPE NCC RPKI pilot for ASPA objects

[Erik Rozendaal <[e-mail]>]

Hi Sriram,

Thanks for your feedback. We've decided to use the terminology already
present in the RIPE NCC RPKI API for consistency. Since we already
used "ASN" for ROAs we also used this for ASPA in preference over the
RFC use of "AS ID".

With respect to the _afiLimit_ field we felt it was better to be
explicit instead of depending on the absence (or null value). For the
CMS objects it makes sense to use a default value to reduce the size
of the objects, but this consideration doesn't really apply to our
API.

The use of _providers_ vs _ProviderASSet_ is more personal preference
and easier typing.

So, mostly the choices were basically due to consistency with our
existing APIs and personal preference, since we don't follow the RFC
naming currently.

Kind regards,
Erik


> On 6 Dec 2022, at 18:05, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[e-mail]> wrote:
> 
> Hi Erik,
> 
> Thank you for the work. Just for my clarification... why the terminology in the RIPE ASPA configuration API does not seem to match that in the ASPA profile draft (v-11)?
> 
> 'RIPE ASPA configuration API' vs. 'ASPA profile draft':
> customerAsn  <-->  customerASID
> ProviderASSet  <-->  providers
> providerAsn  <-->  providerASID
> afiLimit  <-->  afiLimit  (this matches)
> 
> For the afiLimit, the profile draft (v-11) says... "if present... the value MUST be either 0001 or 0002."
> But the RIPE ASPA configuration API seems to allow a value ANY. The example in your post says: { "providerAsn": "AS64500", "afiLimit": "ANY" }.
> 
> Sriram 
> 
> --------------------------------
> From: Erik Rozendaal <[e-mail]> Mon, 21 November 2022 14:00 UTCShow header
> 
> 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].
> 
> 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.
> 
> Below you can find the description of the RIPE NCC RPKI ASPA
> configuration API. Please contact us at [e-mail] if
> you have any questions or problems.
> 
> # ASPA configuration API
> 
> 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:
> 
> ## 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": "\"PUwiLtHQSA9LqD5mvUW3Rp7WqPCsS28p/5a52N9AcS8=\"",
>      "aspaConfigurations": [{
>          "customerAsn": "AS64496",
>          "providers": [
>              { "providerAsn": "AS64500", "afiLimit": "ANY" }
>          ]
>      }]
>    }
> 
> ## 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. 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:
> 
>    {
>      "ifMatch": "\"PUwiLtHQSA9LqD5mvUW3Rp7WqPCsS28p/5a52N9AcS8=\"",
>      "aspaConfigurations": [{
>        "customerAsn": "AS64496",
>        "providers": [
>            { "providerAsn":"AS64500", "afiLimit": "IPv4" }
>        ]
>      }]
>    }
> 
> 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`: your ASN, which must be part of your certified
> resources.
> 
> `providers`: a non-empty list of objects with two fields:
> `providerAsn` and `afiLimit`.
> 
> `providerAsn`: the ASN of the authorised provider or internet exchange
> point route server.
> 
> `afiLimit`: one of `ANY`, `IPv4`, or `IPv6` (case sensitive) to limit
> the kind of traffic that is authorised.
> 
> # References
> 
> [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-test-environment
> [4]: https://www.ripe.net/support/documentation/developer-documentation/rpki-management-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
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops