Internet-Draft scion-research_I-D July 2024
Meynell, et al. Expires 13 January 2025 [Page]
Workgroup:
PANRG
Internet-Draft:
draft-meynell-panrg-scion-research-questions-latest
Published:
Intended Status:
Informational
Expires:
Authors:
K. Meynell
SCION Association
J. García Pardo
ETH Zürich
T. Zäschke
ETH Zürich
N. Rustignoli
SCION Association

SCION Research Questions

Abstract

TODO Abstract here

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://scionassociation.github.io/scion-research_I-D/draft-meynell-panrg-scion-research-questions.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-meynell-panrg-scion-research-questions/.

Discussion of this document takes place on the WG Working Group mailing list (mailto:panrg@irtf.org), which is archived at https://datatracker.ietf.org/rg/panrg. Subscribe at https://www.ietf.org/mailman/listinfo/panrg/.

Source for this draft and an issue tracker can be found at https://github.com/scionassociation/scion-research_I-D.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 13 January 2025.

Table of Contents

1. Introduction

SCION is an inter-domain network architecture. Its core components specification, as deployed by some of its early adopters, is outlined in [I-D.scion-dataplane], [I-D.scion-cppki], [I-D.scion-cp], currently under ISE review.

The goal of this draft is to explore how SCION and its early deployments try to address open research questions in [RFC9217]. 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 the very first version of the SCION research questions draft, and it merely contains a skeleton of potential topics to be further discussed in this draft. Any feedback is welcome and much appreciated. Thanks!

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Discovery, Distribution, and Trustworthiness of Path Properties

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. Segment Dissemination

Control servers return a large number of path segments. This can cost considerable bandwidth / network egress while at the same time overloading clients with an unnecessarily large numbers of segments, mostly consisting of redundant information in terms of duplicate link and hops.

  • This problem may be more problematic 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 (idea suggested by Francois Wirz): 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.

  • Allow queries 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 ASs. If a user requires a custom policy they can still resort to requesting actual segments.

Doing path computation 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.

3.3. 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.4. DRKey

  • Is forward-secrecy DRKey useful and should we develop it?

  • What are the properties of the control-plane?

    • Do we want to have any authorization of the data-plane transit undertaken at this stage?

    • Would this obsolete firewalls?

    • What do we mean when we say "authorize transit"?

For more info: [I-D.garciapardo-drkey].

3.7. NAT

At this moment, the SCION implementation is not compatible out-of-the-box with NAT'ed devices, 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.

  • With IPv6 underlay, this problem disappears.

  • Modify the SCION border router to also act as a STUN server.

4. Dataplane stability

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. It the server uses that path for a long period of time, the path will eventually expire. How to standardize the process of refreshment?

  • The server must ask the CS 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. We might need to take this into account.

5. Hummingbird / QoS

6. Interfaces for Path Awareness

7. Implications of Path Awareness for the Transport and Application Layers

To be discussed

8. Naming

To be discussed

9. Security Considerations

TODO Security

10. IANA Considerations

This document has no IANA actions.

11. References

11.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, , <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", , <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", , <https://datatracker.ietf.org/doc/draft-dekater-scion-pki/>.
[I-D.scion-dataplane]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Data Plane", , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9217]
Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, , <https://www.rfc-editor.org/rfc/rfc9217>.

11.2. Informative References

[I-D.garciapardo-drkey]
Pardo, J., Krähenbühl, C., Rothenberger, B., and A. Perrig, "Dynamically Recreatable Keys", , <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", , <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", , <https://netsec.ethz.ch/publications/papers/Legner_Usenix2020_EPIC.pdf>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Kevin Meynell
SCION Association
Juan A. García Pardo Giménez de los Galanes
ETH Zürich
Tilmann Zäschke
ETH Zürich
Nicola Rustignoli
SCION Association