]> SCION Association

kme@scion.org

ETH Zürich

juan.garcia@inf.ethz.ch

ETH Zürich

tilmann.zaeschke@inf.ethz.ch

SCION Association

nic@scion.org

IRTF PANRG Internet-Draft This draft intends to summarize all SCION related questions which are deemed important to be answered for SCION to properly work at Internet scale. The set of questions is at the moment not comprehensive, but we intend them to initiate a discussion to determine which questions should remain here, and which ones are missing. When appropriate, some example solutions can be provided for the community to determine whether said solutions are adequate or not. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction SCION is an inter-domain network architecture. Its core components, as deployed by some of its early adopters, are specified in , , which are currently under ISE review. The goal of this draft is to explore how SCION and its early deployment experiences can help address open research questions in . Specifically, there are still many open areas of research around path-aware networking, where SCION with its early deployment experiences and research efforts can provide a contribution. This can also be a starting point for discussions around long-term protocol evolution. This draft assumes the reader is familiar with some of the fundamental concepts defined in the components specification. Note: This is a very early version of the SCION research questions draft, and it merely contains a selection of potential topics to be further discussed in this draft. Any feedback is welcome and much appreciated. Thanks!

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

Discovery, Distribution, and Trustworthiness of Path Properties

ISD, AS Identity In the SCION specification, identifiers for ISDs and ASes are 16 bits and 48 bits long respectively. Whilst 48 bits for the AS will accommodate up to 2.81475e14 assignments which is likely to be more than sufficient for the future, using 16 bits for the ISD only offers 65,536 possible assignments. Further investigation on whether this is sufficient is required. The following questions arise: (not comprehensive)

• How many ASes do we expect in the SCION network model?
• Can one AS belong to many ISDs?
• Are AS numbers globally unique, or only unique within each ISD?
• How many ISDs do we expect?
• What is the ontology of an ISD?
  • Per geographic area?
  • Per legal jurisdiction?
  • Per capacity tier?
  • Per "type"? (meaning: any grouping that makes sense to their members)
  • Possible combinations of any previous "types"?
• Note that, to achieve global connectivity, ISDs require core links to other ISDs. This reduces the number of ISDs to those that have core ASes that can directly connect to core ASes in other ISDs. The number of ISDs is still super-exponential asymptotically.

Beacon Selection Policies Path discovery between SCION ASes relies on Path Construction Beacons (PCBs). In core beaconing PCBs are propagated omnidirectionally, unless this would cause a loop or exceed the maximum path length. A core AS selects a small number of paths to/from other core ASes, based on its beacon selection policy. It then propagates valid and policy compliant paths to neighbor ASes. The number of propagated beacons is limited to the best PCBs set size, in order to avoid that the number of paths (and beacons) grows exponentially with core network size. Some potential questions are:

• Limiting the number of beacons to a best PCBs set size per AS results in a partial view of the network being available to endpoints. To what point this affects endpoint's path-selection possibilities?
• what is a good, practical, general purpose policy, that can fulfill conflicting requirements of both operators and endpoints, as highlighted in section 2.7 of ?
• What are the desirable path properties (e.g. diversity, PCB Expiration Time, how recently the same PCBs was forwarded before).

Name Resolution and DNS Service Binding (SVCB) In current deployments, SCION addresses are added to TXT records. Example of current entry: The DNS Service Binding allows a dedicated SCION Service Parameter to be specified. Service Parameters allow the specification of alternative IP addresses or other parameters (such as ISD/AS numbers) for a given URL. This would be more elegant than using DNS TXT records. With SVCB this may look like this for https: SVCB is also planned to be supported by Happy Eyeballs v3 .

Segment Dissemination A path look-up in SCION works similarly to a recursive DNS query (section 4 of ):

• The source endpoint queries the control service in its own AS.
• The local AS has already at least one segment to one core AS of its local ISD. It uses it to query the core AS' control service for segments to core ASes of the remote ISD.
• The local AS has now segments also from its local ISD core ASes to core ASes in the remote ISD. The local AS queries the remote ISD's core ASes for segments to the destination AS.
• The local AS returns all these segments to the endpoint, to be combined.

