ARIN-prop-342: Require newly created AS-SETs to have hierarchical names

Date: 27 March 2025

Proposal Originators: James Bensley

Problem Statement:

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.

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. This can be achieved by enforcing newly created AS-SETs to have hierarchical names. This 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.

To date:

Policy Statement:

The creation of an AS-SET in the ARIN DB requires the AS-SET name to be hierarchical.

By using hierarchical set naming which starts with an AS number, only the maintainer of the AS number is able to create such an AS-SET.

This requirement is not currently 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
  • The second element of the name must be an AS-SET name starting with ‘AS-’
  • Any further elements can be either ASNs or AS-SET names

Timetable for Implementation: TBD