idnits 2.17.1 draft-dekater-panrg-scion-overview-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (19 May 2022) is 706 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TRC' is mentioned on line 335, but not defined == Missing Reference: 'TCR' is mentioned on line 338, but not defined == Unused Reference: 'CHUAT22' is defined on line 1468, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG C. de Kater 3 Internet-Draft N. Rustignoli 4 Intended status: Informational A. Perrig 5 Expires: 20 November 2022 ETH Zuerich 6 19 May 2022 8 SCION Overview 9 draft-dekater-panrg-scion-overview-01 11 Abstract 13 The Internet has been successful beyond even the most optimistic 14 expectations and is intertwined with many aspects of our society. 15 But although the world-wide communication system guarantees global 16 reachability, the Internet has not primarily been built with security 17 and high availability in mind. The next-generation inter-network 18 architecture SCION (Scalability, Control, and Isolation On Next- 19 generation networks) aims to address these issues. SCION was 20 explicitly designed from the outset to offer security and 21 availability by default. The architecture provides route control, 22 failure isolation, and trust information for end-to-end 23 communication. It also enables multi-path routing between hosts. 25 This document discusses the motivations behind the SCION architecture 26 and gives a high-level overview of its fundamental components, 27 including its authentication model and the setup of the control- and 28 data plane. As SCION is already in production use today, the 29 document concludes with an overview of SCION deployments. 31 About This Document 33 This note is to be removed before publishing as an RFC. 35 The latest revision of this draft can be found at 36 https://scionassociation.github.io/scion-overview_I-D/draft-dekater- 37 panrg-scion-overview.html. Status information for this document may 38 be found at https://datatracker.ietf.org/doc/draft-dekater-panrg- 39 scion-overview/. 41 Discussion of this document takes place on the WG Working Group 42 mailing list (mailto:panrg@irtf.org), which is archived at 43 https://datatracker.ietf.org/rg/panrg. 45 Source for this draft and an issue tracker can be found at 46 https://github.com/scionassociation/scion-overview_I-D. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on 20 November 2022. 65 Copyright Notice 67 Copyright (c) 2022 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 72 license-info) in effect on the date of publication of this document. 73 Please review these documents carefully, as they describe your rights 74 and restrictions with respect to this document. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Why SCION - Motivation . . . . . . . . . . . . . . . . . 3 80 1.1.1. Scope of SCION . . . . . . . . . . . . . . . . . . . 5 81 1.1.2. Practical Considerations Based on Related RFCs . . . 5 82 1.1.3. Why Now? . . . . . . . . . . . . . . . . . . . . . . 7 83 1.2. SCION Overview . . . . . . . . . . . . . . . . . . . . . 7 84 1.2.1. Network Architecture and Naming . . . . . . . . . . . 7 85 1.2.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 86 1.2.3. Infrastructure Components . . . . . . . . . . . . . . 10 87 1.2.4. Formal Verification . . . . . . . . . . . . . . . . . 11 88 1.3. Conventions and Definitions . . . . . . . . . . . . . . . 11 89 2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 11 90 2.1. Authentication . . . . . . . . . . . . . . . . . . . . . 12 91 2.1.1. The Control-Plane PKI (CP-PKI) . . . . . . . . . . . 12 92 2.1.2. TRC Update and Verification . . . . . . . . . . . . . 13 93 2.1.3. Dissemination of TRC Updates . . . . . . . . . . . . 14 94 2.1.4. Grace Period . . . . . . . . . . . . . . . . . . . . 14 95 2.1.5. Revocation and Recovery from a Catastrophic Event . . 14 97 2.2. SCION Control Plane . . . . . . . . . . . . . . . . . . . 15 98 2.2.1. Path Exploration . . . . . . . . . . . . . . . . . . 15 99 2.2.2. Path Registration . . . . . . . . . . . . . . . . . . 18 100 2.2.3. Path Lookup . . . . . . . . . . . . . . . . . . . . . 19 101 2.2.4. Link Failures . . . . . . . . . . . . . . . . . . . . 20 102 2.3. SCION Data Plane . . . . . . . . . . . . . . . . . . . . 21 103 2.3.1. Path Construction via Segment Combination . . . . . . 21 104 2.3.2. Path Authorization . . . . . . . . . . . . . . . . . 24 105 2.3.3. Forwarding . . . . . . . . . . . . . . . . . . . . . 24 106 2.3.4. Intra-AS Communication . . . . . . . . . . . . . . . 24 107 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 3.1. Autonomous System Deployment . . . . . . . . . . . . . . 25 109 3.2. Internet Exchange Points . . . . . . . . . . . . . . . . 26 110 3.3. End Hosts and Incremental Deployability . . . . . . . . . 26 111 3.3.1. Native End Hosts . . . . . . . . . . . . . . . . . . 27 112 3.3.2. SCION to IP Gateway (SIG) . . . . . . . . . . . . . . 27 113 3.4. Deployment Experiences . . . . . . . . . . . . . . . . . 27 114 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 115 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 116 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 117 6.1. Normative References . . . . . . . . . . . . . . . . . . 28 118 6.2. Informative References . . . . . . . . . . . . . . . . . 29 119 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 122 1. Introduction 124 The Introduction section explores the motivation to develop SCION, 125 followed by a short description of SCION's main elements. The 126 sections after the Introduction provide further insight into SCION's 127 key concepts and deployment scenarios. The document concludes with 128 some concrete case studies where SCION has been successfully deployed 129 in production. 131 1.1. Why SCION - Motivation 133 Since its inception, the Internet has continued to expand, 134 encompassing new uses over time. The continuous expansion has 135 brought many issues to light, including a lack of control, 136 limitations in scalability, performance and security, occurrences of 137 severe outages, weak fault isolation, and energy consumption. With 138 the core focus on functionality and operation, the current Internet 139 offers little protection against attacks such as spoofing, IP-address 140 hijacking, denial-of-service, and combinations of these. For more 141 background information, see [SCHUCHARD2011], [LABOVITZ2000], 142 [GRIFFIN1999], [SAHOO2009], and [RFC4264]. 144 There have been numerous initiatives to address the above issues. 145 Although these initiatives have brought many improvements, concerns 146 regarding security and scalability still remain. For more details, 147 see, e.g., [RFC4033], [RFC6480], [RFC8205], and [RFC8446], as well as 148 [LYCHEV2013], [LI2014], [COOPER2013], [ROTHENBERGER2017], 149 [MORILLO2021], and [KING2022]. 151 As a consequence, today's Internet fails to fulfil many users' 152 requirements. This especially pertains to the demands of enterprises 153 globally exchanging sensitive information, such as financial 154 institutions, healthcare providers, universities, multinationals, 155 governments, critical and transportation infrastructure operators. 156 These users require the Internet to be highly available at all times. 157 They expect reliable operation of the global network also in case of 158 failures. They need availability guarantees across multiple routing 159 domains, even in the presence of attacks. They further want to rely 160 on an Internet that can be multilaterally governed and is free from 161 global kill-switches. 163 SCION has been developed in order to meet the above-mentioned 164 requirements. SCION aims to reach the following goals: 166 * Provide high-availability architecture (also in the presence of 167 adversaries) 169 * Provide fast failover in the case of inter-domain link or router 170 failures 172 * Prevent from IP-address hijacking, DoS, and other attacks 174 * Enable path transparency as well as application-specific path 175 optimizations 177 * Improve the inter-domain control plane's scalability 179 * Prepare the Internet for tomorrow's applications, such as virtual 180 reality, Internet of Things (IoT), and all other applications 181 requiring high-performance connectivity. 183 *Note*: A more detailed motivation for developing SCION will be 184 described in a separate gap analysis internet draft. 186 1.1.1. Scope of SCION 188 The above section describes SCION's aspiration to improve _inter_-AS 189 routing and to focus on providing end-to-end connectivity. However, 190 SCION does not solve _intra_-AS routing issues, nor does it provide 191 end-to-end payload encryption, and identity authentication. These 192 topics, which are equally important for the Internet to perform well, 193 lie outside the scope of SCION. 195 1.1.2. Practical Considerations Based on Related RFCs 197 The SCION inter-domain routing concept has initially been developed 198 by researchers of the ETH Zuerich [PERRIG2017], and could in the 199 meantime also gain attention and recognition in the international 200 academic world. However, for an IT architecture to be successful, it 201 must work well in practice, too. This section pays attention to the 202 implementation considerations of a conceptual framework such as SCION 203 in real life, on the basis of some RFCs exploring this topic. It 204 also verifies in how far SCION meets the requirements mentioned and 205 questions raised in these RFCs. 207 1.1.2.1. Avoiding Pitfalls 209 [RFC9049] describes why previous proposals to tackle some of the 210 Internet's fundamental issues did not manage to succeed. SCION seems 211 to avoid the pitfalls mentioned in that document. For example, SCION 212 does not have to be adopted by the entire Internet to be effective: 213 The routing architecture provides benefits already to early adapters. 214 Even if only a small part of the global network works with SCION, 215 adapters will still take advantage of using the SCION routing 216 technology. Moreover, not only users of SCION benefit from it, also 217 ISPs and operators benefit from deploying SCION: early deployments 218 showed that providers can charge the use of SCION as premium 219 connectivity, with users who are willing to pay for it. Furthermore, 220 SCION can be installed on top of and function alongside the existing 221 routing infrastructure and protocols--there is no need for high- 222 impact changes in an operational network. 224 Another RFC that must be mentioned in this context is [RFC5218], 225 "What Makes for a Successful Protocol?". SCION seems to fulfil most 226 factors that contribute to the success of a protocol, as described in 227 section 2.1 of the RFC. This includes such factors as offering a 228 positive net value (i.e., the benefits of deploying SCION outweigh 229 the costs), incremental deployability, and open source code 230 availability. More importantly, SCION averts the failure criteria 231 mentioned in section 1.4 of the RFC: SCION is already deployed and in 232 use by many actors of the Swiss financial and academic ecosystems, 233 and allows for multiple implementations, both open and closed source. 234 As existing SCION implementations are easily portable, adoption in 235 mainstream platforms is also possible. 237 1.1.2.2. Answering Questions 239 SCION can be considered a _path-aware internetworking_ architecture, 240 as described in [RFC9217]. This RFC poses (open) questions that must 241 be answered in order to realize such a path-aware networking system. 242 It was originally written to frame discussions in the Path Aware 243 Networking Research Group (PANRG), and has been published to snapshot 244 current thinking in this space. 246 SCION intends to answer the questions raised in this RFC. This 247 especially pertains to the second, third, seventh, and eighth 248 question: 250 * How do endpoints and applications get access to accurate, useful, 251 and trustworthy path properties? 253 * How can endpoints select paths to use for traffic in a way that 254 can be trusted by the network, the endpoints, and the applications 255 using them? 257 * How can a path-aware network in a path-aware internetwork be 258 effectively operated, given control inputs from network 259 administrators, application designers, and end users? 261 * How can the incentives of network operators and end users be 262 aligned to realize the vision of path-aware networking, and how 263 can the transition from current ("path-oblivious") to path-aware 264 networking be managed? 266 SCION's answers to these questions can be found in Key Concepts 267 (Section 2) and Deployments (Section 3.4), respectively. 269 1.1.3. Why Now? 271 The emergence of multiple SCION implementations and early deployments 272 highlight the need for standardization. The time seems therefore 273 ripe to take SCION to the IETF, also in order to contribute to the 274 important discussion regarding path-aware networking. 276 1.2. SCION Overview 278 SCION has been designed to address the fundamental issues of today's 279 Internet depicted in Why SCION - Motivation (Section 1.1). The 280 following section gives a high-level overview of SCION's main 281 elements, providing a basic understanding of this next-generation 282 inter-network architecture. 284 1.2.1. Network Architecture and Naming 286 SCION's main goal is to offer highly available and efficient inter- 287 domain packet delivery--even in the presence of actively malicious 288 entities. To achieve scalability and sovereignty, SCION organizes 289 existing ASes into groups of independent routing planes, called 290 *Isolation Domains (ISD)*. An AS can be a member of multiple ISDs. 291 All ASes in an ISD agree on a set of trust roots, called the *Trust 292 Root Configuration (TRC)*. The ISD is governed by a set of *core 293 ASes*, which provide connectivity to other ISDs and manage the trust 294 roots. Typically, a few distinguished ASes within an ISD form the 295 ISD's core. 297 Isolation domains serve the following purposes: 299 * They allow SCION to support trust heterogeneity, as each ISD can 300 independently define its roots of trust; 302 * They provide transparency for trust relationships; 304 * They isolate the routing process within an ISD from external 305 influences such as attacks and misconfigurations; and 307 * They improve the scalability of the routing protocol by separating 308 it into a process within and one between ISDs. 310 ISDs provide natural isolation of routing failures and 311 misconfigurations, provide meaningful and enforceable trust, enable 312 endpoints to optionally restrict traffic forwarding to trusted parts 313 of the Internet infrastructure only, and enable scalable routing 314 updates with high path-freshness. 316 1.2.1.1. Links 318 There are three types of links in SCION: core links, parent-child 319 links, and peering links. 321 * A *core link* can only exist between two core ASes. 323 * A *parent-child link* requires that at least one of the two 324 connected ASes is a non-core AS. ASes with a parent-child link 325 usually belong to the same entity or have a provider-customer 326 relationship. 328 * A *peering link* also includes at least one non-core AS. 330 See Figure 1 for a high-level overview of the SCION network 331 structure. 333 ............................... 334 : : 335 : [TRC] : 336 : (::::::::::::::) : ...................... 337 : (::::: ISD core :::::) : : : 338 : (:: +---+ ::::::::: +---+ ::) : : [TCR] : 339 : (::::: |CAS|===+---+ : |CAS| :::::) : : (: ISD core :) : 340 : (:: +---+ : |CAS|===+---+====)===:==:=====(=+---+ :: +---+ :) : 341 : /(:::::: +---+ ::::::) \ : : (: |CAS| == |CAS| :) : 342 : / (::::::: | :::::::) \ : : ( +---+ :: +---+ ) : 343 : / | o : : /(::::::::::::) : 344 : o | +---+ : : / \ : 345 : +---+ | /|ASb| : : / \ : 346 : |ASa| | / +---+ : : o o : 347 : +---+ | / | : : +---+ +---+ : 348 : | | / | : : |ASx| ---------|ASy| : 349 : | | / o : : +---+ +---+ : 350 : o o / +---+ : : | : 351 : +---+ +---+ / |ASe| : : o : 352 : |ASc|---------|ASd| o +---+ -:--:--+---+ : 353 : +---+ +---+ : : |ASz| ISD 2 : 354 : : : +---+ : 355 : ISD 1 : ........................ 356 ................................. 357 Legend: 358 | 359 | 360 Parent AS - child AS: o 361 Peering link: ---- 362 Core link: === 363 Core AS: CAS 364 Figure 1: SCION network structure 366 1.2.2. Routing 368 SCION operates on two routing levels: intra-ISD and inter-ISD. Both 369 levels use *path-segment construction beacons (PCBs)* to explore 370 network paths. A PCB is initiated by a core AS and then disseminated 371 either within an ISD (to explore intra-ISD paths) or among core ASes 372 (to explore core paths across different ISDs). The PCBs accumulate 373 cryptographically protected path and forwarding information on AS- 374 level, and store this information in the form of *hop fields (HFs)*. 375 End hosts use information from these hop fields to create end-to-end 376 forwarding paths for data packets, who carry this information in 377 their packet headers. This concept is called *packet-carried 378 forwarding state (PCFS)*. The concept also supports multi-path 379 communication among end hosts. 381 The process of creating an end-to-end forwarding path consists of the 382 following steps: 384 1. First, an AS discovers paths to other ASes, during the _path 385 exploration_ (or beaconing) phase. 387 2. The AS then selects a few PCBs according to defined policies, 388 transforms the selected PCBs into path segments, and registers 389 these segments with its path infrastructure, thus making them 390 available to other ASes. This happens during the _path 391 registration_ phase. 393 3. During the _path resolution_ phase, the actual creation of an 394 end-to-end forwarding path to the destination takes place. For 395 this, an end host performs (a) a _path lookup_ step, to obtain 396 path segments, and (b) a _path combination_ step, to combine the 397 forwarding path from the segments. 399 Figure 2 below shows the SCION routing process in a nutshell. 401 +------------------+ +------------------+ 402 | Path Exploration | | | 403 | (Beaconing) |------------>|Path Registration | 404 | | | | 405 +------------------+ +--------+---------+ 406 | 407 +-----------------+ 408 | 409 +------------------v-----------------------+ 410 | Path Resolution | 411 |+--------------+ +-------------------+| 412 || Path Lookup |---->| Path Combination || 413 |+--------------+ +-------------------+| 414 +------------------------------------------+ 416 Figure 2: SCION routing in a nutshell 418 1.2.2.1. ISD and AS numbering 420 SCION decouples end-host addressing from inter-domain routing. 421 Routing is based on the tuple, agnostic of end-host 422 addressing. Existing AS numbers are inherited from the current 423 Internet, but a 48-bit namespace allows for additional SCION AS 424 numbers beyond the 32-bit space in use today. The end host local 425 address is not used for inter-domain routing or forwarding, does not 426 need to be globally unique, and can thus be an IPv4, IPv6, or MAC 427 address, for example. A SCION address is therefore composed of the 428 3-tuple. 430 1.2.3. Infrastructure Components 432 The *beacon service*, the *path service*, and the *certificate 433 service* are the main control-plane infrastructure components within 434 a SCION AS. Each service can be deployed redundantly, depending on 435 the AS's size and type. Existing Internal routers are used to 436 forward packets inside the AS, while _SCION border routers_ provide 437 interconnectivity between ASes. 439 * The _beacon service_ discovers path information. It is 440 responsible for generating, receiving, and propagating PCBs. 441 Periodically, the beacon service generates a set of PCBs, which 442 are forwarded to its child ASes or neighboring core ASes. The 443 PCBs are flooded over policy-compliant paths to discover multiple 444 paths between any pair of core ASes. 446 * The _path service_ stores mappings from AS identifiers to sets of 447 announced path segments. The path service is organized as a 448 hierarchical caching system similar to that of DNS. Through the 449 beacon service, ASes select the set of path segments through which 450 they want to be reached, and they register them to the path 451 service in the ISD core. 453 * The _certificate service_ keeps cached copies of certificates and 454 manages keys and certificates for securing inter-AS communication. 455 The certificate service is queried by the beacon service when 456 validating the authenticity of PCBs (i.e., when the beacon service 457 lacks a certificate). 459 _Border routers_ are deployed at the edge of SCION ASes. The main 460 task of border routers is to forward packets to a neighbor border 461 router or to the destination host within the AS. While SCION takes 462 care of inter-domain routing, it relies on existing routing protocols 463 (e.g., IS-IS, OSPF, SR) and communication fabric (e.g., IP, MPLS) for 464 intra-domain forwarding. _Internal routers_, therefore, do not need 465 to be changed to support SCION. 467 1.2.4. Formal Verification 469 An additional feature of SCION is its formal verification. The SCION 470 network system consists of a variety of components such as routers, 471 servers, and edge devices. Such a complex system eludes the mental 472 capacities of human beings for considering all possible states and 473 interactions. That is why SCION includes a formal verification 474 framework developed by the Department of Computer Science of the ETH 475 Zurich [KLENZE2021]. This guarantees that packet forwarding as well 476 as SCION's authentication mechanisms and implementations are correct 477 and consistent. 479 1.3. Conventions and Definitions 481 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 482 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 483 "OPTIONAL" in this document are to be interpreted as described in 484 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 485 capitals, as shown here. 487 2. Key Concepts 489 This section explains the SCION key concepts, including 490 authentication, control- and data plane. 492 2.1. Authentication 494 SCION's control plane relies on a public-key infrastructure called 495 the *control-plane PKI (CP-PKI)*, which is organized on ISD-level. 496 Each ISD can independently build its own roots of trust, defined in a 497 file called *trust root configuration (TRC)*. 499 *Note*: This section describes the SCION authentication concept on a 500 very high level. A much more detailed description of SCION's 501 authentication will follow in a separate internet draft. 503 2.1.1. The Control-Plane PKI (CP-PKI) 505 Trust within each isolation domain is anchored in the trust root 506 configuration (TRC) file. Each TRC contains a collection of signed 507 root certificates, which are used to sign CA certificates, which are 508 in turn used to sign AS certificates. The TRC also includes ISD- 509 policies that specify, for example, the TRC's usage, validity, and 510 future updates. A TRC is a fundamental component of an CP-PKI. 512 The initial TRC in an ISD is called the *base TRC*. This base TRC 513 constitutes the ISD's trust anchor. It is signed during a signing 514 ceremony and then distributed throughout the ISD. All entities 515 within the ISD obtain the initial TRC with an offline mechanism such 516 as a USB flash drive provided by a trusted AS, like the relevant ISP, 517 or with an online mechanism that relies on a trust-on-first-use 518 (TOFU) approach. However, all updates to the base TRCs are performed 519 in a straightforward process that does not require any manual or out- 520 of-band action (such as a software update), see TRC Update and 521 Verification (Section 2.1.2). 523 Figure 3 shows the TRC trust chain and associated certificates. TRC 524 1 is the base TRC, and TRC 2 and 3 constitute updates to this base 525 TRC. TRC 2 must be verified using the voting certificates in TRC 1. 526 Control-plane (CP) root certificates are used to verify other CP 527 certificates (which are in turn used to verify path-segment 528 construction beacons PCBs). 530 Each SCION AS must hold a private key (to sign PCBs) and a 531 certificate attesting that it is the rightful owner of the 532 corresponding public key. One of the main roles of the TRC is thus 533 enabling the verification of *AS certificates* and PCBs. 535 TRC 2 536 +--------------------------------------+ 537 |+------------------------------------+| 538 ||- Version - Core ASes || 539 +--------+ ||- ID - Description || +--------+ 540 | TRC 1 | ||- Validity - No Trust Reset || | TRC 3 | 541 | (Base |---->||- Grace Period - Voting Quorum ||--->| | 542 | TRC) | ||- ... || | | 543 +--------+ |+------------------------------------+| +--------+ 544 |+----------------+ +----------------+| 545 || Regular Voting | |Sensitive Voting|| 546 || Certificate | | Certificate || 547 |+----------------+ +----------------+| 548 |+----------------+ +----------------+| 549 || Votes | | Signatures || 550 |+----------------+ +----------------+| 551 |+------------------------------------+| 552 || CP Root Certificates || 553 |+----------+-------------+-----------+| 554 | | | | 555 +-----------+-------------+------------+ 556 | | 557 | | 558 v v 559 +-----------+ +-----------+ 560 | CP CA | | CP CA | 561 |Certificate| |Certificate| 562 +-+-------+-+ +-----+-----+ 563 | | | 564 | | | 565 v v v 566 +-----------+ +-----------+ +-----------+ 567 | CP AS | | CP AS | | CP AS | 568 |Certificate| |Certificate| |Certificate| 569 +-----------+ +-----------+ +-----------+ 571 Figure 3: TRC contents and trust chain 573 2.1.2. TRC Update and Verification 575 With a base TRC as trust anchor, TRCs can be updated in a verifiable 576 manner. There are two kinds of TRC updates: regular and sensitive 577 updates. A _regular_ TRC update happens when the TRC's validity 578 period expires. This period is defined by the _validity_ parameter 579 in the TRC. The default is one year. A TRC update is _sensitive_ if 580 and only if critical sections of the TRC are affected (for example, 581 if the set of core ASes is modified). For both regular and sensitive 582 TRC updates, a number of votes (in the form of signatures) must be 583 cast to approve the update. This number of votes is dictated by the 584 voting quorum and set in each TRC with the _voting quorum_ parameter. 586 2.1.3. Dissemination of TRC Updates 588 Information about a TRC update is disseminated via the SCION's 589 beaconing process, through the path-segment constructions beacons. 590 Each PCB contains the version number of the currently active TRC. If 591 an AS receives a PCB with a TRC version number higher than the 592 locally stored TRC, it requests the PCB-sending AS for the new TRC. 593 The new TRC is verified on the basis of the current one, and is 594 accepted if it contains at least the required quorum of correct 595 signatures by trust roots defined in the current TRC. This simple 596 dissemination mechanism has two advantages: It is very efficient (as 597 fresh PCBs rapidly reach all ASes), and it avoids circular 598 dependencies with regard to the verification of PCBs and the 599 beaconing process itself (as no server needs to be contacted over 600 unknown paths in order to fetch the updated TRC). 602 2.1.4. Grace Period 604 At most two TRCs per ISD can be active at the same time. The TRC 605 parameter _grace period_ indicates for how long the currently active 606 TRC can still be active after a new TRC is disseminated. This so- 607 called *grace period* starts at the beginning of the validity period 608 of the new TRC. An older TRC can only be active until either (1) the 609 grace period has passed, or (2) yet a newer TRC is announced. AS 610 certificates are validated by following the chain of trust up to an 611 active TRC. 613 2.1.5. Revocation and Recovery from a Catastrophic Event 615 The TRC dissemination mechanism also enables rapid revocation of 616 trust roots. When a trust root is compromised, the other trust roots 617 can remove it from the TRC and disseminate a new TRC alongside a PCB 618 with a new version number. 620 In case of a catastrophic event--such as several private root keys 621 being disclosed due to a critical vulnerability in a cryptographic 622 library--SCION is equipped with a recovery procedure called *trust 623 reset*. This procedure consists of creating a new TRC with fresh, 624 trustworthy keys (and potentially new algorithms), and redistributing 625 this TRC out-of-band. A trust reset effectively establishes a new 626 base TRC for the ISD. It is possible for ISDs to disable trust 627 resets by setting the _no trust reset_ Boolean parameter to "true" in 628 their TRC, with the effect that the entire ISD would have to be 629 abandoned in the event of such a catastrophic compromise (this 630 abandonment would also have to be announced out-of-band). 632 The partition of the SCION network into ISDs guarantees that no 633 single entity can take down the entire network. Even if several 634 entities formed a coalition to carry out an attack, the effects of 635 that attack would be limited to one or a few ISDs. 637 2.2. SCION Control Plane 639 The SCION control plane is responsible for discovering path segments 640 and making them available to end hosts. This process includes path 641 exploration, registration, and lookup; it involves the path service, 642 beacon service, and certificate service, both in core ASes and non- 643 core ASes. 645 *Note*: This section describes the SCION control plane on a very high 646 level. A much more detailed description of SCION's control plane 647 will follow in a separate internet draft. 649 2.2.1. Path Exploration 651 In SCION, the path segment construction process is referred to as 652 *beaconing*. The _beacon service_ of each AS is responsible for the 653 beaconing process. The beacon service generates, receives, and 654 propagates the *path-segment construction beacons (PCBs)* on a 655 regular basis, to iteratively construct path segments. 657 There are three types of path segments (note that all path segments 658 can be used to send data traffic in both directions): 660 * A path segment from a non-core AS to a core AS is an _up-path 661 segment_. 663 * A path segment from a core AS to a non-core AS is a _down-path 664 segment_. 666 * A path segment between core ASes is a _core-path segment_. 668 All path segments are invertible: A core-path segment can be used 669 bidirectional, and an up-path segment can be converted into a down- 670 path segment, or vice versa, depending on the direction of the end- 671 to-end path. 673 Path segment construction is conducted hierarchically on two levels: 675 * _Core beaconing_ is the process of constructing path segments 676 between core ASes. During core beaconing, the beacon service of a 677 core AS either initiates PCBs or propagates PCBs received from 678 neighboring core ASes to all other neighboring core ASes. Core 679 beaconing in SCION is similar to BGP's route-advertising process, 680 although in SCION the process is periodic and PCBs are flooded 681 over policy-compliant paths to discover multiple paths between any 682 pair of core ASes. 684 * _Intra-ISD beaconing_ creates path segments from core ASes to non- 685 core ASes. For this, the beacon service of a core AS creates PCBs 686 and sends them to the non-core child ASes (typically customer 687 ASes). The beacon service of a non-core child AS receives these 688 PCBs and forwards them to its child ASes, and so on. This 689 procedure continues until the PCB reaches an AS without any 690 customer (leaf AS). As a result, all ASes receive path segments 691 to reach the core ASes of their ISD. 693 On its way down, a PCB accumulates cryptographically protected path- 694 and forwarding information per traversed AS. At every AS, metadata 695 as well as information about the AS's ingress and egress interfaces 696 (i.e., link identifiers) is added to the PCB. The ingress and egress 697 interface IDs identify connections to neighboring ASes. These IDs 698 only need to be unique within each AS. Therefore, they can be chosen 699 and encoded by each AS independently and without any need for 700 coordination. 702 SCION also supports shortcuts and peering links. In a _shortcut_, a 703 path only contains an up-path and a down-path segment, which can 704 cross over at a non-core AS that is common to both paths. _Peering 705 links_ can be added to up- or down-path segments, resulting in an 706 operation similar to today's Internet. 708 To reduce beaconing overhead and prevent possible forwarding loops, 709 PCBs do not traverse peering links. Instead, peering links are 710 announced along with a regular path in a PCB. If the path segments 711 of both ASes at the end of a peering link contain this peering link, 712 then it is possible to use the peering link to shortcut the end-to- 713 end path (i.e., without going through the core). SCION also supports 714 peering links that cross ISD boundaries, according to SCION's path 715 transparency property. 717 Figure 4 shows how intra-ISD PCB propagation works, from the ISD's 718 core AS down to child ASes. For the sake of illustration, the 719 interfaces of each AS are numbered with integer values. In practice, 720 each AS can choose any encoding for its interfaces; in fact, only the 721 AS itself needs to understand its encoding. Here, AS F receives two 722 different PCBs via two different links from core AS X. Moreover, AS 723 F uses two different links to send two different PCBs to AS G, each 724 containing the respective egress interfaces. AS G extends the two 725 PCBs and forwards both of them over a single link to a child AS. 727 .-----. 728 ; Core : 729 +-----+ : AS X ; 730 |PCB | \ 2 1 / +-----+ 731 |Core | `+-+' |pcb | 732 |Out:2| | | |core | 733 +--+--+ +-+ | |out:1| 734 | | | +--+--+ 735 v | | | 736 .-+---+. v 737 .---. / 2 3 \ .---. 738 ( J )- - -; 1 4 :- - - - - -( H ) 739 `---' : AS F ; `---' 740 +--\7 / 741 +----------+ +----------+ <-+ 6 5 742 |PCB | |pcb | `+--+' 743 |Core | |core | | | 744 |Out:2 | |out:1 | | | 745 |----------| |----------| | | 746 |AS F | |as f | | | 747 |In:2 Out:7| |in:3 out:7| | | 748 |Peer J:1 | |peer j:1 | | | +----------+ +----------+ 749 |Peer H:4 | |peer h:4 | | | |PCB | |pcb | 750 | | | | | | |Core | |core | 751 +--+-------+ +--+-------+ | | |Out:2 | |out:1 | 752 | | | | |----------| |----------| 753 <+ <+ | | |AS F | |as f | 754 | | |In:2 Out:5| |in:3 out:5| 755 +----------+ +----------+| | |Peer J:1 | |peer j:1 | 756 |PCB | |pcb || | |Peer H:4 | |peer h:4 | 757 |Core | |core || | | | | | 758 |Out:2 | |out:1 || | +----+-----+ +----+-----+ 759 |----------| |----------|| | | | 760 |AS F | |as f || | v v 761 |In:2 Out:6| |in:3 out:6|| | 762 |Peer J:1 | |peer j:1 || | 763 |Peer H:4 | |peer h:4 || | 764 | | | || | 765 +----+-----+ +----+-----+| | 766 | | .+--+-. 767 v v ,' 5 1 `. 768 ; : 769 : AS G ; 770 \ / 771 +---` 4 3 ,' 772 <-+ `--+' 773 | +----------+ +----------+ 774 | |PCB | |pcb | 775 | |Core | |core | 776 | |Out:2 | |out:1 | 777 +----------+ +----------+ | |----------| |----------| 778 |PCB | |pcb | | |AS F | |as f | 779 |Core | |core | | |In:2 Out:5| |in:3 out:5| 780 |Out:2 | |out:1 | | |Peer J:1 | |peer j:1 | 781 |----------| |----------| | |Peer H:4 | |peer h:4 | 782 |AS F | |as f | | |----------| |----------| 783 |In:2 Out:6| |in:3 out:6| | |AS G | |as g | 784 |Peer J:1 | |peer j:1 | | |In:1 Out:3| |in:1 out:3| 785 |Peer H:4 | |peer h:4 | | | | | | 786 |----------| |----------| | +----+-----+ +----+-----+ 787 |AS G | |as g | | | | 788 |In:5 Out:3| |in:5 out:3| v v v 789 | | | | 790 +----+-----+ +----+-----+ 791 | | 792 v v 794 Figure 4: Intra-ISD PCB propagation from the ISD core down to 795 child ASes 797 2.2.1.1. Security 799 Each PCB contains signatures of all on-path ASes. Every time a 800 beacon service receives a PCB, it validates the PCB's authenticity. 801 During this process, the beacon service can query the certificate 802 service, for example, when it lacks an intermediate certificate. 804 2.2.1.2. Policies 806 Each AS can independently set policies dictating which PCBs are sent 807 in which time intervals, and to which neighbors. In particular, PCBs 808 do not need to be propagated immediately upon arrival. However, 809 during bootstrapping and if the AS obtains a PCB containing a 810 previously unknown path, the AS should forward the PCB immediately, 811 to ensure quick connectivity establishment. 813 2.2.2. Path Registration 815 Both the beacon service and the path service are involved in the path 816 registration process. A non-core AS typically receives several PCBs 817 representing several path segments to various core ASes. Out of 818 these PCBs, the non-core AS must select those down-path segments 819 through which it wants to be reached. It is the task of the AS's 820 beacon service to make this selection, according to the criteria 821 described in Path-Segment Selection (Section 2.2.2.1). The beacon 822 service then registers these path segments both at the local path 823 service and at the path service of all core ASes. When links fail, 824 segments expire, or better segments become available, the beacon 825 service updates the down-path segments registered for its AS. 827 As a result, a core AS's path service contains all intra-ISD path 828 segments registered by the leaf ASes of its ISD. In addition, a core 829 AS path service also stores the preferred core-path segments to other 830 core ASes. 832 2.2.2.1. Path-Segment Selection 834 Among the received PCBs, the beacon service of an AS must choose (1) 835 a set of PCBs to propagate further, and (2) a set of path segments to 836 register. The selection of these PCBs and path segments is based on 837 a path quality metric. This metric aims at identifying consistent, 838 diverse, efficient, and policy-compliant paths: 840 * _Consistency_ implies that at least one property along the path is 841 uniform, such as an AS capability (e.g., high bandwidth). 843 * _Diversity_ means that the set of paths announced over time are as 844 path-disjoint as possible, in order to provide high-quality 845 multipath options. 847 * _Efficiency_ refers to the length, bandwidth, latency, 848 utilization, and availability of a path, where more efficient 849 paths are naturally preferred. 851 * _Policy compliance_ implies that the path adheres to the AS's 852 routing policy. 854 Based on past PCBs, the AS beacon service assigns scores to the 855 current set of candidate path segments, and sends the best segments 856 in the next beaconing interval. 858 Core beaconing operates similarly to intra-ISD beaconing, except that 859 core PCBs only traverse core ASes. The same path selection metrics 860 apply, where a core AS attempts to forward the set of most desirable 861 paths to its neighbors. 863 2.2.3. Path Lookup 865 An end host (source) who wants to start communication with another 866 host (destination), requires up to three path segments: An up-path 867 segment to reach the ISD core, a core-path segment to reach the 868 destination ISD, and a down-path segment to reach the destination AS. 869 The source host queries the path service in its AS for such segments. 870 The path service has up-path segments stored in its database and 871 furthermore checks if it has appropriate core- and down-path segments 872 in its cache; in this case it returns them immediately. 874 If not, the path service in the source AS queries core path services 875 (using locally stored up-path segments) in the source ISD for core- 876 path segments to the destination ISD. Then, it combines up-path 877 segments with the newly retrieved core-path segments, and queries 878 core path services in the remote ISD to fetch remote down-path 879 segments. To improve overall efficiency, the local path service 880 caches the returned path segments and uses parallelism when 881 requesting path segments from core path services. Finally, the local 882 path service returns all path segments to the source host. 884 This recursive lookup significantly simplifies the process for end 885 hosts (which only have to send a single query, similar to stub DNS 886 resolvers). The caching strategy ensures that path lookups are fast 887 for frequently used destinations (similar to caching in recursive DNS 888 resolvers). 890 2.2.4. Link Failures 892 Unlike in the current Internet, link failures are not automatically 893 resolved by the network, but require active handling by end hosts. 894 Since SCION forwarding paths are static, they break when one of the 895 links fails. Link failures are handled by a two-pronged approach 896 that typically masks link failures without any outage to the 897 application and rapidly re-establishes fresh working paths: 899 * The SCION Control Message Protocol (SCMP) (the SCION equivalent of 900 ICMP) is used for signaling connectivity problems. Instead of 901 relying on application- or transport-layer timeouts, end hosts get 902 immediate feedback from the network if a path stops working, and 903 can quickly switch to an alternative path. 905 * SCION end hosts are encouraged to use multipath communication by 906 default, thus masking a link failure with another working path. 907 As multipath communication can increase availability (even in 908 environments with very limited path choices), SCION beacon 909 services attempt to create disjoint paths, SCION path services 910 attempt to select and announce disjoint paths, and end hosts 911 compose path segments to achieve maximum resilience to path 912 failure. Consequently, most link failures in SCION remain 913 unnoticed by the application, unlike the frequent (albeit mostly 914 brief) outages in the current Internet. See also [ANDERSEN2001], 915 [KATZ2012], [KUSHMAN2007], and [HITZ2021]. 917 2.3. SCION Data Plane 919 While the control plane is responsible for providing end-to-end 920 paths, the data plane ensures that packets are forwarded on the 921 selected path. SCION border routers forward packets to the next AS 922 based on the AS-level path in the packet header (which is extended 923 with ingress and egress interface identifiers for each AS), without 924 inspecting the destination address and also without consulting an 925 inter-domain forwarding table. Only the border router at the 926 destination AS needs to inspect the destination address to forward it 927 to the appropriate local end host. 929 Because SCION splits the information about the locator (the path 930 towards the destination AS) and the identifier (the destination 931 address), the identifier can have any format that the destination AS 932 can interpret--only the destination needs to consider that local 933 identifier (see also [RFC6830]). In other words, an AS can select an 934 arbitrary addressing format for its hosts, e.g., a 4-byte IPv4, 935 6-byte media access control (MAC) address, 16-byte IPv6, or any other 936 up to 16-byte addressing scheme. A valuable consequence is that 937 hosts with different address types can directly communicate. 939 The next two sections describe how an end host combines path segments 940 into an end-to-end forwarding path, and how border routers forward 941 packets efficiently. 943 *Note*: This section describes the SCION data plane on a very high 944 level. A much more detailed description of SCION's data plane will 945 follow in a separate internet draft. 947 2.3.1. Path Construction via Segment Combination 949 Through the path lookup, the end host obtains path segments that must 950 be combined into an end-to-end path. A valid SCION *forwarding path* 951 can be created by combining up to three path segments, in the 952 following ways: 954 * *Immediate combination of path segments*: The last AS on the up- 955 path segment is also the first AS on the down-path segment. In 956 this case, the simple combination of an up-path segment and a 957 down-path segment creates a valid forwarding path. 959 * *AS shortcut*: The up-path segment and down-path segment intersect 960 at a non-core AS. In this case, a shorter forwarding path can be 961 created by removing the extraneous part of the path. 963 * *Peering shortcut*: A peering link exists between the two 964 segments, so a shortcut via the peering link is possible. As in 965 the AS shortcut case, the extraneous path segment is cut off. The 966 peering link could be traversing to a different ISD. 968 * *Combination with a core-path segment*: The last AS on the up-path 969 segment is different from the first AS on the down-path segment. 970 This case requires an additional core-path segment to connect the 971 up- and down-path segment. If the communication remains within 972 the same ISD, a local ISD core-path segment is needed; otherwise, 973 an inter-ISD core-path segment is required. 975 * *On-path*: The destination AS is part of the up-path segment or 976 the source AS is part of the down-path segment; in this case, a 977 single up- or down-path segment, respectively, is sufficient to 978 create a forwarding path. 980 Once a forwarding path is chosen, it is encoded in the SCION packet 981 header. This makes inter-domain routing tables unnecessary for 982 border routers: Both the ingress and the egress interface of each AS 983 on the path are encoded as *packet-carried forwarding state (PCFS)* 984 in the packet header. The destination can respond to the source by 985 reversing the end-to-end path from the packet header, or it can 986 perform its own path lookup and combination. 988 The SCION packet header contains of a sequence of *hop fields (HFs)*, 989 one HF for each AS that is traversed on the end-to-end path. Each 990 hop field contains the encoded numbers of the ingress and egress 991 links, and thus defines which interfaces may be used to enter and 992 leave an AS. In addition to the hop fields, each path segment 993 contains an *info field (INF)* with basic information about the 994 segment. A host can create an end-to-end forwarding path by 995 extracting info fields and hop fields from path segments, as depicted 996 in Figure 5. The additional meta header (META) contains pointers to 997 the currently active INF and HF. 999 up-path segment core-path segment down-path segment 1001 +-------+ +-------+ +-------+ 1002 |+-----+| |+-----+| |+-----+| 1003 |+ INF ||----------+ |+ INF ||---+ |+ INF ||-+ 1004 |+-----+| | |+-----+| | |+-----+| | 1005 |+-----+| | |+-----+| | |+-----+| | 1006 || hf ||--------+ | || hf ||---+--+ || hf ||-+--+ 1007 |+-----+| | | |+-----+| | | |+-----+| | | 1008 |+-----+| | | |+-----+| | | |+-----+| | | 1009 || hf ||-----+ | | || hf ||---+--+--+ || hf ||-+--+--+ 1010 |+-----+| | | | |+-----+| | | | |+-----+| | | | 1011 |+-----+| | | | +-------+ | | | +-------+ | | | 1012 || hf ||--+ | | | | | | | | | 1013 |+-----+| | | | | +--------+ | | | | | | 1014 +-------+ | | | | |++-----+| | | | | | | 1015 | | | | |++ Meta|| | | | | | | 1016 | | | | |++-----+| | | | | | | 1017 | | | | |+-----+ | | | | | | | 1018 | | | +-->|+ INF | | | | | | | | 1019 | | | |+-----+ | | | | | | | 1020 | | | |+-----+ | | | | | | | 1021 | | | |+ INF | |<-+ | | | | | 1022 | | | |+-----+ | | | | | | 1023 | | | |+-----+ | | | | | | 1024 | | | |+ INF | |<----+--+----------------+ | | 1025 | | | |+-----+ | | | | | 1026 | | | |+-----+ | | | | | 1027 | | +---->|| hf | | | | | | 1028 | | |+-----+ | | | | | 1029 | | |+-----+ | | | | | 1030 | +------->|| hf | | | | | | 1031 | |+-----+ | | | | | 1032 | |+-----+ | | | | | 1033 +---------->|| hf | | | | | | 1034 |+-----+ | | | | | 1035 |+-----+ | | | | | 1036 || hf | |<----+ | | | 1037 |+-----+ | | | | 1038 |+-----+ | | | | 1039 || hf | |<-------+ | | 1040 |+-----+ | | | 1041 |+-----+ | | | 1042 || hf | |<---------------------------+ | 1043 |+-----+ | | 1044 |+-----+ | | 1045 || hf | |<------------------------------+ 1046 |+-----+ | 1047 +--------+ 1048 forwarding path 1050 Figure 5: Combining three path segments into a forwarding path 1052 2.3.2. Path Authorization 1054 It is crucial for the data plane that end hosts only use paths 1055 constructed and authorized by ASes in the control plane. In 1056 particular, end hosts should not be able to craft HFs themselves, 1057 modify HFs in authorized path segments, or combine HFs of different 1058 path segments (path splicing). This property is called *path 1059 authorization* (see [KLENZE2021] and [LEGNER2020]). 1061 SCION achieves path authorization by creating message-authentication 1062 codes (MACs) during the beaconing process. Each AS calculates these 1063 MACs using a local secret key (that is only shared between SCION 1064 infrastructure elements within the AS) and chains them to the 1065 previous HFs. The MACs are then included in the forwarding path as 1066 part of the respective HFs. 1068 2.3.3. Forwarding 1070 Routers can efficiently forward packets in the SCION architecture. 1071 In particular, the absence of inter-domain routing tables and of 1072 complex longest-IP-prefix matching performed by current routers 1073 enables the construction of more efficient routers. 1075 During packet forwarding, a SCION border router at the ingress point 1076 of the AS verifies that: 1078 * the packet entered through the correct ingress interface 1079 corresponding to the information in the HF, 1081 * the HF is still valid, and 1083 * the MAC in the HF is correct. 1085 If the packet has not yet reached the destination AS, the egress 1086 interface number in the HF of the non-destination AS refers to the 1087 egress SCION border router of this AS. In this case, the packet can 1088 be sent from the ingress SCION border router to the egress SCION 1089 border router via native intra-domain forwarding (e.g., IP or MPLS). 1090 In case the packet has arrived at the destination AS, the destination 1091 AS's border router inspects the destination address and sends the 1092 packet to the corresponding host. 1094 2.3.4. Intra-AS Communication 1096 SCION routers use IP to communicate within an AS, therefore they rely 1097 on existing intra-domain routing protocols, such as Multiprotocol 1098 Label Switching (MPLS) or others. 1100 3. Deployment 1102 Adoption of a next-generation architecture is a challenging task, as 1103 it needs to be integrated with, and operate alongside existing 1104 infrastructure. SCION is designed to coexist with existing intra- 1105 domain routing infrastructure, and comprises coexistence and 1106 transition mechanisms that facilitate adoption, in accordance to 1107 principles defined in [RFC8170]. The following section discusses 1108 practical considerations for deploying SCION and briefly touches on 1109 some of the transition mechanisms, with focus on: 1111 * Autonomous Systems (Section 3.1), 1113 * Internet Exchange Points (Section 3.2), and 1115 * end hosts (Section 3.3), covering both native SCION hosts and 1116 SCION to IP encapsulation. 1118 We then describe some of the early adopters deployment experiences. 1119 A more detailed adoption plan is to be outlined in dedicated 1120 documents. 1122 3.1. Autonomous System Deployment 1124 A SCION AS needs to deploy the SCION infrastructure components 1125 (Section 1.2.3) and border routers. Within an AS, SCION is often 1126 deployed as an IP overlay on top of the existing network. This way 1127 SCION allows to reuse the existing intra-domain network and equipment 1128 (e.g., IP, MPLS). Customer-side SCION border routers directly 1129 connect to the provider-side border routers using last-mile 1130 connections. The SCION design assumes that AS's internal entities 1131 are considered to be trustworthy, therefore the IP overlay or the 1132 first-hop routing does not compromise or degrade any security 1133 properties SCION delivers. When it comes to inter-domain 1134 communication, an overlay deployment on top of today's Internet is 1135 not desirable, as SCION would inherit issues from its weak underlay. 1136 Thus, inter-AS SCION links are usually deployed in parallel to 1137 existing links, in order to preserve its security properties. That 1138 is, two SCION border routers from neighbour ASes are directly 1139 connected via a layer-2 cross-connection at a common point-of- 1140 presence. 1142 All SCION AS components can be deployed on standard x86 commercial 1143 off-the-shelf servers or virtual machines. In fact, SCION border 1144 routers do not rely on forwarding tables, therefore they do not 1145 require specialized hardware. Practice shows that off-the-shelf 1146 hardware can handle up to 100 Gbps links, while a prototype P4 1147 implementation [DERUITER2021] showed that it is possible to forward 1148 SCION traffic even at terabit speeds. 1150 Overall, an AS can be connected to SCION without high-impact changes 1151 to its network. In addition, use of commodity hardware for both 1152 control and data-plane components reduces initial deployment costs. 1154 3.2. Internet Exchange Points 1156 Internet Exchange Points (IXP) play as important a role for SCION as 1157 they do in today's Internet. SCION can be deployed at existing IXPs 1158 following a "big switch" model, where the IXP provides a large L2 1159 switch between multiple SCION ASes. SCION has been deployed 1160 following this model at the Swiss Internet Exchange (SwissIX), 1161 currently interconnecting major SCION Swiss ISPs and enterprises 1162 through bi-lateral peering over dedicated SCION ports. 1164 Additionally, thanks to its path-awareness, SCION offers the option 1165 of an enhanced deployment model, i.e., to expose the internal 1166 topology of an IXP within the SCION control plane. This enables IXP 1167 customers to use SCION's multi-path and fast failover capabilities to 1168 leverage the IXP's internal links (including backup links) and to 1169 select paths depending on the application's needs. IXPs have 1170 therefore an incentive to expose their rich internal connectivity, as 1171 the benefits from SCION's multi-path capabilities would increase 1172 their value for customers and provide them with a competitive 1173 advantage. 1175 3.3. End Hosts and Incremental Deployability 1177 End users can leverage SCION in two different ways: (1) using SCION- 1178 aware applications on a SCION native end host (Section 3.3.1), or (2) 1179 using transparent IP-to-SCION conversion (Section 3.3.2). The 1180 benefit of using SCION natively is that the full range of advantages 1181 becomes available to applications, at the cost of installing the 1182 SCION endpoint stack and making the application SCION-aware. In 1183 early deployments, the second approach is often preferred, so that no 1184 changes are needed within applications or end hosts. 1186 3.3.1. Native End Hosts 1188 A SCION native end host's stack consists of a dispatcher, which 1189 handles all incoming and outgoing SCION packets, and of a SCION 1190 daemon, which handles control-plane messages. The latter fetches 1191 paths to remote ASes and provides an API for applications and 1192 libraries to interact with the SCION control plane (i.e., for path 1193 lookup, SCION extensions). The current SCION implementation uses an 1194 UDP/IP underlay for communication between end hosts and SCION 1195 routers. This allows reuse of existing intra-domain networking 1196 infrastructure. SCION end hosts can optionally use automated 1197 bootstrapping mechanisms to retrieve configuration from the network 1198 and establish SCION connectivity. This way, clients require no pre- 1199 existing network-specific configurations. 1201 3.3.2. SCION to IP Gateway (SIG) 1203 A SCION-IP-Gateway (SIG) encapsulates regular IP packets into SCION 1204 packets with a corresponding SIG at the destination that performs the 1205 decapsulation. A SIG can be deployed close to the end user (i.e., at 1206 branches of an enterprise, on a CPE), or within an ISP's network. In 1207 the latter case, the SIG is called carrier-grade SIG, as it serves 1208 multiple customers within the AS where it is deployed. This approach 1209 has the advantage that it does not require any changes at the 1210 customer's premises. In order to allow incremental deployability and 1211 to ease transition from legacy IP-based Internet to SCION, SIGs can 1212 be augmented with mechanisms allowing them to coordinate and 1213 automatically exchange IP prefix information. A more detailed 1214 description of the SIG and its coordination mechanisms is to be 1215 presented in dedicated documents. 1217 3.4. Deployment Experiences 1219 SCION has been deployed in production by multiple entities, growing 1220 its acceptance among industry. While early deployments started on 1221 academic and research networks, SCION has expanded to serve the 1222 financial industry, government, and it is being evaluated for the 1223 healthcare sector. 1225 In 2017, SCION was evaluated for production use by a central bank, 1226 with the goal of modernising the network interconnecting banks and 1227 their branches. SCION was chosen, as it allows moving away from a 1228 dedicated private network to a reliable Internet-based solution. 1229 SCION connectivity was later extended to support system-critical 1230 applications, like the national real-time gross settlement (RTGS) 1231 system, connecting all country's banks to exchange real-time payment 1232 information. The network, called Secure Swiss Finance Network or 1233 SSFN (https://perma.cc/PU5L-ALPM), is implemented as a SCION ISD, 1234 where a federation of three ISPs forms the ISD core. Financial 1235 institutions are themselves SCION ASes and directly connect to one or 1236 more of the core ASes. Institutions deploy SCION-IP gateways (SIGs), 1237 transparently enabling their traditional IP-based applications to use 1238 the SCION network. The concept of the SCION ISD also provides a 1239 mechanism to implement strict governance and access control (through 1240 the issuance of AS certificates). 1242 Besides the SSFN, SCION connectivity has also been adopted by 1243 government entities for their international communications. In 1244 addition, Swiss higher education institutions are connected thanks to 1245 the SCI-ED (http://scied.scion-architecture.net/) network. 1247 In addition to productive deployments, SCION also comprises a global 1248 SCION research testbed called SCIONLab (https://www.scionlab.org). 1249 It is composed of dozens of globally distributed infrastructure ASes, 1250 mostly run by academic institutions. The testbed is open to any user 1251 who can easily set up their own AS with the aid of a web-based UI, 1252 connect to the network, and run experiments. The setup has been the 1253 earliest global deployment of SCION and it has been supporting 1254 research and development of path-aware networking and SCION. 1256 4. IANA Considerations 1258 Currently, this document has no request for action to IANA. However, 1259 when full specification of SCION is available, requests for IANA 1260 actions are expected regarding the registration of optional packet 1261 header fields as well as the coordination of SCION ISD and AS number 1262 assignments. 1264 5. Security Considerations 1266 SCION has been designed from the outset to offer security by default, 1267 and thus there are manifold security considerations. As a matter of 1268 fact, SCION's protocol design has been formally verified and the open 1269 source router implementation is undergoing formal verification (see 1270 also [KLENZE2021]). Describing all security considerations here, 1271 therefore, would go beyond the scope of this document. A separate 1272 document including all security implications and considerations will 1273 follow later. 1275 6. References 1277 6.1. Normative References 1279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", BCP 14, RFC 2119, 1281 DOI 10.17487/RFC2119, March 1997, 1282 . 1284 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1285 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1286 May 2017, . 1288 6.2. Informative References 1290 [ANDERSEN2001] 1291 Andersen, D., Balakrishnan, H., Kaashoek, F., and R. 1292 Morris, "Resilient overlay networks", Proceedings of the 1293 eighteenth ACM symposium on Operating systems principles, 1294 DOI 10.1145/502034.502048, October 2001, 1295 . 1297 [CHUAT22] Chuat, L., Legner, M., Basin, D., Hausheer, D., Hitz, S., 1298 Mueller, P., and A. Perrig, "The Complete Guide to SCION", 1299 ISBN 978-3-031-05287-3, 2022, 1300 . 1302 [COOPER2013] 1303 Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S. 1304 Goldberg, "On the risk of misbehaving RPKI authorities", 1305 Proceedings of the Twelfth ACM Workshop on Hot Topics 1306 in Networks, DOI 10.1145/2535771.2535787, November 2013, 1307 . 1309 [DERUITER2021] 1310 de Ruiter, J. and C. Schutijser, "Next-generation internet 1311 at terabit speed: SCION in P4", Proceedings of the 17th 1312 International Conference on emerging Networking 1313 EXperiments and Technologies, DOI 10.1145/3485983.3494839, 1314 December 2021, . 1316 [GRIFFIN1999] 1317 Griffin, T. and G. Wilfong, "An analysis of BGP 1318 convergence properties", ACM SIGCOMM Computer 1319 Communication Review Vol. 29, pp. 277-288, 1320 DOI 10.1145/316194.316231, October 1999, 1321 . 1323 [HITZ2021] Hitz, S., "Demonstrating the reliability and resilience of 1324 Secure Swiss Finance Network", 2021, 1325 . 1327 [KATZ2012] Katz-Bassett, E., Scott, C., Choffnes, D., Cunha, Í., 1328 Valancius, V., Feamster, N., Madhyastha, H., Anderson, T., 1329 and A. Krishnamurthy, "LIFEGUARD: practical repair of 1330 persistent route failures", ACM SIGCOMM Computer 1331 Communication Review Vol. 42, pp. 395-406, 1332 DOI 10.1145/2377677.2377756, September 2012, 1333 . 1335 [KING2022] King, D., Farrel, A., and C. Jacquenet, "Challenges for 1336 the Internet Routing Systems Introduced by Semantic 1337 Routing", 2022, . 1340 [KLENZE2021] 1341 Klenze, T., Sprenger, C., and D. Basin, "Formal 1342 Verification of Secure Forwarding Protocols", 2021 IEEE 1343 34th Computer Security Foundations Symposium (CSF), 1344 DOI 10.1109/csf51468.2021.00018, June 2021, 1345 . 1347 [KUSHMAN2007] 1348 Kushman, N., Kandula, S., and D. Katabi, "Can you hear me 1349 now?!: it must be BGP", ACM SIGCOMM Computer Communication 1350 Review Vol. 37, pp. 75-84, DOI 10.1145/1232919.1232927, 1351 March 2007, . 1353 [LABOVITZ2000] 1354 Labovitz, C., Ahuja, A., Bose, A., and F. Jahanian, 1355 "Delayed Internet routing convergence", Proceedings of the 1356 conference on Applications, Technologies, Architectures, 1357 and Protocols for Computer Communication - SIGCOMM '00, 1358 DOI 10.1145/347059.347428, 2000, 1359 . 1361 [LEGNER2020] 1362 Legner, M., Klenze, T., Wyss, M., Sprenger, C., and A. 1363 Perrig, "EPIC: Every Packet Is Checked in the Data Plane 1364 of a Path-Aware Internet", 2020, 1365 . 1368 [LI2014] Li, Q., Hu, Y., and X. Zhang, "Even Rockets Cannot Make 1369 Pigs Fly Sustainably: Can BGP be Secured with BGPsec?", 1370 Proceedings 2014 Workshop on Security of Emerging 1371 Networking Technologies, DOI 10.14722/sent.2014.23001, 1372 2014, . 1374 [LYCHEV2013] 1375 Lychev, R., Goldberg, S., and M. Schapira, "BGP security 1376 in partial deployment: is the juice worth the squeeze?", 1377 ACM SIGCOMM Computer Communication Review Vol. 43, pp. 1378 171-182, DOI 10.1145/2534169.2486010, September 2013, 1379 . 1381 [MORILLO2021] 1382 Morillo, R., Furuness, J., Morris, C., Breslin, J., 1383 Herzberg, A., and B. Wang, "ROV++: Improved Deployable 1384 Defense against BGP Hijacking", Proceedings 2021 Network 1385 and Distributed System Security Symposium, 1386 DOI 10.14722/ndss.2021.24438, 2021, 1387 . 1389 [PERRIG2017] 1390 Perrig, A., Szalachowski, P., Reischuk, R., and L. Chuat, 1391 "SCION: A Secure Internet Architecture", 1392 ISBN 978-3-319-67079-9, 2017, 1393 . 1395 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1396 Rose, "DNS Security Introduction and Requirements", 1397 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1398 . 1400 [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, 1401 DOI 10.17487/RFC4264, November 2005, 1402 . 1404 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1405 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1406 . 1408 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1409 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1410 February 2012, . 1412 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1413 Locator/ID Separation Protocol (LISP)", RFC 6830, 1414 DOI 10.17487/RFC6830, January 2013, 1415 . 1417 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 1418 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 1419 May 2017, . 1421 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 1422 Specification", RFC 8205, DOI 10.17487/RFC8205, September 1423 2017, . 1425 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1426 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1427 . 1429 [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to 1430 Deployment (A Bestiary of Roads Not Taken)", RFC 9049, 1431 DOI 10.17487/RFC9049, June 2021, 1432 . 1434 [RFC9217] Trammell, B., "Current Open Questions in Path-Aware 1435 Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, 1436 . 1438 [ROTHENBERGER2017] 1439 Rothenberger, B., Asoni, D., Barrera, D., and A. Perrig, 1440 "Internet Kill Switches Demystified", Proceedings of the 1441 10th European Workshop on Systems Security, 1442 DOI 10.1145/3065913.3065922, April 2017, 1443 . 1445 [SAHOO2009] 1446 Sahoo, A., Kant, K., and P. Mohapatra, "BGP convergence 1447 delay after multiple simultaneous router failures: 1448 Characterization and solutions", Computer 1449 Communications Vol. 32, pp. 1207-1218, 1450 DOI 10.1016/j.comcom.2009.03.009, May 2009, 1451 . 1453 [SCHUCHARD2011] 1454 Schuchard, M., Mohaisen, A., Foo Kune, D., Hopper, N., 1455 Kim, Y., and E. Vasserman, "Losing control of the 1456 internet: using the data plane to attack the control 1457 plane", Proceedings of the 17th ACM conference on Computer 1458 and communications security - CCS '10, 1459 DOI 10.1145/1866307.1866411, 2010, 1460 . 1462 Acknowledgments 1464 Many thanks go to Cyrill Kraehenbuehl and Juan A. Garcia-Pardo for 1465 reviewing this document. We are also indebted to Laurent Chuat, 1466 Markus Legner, David Basin, David Hausheer, Samuel Hitz, and Peter 1467 Mueller, for writing the book "The Complete Guide to SCION" (see 1468 [CHUAT22]), which provides the background information needed to write 1469 this informational draft. 1471 Authors' Addresses 1473 Corine de Kater 1474 ETH Zuerich 1475 Email: corine.dekatermuehlhaeuser@inf.ethz.ch 1477 Nicola Rustignoli 1478 ETH Zuerich 1479 Email: nicola.rustignoli@inf.ethz.ch 1481 Adrian Perrig 1482 ETH Zuerich 1483 Email: adrian.perrig@inf.ethz.ch