There is considerable work underway across several IETF working groups to ensure the Internet’s routing infrastructure is more secure and resilient in both the short and long runs. Many of these groups will meet in Prague at IETF 93 next week.
Let me begin, as always, by listing the WGs where security and resilience issues of the global routing system are discussed and solutions are developed. The groups meeting at IETF 93 are: Secure Inter-Domain Routing (SIDR, http://datatracker.ietf.org/wg/sidr/) WG, Global Routing Operations (GROW, http://datatracker.ietf.org/wg/grow/) WG, Inter-Domain Routing Working Group (IDR, http://datatracker.ietf.org/wg/idr/) WG.
Secure Inter-Domain Routing
The SIDR WG focuses 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 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.
For more than a year, participants have been discussing an issue of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries. There is a draft, “RPKI Validation Reconsidered” (http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered), that proposes changes to the certificate validation procedure. While the issue is real, one of the problems is that the implementation of resource transfers in RPKI is not documented and the implications are not clear. To address this, a new draft “Resource Transfer in the Resource Public Key Infrastructure” (https://datatracker.ietf.org/doc/draft-ymbk-sidr-transfer/) has been published and is under discussion.
There are also other types of mistakes a Certificate Authority (CA) or repository operator may make. For example, they may be subject to legal measures that compel actions resulting in generating “bogus” signed objects or removing legitimate repository data. Draft “Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)” (https://datatracker.ietf.org/doc/draft-kent-sidr-adverse-actions/) attempts to catalogue such actions and analyze the implications. It will be discussed in Prague.
BGPSEC
There are some movements in the BGPSEC area, too. The BGPSEC protocol specification is in the Working Group Last Call (draft-ietf-sidr-bgpsec-protocol-11). People found a few omissions that are easy to fix, like insecure Address Family Identifiers (AFI) that allow the attacker to confuse IPv4 and IPv6 prefixes that look the same on the wire.
Extra care needs to be taken when making a significant reconfiguration, like Autonomous System (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 of AS migration within the BGPSEC protocol.
As a matter of fact, this common method is not trivial, 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, an ISP would be required 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 applies to the two drafts I just mentioned. Even if an ISP has redundant connections, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is not satisfactory for applications like Voice Over IP, online gaming, or virtual private networks (VPNs). 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). This draft is now expired because of dependencies on other drafts, not because of the loss of interest, but it is being discussed in the GROW WG.
Routing System Operational Issues
In general, the GROW WG focuses 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 that originally emerged in the SIDR WG is the so-called “route-leaks”. Simply put, 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, unless precautions are taken this results in traffic being passed from one provider to another, bypassing the customer. This sets the stage for a potential Man in the Middle (MITM) attack. Unfortunately none of the solutions developed in the SIDR WG protect against this type of attack, simply because BGP does not have the ability to signal relationships like customer-provider.
In “Methods for Detection and Mitigation of BGP Route Leaks” (http://datatracker.ietf.org/doc/draft-sriram-idr-route-leak-detection-mitigation/) 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’) for one or more hops in the AS path from a customer or a peer will indicate 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).
Massive 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 expands the concept of Remote Triggered Black Hole (RTBH) filtering [RFC5635]. A draft “BLACKHOLEIXP BGP Community for Blackholing at IXPs” (https://datatracker.ietf.org/doc/draft-ymbk-grow-blackholing/) 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 and its implications will be discussed in the GROW WG.
Related Working Groups at IETF 93
SIDR (Secure Inter-Domain Routing) WG
Friday, 24 July, 09:00-11:30, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/93/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/
GROW (Global Routing Operations) WG
Monday, 20 July, 18:50-19:50, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/93/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/
IDR (Inter-Domain Routing Working Group) WG
Monday, 20 July, 17:40-18:40, Grand Hilton Ballroom
Friday, 24 July, 11:50-13:20, Grand Hilton Ballroom
Agenda: https://datatracker.ietf.org/meeting/93/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/