Internet-Draft SCION DP October 2024
de Kater, et al. Expires 19 April 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-dekater-scion-dataplane-latest
Published:
Intended Status:
Informational
Expires:
Authors:
C. de Kater
SCION Association
N. Rustignoli
SCION Association
J. C. Hugly
SCION Association
S. Hitz
Anapaya Systems

SCION Data Plane

Abstract

This document describes the data plane of the path-aware, inter-domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION control plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION data plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path.

The SCION data plane fundamentally differs from today's IP-based data plane in that it is path-aware: In SCION, interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers.

About This Document

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

The latest revision of this draft can be found at https://scionassociation.github.io/scion-dp_I-D/draft-dekater-scion-dataplane.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/.

Source for this draft and an issue tracker can be found at https://github.com/scionassociation/scion-dp_I-D.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 19 April 2025.

▲

Table of Contents

1. Introduction

SCION is a path-aware internetworking routing architecture as described in [RFC9217]. It allows endpoints and applications to select paths across the network to use for traffic, based on trusted path properties. SCION is an inter-domain network architecture and is therefore not concerned with intra-domain forwarding.

The data transmission order for SCION is the same as for IPv6 as defined in Introduction of [RFC8200].

SCION has been developed with the following goals:

Availability - to provide highly available communication that can send traffic over paths with optimal or required characteristics, quickly handle inter-domain link or router failures (both on the last hop or anywhere along the path) and provide continuity in the presence of adversaries.

Security - to provide higher levels of trust in routing information in order to prevent traffic hijacking, reduce potential for denial-of-service and other attacks. Endpoints can decide the trust roots they wish to rely on, routing information can be unambiguously attributed to an AS, and packets are only forwarded along authorized path segments. A particular use case is to enable geofencing.

Scalability - to improve the scalability of the inter-domain control plane and data plane, avoiding existing limitations related to convergence and forwarding table size. The advertising of path segments is separated into a beaconing process within each Isolation Domain (ISD) and between ISDs which incurs minimal overhead and resource requirements on routers.

SCION relies on three main components:

PKI - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called Isolation Domains (ISDs). All ASes in an ISD agree on a set of trust roots called the Trust Root Configuration (TRC) which is a collection of signed root certificates in X.509 v3 format [RFC5280]. The ISD is governed by a set of core ASes which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane. See [I-D.dekater-scion-pki]

Control Plane - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See [I-D.dekater-scion-controlplane]

Data Plane - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS.

This document describes the SCION Data Plane component. It should be read in conjunction with the other components [I-D.dekater-scion-pki] and [I-D.dekater-scion-controlplane].

The SCION architecture was initially developed outside of the IETF by ETH Zurich with significant contributions from Anapaya Systems. It is deployed in the Swiss finance sector to provide resilient connectivity between financial institutions. The aim of this document is to document the existing protocol specification as deployed, and to introduce new concepts that can potentially be further improved to address particular problems with the current Internet architecture.

Note (to be removed before publication): this document, together with the other components [I-D.dekater-scion-pki] and [I-D.dekater-scion-controlplane], deprecates [I-D.dekater-panrg-scion-overview]. This document provides an extensive description of how the SCION Data Plane is implemented in order to facilitate understanding, but could potentially be split into separate documents if considered suitable for submission to the Internet Standards Process.

1.1. Terminology

Autonomous System (AS): An autonomous system is a network under a common administrative control. For example, the network of an Internet service provider or organization can constitute an AS.

Core AS: Each SCION isolation domain (ISD) is administered by a set of distinguished autonomous systems (ASes) called core ASes, which are responsible for initiating the path discovery and path construction process (in SCION called "beaconing").

Data Plane: The data plane (sometimes also referred to as the forwarding plane) is responsible for forwarding data packets that endpoints have injected into the network. After routing information has been disseminated by the control plane, packets are forwarded by the data plane in accordance with such information.

Egress/Ingress: refers to the direction of travel. In SCION, path construction with beaconing happens in one direction, while actual traffic might follow the opposite direction. This document clarifies on a case-by-case basis whether 'egress' or 'ingress' refers to the direction of travel of the SCION packet or to the direction of beaconing.

Endpoint: An endpoint is the start or the end of a SCION path. For example, an endpoint can be a host as defined in [RFC1122] or a SCION IP gateway (Section 8) bridging a SCION and an IP domain. This definition is based on the definition in [RFC9473].

Forwarding Key: A forwarding key is a symmetric key that is shared between the control service (control plane) and the routers (data plane) of an AS. It is used to authenticate Hop Fields in the end-to-end SCION path. The forwarding key is an AS-local secret and is not shared with other ASes.

Forwarding Path: A forwarding path is a complete end-to-end path between two SCION endpoints which is used to transmit packets in the data plane. It can be created with a combination of up to three path segments (an up segment, a core segment, and a down segment).

Hop Field (HF): As they traverse the network, path segment construction beacons (PCBs) accumulate cryptographically protected AS-level path information in the form of Hop Fields. In the data plane, Hop Fields are used for packet forwarding: they contain the incoming and outgoing interface IDs of the ASes on the forwarding path.

Info Field (INF): Each path segment construction beacon (PCB) contains a single Info field, which provides basic information about the PCB. Together with Hop Fields (HFs), these are used to create forwarding paths.

Interface Identifier (Interface ID): A 16-bit identifier that designates a SCION interface at the end of a link connecting two SCION ASes, with each interface belonging to one border router. Hop fields describe the traversal of an AS by a pair of interface IDs called ConsIngress and ConsEgress, as they refer to the ingress and egress interfaces in the direction of path construction (beaconing). The Interface ID MUST be unique within each AS. Interface ID 0 is not a valid identifier as implementations MAY use it as the "unspecified" value.

Isolation Domain (ISD): In SCION, Autonomous Systems (ASes) are organized into logical groups called Isolation Domains or ISDs. Each ISD consists of ASes that span an area with a uniform trust environment (e.g. a common jurisdiction). A possible model is for ISDs to be formed along national boundaries or federations of nations.

Leaf AS: An AS at the "edge" of an ISD, with no other downstream ASes.

MAC: Message Authentication Code. In the rest of this document, "MAC" always refers to "Message Authentication Code" and never to "Medium Access Control". When "Medium Access Control address" is implied, the phrase "Link Layer Address" is used.

Path Authorization: A requirement for the data plane is that endpoints can only use paths that were constructed and authorized by ASes in the control plane. This property is called path authorization. The goal of path authorization is to prevent endpoints from crafting Hop Fields (HFs) themselves, modifying HFs in authorized path segments, or combining HFs of different path segments.

Path Control: Path control is a property of a network architecture that gives endpoints the ability to select how their packets travel through the network. Path control is stronger than path transparency.

Path Segment: Path segments are derived from path segment construction beacons (PCBs). A path segment can be (1) an up segment (i.e. a path between a non-core AS and a core AS in the same ISD), (2) a down segment (i.e. the same as an up segment, but in the opposite direction), or (3) a core segment (i.e., a path between core ASes). Up to three path segments can be used to create a forwarding path.

Path-Segment Construction Beacon (PCB): Core AS control planes generate PCBs to explore paths within their isolation domain (ISD) and among different ISDs. ASes further propagate selected PCBs to their neighboring ASes. As a PCB traverses the network, it carries path segments, which can subsequently be used for traffic forwarding.

Path Transparency: Path transparency is a property of a network architecture that gives endpoints full visibility over the network paths their packets are taking. Path transparency is weaker than path control.

Peering Link: A link between two SCION border routers of different ASes that can be used as a shortcut. Peering link information is added to segment information during the beaconing process and used to shorten paths while assembling them from segments. It is possible to construct a path out of only two partial segments which top-most hops are joined by a peering link. Two peering ASes may be in different ISDs and may exist between any ASes, including core ASes.

1.2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.3. Overview

The SCION data plane forwards inter-domain packets between SCION-enabled ASes. SCION routers are normally 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 (HFs). Each Hop Field corresponds to an AS on the path, and it includes an ingress interface ID as well as an egress interface ID, which unequivocally identifies 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. 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.

This SCION design choice has the following advantages:

  • It provides control and transparency over forwarding paths to endpoints.

  • It simplifies the packet processing at routers. Instead of having to perform longest prefix matching on IP addresses which requires expensive hardware and substantial amounts of energy, a router can simply access the next hop from the packet header after having verified the authenticity of the Hop Field's MAC.

1.3.1. Inter- and Intra-Domain Forwarding

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. In fact, even if ASes use IP forwarding internally today, they typically encapsulate the original IP packet they receive at the edge of their network into another IP packet with the destination address set to the egress border router, to avoid full inter-domain forwarding tables at internal routers.

SCION emphasizes this separation as it is used exclusively for inter-domain forwarding; re-using the intra-domain network fabric to provide connectivity amongst all SCION infrastructure services, border routers, and endpoints. As a consequence, minimal change to the infrastructure is required for ISPs when deploying SCION. In practice, in most existing SCION deployments, SCION routers communicate among themselves and with endpoints by enclosing the SCION header inside an UDP/IPv6 or UDP/IPv4 packet. The choice of using an UDP/IP as an intra-domain protocol between routers was driven by the need to maximize compatibility with existing networks. This does not exclude that a SCION packet may be enclosed directly on top of a L2 protocol, since the choice of intra-domain protocol is AS specific.

