ISOC Rough Guide to IETF 90: Routing Resilience Thumbnail
‹ Back
IETF 16 July 2014

ISOC Rough Guide to IETF 90: Routing Resilience

Security and resilience are important aspects of IETF work and there are many Working Groups (WGs) that contribute to the Internet routing infrastructure, including:

    • Secure Inter-Domain Routing (SIDR, WG
    • Global Routing Operations (GROW, WG
    • Inter-Domain Routing Working Group (IDR, WG
    • Operational Security (OPSEC, WG

All of these WGs are meeting next week at IETF 90 in Toronto.

Securing Inter-Domain Routing (SIDR)

The SIDR WG is focusing on securing inter-domain routing. 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 routing infrastructure.

RPKI still dominates the discussions. These result in refinements of the protocols and fixing some of the issues. This is a normal cycle of protocol maturity, when operational experience is fed back into the protocol development, leading to improvements.

One such refinement is an update to RFC 6810 that defines the RPKI to router protocol, allowing a router to receive prefix origin data from a trusted cache. The document draft-ietf-sidr-rpki-rtr-rfc6810-bis proposes a few changes based on the group’s discussion at IETF 89.

Other updates include a small change to signature algorithms in RFC 6485 “The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)” and RFC 6490 “Resource Public Key Infrastructure (RPKI) Trust Anchor Locator”, introducing multiple publication points for the Trust Anchor.

Perhaps a bigger change that is being discussed is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries described by the draft “RPKI Validation Reconsidered”. The problem in a nutshell is that in the current model, specified by RFC 6487, a certificate is considered invalid if a proper validation path cannot be built for all resources specified by that certificate. But in operational reality such a situation can occur, for instance, with the resource transfer, when “shrinkage” of the parent certificate will immediately invalidate the whole branch beneath, unless all subordinate certificates are also re-issued. If such a situation happens high in the hierarchy, say at the RIR level, the impact can be pretty severe. The draft also describes alternative approaches, although the focus of the discussion now is on the problem.

There are some movements in the BGPSEC area, too. The Security Requirements for BGP Path Validation document is now under the IESG evaluation and that opens the specification of the BGPSEC protocol itself for discussion. A new version of the spec (draft-ietf-sidr-bgpsec-protocol-09) appeared recently, as it was dormant for some time awaiting the requirements that many participants felt should come first.

The meeting agenda for SIDR WG is pretty full. In addition to the issues I already mentioned, participants will discuss router keying for BGPsec, validation signaling, and various models for ensuring more “checks and balances” in the RPKI system and control of a resource holder over their resources there. The latter come in different flavors: LTA, SLURM, Suspenders. I am sure it will be an interesting discussion.

Global Routing Operations (GROW)

The focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of the items, which originally emerged in the SIDR WG and has now also been discussed in the GROW WG, is so-called “route-leaks”. Simply speaking, this describes a violation of a “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer. This introduces the potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see

Just recently, another draft was submitted that enumerates different types of route leaks based on observed events on the Internet. It illustrates how BGPSEC in its current form already provides protection against all but one of these route-leaks scenarios. It is not yet a WG item, but may get some airtime at the meeting.

Inter-Domain Routing (IDR)

The IDR WG continues to work on better handling of malformed BGP attributes that may cause serious outages, and even cascading effects for other networks. A draft “Revised Error Handling for BGP UPDATE Messages” is aimed at improving the robustness of the BGP. It has already undergone 13 revisions, so the issue appears to be complex.

Operational Security (OPSEC)

Finally, in the OPSEC WG, the draft “BGP operations and security”, which documents operational issues and best current practices with regard to routing security, has gone through a second WG Last Call and is close to being published as a BCP RFC.

In summary, there is a considerable set of work underway across a number of IETF working groups to ensure the Internet’s routing infrastructure is more secure and resilient in both the short and long runs.

Related Working Groups at IETF 90

SIDR (Secure Inter-Domain Routing) WG
(Friday, 25 July, 0900-1130 EDT, Territories Room)

GROW (Global Routing Operations) WG
(Friday, 25 July, 1150-1320 EDT, Ontario Room)

IDR (Inter-Domain Routing Working Group) WG
(Tuesday, 22 July, 0900-1130 EDT, Tudor 7/8 Room)

OPSEC (Operational Security) WG
(Tuesday, 22 July, 1300-1400 EDT, Territories Room)

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. 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

‹ Back

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

Related articles

Rough Guide to IETF 89: Routing Resilience
Rough Guide to IETF 89: Routing Resilience
Improving Technical Security24 February 2014

Rough Guide to IETF 89: Routing Resilience

Security and resilience are important aspects of IETF work and there are many Working Groups (WGs) that contribute to the...

Rough Guide to IETF 88: Routing Resilience
IETF29 October 2013

Rough Guide to IETF 88: Routing Resilience

Security is an important topic for the Internet Engineering Task Force (IETF) in general and at IETF 88 next week in Vancouver in particular....

Rough Guide to IETF 92: Routing Resilience and Security
Rough Guide to IETF 92: Routing Resilience and Security
IETF16 March 2015

Rough Guide to IETF 92: Routing Resilience and Security

There is considerable work underway across a number of IETF working groups to ensure the Internet's routing infrastructure is more...

Join the conversation with Internet Society members around the world