SCION Overview

1.2.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.2.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.2.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.3.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.¶

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

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

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

+-------------------------+       +-------------------------+
| Exploration (Beaconing) |------>|      Registration       |
+-------------------------+       +-----------+-------------+
                                              |
                              +---------------+
                              |
     +------------------------v------------------------+
     |                 Path Resolution                 |
     |                                                 |
     |   +----------------+       +----------------+   |
     |   |     Lookup     +------>|  Combination   |   |
     |   |                |       |    (Data Plane)|   |
     |   +----------------+       +----------------+   |
     +-------------------------------------------------+

1.3.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.3.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.¶

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

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

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

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

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.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.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.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   |     |
|     |         |     |      |      |          |                     |
|    .+.       .+.    |      |     .+.         |    .+.       .+.    |
|   (   )     (   )   |      |    (   )        |   (   #-----#   )   |
|    `+'       `+'    |      |     `+'         |    `+'  Peer `+'    |
|     |         |     |      |      |          |     |         |     |
|     |         |     |      |      |          |     |         |     |
|     |         |     |      |      |          |     |         |     |
|    .+.       .+.    |      |     .+.         |    .+.       .+.    |
+-> ( * )     ( * ) <-+      +->  ( * )        +-> ( * )     ( * ) <-+
     `-'       `-'                 `-'              `-'       `-'


          Core                                    Core
      ---------->                              ---------->
     .-.       .-.             .-.            .-.       .-.        .-.
 +--( C )- - -( C )--+  +---- ( C ) ----+    ( C )- - -( C )  +-- ( C )
 |   `+'       `+'   |  |      `+'      |     `+'       `+'   |    `+'
 |         3b        |  |           4a  |          4b         |  5
 |    |         |    |  |       |       |      |         |    |     |
 |                   |  |               |                     |
 |   .+.       .+.   |  |      .+.      |      + - --. - +    |    .+.
 |  (   #-----#   )  |  |   +-(   )-+   |      +--(   )--+    |   ( * )
 |   `+'  Peer `+'   |  |   |  `-'  |   |      |   `-'   |    |    `+'
 |    |         |    |  |   |       |   |      |         |    |     |
 |    |         |    |  |   |       |   |      |         |    |     |
 |    |         |    |  |   |       |   |      |         |    |     |
 |   .+.       .+.   |  |  .+.     .+.  |     .+.       .+.   |    .+.
 +->( * )     ( * )<-+  +>( * )   ( * )<+    ( * )     ( * )  +-> ( * )
     `-'       `-'         `-'     `-'        `-'       `-'        `-'

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

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

+--------------------------------------------------------+
|                     Common header                      |
|                                                        |
+--------------------------------------------------------+
|                     Address header                     |
|                                                        |
+--------------------------------------------------------+
|                      Path header                       |
|                                                        |
+--------------------------------------------------------+
|              Extension header (optional)               |
|                                                        |
+--------------------------------------------------------+

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

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

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