ARIN-prop-304: Deprecation of the 'Autonomous System Originations' Field [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

Date: 7 July 2021

Proposal Originator: Job Snijders

Problem Statement:

In the last two decade ARIN has developed multiple services which provide mechanisms for Internet Number Resource holders to publish information about their routing intentions.

The concept of the ‘OriginAS’ field was invented in an era where RPKI did not yet exist. Additionally, back then, ARIN’s Internet Routing Registry (IRR) followed a weak authorization model compared to what’s in use nowadays. The concept of ‘OriginAS’ was an improvement compared the other mechanisms that were available at that time.

As the community’s understanding of BGP routing security best practises matures, a movement towards cryptographically verifiable attestations rather than plain-text interfaces can be observed.

The existence of the ‘OriginAS’ (in addition to RPKI and IRR services) might confuse INR holders, who have to overcome the challenge of figuring out how to publish their routing intentions. Having too many options to choose from (some of which have tangible downsides, as described below) might be detrimental to operations.

Issues with entering data into the OriginAS field:

The semantics of the OriginAS field are unclear: the scope of the field extends to assignment boundaries, not to ‘routing’ boundaries. It is not trival to make it clear through the OriginAS field that one half of the assignment is to be originated by AS X, and the other half of the assignment by AS Y. This leads to a situation where the user will enter both AS X and AS Y for the entire assignment. This problem does not exist in RPKI and IRR, both RPKI and IRR permit to define routing intentions to a more fine-grained and precise level.

Issues with consumption of the OriginAS field:

Consuming the ‘OriginAS’ field in a high-scale automated pipeline is challenging: the consumer needs to enter into a ‘Bulk Whois Data’ agreement with ARIN, then download a multiple-gigabytes XML file (which is only generated once a day), parse this XML, and then extract the OriginAS field. Querying objects one-by-one via the HTTPS interface does not scale well.

Issues with nonverifiability of the OriginAS field contents:

Notwithstanding that the transport to retrieve the Bulk Whois Data file from ARIN’s servers is secured using TLS, it is not possible for consumers of the data to verify whether it was the Resource Holder that entered the values in the OriginAS field, or some other entity.

Policy statement:

Remove Section 3.5 “Autonomous System Originations” of the NRPM in its entirety.

Timetable for implementation: TBD by ARIN. ARIN should take as much time as they deemed requirement to inform the community and facilitate migrations to IRR and/or RPKI.

Policy Term: Permanent

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.