SCION Control Plane

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, company, or university can constitute an AS.¶

Beaconing: The Control Plane process where an AS discovers paths to other ASes.¶

Control Plane: The SCION Control Plane is responsible for the propagation and discovery of network paths, i.e., for the exchange of routing information between SCION nodes. The Control Plane thus determines where traffic can be sent and deals with questions such as how paths are discovered, which paths exist, how they are disseminated to endpoints, etc. Within a SCION AS, such functionalities are carried out by the Control Service whereas packet forwarding is a task carried out by the data plane.¶

Control Service: The Control Service is the main control plane infrastructure component within a SCION AS. It is responsible for the path exploration and registration processes that take place within the Control Plane.¶

Core AS: Each 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 -construction process (in SCION called "beaconing").¶

Endpoint: An endpoint is the start or the end of a SCION path, as defined in [RFC9473].¶

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

Isolation Domain (ISD): 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 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 and accumulates path segments, which can subsequently be used for traffic forwarding.¶

SCMP: A signaling protocol analogous to the Internet Control Message Protocol (ICMP). This is described in Section 6.¶

Trust Root Configuration (TRC): A Trust Root Configuration or TRC is a signed collection of certificates pertaining to an isolation domain (ISD). TRCs also contain ISD-specific policies.¶

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. Paths and Links

SCION routers and endpoints connect to each other via links. A SCION path between two endpoints essentially traverses one or more links.¶

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 (i.e. a common jurisdiction). An ISD is administered by a set of distinguished ASes called core ASes.¶

SCION distinguishes three types of links between ASes: (1) core links, (2) parent-child links, and (3) peering links.¶

• Core links connect two core ASes, which are either within the same or in different ISDs. Core links can exist for various reasons, including provider-customer (where the customer pays the provider for traffic) and peering relationships.¶

• Parent-child links create a hierarchy between the parent and the child AS within the same ISD. ASes with a parent-child link typically have a provider-customer relationship.¶

• Peering links exist between ASes with a (settlement-free or paid) peering relationship. They can be established between any two ASes (core or non-core) and can cross ISD boundaries.¶

These link types form the basis of the notion of "valley free" paths. Valley free paths means that a child AS does not carry transit traffic from a parent AS.¶

The SCION paths are always valley free, and consist of at most three segments: an up segment, traversing links from child to parent, then a core segment consisting of core links, followed by a down segment traversing links from parent to child. Peering links can be used as "shortcuts" in an up-core-down path.¶

A path can contain at most one peering link shortcut which means they can only be used in paths between ASes within the "customer cone" of the ASes connected by the peering link.¶

Figure 1 shows the three types of links for one small ISD with two core ASes A and C, and four non-core ASes D,E,F, and G.¶

+-------------------------+
|                         |       #
|        ISD Core         |       |      parent-child
|  .---.           .---.  |       |      link
| (  A  )*-------*(  C  ) |       |
|  `-#-'           `-#-'  |       0
|    |               |    |
+----|---------------|----+   *-------*  core link
     |               |
     |               |        < - - - >  peering link
   .-0-.           .-0-.
  (  D  )< - - - >(  E  )
   `-#-'           `-#-'
     |               |
     |               |
     |               |
   .-0-.           .-0-.
  (  G  )         (  F  )
   `---'           `---'

Each link connecting SCION routers is bi-directional and is identified by its corresponding egress and ingress interface IDs. An interface ID consists of a 16-bit identifier that MUST be unique within each AS, with the exception of value 0 (see [I-D.dekater-scion-dataplane]). Therefore, they can be chosen and encoded by each AS independently without any need for coordination between ASes.¶

1.4. Routing

SCION provides path-aware inter-domain routing between ASes across the Internet. The SCION Control Plane is responsible for discovering these inter-domain paths and making them available to the endpoints within the ASes.¶

SCION inter-domain routing operates on two levels: within a ISD which is called intra-ISD routing, and between ISD which is called inter-ISD routing. Both levels use Path Segment Construction Beacons (PCBs) to explore network paths. A PCB is initiated by a core AS and then disseminated either within an ISD to explore intra-ISD paths, or among core ASes to explore core paths across different ISDs.¶

The PCBs accumulate cryptographically protected path and forwarding information at an AS level and store this information in the form of Hop Fields. Endpoints use information from these Hop Fields to create end-to-end forwarding paths for data packets that carry this information in their headers. This also supports multi-path communication among endpoints.¶

The creation of an end-to-end forwarding path consists of the following processes:¶

1. Path exploration (or beaconing): This is the process where an AS discovers paths to other ASes. See also Section 2.¶

2. Path registration: This is the process where an AS selects a few PCBs, according to defined policies, turns the selected PCBs into path segments, and adds these path segments to the relevant path infrastructure, thus making them available to other ASes. See also Section 4.¶

3. Path resolution: This is the process of actually creating an end-to-end forwarding path from the source endpoint to the destination. For this, an endpoint performs (a) a path lookup step to obtain path segments, and (b) a path combination step to combine the forwarding path from the segments. This last step takes place in the data plane. See also Section 5.¶

All processes operate concurrently.¶

The Control Service is responsible for the path exploration and registration processes in the Control Plane. It is the main control plane infrastructure component within each SCION AS and has the following tasks:¶

• Generating, receiving, and propagating PCBs. Periodically, the Control Service of a core AS generates a set of PCBs, which are forwarded to the child ASes or neighboring core ASes. In the latter case, the PCBs are sent over policy compliant paths to discover multiple paths between any pair of core ASes.¶

• Selecting and registering the set of path segments via which the AS wants to be reached.¶

• Managing certificates and keys to secure inter-AS communication. Each PCB contains signatures of all on-path ASes and each time the Control Service of an AS receives a PCB, it validates the PCB's authenticity. When the Control Service lacks an intermediate certificate, it can query the Control Service of the neighboring AS that sent the PCB.¶

