SCION Components Analysis

Minimal Stack - Core Components To establish end-to-end connectivity, SCION relies on three main components.

Data plane: it carries out secure packet forwarding, providing path-aware inter-domain connectivity.
Control plane: it performs inter-domain routing by discovering and securely disseminating path information.
PKI: it handles cryptographic material and provides a unique trust model.

A SCION network is formed of multiple interconnected administrative domains, called SCION autonomous systems (AS). Each AS deploys all of the three components above. Implementations of all of the above components are deployed in production (e.g., they are in use within the SSFN, the Swiss Finance Network). There are commercial implementations (including a high-performance data plane). A SCION packet is sent through a SCION network by SCION endpoints (i.e., a network host). It is then forwarded between ASes by the SCION data plane, which authenticates packets at each hop. The control plane is responsible for discovering and disseminating routing information. Path discovery is performed by each AS thanks to an authenticated path-exploration mechanism called beaconing. SCION endpoints query their respective AS control plane and obtain authenticated and authorized network paths, in the form of path segments. Endpoints select one or more of the end-to-end network paths, based on the application requirements (i.e., latency). Endpoints then craft SCION packets containing the end-to-end path to the destination. The control plane relies on the control-plane PKI (CP-PKI) for authentication (e.g., of path segments). SCION's authentication mechanisms aim at protecting the whole end-to-end path at each hop. Such mechanisms are based on a trust model that is provided by the concept of Isolation Domains (ISDs). An ISD is a group of Autonomous Systems that independently defines its own roots of trust. ISD members share therefore a uniform trust environment (i.e., a common jurisdiction). They can transparently define trust relationships between parts of the network by deciding whether to trust other ISDs. SCION trust model, therefore, differs from the one provided by other PKI architectures. The motivation behind this design choice is clarified in . The following paragraphs look at each component individually. Rather than describing how each component works, they focus on each component's dependencies and properties provided to other components. The idea is to try to think of each component as a black box, and look at its "inputs" and "outputs".

Authentication - SCION CP-PKI SCION's control plane messages and path information are all authenticated. This helps SCION avoid some of the obstacles to deployment mentioned in , where several path-aware methods failed to achieve deployment because of lack of authentication or lack of mutual trust between hosts and the intermediate network. The verification of messages relies on a public-key infrastructure (PKI) called the control-plane PKI or CP-PKI. It consists of a set of mechanisms, roles, and policies related to the management and usage of certificates, which enables the verification of signatures of, e.g., path-segment construction beacons (PCBs). A detailed specification of the PKI is available in .

Key Properties One might ask why SCION requires its own PKI, rather than reusing some of the existing PKI architectures to issue AS certificates. Several properties distinguish the CP-PKI from others, and motivate SCION's distinct approach.

Locally scoped and flexible trust. SCION is designed to securely connect ASes that do not necessarily share mutual trust. This requires a trust model that is different from the ones that are behind commonly deployed PKIs. In a monopolistic model, all entities trust one or a small number of roots of trust. In an oligopolistic model, there are multiple equally trusted roots (e.g., in the Web PKI). In both models, some or all certification authorities are omnipotent. If their key is compromised, then the security of the entire system collapses. Both models do not scale well to a global environment, because mutually distrustful entities cannot agree on a single root of trust (monopoly) and because in the oligopoly model, the security is as strong as its weakest root. In the SCION CP-PKI, trust is locally scoped within each ISD, and the capabilities of each ISD (authentication-wise) are limited to the communication channels in which they are involved. Each ISD can define its own trust policy. ASes must accept the trust policy of the ISD(s) in which they participate, but they can decide which ISDs they want to join, and they can participate in multiple ISDs.
Resilience to compromised entities and keys. Compromised or malicious trust roots outside an ISD cannot affect operations that stay within that ISD. Moreover, as trust roots (in the form of a TRC) can only be updated through a voting process, each ISD can be configured to withstand the compromise of a number of its root keys.
Multilateral governance. The voting mechanism mentioned above makes sure that fundamental changes to the trust policies are only allowed with the consent of multiple entities administering an ISD. Within an ISD, no single entity is in full control, or owns a cryptographic "kill-switch".
Support for versioning & updates. Trust within an ISD is normally bootstrapped with an initial ceremony. Subsequent updates to the root of trust (TRC) are handled automatically. The PKI design makes sure that certificate rollover can be automated so that certificates can be rotated frequently (e.g., every few days for AS certificates).
Scalability. The authentication infrastructure scales to the size of the Internet and is adapted to the heterogeneity of today's Internet constituents.

