New internet infrastructures: An introduction to SCION

Isolation domains

Currently the internet is, as the name suggests, a system of interconnected networks, also referred to as autonomous systems (ASs). With SCION, the internet still consists of autonomous systems. However, an additional layer of hierarchy is added by grouping autonomous systems into so-called Isolation Domains (ISDs). Typically the ASs in an ISD share certain properties. They might, for example, share a jurisdiction or geographic location. Every ISD has its own Public Key Infrastructure (PKI), which is used, for example, to secure routing within SCION. The PKI of an ISD can only hand out certificates for systems in its own Isolation Domain. In the event of security being compromised, the effects are therefore limited to the compromised Isolation Domain. The administration of an Isolation Domain is taken care of by the ISD core, a group of multiple autonomous systems referred to as core ASs. As the core ASs are responsible for the administration of the ISD, they will typically be run by parties that are trusted by all the other ASs in the ISD. The ISD core also plays an important role in the inter-domain routing, which we will explain below. Figure 1 depicts the different ISDs and some of the ASs in the SCIONLab network (as of September 2020), a global research network that enables experimentation with SCION.

Figure 1: topology of SCIONLab as of September, 2020, showing autonomous systems residing in various Isolation Domains (source SCIONLab).

Routing

For routing on the internet we currently rely on BGP, the Border Gateway Protocol. As the Internet is organised on a non-hierarchical basis, as a 'flat' network, huge tables are used by routers to determine where to forward packets based on the destination address. In SCION this works a bit differently: forwarding is based on so-called Packet Carried Forwarding State. That means that every packet contains the path that it needs to travel (at the AS level), so we no longer need huge tables on the routers. That allows routers to operate more efficiently in terms of memory usage, but more importantly it gives senders the capability to determine how their network traffic should travel through the internet. In order to do that, the senders need to know which paths to the intended destination AS are available. That is not unlike the way we currently look up domain names to retrieve the corresponding IP addresses in order to communicate with other hosts. When determining the paths, distinction is made between two scenarios: traffic within an ISD (intra-ISD) and between ISDs (inter-ISD).

In every ISD, the ASs are hierarchically organised based on their connections in a directed acyclic graph with the ISD core as the root. That allows the possible paths to be determined in a straightforward and efficient way. The process, also known as beaconing, is started by the core ASs, which send path segment construction beacons (PCBs) downstream to their neighbouring non-core ASs. When a non-core AS receives a PCB, it adds its own identity and some additional information, which will be needed later when constructing the paths in the packet headers. It then forwards the PCB to all downstream neighbours, which follow the same procedure. A PCB therefore contains information about the path it travelled from the ISD core to the current AS. Eventually the PCBs will reach the leaf ASs and, based on the information in the PCBs, all ASs will know at least one path by which the core of the ISD can be reached. As well as forwarding the PCB, every AS stores the path it just learned locally and informs the ISD core about the path(s) over which it prefers to be reached. Finally, the core knows how every AS can be reached and every AS knows how the core can be reached.

Figure 2: An example of a SCION topology with a single ISDs. The nodes in the ISDs represent ASs.

Now consider a situation where AS D (in Figure 2) wants to communicate with AS E (where both are non-core ASs), so it asks the core how AS E can be reached from the core (we refer to this part of the path as the down segment). It already knows how it can reach the core itself (we refer to this part of the path as the up segment) so it can combine the two segments to construct a path from itself to AS E. It includes the path in the SCION packet header, so every AS on the path will know where to forward the packet. A shortcut can be taken if two segments intersect, i.e. if the up and down segments of the path pass through the same non-core AS. In a situation like that, it would not make sense to forward the packet first to the core, only for it to take the same route back again. Direct peering is also still possible, between ASs in the same ISD or in different ISDs.

We now know how to reach another AS in the same ISD, as long as both path segments start/end at the same core AS. However, we still don't have the whole path needed to reach an AS in another ISD, or using a path where the up and down segments do not end/start at the same core AS. That problem is taken care of by inter-ISD routing, in which all core ASs participate. Inter-ISD routing uses a similar approach to that used by BGP: it sends PCBs to its neighbours, who add their respective information and forward the new PCB to their neighbours. That sounds similar to the intra-ISD routing approach, but with inter-ISD routing there is no directionality. That means that the process is not as efficient as the intra-ISD approach and does not scale as well.

Figure 3: An example of a SCION topology with three different ISDs. The nodes in the ISDs represent ASs.

