In this post of the Internet Society Rough Guide to IETF 101, I’ll focus on important work the IETF is doing that helps improve security and resilience of the Internet infrastructure.
BGP
What happens if an IXP operator begins maintenance work on the switches without ensuring that BGP sessions between the peers have been shut down? A network disruption and outage. A draft now in the RFC editor queue, “Mitigating Negative Impact of Maintenance through BGP Session Culling”, provides guidance to IXP operators on how to avoid such situations by forcefully tearing down the BGP sessions (session culling) affected by the maintenance before the maintenance activities commence. This approach allows BGP speakers to pre-emptively converge onto alternative paths while the lower layer network’s forwarding plane remains fully operational.
Another draft also in the RFC editor queue, “Graceful BGP session shutdown”, addresses issues related to planned maintenance. The procedures described in this document can be applied to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link to be shut down. These procedures trigger, in both Autonomous Systems (AS), rerouting to alternate paths if they exist within the AS, while allowing the use of the old path until alternate ones are learned. This ensures that routers always have a valid route available during the convergence process.
Both recommendations have been developed in the GROW WG. They represent simple measures that can have a significant positive impact on overall stability.
RPKI and BGPSEC
The 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.
If you follow the work of SIDR and now SIDROPS WGs 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. Finally, the IESG has approved it and the draft is in the RFC editor queue.
Here is the summary of the proposal: “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)”.
A possible sign of RPKI adoption is the fact that IXPs are considering or even performing RPKI checks by the route server. Route server is a common IXP component enabling multilateral peerings at the exchange point. To clarify how such validation can be performed and signalled, if necessary, to the peers, a draft “Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers” is now under discussion. The main argument is whether it is productive to signal validation results instead of simply discarding “invalid” routes and maybe tagging “valid” and “unknown”. This discussion will likely surface at the meeting, too.
DDoS
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. In the DOTS architecture, clients and servers communicate using DOTS signalling. 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.
The main work is now concentrated on defining the signal channel (https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ ) that allows a client to ask a DOTS server for help in mitigating an attack, and for the DOTS server to inform the DOTS client about the status of such mitigation. They also work on the optional data channel (https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/) that provides additional capabilities, such as configuration and policy information exchange.
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 101
SIDROPS (SIDR Operations) WG
Thursday, 22 March, 15:50-17:50, Park Suite
Agenda: https://datatracker.ietf.org/meeting/101/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/
GROW (Global Routing Operations) WG
Monday, 19 March, 17:40-18:40, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/
IDR (Inter-Domain Routing) WG
Monday, 19 March, 15:50-17:20, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
DOTS (DDoS Open Threat Signaling) WG
Tuesday, 20 March, 15:50-18:20, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/
Follow Us
It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.