Dependencies Setting up the PKI in a freshly created Isolation Domain requires an initial trust bootstrapping process among some of the ISD members (i.e. a key exchange ceremony, and manual distribution of the initial ISD trust anchor). As updates to the later roots of trust are automated, this process is in principle only required once. In addition, certificate verification requires that PKI components can mutually communicate and have coarsely synchronized time. The CP PKI enables the verification of signatures, e.g., on path-segment construction beacons (PCBs). It is built on top of a peculiar trust model, where entities are able to select their roots of trust. It constitutes the most independent and self-contained core component, as it does not have significant dependencies on other SCION components.

Provided to Other Components The PKI makes trust information available to the control plane through two elements:

Trust Root Configuration (TRC): The PKI provides well-defined per-ISD trust policies, in the form of a per-ISD Trust Root Configuration (TRC). The TRC contains the ISD trust roots, and it is co-signed by multiple entities in a multilateral process called voting.
AS certificates: For each Autonomous System that is part of an ISD, the PKI provides an AS certificate that is used by other components for authentication. It also provides a validation path up to the ISD trust root, through intermediate CA certificates.

SCION CP-PKI comprises an optional extension called DRKey, which enables efficient symmetric key derivation between any two entities in possession of AS certificates. Such symmetric keys are used for additional authentication mechanisms for high-rate data-plane traffic and some control messages. As authentication based on digital signatures only scales well for relatively low message rates, using symmetric keys makes sure that the performance requirements for the high message rate of the data plane can be met. For more information, refer to the extension draft . The trust model and certificates provided could be used not only by the SCION control plane but also other systems and protocols.

Relationship to Existing Protocols The CP-PKI is based on certificates that use the X.509v3 standard . There are already several professional industry-grade implementations. The SCION trust model differs from existing PKIs in two ways. First, no entity is globally omnipotent, as Isolation Domains elect their own locally scoped root of trust. Second, changes to the trust roots require a voting process, making governance multilateral and each trust root resilient to the compromise of some of its keys. These properties would be lost if SCION were to rely on an existing PKI (i.e., the web PKI, the RPKI, ...). For example, if SCION were to use the RPKI instead of the CP-PKI, its control plane would lack the trust model required to support Isolation Domains. This is because RPKI's trust model follows the same structure as the IP allocation hierarchy, where the five RIRs represent the trust roots. Within SCION, RPKI is instead used to secure some of its transition mechanisms, as later explained in . In conclusion, SCION is built around a unique trust model, justifying the existence of the CP-PKI.

Routing - Control Plane The SCION control plane's main purpose is to securely discover and disseminate routing information. Path exploration is based on path-segment construction beacons (PCBs), which are initiated by a subset of ASes and accumulate cryptographically protected path forwarding information. Each AS selects a few PCBs and makes them available to endpoints via its path service, part of the control plane. Overall, the control plane takes an unexplored topology and AS certificates as input, it then discovers the inter-domain topology and makes routing information available to endpoints. The following section describes the core properties provided by the SCION control plane, its relationships with existing protocols, and its dependencies on the PKI. For an overview of the process to create and disseminate path information, refer to , section 1.2.2. The control plane is internally formed by multiple sub-components (as the beacon service, responsible for path discovery, and the path service, responsible for path dissemination). Processes and interfaces specifications between these sub-components could be topic for one or multiple dedicated documents.

Key Properties

