Internet DRAFT - draft-dekater-scion-dataplane

draft-dekater-scion-dataplane







Network Working Group                                        C. de Kater
Internet-Draft                                             N. Rustignoli
Intended status: Informational                         SCION Association
Expires: 5 September 2024                                        S. Hitz
                                                         Anapaya Systems
                                                            4 March 2024


                            SCION Data Plane
                    draft-dekater-scion-dataplane-01

Abstract

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

   The SCION data plane fundamentally differs from today's IP-based data
   plane in that it is _path-aware_: In SCION, interdomain forwarding
   directives are embedded in the packet header.  This document first
   provides a detailed specification of the SCION data packet format as
   well as the structure of the SCION header.  SCION also supports
   extension headers - these are described, too.  The document then
   shows the life cycle of a SCION packet while traversing the SCION
   Internet.  This is followed by a specification of the SCION path
   authorization mechanisms and the packet processing at routers.  SCION
   also includes its own protocol to communicate failures to endpoints,
   the SCION Control Message Protocol (SCMP).  This protocol will be
   described in a separate document, which will follow later.

About This Document

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

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

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




de Kater, et al.        Expires 5 September 2024                [Page 1]

Internet-Draft                  SCION DP                      March 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 5 September 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.   Overview . . . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.1.   Inter- and Intra-Domain Forwarding . . . . . . . . .   7
       1.3.2.   Intra-Domain Forwarding Process  . . . . . . . . . .   8
     1.4.  Path Construction (Segment Combinations)  . . . . . . . .   8
     1.5.   Path Authorization . . . . . . . . . . . . . . . . . . .  12
   2.  SCION Header Specification  . . . . . . . . . . . . . . . . .  12
     2.1.  SCION Packet Header Format  . . . . . . . . . . . . . . .  12
       2.1.1.   Header Alignment . . . . . . . . . . . . . . . . . .  13
     2.2.   SCION Header Structure . . . . . . . . . . . . . . . . .  13
       2.2.1.   Common Header  . . . . . . . . . . . . . . . . . . .  13
       2.2.2.   Address Header . . . . . . . . . . . . . . . . . . .  15
       2.2.3.   Path Header  . . . . . . . . . . . . . . . . . . . .  16
     2.3.  Extension Headers . . . . . . . . . . . . . . . . . . . .  25
       2.3.1.   Format of the SCION Options Headers  . . . . . . . .  25
     2.4.  Upper-Layer Protocol Issues . . . . . . . . . . . . . . .  28



de Kater, et al.        Expires 5 September 2024                [Page 2]

Internet-Draft                  SCION DP                      March 2024


       2.4.1.   Pseudo Header for Upper-Layer Checksum . . . . . . .  28
   3.  Life of a SCION Data Packet . . . . . . . . . . . . . . . . .  29
     3.1.   Description  . . . . . . . . . . . . . . . . . . . . . .  30
     3.2.   Creating an End-to-End SCION Forwarding Path . . . . . .  31
     3.3.   Step-by-Step Explanation . . . . . . . . . . . . . . . .  32
   4.  Path Authorization  . . . . . . . . . . . . . . . . . . . . .  37
     4.1.  Authorizing Segments through Chained MACs . . . . . . . .  38
       4.1.1.   Hop Field MAC Computation  . . . . . . . . . . . . .  38
       4.1.2.   Peering Links  . . . . . . . . . . . . . . . . . . .  41
     4.2.   Path Initialization and Packet Processing  . . . . . . .  42
       4.2.1.   Initialization at Source Endpoint  . . . . . . . . .  42
       4.2.2.   Processing at Routers  . . . . . . . . . . . . . . .  44
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  51
     5.1.  Path Authorization  . . . . . . . . . . . . . . . . . . .  51
       5.1.1.  Forwarding key compromise . . . . . . . . . . . . . .  51
       5.1.2.  Forging hop field MAC . . . . . . . . . . . . . . . .  52
       5.1.3.  Path Splicing . . . . . . . . . . . . . . . . . . . .  52
     5.2.   On-Path Attacks  . . . . . . . . . . . . . . . . . . . .  52
       5.2.1.  Modification of the Path Header . . . . . . . . . . .  52
     5.3.  Off-Path Attacks  . . . . . . . . . . . . . . . . . . . .  53
     5.4.  Volumetric Denial of Service Attacks  . . . . . . . . . .  53
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  54
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  54
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  56
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  56
   Assigned SCION Protocol Numbers . . . . . . . . . . . . . . . . .  56
      Considerations . . . . . . . . . . . . . . . . . . . . . . . .  56
     Assignment  . . . . . . . . . . . . . . . . . . . . . . . . . .  57
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57

1.  Introduction

   SCION leverages source-based path selection, where path information
   is embedded in the packet header - this is called packet-carried
   forwarding state (PCFS).  This section explains how data packets are
   forwarded through the network, how the SCION inter-domain routing
   differs from intra-domain routing, and how endpoints can construct
   end-to-end paths from path segments.  It also briefly touches the
   concept of path authorization, which ensures that data packets always
   traverse the network along authorized paths.

   *Note:* This is the very first version of the SCION Data Plane
   document.  We are aware that the draft is far from perfect, and hope
   to improve the content in later versions of the document.  To reach
   this goal, any feedback is welcome and much appreciated.  Thanks!





de Kater, et al.        Expires 5 September 2024                [Page 3]

Internet-Draft                  SCION DP                      March 2024


   *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],
   [I-D.scion-cppki], and [I-D.scion-cp], 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.

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

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

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

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

   *Forwarding Path*: A forwarding path is a complete end-to-end path
   between two SCION 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.



de Kater, et al.        Expires 5 September 2024                [Page 4]

Internet-Draft                  SCION DP                      March 2024


   *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 (e.g., a common jurisdiction).  A possible model is for
   ISDs to be formed along national boundaries or federations of
   nations.

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

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

   *Packet-Carried Forwarding State (PCFS)*: Rather than relying on
   inter-domain forwarding tables, SCION data packets contain all the
   necessary, cryptographically-protected path information.  This
   property is referred to as packet-carried forwarding state.

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

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

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






de Kater, et al.        Expires 5 September 2024                [Page 5]

Internet-Draft                  SCION DP                      March 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.

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

   *SCMP*: SCION Control Message Protocol.  SCMP is used for signaling
   connectivity problems, analogous to the Internet Control Message
   Protocol (ICMP).  SCMP provides network diagnostic and error
   messages.

   *Valley Route*: A valley route contains ASes that do not profit
   economically from traffic on this route.  The name comes from the
   fact that such routes go "down" (following parent-child links) before
   going "up" (following child-parent links).

1.2.  Conventions and Definitions

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

1.3.   Overview

   The SCION data plane forwards inter-domain packets between ASes.
   SCION routers are normally deployed at the edge of an AS, and peer
   with neighbor SCION routers.  Inter-domain forwarding is based on
   end-to-end path information contained in the packet header.  This
   path information consists of a sequence of hop fields (HFs).  Each
   hop field corresponds to an AS on the path, and it includes an
   ingress- as well as an egress interface ID, which univocally identify
   the ingress and egress interfaces within the AS.  The information is
   authenticated with a Message Authentication Code (MAC) to prevent
   forgery.

   This concept allows SCION routers to forward packets to a neighbor AS
   without inspecting the destination address and also without
   consulting an inter-domain forwarding table.  Intra-domain forwarding
   and routing are based on existing mechanisms (e.g., IP).  A SCION
   border router reuses existing intra-domain infrastructure to
   communicate to other SCION routers or SCION endpoints within its AS.



de Kater, et al.        Expires 5 September 2024                [Page 6]

Internet-Draft                  SCION DP                      March 2024


   The last SCION router at the destination AS therefore uses the
   destination address to forward the packet to the appropriate local
   endpoint.

   This SCION design choice has the following advantages:

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

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

1.3.1.   Inter- and Intra-Domain Forwarding

   As SCION is an inter-domain network architecture, it is not concerned
   with intra-domain forwarding.  This corresponds to the general
   practice today where BGP and IP are used for inter-domain routing and
   forwarding, respectively, but ASes use an intra-domain protocol of
   their choice, for example OSPF or IS-IS for routing and IP, MPLS, and
   various layer-2 protocols for forwarding.  In fact, even if ASes use
   IP-forwarding internally today, they typically encapsulate the
   original IP packet they receive at the edge of their network into
   another IP packet with the destination address set to the egress
   border router, to avoid full inter-domain forwarding tables at
   internal routers.

   SCION emphasizes this separation, as SCION is used exclusively for
   inter-domain forwarding, and re-uses the intra-domain network fabric
   to provide connectivity among all SCION infrastructure services,
   border routers, and endpoints.  As a consequence, minimal change to
   the infrastructure is required for ISPs when deploying SCION.

   Although a complete SCION address is composed of the <ISD, AS,
   endpoint address> 3-tuple, the endpoint address is not used for
   inter-domain routing or forwarding.  This implies that the endpoint
   addresses are not required to be globally unique or globally
   routable, they can be selected independently by the corresponding
   ASes.  This means, for example, that an endpoint identified by a
   link-local IPv6 address in the source AS can directly communicate
   with an endpoint identified by a globally routable IPv4 address via
   SCION.  Alternatively, it is possible for two SCION hosts with the
   same IPv4 address 10.0.0.42 but located in different ASes to
   communicate with each other via SCION ([RFC1918]).





de Kater, et al.        Expires 5 September 2024                [Page 7]

Internet-Draft                  SCION DP                      March 2024


1.3.2.   Intra-Domain Forwarding Process

   The full forwarding process for a packet transiting an intermediate
   AS consists of the following steps.

   *Note:* In this context, a border router is called *ingress* border
   router when it refers to an entrance border router to an AS, as seen
   from the direction of travel of the SCION packet.  A border router is
   called *egress* border router when it refers to an exit border router
   of an AS, as seen from the direction of travel of the SCION packet.

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

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

   3.  The SCION router maps the egress interface ID in the current hop
       field of the SCION header to the destination "intra-protocol"
       address of the egress border router (where "intra-protocol" is
       the intra-domain forwarding protocol, e.g., MPLS or IP).

   4.  The packet is forwarded within the AS by routers and switches
       based on the "intra-protocol" header.

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

   *Note:* The current SCION implementation uses the UDP/IP protocol as
   underlay.  However, the use of other underlay protocols is possible
   and allowed.

