two trust models: monopoly and oligopoly. In the monopoly model, a single root of trust is used for authentication. The DNSSEC PKI5 or the Resource Public-Key Infrastructure (RPKI) 2 used in BGPsec are examples of the monopoly model, as both essentially rely on a single public key that serves as a root of trust to verify all subsequent entities. The monopoly model suffers from two main drawbacks: All parties must agree on a single root of trust, and the single root of trust represents a single point of failure, the misuse of which enables forging a certificate for an arbitrary entity, and its revocation can result in a kill-switch for all its entities. The oligopoly model fares no better; instead of a single root of trust, the oligopoly model relies on several roots of trust, all equally and completely trusted. Instead of a single point of failure in the monopoly model, the oligopoly model thus exposes several points of failure. The prime example is the TLS PKI, featuring approximately 1,500 trusted signing certificates with approximately 300 roots of trust. 1, 12 Attacks reported since 2011 against authorities (such as Comodo, DigiNotar, and GlobalSign) demonstrate how compromise of a single trusted certificate authority enables issuing server certificates for any domain, including those with which there is no business relationship.

SCION allows each ISD to define its own set of trust roots, along with the policy governing their use. Such scoping of trust roots within an ISD greatly improves security, as compromise of a private key associated with a trust root cannot be used to forge a certificate outside the ISD. An ISD’s trust roots and policy are encoded in the TRC, which has a version number, a list of public keys that serve as roots of trust for various purposes, and policies governing the number of signatures required for performing different types of actions. The TRC serves as a way to bootstrap all authentications within SCION.

The TRC provides important proper-
ties. Trust agility enables users to select
trust roots used to initiate certificate
validation. Users can thus select an ISD
AS on the down-segment (starting at
a core AS). In this case, the simple
combination of an up-segment and
a down-segment creates a valid for-
warding path;

˲ Peering shortcut (such as A → B in Figure 2a). A peering link exists between the two segments, so a shortcut via the peering link is possible. As in the case of the AS shortcut, the extraneous path segment is cut off; the peering link could also traverse to a different ISD;

˲ AS shortcut (such as B → C in Figure 2a). The up-segment and down-segment intersect at a non-core AS. In this case, a shorter forwarding path can be created by removing the extraneous part of the path. The special case where the source’s up-segment contains the destination AS is treated the same way or the intersection of both segments is omitted from the path;

˲ Combination with a core-segment (such as A → D in Figure 2a). The last AS on the up-segment is different from the first AS on the down-segment. This case requires an additional core-segment to connect the up- and down-segment. If the communication remains within the same ISD (A → D), an intra-ISD core-segment is needed; otherwise, an inter-ISD core segment is needed; and

˲ On-path (such as A → E in Figure 2a). The destination AS is directly on the path to the ISD core, so a single up-segment is sufficient to create a forwarding path.

Once the host chooses a forwarding path, it is encoded in the SCION packet header, making inter-domain routing tables unnecessary for border routers; both the egress and the ingress interface of each AS on the path are encoded as PCFS in the packet header. The destination can respond to the source by inverting the end-to-end path from the packet header or perform its own path lookup and combination.

Security. For protection against malicious entities and provide secure control and data planes, SCION is equipped with an arsenal of security mechanisms.

As in BGPsec, 19 each AS signs the
PCB it forwards, enabling PCB valida-
tion by all entities. To ensure path cor-
rectness, the forwarding information
within each PCFS also needs to be cryp-
tographically protected, but signature
verification would hamper efficient
forwarding. Each AS thus uses a secret
symmetric key that is shared among
beacon servers and border routers and
used to efficiently compute a message
authentication code (MAC) over the
forwarding information. The per-AS
information includes the ingress and
egress interfaces, an expiration time,
and the MAC computed over these
fields, which are (by default) all en-
coded within an 8B field we refer to as
a “hop field” (HF). The structure of the
HF is largely at the discretion of each
AS and requires no coordination with
any other AS, as long as the AS itself can
determine how to forward the packet
on to the next AS.
The specified ingress and egress in-
terfaces uniquely identify the links to
the previous and following ASes. If, for
example, a router is connected via the
same outgoing interface to three differ-
ent neighboring ASes, three different
egress-interface identifiers would be
assigned by network administrators.
The HF’s expiration time can be set to
the granularity of seconds or hours, de-
pending on path type. For this article, we
consider only the common case where
paths are long-lived and HFs have an ex-
piration time of approximately 12 hours.
Algorithm agility. In terms of crypto-
graphic mechanisms, SCION includes
built-in algorithm agility, meaning
cryptographic methods are easily up-
dated and exchanged. The MAC vali-
dation of HFs is per-AS, so an AS can
independently (without interaction
with any other entity) update its keys
or cryptographic mechanisms. SCION
supports multiple signatures by an AS,
meaning an AS can readily deploy a
new signature algorithm and start add-
ing those signatures as well. A compo-
nent of the selection metric favors cre-
ating paths where each AS on the path
supports the new algorithm.

Authentication. Authentication in SCION is based on digital certificates that bind identifiers to public keys and carry digital signatures that are verified by roots of trust. One notable challenge is how to achieve trust agility to enable flexible selection of trust roots, resilience to private key compromise, and efficient key revocation. 20

A central question we have had to address is how to structure the Internet’s trust roots. The current Internet follows