Switch from "rewriting" to "injecting"

[kazuho]

Current design suggests middleboxes rewrite QUIC packets.

This approach has the following problem:

• If middleboxes rewrite ordinary QUIC packets (e.g., V1) as the current draft suggests, it would have negative performance impact to existing stacks, as the rewrite would lead up to packet loss events.
• We could define a trigger version, but that requires coordination on both endpoints. While that is possible, the concern is that the design might become dependent to the internals of specific version of QUIC (see #3). What we prefer is a design neutral to QUIC versions (or a design that works with UDP-based protocols other than QUIC).

So what about the following:

• Instead of rewriting packets, let middleboxes inject long header QUIC packets. The QUIC version number field identifies that the packet carries bandwidth information. The bandwidth information itself can be encoded as part of the version number, or it can be the payload of the long header packet.
• The receiver verifies if the injected packet is from a on-path device, by verifying the CID pair of the QUIC packet. This works because QUIC deployments use non-zero length CID in at least one direction.

To paraphrase, middleboxes that observe a long header QUIC packet can simply copy the Destination CID and Source CID fields of the QUIC packet, and inject a new QUIC packet using the same CID pair, with a special version number(s) indicating that the information is from the middlebox.

As said, the benefit of this approach is that it would work with any version of QUIC, and that there would be no negative impact to the throughput of existing QUIC stacks. Also, the protocol can be used by other UDP-based protocols, provided that they define a way for endpoints to agree on the value of CID fields used for validation.

WDYT?

[martinthomson]

Christian and I are talking about doing a completely new QUIC version, which addresses the packet drop risk.

My understanding is that replacement is far easier than insertion for a middlebox, to the extent that anything else is likely a non-starter.

[kazuho]

My assumption has been that the middleboxes that send TRAIN packets are going to be the sophisticated ones and that they can inject packets like they do with ICMP packets. But I could very well be incorrect.

That said, I think rewriting is fine.

Separately, I would point out that the receiver cannot distinguish between a rewritten packet and an injected packet if Initial packets are allowed to carry the bandwidth information, as they are not encrypted using keys known only to the endpoints.

[martinthomson]

Rewriting helps if you consider it likely that there could be an attacker that can observe and inject packets on the path. The conditions for success there aren't great, but it is an attack modality that is easier to block than document :)

The point about the Initial packet is well-taken. Particularly if an off-path attacker is willing to accept a high risk of failure. Though I would observe that there are limits to what an attacker might achieve in most of these adaptive bit rate scenarios.

[martinthomson]

@kazuho with the new design, are you comfortable closing this issue? I think that we're in pretty good shape overall. We'll need to expand on the attack modalities stuff though.

[kazuho]

Yes, let's close.