Massively multipath. When exploring paths through beaconing, SCION ASes can select PCBs according to their policies, and register the corresponding path segments, making them available to other ASes and endpoints inside their network. SCION endpoints can leverage a wide range of (possibly disjoint) inter-domain paths, based on application requirements or path conditions. This goes beyond the capabilities of existing multipath mechanisms, such as BGP ADD-PATH , that is focusing on advertising multiple paths for the same prefix to provide a backup path.
Scalability. The SCION's beaconing algorithm is scalable and efficient due to the following reasons: The routing process is divided into a process within each ISD (intra-ISD) and one between ISDs (inter-ISD), SCION beaconing does not need to iteratively converge, and SCION makes AS-based announcements instead of IP prefix-based announcements. Scalability of the routing process is fundamental not only to support network size growth but also to quickly react to failures. An in-depth study of SCION's scalability in comparison to BGP is available in .
Convergence time. Since routing decisions are decoupled from the dissemination of path information, SCION features faster convergence times than path-vector protocols. Path information is propagated across the network by PCBs in times that are within the same order of magnitude of network round trip time. In addition, the division of the beaconing process into intra- and inter-ISD helps in speeding up global distribution of routing information. This means that SCION can restore global reachability, even after catastrophic failures, within tens of seconds.
Hop-by-hop path authorization. SCION packets can only be forwarded along authorized path segments. This is achieved thanks to message authentication codes (MACs) within each hop field. During beaconing, each AS's control plane creates nested MACs, which are then verified during forwarding. This gives endpoints strong guarantees about the path where the data is routed, with minimal overhead and resource requirements on routers. Giving endpoints strong guarantees about the full inter-domain path is important to avoid traffic interception, and to enable geofencing (i.e., keeping data in transit within a well-defined trusted area of the SCION network). This facilitated early adoption in the finance industry.
Host addressing agnostic. SCION decouples routing from host addressing: inter-domain routing is based on ISD-AS tuples rather than on host addresses. This design decision has two outcomes: First of all, SCION can reuse existing host addressing schemes, such as IPv6, IPv4, or others. Second, the control plane does not carry prefix information. Thanks to PCFS, packets contain forwarding state, so routers do not need to look up routing tables (avoiding the need for dedicated hardware).
Transparency. SCION endpoints have full visibility of the inter-domain path where their data is forwarded. This is a property that is missing in traditional IP networks, where routing decisions are made by each hop, therefore endpoints have no visibility nor guarantees on where their traffic is going. Additionally, SCION users have visibility on the roots of trust that are used to forward traffic. SCION, therefore, makes it harder to redirect traffic through an adversary's vantage point. Moreover, SCION gives end users the ability to select which parts of the Internet to trust. This is particularly relevant for workloads that currently use segregated networks.
Fault isolation. As the SCION routing process is hierarchically divided into intra-ISD and inter-ISD, faults have a generally limited and localized impact. Misconfigurations, such as an erroneous path policy, may suppress some paths. However, as long as an alternative path exists, communication is possible. In addition, while the control plane is responsible for creating new paths, it does not invalidate existing paths. The latter function is handled by endpoints upon detecting failures or eventually receiving an SCMP message from the data plane. This separation of control and data plane prevents the control plane from cutting off an existing communication or having a global kill-switch.

Dependencies The SCION control plane requires the control-plane PKI to authenticate path information. It heavily relies on certificates provided by the CP-PKI for beaconing (i.e., for authenticating routing information). Each Isolation Domain requires its own root of trust, in the form of a TRC, in order to carry out path exploration and dissemination. While in principle the control plane could use certificates provided by another PKI, it would be severely affected by a lack of the ISD concept. All security properties related to the trust model would be affected. The concept of ISD is also necessary for scalability and fault isolation to organize the routing process into a two-tiered architecture. In conclusion, the control plane depends on the CP-PKI. If it were to be used with another PKI, it would lose several of its fundamental properties.

Provided to Other Components In SCION, an endpoint sending a packet must specify, in the header, the full SCION forwarding path the packet takes towards the destination. This concept is called packet-carried forwarding state (PCFS). Rather than having knowledge of the network topology, an endpoint's data plane relies on the control plane for getting such information. The endpoint's SCION stack queries path segments, then it selects them and combines them into a full forwarding path to the destination. The control plane is responsible, therefore, for providing an authenticated (multipath) view of the explored global topology to endpoints (and, in turn, to the data plane). In addition, it provides the data plane the ability to send authenticated control messages. The "interfaces" towards the data plane are represented by:

