Reporting on Border Gateway Protocol Risk Mitigation Progress; Secure Internet Routing, 51284-51293 [2024-13048]

Agencies

• FEDERAL COMMUNICATIONS COMMISSION

[Federal Register Volume 89, Number 117 (Monday, June 17, 2024)]
[Proposed Rules]
[Pages 51284-51293]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-13048]


=======================================================================
-----------------------------------------------------------------------

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Part 1

[PS Docket Nos. 24-146, 22-90; RIN 3060-AL83; FCC 24-62; FR ID 225236]


Reporting on Border Gateway Protocol Risk Mitigation Progress; 
Secure Internet Routing

AGENCY: Federal Communications Commission

ACTION: Proposed rule.

-----------------------------------------------------------------------

SUMMARY: In this document, the Federal Communications Commission 
(Commission) seeks to increase the security of the information routed 
across the internet by proposing certain reporting obligations on 
providers of broadband internet access service (BIAS providers) and 
their use of the Border Gateway Protocol (BGP). Internet traffic can be 
disrupted, intercepted, and blackholed--when a service provider drops 
traffic addressed to a targeted IP address or range of addresses by 
redirecting it to a null route--due to either accidental or deliberate 
adversarial manipulation of security vulnerabilities inherent to BGP. 
Together, the intended effect of the plans, filings, and measures the 
Commission proposes would be to mitigate such threats. BIAS providers 
would be required to develop BGP Routing Security Risk Management Plans 
that describe their plans for and progress in implementing security 
measures that utilize the Resource Public Key Infrastructure (RPKI). 
Nine of the largest service providers would be required to file 
specific additional data on a quarterly basis. The FCC also seeks 
comment on issues related to implementing RPKI-based security measures.

DATES: Comments are due on or before July 17, 2024 and reply comments 
are due on or before August 1, 2024. Written comments on the Paperwork 
Reduction Act proposed information collection requirements must be 
submitted by the public and other interested parties on or before 
August 16, 2024.

ADDRESSES: You may submit comments, identified by PS Docket Nos. 24-146 
and 22-90, by any of the following methods:
     Federal Communications Commission's website: https://www.apps.fcc.gov/ecfs/. Follow the instructions for submitting 
comments.
     Mail: Parties who choose to file by paper must file an 
original and one copy of each filing. If more than one docket or 
rulemaking number appears in the caption of this proceeding, filers 
must submit two additional copies for each additional docket or 
rulemaking number. Filings can be sent by commercial overnight courier, 
or by first-class or overnight U.S. Postal Service mail. All filings 
must be addressed to the Commission's Secretary, Office of the 
Secretary, Federal Communications Commission. Commercial overnight mail 
(other than U.S. Postal Service Express Mail and Priority Mail) must be 
sent to 9050 Junction Drive, Annapolis Junction, MD 20701. U.S. Postal 
Service first-class, Express, and Priority mail must be addressed to 45 
L Street NE, Washington, DC 20554.
    Effective March 19, 2020, and until further notice, the Commission 
no longer accepts any hand or messenger delivered filings. This is a 
temporary measure taken to help protect the health and safety of 
individuals, and to mitigate the transmission of COVID-19. See FCC 
Announces Closure of FCC Headquarters Open Window and Change in Hand-
Delivery Policy, Public Notice, DA 20-304 (March 19, 2020). https://www.fcc.gov/document/fcc-closes-headquarters-open-window-and-changes-hand-delivery-policy.
    People with Disabilities. To request materials in accessible 
formats for people with disabilities (braille, large print, electronic 
files, audio format), send an email to [email protected] or call the 
Consumer & Governmental Affairs Bureau at 202-418-0530 (voice), 202-
418-0432 (TTY).

FOR FURTHER INFORMATION CONTACT: George Donato, Associate Division 
Chief, Cybersecurity and Communications Reliability Division, Public 
Safety and Homeland Security Bureau, (202) 418-0729, or by email to 
[email protected]; or James Zigouris, Attorney-Advisor, 
Cybersecurity and Communications Reliability Division, Public Safety 
and Homeland Security Bureau, (202) 418-0697, or by email to 
[email protected]; or Bradley Rosen, Attorney-Advisor, 
Cybersecurity and Communications Reliability Division, Public Safety 
and Homeland Security Bureau, (202) 418-0226, or by email to 
[email protected]. For additional information concerning the 
Paperwork Reduction Act information collection requirements contained 
in this document, send an email to [email protected] or contact Nicole 
Ongele, Office of Managing Director, Performance Evaluation and Records 
Management, 202-418-2991, or by email to [email protected].

SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Notice 
of Proposed Rulemaking (NPRM), PS Docket Nos. 24-146 and 22-90; FCC 24-
62, adopted June 6, 2024, and released June 7, 2024. The full text of 
this document is available by downloading the text from the 
Commission's website at: https://www.fcc.gov/document/fcc-proposes-internet-routing-security-reporting-requirements-0. When the FCC 
Headquarters reopens to the public, the full text of this document will 
also be available for public inspection and copying during regular 
business hours in the FCC Reference Center, 45 L Street NE, Washington, 
DC 20554. To request materials in accessible formats for people with 
disabilities (Braille, large print, electronic files, audio format), 
send an email to [email protected] or call the Consumer & Governmental 
Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (TTY).
    Ex Parte Rules--Permit-But-Disclose: This proceeding shall be 
treated as a ``permit-but-disclose'' proceeding in accordance with the 
Commission's ex parte rules, with a limited exception described in the 
following paragraph. 47 CFR 1.1200, 1.1206. Persons making ex parte 
presentations must file a copy of any written presentation or a 
memorandum summarizing any oral presentation within two business days 
after the presentation (unless a different deadline applicable to the 
Sunshine period applies). Persons making oral ex parte presentations 
are reminded that memoranda summarizing the presentation must (1) list 
all persons attending or otherwise participating in the meeting at 
which the ex parte presentation was made, and (2) summarize all data 
presented and arguments made during the presentation. If the 
presentation consisted in whole or in part of the presentation of data 
or arguments already reflected in the presenter's written comments, 
memoranda or other filings in the proceeding, the presenter may provide 
citations to such data or arguments in his or her prior comments, 
memoranda, or other filings (specifying the relevant page and/or 
paragraph numbers where such data or arguments can be found) in lieu of 
summarizing them in the memorandum. Documents shown or given to 
Commission staff during ex parte meetings are deemed to

[[Page 51285]]

be written ex parte presentations and must be filed consistent with 
Sec.  1.1206(b). In proceedings governed by Sec.  1.49(f) or for which 
the Commission has made available a method of electronic filing, 
written ex parte presentations and memoranda summarizing oral ex parte 
presentations, and all attachments thereto, must be filed through the 
electronic comment filing system available for that proceeding, and 
must be filed in their native format (e.g., .doc, .xml, .ppt, 
searchable .pdf). Participants in this proceeding should familiarize 
themselves with the Commission's ex parte rules.
    In order to facilitate the free exchange of exploratory ideas among 
