Guidelines for QUIC Multipath over SCION

Internet-Draft	SCION-QUIC-MP	June 2025
van Bommel, et al.	Expires 5 December 2025	[Page]

Abstract

This document provides informational guidance for using the Multipath Extension for QUIC [QUIC-MP] with the SCION networking technology ([SCION-CP], [SCION-DP]).¶

SCION is an inter-domain routing protocol that supports path-aware multi-path networking. The multiple path and their associated path information offered by SCION provide opportunities as well as challenges for combining QUIC-MP with SCION.¶

This document explores various aspects of this combination, such as algorithms for congestion control, RTT estimation, or general application scenarios. In addition it provides techniques and guidance to maintain security and to leverage path-aware multi-path networking with QUIC-MP.¶

1. Introduction

The Multipath Extension for QUIC [QUIC-MP], ia an extension for the QUIC protocol that enables the simultaneous usage of multiple paths for a single QUIC connection.¶

SCION ([SCION-CP], [SCION-DP]) is an inter-domain routing protocol that can provide many different paths between two endpoints, where every path has detailed information on traversed autonomous systems (ASes), links, router interfaces and MTU.¶

The purpose of this document is to explore how QUIC-MP and SCION can interoperate, how we can leverage the path awareness offered by SCION and how to overcome challenges.¶

One important aspect of this interoperability is that there is not a clear 1:1 mapping between QUIC-MP and SCION regarding what constitutes a path or how to identify an endpoint.¶

In SCION, paths have additional associated information. This can be used to improve algorithms, for example, for congestion control, by identifying overlapping paths or by more accurately identifying path changes.¶

With SCION, endpoints are identified with a network address that allows private (globally not unique) IP addresses and instead uses the AS number to uniquely identify endpoints. This can lead to challenges when QUIC-MP uses a 4-tuple combined with path ID as identity.¶

This document looks at different usage scenarios Section 3, lists notable points when using QUIC-MP over a PAN such as SCION, gives implementations considerations (Section 5) for library developers of SCION and QUIC-MP, and discusses general security considerations (Section 8).¶

While we provide guidelines for these areas, we do not discuss concrete algorithms, APIs, QUIC-MP or SCION implementations, or QUIC-MP user applications; these are considered out of scope.¶

Some considerations are independent of multipathing and may be directly applicable for using [QUIC-TRANSPORT] over SCION.¶

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.¶

2.1. Terminology

We assume that the reader is familiar with the terminology used in [QUIC-TRANSPORT] and [QUIC-MP]. We also draw on the terminology of [PATH-VOCABULARY] and of SCION ([SCION-CP] and [SCION-DP]). For ease of reference, we have included some definitions here, but refer the reader to the references above for complete specifications of the relevant terminology.¶

Autonomous System (AS): An autonomous system is a network under common administrative control. For example, the network of an Internet service provider or organization can constitute an AS.¶

Endpoint: An endpoint is the start or end of a path, as defined in [PATH-VOCABULARY].¶

Inter-AS Link: A direct link between two external interfaces of two ASes.¶

Intra-AS Link: A direct link between two internal interfaces of a single AS. A direct link may contain several internal hops.¶

Link: General term that refers to "inter-AS links" and "intra-AS links".¶

Network Address: In IP networks, the network address is the IP and port of an endpoint. In SCION, the network address holds additional information, such as the AS number of the endpoint.¶

Network Path: The network path is a SCION path that consists of the network address at each endpoint, a list of all traversed ASes, and links inside and between ASes, including interface IDs on border routers of each AS.¶

QUIC-MP Path: Consists of the network address at each endpoint and a Path ID (see [QUIC-MP]). The Path ID allows having multiple logical paths for the same set of network addresses.¶

Path Metadata: Path metadata is additional data that is available to endpoints when they request a selection of paths to a destination. Path metadata is authenticated by the owner of each link, but is otherwise not verified. Path metadata includes data about ASes and links, such as MTU.¶

Metadata Extension: SCION offers additional path metadata via extensions. The metadata includes properties such as bandwidth and latency. The extension widely saupported but not further discusses here as it is not specified in [SCION-CP] or [SCION-DP].¶

4. Notable Differences when using QUIC-MP over SCION

Using QUIC or QUIC-MP over a PAN, such as SCION, changes some of the underlying assumptions. This provides certain benefits, such as additional information and control over paths, but also some pitfalls.¶

