2022 ARIN Community Grant Program Recipients

Current ARIN Community Grant Program Recipients

2022 Applications

Applications	14
Organization Type	3 associations, 3 corporations, 6 non-profits, 1 Foundation, 1 University
Organization Region	5 United States, 4 Caribbean, 5 outside ARIN region
Category (some projects identified multiple categories)	1 Internet technical improvements, 1 Registry processes and technology improvements, 5 Informational outreach, 8 Research
Total funding requested (USD)	$235,813.60
Average funding requested (USD)	$16,843
Projects selected to receive a grant	3
Total funding provided (USD)	$44,500

Project summaries provided by grant recipients.

Routing Security in the ARIN Region: Studying Trends, Facilitating Data Analysis and Promoting RPKI Adoption

DNS Research Federation
Oxford, United Kingdom
Grant amount: $17,000

Internet routing is a key building block of the Internet’s infrastructure that remains vulnerable to attacks. Resource Public Key Infrastructure (RPKI) has emerged as the leading strategy for securing BGP routing, though the technology has had a slow uptake worldwide, including in North America and the Caribbean. The goal of this project is to promote routing security in the ARIN region by showcasing data on route hijacks and RPKI adoption and encouraging greater academic and industry scrutiny over routing security practices. While there are multiple initiatives that currently measure RPKI adoption and routing security, customized analysis and in-depth academic and industry studies remain challenging due to the complexity associated with data processing. The present project proposes to leverage the Data Analytics Platform of the DNS Research Federation (DNSRF) to facilitate academic and industry data analysis on BGP routing, routing incidents and RPKI adoption. The DNSRF will produce a diagnostic report on the state of RPKI uptake and impact of route hijacks in the ARIN region, highlighting trends and differences across countries in the RIR’s service region, and conduct an outreach campaign to disseminate report results, encourage RPKI adoption and promote the use of the data analytics tool among key stakeholders.

Refactor and Upgrade ntpd’s Extension Field Handling

Network Time Foundation, Inc
Talent, Oregon, USA
Grant amount: $20,000

The NTP Project’s NTP software has been the gold standard for synchronized time since the 1980s. It is the base from which almost all of the IETF NTP Standards have been codified and is the only complete reference implementation of NTP.

The first software release of NTPv4 happened in September of 1997, with the first production release in August of 2001. The NTPv4 protocol included support for “extension fields”, a means to associate additional optional data with an NTP packet. The first use of extension fields was for NTP Autokey, a means to provide ephemeral authentication of NTP packets, using public-key authentication. NTP Autokey was first released sometime between 1997 and 2001, as part of the first releases of NTPv4.

The first draft of the IETF NTPv4 specification was published in July of 2005, and the first draft of the IETF NTP Autokey specification was published in September of 2007.

The IETF NTP specifications used to be based on thoroughly tested and proven code. The extension field code that was originally deployed used what we call the “version 1” data structure. The IETF NTP Autokey specification uses what we call the “version 2” data structure.

Several years’ ago Moore’s Law caught up with some (arguably, in hindsight, poor) design decisions in NTP Autokey, rendering it ineffective. IETF Committee work began on a replacement, and this replacement, Network Time Security, has been accepted as a new IETF Standard. NTS uses the “version 2” extension field data structure.

In order to remain backward- and forward- compatible with the huge number of deployed ntpd instances in the field, the reference implementation of NTP needs to have support for both the version 1 and version 2 extension field formats.

To support NTS and other new use-cases of extension fields, the NTP codebase must upgraded to also support the version 2 extension field format.

This grant will fund the effort to implement, test, and document a carrier-grade improvement to ntpd’s extension field handling, in order to pave the way for our implementation of NTS and other features that require NTP extension fields.

AS112 Project Website Improvements

DNS-OARC
Indianapolis, IN, USA
Grant amount: $7,500

The manually edited AS112 operator listing in its current state is difficult to use to obtain useful and important information for several reasons. First, because it is free form, manually edited HTML, the information provided tends to vary from listing to listing. Some information, such as geographic location or the unicast addresses of public instances, can follow many different formats making searches or other analyses difficult. Some listing data is overlooked when AS112 operators submit their listing information. Additionally, there is no mechanism for garbage collection resulting in defunct instances remaining on the list.

At the same time, the general site information has aged: some links are now broken due to changes in URL structures at remote sites; news items from several years ago have not been integrated into the main body of data; and, the site design and HTML are old, making for a site that presents badly on modern software and is non-navigable by anyone with visual impairment.

OARC will address the issues with the operator listing by obtaining information about AS112 instances at IXPs from the PeeringDB API (OARC and PeeringDB have recently been directing IXP operators and AS112operators alike to use the PeeringDB API to automatically update the AS112 listing there with their data).

Non-IXP instances which are available via the public Internet do not have any such automated maintenance mechanism, but they can be moved to structured data, making it easier to identify missing data and to present them in a more consistent fashion. Garbage collection of IXP instances will thus be automatic, as IXPs updating PeeringDB will automatically delete AS112 instances that are no longer present at their IXP, and operators of public instances will have a structured form to use to submit updates, which will help with obtaining more complete information from them.

As a future development project that is NOT included in this proposal, we expect that more structured data about public instances could be used to regularly probe instances for continued operation. Operators could be contacted for updates, and long-inaccessible instances could be removed.

The remaining issues with the site will be addressed with a general refresh of the information provided, a redesign of the site to use more modern HTML that accounts for the wide variety of devices people use to browse the web, and support for assisted browsing software will be added.

Undertaking this project helps to improve the overall industry by making it easier to participate in—and to support—the AS112 Project, which is instrumental in keeping this category of unwanted traffic from reaching the root or the in-addr.arpa servers operated by ARIN and other RIRs.