Skip to main content
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026
  • Secretariat restructuring and staffing update

    There have been a few changes in IETF Administration LLC staffing since January of this year (2026) including the recent insourcing of the Secretariat, which are summarised here to give an overall view of the staffing structure.

    30 Jul 2026

Filter by topic and date

Filter by topic and date

Preventing Internet Route Hijack with SIDRops Technology

8 Oct 2025

Route hijack attacks cause malicious rerouting of Internet traffic by exploiting the trusting nature of the Internet’s routing system. During the summer of 2025, a route hijack attack affected the Domain Name System’s (DNS) root servers. If it were more widely deployed, technology developed in the IETF’s Secure Inter-Domain Routing Operations (SIDRops) Working Group could have quickly detected and defeated this attack.

Route Hijack Attacks are not new to the Internet. They cause malicious rerouting of Internet traffic by exploiting Border Gateway Protocol (BGP), which is the technology that enables exchange of routing information across the hundreds of thousands of diverse and independently managed networks—known in autonomous systems (ASes)—that make up the global Internet. With this kind of attack, Internet traffic can be monitored or intercepted, black holed, or directed to unintended destinations.

On 20 June 2025, a significant routing incident occurred that affected the global BGP routing table. This attack specifically concerned address prefixes—which are the parts of an IP address that specifies an Internet-connected network and in BGP is used to let other networks know where to route network traffic—for several DNS root servers. Routes for these critical prefixes were observed originating from an unauthorized AS.

These illicit routes were broadcast by the unauthorized AS to its peer ASes, and remained active in the global routing system for approximately 90 minutes. During this critical window, the DNS queries originating from some systems within the geographic region where the unauthorized AS was operating were erroneously directed to unauthorized root name servers. This misdirection of DNS traffic has serious implications for Internet stability and security, as it could lead to manipulated domain name resolution, potential data interception, and service disruptions for users relying on those affected DNS services.

The result is that Internet users might connect to web, email, or other servers not controlled by the expected organizations because the responses to their DNS queries provided by the unauthorized root servers were bogus.

The following figure provides a snapshot obtained from the RIPE NCC's BGPlay system, showing a bogus route advertisement from the unauthorized AS for one of the DNS root prefixes.

route-hijack-figure
A snapshot obtained from the RIPE NCC's BGPlay system, showing a bogus route advertisement.

Broader deployment of existing technologies developed in the IETF would thwart similar future attacks.

The IETF SIDR Operations (SIDRops) Working Group has been working for years on Route Origin Validation (ROV) [RFC8893] as a way to authenticate route advertisement as coming from an expected AS. More specifically, a digitally signed Route Origin Authorization (ROA) [RFC9582] identifies the ASes that are allowed to originate routes for specific BGP prefixes, and the signature can be validated with certificates from the Resource Public Key Infrastructure (RPKI) [RFC7115]. If ROV was used to check the announcements from the unauthorized AS, the attack would have failed from the beginning since peer ASes would have discovered that the prefix was being announced by an unauthorized AS. Peers would have simply ignored the unauthorized announcement, with no impact on the routing table, hence completely preventing the attack. 

SIDRops is going further, working on Autonomous System Provider Authorization (ASPA), a technology that enables verification of prefix advertisements on intermediate AS, providing protections beyond the origin AS. The deployment of ASPA will further strengthen the robustness of the Internet routing system, greatly reducing the possibility to carry out route hijacks.

If you are interested in learning more about or participating in the work underway to improve the security of the Internet’s routing system, join the SIDRops mailing list.


Share this page