4.1. Endpoint Identity

In QUIC-MP, in some situations, endpoints are identified only by their IP and port number. This works because IP addresses are unique (globally, or in whatever context they are used).¶

SCION allows IPs from the private IP ranges (e.g. 192.168.1.1/32). To uniquely identify endpoints globally, the AS (autonomous system) identifier is added to fully qualify a network address.¶

This has consequences for security mechanisms. Implementations must be careful to consider the full network address, for example, when triggering path validation. However, this does not necessarily require a change in the QUIC-MP implementation. See also Section 8.2, Section 7.4 and Section 7.¶

4.2. Path Identity

The identification of "paths" varies between QUIC, QUIC-MP and SCION.¶

[QUIC-TRANSPORT] uses a 4-tuple of local/remote IP/port to distinguish paths.¶
[QUIC-MP] extends the 4-tuple with a path IDs to distinguish logical paths (connections).¶
SCION can distinguish paths based on the physical network path and additional properties, such as an expiration date (the latter may or may not be used to distinguish path instances).¶

When using a PAN such as SCION, the path identity can and should be used to detect path changes even when the 4-tuple of local/remote IP/port (or equivalent) stays the same.¶

Path change detection can be useful for avoiding unintended path changes or to trigger actions, such as resetting congestion control or RTT estimation algorithms. See also Section 5.3, Section 5.4, and Section 7.¶

4.2.1. Interoperability of the QUIC-MP Path ID and the Network Paths

Implementations should try to maintain a 1:1 mapping between QUIC-MP path IDs and SCION network paths. However, this is not always possible or useful.¶

It seems reasonable that a SCION implementation may refresh an expiring path with a new identical path. It seems equally reasonable that this is handled by the path selector, see Section 5.7.¶
This document recommends that a SCION implementation, when used with QUIC-MP should be configured, such that every SCION network path is used for exactly one QUIC-MP path ID. However, it may not always be possible or feasible to configure SCION implementations this way, for example when they are part of a SCION gateway or proxy, see Section 3.1.¶
With NAT rebinding, as described in Section 5.2 of [QUIC-MP], the path can effectively change, the implication need to be discussed in a future version of this document TODO.¶
SCION path should be allowed to be reused, e.g., they may be assigned to one path ID, then that path ID is closed, then they may be assigned to another path ID. This should cause no problem except for the marginal complexity of managing the associate state with a path ID.¶

Recommendations, see also Section 7:¶

Changes of the network address, except possibly for expired paths being renewed, should trigger path validation.¶
Within a QUIC-MP session, every SCION network path should be used only with one path ID. However, it may be reused if the path was abandoned or closed.¶
Changes of the network path (while the network address stays the same), except for expired paths being renewed, should trigger algorithm reset (CC, RTT estimate), see Section 5.1 of [QUIC-MP].¶

4.3. Disjointness

For Fault Tolerance scenarios, paths are more interesting if they are disjoint. For High Bandwidth scenarios, paths should be mostly disjunct, but overlap is acceptable if the overlapping links have high bandwidth available (see bottleneck}}).¶

This is especially relevant for congestion control algorithms, see Section 5.3, but can also be useful for retransmission (Section 5.5).¶

4.4. Explicit Path Selection

Based on path metadata and algorithmic analysis (Section 4.3), an endpoint can explicitly select paths or avoid paths. This allows avoiding or abandoning paths for more paths with more suitable properties. Notably, for SCION, path selection is often not done by an algorithm but may be performed by a user or through a configuration file.¶

4.5. MTU

The MTU may be used to calculate the available payload size. SCION inserts an additional header (Section 2 of [SCION-DP]) into every packet. The header size depends on the IP family (e.g., IP4 vs IPv6 addresses) and on the "length" of the path, i.e., the number of ASes that are traversed. This must be taken into account when calculating the available payload size.¶

MTU detection is discussed in Section 5.2.¶

5. QUIC Implementation Considerations

This section provides guidance for implementors of SCION libraries and QUIC-MP libraries. Recommendations are summarized in Section 7.¶

5.1. Automatic Path Changes - Initial Handshake

[QUIC-TRANSPORT] requires that there is no connection migration during the initial handshake, and that there are no other packets sent (including probing packets) during the initial handshake, see Section 9 of [QUIC-TRANSPORT], paragraphs 2 and 3.¶