Figure 1 shows the SCION header within the protocol stack, in an AS where the SCION deployment uses UDP/IP as an intra-domain protocol. A similar model may be used for inter-domain links, depending on the individual choice of the two interconnected SCION router operators. A full example of the life of a SCION packet is later presented in Section 3. A list of currently used upper layer protocols on top of SCION is presented in Appendix "Assigned SCION Protocol Numbers".

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             |
|                             |
|        Payload (L4)         |
|                             |
|                             |
|                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             |
|            SCION            |
|                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  --------------+
|             UDP             |                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Intra-domain  |
|             IP              |                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    protocol    |
|         Link Layer          |                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  --------------+
Figure 1: The SCION header within the protocol stack in a typical deployment.

A complete SCION address is composed of the <ISD, AS, endpoint address> 3-tuple. The ISD-AS part is used for inter-domain routing. The endpoint address part is only used for intra-domain forwarding at the source and destination ASes. This implies that endpoint addresses are only required to be globally unique within each SCION AS. This means, for example, that an endpoint running a SCION stack using a [RFC1918] could directly communicate with another SCION endpoint using a [RFC1918] endpoint address in a different SCION AS.

1.3.2. Intra-Domain Forwarding Process

When transiting an intermediate SCION AS, a packet gets forwarded by at most two SCION routers. The forwarding process consists of the following steps.

  1. The AS's SCION ingress router receives a SCION packet from the neighboring AS.

  2. The SCION router parses, validates, and authenticates the SCION header.

  3. The SCION router maps the egress interface ID in the current Hop Field of the SCION header to the destination address of the intra-domain protocol (e.g. MPLS or IP) of the egress border router.

  4. The packet is forwarded within the AS by SCION-unaware routers and switches based on the header of the intra-domain protocol.

  5. Upon receiving the packet, the SCION egress router strips off the header of the intra-domain protocol, again validates and updates the SCION header, and forwards the packet to the neighboring SCION router.

  6. The last SCION router on the path forwards the packet to the packet's destination endpoint indicated by the field DstHostAddr of the Address Header (Section 2.2).

1.3.3. Configuration

Border routers require mappings from SCION interface IDs to underlay addresses and such information MUST be supplied to each router in an out of band fashion (e.g in a configuration file). For each link to a neighbor, these values MUST be configured. A typical implementation will require:

  • Interface ID.

  • Link type (core, parent, child, peer). Link type depends on mutual agreements between the organizations operating the ASes at each end of each link.

  • Neighbor ISD-AS number.

  • For the router that manages the interface: the neighbor interface underlay address.

  • For the routers that do not manage the interface: the address of the intra-domain protocol on the router that does.

In order to forward traffic to a service endpoint address (DT/DS == 0b01 in the common header (Section 2.1)), a border router translates the service number into a specific destination address. The method used to accomplish the translation is not defined by this document and is only dependent on the implementation and the choices of each AS's administrator. In current practice this is accomplished by way of a configuration file.

Note: The current SCION implementation runs over the UDP/IP protocol. However, the use of other lower layers protocols is possible.

1.4. Path Construction (Segment Combinations)

Paths are discovered by the SCION control plane which makes them available to SCION endpoints in the form of path segments. As described in [I-D.dekater-scion-controlplane], 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.

Segments cannot be combined arbitrarily. To construct a valid forwarding path, the source endpoint MUST obey the following rules:

  • There MUST be at most one of each type of segment (up, core, and down). Allowing multiple up or down segments would decrease efficiency and the ability of ASes to enforce path policies.

  • If an up segment is present, it MUST be the first segment in the path.

  • If a down segment is present, it MUST be the last segment in the path.

  • If there are two path segments (one up and one down segment) that both announce the same peering link, then a shortcut via this peering link is possible.

  • If there are two path segments (one up and one down segment) that share a common ancestor AS (in the direction of beaconing), then a shortcut via this common ancestor AS is possible. The Up-then-Down constraint still applies.

  • Additionally, all segments without any peering possibility MUST consist of at least two Hop Fields.

Note that the type of segment is known to the endpoint but it is not explicitly visible in the path header of data packets. Therefore, a SCION router needs to explicitly verify that these rules were followed correctly by performing checks described in Section 4.2.2.1.

Besides enabling the enforcement of path policies, the above rules also protect the economic interest of ASes as they prevent building "valley paths". A valley path contains ASes that do not profit economically from traffic on this route, with the name coming from the fact that such paths go "down" (following parent-child links) before going "up" (following child-parent links).

Figure 2 below shows valid segment combinations.

Note: It is assumed that the source and destination endpoints are in different ASes (as endpoints from the same AS use an empty forwarding path to communicate with each other).

                                  ------- = 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 `+'   |  |   |  `-'  |   |      |   `-'   |    |    `+'
 |    |         |    |  |   |       |   |      |         |    |     |
 |    |         |    |  |   |       |   |      |         |    |     |
 |    |         |    |  |   |       |   |      |         |    |     |
 |   .+.       .+.   |  |  .+.     .+.  |     .+.       .+.   |    .+.
 +->( * )     ( * )<-+  +>( * )   ( * )<+    ( * )     ( * )  +-> ( * )
     `-'       `-'         `-'     `-'        `-'       `-'        `-'
Figure 2: Illustration of valid path segment combinations. Each node represents a SCION Autonomous System.

Valid path segment combinations:

  • Communication through core ASes:

    • Core-segment combination (Cases 1a, 1b, 1c, 1d in Figure 2): 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 segment 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 segments are REQUIRED to connect the respective ASes to the core segment.

    • Immediate combination (Cases 2a, 2b in Figure 2): 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, and 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.

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

1.5. Path Authorization

The SCION data plane provides path authorization. This property ensures that data packets always traverse the network using path segments that were explicitly authorized by the respective ASes and prevents endpoints from constructing unauthorized paths or paths containing loops. SCION uses symmetric cryptography in the form of Message Authentication Codes (MACs) to authenticate the information encoded in Hop Fields and such MACs are verified by routers at forwarding. For a detailed specification, see Section 4.

3. Life of a SCION Data Packet

This section gives a high-level description of the life cycle of a SCION packet: how it is created at its source endpoint, passes through a number of SCION routers, and finally reaches its destination endpoint. It is assumed that both source and destination are native SCION endpoints (i.e. they both run a native SCION network stack).

This example illustrates an intra-ISD case, i.e. all communication happening within a single ISD. As the sample ISD only consists of one core AS, the end-to-end path only includes an up-path and down-path segment. In the case of inter-ISD forwarding, the complete end-to-end path from source endpoint to destination endpoint would always require a core path segment as well, although this makes no difference for the forwarding process which works the same in an intra-ISD and inter-ISD context.

3.1. Description 

                    +--------------------+
                    |                    |
                    |        AS1         |
                    |                    |
                    |                    |
                    |     198.51.100.4 .-+. i1b (1-1,198.51.100.17)
                    |          +------( R3 )---+
                   .+-.        |       `-+'    |
          +-------( R2 )-------+         |     |
          |    i1a `+-' 198.51.100.1     |     |
          |         |                    |     |
          |         +--------------------+     | (1-3,198.51.100.18)
          |                                    | i3a
          |                                   .+-.
    i2a .-+.                          +------( R4 )--------+
+------( R1 )--------+                |       `-+'         |
|       `-+'         |                |         |192.0.2.34|
|         |203.0.113.17               |         |          |
|         |          |                |         |    AS3   |
|         |    AS2   |                |         |          |
|         |          |                |       +---+        |
|       +---+        |                |       | B |        |
|       | A |        |                |       +---+        |
|       +---+        |                |   1-3,192.0.2.7    |
|  1-2,203.0.113.6   |                |                    |
|                    |                +--------------------+
+--------------------+
Figure 18: Sample topology to illustrate the life cycle of a SCION packet. AS1 is the core AS of ISD 1, and AS2 and AS3 are non-core ASes of ISD 1.

Based on the network topology in Figure 18 above, this example shows the path of a SCION packet sent from its source at Endpoint A to its destination at Endpoint B, and how it will be processed by each router on the path using simplified snapshots of the packet header after each processing step. These snapshots, which are depicted in tables, show the most relevant information of the header, i.e. the SCION path and IP encapsulation for local communication.

3.2. Creating an End-to-End SCION Forwarding Path

In this example, Endpoint A in AS2 wants to send a data packet to Endpoint B in AS3. Both AS2 and AS3 are part of ISD 1. To create an end-to-end SCION forwarding path, Endpoint A first requests its own AS2 control service for up segments to the core AS in its ISD. The AS2 control service will return up segments from AS2 to the ISD core. Endpoint A will also query its AS2 control service for a down segment from its ISD core AS to AS3, in which Endpoint B is located. The AS2 control service will return down segments from the ISD core down to AS3.

Note: For more details on the lookup of path segments, see the section "Path Lookup" in the Control Plane specification ([I-D.dekater-scion-controlplane]).

Based on its own selection criteria, Endpoint A selects the up segment (0,i2a)(i1a,0) and the down segment (0,i1b)(i3a,0) from the path segments returned by its own AS2 control service. The path segments consist of Hop Fields that carry the ingress and egress interfaces of each AS (e.g., i2a, i1a, ...), as described in detail in Section 2 - (x,y) represents one Hop Field.

To obtain an end-to-end forwarding path from the source AS to the destination AS, Endpoint A combines the two path segments into the resulting SCION forwarding path, which contains the two Info Fields IF1 and IF2 and the Hop Fields (0,i2a), (i1a,0), (0,i1b), and (i3a,0).

