SCION Research Questions

3.1. ISD, AS identity

• How many ASes do we expect in the SCION network model?¶

• How many ISDs? What is the ontology of an ISD? Per geographic area only?¶

• One AS belongs to many ISDs?¶

3.2. Beacon Forwarding Policy

The idea behind "beaconing" is to discover all possible paths (loop free and with a fixed maximum length) between two CORE AS. Every CORE AS forwards any received beacons to all neighbor CORE ASes unless this would cause a loop or exceed the fixed maximum length. Implemented naively, the number of paths (and beacons) grows exponentially with the network size. This is currently mitigated, primarily (and efficiently), by forwarding only the five "best PCBs" (from a given remote source CORE AS) to neighbors. "Best" here takes into account properties such as diversity, time to expire and whether (or how recently) the same PCBs has been forwarded before.¶

Since path may expire after an hour or so and because expiration is not the only factor, an AS will typically start resending the same beacons in less than an hour (i.e. the typical expiration time).¶

This means the total number of different PCBs that an AS will receive from a given neighbor is e.g. 5 per minute * 30 minute = 150 paths.¶

Most likely, an AS will receive PCBs originated from a given source from several neighbors, however these are likely to be very similar. They are likely to have the same tail and only differ in the few last added hops, i.e. the immediate neighbors.¶

As a result, an AS will probably have only little more than 150 paths to a given remote AS.¶

This is likely sufficient for most applications, but is far from a complete view of the network.¶

This can be problematic:¶

• Massive multipathing: endpoints may not be able to use the theoretically best paths.¶

• Unusual path policies, such as geofencing, may not be fulfillable by the limited number of paths on offer.¶

3.3. Wormhole attack

3.4. DNS Service Binding (SVCB)

The DNS Service Binding [RFC9460], Section 14.3 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.¶

Example of current entry:¶

$ dig +short ethz.ch TXT  | grep scion
"x-sciondiscovery=8041"
"scion=64-2:0:9,129.132.230.98"

With SVCB this may look like this for https:¶

dig +short https ethz.ch
1 . alpn="h2" scion=64-2:0:9,129.132.230.98

SVCB is also planned to be supported by Happy Eyeballs v3 [I-D.draft-pauly-v6ops-happy-eyeballs-v3-01].¶

3.5. Segment Dissemination

Control servers may return a large number of path segments for some queries. This can cost considerable bandwidth / network egress while at the same time overloading clients with an unnecessarily large numbers of segments.¶

• This problem may be more acute in ASes with many end hosts (e.g. IoT), or end hosts with little computing power or little spare bandwidth.¶

• Getting a full path to a remote endhost may require three round-trips with the control server.¶

There are multiple possible and independent solution steps here:¶

• Compression: Segments could be stored in a way that duplicate information (hops & links) is only stored once and the segments contain only references to the hops and links.¶

• Instead of requiring three separate queries for (UP/CORE/DOWN), we could allow a single query from <start AS> to <end AS> across multiple segments. This should be very easy to implement and would be compatible with the current wire protocol (protobuf).¶

  • This would reduce the number of round trips to one.¶

  • It would reduce the number of returned segments because only segments that actually connect to other segments would need to be returned.¶

• Predefine some policies that can be resolved by the control server, e.g. ANY, BEST_LATENCY, BEST_BANDWIDTH, BEST_PRICE, BEST_CO2. For these, a control server could simply calculate 5-10 good 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.¶

Doing path selection on the control server will initially increase computational cost. However, it would substantially decrease network egress. Caching of paths should reduce CPU cost, maybe even below the current cost for retrieving a large amount of segments from the local database and sending them over the network interface.¶

Examples for requesting CORE segments between different ISDs or within an ISD (as of 2024-07-12):¶

3.6. Periodic beacon propagation

The SCION control plane protocol specifies that beacons should be propagated periodically. Is it 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.¶

3.7. 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 at each beaconing period may not satisfy all requirements that different applications, on different endpoints, 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 [RFC9217].¶

• 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 [TABAEIAGHDAEI2023]¶

3.8. Routing Policies and Traffic Engineering

Reduced adoption due to limited routing policy possibilities, such as a (core-)AS does not want to accept transit traffic unless it starts/ends in ASs with special properties. For example a GEANT AS does not want to allow transit traffic unless it originates or ends in another research AS.¶

One solution could be to add a “confirm full path”-flag to certain segments. If this flag is set, the full path (all segments) needs to authorized by all ASes that insist on authorizing it. This is obviously less scalable but may be viable for ASes that insist on such policies. This also allows for “secret” policies.¶

Collateral: this probably needs a data plane change. Conceptually, we have only a single resulting segment, and that segment needs to be used in full, e.g. no on-path trickery.¶

3.9. 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, be moved to the control-plane? This could include e.g. authorization to deliver traffic depending on the source, but also things 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: [I-D.garciapardo-drkey].¶

3.10. SCMP Authentication

In SCION, we would like to have SCMP (SCION Control Message Protocol) include authentication for some of the message types, e.g. the interface down type, as it would affect the path choices that the endpoint, and even the source AS, can make.¶