An implementation must ensure at some level that no path change or probing occurs.¶

This is covered by the recommendation that a SCION implementation should not automatically switch without explicit request by the QUIC(-MP) layer, see Section 7.¶

THere may be implicit path switching to an identical new path due to refreshing expired paths, however, this can be safely ignored.¶

5.2. MTU Detection

In SCION, when an endpoint requests a network path, it will be provided with MTU information for every hop on a path, see also Section 4.5 and Section 4.4 of [SCION-CP].¶

However, in SCION, paths are typically only requested by client endpoints, not by server endpoints.¶

There are several ways for a server to determine the MTU. If a server wants to know the MTU, it may:¶

Try to determine the MTU from incoming packets.¶
Use an algorithm to determine the MTU, see Path MTU Discovery in Section 14.3 of [QUIC-TRANSPORT] and Section 5.8 of [QUIC-MP].¶
Try to look up the path to the client endpoint that is identical to the incoming path. This is not recommended because it requires time and effort on the server side, and there is no guarantee that the incoming path is available in the local AS.¶

Also, note that the MTU information is authenticated but not verified, it may be incorrect due to misconfiguration or malicious ASes.¶

5.3. Congestion Control

Following Section 5.1 of [QUIC-MP], CC algorithm should be reset when the 4-tuple of a QUIC-path changes. With SCION, 4-tuples are not sufficient to identify paths, see Section 4.2. To avoid missing a path change, SCION implementation should never change a network path unless instructed otherwise by the QUIC-MP implementation, see Section 7. If this is not followed, a network path change may go unnoticed in case a SCION implementation changes a path that happens to have the same IP/port for both endpoints.¶

Congestion control (CC) algorithms can also benefit from exact knowledge of a path:¶

When using multiple paths, a CC algorithm can access information as to if and where the paths overlap and some of the properties of the overlapping sections.¶
CC algorithms should be notified of every path change, allowing them to reset only when necessary. A reset may not be unnecessary if the network path remains the same and only the IP or port of an endpoint changes. This can make sense if any congestion is assumed to be on the network path rather than behind the remote IP/port.¶

5.3.1. Coupled Congestion Control

Section 5.3 of [QUIC-MP] mentions coupled congestion control algorithms, such as [CC-MULTIPATH-TCP]. [CC-MULTIPATH-TCP] states that:¶

"One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows.".¶

This can be avoided in PANs, such as SCION, through link-level analysis of paths and selecting paths that do not share a bottleneck link. Instead, this bottleneck knowledge can be used to effectively use separate congestion control for each path. Alternatively, a CC algorithm could be employed that focuses on known shared shared links (which may be bottlenecks).¶

There are several congestion control algorithms proposed in literature, e.g. LIA, OLIA, BALIA and RSF. These combine congestion control with path selection algorithms. For simplicity, we suggest separating concerns in terms of congestion control and path selection. This allows us to better tailor the solutions to the different usage scenarios.¶

The proposition is to use non-coupled congestion control per path, tailored for each use case Section 3 and on top of that separately use path selection algorithms.¶

CC algorithms can also benefit from the SCION metadata extension that provide bandwidth and latency data for each node and link on a network path.¶

5.4. RTT Estimation

Similarily to congestion control, and following Section 5.1 of [QUIC-MP], RTT estimation algorithm should be reset when the 4-tuple of a QUIC-path changes. As described in Section 5.3 this can be avoided if SCION implementation should never change a network path unless instructed otherwise by the QUIC-MP implementation, see Section 7.¶

Round-trip time estimation (RTT) algorithms can also benefit from exact knowledge of a path:¶

An implementation may use SCIONs SCMP traceroute (Section 6 of [SCION-CP]) to measure latency of individual links and then use this information to select new network paths that favour low latency links and avoid low latency links. See also Section 5.7.3.¶
An implementation could use the SCION metadata extension to get latency on links in a path without having to measure it. This latency may not by fully accurate, but may in many cases be "good enough".¶

5.5. Retransmission & PTO

See Section 5.6 of [QUIC-MP] and Section 5.7 of [QUIC-MP]. For retransmission, a SCION client or server may compare available paths and choose one or more paths that have minimum overlap with the current (unreliable) path.¶