1.4.  Path Construction (Segment Combinations)

   Paths are discovered by the SCION control plane, which makes them
   available to SCION endpoints in the form of path segments.  As
   described in [I-D.scion-cp], there are three kinds of path segments:
   up, down, and core.  In the data plane, a SCION endpoint creates end-
   to-end paths from the path segments, by combining multiple path
   segments.  Depending on the network topology, a SCION forwarding path
   can consist of one, two, or three segments.  Each path segment
   contains several hop fields representing the ASes on the segment as
   well as one info field with basic information about the segment, such
   as a timestamp.

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



de Kater, et al.        Expires 5 September 2024                [Page 8]

Internet-Draft                  SCION DP                      March 2024


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

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

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

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

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

   *  Additionally, all segments without any peering possibility MUST
      consist of at least two hop fields.

   *Note:* The type of segment is known to the endpoint but is not
   visible in the path header of data packets.  Therefore, a SCION
   router needs to explicitly verify that these rules were followed
   correctly.

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

   Figure 1 below shows the different allowed segment combinations.

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

                                   ------- = end-to-end path
    C = Core AS                    - - - - = unused links
    * = source/destination AS      ------> = direction of beaconing


           Core                        Core                  Core
       ---------->                 ---------->           ---------->
      .-.       .-.               .-.       .-.         .-.       .-.



de Kater, et al.        Expires 5 September 2024                [Page 9]

