Subject: [quicwg/base-drafts] Small clarification in 12.2 Coalescing Packets (#2900)

From: anrossi <[email-masked]>
Date: Mon, 15 Jul 2019 15:00:39 -0700

In some testing with WinQuic, we noticed a small inconsistency in Section 12.2 of the transport spec that needs some clarification.
Section 12.2 says that if decryption fails, an implementation MUST attempt to process remaining packets in a coalesced UDP datagram. However, consider the following scenario:

1. An endpoint received a UDP datagram with a single short header packet, the first of the 1-RTT encryption level. This implicitly ACKs the end of the handshake and the receiver discards the handshake keys.
2. The sender then sends a coalesced datagram with a single long-header packet (an ACK for the handshake), and then a short header packet containing more 1-RTT data.

Since the receiver has thrown away the handshake keys, they are unable to decrypt the long header packet in the second datagram, and without being able to decrypt the header protection on the long header packet, they cannot ascertain the length, and are unable to find the short header packet that follows. As a result, the whole datagram is thrown away.

Can the "MUST" referenced above be clarified for which scenarios are/aren't supported?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900

---

From: David Schinazi <[email-masked]>
Date: Mon, 15 Jul 2019 17:27:06 -0700

The `Length` field in long header packets is not encrypted, precisely to allow scenarios like this one.

Also note that an endpoint only discards handshake keys once the handshake is confirmed: https://tools.ietf.org/html/draft-ietf-quic-tls-22#section-4.9.2

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511617466

---

From: Nick Banks <[email-masked]>
Date: Mon, 15 Jul 2019 18:08:43 -0700

https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-12.2 states:

> The length of the Payload field is learned once header protection is removed.

If you can't remove header protection, then you can't process any additional coalesced packets in the datagram because you don't know the length of the current packet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511624594

---

From: ianswett <[email-masked]>
Date: Mon, 15 Jul 2019 18:21:25 -0700

>From what I can find, header protection isn't applied to the Length field, so should that sentence be removed?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511626921

---

From: Nick Banks <[email-masked]>
Date: Mon, 15 Jul 2019 18:53:21 -0700

I went back and double checked. I thought Length followed the packet number, which is variable length, but it does seem to precede the field. Perhaps all that does need to be done is to remove that sentence then.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511632885

---

From: David Schinazi <[email-masked]>
Date: Mon, 15 Jul 2019 22:08:59 -0700

The length is definitely not encrypted (there's no text explaining how to encrypt or decrypt it). I'd mark this issue as editorial and have it track the removal of the sentence `The length of the Payload field is learned once header protection is removed.` Feel free to send a PR :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511666876

---

From: MikkelFJ <[email-masked]>
Date: Tue, 16 Jul 2019 00:49:00 -0700

The Path Probe is abusing coalescing to ensure to get a long header
reflected via an invalid old handshake packet.

While I do not appreciate this design, everyone else seems to think it is a
great way to solve that problem.

If the old packet cannot not be skipped, this would not work. If the length
cannot be decoded due to other changes, this design needs to be revisited.

More likely though, the packet can be skipped, but some implementations
won’t, so path probing will be broken anyway.

On 16 July 2019 at 03.53.16, Nick Banks ([email-masked]) wrote:

I went back and double checked. I thought Length followed the packet
number, which is variable length, but it does seem to precede the field.
Perhaps all that does need to be done is to remove that sentence then.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/issues/2900?email_source=notifications&email_token=AABPGN3Q7TB7653HEXMGXS3P7USYXA5CNFSM4ID3FA42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7OL5I#issuecomment-511632885>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABPGN2TD6NXLLDY6ETGV5DP7USYXANCNFSM4ID3FA4Q>
.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511706288

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jul 2019 10:23:48 -0700

The sentence is correct. The only thing that is uncertain is the length of the packet number, but this also determines the length of the payload field. The question you are attempting to answer is the length of the packet. David is correct to point out that that length can be determined from unencrypted information.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-512430995

---

From: Nick Banks <[email-masked]>
Date: Wed, 17 Jul 2019 10:43:35 -0700

Ok. That makes sense. I think we can then just close this issue as a misunderstanding, as well as my PR.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#issuecomment-512477851

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 05:04:17 -0700

Closed #2900.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2900#event-2498012594