Note: As this brief sample path does not contain a core segment, the end-to-end path only consists of two path segments.

Endpoint A now adds this end-to-end forwarding path to the header of the packet that it wants to send to Endpoint B, and starts transferring the packet.

3.3. Step-by-Step Explanation

This section explains what happens with the SCION packet header at each router, based on the network topology in described Figure 18 above. Each step includes a table that represents a simplified snapshot of the packet header at the end of this specific step. Regarding the notation used in the figure/tables, each source and destination entry should be read as router (or endpoint) followed by its address. The current Info Field (with metadata on the current path segment) in the SCION header is depicted as italic/cursive in the tables. The current Hop Field, representing the current AS, is shown bold. The snapshot tables also include references to IP/UDP addresses. In this context, words "ingress" and "egress" refer to the direction of travel of SCION data packets.

  • Step 1
    A->R1: The SCION-enabled Endpoint A in AS2 creates a new SCION packet destined for destination endpoint B in AS3, with payload P. Endpoint A sends the packet (for the chosen forwarding path) to the next SCION router as provided by its control service, which is in this case Router 1. Endpoint A encapsulates the SCION packet into an underlay UDP/IPv4 header for the local delivery to Router 1, utilizing AS2's internal routing protocol. The current Info Field is IF1. Upon receiving the packet, Router 1 will forward the packet on the egress interface that endpoint A has included into the first Hop Field of the SCION header.

Table 6: Snapshot header - step 1
A -> R1  
SCION SRC = 1-2,203.0.113.6 (source Endpoint A)
  DST = 1-3,192.0.2.7 (dest. Endpoint B)
  PATH =
  - IF1 (0,i2a) (i1a,0)
  - IF2 (0,i1b) (i3a,0)
UDP PS = 30041, PD = 30041
IP SRC = 203.0.113.6 (Endpoint A)
  DST = 203.0.113.17 (Router 1)
Link layer SRC=A, DST=R1

  • Step 2
    R1->R2: Router 1 inspects the SCION header and considers the relevant Info Field of the specified SCION path, which is the Info Field indicated by the current Info Field pointer. In this case, it is the first Info Field IF1. The current Hop Field is the first Hop Field (0,i2a), which instructs router 1 to forward the packet on its interface i2a. After reading the current Hop Field, Router 1 moves the pointer forward by one position to the second Hop Field (i1a,0).

    The link shown here is an example of not using a UDP/IP underlay. Although most implementations use such an encapsulation, SCION only requires link-layer connectivity. What is used for one given inter-AS link is a function of the available implementations at each end, the available infrastructure, and the joint preference of the two ASes administrators.

Table 7: Snapshot header - step 2
R1 -> R2  
SCION SRC = 1-2,203.0.113.6 (source Endpoint A)
  DST = 1-3,192.0.2.7 (dest. Endpoint B)
  PATH =
  - IF1 (0,i2a) (i1a,0)
  - IF2 (0,i1b) (i3a,0)
Link layer SRC=R1, DST=R2

  • Step 3
    R2->R3: When receiving the packet, Router 2 of Core AS1 checks whether the packet has been received through the ingress interface i1a as specified by the current Hop Field. Otherwise, the packet is dropped by Router 2. The router notices that it has consumed the last Hop Field of the current path segment, and hence moves the pointer from the current Info Field to the next Info Field IF2. The corresponding current Hop Field is (0,i1b), which contains egress interface i1b. Router maps the i1b interface ID to egress Router 3, it therefore encapsulates the SCION packet inside an intra-AS underlay IP packet with the address of Router 3 as the underlay destination.

Table 8: Snapshot header - step 3
R2 -> R3  
SCION SRC = 1-2,203.0.113.6 (source Endpoint A)
  DST = 1-3,192.0.2.7 (dest. Endpoint B)
  PATH =
  - IF1 (0,i2a) (i1a,0)
  - IF2 (0,i1b) (i3a,0)
UDP PS = 30041, PD = 30041
IP SRC = 198.51.100.1 (Router 2)
  DST = 198.51.100.4 (Router 3)
Link layer SRC=R2, DST=R3

  • Step 4
    R3->R4: Router 3 inspects the current Hop Field in the SCION header, uses interface i1b to forward the packet to its neighbor SCION-enabled Router 4 of AS3, and moves the current hop-field pointer forward. It adds an IP header to reach Router 4.

Table 9: Snapshot header - step 4
R3 -> R4  
SCION SRC = 1-2,203.0.113.6 (source Endpoint A)
  DST = 1-3,192.0.2.7 (dest. Endpoint B)
  PATH =
  - IF1 (0,i2a) (i1a,0)
  - IF2 (0,i1b) (i3a,0)
UDP PS = 30041, PD = 30041
IP SRC = 1-1,198.51.100.17 (Router 3)
  DST = 1-3,198.51.100.18 (Router 4)
Link layer SRC=R3, DST=R4

  • Step 5
    R4->B: SCION-enabled Router 4 first checks whether the packet has been received through the ingress interface i3a as specified by the current Hop Field. Router 4 will then also realize, based on the fields CurrHF and SegLen in the SCION header, that the packet has reached the last hop in its SCION path. Therefore, instead of stepping up the pointers to the next Info Field or Hop Field, Router 4 inspects the SCION destination address and extracts the endpoint address 192.0.2.7. It creates a fresh underlay UDP/IP header with this address as destination and with itself as source. The intra-domain forwarding can now deliver the packet to its destination at Endpoint B.

Table 10: Snapshot header - step 5
R4 -> B  
SCION SRC = 1-2,203.0.113.6 (source Endpoint A)
  DST = 1-3,192.0.2.7 (dest. Endpoint B)
  PATH =
  - IF1 (0,i2a) (i1a,0)
  - IF2 (0,i1b) (i3a,0)
UDP PS = 30041, PD = 30041
IP SRC = 192.0.2.34 (Router 4)
  DST = 192.0.2.7 (Endpoint B)
Link layer SRC=R4, DST=B

When destination Endpoint B wants to respond to source Endpoint A, it can just swap the source and destination addresses in the SCION header, reverse the SCION path, and set the pointers to the Info Fields and Hop Fields at the beginning of the reversed path (see also Section 2.3.4).

3.4. MTU

SCION requires its underlay protocol to provide a minimum MTU of 1232 bytes. This number results from 1280, the minimum IPv6 MTU as of [RFC2460]), minus 48, assuming UDP/IPv6 as underlay. Higher layer protocols such as SCMP rely only on such minimum MTU.

The MTU of a SCION path is defined as the minimum of the MTUs of the links traversed by that path. The control plane disseminates such values and makes them available to endpoints (see: [I-D.dekater-scion-controlplane], Path MTU).

The MTU of each link may be discovered or administratively configured (current practice is for it to be configured). It must be less than or equal to the MTU of the link's underlay encapsulation or native link-layer in either direction.

SCION assumes that the MTUs of a path segment remains correct for the life time of that segment. This is generally a safe assumption because:

  • Intra-AS network MTUs are a result of the network configuration of each AS and therefore predictable.

  • Inter-AS links MTU are normally under the joint control of the administrators of the two ASes involved and therefore equally predictable.

Should the inter-AS link MTU be unpredictable (e.g. because the inter-AS link is deployed as an overlay), then the link's MTU MUST be configured statically to a conservative value. For a UDP/IP underlay, 1232 is a safe value.

3.5. Packet Fragmentation

The SCION network layer does not support packet fragmentation; not even at the source endpoint. Upper layer protocols and applications MUST comply with the MTU of the paths that they use.

SCION is agnostic to datagram fragmentation by the underlay network layer, (e.g. used for intra-AS communication). Implementations SHOULD allow MTU discovery mechanisms such as [RFC4821] to be enabled in the underlay and avoid fragmentation. For inter-AS links, using a different configuration is the joint decision of the administrators of the two ASes involved. For intra-AS interfaces using a different configuration is the choice of that AS' administrator alone.

4. Path Authorization

Path authorization guarantees that data packets always traverse the network along paths segments authorized by all on-path ASes in the control plane. In contrast to the IP-based Internet where forwarding decisions are made by routers based on locally stored information, SCION routers base their forwarding decisions purely on the forwarding information carried in the packet header and set by endpoints.

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. This section first explains how Hop Field MACs are computed, then how they are validated as they traverse the network.

4.1. Authorizing Segments through Chained MACs

When authorizing SCION PCBs and path segments in the control plane and forwarding information in the data plane, an AS authenticates not only its own hop information but also an aggregation of all upstream hops. This section describes how this works.

4.1.1. Hop Field MAC Overview

The MAC in the Hop Fields of a SCION path has two purposes:

  • Preventing malicious endpoints from adding, removing or reordering hops within a path segment created during beaconing in the control plane. In particular, preventing path splicing, i.e. the combination of parts of different valid path segments into a new and unauthorized path segment.

  • Authentication of the information contained in the Hop Field itself, in particular the ExpTime, ConsIngress, and ConsEgress.

To fulfill these purposes, the MAC for the Hop Field of ASi includes both the components of the current Hop Field HFi and an aggregation of the path segment identifier and all preceding Hop Fields/entries in the path segment. The aggregation is a 16-bit XOR-sum of the path segment identifier and the Hop Field MACs.

When originating a path segment construction beacon PCB in the control plane, a core AS chooses a random 16-bit value as segment identifier SegID for the path segment and includes it in the PCB's Segment Info component. In the control plane, each ASi on the path segment computes the MAC for the current HFi, based on the value of SegID and the MACs of the preceding hop entries. Here, the full XOR-sum is computed explicitly.