Internet-Draft                  SCION DP                      March 2024


 +-- ( C )-----( C ) --+     +-- ( C )-----(C/*)       (C/*)-----(C/*)
 |    `+'       `+'    |     |    `+'       `-'         `-'       `-'
 |     |    1a   |     |     |     |     1b                   1c
 |     |         |     |     |     |
 |     |         |     |     |     |
 |    .+.       .+.    |     |    .+.                       Core
 |   (   )     (   )   |     |   (   )                 -------------->
 |    `+'       `+'    |     |    `+'                        .-.
 |     |         |     |     |     |                   +----( C )----+
 |     |         |     |     |     |                   |     `-'     |
 |     |         |     |     |     |                   |             |
 |    .+.       .+.    |     |    .+.                 .+.     1d    .+.
 +-> ( * )     ( * ) <-+     +-> ( * )               (C/*)         (C/*)
      `-'       `-'               `-'                 `-'           `-'



           .-.                      .-.                   .-.
 +--   +--( C )--+   --+      +--  (C/*)        +--    - ( C ) -    --+
 |     |   `-'   |     |      |     `+'         |     |   `-'   |     |
 |     |         |     |      |      |          |                     |
 |     |    2a   |     |      |  2b  |          |     |    3a   |     |
 |     |         |     |      |      |          |                     |
 |    .+.       .+.    |      |     .+.         |    .+.       .+.    |
 |   (   )     (   )   |      |    (   )        |   (   #-----#   )   |
 |    `+'       `+'    |      |     `+'         |    `+'  Peer `+'    |
 |     |         |     |      |      |          |     |         |     |
 |     |         |     |      |      |          |     |         |     |
 |     |         |     |      |      |          |     |         |     |
 |    .+.       .+.    |      |     .+.         |    .+.       .+.    |
 +-> ( * )     ( * ) <-+      +->  ( * )        +-> ( * )     ( * ) <-+
      `-'       `-'                 `-'              `-'       `-'


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



de Kater, et al.        Expires 5 September 2024               [Page 10]

Internet-Draft                  SCION DP                      March 2024


  |   .+.       .+.   |  |  .+.     .+.  |     .+.       .+.   |    .+.
  +->( * )     ( * )<-+  +>( * )   ( * )<+    ( * )     ( * )  +-> ( * )
      `-'       `-'         `-'     `-'        `-'       `-'        `-'

     Figure 1: Illustration of possible path-segment combinations.
            Each node represents a SCION Autonomous System.

   The following path-segment combinations are allowed:

   *  *Communication through core ASes*:

      -  *Core-segment combination* (Cases 1a, 1b, 1c, 1d in Figure 1):
         The up- and down-segments of source and destination do not have
         an AS in common.  In this case, a core-segment is required to
         connect the source's up- and the destination's down-segment
         (Case 1a).  If either the source or the destination AS is a
         core AS (Case 1b) or both are core ASes (Cases 1c and 1d), then
         no up- or down-segment(s) are required to connect the
         respective AS(es) to the core-segment.

      -  *Immediate combination* (Cases 2a, 2b in Figure 1): The last AS
         on the up-segment (which is necessarily a core AS) is the same
         as the first AS on the down-segment.  In this case, a simple
         combination of up- and down-segments creates a valid forwarding
         path.  In Case 2b, only one segment is required.

   *  *Peering shortcut* (Cases 3a and 3b): A peering link exists
      between the up- and down-segment.  The extraneous path segments to
      the core are cut off.  Note that the up- and down-segments do not
      need to originate from the same core AS and the peering link could
      also be traversing to a different ISD.

   *  *AS shortcut* (Cases 4a and 4b): The up- and down-segments
      intersect at a non-core AS below the ISD core, thus creating a
      shortcut.  In this case, a shorter path is made possible by
      removing the extraneous part of the path to the core.  Note that
      the up- and down-segments do not need to originate from the same
      core AS and can even be in different ISDs (if the AS at the
      intersection is part of multiple ISDs).

   *  *On-path* (Case 5): In the case where the source's up-segment
      contains the destination AS or the destination's down-segment
      contains the source AS, a single segment is sufficient to
      construct a forwarding path.  Again, no core AS is on the final
      path.






de Kater, et al.        Expires 5 September 2024               [Page 11]

Internet-Draft                  SCION DP                      March 2024


1.5.   Path Authorization

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

2.  SCION Header Specification

   This section provides a detailed specification of the SCION packet
   header.  SCION also supports extension headers - these are described,
   too.

2.1.  SCION Packet Header Format

   The SCION packet header is composed of a common header, an address
   header, a path header, and an OPTIONAL extension header, see Figure 2
   below.

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

                Figure 2: High-level SCION header structure

   The _common header_ contains important meta information like a
   version number and lengths of the header and payload.  In particular,
   it contains flags that control the format of subsequent headers such
   as the address and path headers.  For more details, see
   Section 2.2.1.







de Kater, et al.        Expires 5 September 2024               [Page 12]

Internet-Draft                  SCION DP                      March 2024


   The _address header_ contains the ISD-, AS-, and endpoint-addresses
   of source and destination.  The type and length of endpoint addresses
   are variable and can be set independently using flags in the common
   header.  For more details, see Section 2.2.2.

   The _path header_ contains the full AS-level forwarding path of the
   packet.  A path type field in the common header specifies the path
   format used in the path header.  For more details, see Section 2.2.3.

   Finally, the optional _extension_ header contains a variable number
   of hop-by-hop and end-to-end options, similar to the extensions in
   the IPv6 header [RFC8200].  For more details, see Section 2.3.

2.1.1.   Header Alignment

   The SCION header is aligned to 4 bytes.

2.2.   SCION Header Structure

2.2.1.   Common Header

   The SCION common header has the following packet format:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  TraffCl      |                FlowID                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    NextHdr    |    HdrLen     |          PayloadLen           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    PathType   |DT |DL |ST |SL |              RSV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: The SCION common header packet format

   *  Version: The version of the SCION common header.  Currently, only
      version "0" is supported.

   *  TrafficClass (TraffCl in the image above): The 8-bit long
      identifier of the packet's class or priority.  The value of the
      traffic class bits in a received packet or fragment might differ
      from the value sent by the packet's source.  The current use of
      the TrafficClass field for Differentiated Services and Explicit
      Congestion Notification is specified in [RFC2474] and [RFC3168].

   *  FlowID: This 20-bit field labels sequences of packets to be
      treated in the network as a single flow.  Sources MUST set this
      field.



de Kater, et al.        Expires 5 September 2024               [Page 13]

Internet-Draft                  SCION DP                      March 2024


   *  NextHdr: Encodes the type of the first header after the SCION
      header.  This can be either a SCION extension or a layer-4
      protocol such as TCP or UDP.  Values of this field respect the
      Assigned SCION Protocol Numbers (see Appendix "Assigned SCION
      Protocol Numbers").

   *  HdrLen: Specifies the entire length of the SCION header in bytes,
      i.e., the sum of the lengths of the common header, the address
      header, and the path header.  All SCION header fields are aligned
      to a multiple of 4 bytes.  The SCION header length is computed as
      HdrLen * 4 bytes.  The 8 bits of the HdrLen field limit the SCION
      header to a maximum of 255 * 4 = 1020 bytes.

   *  PayloadLen: Specifies the length of the payload in bytes.  The
      payload includes (SCION) extension headers and the L4 payload.
      This field is 16 bits long, supporting a maximum payload size of
      65'535 bytes.

   *  PathType: Specifies the type of the SCION path.  It is possible to
      specify up to 256 different types.  The format of one path type is
      independent of all other path types.  The currently defined SCION
      path types are Empty (0), SCION (1), OneHopPath (2), EPIC (3) and
      COLIBRI (4).  This document only specifies the Empty, SCION and
      OneHopPath path types.  The other path types are currently
      experimental.

                  +=======+=============================+
                  | Value | Path Type                   |
                  +=======+=============================+
                  | 0     | Empty path (EmptyPath)      |
                  +-------+-----------------------------+
                  | 1     | SCION (SCION)               |
                  +-------+-----------------------------+
                  | 2     | One-hop path (OneHopPath)   |
                  +-------+-----------------------------+
                  | 3     | EPIC path (experimental)    |
                  +-------+-----------------------------+
                  | 4     | COLIBRI path (experimental) |
                  +-------+-----------------------------+

                         Table 1: SCION path types

   *  DT/DL/ST/SL: These fields define the endpoint-address type and
      endpoint-address length for the source and destination endpoint.
      DT and DL stand for Destination Type and Destination Length,
      whereas ST and SL stand for Source Type and Source Length.  The
      possible endpoint address length values are 4 bytes, 8 bytes, 12
      bytes, and 16 bytes.  If some address has a length different from



de Kater, et al.        Expires 5 September 2024               [Page 14]

Internet-Draft                  SCION DP                      March 2024


      the supported values, the next larger size can be used and the
      address can be padded with zeros.  Table 2 below lists the
      currently used values for address length.  The "type" identifier
      is only defined in combination with a specific address length.
      For example, address type "0" is defined as IPv4 in combination
      with address length 4, but in combination with address length 16,
      it stands for IPv6.  Per address length, several sub-types are
      possible.  Table 3 shows the currently valid allocations of type
      values to length values.

                     +=============+================+
                     | DL/SL Value | Address Length |
                     +=============+================+
                     | 0           | 4 bytes        |
                     +-------------+----------------+
                     | 1           | 8 bytes        |
                     +-------------+----------------+
                     | 2           | 12 bytes       |
                     +-------------+----------------+
                     | 3           | 16 bytes       |
                     +-------------+----------------+

                      Table 2: Address length values

    +================+======+=======================+================+
    | Length (bytes) | Type |  Type/Length (binary) | Interpretation |
    +================+======+=======================+================+
    | 4              | 0    | 0b0000                | IPv4           |
    +----------------+------+-----------------------+----------------+
    | 4              | 1    | 0b0100                | Service        |
    +----------------+------+-----------------------+----------------+
    | 16             | 0    | 0b1100                | IPv6           |
    +----------------+------+-----------------------+----------------+
    | other          |      |                       | Unassigned     |
    +----------------+------+-----------------------+----------------+

           Table 3: Allocations of type values to length values

   *  RSV: These bits are currently reserved for future use.

2.2.2.   Address Header

   The SCION address header has the following format:








de Kater, et al.        Expires 5 September 2024               [Page 15]

Internet-Draft                  SCION DP                      March 2024


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DstISD             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                             DstAS                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            SrcISD             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                             SrcAS                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    DstHostAddr (variable Len)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SrcHostAddr (variable Len)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: The SCION address header packet format

   *  DstISD, SrcISD: The 16-bit ISD identifier of the destination/
      source.

   *  DstAS, SrcAS: The 48-bit AS identifier of the destination/source.

   *  DstHostAddr, SrcHostAddr: Specifies the variable length endpoint
      address of the destination/source.  The accepted type and length
      are defined in the DT/DL/ST/SL fields of the common header.

   *Note:* For more information on addressing in SCION, see the
   introduction of the SCION Control Plane Specification
   ([I-D.scion-cp]).

2.2.3.   Path Header

   The path header of a SCION packet differs for each SCION path type.

   *Note:* The path type is set in the PathType field of the SCION
   common header.

   Currently, SCION supports three path types:

   *  The Empty path type (PathType=0).  For more information, see
      Section 2.2.3.1.

   *  The SCION path type (PathType=1).  This is the standard path type
      in SCION.  For a detailed description, see Section 2.2.3.2.

   *  The OneHopPath path type (PathType=2).  For more information, see
      Section 2.2.3.3.



de Kater, et al.        Expires 5 September 2024               [Page 16]

Internet-Draft                  SCION DP                      March 2024


2.2.3.1.   Empty Path Type

   The Empty path type is used to send traffic within an AS.  It has no
   additional fields, i.e., it consumes 0 bytes on the wire.

   One use case of the Empty path type lies in the context of link-
   failure detection.  To this end, SCION uses the Bidirectional
   Forwarding Detection (BFD) protocol ([RFC5880] and [RFC5881]).  BFD
   is a protocol intended to detect faults in the bidirectional path
   between two forwarding engines, with typically very low latency.  It
   operates independently of media, data protocols, and routing
   protocols.  SCION uses the Empty path type, together with OneHopPath
   path type, to bootstrap BFD within SCION.  (For more information on
   the OneHopPath path type, see Section 2.2.3.3.)

2.2.3.2.   SCION Path Type

   This section specifies the standard SCION path type.  A SCION path
   has the following layout:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          PathMetaHdr                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           InfoField                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           InfoField                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           HopField                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           HopField                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5: Layout of a standard SCION path



de Kater, et al.        Expires 5 September 2024               [Page 17]

Internet-Draft                  SCION DP                      March 2024


   It consists of a path meta header, up to 3 info fields and up to 64
   hop fields.

   *  The path meta header (PathMetaHdr) indicates the currently valid
      info field and hop field while the packet is traversing the
      network along the path, as well as the number of hop fields per
      segment.

   *  The number of info fields (InfoField) equals the number of path
      segments that the path contains - there is one info field per path
      segment.  Each info field contains basic information about the
      corresponding segment, such as a timestamp indicating the creation
      time.  There are also two flags.  One specifies whether the
      segment is to be traversed in construction direction, the other
      whether the first or last hop field in the segment represents a
      peering hop field.

   *  Each hop field (HopField) represents a hop through an AS on the
      path, with the ingress and egress interface identifiers for this
      AS.  This information is authenticated with a Message
      Authentication Code (MAC) to prevent forgery.

   The SCION header is created by extracting the required info fields
   and hop fields from the corresponding path segments.  The process of
   extracting is illustrated in Figure 6 below.  Note that ASes at the
   joints of multiple segments are represented by two hop fields.  Be
   aware that these hop fields are not equal!  In the hop field that
   represents the last hop in the first segment (seen in the direction
   of travel), only the ingress interface will be specified.  However,
   in the hop field that represents the first hop in the second segment
   (also in the direction of travel), only the egress interface will be
   defined.  Thus, the two hop fields for this one AS build a full hop
   through the AS, specifying both the ingress and egress interface.  As
   such, they bring the two adjacent segments together.

                      +-----------------+
                      |    ISD Core     |
     .--.    .--.     |  .--.     .--.  |     .--.    .--.
    (AS 3)--(AS 4)----|-(AS 1)---(AS 2)-|----(AS 5)--(AS 6)
     `--'    `--'     |  `--'     `--'  |     `--'    `--'
                      +-----------------+

    Up-Segment           Core-Segment        Down-Segment
   +---------+           +---------+         +---------+
   | +-----+ |           | +-----+ |         | +-----+ |
   | + INF + |--------+  | + INF + |---+     | + INF + |--+
   | +-----+ |        |  | +-----+ |   |     | +-----+ |  |
   | +-----+ |        |  | +-----+ |   |     | +-----+ |  |



de Kater, et al.        Expires 5 September 2024               [Page 18]

Internet-Draft                  SCION DP                      March 2024


   | | HF  | |------+ |  | | HF  | |---+-+   | | HF  | |--+-+
   | +-----+ |      | |  | +-----+ |   | |   | +-----+ |  | |
   | +-----+ |      | |  | +-----+ |   | |   | +-----+ |  | |
   | | HF  | |----+ | |  | | HF  | |---+-+-+ | | HF  | |--+-+-+
   | +-----+ |    | | |  | +-----+ |   | | | | +-----+ |  | | |
   | +-----+ |    | | |  +---------+   | | | | +-----+ |  | | |
   | | HF  | |--+ | | |                | | | | | HF  | |--+-+-+-+
   | +-----+ |  | | | |  +----------+  | | | | +-----+ |  | | | |
   +---------+  | | | |  | ++++++++ |  | | | +---------+  | | | |
                | | | |  | | Meta | |  | | |              | | | |
                | | | |  | ++++++++ |  | | |              | | | |
                | | | |  | +------+ |  | | |              | | | |
                | | | +->| + INF  + |  | | |              | | | |
                | | |    | +------+ |  | | |              | | | |
                | | |    | +------+ |  | | |              | | | |
                | | |    | + INF  + |<-+ | |              | | | |
                | | |    | +------+ |    | |              | | | |
                | | |    | +------+ |    | |              | | | |
                | | |    | + INF  + |<---+-+--------------+ | | |
                | | |    | +------+ |    | |                | | |
                | | |    | +------+ |    | |                | | |
                | | +--->| |  HF  | |    | |                | | |
                | |      | +------+ |    | |                | | |
                | |      | +------+ |    | |                | | |
                | +----->| |  HF  | |    | |                | | |
                |        | +------+ |    | |                | | |
                |        | +------+ |    | |                | | |
                +------->| |  HF  | |    | |                | | |
                         | +------+ |    | |                | | |
                         | +------+ |    | |                | | |
                         | |  HF  | |<---+ |                | | |
                         | +------+ |      |                | | |
                         | +------+ |      |                | | |
        Forwarding Path  | |  HF  | |<-----+                | | |
                         | +------+ |                       | | |
                         | +------+ |                       | | |
                         | |  HF  | |<----------------------+ | |
                         | +------+ |                         | |
                         | +------+ |                         | |
                         | |  HF  | |<------------------------+ |
                         | +------+ |                           |
                         | +------+ |                           |
                         | |  HF  | |<--------------------------+
                         | +------+ |
                         +----------+

                    Figure 6: Path construction example




de Kater, et al.        Expires 5 September 2024               [Page 19]

Internet-Draft                  SCION DP                      March 2024


2.2.3.2.1.   Path Meta Header Field

   The 4-byte Path Meta Header field (PathMetaHdr) defines meta
   information about the SCION path that is contained in the path
   header.  It has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | C |  CurrHF   |    RSV    |  Seg0Len  |  Seg1Len  |  Seg2Len  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 7: SCION path type - Format of the Path Meta Header field

   *  C (urrINF): Specifies a 2-bits index (0-based) pointing to the
      current info field for the packet on its way through the network.
      For details, see Section 2.2.3.2.2 below.

   *  CurrHF: Specifies a 6-bits index (0-based) pointing to the current
      hop field for the packet on its way through the network.  For
      details, see Section 2.2.3.2.2 below.  Note that the CurrHF index
      MUST point to a hop field that is part of the current path
      segment, as indicated by the CurrINF index.

   Both indices are used by SCION routers when forwarding data traffic
   through the network.  The SCION routers also increment the indexes if
   required.  For more details, see Section 4.2.2.

   *  Seg{0,1,2}Len: The number of hop fields in a given segment.
      Seg{i}Len > 0 implies that segment _i_ contains at least one hop
      field, which means that info field _i_ exists.  (If Seg{i}Len = 0
      then segment _i_ is empty, meaning that this path does not include
      segment _i_, and therefore there is no info field _i_.) The
      following rules apply:

      -  The total number of hop fields in an end-to-end path MUST be
         equal to the sum of all Seg{0,1,2}Len contained in this end-to-
         end path.

      -  It is an error to have Seg{X}Len > 0 AND Seg{Y}Len == 0, where
         2 >= _X_ > _Y_ >= 0.  That is, if path segment Y is empty, the
         following path segment X MUST also be empty.

   *  RSV: Unused and reserved for future use.







de Kater, et al.        Expires 5 September 2024               [Page 20]

Internet-Draft                  SCION DP                      March 2024


2.2.3.2.2.   Path Offset Calculations

   The path offset calculations are used by the SCION border routers to
   determine the info field and hop field that are currently valid for
   the packet on its way through the network.

   The following rules apply when calculating the path offsets:

      if Seg2Len > 0: NumINF = 3
      else if Seg1Len > 0: NumINF = 2
      else if Seg0Len > 0: NumINF = 1
      else: invalid

   The offsets of the current info field and current hop field (relative
   to the end of the address header) are now calculated as:

      B = byte
      InfoFieldOffset = 4B + 8B.CurrINF
      HopFieldOffset = 4B + 8B.NumINF + 12B.CurrHF

   To check that the current hop field is in the segment of the current
   info field, the CurrHF needs to be compared to the SegLen fields of
   the current and preceding info fields.

2.2.3.2.3.   Info Field

   The 8-byte Info Field (InfoField) has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |r r r r r r P C|      RSV      |             Acc               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8: SCION path type - Format of the Info Field

   *  r: The r bits are unused and reserved for future use.

   *  P: Peering flag.  If the flag has value "1", the segment
      represented by this info field contains a peering hop field, which
      requires special processing in the data plane.  For more details,
      see Section 4.1.2 and Section 4.2.







de Kater, et al.        Expires 5 September 2024               [Page 21]

Internet-Draft                  SCION DP                      March 2024


   *  C: Construction direction flag.  If the flag has value "1", the
      hop fields in the segment represented by this info field are
      arranged in the direction they have been constructed during
      beaconing.

   *  RSV: Unused and reserved for future use.

   *  Acc: This updatable field/counter is required for calculating the
      MAC in the data plane.  Acc stands for "Accumulator".  For more
      details, see Section 4.1.

   *  Timestamp: Timestamp created by the initiator of the corresponding
      beacon.  The timestamp is defined as the number of seconds elapsed
      since the POSIX Epoch (1970-01-01 00:00:00 UTC), encoded as a
      32-bit unsigned integer.  This timestamp enables the validation of
      a hop field in the segment represented by this info field, by
      verifying the expiration time and MAC set in the hop field - the
      expiration time of a hop field is calculated relative to the
      timestamp.

2.2.3.2.4.  Hop Field

   The 12-byte Hop Field (HopField) has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |r r r r r r I E|    ExpTime    |           ConsIngress         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        ConsEgress             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                              MAC                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9: SCION path type - Format of the Hop Field

   *  r: The r bits are unused and reserved for future use.

   *  I: The ConsIngress Router Alert flag.  If the ConsIngress Router
      Alert flag has value "1", the ingress router (in construction
      direction) will process the L4 payload in the packet.  The
      construction direction is the direction of beaconing.

   *  E: The ConsEgress Router Alert flag.  If the ConsEgress Router
      Alert flag has value "1", the egress router (in construction
      direction) will process the L4 payload in the packet.





de Kater, et al.        Expires 5 September 2024               [Page 22]

Internet-Draft                  SCION DP                      March 2024


   *Note:* A sender cannot rely on multiple routers retrieving and
   processing the payload even if it sets multiple router alert flags.
   This is use-case dependent: In the case of Traceroute informational
   messages, for example, the router for which the traceroute request is
   intended will process the request (if the corresponding Router Alert
   flag is set to "1") and reply to it without further forwarding the
   request along the path.  Use cases that require multiple routers/hops
   on the path to process a packet have to instead rely on a hop-by-hop
   extension (see Section 2.3).  For general information on router
   alerts, see [RFC2711].

   *  ExpTime: Expiry time of a hop field.  The field is 1-byte long,
      thus there are 256 different values available to express an
      expiration time.  The expiration time specified in this field is
      relative.  An absolute expiration time in seconds is computed in
      combination with the Timestamp field (from the corresponding info
      field), as follows:

      -  Timestamp + (1 + ExpTime) * (24 hours/256)

   *  ConsIngress, ConsEgress: The 16-bits ingress/egress interface IDs
      in construction direction, that is, the direction of beaconing.

   *  MAC: The 6-byte Message Authentication Code to authenticate the
      hop field.  For details on how this MAC is calculated, see
      Section 4.1.1.

2.2.3.3.  One-Hop Path Type

   The one-hop path type OneHopPath is currently used to bootstrap
   beaconing between neighboring ASes.  This is necessary, as neighbor
   ASes do not have a forwarding path yet before beaconing is started.

   A one-hop path has exactly one info field and two hop fields with the
   specialty that the second hop field is not known a priori, but is
   instead created by the ingress SCION border router of the neighboring
   AS while processing the one-hop path.  Any entity with access to the
   forwarding key of the source endpoint AS can create a valid info and
   hop field as described in Section 2.2.3.2.3 and Section 2.2.3.2.4,
   respectively.

   Upon receiving a packet containing a one-hop path, the ingress border
   router of the destination AS fills in the ConsIngress field in the
   second hop field of the one-hop path with the ingress interface ID.
   It sets the ConsEgress field to "0", indicating that the path cannot
   be used beyond the destination AS.  Then it calculates and appends
   the appropriate MAC for the hop field.




de Kater, et al.        Expires 5 September 2024               [Page 23]

Internet-Draft                  SCION DP                      March 2024


   Figure 10 below shows the layout of a SCION one-hop path type.  There
   is only a single info field; the appropriate hop field can be
   processed by a border router based on the source and destination
   address.  In this context, the following rules apply:

   *  At the source endpoint AS, _CurrHF := 0_.

   *  At the destination endpoint AS, _CurrHF := 1_.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           InfoField                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           HopField                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           HopField                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 10: Layout of the SCION one-hop path type

2.2.3.4.  Path Reversal

   When a destination endpoint receives a SCION packet, it can use the
   path information in the SCION header for sending the reply packets.
   For this, the destination endpoint MUST perform the following steps:

   1.  Reverse the order of the info fields;

   2.  Reverse the order of the hop fields;

   3.  For each info field, negate the construction direction flag C; do
       not change the accumulator field Acc.

   4.  In the PathMetaHdr field:

       *  Set the CurrINF and CurrHF to "0".

       *  Reverse the order of the non-zero SegLen fields.

       *Note:* For more information on the PathMetaHdr field, see
       Section 2.2.3.2.1.

   A similar mechanism is possible for on-path routers, for example to
   send SCION Control Message Protocol (SCMP) messages to the sender of
   the original packet.







de Kater, et al.        Expires 5 September 2024               [Page 24]

Internet-Draft                  SCION DP                      March 2024


2.3.  Extension Headers

   This section specifies the SCION extension headers.  SCION currently
   provides two types of extension headers: the Hop-by-Hop (HBH) Options
   header and the End-to-End (E2E) Options header.

   *  The Hop-by-Hop Options header is used to carry optional
      information that may be examined and processed by every SCION
      router along a packet's delivery path.  The Hop-by-Hop Options
      header is identified by value "200" in the NextHdr field of the
      SCION common header (see Section 2.2.1).

   *  The End-to-End Options header is used to carry optional
      information that may be examined and processed by the sender and/
      or the receiver of the packet.  The End-to-End Options header is
      identified by value "201" in the NextHdr field of the SCION common
      header (see Section 2.2.1).

   If both headers are present, the HBH Options header MUST come before
   the E2E Options header.

   *Note:* The SCION extension headers are defined and used based on and
   similar to the IPv6 extensions as specified in section 4 of
   [RFC8200].  The SCION Hop-by-Hop Options header and End-to-End
   Options header resemble the IPv6 Hop-by-Hop Options Header (section
   4.3 in the RFC) and Destination Options Header (section 4.6),
   respectively.

2.3.1.   Format of the SCION Options Headers

   The SCION Hop-by-Hop Options and End-to-End Options headers have the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    NextHdr    |     ExtLen    |            Options            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 11: Extension headers: Options header

   *  NextHdr: Unsigned 8-bit integer.  Identifies the type of header
      immediately following the Hop-by-Hop/End-to-End Options header.
      Values of this field respect the Assigned SCION Protocol Numbers
      (see also Appendix "Assigned SCION Protocol Numbers").




de Kater, et al.        Expires 5 September 2024               [Page 25]

Internet-Draft                  SCION DP                      March 2024


   *  ExtLen: Unsigned 8-bit integer.  The value of this field is
      computed as the length of the complete Hop-by-Hop/End-to-End
      Options header in multiples of 4-bytes minus 1.

   *  Options: This is a variable-length field.  The length of this
      field MUST be such that the complete length of the Hop-by-Hop/End-
      to-End Options header is an integer multiple of 4 bytes.  The
      Options field contains one or more Type-Length-Value (TLV) encoded
      options.  For details, see Section 2.3.1.1.

   The Hop-by-Hop/End-to-End Options header is aligned to 4 bytes.

2.3.1.1.   Options Field

   The Options field of the Hop-by-Hop Options and the End-to-End
   Options headers carries a variable number of options that are type-
   length-value (TLV) encoded.  Each TLV-encoded option has the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    OptType    |  OptDataLen   |            OptData            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 12: Options field: TLV-encoded options

   *  OptType: 8-bit identifier of the type of option.  The following
      option types are assigned to the SCION HBH/E2E Options header:




















de Kater, et al.        Expires 5 September 2024               [Page 26]

Internet-Draft                  SCION DP                      March 2024


             +=========+====================================+
             | Decimal | Option Type                        |
             +=========+====================================+
             | 0       | Pad1 (see Section 2.3.1.1.1)       |
             +---------+------------------------------------+
             | 1       | PadN (see Section 2.3.1.1.2)       |
             +---------+------------------------------------+
             | 2       | SCION Packet Authenticator Option. |
             |         | Only used by the End-to-End        |
             |         | Options header (experimental).     |
             +---------+------------------------------------+
             | 253     | Used for experimentation and       |
             |         | testing                            |
             +---------+------------------------------------+
             | 254     | Used for experimentation and       |
             |         | testing                            |
             +---------+------------------------------------+
             | 255     | Reserved                           |
             +---------+------------------------------------+

              Table 4: Option types of SCION Options header

   *  OptDataLen: Unsigned 8-bit integer denoting the length of the
      OptData field of this option in bytes.

   *  OptData: Variable-length field.  Option-type specific data.

   The options within a header MUST be processed strictly in the order
   they appear in the header.  This is to prevent a receiver from, for
   example, scanning through the header looking for a specific option
   and processing this option prior to all preceding ones.

   Individual options may have specific alignment requirements, to
   ensure that multibyte values within the OptData fields have natural
   boundaries.  The alignment requirement of an option is specified
   using the notation "xn+y".  This means that the OptType MUST appear
   at an integer multiple of x bytes from the start of the header, plus
   y bytes.  For example:

   *  2n: means any 2-bytes offset from the start of the header.

   *  4n+2: means any 4-bytes offset from the start of the header, plus
      2 bytes.

   There are two padding options to align subsequent options and to pad
   out the containing header to a multiple of 4 bytes in length - for
   details, see below.  All SCION implementations MUST recognize these
   padding options.



de Kater, et al.        Expires 5 September 2024               [Page 27]

Internet-Draft                  SCION DP                      March 2024


2.3.1.1.1.   Pad1 Option

   Alignment requirement: none.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

                Figure 13: TLV-encoded options - Pad1 option

   *Note:* The format of the Pad1 option is a special case - it does not
   have length and value fields.

   The Pad1 option is used to insert 1 byte of padding into the Options
   field of an extension header.  If more than one byte of padding is
   required, the PadN option SHOULD be used, rather than multiple Pad1
   options.  See the next section for more information on the PadN
   option.

2.3.1.1.2.   PadN Option

   Alignment requirement: none.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |  OptDataLen   |            OptData            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 14: TLV-encoded options - PadN option

   The PadN option is used to insert two or more bytes of padding into
   the Options field of an extension header.  For N bytes of padding,
   the OptDataLen field contains the value N-2, and the OptData consists
   of N-2 zero-valued bytes.

2.4.  Upper-Layer Protocol Issues

2.4.1.   Pseudo Header for Upper-Layer Checksum

   Any transport or other upper-layer protocol that includes addresses
   from the SCION header in the checksum computation MUST use the
   following pseudo header:




de Kater, et al.        Expires 5 September 2024               [Page 28]

Internet-Draft                  SCION DP                      March 2024


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+
|            DstISD             |                               |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + SCION|
|                             DstAS                             |   ad-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ dress|
|            SrcISD             |                               |  hea-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +   der|
|                             SrcAS                             |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |
|                    DstHostAddr (variable Len)                 |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |
|                    SrcHostAddr (variable Len)                 |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+
|                    Upper-Layer Packet Length                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      zero                     |  Next Header  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 15: Layout of the pseudo header for the upper-layer checksum

   *  DstISD, SrcISD, DstAS, SrcAS, DstHostAddr, SrcHostAddr: These
      values are taken from the SCION address header.

   *  Upper-Layer Packet Length: The length of the upper-layer header
      and data.  Some upper-layer protocols define headers that carry
      the length information explicitly (e.g., UDP).  This information
      is used as the upper-layer packet length in the pseudo header for
      these protocols.  The remaining protocols, which do not carry the
      length information directly (e.g., the SCION Control Message
      Protocol SCMP), use the value from the PayloadLen field in the
      SCION common header, minus the sum of the extension header
      lengths.

   *  Next Header: The protocol identifier associated with the upper-
      layer protocol (e.g., 17 for UDP - see also Appendix "Assigned
      SCION Protocol Numbers").  This field can differ from the NextHdr
      field in the SCION common header, if extensions are present.

3.  Life of a SCION Data Packet

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




de Kater, et al.        Expires 5 September 2024               [Page 29]

Internet-Draft                  SCION DP                      March 2024


   To keep it brief, the example illustrates an intra-ISD case, i.e.,
   all communication happens within a single ISD.  As the sample ISD
   only consists of one core AS, the end-to-end path only includes an
   up-path and down-path segment.  In the case of inter-ISD forwarding,
   the complete end-to-end path from source endpoint to destination
   endpoint would always require a core-path segment, too.  But this
   makes no difference for the forwarding process, which works the same
   in an intra- and inter-ISD context.  We therefore abstain from
   describing the inter-ISD forwarding.

3.1.   Description

                       +--------------------+
                       |                    |
                       |        AS 1        |
                       |                    |
                       |                    |
                       |     198.51.100.4 .-+. i1b (1-1,198.51.100.17)
                       |          +------( R3 )---+
                      .+-.        |       `-+'    |
             +-------( R2 )-------+         |     |
             |    i1a `+-' 198.51.100.1     |     |
             |         |                    |     |
             |         +--------------------+     | (1-3,198.51.100.18)
             |                                    | i3a
             |                                   .+-.
       i2a .-+.                          +------( R4 )--------+
   +------( R1 )--------+                |       `-+'         |
   |       `-+'         |                |         |192.0.2.34|
   |         |203.0.113.17               |         |          |
   |         |          |                |         |    AS 3  |
   |         |    AS 2  |                |         |          |
   |         |          |                |       +---+        |
   |       +---+        |                |       | B |        |
   |       | A |        |                |       +---+        |
   |       +---+        |                |   1-3,192.0.2.7    |
   |  1-2,203.0.113.6   |                |                    |
   |                    |                +--------------------+
   +--------------------+

        Figure 16: Sample topology to illustrate the life cycle of a
       SCION packet.  AS 1 is the core AS of ISD 1, and AS 2 and AS 3
                        are non-core ASes of ISD 1.

   Based on the network topology in Figure 16 above, this example shows
   the path of a SCION packet sent from source endpoint A to destination
   endpoint B, and how it will be processed by each router on the path.
   This is done by means of simplified snapshots of the packet header



de Kater, et al.        Expires 5 September 2024               [Page 30]

Internet-Draft                  SCION DP                      March 2024


   after each such processing step.  These snapshots, which are depicted
   in tables, show the most relevant information of the header, i.e.,
   the SCION path and IP encapsulation for local communication.

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

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

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

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

   To obtain an end-to-end forwarding path from the source AS to the
   destination AS, source endpoint A combines the two path segments into
   the resulting SCION forwarding path, which contains the two info
   fields _IF1_ and _IF2_ and the hop fields (0,i2a), (i1a,0), (0,i1b),
   and (i3a,0).

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

   Source endpoint A now adds this end-to-end forwarding path to the
   header of the packet that A wants to send to destination endpoint B,
   and starts transferring the packet.  The following section describes
   what happens with the SCION packet header on the packet's way from A
   to B.









de Kater, et al.        Expires 5 September 2024               [Page 31]

Internet-Draft                  SCION DP                      March 2024


3.3.   Step-by-Step Explanation

   This section explains the packet header modifications at each router,
   based on the network topology in Figure 16 above.  Each step includes
   a table that represents a simplified snapshot of the packet header at
   the end of this specific step.  Regarding the notation used in the
   figure/tables, each SRC and DST entry should be read as router (or
   endpoint) followed by its address.  The current info field (with
   metadata on the current path segment) in the SCION header is depicted
   italic/cursive in the tables.  The current hop field, representing
   the current AS, is shown bold.  The snapshot tables also include
   references to IP/UDP addresses.

   *Note:* In this context, a border router is called *ingress* border
   router when it refers to an entrance border router to an AS, as seen
   from the direction of travel of the SCION packet.  So in the context
   here, the ingress border router is the _(packet) incoming_ border
   router.  A border router is called *egress* border router when it
   refers to an exit border router of an AS, as seen from the direction
   of travel of the SCION packet.  So in this context, the egress border
   router is the _(packet) leaving_ border router.

   *  _Step 1_
      *A->R1*: The SCION-enabled source endpoint A in AS 2 creates a new
      SCION packet destined for destination endpoint B in AS 3, with
      payload P.  Endpoint A sends the packet (for the chosen forwarding
      path) to the next SCION router as provided by its control service,
      which is in this case R1.  A encapsulates the SCION packet into an
      underlay UDP/IPv4 header for the local delivery to R1, utilizing
      AS 2's internal routing protocol.  The current info field is
      _IF1_. Upon receiving the packet, R1 will forward the packet on
      the egress interface that endpoint A has included into the first
      hop field of the SCION header.


















de Kater, et al.        Expires 5 September 2024               [Page 32]

Internet-Draft                  SCION DP                      March 2024


        +============+===========================================+
        | A -> R1    |                                           |
        +============+===========================================+
        | SCION      | SRC = 1-2,203.0.113.6 (source endpoint A) |
        +------------+-------------------------------------------+
        |            | DST = 1-3,192.0.2.7 (dest. endpoint B)    |
        +------------+-------------------------------------------+
        |            | PATH =                                    |
        +------------+-------------------------------------------+
        |            | - _IF1_ *(0,i2a)* (i1a,0)                 |
        +------------+-------------------------------------------+
        |            | - IF2 (0,i1b) (i3a,0)                     |
        +------------+-------------------------------------------+
        | UDP        | P_S = 30041, P_D = 30041                  |
        +------------+-------------------------------------------+
        | IP         | SRC = 203.0.113.6 (endpoint A)            |
        +------------+-------------------------------------------+
        |            | DST = 203.0.113.17 (router R1)            |
        +------------+-------------------------------------------+
        | Link layer | SRC=A, DST=R1                             |
        +------------+-------------------------------------------+

                    Table 5: Snapshot header - step 1

   *  _Step 2_
      *R1->R2*: Router R1 inspects the SCION header and considers the
      relevant info field of the specified SCION path, which is the info
      field indicated by the current info field pointer.  In this case,
      it is the first info field _IF1_. The current hop field is the
      first hop field (0,i2a), which instructs router R1 to forward the
      packet on its interface i2a.  After reading the current hop field,
      R1 moves the pointer forward by one position to the second hop
      field (i1a,0).  Note that, at this point, no underlay IP header is
      necessary, since the routers R1 and R2 are directly connected over
      layer 2.

      *Note:* Although technically there is no need for a UDP/IP
      underlay if two routers are directly connected, the SCION
      implementation always uses a UDP/IP underlay in practice.  This is
      to enable a common interface for all routers.











de Kater, et al.        Expires 5 September 2024               [Page 33]

Internet-Draft                  SCION DP                      March 2024


        +============+===========================================+
        | R1 -> R2   |                                           |
        +============+===========================================+
        | SCION      | SRC = 1-2,203.0.113.6 (source endpoint A) |
        +------------+-------------------------------------------+
        |            | DST = 1-3,192.0.2.7 (dest. endpoint B)    |
        +------------+-------------------------------------------+
        |            | PATH =                                    |
        +------------+-------------------------------------------+
        |            | - _IF1_ (0,i2a) *(i1a,0)*                 |
        +------------+-------------------------------------------+
        |            | - IF2 (0,i1b) (i3a,0)                     |
        +------------+-------------------------------------------+
        | Link layer | SRC=R1, DST=R2                            |
        +------------+-------------------------------------------+

                    Table 6: Snapshot header - step 2

   *  _Step 3_
      *R2->R3*: When receiving the packet, router R2 of core AS 1 checks
      whether the packet has been received through the ingress interface
      i1a as specified by the current hop field.  Otherwise, the packet
      is dropped by router R2.  The router notices that it has consumed
      the last hop field of the current path segment, and hence moves
      the pointer from the current info field to the next info field
      _IF2_. The corresponding current hop field is (0,i1b), which
      contains egress interface i1b.  R2 maps the i1b interface ID to
      egress router R3, it therefore encapsulates the SCION packet
      inside an intra-AS underlay IP packet with the address of R3 as
      the underlay destination.





















de Kater, et al.        Expires 5 September 2024               [Page 34]

Internet-Draft                  SCION DP                      March 2024


        +============+===========================================+
        | R2 -> R3   |                                           |
        +============+===========================================+
        | SCION      | SRC = 1-2,203.0.113.6 (source endpoint A) |
        +------------+-------------------------------------------+
        |            | DST = 1-3,192.0.2.7 (dest. endpoint B)    |
        +------------+-------------------------------------------+
        |            | PATH =                                    |
        +------------+-------------------------------------------+
        |            | - IF1 (0,i2a) (i1a,0)                     |
        +------------+-------------------------------------------+
        |            | - _IF2_ *(0,i1b)* (i3a,0)                 |
        +------------+-------------------------------------------+
        | UDP        | P_S = 30041, P_D = 30041                  |
        +------------+-------------------------------------------+
        | IP         | SRC = 198.51.100.1 (router R2)            |
        +------------+-------------------------------------------+
        |            | DST = 198.51.100.4 (router R3)            |
        +------------+-------------------------------------------+
        | Link layer | SRC=R2, DST=R3                            |
        +------------+-------------------------------------------+

                    Table 7: Snapshot header - step 3

   *  _Step 4_
      *R3->R4*: Router R3 inspects the current hop field in the SCION
      header, uses interface i1b to forward the packet to its neighbor
      SCION router R4 of AS 3, and moves the current hop-field pointer
      forward.  It adds an IP header to reach R4.






















de Kater, et al.        Expires 5 September 2024               [Page 35]

Internet-Draft                  SCION DP                      March 2024


        +============+===========================================+
        | R3 -> R4   |                                           |
        +============+===========================================+
        | SCION      | SRC = 1-2,203.0.113.6 (source endpoint A) |
        +------------+-------------------------------------------+
        |            | DST = 1-3,192.0.2.7 (dest. endpoint B)    |
        +------------+-------------------------------------------+
        |            | PATH =                                    |
        +------------+-------------------------------------------+
        |            | - IF1 (0,i2a) (i1a,0)                     |
        +------------+-------------------------------------------+
        |            | - _IF2_ (0,i1b) *(i3a,0)*                 |
        +------------+-------------------------------------------+
        | UDP        | P_S = 30041, P_D = 30041                  |
        +------------+-------------------------------------------+
        | IP         | SRC = 1-1,198.51.100.17 (router R3)       |
        +------------+-------------------------------------------+
        |            | DST = 1-3,198.51.100.18 (router R4)       |
        +------------+-------------------------------------------+
        | Link layer | SRC=R3, DST=R4                            |
        +------------+-------------------------------------------+

                    Table 8: Snapshot header - step 4

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















de Kater, et al.        Expires 5 September 2024               [Page 36]

Internet-Draft                  SCION DP                      March 2024


        +============+===========================================+
        | R4 -> B    |                                           |
        +============+===========================================+
        | SCION      | SRC = 1-2,203.0.113.6 (source endpoint A) |
        +------------+-------------------------------------------+
        |            | DST = 1-3,192.0.2.7 (dest. endpoint B)    |
        +------------+-------------------------------------------+
        |            | PATH =                                    |
        +------------+-------------------------------------------+
        |            | - IF1 (0,i2a) (i1a,0)                     |
        +------------+-------------------------------------------+
        |            | - _IF2_ (0,i1b) *(i3a,0)*                 |
        +------------+-------------------------------------------+
        | UDP        | P_S = 30041, P_D = 30041                  |
        +------------+-------------------------------------------+
        | IP         | SRC = 192.0.2.34 (router R4)              |
        +------------+-------------------------------------------+
        |            | DST = 192.0.2.7 (endpoint B)              |
        +------------+-------------------------------------------+
        | Link layer | SRC=R4, DST=B                             |
        +------------+-------------------------------------------+

                    Table 9: Snapshot header - step 5

   When destination endpoint B wants to respond to source endpoint A, it
   can just swap the source and destination addresses in the SCION
   header, reverse the SCION path, and set the pointers to the info and
   hop fields at the beginning of the reversed path (see also
   Section 2.2.3.4).

4.  Path Authorization

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

   SCION uses cryptographic mechanisms to efficiently provide path
   authorization.  The mechanisms are based on _symmetric_ cryptography
   in the form of Message Authentication Codes (MACs) in the data plane
   to secure forwarding information encoded in hop fields.  This chapter
   first explains how hop field MACs are computed, then how they are
   validated as they traverse the network.





de Kater, et al.        Expires 5 September 2024               [Page 37]

Internet-Draft                  SCION DP                      March 2024


4.1.  Authorizing Segments through Chained MACs

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

4.1.1.   Hop Field MAC Computation

   The MAC in the hop fields of a SCION path has two purposes:

   *  Preventing malicious endpoints from illegally adding, removing, or
      reordering hops within a path segment created during beaconing in
      the control plane.

   *  Authentication of the information contained in the hop field
      itself, in particular the ExpTime, ConsIngress, and ConsEgress.

   To fulfill the above purposes, the MAC for the hop field of AS_i
   includes both the components of the current hop field HF_i and an
   aggregation of the path segment identifier and all preceding hop
   fields/entries in the path segment.  The aggregation is a 16-bit XOR-
   sum of the path segment identifier and the hop field MACs.

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

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

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




de Kater, et al.        Expires 5 September 2024               [Page 38]

Internet-Draft                  SCION DP                      March 2024


   In the following, the computation of the hop field MAC as well as the
   accumulator field Acc is explained.

   *Note:* The algorithm used by SCION to compute the hop field MAC is
   based on the AES-CMAC algorithm, truncated to 48-bits - see also
   [RFC4493].  In principle, the computation of the MAC is an AS-
   specific choice; only the control service and routers of the AS need
   to agree on keys, algorithm, and input for the MAC.  However, note
   that we do not provide nor specify any mechanism to coordinate AS-
   specific choices between the routers and the control services of the
   AS.

4.1.1.1.   MAC - Definition

   *  Consider a path segment with "n" hops, containing ASes AS_0, ... ,
      AS_(n-1), with forwarding keys K_0, ... , K_(n-1) in this order.

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

   The MAC_i of the hop field of AS_i is now calculated based on the
   following definition:

   MAC_i =
   Ck_i (SegID XOR MAC_0 [:2] ... XOR MAC_(i-1) [:2], Timestamp,
   ExpTime_i, ConsIngress_i, ConsEgress_i)

   where

   *  k_i = The forwarding key k of the current AS_i

   *  Ck_i (...) = Checksum C over (...) computed with forwarding key
      k_i

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

   *  XOR = The bitwise "exclusive or" operation

   *  MAC_i [:2] = The hop field MAC for AS_i, truncated to 2 bytes

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

   *  ExpTime_i, ConsIngress_i, ConsEgress_i = The content of the hop
      field HF_i




de Kater, et al.        Expires 5 September 2024               [Page 39]

Internet-Draft                  SCION DP                      March 2024


   The above definition implies that the current MAC is based on the
   XOR-sum of the truncated MACs of all preceding hop fields in the path
   segment as well as the path segment's SegID.  In other words, the
   current MAC is _chained_ to all preceding MACs.

4.1.1.2.   Layout of the Input Data for the MAC Calculation

   Figure 17 below shows the layout of the input data to calculate the
   hop field MAC in the data plane.  The input layout represents the 8
   bytes of the info field and the first 8 bytes of the hop field, with
   some fields zeroed out.

   Note that the MAC field itself is only 6 bytes long - see also
   Section 2.2.3.2.4.

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+
|               0               |           Acc                 |   Hop|
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Field|
|                           Timestamp                           |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -----+
|       0       |    ExpTime    |          ConsIngress          |  Info|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field|
|          ConsEgress           |               0               |      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+

         Figure 17: Input data to calculate the hop field MAC

4.1.1.3.   Accumulator Acc - Definition

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |r r r r r r P C|      RSV      |             Acc               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





de Kater, et al.        Expires 5 September 2024               [Page 40]

Internet-Draft                  SCION DP                      March 2024


        Figure 18: The Info Field of a specific path segment in the
         packet header, with the updatable accumulator field `Acc`.

   This is how it works:

   Section 4.1.1.1 defines MAC_i as follows:

   MAC_i =
   Ck_i (SegID XOR MAC_0 [:2] ... XOR MAC_(i-1) [:2], Timestamp,
   ExpTime_i, ConsIngress_i, ConsEgress_i)

   In the data plane, the expression SegID XOR MAC_0 [:2] ... XOR
   MAC_i-1 [:2] is replaced by Acc_i.  This results in the following
   alternative procedure for the computation of MAC_i used in the data
   plane:

   MAC_i = Ck_i (Acc_i, Timestamp, ExpTime_i, ConsIngress_i,
   ConsEgress_i)

   During forwarding in the data plane, each AS_i updates the Acc field
   in the packet header, such, that it contains the correct input value
   of the Accumulator Acc for the next AS in the path segment to be able
   to calculate the MAC over its hop field.  Note that the correct input
   value of the Acc field depends on the direction of travel.

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

   Acc_(i+1) = Acc_i XOR MAC_i [:2]

   *  XOR = The bitwise "exclusive or" operation

   *  MAC_i [:2] = The hop field MAC for the current AS_i, truncated to
      2 bytes

4.1.2.   Peering Links

   The above described computation of a hop field MAC does not apply to
   a peering hop field, i.e., to a hop field that allows transiting from
   a child interface/link to a peering interface/link.

   The reason for this is that the MACs of the hop fields "after" the
   peering hop field (in beaconing direction) are not chained to the MAC
   of the peering hop field, but to the MAC of the main hop field in the
   corresponding AS entry.  To make this work, the MAC of the peering
   hop field is also chained to the MAC of the main hop field - this
   allows to validate the chained MAC for both the peering hop field and
   the following hop fields, by using the same Acc field value.



de Kater, et al.        Expires 5 September 2024               [Page 41]

Internet-Draft                  SCION DP                      March 2024


   This results in the following definition for the calculation of the
   MAC for a peering hop field.

   The Control Plane Internet-Draft defines a peering hop field as
   follows:

   hop field^Peer_i = (ExpTime^Peer_i, ConsIngress^Peer_i,
   ConsEgress^Peer_i, MAC^Peer_i)

   This definition, the general definition of a hop field MAC and the
   explanation above leads to the following definition of the MAC for a
   peering hop field^Peer_i:

   MAC^Peer_i =
   Ck^Peer_i (SegID XOR MAC_0 [:2] ... XOR MAC_i [:2], Timestamp,
   ExpTime^Peer_i, ConsIngress^Peer_i, ConsEgress^Peer_i)

   *Note:* The XOR-sum of the MACs in the formula of the peering hop
   field *also includes* the MAC of the main hop field (whereas for the
   calculation of the MAC for the main hop field itself only the XOR-sum
   of the _previous_ MACs is used).

   *Note:* The Control-Plane Internet-Draft is available here:
   [I-D.scion-cp].

4.2.   Path Initialization and Packet Processing

   As is described in Section 2.1, the path header of the data-plane
   packets only contains a sequence of info fields and hop fields
   without any additional data from the corresponding PCBs.  Also, the
   SCION path does not contain any AS numbers (except for the source and
   destination ASes), and there is no field explicitly defining the type
   of each segment (up, core, or down).  This chapter describes the
   required steps for the source endpoint and each SCION router to
   ensure that a data packet only traverses authorized segments.  The
   chapter first specifies the initialization of a path at the source
   endpoint, followed by the steps that the SCION routers needs to
   perform when a data-plane packet traverses an AS on its way to the
   destination.

4.2.1.   Initialization at Source Endpoint

   The source endpoint needs to initialize a path correctly for the
   SCION routers to be able to verify the hop fields in the data plane.
   To this end, the source endpoint MUST perform the following steps:

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



de Kater, et al.        Expires 5 September 2024               [Page 42]

Internet-Draft                  SCION DP                      March 2024


   2.  Extract the info fields and hop fields from the different path
       segments that together build the end-to-end path to the
       destination endpoint.  Then insert the relevant information from
       the path segments' info and hop fields into the corresponding
       InfoFields and Hopfields, respectively, in the data packet
       header.

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

       *Note:* As already stated above, the type of segment is not
       visible directly in the forwarding path but can be inferred from
       flags and other information.  See also Section 4.2.2.

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

       *  The Peering flag P MUST be set to "1" for up- and down-
          segments if, and only if, the path contains a peering hop
          field.

       *  The field Acc field is an updatable field.  It is used to
          compute the MAC over the current hop field.  The value of the
          field Acc field corresponds to the value of the Accumulator
          Acc_i for AS_i.  It is initialized based on the location of
          the sender in relation to path construction.

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

       *  *Use case 1*
          The path segment is traversed in construction direction and
          includes no peering hop field.  It starts at the _i_-th AS of
          the full segment discovered in beaconing.  In this case:

          -  The Peering flag P = "0"

          -  The Construction Direction flag C = "1"

          -  The value of the Acc = Acc_i.  For more details, see
             Section 4.1.1.3.



de Kater, et al.        Expires 5 September 2024               [Page 43]

Internet-Draft                  SCION DP                      March 2024


       *  *Use case 2*
          The path segment is traversed in construction direction and
          includes a peering hop field (which is the first hop field of
          the segment).  It starts at the _i_-th AS of the full segment
          discovered in beaconing.  In this case:

          -  The Peering flag P = "1"

          -  The Construction Direction flag C = "1"

          -  The value of the Acc = Acc_(i+1).  For more details, see
             Section 4.1.1.3.

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

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

          -  The Construction Direction flag C = "0"

          -  The value of the Acc = Acc_(n-1).  This is because seen
             from the direction of beaconing, the source endpoint is the
             last AS in the path segment.  For more details, see
             Section 4.1.1.1 and Section 4.1.1.3.

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

4.2.2.   Processing at Routers

   During forwarding, each AS_i verifies the path contained in the
   packet header with the help of the current value of the MAC in the
   current hop field, and the current value of the Accumulator in the
   Acc field of the current info field.  Additionally, each AS has to
   correctly set the value of the Accumulator in the Acc field for the
   next AS to be able to verify its hop field.  The exact operations
   differ based on the location of the AS on the path.









de Kater, et al.        Expires 5 September 2024               [Page 44]

Internet-Draft                  SCION DP                      March 2024


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

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

   *Note:* In this context, a border router is called *ingress* border
   router when it refers to an entrance border router to an AS, as seen
   from the direction of travel of the SCION packet.  So in the context
   here, the ingress border router is the _(packet) incoming_ border
   router.  A border router is called *egress* border router when it
   refers to an exit border router of an AS, as seen from the direction
   of travel of the SCION packet.  So in this context, the egress border
   router is the _(packet) leaving_ border router.

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

























de Kater, et al.        Expires 5 September 2024               [Page 45]

Internet-Draft                  SCION DP                      March 2024


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

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

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

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

                                                      Processing against
                                                            construction
                                                               direction

     Figure 19: A simplified representation of the processing at
                     routers in both directions.

4.2.2.1.  Steps Ingress Border Router

   This section describes the steps that a SCION ingress border router
   MUST perform when it receives a SCION packet.

   1.  Check that the interface through which the packet was received is
       equal to the ingress interface in the current hop field.

   2.  Check that the current hop field is not expired and within its
       validity period.









de Kater, et al.        Expires 5 September 2024               [Page 46]

Internet-Draft                  SCION DP                      March 2024


   3.  The next steps depend on the direction of travel and whether this
       segment includes a peering hop field.  Both features are
       indicated by the settings of the Construction Direction flag C
       and the Peering flag P in the current info field.  Therefore,
       check the settings of both flags.  The following combinations are
       possible:

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

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

          -  *Use case 1*
             The path segment includes *no peering hop field* (P = "0").
             In this case, the ingress border router MUST take the
             following step(s):

             o  Compute the value of the Accumulator Acc as follows:

                Acc = Acc_(i+1) XOR MAC_i
                where
                Acc_(i+1) = the current value of the field Acc in the
                current info field
                MAC_i = the value of MAC_i in the current hop field
                representing AS_i

                *Note:* In the case described here the packet travels
                against direction of beaconing.  That is, the packet
                comes from AS_(i+1) and is going to enter AS_i.  This
                means that the Acc field of this incoming packet
                represents the value of Accumulator Acc_(i+1).  However,
                to compute the MAC_i for the current AS_i, we need the
                value of Accumulator Acc_i (see Section 4.1.1.3).
                Because the border router knows that the formula for
                Acc_(i+1) = Acc_i XOR MAC_i [:2] (see also
                Section 4.1.1.3), and because the values of Acc_(i+1)
                and MAC_i are known, the router will be able to recover
                the value Acc_i based on the just-mentioned formula for
                Acc.

             o  Replace the current value of the field Acc in the
                current info field with the newly calculated value of
                Acc.






de Kater, et al.        Expires 5 September 2024               [Page 47]

Internet-Draft                  SCION DP                      March 2024


             o  Compute the MAC^Verify_i over the hop field of the
                current AS_i.  For this, use the formula in
                Section 4.1.1.1, but replace SegID XOR MAC_0[:2] ... XOR
                MAC_i-1 [:2] in the formula with the value of the
                accumulator Acc as just set in the Acc field in the
                current info field.

             o  Check that the MAC_i in the current hop field matches
                the just-calculated MAC^Verify_i.  If yes, it is fine.
                Otherwise, drop the packet, and reply with a "parameter
                problem" type of SCMP message.

             o  Check whether the current hop field is the last hop
                field in the path segment.  For this, look at the value
                of the current SegLen and other metadata in the path
                meta header.  If yes, increment both CurrInf and CurrHF
                in the path meta header.  Proceed with step 4.

          -  *Use case 2*
             The path segment includes a *peering hop field* (P = "1"),
             but the current hop is *not* the peering hop, that is, the
             current hop field is *not* the _last_ hop field of the
             segment, seen from the direction of travel - this can be
             determined by looking at the value of the current SegLen
             and other metadata in the path meta header.  In this case,
             the ingress border router needs to perform the steps
             previously described for the path segment without peering
             hop field.  However, the border router MUST NOT increment
             CurrInf and MUST NOT increment CurrHF in the path meta
             header.  Proceed with step 4.

          -  *Use case 3*
             The path segment includes a *peering hop field* (P = "1"),
             and the current hop field _is_ the peering hop field.  This
             would be the case if the current hop field is the _last_
             hop field of the segment, seen from the direction of travel
             - to find out whether this is true, check the value of the
             current SegLen and other metadata in the path meta header.
             In this case, the ingress border router MUST take the
             following step(s):

             o  Compute MAC^Peer_i.  For this, use the formula in
                Section 4.1.2, but replace SegID XOR MAC_0[:2] ... XOR
                MAC_i [:2] in the formula with the value of the
                accumulator Acc as set in the Acc field in the current
                info field (this is the value of the accumulator Acc as
                it comes with the packet).




de Kater, et al.        Expires 5 September 2024               [Page 48]

Internet-Draft                  SCION DP                      March 2024


             o  Check that the MAC_i in the current hop field matches
                the just-calculated MAC^Peer_i.  If yes, it is fine.
                Otherwise, drop the packet, and reply with a "parameter
                problem" type of SCMP message.

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

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

   *Note:* For more information on the path meta header, see
   Section 2.2.3.2.1.

4.2.2.2.  Steps Egress Border Router

   This section describes the steps that a SCION egress border router
   MUST perform when it receives a SCION packet.

   1.  Parse the SCION packet.

   2.  The next steps depend on the direction of travel and whether this
       segment includes a peering link.  Both features are indicated by
       the settings of the Construction Direction flag C and the Peering
       flag P in the currently valid info field.  Therefore, first check
       the settings of both flags.  The following use cases are
       possible:

       *  *Use case 1*
          The packet traverses the path segment in *construction
          direction* (C = "1").  The path segment either includes *no
          peering hop field* (P = "0"), or the path segment does include
          a *peering hop field* (P = "1"), but the current hop is *not*
          the peering hop, that is, the current hop field is *not* the
          _first_ hop field of the segment, seen from the direction of
          travel.  To check whether this is true, look at the value of
          the current SegLen and other metadata in the path meta header.
          In this case, the egress border router MUST take the following
          step(s):

          -  Compute MAC^Verify_i over the hop field of the current
             AS_i.  For this, use the formula in Section 4.1.1.1, but
             replace SegID XOR MAC_0[:2] ... XOR MAC_i-1 [:2] in the
             formula with the value of the accumulator Acc as set in the
             Acc field in the current info field.





de Kater, et al.        Expires 5 September 2024               [Page 49]

Internet-Draft                  SCION DP                      March 2024


          -  Check that the just-calculated MAC^Verify_i matches MAC_i
             in the hop field of the current AS_i.  If yes, it is fine.
             Otherwise, drop the packet, and reply with a "parameter
             problem" type of SCMP message.

          -  Compute the value of Acc_(i+1).  For this, use the formula
             in Section 4.1.1.3.  Replace Acc_i in the formula with the
             current value of the accumulator Acc as set in the Acc
             field of the current info field.

          -  Replace the value of the Acc field in the current info
             field with the just-calculated value of Acc_(i+1).

          -  Proceed with step 3.

       *  *Use case 2*
          The packet traverses the path segment in *construction
          direction* (C = "1").  The path segment includes a *peering
          hop field* (P = "1"), and the current hop field _is_ the
          peering hop field.  This would be the case if the current hop
          field is the _first_ hop field of the segment, seen from the
          direction of travel - to find out whether this is true, check
          the value of the current SegLen and other metadata in the path
          meta header.  In this case, the egress border router MUST take
          the following steps:

          -  Compute MAC^Peer_i.  For this, use the formula in
             Section 4.1.2, but replace SegID XOR MAC_0 [:2] ... XOR
             MAC_i [:2] with the value in the Acc field of the current
             info field.

          -  Check that the MAC_i in the hop field of the current AS_i
             matches the just-calculated MAC^Peer_i.  If yes, it is fine
             - proceed with step 3.  Otherwise, drop the packet, and
             reply with a "parameter problem" type of SCMP message.

       *  *Use case 3*
          The packet traverses the path segment *against construction
          direction* (C = "0" and P = "0" or "1").  In this case,
          proceed with the next step, step 3.

   3.  Increment CurrHF in the path meta header.

   4.  Forward the packet to the neighbor AS.

   *Note:* For more information on the path meta header, see
   Section 2.2.3.2.1.




de Kater, et al.        Expires 5 September 2024               [Page 50]

Internet-Draft                  SCION DP                      March 2024


5.  Security Considerations

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

5.1.  Path Authorization

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

   The main protection mechanism here is the hop field MAC (see
   Section 4.1), authenticating the hop field content, consisting of
   ingress/egress interface identifiers, creation and expiration
   timestamp and, virtually, the preceding hop field MACs in the path
   segment.  Recall that each hop field MAC is computed using the
   respective AS's secret forwarding key, which is shared across the
   SCION routers and control plane services within each AS.

5.1.1.  Forwarding key compromise

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

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






de Kater, et al.        Expires 5 September 2024               [Page 51]

Internet-Draft                  SCION DP                      March 2024


5.1.2.  Forging hop field MAC

   As a second method to break path authorization is to directly forge a
   hop field in an online attack, using the router as an oracle to
   determine the validity of the hop field MAC.  The adversary needs to
   send one packet per guess for verification.  For a 6-byte MAC, the
   adversary would need an expected 2^47 (~140 trillion) tries to
   successfully forge the MAC of a single hop field.  As the router only
   checks MACs during the encoded validity period of the hop field,
   which is limited by the packet header format to at most 24 hours,
   these tries need to occur in a limited time period.  This results in
   a seemingly infeasible number of ~1.6e9 guesses per second.  In the
   unlikely case that an online brute-force attack succeeds, the
   obtained hop field can be used until its inevitable expiration after
   the just mentioned 24 hour limit.

5.1.3.  Path Splicing

   In a path-splicing attack, an adversary source endpoint takes valid
   hop fields of multiple path segments and splices them together to
   obtain a new unauthorized path.  However, SCION’s MAC-chaining
   mechanism prevents from this kind of attacks.  MAC validation for
   spliced segments would fail at SCION routers and the corresponding
   packets would be dropped.  For details, see Section 4.1.

5.2.   On-Path Attacks

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

5.2.1.  Modification of the Path Header

   An on-path adversary could modify the SCION path header, and replace
   the remaining part of path segments to the destination with different
   segments.  Such replaced segments must include authorized segments,
   as otherwise the packet would be simply dropped on its way to the
   destination.  The already traversed portion of the current segment
   and past segments can also be modified by the adversary (for
   instance, deleting and adding valid and invalid hop fields).  On
   reply packets from the destination, the adversary can transparently



de Kater, et al.        Expires 5 September 2024               [Page 52]

Internet-Draft                  SCION DP                      March 2024


   revert the changes to the path header again.  For instance, if an
   adversary M is an intermediate AS on the path of a packet from A to
   B, then M can replace the packet’s past path (leading up to, but not
   including M).  The new path may not be a valid end-to-end path.
   However, when B reverses the path and sends a reply packet, that
   packet would go via M, which can then transparently change the
   invalid path back to the valid path to A.  In addition, the endpoint
   address header can also be modified.

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

   Moreover, packet integrity protection is not enough if there are two
   colluding adversaries on the path.  These colluding adversaries can
   forward the packet between them using a different path than selected
   by the source endpoint: The first on-path attacker remodels the
   packet header arbitrarily, and the second on-path attacker changes
   the path back to the original source-selected path, such that the
   integrity check by the destination endpoint succeeds.  To prevent
   this attack and to defend against multiple on-path adversaries in
   general, proof of transit is required, which is not in scope for this
   document.

5.3.  Off-Path Attacks

   SCION's path-awareness limits the abilities of an off-path adversary
   to influence forwarding in the data plane.  Once a packet is "in
   flight", it will follow its set route, no matter what an adversary
   may do.  An adversary can attempt to disrupt the connectivity of said
   path by flooding a link with excessive traffic (see Section 5.4
   below).  After detecting congestion, the endpoint can switch to
   another, non-congested path for subsequent packets.

5.4.  Volumetric Denial of Service Attacks

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

   SCION provides protection against certain reflection-based DoS
   attacks.  Here, the adversary sends requests to a server with the
   source address set to the address of the victim.  The server will
   send a reply, typically larger than the request, to the victim.  As



de Kater, et al.        Expires 5 September 2024               [Page 53]

Internet-Draft                  SCION DP                      March 2024


   long as the attacker and the victim are located in different ASes,
   this can be prevented in SCION.  The reply packets are simply
   returned along reversed path to the actual sender, regardless of the
   source address information.  Thus, the reflected will be forwarded to
   the attackers AS (where it will be discarded because the destination
   AS does not match).

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

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

6.  IANA Considerations

   This document has no IANA actions.

   The SCION AS and ISD number are SCION-specific numbers.  They are
   currently allocated by Anapaya Systems, a provider of SCION-based
   networking software and solutions (see Anapaya ISD AS assignments
   (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

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

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







de Kater, et al.        Expires 5 September 2024               [Page 54]

Internet-Draft                  SCION DP                      March 2024


   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.

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

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/rfc/rfc2474>.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, DOI 10.17487/RFC2711, October 1999,
              <https://www.rfc-editor.org/rfc/rfc2711>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/rfc/rfc3168>.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
              2006, <https://www.rfc-editor.org/rfc/rfc4493>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5880>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5881>.

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

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/rfc/rfc8200>.





de Kater, et al.        Expires 5 September 2024               [Page 55]

Internet-Draft                  SCION DP                      March 2024


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

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-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", 2024, <https://datatracker.ietf.org/doc/draft-
              dekater-scion-pki/>.

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

Acknowledgments

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

Assigned SCION Protocol Numbers

   This appendix lists the assigned SCION protocol numbers.

 Considerations

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



de Kater, et al.        Expires 5 September 2024               [Page 56]

Internet-Draft                  SCION DP                      March 2024


   The protocol numbers are used in the SCION header to identify the
   next level protocol.

Assignment

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

              Table 10: The assigned SCION protocol numbers

Authors' Addresses

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


   Nicola Rustignoli
   SCION Association
   Email: nic@scion.org




de Kater, et al.        Expires 5 September 2024               [Page 57]

Internet-Draft                  SCION DP                      March 2024


   Samuel Hitz
   Anapaya Systems
   Email: hitz@anapaya.net
















































de Kater, et al.        Expires 5 September 2024               [Page 58]