Improving the overall security, efficiency, and resilience of the Internet’s global routing system will be a hot topic at next week’s IETF 91 meeting in Honolulu. In this post, I’ll share a few of the highlights in some of the IETF Working Groups.
As the Internet grows, so grows the routing table, although it doesn’t need to grow as fast. Almost half of the IPv4 routing table (45% for IPv4 and 24% for IPv6, to be precise, see http://bgp.potaroo.net/index-cidr.html) contains redundant information. More specific prefixes are announced along with the covering ones, which is called de-aggregation.
Apart from putting extra burden on routers, this growth may case also instability. See, for instance, some observations of what happened when the IPv4 routing table hit the 512K boundary (http://www.bgpmon.net/what-caused-todays-internet-hiccup/, http://www.renesys.com/2014/08/internet-512k-global-routes/).
Some of the causes of de-aggregation are traffic engineering, security concerns (announcing more specifics to win over potentially hijacked prefixes), or simply configuration mistakes. Is there a technical solution to this problem?
Some people think so. One of the proposals “Filtering of Overlapping Routes” published two years ago is aimed at filtering the overlapping routes (longer prefixes) when the rest of the information is the same for the covering prefix. The proposal was discussed in the GROW WG, but it seems it has not gotten enough traction and was not adopted as a WG item.
And while IPv4 may be a lost cause, shouldn’t we follow the same path with IPv6? Ilijtch van Beijnum observes some of the de-aggregation problems in IPv6 that happen when one organization announces different prefixes to different ISPs from its different units that may be geographically distributed. His draft “Controlled IPv6 de-aggregation by large organizations” proposes some solutions.
Route leaks, a violation of the so-called valley-free routing principle, can undermine security of the routing system by giving an adversary an ability to re-direct traffic targeted to specific destinations. Internet history knows many cases when route leaks caused serious disruptions (see, for instance Geoff Huston’s “Leaking Routes“, or Jim Cowie’s “China’s 18-Minute Mystery“).
This is aggravated by the fact that these anomalies are immune to the solutions being developed in the SIDR WG, i.e. RPKI and BGPSEC (see http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help).
Unfortunately we are still lacking a common definition of the term, making discussion of threats and possible solutions difficult. A new draft “Problem Definition and Classification of BGP Route Leaks” makes such an attempt and will be discussed in the GROW WG.
A companion draft “Methods for Detection and Mitigation of BGP Route Leaks” will be discussed in the IDR and SIDR WGs.
Since the previous IETF, a draft “RPKI Validation Reconsidered” is being discussed in the SIDR WG. The draft reviews the certificate validation procedure specified in RFC6487 and highlights aspects of potentially acute operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement.
To put it simpler, the idea is that if only a subset of the resources specified in the certificate extensions cannot be validated, it doesn’t invalidate the rest of them. From an operational point of view this should increase robustness of the overall system, but it also fundamentally changes the PKI validation process.
In general, as the IETF-developed building blocks are becoming parts of the deployed solutions there is more attention to risks, resilience and robustness of the overall system. Not surprisingly the 2014 ANRP award was given to Sharon Goldberg and her colleagues for the paper “On the Risk of Misbehaving RPKI Authorities“. The paper contains a proposal on how to protect against “Dutch Police Attack” where the RPKI is used for IP prefix takedowns. It is the suspenders proposal that featured in SIDR and will be discussed at the WG session. Depending on the feedback, we may see an I-D.
The development of the BGPSEC protocol continues. And at the upcoming IETF, SIDR and IDR WGs will hold a joint session for the purpose of discussing the BGPSEC protocol.
Of course the utility of the developed building blocks, solutions, and practices is only materialized when they are deployed in operators’ networks. And when we talk about the security and resilience of the global routing system, the deployment should match the global scale of it.
This is where technology meets with social and economic facets of the solution. This is where collaboration, shared responsibility, and individual commitment are essential.
Throughout the history of the Internet, collaboration among participants and shared responsibility for its smooth operation have been two of the pillars supporting the Internet’s tremendous growth and success, as well as its security and resilience. And today we, as a community made another important step in this direction, when leading network operators around the world announced that they have implemented a package of recommended measures that help improve the security and resilience of the global Internet. This “package” is documented in the “Mutually Agreed Norms for Routing Security” (MANRS) and it is live on the Internet: https://www.manrs.org). But more about this in another blog post!
Related Working Groups at IETF 91
SIDR (Secure Inter-Domain Routing) WG
Monday, 10 November 2014, 0900-1130 HST, Coral 1
GROW (Global Routing Operations) WG
Monday, 10 November 2014, 1730-1830 HST, Coral 4
IDR (Inter-Domain Routing Working Group) WG
Thursday, 13 November 2014, 1300-1500 HST, Kahili
Friday, 14 November 2014, 0900-1130 HST, Coral 2
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 http://dev.internetsociety.org/rough-guide-ietf91.