For high-speed packet processing in the data plane, computing even cheap operations such as the XOR-sum over a variable number of inputs is complicated, in particular for hardware router implementations. To avoid this overhead for the MAC chaining in path authorization in the data plane, the XOR-sum is tracked incrementally for each of the path segments in a path as a separate, updatable Accumulator Field Acc. The routers update Acc by adding/subtracting only a single 16-bit value each.

When combining path segments to create a path to the destination endpoint, the source endpoint MUST also initialize the value of accumulator field Acc for each path segment. The Acc field MUST contain the correct XOR-sum of the path segment identifier and preceding Hop Field MACs expected by the first router that is traversed.

The aggregated 16-bit path segment identifier and preceding MACs prevent splicing of different path segments unless there is a collision of the Acc value among compatible path segments in an AS. See Section 7.1.3 for more details.

4.1.1.1. Hop Field MAC - Calculation

The Hop Field MAC is generally calculated at a current ASi as follows:

  • Consider a path segment with "n" hops, containing ASes AS0, ... , ASn-1, with forwarding keys K0, ... , Kn-1 in this order.

  • AS0 is the core AS that created the PCB representing the path segment and that added a random initial 16-bit segment identifier SegID to the Segment Info field of the PCB.

MACi =
Cki (SegID XOR MAC0 [:2] ... XOR MACi-1 [:2], Timestamp, ExpTimei, ConsIngressi, ConsEgressi)

where

  • ki = The forwarding key k of the current ASi

  • Cki (...) = Cryptographic checksum C over (...) computed with forwarding key ki

  • SegID = The random initial 16-bit segment identifier set by the core AS when creating the corresponding PCB

  • XOR = The bitwise "exclusive or" operation

  • MACi [:2] = The Hop Field MAC for ASi, truncated to 2 bytes

  • Timestamp = The timestamp set by the core AS when creating the corresponding PCB

  • ExpTimei, ConsIngressi, ConsEgressi = The content of the Hop Field HFi

Thus, the current MAC is based on the XOR-sum of the truncated MACs of all preceding Hop Fields in the path segment as well as the path segment's SegID. In other words, the current MAC is chained to all preceding MACs. In order to effectively prevent path-splicing, the cryptographic checksum function used MUST ensure that the truncation of the MACs is non-degenerate and roughly uniformly distributed (see Section 4.1.1.4).

4.1.1.2. Accumulator Acc - Definition

The Accumulator Acci is an updatable counter introduced in the data plane to avoid the overhead caused by MAC-chaining for path authorization. This is achieved by incrementally tracking the XOR-sum of the previous MACs as a separate, updatable accumulator field Acc, which is part of the path segment's Info Field InfoField in the packet header (see also Section 2.3.2.3). Routers update this field by adding/subtracting only a single 16-bit value each.

Section 4.1.1.1 provides a general formula to compute MACi, but at each SCION router the expression SegID XOR MAC_0 [:2] ... XOR MAC_i-1 [:2] is replaced by Acci. This results in the following alternative procedure for the computation of MACi at SCION routers:

MACi = Cki (Acci, Timestamp, ExpTimei, ConsIngressi, ConsEgressi)

During forwarding, SCION routers at each ASi update the Acc field in the packet header so that it contains the correct input value of Acc for the next AS in the path segment to be able to calculate the MAC over its Hop Field. Note that the correct input value of the Acc field depends on the direction of travel.

The value of Acci+1 is calculated based on the following definition (in the direction of beaconing):

Acci+1 = Acci XOR MACi [:2]

  • XOR = The bitwise "exclusive or" operation

  • MACi [:2] = The Hop Field MAC for the current ASi, truncated to 2 bytes

4.1.1.3. Default Hop Field MAC Algorithm

The algorithm used to compute the Hop Field MAC is an AS-specific choice. The operator of an AS can freely choose any MAC algorithm and the control service and routers of the AS do need to agree on the algorithm used, but all implementations MUST support the Default Hop Field MAC algorithm described below.

The default MAC algorithm is AES-CMAC ([RFC4493]) truncated to 48-bits, computed over the Info Field and the first 6 bytes of the Hop Field with flags and reserved fields zeroed out. The input is padded to 16 bytes. The first 6 bytes of the AES-CMAC output are used as resulting Hop Field MAC.

Figure 19 below shows the layout of the input data to calculate the Hop Field MAC.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+
|               0               |           Acc                 |  Info|
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Field|
|                           Timestamp                           |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -----+
|       0       |    ExpTime    |          ConsIngress          |   Hop|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field|
|          ConsEgress           |               0               |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+
Figure 19: Input data to calculate the Hop Field MAC for the default hop-field MAC algorithm
4.1.1.4. Alternative Hop Field MAC Algorithms

For alternative algorithms, the following requirements MUST all be met:

  • The Hop Field MAC field is computed as a function of the secret forwarding key, the Acc and Timestamp fields of the Info Field, and the ExpTime, ConsIngress and ConsEgress fields of the Hop Field. Function is used in the mathematical sense that for for any values of these inputs there is exactly one result.

  • The algorithm returns an unforgable 48-bit value. Unforgable specifically means "existentially unforgable under a chosen message attack" ([CRYPTOBOOK]). Informally, this means an attacker without access to the secret key has no computationally efficient means to create a valid MAC for some attacker chosen input values, even if it has access to an "oracle" providing a valid MAC for any other input values.

  • The truncation of the result value to the first 16 bits of the result value:

    • is not degenerate, i.e. any small change in any input value SHOULD have an "avalanche effect" on these bits, and

    • is roughly uniformly distributed when considering all possible input values.

This additional requirement is naturally satisfied for MAC algorithms based on typical block ciphers or hash algorithms. It ensures that the MAC chaining via the Acc field is not degenerate.

4.2. Path Initialization and Packet Processing

As described in Section 2, the path header of the data plane packets only contains a sequence of Info Fields and Hop Fields without any additional data from the corresponding PCBs. The SCION path also does not contain any AS numbers - except for the source and destination ASes - and there is no field explicitly defining the type of each segment (up, core, or down). This chapter describes the required steps for the source endpoint and SCION routers to respectively craft and forward a data packet.

4.2.1. Initialization at Source Endpoint

The source endpoint MUST perform the following steps to correctly initialize a path:

  1. Combine the preferred end-to-end path from the path segments obtained during path lookup.

  2. Extract the Info Fields and Hop Fields from the different path segments that together build the end-to-end path to the destination endpoint. Then insert the relevant information from the Info Fields and Hop Fields into the corresponding InfoFields and Hopfields in the data packet header.

  3. Each 8-byte Info Field InfoField in the packet header contains the updatable Acc field as well as a Peering flag P and a Construction Direction flag C (see also Section 2.3.2.3). As a next step in the path initialization process, the source MUST correctly set the flags and the Acc field of all InfoFields included in the path, according to the following rules:

    • The Construction Direction flag C MUST be set to "1" whenever the corresponding segment is traversed in construction direction, i.e., for down-path segments and potentially for core segments. It MUST be set to "0" for up-path segments and "reversed" core segments.

    • The Peering flag P MUST be set to "1" for up-segments and down-segments if the path contains a peering Hop Field.

    The following InfoField settings are possible, based on the following cases:

    • Case 1
      The path segment is traversed in construction direction and includes no peering Hop Field. It starts at the i-th AS of the full segment discovered in beaconing. In this case:

      • The Peering flag P = "0"

      • The Construction Direction flag C = "1"

      • The value of the Acc = Acci. For more details, see Section 4.1.1.2.

    • Case 2
      The path segment is traversed in construction direction and includes a peering Hop Field (which is the first Hop Field of the segment). It starts at the i-th AS of the full segment discovered in beaconing. In this case:

      • The Peering flag P = "1"

      • The Construction Direction flag C = "1"

      • The value of the Acc = Acci+1. For more details, see Section 4.1.1.2.

    • UCase 3
      The path segment is traversed against construction direction. The full segment has "n" hops. In this case:

      • The Peering flag P = "0" or "1" (depending on whether the last Hop Field in the up-segment is a peering Hop Field)

      • The Construction Direction flag C = "0"

      • The value of the Acc = Accn-1. This is because seen from the direction of beaconing, the source endpoint is the last AS in the path segment. For more details, see Section 4.1.1.1 and Section 4.1.1.2.

  4. Besides setting the flags and the Acc field, the source endpoint MUST also set the pointers in the CurrInf and CurrHF fields of the Path Meta Header PathMetaHdr (see Section 2.3.2.1). As the source endpoint builds the starting point of the forwarding, both pointers MUST be set to "0".

4.2.2. Processing at Routers

During forwarding, each SCION router verifies the path contained in the packet header. Each SCION router also MUST correctly verify or set the value of the Accumulator in the Acc field for the next AS to be able to verify its Hop Field. The exact operations differ based on the location of the AS on the path.

The processing of SCION packets for ASes where a peering link is crossed between path segments is a special case. A path containing a peering link contains exactly two path segments, one against construction direction (up) and one in construction direction (down). On the path segment against construction direction (up), the peering Hop Field is the last hop of the segment. In construction direction (down), the peering Hop Field is the first hop of the segment.

The following sections describe the tasks to be performed by the ingress and egress border routers (see ) of each on-path AS. Each operation is described from the perspective of ASi, where i belongs to [0 ... n-1], and n == the number of ASes in the path segment (counted from the first AS in the beaconing direction).