the staff of the federal agencies working toward the critical goal of 
promoting secure internet routing, we find the public interest requires 
a limited modification of the ex parte status in this proceeding. See 
47 CFR 1.1200(a). Communications between the Commission staff and staff 
of the Federal Government entities with a formal role in these internet 
security matters, i.e., Office of the National Cyber Director (ONCD), 
Cybersecurity and Infrastructure Security Agency (CISA), Department of 
Justice (DOJ), Office of the Director of National Intelligence, 
National Institute of Standards and Technology (NIST), and National 
Telecommunications and Information Administration (NTIA) shall be 
exempt from the rules requiring disclosure in permit-but-disclose 
proceedings and exempt from the prohibitions during the Sunshine Agenda 
period. See generally 47 CFR 1.1206, 1.1203. To be clear, while the 
Commission recognizes that consultation with these entities is 
critically important, the Commission will rely in its decision-making 
only on facts and arguments that are placed in the public record for 
this proceeding. To this end, the enumerated Federal Government 
entities, like all interested parties, should submit in the public 
record of this proceeding comments, reply comments, and other 
presentations presenting those facts and arguments they wish the 
Commission to rely on in its decision-making process. If the 
presentation made by staff of one of the federal agencies enumerated 
above is of ``substantial significance and clearly intended to affect 
the ultimate decision,'' the Commission will rely on such presented 
information in its decision-making process only if it coordinates in 
advance with the agency involved to ensure that such agency retains 
control over the timing and extent of any disclosure that may impact 
that agency's jurisdictional responsibilities. See 47 CFR 1.1206(b)(3).
    Paperwork Reduction Act: This document may contain proposed 
modified information collection requirements. Therefore, the Commission 
seeks comment on potential new or revised information collections 
subject to the Paperwork Reduction Act of 1995. If the Commission 
adopts any new or revised information collection requirements, the 
Commission will publish a notice in the Federal Register inviting the 
general public and the Office of Management and Budget to comment on 
the information collection requirements, as required by the Paperwork 
Reduction Act of 1995, Public Law 104-13. In addition, pursuant to the 
Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 
U.S.C. 3506(c)(4), the Commission seeks specific comments on how it 
might further reduce the information collection burden for small 
business concerns with fewer than 25 employees.
    Regulatory Flexibility Act: The Regulatory Flexibility Act of 1980, 
as amended (RFA), requires an agency to prepare a regulatory 
flexibility analysis for notice-and-comment rulemakings, unless the 
agency certifies that ``the rule will not, if promulgated, have a 
significant economic impact on a substantial number of small 
entities.'' The Commission seeks comment on potential rule and policy 
changes contained in the document, and accordingly, has prepared an 
IRFA. The IRFA for this document in PS Docket Nos. 24-146 and 22-90 is 
set forth below in this document and written public comments are 
requested. Comments must be filed by the deadlines for comments on the 
NPRM indicated under the DATES section of this document and must have a 
separate and distinct heading designating them as responses to the 
IRFA. The Commission reminds commenters to file in the appropriate 
dockets: PS Docket Nos. 24-146 and 22-90.
    Providing Accountability Through Transparency Act: Consistent with 
the Providing Accountability Through Transparency Act, Public Law 118-
9, a summary of this document will be available on https://www.fcc.gov/proposed-rulemakings.

Synopsis

Introduction and Background

    1. Today, we are seeking comment on several proposals targeted 
towards improving the security of internet routing, in particular of 
BGP, which, as detailed above includes key vulnerabilities capable of 
impacting this nation's critical infrastructure. We intend these 
proposals to apply to providers of broadband internet access service on 
a mass market retail basis (BIAS), based primarily on our authority 
under Title II of the Communications Act. Our proposals take into 
account our understanding of the current state of industry 
participation in RPKI-based approaches to routing security, including 
the deployment of Route Origin Validation (ROV), from our active and 
continuing engagement on these issues with industry stakeholders and 
other government agencies. In short, there is an apparent wide 
disparity in the percentage of originated routes covered by Route 
Origin Authorizations (ROAs) and limited or incomplete support for ROV. 
Further action is urgently required.
    2. As of May 2024, only 38% of U.S. networks allow for the 
validation of their routing information by registering and maintaining 
ROAs in the RPKI. That figure is derived from data found in 
Cloudflare's Radar, and it is confirmed by data in the MANRS 
Observatory. The MANRS Observatory provides trend data for the 
maintenance of routing information in the RPKI by the networks 
participating in MANRS. There are other measurement tools publicly 
available online that reveal similar data, such as NIST's RPKI Monitor. 
Looking at an earlier date, as of December 2024, 36% of traffic 
originating from non-U.S. Federal Government networks was covered by a 
valid ROA, but less than 1% of traffic originating from U.S. Federal 
Government networks was covered by a valid ROA. Thus, we observe that 
the use of RPKI services across the internet has continued to increase 
over the past several years through service providers seeking to secure 
their BGP architectures. Despite the increasing deployment of RPKI-
based security measures by some service providers in the United States, 
service providers that participate in BGP routing will need to make 
additional progress to reduce exposure to the types of communications 
attacks described and the ensuing risks.
    3. Thus, consistent with comments filed by DOD, DOJ, and CISA in 
response to the Secure internet Routing NOI, we are proposing reporting 
obligations on service providers intended to help assess, prioritize, 
and maintain plans for utilizing the RPKI architecture to further BGP 
operational security. As the agency with regulatory authority in this 
area, we intend to continue our close collaboration with

[[Page 51286]]

other federal agencies which have been actively considering similar 
secure internet routing issues through National Cybersecurity Strategy 
initiatives. We seek comment on how the deployment of RPKI and other 
solutions may promote accountability through collaboration among key 
internet stakeholders, such as private, government, regulated, and 
unregulated entities, and between the United States and our global 
partners. Our proposals are largely focused on the preparation and 
filing of BGP Routing Security Risk Management Plans, but we do seek 
comment on certain additional measures that we believe hold promise for 
facilitating the implementation of RPKI-based routing security.

A. BGP Routing Security Risk Management Plans

    4. We propose to require service providers to prepare and maintain 
BGP Routing Security Risk Management Plans (BGP Plans) describing and 
attesting to the specific efforts they have made, and further plan to 
undertake, to create and maintain ROAs in the RPKI. We expect that 
requiring service providers to prepare plans on how they have and will 
institute RPKI, a solution developed through an open standards setting 
process, can promote participation in the standards setting process. 
The Commission continues to strongly support open standards setting 
processes, and that is also a core goal of strategic objective 4.1 of 
the National Cybersecurity Strategy. We seek comment on the impact that 
our reporting proposals may have on this goal.
    5. Under our proposals, BGP Plans can be risk-based performance 
