Internet DRAFT - draft-dekater-scion-controlplane

draft-dekater-scion-controlplane







Network Working Group                                        C. de Kater
Internet-Draft                                             N. Rustignoli
Intended status: Informational                         SCION Association
Expires: 26 August 2024                                          S. Hitz
                                                         Anapaya Systems
                                                        23 February 2024


                          SCION Control Plane
                  draft-dekater-scion-controlplane-02

Abstract

   This document describes the control 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 SCION-
   capable endpoints.  In fact, endpoints can choose between multiple
   path options, enabling the optimization of network paths.  The SCION
   control plane is responsible for discovering these paths and making
   them available to the endpoints.

   The main goal of SCION's control plane is to create and manage path
   segments, which can then be combined into forwarding paths to
   transmit packets in the data plane.  This document first discusses
   how path exploration is realized through beaconing and how path
   segments are created and registered.  Each SCION autonomous system
   (AS) can register segments according to its own policy - it is free
   to specify which path properties and algorithm(s) to use in the
   selection procedure.  The document then describes the path lookup
   process, where endpoints obtain path segments - a fundamental
   building block for the construction of end-to-end paths.

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-cp_I-D/draft-dekater-scion-
   controlplane.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-dekater-scion-
   controlplane/.

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






de Kater, et al.         Expires 26 August 2024                 [Page 1]

Internet-Draft                  SCION CP                   February 2024


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 26 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Conventions and Definitions . . . . . . . . . . . . . . .   6
     1.3.  Paths and Links . . . . . . . . . . . . . . . . . . . . .   6
     1.4.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .   7
       1.4.1.  Path Segments . . . . . . . . . . . . . . . . . . . .   9
     1.5.  Addressing  . . . . . . . . . . . . . . . . . . . . . . .  10
       1.5.1.  ISD Numbers . . . . . . . . . . . . . . . . . . . . .  10
       1.5.2.  SCION AS Numbers  . . . . . . . . . . . . . . . . . .  11
       1.5.3.  Wildcard Addressing . . . . . . . . . . . . . . . . .  12
     1.6.  Avoiding Circular Dependencies and Partitioning . . . . .  13
       1.6.1.  Partition and Healing . . . . . . . . . . . . . . . .  14
     1.7.  Communication Protocol  . . . . . . . . . . . . . . . . .  14
   2.  Path Exploration or Beaconing . . . . . . . . . . . . . . . .  14
     2.1.  Introduction and Overview . . . . . . . . . . . . . . . .  14
       2.1.1.  Peering Links . . . . . . . . . . . . . . . . . . . .  15
       2.1.2.  Extending a PCB . . . . . . . . . . . . . . . . . . .  15
       2.1.3.  PCB Propagation - Illustrated Examples  . . . . . . .  16



de Kater, et al.         Expires 26 August 2024                 [Page 2]

Internet-Draft                  SCION CP                   February 2024


     2.2.  Path-Segment Construction Beacons (PCBs)  . . . . . . . .  21
       2.2.1.  Components of a PCB in Message Format . . . . . . . .  21
       2.2.2.  PCB Extensions  . . . . . . . . . . . . . . . . . . .  33
     2.3.  Propagation of PCBs . . . . . . . . . . . . . . . . . . .  34
       2.3.1.  Selection of PCBs to Propagate  . . . . . . . . . . .  34
       2.3.2.  Propagation of Selected PCBs  . . . . . . . . . . . .  37
   3.  Registration of Path Segments . . . . . . . . . . . . . . . .  40
     3.1.  Intra-ISD Path-Segment Registration . . . . . . . . . . .  41
       3.1.1.  Terminating a PCB . . . . . . . . . . . . . . . . . .  41
       3.1.2.  Transforming a PCB into an Up-Segment . . . . . . . .  42
       3.1.3.  Transforming a PCB into a Down-Segment  . . . . . . .  42
     3.2.  Core Path-Segment Registration  . . . . . . . . . . . . .  43
     3.3.  Path-Segment Registration on Code-Level . . . . . . . . .  44
   4.  Path Lookup . . . . . . . . . . . . . . . . . . . . . . . . .  44
     4.1.  Lookup Process  . . . . . . . . . . . . . . . . . . . . .  45
       4.1.1.  Sequence of Lookup Requests . . . . . . . . . . . . .  46
       4.1.2.  Caching . . . . . . . . . . . . . . . . . . . . . . .  47
     4.2.  Behavior of Actors in the Lookup Process  . . . . . . . .  47
       4.2.1.  Use of Wildcard Addresses in the Lookup Process . . .  47
       4.2.2.  Segment-Request Handler of a Non-Core Source AS . . .  48
       4.2.3.  Segment-Request Handler of a Core AS  . . . . . . . .  49
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  50
     5.1.  Manipulation of the Beaconing Process by a Core
           Adversary . . . . . . . . . . . . . . . . . . . . . . . .  50
     5.2.  Manipulation of the Beaconing Process by a Non-Core
           Adversary . . . . . . . . . . . . . . . . . . . . . . . .  51
       5.2.1.  Path Hijacking through Interposition  . . . . . . . .  51
       5.2.2.  Creation of Spurious ASes and ISDs  . . . . . . . . .  52
       5.2.3.   Peering Link Misuse  . . . . . . . . . . . . . . . .  52
       5.2.4.  Manipulation of the Path-Selection Process  . . . . .  53
     5.3.  Denial of Service Attacks . . . . . . . . . . . . . . . .  54
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  55
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  55
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  55
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  56
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  57
   PCB Protobuf Messages - Full Example  . . . . . . . . . . . . . .  57
   Path-Lookup Examples  . . . . . . . . . . . . . . . . . . . . . .  59
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  63

1.  Introduction

   The SCION control plane is responsible for discovering path segments
   and making them available to endpoints.  This process includes path
   exploration, registration, and lookup.  This section explains the
   basic concepts of the control plane in SCION and introduces SCION's
   routing concept.




de Kater, et al.         Expires 26 August 2024                 [Page 3]

Internet-Draft                  SCION CP                   February 2024


   As SCION is an _inter-domain_ network architecture, it only deals
   with _inter_-domain routing.  One feature of SCION is the decoupling
   of inter-domain routing from endpoint addressing.  This Introduction
   section provides a description of the SCION addressing system in more
   detail.

   *Note:* It is assumed that readers of this draft are familiar with
   the basic concepts of the SCION next-generation inter-domain network
   architecture.  If not, please find more detailed information in the
   IETF Internet Drafts [I-D.scion-overview], [I-D.scion-components],
   and [I-D.scion-cppki], as well as in [CHUAT22], especially Chapter 2.
   A short description of the SCION basic terms and elements can be
   found in Section 1.1 below.

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 network nodes.  The control plane thus
   determines where traffic can be sent and deals with questions such as
   how paths are discovered, which paths exist, what quality individual
   links offer, etc.  Within a SCION AS, such functionalities are
   carried out by the control service.  Packet forwarding is instead a
   task pertaining to 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 endpoint of a SCION
   path.  For example, an endpoint can be a host as defined in
   [RFC1122], or a gateway bridging a SCION and an IP domain.  This
   definition is based on the definition in [RFC9473].




de Kater, et al.         Expires 26 August 2024                 [Page 4]

Internet-Draft                  SCION CP                   February 2024


   *Forwarding Path*: A forwarding path is a complete end-to-end path
   between two SCION hosts, which is used to transmit packets in the
   data plane and 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), info fields are used to
   create forwarding paths.

   *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 (i.e., 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.

   *Packet-Carried Forwarding State (PCFS)*: Rather than relying on
   costly inter-domain forwarding tables, SCION data packets contain all
   the necessary path information.  We refer to this property as packet-
   carried forwarding state or PCFS.

   *Path Segment*: Path segments are derived from path-segment
   construction beacons (PCBs) and registered at control services.  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.







de Kater, et al.         Expires 26 August 2024                 [Page 5]

Internet-Draft                  SCION CP                   February 2024


   *Path-Segment Construction Beacon (PCB)*: Core ASes 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.

   *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.  Within and between ISDs, SCION supports three
   types of links: (1) core links, (2) parent-child links, and (3)
   peering links.

   *  A _core_ link always connects two core ASes, which are either
      within the same or in a different ISD.  Core links can exist for
      various underlying business relationships, including provider-
      customer (where the customer pays the provider for traffic) and
      peering relationships.

   *  _Parent-child_ links create a hierarchy between the parent and the
      child.  ASes with a parent-child link typically have a provider-
      customer relationship.

   *  _Peering_ links exist between ASes with a (settlement-free or
      paid) peering relationship.  Peering links can only be used to
      reach destinations within or downstream of the peering AS.  They
      can be established between any two core or non-core ASes, and
      between core and non-core ASes.  Peering links can also cross ISD
      boundaries.




de Kater, et al.         Expires 26 August 2024                 [Page 6]

Internet-Draft                  SCION CP                   February 2024


   The following figure shows the three types of links for one small ISD
   with the two core ASes A and C, and the 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  )
      `---'           `---'

            Figure 1: The three types of SCION links in one ISD

   Each link connecting SCION routers is bidirectional and identified by
   its corresponding egress and ingress interface IDs.  These interface
   IDs only need to be unique within each AS.  Therefore, they can be
   chosen and encoded by each AS independently and without any need for
   coordination.

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 SCION isolation domain (ISD), which is called _intra_-ISD
   routing, and between ISDs, called _inter_-ISD routing.  Both levels
   use the so-called _path-segment construction beacons (PCBs)_ to
   explore network paths.  A PCB is initiated by a core AS and then
   disseminated either within an ISD to explore intra-ISD paths, or
   among core ASes, to explore core paths across different ISDs.

   The PCBs accumulate cryptographically protected path and forwarding
   information on AS-level, and store this information in the form of
   _hop fields_. Endpoints use information from these hop fields to



de Kater, et al.         Expires 26 August 2024                 [Page 7]

Internet-Draft                  SCION CP                   February 2024


   create end-to-end forwarding paths for data packets, who carry this
   information in their packet headers.  This concept is called _packet-
   carried forwarding state_. The concept also supports multi-path
   communication among endpoints.

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

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

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

   All processes operate concurrently.

   Figure 2 below shows the SCION routing processes and their relation
   to each other.

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

        Figure 2: SCION routing processes and their relation to each
                 other.  All processes operate concurrently





de Kater, et al.         Expires 26 August 2024                 [Page 8]