The following figure provides a simplified representation of the processing at routers both in construction direction and against construction direction.

                              .--.
                             ( RR )  = Router
Processing in                 `--'
construction
direction

      1. Verify MAC of AS1          1. Verify MAC of AS2
      2. Update Acc for AS2         2. Update Acc for AS3
                 |                            |
>>>--------------o----------------------------o---------------------->>>

+-------------+  |           +-------------+  |          +-------------+
|             |              |             |             |             |
|           .--. |          .--.         .--. |         .--.           |
|   AS1    ( RR )o---------( RR )  AS2  ( RR )o--------( RR )  AS3     |
|           `--' |          `--'         `--' |         `--'           |
|             |              |             |             |             |
+-------------+  |           +-------------+  |          +-------------+

                 |                            |
<<<--------------o----------------------------o----------------------<<<
                 |                            |
      1. Update Acc for AS1         1. Update Acc for AS2
      2. Verify MAC of AS1          2. Verify MAC of AS2

                                                      Processing against
                                                            construction
                                                               direction
Figure 20: A simplified representation of the processing at routers in both directions.
4.2.2.1. Steps at Ingress Border Router

A SCION ingress border router MUST perform the following steps when it receives a SCION packet:

  1. Check that the interface through which the packet was received is equal to the ingress interface in the current Hop Field. If not, the router MUST drop the packet.

  2. If there is a segment switch at the current router, check that the ingress and egress interface links are either:

  • Both core

  • Parent-child or vice-versa

  • Peering-child or vice-versa

Link types above are defined in [I-D.dekater-scion-controlplane] section "Paths and Links". This check prevents valley-use of peering-links or hair-pin segments. 3. Check if the current Hop Field is expired or originated in the future, i.e. the current Info Field MUST NOT have a timestamp in the future, as defined in Section 2.3.2.3. If either is true, the router MUST drop the packet.

The next steps depend on the direction of travel and whether this segment includes a peering Hop Field. Both features are indicated by the settings of the Construction Direction flag C and the Peering flag P in the current Info Field, so the settings of both flags MUST be checked. The following combinations are possible:

  • The packet traverses the path segment in construction direction (C = "1" and P = "0" or "1"). In this case, proceed with step 4.

  • The packet traverses the path segment against construction direction (C = "0"). The following cases are possible:

    • Case 1
      The path segment includes no peering Hop Field (P = "0"). In this case, the ingress border router MUST take the following step(s):

      • Compute the value of the Accumulator Acc as follows:

        Acc = Acci+1 XOR MACi
        where
        Acci+1 = the current value of the field Acc in the current Info Field
        MACi = the value of MACi in the current Hop Field representing ASi

        Note: In the case described here, the packet travels against direction of beaconing, i.e. the packet comes from ASi+1 and will enter ASi. This means that the Acc field of this incoming packet represents the value of Acci+1, but to compute the MACi for the current ASi, we need the value of Acci (see Section 4.1.1.2). As the border router knows that the formula for Acci+1 = Acci XOR MACi [:2] (see also Section 4.1.1.2), and because the values of Acci+1 and MACi are known, the router will be able to recover the value Acci based on the aforementioned formula for Acc.

      • Replace the current value of the field Acc in the current Info Field with the newly calculated value of Acc.

      • Compute the MACVerifyi over the Hop Field of the current ASi. For this, use the formula in Section 4.1.1.1, but replace SegID XOR MAC_0[:2] ... XOR MAC_i-1 [:2] in the formula with the value of Acc as just set in the Acc field in the current Info Field.

      • If the MACi in the current Hop Field does not match the just calculated MACVerifyi, drop the packet.

      • If the current Hop Field is the last Hop Field in the path segment as determined by the value of the current SegLen and other metadata in the path meta header, increment both CurrInf and CurrHF in the path meta header. Proceed with step 4.

    • Case 2
      The path segment includes a peering Hop Field (P = "1"), but the current hop is not the peering hop (i.e. the current hop is neither the last hop of the first segment nor the first hop of the second segment). In this case, the ingress border router needs to perform the steps previously described for the path segment without peering Hop Field, but the border router MUST NOT increment CurrInf and MUST NOT increment CurrHF in the path meta header. Proceed with step 4.

    • Case 3
      The path segment includes a peering Hop Field (P = "1"), and the current Hop Field is the peering Hop Field (i.e. the current hop is either the last hop of the first segment or the first hop of the second segment). In this case, the ingress border router MUST take the following step(s):

      • Compute MACPeeri. For this, use the formula in Section 4.1.2, but replace SegID XOR MAC_0[:2] ... XOR MAC_i [:2] in the formula with the value of Acc as set in the Acc field in the current Info Field (this is the value of Acc as it comes with the packet).

      • If the MACi in the current Hop Field does not match the just calculated MACPeeri, drop the packet.

      • Increment both CurrInf and CurrHF in the path meta header. Proceed with step 4.

  1. Forward the packet to the egress border router (based on the egress interface ID in the current Hop Field) or to the destination endpoint, if this is the destination AS.

4.2.2.2. Steps at Egress Border Router

A SCION egress border router MUST perform the following steps when it receives a SCION packet:

  1. Check the settings of the Construction Direction flag C and the Peering flag P in the currently valid Info Field. The following cases are possible:

    • Case 1
      The packet traverses the path segment in construction direction (C = "1"). The path segment either includes no peering Hop Field (P = "0") or the path segment does include a peering Hop Field (P = "1"), but the current hop is not the peering hop (i.e. the current hop is neither the last hop of the first segment nor the first hop of the second segment). In this case, the egress border router MUST take the following step(s):

      • Compute MACVerifyi over the Hop Field of the current ASi. For this, use the formula in Section 4.1.1.1, but replace SegID XOR MAC_0[:2] ... XOR MAC_i-1 [:2] in the formula with the value of Acc as set in the Acc field in the current Info Field.

      • If the just calculated MACVerifyi does not match the MACi in the Hop Field of the current ASi, drop the packet.

      • Compute the value of Acci+1. For this, use the formula in Section 4.1.1.2. Replace Acci in the formula with the current value of Acc as set in the Acc field of the current Info Field.

      • Replace the value of the Acc field in the current Info Field with the just calculated value of Acci+1.

    • Case 2
      The packet traverses the path segment in construction direction (C = "1") where the path segment includes a peering Hop Field (P = "1") and the current Hop Field is the peering Hop Field (i.e. the current hop is either the last hop of the first segment or the first hop of the second segment). In this case, the egress border router MUST take the following steps:

      • Compute MACPeeri. For this, use the formula in Section 4.1.2, but replace SegID XOR MAC_0 [:2] ... XOR MAC_i [:2] with the value in the Acc field of the current Info Field.

      • If the MACi in the Hop Field of the current ASi does not match the just calculated MACPeeri, drop the packet.

    • Case 3
      The packet traverses the path segment against construction direction (C = "0" and P = "0" or "1"). In this case, proceed with Step 3.

  2. Increment CurrHF in the path meta header.

  3. Forward the packet to the neighbor AS.

4.2.2.3. Effects of Clock Inaccuracy

A PCB originated by a given control service is used to construct data plane paths. Specifically, the timestamp in the Info Field and the expiry time of Hop Fields are used for Hop Field MAC computation, see Section 4.1.1.1, which is used to validate paths at each on-path SCION router. A segment's originating control service and the routers that the segment refers to all have different clocks. Their differences affect the validation process:

  • A fast clock at origination or a slow clock at validation will yield a lengthened expiration time for hops, and possibly an origination time in the future.

  • A slow clock at origination or a fast clock at validation will yield a shortened expiration time for hops, and possibly an expiration time in the past.

This bias comes in addition to a structural delay: PCBs are propagated at a configurable interval (typically, one minute). As a result of this and the way they are iteratively constructed, PCBs with N hops may become available for path construction up to N intervals (so typically N minutes) after origination which creates a constraint on the expiration of hops. Hops of the minimal expiration time (337.5 seconds - see Section 2.3.2.4) would render useless any path segment longer than 5 hops. For this reason, it is unadvisable to create hops with a short expiration time. The norm is 6 hours.

In comparison to these time scales, clock offsets in the order of minutes are immaterial.

Each administrator of SCION control services and routers is responsible for maintaining sufficient clock accuracy. No particular method is assumed for this.

5. SCMP

The SCION Control Message Protocol (SCMP) is analogous to the Internet Control Message Protocol (ICMP). It provides functionality for network diagnostics, such as traceroute, and error messages that signal packet processing or network-layer problems. SCMP is a helpful tool for network diagnostics and, in the case of External Interface Down and Internal Connectivity Down messages, a signal for endpoints to detect network failures more rapidly and fail-over to different paths. However, SCION nodes should not strictly rely on the availability of SCMP, as this protocol may not be supported by all devices and/or may be subject to rate limiting.

This document specifies only messages RECOMMENDED for the purposes of path diagnosis and recovery. An extended specification, still a work in progress, can be found in [SCMP].

5.1. General Format

Every SCMP message is preceded by a SCION header, and zero or more SCION extension headers. The SCMP header is identified by a NextHdr value of 202 in the immediately preceding header.

The messages have the following general format:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Type-dependent Block                    |
    +                                                               +
    |                         (variable length)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: SCMP message format

  • Type: it indicates the type of SCMP message. Its value determines the format of the type-dependent block.

  • Code: it provides additional granularity to the SCMP type.

  • Checksum: it is used to detect data corruption.

  • Type-dependent Block: optional field of variable length which format is dependent on the message type.

