As usual, in this post I’ll focus on important work the IETF is doing that helps improve the security and resilience of the Internet infrastructure.
At IETF 102 there are a lot of new ideas being brought to the community in the form of Internet Drafts aimed at improving the security and resilience of the Internet infrastructure, and I’d like to introduce some of them to you. But keep in mind – an Internet Draft does not indicate IETF endorsement, is not a standard, and may not result in any further work at the IETF.
So, let us look at what is happening in the domain of BGP, the routing protocol that connects the Internet.
Route leaks
There has been slow progress in the work on mitigating route leaks in the IDR Working Group (WG). One of the reasons for the slowness was that the group was considering two proposals addressing the route leak problem and 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”. Plus, there is a third submission “Route Leak Detection and Filtering using Roles in Update and Open Messages” that also provides a solution in this area.
Fortunately, it seems that the relationship between all three is clearer now. Preventing route leaks locally by the potential culprit is described in draft-ietf-idr-bgp-open-policy. It also defines roles that can be useful in other solutions. draft-ietf-idr-route-leak-detection-mitigation now incorporates some ideas from draft-ymbk-idr-bgp-eotr-policy and is focused on detection and mitigation of the leaks upstream, more than one hop away from the culprit. In other words, the group is now working on two complementary and not conflicting solutions. Hopefully that will help with finalizing them soon.
Leveraging RPKI for proven operational practices
A common best practice to ensure that one’s customers only announce their own networks and the networks of their customers, is to build prefix filters. In fact, this should become a norm for every network, as defined in Action 1 of MANRS.
In the case where there are only direct customer relationships (i.e. the network’s customers are all “stub networks”), the task is relatively easy – one needs to collect the list of prefixes legitimately originated by these customer networks. This is most commonly done by using an IRR and collecting corresponding “route” objects, but with the proliferation of RPKI this can become a more robust process using cryptographically verifiable ROA objects that serve a similar purpose.
If you are a bigger network and some of your customers also provide transit services for smaller networks, the task is more difficult. How does one determine who are the customers of one’s customers and so on?
To help with this task, there is a special IRR object – “as-set”. This object is a list of ASNs or other “as-sets” that defines a customer cone of a particular AS. However, when it comes to RPKI, there is no way for an operator to assert the routes for its customer networks, making it difficult to use the information carried by RPKI to create meaningful prefix filters without relying on RPSL “as-sets”.
The Internet Draft “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” tries to fix that problem by introducing a new attestation object, called an AS-Cone. An AS-Cone is a digitally signed object with the goal of enabling operators to define a set of customers that can be considered transit customer networks, thereby facilitating the construction of prefix filters for a given ASN and making routing more secure.
By leveraging RPKI, AS-Cone also addresses two fundamental problems with the RPSL “as-set”:
- the same AS-SET name can exist in multiple IRRs,
- a relying party does not know which “as-set” belongs to which ASN, and which as-set to use.
Validating AS-PATH without BGPsec
The Border Gateway Protocol (BGP) was designed with no mechanisms to validate BGP attributes. The ability to manipulate one of them – AS_PATH – creates one of the more serious vulnerabilities of the Internet routing system. BGPsec was designed to solve the problem of AS_PATH correctness.
But according to the authors of a new Internet Draft, “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization“, even leaving aside its complexity, its backward compatibility with ‘insecure’ BGP allows an attacker to mount a downgrade attack to nullify all the work of AS_PATH signing. The authors suggest a more pragmatic approach that can help leveraging the benefits of RPKI without the need for the ubiquitous deployment of BGPsec. The idea is that any AS can declare its upstream providers and peers – the networks that can propagate its prefix announcements. The more networks do that – the more chances to detect misconfigurations (malicious or not).
The draft defines the semantics of Autonomous System Provider Authorization (ASPA) objects that should become part of RPKI. ASPAs are digitally signed objects that bind a in a selected AFI Provider AS number to a Customer AS number (in terms of BGP announcements, not business), and are signed by the holder of the Customer AS. An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements, e.g. to the Provider’s upstream providers or peers.
Using blockchain to secure IP addresses allocation, delegation and bindings
While RPKI technology offers the significant benefits of cryptographically secured authentication and authorisation of ownership of Internet number resources (IP address blocks and AS numbers), aligned with the distribution hierarchy of Internet number resources, it has also raised some concerns. The concerns are mostly related to centralization of routing authority and creating single points of failure, or even kill switches, represented by the RIRs and IANA.
A technology that can facilitate building cryptographically strong and credible ledgers, without relying on a hierarchical system, is blockchain. Can it be applied in this case?
The Internet Draft, “An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings“, looks at how blockchain technology can be used to secure the allocation, delegation, and binding to topological information of the IP address space. The main outcomes of the analysis are that blockchain is suitable in environments with multiple distrusting parties and that Proof of Stake is a potential candidate for a consensus algorithm.
However, several questions remain open, such as the balance of power between providers and customers, enforcement of RIR policies, incentives for adoption or deployment cost.
As you can see, the meeting in Montreal is certainly going to be full of interesting discussions in the area of Internet infrastructure resilience, and will hopefully lead to some important work, specifications and improvements to the fabric of the network that we all depend on for so much.
Related Working Groups at IETF 102
SIDROPS (SIDR Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/
GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/
IDR (Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
DOTS (DDoS Open Threat Signaling) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/
Follow Us
It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.