Register now: SCION Day 2024 on 22 October 2024! Visit
Search
Talk to us
Search
START TYPING AND PRESS ENTER TO SEARCH
Join us
Talk to us

FIXING THE INTERNET ROUTING SYSTEM

The Internet comprises more than 75,000 interconnected networks that exchange data such as pictures, videos, calls, financial and personal information. These networks are connected to each other using routers that dynamically build a map of the Internet with the Border Gateway Protocol (or BGP), allowing traffic to be forwarded from router to router to its final destination, typically using the most optimal path through the Internet.
More
BGP was originally designed in the 1980s, a time when security was not a significant consideration, as the smaller number of participating networks could be expected to cooperate to keep the network in good health. The Internet is therefore inherently based on unverified trust between networks — namely, that a network (known as an Autonomous System or AS) will only advertise IP prefixes (or routes) that it legitimately holds, will only announce routes to other ASes that it can actually reach, and will only send packets with the correct source IP addresses.

Another problem with BGP is that it typically selects routes based on the fewest number of logical hops to a destination and doesn’t consider other factors such as physical distances, congested links or geopolitical considerations, which can be an issue for reliable data transmission and ensuring data security. When there is a change in the reachability of one or more networks, BGP also needs to recalculate how to send data across the Internet. This so-called convergence can take several minutes, causing delays and/or data loss.

Unfortunately, this means the Internet can no longer meet the security and reliability needs of many organizations and users, particularly those in the finance, healthcare, utilities, and public sectors, as well as operators of critical infrastructure.

For more read the blog “Overcoming BGP's limitations with SCION”

INTERNET ROUTING ISSUES

The issues with BGP have been understood for many years, and the Internet industry has attempted to develop a number of solutions, but these have been slow to be adopted and do not currently offer a complete fix.

Gaps in routing security

It is trivial and, unfortunately, quite common for networks (ASes) to announce incorrect information, whether accidentally or for malicious purposes, and/or allow packets to be sent out with forged (or spoofed) IP source addresses.
More

This can variously lead to service disruption, traffic interception, redirection or modification, and large-scale Distributed Denial-of-Service (DDoS) attacks, all of which pose significant and substantial security risks to enterprises, governments, and end users. In particular, activists and criminals have increasingly targeted the routing system to steal data and cause disruption, while state-level actors have also manipulated it to impose censorship, undertake espionage, and/or conduct cyberwarfare.

While RPKI (Resource Public Key Infrastructure) is being deployed to allow the ownership of networks to be cryptographically verified, it requires widespread adoption to be effective, and as of 2024, less than 50% of the nearly one million IP prefixes currently have valid Route Origin Authorizations (ROAs). Even fewer networks (around 5%) are currently checking ROAs using Route Origin Validation (ROV), and even this only checks the details of the destination network and does not validate paths through the Internet. Moreover, the RPKI system is provisioned by third parties—specifically Regional Internet Registries (RIRs), who are authoritative and generally reliable—which can contain errors and/or be subject to hacking.

Routing security
Gaps in routing security

Lack of path selection, control & validation

BGP is designed to automatically discover how to send data to particular destinations on the Internet, but users have no control over the paths their data takes. This means that data can be (and often is) routed through different countries and over unsafe or congested networks.
More
Although BGPSEC was designed as a security extension of BGP to provide cryptographic assurances that every router (hop) en route to a destination has authorized the advertisement of that route, deployment is challenging as it needs to be explicitly supported by all routers along a path to achieve its full benefits. It is also computationally intensive, as each hop must be cryptographically verified at startup and when routes change, which can introduce significant delays in convergence even when the routers are capable of handling the additional computation. As a consequence, BGPSEC has yet to see much deployment and—when and if this happens—explicit path selection across the Internet is still not possible with the current protocol.
Gaps in routing security

Challenges in enforcing data sovereignty

BGP can, and often does, send traffic across international boundaries. Users have little or no control over this and are often unaware of the path their data is taking across the Internet to its destination.
More
In addition to introducing the possibility that traffic can be disrupted, intercepted, and/or monitored by bad actors, sending data outside of particular jurisdictions (e.g., the CH, EU/EEA) can breach national and supranational data protection legislation (e.g., FADP, GDPR). This is a particular issue in the healthcare, critical infrastructure, military, and public services sectors, where it is especially important to know and control the paths that data is taking across the Internet.
Gaps in routing security