5.2. Message Types

SCMP messages are grouped into two classes: error messages and informational messages. Error messages are identified by a zero in the high-order bit of the type value. I.e., error messages have a type value in the range of 0-127. Informational messages have type values in the range of 128-255.

This specification defines the message formats for the following SCMP messages:

Table 11: error messages types
Type Meaning
1 Reserved for future use
2 Packet Too Big (Section 5.5.1)
3 Reserved for future use
4 Reserved for future use
5 External Interface Down (Section 5.5.2)
6 Internal Connectivity Down (Section 5.5.3)
   
100 Private Experimentation
101 Private Experimentation
   
127 Reserved for expansion of SCMP error messages
Table 12: informational messages types
Type Meaning
128 Echo Request (Section 5.6.1)
129 Echo Reply (Section 5.6.2)
130 Traceroute Request (Section 5.6.3)
131 Traceroute Reply (Section 5.6.4)
200 Private Experimentation
201 Private Experimentation
   
255 Reserved for expansion of SCMP informational messages

Type values 100, 101, 200, and 201 are reserved for private experimentation.

All other values are reserved for future use.

5.3. Checksum Calculation

The checksum is the 16-bit one's complement of the one's complement sum of the entire SCMP message, starting with the SCMP message type field, and prepended with a "pseudo-header" consisting of the SCION address header and the layer-4 protocol type as defined in Section 2.5.

5.4. Processing Rules

Implementations MUST respect the following rules when processing SCMP messages:

  • If an SCMP error message of unknown type is received at its destination, it MUST be passed to the upper-layer process that originated the packet that caused the error, if it can be identified.

  • If an SCMP informational message of unknown type is received, it MUST be silently dropped.

  • Every SCMP error message MUST include as much of the offending SCION packet as possible. The error message packet - including the SCION header and all extension headers - MUST NOT exceed 1232 bytes in order to fit into the minimum MTU (see Section 3.4).

  • In case the implementation is required to pass an SCMP error message to the upper-layer process, the upper-layer protocol type is extracted from the original packet in the body of the SCMP error message and used to select the appropriate process to handle the error. In case the upper-layer protocol type cannot be extracted from the SCMP error message body, the SCMP message MUST be silently dropped.

  • An SCMP error message MUST NOT be originated in response to any of the following:

    • An SCMP error message.

    • A packet which source address does not uniquely identify a single node. E.g., an IPv4 or IPv6 multicast address.

The maximum size 1232 bytes is chosen so that the entire datagram, if encapsulated in UDP and IPv6, does not exceed 1280 bytes (L2 Header excluded). 1280 bytes is the minimum MTU required by IPv6 and it is assumed that, nowadays, this MTU can also be safely expected when using IPv4.

5.5. Error Messages

5.5.1. Packet Too Big 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            reserved           |             MTU               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                As much of the offending packet                |
    +              as possible without the SCMP packet              +
    |                    exceeding 1232 bytes.                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Packet-too-big format
Table 13: field values
Name Value
Type 2
Code 0
MTU The Maximum Transmission Unit of the next-hop link.

A Packet Too Big message SHOULD be originated by a router in response to a packet that cannot be forwarded because the packet is larger than the MTU of the outgoing link. The MTU value is set to the maximum size a SCION packet can have to still fit on the next-hop link, as the sender has no knowledge of the underlay.

5.5.2. External Interface Down 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ISD              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         AS                    +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                        Interface ID                           +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                As much of the offending packet                |
    +              as possible without the SCMP packet              +
    |                    exceeding 1232 bytes.                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: External-interface-down format
Table 14: field values
Name Value
Type 5
Code 0
ISD The 16-bit ISD identifier of the SCMP originator
AS The 48-bit AS identifier of the SCMP originator
Interface ID The interface ID of the external link with connectivity issue.

A External Interface Down message SHOULD be originated by a router in response to a packet that cannot be forwarded because the link to an external AS is broken. The ISD and AS identifier are set to the ISD-AS of the originating router. The interface ID identifies the link of the originating AS that is down.

Recipients can use this information to route around broken data-plane links.

5.5.3. Internal Connectivity Down 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ISD              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         AS                    +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                   Ingress Interface ID                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                   Egress Interface ID                         +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                As much of the offending packet                |
    +              as possible without the SCMP packet              +
    |                    exceeding 1232 bytes.                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Internal-connectivity-down format
Table 15: field values
Name Value
Type 6
Code 0
ISD The 16-bit ISD identifier of the SCMP originator
AS The 48-bit AS identifier of the SCMP originator
Ingress ID The interface ID of the ingress link.
Egress ID The interface ID of the egress link.

A Internal Connectivity Down message SHOULD be originated by a router in response to a packet that cannot be forwarded inside the AS because because the connectivity between the ingress and egress routers is broken. The ISD and AS identifier are set to the ISD-AS of the originating router. The ingress interface ID identifies the interface on which the packet enters the AS. The egress interface ID identifies the interface on which the packet is destined to leave the AS, but the connection is broken to.

Recipients can use this information to route around broken data-plane inside an AS.

5.6. Informational Messages

5.6.1. Echo Request 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Data (variable Len)                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Echo-request format
Table 16: field values
Name Value
Type 128
Code 0
Identifier A 16-bit identifier to aid matching replies with requests
Sequence Nr. A 16-bit sequence number to aid matching replies with requests
Data Variable length of arbitrary data

Every node SHOULD implement a SCMP Echo responder function that receives Echo Requests and originates corresponding Echo replies.

5.6.2. Echo Reply 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Data (variable Len)                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Echo-reply format
Table 17
Name Value
Type 129
Code 0
Identifier The identifier of the Echo Request
Sequence Nr. The sequence number of the Echo Request
Data The data of the Echo Request

Every node SHOULD implement a SCMP Echo responder function that receives Echo Requests and originates corresponding Echo replies.

The data received in the SCMP Echo Request message MUST be returned entirely and unmodified in the SCMP Echo Reply message.

5.6.3. Traceroute Request 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ISD              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         AS                    +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                          Interface ID                         +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Traceroute-request format

Given a SCION path constituted of hop fields, traceroute allows to identify the corresponding on-path ISD-ASes.

Table 18: field values
Name Value
Type 130
Code 0
Identifier A 16-bit identifier to aid matching replies with requests
Sequence Nr. A 16-bit sequence number to aid matching replies with request
ISD Place holder set to zero by SCMP sender
AS Place holder set to zero by SCMP sender
Interface ID Place holder set to zero by SCMP sender

A border router is alerted of a Traceroute Request message through the Ingress or Egress Router Alert flag set to 1 in the hop field that describes the traversal of that router in a packet's path (See Section 2.3.2.4). When such a packet is received, the border router SHOULD reply with a Traceroute Reply message (Section 5.6.4).

5.6.4. Traceroute Reply 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              ISD              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         AS                    +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                          Interface ID                         +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Traceroute-reply format
Table 19: field values
Name Value
Type 131
Code 0
Identifier The identifier set in the Traceroute Request
Sequence Nr. The sequence number of the Tracroute Request
ISD The 16-bit ISD identifier of the SCMP originator
AS The 48-bit AS identifier of the SCMP originator
Interface ID The interface ID of the SCMP originating router

The identifier is set to the identifier value from the Traceroute Request message (Section 5.6.3). The ISD and AS identifiers are set to the ISD-AS of the originating border router.

5.7. SCMP Authentication

Authentication of SCMP packets is not specified here. In current deployments it is still experimental. Endpoints should therefore validate link down messages (External Interface Down (Section 5.5.2) and Internal Connectivity Down (Section 5.5.3)) with additional signals for reliable operations.

7. Security Considerations

This section describes the possible security risks and attacks that SCION's data plane may be prone to, and how these attacks may be mitigated. It first discusses security risks that pertain to path authorization, followed by a section on other forwarding related security considerations.

7.1. Path Authorization

A central property of the SCION path-aware data plane is path authorization. Path authorization guarantees that data packets always traverse the network along path segments authorized in the control plane by all on-path ASes. This section discusses how an adversary may attempt to violate the path-authorization property, as well as SCION's prevention mechanisms; either an attacker can attempt to create unauthorized Hop Fields, or they can attempt to create illegitimate paths assembled from authentic individual Hop Fields.

The main protection mechanism is the Hop Field MAC (see Section 4.1) that authenticates the Hop Field content comprised of ingress/egress interface identifiers, creation and expiration timestamp and the preceding Hop Field MACs in the path segment. Each Hop Field MAC is computed using the secret forwarding key of the respective AS, which is shared across the SCION routers and control plane services within each AS.

7.1.1. Forwarding key compromise

For the current default MAC algorithm - AES-CMAC truncated to 48 bits - key recovery attacks from (any number of) known plaintext/MAC combinations is computationally infeasible as far as publicly known. In addition, the MAC algorithm can be freely chosen by each AS, enabling algorithmic agility for MAC computations. Should a MAC algorithm be discovered to be weak or insecure, each AS can quickly switch to a secure algorithm without the need for coordination with other ASes.

A more realistic risk to the secrecy of the forwarding key is exfiltration from a compromised router or control plane service. An AS can optionally rotate its forwarding key at regular intervals to limit the exposure after a temporary device compromise. However, such a key rotation scheme cannot mitigate the impact of an undiscovered compromise of a device.