Control services may return a large number of path segments for some queries. This can cost considerable bandwidth while at the same time overload clients with an unnecessarily large numbers of segments.

• This problem may be more acute in ASes with many endpoints (e.g. IoT), or for resource-constrained endpoints.
• Getting a full path to a remote endpoint may require three queries to control services.

There are multiple possible and independent solution steps here:

• Predefine some policies that can be resolved by the control plane, e.g. ANY, BEST_LATENCY, BEST_BANDWIDTH, BEST_PRICE, BEST_CO2. For these, the control plane could simply calculate 5-10 compliant paths and return these. Moreover these could be cached for commonly requested remote ASes. If a user requires a custom policy they can still resort to requesting actual segments.
• Caching of paths. An open question concerns when a control service should return a chached path, versus performing a recursive path lookup.

An example including the number of core segments between different ISDs as of 2024-07-12 in the SCION production network is shown in . core segment count examples

src ISD	dst ISD	segments returned
64	64	337
64	65	240
64	67	60

Periodic Beacon Propagation The SCION control plane protocol specifies that beacons should be propagated periodically. Is this really necessary?

• For path freshness, only the initial AS emitting the PCB needs to originate beacons periodically, and others can disseminate immediately.
• As response to link failures or availability of new paths, beacon services can respond instantly.

If no periodic propagation is necessary for path freshness or to respond to link failures, the periodic propagation would only be used for the discovery of new paths at each interval, enhancing the scalability and path diversity.

Beacon Optimization and Extensibility Communication requirements vary according to source, destination, and application. Satisfying all these requirements either requires discovering all paths in the network, or optimizing the creation of paths during the beaconing process. Selecting the 5 shortest paths per destination for each beaconing period may not satisfy all requirements that different applications, on different endpoints, and on different ASes, will have. The beacon selection process, the criteria and metrics that they carry, and the adaptability of them all have a strong impact in the traffic engineering of the individual ASes, and of the inter-domain communication as a whole. See question 2.7 of .

• What optimization functions should be applied to beacons and what metrics should be considered when propagating them? Is the set of properties composed of path length, peering ASes, path disjointness, PCB last reception, and path lifetime enough?
• How do we extend the metrics with new dimensions, such as bandwidth, latency, geo-position, etc?
• Who should select these functions?
• How should the outcome of these functions be verified?
• How can multiple functions be applied concurrently, for different source and destination applications?
• How should end-ASes express their desired requirements to the inter-domain control plane?
• How do these requirements translate into concrete optimization functions?
• How would standardization of the functions look like?
• The functions changing over time:
  • How can optimization functions adapt to incorporate these changes?
  • How to achieve fast adaptation of optimization functions?
• See also: IREC

DRKey DRKey is a key distribution system that scales well with the number of endpoints in the network. It relies on two things:

• Two sides of a key: a fast side, and a slow side. Sometimes called fast and slow side of the derivation. The ability of deriving a key very quickly on the fast side is necessary for most of its use cases.
• A grouping of endpoints (such as ASes): The pieces necessary to derive a key, namely the L1 keys, are communicated to each keystore at each grouping (e.g., a keystore per AS).

The questions related to DRKey are the following ones (not comprehensive):

• Do we want to have any possible authorization that is at the moment carried out at the data-plane to be moved to the control-plane? This could include e.g. authorization to deliver traffic depending on the source, but also information like port numbers/ranges per source, etc.
  • Could this obsolete firewalls? What else would be necessary?
  • What do we mean when we say "authorize transit"?
• Could perfect forward secrecy DRKey be useful, and should we research it?
  • What would be the trust model? Do end-users trust their ASes to ephemerally create personal keys?
  • What would be the attacker model?
  • Which use cases are relevant?

For more info: .

SCMP Authentication In SCION, endpoints are responsible to select alternate paths in case of failure. One approach to detect failures is to rely on signals from the network, such as SCMP (SCION Control Message Protocol) messages. These signals must be authenticated in order to be trusted by endpoints. This reflects a question raised in section 2.7 of . One option is to use DRKey as the mechanism to use to derive the authentication key, where the fast path would be on the infrastructure side (e.g. the border router in the case of an interface down type of message), and the slow side being on the intended endpoint destination for that SCMP message (e.g. the endpoint receiving the SCMP interface down message). Another option is to leverage the control-plane PKI. However, we have identified a number of possible issues (not comprehensive):