Internet-Draft                  SCION CP                   February 2024


   The *control service* is responsible for the path exploration and
   registration processes in the control plane.  It is the main control-
   plane infrastructure component within each SCION AS.  The control
   service of an AS has the following tasks:

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

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

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

   *Note:* The control service of an AS must not be confused with a
   border router.  The control service of a specific AS is part of the
   control plane and responsible for _finding and registering suitable
   paths_. It can be deployed anywhere inside the AS.  A border router
   belongs to the data plane; its main task is to _forward data
   packets_. Border routers are deployed at the edge of an AS.

1.4.1.  Path Segments

   As described previously, the main goal of SCION's control plane is to
   create and manage path segments, which can then be combined into
   forwarding paths to transmit packets in the data plane.  SCION
   distinguishes the following types of path segments:

   *  A path segment from a non-core AS to a core AS is an _up-segment_.

   *  A path segment from a core AS to a non-core AS is a _down-
      segment_.

   *  A path segment between core ASes is a _core-segment_.

   So each path segment either ends at a core AS, or starts at a core
   AS, or both.







de Kater, et al.         Expires 26 August 2024                 [Page 9]

Internet-Draft                  SCION CP                   February 2024


   *Note:* There are no SCION path segments that start and end at a non-
   core AS.  However, when combining path segments into an end-to-end
   SCION path, it is possible to use peering links.  For more
   information on SCION and peering links, see Section 2.

   All path segments are invertible: A core-segment can be used
   bidirectionally, and an up-segment can be converted into a down-
   segment, or vice versa, depending on the direction of the end-to-end
   path.  This means that all path segments can be used to send data
   traffic in both directions.

1.5.  Addressing

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

   However, the ISD-AS number is a SCION-specific number.  It consists
   of 64-bits, with the top 16 bits indicating the ISD, and the bottom
   48 bits indicating the AS.  The text representation uses a dash-
   separator between the ISD and AS numbers, for example: 4-ff00:1:f.
   This section provides more details about the numbering scheme for
   SCION ISD and AS numbers.

   *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.5.1.  ISD Numbers

   An ISD number is the 16-bit global identifier for an ISD.  It MUST be
   globally unique.  The following table gives an overview of the ISD
   number allocation.












de Kater, et al.         Expires 26 August 2024                [Page 10]