When an AS's forwarding key is compromised, an attacker can forge Hop Field MACs and undermine path authorization. As path segments are checked for validity and policy compliance during the path discovery phase and during forwarding, routers only validate the MAC and basic validity of the current the Hop Field. Consequently, creating fraudulent Hop Fields with valid MACs allows an attacker to bypass most path segment validity checks and to create path segments that violate the AS's local policy and/or general path segment validity requirements. In particular, an attacker could create paths that include loops (limited by the maximum number of Hop Fields of a path).

Unless an attacker has access to the forwarding keys of all ASes on the illegitimate path it wants to fabricate, it will need to splice fragments of two legitimate path segments with an illegitimate Hop Field. For this, it needs to create a Hop Field with a MAC that fits into the MAC chain expected by the second path segment fragment. The only input that the attacker can vary relatively freely is the 8-bit ExpTime, but the resulting MAC needs to match a specific 16 bit Acc value. While there is a low probability of this working for a specific attempt (1/256), the attack will succeed eventually if the attacker can keep retrying over a longer time period or with many different path segment fragments.

While a forwarding key compromise and the resulting loss of path authorization is a serious degradation of SCION's routing security properties, this does not affect access control or data security for the hosts in the affected AS. Unauthorized paths are available to the attacker, but the routing of packets from legitimate senders is not affected.

7.1.2. Forging Hop Field MAC

Another method to break path authorization is to directly forge a Hop Field in an online attack, using the router as an oracle to determine the validity of the Hop Field MAC. The adversary needs to send one packet per guess for verification and for 6-byte MAC, an adversary would need an expected 247 (~140 trillion) tries to successfully forge the MAC of a single Hop Field.

As the router only checks MACs during the encoded validity period of the Hop Field, which is limited by the packet header format to at most 24 hours, these tries need to occur in a limited time period. This results in a seemingly infeasible number of ~1.6e9 guesses per second.

In the unlikely case that an online brute-force attack succeeds, the obtained Hop Field can be used until its inevitable expiration after the just mentioned 24 hour limit.

7.1.3. Path Splicing

In a path splicing attack, an adversary source endpoint takes valid Hop Fields of multiple path segments and splices them together to obtain a new unauthorized path.

Candidate path segments for splicing must have at least one AS interface in common as a connection point, and the same origination timestamp as this is directly protected by the Hop Field MAC. This can occur by chance or if the two candidate path segments were originated as the same segment that diverged and converged back.

The Hop Field MAC protects the 16-bit aggregation of path segment identifier and preceding MACs, see Section 4.1. This MAC chaining prevents splicing even in the case that the AS interface and segment timestamp match.

As the segment identifier and aggregation of preceding MACs is only 16-bits wide, a chance collision among compatible path segments can occur rarely. Successful path splicing would allow an attacker to briefly use a path that violates an ASes path policy, e.g. making a special transit link available to a customer AS that is not billed accordingly, or violate general path segment validity requirements. In particular, a spliced path segment could traverse one or multiple links twice. However, creating a loop traversing a link an arbitrary number of times would involve multiple path splices and therefore multiple random collisions happening simultaneously, which is exceedingly unlikely. A wider security margin against path splicing could be obtained by increasing the width of the segment identifier / Acc field, e.g. by extending it into the 8-bit reserved field next to it in the Info Field.

7.2. On-Path Attacks

When an adversary sits on the path between the source and destination endpoint, it is able to intercept the data packets that are being forwarded and would allow the adversary to hijack traffic onto a path that is different from the intended one selected by the source endpoint. Possible on-path attacks in the data plane are modifications of the SCION path header and SCION address header, or by simply dropping packets. This kind of attack generally cannot be prevented, although anendpoint can use SCION's path awareness to immediately select an alternate path if available.

7.2.1. Modification of the Path Header

An on-path adversary could modify the SCION path header and replace the remaining part of path segments to the destination with different segments. Such replaced segments must include authorized segments as otherwise the packet would be simply dropped on its way to the destination.

The already traversed portion of the current segment and past segments can also be modified by the adversary (e.g. by deleting and adding valid and invalid Hop Fields). On reply packets from the destination, the adversary can transparently revert the changes to the path header again. For instance, if an adversary M is an intermediate AS on the path of a packet from A to B, then M can replace the packet’s past path (leading up to, but not including M) where the new path may not be a valid end-to-end path. However, when B reverses the path and sends a reply packet, that packet would go via M which can then transparently change the invalid path back to the valid path to A. In addition, the endpoint address header can also be modified.

Modifications of the SCION path and address header can be discovered by the destination endpoint by a data integrity protection system. Such a data integrity protection system, loosely analogous to the IPSec Authentication Header, exists for SCION but is out of scope for this document. This is described as the SCION Packet Authentication Option (SPAO) in [CHUAT22].

Moreover, packet integrity protection is not enough if there are two colluding adversaries on the path. These colluding adversaries can forward the packet between them using a different path than selected by the source endpoint: The first on-path attacker remodels the packet header arbitrarily, and the second on-path attacker changes the path back to the original source-selected path, such that the integrity check by the destination endpoint succeeds. However, such an attack is of little value. An on-path adversary may inspect/copy/disrupt its traffic without diverting it away from the sender-chosen path. For this reason proof-of-transit, which would be required to detect such an attack, has marginal benefit in the context of SCION and it is not in scope for this document.

7.2.2. Payload Integrity

An on-path attacker can modify the payload of a SCION packet. Existing higher-layer protocols can easily defend against such an attack without any cooperation by the SCION network. For that reason, payload integrity is not in scope for this specification. However, there exists a proposal for an experimental extension to authenticate addresses, provide integrity protection for payloads, and replay protection: SPAO . This is still very experimental and it not used in the production network.

7.3. Off-Path Attacks

SCION's path awareness limits the abilities of an off-path adversary to influence forwarding in the data plane. Once a packet is en-route it will follow its determined path regardless of the actions of the adversary. An adversary can attempt to disrupt the connectivity of the path by flooding a link with excessive traffic (see Section 7.4 below), but after detecting congestion, the endpoint can switch to another non-congested path for subsequent packets.

7.4. Volumetric Denial of Service Attacks

An adversary can attempt to disrupt the connectivity of a network path by flooding a link with excessive traffic. In this case, the endpoint can switch to another non-congested path for subsequent packets.

SCION provides protection against certain reflection-based DoS attacks. Here, the adversary sends requests to a server with the source address set to the address of the victim, and the server will send a reply that is typically larger than the request to the victim. This can be prevented in SCION as long as the attacker and the victim are located in different ASes as the reply packets are simply returned along reversed path to the actual sender regardless of the source address information. Thus, the reply packets will be forwarded to the attacker's AS where they will be discarded because the destination AS does not match.

However, the path choice of the endpoint may possibly be exploited by an attacker to create intermittent congestion with a relatively low send rate. The attacker can exploit the latency differences of the available paths, sending at precisely timed intervals to cause short, synchronized bursts of packets near the victim.

Note SCION does not protect against two other types of DoS attacks, namely transport protocol attacks and application layer attacks. Such attacks are out of SCION's scope although additional information contained in the SCION header enables more targeted filtering, e.g. by ISD, AS or path length.

8. Interoperability: SCION IP Gateway

The SCION IP Gateway (SIG) enables IP packets to be tunneled over SCION to support communication between hosts that do not run a SCION implementation. A SIG acts as a router from the perspective of IP, whilst acting as SCION endpoint from the perspective of the SCION network. It is typically deployed inside the same AS-internal network as its non-SCION hosts, or at the edge of an enterprise network.

Tunneling IP traffic over SCION requires a pair of SIGs and it involves the following steps:

  1. A sender sends an IP packet towards an IP destination.

  2. The IP packet reaches a SIG in the sender’s network via standard IP routing.

  3. Based on the destination IP address, the source (ingress) SIG determines the destination (egress) SIG's ISD-AS endpoint address. To achieve this, SIGs may be pre-configured with a static IP prefix to remote SIG SCION address mappings. Alternatively, multiple SIGs may be configured to speak a dynamic routing protocol between each other. The choice of protocol is left up to implementors and is outside of the scope of this document. Whether an egress SIG accepts or drops traffic from a given ingress SIG is up to the policies of the receiver's operator. The control mechanisms are implementation defined.

  4. The ingress SIG encapsulates the original IP packet within a SCION packet and sends it to the egress SIG. If necessary, the ingress SIG performs SCION path lookups and selects a SCION path to the egress SIG.

  5. The egress SIG receives the SCION packet and decapsulates the original IP packet. It then forwards the packet to the final IP destination using standard IP routing.

8.1. SIG Framing

IP packets are encapsulated over SCION/UDP into SIG frames. Whilst in principle, a given pair of SIGs may use any tunneling protocol, existing deployments use the SIG framing as described here. This protocol is designed to:

  • provide independence from the underlying SCION path MTU which can increase and decrease over time.

  • provide fast detection of packet loss and subsequent recovery of decapsulation for packets that weren't lost.

  • support for multiple streams within a framing session such that independent packet sequences be tunneled in parallel.

There may be multiple IP packets in a single SIG frame, and a single IP packet may be split into multiple SIG frames.

The ingress SIG initiates unidirectional packet flows with the egress SIG simply by sending the corresponding SIG frames. There is no handshake. The egress SIG, should it accept the traffic, instanciates the necessary resources on-demand to process each flow. Each such flow forms an independent sequence of packets (a stream) ordered by an incrementing sequence number. Between a given SIG ingress/egress pair, a (session ID, stream ID) pair uniquely identifies a stream.

