[ARIN-Suggestions] Two Suggestions are now closed

[ARIN]

New responses from ARIN have been posted for suggestions 2025.3: Enforce Hierarchical Naming for AS-SETs and 2008.14: Construct Validated IRR Data and these suggestions are now closed. You may find the original suggestions and the responses from ARIN below. 

 
Regards, 

American Registry for Internet Numbers (ARIN)

------
ACSP Suggestion 2025.3: Enforce Hierarchical Naming for AS-SETs
https://www.arin.net/participate/community/acsp/suggestions/2025/2025-03/

Author: James Bensley   

Description: There is a long running issue of AS-SET names not being unique across authoritative IRR databases. This happens because at the time of AS-SET creation, an authoritative IRR server can’t be sure that the proposed set name doesn’t exist in all other IRR databases.

This creates a problem for resolving IRR servers in particular. Resolving IRR servers typically mirror multiple authoritative IRR databases and as a result contain AS-SET with non-unique names. When a resolving IRR server is queried to compile a prefix or AS path filter list for example, the wrong data may be returned, leading to prefix leaking, or no data may be returned in the case an empty AS-SET is referenced instead of a populated one, resulting in the disconnection of networks.

There has been many incidents over the years, but incidents which relate to hyperscalers are implicitly more visible to the community. MANRS documented the incident with AS-AMAZON back in 2022, https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. At the time of writing Google’s official source for their AS-SET is RADB as documented in their PeeringDB entry https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an empty AS-SET in the RIPE DB https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set. From this we can see this is an ongoing issue.

Not only do name collisions exist, but getting them fixed is extremely difficult because a network operator does not own a specific AS-SET name. AS-SET names are essentially ambiguous, meaning any name can be used, however it has become industry standard practice to use an AS-SET name which easily identifies the network using the AS-SET i.e, AS-AMAZON is used by Amazon. If name squatting takes place intentionally as part of a malicious act, the victim has no rights to get the squatting AS-SET removed, especially if it is in a different IRR DB.

Therefore, there is a need for AS-SET names to be unique across authoritative IRR database, and to authorize the name assigned to the AS-SET, to stop these issues from continuing.

This can be achieved by enforcing newly created AS-SETs to have hierarchical names. Enforcing hierarchical names for AS-SETs doesn’t rectify existing naming collisions, but it stops the problem from growing any larger than it already is.

The change being proposed is that the creation of an AS-SET in the ARIN DB requires the AS-SET name to be hierarchical.

This requirement is not being recommended to be extended to any other set types such as route sets, to keep the scope of this change to a more manageable level. Also, existing AS-SETs will not be renamed due to the massive data inconsistencies this would create, and because there is no way to programmatically determine which ASNs the existing AS-SETs in the ARIN DB relate to. Additionally, the existing AS-SETs which have a non-hierarchical name may continue to do so; editing an existing AS-SET MUST NOT require the maintainer to also rename the set to have a hierarchical name. The scope of the change is simply to disallow the creation of new AS-SETs unless they have a hierarchical set name.

The definition of a hierarchical set name is already defined in RFC 2622 Section 5 (https://www.rfc-editor.org/rfc/rfc2622.html#page-13). A summary is provided below:

- There must be at least one colon (:) character in the name
- The first element of the name must be an ASN
- Any further elements can be either ASNs or AS-SET names

Value to Community: Enforcing hierarchical names for AS-SETs makes the AS-SET name unique because the AS number at the front of the AS-SET is uniquely assigned by the RIR which assigned the AS number. This also authorizes the user of the AS-SET because only the operator of the AS number can create hierarchical AS-SET names which start with that AS number. As a result AS-SET name collisions will no longer be possible for AS-SETs belonging to ASNs managed by the ARIN DB.

To date -

APNIC have implemented this under PROP-151 - https://www.apnic.net/community/policy/proposals/prop-151/
RIPE have implemented this under NWI-19 - https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/
LACNIC implemented this as part of their initial IRR daemon deployment.
If ARIN implement the change then AFRINIC will be the only remaining RIR not enforcing this policy.

Status: Closed   

ARIN Response: Thank you for your suggestion, numbered 2025.3 upon confirmed receipt, asking that ARIN enforce hierarchical naming for AS-SETs created in its IRR. It is our understanding that this change would apply to new AS-SETs only, with no expectation that the rule be retroactively enforced.

We would like to assess community support and interest in this change to establish the priority for this effort. This suggestion will be closed and a community consultation on this matter will be initiated in the near future.

Thank you for participating in ARIN’s Consultation and Suggestion Process.

------------
ACSP Suggestion 2008.14: Construct Validated IRR Data
https://www.arin.net/participate/community/acsp/suggestions/2008/2008-14/

Author: Danny McPherson   

Description: Develop validated IRR data infrastructure constructed from RPKI in coordination with other RIRs. Initial proposals have been submitted to APNIC, RIPE and ARIN PPML. Full text below. I would very much like to see ARIN do this in order to facilitate IRR and RPSL extensions that enable inter-provider route filtering and advertisement authorization.

Status: Closed   

ARIN Response: Thank you for your suggestion, numbered 2008.14 on confirmed receipt, asking that ARIN develop validated IRR data infrastructure constructed from RPKI. Validated IRR was deployed in June of 2020, and on 13 January 2025 we deployed new routing security features that now automatically creates and manages the matching IRR Route Objects based on the ROA prefix and max length configuration.

Because this work is completed, we are closing this suggestion.

Thank you for participating in the ARIN Consultation and Suggestion Process.