PANRG K. Meynell
Internet-Draft SCION Association
Intended status: Informational J. García Pardo
Expires: 9 January 2025 T. Zäschke
ETH Zürich
N. Rustignoli
SCION Association
8 July 2024
SCION Research Questions
draft-meynell-panrg-scion-research-questions-latest
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 9 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction
2. Conventions and Definitions
3. Discovery, Distribution, and Trustworthiness of Path Properties
3.1. ISD, AS identity
3.2. Segment Dissemination
3.3. Routing Policies and Traffic Engineering
3.4. DRKey
3.5. SCMP Authentication
3.6. Proof of transit
3.7. NAT
4. Dataplane stability
4.1. Link load balancing
4.2. Reverse Path Refreshment
5. Hummingbird / QoS
6. Interfaces for Path Awareness
7. Implications of Path Awareness for the Transport and
Application Layers
8. Naming
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
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.5. SCMP Authentication
3.6. Proof of transit
FABRID [KRAHENBUHL2023] and EPIC [LEGNER2020].
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.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 CS 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. 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
* How many QoS flows to support at core routers?
* How does QoS interact with Net Neutrality?
* What proof of transit (or forwarding failure detection) is needed
or wanted?
* What time synchronization precision should we expect at the border
router level of every AS? How far can we go realistically?
6. Interfaces for Path Awareness
* IPv6 in the Data Plane
* SCION-IP translation
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.scion-cp]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control
Plane", 2023, .
[I-D.scion-cppki]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control-
Plane PKI", 2023, .
[I-D.scion-dataplane]
de Kater, C., Rustignoli, N., and S. Hitz, "SCION Data
Plane", 2023, .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
.
11.2. Informative References
[I-D.garciapardo-drkey]
Pardo, J., Krähenbühl, C., Rothenberger, B., and A.
Perrig, "Dynamically Recreatable Keys", 2022,
.
[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,
.
[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,
.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Kevin Meynell
SCION Association
Email: kme@scion.org
Juan A. García Pardo Giménez de los Galanes
ETH Zürich
Email: juan.garcia@inf.ethz.ch
Tilmann Zäschke
ETH Zürich
Email: tilmann.zaeschke@inf.ethz.ch
Nicola Rustignoli
SCION Association
Email: nic@scion.org