So you want to know about SCION - part 1

What is wrong with the Internet today?

Over the past years, people have become more aware of security and privacy issues. Providing a more secure channel will help mitigate these problems. Since the Internet was initially created, the way people use technology has radically changed - we rely on constant Internet access via our mobile phones for communicating with others, our doctors exchange more and more data and our banks require connectivity at all times to make sure our digital banking apps are safe and sound. None of those use cases was in the mind of original creators of the Internet, but they have become de facto use cases nowadays. That created a need to develop and adopt a revolutionary rather than evolutionary internet architecture.

SCION is a clean-slate internet architecture, with up-to-date security and scalability properties, meant to overcome the limitations of the current IP- and BGP-based internet, namely security, availability, and performance. While a complete revolution is never easy, SCION design is focused on incremental deployment and backward-compatibility. The project has left an academic state already years ago and nowadays it is considered by critical industries and government.

In the following series of articles, we will explain some main problems of the current Internet, how SCION works to address them and what new ideas it introduces, as well as describe some of the existing deployments and on-going works to make it already available for general use.

"Throw and Pray" vs Smart End-Host

On a very high level, the principles governing data transmission in the current network are very simple -- an end-user specifies the recipient of the data and sends the traffic to its own network provider. It is up to the latter to make a choice on how the data will finally reach the desired recipient. But what if we wanted to change this status quo? Could we say that we want it to be the sender who specifies not only the recipient but also the path to reach it? This concept is referred to in the networking community as "a path-aware network protocol".

SCION, as such, is an alternative to the BGP, the network protocol responsible for a majority of the traffic passing through the Internet at present. With BGP, the end-hosts do not fully control the path of the packet - they can specify who is supposed to receive it, but not how it reaches its destination. This can be problematic from both a security and usability perspective.

As a principle, BGP looks for available paths to reach the destination and selects the fastest route. By doing so, in most cases, it passes through multiple network providers as well as multiple countries. This model presents flaws - how can we be sure that the path chosen by the BGP is the correct path? In the original design of BGP, no safeguards were preventing malicious parties from announcing false routes, so that the protocol by itself is prone to so-called "hijacking attacks".

While we don't want to list here all the major and recent BGP hijacking attacks, they have become a daily business reality for network operators. Some of those improvements include extensions to the protocol, like RPKI - Resource Public Key Infrastructure. While in BGP’s original design of the BGP, anyone could announce that they own any address range, without asserting the ownership, RPKI tries to change this by introducing a system of Route Origin Authorisations, which labels network operators as authorised to originate the IP range. Skipping through too many technical details, we want to point here only 2 issues with RPKI. First, it is an extension that needs to be adopted by the community and providers around the world, and such an adoption takes time. Second, RPKI only secures the origin of the route, rather than the whole path.

BGP’s issues originate at the beginning of the expansion of what became the current Internet when all communications happening between different network providers were based on mutual trust. With more and more players in the networking community, trust is no longer a viable security. The initiative called MANRS - Mutually Agreed Norms for Routing Security - was recently created in order to push the community to implement routing security by sharing and promoting best-practices. However, such initiatives always take longer than it takes attackers to adapt to the new environment. Because of that, we believe that the BGP’s problems require the creation of new solutions; solutions such as SCION.

In SCION, the sender fully controls the path taken by the packet to reach its destination, through the use of beacons and segments, described in the following sections. Cryptographic signatures applied on top of beacons are the guarantee that the chosen path is being used and that that the path will not be altered during the lifetime of the packet. Offloading the decision-making process to the end host ensures that no malicious entity can interfere with the packet routing process once the data has been sent.

SCION: A clean-slate redesign

Isolation Domain (ISD)

With the current Internet architecture, entities are split into a multitude of Autonomous Systems (AS). A public IP address always belongs to a single AS and this address is used to communicate between different hosts in the networks. In SCION we introduce an additional element - The isolation Domain. This is a way of logically grouping multiple Autonomous Systems that share some common properties (that could be for example a country or an international organisation) and a mutual trust, due to this shared characteristic. The latter is a very important concept; AS-es belonging to the same Isolation Domain will have more trust in each other than AS-es from separate ISDs.

Inside an Isolation Domain, all the AS-es are organised in a hierarchical structure, creating a system of core, intermediate, and leaf AS-es. Core AS-es are at the top of the ISD’s hierarchy and connect to other core AS-es in the same or in a different ISD. Intermediate and leaf AS-es are mainly connected to core AS-es in their ISD.

Beaconing

Having outlined how the end-host is responsible for selecting a path for the packet, we now explain how SCION explores and registers path segments. It is important here to note that SCION, as an inter-AS routing protocol, does not interfere with how internal routing is implemented inside the same AS. Here, we will focus mostly only on intra-ISD, traffic between different AS-es in the same ISD, rather than inter-ISD traffic, traffic between different ISDs.

First, we outline how paths inside ISDs are created. Core AS-es broadcast beacons, regularly to all the directly connected downstream AS-es. Those beacons contain a multitude of information like ingress and egress interfaces, timestamp, cryptographic signature, and so on - those can be later used by either end-host or a network operator to, for example, assess how useful it is to route the traffic through some parts of the network based on its properties. Every AS that receives such a beacon will add additional information to it and forward that to the next AS. By following this process, each AS learns paths up to the core AS which originated the beacon. These path segments can then be combined with path segments of other AS-es to build paths between any source and destination within the same Isolation Domain. We thus introduced a way for any host to find a path to any other host in the same ISD.

A similar process is employed for communication between multiple ISDs. A careful reader can spot that the beaconing process can create a significant amount of broadcast traffic. In order to solve this issue, instead of all AS-es partaking in the beaconing between all ISDs, only the core AS-es of each ISD are involved. Designing the beaconing process in such a way still preserves the ability of an arbitrary host to be able to reach any other ISD - in such a scenario the host can send a request to its upstream AS for a path to the AS in another ISD.

This is a series of articles

We have described what SCION is and what fundamental problem of the current Internet it solves. In part 2 of this article, we will describe the new features SCION brings and how they can be leveraged to improve the security and reliability of already existing networks. Later in the series, we will also take a look at how possible it is to seamlessly integrate SCION with the current networks and how it can be done without using expensive and very often, proprietary hardware.

About the author:

Mateusz is a Senior Site Reliability Engineer at Anapaya Systems. He has a proven track record in designing and deploying architectures for large‐scale systems. His career has been shaped by DevOps movement and covers both software as well as system engineering. He used to work at CERN as part of the team responsible for computing resources for the Large Hadron Collider. He is passionate about cloud and container technologies as much as spending hours in data centres deploying bare-metal hardware.

"As engineers and scientists, our main goal should always be to provide society with better tools to solve their daily problems. While not always an easy task, whenever possible we should avoid taking shortcuts causing people to lose trust in the technology they use. Sometimes it means a more revolutionary rather than evolutionary approach but this should not stop us from pushing for changes that we believe can make technology better, safer, and more accessible."