plans, but would have to describe and attest to the extent to which the 
service provider conducts ROV filtering at the interconnection points 
between the service provider and its peers and clients, as well as 
describe any other methods at their disposal. These plans are to be 
updated on an annual basis. The following subsections discuss which 
service providers would be required to confidentially file their BGP 
Plans with the Commission, in addition to discussing the details that 
we propose should be included in all BGP Plans, whether filed with the 
Commission or not. Should the Commission promote risk-based solutions 
among service providers?
1. Initial BGP Plans
    6. We propose to require certain large service providers to file 
initial BGP Plans with the Commission. In particular, we propose to 
impose this filing requirement on all Tier 1 service providers as well 
as the other most significant service providers, which would currently 
include: AT&T, Inc.; Altice USA; Charter Communications; Comcast 
Corporation; Cox Communications, Inc.; Lumen Technologies, Inc.; T-
Mobile USA, Inc.; Telephone & Data Systems (including US Cellular); and 
Verizon Communications, Inc. These significant providers are likely to 
originate routes covering a large proportion of the IP address space in 
the United States and will play critical roles ensuring effective 
implementation of ROV filtering. The initial BGP plans prepared by 
service providers other than those suggested above would not need to be 
filed with the Commission but should be made available to FCC staff 
upon request. We propose, but seek comment on, a requirement that BGP 
Plans submitted to the Commission should be attested by a corporate 
officer at each service provider.
    7. We seek comment on whether we should require the filing of BGP 
Plans by a different set of service providers than those identified 
above. If so, commenters should explain the reasons for, and factors 
involved with, reaching that determination, and the feasibility of 
using particular metrics. For instance, should only the most 
significant service providers based on number of clients, or number of 
public peers, need to file? Or, should we choose based on other 
criteria, such as several of the following: the size of the address 
space under their control (through legacy ownership or assigned by 
ARIN), the number of customers, or the number of originated routes?
    8. We do not propose in this NPRM to set specific industry-wide 
substantive requirements with industry-wide deadlines. BGP Plans are 
intended to establish a mechanism by which the Commission, working in 
coordination with other federal agencies, can assess a service 
provider's actions to prioritize routing security through use of the 
RPKI architecture, measure its progress over time to evaluate the 
reasonableness of its BGP routing security risk management plan, and 
verify its commitments to following it. In addition, the development of 
BGP Plans by all service providers would be important for securing BGP 
operations in the near term because it would require service providers 
to consider the benefits of creating and maintaining ROAs and 
conducting ROV filtering. We recognize that service providers often 
have different network architectures and different technologies, partly 
as a reflection of the types of customers and services offered, and 
that these differences may have affected the speed with which they have 
deployed RPKI and may affect their plans going forward. We seek comment 
on whether our proposals address these issues and promote the 
implementation of routing security among U.S. service providers. The 
specific BGP Plan requirements concerning ROAs and ROV are discussed 
seriatim. We seek comment generally on whether it would be helpful for 
the Public Safety and Homeland Security Bureau (PSHSB) to develop a 
standardized template for preparing BGP Plans. We also seek comment on 
how service providers should respond if mandatory elements of a BGP 
Plan do not apply to their particular circumstances.
a. Creating and Maintaining Route Origin Authorizations
    9. Registering and maintaining updated ROAs with the appropriate 
internet registry is a critical and necessary step for securing BGP 
operation in the near term. At present, only the holders of specific IP 
address prefixes can register ROAs for originated routes that pertain 
to those prefixes. As a result, a service provider is able to directly 
register and manage ROAs only when it controls the IP address 
prefix(es) in question. An effective path forward must therefore take 
into account the difference in the service provider's route origination 
control over the IP prefix(es) assigned to it by ARIN. The information 
we would require service providers to submit would depend on the 
various categories of IP address prefixes for which a service provider 
can be the route originator. In the subsections below, we discuss the 
different cases that we have observed in which the service provider 
either does or does not control the IP address prefix(es) assigned or 
allocated to it and route originations for the same. We anticipate that 
most service providers will be originating routes for prefixes drawn 
from all these cases. We would evaluate RPKI deployment in each set of 
circumstances differently depending on what type of control the service 
provider has over route originations to various IP address prefix(es).
i. Cases Where the Service Provider Controls the ASNs and IP Address 
Prefix(es)
    10. We first consider where a service provider has full authority 
to register ROAs because it controls the associated IP address 
prefix(es). ROAs are registered with the responsible regional registry, 
which is ARIN for the United States and North America. ARIN assigns

[[Page 51287]]

ASNs and IP address prefixes to the Local Internet Registries (LIRs). 
As set out in the ARIN Manual, LIRs are ``generally ISPs whose 
customers are primarily end users and possibly other ISPs.'' The ISP 
might in turn designate a subset of the IP address space it holds to be 
used by its customers, but in the current ARIN operational convention 
only the original ISP can register ROAs even for reallocated address 
space.
    11. For these cases, we propose that BGP Plans would be required to 
include a detailed description of the service provider's process for 
assessing and prioritizing the creation and maintenance of ROAs which 
cover the routes originating from their networks. We contemplate that 
general statements that a service provider is following a risk-based 
approach would not be sufficient to satisfy the requirement for a 
detailed description. Rather, we believe there should be sufficient 
reporting to understand whether each service provider is taking 
meaningful action to assess its risk posture and that it prioritizes 
implementing protections accordingly. The BGP Plan would incorporate 
and explain in detail factors affecting the service provider's ability 
to register and maintain ROAs for its IP address prefix(es). We seek 
comment on whether a BGP Plan should include specific goals for the 
service provider pertaining to ROA registrations as well as estimated 
timetables for attaining those goals. We seek comment on what criteria 
providers should include in their BGP Plans for measuring progress in 
deployment of BGP origin validation, as well as what specific details 
should be provided to describe the service provider's plans for 
creating and maintaining ROAs going forward. We seek comment as well on 
whether there are alternatives to ROAs or to specific ROA registration 
goals that would ensure continued progress in the implementation of 
RPKI, and if so, what they would be. We propose that the initial BGP 
Plans that are to be filed with the Commission should be filed no later 
than 90 days after the effective date of the requirement.
    12. We seek comment on the criteria by which we should evaluate the 
relevance of individual BGP Plans filed with, or reviewed by, the 
Commission. We recognize, for instance, that different service 
providers are in substantially different positions regarding the extent 
to which they control the ASN and the IP address prefixes that they 
originate. We also understand that some service providers have fewer 
in-house resources available than others. We recognize as well that the 
processes for creating ROAs for legacy number resources originally 
issued to the service provider by an Internet Registry prior to the 
creation of ARIN may raise additional issues, and we seek comment on 
how our proposals may address those issues. Finally, we anticipate 
receiving detailed explanations if a service provider contends that 
``multi-homing,'' traffic engineering, or some other factor 
significantly reduces its ability to increase and maintain ROA coverage 
for IP prefixes they control. Regarding multi-homing, are there 
measures that would facilitate coordinating all necessary ROAs for all 
the ASNs that may originate routes to the same prefix? What are factors 
that might inhibit such coordination? If at least one ROA registration 
of the IP prefix is valid, is that sufficient to protect the IP prefix 
even if there are other invalid registrations for that prefix?
    13. To help ensure that we are accurately measuring and tracking 
