There is considerable 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. Many of those working groups will be meeting in Dallas, TX, next week at IETF 92.
Let me begin, as always, with listing the WGs where security and resilience issues of the global routing system are discussed and solutions are developed. The groups meeting at IETF 92 are:
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.
A lot of work has been done, and there are quite a few operational deployments. This results in refinements to the protocols and fixing some 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 RPKI Repository Delta Protocol (https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/), which provides relying parties with a mechanism to query a repository for changes, improving the overall scalability and performance of the system compared to the currently used rsync protocol.
Another draft 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. The draft, “RPKI Validation Reconsidered” (http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered), has its next revision, but not much discussion happening despite some disagreements over the proposal within the Working Group.
There are some movements in the BGPSEC area, too. The BGPSEC protocol specification is in the WGLC (draft-ietf-sidr-bgpsec-protocol-11). People found a few omissions that are easy to fix, like unsecure AFI allowing the attacker to confuse IPv4 and IPv6 prefixes that look the same on the wire.
Extra care needs to be taken when making significant reconfiguration, like AS migration when networks are merged, for example. A draft “BGPSec Considerations for AS Migration” (http://tools.ietf.org/html/draft-ietf-sidr-as-migration) discusses this for a common method for AS migration within the BGPSEC protocol.
As a matter of fact such a common method is not trivial and requires some BGP features that are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. Absent these features, it would have required an ISP to coordinate an ASN change with, in some cases, tens of thousands of customers. In particular, as each router is migrated to the new ASN, to avoid an outage due to ASN mismatch, the ISP would have to force all customers on that router to change their router configurations to use the new ASN immediately after the ASN change.
This is addressed in the draft “Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute” (http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration). This draft is being discussed in the IDR WG and is largely parallel to one of the SIDR WG I just mentioned, although addressing different aspects.
Speaking of network reconfigurations and maintenance, one very important requirement is operational continuity, which is also applicable to the two drafts I just mentioned. Even if an ISP has redundant connections, simply taking down or bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications, like Voice Over IP (VoIP), online gaming, or VPN. Therefore, a solution is needed for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. Such a solution is described in a draft “Graceful BGP session shutdown” (draft-ietf-grow-bgp-gshut, now expired because of dependencies on other drafts, not because of the loss of interest), that is being discussed in the GROW WG.
In general, 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 these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “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 – 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 https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definition/.
This time there is not much work related to routing happening in the OPSEC working group. But late last year the IESG approved draft “BGP operations and security” (https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/) as a Best Current Practice (BCP194, RFC7454). This is a very useful document that brings major operational issues and best current practices with regard to routing security. It has gone through a second Working Group Last Call and hopefully is close to be published as a BCP RFC.
Related Working Groups at IETF 92
- SIDR (Secure Inter-Domain Routing) WG
Monday, 23 March, 0900-1130 CDT, Parisian
- GROW (Global Routing Operations) WG
Wednesday, 25 March, 1520-1620 CDT, Parisian
- IDR (Inter-Domain Routing Working Group) WG
Tuesday, 24 March, 1520-1720 CDT, Far East
- OPSEC (Operational Security) WG
Thursday, 26 March, 1740-1840 CDT, Far East
There’s a lot going on in Dallas, 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 http://dev.internetsociety.org/rough-guide-ietf92.