To preserve performance, IP packets encapsulated in a single stream SHOULD leave the egress SIG in the order in which they entered it. To that end:

  • The ingress SIG SHOULD encapsulate IP packets that cannot be proven independent (e.g., with the same IP 6-tuple) in the same stream.

  • The ingress SIG SHOULD encapsulate IP packets to a given stream in the order in which they were received.

  • The ingress SIG SHOULD send all frames of a given stream over the same SCION path.

  • The egress SIG SHOULD reassemble and forward packets from each stream, ordered by frame sequence number and packet within each frame.

The session ID part of the (session ID, stream ID) pair is used to indicate traffic priority grouping. The egress SIG MAY dedicate processing resources to each session rather than to each individual stream.

+-----------------------+
|         SCION         |
+-----------------------+
|          UDP          |
+-----------------------+
|    SIG frame header   |
+-----------------------+
|   SIG frame payload   |
+-----------------------+
Figure 29: SIG framing within a SCION packet

8.2. SIG Frame Header 

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Version   |  Session ID   |            Index              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Reserved        |             Stream ID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       Sequence Number                         +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: SIG Frame Header format

All fields within SIG Frame Header are in network byte order.

  • Version (8 bits) indicates the SIG framing version. It MUST be set to zero if following this specification.

  • Session ID (8 bits) identifies a tunneling session between a pair of SIGs.

  • Index (16 bits) is the byte offset of the first beginning of an IP packet within the payload. If no IP packet starts in the payload, e.g. if the frame contains only the middle or trailing part of an IP packet, the field MUST be set to 0xFFFF.

  • Reserved (12 bits): it MUST be set to zero.

  • Stream ID (20 bits), along with the session, it identifies a unique sequence of SIG frames. Frames from the same stream are, on the egress SIG, put into the same reassembly queue. There may be multiple streams per session.

  • Sequence Number (64 bits) indicates the position of the frame within a stream. Consecutive frames of a given stream have consecutive sequence numbers. IP packets split among multiple frames are re-assembled by concatenating the payloads of consecutive frames.

A SIG MAY drop frames. Buffering frames received out-of-order by the egress SIG is optional. The egress SIG SHOULD drop frames from a stream if unable to perform the sequence re-assembly.

The Session ID and Stream ID are chosen by the sender but the tuple MUST be unique within a session.

8.3. SIG Frame Payload

The SIG frame payload may contain multiple IPv4 or IPv6 packets, or parts thereof. No other types of packets can be encapsulated and the packets are placed directly after one another with no padding. Handling of multicast is not covered by this specification and it is left as future work.

SIG uses the IPv4 or IPv6 'Payload Length Field to determine the size of the packet. To make the processing easier, it is REQUIRED that the fixed part of the IP header is in the frame where the IP packet begins. In other words, the initial fragment of an IPv4 packet must be at least 20 bytes long, whilst the initial fragment of an IPv6 packet must be at least 40 bytes long.

9. IANA Considerations

This document has no IANA actions.

The SCION AS and ISD number are SCION-specific numbers. They are currently allocated by Anapaya Systems, a provider of SCION-based networking software and solutions (see Anapaya ISD AS assignments). This task is currently being transitioned from Anapaya to the SCION Association.

10. References

10.1. Normative References

[I-D.dekater-scion-controlplane]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control Plane", Work in Progress, Internet-Draft, draft-dekater-scion-controlplane-05, , <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-05>.
[I-D.dekater-scion-pki]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control-Plane PKI", Work in Progress, Internet-Draft, draft-dekater-scion-pki-06, , <https://datatracker.ietf.org/doc/html/draft-dekater-scion-pki-06>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2460]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, , <https://www.rfc-editor.org/rfc/rfc2460>.
[RFC2474]
Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, , <https://www.rfc-editor.org/rfc/rfc2474>.
[RFC3168]
Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/rfc/rfc3168>.
[RFC4493]
Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, , <https://www.rfc-editor.org/rfc/rfc4493>.
[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, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5880]
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, , <https://www.rfc-editor.org/rfc/rfc5880>.
[RFC6437]
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, , <https://www.rfc-editor.org/rfc/rfc6437>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/rfc/rfc8200>.

10.2. Informative References

[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, , <https://doi.org/10.1007/978-3-031-05288-0>.
[CRYPTOBOOK]
Boneh, D. and V. Shoup, "A Graduate Course in Applied Cryptography", , <https://toc.cryptobook.us/>.
[I-D.dekater-panrg-scion-overview]
de Kater, C., Rustignoli, N., and A. Perrig, "SCION Overview", Work in Progress, Internet-Draft, draft-dekater-panrg-scion-overview-06, , <https://datatracker.ietf.org/doc/html/draft-dekater-panrg-scion-overview-06>.
[RFC1122]
Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <https://www.rfc-editor.org/rfc/rfc1122>.
[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, , <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2711]
Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, , <https://www.rfc-editor.org/rfc/rfc2711>.
[RFC4821]
Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, , <https://www.rfc-editor.org/rfc/rfc4821>.
[RFC9217]
Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, , <https://www.rfc-editor.org/rfc/rfc9217>.
[RFC9473]
Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path Properties", RFC 9473, DOI 10.17487/RFC9473, , <https://www.rfc-editor.org/rfc/rfc9473>.
[SCIONLAB]
Kown, J., García-Pardo, J., Legner, M., Wirz, F., Frei, M., Hausheer, D., and A. Perrig, "SCIONLAB - A Next-Generation Internet Testbed", , <https://ieeexplore.ieee.org/abstract/document/9259355>.
[SCIONLAB_WEBSITE]
"SCIONLab website", , <https://www.scionlab.org/>.
[SCMP]
Anapaya, ETH, and SCION, "SCMP Documentation", , <https://docs.scion.org/en/latest/protocols/scmp.html>.

Acknowledgments

Many thanks go to Matthias Frei (SCION Association), Juan A. Garcia Prado (ETH Zurich) and Kevin Meynell (SCION Association) for reviewing this document. We are also very grateful to Adrian Perrig (ETH Zurich), for providing guidance and feedback about each aspect of SCION. Finally, we are indebted to the SCION development teams of Anapaya and ETH Zurich, for their practical knowledge and for the documentation about the SCION Data Plane, as well as to the authors of [CHUAT22] - the book is an important source of input and inspiration for this draft.

Deployment Testing: SCIONLab

SCIONLab is a global research network that is available to test the SCION architecture. You can create and use your ASes using your own computation resources which allows you to gain real-world experience of deploying and managing a SCION network.

More information can be found at [SCIONLAB_WEBSITE] and in the [SCIONLAB] paper.

Assigned SCION Protocol Numbers

This appendix lists the assigned SCION protocol numbers.

Considerations

SCION attempts to take the IANA's assigned Internet protocol numbers into consideration. Widely employed protocols have the same protocol number as the one assigned by IANA. SCION specific protocol numbers start at 200.

The protocol numbers are used in the SCION header to identify the upper layer protocol.

Assignment

Table 20: The assigned SCION protocol numbers
Decimal Keyword Protocol
0-5   Unassigned
6 TCP/SCION Transmission Control Protocol over SCION
7-16   Unassigned
17 UDP/SCION User Datagram Protocol over SCION
18-199   Unassigned
200 HBH SCION Hop-by-Hop Options
201 E2E SCION End-to-End Options
202 SCMP SCION Control Message Protocol
203 BFD/SCION BFD over SCION
204-252   Unassigned
253   Use for experimentation and testing
254   Use for experimentation and testing
255   Reserved

Change Log

Changes made to drafts since ISE submission. This section is to be removed before publication.

draft-dekater-scion-dataplane-03

Major changes:

  • Added section with SCMP specification

  • Added section on SCION IP Gateway

  • Added section on Handling Link Failures and BFD

  • Added sections on MTU and fragmentation

  • Clarified router checks in Processing at Routers

  • Security Considerations: add section on Payload Modifications

Minor changes:

  • Added Figure on Header Overview in introduction

  • Clarified the router alert flags and relationship to the ConsIngress/Egress fields.

  • Clarifications in the SCION Header Specification section (router alert flags, service addresses, one-hop paths, text clarifications, validity of peering links)

  • Added mention of why proof of transit is not needed.

  • Rename flow ID to Flow Label and document by reference to [RFC6437].

  • Added reference to SCIONLab as a testbed for implementors

  • Added J. C. Hugly as author.

  • Introduced this change log

  • Clarify addressing and avoid confusing claim of communication between two endpoints with the same IP (section 1.3.1)

draft-dekater-scion-dataplane-02

Major changes:

  • Added overview of SCION components to Introduction section.

  • Introduced AES-CMAC as default MAC algorithm and elaborated on MAC chaining and path splicing.

  • Added section to describe Effects of Clock Inaccuracy / time synchronization requirements

  • Added section to describe required router Configuration

  • Added service field table

Minor changes:

  • Removed forward references.

  • General edits to make terminology consistent, remove duplication and rationalize text.

  • Added and capitalized RFC2119 compliant terminology.

  • Clarified implications of AS forwarding key compromise and path splicing in security considerations

  • Clarified the computation of ExtLen.

Authors' Addresses

Corine de Kater
SCION Association
Nicola Rustignoli
SCION Association
Jean-Christophe Hugly
SCION Association
Samuel Hitz
Anapaya Systems