Subject: [quicwg/base-drafts] PONG frame (#878)

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Oct 2017 22:29:44 -0700

Split this from the migration patch.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/878

-- Commit Summary --

  * PONG frame
  * Actually define the error code

-- File Changes --

    M draft-ietf-quic-transport.md (58)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/878.patch
https://github.com/quicwg/base-drafts/pull/878.diff

-- 
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/pull/878

---

From: MikkelFJ <[email-masked]>
Date: Mon, 16 Oct 2017 08:54:32 +0000 (UTC)

I like the PONG especially because it can elicit an immediate response when app protocol so desires as opposed to delayed ACKs. This can be used liveness checks at various levels in the stack.

I assume the length field is 8 bytes in anticipation of a future var length encoding that has not yet been made to mainstream, otherwise 8 bytes is a way to big number. Allowing it to be large may put unnecessary security constraints on the app protocols because the PING frame can be abusively large on large MTU's forcing PING response caches waiting for app protocol to respond and thus waste memory. There is on overall flow control limit, but no limit like for stream data.

My immediate thought was that a simple single integer would suffice and simplify the idea without giving up much. But, I can see that you might want a serial number + an application subsystem identifier, or more generally, an encoded message in one of many possible binary encodings.

Thus, I think some safety concerns must be considered, possibly limiting the frequence or size, or at least very clearly state the application protocol must be aware of any potential attack vectors.

-- 
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/pull/878#issuecomment-336822894

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 22:17:45 +0000 (UTC)

janaiyengar commented on this pull request.

Thanks for splitting this out. A couple of points, inline.

> -application protocol wishes to prevent the connection from timing out.  An
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|   Length(8)   |                 Data (*)                    ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+Length:
+
+: This 8-bit value describes the length of the Data field.
+
+Data:
+
+: This variable-length field contains arbitrary data.

"Upon loss detection, a retransmitted PING MUST carry the same data."

> @@ -2063,6 +2087,20 @@ Application Error Code:
   {{app-error-codes}}).

+
+## PONG Frame {#frame-pong}
+
+The PONG frame (type=0x0d) is sent in response to a PING frame that contains
+data.  Its format is identical to the PING frame ({{frame-ping}}).
+
+An endpoint that receives an unsolicited PONG frame - that is, a PONG frame
+containing a payload that is either empty or not identical to the content of a
+PING frame that the endpoint previously sent - MUST generate a connection error
+of type UNSOLICITED_PONG.  Note that the Data field of the frame is the only

You'll need to account for retransmission/duplication of PONG packets. If an endpoint transmits a PONG, has a timeout and retransmits the PONG, then the receiver of the first PONG will discard state associated with the PING, and will close the connection on receiving the second PONG.

You could ask the PING sender to remember PINGs sent over the past X RTTs, or simply discard PONGs with unknown data. I'd recommend (and implement) the latter, since its easier, has very little state, and there's no way to enforce that an endpoint terminate a connection on receiving a bad PONG.

-- 
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/pull/878#pullrequestreview-69716231

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 17:45:27 -0700

martinthomson commented on this pull request.

+~~~
+ 0                   1                   2                   3

I don't think that's necessary.  On the contrary, it could increase the state commitment for the sender.  What is being tested is the need for a PING/PONG.  We're not trying to send data.

For reference, ICE sends similar probes and every single one of them contains a different transaction ID (the field that is analogous to the field that this PR adds), especially when the probe is being sent multiple times over a long period of time.  QUIC doesn't have the same identification problem - it can use ACKs to correlate packets - but it does have to verify that a particular was correctly received, and it can be more certain of that if the PING contains fresh entropy every time.

-- 
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/pull/878#discussion_r145005047

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 17:47:05 -0700

{{app-error-codes}}).

+

...or you could include a MAC in the payload and avoid all state, thereby avoiding the problem.

-- 
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/pull/878#discussion_r145005226

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 20:47:54 -0700

+~~~
+ 0                   1                   2                   3

Hm -- yeah, I forgot that there are ACKs for PINGs.

-- 
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/pull/878#discussion_r145021955

---

From: janaiyengar <[email-masked]>
Date: Tue, 17 Oct 2017 03:49:59 +0000 (UTC)

{{app-error-codes}}).

+

I don't understand. My suggestion here was to remove the requirement that a PONG MUST match an open PING. This seems unnecessary.

-- 
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/pull/878#discussion_r145022143

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Oct 2017 03:57:10 +0000 (UTC)

{{app-error-codes}}).

+

Would you be OK with MAY?  I want to ensure that bad actors can't guess PONG values without consequence.

-- 
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/pull/878#discussion_r145022773

---

From: janaiyengar <[email-masked]>
Date: Tue, 17 Oct 2017 04:44:17 +0000 (UTC)

{{app-error-codes}}).

+

Bad actors can simply send random PONGs and cause the connection to be torn down, that's quite a bad consequence, isn't it? I was trying to prevent the connection from getting torn down because of legitimate operational issues, such as a duplicate PONG reaching the PING sender late. Basically, you're currently requiring that the sender of a PING hold some state without stating exactly what state, and if it sees a PONG that doesn't match the unspecified state, that it kill the connection. 

I am fine with saying MAY, but I would qualify the sentence with something like "If the receiver of a PONG can be certain that the received Data was not sent by it .... ". WDYT?

-- 
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/pull/878#discussion_r145026685

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 21:50:00 -0700

{{app-error-codes}}).

+

I can work with that; it's what I was thinking.

FWIW, I didn't have a design that required state in mind.  But you are right to point out that a MUST narrows the range of reasonable designs considerably.

Not sure about the "bad actors" point you make here.  The point is to have the connection torn down if someone starts generating random PONGs.  After all, if you want to close the connection and you have the keys, you have other more direct methods available to you.

-- 
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/pull/878#discussion_r145027133

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Oct 2017 04:54:03 +0000 (UTC)

@martinthomson pushed 1 commit.

d37d72f  Loosen UNSOLICITED_PONG requirements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/878/files/9b109a3ef936f690bd5608213e4911ba3c29a5d8..d37d72fab17a226d1639786ac406f637a77628f5

---

From: janaiyengar <[email-masked]>
Date: Tue, 17 Oct 2017 04:56:01 +0000 (UTC)

{{app-error-codes}}).

+

I can totally see that you can build this without state, but we have to prepare for a naive implementer who doesn't recognize that a simple implementation that remembers exactly one PING is likely to break in a variety of situations.

About the "bad actors", agreed.

-- 
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/pull/878#discussion_r145027658

---

From: janaiyengar <[email-masked]>
Date: Mon, 16 Oct 2017 21:56:38 -0700

janaiyengar approved this pull request.

Thanks for working through this!

-- 
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/pull/878#pullrequestreview-69765737

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 22:00:33 -0700

Merged #878.

-- 
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/pull/878#event-1296133026