Internet Infrastructure Resilience

This issue of the ISOC Rough Guide to IETF 95 includes not only issues related to the

control plane (routing), but also to the data forwarding plane – specifically DDoS attacks. There is interesting and important work underway at IETF 95 in Buenos Aires next week that can help addressing problems in both areas. The Secure Inter-Domain Routing (SIDR, http://datatracker.ietf.org/wg/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 global routing infrastructure. If you look at the agenda, quite a few new proposals are brought to the table and will be discussed in Buenos Aires. Remarkably, most of them are related to the RPKI and Origin Validation, its operational and deployment aspects, which is a good indicator of the maturing process of this technology. For quite some time the RIR engineers operating apexes of the RPKI hierarchy have been raising concerns about fragility of the system to potential mistakes of “over-claiming.” This is a case when a subordinate certificate “over-claims” resources compared to its parent, which leads to invalidation of the whole branch beneath. The closer to the top of the RPKI hierarchy such mistakes happen, the bigger the impact – some ISPs can lose their routing completely (assuming other folks validate, of course). And the probability of such mistakes is unfortunately non-zero, especially taking into account the inter-RIR address transfers. A proposal "RPKI Validation Reconsidered" ( http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered) tried to address this issue, but proposed quite fundamental changes to the PKI validation process that raised strong opposition in SIDR. A new draft “RPKI Multiple ‘All Resources’ Trust Anchors Applicability Statement” ( https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-00) attempts to address this problem, but from a different angle. It suggests that each RIR will move from a Trust Anchor that reflects their current holdings to one that reflects all holdings (e.g. 0/0) so that over-claiming can not occur at an RIR level when dealing with transfers from one RIR to another. Interesting solution – I am sure it will generate some discussion at the microphone! In order to use information published in RPKI repositories, Relying Parties (RP) need to retrieve and validate the content of certificates, CRLs, and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore, the validation of a certificate tree is usually performed top-down, starting from the TA certificate and descending down the certificate chain, validating every encountered certificate and its products. A draft “RPKI Certificate Tree Validation by a Relying Party Tool ( https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-00) describes how a Relying Party tool could discover RPKI objects to download, build certificate path, and validate RPKI objects, independently from what repository access protocol is used. The draft documents the process used by the RIPE NCC RPKI Validator implementation, but if there is interest it may be a good starting point of a generic validation document. I think that work can lead to more coherent and robust implementations of the validators. A draft “Signaling RPKI Validation Results from a Route-Server to Peers” ( https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-00) proposes how RPKI can be effectively used in an IXP environment, enhancing the functionality of a route server. This all indicates to me that practical RPKI is getting more momentum. We talked before about a so-called “route-leak.” Simply speaking, this term describes an otherwise valid announcement that nevertheless violated 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 “attack.” Seems like a significant “hole” that needs to be fixed. Next to the “Methods for Detection and Mitigation of BGP Route Leaks” ( http://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation), where the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC, there is a yet another proposal – “Route Leak Detection and Filtering using Roles in Update and Open messages” ( https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-00). This new proposal enhances the BGP Open message to establish an agreement of the (peer, customer, provider, internal) relationship of two BGP neighboring speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks. There are similarities among the two proposals and I think they can complement each other. I hope this will be discussed soon and an agreed common approach will be adopted. Related to the forwarding plane, a recently created WG – a DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG is making good progress. 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. There are a few drafts focusing on inter-domain operation that will be discussed during the WG meeting. By blocking DDoS attacks with inter-domain cooperation, average utility of DDoS mitigation equipment will increase. This will leverage total capacity of DDoS protection systems all over the internet. With this mechanism, we can manage DDoS attacks that exceed the capacity of its own platform. Let us hope this work will lead to effective solution of this huge problem of the Internet and facilitate necessary cooperation on the global level. Related Working Groups at IETF 95 SIDR (Secure Inter-Domain Routing) WG Monday, 4 April 2016, 14:00-15:30, Atlantico B Wednesday, 6 April 2016, 14:00-16:00, Buen Ayre A Agenda: https://datatracker.ietf.org/meeting/95/agenda/sidr/ Charter: https://datatracker.ietf.org/wg/sidr/charter/ GROW (Global Routing Operations) WG Thursday, 7 April 2016, 16:20-17:20, Buen Ayre B Agenda: https://datatracker.ietf.org/meeting/95/agenda/grow/ Charter: https://datatracker.ietf.org/wg/grow/charter/ IDR (Inter-Domain Routing Working Group) WG Tuesday, 5 April 2016, 10:00-12:30, Buen Ayre B Agenda: https://datatracker.ietf.org/meeting/95/agenda/idr/ Charter: https://datatracker.ietf.org/wg/idr/charter/ DOTS (DDoS Open Threat Signaling) WG Friday 8 April 2016, 10:00-12:00, Atlantico B Agenda: https://datatracker.ietf.org/meeting/95/agenda/dots/ Charter: https://datatracker.ietf.org/wg/dots/charter/ Follow Us There’s a lot going on in Buenos Aires, 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://www.internetsociety.org/rough-guide-ietf95.