Rough Guide to IETF 94: Routing Security & Resilience Thumbnail
‹ Back
IETF 27 October 2015

Rough Guide to IETF 94: Routing Security & Resilience

Andrei Robachevsky
By Andrei RobachevskySenior Director, Technology Programmes

There is significant work underway across several IETF working groups to ensure the Internet’s infrastructure is more secure and resilient in both the short and long runs. This does not only relate to routing, although it is the focus of this guide, but to all layers and components of the Internet architecture. Several of these groups will meet at IETF 94 in Yokohama next week.

The Secure Inter-Domain Routing (SIDR) WG focuses on securing the global routing system. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to BGP and is an important component of BGP security extensions – BGPSEC, also developed in SIDR WG. This is a key technology for improving trust in the global routing infrastructure.

The two main enhancements to the security of inter-domain routing – Origin Validation (OV) and path validation (BGPSEC) are in a good shape, but a lot of work and attention is given to details now. Since OV was the first component standardized in the IETF, additional considerations come from deployment and operational experience. Examples are RPKI Repository Delta Protocol improving the overall scalability and performance of the system, or an out-of-band protocol proposed to ease setup of the RPKI provisioning and publication protocols between two parties.

There are also more fundamental changes requested, like the proposal to change the certificate validation procedure. Authors of the draft “RPKI Validation Reconsidered“, which has an informational status, replaced it with another, more succinct specification on the standards track updating the RPKI certificate validation procedure as specified in Section 7.2 of RFC6487.

The path validation component – BGPSEC – is maturing, too. The BGPSEC protocol specification is now in its 13th revision and is almost in the WG Last Call. New potential vulnerabilities are found and some clarifications are needed, so this is still work in progress.

There are already implementations of the spec, being developed in parallel with the standardization process! For example, there is running code that adds BGPsec capability to the open source routing daemon BIRD.

But there is a significant threat that SIDR technologies cannot fix: so-called “route-leak.” Simply speaking, this term describes an otherwise valid announcement that nevertheless violates the intended propagation scope. For example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Because it is a policy violation, neither OV nor BGPSEC can detect or mitigate such an “attack.”

In “Methods for Detection and Mitigation of BGP Route Leaks”, the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC. The draft proposes a new Route Leak Protection (RLP) field that operators should set when announcing routes to their customers and peers. Receiving a BGP update that has the RLP field set to ’01’ (‘Do not Propagate Up or Laterally’) for one or more hops in the AS path from a customer or a peer indicates that such announcement represents a “route leak” and should be treated accordingly (e.g. by preferring a valid signed update from a peer or an upstream provider over the customer’s update).

This draft is being discussed in the Inter-Domain Routing Working Group (IDR).

Another working group – Global Routing Operations (GROW), which focuses on operational problems associated with the global routing system – is also active working on issues related to security and resilience of global routing.

Massive Distributed Denial of Service (DDoS) attacks targeting Internet Exchange Point (IXP) members may cause congestion of their peering port(s). In order to limit the impact of such a scenario on legitimate traffic, IXPs adopted a feature called blackholing. A member may trigger blackholing via BGP through the route server. The concept of blackholing at IXPs is similar to blackholing in iBGP scenarios [RFC3882] and the expansion RTBH filtering [RFC5635]. A draft “ BLACKHOLEIXP BGP Community for Blackholing at IXPs” proposes to define a well-known transitive BGP community, to allow an operator to indicate to the IXP route server which routes should be discarded on the switching fabric of the IXP. The draft has been discussed on the mailing list and during IETF 93 and is about to get adopted as a WG document.

Speaking of DDoS attacks, another WG has recently been created – DDoS Open Threat Signaling (DOTS). DDoS attacks are not strictly related to the routing plane of the Internet communication system, but they may have a significant impact on the overall resilience. The goal of the group is to develop a communications protocol intended to facilitate the programmatic, coordinated mitigation of such attacks via a standards-based mechanism. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries.

Related Working Groups at IETF 94

SIDR (Secure Inter-Domain Routing) WG
Tuesday, 3 November, 17:10-18:40, Room 304
Friday, 6 November, 09:00-10:30, Room 303

GROW (Global Routing Operations) WG
Friday, 6 November, 09:00-11:30, Room 303

IDR (Inter-Domain Routing Working Group) WG
Monday, 2 November, 13:00-15:00, Room 502

DOTS (DDoS Open Threat Signaling) WG
Tuesday, 3 November, 13:00-15:00, Room 501

Follow Us

There’s a lot going on in Yokohama, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Photo Credit:
‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

About Internet Society 30 November 2020

Internet Society Continues Strong Support for the IETF’s Critical Work on Open Standards

Open standards and the role they play are an important part of what makes the Internet the Internet. A...

IETF 23 March 2020

IETF 107 Starts Today as a Virtual Meeting

Later today, the 107th meeting of the Internet Engineering Task Force (IETF) will begin its working group sessions in...

IETF 15 November 2019

IETF 106 Begins Nov 16 in Singapore – Here is how you can participate remotely in building open Internet standards

Starting Saturday, November 16, 2019, the 106th meeting of the Internet Engineering Task Force (IETF) will begin in Singapore....

Join the conversation with Internet Society members around the world