SCION

SCION

Introduction

Global communication guarantees can be achieved as long as a path composed of benign domains exists.

During our journey we discovered that path-aware networking and multi-path communication are powerful concepts that can provide higher efficiency than a single-path Internet:

• Enables path optimization depending on application needs
• Simultaneous use of several paths unlocks additional bandwidth

SCION Architecture Principles

• Stateless Packet Forwarding
  • No inconsistent forwarding state
• “Instant convergence” routing
• Path-aware networking
• Multi-path communication
• High security through design and formal verification
• Sovereignty and transparency for trust roots

Approach for Scalability

• Isolation Domain (ISD): grouping of ASes
• ISD Core: ASes that manage the ISD and provide global connectivity
• Core AS: AS that is part of the ISD Core

Path-based Network Architecture

• Control Plane - Routing
  • Constructs and disseminates path segments
• Data Plane - Packet Forwarding
  • Combines Path Segments to Path
  • Packets contain Path
  • Routers forward packets based on Path
    • Simpler routers, stateless operation

Intra-ISD Path Exploration: beaconing

Core ASes initiate Path-segment Construction Beacons (PCBs), which traverse ISD as a flood to reach downstream ASes.

Each AS receives multiple PCBs representing path segments to a core AS.

PCB Contents:

• PCB creation time

Each AS on path adds:

• AS name
• Hop field for data-plane forwarding
  • Link identifiers
  • Expiration time
  • Message Authentication Code
• AS signature

Inter-ISD Path Exploration: core beaconing

Path Server Infrastructure

Path servers offer lookup service:

• ISD, AS → down-path-segments, core-path segments
• Local up-path segment request → up-path segments to core ASes

Core ASes operate core path server infrastructure:

• consistent, replicated storage of down-path segments and core-path segments

Each non-core AS runs local path servers:

• serves up-path segments to local clients
• resolves and caches response of remote AS lookups.

Up-Path Segment Registration

AS selects path segments to announce as up-path segments for local hosts. Up-path segments are registered at local path servers.

Down-Path Segment Registration

AS selects path segments to announce as down-path segments for others to use to communicate with AS. Down-path segments are uploaded to core path server in core AS.

**Communication within ISD**

The client obtains path segments:

• Up-path segments to local ISD core ASes (blue);
• Down-path segments to destination (green);
• Core-path segments as needed to connect up-path and down- path segments (orange).

The client then combines path segments to obtain end-to-end paths (yellow).

Communication to Remote ISD

Host contacts local path server requesting <ISD, AS>.

If path segments are not cached, local path server will contact core path server.

If core path server does not have path segments cached, it will contact remote core path server.

Finally, host receives up-, core- and down-segments.

Path Combination

Scion Control and Data Plane

The Control Plane has three main functions:

• Path exploration → path segments
• Path dissemination → senders request segments
• Certificate dissemination/renewal → needed for segment verification

Path segments contain forwarding and meta information. Meta information can include geographical location of routers, MTU, bandwidth, link latency.

Senders extract the forwarding information from the path segments to form complete end-to-end paths.

Forwarding information is encoded in the packet header. Routers only verify the authenticity of the information → two AES operations replace longest-prefix match.

Since addresses are tied to AS numbers, and the hop fields are authenticated with signatures, an off path attacker has no way to tamper with the routing process. In addition, forwarding is only based on the path in the packet header which cannot be influenced by off-path attackers.

SCION Drawbacks

• Initial Latency Inflation

  • additional latency to obtain oaths

    • amortised by caching and path reuse

• Bandwidth overhead due to paths in packets

  • usually around 80 bytes

    • enables path control

    • simpler data plane

• Increased complexity in key management

  • new certificates (e.g.: TRC certificates)

    • high security design

• Initial setup cost

  • training network operators

    • installing new infrastructure

    • offers methods to facilitate deployment

**How to Deploy SCION:**

**ISP**

CORE Routers are set up at the borders of an ISP: to peer with other SCION-enabled networks and to collect customer accesses. No change to the internal network infrastructure of an ISP needed!

End Domain

SCION IP Gateway (SIG) enables seamless integration of SCION capabilities in end-domain networks.

No upgrades of end hosts or applications needed.

Dynamically Recreatable Key (DRKey)

Use a per-AS secret value to derive keys with an efficient Pseudo-Random Function

Key Server Infrastructure

Key servers that are deployed in each AS build the backbone of key hierarchy and they’re responsible for key exchange, local key establishment and key management.

After AS-level keys are established, symmetric keys for end hosts can be provided using key derivation.

Keys can be used to provide source authenticity of packets without costly key exchange between communicating parties.

Each host is required to contact their local key server.

Key Hierarchy

AS A creates key hierarchy from secret value A (SV_A) using a Pseudo-Random Function $K_{A\rightarrow B}=PRF_{SVA}(B)$.

Similarly, AS B creates key hierarchy based on SV_B

First-level Key Exchange

Second-level DRKey

DRKey Use Case: SCMP Authentication

Border router in AS B can derive key $K^{smcp}_{B\rightarrow A:source}$ from SV_B.

Host “Source” can fetch key from local key server KS_A to authenticate SCMP message

DRKey Use Case: LightningFilter

Approach: sender locally fetches remote LightningFilter’s key via DRKey; remote LightningFilter can derive key within a few milliseconds and can authenticate the packet.

Advantage: packet verification possible in less than 10 nanoseconds at a much lower overhead than heuristic-based firewalls.

LightningFilter History-based Filtering

Filtering service deployed upstream of protected end services.

It performs:

• Packet authentication with DRKey
  • authentic source AS
• Duplicate suppression using Bloom Filter
• Per-AS history collection using Cuckoo hash table
• History-based resource allocation and filtering during DoS
  • fair resource allocation based on historical usage

This results in a guaranteed service, as long as total number of requests from AS < allowed number of requests → collateral damage only for hosts within attacker-controlled AS.

EPIC: Every Packet Is Checked

Goals:

• Per-packet source authentication by every router and destination
• Per-packet unique hop fields
• Path validation by destination

Attacks prevents:

• Malicious router replays packets or increases packet size
• Hop field MAC is brute forced and destination attacked until expiration time

**Importance of Path Awareness & Multi-path**

Multi-Path Routing Approaches

For a powerful multi-path system, we need a rich set of path choices: ideally dozens of paths if possible.

Problem: most prior multi-path routing algorithms are based on BGP, offering only 2-3 different path choices.

• Overhead increases linearly in the number of paths hampering scalability

The path segment combination of SCION provides a rich set of path choices.

Admission Algorithm with per-neighbour fairness

Each AS defines neighbour-to-neighbour minimum bandwidth guarantees. For any path, AS-to-AS minimum bandwidth guarantee can be computed, regardless of other demands. Algorithm guarantees that no set of ASes can reserve a disproportionate amount of bandwidth through any link.