FCC seeks comment on proposed security and reporting requirements for Border Gateway Protocol

Hogan Lovells
Contact

Hogan Lovells

With new authority to regulate broadband internet access service (BIAS) providers following reclassification of BIAS as a Title II service under the Communications Act, the Federal Communications Commission (FCC) advanced a Notice of Proposed Rulemaking (NPRM) that aims to increase the security and integrity of the Border Gateway Protocol (BGP), the information routing infrastructure underpinning the internet. The NPRM would impose obligations on BIAS providers, including a mandate to develop and maintain BGP security plans, and require large providers to file quarterly reports. Questions posed in the NPRM raise the possibility of additional requirements. The NPRM, arriving against the backdrop of ongoing multistakeholder efforts to address BGP vulnerabilities, reflects the FCC’s ongoing efforts to assert its role in ensuring internet security. Interested stakeholders still have an opportunity to engage the FCC on the proposals before the July 17, 2024, comment deadline.


Background

The proposed rules address BIAS providers’ use of the BGP and the Resource Public Key Infrastructure (RPKI). The internet consists of thousands of interconnected, independently administered networks known as Autonomous Systems (AS). The BGP is the global inter-domain routing protocol that facilitates the exchange of reachability information between all of these independently managed ASes.

The BGP has been transformative, but it has limitations. The original design—still widely used today—did not include security features necessary to ensure that information used to route internet traffic is trustworthy and reliable. In particular, the BGP does not include a mechanism to validate either where information originates or the route it is supposed to travel. This lack of foundational security makes the BGP vulnerable to malicious actors who might exploit its weaknesses to redirect internet traffic, disrupt critical services, facilitate theft and espionage, and expose Americans’ personally identifiable information. These concerns are not speculative. Programming errors have resulted in disruptions in the availability of popular services.1 More troubling, malicious actors, including adversary nations, have exploited BGP vulnerabilities.2 The FCC asserts that in today’s economy the centrality of the internet to financial markets, critical utility services, public safety, and defense elevates concerns about BGP security to matters of national security.

Efforts to address BGP security and protect communications infrastructure must ultimately address both origin validation and path validation. The FCC focuses here on improving origin validation using RPKI, which enhances trust in reachability information by supporting cryptographic verification of associations between specific IP address blocks, or autonomous system numbers (ASN’s), and the “holders” of those Internet number resources. The requirements generally favor reporting and transparency over more prescriptive measures, but they would still place new burdens on BIAS providers. The weight of those burdens will be determined by this rulemaking and the parameters of the final rule.                       


BGP Plans

The primary regulatory impact of the NPRM would be a new obligation for all BIAS providers to prepare and maintain an initial BGP Routing Security Risk Management Plan (BGP Plan). A BIAS provider’s BGP Plan would have to: (1) describe and attest to their present and planned future efforts to create and maintain Route Origin Authorizations (ROAs) in the RPKI; (2) include attestations about the extent of their efforts to conduct Route Origin Validation (ROV) filtering at interconnection points with peers and clients; and (3) provide goals and timetables for RPKI implementation. The FCC’s rules would permit risk-based performance plans, but to qualify as BGP Plans, they would have to include the attestations to ROV filtering efforts and describe any other methods available to the BIAS provider. Generally, BIAS providers would not have to file their BGP Plans with the FCC, but they would have to furnish them upon request. All BIAS providers would have to update their BGP Plans annually.

Recognizing the diversity among service providers, the FCC does not propose to establish specific industry-wide substantive requirements for the BGP Plans. For required attestations about ROA efforts and RPKI deployment, the NPRM outlines a range of potential requirements based on whether a BIAS provider controls the IP address prefixes assigned to it and the related route originations. The FCC seeks comment on publicly available tools, including the National Institute for Standards and Technology’s RPKI Monitor, that could provide metrics for measuring ROA registrations and RPKI deployment. For ROV filtering, the proposed rules would require certain large BIAS providers to report the extent to which they have implemented ROV filtering at interconnection points with peers and customers, and the extent to which ROV filtering is turned off or not deployed. The NPRM seeks comment on whether the FCC should require all BIAS providers to include this information in their plans. The FCC also seeks comment on whether it should develop a standardized template for BGP Plans.