the status of ROA registrations, we seek comment regarding the metrics 
offered by several publicly available tools. The NIST RPKI Monitor is 
one example of these tools, but there are others available, too. We 
seek comment on the relative merits of such publicly available tools 
that track the status of ROA registrations covering route originations, 
including their utility in measuring providers' execution of their 
individual BGP Plans. Which, if any, are perceived to be more accurate 
or comprehensive than others? Should the FCC select one tool, based on 
comments submitted, to use to track ROA coverage? Or, should the FCC 
use a subset of public monitoring tools and cross-reference among them 
to track and analyze ROA coverage?
ii. Cases Where the Service Provider Does Not Control the IP Address 
Prefix(es)
    14. We next consider the information we propose to require in an 
initial BGP Plan in cases where we understand that service providers 
are unable to register a ROA because that service provider does not 
control the IP address prefix(es) in question. This apparently can 
happen in three instances: (1) A service provider can contractually 
reassign one or more IP address prefixes to downstream providers or 
other client customers, who are then the entities able to register ROAs 
for those prefixes. (2) A party may obtain its own IP prefix directly 
from ARIN and use the service provider as its upstream provider. (3) A 
party may obtain its own ASN and IP prefix directly from ARIN and 
contract with the service provider to propagate the route. In those 
cases, we understand that the entity which controls the associated IP 
address prefix(es) in the RIR (ARIN), would have to register ROAs for 
those prefixes. In order to implement RPKI-based improvements to BGP 
security architectures successfully and to create a healthy ecosystem, 
it is essential that every entity that controls IP address prefixes 
effects all necessary coordination to register the associated ROAs.
    15. For these cases, we propose to require that a service 
provider's initial BGP Plan describe the status of the ROA 
registrations for routes they originate within these three cases. We 
propose that the BGP Plan explain the reason(s) why the service 
provider is unable to register particular sets of IP prefixes. The Plan 
should also describe in detail the service provider's efforts and plans 
for facilitating the ROA registrations for the IP prefixes that have 
been transferred and not under its control. Among other issues, we 
believe that BGP Plans would need to describe the steps that the 
service provider takes to identify and address cases in which customers 
or clients with their own IP prefixes are multi-homed and the frequency 
it encounters multi-homing. In multi-homing situations where it is the 
responsibility of the customer or client to create and register, rather 
than the service provider, the chances for errors in ROA registration 
may be greater, potentially resulting in the customer's traffic 
becoming blackholed through a given provider. We understand that in 
many cases, the service provider will have direct contractual 
relationships with the holder of the IP address prefixes and will be, 
or can be, made aware of the ROA registration status of those prefixes 
with ARIN. Although the service provider itself is not able at this 
time to register ROAs in these circumstances, we are seeking comment on 
the steps that service providers can or should do to help secure ROAs 
for the IP address space held by downstream clients.
b. Route Origin Validation Filtering
    16. The implementation of ROV is necessary to determine whether 
received route advertisements are legitimate when checked against ROAs 
in the RPKI repositories. ROV is the step in origin validation 
predicated on the existence of ROAs, and is the key action that 
facilitates detection of invalid or unknown route originations that 
indicate a prefix is being incorrectly advertised, either maliciously 
or accidentally, by a service provider or enterprise network. For the 
RPKI to be effective, most if not all service providers will need 
either to conduct ROV filtering in their interconnections

[[Page 51288]]

with other service providers, or to have contractual commitments with 
third parties to have routes propagated to them subject to ROV 
filtering. Moreover, to fully realize the origin validation benefits of 
the RPKI, some service providers may need to perform ROV filtering in 
interconnections with their clients. In this way, the service provider 
examines incoming BGP routing announcements from its peers in addition 
to its clients. In cases where a service provider is downstream from a 
more widely accessed provider (e.g., stub networks), there could be 
great benefits from the downstream provider relying on the ROV 
filtering performed by its upstream provider.
    17. We propose that the BGP Plan of a Tier 1 service provider 
should describe the extent to which it has implemented ROV filtering at 
its interconnection points with its peers as well as its customers, and 
to what extent ROV has been disabled or not deployed within its 
network. We also propose that BGP Plans describe, to the extent 
applicable, any contractual requirements a service provider may have 
for upstream third-parties to provide ROV filtering for incoming 
routes. We seek comment on whether this information would be required 
of all BGP Plans, whether filed with the Commission or made available 
upon request. We believe that this information is likely to be most 
relevant for Tier 3 service providers who do not have peering 
relationships and solely rely on contracts with other upstream service 
providers. We seek comment on the use of this information to monitor 
the effective deployment of ROV.
    18. We also seek comment on two proposals regarding the 
implementation of ROV filtering that potentially may affect the ROV 
information that needs to be included in certain providers' BGP Plans. 
We seek comment, first, on whether it would be sufficient if a 
corporate officer or other responsible official at a Tier 1 service 
provider attests that it supports ROV for all directly connected peers 
with settlement-free access as well as their directly connected 
clients, including other service providers. We seek comment, second, on 
whether it would be sufficient if such official within a Tier 2 service 
provider attests that it is implementing ROV filtering in peering 
relationships with other Tier 2 providers, and have contractual 
relationships with Tier 1 providers that require Tier 1 providers to 
perform ROV filtering on traffic being terminated to the Tier 2 
provider. We seek comment as to whether there are circumstances where 
Tier 2 service providers need not provide ROV support for clients that 
participate in BGP routing. We also seek comment on the extent to 
which, if we adopt such proposals, ROV information needs to be included 
in a provider's BGP Plan.
    19. We recognize that there are no publicly available resources 
that allow comprehensive third-party measurement and validation 
regarding the extent that service providers conduct ROV filtering. 
Third-party measurement methodologies involve some degree of sampling 
and estimation and come with varying strengths and weaknesses. For 
example, APNIC, Cloudflare, and Virginia Tech (RoVISTA), are examples 
of entities which have developed methodologies using various sampling 
techniques to assess the degree of ROV filtering prevalent, and which 
make the resulting assessments public. We propose to monitor a limited 
set of respected consensus methodologies to determine whether the set, 
as a whole, shows consistent trends and patterns. We seek comment on 
whether there are particular approaches or sources that we should 
monitor for determining the extent to which an essential set of service 
providers is performing ROV filtering and executing on its BGP Plan.
    20. We note that there are several publicly available, open-source 
software packages that validate BGP routing information based on 
information stored in the RPKI. We seek comment on the maturity of the 
open-source software used in route validation, the degree to which 
these are currently deployed by service providers, the extent to which 
such deployments verify that secure software design principles 
including testing for trustworthy operation have been utilized, and the 
extent to which such software receives continued support by 
contributors. We seek comment on the inclusion of deployment decisions 
in the BGP Plan, to include mitigation plans in cases where the public 
domain software is no longer supported or available. We also seek 
comment on other validators not listed by ARIN.
2. Subsequent BGP Plans
    21. We propose that subsequent BGP Plans do not need to be filed 
