The Internet is a truly amazing system. Originally developed as a research network in the 1960s and 1970s, it is still operational today, connecting billions of users and tens of billions of devices.
It is remarkable that the protocols at the core of the Internet — the Internet Protocol (IP) and the Border Gateway Protocol (BGP), which have changed little over the past decades — are able to handle the vast scale the Internet has reached today. Still, the effects of the lack of built-in security mechanisms of these protocols are becoming increasingly apparent — IP and BGP were simply not built for the threat landscape of today’s Internet.
Around the year 2000, alongside security patches to BGP (some of which have been discussed in a recent APNIC blog post by Geoff Huston), the research community had also started to consider new, clean-slate Internet architectures. In this blog post, I will focus on a particular class of so-called path-aware Internet architectures, which allow end hosts to select a path for their traffic from a set of available paths and embed it explicitly in the header of data packets. Together with strong authentication mechanisms in the path-exploration system, this not only empowers end hosts, but fundamentally solves routing hijacks that are prevalent in today’s BGP-based Internet.
The Network Security Group at ETH Zurich in Switzerland has been developing the path-aware SCION Internet architecture over the past 11 years, which has now reached a level of maturity that facilitated real-world deployment and production use since 2017. (Note: we are interested in the inter-domain setting here; there are also examples for path-aware networking within Autonomous Systems (ASes) such as segment routing.)
In fact, a BGP-free production network across several ISPs in Europe and Asia today carries production traffic for banks and the Swiss government. SCION and these recent developments provided the motivation to analyse trade-offs, challenges, and opportunities in the forwarding process of such a path-aware Internet architecture in further detail. The results were published recently at the USENIX Security Symposium.
How to protect policies of ASes?
The design choice of allowing end hosts to choose forwarding paths and embedding them in packet headers clearly has many advantages:
- An end host can use a path that best fulfills the requirements of a particular application (in terms of, for example, bandwidth, latency, or traversed networks).
- It enables meaningful inter-domain multipath communication.
- It prevents hijacking attacks by off-path adversaries.
- Routers in the network can reach a forwarding decision by simply looking at the packet header instead of performing (expensive) longest-prefix matching.
However, it also comes with a potential challenge, which is often presented as an argument against end-host path control: How can network operators be protected against malicious end hosts?
For example, a path-aware Internet architecture needs to ensure that end-hosts cannot craft paths that contain loops or violate routing policies of ASes, as illustrated in Figure 1.
Figure 1 — A path-aware Internet architecture needs to ensure that end hosts can only use paths consistent with the policies of ASes.
SCION achieves this through Message-Authentication Codes (MACs) that an AS calculates to authorize specific paths and checks during the forwarding process. Based on highly efficient symmetric cryptography, these checks can be performed within as little as ten nanoseconds. This restricts an end host to only use paths that have been authorized by all on-path ASes.
EPIC: Every Packet Is Checked
In our recent publication, “EPIC: Every Packet Is Checked in the Data Plane of a Path-Aware Internet”, we explored and resolved the trade-off faced by the length of these MACs in terms of communication overhead and security.
One of our core insights was that individual packets that violate a path policy are no threat to ASes; problems only arise if an attacker reuses illegitimately obtained (for example, through brute-forcing) MACs to send many additional packets. In particular, we found that if the end host calculates unique MACs for individual packets, these fields can be shortened significantly without compromising the security guarantees.
This approach of authenticating paths through MACs can achieve additional security properties with little extra overhead. Leveraging DRKey, a system for deriving and distributing shared symmetric keys between ASes, EPIC also describes a protocol that allows on-path routers and the destination to authenticate the source of any packet.
Remarkably, source authentication is possible within as little as a hundred nanoseconds — even in a software router without specialized hardware — and this overhead can be reduced further through dedicated hardware and parallelization. Most importantly, thanks to the DRKey system, routers do not need to keep tables with keys but can derive them on the fly within some tens of nanoseconds through highly efficient pseudorandom functions. This provides an opportunity for meaningful source-address-based filtering of attack traffic (for example, during denial-of-service attacks) and rules out prevalent reflection attacks.
Finally, we’ve described how negligible additional processing on routers enables communicating end hosts to validate the actual path taken by packets. This may be particularly relevant in the future when specialized networks such as Low-Earth-Orbit (LEO) satellite networks may be integrated into the Internet and end hosts may want confirmation that their path decision was obeyed by on-path routers.
EPIC achieves these properties with substantially lower computation and communication overhead than state-of-the-art systems, making it practical for real-world deployments — it only requires 5 bytes for each AS-level hop and can scale to process 100 Gbps minimum-sized packets on a software router through parallelization.
Learn more about SCION and EPIC
If you want to learn more, please read our paper, check out the online resources on the SCION architecture including the open-source reference implementation, or try it out with our global SCION-based networking testbed SCIONLab.
Markus Legner is a postdoctoral researcher and lecturer in the Network Security Group headed by Prof. Adrian Perrig at ETH Zurich, Switzerland.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.