The proposed rules would impose further obligations on nine larger BIAS providers, including a requirement to file their initial BGP Plans with the FCC. The large BIAS providers that attest to maintaining ROAs covering at least 90% of originated routes for IP address prefixes under their control would not have to file their annual updates, but they would still have to provide their updated BGP Plans to the FCC upon request.

In addition to the specific questions noted above, the FCC seeks comment on several issues related to the BGP Plan requirement. These questions include among others (1) whether the substantive content in large BIAS providers’ reports should differ from the majority of BIAS providers; (2) whether the FCC should differentiate among tiers of BIAS providers beyond the nine large BIAS providers; and (3) whether and how the content of subsequent BGP Plans might differ from initial plans.


Quarterly Reports

The proposed rules would also require nine large service providers to file quarterly data reports. These quarterly filings, which would be publicly available, would supply the FCC with data that is difficult to aggregate from public sources and allow the FCC to measure progress in ROA registration and maintenance and assess the reasonableness of BGP Plans. BIAS providers would have to report (i) Registry Org_IDs for all AS and address allocations to the service provider; (ii) a list of all Autonomous System Numbers (ASN) held by service provider; (iii) a list of ASNs held by service provider that it uses to originate routes; (iv) a list of address holdings that have been reassigned or reallocated; (v) a list of IP prefixes in originated routes that are covered by ROAs; and (vi) a list of IP prefixes in originated routes that are not covered by a ROA. The quarterly reports would also include ROV-related data, such as the extent of ROV filtering. The FCC seeks comment on whether the quarterly filings should also include information that is not presently available from public sources.


Other Questions Raised by the NPRM

In addition to questions related to the proposals described above, the NPRM also seeks comment on a range of issues related to implementing these requirements and BGP security more generally, including:

  1. whether the FCC should require conditions on current or future service provider contracts to increase ROA registration, which is crucial to efforts to secure the BGP using the RPKI;

  2. deployment goals and timelines for different tiers of service providers;

  3. whether and how to promote and/or require efforts to educate downstream IP address holders about BGP security;

  4. coordination with other agencies and stakeholders; and

  5. alternate security approaches, such as path validation.


Next Steps

This NPRM is the FCC’s first regulatory action to address cybersecurity since it voted to reclassify BIAS as a telecommunications service. It raises important questions regarding the scope of the FCC’s new authority and how the FCC plans to use its authority to address cybersecurity and national security matters.

Stakeholders still have an opportunity to contribute to the development of these policies before the July 17 comment deadline. In addition, parties may file reply comments until August 1, 2024.

1/ Secure Internet Routing, PS Docket 22-90, Notice of Proposed Rulemaking, FCC 24-62 ¶10. In 2020, a Russian telecommunications provider misoriginated routing information, leading to a BGP hijack that caused significant service disruptions across the globe. A 2018 news report revealed that China Telecom mishandled routing announcements for a U.S. telecommunications provider, which led to U.S. internet traffic being routed to one of China Telecom’s networks for two and a half years.

2/ Id. ¶11. Russia allegedly used a BGP hijack to disrupt financial services on the eve of its 2022 invasion of Ukraine. In 2020, a Russian digital services provider diverted traffic from major U.S. based internet platforms through Russia and prevented the data from reaching the intended recipients.

[View source.]

DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Hogan Lovells | Attorney Advertising

Written by:

Hogan Lovells
Contact
more
less

PUBLISH YOUR CONTENT ON JD SUPRA NOW

  • Increased visibility
  • Actionable analytics
  • Ongoing guidance

Hogan Lovells on:

Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Custom Email Digest
- hide
- hide