ARIN (American Registry for Internet Numbers) has hosted a number of interesting and helpful webinars this year. We joined the Using ARIN’s RESTful API for IRR webinar excited to learn how to manage multiple IRR records quickly by setting up systems to connect to ARIN’s IRR database using the RESTful API.
Hosted by Jon Worley, Senior Technology Architect at ARIN, the webinar covered how to easily transition from using the IRR-email system to the API, how to access OT&E environment and then how to create, view, update and delete routing objects using REST calls. Routing policy specification language was explained as well as identifying necessary commands and URL structure in REST.
The Using ARIN’s RESTful API for IRR webinar kicked off with a poll to gauge the attendees’ understanding of APIs and routing registries. Responses showed diverse levels of familiarity and experience with IRR and API, so no matter our level of understanding, we knew we weren’t alone. Many attendees expressed that while they have used the API, they were ready to learn how to do it with ARIN.
Once we knew everyone’s experience level, it was time for a helpful breakdown of acronyms and definitions. The first of these acronyms was IRR or Internet Routing Registry. Jon explained IRR as a way to publish information about how you wish your resources to be routed. In essence, IRR achieves route origination security by telling people how to safely get from their network to yours.
Next, Jon described APIs (Application Programming Interface) as a superior way to do calls to a website and get back structured data and payloads. For example, using email is not a great way to convey structured data because many things could go wrong, like weird encoding and extra white space. APIs on the other hand are structured and machine-friendly, offering a superior customer experience.
OT&E (Operation Test and Evaluation) was next on the docket. It is a sandbox with production data backwashed into it around the first of every month. Anything you do during the month will be overwritten during the monthly backwash, so it is not intended to be a place where things stay for long. This tool can be used to automate assignments, reverse DNS management, and is generally a great place to do your testing.
RPSL (Routing Policy Specification Language) was defined as a specified common language for how we talk about routing policy. It is important to note that you don’t need to know RPSL when you publish via ARIN; ARIN asks for information and translates it to RPSL for you. The translation to RPSL is necessary because objects must be properly formatted when using the API. ARIN did this specifically to create a better user experience for those transitioning from IRR-email.
Our last acronym to learn was REST (Representational State Transfer), essentially an architecture that uses HTTP to view, edit, modify and delete records.
Armed with our new level of knowledge, we then learned about methods and when to use them. Jon highly encouraged us to do a GET of an organization record to avoid spending time solving complex problems, only to realize there was a typo in the URL.
He went on to do a live demonstration of this action by using a Chrome plug-in called ARC (Advanced Rest Client), setting his method to GET and inputting a structured URL. It immediately gave him an HTTP 200 and a structured object, letting him know that it worked. It is important to note that almost all of ARIN’s APIs use application/xml as the content type. Once these fields were filled correctly, he clicked send, essentially requesting information about the org ID through the live OT&E. The system returned an XML letting him know that there was no fundamental error within the URL.
Once we verified our URL using ARC, we learned how to automate the creation of route objects. To create a route object, we used the POST method, a structured URL, and input application.rpsl as the content type. When our fields were filled correctly, Jon clicked send and our results were returned which we could then see in our ARIN online account.
We then returned to ARC and updated our method to POST, pasted in our URL, and updated our content type to application.rpsl. Under the body tab, we can see that our object has been put in, but Jon provided an example of how we could delete the body and compose the object in another way. When we clicked send, our object was published and became live. This can be viewed in our OT&E ARIN online account under IRR Object Records.
Modifying is not an option because they honor the object exactly. If you publish something on a web interface, it is considered a structured object which is stored in fields and may not come out in the exact order in which it was desired. So if you want to publish an object exactly as it looks like, you’ll want to use this entry method.
Now that we learned how to create route objects, Jon opened the floor to attendees to ask questions. These questions revealed that IRR-email functionality will be disabled, but has been delayed until March of 2022 to give people time to transition. Another helpful question revealed that API keys can be created in our account manager.
ARIN provided another awesome instructional webinar with an in-depth look at some of ARIN’s functions and services. We look forward to joining more of their webinars as they have an interesting one titled Enhance Your Routing Security using ARIN’s Hosted RPKI coming up later this month.
The Using ARIN’s RESTful API for IRR webinar is available on-demand if you didn’t get a chance to attend when Jon was presenting live.
