As we approach IETF 100 in Singapore next week, this post in the Rough Guide to IETF 100 has much progress to report in the world of Internet Infrastructure Resilience. After several years of hard work, the last major deliverable of the Secure Inter-Domain Routing (SIDR) WG is done – RFC 8205, the BGPSec Protocol Specification, was published in September 2017 as standard. BGPsec is an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message propagates.
There are seven RFCs in the suite of BGPsec specifications:
- RFC 8205 (was draft-ietf-sidr-bgpsec-protocol) – BGPsec Protocol Specification
- RFC 8206 (was draft-ietf-sidr-as-migration) – BGPsec Considerations for Autonomous System (AS) Migration
- RFC 8207 (was draft-ietf-sidr-bgpsec-ops) – BGPsec Operational Considerations
- RFC 8208 (was draft-ietf-sidr-bgpsec-algs) – BGPsec Algorithms, Key Formats, and Signature Formats
- RFC 8209 (was draft-ietf-sidr-bgpsec-pki-profiles) – A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
- RFC 8210 (was draft-ietf-sidr-rpki-rtr-rfc6810-bis) – The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
- RFC 8211 (was draft-ietf-sidr-adverse-actions) – Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)
You can read more about this important milestone in our recent blog post: BGPsec: A Reality Now.
If you follow the work of the SIDR and SIDR Operations Working Group (SIDROPS) working groups, you may recall that for more than three years the 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. At the moment, the final version of the I-D is under the IESG evaluation. The substance of the proposal is summarized in the draft: “Where the procedure specified in RFC 6487 requires that Resource Certificates are rejecting entirely if they are found to over-claim any resources not contained on the issuing certificate, the validation process defined here allows an issuing Certificate Authority to choose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. This choice is signaled by form of a set of alternative Object Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484).”
In the area of Resource Public Key Infrastructure (RPKI) and BGPsec, SIDROPS has taken over the technology developed in SIDR 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.
In my last guide, I mentioned some work to ease the job of an RPKI relying party software developer. An individual submission, “Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties”, recently being called for adoption, provides a single reference point for requirements for Relying Party (RP) software for use in the RPKI. To see how these requirements are implemented in practice, one can look at the RPSTIR package. Hopefully efforts like this will ease adoption of the technology.
Another item in this area is a recently adopted I-D “Origin Validation Clarifications“ that provides guidance to equipment vendors to resolve potential ambiguity regarding the implementation. Specifically, it requires that all routes are considered for validation and marked accordingly, as a default mode. It also states that by default no policy should be applied to these marked routes – this is a job of the network operator.
There was little progress in the work on mitigating route leaks and I am curious if this discussion surfaces on the Inter-Domain Routing Working Group (IDR) WG agenda. At the moment, there are still two proposals addressing the route leak problem. Both are IDR WG documents: “Methods for Detection and Mitigation of BGP Route Leaks”, and “Route Leak Prevention using Roles in Update and Open messages”.
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 is required between the victims and parties that can help in mitigating such attacks. 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) 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 100
SIDROPS (SIDR Operations) WG
Wednesday, 15 November, 13:30-15:00, Sophia
Agenda: https://datatracker.ietf.org/meeting/100/session/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/
IDR (Inter-Domain Routing Working Group) WG
Monday, 13 November, 13:30-15:30, Canning
Agenda: https://datatracker.ietf.org/meeting/100/session/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
DOTS (DDoS Open Threat Signaling) WG
Tuesday, 14 November, 13:30-15:30, Olivia
Agenda: https://datatracker.ietf.org/meeting/100/session/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/
Follow Us
A lot is going on in Singapore, 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 Society blog, Twitter, Facebook, or see https://www.internetsociety.org/events/ietf/ietf-100/.