Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can Retry or VNego be compound with other packets? #1292

Closed
huitema opened this issue Apr 13, 2018 · 3 comments
Closed

Can Retry or VNego be compound with other packets? #1292

huitema opened this issue Apr 13, 2018 · 3 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@huitema
Copy link
Contributor

huitema commented Apr 13, 2018

The spec now says that "A sender can coalesce multiple QUIC packets (typically a Cryptographic Handshake packet and a Protected packet) into one UDP datagram." Should that be qualified?

For example, does it make sense to compound a Version Negotiation packet with any other packet? Of course, there is no length field in VNego, but one might imagine combining a handshake packet and a VNego packet, maybe as away to send an ACK for the client init. My feeling is "don't do that". Should it be said?

The same goes for the stateless retry packet. Does it make sense to combine it with a handshake packet?

@MikeBishop MikeBishop added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Apr 15, 2018
@MikeBishop
Copy link
Contributor

Perhaps worth noting. However, if you send a packet with the version the client proposed, you've accepted the version, so the Version Negotiation packet would then be ignored (existing text). Retry might get a little hairier.

@kazuho
Copy link
Member

kazuho commented Apr 16, 2018

While I agree that coalescing some types of packets does not make sense on the sender side, I think that the receiver needs to handle each QUIC packet coalesced into a UDP datagram individually, regardless of their types.

Otherwise, coalescing could become an attack vector.

When coalescing is not used, an on-path attacker needs to do AES calculation to inject a packet that will be processed (instead of being dropped) by an endpoint. Coalescing should not change that.

@martinthomson
Copy link
Member

With recent changes, which remove the length field from these packets, the answer is no.

martinthomson added a commit that referenced this issue Jul 31, 2018
For Retry and Version Negotiation.

Closes #1292.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

No branches or pull requests

4 participants