Using the results from the processes above, ASs are able to communicate with other ASs, both in their own ISD and in other ISDs, by using the following recursive approach to path construction. This time AS G wants to communicate with AS Q (in Figure 3), which is located in another ISD. Through the intra-ISD beaconing, G knows how the core of its ISD can be reached (the up segment). G asks the core how Q can be reached. Through the inter-ISD routing, the core of G’s ISD knows how it can reach the core of Q’s ISD. This part of the path is referred to as the core segment. G’s ISD core asks Q’s ISD core how Q can be reached from its ISD core (the down segment). G's ISD core then returns the core segment and down segment to G. G can now construct a complete path to Q by combining the up, core and down segments. Note that, as there might be several options for each segment, there can be multiple paths that can be used and different packets can use different paths. It could of course happen that a path does not work anymore, e.g., due to a link failure. In that case, G would need to send the lost and subsequent packets again via another path. Path problems can either signaled to the sender by the network (similar to what happens with ICMP today) or deduced from the fact that packets are not being received.

As the paths are defined at the AS level and included in the packet, we need to know in which AS and ISD an end host that we want to communicate with is located. We therefore need those two additional pieces of information to be included in an end host’s address. Hence, an address now has three parts: the ISD, AS and local address of an end host. The address of the end host is not used in any of the processes above and is only used for local delivery within the AS.

SCION is designed with security in mind, so in all the processes described above the data involved is authenticated, thus precluding route hijacks.

Increased security and high availability

So far, we have discussed what could be called 'plain' SCION. While plain SCION has security and availability benefits, there are two additional “flavours” of SCION, which bring additional properties to inter-domain routing. The flavours are called EPIC and COLIBRI. In this section, we will give a quick overview of EPIC and COLIBRI and how their properties can be used to increase security and achieve high availability.

EPIC

EPIC stands for Every Packet Is Checked. It introduces additional security and transparency with per-packet granularity in the data plane. Whereas in plain SCION the same path information is used for several packets and is independent from the packet contents, in EPIC the path information is tied to the packet content. There are several variations of EPIC offering various levels of security. It can be used to provide both authentication of a packet source to all intermediate hops and authentication of the payload to the destination. By building on those capabilities, it can even be used to provide both the source and the destination with verification of the path that a packet has taken. To make that possible, every hop adds cryptographic evidence to the packet, recording the processing. However, that functionality requires additional cryptographic operations during packet processing, and additional keys are needed that are shared between an end host and each hop on the path. That can be done efficiently with a system named DRKey, which we will not discuss in detail but regarding which more information can be found in the SCION book (section 12.5). One important feature of DRKey is that keys can be computed on the fly, making the cryptography of EPIC faster than when memory lookups are involved. Packets are processed in less than 100ns on standard x86 hardware. That allows for very fast packet authentication, and thus very fast data transfers, because authenticated packets can be allowed through traditional firewalls. The principle has been demonstrated in LightningFilter, which achieved speeds of 120 Gbps on an x86-based server in an experimental setup.

COLIBRI

Whereas EPIC introduces additional authentication and verification, COLIBRI provides inter-domain bandwidth reservation, which makes it possible to secure a minimum bandwidth for a path between two end hosts. Combined with LightningFilter to filter authenticated packets at high speed, that makes it possible to achieve high levels of critical service availability, even when under a denial-of-service attack.

Using SCION on current IP networks

Although the native use of SCION throughout an AS may be the best way to fully leverage SCION, it may be hard to achieve. Adopting SCION throughout a network would require each connected device to handle the SCION protocols. Getting SCION implemented on devices of all types and in all applications may prove to be hard, if not impossible.

Fortunately, there is a way to deploy SCION which allows us to leverage quite a number of its advantages while also removing the need to modify applications or the end hosts in the network. In this scenario (depicted in Figure 4), inter-domain SCION communication is handled by the network instead of the end hosts. All end hosts continue to use IP the way they currently do. That is achieved by deploying a SCION-IP Gateway (SIG) in a network. A SIG tunnels incoming IP packets through the SCION network, handling, for example, the selection of paths. A SIG in the destination network then delivers the IP packet to the destination end host. Thus, we can integrate today’s IP networks with SCION and immediately benefit from SCION’s properties.

Figure 4: two traditional IP networks connected through SCION. The SCION-IP Gateways (SIGs) tunnel the IP packets through the SCION network to their destinations.

Final remarks

In this blog post, we have provided an introduction to the SCION architecture. We can only scratch the surface in an article such as this, but hopefully we have given some insight into how SCION works. More details can be found on the SCION website and in the SCION book.

SCION is already more than just a research project, with the spin-off company Anapaya working on the technology's commercial deployment. For example, the Swiss National Bank is looking at using SCION for its inter-banking communication, a project in which the major Swiss ISPs are also involved, while various universities in Switzerland are setting up a SCION network to inter-connect their networks.

In the future we will keep you up to date on the developments at SIDN Labs relating to SCION and other future internet architectures that we're looking at as part of the 2STiC programme.