5.6. Paths Having Different PMTU Sizes

Section 5.8 of [QUIC-MP] suggests determining a single MTU size in order to simplify retransmission. At least on the client, this can be facilitated by computing a viable minimum MTU size from all available network paths. However, these MTU values are not available on the server, and it may be incorrect, see Section 4.5 and Section 5.2.¶

5.7. Path Selection

The path selection component is responsible for requesting paths to a destination, ordering the path based on policy and preferences, using them when new QUIC-paths are opened, and retiring them or listing them for reuse when they are closed.¶

5.7.1. General Path Management

In order to manage paths effectively, the path selection algorithm probably requires acces to the following fields and events:¶

initial_max_path_id (Section 2.1 of [QUIC-MP])¶
MAX_PATH_ID frames (Section 4.6 of [QUIC-MP]¶
PATH_AVAILABLE and PATH_BACKUP, see Section 3.3 of [QUIC-MP],¶
PATH_ABANDON Section 3.4 of [QUIC-MP].¶

Moreover, path selection must exclude paths whose MTU is too small to guarantee 1200 bytes MTU payload for QUIC packets. The effective MTU also depends on the length of the paths.¶

5.7.2. Dynamic Approach

A dynamic approach could start with using low latency paths. If the connection appears to be long lasting it could start, and keep, adding additional paths and as long as the traffic increases. Additional paths can be chosen following the guidelines discussed in Section 6.1.¶

As an example, if the algorithm detects traffic that lasts for at least one second and transfers at least 100MB of traffic, the algorithm could trigger creation of additional QUIC-paths.¶

5.7.3. Bottleneck Detection

If no live traffic information is available, bottleneck detection can help to identify linkks that should be avoided. In path-aware networks, this can be done using approaches such as [UMCC].¶

One alternative is to use SCION's SCMP traceroute command (Section 6 of [SCION-CP]) to measure the latency between two consecutive AS border routers. The measured latency can be compared to earlier measurements or to the latency given in the path metadata. Discrepancies can be an indication of high traffic and queueing problems on the measured link.¶

While traceroute may be useful, it should be used with care:¶

traceroute traffic is not congestion controlled.¶
it is clearly distinguishable from QUIC traffic, so it may affect anonymity.¶

5.8. Packet Scheduling

Packet scheduling helps distributing the transfer load efficiently over multiple paths, see also Section 5.5 of [QUIC-MP].¶

One advantage over a PAN such as SCION is that network paths are stable and cannot change unexpectedly. This may simplify packet scheduling algorithms because the performance of individual QUIC-paths is more reliable if they cannot unexpectedly be rerouted.¶

6. Applications

See also Section 3. TODO merge with Categories?¶

6.1. Data Transfer

The aim of a data transfer application is to maximize throughput, regardless of latency, jitter or packet loss.¶

The solution here is to identify multiple paths that are either disjoint, or where the non-disjoint links allow higher throughput than other links on the same paths (i.e. high enough to prevent the link from being a bottleneck).¶

6.2. Low Latency

Latency may be determined via RTT estimation, see Section 5.4.¶

For dead-line sensitive appilications, an algorithm as described in [DMTP] may be useful.¶

6.2.1. Probing

Generally, instead of probing many paths at once, an implementation should probe only the most promising paths (following the metadata). This should allow excluding many other paths if their metadata latency (which should represent best-case latency) is larger than any latency measured on the previously selected paths.¶

Probing many paths should also be avoided to avoid overloading individual links, and it may effectively be limited (except traceroute) by the abvailable path IDs and connection IDs, see Section 7.2 of [QUIC-MP].¶

6.3. High Availability / Redundancy

An approach to high availability is to send data on multiple paths in parallel. A tradeoff here is that sending on all available paths may be infeasible because of the number of available paths (with SCION we often see 100+ paths to a destination). Depending on cost factors, and to avoid overloading the network, any algorithms should keep redundant sending to a minimum. See also Section 7.2 of [QUIC-MP] for DoC security considerations.¶

Path analysis can be used to identify a set of paths that are mostly or completely (using multiple interfaces) disjoint, but that still satisfy latency, bandwidth, and other constraints.¶

In addition, RTT estimation Section 5.4 may be used to regularly measure packet drop rates or latency variations.¶

6.4. Multipathing for Anonymity

Multipathing could also be used for anonymity, e.g., by switching paths at random intervals. With a continuous data stream, care should be taken, otherwise traffic characteristics may be used to identify paths. For example, paths could be identified by packet frequency, packet burst frequency, or general bandwidth. For continuous streams, simply moving one stream from one path to another may expose stream identity.¶

As mitigation, network paths could be selected based on disjointness (Section 4.3) which should decrease the probability of eavesdropping by an attacker that is located in a single AS.¶

Another mitigation is that SCION allows selecting paths such that specific untrusted ASes are never traversed.¶

7. Summary of Recommendations

This memo is informational. However, we use [RFC2119] imperative language here for recommendations that are relevant to security or performance.¶

7.1. Recommendations for QUIC-MP Implementations

To prevent attackers circumventing path validation, a QUIC-MP implementation MUST ensure to trigger path validation when the network address of the destination changes; this includes IP, port and AS number. This protects against several attacks, see Section 8.2 and especially Section 8.2.4.¶

There are several ways to achieve this, for example:¶
- Adapt the QUIC-MP library to be aware of the AS number in SCION network addresses.¶
- If the network address is available as a single "object", the SCION layer can extend this with the AS code and the QUIC-MP implementation must only ensure to compare the whole object instead of port and IP separately.¶
- The SCION implementation could detect cases where only the AS changes and then mangle the port or IP to trigger a path validation in the QUIC-MP layer. This may be pragmatic solution but is discouraged, because:¶
  - Managing paths in the SCION layer is difficult (when is a path valid? When is it closed? ...).¶
  - It creates opportunities for memory exhaustion attacks (for storing the mapping of mangled IP/port).¶
  - It reports a wrong IP/port to the application.¶
A QUIC-MP implementations SHOULD be able to recognize network path changes beyond 4-tuple or AS changes. This enables resetting congestion control and RTT algorithms.¶

7.2. Recommendations for SCION Implementations

A SCION implementation SHOULD NOT store or cache paths, especially (MUST?) not on the server side. This prevents memory exhaustion attacks, see {attack-memory-exhaustion}. This also avoid the problem of determining which paths are still alive a which have been closed or abandoned.¶
When used with QUIC-MP, a SCION implementation MUST not change the network paths, possibly with the exception of refreshing expired paths. When a path stops working, the implementation should instead report an error to the QUIC(-MP) layer or time out silently.¶

7.3. Recommendations for both QUIC-MP and SCION Implementations

A server should return packets on the same path on which they were received.¶
- Generally a server SHOULD respond on the same path on which the data was originally requested, unless the new path has been validated. This ensures that the path does not violate the path policy of the client.¶
- A server SHOULD NOT create new path. Any new path may violate a client's path policy.¶
- Returning probing packets on the same network path on which they were received: this greatly simplifies RTT estimation, see Section 5.4.¶
Clients may replace expired paths with identical paths without performing path migration / validation.¶
Within a QUIC-MP session, every SCION network path should be used only with one path ID. However, it may be reused if the path was abandoned or closed. This is the respponsibility of the path selection algorithm, independent of whether it is considered part of SCION or part of QUIC-MP.¶

7.4. Address Validation Token

TODO This section needs a lot more work! See discussion in https://github.com/quicwg/multipath/issues/550¶

From Section 3.1.3 of [QUIC-MP]: > As specified in Section 9.3 of [QUIC-TRANSPORT], a server is > expected to send a new address validation token to a client > following the successful validation of a new client address. > The client will receive several tokens. When considering using a > token for subsequent connections, it may be difficult for the > client to pick the "right" token among multiple tokens obtained in > a previous connection. > The client is likely to fall back to the strategy specified in > Section 8.1.3 of [QUIC-TRANSPORT], i.e., pick the last received > token. To avoid issues when clients make the "wrong" choice, a > server SHOULD issue tokens that are capable of validating any of > the previously validated addresses. Further guidance on token usage > can be found in Section 8.1.3 of [QUIC-TRANSPORT].¶

Clients may not know their IP address (e.g. NAT) and their IP address may change.¶

As discussed (TODO elsewhere: trigger path validation, reset CC and RTT estimation algorithms), QUIC-MP implementations should consider not only the 4-tuple, but also the AS codes and actual paths when comparing network addresses.¶

One problem here is as follows: If we adopt an implementation to use the full network address + path for identity, and if we use this to generate tokens, then we may end up generating many more or longer tokens.¶

This needs to be considered carefully.¶

See also Section 21.3 of [QUIC-TRANSPORT].¶

TODO Move this section to after discussing network addresses¶

TODO read the referenced sections and come up with recommendations.¶

8. Security Considerations

The aim is that [QUIC-MP] over SCION retains all security properties of [QUIC-MP]. However, this requires some implementation changes and additional consideration regarding:¶

endhost identity: a 4-tuple is not sufficient to identify an endhost;¶
netwotk path authenticity: paths may be spoofed;¶
probing patterns which may expose user intentions or identity.¶

8.1. Probe Fingerprinting

An endpoint may probe multiple paths in order to determine the best path(s) for a given usecase. One example of probing packets are packets that measure round trip time (RTT).¶

If sent en-block, probing packets can be detected because they may be sent in bulk, to the same destination, in regular intervals, and all with slightly different paths attached.¶

This can be used to fingerprinting an endpoints or their intentions (applications may have unique intervals definded).¶

This can be mitigated by varying and generally reducing the number of probing packets, and by sending probing packets not en block but time-shifted.¶

8.2. Path Injection

There are several potential attacks that build on injecting paths (valid or invalid) into the server-side software stack.¶

These attacks can be prevented in several ways, we recommend the following where possible:¶

SCION layers should avoid storing/caching paths and network addresses (beyond IP/port) internally. Instead, they should be given to the QUIC(-MP) layer or the application layer. That means that path information would only be accepyted and retained if the QUIC(-MP) or application layer.¶
SCION layers and QUIC(-MP) layers should interface by using network addersses that include all information that identifies an andpoint, including, for example, AS code. Any change to a network address (including the AS code) should trigger path validation.¶

Alternatives:¶

If paths and network addresses must be stored in the SCION layer, an alternative solution would be to implement some kind of signalling which would indicate that a packet is (or would be) rejected/dropped by the QUIC(-MP) layer. These addresses and path from such packets should not be added to storage. However, to avoid connection drop, they should not be removed if they were previously used with a valid connection.¶

Examples of attacks include memory exhaustion attacks, traffic redirection attacks, and traffic amplification attacks.¶

8.2.1. Memory Exhaustion

An attacker may flood a server with packets that each have a different source network address. If these are stored in the SCION layer, they may cause memory exhaustion.¶

Mitigation: do not store state in the SCION layer, or implement a way to clean up state without affecting valid connection.¶

8.2.2. Traffic Redirection to Different AS

An attacker may craft a packet that appears to originate from the same IP/port, but is located in a different AS than an existing connection. If the server's SCION layer stores paths internally, and uses IP/port as key to look them up, then the new paths may replace the exisitng one and outgoing traffic is redirected to the new paths and destination.¶

Mitigation:¶

The QUIC(-MP) layer MUST trigger path validation if the network address changes, and must consider every attribute of the address, not just IP and port.¶
If a packet is rejected by the QUIC(-MP) layer, the SCION layer MUST NOT add it to any local state (including not replacing exisint state). This can be achieved trivially by not having state in the SCION layer.¶

8.2.3. Traffic Redirection over Different Path

An attacker may craft a path with a network address that is identical to an existing valid client, but with a different path.¶

The new route is invalid (contains loops or non-existent links) or may be broken (contains links that are broken or have high latency or drop rate).¶

The new route may also work fine, but violate the client's path policy or be used for traffic observation.¶

     AS #100               AS #200                   AS #300
   +------------+        +----------------+        +----------------+
   | Server     |        | Attacker       |        | Victim         |
   | IP=1.2.3.4 | ------ | IP=192.168.0.1 | ------ | IP=192.168.0.1 |
   | port = 42  |        | port= 12345    |        | port= 12345    |
   +------------+        +----------------+        +----------------+

    **TODO** use IPs from documentation range

Figure 1: Example of non-unique IPs

This attack requires either spoofing of the client's IP address (when the attacker is in the same AS as the client) or injection of a path (which requires control over an AS that is en-route between the client and server).¶

Mitigation: TODO¶

8.2.4. Traffic Amplification

An attacker may establish a normal connection with a server, request a large amount of data, and then inject a path that redirects to a victim that has the same IP/port, but in a different AS.¶

If the server-side QUIC-MP does not trigger path validation (because IP/port are the same), then it may implicitly accept the new path and send the requested data to a victim.¶

This attack requires the attacker to have control over an AS that is en-route between client (victim) and server.¶

Mitigation:¶

A QUIC(-MP) library must consider all attributes (not just the 4-tuple) when checking for a change in the network address. This would then trigger path validation and the attack can be averted.¶
If a QUIC(-MP) library cannot compare additional attributes (e.g. legacy library), the SCION layer (server side) should have an option to perform port mangling or IP mangling: when the SCION layer detects a new network address that differs only in the AS number from a previously seen address (IP/port are the same), then it should perform IP/port mangling, i.e. reporting a modified IP or port to the QUIC(-MP) layer. This new IP/port would trigger a path validation or algorithm reset where required.¶

Caveats¶

Offering a mangeled IP/port to the application may have implications for application correctness, such as displaying an unexpected IP/port.¶

   Attacker                                                Server
   (Establish connection)
   Path=[#200, #100] -->
                                                <-- Path=[#100, #200]

   (Change Path)
   Path=[#300, #200, #100] -->
                                          <-- Path=[#100, #200, #300]

   Client: receives unwanted traffic

Figure 2: Example of traffic amplification attack

8.3. More ?

Use multipathing for anonymity, see EVA in Section 3.¶
See other attacks in Section 7.2.4 of [SCION-CP]?¶

TODO¶

10. References

10.1. Normative References

[CC-ALGORITHMS]: Duke, M., Ed. and G. Fairhurst, Ed., "Specifying New Congestion Control Algorithms", BCP 133, RFC 9743, DOI 10.17487/RFC9743, March 2025, <https://www.rfc-editor.org/rfc/rfc9743>.
[CC-PRINCIPLES]: Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/rfc/rfc2914>.
[DCCP-UDPENCAP]: Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, <https://www.rfc-editor.org/rfc/rfc6773>.
[MPTCP-ARCHITECTURE]: Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/rfc/rfc6182>.
[MTU-DISCOVERY]: Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.
[QUIC-RECOVERY]: Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[QUIC-TLS]: Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.
[QUIC-TRANSPORT]: 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>.
[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>.
[UDP-GUIDELINES]: Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.

10.2. Informative References

[CC-MULTIPATH-TCP]: Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <https://www.rfc-editor.org/rfc/rfc6356>.
[DMTP]: John, T. and T. Riechard, "Deadline Aware Streams in QUIC Multipath", Work in Progress, Internet-Draft, draft-tjohn-quic-multipath-dmtp-01, 5 June 2025, <https://datatracker.ietf.org/doc/html/draft-tjohn-quic-multipath-dmtp-01>.
[OLIA]: Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. Le Boudec, "MPTCP is not pareto-optimal: performance issues and a possible solution", Proceedings of the 8th international conference on Emerging networking experiments and technologies, ACM , 2012.
[PATH-VOCABULARY]: Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path Properties", RFC 9473, DOI 10.17487/RFC9473, September 2023, <https://www.rfc-editor.org/rfc/rfc9473>.
[QUIC-ACKFREQUENCY]: Iyengar, J., Swett, I., and M. Kühlewind, "QUIC Acknowledgment Frequency", Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-11, 28 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-11>.
[QUIC-MP]: 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-14, 23 April 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-14>.
[SCION-CP]: de Kater, C., Rustignoli, N., and S. Hitz, "SCION Control Plane", Work in Progress, Internet-Draft, draft-dekater-scion-controlplane-08, 3 March 2025, <https://datatracker.ietf.org/doc/html/draft-dekater-scion-controlplane-08>.
[SCION-DP]: de Kater, C., Rustignoli, N., Hugly, J., and S. Hitz, "SCION Data Plane", Work in Progress, Internet-Draft, draft-dekater-scion-dataplane-05, 3 March 2025, <https://datatracker.ietf.org/doc/html/draft-dekater-scion-dataplane-05>.
[UMCC]: Gartner, M. and D. Hausheer, "UMCC: Uncoupling Multipath Congestion Control through Shared Bottleneck Detection in Path-Aware Networks", Proceedings of the IEEE 49th Conference on Local Computer Networks (LCN) , 2024.