We propose 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). 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.¶

3.11. Proof of transit

FABRID [KRAHENBUHL2023] and EPIC [LEGNER2020].¶

3.12. NAT

At this moment, 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 underlay, this problem disappears. // TODO Clarify why it disappears? IS the idea that we can remove NATs if everyone would use IPv6?¶

• Introduce a mechanism so that the SCION border router can report the NATed address to an endpoint (similar to a STUN server).¶

4.1. Link load balancing

Links may get overloaded because the SCION routing system fails to distribute load properly over different links. New/different links might be underutilized.¶

If links become overloaded, there are several ways to handle that. Non comprehensively:¶

• Squeeze: send an SCMP message to trigger end-hosts to use an alternative path¶

• Steer: send and SCMP to trigger users to ask control server for a better path¶

• Reduce: hand over very short lived paths, let the end-hosts wait for the path to expire so that they request new paths and (hopefully) decide on a different path.¶

• Recommend: let the end-hosts know which paths are recommended by the AS at this time.¶

If a link has good properties, many AS will disseminate segments, therefore paths that go through this link and the link may become overloaded. See Simon Scherrer's work on Braess Paradox.¶

Either there needs to be some constant control by all clients to not choose the best theoretical path, but the one that works best. Or we need to find a way that control servers do not disseminate “good” links to all end-hosts.¶

The current consensus is that end-hosts can use multi-pathing and “automatically” converge on the best path, i.e. creating an equilibrium. Again, see Simon Scherrer's work on Braess Paradox.¶

4.2. Reverse Path Refreshment

When a client contacts a server, it is usually understood that it wants the server to use the reverse path to answer back. If the server uses that path for a long period of time, the path will eventually expire. How to standardize the process of refreshment?¶

There are some relevant points we have identified 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 IP/TCP-port 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? Leave it to transport layer protocol, as in the case of QUIC-MP [I-D.ietf-quic-multipath]?¶

• How long before 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).¶

4.3. Signalling faulty segments

Faulty segments are segments that do not work as advertised, i.e. they are either physically faulty (broken link, high packet loss, jitter, ...) or come with faulty metadata, suggesting too few hops, too low latency, too much bandwith, or similar problems. The fault may be caused by a technical problem (e.g. broken link) or by a malicious adversary.¶

An example for a malicious adversary is the "wormhole" attack, see [I-D.scion-cp], where, an AS may be coaxed to disseminate a faulty segment. How do we recover from faulty segments? Currently only endpoints may realize that a segment does not work as advertised, either via SCMP errors or simply by traffic degradation. This would be a possible sequence of events:¶

• An endpoint realizes that a segment is faulty¶

• An endpoint needs to signal to its local AS that a segment is faulty¶

• Local AS needs to signal its CORE AS that a segment is faulty¶

• The CORE AS needs to:¶

  • change policy to exclude faulty segments AND/OR¶

  • signal other COREs and ISDs to stop delivering the segment (they only deliver 5 each, so any faulty segment shoud be avoided)¶

10.1. Normative References

[I-D.ietf-quic-multipath]

Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-10, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-10>.

[I-D.scion-cp]

de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control Plane", 2023, <https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/>.

[I-D.scion-cppki]

de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control-Plane PKI", 2023, <https://datatracker.ietf.org/doc/draft-dekater-scion-pki/>.

[I-D.scion-dataplane]

de Kater, C., Rustignoli, N., and S. Hitz, "SCION Data Plane", 2023, <https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9217]

Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, <https://www.rfc-editor.org/rfc/rfc9217>.

10.2. Informative References

[I-D.draft-pauly-v6ops-happy-eyeballs-v3-01]

Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi, "Happy Eyeballs Version 3: Better Connectivity Using Concurrency", Work in Progress, Internet-Draft, draft-pauly-v6ops-happy-eyeballs-v3-01, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-pauly-v6ops-happy-eyeballs-v3-01>.

[I-D.garciapardo-drkey]

Pardo, J., Krähenbühl, C., Rothenberger, B., and A. Perrig, "Dynamically Recreatable Keys", 2022, <https://datatracker.ietf.org/doc/draft-garciapardo-panrg-drkey/>.

[KRAHENBUHL2023]

Krähenbühl, C., Wyss, M., Basin, D., Lenders, V., Perrig, A., and M. Strohmeier, "FABRID: Flexible Attestation-Based Routing for Inter-Domain Networks", 2020, <https://www.usenix.org/conference/usenixsecurity23/presentation/krahenbuhl>.

[LEGNER2020]

Legner, M., Klenze, T., Wyss, M., Sprenger, C., and A. Perrig, "EPIC: Every Packet Is Checked in the Data Plane of a Path-Aware Internet", 2020, <https://netsec.ethz.ch/publications/papers/Legner_Usenix2020_EPIC.pdf>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[TABAEIAGHDAEI2023]

Tabaeiaghdaei, S., Wyss, M., Giuliari, G., van Bommel, J., Zehmakan, A. N., and A. Perrig, "Inter-domain Routing with Extensible Criteria", 2023, <https://netsec.ethz.ch/publications/papers/IREC_arXiv.pdf>.