SCION: Secure, Scalable Next-Gen Internet
- SCION is a clean-slate inter-domain Internet architecture that provides explicit AS-level path choices, isolation, and robust security for enhanced network resilience.
- It employs a separated control and data plane design with cryptographically secured forwarding state, enabling multipath communication and rapid path recovery.
- The architecture leverages ISolation Domains (ISDs) and Trust Root Configurations (TRCs) to incorporate heterogeneous trust, offering improved censorship resilience and global reachability.
SCION, short for “Scalability, Control, and Isolation on Next-Generation Networks,” is a clean-slate inter-domain Internet architecture designed to address the availability, scalability, and security shortcomings of the current Internet. Its defining property is path awareness: endpoints obtain explicit AS-level paths, can know and verify which ASes their packets traverse, and can select or restrict paths while using multipath communication for redundancy and performance. SCION separates control and data planes, encodes forwarding state in packets, and organizes the network into ISolation Domains (ISDs) governed by Trust Root Configurations (TRCs), thereby combining routing control, heterogeneous trust, and failure isolation (Barrera et al., 2015).
1. Design objectives and system model
SCION was introduced to provide availability in the presence of adversaries, transparency and control, efficiency, scalability, extensibility, support for global but heterogeneous trust, deployability, and isolation. The architecture assumes that incremental fixes to the current Internet are constrained by architectural limitations, especially with respect to path control, trust-root agility, and resilience to failures, hijacks, and policy subversion. Its model therefore gives end hosts explicit influence over inter-domain routing while keeping forwarding simple at border routers (Barrera et al., 2015).
A central architectural abstraction is the ISD, a logical grouping of ASes, typically aligned with legal or administrative boundaries. Each ISD is run by one or more Core ASes and governed by a TRC, which specifies trust roots and policies. TRCs are versioned and cross-signed, allowing secure global validation while preserving jurisdictional trust separation. This design is intended to provide meaningful trust roots with distinct administrative scopes rather than a single global root set (Barrera et al., 2015).
| Element | Role |
|---|---|
| ISD | Logical grouping of ASes providing propagation and isolation of trust, policy, and failures |
| Core ASes | Administrators of an ISD |
| TRC | Specifies trust roots and policies |
| PCB | Periodic path-construction beacon for path discovery |
| PCFS | Packet-carried forwarding state used in data-plane forwarding |
| Opaque Field (OF) | Per-AS cryptographically protected forwarding field |
The resulting design is neither conventional hop-by-hop routing nor unrestricted source routing. End hosts choose from a manageable set of discovered paths, and routers validate and forward packets based on packet-carried state rather than large inter-domain routing tables. This suggests that SCION’s notion of control is deliberately constrained: it exposes explicit path choice to endpoints, but only over paths that have been discovered and authorized by the control plane (Barrera et al., 2015).
2. Control plane, path construction, and forwarding
SCION cleanly separates the control plane from the data plane. In the control plane, Path Construction Beacons (PCBs) are periodically disseminated from ISD cores to discover possible paths. Each AS appends its own path information and cryptographically signs or MACs the beacon. Path servers maintain and announce mappings from ASes to path segments, while certificate servers distribute and cache TRCs and certificates (Barrera et al., 2015).
End-to-end paths are formed by composing up-segments, core-segments, and down-segments. For a source in one ISD and a destination in another, path construction follows the composition
The architecture also supports shortcuts, including intersections before the core and peering shortcuts, when such compositions exist. PCB dissemination every 10–15 seconds is intended to refresh working paths rapidly after failures, and end hosts use multipath by default (Barrera et al., 2015).
In the data plane, packets carry PCFS as a sequence of Opaque Fields, one per AS hop. An OF is an 8-byte cryptographically protected field that carries ingress interface, egress interface, expiration, and a MAC. Border routers use OFs to verify that a packet arrived via the correct ingress interface and to determine the egress interface for the next hop. No inter-domain routing tables are needed for packet forwarding, and only border routers at the destination AS need to inspect the destination address. The architecture also supports arbitrary local addressing, including IPv4, IPv6, MAC, and AIP, by separating the locator function of the AS path from the identifier function of the host address (Barrera et al., 2015).
The original design reports a typical header overhead of bytes, where is the AS-path length, and states that the average AS-path is approximately 4–5 hops. That design point is significant because it captures SCION’s core trade-off: larger headers in exchange for transparent, cryptographically protected forwarding state and elimination of inter-domain lookup complexity (Barrera et al., 2015).
3. Security, trust agility, and formal verification
SCION’s security model is adversarial. It considers on-path and off-path attackers, fully compromised ASes, misbehaving entities, and malicious roots of trust, while assuming an honest majority for TRC signatures. Control-plane information is cryptographically secured, and the architecture includes path and entity validation mechanisms such as DRKey and path-validation work such as OPT. The design also emphasizes algorithm agility, allowing each AS to change keys or signature algorithms independently (Barrera et al., 2015).
The data-plane cryptographic mechanism used by SCION routers was formalized in later work on router verification. In that model, hop-field MACs take the form
and the segment identifier is updated as
This construction allows each AS to locally validate its position on a path, while the nested MAC/XOR structure authorizes all previous hops in the segment (Pereira et al., 2024).
A major development was the verification of the first formally-verified Internet router, implemented as a SCION border router. The verification linked protocol models in Isabelle/HOL with verification of production Go code using Gobra, proving memory safety, crash freedom, freedom from data races, termination of packet processing, and adherence to the protocol model. At the protocol level, the work established path authorization, valley freedom, and loop freedom as trace invariants, even under strong adversary models including a Dolev–Yao attacker and compromise of some AS secrets. The effort uncovered five previously unknown protocol attacks and thirteen new implementation bugs, all confirmed by developers, and led to strengthened security checks (Pereira et al., 2024).
A common misconception is that SCION’s security properties are exhausted by cryptographic path validation. The formal-verification results indicate otherwise: the architecture’s practical security also depends on faithful implementation of buffering, interface checks, packet parsing, and concurrency semantics. In SCION, protocol assurance and code assurance were treated as linked obligations rather than as independent concerns (Pereira et al., 2024).
4. Measured path dynamics and multipath transport
Deployed-path measurements on the global SCIONLab testbed show that SCION’s path diversity is real, but highly dynamic. A four-week longitudinal study found significant control-plane churn, with path sets changing frequently and many paths being short-lived. Between one pair of measurement locations, the study observed 161 path-change events with 557 paths added and 577 removed, with mean lifetime approximately 15.7 hours; another pair showed 301 events, 1254 paths added, 1259 removed, and mean lifetime approximately 8.6 hours. The path-lifetime histogram showed that most paths lived less than 27 hours. The same work identified path discrepancy, meaning asymmetric path availability between endpoints caused by independently applied routing policies (Herschbach et al., 4 Sep 2025).
The study also found a systematic performance trade-off in concurrent multipath use. Parallel use of several paths increased aggregate throughput compared with the best single path, but individual paths experienced worse latency, jitter, and loss in multipath mode than in single-path mode. The paper therefore argued that protocols such as MPQUIC should not assume stable, symmetric path sets and should distinguish between path classes for latency-sensitive and bulk traffic (Herschbach et al., 4 Sep 2025).
A complementary simulation study analyzed decentralized path selection in a SCION-like path-aware environment using four axioms: Efficiency , Loss Avoidance, Stability , and Fairness as measured by Jain’s Index. The study compared Min-RTT, Round-Robin, and Epsilon-Greedy strategies. Purely greedy Min-RTT was efficient under low load but became catastrophically unstable as competing agents increased, with packet loss rising from 2.44 Mbps at 10 agents to 454.24 Mbps at 500 agents, an increase of over 18,000%. Round-Robin remained very stable and maximally fair with but underutilized high-capacity paths. Epsilon-Greedy provided the best compromise, reaching the highest efficiency at 500 agents with Mbps and improving fairness relative to Min-RTT, with 0 versus 0.34 for Min-RTT (Baumeister et al., 7 Sep 2025).
These results challenge a second common misconception: that exposing many paths to endpoints is sufficient for robust multipath transport. The measurement and simulation literature instead suggests that path diversity without path-selection discipline can amplify contention, oscillation, and asymmetry. In SCION, host control is powerful, but it creates a nontrivial scheduling problem at the transport layer (Herschbach et al., 4 Sep 2025).
5. Censorship resilience, reachability, and system-level applications
SCION has been studied as an architecture for censorship resilience and global Internet reachability. A quantitative framework introduced Avoidability Potential (AP), specialized as Censorship Resilience Potential (CRP) and Global Reachability Potential (GRP), to compare BGP/IP, a waypoint-based overlay, and SCION on identical AS-level topologies. In that analysis, SCION’s path awareness and multipath support allowed sources to avoid undesirable ASes whenever such paths existed, yielding substantially better resilience than either BGP/IP or overlay routing for modest numbers of collaborating censors. For global reachability, the paper reported that SCION’s GRP approaches 1.0 for all country sets examined, with values above 0.99 in all cases in the reported table, whereas BGP remained below 0.6 for central countries. The same work also stated an important limit: if almost all exit ASes are compromised, SCION, like any architecture, cannot provide full resilience (Ivanović et al., 2024).
The architecture has also been used as a substrate for systems requiring strong timing, path control, or policy enforcement. G-SINC, a Byzantine fault-tolerant global clock-synchronization infrastructure built on SCION, uses SCION’s multipath routing, path transparency and control, path reversibility or symmetry, TRCs, and scalable authentication. Its evaluation reported that over 94% of time servers reliably minimize the offset of their local clocks to real time in the presence of up to 20% malicious nodes, and that all time servers remain synchronized with a skew of only 2 ms even after one year of reference clock outage (Frei et al., 2022).
In peer-to-peer transfer, BitTorrent over SCION introduced the notion of path-level peers, allowing separate QUIC connections over different SCION paths. In a small-scale Internet topology, the study observed an increase in goodput of 48% compared to BitTorrent over BGP and 33% compared to a BGP-M candidate; for a 10-AS torrent network it reported a 38% goodput increase over BGP. Download time was reduced to 69% of BGP in the 5-AS case and 73% in the 10-AS case (Gartner et al., 2023).
SCION has also been used for browser-enforced policy routing and for cyber-physical control. A browser prototype for geo-fenced browsing used SCION path policies in a browser extension and local proxy, demonstrating feasibility without introducing any significant performance overheads (Davidson et al., 2022). In power systems, a real-time reserve-dispatch framework for fast frequency response exploited SCION’s latency-minimum path selection, reporting a 99th percentile latency of approximately 410 ms for SCION versus approximately 480 ms for BGP, a 70 ms improvement in the evaluated setting (Zhang et al., 11 Jan 2026).
Taken together, these studies position SCION less as a single-purpose secure-routing proposal than as a general path-aware substrate. The common thread is not merely stronger security, but the combination of explicit path choice, multipath support, and trust-root and policy separation at Internet scale (Ivanović et al., 2024).
6. Deployment status, limitations, and homonymous usages
SCION was designed for incremental, low-cost deployment. ISPs need border routers and a small set of servers rather than changes to intra-domain infrastructure, and the architecture can operate over the existing IP substrate. The 2015 retrospective reported a global testbed with 3 ISDs, 20+ ASes, and presence on over 5 continents. Mechanisms such as DENA were proposed to enable near-zero-friction end-user adoption, while extensions such as SIBRA, HORNET, and LAP were developed around the architecture (Barrera et al., 2015).
At the same time, the literature repeatedly marks deployment maturity as a limitation. The censorship-resilience study described current SCION deployment as small and interpreted many results prospectively rather than as a description of the present Internet (Ivanović et al., 2024). The SCIONLab measurements also warned that some observed issues may be exacerbated by testbed, VPN, or overlay artifacts, and that production deployments may be more stable. This suggests that current empirical studies should be read as lower-bound robustness requirements for transport and application design rather than as definitive steady-state properties of all future SCION deployments (Herschbach et al., 4 Sep 2025).
The name “Scion” also appears in unrelated arXiv contexts. In machine learning, Scion denotes a norm-based optimizer whose optimal hyperparameter scaling is linked to an invariant output-layer operator norm (Filatov et al., 4 Oct 2025). In computer graphics and scientific computing, Scion denotes a domain-specific language and compiler for data-layout polymorphism in bounding volume hierarchies (Gyurgyik et al., 19 Nov 2025). In AI4Science, SCION denotes “Scientific Collaborative Innovation with Agentic Organizational Nexus,” an agentic scientific operating system built around the Research Execution Plan (REP) (Zheng et al., 4 Jul 2026). These homonymous usages are distinct from the path-aware Internet architecture.
In networking, however, SCION retains a comparatively specific meaning: a path-aware inter-domain architecture organized around ISDs, TRCs, PCBs, PCFS, and endpoint-visible path choice. The principal research question is no longer whether such a design can be specified, but how its control, trust, transport, and application semantics behave under real deployment, adversarial pressure, and large-scale multipath use.