SCION, built on trust for today’s needs

SCION gives senders control over the path their data takes.
MORE Security

In today’s Internet, users need to be able to trust the networks to which they are sending their data and the networks through which their data passes. SCION has been designed with security considerations at the forefront, introducing the concept of trusted networks and domains combined with robust verification to address the existing issues with how data is sent over the Internet.

MORE Reliability

SCION can use existing Internet infrastructure but offers fast multi-path discovery and path selection. Users can select how their data is sent to other SCION networks, as applications are able to choose paths based on optimal characteristics or other parameters. Applications can also very quickly switch (within 1 or 2 seconds) to alternative paths in the event of link failure, congestion, or denial-of-service attacks, providing higher levels of assurance of availability and reliability.

Become a member

SCION advantages

Trusted networks for reduced attack surface

With SCION, networks (ASes) can be grouped into common trust domains (known as ISDs) with agreed trust policies. ISDs can establish their own trust roots and maintain their own PKI services to cryptographically verify each participating AS, so are not reliant on third party PKIs (e.g. Global CAs). This offers advantages to industry sectors and communities that require enhanced trust and data governance policies.

Path validation against route leaks and spoofing

ISDs may choose how they advertise their network topologies and how they send and receive traffic from other ISDs. Unlike with BGP, every hop on the paths between origin and destination networks is cryptographically verified which provides protection against route leaks, hijacks and IP address spoofing.

Geofencing for data sovereignty

SCION discovers path segments (hops) between networks which are assembled into cryptographically verified paths to which particular attributes can be assigned or dynamically calculated. Users may then select the path(s) by which to send their data across the Internet, based on optimal characteristics or other parameters (e.g. geofencing). Hidden path segments can be configured so they are only visible and available to authorized networks which can help protect against denial-of-service attacks.

Multi-path and fast fail-over for network uptime

SCION discovers path segments (hops) and assembles these into available paths to destinations in advance, so is therefore not reliant on iterative BGP convergence. This allows users to very quickly switch between paths and use multiple paths simultaneously, thereby increasing resilience and reliability in mission-critical networks as well as helping protect against denial-of-service attacks.

Scalable and interoperable for easy deployment

SCION is based on Internet protocols and can utilize existing Internet infrastructure. No change is needed to the internal network infrastructure of a network operator, and devices that are not SCION enabled can utilize SCION gateways.

The aim is to have the SCION technology recognised as an IETF standard, and several Internet Drafts describing the various aspects have been published and are currently progressing through the IETF with a view to being published as RFCs.

SCION FEATURES: HOW SCION WORKS

SCION addresses many of the existing issues with how data is sent over the Internet, including those relating to inter-domain routing security and path selection. It introduces the concept of trusted networks and domains, and supports fast multi-path discovery and failover between participating networks.

Scion features

Trust model based on Isolation Domains (ISDs)

The SCION trust model is based around Isolation Domains (ISDs) that are logical groupings of participating networks (ASes) sharing a uniform trust environment – namely a common jurisdiction with agreed trust policies. Each ISD is administered by one or more core ASes who collectively generate a trust root called the Trust Root Configuration (a collection of X.509 certificates with ISD information). This is used to establish a standalone CA (i.e. one that is not reliant on third-party CAs) to issue certificates to each AS in the ISD, which can then be validated by the SCION Control Plane. It allows operators and users to establish and manage their own trust criteria and choose with whom to send, receive and transit traffic.

Control plane

SCION utilizes a beaconing mechanism to discover path segments between ASes, which are then assembled into available routing paths that are cryptographically validated using the certificates issued to each AS in an ISD. It is necessary for each ASN in an ISD to run control plane services that include beaconing, path mapping and certificate/key management, and are typically provided by dedicated hardware or run in a Docker container.

By grouping ASes into ISDs, this also isolates their control planes and reduces communications overhead with the rest of the Internet. In addition, only explicitly allowed traffic is exchanged between ISDs.

Routing

SCION sends data from network-to-network using simplified routers that are set-up on the borders of an AS, without changes being needed to the internal structure of that AS. These SCION-enabled routers peer with other SCION-enabled routers to forward and receive customer traffic and do not need to undertake control plane operations which are handled by the control services for each ISD. Endpoints can either run a SCION-aware stack or alternatively utilize a SCION gateway.

Download technical resources

