SCION - Next-Generation Internet

Do we need a new Internet? According to various researchers and professors in the Internet field, yes.

They have developed a new network architecture:

Scalability, Control, and Isolation on next-generation Networks (SCION), which I would like to introduce to you. I was attanding a talk of the ISSS (Internet Security Society Switzerland) and Adrian Perrig personally presented his work, which has been ongoing since 2009, to the participants.

Problems with the current network architecture

Today’s architecture of the internet has several difficulties. On the one hand, there is the availability, which according to today’s measurements is 99.9% (86 s per day) for a well linked entity.
For comparison: A fixed line connection (cable, no VOIP) has 99.999% (0.86 s per day) availability.
Many people have certainly noticed the short outages in global routing caused by misconfigurations or intentional attacks (prefix hijacking) with BGP, or the prominent examples in the DDoS area, from which we are already affected almost daily. A second problem is the control over the communication paths, because they can be manipulated very easily and the whole traffic can be redirected. It’s amazing that only one ISP can take an entire country offline (e.g.Google and Japan). The military also has a strong interest in so-called “kill switches”, which are also actively managed. One of the reasons why we have DDoS attacks today is that there is no real control over incoming traffic, and only the one with the most resources can fend it off.
There are further problems with the transparency of the routing paths, because the sender cannot be sure that his package is taking the route for which it was originally intended and where it was actually routed. SCION would like to solve all these problems and more, which I have not listed here.


Now to SCION itself. What benefits does SCION offer?

  • High availability: end-to-end connection, no matter if there are network failures
  • Control over the path: ISP, transmitter and receiver together control the end-to-end paths.
  • Transparency: Clearly what happens to packages and who should be familiar with them
  • Secure network traffic authentication

ISD Overview
Source “SCION: A Secure Internet Architecture (Open Access PDF)”

The current concept of “autonomous aystems” (ASes) is adopted and these are regrouped into so-called “isolation domains” (ISDs). This is a major change to today’s architecture and some critical observers have come across the fact that the internet is being “parted”. However, if the whole concept is considered, this could work out. The “Core ASes” are directly connected to other Core ASs of other ISD, the rest via customers to provider or peering links. As an example, you can imagine a ISD as a country and Core-ASes are for example the larger providers.
Routing is ensured by a process called “beaconing”. Each ISD floods its network with so-called PCBs (path-segement construction beacons), which then authenticates each path and traverses all possible network paths. Every AS traversal is noted in the Beacon and so a protocol is created automatically, where the Beacon was passed through everywhere. These beacons can then be converted to path segments and registered in the network.

To do this, each AS needs some major components for SCION:

  • Beacon Servers: For information and path search; by generating, receiving and sending PCBs
  • Path Server: Registration and search of path segments
  • Certificate Server: Helps validate path information
  • Name server: Similar to DNS, but for SCION addresses (whole path segments)
  • Border router: Connects different ASes that support SCION. Distinguish between service communication and data packets. Supports all common protocols (OSPF, SDN, MPLS)

Path Lookup
Source “SCION: Slides Architecture Overview”

If my client now wants to contact a host, a query is made to the local path server, similar to the DNS, asking which paths are available. If they are not cached, the request is forwarded to the core path server. If the host has no information about it (e. g. the host is located in another ISD), it asks the remote path server. Finally, the client receives all available paths/segments in response.
If there is a network interruption, the client already has backup paths or if the path is “clogged”, a different route can be choosen very quickly and automatically due to the bandwidth and latency information, which is also available in the path-segemt info. The ISP has control over which paths are made available, and yet the client has the choice of which path to choose. In addition, it is transparent where the packet is routed through.

The whole concept was designed with “security in mind”, therefore all ISD configurations are secured and managed by the Core-ASes with an own PKI infrastructure. Since I haven’t dealt with this myself much more deeply, I can only reflect what emerged from the statements and questions: It takes more than one Core AS to make major changes and multiple “evil” ASs to infiltrate the ISD’s network.

TRC Infrastructure
Source SCION: A Secure Internet Architecture (Open Access PDF)"

Each ISD has a trust root configuration (TRC) which defines the cryptographic configurations in the ISD. In order to exchange traffic with other ISDs, the TRCs must be cross-signed with the neighboured Domains. These signatures allow the clients to verify the paths and various other information. But this is also one of the challenges, because if something goes wrong with these configurations and signatures, there is no connection. For more information, seeSCION Book.
One of the exciting aspects I found was that packages are signed with a MAC (Message Authentication Code) to verify the paths. Immediately afterwards, someone asked Adrian Perrig if the cryptographic operations would slow down the network. He proudly replied that with 128 bit CBC ciphers and AESni supported hardware (which by the way almost every device has) only ~30 CPU cycles are needed. A comparison: a lookup in memory takes ~200 cycles. “This also saves energy!”, was his statement.
This now also addresses the problems with the incoming traffic at the border gateways. If it is not signed or unknown (so-called default off), it is simply ignored.

In the following round of discussions various interesting questions were asked, among others how much the deployment would cost and if it would not be as it is with IPv6. IPv6 had the launch on June 6th, 2012 and is only rolled out to 23% (status 09.11.2017). Unlike IPv6, SCION would have real and many advantages (multipath, auto-failover, transparency, resiliency, etc.). Perrig’s generous estimate of costs is CHF 25 million CHF for the whole of Switzerland (including hardware, training of personnel, etc.).
By way of comparison, a 400-metre highway in Switzerland costs 27 million CHF. Personally, I could live without 400 meters of road to have a safer Internet :).


All in all, I think the concept very interesting and I am curious to see how the still open challenges will be solved. A proof-of-concept is already underway, because there is already an active SCION network, as the map on the SCION Website shows, and some of the parties involved in Switzerland were mentioned in the talk. If administration of the infrastructure is easily possible (e. g. exchanging the signatures etc.), this concept could really become established.
Currently, a draft for the IETF is being worked on, but once it is adopted, this could really turn the Internet upside down. However, this could take some time.

Source / Code

The participation in the network can be tested with a virtual machine (image), which I will try out next. The whole development is open source, the code can be found on Github:

More Links: