IETF 99 is next week in Prague, and I’d like to take a moment to discuss some of the interesting things happening there related to Internet infrastructure resilience in this installment of the Rough Guide to IETF 99.
Simple solutions sometimes have a huge impact. Like a simple requirement that “routes are neither imported nor exported unless specifically enabled by configuration”, as specified in an Internet draft “Default EBGP Route Propagation Behavior Without Policies”. The draft is submitted to IESG and expected to be published as a Standards Track RFC soon.
This specification intends to limit the impact of misbehaving networks by requiring the explicit configuration of both BGP Import and Export Policies for an External BGP (EBGP) session such as customers, peers, or confederation boundaries for all enabled address families. When widely deployed, this measure should reduce the occurrence of route leaks and some other routing misconfigurations.
Speaking of route leaks, there are still two proposals addressing the route leak problem. Now both are IDR WG documents: “Methods for Detection and Mitigation of BGP Route Leaks” (http://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation), and “Route Leak Prevention using Roles in Update and Open messages” (https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/). The first approach uses a so-called RLP Route Leak Prevention field to inform upstream networks and lateral peers of a “leaked” route. Another one leverages the BGP Open message to establish an agreement of the (customer, provider, complex) 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.
In the area of RPKI and BGPSEC a recently chartered SIDR Operations Working Group (SIDROPS) has taken over the technology developed in SIDR WG and is focused on developing guidelines for the operation of SIDR-aware networks, and providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks. The first of such guidelines was just published and will probably be discussed during the WG meeting: “Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties” (https://datatracker.ietf.org/doc/draft-madi-sidrops-rp). Being a relying party is not an easy job – one has to comply to dozen of RFCs, from protocol specifications to best practices – and this document attempts to outline a set of baseline requirements imposed on RPs and provides a single reference point for requirements for RP software for use in the RPKI, as segmented with orthogonal functionalities:
- Fetching and Caching RPKI Repository Objects
- Processing Certificates and CRLs
- Processing RPKI Repository Signed Objects
- Delivering Validated Cache Data to BGP Speakers
The IDR WG continues working on the proposal “Making Route Servers Aware of Data Link Failures at IXPs” (https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/). When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes a means for the peers to verify connectivity amongst themselves, and a means of communicating the knowledge of the failure back to the route server. There was quite some discussion on the mailing list about whether communication of failures back to the RS is necessary. I imagine this discussion will continue during the WG session.
It seems the OPSEC WG will discuss another attempt at addressing the source IP spoofing problem. A draft “Enhanced Feasible-Path Unicast Reverse Path Filtering Anti-spoofing” (https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements) proposed a method that does not have the drawbacks of the existing modes of Unicast Reverse Path Filtering (uRPF) – strict, feasible and loose. Apart from implementation issues and a potential performance hit, uRPF presents risks of dropping traffic by an ISP implementing it. These were the major obstacles in the way of its deployment and protection against IP-spoofed traffic.
DDoS attacks are a persistent and growing threat on the Internet. And as DDoS attacks evolve rapidly in the aspect of volume and sophistication, more efficient cooperation between the victims and parties that can help in mitigating such attacks is required. The ability to quickly and precisely respond to a beginning attack, communicating the exact information to the mitigation service providers is crucial.
Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG busy. 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. Specifications outlining the requirements, architecture and the use cases for DOTs are maturing and will be discussed at the meeting.
To summarize – there is important work underway at the IETF that will hopefully lead to a more resilient and secure Internet infrastructure.
Related Working Groups at IETF 99
SIDROPS (SIDR Operations) WG
Monday, 17 July, 15:50-17:20, Congress Hall III
Charter: https://datatracker.ietf.org/wg/sidrops/charter/
GROW (Global Routing Operations) WG
Monday, 17 July, 17:40-18:40, Congress Hall III
Charter: https://datatracker.ietf.org/wg/grow/charter/
IDR (Inter-Domain Routing Working Group) WG
Thursday, 20 July, 09:30-12:00, Congress Hall III
Charter: https://datatracker.ietf.org/wg/idr/charter/
DOTS (DDoS Open Threat Signaling) WG
Thursday, 20 July, 15:50-17:50, Berlin/Brussels
Charter: https://datatracker.ietf.org/wg/dots/charter/
OPSEC (Operational Security) WG
Wednesday, 19 July, 13:30-15:00, Berlin/Brussels
Charter: https://datatracker.ietf.org/wg/opsec/charter/