Path segments, that are provided to endpoints and used by SCION routers for forwarding. Segments are designed so that each AS data plane can independently verify its own segments, while globally achieving full path authorization.
SCMP. SCION control-plane messages are by default all authenticated. In addition to beacons, the control plane offers the SCION Control Message Protocol (SCMP). It is analogous to ICMP, and it provides functionality for network diagnostics, such as ping and traceroute, and authenticated error messages that signal packet processing or network layer problems. SCMP is the first control message protocol that supports the authentication of network control messages, preventing unauthenticated control messages from potentially being used to affect or even prevent traffic forwarding. SCMP is used, for example, by the data plane to achieve path revocation.

Relationship to Existing Protocols At first sight, it might seem that the SCION control plane takes care of similar duties as existing routing protocols. While both focus on disseminating routing information, there are substantial differences in their mechanisms and properties offered. The SCION control plane was designed to carry out inter-domain routing, while intra-domain routing (and forwarding) are intentionally left out of scope. Existing IGPs are used within an AS, allowing the reuse of existing intra-domain routing infrastructure and reducing the amount of changes required for deployment. End-host addressing is decoupled from routing. Similar to LISP , SCION separates routing, that is based on locator (an ISD-AS tuple), and host identifiers (e.g., IPv6, IPv4, ...). While the two architectures have this concept in common, there are notable differences. SCION brings improvements to inter-domain routing and provides secure multipath, while LISP provides a framework to build overlays on top of the existing Internet. In addition, LISP security proposals focus on protecting identifier to locator mappings, while SCION focuses on securing inter-domain routing. Lastly, identifier to locator mapping in SCION not part of the core components, rather it is left to some of its transition mechanisms, later described in . The above-mentioned decoupling also implies that SCION does not provide, by design, IP prefix origin validation, which is currently provided by RPKI . As prefix origin validation is outside of SCION's scope, IP-to-SCION's coexistence mechanisms (SIAM, SBAS) later discussed in build on top of RPKI for IP origin attestation. Additionally, the SCION control plane design takes into account some of the lessons learned discussed in : It does not try to outperform end-to-end mechanisms, as path selection is performed by endpoints. SCION, therefore, can leverage existing end-to-end mechanisms to switch paths, rather than compete with them. In addition, no single component in the architecture needs to keep connection state, as this task is pushed to endpoints. One last point is that several of the SCION control plane properties and key mechanisms depend on the fact that SCION ASes are grouped into Isolation Domains (ISDs). For example, ISDs are fundamental to achieving transparency, routing scalability, fault isolation, and fast propagation of routing information. No existing protocol provides such a concept, motivating the existence of the control plane.

Forwarding - Data Plane The SCION data plane is responsible for inter-domain packet forwarding between ASes. SCION routers are deployed at an AS network edge. They receive and validate SCION packets from neighbors, then they use their intra-domain forwarding information to transmit packets to the next SCION border router or to a SCION endpoint inside the AS. SCION packets are at the network layer (layer-3), and the SCION header sits in between the transport and link layer. The header contains a variable type and length host address, and can therefore carry any address (IPv4, IPv6, ...). In addition, host addresses only need to be unique within an AS, and can be, in principle, reused.

Key Properties

Path selection. In SCION, endpoints select inter-domain network paths, rather than routers. The endpoints are empowered to make end-to-end path choices based on application requirements. This means that routers do not carry the burden of making enhanced routing or forwarding decisions.
Scalability. SCION routers can efficiently forward packets without the need to look up forwarding tables or keep per-connection state. Routers only need to verify MACs in hop fields. This operation is based on modern block ciphers such as AES, can be computed faster than performing a memory lookup, and is widely supported in modern CPUs. Routers, therefore, do not require expensive and energy-intensive dedicated hardware and can be deployed on off-the-shelf hardware. The lack of forwarding tables also implies that the growing size of forwarding tables is of no concern to SCION. Additionally, routers that keep state of network information can suffer from denial-of-service (DoS) attacks exhausting the router's state , which is less of a problem to SCION.
Recovery from failures. SCION hosts usually receive more than one path to a given destination. Each host can select (potentially disjoint) backup paths that are available in case of a failure. In contrast to the IP-based Internet, SCION packets are not dynamically rerouted by the network in case of failures. Routers use BFD to detect link failures, and in case they cannot forward a packet, they send an authenticated SCMP message triggering path revocation. End hosts can use this information, or perform active monitoring, to quickly reroute traffic in case of failures. There is therefore no need to wait for inter-domain routing protocol convergence.
Extensibility. SCION, similarly to IPv6, supports extensions in its header. Such extensions can be hop-by-hop (and are processed at each hop), or end-to-end.
Path validation. SCION routers validate network paths in packets at each hop, so that they are only forwarded along paths that were authorized by all on-path ASes in the control plane. Thanks to a system of nested message authentication codes, traffic hijacking attacks are avoided.