Note: The Control Service of an AS is decoupled from SCION border routers. The Control Service of a specific AS is part of the Control Plane, is responsible for finding and registering suitable paths, and can be deployed anywhere inside the AS. Border routers are deployed at the edge of an AS and their main tasks are to forward data packets.¶

1.5. Addressing

Inter-domain SCION routing is based on an <ISD, AS> tuple. Although a complete SCION address is composed of the <ISD, AS, endpoint address> 3-tuple, the endpoint address is not used for inter-domain routing or forwarding. The endpoint address is of variable length, does not need to be globally unique, and can thus be an IPv4, IPv6, or link layer address.¶

Note: As a consequence of the fact that SCION relies on existing routing protocols (e.g. IS-IS, OSPF, SR) and communication fabric (e.g. IP, MPLS) for intra-domain forwarding, existing internal routers do not need to be changed to support SCION.¶

1.6. Avoiding Circular Dependencies and Partitioning

A secure and reliable routing architecture has to be designed specifically to avoid circular dependencies during network initialization. One goal of SCION is that the Internet can start up even after large outages or attacks, in addition to avoiding cascades of outages caused by fragile interdependencies. This section lists the concepts SCION uses to prevent circular dependencies.¶

• Neighbor-based path discovery: Path discovery in SCION is performed by the beaconing mechanism. In order to participate in this process, an AS only needs to be aware of its direct neighbors. As long as no path segments are available, communicating with the neighboring ASes is possible with the one hop path type which does not rely on any path information. SCION uses these one hop paths to propagate PCBs to neighboring ASes to which no forwarding path is available yet. The One Hop Path Type is described in more detail in [I-D.dekater-scion-dataplane].¶

• Path segment types: SCION uses different types of path segments to compose end-to-end paths. Notably, a single path segment already enables intra-ISD communication. For example, a non-core AS can reach the core of the local ISD simply by using an up segment fetched from the local path storage which is populated during the beaconing process.¶

• Path reversal: In SCION, every path is reversible. That is, the receiver of a packet can reverse the path in the packet header in order to produce a reply packet without having to perform a path lookup. Such a packet follows the original packet's path backwards.¶

