Donate
ISOC Rough Guide to IETF 96: Internet Infrastructure Resilience Thumbnail
‹ Back
Building Trust 12 July 2016

ISOC Rough Guide to IETF 96: Internet Infrastructure Resilience

Andrei Robachevsky
By Andrei RobachevskySenior Technology Programme Manager

We continue to look at the work in the IETF with a wider angle – not just routing resilience, but also the resilience of the data forwarding plane – specifically to DDoS attacks. There is interesting and important work underway at IETF 96 in Berlin next week that can help address 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.

While RPKI and BGPsec are aimed at making routing more secure, these infrastructures introduce their own risks. One of the concerns, for example, was the amplifying impact mistakes of “over-claiming” at the higher levels of RPKI hierarchy (say the RIR level) have on the INR holders. Another concern was related to potential abuse of RPKI to reach certain policy and law enforcement objectives. To answer the question about what operational impact various adverse actions and mistakes may have a draft-ietf-sidr-adverse-actions-00 enumerates possible actions and analyses four operational scenarios. The document intends to provide a basis for the design of future RPKI security mechanisms that seek to address the concerns associated with such actions. The draft was discussed prior to the adoption it as a WG document and the authors have requested a last call already on the -00 version.

By the way, after some impasse, the proposal ” RPKI Validation Reconsidered“, which tries to address the issue of “over-claiming” by proposing changes to the PKI validation process, is making good progress and has a good chance of reaching consensus.

A draft “ Signaling RPKI Validation Results from a Route-Server to Peers”, which proposes how RPKI can be effectively used in an IXP environment, enhancing the functionality of a route server has been adopted as a WG document and will progress.

This all indicates to me that practical RPKI is getting more momentum.

BGPsec is maturing as well. The protocol specification has been submitted to the IESG for publication. BGPsec Operational Considerations attempts to collect and present the most critical and universal operational considerations. As the document states, it is expected to evolve as BGPsec is formalized and initially deployed. This document is submitted for publication as a Best Current Practice.

In the area of route leaks there are two proposals. One is an IDR WG document

Methods for Detection and Mitigation of BGP Route Leaks”, where the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC. Another is an independent submission “ Route Leak Detection and Filtering using Roles in Update and Open messages”. 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.

The idea of “negotiating” the relationships through the BGP Open message is an interesting one. It can certainly help minimize unilateral mistakes. It has some limitations, since routing policy is not always defined on a per peer (or, per session) basis, but sometimes with a greater, per prefix granularity.

Another difference is that the first draft suggests per hop (i.e. every element of the AS_PATH may have this flag set), while the second one – per update tagging of routes. The latter does not allow detection of leaks in certain situations, on lateral peering leaks, for instance.

I hope good ideas from both drafts will be integrated into a single solution.

Related to the forwarding plane and DDoS specifically, a few meetings ago a draft “BLACKHOLE BGP Community for Blackholing” was introduced initially to document a well-known community used for triggering blackholing at IXPs, similar to what DE-CIX is doing ( https://www.de-cix.net/products-services/de-cix-frankfurt/blackholing). Several concerns about the risk of abusing IXPs as a “filtering sink of the internet” for example by law enforcement were raised that led to a more general document describing use of this attribute for just networks. The document is now adopted by the WG and is in its third revision ( https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing). There is still quite some discussion on additional attack vectors this proposal may introduce due to the well-known and transitive nature of the attribute.

Also in the same problem area a recently created WG – a DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) 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.

The architecture of DOTS systems is shaping up. The draft “ Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture” has been adopted as a WG document. In this architecture, DOTS clients and servers communicate using the DOTS signaling. As a result of signals from a DOTS client, the DOTS server may modify the forwarding path of traffic destined for the attack target(s), for example by diverting traffic to a mitigator or pool of mitigators, where policy may be applied to distinguish and discard attack traffic. Any such policy is deployment-specific.

In addition to the WG session, there is plan to organize two design team meetings. One on Joint Use Case, Requirements and Architecture, and another with the implementers.

Let us hope this work will lead to effective solution of this huge problem of the Internet and facilitate necessary cooperation across network administrative domains.

Related Working Groups at IETF 96

SIDR (Secure Inter-Domain Routing) WG
Thursday, 21 July, 10AM-12:30PM, Bellevue
Agenda: https://datatracker.ietf.org/meeting/96/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations) WG
Friday, 22 July, 12:20-1:20PM, Tiergarten
Agenda: https://datatracker.ietf.org/meeting/96/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Tuesday, 19 July, 10AM-12:30PM, Schoeneberg
Agenda: https://datatracker.ietf.org/meeting/96/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Tuesday, 19 July, 4:20PM-6:20PM, Bellevue
Agenda: https://datatracker.ietf.org/meeting/96/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

There’s a lot going on in Berlin, 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-ietf96.

‹ Back
Join the conversation with Internet Society members around the world