In conclusion, in comparison to today's Internet, the SCION's data plane takes some of the responsibilities away from routers and places them on endpoints (such as selecting paths or reacting to failures). This contributes to creating a data plane that is more efficient and scalable, and that does not require routers with specialized routing table lookup hardware. Routers validate network paths so that packets are only forwarded on previously authorized paths.

Dependencies The data plane is generally decoupled from the control plane. To be able to transmit data, endpoints need to fetch path information from their AS control plane. In addition, some operations (such as path revocation) require the data plane to be able to use an authenticated control-plane mechanism, such as SCMP. Path information is assumed to be fresh and validated by the control plane, which in turn relies on the CP-PKI for validation. The data plane, therefore, relies on both the control plane and indirectly on the CP-PKI to function. Should the data plane be used independently, without end-to-end path validation, SCION would lose many of its security properties, which are fundamental in an inter-domain scenario where entities are mutually distrustful. As discussed in , lack of authentication has often been the cause for path-aware protocols never being adopted because of security concerns. SCION should avoid such pitfalls and therefore its data plane should rely on the corresponding control plane and control-plane PKI.

Provided to Other Components The SCION data plane provides path-aware connectivity to applications. The SCION stack on an endpoint, therefore, takes application requirements as an input (i.e., latency, bandwidth, a list of trusted ASes, ... ), and crafts packets containing an appropriate path to a given destination. How to expose capabilities of path-aware networking to upper layers remains an open question. PANAPI (Path-Aware Networking API) is being evaluated as a way of making path-awareness and multipath available to the transport layer at endpoints, using the TAPS abstraction layer.

Relationship to Existing Protocols SCION is an inter-domain network architecture and as such its data plane does not interfere with intra-domain forwarding. It re-uses the existing intra-domain data and control plane to provide connectivity among its infrastructure services, border routers, and endpoints, minimizing changes to the internal infrastructure. This corresponds to the practice today where ASes use an intra-domain protocol of their choice (i.e., OSPF, IS-IS, MPLS, ...). Given its path-aware properties, some of SCION's data plane characteristics might seem similar to the ones provided by Segment Routing (SR) . There are, however, fundamental differences that distinguish and motivate SCION. The most salient one is that Segment Routing is designed to be deployed across a single trusted domain. SR, therefore, does not focus on security, which remains an open question, as outlined in . SCION, instead, is designed from the start to facilitate inter-domain communication between (potentially mutually distrustful) entities. It comes, therefore, with built-in security measures to prevent attacks (i.e., authenticating all control-plane messages and all critical fields in the data-plane header). Rather than compete, SCION and SR complement each other. SCION relies on existing intra-domain routing protocols, therefore SR can be one of the possible intra-domain forwarding mechanisms. Possible integration of its path-aware properties with SR remains for now an open question. In SCION's current implementation and early deployments, intra-AS SCION packets are encapsulated into an IP/UDP datagram for AS-local packet delivery, reusing the AS existing IGP and IP-based data plane. This design decision eased early deployments of SCION in IP-based networks. In the long term, it is not excluded that SCION's data plane could be better integrated with IP. For example, SCION path information could be included in a custom IPv6 routing extension header ( section 4.4). Such approach requires further exploration on its impact on intra-domain forwarding and on addressing, so further discussion on the topic is left to future revisions of this draft.