• Denial of Service/Capability Attacks: If an endpoint receives (too) many SCMP messages, it will need (too) many resources just to authenticate their origin. Most of these messages could just be sent to the endpoint to exhaust its processing capacity.
• Sending an SCMP message in certain cases might be an amplification factor: If a border router sends an SCMP message (e.g. interface down) on all cases, even with small packets, there is the risk of having that border router sending a lot of traffic to a possibly unintended recipient, e.g. when the packet is not source validated. In addition, validation may trigger additional requests for keys.

Proof of Transit FABRID and EPIC .

NAT Currently, the SCION implementation is not compatible out-of-the-box with NAT'ed devices, regardless of whether these devices are end-hosts, or even running SCION services. This is due to the (UDP-IP) underlay being modified by the NAT mechanism, but not the internal destination SCION address. Although this does not concern the SCION protocols themselves, we want to check that this will not be a problem. Critically, the SCION header needs to contain the SRC address as seen by the border router so that the border router can forward incoming response packets to the correct NAT device and port. Possible solutions:

• With IPv6 as an intra-domain protocol, this problem disappears.
• Introduce a mechanism so that the SCION border router can report the NATed address to an endpoint (similar to a STUN server).

Data Plane Stability

Link Load Balancing Links may get overloaded because the SCION distributed path selection process fails to distribute load properly over different links, resulting in uneven utilization. There are several potential approaches to relieve an overloaded link:

• introduce explicit congestion notifications from routers to endpoints.
• optimize the path lookup process so that the control plane hands out paths that optimize load balancing.

Reverse Path Refreshment When a client and server communicate, return traffic should usually follow the same reverse path. If the server uses that path for a long period of time, the path will eventually expire. How should the server determine the path for return traffic and at which layer? How to avoid this being a vector pf path hijackings? There are some relevant points for the discussion:

• In order to send data back to the client, the server needs to store the path locally (analogous to storing the client's 4-tuple in an TCP/IP scenario).
• More generally, if multiple paths are used to contact the server, which one of those would be used to reply? Should this be responsibility of the transport protocol, as in the case of QUIC-MP ?
• How long before path expiration should the client and server still use a path? The client can choose from paths that will not expire in a short period of time, but it does not control for how long the server will attempt to use it (i.e. how long it will take the server to send the complete response).

Proposed Solutions (not comprehensive)

• The server MUST ask the control plane for a path, regardless of the client's policy.
• The client SHOULD (somehow) send a new packet with a new path, prompting the server to use this path from now on.
• The client and server agree, via a path policy specification, on which kinds of paths are okay for the server to use. This solution implies a standard specification of this path policy.
• Leave the solution to the application and transport layers. Transport protocols may require keep alive messages, or already support multiple paths. Applications should know for how long they are willing to read a response from a server. With this knowledge these two layers can easily determine when to send a new path (analogous to connection migration in QUIC ), so that the server is instructed to use it for the next replies.
• The server must ask the control plane for a path, regardless of the client's policy.
• The client (somehow) sends a new packet with a new path, prompting the server to use this path from now on.

There are some nuances: Usually the server's API will store the initial address of the client to be used through all the session. A related question: how long before expiration should a path be used? Is reverse path refresh a relevant problem?

• Contra: It is probably rare that a server needs to send data for a long time without the application layer protocol requiring the client to ever answer back.
• Pro: The client may happen to have an old-ish path. If we can't refresh, the client always needs to consider whether a path is valid "long enough", which might only be possible to guess.
• Contra: Sending keep-alives sounds like a connection based protocol. It also means we need to figure out when to stop sending keep-alives.
• Contra: It may be better to solve this in the application layer or in the overlay protocol, where we we know more about potential length of the session, whether this is a singular request/answer type of exchange, or whether more frequent keep-alives are required anyway.

Interfacing SCION with Existing Technologies The questions posed here are:

• What existing protocols/solutions should be compatible with SCION simultanously? How can ISPs offer traditional IP side by side with SCION.
• Could a future evolution of the SCION specification better reuse existing technologies? Referring to the possibility of slightly changing an existing technology (e.g. IPv6) to be used as part of SCION, replacing part of the ad-hoc specification that we have for SCION.
• What would be required effort to make them work? Referring to the ranking according to different types of parties involved: ISPs, vendors, application developers, etc.

There are several possibilities of existing protocols/technologies/solutions that may work for this purpose:

• IPv6 in the Data Plane. Use an IPv6 routing header as specified in 4.4. of .
• SCION IP Gateway. See section 3 of
• SCION-IP translation
• How can we interface with QUIC Multipath ?
• How can we interface with, and what is the relationship to TAPS ?

Implications of Path Awareness for the Transport and Application Layers This question relates to 2.5 in .

• How to express transport preferences and map them to SCION path properties?

Naming To be discussed

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet. This document poses questions in path-aware networking, open as of 2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group (PANRG), and has been published to snapshot current thinking in this space. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Alibaba Inc. Uber Technologies Inc. University of Mons (UMONS) UCLouvain and Tessares Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. SCION Association SCION Association Anapaya Systems This document describes the control plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to SCION- capable endpoints. In fact, endpoints can choose between multiple path options, enabling the optimization of network paths. The SCION control plane is responsible for discovering these paths and making them available to the endpoints. The main goal of SCION's control plane is to create and manage path segments, which can then be combined into forwarding paths to transmit packets in the data plane. This document first discusses how path exploration is realized through beaconing and how path segments are created and registered. Each SCION autonomous system (AS) can register segments according to its own policy - it is free to specify which path properties and algorithm(s) to use in the selection procedure. The document then describes the path lookup process, where endpoints obtain path segments - a fundamental building block for the construction of end-to-end paths. SCION Association SCION Association Anapaya Systems This document presents the trust concept and design of the SCION _control-plane Public Key Infrastructure (PKI)_, SCION's public key infrastructure model. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture. The control-plane PKI, or short CP-PKI, handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's control plane to authenticate and verify path information, and builds the basis for SCION's special trust model based on so-called Isolation Domains. This document first introduces the trust model behind the SCION's control-plane PKI, as well as clarifications to the concepts used in it. This is followed by specifications of the different types of certificates and the Trust Root Configuration. The document then specifies how to deploy the whole infrastructure. SCION Association SCION Association Anapaya Systems This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION control plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION data plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION data plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document first provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers - these are described, too. The document then shows the life cycle of a SCION packet while traversing the SCION Internet. This is followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References SCION Association SCION Association SCION is an inter-domain Internet architecture that focuses on security and availability. Its fundamental functions are carried out by a number of components. This document analyzes its core components from a functionality perspective, describing their dependencies, outputs, and properties provided. The goal is to answer the following questions: * What are the main components of SCION and their dependencies? Can OVGU Magdeburg, Germany OVGU Magdeburg, Germany OVGU Magdeburg, Germany ACM This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. ETH Zürich ETH Zürich ETH Zürich ETH Zürich DRKey is a pragmatic Internet-scale key-establishment system that allows any host to locally obtain a symmetric key to enable a remote service to perform source-address authentication, and enables first- packet authentication. The remote service can itself locally derive the same key with efficient cryptographic operations. DRKey was developed with path aware networks in mind, but it is also applicable to today's Internet. It can be incrementally deployed and it offers incentives to the parties using it independently of its dissemination in the network. ETH Zürich ETH Zürich ETH Zürich ETH Zürich Australian National University ETH Zürich ETH Zürich ETH Zürich ETH Zürich ETH Zürich ETH Zürich ETH Zürich ETH Zürich ETH Zürich Armasuisse ETH Zürich Armasuisse Apple Inc Google LLC Google LLC Google LLC Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305.

Acknowledgments Many thanks go to Matthias Frei (SCION Association), Seyedali Tabaeiaghdaei (ETH Zurich) for reviewing and contributing to this document.