with the Commission by large service providers that file an attestation 
that they have registered and maintained ROAs covering at least 90% of 
originated routes for IP address prefixes under their control. In other 
words, after the initial filings, large service providers that continue 
to have at least 90% of the originated IP address prefixes that they 
control covered by ROAs would not need to submit information about 
their process and future plans for assessing and prioritizing the 
creation and maintenance of ROAs in the RPKI, nor of their plans to 
conduct ROV filtering. Such a service provider, however, would be 
obligated to make its BGP Plan available to the Commission upon request 
from its staff. We anticipate that we may establish specific goals and 
deadlines for ROA registration in the future if progress is deemed 
insufficient after collaboration with federal interagency partners.
    22. We seek comment as to whether the 90% ROA coverage metric is a 
reasonable standard for determining when the large service providers 
identified above should no longer be required to file BGP Plans after 
the filing of their initial plans. Commenters disagreeing with use of 
that standard should propose an alternative standard, along with 
reasons why the alternative better serves the overall purposes of this 
proceeding.
    23. We also seek comment on the content that needs to be included 
in the BGP Plans prepared after the initial Plans. We anticipate that 
subsequent Plans would largely consist of updates to the initial Plans, 
so that the burden of preparing such Plans would be significantly less 
than preparing the initial Plans. We seek comment on that conclusion 
and on what information should be included in subsequent Plans. We seek 
comment on when the requirement to prepare subsequent BGP Plans 
annually should sunset, such as in five years. Would the information 
included in these plans become less important as the RPKI is 
extensively deployed? To that end, we seek comment on the frequency 
with which the Commission should revisit the form and content of BGP 
Plans.
3. BGP Plan Issues for Service Providers Other Than the Largest 
Providers
    24. As discussed above, we are proposing to require service 
providers other than the largest providers as defined in this NPRM to 
prepare their BGP Plans generally in accordance with the same 
provisions. Such service providers would not have to file their BGP 
Plans with the Commission but would still need to make them available 
to the Commission upon receiving a request from its staff. We believe 
that the development of a BGP Plan--even if never requested by the 
Commission--would be important for securing BGP in the near term 
because it would require service providers to consider the benefits of 
creating and maintaining ROAs and conducting ROV filtering. We also 
think that those provisions

[[Page 51289]]

generally take into account the different circumstances of various 
service providers.
    25. Nevertheless, we also seek comment here on whether the 
information that these service providers would need to include in their 
BGP Plans should differ from the information required in the BGP Plans 
filed by the large service providers. If so, what information would not 
be needed, and why? In addition, to what extent should the required 
information change if they have maintained the 90% ROA threshold 
described above during the previous year?
    26. We seek comment as well on whether to adopt significantly 
limited requirements for Tier 3 service providers--that is, those 
service providers that do not have peering relationships with any other 
providers and connect to the internet only through upstream transit 
providers. What information should be included in the BGP Plans 
prepared by such Tier 3 service providers? For instance, would it be 
sufficient for their BGP plans to attest to all of the Org_ID 
information used in ARIN's WHOIS entries and to their ROA registration 
of their IP prefix(es), as well as to whether they have default BGP 
route(s) to their upstream provider(s) that all implement ROV on their 
traffic?

B. BGP Routing Security Information--Quarterly Reports

    27. In addition to the preparation of BGP plans, we propose to 
require a set of the largest service providers as defined in this NPRM 
to file specific data on a quarterly basis, which would be made 
publicly available by provider. We anticipate that such quarterly 
filings would allow the Commission to measure progress in ROA 
registration and maintenance and assess the reasonableness of the 
service provider's BGP Plan (not only on an industry-wide basis but 
also by individual and types of service providers). Tier 1 service 
providers would need to file the quarterly data described in the 
paragraph below, which would show the extent to which the service 
provider has maintained that coverage. We propose that the first 
quarterly report be filed 30 days after the necessary steps are 
concluded to allow the relevant rule to take effect, and not from the 
date of publication of the adopted rule in the Federal Register.
    28. We propose to include, and seek comment on including, the 
following information in quarterly reports concerning both ARIN 
allocated resources (i.e., ASN and IP prefix) and legacy number 
resources originally issued to the service provider by an Internet 
Registry prior to the creation of ARIN: (i) List of all Registry 
Org_IDs for all AS and address allocations to the service provider 
(obtained from WHOIS); (ii) list of all ASNs held by service provider; 
(iii) list of ASNs held by service provider that it uses to originate 
routes; (iv) list of address holdings that have been reassigned or 
reallocated; (v) list of IP prefixes in originated routes that are 
covered by ROAs (grouped by originating AS number); and (vi) list of IP 
prefixes in originated routes that are not covered by a ROA (grouped by 
originating ASN). We seek comment as well on obtaining ROV-related 
data, including the extent to which ROV filtering is performed by the 
Tier 1 service provider for both directly connected peers with 
settlement-free access as well as their directly connected clients, 
including other service providers. We anticipate that much of the 
information requested would not vary by quarter, but that certain key 
data points related to ROA registrations could be tracked on a 
quarterly basis and would promote the Commission's ability to assess 
RPKI trends. We seek comment as well on whether it would be helpful for 
PSHSB to develop a standardized template for quarterly data reporting.
    29. As noted above, there may be special challenges in the cases of 
ROAs for routes pertaining to networks that are multi-homed, and so the 
prevalence of such routes may well be relevant in assessing the 
security of the BGP routing system. To what extent are service 
providers aware of multi-homing scenarios for the routes they 
originate, and can they enumerate and report on these use cases? Are 
there other sources of information on these cases? We believe that 
quarterly reporting is necessary, at least initially, to measure on a 
reasonably timely basis the evolution of RPKI-derived routing security, 
and to determine whether additional steps are needed--whether 
regulatory or otherwise--to encourage continued progress. We also 
believe that the data proposed for collection should be readily 
available within the individual service providers. In addition, once 
collected, it should not be burdensome to be updated on a quarterly 
basis. For instance, ARIN repositories are updated every five minutes, 
and the NIST RPKI Monitor updates its analyses every six hours to 
reflect the corresponding route collector updates. We seek comment as 
to whether the reporting obligations in this context should be reduced 
if a service provider files with the Commission an attestation that--as 
specified above with regard to subsequent BGP Plans--it has achieved 
and maintained ROAs covering at least 90% of originated routes in IP 
address prefixes that it controls. In those cases, would semi-annual or 
annual reporting be sufficient for monitoring that service provider's 
progress toward full RPKI implementation? Would any data reporting be 
necessary? We seek comment on this approach.
    30. In addition, this proposed direct reporting by service 
