Internet DRAFT - draft-dekater-panrg-scion-overview
draft-dekater-panrg-scion-overview
PANRG C. de Kater
Internet-Draft N. Rustignoli
Intended status: Informational SCION Association
Expires: 8 May 2024 A. Perrig
ETH Zuerich
5 November 2023
SCION Overview
draft-dekater-panrg-scion-overview-05
Abstract
The Internet has been successful beyond even the most optimistic
expectations and is intertwined with many aspects of our society.
But although the world-wide communication system guarantees global
reachability, the Internet has not primarily been built with security
and high availability in mind. The next-generation inter-network
architecture SCION (Scalability, Control, and Isolation On Next-
generation networks) aims to address these issues. SCION was
explicitly designed from the outset to offer security and
availability by default. The architecture provides route control,
failure isolation, and trust information for end-to-end
communication. It also enables multi-path routing between hosts.
This document discusses the motivations behind the SCION architecture
and gives a high-level overview of its fundamental components,
including its authentication model and the setup of the control- and
data plane. As SCION is already in production use today, the
document concludes with an overview of SCION deployments.
For detailed descriptions of SCION's components, refer to
[I-D.dekater-scion-pki], [I-D.dekater-scion-controlplane], and
[I-D.dekater-scion-dataplane]. A more detailed analysis of
relationships and dependencies between components is available in
[I-D.rustignoli-scion-components].
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://scionassociation.github.io/scion-overview_I-D/draft-dekater-
panrg-scion-overview.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-dekater-panrg-
scion-overview/.
de Kater, et al. Expires 8 May 2024 [Page 1]
Internet-Draft SCION I-D November 2023
Discussion of this document takes place on the WG Working Group
mailing list (mailto:panrg@irtf.org), which is archived at
https://datatracker.ietf.org/rg/panrg. Subscribe at
https://www.ietf.org/mailman/listinfo/panrg/.
Source for this draft and an issue tracker can be found at
https://github.com/scionassociation/scion-overview_I-D.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why SCION - Motivation . . . . . . . . . . . . . . . . . 3
1.1.1. Scope of SCION . . . . . . . . . . . . . . . . . . . 5
1.1.2. Practical Considerations Based on Related RFCs . . . 5
1.1.3. Why Now? . . . . . . . . . . . . . . . . . . . . . . 7
1.2. SCION Overview . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. Network Architecture and Naming . . . . . . . . . . . 7
1.2.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3. Link Failures . . . . . . . . . . . . . . . . . . . . 13
1.2.4. Formal Verification . . . . . . . . . . . . . . . . . 13
de Kater, et al. Expires 8 May 2024 [Page 2]
Internet-Draft SCION I-D November 2023
1.3. Conventions and Definitions . . . . . . . . . . . . . . . 13
2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. The Control-Plane PKI . . . . . . . . . . . . . . . . . . 14
2.1.1. Control-Plane PKI - Overview . . . . . . . . . . . . 14
2.1.2. Overview of Certificates, Keys, and Roles . . . . . 15
2.1.3. TRC Updates . . . . . . . . . . . . . . . . . . . . . 15
2.1.4. Revocation and Recovery from a Catastrophic Event . . 17
2.2. SCION Control Plane . . . . . . . . . . . . . . . . . . . 17
2.2.1. Path Exploration . . . . . . . . . . . . . . . . . . 18
2.2.2. Path Registration . . . . . . . . . . . . . . . . . . 20
2.2.3. Path Lookup . . . . . . . . . . . . . . . . . . . . . 21
2.3. SCION Data Plane . . . . . . . . . . . . . . . . . . . . 23
2.3.1. Path Construction via Segment Combination . . . . . . 24
2.3.2. SCION Header Specification . . . . . . . . . . . . . 26
2.3.3. Path Authorization . . . . . . . . . . . . . . . . . 29
2.3.4. Intra-AS Communication . . . . . . . . . . . . . . . 29
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1. Autonomous System Deployment . . . . . . . . . . . . . . 30
3.2. Internet Exchange Points . . . . . . . . . . . . . . . . 31
3.3. Endpoints and Incremental Deployability . . . . . . . . . 31
3.3.1. Native Endpoints . . . . . . . . . . . . . . . . . . 32
3.3.2. SCION to IP Gateway (SIG) . . . . . . . . . . . . . . 32
3.4. Deployment Experiences . . . . . . . . . . . . . . . . . 32
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References . . . . . . . . . . . . . . . . . . 33
6.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
The Introduction section explores the motivation to develop SCION,
followed by a short description of SCION's main elements. The
sections after the Introduction provide further insight into SCION's
key concepts and deployment scenarios. The document concludes with
some concrete case studies where SCION has been successfully deployed
in production.
1.1. Why SCION - Motivation
Since its inception, the Internet has continued to expand,
encompassing new uses over time. The continuous expansion has
brought many issues to light, including a lack of control,
limitations in scalability, performance and security, occurrences of
severe outages, weak fault isolation, and energy consumption. With
the core focus on functionality and operation, the current Internet
de Kater, et al. Expires 8 May 2024 [Page 3]
Internet-Draft SCION I-D November 2023
offers little protection against attacks such as spoofing, IP-address
hijacking, denial-of-service, and combinations of these. For more
background information, see [SCHUCHARD2011], [LABOVITZ2000],
[GRIFFIN1999], [SAHOO2009], and [RFC4264].
There have been numerous initiatives to address the above issues.
Although these initiatives have brought many improvements, concerns
regarding security and scalability still remain. For more details,
see, e.g., [RFC4033], [RFC6480], [RFC8205], and [RFC8446], as well as
[LYCHEV2013], [LI2014], [COOPER2013], [ROTHENBERGER2017],
[MORILLO2021], and [KING2022].
As a consequence, today's Internet fails to fulfil many users'
requirements. This especially pertains to the demands of enterprises
globally exchanging sensitive information, such as financial
institutions, healthcare providers, universities, multinationals,
governments, critical and transportation infrastructure operators.
These users require the Internet to be highly available at all times.
They expect reliable operation of the global network also in case of
failures. They need availability guarantees across multiple routing
domains, even in the presence of attacks. They further want to rely
on an Internet that can be multilaterally governed and is free from
global kill-switches.
SCION has been developed in order to meet the above-mentioned
requirements. SCION aims to reach the following goals:
* Provide high-availability architecture (also in the presence of
adversaries)
* Provide fast failover in the case of inter-domain link or router
failures
* Prevent from IP-address hijacking, DoS, and other attacks
* Enable path transparency as well as application-specific path
optimizations
* Improve the inter-domain control plane's scalability
* Prepare the Internet for tomorrow's applications, such as virtual
reality, Internet of Things (IoT), and all other applications
requiring high-performance connectivity.
de Kater, et al. Expires 8 May 2024 [Page 4]
Internet-Draft SCION I-D November 2023
1.1.1. Scope of SCION
The above section describes SCION's aspiration to improve _inter_-AS
routing and to focus on providing end-to-end connectivity. However,
SCION does not solve _intra_-AS routing issues, nor does it provide
end-to-end payload encryption, and identity authentication. These
topics, which are equally important for the Internet to perform well,
lie outside the scope of SCION.
1.1.2. Practical Considerations Based on Related RFCs
The SCION inter-domain routing concept has initially been developed
by researchers of the ETH Zuerich [PERRIG2017], and could in the
meantime also gain attention and recognition in the international
academic world. However, for an IT architecture to be successful, it
must work well in practice, too. This section pays attention to the
implementation considerations of a conceptual framework such as SCION
in real life, on the basis of some RFCs exploring this topic. It
also verifies in how far SCION meets the requirements mentioned and
questions raised in these RFCs.
1.1.2.1. Avoiding Pitfalls
[RFC9049] describes why previous proposals to tackle some of the
Internet's fundamental issues did not manage to succeed. SCION seems
to avoid the pitfalls mentioned in that document. For example, SCION
does not have to be adopted by the entire Internet to be effective:
The routing architecture provides benefits already to early adapters.
Even if only a small part of the global network works with SCION,
adapters will still take advantage of using the SCION routing
technology. Moreover, not only users of SCION benefit from it, also
ISPs and operators benefit from deploying SCION: early deployments
showed that providers can charge the use of SCION as premium
connectivity, with users who are willing to pay for it. Furthermore,
SCION can be installed on top of and function alongside the existing
routing infrastructure and protocols--there is no need for high-
impact changes in an operational network.
de Kater, et al. Expires 8 May 2024 [Page 5]
Internet-Draft SCION I-D November 2023
Another RFC that must be mentioned in this context is [RFC5218],
"What Makes for a Successful Protocol?". SCION seems to fulfil most
factors that contribute to the success of a protocol, as described in
section 2.1 of the RFC. This includes such factors as offering a
positive net value (i.e., the benefits of deploying SCION outweigh
the costs), incremental deployability, and open source code
availability. More importantly, SCION averts the failure criteria
mentioned in section 1.4 of the RFC: SCION is already deployed and in
use by many actors of the Swiss financial and academic ecosystems,
and allows for multiple implementations, both open and closed source.
As existing SCION implementations are easily portable, adoption in
mainstream platforms is also possible.
1.1.2.2. Answering Questions
SCION can be considered a _path-aware internetworking_ architecture,
as described in [RFC9217]. This RFC poses (open) questions that must
be answered in order to realize such a path-aware networking system.
It was originally written to frame discussions in the Path Aware
Networking Research Group (PANRG), and has been published to snapshot
current thinking in this space.
SCION intends to answer the questions raised in this RFC. This
especially pertains to the second, third, seventh, and eighth
question:
* How do endpoints and applications get access to accurate, useful,
and trustworthy path properties?
* How can endpoints select paths to use for traffic in a way that
can be trusted by the network, the endpoints, and the applications
using them?
* How can a path-aware network in a path-aware internetwork be
effectively operated, given control inputs from network
administrators, application designers, and end users?
* How can the incentives of network operators and end users be
aligned to realize the vision of path-aware networking, and how
can the transition from current ("path-oblivious") to path-aware
networking be managed?
SCION's answers to these questions can be found in Key Concepts
(Section 2) and Deployments (Section 3.4), respectively.
de Kater, et al. Expires 8 May 2024 [Page 6]
Internet-Draft SCION I-D November 2023
1.1.3. Why Now?
The emergence of multiple SCION implementations and early deployments
highlights the need for standardization. The time seems therefore
ripe to take SCION to the IETF, also in order to contribute to the
important discussion regarding path-aware networking.
1.2. SCION Overview
SCION has been designed to address the fundamental issues of today's
Internet depicted in Why SCION - Motivation (Section 1.1). The
following section gives a high-level overview of SCION's main
elements, providing a basic understanding of this next-generation
inter-network architecture.
1.2.1. Network Architecture and Naming
SCION's main goal is to offer highly available and efficient inter-
domain packet delivery—even in the presence of actively malicious
entities. To achieve scalability and sovereignty, SCION organizes
existing ASes into groups of independent routing planes, called
*Isolation Domains (ISD)*. An AS can be a member of multiple ISDs.
All ASes in an ISD agree on a set of trust roots, called the *Trust
Root Configuration (TRC)*. The ISD is governed by a set of *core
ASes*, which provide connectivity to other ISDs and manage the trust
roots. Typically, a few distinguished ASes within an ISD form the
ISD’s core.
Isolation domains serve the following purposes:
* They allow SCION to support trust heterogeneity, as each ISD can
independently define its roots of trust;
* They provide transparency for trust relationships;
* They isolate the routing process within an ISD from external
influences such as attacks and misconfigurations; and
* They improve the scalability of the routing protocol by separating
it into a process within and one between ISDs.
ISDs provide natural isolation of routing failures and
misconfigurations, provide meaningful and enforceable trust, enable
endpoints to optionally restrict traffic forwarding to trusted parts
of the Internet infrastructure only, and enable scalable routing
updates with high path-freshness.
de Kater, et al. Expires 8 May 2024 [Page 7]
Internet-Draft SCION I-D November 2023
1.2.1.1. Links
Within and between ISDs, SCION supports three types of links: (1)
core links, (2) parent-child links, and (3) peering links.
* A *core link* always connects two core ASes, which are either
within the same or in a different ISD. Core links can exist for
various underlying business relationships, including provider-
customer (where the customer pays the provider for traffic) and
peering relationships.
* A *parent-child link* creates a hierarchy between the parent and
the child. ASes with a parent-child link typically have a
provider-customer relationship.
* *Peering links* exist between ASes with a (settlement-free or
paid) peering relationship. Peering links can only be used to
reach destinations within or downstream of the peering AS. They
can be established between any two core or non-core ASes, and
between core and non-core ASes. Peering links can also cross ISD
boundaries.
See Figure 1 for a high-level overview of the SCION network
structure.
de Kater, et al. Expires 8 May 2024 [Page 8]
Internet-Draft SCION I-D November 2023
+-------------------------------------+
| |
| +-[TRC]---------------------------+ | +----------------------------+
| | ISD Core | | | +-[TRC]------------------+ |
| | | | | | ISD Core | |
| | .---. .---. .---. | | | | .---. .---. | |
| |(CAS A)*----*(CAS B)*---*(CAS C)*--------*CAS I)*----*(CAS J) | |
| | `-#-' `-#-' `-#-' | | | | `-#-' `-#-' | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| +---|------------|-----------|----+ | | +---|------------+-------+ |
| | | | | | | | |
| .-0-. | .-0-. | | .-0-. .-0-. |
| (AS D ) | +---# AS E) | | (AS K )< - ->( AS L) |
| `-#-' | | `-#-' | | `-#-' `---' |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | ISD 2 |
| | | | | | | | |
| | | | | | | | |
| .-0-. .-0-0--+ .-0-. | | .-0-. |
| (AS F )< - ->( AS G) (AS H )< -|- - >(AS M ) |
| `---' `---' `---' | | `---' |
| | +----------------------------+
| |
| ISD 1 |
| |
+-------------------------------------+
parent-child link #-------0 CAS: core AS
core link *-------* TRC: trust root configuration
peering link < - - - >
Figure 1: SCION network structure
1.2.2. Routing
SCION provides path-aware inter-domain routing between ASes across
the Internet. The SCION control plane is responsible for discovering
these inter-domain paths and making them available to the endpoints
within the ASes. SCION inter-domain routing operates on two levels:
Within a SCION isolation domain (ISD), which is called _intra_-ISD
routing, and between ISDs, called _inter_-ISD routing. Both levels
use the so-called _path-segment construction beacons (PCBs)_ to
explore network paths. A PCB is initiated by a core AS and then
disseminated either within an ISD to explore intra-ISD paths, or
among core ASes, to explore core paths across different ISDs.
de Kater, et al. Expires 8 May 2024 [Page 9]
Internet-Draft SCION I-D November 2023
The PCBs accumulate cryptographically protected path and forwarding
information on AS-level, and store this information in the form of
_hop fields_. Endpoints use information from these hop fields to
create end-to-end forwarding paths for data packets, who carry this
information in their packet headers. This concept is called _packet-
carried forwarding state_. The concept also supports multi-path
communication among endpoints.
The creation of an end-to-end forwarding path consists of the
following processes:
* _Path exploration (or beaconing)_: This is the process where an AS
discovers paths to other ASes.
* _Path registration_: This is the process where an AS selects a few
PCBs, according to defined policies, turns the selected PCBs into
path segments, and adds these path segments to the relevant path
infrastructure, thus making them available to other ASes.
* _Path resolution_: This is the process of actually creating an
end-to-end forwarding path from the source endpoint to the
destination. For this, an endpoint performs (a) a path lookup
step, to obtain path segments, and (b) a path combination step, to
combine the forwarding path from the segments. This last step
takes place in the data plane.
All processes operate concurrently.
For detailed information on path exploration, registration, and
lookup, see [I-D.dekater-scion-controlplane]. For a detailed
description of the path combination and construction process, see
[I-D.dekater-scion-dataplane].
Figure 2 below shows the SCION routing processes and their relation
to each other.
de Kater, et al. Expires 8 May 2024 [Page 10]
Internet-Draft SCION I-D November 2023
+-------------------------+ +-------------------------+
| Exploration (Beaconing) |------>| Registration |
+-------------------------+ +-----------+-------------+
|
+---------------+
|
+------------------------v------------------------+
| Path Resolution |
| |
| +----------------+ +----------------+ |
| | Lookup +------>| Combination | |
| | | | (Data Plane)| |
| +----------------+ +----------------+ |
+-------------------------------------------------+
Figure 2: SCION routing processes and their relation to each
other. All processes operate concurrently.
1.2.2.1. Path Segments
As described previously, the main goal of SCION's control plane is to
create and manage path segments, which can then be combined into
forwarding paths to transmit packets in the data plane. SCION
distinguishes the following types of path segments:
* A path segment from a non-core AS to a core AS is an *up-segment*.
* A path segment from a core AS to a non-core AS is a *down-
segment*.
* A path segment between core ASes is a *core-segment*.
Each path segment either ends at a core AS, or starts at a core AS,
or both.
*Note*: There are no SCION path segments that start and end at a non-
core AS. However, when combining path segments into an end-to-end
SCION path, it is possible to use peering links.
All path segments are invertible: A core-segment can be used
bidirectionally, and an up-segment can be converted into a down-
segment, or vice versa, depending on the direction of the end-to-end
path. This means that all path segments can be used to send data
traffic in both directions.
de Kater, et al. Expires 8 May 2024 [Page 11]
Internet-Draft SCION I-D November 2023
1.2.2.2. ISD and AS numbering
The inter-domain SCION routing is based on the <ISD, AS> tuple.
Although a complete SCION address is composed of the <ISD, AS,
endpoint address> 3-tuple, the endpoint address is not used for
inter-domain routing or forwarding. The endpoint address can be of
variable length, does not need to be globally unique, and can thus be
an IPv4, IPv6, or MAC address, for example - in fact, the endpoint
address is the "normal", currently used, non-SCION-specific endpoint
address.
*Note*: As a consequence of the fact that SCION relies on existing
routing protocols (e.g., IS-IS, OSPF, SR) and communication fabric
(e.g., IP, MPLS) for intra-domain forwarding, existing internal
routers do not need to be changed to support SCION.
1.2.2.3. Control Service
The *control service* is responsible for the path exploration and
registration processes in the control plane. It is the main control-
plane infrastructure component within each SCION AS. The control
service of an AS has the following tasks:
* Generating, receiving, and propagating PCBs. Periodically, the
control service of a core AS generates a set of PCBs, which are
forwarded to the child ASes or neighboring core ASes. In the
latter case, the PCBs are sent over policy-compliant paths to
discover multiple paths between any pair of core ASes.
* Selecting and registering the set of path segments via which the
AS wants to be reached.
* Managing certificates and keys to secure inter-AS communication.
Each PCB contains signatures of all on-path ASes. Every time the
control service of an AS receives a PCB, it validates the PCB's
authenticity. When the control service lacks an intermediate
certificate, it can query the control service of the neighboring
AS that sent the PCB.
*Note:* The control service of an AS must not be confused with a
border router. The control service of a specific AS is part of the
control plane and responsible for _finding and registering suitable
paths_. It can be deployed anywhere inside the AS. A border router
belongs to the data plane; its main task is to _forward data
packets_. Border routers are deployed at the edge of an AS.
de Kater, et al. Expires 8 May 2024 [Page 12]
Internet-Draft SCION I-D November 2023
1.2.3. Link Failures
Unlike in the current Internet, link failures are not automatically
resolved by the network, but require active handling by endpoints.
Since SCION forwarding paths are static, they break when one of the
links fails. Link failures are handled by a two-pronged approach
that typically masks link failures without any outage to the
application and rapidly re-establishes fresh working paths:
* The SCION Control Message Protocol (SCMP) (the SCION equivalent of
ICMP) is used for signaling connectivity problems. Instead of
relying on application- or transport-layer timeouts, endpoints get
immediate feedback from the network if a path stops working, and
can quickly switch to an alternative path.
* SCION endpoints are encouraged to use multipath communication by
default, thus masking a link failure with another working path.
As multipath communication can increase availability (even in
environments with very limited path choices), the SCION control
services attempt to create, select and announce disjoint paths,
and endpoints compose path segments to achieve maximum resilience
to path failure. Consequently, most link failures in SCION remain
unnoticed by the application, unlike the frequent (albeit mostly
brief) outages in the current Internet. See also [ANDERSEN2001],
[KATZ2012], [KUSHMAN2007], and [HITZ2021].
1.2.4. Formal Verification
An additional feature of SCION is its formal verification. The SCION
network system consists of a variety of components such as routers,
servers, and edge devices. Such a complex system eludes the mental
capacities of human beings for considering all possible states and
interactions. That is why SCION includes a formal verification
framework developed by the Department of Computer Science of the ETH
Zurich [KLENZE2021]. This guarantees that packet forwarding as well
as SCION's authentication mechanisms and implementations are correct
and consistent.
1.3. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
de Kater, et al. Expires 8 May 2024 [Page 13]
Internet-Draft SCION I-D November 2023
2. Key Concepts
This section explains the SCION key concepts, including
authentication, control- and data plane.
2.1. The Control-Plane PKI
SCION's control plane relies on a public-key infrastructure called
the *control-plane PKI (CP-PKI)*, which is organized on ISD-level.
Each ISD can independently build its own roots of trust, defined in a
file called *trust root configuration (TRC)*.
*Note*: This document describes the SCION control-plane PKI on a very
high level. For a detailed specification of the SCION control-plane
PKI, see [I-D.dekater-scion-pki].
2.1.1. Control-Plane PKI - Overview
Authentication in SCION is based on digital certificates that bind
identifiers to public keys and carry digital signatures that are
verified by roots of trust. SCION allows each ISD to define its own
set of trust roots, along with the policy governing their use. Such
scoping of trust roots within an ISD improves security, as compromise
of a private key associated with a trust root cannot be used to forge
a certificate outside the ISD. An ISD's trust roots and policy are
encoded in the TRC, which has a version number, a list of public keys
that serves as root of trust for various purposes, and policies
governing the number of signatures required for performing different
types of actions. The TRC serves as a way to bootstrap all
authentication within SCION. Additionally, TRC versioning is used to
efficiently revoke compromised roots of trust.
Each TRC consists of a collection of signed root certificates, which
are used to sign CA certificates, which are in turn used to sign AS
certificates. The TRC also includes ISD-policies that specify, for
example, the TRC's usage, validity, and future updates. A TRC is a
fundamental component of an ISD's control-plane PKI. The so-called
*base TRC* constitutes the ISD's trust anchor and is thus
axiomatically trusted. It is signed during a signing ceremony by so-
called voting ASes and then distributed throughout the ISD. All ASes
within an ISD must be pre-loaded with the currently valid base TRC of
their own ISD.
de Kater, et al. Expires 8 May 2024 [Page 14]
Internet-Draft SCION I-D November 2023
2.1.2. Overview of Certificates, Keys, and Roles
All certificates used in SCION's control-plane PKI are in X.509 v3
format [RFC5280]. Additionally, the TRC contains self-signed
certificates instead of plain public keys. Self-signed certificates
have the following advantages over plain public keys: (1) They make
the binding between name and public key explicit; and (2) the binding
is signed to prove possession of the corresponding private key.
All ASes in SCION have the task to sign and verify control-plane
messages. However, certain ASes have additional roles:
* *Core ASes*: Core ASes are a distinct set of ASes in the SCION
control plane. For each ISD, the core ASes are listed in the TRC.
Each core AS in an ISD has links to other core ASes (in the same
or in different ISDs).
* *Certification authorities (CAs)*: CAs are responsible for issuing
AS certificates to other ASes and/or themselves.
* *Voting ASes*: Only certain ASes within an ISD may sign TRC
updates. The process of appending a signature to a new TRC is
called "casting a vote"; the designated ASes that hold the private
keys to sign a TRC update are "voting ASes".
* *Authoritative ASes*: Authoritative ASes are those ASes in an ISD
that always have the latest TRCs of the ISD. They start the
announcement of a TRC update.
2.1.3. TRC Updates
There are two types of TRC updates: regular and sensitive. A
_regular_ TRC update is a periodic re-issuance of the TRC where the
entities and policies listed in the TRC remain unchanged, whereas a
_sensitive_ TRC update is an update that modifies critical aspects of
the TRC, such as the set of core ASes. In both cases, the base TRC
remains unchanged. If the ISD's TRC has been compromised, it is
necessary for an ISD to re-establish the trust root. This is
possible with a process called trust reset (if allowed by the ISD's
trust policy). In this case, a new base TRC is created. For more
details on a trust reset, see Section 2.1.4.
Figure 3 shows the TRC trust chain and associated certificates. TRC
1 is the base TRC, and TRC 2 and 3 constitute updates to this base
TRC. TRC 2 must be verified using the voting certificates in TRC 1.
Control-plane (CP) root certificates are used to verify other CP
certificates (which are in turn used to verify path-segment
construction beacons PCBs).
de Kater, et al. Expires 8 May 2024 [Page 15]
Internet-Draft SCION I-D November 2023
TRC 2
+--------------------------------------+
|+------------------------------------+|
||- Version - Core ASes ||
+--------+ ||- ID - Description || +--------+
| TRC 1 | ||- Validity - No Trust Reset || | TRC 3 |
| (Base |---->||- Grace Period - Voting Quorum ||--->| |
| TRC) | ||- ... || | |
+--------+ |+------------------------------------+| +--------+
|+----------------+ +----------------+|
|| Regular Voting | |Sensitive Voting||
|| Certificate | | Certificate ||
|+----------------+ +----------------+|
|+----------------+ +----------------+|
|| Votes | | Signatures ||
|+----------------+ +----------------+|
|+------------------------------------+|
|| CP Root Certificates ||
|+----------+-------------+-----------+|
| | | |
+-----------+-------------+------------+
| |
| |
v v
+-----------+ +-----------+
| CP CA | | CP CA |
|Certificate| |Certificate|
+-+-------+-+ +-----+-----+
| | |
| | |
v v v
+-----------+ +-----------+ +-----------+
| CP AS | | CP AS | | CP AS |
|Certificate| |Certificate| |Certificate|
+-----------+ +-----------+ +-----------+
Figure 3: Chain of trust within an ISD
2.1.3.1. Discovering TRC Updates
SCION provides the following mechanisms for discovering TRC updates:
* _Beaconing Process_: The TRC version is announced in the beaconing
process. Each AS must announce what it considers to be the latest
TRC. Furthermore, each AS must include the hash value of the TRC
contents to facilitate the discovery of discrepancies. Therefore,
relying parties that are part of the beaconing process discover
TRC updates passively: A core AS notices TRC updates for remote
de Kater, et al. Expires 8 May 2024 [Page 16]
Internet-Draft SCION I-D November 2023
ISDs that are on the beaconing path. A non-core AS only notices
TRC updates for the local ISD through the beaconing process, if it
receives a PCB with a TRC version number higher than the locally
stored TRC. The creation of a new TRC should trigger the
generation of new control-plane messages, as the propagation of
control-plane messages will help other ASes rapidly discover the
new TRC. This simple dissemination mechanism has two advantages:
(1) It is very efficient (as fresh PCBs rapidly reach all ASes),
and (2) it avoids circular dependencies with regard to the
verification of PCBs and the beaconing process itself (as no
server needs to be contacted over unknown paths in order to fetch
the updated TRC).
* _Path Lookup_: In every path segment, all ASes must reference the
latest TRC of their ISD. Therefore, when resolving paths, every
relying party will notice TRC updates, even remote ones. Note
that this mechanism only works when there is an active
communication between the relying party and the ISD in question.
2.1.4. Revocation and Recovery from a Catastrophic Event
The TRC dissemination mechanism also enables rapid revocation of
trust roots. When a trust root is compromised, the other trust roots
can remove it from the TRC and disseminate a new TRC alongside a PCB
with a new version number.
In case of a catastrophic event—such as several private root keys
being disclosed due to a critical vulnerability in a cryptographic
library—SCION is equipped with a recovery procedure called *trust
reset*. This procedure consists of creating a new TRC with fresh,
trustworthy keys (and potentially new algorithms), and redistributing
this TRC out-of-band. A trust reset effectively establishes a new
base TRC for the ISD. It is possible for ISDs to disable trust
resets by setting the _no trust reset_ Boolean parameter to "true" in
their TRC, with the effect that the entire ISD would have to be
abandoned in the event of such a catastrophic compromise (this
abandonment would also have to be announced out-of-band).
The partition of the SCION network into ISDs guarantees that no
single entity can take down the entire network. Even if several
entities formed a coalition to carry out an attack, the effects of
that attack would be limited to one or a few ISDs.
2.2. SCION Control Plane
The SCION control plane is responsible for discovering path segments
and making them available to endpoints.
de Kater, et al. Expires 8 May 2024 [Page 17]
Internet-Draft SCION I-D November 2023
*Note*: This section describes the SCION control plane on a very high
level. For a detailed specification of the SCION control plane, see
[I-D.dekater-scion-controlplane].
2.2.1. Path Exploration
Path exploration is the process where an AS discovers paths to other
ASes. In SCION, this process is referred to as *beaconing*. This
section gives a high level explanation of the SCION beaconing
process.
In SCION, the _control service_ of each AS is responsible for the
beaconing process. The control service generates, receives, and
propagates so-called *path-segment construction beacons (PCBs)* on a
regular basis, to iteratively construct path segments. PCBs contain
topology and authentication information, and can also include
additional metadata that helps with path management and selection.
The beaconing process itself is divided into routing processes on two
levels, where _inter_-ISD or core beaconing is based on the
(selective) sending of PCBs without a defined direction, and _intra_-
ISD beaconing on top-to-bottom propagation.
* _Inter-ISD or core beaconing_ is the process of constructing path
segments between core ASes in the same or in different ISDs.
During core beaconing, the control service of a core AS either
initiates PCBs or propagates PCBs received from neighboring core
ASes to other neighboring core ASes. Core beaconing is periodic;
PCBs are sent over policy-compliant paths to discover multiple
paths between any pair of core ASes.
* _Intra-ISD beaconing_ creates path segments from core ASes to non-
core ASes. For this, the control service of a core AS creates
PCBs and sends them to the non-core child ASes (typically customer
ASes). The control service of a non-core child AS receives these
PCBs and forwards them to its child ASes, and so on. This
procedure continues until the PCB reaches an AS without any
customer (leaf AS). As a result, all ASes within an ISD receive
path segments to reach the core ASes of their ISD.
On its way, a PCB accumulates cryptographically protected path- and
forwarding information per traversed AS. At every AS, metadata as
well as information about the AS's ingress and egress interfaces
(i.e., link identifiers) are added to the PCB. The ingress and
egress interface IDs identify connections to neighboring ASes. These
IDs only need to be unique within each AS. Therefore, they can be
chosen and encoded by each AS independently and without any need for
coordination.
de Kater, et al. Expires 8 May 2024 [Page 18]
Internet-Draft SCION I-D November 2023
SCION also supports shortcuts and peering links. In a _shortcut_, a
path only contains an up-path and a down-path segment, which can
cross over at a non-core AS that is common to both paths. _Peering
links_ can be added to up- or down-path segments, resulting in an
operation similar to today’s Internet.
Note that PCBs do not traverse peering links. Instead, peering links
are announced along with a regular path in a PCB. If both ASes at
either end of a peering link have registered path segments that
include this specific peering link, then it is possible to use this
peering link during segment combination to create the end-to-end
path.
2.2.1.1. Selection of PCBs to Propagate
As an AS receives a series of intra-ISD or core PCBs, it must select
the PCBs it will use to continue beaconing. Each AS can
independently set policies dictating which PCBs are propagated in
which time intervals, and to which neighbors. The selection process
can be based on path properties (e.g., length, disjointness across
different paths) as well as on PCB properties (e.g., age, remaining
lifetime of sent instances) - each AS is free to use those properties
that suit the AS best. The control service can then compute the
overall quality of each candidate PCB based on these properties. For
this, the AS should use a selection algorithm or metric that reflects
its needs and requirements and identifies the best PCBs or paths
segments for this AS.
For a detailed description of selecting PCBs to propagate, see the
section "Selection of PCBs to Propagate" in
[I-D.dekater-scion-controlplane].
2.2.1.2. Propagating a PCB
Every propagation period (as configured by the AS), the control
service
* selects the best combinations of PCBs and interfaces connecting to
a neighboring AS (i.e., a child AS or a core AS), and
* sends each selected PCB to the selected egress interface(s)
associated with it.
de Kater, et al. Expires 8 May 2024 [Page 19]
Internet-Draft SCION I-D November 2023
For every selected PCB and egress interface combination, the AS
extends the PCB by adding a so-called _AS entry_ to the selected PCB.
Such an AS entry includes a hop field that specifies the incoming
(ingress) and outgoing (egress) interface for the packet forwarding
through this AS, in the beaconing direction. The AS entry can also
contain peer entries.
For a detailed description of the propagation of a PCB, see the
sections "PCB Propagation - Illustrated Example" and "Propagation of
Selected PCBs" in [I-D.dekater-scion-controlplane].
2.2.2. Path Registration
Path registration is the process where an AS transforms selected PCBs
into path segments, and adds these segments to the relevant path
databases, thus making them available to other ASes.
As mentioned previously, a non-core AS typically receives several
PCBs representing several path segments to the core ASes of the ISD
the AS belongs to. Out of these PCBs, the non-core AS selects those
down-path segments through which it wants to be reached, based on AS-
specific selection criteria. The next step is to register the
selected down-segments with the control service of the relevant core
ASes, according to a process called _intra-ISD path-segment
registration_. As a result, a core AS's control service contains all
intra-ISD path segments registered by the non-core ASes of its ISD.
In addition, each core AS control service also stores preferred core-
path segments to other core ASes, in the _core-segment registration_
process.
For a detailed description of path-segment registration, see the
section "Registration of Path Segments" in
[I-D.dekater-scion-controlplane].
2.2.2.1. Intra-ISD Path-Segment Registration
Every _registration period_ (determined by each AS), the AS's control
service selects two sets of PCBs to transform into two types of path
segments:
* Up-segments, which allow the infrastructure entities and endpoints
in this AS to communicate with core ASes; and
* down-segments, which allow remote entities to reach this AS.
de Kater, et al. Expires 8 May 2024 [Page 20]
Internet-Draft SCION I-D November 2023
The up- and down-segments do not have to be equal. An AS may want to
communicate with core ASes via one or more up-segments that differ
from the down-segment(s) through which it wants to be reached.
Therefore, an AS can define different selection policies for the up-
and down-segment sets.
2.2.2.2. Core Path-Segment Registration
The core beaconing process creates path segments from core AS to core
AS. These core-segments are then added to the control service path
database of the core AS that created the segment, so that local and
remote endpoints can obtain and use these core-segments. In contrast
to the intra-ISD registration procedure, there is no need to register
core-segments with other core ASes (as each core AS will receive PCBs
originated from every other core AS).
2.2.3. Path Lookup
The _path lookup_ is a fundamental building block of SCION's path
management, as it enables endpoints to obtain path segments found
during path exploration and registered during path registration.
This allows the endpoints to construct end-to-end paths from the set
of possible path segments returned by the path lookup process. The
lookup of paths still happens in the control plane, whereas the
construction of the actual end-to-end paths happens in the data
plane.
2.2.3.1. Lookup Process
An endpoint (source) that wants to start communication with another
endpoint (destination), requires up to three path segments:
* An up-path segment to reach the core of the source ISD (only if
the source endpoint is a non-core AS),
* a core-path segment to reach
- another core AS in the source ISD, in case the destination AS
is in the same source ISD, or
- a core AS in a remote ISD, if the destination AS is in another
ISD, and
* a down-path segment to reach the destination AS.
de Kater, et al. Expires 8 May 2024 [Page 21]
Internet-Draft SCION I-D November 2023
*Note*: The actual number of required path segments depends on the
location of the destination AS as well as on the availability of
shortcuts and peering links. More information on combining and
constructing paths is provided by the [I-D.dekater-scion-dataplane]
document.
The process to look up and fetch path segments consists of the
following steps:
1. First, the source endpoint queries the control service in its own
AS (i.e., the source AS) for the required segments. The control
service has up-path segments stored in its path database.
Additionally, the control service checks if it has appropriate
core- and down-path segments in store as well; in this case it
returns them immediately.
2. If there are no appropriate core-segments and down-segments, the
control service in the source AS queries the control services of
the reachable core ASes in the source ISD, for core-path segments
to core ASes in the destination ISD (which is either the own or a
remote ISD). To reach the core control services, the control
service of the source AS uses the locally stored up-path
segments.
3. Next, the control service of the source AS combines up-path
segments with the newly retrieved core-path segments. The
control service then queries the control services of the remote
core ASes in the destination ISD, to fetch down-path segments to
the destination AS. To reach the remote core ASes, the control
service of the source AS uses the previously obtained and
combined up- and core segments.
4. Finally, the control service of the source AS returns all
retrieved path segments to the source endpoint.
5. Once it has obtained all path segments, the endpoint combines
them into an end-to-end path in the data plane.
2.2.3.2. Caching
For the sake of efficiency, the control service of the source AS
should cache each returned path segment request. Caching ensures
that path lookups are fast for frequently used destinations. The use
of caching is also essential to ensure that the path-lookup process
is scalable and can be performed with low latency. Additionally, it
is good practice to send requests in parallel when requesting path
segments from other control services.
de Kater, et al. Expires 8 May 2024 [Page 22]
Internet-Draft SCION I-D November 2023
2.3. SCION Data Plane
While the control plane is responsible for providing end-to-end
paths, the data plane ensures that packets are forwarded on the
selected path. The SCION data plane fundamentally differs from
today's IP-based data plane in that it is _path-aware_: In SCION,
inter-domain forwarding directives are embedded in the packet header.
SCION routers are deployed at the edge of an AS, and peer with
neighbor SCION routers. Inter-domain forwarding is based on end-to-
end path information contained in the packet header. This path
information consists of a sequence of hop fields. Each hop field
corresponds to an AS on the path, and it includes an ingress- as well
as an egress interface ID, which univocally identify the ingress and
egress interfaces within the AS. The information is authenticated
with a Message Authentication Code (MAC) to prevent forgery. This
concept allows SCION routers to forward packets to a neighbor AS
without inspecting the destination address and also without
consulting an inter-domain forwarding table; the SCION router can
just access the next hop from the packet header.
_Intra_-domain forwarding and routing are based on existing
mechanisms (e.g., IP). A SCION border router reuses existing intra-
domain infrastructure to communicate to other SCION routers or SCION
endpoints within its AS. The last SCION router at the destination AS
therefore uses the destination address to forward the packet to the
appropriate local endpoint.
The SCION design choice has the following advantages:
* It provides control and transparency over forwarding paths to
endpoints.
* It simplifies the packet-processing at routers: Instead of having
to perform longest-prefix matching on IP addresses, which requires
expensive hardware and substantial amounts of energy, a router can
simply access the next hop from the packet header, after having
verified the authenticity of the hop field's MAC.
*Note*: This section describes the SCION data plane on a very high
level. A much more detailed description of SCION's data plane is
available in [I-D.dekater-scion-dataplane].
de Kater, et al. Expires 8 May 2024 [Page 23]
Internet-Draft SCION I-D November 2023
2.3.1. Path Construction via Segment Combination
Paths are discovered by the SCION control plane, which makes them
available to SCION endpoints in the form of path segments. There are
three kinds of path segments: up, down, and core. In the data plane,
a SCION endpoint creates end-to-end paths from the path segments, by
combining multiple path segments. Depending on the network topology,
a SCION forwarding path can consist of one, two, or three segments.
Each path segment contains several hop fields representing the ASes
on the segment as well as one info field with basic information about
the segment, such as a timestamp.
Figure 4 below shows the different allowed segment combinations.
*Note*: It is assumed that the source and destination endpoints are
in different ASes.
------- = end-to-end path
C = Core AS - - - - = unused links
* = source/destination AS ------> = direction of beaconing
Core Core Core
----------> ----------> ---------->
.-. .-. .-. .-. .-. .-.
+-- ( C )-----( C ) --+ +-- ( C )-----(C/*) (C/*)-----(C/*)
| `+' `+' | | `+' `-' `-' `-'
| | 1a | | | | 1b 1c
| | | | | |
| | | | | |
| .+. .+. | | .+. Core
| ( ) ( ) | | ( ) -------------->
| `+' `+' | | `+' .-.
| | | | | | +----( C )----+
| | | | | | | `-' |
| | | | | | | |
| .+. .+. | | .+. .+. 1d .+.
+-> ( * ) ( * ) <-+ +-> ( * ) (C/*) (C/*)
`-' `-' `-' `-' `-'
.-. .-. .-.
+-- +--( C )--+ --+ +-- (C/*) +-- - ( C ) - --+
| | `-' | | | `+' | | `-' | |
| | | | | | | |
| | 2a | | | 2b | | | 3a | |
| | | | | | | |
de Kater, et al. Expires 8 May 2024 [Page 24]
Internet-Draft SCION I-D November 2023
| .+. .+. | | .+. | .+. .+. |
| ( ) ( ) | | ( ) | ( #-----# ) |
| `+' `+' | | `+' | `+' Peer `+' |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| .+. .+. | | .+. | .+. .+. |
+-> ( * ) ( * ) <-+ +-> ( * ) +-> ( * ) ( * ) <-+
`-' `-' `-' `-' `-'
Core Core
----------> ---------->
.-. .-. .-. .-. .-. .-.
+--( C )- - -( C )--+ +---- ( C ) ----+ ( C )- - -( C ) +-- ( C )
| `+' `+' | | `+' | `+' `+' | `+'
| 3b | | 4a | 4b | 5
| | | | | | | | | | |
| | | | |
| .+. .+. | | .+. | + - --. - + | .+.
| ( #-----# ) | | +-( )-+ | +--( )--+ | ( * )
| `+' Peer `+' | | | `-' | | | `-' | | `+'
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| .+. .+. | | .+. .+. | .+. .+. | .+.
+->( * ) ( * )<-+ +>( * ) ( * )<+ ( * ) ( * ) +-> ( * )
`-' `-' `-' `-' `-' `-' `-'
Figure 4: Illustration of possible path-segment combinations.
Each node represents a SCION Autonomous System.
The following path-segment combinations are allowed:
* _Communication through core ASes_:
- _Core-segment combination_ (Cases 1a, 1b, 1c, 1d in Figure 4):
The up- and down-segments of source and destination do not have
an AS in common. In this case, a core-segment is required to
connect the source's up- and the destination's down-segment
(Case 1a). If either the source or the destination AS is a core
AS (Case 1b) or both are core ASes (Cases 1c and 1d), then no
up- or down-segment(s) are required to connect the respective
AS(es) to the core-segment.
de Kater, et al. Expires 8 May 2024 [Page 25]
Internet-Draft SCION I-D November 2023
- _Immediate combination_ (Cases 2a, 2b in Figure 4): The last AS
on the up-segment (which is necessarily a core AS) is the same
as the first AS on the down-segment. In this case, a simple
combination of up- and down-segments creates a valid forwarding
path. In Case 2b, only one segment is required.
* _Peering shortcut_ (Cases 3a and 3b): A peering link exists
between the up- and down-segment. The extraneous path segments to
the core are cut off. Note that the up- and down-segments do not
need to originate from the same core AS and the peering link could
also be traversing to a different ISD.
* _AS shortcut_ (Cases 4a and 4b): The up- and down-segments
intersect at a non-core AS below the ISD core, thus creating a
shortcut. In this case, a shorter path is made possible by
removing the extraneous part of the path to the core. Note that
the up- and down-segments do not need to originate from the same
core AS and can even be in different ISDs (if the AS at the
intersection is part of multiple ISDs).
* _On-path_ (Case 5): In the case where the source's up-segment
contains the destination AS or the destination's down-segment
contains the source AS, a single segment is sufficient to
construct a forwarding path. Again, no core AS is on the final
path.
Once a forwarding path is chosen, it is encoded in the SCION packet
header, making inter-domain routing tables unnecessary for the SCION
routers. The destination can respond to the source by reversing the
end-to-end path from the packet header, or it can perform its own
path lookup and combination.
2.3.2. SCION Header Specification
As mentioned above, when a source endpoint wants to communicate with
a destination endpoint in SCION, it encodes the end-to-end path made
up out of path segments in the SCION packet header. This section
introduces the SCION header structure and specification. A much more
detailed description of the SCION header is provided in the section
"SCION Header Specification" of the SCION Data Plane draft
[I-D.dekater-scion-dataplane].
2.3.2.1. SCION Packet Header
The SCION packet header is composed of a common header, an address
header, a path header, and an optional extension header:
de Kater, et al. Expires 8 May 2024 [Page 26]
Internet-Draft SCION I-D November 2023
+--------------------------------------------------------+
| Common header |
| |
+--------------------------------------------------------+
| Address header |
| |
+--------------------------------------------------------+
| Path header |
| |
+--------------------------------------------------------+
| Extension header (optional) |
| |
+--------------------------------------------------------+
Figure 5: High-level SCION header structure
* The *common header* contains important meta information like a
version number and the lengths of the header and payload. In
particular, it contains flags that control the format of
subsequent headers such as the address and path headers.
* The *address header* contains the ISD-, AS-, and endpoint-
addresses of source and destination.
* The *path header* contains the full AS-level forwarding path of
the packet. The PathType field in the common header specifies the
path format used in the path header.
* Finally, the optional *extension header* contains a variable
number of hop-by-hop and end-to-end options, similar to the
extensions in the IPv6 header [RFC8200].
This document continues with a high-level description of the SCION
path header. For a detailed description of the SCION path header,
and of the other SCION headers (common-, address-, and extension
header), see the SCION Data Plane draft
[I-D.dekater-scion-dataplane].
2.3.2.2. Path Header
The SCION path type is the standard SCION path type. The path header
for the SCION path type consists of a path meta header, up to 3 info
fields and up to 64 hop fields. It has the following layout:
de Kater, et al. Expires 8 May 2024 [Page 27]
Internet-Draft SCION I-D November 2023
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathMetaHdr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InfoField |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InfoField |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HopField |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HopField |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Layout of a standard SCION path header
* The Path Meta Header (PathMetaHdr) indicates the currently valid
info field and hop field while the packet is traversing the
network along the path, as well as the number of hop fields per
path segment.
* The number of info fields (InfoField) equals the number of path
segments that the path contains - there is one info field per path
segment. Each info field contains basic information about the
corresponding segment, such as a timestamp indicating the creation
time. There are also two flags. One specifies whether the path
segment must be traversed in construction (beaconing) direction,
the other whether the first or last hop field in the path segment
represents a peering hop field.
* Each hop field (HopField) represents a hop through an AS on the
path, with the ingress and egress interface identifiers for this
AS. This information is authenticated with a Message
Authentication Code (MAC) to prevent forgery.
de Kater, et al. Expires 8 May 2024 [Page 28]
Internet-Draft SCION I-D November 2023
The SCION path header is created by extracting the required info
fields and hop fields from the corresponding path segments, which
were looked up by the source endpoint in the control plane.
A detailed description of the path header and its creation is
provided in the section "Path Header" of the SCION Data Plane draft
[I-D.dekater-scion-dataplane].
2.3.3. Path Authorization
It is crucial for the data plane that endpoints only use paths
constructed and authorized by ASes in the control plane. In
particular, endpoints should not be able to craft hop fields
themselves, modify hop fields in authorized path segments, or combine
hop fields of different path segments (path splicing). The property
that prevents this is called *path authorization* (see [KLENZE2021]
and [LEGNER2020]).
SCION uses cryptographic mechanisms to efficiently provide path
authorization. The mechanisms are based on _symmetric_ cryptography
in the form of message-authentication codes (MACs) in the data plane
to secure forwarding information encoded in hop fields. Each AS
calculates these MACs using a local secret key (that is only shared
between SCION infrastructure elements within the AS) and chains them
to the previous hop fields on the path. The MACs are then included
in the forwarding path as part of the respective hop fields.
Detailed information on path authorization in the SCION data plane is
provided in the section "Path Authorization" of the SCION Data Plane
draft [I-D.dekater-scion-dataplane].
2.3.4. Intra-AS Communication
As SCION is an _inter_-domain network architecture, it is not
concerned with _intra_-domain forwarding. This corresponds to the
general practice today where BGP and IP are used for inter-domain
routing and forwarding, respectively, but ASes use an intra-domain
protocol of their choice, for example OSPF or IS-IS for routing and
IP, MPLS, and various layer-2 protocols for forwarding.
SCION emphasizes this separation, as SCION is used exclusively for
inter-domain forwarding, and re-uses the intra-domain network fabric
to provide connectivity among all SCION infrastructure services,
border routers, and endpoints. As a consequence, minimal change to
the infrastructure is required for ISPs when deploying SCION.
de Kater, et al. Expires 8 May 2024 [Page 29]
Internet-Draft SCION I-D November 2023
Although a complete SCION address is composed of the <ISD, AS,
endpoint address> 3-tuple, the endpoint address is not used for
inter-domain routing or forwarding. This implies that the endpoint
addresses are not required to be globally unique or globally
routable, they can be selected independently by the corresponding
ASes. This means, for example, that an endpoint identified by a
link-local IPv6 address in the source AS can directly communicate
with an endpoint identified by a globally routable IPv4 address via
SCION. Alternatively, it is possible for two SCION hosts with the
same IPv4 address 10.0.0.42 but located in different ASes to
communicate with each other via SCION ([RFC1918]).
3. Deployment
Adoption of a next-generation architecture is a challenging task, as
it needs to be integrated with, and operate alongside existing
infrastructure. SCION is designed to coexist with existing intra-
domain routing infrastructure, and comprises coexistence and
transition mechanisms that facilitate adoption, in accordance to
principles defined in [RFC8170]. The following section discusses
practical considerations for deploying SCION and briefly touches on
some of the transition mechanisms, with focus on:
* Autonomous Systems (Section 3.1),
* Internet Exchange Points (Section 3.2), and
* endpoints (Section 3.3), covering both native SCION hosts and
SCION to IP encapsulation.
We then describe some of the early adopters deployment experiences.
A more detailed adoption plan is to be outlined in dedicated
documents.
3.1. Autonomous System Deployment
A SCION AS needs to deploy the SCION infrastructure components
(Section 1.2.2.3) and border routers. Within an AS, SCION is often
deployed as an IP overlay on top of the existing network. This way
SCION allows to reuse the existing intra-domain network and equipment
(e.g., IP, MPLS). Customer-side SCION border routers directly
connect to the provider-side border routers using last-mile
connections. The SCION design assumes that AS’s internal entities
are considered to be trustworthy, therefore the IP overlay or the
first-hop routing does not compromise or degrade any security
properties SCION delivers. When it comes to inter-domain
communication, an overlay deployment on top of today’s Internet is
not desirable, as SCION would inherit issues from its weak underlay.
de Kater, et al. Expires 8 May 2024 [Page 30]
Internet-Draft SCION I-D November 2023
Thus, inter-AS SCION links are usually deployed in parallel to
existing links, in order to preserve its security properties. That
is, two SCION border routers from neighbour ASes are directly
connected via a layer-2 cross-connection at a common point-of-
presence.
All SCION AS components can be deployed on standard x86 commercial
off-the-shelf servers or virtual machines. In fact, SCION border
routers do not rely on forwarding tables, therefore they do not
require specialized hardware. Practice shows that off-the-shelf
hardware can handle up to 100 Gbps links, while a prototype P4
implementation [DERUITER2021] showed that it is possible to forward
SCION traffic even at terabit speeds.
Overall, an AS can be connected to SCION without high-impact changes
to its network. In addition, use of commodity hardware for both
control and data-plane components reduces initial deployment costs.
3.2. Internet Exchange Points
Internet Exchange Points (IXP) play as important a role for SCION as
they do in today's Internet. SCION can be deployed at existing IXPs
following a "big switch" model, where the IXP provides a large L2
switch between multiple SCION ASes. SCION has been deployed
following this model at the Swiss Internet Exchange (SwissIX),
currently interconnecting major SCION Swiss ISPs and enterprises
through bi-lateral peering over dedicated SCION ports.
Additionally, thanks to its path-awareness, SCION offers the option
of an enhanced deployment model, i.e., to expose the internal
topology of an IXP within the SCION control plane. This enables IXP
customers to use SCION’s multipath and fast failover capabilities to
leverage the IXP’s internal links (including backup links) and to
select paths depending on the application’s needs. IXPs have
therefore an incentive to expose their rich internal connectivity, as
the benefits from SCION’s multipath capabilities would increase their
value for customers and provide them with a competitive advantage.
3.3. Endpoints and Incremental Deployability
End users can leverage SCION in two different ways: (1) using SCION-
aware applications on a SCION native endpoint (Section 3.3.1), or (2)
using transparent IP-to-SCION conversion (Section 3.3.2). The
benefit of using SCION natively is that the full range of advantages
becomes available to applications, at the cost of installing the
SCION endpoint stack and making the application SCION-aware. In
early deployments, the second approach is often preferred, so that no
changes are needed within applications or endpoints.
de Kater, et al. Expires 8 May 2024 [Page 31]
Internet-Draft SCION I-D November 2023
3.3.1. Native Endpoints
A SCION native endpoint's stack consists of a dispatcher, which
handles all incoming and outgoing SCION packets, and of a SCION
daemon, which handles control-plane messages. The latter fetches
paths to remote ASes and provides an API for applications and
libraries to interact with the SCION control plane (i.e., for path
lookup, SCION extensions). The current SCION implementation uses an
UDP/IP underlay for communication between endpoints and SCION
routers. This allows reuse of existing intra-domain networking
infrastructure. SCION endpoints can optionally use automated
bootstrapping mechanisms to retrieve configuration from the network
and establish SCION connectivity. This way, clients require no pre-
existing network-specific configurations.
3.3.2. SCION to IP Gateway (SIG)
A SCION-IP-Gateway (SIG) encapsulates regular IP packets into SCION
packets with a corresponding SIG at the destination that performs the
decapsulation. A SIG can be deployed close to the end user (i.e., at
branches of an enterprise, on a CPE), or within an ISP's network. In
the latter case, the SIG is called carrier-grade SIG, as it serves
multiple customers within the AS where it is deployed. This approach
has the advantage that it does not require any changes at the
customer's premises. In order to allow incremental deployability and
to ease transition from legacy IP-based Internet to SCION, SIGs can
be augmented with mechanisms allowing them to coordinate and
automatically exchange IP prefix information. A more detailed
description of the SIG and its coordination mechanisms is to be
presented in dedicated documents.
3.4. Deployment Experiences
SCION has been deployed in production by multiple entities, growing
its acceptance among industry. While early deployments started on
academic and research networks, SCION has expanded to serve the
financial industry, government, and it is being evaluated for the
healthcare sector.
In 2017, SCION was evaluated for production use by a central bank,
with the goal of modernising the network interconnecting banks and
their branches. SCION was chosen, as it allows moving away from a
dedicated private network to a reliable Internet-based solution.
SCION connectivity was later extended to support system-critical
applications, like the national real-time gross settlement (RTGS)
system, connecting all country's banks to exchange real-time payment
information. The network, called Secure Swiss Finance Network or
SSFN (https://perma.cc/PU5L-ALPM), is implemented as a SCION ISD,
de Kater, et al. Expires 8 May 2024 [Page 32]
Internet-Draft SCION I-D November 2023
where a federation of three ISPs forms the ISD core. Financial
institutions are themselves SCION ASes and directly connect to one or
more of the core ASes. Institutions deploy SCION–IP gateways (SIGs),
transparently enabling their traditional IP-based applications to use
the SCION network. The concept of the SCION ISD also provides a
mechanism to implement strict governance and access control (through
the issuance of AS certificates).
Besides the SSFN, SCION connectivity has also been adopted by
government entities for their international communications. In
addition, Swiss higher education institutions are connected thanks to
the SCI-ED (http://scied.scion-architecture.net/) network.
In addition to productive deployments, SCION also comprises a global
SCION research testbed called SCIONLab (https://www.scionlab.org).
It is composed of dozens of globally distributed infrastructure ASes,
mostly run by academic institutions. The testbed is open to any user
who can easily set up their own AS with the aid of a web-based UI,
connect to the network, and run experiments. The setup has been the
earliest global deployment of SCION and it has been supporting
research and development of path-aware networking and SCION.
4. IANA Considerations
Currently, this document has no request for action to IANA. However,
when full specification of SCION is available, requests for IANA
actions are expected regarding the registration of optional packet
header fields as well as the coordination of SCION ISD and AS number
assignments.
5. Security Considerations
SCION has been designed from the outset to offer security by default,
and thus there are manifold security considerations. As a matter of
fact, SCION's protocol design has been formally verified and the open
source router implementation is undergoing formal verification (see
also [KLENZE2021]). Describing all security considerations here,
therefore, would go beyond the scope of this document. A separate
document including all security implications and considerations will
follow later.
6. References
6.1. Normative References
de Kater, et al. Expires 8 May 2024 [Page 33]
Internet-Draft SCION I-D November 2023
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
6.2. Informative References
[ANDERSEN2001]
Andersen, D., Balakrishnan, H., Kaashoek, F., and R.
Morris, "Resilient overlay networks", ACM, Proceedings of
the eighteenth ACM symposium on Operating
systems principles, DOI 10.1145/502034.502048, October
2001, <https://doi.org/10.1145/502034.502048>.
[CHUAT22] Chuat, L., Legner, M., Basin, D., Hausheer, D., Hitz, S.,
Mueller, P., and A. Perrig, "The Complete Guide to SCION",
ISBN 978-3-031-05287-3, 2022,
<https://doi.org/10.1007/978-3-031-05288-0>.
[COOPER2013]
Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S.
Goldberg, "On the risk of misbehaving RPKI authorities",
ACM, Proceedings of the Twelfth ACM Workshop on Hot Topics
in Networks, DOI 10.1145/2535771.2535787, November 2013,
<https://doi.org/10.1145/2535771.2535787>.
[DERUITER2021]
de Ruiter, J. and C. Schutijser, "Next-generation internet
at terabit speed: SCION in P4", ACM, Proceedings of the
17th International Conference on emerging Networking
EXperiments and Technologies, DOI 10.1145/3485983.3494839,
December 2021, <https://doi.org/10.1145/3485983.3494839>.
de Kater, et al. Expires 8 May 2024 [Page 34]
Internet-Draft SCION I-D November 2023
[GRIFFIN1999]
Griffin, T. and G. Wilfong, "An analysis of BGP
convergence properties", Association for Computing
Machinery (ACM), ACM SIGCOMM Computer Communication
Review vol. 29, no. 4, pp. 277-288,
DOI 10.1145/316194.316231, August 1999,
<https://doi.org/10.1145/316194.316231>.
[HITZ2021] Hitz, S., "Demonstrating the reliability and resilience of
Secure Swiss Finance Network", 2021,
<https://perma.cc/4H3Q-WZNG>.
[I-D.dekater-scion-controlplane]
de Kater, C., Frei, M., and N. Rustignoli, "SCION Control
Plane", 2023, <https://datatracker.ietf.org/doc/draft-
dekater-scion-controlplane/>.
[I-D.dekater-scion-dataplane]
de Kater, C. and N. Rustignoli, "SCION Data Plane", 2023,
<https://datatracker.ietf.org/doc/draft-dekater-scion-
dataplane/>.
[I-D.dekater-scion-pki]
de Kater, C. and N. Rustignoli, "SCION Control-Plane PKI",
2023, <https://datatracker.ietf.org/doc/draft-dekater-
scion-pki/>.
[I-D.rustignoli-scion-components]
de Kater, C. and N. Rustignoli, "SCION Components
Analysis", 2023, <https://datatracker.ietf.org/doc/draft-
rustignoli-panrg-scion-components/>.
[KATZ2012] Katz-Bassett, E., Scott, C., Choffnes, D., Cunha, Í.,
Valancius, V., Feamster, N., Madhyastha, H., Anderson, T.,
and A. Krishnamurthy, "LIFEGUARD: practical repair of
persistent route failures", Association for Computing
Machinery (ACM), ACM SIGCOMM Computer Communication
Review vol. 42, no. 4, pp. 395-406,
DOI 10.1145/2377677.2377756, August 2012,
<https://doi.org/10.1145/2377677.2377756>.
[KING2022] King, D., Farrel, A., and C. Jacquenet, "Challenges for
the Internet Routing Systems Introduced by Semantic
Routing", 2022, <https://datatracker.ietf.org/doc/draft-
king-irtf-challenges-in-routing/>.
de Kater, et al. Expires 8 May 2024 [Page 35]
Internet-Draft SCION I-D November 2023
[KLENZE2021]
Klenze, T., Sprenger, C., and D. Basin, "Formal
Verification of Secure Forwarding Protocols", IEEE, 2021
IEEE 34th Computer Security Foundations Symposium (CSF),
DOI 10.1109/csf51468.2021.00018, June 2021,
<https://doi.org/10.1109/csf51468.2021.00018>.
[KUSHMAN2007]
Kushman, N., Kandula, S., and D. Katabi, "Can you hear me
now?!: it must be BGP", Association for Computing
Machinery (ACM), ACM SIGCOMM Computer Communication
Review vol. 37, no. 2, pp. 75-84,
DOI 10.1145/1232919.1232927, March 2007,
<https://doi.org/10.1145/1232919.1232927>.
[LABOVITZ2000]
Labovitz, C., Ahuja, A., Bose, A., and F. Jahanian,
"Delayed Internet routing convergence", ACM, Proceedings
of the conference on Applications, Technologies,
Architectures, and Protocols for Computer Communication,
DOI 10.1145/347059.347428, August 2000,
<https://doi.org/10.1145/347059.347428>.
[LEGNER2020]
Legner, M., Klenze, T., Wyss, M., Sprenger, C., and A.
Perrig, "EPIC: Every Packet Is Checked in the Data Plane
of a Path-Aware Internet", 2020,
<https://www.usenix.org/conference/usenixsecurity20/
presentation/legner>.
[LI2014] Li, Q., Hu, Y., and X. Zhang, "Even Rockets Cannot Make
Pigs Fly Sustainably: Can BGP be Secured with BGPsec?",
Internet Society, Proceedings 2014 Workshop on Security of
Emerging Networking Technologies,
DOI 10.14722/sent.2014.23001, 2014,
<https://doi.org/10.14722/sent.2014.23001>.
[LYCHEV2013]
Lychev, R., Goldberg, S., and M. Schapira, "BGP security
in partial deployment: is the juice worth the squeeze?",
Association for Computing Machinery (ACM), ACM SIGCOMM
Computer Communication Review vol. 43, no. 4, pp. 171-182,
DOI 10.1145/2534169.2486010, August 2013,
<https://doi.org/10.1145/2534169.2486010>.
[MORILLO2021]
Morillo, R., Furuness, J., Morris, C., Breslin, J.,
Herzberg, A., and B. Wang, "ROV++: Improved Deployable
de Kater, et al. Expires 8 May 2024 [Page 36]
Internet-Draft SCION I-D November 2023
Defense against BGP Hijacking", Internet Society,
Proceedings 2021 Network and Distributed System
Security Symposium, DOI 10.14722/ndss.2021.24438, 2021,
<https://doi.org/10.14722/ndss.2021.24438>.
[PERRIG2017]
Perrig, A., Szalachowski, P., Reischuk, R., and L. Chuat,
"SCION: A Secure Internet Architecture",
ISBN 978-3-319-67079-9, 2017,
<https://doi.org/10.1007/978-3-319-67080-5>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
DOI 10.17487/RFC4264, November 2005,
<https://www.rfc-editor.org/rfc/rfc4264>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/rfc/rfc5218>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/rfc/rfc8170>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/rfc/rfc8205>.
de Kater, et al. Expires 8 May 2024 [Page 37]
Internet-Draft SCION I-D November 2023
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/rfc/rfc9049>.
[RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
<https://www.rfc-editor.org/rfc/rfc9217>.
[ROTHENBERGER2017]
Rothenberger, B., Asoni, D., Barrera, D., and A. Perrig,
"Internet Kill Switches Demystified", ACM, Proceedings of
the 10th European Workshop on Systems Security,
DOI 10.1145/3065913.3065922, April 2017,
<https://doi.org/10.1145/3065913.3065922>.
[SAHOO2009]
Sahoo, A., Kant, K., and P. Mohapatra, "BGP convergence
delay after multiple simultaneous router failures:
Characterization and solutions", Elsevier BV, Computer
Communications vol. 32, no. 7-10, pp. 1207-1218,
DOI 10.1016/j.comcom.2009.03.009, May 2009,
<https://doi.org/10.1016/j.comcom.2009.03.009>.
[SCHUCHARD2011]
Schuchard, M., Mohaisen, A., Foo Kune, D., Hopper, N.,
Kim, Y., and E. Vasserman, "Losing control of the
internet: using the data plane to attack the control
plane", ACM, Proceedings of the 17th ACM conference on
Computer and communications security,
DOI 10.1145/1866307.1866411, October 2010,
<https://doi.org/10.1145/1866307.1866411>.
Acknowledgments
Many thanks go to Cyrill Krähenbühl and Juan A. Garcia-Pardo for
reviewing this document. We are also indebted to Laurent Chuat,
Markus Legner, David Basin, David Hausheer, Samuel Hitz, and Peter
Müller, for writing the book "The Complete Guide to SCION" (see
[CHUAT22]), which provides the background information needed to write
this informational draft.
Authors' Addresses
de Kater, et al. Expires 8 May 2024 [Page 38]
Internet-Draft SCION I-D November 2023
Corine de Kater
SCION Association
Email: cdk@scion.org
Nicola Rustignoli
SCION Association
Email: nic@scion.org
Adrian Perrig
ETH Zuerich
Email: adrian.perrig@inf.ethz.ch
de Kater, et al. Expires 8 May 2024 [Page 39]
