Advantages presented by SCION
Nowadays, an ever increasing number of devices and applications require different properties from the network they are connected to. For some of them the shortest path is a desired property, but others want to sacrifice distance and latency for the benefit of having a significantly better throughput.
We will be presenting properties of SCION that enable optimal usage of the network by applications and end users.
Path control in SCION
A careful reader may have gotten the impression that SCION is simply source routing in disguise, however, this is not the case for a variety of reasons. First of all, end hosts do not learn any information about topology inside the Autonomous System (AS) - this is still under the control of the local network administrators who may want to implement complicated firewall rules or in any other way affect the traffic in their local networks.
While with SCION the end-host selects the path of the packet, it cannot perform this selection completely independently. Instead, the network operator distributes the available paths and the end-host can only choose from this pre-selected set.
An interesting use case of path control in SCION is called “geo-fencing”. Because the sender selects the path to the destination, it is able to select only paths avoiding undesirable entities. This is not always the case with the current Internet, and as a result, traffic sometimes travels between different providers in the same country or crosses borders. Consequently, enterprise and government customers can use SCION’s geo-fencing feature as a strong guarantee that the data never leaves a desired jurisdiction.
One of the problems with source routing, a protocol that we have already described in the "SCION vs. Segment Routing" post, is the ability to bypass various security perimeters of the network. Source routing can operate in two modes, loose and strict. The loose mode only specifies that the traffic should pass by specified parts of the network, whereas the strict mode specifies an exact, full path. As a result, when using the strict mode, an attacker can force the traffic to take a specific path through the network, effectively bypassing existing security equipment. In SCION we solve this issue by introducing additional security features, described in detail below, which make it impossible for an attacker to use a path that has not been authorised by the network.
The first measure are beacons, which were previously described as cryptographically protected. Every time an AS writes its information into the beacon, it is being signed so that any other AS can verify this information. This removes any ability for a third-party to inject rogue information into the beacon that could result in a fake path segment being broadcasted by the network. This highlights one more important role of the Isolation Domain - it creates trust relationships between the few different entities in the same ISD, so that we could for example designate one of the AS-es as our trusted certificate issuer. At the same time, there is no trust relationship required between arbitrary AS-es from different ISDs. Concretely, this means you only have to trust people within your AS, from your own entity.
Second, Message-Authentication codes are used when the data is forwarded to make sure only authorised traffic is allowed. This mechanism protects the network from, for example, "replay attacks" (DoS Attacks) where a third-party attacker records some of the legitimate traffic in order to inject it into the network with a significantly amplified volume. This form of DoS attacks cannot take place in the SCION Internet.
Last but not least, EPIC (Every Packet Is Checked) is an extension of SCION offering an additional layer of security. On a very high level, every router adds a cryptographic signature to every packet. This allows every on-path device to authenticate the source of the processed packet effectively making it easier to detect and drop malicious traffic.
Native multi-path, fault tolerance, failure isolation
Multi-path routing enables two desirable features: performance and reliability.
Having the ability to use multiple paths to reach the intended destination, the host should be able to select a combination that allows reaching the best throughput or latency based on any specific requirement the traffic might need. The SCION-based network enables superior performance.
In terms of reliability, we come back to the problem of the BGP-based infrastructure. BGP is inherently a single path architecture, meaning that there is a single preferred path to a given destination. Because the same path is used by a multitude of users, it is prone to cause problems in case of a congestion or an outage. Whereas congestion can be addressed by proper prediction through algorithms and capacity planning, an outage cannot be easily addressed. In case an outage happens on a path that is currently used, a process of routing convergence starts. This mechanism announces the unavailability to all the parties trying to send traffic over the broken path. However, as the process can take up to several minutes during which the path is unavailable, this has a direct impact on end-users.
By offering a native mutli-path, the convergence problem is resolved, as long as there is at least a single working path, the connectivity is not affected.
A common argument in every discussion against source routing protocols and its derivatives is that the end-host cannot have as good a picture of the state of the network as its administrator. Not having the picture of the whole network, end-hosts cannot select the shortest path. On the other hand, if every host in the network selects the same path, it quickly becomes congested and we are back to point zero.
In theory network operators can avoid such scenarios because all the data they have about the traffic traversing their networks and the patterns. By using this data, they can make an optimal decision about what the next destination of the packet should be. As has been proven multiple times, quite often the BGP is abused as a cheapest-first type of a protocol and not necessarily shortest-first. Because of different prices for transit traffic between different providers, it's not always the shortest or the fastest path that is being selected, but the cheapest one.
To protect interests of the network operators when using SCION - it is still possible to control path segments (via beaconing described previously) available for end-hosts by for example selectively enabling or disabling specific parts of the network for a general availability.
This is a series of articles
So far we have described what SCION is, what problems of the current Internet it solves and what are the new features it brings. What we still need to explain is how we made it possible for SCION to run next to the current network infrastructures without a need to completely redesign the existing deployments.
In the next article we will focus on how it is possible to almost seamlessly integrate SCION with the current networks and how it can be done without using expensive and very often proprietary hardware.