providers provides data, even though in the public domain, that is 
difficult, if not impossible, to reliably aggregate from publicly 
available sources. For instance, many service providers, especially the 
most widely accessed service providers, possess resources obtained from 
ARIN, including ASNs and IP address prefixes, under a wide variety of 
different Org IDs that are subject to change at any time. In addition, 
each publicly available measurement tool may have its own set of 
approaches and assumptions. We believe that direct reporting by a 
service provider of the requested information would not be burdensome 
because that information should be readily available to it. Reporting 
that information would help ensure that Commission staff and the 
service providers are considering BGP progress from the same set of 
facts. We seek comment on these observations.
    31. We further seek comment on the utility of requiring non-public 
information related to the above, including the following: (i) number 
of invalid routes received from peers and customers; (ii) proportion of 
invalid routes received relative to the total routes received per peer 
and customer; (iii) number of routes filtered in cases where the 
service provider itself implements RPKI-ROV; (iv) number of observed 
instances, if any, where RPKI-ROV processes were shown to incorrectly 
deem routes invalid due to inaccurate ROAs or other reasons; and (v) 
number of origin hijack instances pertinent to routes for service 
providers' address space that were (a) detected and (b) undetected 
during the reporting period.
    32. Service Providers Other Than the Largest Providers. We propose 
that service providers other than the largest providers as defined in 
this NPRM do not need to file quarterly data reports, and we have 
proposed significantly limited data reporting requirements to be 
included in their annual BGP Plans.

[[Page 51290]]

C. Confidential Treatment of BGP Plans and FOIA

    33. We propose to treat the BGP Plans as confidential under our 
rules; we tentatively conclude that such Plans will contain highly 
confidential and competitively sensitive business information that the 
companies would not publicly reveal, and may also contain trade 
secrets. We seek comment on this conclusion, and on whether there are 
any other BGP routing security submissions that we might require that 
should be treated as confidential. We note that, pursuant to Sec.  
0.461(d)(3) of our rules, when the Commission receives a request under 
the Freedom of Information Act (FOIA) for inspection of records that 
are presumed confidential or have been submitted with a request for 
confidential treatment, the custodian of the records shall provide a 
copy of the request to the submitter of the information, who will be 
given 10 calendar days to submit a detailed written statement 
specifying the grounds for any objection to disclosure. If the 
submitter fails to respond, it will be considered to have no objection 
to disclosure. We seek comment on whether this notice process is 
routinely necessary for filings with the Commission of BGP Plan reports 
or of any other submissions we conclude should be treated as 
presumptively confidential. In particular, should staff have 
discretion, upon consideration of all the circumstances, whether to 
initiate the notice process for any such reports or to deny such 
requests, other than from governmental entities that may be granted 
confidential access in connection with their official functions, 
outright? Is there any appreciable possibility, given the competitive 
sensitivity of the information contained in such reports and its 
potential misuse to cause network harm, that a submitter might not 
treat this information as confidential and object to its disclosure? If 
not, what is the benefit of routinely undertaking the notice process? 
Are there particular considerations, for example, the type of 
information requested within the reports or the stated public interest 
purpose for the request, that may militate in favor of disclosure after 
notice to the submitter? Are there objective criteria, such as the age 
of the reports, under which confirmation of the submitter's continued 
confidential treatment of the information and justification of its 
objection to disclosure should always be required? Are there any legal 
limitations on our ability to withhold the reports under Exemption 4 of 
the FOIA without confirming the submitter's objection to a specific 
information request? We invite comment on these and any other questions 
relating to our affording confidential treatment to any such reports.

D. Other Issues

1. Possible Conditions on Service Provider Contracts
    34. Based on our continuous engagement with industry and government 
stakeholders on BGP issues, we understand that a substantial portion of 
IP address prefixes issued by ARIN for the United States are prefixes 
for which service providers cannot register ROAs. As detailed above, 
these prefixes include circumstances in which the service provider has 
contractually reassigned IP prefixes received from ARIN to downstream 
providers or other client customers and therefore no longer controls 
the IP prefix for purposes of ROA registration. These cases also 
include circumstances in which the client customer has obtained the IP 
prefix (and possibly an ASN) directly from ARIN and therefore is the 
party able to register a ROA for those prefixes. In all these 
circumstances, we understand, the service provider has a contractual 
relationship with the holder of the IP address prefixes who is able to 
register ROAs with ARIN.
    35. Given the substantial presence of these situations in the 
United States, it is critical to develop an overall strategy to address 
secure internet routing issues and implement solutions that facilitate 
more widespread registration of ROAs for these prefixes--the 
foundational step necessary to enable RPKI-based BGP security measures 
towards securing the nation's communications from adversaries seeking 
to exploit BGP's inherent vulnerabilities, and thereby promote public 
safety and protect against serious national security threats. We 
propose above that BGP Plans address in detail the steps that a service 
provider is taking to address these issues. We continue to recognize as 
well the continuing importance of outreach and education efforts. 
However, we are concerned that these steps may not be enough.
    36. For instance, from our continuing stakeholder engagement, we 
understand that service providers believe that they are not in a 
position to insist in these situations that client customers register 
ROAs for these IP address prefixes. Unlike some internet participants 
that have successfully adopted policies that require ROA registration 
for interconnection, service providers believe that they are not in a 
position to adopt similar policies and practices because client 
customers are likely to have alternative options for their upstream 
service provider who would not insist that the IP address holder take 
the additional step of registering ROAs.
    37. Because the benefits that the RPKI-based approach to a more 
secure BGP can contribute to national security are so great, we must 
consider all possible tools and options at our disposal in order to 
address these potential collective action issues. We therefore are 
seeking comment on the additional proposals below, which we believe to 
be in line with the whole-of-government approach to ``develop and drive 
adoption of solutions that will improve the security of the internet 
ecosystem and support research to understand and address reasons for 
slow adoption.''
    38. In particular, we seek comment on possible conditions that the 
Commission should require service providers to place on current and 
future contracts. There are three separate cases to consider in this 
context: (i) where the IP address prefix was originally held by the 
service provider holding the ASN, who then reallocated/reassigned the 
prefix to a client; (ii) where the IP address was obtained directly 
from ARIN by the client; and (iii) where the service provider is 
propagating routes where the client has obtained both the ASN and the 
IP address prefixes that are to be originated.
    39. We seek comment in such cases on the possibility of the 
following conditions to address cases where the service provider does 
not hold the IP address prefix in a route without a corresponding ROA: 
(i) prohibiting entry into new contracts unless those contracts contain 
plans for registering ROAs for the originated routes; (ii) requiring 
service providers to insist on ROA registrations by existing clients 
with IP prefixes it has transferred to them, or to ``take back'' any IP 
prefixes it has leased to clients; and (iii) requiring service 
providers, at the time of contract renewal (or after a set period, such 
as two years), to insist on having a plan for ROA registration from 
their client. We are, at the same time, mindful of our goal in this 
proceeding to avoid substantive BGP implementation obligations enforced 
by the Commission in favor of a reporting regime.
    40. Again, we seek to address any potential for collective action 
issues under these circumstances. Would a service provider or its 
customer be likely to encounter any disincentives for the registration 
of ROAs, particularly if, in the absence of any conditions, other 
service providers are free not to do so? We seek comment on the 
likelihood that