Internet-Draft                  SCION CP                   February 2024


     +==============+================================================+
     | ISD          | Description                                    |
     +==============+================================================+
     | 0            | The wildcard ISD.                              |
     +--------------+------------------------------------------------+
     | 1 - 15       | Reserved for documentation and sample code     |
     |              | (analogous to [RFC5398]).                      |
     +--------------+------------------------------------------------+
     | 16 - 63      | Private use (analogous to [RFC6996]).  Can be  |
     |              | used for testing and private deployments       |
     +--------------+------------------------------------------------+
     | 64 - 4094    | Public ISDs.  Should be allocated in ascending |
     |              | order, without gaps and "vanity" numbers.      |
     +--------------+------------------------------------------------+
     | 4095 - 65535 | Reserved for future use.                       |
     +--------------+------------------------------------------------+

                      Table 1: ISD number allocations

   Currently, ISD numbers are allocated by Anapaya, the Swiss-based
   provider of SCION-based networking software and solutions (see
   Anapaya ISD AS assignments
   (https://docs.anapaya.net/en/latest/resources/isd-as-assignments/)).

1.5.2.  SCION AS Numbers

   A SCION AS number is the 48-bit identifier for an AS.  Although they
   play a similar role, there is no relationship between SCION AS
   numbers and BGP ASNs as defined by RFC4893.  For historical reasons
   some SCION autonomous systems use a SCION AS number where the first
   16 bits are 0, and the remaining 32 bits are identical to their BGP
   ASN.  There is no technical requirement for such an equality.

1.5.2.1.  Text Representation

   The default text representation for SCION AS numbers is very similar
   to IPv6 (see [RFC5952]).  It uses a 16-bit colon-separated lower-case
   hex encoding with leading 0's omitted: 0:0:0 to ffff:ffff:ffff.

   In SCION, the following rules apply:

   *  The :: zero-compression feature of IPv6 is NOT allowed.  The
      feature has very limited use in a 48-bit address space and would
      only add more complexity.







de Kater, et al.         Expires 26 August 2024                [Page 11]

Internet-Draft                  SCION CP                   February 2024


   *  A range of AS numbers can be shortened with a notation similar to
      the one used for CIDR IP ranges ([RFC4632]).  For example, the
      range of the lowest 32-bit AS numbers (0-4294967295) can be
      represented as 0:0:0/16.

   For historical reasons, SCION AS numbers in the lower 32 bit range
   may also be represented as decimal for human readability.  For
   example, if a program receives the AS number 0:1:f, it may display
   the number as "65551".

1.5.2.2.  Special-Purpose SCION AS Numbers

    +===================+=============+===============================+
    | AS                | Size        | Description                   |
    +===================+=============+===============================+
    | 0:0:0             | 1           | The wildcard AS               |
    +-------------------+-------------+-------------------------------+
    | 0:0:1-0:ffff:ffff | ~4.3 bill.  | Public SCION AS numbers       |
    +-------------------+-------------+-------------------------------+
    | 1:0:0             | 1           | Reserved                      |
    +-------------------+-------------+-------------------------------+
    | 2:0:0/16          | ~4.3 bill.  | Additional public SCION AS    |
    |                   |             | numbers                       |
    +-------------------+-------------+-------------------------------+
    | ff00:0:0/32       | 65535       | Reserved for documentation    |
    |                   |             | and test/sample code          |
    |                   |             | (analogous to [RFC5398]).     |
    +-------------------+-------------+-------------------------------+
    | ff00:0:0/24       | ~16.8 mill. | Reserved for private use      |
    |                   |             | (analogous to [RFC6996]).     |
    |                   |             | These numbers can be used for |
    |                   |             | testing/private deployments.  |
    +-------------------+-------------+-------------------------------+
    | ffff:ffff:ffff    | 1           | Reserved                      |
    +-------------------+-------------+-------------------------------+

                       Table 2: AS number allocations

   The rest of the space is currently unallocated.

1.5.3.  Wildcard Addressing

   SCION allows endpoints to use wildcard addresses in the control-plane
   routing, to designate any core AS, e.g., to place requests for core-
   or down-segments during path lookup.  These wildcard addresses are of
   the form I-0, to designate any AS in ISD I.  Here, "0" is the
   wildcard for the AS.  For more information, see Section 4.2.1.




de Kater, et al.         Expires 26 August 2024                [Page 12]

Internet-Draft                  SCION CP                   February 2024


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 will be described in more detail in the SCION Data Plane
      specification (this document will be available later this year).

   *  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—i.e., the
      receiver of a packet can reverse the path in the packet header to
      send back a reply packet without having to perform a path lookup.

   *  Availability of certificates: In SCION, every entity is required
      to be in possession of all cryptographic material (including the
      ISD's Trust Root Configuration 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 necessary 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.scion-cppki].











de Kater, et al.         Expires 26 August 2024                [Page 13]

Internet-Draft                  SCION CP                   February 2024


1.6.1.  Partition and Healing

   Besides inter-dependencies, another threat to the Internet is network
   partition.  Partition 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: 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 could always switch to
   otherwise unused links.

   Recovering (also called healing) 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.

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

   *Note:* The details of how gRPC is mapped to the SCION data plane
   will be described in a separate document.

2.  Path Exploration or Beaconing

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_.
   This section gives a detailed explanation of the SCION beaconing
   process.

   In SCION, the _control service_ of each AS is responsible for the
   beaconing process.  The control service generates, receives, and
   propagates so-called _path-segment construction beacons (PCBs)_ on a
   regular basis, to iteratively construct path segments.  PCBs contain
   topology and authentication information, and can also include
   additional metadata that helps with path management and selection.
   The beaconing process itself is divided into routing processes on two
   levels, where _inter-ISD_ or core beaconing is based on the
   (selective) sending of PCBs without a defined direction, and _intra-
   ISD_ beaconing on top-to-bottom propagation.





de Kater, et al.         Expires 26 August 2024                [Page 14]

Internet-Draft                  SCION CP                   February 2024


   *  _Inter-ISD or core beaconing_ is the process of constructing path
      segments between core ASes in the same or in different ISDs.
      During core beaconing, the control service of a core AS either
      initiates PCBs or propagates PCBs received from neighboring core
      ASes to other neighboring core ASes.  Core beaconing is periodic;
      PCBs are sent over policy-compliant paths to discover multiple
      paths between any pair of core ASes.

   *  _Intra-ISD beaconing_ creates path segments from core ASes to non-
      core ASes.  For this, the control service of a core AS creates
      PCBs and sends them to the non-core child ASes (typically customer
      ASes).  The control service of a non-core child AS receives these
      PCBs and forwards them to its child ASes, and so on.  This
      procedure continues until the PCB reaches an AS without any
      customer (leaf AS).  As a result, all ASes within an ISD receive
      path segments to reach the core ASes of their ISD.

   On its way, a PCB accumulates cryptographically protected path- and
   forwarding information per traversed AS.  At every AS, metadata as
   well as information about the AS's ingress and egress interfaces are
   added to the PCB.

2.1.1.  Peering Links

   PCBs do not traverse peering links.  Instead, peering links are
   announced along with a regular path in a PCB.  If both ASes at either
   end of a peering link have registered path segments that include this
   specific peering link, then it is possible to use this peering link
   during segment combination to create the end-to-end path.

2.1.2.  Extending a PCB

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

   *  selects the best combinations of PCBs and interfaces connecting to
      a neighboring AS (i.e., a child AS or a core AS), and

   *  sends each selected PCB to the selected egress interface(s)
      associated with it.

   For every selected PCB and egress interface combination, the AS
   extends the PCB by adding a so-called _AS entry_ to the selected PCB.
   Such an AS entry includes a hop field that specifies the incoming
   (ingress) and outgoing (egress) interface for the packet forwarding
   through this AS, in the beaconing direction.  The AS entry can also
   contain peer entries.




de Kater, et al.         Expires 26 August 2024                [Page 15]

Internet-Draft                  SCION CP                   February 2024


   *  For the specification of one PCB, see Section 2.2

   *  For more details on selecting PCBs, see Section 2.3.1

   *  For more details on propagating PCBs, see Section 2.3.2

2.1.3.  PCB Propagation - Illustrated Examples

   The following three figures show how intra-ISD PCB propagation works,
   from the ISD's core AS down to child ASes.  For the sake of
   illustration, the interfaces of each AS are numbered with integer
   values.

   In Figure 3 below, core AS X sends the two different PCBs "a" and "b"
   via two different links to child AS Y: PCB "a" leaves core AS X via
   egress interface "2", whereas PCB "b" is sent over egress interface
   "1".  Core AS X adds the respective egress information to the PCBs
   when sending them off, as can be seen in the figure (the entries
   "_Core - Out:2_" and "_Core - Out:1_", respectively).

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

       Figure 3: Intra-ISD PCB propagation from the ISD core to child
                               ASes - Part 1














de Kater, et al.         Expires 26 August 2024                [Page 16]

Internet-Draft                  SCION CP                   February 2024


   AS Y receives the two PCBs "a" and "b" through two different
   (ingress) interfaces, namely "2" and "3", respectively (see Figure 4
   below).  Additionally, AS Y forwards to AS Z four PCBs that were
   previously sent by core AS X.  For this, AS Y uses the two different
   (egress) links "5" and "6".  AS Y extends the four PCBs with the
   corresponding ingress and egress interface information.  As can be
   seen in the figure, AS Y also has two peering links to its
   neighboring peers V and W, through the interfaces "1" and "4",
   respectively - AS Y includes this information in the PCBs, as well.
   Thus, each forwarded PCB cumulates path information on its way "down"
   from core AS X.

                           +-----+ |   | +-----+
                           |PCB a| |   | |PCB b|
                           +-----+ |   | +-----+
                              |    |   |    |
                              v    |   |    v
                                   v   v
                              +----#---#----+
                    .---.     |    2   3    |
                   (  V  )- --# 1           |
                    `---'     |     AS Y    |     .---.
                              |           4 #- --(  W  )
                              |             |     `---'
                              |    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     |

       Figure 4: Intra-ISD PCB propagation from the ISD core to child
                               ASes - Part 2



de Kater, et al.         Expires 26 August 2024                [Page 17]

Internet-Draft                  SCION CP                   February 2024


   The following figure shows how the four PCBs "c", "d", "e", and "f",
   coming from AS Y, are received by AS Z over two different links: PCBs
   "c" and "e" reach AS Z over ingress interface "5", whereas PCBs "d"
   and "f" enter AS Z via ingress interface "1".  Additionally, AS Z
   propagates PCBs "g", "h", "i", and "j" further down, all over the
   same link (egress interface "3").  AS Z extends the PCBs with the
   relevant information, so that each of these PCBs now includes AS hop
   entries from core AS X, AS Y, and 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

       Figure 5: Intra-ISD PCB propagation from the ISD core to child
                               ASes - Part 3




de Kater, et al.         Expires 26 August 2024                [Page 18]

Internet-Draft                  SCION CP                   February 2024


   Based on the figures above, one could say that a PCB represents a
   single path segment.  However, there is a difference between a PCB
   and a (registered) path segment.  A PCB is a so-called "travelling
   path segment" that accumulates AS entries when traversing the
   Internet.  A (registered) path segment, instead, is a "snapshot" of a
   travelling PCB at a given time T and from the vantage point of a
   particular AS A.  This is illustrated by Figure 6.  This figure shows
   several possible path segments to reach AS Z, based on the PCBs "g",
   "h", "i", and "j" from Figure 5 above.  It is up to AS Z to use all
   of these path segments or just a selection of them.









































de Kater, et al.         Expires 26 August 2024                [Page 19]

Internet-Draft                  SCION CP                   February 2024


                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

           Figure 6: Possible up- or down-segments for AS Z






de Kater, et al.         Expires 26 August 2024                [Page 20]

Internet-Draft                  SCION CP                   February 2024


2.2.  Path-Segment Construction Beacons (PCBs)

   This section provides a detailed specification of a single PCB and
   its message format.

   *Note:* The SCION open-source implementation makes use of Protobuf
   (Protocol Buffers), a free and open-source cross-platform data format
   developed by Google and used to serialize structured data.  The
   messages and remote procedure calls described below are in "proto3"
   language.  For more information on Protobuf, see the official
   "Protocol Buffers Documentation" (https://protobuf.dev/).

2.2.1.  Components of a PCB in Message Format

   Figure 7 graphically represents the PCB message format:

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



de Kater, et al.         Expires 26 August 2024                [Page 21]

Internet-Draft                  SCION CP                   February 2024


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

              Figure 7: Top-down composition of one PCB

   The following sections provide detailed specifications of the PCB
   messages, starting with the top-level message of one PCB, and then
   diving deeper into each of the PCB's message components.

   *Note:* For a full example of one PCB in the Protobuf message format,
   please see Appendix "PCB Protobuf Messages - Full Example".

2.2.1.1.  PCB Top-Level Message Format

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

   Each PCB MUST consists of at least:

   *  An information field with an identifier and a timestamp.

   *  Entries of all ASes on the path segment represented by this PCB.

   The following code block defines the PCB on top level in Protobuf
   message format.





de Kater, et al.         Expires 26 August 2024                [Page 22]

Internet-Draft                  SCION CP                   February 2024


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

   *  segment_info: This field is used as input for the PCB signature.
      It is the encoded version of the component SegmentInformation,
      which provides basic information about the PCB.  The
      SegmentInformation component is specified in detail in
      Section 2.2.1.2.

   *  as_entries: Contains the ASEntry component of all ASes on the path
      segment represented by this PCB.

      -  ASEntry: The ASEntry component contains the complete path
         information of a specific AS that is part of the path segment
         represented by the PCB.  The ASEntry component is specified in
         detail in Section 2.2.1.3.

2.2.1.2.  Segment Information

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

   Each PCB MUST include an information component with basic information
   about the PCB.

   In the Protobuf message format, the information component of a PCB is
   called the SegmentInformation message.  The following code block
   shows the Protobuf message definition for the SegmentInformation
   message.

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







de Kater, et al.         Expires 26 August 2024                [Page 23]

Internet-Draft                  SCION CP                   February 2024


   *  timestamp: The 32-bit timestamp indicates the creation time of
      this PCB.  It is set by the originating core AS.  The expiration
      time of the corresponding path segment is computed relative to
      this timestamp.  The timestamp is encoded as the number of seconds
      elapsed since the POSIX Epoch (1970-01-01 00:00:00 UTC).

   *  segment_id: The 16-bit identifier of this PCB and the
      corresponding path segment.  The segment ID is required for the
      computation of the message authentication code (MAC) of an AS's
      hop field.  The MAC is used for hop field verification in the data
      plane.  The originating core AS MUST fill this field with a
      cryptographically random number.

   *Note:* See Section 2.2.1.6 for more information on the hop field
   message format.  The SCION Data Plane Specification provides a
   detailed description of the computation of the MAC and the
   verification of the hop field in the data plane.

2.2.1.3.  AS Entry

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

   Beside the basic information component, each PCB MUST also contain
   the entries of all ASes included in the corresponding path segment.
   This means that the originating core AS MUST add its AS entry to each
   PCB it creates.  During the beaconing process, also each traversed AS
   MUST attach its AS entry to the PCB.

   One AS entry contains the complete hop information for this specific
   AS in this specific path segment.  It consists of a signed and an
   unsigned component.

   The code block below defines an AS entry ASEntry in Protobuf message
   format.







de Kater, et al.         Expires 26 August 2024                [Page 24]

Internet-Draft                  SCION CP                   February 2024


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

   It includes the following components:

   *  SignedMessage: The signed component of an AS entry.  For the
      specification of this part of the AS entry, see Section 2.2.1.4
      below.

   *  PathSegmentUnsignedExtensions: The unsigned and thus unprotected
      part of the AS entry.  These are extensions with metadata that
      need no explicit protection.

2.2.1.4.  AS Entry Signed Component

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

   Each AS entry of a PCB MUST include a signed component as well as a
   signature computed over the signed component.  Each AS entry MUST be
   signed with a private key that corresponds to the public key
   certified by the AS's certificate.

   This section specifies the signed component of an AS entry.  The
   signed component of an AS entry MUST include the following elements:

   *  a header,

   *  a body, and

   *  a signature.

   In the Protobuf message-format implementation, the signed component
   of an AS entry is specified by the SignedMessage.  It consists of a
   header-and-body part (header_and_body) and a raw signature
   (signature).  See also the code block below.





de Kater, et al.         Expires 26 August 2024                [Page 25]

Internet-Draft                  SCION CP                   February 2024


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

   The following code block shows the low-level representation of the
   HeaderAndBodyInternal message used for signature computation input.
   This message should not be used by external code.

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

   *  For the specification of the signed header, see Section 2.2.1.4.1.

   *  For the specification of the signed body, see Section 2.2.1.4.2.

   *  For the specification of the signature field, see
      Section 2.2.1.4.3.

2.2.1.4.1.  AS Entry Signed Header

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

   The header part defines metadata that is relevant to (the computation
   and verification of) the signature.  It MUST include at least the
   following metadata:

   *  The algorithm to compute the signature





de Kater, et al.         Expires 26 August 2024                [Page 26]

Internet-Draft                  SCION CP                   February 2024


   *  The identifier of the public key used to verify the signature
      (i.e., the public key certified by the AS's certificate)

   *  The ISD-AS number of the AS

   The following code block defines the signed header of an AS entry in
   Protobuf message format (called the Header message).

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

   *  signature_algorithm: Specifies the algorithm to compute the
      signature.

   *  verification_key_id: Holds the serialized data defined by the
      VerificationKeyID message type.  The VerificationKeyID message
      contains more information that is relevant to signing and
      verifying PCBs and other control-plane messages.  The
      VerificationKeyID message type includes the following fields (see
      also the above code block):

      -  isd_as: The ISD-AS number of the current AS.

      -  subject_key_id: Refers to the certificate that contains the
         public key needed to verify this PCB's signature.

      -  trc_base: Defines the _base_ number of the latest Trust Root
         Configuration (TRC) available to the signer at the time of the
         signature creation.

      -  trc_serial: Defines the _serial_ number of the latest TRC
         available to the signer at the time of the signature creation.





de Kater, et al.         Expires 26 August 2024                [Page 27]

Internet-Draft                  SCION CP                   February 2024


   *Note:* For more information on signing and verifying control-plane
   messages (such as PCBs), see the chapter Signing and Verifying
   Control-Plane Messages of the SCION Control-Plane PKI Specification
   [I-D.scion-cppki].  For more information on the TRC base and serial
   number, see the chapter Trust Root Configuration Specification of the
   SCION Control-Plane PKI Specification [I-D.scion-cppki].

   *  timestamp: Defines the signature creation timestamp.  This field
      is optional.

   *  metadata: Can be used to include arbitrary per-protocol metadata.
      This field is optional.

   *  associated_data_length: Specifies the length of associated data
      that is covered by the signature, but is not included in the
      header and body.  The value of this field is zero, if no
      associated data is covered by the signature.

2.2.1.4.2.  AS Entry Signed Body

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

   The body of an AS entry MUST consist of the signed component
   ASEntrySignedBody of all ASes in the path segment represented by the
   PCB, up until and including the current AS.

   The following code block defines the signed body of one AS entry in
   Protobuf message format (called the ASEntrySignedBody message).

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

   *  isd_as: The ISD-AS number of the AS that created this AS entry.



de Kater, et al.         Expires 26 August 2024                [Page 28]

Internet-Draft                  SCION CP                   February 2024


   *  next_isd_as: The ISD-AS number of the downstream AS to which the
      PCB should be forwarded.

   *  hop_entry: The hop entry (HopEntry) with the information required
      to forward this PCB through the current AS to the next AS.  This
      information is used in the data plane.  For a specification of the
      hop entry, see Section 2.2.1.5.

   *  peer_entries: The list of optional peer entries (PeerEntry).  For
      a specification of one peer entry, see Section 2.2.1.7.

   *  mtu: The size of the maximum transmission unit (MTU) within the
      current AS's network.

   *  extensions: List of (signed) extensions (optional).  PCB
      extensions defined here are part of the signed AS entry.  This
      field SHOULD therefore only contain extensions that include
      important metadata for which cryptographic protection is required.
      For more information on PCB extensions, see Section 2.2.2.

2.2.1.4.3.  AS Entry Signature

   Each AS entry is signed with a private key K_i that corresponds to
   the public key certified by the AS's certificate.  The signature
   Sig_i of an AS entry ASE_i is computed over the AS entry's signed
   component.  This is the input for the computation of the signature:

   *  The signed header and body of the current AS (header_and_body).

   *  The segment_info component of the current AS.  This is the encoded
      version of the SegmentInformation component containing basic
      information about the path segment represented by the PCB.  For
      the specification of SegmentInformation, see Section 2.2.1.2.

   *  The signed header_and_body/signature combination of each previous
      AS on this specific path segment.

   The signature Sig_i of an AS entry ASE_i is now computed as follows:

   Sig_i = K_i( SegInfo || ASE_0^(signed) || Sig_0 || ... ||
   ASE_(i-1)^(signed) || Sig_(i-1) || ASE_i^(signed) )

   The signature metadata minimally contains the ISD-AS number of the
   signing entity and the key identifier of the public key that should
   be used to verify the message.  For more information on signing and
   verifying control-plane messages, see the chapter "Signing and
   Verifying Control-Plane Messages" of the SCION Control-Plane PKI
   Specification [I-D.scion-cppki].



de Kater, et al.         Expires 26 August 2024                [Page 29]

Internet-Draft                  SCION CP                   February 2024


   The following code block shows how the signature input is defined in
   the SCION Protobuf implementation ("ps" stands for path segment).
   Note that the signature has a nested, onion-like structure.

   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

2.2.1.5.  Hop Entry

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

   Each body of an AS entry MUST contain exactly one hop entry
   component.  The hop entry component specifies forwarding information
   for the data plane.  The data plane requires this information to
   create the hop through the current AS (in the direction of the
   beaconing).

   The following code block defines the hop entry component HopEntry in
   Protobuf message format:

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

   *  hop_field: Contains the authenticated information about the
      ingress and egress interfaces in the direction of beaconing.  The
      data plane needs this information to forward packets through the
      current AS.  For further specifications, see Section 2.2.1.6.

   *  ingress_mtu: Specifies the maximum transmission unit (MTU) of the
      ingress interface of the current AS.





de Kater, et al.         Expires 26 August 2024                [Page 30]

Internet-Draft                  SCION CP                   February 2024


2.2.1.6.  Hop Field

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

   The hop field, part of both hop entries and peer entries, is used
   directly in the data plane for packet forwarding: It specifies the
   incoming and outgoing interfaces of the ASes on the forwarding path.
   To prevent forgery, this information is authenticated with a message
   authentication code (MAC).

   The following code block defines the hop field component HopField in
   Protobuf message format:

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

   *  ingress: The 16-bit ingress interface identifier (in the direction
      of the path construction, that is, in the direction of beaconing
      through the current AS).

   *Note:* For the AS that initiates the PCB, the ingress interface
   identifier MUST NOT be specified.  This initiating AS is a core AS.

   *  egress: The 16-bit egress interface identifier (in the direction
      of beaconing).

   *  exp_time: The 8-bit encoded expiration time of the hop field,
      indicating how long the hop field is valid.  This value is an
      offset relative to the PCB creation timestamp set in the PCB's
      segment information component (see also Section 2.2.1.2).  By
      combining these two values, the AS can compute the absolute
      expiration time of the hop field.  Data-plane packets that use the
      hop field after the expiration time MUST be dropped.





de Kater, et al.         Expires 26 August 2024                [Page 31]

Internet-Draft                  SCION CP                   February 2024


   *  mac: The message authentication code (MAC) used in the data plane
      to verify the hop field.  The SCION Data Plane Specification
      provides a detailed description of the computation of the MAC and
      the verification of the hop field in the data plane.

2.2.1.7.  Peer Entry

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

   By means of a peer entry, an AS can announce that it has a peering
   link to another AS.  A peer entry is an optional component of a PCB -
   it is only included if there is a peering link to a peer AS.

   The following code block defines the peer entry component PeerEntry
   in Protobuf message format:

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

   *  peer_isd_as: The ISD-AS number of the peer AS.  This number is
      used to match peering segments during path construction.

   *  peer_interface: The 16-bit interface identifier of the peering
      link on the peer AS side.  This identifier is used to match
      peering segments during path construction.

   *  peer_mtu: Specifies the maximum transmission unit MTU on the
      peering link.

   *  hop_field: Contains the authenticated information about the
      ingress and egress interfaces in the current AS (coming from the
      peering link, in the direction of beaconing - see also Figure 8).
      The data plane needs this information to forward packets through
      the current AS.  For further specifications, see Section 2.2.1.6.





de Kater, et al.         Expires 26 August 2024                [Page 32]

Internet-Draft                  SCION CP                   February 2024


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

      Figure 8: Peer entry information, in the direction of beaconing

2.2.2.  PCB Extensions

   In addition to basic routing information like hop entries and peer
   entries, PCBs can be used to communicate additional metadata, in its
   extensions.  Extensions can be signed and unsigned.  Signed
   extensions are protected by the AS signature, whereas unsigned
   extensions are not.

   On code-level and in Protobuf message format, extensions are
   specified as follows:

   *  Unsigned extensions PathSegmentUnsignedExtensions are part of the
      AS entry component (the ASEntry message, see also
      Section 2.2.1.3).

   *  Signed extensions PathSegmentExtensions are part of the signed
      body component of an AS entry (the ASEntrySignedBody message, see
      also Section 2.2.1.4.2).




de Kater, et al.         Expires 26 August 2024                [Page 33]

Internet-Draft                  SCION CP                   February 2024


   *Note:* SCION also supports so-called "detachable extensions".  The
   detachable extension itself is part of a PCB's unsigned extensions,
   but a cryptographic hash of the detachable extension data is added to
   the signed extensions.  Thus, a PCB with a detachable extension can
   be signed and verified without actually including the detachable
   extension in the signature.  This prevents a possible processing
   overhead caused by large cryptographically-protected extensions.

2.3.  Propagation of PCBs

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

2.3.1.  Selection of PCBs to Propagate

   As an AS receives a series of intra-ISD or core PCBs, it must select
   the PCBs it will use to continue beaconing.  Each AS must specify a
   local policy on the basis of which PCBs are evaluated, selected or
   eliminated.  The selection process can be based on _path_ properties
   (e.g., length, disjointness across different paths) as well as on
   _PCB_ properties (e.g., age, remaining lifetime of sent instances) -
   each AS is free to use those properties that suit the AS best.  The
   control service can then compute the overall quality of each
   candidate PCB based on these properties.  For this, the AS should use
   a selection algorithm or metric that reflects its needs and
   requirements and identifies the best PCBs or paths segments for this
   AS.

2.3.1.1.  Storing and Selecting Candidate PCBs

   When receiving a PCB, an AS first stores the PCB in a temporary
   storage for candidate PCBs, called the _beacon store_.

   PCBs are propagated in batches to each connected downstream AS at a
   fixed frequency, the _propagation interval_. At each propagation
   event, each AS selects a set of the best PCBs from the candidates in
   the beacon store, according to the AS's selection policy.  This set
   should have a fixed size, the _best PCBs set size_.

   *  The _best PCBs set size_ SHOULD be at most "50" (PCBs) for intra-
      ISD beaconing and at most "5" (PCBs) for core beaconing.

   *Note:* Depending on the selection criteria, it may be necessary to
   keep more candidate PCBs than the _best PCBs set size_ in the beacon
   store, to be able to determine the best set of PCBs.  If this is the
   case, an AS should have a suitable pre-selection of candidate PCBs in
   place, in order to keep the beacon store capacity limited.




de Kater, et al.         Expires 26 August 2024                [Page 34]

Internet-Draft                  SCION CP                   February 2024


   *  The _propagation interval_ SHOULD be at least "5" (seconds) for
      intra-ISD beaconing and at least "60" (seconds) for core
      beaconing.

   *Note:* Note that during bootstrapping and if the AS obtains a PCB
   containing a previously unknown path, the AS SHOULD forward the PCB
   immediately, to ensure quick connectivity establishment.

2.3.1.2.  Selection Policy Example

   Figure 9 below illustrates the selection of path segments in three
   networks.  Each network uses a different path property to select path
   segments.

   *  The network at the upper left considers the _path length_, which
      is here defined as the number of hops from the originator core AS
      to the local AS.  This number can give an indication of the path's
      latency.  Based on this criterion, the network will select the PCB
      representing path segment A-G (in direction of beaconing) to
      propagate.

   *  The network at the upper right uses _peering links_ as the
      selection criterion, that is, the number of different peering ASes
      from all non-core ASes on the PCB or path segment: A greater
      number of peering ASes increases the likelihood of finding a
      shortcut on the path segment.  Based on this criterion, the
      network will select the PCB representing path segment B-E-I-L (in
      direction of beaconing) to propagate.

   *  The lower network selects PCBs based on _disjointness_. The
      disjointness of a PCB is calculated relative to the PCBs that have
      been previously sent.  Paths can be either AS-disjoint or link-
      disjoint.  AS-disjoint paths have no common upstream/core AS for
      the current AS, whereas link-disjoint paths do not share any AS-
      to-AS link.  Depending on the objective of the AS, both criteria
      can be used: AS-disjointness allows path diversity in the event
      that an AS becomes unresponsive, and link-disjointness provides
      resilience in case of link failure.  Based on the disjointness
      criterion, the network will select the PCBs representing the path
      segments A-D-G-H-J and C-E-F-I-J (in direction of beaconing) to
      propagate.

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

     ISD A: Path Length                 ISD B: Peering Links
  +----------------------+          +---------------------------+
  |      ISD Core        |          |        ISD Core           |



de Kater, et al.         Expires 26 August 2024                [Page 35]

Internet-Draft                  SCION CP                   February 2024


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



de Kater, et al.         Expires 26 August 2024                [Page 36]

Internet-Draft                  SCION CP                   February 2024


  (   H  *----*   #------#   I   )
   `---*-'                `-#---'
       |                    |
       |       .---.        |
       *------*  J  #-------#
               `---'

     Figure 9: Example networks to illustrate path-segment selection
                   based on different path properties.

2.3.2.  Propagation of Selected PCBs

   As mentioned above, once per _propagation period_ (determined by each
   AS), an AS propagates selected PCBs to its neighboring ASes.  This
   happens on the level of both intra-ISD beaconing and core beaconing.
   This section describes both processes in more detail.

   To bootstrap the initial communication with a neighboring beacon
   service, ASes use so-called one-hop paths.  This special kind of path
   handles beaconing between neighboring ASes for which no forwarding
   path may be available yet.  In fact, it is the task of beaconing to
   discover such forwarding paths.  The purpose of one-hop paths is thus
   to break this circular dependency.  The One-Hop Path Type will be
   described in more detail in the SCION Data Plane specification.

2.3.2.1.  Propagation - First Steps

   The following first steps of the propagation procedure are the same
   for both intra-ISD and core beaconing:

   1.  Upon receiving a PCB, the control service of an AS verifies the
       structure and all signatures on the PCB.
       *Note:* The PCB contains the version numbers of the trust root
       configuration(s) (TRC) and certificate(s) that must be used to
       verify its signatures.  This enables the control service to check
       whether it has the relevant TRC(s) and certificate(s); if not,
       they can be requested from the control service of the sending AS.

   2.  As core beaconing is based on sending PCBs without a defined
       direction, it is necessary to avoid loops during path creation.
       The control service of core ASes MUST therefore check whether the
       PCB includes duplicate hop entries created by the core AS itself
       or by other ASes.  If so, the PCB MUST be discarded in order to
       avoid loops.  Additionally, core ASes could forbid, that is, not
       propagate, beacons containing path segments that traverse the
       same ISD more than once. *Note:* Where loops must always be
       avoided, it is a policy decision to forbid ISD double-crossing.
       It can be legitimate to cross the same ISD multiple times: For



de Kater, et al.         Expires 26 August 2024                [Page 37]

Internet-Draft                  SCION CP                   February 2024


       example, if the ISD spans a large geographical area, a path
       transiting another ISD may constitute a shortcut.  However, it is
       up to each core AS to decide whether it wants to allow this.

   3.  If the PCB verification is successful, the control service
       decides whether to store the PCB as a candidate for propagation
       based on selection criteria and polices specific for each AS.
       For more information on the selection process, see Section 2.3.1.

2.3.2.2.  Propagation of PCBs in Intra-ISD Beaconing

   The propagation process in intra-ISD beaconing includes the following
   steps:

   1.  From the candidate PCBs stored in the beacon store, the control
       service of an AS selects the best PCBs to propagate to its
       downstream neighboring ASes, based on a selection algorithm
       specific for this AS.

   2.  The control service adds a new AS entry to every selected PCB.
       This AS entry MUST at least include:

       *  The ingress interface to this AS, in the hop field component.

       *  The egress interface to the neighboring AS, also in the hop
          field component.

       *  The ISD_AS number of the next AS, in the signed body component
          of the AS entry.

       *  If the AS has peering links, the control service should add
          corresponding peer entry components to the signed body of the
          AS entry; one peer entry component for each peering link that
          the AS wants to advertise.  The hop field component of each
          added peer entry MUST have a specified egress interface.

   3.  The control service MUST now sign each selected, extended PCB and
       append the computed signature.

   4.  As a final step, the control service propagates each extended PCB
       to the correct neighboring ASes, by invoking the
       SegmentCreationService.Beacon remote procedure call (RPC) in the
       control services of the neighboring ASes (see also
       Section 2.3.2.4).

   *Note:*





de Kater, et al.         Expires 26 August 2024                [Page 38]

Internet-Draft                  SCION CP                   February 2024


   *  For more information on the signed body component of an AS entry,
      see Section 2.2.1.4.2.

   *  For more information on a peer entry, see Section 2.2.1.7.

   *  For more information on the hop field component, see
      Section 2.2.1.6.

   *  For more information on signing an AS entry, see
      Section 2.2.1.4.3.

2.3.2.3.  Propagation of PCBs in Core Beaconing

   The propagation process in core beaconing includes the following
   steps:

   1.  The core control service selects the best PCBs to forward to
       neighboring core ASes observed so far.

   2.  The service adds a new AS entry to every selected PCB.  This AS
       entry MUST at least include:

       *  The egress interface to the neighboring core AS, in the hop
          field component.

       *  The ISD_AS number of the neighboring core AS, in the signed
          body component of the AS entry.

   3.  The core control service MUST now sign the extended PCBs and
       append the computed signature.

   4.  As a final step, the service propagates the extended PCBs to the
       neighboring core ASes, by invoking the
       SegmentCreationService.Beacon remote procedure call (RPC) in the
       control services of the neighboring core ASes (see also
       Section 2.3.2.4).

2.3.2.4.  Propagation of PCBs in Protobuf Message Format

   The last step of the above described core and intra-ISD propagation
   procedures is implemented as follows in Protobuf message format:










de Kater, et al.         Expires 26 August 2024                [Page 39]

Internet-Draft                  SCION CP                   February 2024


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

      message BeaconRequest {
          PathSegment segment = 1;
      }

      message BeaconResponse {}

   The propagation procedure includes the following elements:

   *  SegmentCreationService: Specifies the service via which the
      extended PCB is propagated to the control service of the
      neighboring AS.

      -  Beacon: Specifies the method that calls the control service at
         the neighboring AS in order to propagate the extended PCB.

   *  BeaconRequest: Specifies the request message sent by the Beacon
      method to the control service of the neighboring AS.  It contains
      the following element:

      -  PathSegment: Specifies the path segment to propagate to the
         neighboring AS.  For more information on the Protobuf message
         type PathSegment, see Section 2.2.1.1.

   *  BeaconResponse: Specifies the response message from the
      neighboring AS.

3.  Registration of Path Segments

   *Path registration* is the process where an AS transforms selected
   PCBs into path segments, and adds these segments to the relevant path
   databases, thus making them available to other ASes.

   As mentioned previously, a non-core AS typically receives several
   PCBs representing several path segments to the core ASes of the ISD
   the AS belongs to.  Out of these PCBs, the non-core AS selects those
   down-path segments through which it wants to be reached, based on AS-
   specific selection criteria.  The next step is to register the
   selected down-segments with the control service of the relevant core
   ASes, according to a process called _intra-ISD path-segment
   registration_. As a result, a core AS's control service contains all
   intra-ISD path segments registered by the non-core ASes of its ISD.
   In addition, each core AS control service also stores preferred core-
   path segments to other core ASes, in the _core-segment registration_
   process.  Both processes are described below.



de Kater, et al.         Expires 26 August 2024                [Page 40]

Internet-Draft                  SCION CP                   February 2024


3.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- and down-segments do not have to be equal.  An AS may want to
   communicate with core ASes via one or more up-segments that differ
   from the down-segment(s) through which it wants to be reached.
   Therefore, an AS can define different selection policies for the up-
   and down-segment sets.  Also, the processes of transforming a PCB in
   an up-segment or a down-segment differ slightly.  Both processes are
   described below.

3.1.1.  Terminating a PCB

   Both the up- and down-segments end at the AS.  One could therefore
   say that by transforming a PCB into a path segment, an AS
   "terminates" the PCB for this AS ingress interface and at this moment
   in time.

   The control service of a non-core AS must perform the following steps
   to "terminate" a PCB:

   1.  The control service adds a new AS entry to the PCB.  This new AS
       entry MUST be defined as follows:

       *  The next AS MUST NOT be specified.

          -  In Protobuf message format, this means that the value of
             the next_isd_as field in the ASEntrySignedBody component
             MUST be "0".

       *  The egress interface in the hop field component MUST NOT be
          specified.

          -  In Protobuf message format, this means that the value of
             the egress field in the HopField component MUST be "0".








de Kater, et al.         Expires 26 August 2024                [Page 41]

Internet-Draft                  SCION CP                   February 2024


   2.  If the AS has peering links, the control service should add
       corresponding peer entry components to the signed body of the AS
       entry - one peer entry component for each peering link that the
       AS wants to advertise.  The egress interface ID in the hop field
       component of each added peer entry MUST NOT be specified.

       *  In Protobuf message format, this means that the value of the
          egress field in the HopField component MUST be "0".

   3.  As a last step, the control service MUST sign the modified PCB
       and append the computed signature.

   *Note:*

   *  For more information on the signed body component of an AS entry,
      see Section 2.2.1.4.2.

   *  For more information on a peer entry, see Section 2.2.1.7.

   *  For more information on the hop field component, see
      Section 2.2.1.6.

   *  For more information on signing an AS entry, see
      Section 2.2.1.4.3.

3.1.2.  Transforming a PCB into an Up-Segment

   Every registration period, the control service of a non-core AS
   performs the following steps to transform PCBs into up-segments:

   1.  The control service selects the PCBs that it wants to transform
       into up-segments from the candidate PCBs in the beacon store.

   2.  The control service "terminates" the selected PCBs by performing
       the steps described in Section 3.1.1.  From this moment on, the
       modified PCBs are called *up-segments*.

   3.  The control service now adds the newly created up-segments to its
       own path database.

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

3.1.3.  Transforming a PCB into a Down-Segment

   Every registration period, the control service of a non-core AS
   performs the following steps to transform PCBs into down-segments:




de Kater, et al.         Expires 26 August 2024                [Page 42]

Internet-Draft                  SCION CP                   February 2024


   1.  The control service selects the PCBs that it wants to transform
       into down-segments from the candidate PCBs in the beacon store.

   2.  The control service "terminates" the selected PCBs by performing
       the steps described in Section 3.1.1.  From this moment on, the
       modified PCBs are called *down-segments*.

   3.  The control service now registers the newly created down-segments
       with the control services of the core ASes that originated the
       corresponding PCBs.  This is done by invoking the
       SegmentRegistrationService.SegmentsRegistration remote procedure
       call (RPC) in the control services of the relevant core ASes (see
       also Section 3.3).

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

3.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 3.1.1.  From this
       moment on, the modified PCBs are called *core-segments*.

   3.  As a final step, 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.









de Kater, et al.         Expires 26 August 2024                [Page 43]

Internet-Draft                  SCION CP                   February 2024


3.3.  Path-Segment Registration on Code-Level

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

4.  Path Lookup

   The _path lookup_ is a fundamental building block of SCION's path
   management, as it enables endpoints to obtain path segments found
   during path exploration and registered during path registration.
   This allows the endpoints to construct end-to-end paths from the set
   of possible path segments returned by the path lookup process.  The
   lookup of paths still happens in the control plane, whereas the
   construction of the actual end-to-end paths happens in the data
   plane.




de Kater, et al.         Expires 26 August 2024                [Page 44]

Internet-Draft                  SCION CP                   February 2024


4.1.  Lookup Process

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

   *  An up-path segment to reach the core of the source ISD (only if
      the source endpoint is a non-core AS),

   *  a core-path segment to reach

      -  another core AS in the source ISD, in case the destination AS
         is in the same source ISD, or

      -  a core AS in a remote ISD, if the destination AS is in another
         ISD, and

   *  a down-path segment to reach the destination AS.

   *Note:* The actual number of required path segments depends on the
   location of the destination AS as well as on the availability of
   shortcuts and peering links.  More information on combining and
   constructing paths will be provided by the SCION Data Plane
   Specification document.

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

   1.  First, the source endpoint queries the control service in its own
       AS (i.e., the source AS) for the required segments.  The control
       service has up-path segments stored in its path database.
       Additionally, the control service checks if it has appropriate
       core- and down-path segments in store as well; in this case it
       returns them immediately.

   2.  If there are no appropriate core-segments and down-segments, the
       control service in the source AS queries the control services of
       the reachable core ASes in the source ISD, for core-path segments
       to core ASes in the destination ISD (which is either the own or a
       remote ISD).  To reach the core control services, the control
       service of the source AS uses the locally stored up-path
       segments.










de Kater, et al.         Expires 26 August 2024                [Page 45]

Internet-Draft                  SCION CP                   February 2024


   3.  Next, the control service of the source AS combines up-path
       segments with the newly retrieved core-path segments.  The
       control service then queries the control services of the remote
       core ASes in the destination ISD, to fetch down-path segments to
       the destination AS.  To reach the remote core ASes, the control
       service of the source AS uses the previously obtained and
       combined up- and core segments.

   4.  Finally, the control service of the source AS returns all
       retrieved path segments to the source endpoint.

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

   Table 3 below shows which control service provides the source
   endpoint with which type of path segment.

      +==============+=============================================+
      | Segment Type | Responsible control service(s)              |
      +==============+=============================================+
      | Up-segment   | Control service of the source AS            |
      +--------------+---------------------------------------------+
      | Core-segment | Control service of core ASes in source ISD  |
      +--------------+---------------------------------------------+
      | Down-segment | Control service of core ASes in destination |
      |              | ISD (either the local ISD or a remote ISD)  |
      +--------------+---------------------------------------------+

        Table 3: Control services responsible for different types
                             of path segments

4.1.1.  Sequence of Lookup Requests

   The overall sequence of requests to resolve a path should be as
   follows:

   1.  Request up-segments for the source endpoint at the control
       service of the source AS.

   2.  Request core-segments, which start at the core ASes that are
       reachable with up-segments, and end at the core ASes in the
       destination ISD.  If the destination ISD coincides with the
       source ISD, this step requests core segments to core ASes that
       the source endpoint cannot directly reach with an up-segment.

   3.  Request down-segments starting at core ASes in the destination
       ISD.




de Kater, et al.         Expires 26 August 2024                [Page 46]

Internet-Draft                  SCION CP                   February 2024


4.1.2.  Caching

   For the sake of efficiency, the control service of the source AS
   should cache each returned path segment request.  Caching ensures
   that path lookups are fast for frequently used destinations.  The use
   of caching is also essential to ensure that the path-lookup process
   is scalable and can be performed with low latency.

   In general, to improve overall efficiency, the control services of
   all ASes should do the following:

   *  Cache the returned path segments.

   *  Send requests in parallel when requesting path segments from other
      control services.

4.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 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.  First, the use of wildcards in the lookup process is
   briefly addressed.

4.2.1.  Use of Wildcard Addresses in the Lookup Process

   Endpoints can use wildcard addresses to designate any core AS in
   path-segment requests.  The segment-request handlers must expand
   these wildcard addresses and translate them into one or more actual
   addresses.  Table 4 below shows who is responsible for what.

   *Note:* For general information on the use of wildcard addresses in
   SCION, see Section 1.5.3.













de Kater, et al.         Expires 26 August 2024                [Page 47]

Internet-Draft                  SCION CP                   February 2024


    +==============+==================+=============+=================+
    | Segment      | Wildcard         | Expanded/   | Translated Into |
    | Request      | Represents       | Translated  |                 |
    |              |                  | By          |                 |
    +==============+==================+=============+=================+
    | Up-segment   | "Destination"    | Control     | Actual address  |
    |              | core AS (where   | service of  | destination     |
    |              | up-segment ends) | the _source | core AS in      |
    |              |                  | AS_         | source ISD      |
    +--------------+------------------+-------------+-----------------+
    | Core-segment | Source core AS   | Control     | Actual address  |
    |              | (where core-     | service of  | source core AS  |
    |              | segment          | the _source | in source ISD   |
    |              | starts)^1        | AS_         |                 |
    +--------------+------------------+-------------+-----------------+
    | Core-segment | Destination core | Control     | Actual address  |
    |              | AS (where core-  | service of  | destination     |
    |              | segment ends)    | the _source | core AS in      |
    |              |                  | core AS_    | destination ISD |
    +--------------+------------------+-------------+-----------------+
    | Down-segment | "Source" core AS | Control     | Actual address  |
    |              | (where down-     | service of  | source core AS  |
    |              | segment          | the _source | in destination  |
    |              | starts)^2        | AS_         | ISD             |
    +--------------+------------------+-------------+-----------------+

            Table 4: Use of wildcards in path segments requests

   1) Includes all core ASes for which an up-segment from the source AS
   exists.
   2) Includes all core ASes in destination ISD with a down-segment to
   destination AS.

4.2.2.  Segment-Request Handler of a Non-Core Source AS

   When the segment-request handler of the control service of a _non-
   core_ source AS receives a path segment request, it MUST proceed as
   follows:

   1.  Determine the requested segment type.

   2.  In the case of an up-segment request, look up matching up-
       segments in the path database and return them.

   3.  In the case of a core-segment request from a source core AS to a
       destination core AS:





de Kater, et al.         Expires 26 August 2024                [Page 48]

Internet-Draft                  SCION CP                   February 2024


       *  Expand the source wildcard into separate requests for each
          reachable core AS in the source ISD.

       *  For each core-segment request,

          -  If possible, return matching core-segments from cache;

          -  otherwise, request the core-segments from the control
             services of each reachable core AS at the source (start) of
             the core-segment.  Add the retrieved core-segments to the
             cache.

   4.  In the case of a down-segment request:

       *  Expand the source wildcard into separate requests for every
          core AS in the destination ISD (destination ISD refers to the
          ISD to which the destination endpoint belongs).

       *  For each segment request,

          -  If possible, return matching down-segments from cache;

          -  otherwise, request the down-segment from the control
             services of the core ASes at the source (start) of the
             down-segment.  Sending the request may require looking up
             core-segments to the source core AS of the down-segment.
             Add the retrieved down-segments to the cache.

4.2.3.  Segment-Request Handler of a Core AS

   When the segment-request handler of a _core AS_ control service
   receives a path segment request, it MUST proceed as follows:

   1.  Validate the request:

       *  The source of the path segment must be this core AS.

       *  The request must either be

          -  for a core-segment to a core AS in this ISD or another ISD,
             or

          -  for a down-segment to an AS in this ISD.

   2.  If the destination is a core or wildcard address, then load
       matching core-segments from the path database and return.





de Kater, et al.         Expires 26 August 2024                [Page 49]

Internet-Draft                  SCION CP                   February 2024


   3.  Otherwise, load the matching down-segments from the path database
       and return.

   Appendix "Path-Lookup Examples" shows by means of an illustration how
   the lookup of path segments in SCION works.

5.  Security Considerations

   As described previously, the goal of SCION’s beaconing process in the
   control plane is to securely discover and disseminate paths between
   any two ASes.  This section describes security considerations for
   SCION's control plane, that focuses on _inter_-domain routing.  SCION
   does not provide intra-domain routing, nor does it provide end-to-end
   payload encryption.  These topics lie therefore outside the scope of
   this section.

   *Note:* This section only discusses SCION control plane- and routing-
   specific security considerations.  For security considerations
   related to the SCION control-plane PKI, see [I-D.scion-cppki].
   [I-D.scion-dp] includes security considerations that concern the
   SCION data plane and data forwarding.

   This section focuses on three kinds of security risks in the control
   plane.  The first risk is when an adversary controls one or all core
   ASes of an ISD and tries to manipulate the beaconing process from the
   top down (see Section 5.1).  Also "ordinary" (non-core) adversaries
   that try to manipulate the beaconing process pose a risk to the
   control plane (see Section 5.2).  The third kind of security risks
   are Denial of Services (DoS) attacks, where attackers overload
   different parts of the infrastructure (see Section 5.3).

5.1.  Manipulation of the Beaconing Process by a Core Adversary

   The first kind of 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 halts.  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.










de Kater, et al.         Expires 26 August 2024                [Page 50]

Internet-Draft                  SCION CP                   February 2024


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

   This section examines several possible approaches open to an
   "ordinary" non-core adversary to manipulate the beaconing process in
   the SCION control plane, and shows for each case to what extent
   SCION's design can prevent the corresponding attack or help to
   mitigate it.

   *  Path hijacking through interposition (see Section 5.2.1)

   *  Creation of spurious ASes and ISDs (see Section 5.2.2)

   *  Peering link misuse (see Section 5.2.3)

   *  Manipulation of the path selection process (see Section 5.2.4)

5.2.1.  Path Hijacking through Interposition

   An malicious AS M might try to manipulate the beaconing process
   between two neighbor ASes A and B, with the goal to hijack traffic to
   flow via M.  If M can interpose itself on the path between A and B,
   then it could attempt several potential attacks:

   *  The adversary M could intercept and disseminate a PCB on its way
      from A to the neighboring AS B, and inject its own AS entry into
      the PCB toward downstream ASes.

   *  The adversary could modify the hop fields of an already existing
      path, in order to insert its own AS in the path.

   *  The adversary could fully block traffic between AS A and AS B, in
      order to force traffic redirection through an alternate path that
      includes its own AS.

   The first type of attack is detectable and blocked by downstream ASes
   (e.g.  B), because a PCB disseminated by AS A towards AS B contains
   the "Next ISD AS" field in the entry of AS A, pointing to AS B, and
   protected by A's signature.  If M manipulates the PCB while in flight
   from A to B, then verification of the manipulated inbound PCBs will
   fail at AS B, as the adversary's PCBs cannot contain A's correct
   signature.  The second type of attack is made impossible by the hop
   field's MAC, which protects the hop field's integrity and chains it
   with the previous hop fields on the path.  The third type of attack
   generally cannot be prevented, however the alternate path would be
   immediately visible to endpoints, as traffic must include hop fields
   from AS M.





de Kater, et al.         Expires 26 August 2024                [Page 51]

Internet-Draft                  SCION CP                   February 2024


5.2.2.  Creation of Spurious ASes and ISDs

   An alternative scenario is when an adversary tries to introduce and
   spoof a nonexistent ASes.  This would enable the adversary to send
   traffic with the spoofed AS as a source, allowing the adversary to
   complicate the detection of its attack and to plausibly deny the
   misbehavior.

   However, spoofing a new AS requires a registration of that AS with
   the ISD core to obtain a valid AS certificate; otherwise the
   adversary cannot construct valid PCBs.  As this registration includes
   a thorough check and authentication by a CA, this cannot be done
   stealthily, which defeats the original purpose.

   Similarly to creating a fake AS, an adversary could try to introduce
   a new, malicious ISD.  This involves the generation of its own TRC,
   finding core ASes to peer with, and convincing other ISDs of its
   legitimacy to accept the new TRC.  Although this setup is not
   entirely impossible, it requires substantial time and effort, and may
   need the involvement of more than one malicious entity.  Here, the
   "costs" of setting up the fake ISD may outweigh the benefits.

5.2.3.   Peering Link Misuse

   The misuse of a peering link by an adversary represents another type
   of attack.  Consider the case where AS A wants to share its peering
   link only with one of its downstream neighbors, AS B, and therefore
   selectively includes the peering link only in PCBs sent to B.  An
   adversary may now try to gain access to this peering link by
   prepending the relevant PCBs to its own path.  For this, the
   adversary needs to be able to (1) eavesdrop on the link from A to B,
   and (2) obtain the necessary hop fields by querying a control service
   and extracting the hop fields from registered paths.

   Even if an adversary succeeds in misusing a peering link as described
   above, SCION is able to mitigate this kind of attack: Each AS
   includes an egress interface as well as specific “next hop”
   information to the PCB before disseminating it further downstream.
   If a malicious entity tries to misuse a stolen PCB by adding it to
   its own segments, verification will fail upstream as the egress
   interface mismatches.  Therefore, the peering link can only be used
   by the intended AS.









de Kater, et al.         Expires 26 August 2024                [Page 52]

Internet-Draft                  SCION CP                   February 2024


5.2.4.  Manipulation of the Path-Selection Process

   Endpoint path control is one of the main benefits of SCION compared
   to the current Internet, as SCION endpoints can select inter-domain
   forwarding paths for each packet.  However, with the benefits of path
   selection comes the risk of endpoints selecting non-optimal paths.
   This section discusses some mechanisms with which an adversary can
   attempt to trick endpoints downstream (in the direction of beaconing)
   into choosing non-optimal paths.  The goal of such attacks is to make
   paths that are controlled by the adversary more attractive than other
   available paths.

   In SCION, overall path selection is the result of three steps.
   First, each AS selects which PCBs are further forwarded to its
   neighbors.  Second, each AS chooses the paths it wants to register at
   the local control service (as up-segments) and at the core control
   service (as down-segments).  Third, the endpoint performs path
   selection among all available paths resulting from a path lookup
   process.  The following text describes attacks that aim at
   influencing the path-selection process.

   These attacks are only successful if the adversary is located within
   the same ISD and upstream relative to the victim AS.  It is not
   possible to attract traffic away from the core as traffic travels
   upstream towards the core.  Furthermore, the attack may either be
   discovered downstream (e.g., by seeing large numbers of paths
   becoming available), or during path registrations.  After detection,
   non-core ASes will be able to identify paths traversing the adversary
   AS and avoid these paths.

   *Announcing Large Numbers of Path Segments*
   This attack is possible if the adversary controls multiple (at least
   two) ASes.  The adversary can create a large number of links between
   the ASes under its control, which do not necessarily correspond to
   physical links.  This allows the adversary to multiply the number of
   PCBs forwarded to its downstream neighbor ASes.  This in turn
   increases the chance that one or several of these forwarded PCBs are
   selected by the downstream ASes.

   In general, the number of PCBs that an adversary can announce this
   way scales exponentially with the number of consecutive ASes the
   adversary controls.  However, this also decreases their chance of
   being chosen by a downstream AS for PCB dissemination or by an
   endpoint for path construction, as these relatively long paths have
   to compete with other, shorter paths.  Furthermore, both endpoints
   and downstream ASes can detect poorer quality paths in the data plane
   and switch to better paths.




de Kater, et al.         Expires 26 August 2024                [Page 53]

Internet-Draft                  SCION CP                   February 2024


   *Wormhole Attack*
   A malicious AS M1 can send a PCB not only to their downstream
   neighbor ASes, but also out-of-band to another, non-neighbor
   colluding malicious AS M2.  This creates new segments to M2 and M2's
   downstream neighbor ASes, simulating a link between M1 and M2 which
   may not correspond to an actual link in the network topology.

   Similarly, a fake path can be announced through a fake peering link
   between two colluding ASes, even if in different ISDs.  An adversary
   can advertise fake peering links between the two colluding ASes, thus
   offering short paths to many destination ASes.  Downstream ASes might
   have a policy of preferring paths with many peering links and thus
   are more likely to disseminate PCBs from the adversary.  Similarly,
   endpoints are more likely to choose short paths that make use of
   peering links.  In the data plane, whenever the adversary receives a
   packet containing a fake peering link, it can transparently exchange
   the fake peering hop fields with valid hop fields to the colluding
   AS.  To avoid detection of the path alteration by the receiver, the
   colluding AS can replace the added hop fields with the fake peering
   link hop fields the sender inserted.

   To defend against this attack, methods to detect the wormhole attack
   are needed.  Per link or path latency measurements can help reveal
   the wormhole and render the fake peering link suspicious or
   unattractive.  Without specific detection mechanisms these so-called
   wormhole attacks are unavoidable in routing.

5.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 at the core control services, 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 volumetric DoS attacks, which aim to
   exhaust network bandwidth on links; in this case, ASes can switch to
   alternative paths that do not contain the congested links.  In
   addition, reflection-based attacks are prevented, as thanks to path-
   awareness, response packets are returned on the same path to the
   actual sender.  Control plane traffic can also be marked with
   priority using the TrafficClass field in the SCION common header, and
   mapped to a prioritized queue on border routers.








de Kater, et al.         Expires 26 August 2024                [Page 54]

Internet-Draft                  SCION CP                   February 2024


   In addition to this, critical control services should be further
   protected to preserve their availability with filtering and rate-
   limiting.  Thanks to its path-awareness, SCION enables more fine-
   grained filtering mechanisms, that can be employed to prevent misuse
   of critical request to the control plane:

   *  ISD / AS whitelisting only allows requests from certain categories
      to pass the filter (e.g. requests from infrastructure nodes of the
      same AS, ISD, or from neighboring ASes)

   *  Path length filtering discriminates packets based on the length of
      the traversed path (e.g. empty path for AS internal traffic, one
      hop paths limiting traffic to one-hop neighbors; and based on the
      number of path segments to distinguish requests from external
      ISDs)

   *  Rate limiting, that can be applied based on various identifiers
      (endpoint address, AS, or ISD)

   A combination of the mechanism above is used to prevent flooding
   attacks on the control service.  In addition, the control services
   are designed to be deployed on replicated instances.  Different
   instances can be made available only to specific groups of endpoints.
   For example, an AS could set up path server replicas such that one
   replica handles all requests originating from outside the AS, whereas
   another replica can only be reached by end hosts within an AS.

6.  IANA Considerations

   This document has no IANA actions.

   The ISD and SCION AS 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
   (https://docs.anapaya.net/en/latest/resources/isd-as-assignments/)).
   This task is currently being transitioned from Anapaya to the SCION
   Association.

7.  References

7.1.  Normative References

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







de Kater, et al.         Expires 26 August 2024                [Page 55]

Internet-Draft                  SCION CP                   February 2024


   [I-D.scion-components]
              Rustignoli, N. and C. de Kater, "SCION Components
              Analysis", 2023, <https://datatracker.ietf.org/doc/draft-
              rustignoli-panrg-scion-components/>.

   [I-D.scion-cppki]
              de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control-
              Plane PKI", 2023, <https://datatracker.ietf.org/doc/draft-
              dekater-scion-pki/>.

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

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

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

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

7.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, 2022,
              <https://doi.org/10.1007/978-3-031-05288-0>.

   [I-D.scion-dp]
              de Kater, C., Rustignoli, N., and S. Hitz, "SCION Data
              Plane", 2023, <https://datatracker.ietf.org/doc/draft-
              dekater-scion-dataplane/>.



de Kater, et al.         Expires 26 August 2024                [Page 56]

Internet-Draft                  SCION CP                   February 2024


   [I-D.scion-overview]
              de Kater, C., Rustignoli, N., and A. Perrig, "SCION
              Overview", 2023, <https://datatracker.ietf.org/doc/draft-
              dekater-panrg-scion-overview/>.

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

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

Acknowledgments

   Many thanks go to William Boye (Swiss National Bank), Matthias Frei
   (SCION Association), Kevin Meynell (SCION Association), Juan A.
   Garcia Prado (ETH Zurich), and Roger Lapuh (Extreme Networks) 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 Control Plane, as well as to the
   authors of [CHUAT22] - the book is an important source of input and
   inspiration for this draft.

PCB Protobuf Messages - Full Example

   The following code block provides a full example of one PCB in the
   Protobuf message format.

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

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

   message ASEntry {
       // The signed part of the AS entry. The body of the SignedMessage
       // is the serialized ASEntrySignedBody.



de Kater, et al.         Expires 26 August 2024                [Page 57]

Internet-Draft                  SCION CP                   February 2024


       // The signature input is defined as following:
       //
       // 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
       //
       SignedMessage signed = 1;
       // Optional
       PathSegmentUnsignedExtensions unsigned = 2;
   }

   message SignedMessage {
       // Encoded header and body.
       bytes header_and_body = 1;
       // Raw signature. The signature is computed over the
       // concatenation of the header and body, and the optional
       // associated data.
       bytes signature = 2;
   }

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

   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;



de Kater, et al.         Expires 26 August 2024                [Page 58]

Internet-Draft                  SCION CP                   February 2024


   }

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

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

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

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

Path-Lookup Examples

   To illustrate how the path lookup works, we show two path-lookup
   examples in sequence diagrams.  The network topology of the examples
   is represented in Figure 10 below.  In both examples, the source
   endpoint is in AS A.  Figure 11 shows the sequence diagram for the
   path lookup process in case the destination is in AS D, whereas
   Figure 12 shows the path lookup sequence diagram if the destination
   is in AS G.  ASes B and C are core ASes in the source ISD, while E
   and F are core ASes in a remote ISD.  Core AS B is a provider of the
   local AS, but AS C is not, i.e., there is no up-segment from A to C.
   "CS" stands for controle service.








de Kater, et al.         Expires 26 August 2024                [Page 59]

Internet-Draft                  SCION CP                   February 2024


   +----------------------------+     +----------------------------+
   |                            |     |                            |
   |                            |     |                            |
   |    +------------------+    |     |    +------------------+    |
   |    |      Core        |    |     |    |          Core    |    |
   |    |                  |    |     |    |                  |    |
   |    | .---.     .---.  |    |     |    |            .---. |    |
   |    |(  C  )---(  B  )-----------------------------(  F  )|    |
   |    | `+--'     `+-+'---------+   |    |    .---.   `+-+' |    |
   |    |  |         | |   |    | +------------(  E  )   | |  |    |
   |    |  |         | |   |    |     |    |    `-+-'----+ |  |    |
   |    +--|---------|-|---+    |     |    +------|--------|--+    |
   |       |         | |        |     |           |        |       |
   |       |         | |        |     |           |        |       |
   |       |+--------+ |        |     |           |        |       |
   |       ||          |        |     |           |        |       |
   |       ||          |        |     |           |        |       |
   |     .-++.         |        |     |         .-+-.      |       |
   |    (  D  )      .-+-.      |     |        (  G  )-----+       |
   |     `---'      (  A  )     |     |         `---'              |
   |                 `---'      |     |                            |
   |   ISD 1                    |     |                    ISD 2   |
   +----------------------------+     +----------------------------+

           Figure 10: Topology used in the path lookup examples.

+---------+          +---------+          +---------+        +---------+
|Endpoint |          |Source AS|          | Core AS |        | Core AS |
|         |          | CS (A)  |          | CS (B)  |        | CS (C)  |
+----+----+          +----+----+          +----+----+        +-----+---+
    +++                   |                    |                   |
    | |                   |                    |                   |
+---+-+-------+           |                    |                   |
|send requests|           |                    |                   |
| in parallel |           |                    |                   |
+---+-+-------+           |                    |                   |
    | |                   |                    |                   |
    | |  request (up)     |                    |                   |
    | +----------------->+++                   |                   |
    | |< -- -- -- -- -- -+++                   |                   |
    | | reply (up,[A->B]) |                    |                   |
    | |                   |                    |                   |
    | |                   |                    |                   |
    | |                   |                    |                   |
    | |request (core,*,*) |                    |                   |
    | +----------------->+++                   |                   |
    | |                  | |request (core,B,*) |                   |
    | |                  | +----------------->+++                  |



de Kater, et al.         Expires 26 August 2024                [Page 60]

Internet-Draft                  SCION CP                   February 2024


    | |                  | |<-- -- -- -- -- --+++                  |
    | |                  | | reply(core,[B->C])|                   |
    | |< -- -- -- -- -- -+++                   |                   |
    | |reply (core,[B->C])|                    |                   |
    | |                   |                    |                   |
    | |                   |                    |                   |
    | |request (down,*,D) |                    |                   |
    | +----------------->+++                   |                   |
    | |            +-----+-+-----+             |                   |
    | |            |send requests|             |                   |
    | |            | in parallel |             |                   |
    | |            +-----+-+-----+             |                   |
    | |                  | |                   |                   |
    | |                  | |request (down,B,D) |                   |
    | |                  | +----------------->+++                  |
    | |                  | |<-- -- -- -- -- --+++                  |
    | |                  | | reply(down,[B->D])|                   |
    | |                  | |                   |                   |
    | |                  | |                   |request (down,C,D) |
    | |                  | +-------------------+----------------->+++
    | |                  | <-- -- -- -- -- -- -+ -- -- -- -- -- --+++
    | |   reply (down,   | |                   | reply(down,[C->D])|
    | |   [B->D, C->D])  | |                   |                   |
    | |< -- -- -- -- -- -+++                   |                   |
    | |                   |                    |                   |
+---+-+----------+        |                    |                   |
|combine segments|        |                    |                   |
+---+-+----------+        |                    |                   |
    | |                   |                    |                   |
    +++                   |                    |                   |
     |                    |                    |                   |
 +---+----+           +---+----+          +----+---+          +----+---+
 +--------+           +--------+          +--------+          +--------+

     Figure 11: Sequence diagram illustrating a path lookup for a
  destination D in the source ISD.  The request (core, x, x) is for
   all pairs of core ASes in the source ISD.  Similarly, (down, x,
  D) is for down-segments between any core AS in the source ISD and
                            destination D.

+---------+     +---------+      +---------+   +---------+   +---------+
|Endpoint |     |Source AS|      | Core AS |   | Core AS |   | Core AS |
|         |     | CS (A)  |      | CS (B)  |   | CS (E)  |   | CS (F)  |
+---+-----+     +----+----+      +----+----+   +----+----+   +----+----+
    |                |                |             |             |
   +++               |                |             |             |
   | |               |                |             |             |
+--+-+------+        |                |             |             |



de Kater, et al.         Expires 26 August 2024                [Page 61]

Internet-Draft                  SCION CP                   February 2024


|   send    |        |                |             |             |
|requests in|        |                |             |             |
| parallel  |        |                |             |             |
+--+-+------+        |                |             |             |
   | |               |                |             |             |
   | |  request (up) |                |             |             |
   | +------------->+++               |             |             |
   | |<- -- -- -- --+++               |             |             |
   | |    reply      |                |             |             |
   | | (up,[A->B])   |                |             |             |
   | |               |                |             |             |
   | |               |                |             |             |
   | |   request     |                |             |             |
   | |(core,*,(2,*)) |                |             |             |
   | +------------->+++    request    |             |             |
   | |              | |(core,B,(2,*)) |             |             |
   | |              | +------------->+++            |             |
   | |              | |<- -- -- -- --+++            |             |
   | |              | | reply (core,  |             |             |
   | |              | | [B->E,B->F])  |             |             |
   | |<- -- -- -- --+++               |             |             |
   | | reply (core,  |                |             |             |
   | | [B->E,B->F])  |                |             |             |
   | |               |                |             |             |
   | |               |                |             |             |
   | |               |                |             |             |
   | |   request     |                |             |             |
   | |(down,(2,*),G) |                |             |             |
   | +------------->+++               |             |             |
   | |        +-----+-+-----+         |             |             |
   | |        |send requests|         |             |             |
   | |        | in parallel |         |             |             |
   | |        +-----+-+-----+         |   request   |             |
   | |              | |               | (down,E,G)  |             |
   | |              | +---------------+----------->+++            |
   | |              | <- -- -- -- -- -+ -- -- -- --+++            |
   | |              | |               |    reply    |             |
   | |              | |               |(down,[E->G])|             |
   | |              | |               |             |   request   |
   | |              | |               |             | (down,F,G)  |
   | |              | +---------------+-------------+----------->+++
   | |              | < -- -- -- -- --|-- -- -- -- -+ -- -- -- --+++
   | |              | |               |             |    reply    |
   | | reply (down, | |               |             |(down,[F->G])|
   | | [E->G,F->G]) | |               |             |             |
   | |<- -- -- -- --+++               |             |             |
   | |               |                |             |             |
+--+-+----+          |                |             |             |



de Kater, et al.         Expires 26 August 2024                [Page 62]

Internet-Draft                  SCION CP                   February 2024


| combine |          |                |             |             |
|segments |          |                |             |             |
+--+-+----+          |                |             |             |
   | |               |                |             |             |
   +++               |                |             |             |
    |                |                |             |             |
+---+----+       +---+----+       +---+----+    +---+----+    +---+----+
+--------+       +--------+       +--------+    +--------+    +--------+

     Figure 12: Sequence diagram illustrating a path lookup for a
   destination G in a remote ISD.  The request (core, x, (2, x)) is
   for all path segments between a core AS in the source ISD and a
     core AS in ISD 2.  Similarly, (down, (2, x), G) is for down-
       segments between any core AS in ISD 2 and destination G.

Authors' Addresses

   Corine de Kater
   SCION Association
   Email: c_de_kater@gmx.ch


   Nicola Rustignoli
   SCION Association
   Email: nic@scion.org


   Samuel Hitz
   Anapaya Systems
   Email: hitz@anapaya.net





















de Kater, et al.         Expires 26 August 2024                [Page 63]