• Availability of certificates: In SCION, every entity is required to be in possession of all cryptographic material (including the ISD's TRC and certificates) that is needed to verify any message it sends. This (together with the path reversal) means that the receiver of a message can always obtain all this material by contacting the sender.
  ¶

Note: For a detailed description of a TRC and more information on the availability of certificates and TRCs, see the SCION Control-Plane PKI Internet-Draft [I-D.dekater-scion-pki].¶

Besides inter-dependencies, another threat to the Internet is network partition which occurs when one network is split into two because of a link failure. However, partition of the global SCION inter-domain network is much less likely to happen as during normal operation the full network fabric is available, offering multiple paths between all ASes. Even during failures there is no special failure mode required as SCION-enabled ASes can always switch to otherwise unused links.¶

Recovering from a partitioned network is also seamless as only coarse time synchronization between the partitions is required to resume normal operation and move forward with updates of the cryptographic material. Section 3.2 further describes the impact of time synchronization.¶

1.7. Communication Protocol

All communication between the Control Services in different ASes is expressed in terms of gRPC remote procedure calls (for details, see [gRPC]). Service interfaces and messages are defined in the Protocol Buffer "proto3" interface definition language (for details, see [proto3]).¶

The RPC messages are transported via the [Connect]'s rpc protocol; a gRPC-like protocol that carries messages over HTTP/3 (see [RFC9114])). HTTP3 traffic uses QUIC/UDP ([RFC9000]) as a transport layer. In the case of SCION, UDP relies on the data plane.¶

Appendix "Full Control Service gRPC API" provides the entire Control Service API definition in protobuf format.¶

Appendix "SCION Data Plane use by the SCION Control Plane" provides details about the establishment of the underlying QUIC connections through the data plane.¶

2.1. Introduction and Overview

Path Exploration is the process where an AS discovers paths to other ASes. In SCION, this process is referred to as beaconing and this section provides a detailed explanation of this.¶

In SCION, the Control Service of each AS is responsible for the beaconing process. The Control Service generates, receives, and propagates the Path Segment Construction Beacons (PCBs) on a regular basis, to iteratively construct path segments.¶

PCBs contain topology and authentication information, and can also include additional metadata that helps with path management and selection. The beaconing process itself is divided into routing processes on two levels, where inter-ISD or core beaconing is based on the (selective) sending of PCBs without a defined direction, and intra-ISD beaconing on top-to-bottom propagation.¶

• Inter-ISD or core beaconing is the process of constructing path segments between core ASes in the same or in different ISDs. During core beaconing, the Control Service of a core AS either initiates PCBs or propagates PCBs received from neighboring core ASes to other neighboring core ASes. PCBs are periodically sent over policy compliant paths to discover multiple paths between any pair of core ASes.¶

• Intra-ISD beaconing creates path segments from core ASes to non-core ASes. For this, the Control Services of core ASes create PCBs and sends them to the non-core child ASes (typically customer ASes) at regular intervals. The Control Service of a non-core child AS receives these PCBs and forwards them to its child ASes, and so on until the PCB reaches an AS without any customer (leaf AS). As a result, all ASes within an ISD receive path segments to reach the core ASes of their ISD.¶

On its way, a PCB accumulates cryptographically protected path and forwarding information per traversed AS. At every AS, metadata as well as information about the AS's ingress and egress interfaces is added to the PCB. The full PCB message format is described in Section 2.2.¶

                            +-------------+
                            | Core AS X   |
                            |             |
                            |    2   1    |
                            +----#---#----+
          +--------+             |   |             +--------+
          |PCB     |     +-----+ |   | +-----+     |PCB     |
          |========|-----|PCB a| |   | |PCB b|=====|++++++++|
          |Core    |     +-----+ |   | +-----+     |Core    |
          |- Out:2 |        |    |   |    |        |- Out:1 |
          +--------+        v    |   |    v        +--------+
                                 v   v
                            +----#---#----+
                            |     AS Y    |

                        +-----+ |   | +-----+
                        |PCB a| |   | |PCB b|
                        +-----+ |   | +-----+
                           |    |   |    |
                           v    |   |    v
        +-------------+         v   v
        |             |    +----#---#----+    +-------------+
        |             |    |    2   3    |    |             |
        |    AS V     #- --# 1           |    |             |
        |             |    |     AS Y    |    |    AS W     |
        |             |    |           4 #- --#             |
        +-------------+    |             |    |             |
                           |    6   5    |    +-------------+
            +--------+     +----#---#----+     +--------+
            |PCB     |          |   |          |PCB     |
            |========|          |   |          |========|
            |Core X  |          |   |          |Core X  |
            |- Out:2 |          |   |          |- Out:2 |
+--------+  |--------|  +-----+ |   | +-----+  |--------|  +--------+
|PCB     |  |AS Y    |--|PCB c| |   | |PCB d|--|AS Y    |  |PCB     |
|++++++++|  |-In:2   |  +-----+ |   | +-----+  |-In:2   |  |++++++++|
|Core X  |  |-Out:6  |     |    |   |    |     |-Out:5  |  |Core X  |
|- Out:1 |  |-PeerV:1|     v    |   |    v     |-PeerV:1|  |- Out:1 |
|--------|  |-PeerW:4|          |   |          |-PeerW:4|  |--------|
|AS Y    |  +--------+          |   |          +--------+  |AS Y    |
|-In:3   |              +-----+ |   | +-----+              |-In:3   |
|-Out:6  |==============|PCB e| |   | |PCB f|==============|-Out:5  |
|-PeerV:1|              +-----+ |   | +-----+              |-PeerV:1|
|-PeerW:4|                 |    |   |    |                 |-PeerW:4|
+--------+                 v    |   |    v                 +--------+
                                v   v
                           +----#---#----+
                           |    AS Z     |

                   +-----+      |   |      +-----+
                   |PCB c|      |   |      |PCB d|
                   +-----+      |   |      +-----+
                     |  +-----+ |   | +-----+  |
                     v  |PCB e| |   | |PCB f|  v
                        +-----+ |   | +-----+
                           |    |   |    |
                           v    |   |    v
                                v   v
                         +------#---#------+
                         |      5   1      |
                         |                 |
                         | AS Z            |
            +--------+   |        3        |   +--------+
            |PCB     |   +--------#--------+   |PCB     |
            |========|            |            |========|
            |Core X  |            |            |Core X  |
+--------+  |- Out:2 |            |            |- Out:2 |  +--------+
|PCB     |  |--------|            |            |--------|  |PCB     |
|++++++++|  |AS Y    |            |            |AS Y    |  |++++++++|
|Core X  |  |-In:2   |            |            |-In:2   |  |Core X  |
|- Out:1 |  |-Out:6  |   +-----+  |  +-----+   |-Out:5  |  |- Out:1 |
|--------|  |-PeerV:1|---|PCB g|  |  |PCB h|---|-PeerV:1|  |--------|
|AS Y    |  |-PeerW:4|   +-----+  |  +-----+   |-PeerW:4|  |AS Y    |
|-In:3   |  |--------|      |     |     |      |--------|  |-In:3   |
|-Out:6  |  |AS Z    |      v     |     v      |AS Z    |  |-Out:5  |
|-PeerV:1|  |-In:5   |            |            |-In:1   |  |-PeerV:1|
|-PeerW:4|  |-Out:3  |            |            |-Out:3  |  |-PeerW:4|
|--------|  +--------+            |            +--------+  |--------|
|AS Z    |               +-----+  |  +-----+               |AS Z    |
|-In:5   |===============|PCB i|  |  |PCB j|===============|-In:1   |
|-Out:3  |               +-----+  |  +-----+               |-Out:3  |
+--------+                  |     |     |                  +--------+
                            v     |     v
                                  v

                AS Entry Core         AS Entry Y          AS Entry Z

               +-------------+     +-------------+     +-------------+
               |  Core AS X  |     |    AS Y     |     |     AS Z    |
path segment 1 |            1#     #3            5     #1            |
               |             |     |             |     |             |
               |            2#-----#2----------- 6-----#5            |
               |             |     |             |     |             |
               +-------------+     +-------------+     +-------------+
                 egress 2       ingress 2 - egress 6      ingress 5

----------------------------------------------------------------------

               +-------------+     +-------------+     +-------------+
               |  Core AS X  |     |    AS Y     |     |     AS Z    |
               |            1#     #3     +-----5#-----#1            |
path segment 2 |             |     |      |      |     |             |
               |            2#-----#2-----+     6#     #5            |
               |             |     |             |     |             |
               +-------------+     +-------------+     +-------------+
                 egress 2       ingress 2 - egress 5      ingress 1

------------------------------------------------------------------------

               +-------------+     +-------------+     +-------------+
               |  Core AS X  |     |    AS Y     |     |     AS Z    |
               |            1#-----#3-----+     5#     #1            |
path segment 3 |             |     |      |      |     |             |
               |            2#     #2     +-----6#-----#5            |
               |             |     |             |     |             |
               +-------------+     +-------------+     +-------------+
                 egress 1       ingress 3 - egress 6      ingress 5

------------------------------------------------------------------------

               +-------------+     +-------------+     +-------------+
               |  Core AS X  |     |   AS Y      |     |     AS Z    |
               |            1#-----#3-----------5#-----#1            |
path segment 4 |             |     |             |     |             |
               |            2#     #2           6#     #5            |
               |             |     |             |     |             |
               +-------------+     +-------------+     +-------------+
                 egress 1       ingress 3 - egress 5      ingress 1

2.2. Path-Segment Construction Beacons (PCBs)

                              PCB / PATH SEGMENT

+-------------+------------+------------+--------+--------------------+
|Segment Info | AS Entry 0 | AS Entry 1 |  ...   |     AS Entry N     |
+-------------+------------+------------+--------+--------------------+
*- - - - # - -*            *- - - # - - *
         |                        |
*- - - - v - - - *                |
+---------+------+                |
|Timestamp|Seg ID|                |
+---------+------+                |
                                  |
*- - - - - - - - - - - - - - - - -v- - - - - - - - - - - - - - - - - - *
+-----------------------+----------------------------------------------+
|    Unsigned Ext.      |               Signed AS Entry                |
+-----------------------+----------------------------------------------+
                        *- - - - - - - - - - - - # - - - - - - - - - - *
                                                 |
                                                 |
*- - - - - - - - - - - - - - - - - - - - - - - - v - - - - - - - - - - *
+--------------------+-----------------++------------------------------+
|     Signature      |    Header       ||                    Body      |
+--------------------+-----------------++------------------------------+
                     *- - - - # - - - -**- - - - - - - - # - - - - - - *
                              |                          |
*- - - - - - - - - - - - - - -v- - - - *                 |
+----------------+---------------------+                 |
| Signature Alg. | Verification Key ID |                 |
+----------------+---------------------+                 |
                 *- - - - - # - - - - -*                 |
                            |                            |
*- - - - - - - - - - - - - -v- - - - - - - - - -*        |
+---------+---------+------------+--------------+        |
| ISD-AS  |TRC Base | TRC Serial |Subject Key ID|        |
+---------+---------+------------+--------------+        |
                                                         |
*- - - - - - - - - - - - - - - - - - - - - - - - - - - - v - - - - - - *
+------+-----------+---------++------------+----+------------++---+----+
|ISD-AS|Next ISD-AS|Hop Entry||Peer Entry 0| ...|Peer Entry N||MTU|Ext.|
+------+-----------+---------++------------+----+------------++---+----+
                   *- - # - -**- - - # - - *
                        |            |
                        |            |
*- - - - - - - - - - - -v- *  *- - - v - - - - - - - - - - - - - - - - *
+-------------+------------+  +--------+--------+----------+-----------+
| Ingress MTU | Hop Field  |  |HopField|PeerMTU |PeerISD-AS|PeerInterf.|
+-------------+--------+---+  +----+---+--------+----------+-----------+
                       *- - -#- - -*
                             |
                             |
*- - - - - - - - - - - - - - v - - - - - - - - - - - - - - *
+------------+-------------+-------------------+-----------+
|  Ingress   |    Egress   |  Expiration Time  |   MAC     |
+------------+-------------+-------------------+-----------+

+-------------+-------------+------------+------+------------+
|Segment Info | AS Entry 0  | AS Entry 1 |  ... | AS Entry N |
+-------------+-------------+------------+------+------------+

   message PathSegment {
       bytes segment_info = 1;
       repeated ASEntry as_entries = 2;
   }

+----------------------------+
|         Segment Info       |
+----------------------------+
*- - - - - - - # - - - - - - *
               |
               |
*- - - - - - - v - - - - - - *
+--------------+-------------+
|   Timestamp  |   Seg ID    |
+--------------+-------------+

   message SegmentInformation {
       int64 timestamp = 1;
       uint32 segment_id = 2;
   }

                           +--------------+
                           |  AS Entry    |
                           +--------------+
                           *- - - -#- - - *
                                   |
                                   |
                                   |
*- - - - - - - - - - - - - - - - - v - - - - - - - - - - - - - - - *
+-----------------------+------------------------------------------+
|    Unsigned Ext.      |          Signed AS Entry                 |
+-----------------------+------------------------------------------+

   message ASEntry {
       SignedMessage signed = 1;
       PathSegmentUnsignedExtensions unsigned = 2;
   }

        +------------------------------------------------------+
        |                   Signed AS Entry                    |
        +------------------------------------------------------+
        *- - - - - - - - - - - - -#- - - - - - - - - - - - - - *
                                  |
                                  |
*- - - - - - - - - - - - - - - - -v- - - - - - - - - - - - - - - - - -*
+--------------------+-----------------+------------------------------+
|      Header        |     Body        |            Signature         |
+--------------------+-----------------+------------------------------+

   message SignedMessage {
       bytes header_and_body = 1;
       bytes signature = 2;
   }

   message HeaderAndBodyInternal {
       // Encoded header suitable for signature computation.
       bytes header = 1;
       // Raw payload suitable for signature computation.
       bytes body = 2;
   }

           +-----------------+
           |     Header      |
           +-----------------+
           *- - - - # - - - -*
                    |
 - - - - - - - - - -v- - - - - - - - - *
+----------------+---------------------+
| Signature Alg. | Verification Key ID |
+----------------+---------------------+
                 *- - - - - # - - - - -*
                            |
 - - - - - - - - - - - - - -v- - - - - - - - - -
+---------+---------+------------+--------------+
| ISD-AS  |TRC Base | TRC Serial |Subject Key ID|
+---------+---------+------------+--------------+

   message Header {
       SignatureAlgorithm signature_algorithm = 1;
       bytes verification_key_id = 2;
       // Optional
       google.protobuf.Timestamp timestamp = 3;
       // Optional
       bytes metadata = 4;
       int32 associated_data_length = 5;
   }

   message VerificationKeyID {
       uint64 isd_as = 1;
       bytes subject_key_id = 2;
       uint64 trc_base = 3;
       uint64 trc_serial = 4;
   }

                +--------------------------------------+
                |                 Body                 |
                +--------------------------------------+
                *- - - - - - - - - -#- - - - - - - - - *
                                    |
                                    |
*- - - - - - - - - - - - - - - - - -v- - - - - - - - - - - - - - - - -*
+------+-----------+---------++------------+---+------------++---+----+
|ISD-AS|Next ISD-AS|Hop Entry||Peer Entry 0|...|Peer Entry N||MTU|Ext.|
+------+-----------+---------++------------+---+------------++---+----+

   message ASEntrySignedBody {
       uint64 isd_as = 1;
       uint64 next_isd_as = 2;
       HopEntry hop_entry = 3;
       repeated PeerEntry peer_entries = 4;
       uint32 mtu = 5;
       PathSegmentExtensions extensions = 6;
   }

input(ps, i) = signed.header_and_body || associated_data(ps, i)

associated_data(ps, i) = ps.segment_info ||
                         ps.as_entries[1].signed.header_and_body ||
                         ps.as_entries[1].signed.signature ||
                         ...
                         ps.as_entries[i-1].signed.header_and_body ||
                         ps.as_entries[i-1].signed.signature

       +-----------+
       | Hop Entry |
       +-----------+
       *- - -#- - -*
             |
 - - - - - - v - - - - - - *
+-------------+------------+
| Ingress MTU | Hop Field  |
+-------------+------------+

   message HopEntry {
       HopField hop_field = 1;
       uint32 ingress_mtu = 2;
   }

                      +-----------+
                      | Hop Field |
                      +-----------+
                      *- - -#- - -*
                            |
                            |
*- - - - - - - - - - - - - -v- - - - - - - - - - - - - - - *
+-------------+-------------+-------------------+----------+
|   Ingress   |    Egress   |  Expiration Time  |   MAC    |
+-------------+-------------+-------------------+----------+

   message HopField {
       uint64 ingress = 1;
       uint64 egress = 2;
       uint32 exp_time = 3;
       bytes mac = 4;
   }

                      +--------------+
                      |  Peer Entry  |
                      +--------------+
                      *- - - -#- - - *
                              |
*- - - - - - - - - - - - - - -v- - - - - - - - - - - - - - *
+-------------+------------+--------------+----------------+
|  Hop Field  |  Peer MTU  | Peer ISD-AS  | Peer Interface |
+-------------+------------+--------------+----------------+

   message PeerEntry {
       uint64 peer_isd_as = 1;
       uint64 peer_interface = 2;
       uint32 peer_mtu = 3;
       HopField hop_field = 4;
   }

   +-----------+
   |           |
   | parent AS |
   |           |
   +-----------+
         |
         |
         | ASE.HF.ingress_interface
+--------#-----------+                  +-----------------+
|        |           |         PE.peer_ |                 |
|                    |         interface|                 |
|        | + - - - - #------------------#     peer AS     |
|                    |PE.HF.ingress_    |                 |
|        | |         |interface         |                 |
|                    |                  +-----------------+
|        v v         |
+---------#----------+
          | PE.HF.egress_interface
          | ASE.HF.egress_interface
          |
          |
    +-----------+
    |           |
    |  child AS |
    |           |
    +-----------+

2.3. Propagation of PCBs

This section describes how PCBs are selected and propagated in the path exploration process.¶

Selected path segment: #------# or *------*
 Peering Link: PL

   ISD A: Path Length                 ISD B: Peering Links
+----------------------+          +---------------------------+
|      ISD Core        |          |        ISD Core           |
| .---.         .---.  |          |  .---.             .---.  |
|(  A  ) - - - (  C  ) |          | (  A  ) - - - - - (  C  ) |
| `-#-'         `---'  |       + --- `---'             `---'  |
|   ||   .---.   | |   |          |      |  .---. - - - - -   |
|   | - (  B  ) -      |       |  |    |  -(  B  )            |
|   |    `-+-'     |   |          |         `-#-||            |
+---|--------------|---+       |  |    |      |   - - - - - - - - +
    |      |       |           |  |           | |             |
    |                          |  +----|------|-|-------------+   |
    |      |     .-+-.                        | + - - - - +
    |    .-+-.  (  E  )        |       |      |                   |
    |   (  D  )  `---'                        |           |
    |    `-+-'     |         .-+-.     |    .-#-.       .-+-.     |
    |            .-+-.      (  D  )-PL-----(  E  )--PL-(  F  )
    |      |    (  F  )      `---'     |    `-#-'       `-+-'   .-+-.
  .-#-.          `-+-'                        |                (  G  )
 (  G  ) - +       |               - - +      |           |     `-+-'
  `---- - - - - - -               |           |
                                .---.       .-#-.       .-+-.     |
                               (  H  )-PL--(  I  )--PL-(  J  )
                                `---'       `-#-'       `---'   .-+-.
                                              |           |    (  K  )
       ISD C: Disjointness                    |                 `---'
  +---------------------------+             .-#-.         |       |
  |          ISD Core         |            (  L  ) - - - -
  |                           |             `---' - - - - - - - - +
  | .---.               .---. |
  |(  A  ) - - - - - - (  C  )|
  | `-*-'               `-#-' |
  |   | |     .---.     | |   |
  |   |  - - (  B  ) - -  |   |
  |   |       `---'       |   |
  +---|-------------------|---+
      |                   |
 .----*.                .-#---.
(   D   )              (   E   )
 `----*'                `-#---'
 |    |                   |   |
    #---------------------#
 |  | |                       |
    | *------------------*
 |  |                    |    |
 .--#--.                .*----.
(   F   #-------#      (   G   )
 `-----'        |       `*----|
 |          *------------*
            |   |             |
 |-----.    |   |       .-----.
(   H  *----*   #------#   I   )
 `---*-'                `-#---'
     |                    |
     |       .---.        |
     *------*  J  #-------#
             `---'

   service SegmentCreationService {
       rpc Beacon(BeaconRequest) returns (BeaconResponse) {}
   }

   message BeaconRequest {
       PathSegment segment = 1;
   }

   message BeaconResponse {}

3.1. Monitoring Considerations

In order to maintain service availability, an AS SHOULD monitor the following aspects when deploying the SCION control plane:¶

• For routers (to enable correlation with link states): state of configured links (core, child, parent)¶

• For any control service:¶

  • Fraction of path lookups served successfully (see Section 5)¶

  • Time synchronization offset with other ASes (see Section 3.2)¶

  • Fraction of ASes found in non-expired segments for which a non-expired certificate exists¶

• For a core AS:¶

  • Fraction of core ASes (preferably only those to which the link is up) that can be found in non-expired core segments¶

  • Fraction of ASes, core or children, (preferably only those to which the link is up) whereto a beacon was initiated during the last propagation interval¶

  • Fraction of freshly propagated beacons for which at least one corresponding down segment has been registered (see Section 4)¶

• For a non-core AS:¶

  • Number of up segments available (may be just 0/non-0) younger than the propagation interval (or some multiple thereof).¶

  • Fraction of up segments that were successfully registered as down segments (see Section 4).¶

  • Fraction of children ASes (preferably only those to which the link is up) whereto a beacon was propagated during the last propagation interval¶

3.2. Effects of Clock Inaccuracy

A PCB originated by a given Control Service is validated by all the Control Services that receive it. All have different clocks and their differences affect the validation process:¶

• A fast clock at origination or a slow clock at reception 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 reception 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 around one minute. As a result of this and the way they are iteratively constructed, PCBs with N hops may be validated up to N intervals (so maximally 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.2.1.6) would make any PCB describing a path longer than 5 hops expire. For this reason it is unadvisable to create hops with a short expiration time - they SHOULD be around 6 hours.¶

The Control Service and its clients authenticate each-other according to their respective AS's certificate. Path segments are authenticated based on the certificates of the ASes that they refer to. The RECOMMENDED expiration time of a SCION AS certificate is between 3h and 3 days. Some deployments use up to 5 days. In comparison to these time scales, clock offsets in the order of minutes are immaterial.¶

Each administrator of a SCION Control Service is responsible for maintaining sufficient clock accuracy. No particular method is assumed by this specification.¶

3.3. Path Discovery Time and Scalability

The path discovery mechanism balances the number of discovered paths and the time it takes to discover them versus resource overhead of the discovery.¶

The resource costs for path discovery are as follows:¶

• Communication overhead is transmitting the PCBs and occasionally obtaining the required PKI material.¶

• Processing overhead is validating the signatures of the AS entries, signing new AS entries, and to a lesser extent, evaluating the beaconing policies.¶

• Storage overhead is both the temporary storage of PCBs before the next propagation interval, and the storage of complete discovered path segments.¶

All of these are dependent on the number and length of the discovered path segments, i.e. the total number of AS entries of the discovered path segments.¶

Interesting metrics for scalability and speed of path discovery are the time until all discoverable path segments have been discovered after a "cold start", and the time until new link is usable. In general, the time until a specific PCB is built depends on its length, the propagation interval, and whether on-path ASes use "fast recovery".¶

At each AS, the PCB will be processed and propagated at the subsequent propagation event. As propagation events are not synchronized between different ASes, a PCB arrives at a random point in time during the interval and may be buffered before potentially being propagated. With a propagation interval T at each AS, the mean time until the PCB is propagated in one AS therefore is T / 2 and the mean total time for the propagation steps of a PCB of length L is at worst L * T / 2 (with a variance of L * T^2 / 12).¶

Note that link removal is not part of path discovery in SCION. For scheduled removal of links, operators let path segments expire. On link failures, endpoints route around the failed link by switching to different paths in the data plane.¶

To achieve scalability, SCION partitions ASes into ISDs and in an ideal topology the inter-ISD core network should be kept to a moderate size. For more specific observations, we distinguish between intra-ISD and inter-ISD beaconing.¶

4.1. Intra-ISD Path Segment Registration

Every registration period (determined by each AS), the AS's Control Service selects two sets of PCBs to transform into two types of path segments:¶

• Up segments, which allow the infrastructure entities and endpoints in this AS to communicate with core ASes; and¶

• Down segments, which allow remote entities to reach this AS.¶

The up segments and down segments do not have to be equal as AS may want to communicate with core ASes via one or more up segments that differ from the down segment(s) through which it wants to be reached. Therefore, an AS can define different selection policies for the up segment and down segment sets. In addition, the processes of transforming a PCB in an up segment or a down segment differ slightly.¶

4.2. Core Path Segment Registration

The core beaconing process creates path segments from core AS to core AS. These core segments are then added to the Control Service path database of the core AS that created the segment, so that local and remote endpoints can obtain and use these core segments. In contrast to the intra-ISD registration procedure, there is no need to register core segments with other core ASes as each core AS will receive PCBs originated from every other core AS.¶

In every registration period, the Control Service of a core AS performs the following operations:¶

1. The core Control Service selects the best PCBs towards each core AS observed so far.¶

2. The core Control Service "terminates" the selected PCBs by performing the steps described in Section 4.1.1. From this moment on, the modified PCBs are called core segments.¶

3. The Control Service adds the newly created core segments to its own path database.¶

Note: For more information on possible selection strategies of PCBs, see Section 2.3.1.¶

4.3. Path Segment Registration gRPC API

The Control Service of a non-core AS has to register the newly created down segments with the Control Services of the core ASes that originated the corresponding PCBs. This registration step is implemented as follows in Protobuf message format:¶

   enum SegmentType {
       SEGMENT_TYPE_UNSPECIFIED = 0;
       SEGMENT_TYPE_UP = 1;
       SEGMENT_TYPE_DOWN = 2;
       SEGMENT_TYPE_CORE = 3;
   }

   service SegmentRegistrationService {
       rpc SegmentsRegistration(SegmentsRegistrationRequest) returns (
         SegmentsRegistrationResponse) {}
   }

   message SegmentsRegistrationRequest {
       message Segments {
           repeated PathSegment segments = 1;
       }

       map<int32, Segments> segments = 1;
   }

   message SegmentsRegistrationResponse {}

• SegmentType: Specifies the type of the path segment to be registered. Currently, only the following type is used:¶

  • SEGMENT_TYPE_DOWN: Specifies a down segment.¶

• map<int32, Segments> segments: Represents a separate list of segments for each path segment type. The key is the integer representation of the corresponding SegmentType.¶

• SegmentRegistrationResponse: an empty message returned as an acknowledgement upon success.¶

4.4. Path MTU

SCION paths represent a sequence of ASes and inter-AS links; each with possibly different MTUs. As a result, the path MTU is the minimum of the MTUs of each inter-AS link and intra-AS networks it traverses. Such MTU information is disseminated during path construction:¶

• The MTU of each intra-AS network traversed (represented by the MTU field of the corresponding AS Entries (Section 2.2.1.4.2))¶

• The MTU of each inter-AS link or peering link (indicated by the ingress_mtu field of each Section 2.2.1.5 or the peer_mtu field of each Section 2.2.1.7 used)¶

Such information is then made available to endpoints during the path lookup process (See Section 5). SCION endpoints are oblivious to the topology of intermediate ASes, therefore when looking up a path they MUST assume that all hops are constrained by the intra-AS MTU of each AS traversed.¶

5.1. Lookup Process

An endpoint (source) that wants to start communication with another endpoint (destination) requires up to three path segments:¶

• An up segment to reach the core of the source ISD (only if the source endpoint is a non-core AS);¶

• a core segment to reach¶

  • another core AS in the source ISD, in case the destination AS is in the same source ISD, or;¶

  • a core AS in a remote ISD, if the destination AS is in another ISD, and;¶

• a down segment to reach the destination AS.¶

The actual number of required path segments depends on the location of the destination AS as well as on the availability of shortcuts and peering links. More information on combining and constructing paths is provided by [I-D.dekater-scion-dataplane].¶

The process to look up and fetch path segments consists of the following steps:¶

1. The source endpoint queries the Control Service in its own AS (i.e. the source AS) for the required segments by sending a SegmentsRequest. The Control Service has up segments stored in its path database and additionally checks if it has appropriate core segments and down segments stored as well - in this case it returns them immediately in a SegmentsResponse.¶

2. If there are no appropriate core segments and down segments, the Control Service in the source AS queries the Control Services of the reachable core ASes in the source ISD for core segments to core ASes in the destination ISD. To reach the core Control Services, the Control Service of the source AS uses the locally stored up segments.¶

3. The Control Service of the source AS combines up segments with the newly retrieved core segments. The Control Service then queries the Control Services of the remote core ASes in the destination ISD to fetch down segments to the destination AS. To reach the remote core ASes, the Control Service of the source AS uses the previously obtained and combined up segments and core segments.¶

4. The Control Service of the source AS returns all retrieved path segments to the source endpoint.¶

5. Once it has obtained all path segments, the source endpoint combines them into an end-to-end path in the data plane.¶

6. The destination endpoint, once it receives the first packet, MAY revert the path in the received packet in order to construct a response. This ensures that traffic flows on the same path bidirectionally.¶

Table 3 below shows which Control Service provides the source endpoint with which type of path segment.¶

5.2. Behavior of Actors in the Lookup Process

As described above, the source endpoint resolves paths with a sequence of segment requests to the Control Service of the source AS. The Control Service in the source AS either answers directly or forwards these requests to the responsible Control Services of core ASes. In SCION, the instances that handle these segment requests at the Control Services are called source AS segment-request handler and core AS segment-request handler, respectively.¶

This section specifies the behavior of the segment request handlers in the lookup process.¶

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

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

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

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

All other values are reserved for future use.¶

6.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 [I-D.dekater-scion-dataplane] section "SCION Header Specification/Pseudo Header for Upper-Layer Checksum".¶

6.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 [I-D.dekater-scion-dataplane] section "Deployment Considerations/MTU").¶

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

6.5. Error Messages

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

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

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

6.6. Informational Messages

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

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

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

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

6.7. SCMP Authentication

Authentication of SCMP packets is not specified here. In current deployments it is still experimental so endpoints should validate link down messages (External Interface Down (Section 6.5.2) and Internal Connectivity Down (Section 6.5.3)) with additional signals for reliable operations.¶

7.1. Manipulation of the Beaconing Process by a Core Adversary

The first risk to the beaconing process comes from an adversary controlling one or more core ASes in an ISD. If the adversary stops all core AS(es) within an ISD from propagating PCBs, the discovery of new paths will halt. In this case, downstream ASes will notice that PCBs are no longer being propagated, but all previously discovered and still valid paths remain usable for data plane forwarding until they expire. This is an unlikely scenario, as it would require compromise of all core ASes within an ISD.¶

7.2. Manipulation of the Beaconing Process by a Non-Core Adversary

This section examines several possible approaches that could be taken by an "ordinary" non-core adversary to manipulate the beaconing process in the SCION Control Plane. For each case it shows to what extent SCION's design can prevent the corresponding attack or help mitigate it.¶

7.3. Denial of Service Attacks

The beaconing process in the SCION Control Plane relies on control plane communication. ASes exchange control plane messages within each other when propagating PCBs to downstream neighbors, when registering PCBs as path segments, or during core path lookup. Volumetric DoS attacks, where attackers overload a link may make it difficult to exchange these messages.¶

SCION limits the impact of such attacks which aim to exhaust network bandwidth on links as ASes can switch to alternative paths that do not contain the congested links. Reflection-based attacks are also prevented as response packets are returned on the same path to the actual sender.¶

Other mechanisms are required to avoid transport protocol attacks where the attacker tries to exhaust the resources on a target server, such as for the Control Services, by opening many connections to this. The means to mitigate these kind of DoS attacks are basically the same as for the current Internet, e.g. filtering, geo-blocking or using cookies.¶

Thanks to its path awareness, SCION enables more fine-grained filtering mechanisms based on certain path properties. For example, control plane RPC methods that are available to endpoints within an AS are strictly separate from methods available to endpoints from other ASes. Specifically, expensive recursive path segment and trust material lookups are thus shielded from abuse by unauthorized entities.¶

For RPC methods exposed to other ASes, the Control Service implementation minimizes its attack surface by rejecting illegitimate callers based on ISD/AS, path type and length and any other available data points as soon as possible, i.e. immediately after determining the request type. For example:¶

• SegmentCreationService.Beacon can only be called by direct neighbors and thus calls from peers with a path length greater than one can immediately be discarded.¶

• SegmentRegistrationService.SegmentsRegistration can only be called from within the same ISD, thus the source address MUST match the local ISD and the number of path segments MUST be 1.¶

A combination of the mechanism above is used to prevent flooding attacks on the Control Service. In addition, the Control Service SHOULD be deployed in a distributed and replicated manner so that requests can be balanced and a single instance failure does not result in a complete failure of the control plane of a SCION AS.¶

9.1. Normative References

[Connect]

"Connect Protocol Reference", 2024, <https://connectrpc.com/docs/protocol/>.

[gRPC]

"gRPC, an open-source universal RPC framework", 2023, <https://grpc.io/>.

[I-D.dekater-scion-dataplane]

de Kater, C., Rustignoli, N., Hugly, J., and S. Hitz, "SCION Data Plane", Work in Progress, Internet-Draft, draft-dekater-scion-dataplane-03, 19 October 2024, <https://datatracker.ietf.org/doc/html/draft-dekater-scion-dataplane-03>.

[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-07, 19 October 2024, <https://datatracker.ietf.org/doc/html/draft-dekater-scion-pki-07>.

[proto3]

"Protocol Buffers Language Guide version 3", 2023, <https://protobuf.dev/programming-guides/proto3/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4632]

Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/rfc/rfc4632>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5952]

Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/rfc/rfc5952>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

9.2. Informative References

[BollRio-2000]

Bollobás, B. and O. Riordan, "The diameter of a scale-free random graph", n.d., <https://kam.mff.cuni.cz/~ksemweb/clanky/BollobasR-scale_free_random.pdf>.

[CHUAT22]

Chuat, L., Legner, M., Basin, D., Hausheer, D., Hitz, S., Mueller, P., and A. Perrig, "The Complete Guide to SCION", ISBN 978-3-031-05287-3, 2022, <https://doi.org/10.1007/978-3-031-05288-0>.

[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, 7 May 2024, <https://datatracker.ietf.org/doc/html/draft-dekater-panrg-scion-overview-06>.

[ISD-AS-assignments]

"SCION ISD and AS Assignments", 2024, <https://docs.anapaya.net/en/latest/resources/isd-as-assignments/>.

[RFC1122]

Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/rfc/rfc1122>.

[RFC4893]

Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, <https://www.rfc-editor.org/rfc/rfc4893>.

[RFC5398]

Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <https://www.rfc-editor.org/rfc/rfc5398>.

[RFC6996]

Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <https://www.rfc-editor.org/rfc/rfc6996>.

[RFC9217]

Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, <https://www.rfc-editor.org/rfc/rfc9217>.

[RFC9473]

Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path Properties", RFC 9473, DOI 10.17487/RFC9473, September 2023, <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", 2020, <https://ieeexplore.ieee.org/abstract/document/9259355>.

[SCMP]

Anapaya, ETH, and SCION, "SCMP Documentation", 2024, <https://docs.scion.org/en/latest/protocols/scmp.html>.

draft-dekater-scion-controlplane-07

• Moved SCMP specification from draft-dekater-scion-dataplane-03 to this document¶

draft-dekater-scion-controlplane-06

Major changes:¶

• New section: Path MTU -New section: Monitoring Considerations¶

• Completed description of Control Services gRPC API in appendix¶

Minor changes:¶

• Introduction: clarify goal of the document¶

• Clarify typical vs recommended-limits values for best PCB set size and for certificate validity duration.¶

• Clarify text representation of ISD-AS¶

• General rewording¶

• Added reference to SCIONLab as a testbed for implementors¶

• Introduced this change log¶

draft-dekater-scion-controlplane-05

Minor changes:¶

• Clarify beaconing fast retry at bootstrapping¶

draft-dekater-scion-controlplane-04

Major changes:¶

• Clarified selection of MAC including a default algorithm¶

• New section: PCB validity¶

• New section: configuration¶

• New section: Path Discovery Time and Scalability¶

• New section: Effects of Clock Inaccuracy¶

• New appendix: Control Service gRPC API¶

Minor changes:¶

• Introduction: Added overview of SCION components¶

• Clarified path reversibility, link types, interface IDs¶

• Fixed private AS range typo¶

• Clarified PCB selection policies and endpoint requirements¶

• Clarified PCB propagation¶

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

• Removed forward references¶

• Added RFC2119 compliant terminology¶