[[Page 51291]]

a service provider might lose customers if it wanted to require ROA 
registration (and/or ROV filtering) to be implemented by their peering 
or downstream neighbor. Assuming that a peering or downstream service 
provider (e.g., Tier 3 provider) might well choose a different transit 
provider to connect their customers to the internet if the alternate 
transit provider did not require the downstream service provider to 
register and maintain accurate ROA objects pertaining to its IP address 
prefixes, to what extent can providers of transit or other 
interconnectivity services incorporate mandatory language into the 
corresponding contractual agreements?
    41. To address these potential collective action barriers to 
widespread ROA registration, we seek comment on requiring that 
providers' contracts in these cases to provide for the registration of 
ROAs for the relevant IP address prefixes. For instance, as identified 
above, we seek comment on requiring service providers not to enter into 
new contracts to route traffic unless ROAs are registered for the 
relevant IP address prefixes. Should such contracts also require the 
holder of the IP prefix to maintain the active ROAs? We also seek 
comment on requiring service providers to mandate that clients with 
whom they have a direct contractual relationship to register their IP 
prefixes with ARIN. If a client refuses to register assigned prefixes, 
could a service provider ``take back'' unregistered IP address prefixes 
it has leased to others so as to enable the service provider to 
register ROAs for those prefixes? We recognize possible disruptions in 
certain cases that may outweigh the benefits, and so seek comment on 
imposing certain requirements at the time of contract renewal. In order 
to judge the potential benefits and costs of any such requirements, we 
seek comment on whether general industry standards exist for setting 
the term of any such contracts. We also recognize that any such 
requirement would depend on the provisions and terms of the existing 
contracts, as well as when their contracts are set to renew. We further 
seek comment on the percentage of client contracts that extend beyond 
two years of the publication of this proceeding. For instance, if a 
substantial percentage of contracts are five years or longer, should 
the Commission consider imposing requirements no later than a set time 
period, such as two years from the effective date of the adoption of 
rules.
    42. In summary, we seek comment about the benefits and drawbacks of 
considering these and any other regulatory approaches to encourage the 
creation and maintenance of ROAs in the RPKI through contractual 
requirements between service providers and their customers, and the 
provisioners of internet resources.
2. Possible ROV and ROA Requirements for Service Providers
    43. We have sought comment above on whether the ROV implementation 
content of the BGP Plans of Tier 1 and Tier 2 service providers should 
differ depending on whether they are able to attest to certain ROV 
implementation. We here seek comment on proposals to require certain 
levels of implementation of ROV by Tier 1 and Tier 2 service providers. 
In particular, we seek comment on whether Tier 1 service providers 
should be required to achieve the ROV deployment described above within 
one year of the effective date of such a requirement, and whether Tier 
2 service providers should be required to achieve the ROV deployment 
described above within two years of the effective date. As described 
above, ROV implementation is a critical piece of successful RPKI 
implementation, and we believe that those target dates are reasonable 
given the current state of ROV deployment. We seek comment on whether 
ROV implementation requirements would be consistent with the 
Commission's expressed construction of the proposals contained in this 
NPRM to establish a framework for multistakeholder collaboration 
instead of a rigid regulatory mandate.
    44. In the sections above we propose that the largest service 
providers prepare and file BGP Plans that address the service 
providers' plans for registering and maintaining ROAs in the RPKI. 
Here, we seek comment on whether the Commission should establish goals 
and timelines for the largest service providers to register ROAs 
covering the routes they originate. If so, how should the Commission 
determine reasonably achievable goals and timelines for service 
providers? What factors should we consider in making those 
determinations? Should we set goals and timelines on an individualized 
basis for the largest providers dependent on the service provider's 
individual circumstances? To what extent should the registration of 
certain ROAs in the RPKI be prioritized, and what should be the basis 
for identifying those ROAs and defining reasonable prioritization? Can 
we set meaningful goals and/or timelines on a standardized basis for 
those providers or for all service providers subject to this NPRM? Is 
there a floor below which ROA registration levels should raise 
particular concern regarding whether ROAs registrations are being 
timely deployed? If so, commenters should provide specific suggestions, 
along with justifications.
3. Outreach and Education
    45. We see a clear need for additional education efforts by the 
service providers, various stakeholder groups, ARIN, and governmental 
entities. As described below, we believe that a number of holders of IP 
address prefix(es) do not fully appreciate the importance of 
registering ROAs for their IP address prefix(es) to help protect those 
critical resources from being compromised in the internet routing 
system, with potentially disastrous consequences described in the 
examples above. Education about the substantial benefits of registering 
ROAs is a necessity. To what extent can or should large service 
providers as defined in this NPRM take steps to support ROA 
registration by other, downstream providers? We also think it is 
important to increase the options for holders of IP prefixes to 
register ROAs for those prefixes.
    46. We seek comment in this context on steps we should consider to 
facilitate the creation and maintenance of ROAs in the RPKI. There are 
resources available to help entities of all sizes. For example, the 
RIRs provide guidance to help populate RPKI, including the registration 
and maintenance of ROAs. We seek comment on the extent to which such 
implementation guidance and resources help service providers of all 
sizes create and maintain ROAs over the IP address(es) that they 
originate from their networks. Are there any aspects that would be 
better served or supported by a government-led educational campaign 
seeking to drive awareness of the issue and facilitate increases in the 
proportions of ROAs to route originations in the RPKI repositories? If 
so, would the inclusion of our federal partners, for example, CISA, 
NIST, and ONCD in such a campaign, facilitate driving both awareness of 
the seriousness of the issue, as well as provide educational support 
for the process involved with accurately registering and actively 
maintaining ROAs in the RPKI infrastructure? What would the metric for 
``success'' be for such an educational campaign? Should we request 
volunteers to join workshops to encourage and facilitate the creation 
and maintenance of ROAs? Additionally, how should we treat those cases 
where a downstream service provider holds its own or reassigned IP 
address space?

[[Page 51292]]

    47. We separately seek comment on the extent to which a government-
led educational campaign could facilitate service providers increasing 
their level of ROV filtering on their own networks. Should we consider 
the relative size of the service provider in addition to the Tier 
category to which it might be considered to belong? Should such a 
campaign educate on both ROV filtering and ROA object registration and 
maintenance, or should they target them as separate campaigns? What 
would a metric for ``success'' be for such an educational campaign? 
Should we request volunteers to join workshops to encourage and 
facilitate the use of ROV filtering on certain parts of the networks 
they control?
4. ARIN Processes
    48. ARIN is the RIR serving the United States and other countries 