SCION Technical PPT
SCION Technical DEEP DIVE
Download the presentation
SCION TECHNICAL OVERVIEW<br />
BOOK: The Complete Guide to SCION (2022)
Download the book
SCION overview at IEFT
SCION overview @ IETF
See IETF draft

Frequently asked questions

Contact us
How can SCION be deployed on the Internet?

SCION can be incrementally deployed at ISPs, who can make use of SCION’s features to route traffic through the backbone of the Internet. This is done by (transparently to end-users) encapsulating SCION packets inside IP packets. At the edges, encapsulation is removed and SCION packets are routed as usual. If a SCION path exists between two or more SCION-enabled ISPs, encapsulation is not needed.

Which ports does SCION run on?

The SCION protocol can be encapsulated on top of UDP. For more details, see the developer docs: https://docs.scion.org/en/latest/manuals/router.html#port-table.

What is the operating system that SCION runs on?
There are multipel implementations of SCION that run on various platforms (e.g. Ubuntu, OpenWRT, etc.). For the open source implementation scionproto, see the release page: https://github.com/scionproto/scion/releases. You can also see a list of related implementations: 
https://github.com/scionproto/awesome-scion.
Why use ISDs? Shouldn't the Internet be a globally-connected entity?
Even with SCION, the Internet remains globally connected – entities anywhere in the world should still be able to communicate with one another using SCION. ISDs provide guarantees that traffic between entities in the same ISD will not exit the ISD, and that traffic will follow known paths. ISDs can also send traffic to other ISDs over known paths in accordance with agreed policies, and also to the rest of the Internet if configured to do so. This means that assurances can be provided about where traffic is routed, and that traffic should not diverted through unknown networks by route leaks and hijacks.
Is SCION a source-routed architecture? What are differences with segment routing?
In SCION, endpoints choose network paths, similarly to source routing. Source routing does not scale to the whole Internet because the source would need to know the entire network topology to determine paths, nor does it allow the receiver or ISPs to control the path. By contrast, SCION enables ISPs, senders and receivers to control the end-to-end path across the networks as they do not need to know the network topology. In this Anapaya blog post you can find more information about the topic (https://www.anapaya.net/blog/scion-vs.-segment-routing), including relations to Segment Routing.
Does SCION need flow state to be set up on intermediate routers before communication can occur?
No, SCION routers do not have any per-flow state. Senders can simply place hop fields from a path in a packet header and send the packet to the destination without any required setup.
How is SCION overcoming configuration errors? Is this simply an artifact of the isolation property (one AS's errors don't impact others) or the reduction in configuration complexity?
On the Internet today, a BGP misconfiguration can result in a route leak or hijack whereby traffic may be inadvertently or intentionally be diverted through an AS where it should not be sent, or even blackholed. SCION’s secure routing architecture prevents incorrect route announcements from being accepted by other ASes due to the absence of correct cryptographic authenticators. Misconfiguration can also result in incorrect forwarding tables. In SCION, ASes cryptographically verify each hop in order to forward traffic, so packets cannot be sent along an incorrect path.
How is SCION's multi-path routing concealing link failures from applications? A loss of some packets on a path will still introduce delays and retransmissions.
Indeed there is an RTT delay for each lost packet, but SCION will quickly determine a failed path and re-direct traffic to a working path or paths.
Does SCION work for hosts behind NATs?
Yes.
How does SCION Interoperate with the existing Internet?
SCION-IP gateways are used to translate from SCION to IP. FOr more information, see the documentation: https://docs.scion.org/en/latest/sig.html.
Does SCION replace existing Internet protocols?
The SCION productive network is deployed in parallel to the regular Internet. In some deployment scenarios, a regular Internet connection may also be used as an additional backup, although with less guarantees.
Does SCION support IPv6?
Yes, for more details see the SCION data plane specification: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane.
What network layer(s) does SCION operate at?
SCION data plane operates at the network layer 3 when transporting inter-domain traffic from one AS to another. Inside an AS, SCION can run on top of layer 3, similarly to a VPN.
What hardware and software is needed to run SCION?

SCION routing does not require specialized hardware, therefore it runs on commercial off-the shelf hardware or in virtualized platforms.

Is SCION standardized?

There is ongoing work at the IETF and at the Association’s Standardization Committee.

WE’RE HAPPY TO SHARE OUR INSIGHTS AT INDUSTRY EVENTS

If you’re interested in having us present SCION, don’t hesitate to reach out to us.

Contact us