SCION — Scalability, Control, and Isolation on Next-Generation Networks — is a secure and reliable inter-domain routing protocol. It empowers Internet Service Providers (ISPs) and other service providers to establish new products and services. SCION can even enable completely new business models. It combines performance and reliability with strong security properties, such as the guarantee that packets will travel only along previously authorized paths, eradicating the traffic-attraction attacks of today’s Internet and enabling sophisticated traffic control such as geofencing.
Designed by researchers at ETH Zürich, Carnegie Mellon University, and other partner institutions, SCION is now deployed for critical infrastructure communication by industry and government. SCION is natively secure and multipath:
- Multipath and traffic engineering: SCION provides strong control over traffic paths, and explicit trust information for end-to-end communication. SCION hosts can use multiple paths, leveraging all network links for optimal performance. This opens new traffic engineering scenarios.
- Reliability: Multipath routing enables the simultaneous use of multiple network paths, enabling rapid failover to redundant paths within milliseconds. Thanks to a sovereign Internet infrastructure, network operation is possible even in the presence of adversaries.
- Security and control: Routing information is always authenticated. Thanks to formal verification, SCION provides strong assurance for its security properties. Routing attacks are impossible by design, and communication is guaranteed despite DDoS attacks. Path control enables routing traffic around untrusted infrastructure or jurisdictions.
How does it work?
SCION is a clean-slate architecture, overcoming limitations of today’s IP and BGP-based Internet. It builds upon three concepts:
- Explicit and transparent trust (see Figure 1). SCION Autonomous Systems (ASes) are grouped into isolation domains (ISDs), establishing a uniform trust environment. ISDs provide transparency and control over the roots of trust that need to be relied upon. A compromised or faulty ISD does not affect others, allowing sovereign network operation.
- Secure multipath routing. A distributed control plane constructs and disseminates path segments. Routing information is propagated through beaconing, and it is protected cryptographically. SCION is used for inter-domain routing only, allowing ISPs to reuse existing intra-domain network infrastructure.
- Authenticated packet forwarding (see Figure 2). SCION hosts combine path segments into end-to-end paths. Packets carry the authenticated forwarding state, so routers are simple and efficient thanks to the absence of inter-domain forwarding tables. As packets contain the full end-to-end path, geofencing is possible.
Regular IP hosts can benefit from SCION thanks to a SCION IP Gateway (SIG) that encapsulates IP into SCION packets.
Multipath opens new business models for ISPs
Time will tell which additional business models are invented and which will ultimately be successful in the Internet of the 21st century. However, SCION ISPs can provide premium paths (with a lower latency) to customers and new LEO satellite networks paths can be integrated in SCION. Dynamic path selection enables path optimization according to a set of policies such as latency, bandwidth, trust, and so on.
In addition, ISPs are empowered to build sovereign networks, with strict geofencing rules that enforce residency even for data in transit. Our recent research is also looking into how a CO2 footprint can be considered when it comes to path selection, so with incentivizing low carbon footprint routing, traffic could flow towards the ISPs who produce less CO2 per packet.
An architecture used for critical infrastructure
Today’s private connectivity solutions such as leased lines, MPLS, or SD-WAN, offer connectivity with stronger guarantees than the public Internet but are mostly limited to a single ISP or vendor deployment.
SCION is federated like the Internet, and therefore it is well suited for scenarios where heterogeneous organizations and ISPs interconnect. As an example, the Secure Swiss Finance Network (SSFN) leverages SCION to provide a reliable and secure communication fabric for Swiss finance. The network spans across multiple ISPs and financial institutions.
Why SCION? Isn’t RPKI good enough?
“Securing origin-AS doesn’t stop bad things from happening”
George Michaelson, APNIC Blog.
The issue is that RPKI protects route origins, but not the path. This leaves RPKI-enabled networks exposed to traffic redirects and snooping. In addition, RPKI does not address other fundamental issues behind BGP, such as convergence time, or the fact that everyone needs to agree on a few trust roots.
Great, how do I connect?
As an ISP, you can join SCION by deploying one or more SCION routers at the edge of your network. SCION routers run as software on commodity server hardware, minimizing adoption costs.
Within your network, SCION reuses existing intra-domain connectivity, so there are no changes required. You can connect to the global production network by peering with another SCION ISP. In Switzerland, Swiss-IX offers a dedicated SCION peering mesh where peering with all the major Swiss SCION ISPs and Anapaya is possible. Further peering opportunities with Anapaya are available at Equinix Frankfurt, Equinix Singapore, and Hong Kong Mega-I. In South Korea, LGU+ is available for peering in various sites.
We also run SCIONLab, a global overlay research and development network. You can join, run your own SCION ASes, and experiment with the unique properties of the SCION architecture.
The website has a wealth of information on SCION architecture, or check out the open-source implementation at GitHub.
Nicola Rustignoli is a research assistant in Network Security at ETH Zürich, where he is responsible for deploying and promoting SCION.
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.
Dear Nicola:
0) Thanks for reporting this intriguing work. For an old timer of the PSTN era, it is refreshing to see in the first video (at time marker 2:00) on their website citing PSTN’s “5-9’s” availability versus Internet’s “3-9’s”. This says it all.
1) Perhaps due to the above reference, I should not be surprised that the presented architecture appears to be a “back to the future” proposal, because it looks very much the same as the traditional telephony hierarchical toll network. See Figure 4-4 on page 125 of the below document. — I have a hard copy of an older (1977) edition that showed an even simpler diagram of the same:
http://bitsavers.trailing-edge.com/communications/westernElectric/books/Engineering_and_Operations_in_the_Bell_System_2ed_1984.pdf
2) To properly correlate my speculation, would you please clarify the definition of the ISD (ISolation Domain)? That is, what sets the border lines that encircle an ISD? Or, which and how AS’s get grouped together under one ISD?
3) Once I understand the ISD, I may be able to share some of our own work with you.
Regards,
Abe (2021-10-10 11:26 EDT)
Dear Abraham,
Thank you for your questions.
1) Indeed, SCION uses a hierarchy between Core and “normal” ASes, and this recalls the PSTN hierarchy in the picture you mentioned. While we cannot directly compare SCION to PSTN, this hierarchy is meant to improve the scalability of the routing protocol by separating it into a process within and one between ISDs. Core ASes (the ones on top in Figure 1 in this blog post) are also in charge of administering their ISD.
2) Each ISD groups ASes that share a uniform trust environment (i.e. a common jurisdiction, the same industry, … ). ISDs can also overlap, so an AS may be part of several ISDs. So, overall, it is up to each AS to decide what ISD they’d like to join.
If you’re interested in more technical details about ISDs, you can look at page 37 of the SCION book https://scion-architecture.net/pdf/SCION-book.pdf . There will be a new edition coming soon.
3) Sure, feel free to get in touch, you can find my contacts on our group page https://netsec.ethz.ch/people/
Best,
Nicola
Dear Nicola:
0) I must have some ESP, because my mental clock reminded me to check in on your article this morning and I found your reply! From the time stamp, I should have received the eMail notification by the blog system as it normally did. I do not understand why it did not for this time.
1) Re: Ur Pt. 1): Although the hierarchical systems of SCION and PSTN may not appear to correlate directly / exactly, I believe that the principles are close enough to be called “the same” philosophically. This is one of my life-time learning from a couple of very respected professors during my graduate study. This perspective has been more than helpful in many occasions, to say the least. Allow me to carry on from this “common ground”.
2) Re: Ur. Pt. 2) ” … a uniform trust environment (i.e. a common jurisdiction, the same industry, … ). “: These are the exact keywords that I was hoping for! I had a quick glance of the material that you cited. But, I believe that we do not need to get into the nitty gritty at this moment. To synchronize our thoughts, please have a look at page 11 of the following white paper:
https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf
Our work was triggered by the exhaustion of IPv4 address pool. So, what you see in the diagram was focused on such aspect which expanded the assignable IPv4 public address pool by utilizing the long-reserved 240/4 netblock through the use of SPR (Semi-Public Router).
3) To deploy the SPR into the existing Internet, we identified a new layer of routers forming Sub-Internets each consisting of Caching Proxy serving as the Gateway to a RAN (Regional Area Network) that is made of SPRs with multiple levels as desired. As a result, not only the top level of “SPR + Caching Proxy” can naturally act like the Core ASs for your ISD functions, but also the lower level SPRs will be running on newly identified address resources (the 240/4 netblock) which by its nature, supports a lot of PSTN like characteristics, starting from straightforward administration, to robust cybersecurity. For example, with the RAN approach, an AS serving two RANs can use independent 240/4 address blocks under respective RANs avoiding any cross-ISD traffic leaks through the common AS.
So, I see a lot of synergy between the efforts of our two teams. I look forward to your thoughts after you have a chance to browse through the related documents on our website:
https://www.avinta.com/phoenix.htm
4) Re: Ur. Pt. 3): Great. I believe that it would be prudent for us to stay on this platform to keep other colleagues informed of our high level exchanges. When we begin to dig into the details, we should avoid burdening others by going offline.
Cheers!
Abe (2021-10-14 11:29 EDT)
“ SCION ISPs can provide premium paths (with a lower latency) to customers” sounds like a violation of Net Neutrality.
Hi Giuseppe,
This is indeed an interesting topic. Neutrality usually refers to ISPs differentiating traffic (i.e. with one application prioritised or slowed down versus others).
With SCION, things work a bit differently, in the sense that:
1) SCION ISPs offer multiple paths towards the same destination (or application). This means that traffic towards the same application can be differentiated (i.e. with business customers getting a lower latency path). This is a bit different from what exists today, in the sense that a SCION ISP can provide better network paths to the same application to premium customers, while regular ISPs can only provide better network paths to a different application. Indeed, if you look at the FCC rule [2] on net neutrality, “Paid prioritization occurs when a broadband provider accepts payment (monetary or otherwise) to manage its network in a way that benefits particular content, applications, services, or devices.”. The focus there is on prohibiting preferential treatment for certain applications (mostly due to anticompetitive practices / payments by application providers). With SCION, instead, you’d have preferential paths to the same app, and this would be paid by the end customer. As SCION packets contain paths, this would be fully transparent and visible to the end customer.
2) In today’s internet, net neutrality “violations” still arise as a result of traffic engineering or routing decisions (i.e., traffic shaping, using a congested peering link, peering disputes, … ). End users have no transparency nor control over this. SCION, instead, gives end users full transparency over network paths. There is a Hotnets 2015 paper [1] where you can find more arguments why we favour the concept of internet transparency rather than neutrality. Many of the arguments in there apply well to SCION.
I hope this clarifies your question.
[1] https://netsec.ethz.ch/publications/papers/transparency2015.pdf
[2] https://www.federalregister.gov/documents/2015/04/13/2015-07841/protecting-and-promoting-the-open-internet