within its coverage area. It maintains a RPKI repository publication 
point, offers hosted RPKI services, and is the source from which would-
be resource holders/network operators/service providers within the 
United States obtain internet number resources, such as ASNs and IP 
addresses. ARIN is also the entity that enables U.S. service providers 
to register, update, and publish ROAs. Beyond providing additional 
educational materials, conducting workshops, and outreach, ARIN has at 
least two initiatives that could facilitate the uptake of RPKI-based 
routing security measures: (i) ARIN had referred for community 
consultation a question from one of its members, that was filed in the 
form of a ticket, asking if reassigned address space holders can 
register their prefixes with ROAs, and thus take advantage of the 
benefits of RPKI origin validation; and (ii) ARIN is considering 
changes in its ROA creation processes to flag instances where attempted 
ROA registrations raise the possibility of misconfigurations.
5. Beyond RPKI Origin Validation--Further Efforts To Secure Internet 
Routing
    49. Although the regulations proposed with this NPRM focus on 
securing route origination, we seek comment on techniques and 
architecture towards path validation as well. Path validation ensures 
the integrity and authenticity of the AS Path attribute. The only 
standard designed to address issues with path validation and 
plausibility is BGPsec. Implementing this is challenging due to the 
intensive cryptographic operations involved. A less complete guarantee 
on path security is offered by a work-in-progress effort from the IETF, 
known as autonomous system provider authorization (ASPA). This effort 
is designed to detect invalid BGP AS_PATHs by registering ASPA objects 
in the RPKI containing verifiable, attested information as to probable 
ASNs in the path. In addition, the ASPA approach accommodates 
incremental deployment, and ``provides benefits to early adopters in 
the context of limited deployment.'' These methods, however, are still 
undergoing discussion among the academic and standards community and 
are not ready for implementation. Although this NPRM focuses on issues 
with origin validation and the techniques currently available to 
address them, achieving a truly secure routing system will involve 
steps beyond deploying RPKI-based origin validation. We do not propose 
at this time to require service providers to implement measures or 
disclose efforts regarding path validation, but we note that their 
implementation is expected to be a critical, future step that service 
providers would need to take to secure their routing systems. We seek 
comment on the maturity of this work-in-progress and any anticipated 
timeline in which ASPA can be deployed after it has been standardized.

Appendix A

Technical Appendix: Additional Background on Inter-Domain Routing

    1. Information traverses the internet in the data fields of 
internet protocol (IP) packets. Each version of IP (of which there are 
currently two established standards, IPv4 and IPv6) specifies the most 
fundamental formats and semantics of internet data transfer. Every IP 
packet includes a source and destination address, to indicate the 
source and destination of that IP packet, representing the 
corresponding endpoints. These networked endpoints may communicate 
through a medium access layer mechanism if the communicating endpoints 
are on a local area/non-routed network. Alternatively, when the 
networked endpoints are on separate networks, the endpoints communicate 
via IP routers that compile reachability data using routing protocols. 
In any sizable collection of networked endpoints, for reasons of 
resilient design and network management, individual Local Area Network 
segments are connected by IP routers that support one or more routing 
protocols.
    2. Routing protocols implement the signaling mechanisms that 
exchange reachability information between or within independent 
networks, as to destinations available and the network paths by which 
to reach them. There are specialized categories of routing protocols 
for signaling, depending on whether the routing protocols are deployed 
within independent networks (Interior Gateway Protocols or IGPs) or 
between independently managed networks (External Gateway Protocols or 
EGPs). Each category of routing protocol has different performance 
characteristics and functional optimizations. Of the two major 
candidate protocols, Inter Domain Routing Protocol and the Border 
Gateway Protocol (BGP), that were considered for use as EGPs, BGP 
emerged as the ubiquitous deployment choice. As mentioned earlier, the 
internet consists of approximately 70,000 independently administered 
and managed networks at the time of writing. These networks use BGP to 
signal reachability information to reflect both technical priorities 
and business objectives, in terms of permitting a choice of the next 
hop of the path to carry their external traffic. In this way, BGP is 
termed as a ``path vector'' routing protocol. However, since BGP also 
supports business priorities by allowing path selection, BGP is also 
said to support policy based routing.
    3. The networks interconnected by BGP are termed BGP Autonomous 
Systems (ASes) and are referred to by their Autonomous System Numbers 
(ASNs). An AS may include one or multiple separate networks, 
collectively all under the technical administration of a single entity. 
For BGP purposes, a network path is denoted as a string of ASNs termed 
an AS Path. The AS Path is one of the ``BGP path attributes'' or 
control variables used in signaling BGP reachability that influences 
how each BGP speaker selects routes to a specific destination. 
Originally, the AS Path was intended to reflect the initial ASN 
originating an advertisement for a prefix, as well as the succession of 
ASes traversed by a BGP update (the basic BGP message carrying 
signaling information). However, no means were provided to verify 
whether this attribute was correct or false in any way. Deliberations 
on how best to address this type of risk and others have occurred since 
at least 1997. As these and other references cited note, there are 
additional vulnerabilities that go beyond the ones described in this 
section.
    4. A BGP route can be defined as a destination prefix associated 
with a string of BGP Path attributes. Attributes provide the semantics 
that affect how the BGP logic in each BGP speaker processes the routes 
it receives from other BGP speakers. The BGP hijacks referred to in 
this document deal with

[[Page 51293]]

incidents associated with manipulating the AS Path attribute, including 
distorting or falsifying the Origin AS, or the originated route 
specificity. Some of the relatively more well-known routing incidents 
have involved these attack vectors.
    5. Internet addressing conventions have implications for BGP 
routing, since BGP routers advertise the reachability of destination 
addresses to which they can find a path. Reachability information 
exchange occurs by exchanging BGP protocol data units or packets that 
contain the necessary information using the formats and semantics 
specified in BGP standard documents. To allow BGP routing to scale, 
Internet Service Providers (ISPs) are required to aggregate the IP 
address space in the route advertisements they originate into a 
compacted contiguous block that forms the ``network prefix.'' Doing so 
reduces the number of route table entries needed to cover the full 
scope of available internet destinations, thus diminishing the size of 
the routing table in those routers central to routing topology in the 
so-called ``default-free zone.'' Since memory and route look up speeds 
both affect router operation, this form of aggregation allows the 
number of addressable endpoints to grow and the internet to scale while 
still retaining acceptable performance in the routers that carry the 
most comprehensive sets of routes, in effect constituting a 
connectivity core for the internet. However, a route that is more 
specific than one that is aggregated is preferred by the BGP state 
machine, so announcing this will preferentially attract traffic 
relative to a route advertising an aggregate. This attack vector is 
somewhat distinct from AS PATH manipulation and has been used in prior 
BGP hijack incidents as well.
    6. Details of the concepts introduced above are further explained 
in several accessible reference works, including the primer entitled 
``Security of the Internet's Routing Infrastructure,'' issued by the 
Broadband Internet Technical Advisory Group (BITAG). For more 
information beyond the summary descriptions in this section, readers 
are referred to the text on ``Network Routing'' in the Morgan Kaufman 
series in Networking or, for simplified review, the BITAG document as 
well as the OECD publication on routing security.

Federal Communications Commission.
Marlene Dortch,
Secretary.
[FR Doc. 2024-13048 Filed 6-14-24; 8:45 am]
BILLING CODE 6712-01-P