Skip to main content

SCION Overview

Document Type Active Internet-Draft (individual)
Authors Corine de Kater , Nicola Rustignoli , Adrian Perrig
Last updated 2023-11-05
RFC stream (None)
Intended RFC status (None)
Additional resources Related Implementations
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
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


   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

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   panrg-scion-overview.html.  Status information for this document may
   be found at

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 (, which is archived at  Subscribe at

   Source for this draft and an issue tracker can be found at

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

   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 (
   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

   *  Provide fast failover in the case of inter-domain link or router

   *  Prevent from IP-address hijacking, DoS, and other attacks

   *  Enable path transparency as well as application-specific path

   *  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.  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.  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

   *  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  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

   See Figure 1 for a high-level overview of the SCION network

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

   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       |
   +-------------------------+       +-----------+-------------+
        |                 Path Resolution                 |
        |                                                 |
        |   +----------------+       +----------------+   |
        |   |     Lookup     +------>|  Combination   |   |
        |   |                |       |    (Data Plane)|   |
        |   +----------------+       +----------------+   |

        Figure 2: SCION routing processes and their relation to each
                other.  All processes operate concurrently.  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-

   *  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  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

   *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.  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",
   "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  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

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

   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

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.  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].  Propagating a PCB

   Every propagation period (as configured by the AS), the control

   *  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_

   For a detailed description of path-segment registration, see the
   section "Registration of Path Segments" in
   [I-D.dekater-scion-controlplane].  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

   *  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.  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.   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]

   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

   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.   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

   *  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

   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].  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].  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

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 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

3.1.  Autonomous System Deployment

   A SCION AS needs to deploy the SCION infrastructure components
   (Section 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-

   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 (, 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 ( network.

   In addition to productive deployments, SCION also comprises a global
   SCION research testbed called SCIONLab (
   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

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,

   [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,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

6.2.  Informative References

              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, <>.

   [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,

              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,

              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, <>.

de Kater, et al.           Expires 8 May 2024                  [Page 34]
Internet-Draft                  SCION I-D                  November 2023

              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,

   [HITZ2021] Hitz, S., "Demonstrating the reliability and resilience of
              Secure Swiss Finance Network", 2021,

              de Kater, C., Frei, M., and N. Rustignoli, "SCION Control
              Plane", 2023, <

              de Kater, C. and N. Rustignoli, "SCION Data Plane", 2023,

              de Kater, C. and N. Rustignoli, "SCION Control-Plane PKI",
              2023, <

              de Kater, C. and N. Rustignoli, "SCION Components
              Analysis", 2023, <

   [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,

   [KING2022] King, D., Farrel, A., and C. Jacquenet, "Challenges for
              the Internet Routing Systems Introduced by Semantic
              Routing", 2022, <

de Kater, et al.           Expires 8 May 2024                  [Page 35]
Internet-Draft                  SCION I-D                  November 2023

              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,

              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,

              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,

              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,

   [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,

              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,

              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,

              Perrig, A., Szalachowski, P., Reischuk, R., and L. Chuat,
              "SCION: A Secure Internet Architecture",
              ISBN 978-3-319-67079-9, 2017,

   [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, <>.

   [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,

   [RFC4264]  Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
              DOI 10.17487/RFC4264, November 2005,

   [RFC5218]  Thaler, D. and B. Aboba, "What Makes for a Successful
              Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <>.

   [RFC8170]  Thaler, D., Ed., "Planning for Protocol Adoption and
              Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
              May 2017, <>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205, September
              2017, <>.

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,

   [RFC9049]  Dawkins, S., Ed., "Path Aware Networking: Obstacles to
              Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
              DOI 10.17487/RFC9049, June 2021,

   [RFC9217]  Trammell, B., "Current Open Questions in Path-Aware
              Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,

              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,

              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,

              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,


   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

   Nicola Rustignoli
   SCION Association

   Adrian Perrig
   ETH Zuerich

de Kater, et al.           Expires 8 May 2024                  [Page 39]