From 33d62fcd264d13fafb5a5571f9506d9411d6e01d Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 29 Jan 2018 15:05:42 -0800 Subject: [PATCH 1/5] Clarify flow control issues on stream 0 --- draft-ietf-quic-transport.md | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0c6fc8db79..3c5dd472cc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -650,6 +650,11 @@ described in {{packet-numbers}}. The client increments the packet number from its previous packet by one for each Handshake packet that it sends (which might be an Initial, 0-RTT Protected, or Handshake packet). +Servers MUST NOT send more than three Handshake packets in response to a +client's Initial packet without validating the client's ownership of the +address, either via a Retry packet or by receiving packets from the client +in response to the server's Handshake packets. + The payload of this packet contains STREAM frames and could contain PADDING and ACK frames. @@ -3368,11 +3373,11 @@ the sender receives an update before running out of flow control credit, even if one of the packets is lost. Connection flow control is a limit to the total bytes of stream data sent in -STREAM frames on all streams. A receiver advertises credit for a connection by -sending a MAX_DATA frame. A receiver maintains a cumulative sum of bytes -received on all streams, which are used to check for flow control violations. A -receiver might use a sum of bytes consumed on all contributing streams to -determine the maximum data limit to be advertised. +STREAM frames on all streams except stream 0. A receiver advertises credit for +a connection by sending a MAX_DATA frame. A receiver maintains a cumulative sum +of bytes received on all streams, which are used to check for flow control +violations. A receiver might use a sum of bytes consumed on all contributing +streams to determine the maximum data limit to be advertised. ## Edge Cases and Other Considerations @@ -3426,6 +3431,17 @@ it increases data limits based on a roundtrip time estimate and the rate at which the receiving application consumes data, similar to common TCP implementations. +### Handshake Exemption + +During the initial handshake, a server could need to send a larger message than +would ordinarily be permitted by the client's initial stream flow control +window. Since MAX_STREAM_DATA frames are not permitted in Handshake packets, the +client cannot respond to server requests for additional flow control window in +order to complete the handshake. + +Servers MAY exceed the flow control limits on stream 0 prior to the completion +of the cryptographic handshake. However, once the handshake is complete, +servers MUST NOT send data beyond the client's permitted offset. ## Stream Limit Increment From 2fa05ac4dc6259ddea18a3d0f83ea33788e20408 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 29 Jan 2018 15:12:57 -0800 Subject: [PATCH 2/5] Really, not zero --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3c5dd472cc..506a4780a5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3375,9 +3375,9 @@ one of the packets is lost. Connection flow control is a limit to the total bytes of stream data sent in STREAM frames on all streams except stream 0. A receiver advertises credit for a connection by sending a MAX_DATA frame. A receiver maintains a cumulative sum -of bytes received on all streams, which are used to check for flow control -violations. A receiver might use a sum of bytes consumed on all contributing -streams to determine the maximum data limit to be advertised. +of bytes received on all contributing streams, which are used to check for flow +control violations. A receiver might use a sum of bytes consumed on all +contributing streams to determine the maximum data limit to be advertised. ## Edge Cases and Other Considerations From eca60b8b3af57993ac4fee8a5a65a35a3ca13cfe Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 31 Jan 2018 16:23:00 -0800 Subject: [PATCH 3/5] Extract amplification mitigation --- draft-ietf-quic-transport.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 506a4780a5..b8fef79bf4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -650,11 +650,6 @@ described in {{packet-numbers}}. The client increments the packet number from its previous packet by one for each Handshake packet that it sends (which might be an Initial, 0-RTT Protected, or Handshake packet). -Servers MUST NOT send more than three Handshake packets in response to a -client's Initial packet without validating the client's ownership of the -address, either via a Retry packet or by receiving packets from the client -in response to the server's Handshake packets. - The payload of this packet contains STREAM frames and could contain PADDING and ACK frames. From 26521a16e9a2ceb9cbdba6c359fbde582165e976 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 31 Jan 2018 16:28:12 -0800 Subject: [PATCH 4/5] Clarify handshake exemption --- draft-ietf-quic-transport.md | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b8fef79bf4..76181a866f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3428,15 +3428,19 @@ implementations. ### Handshake Exemption -During the initial handshake, a server could need to send a larger message than -would ordinarily be permitted by the client's initial stream flow control -window. Since MAX_STREAM_DATA frames are not permitted in Handshake packets, the -client cannot respond to server requests for additional flow control window in -order to complete the handshake. - -Servers MAY exceed the flow control limits on stream 0 prior to the completion -of the cryptographic handshake. However, once the handshake is complete, -servers MUST NOT send data beyond the client's permitted offset. +During the initial handshake, an endpoint could need to send a larger message on +stream 0 than would ordinarily be permitted by the peer's initial stream flow +control window. Since MAX_STREAM_DATA frames are not permitted in these early +packets, the peer cannot provide additional flow control window in order to +complete the handshake. + +Endpoints MAY exceed the flow control limits on stream 0 prior to the completion +of the cryptographic handshake. (That is, in Initial, Retry, and Handshake +packets.) However, once the handshake is complete, endpoints MUST NOT send +additional data beyond the peer's permitted offset. If the amount of data sent +during the handshake exceeds the peer's maximum offset, the endpoint cannot send +additional data until the peer has sent a MAX_STREAM_DATA frame indicating a +larger maximum offset. ## Stream Limit Increment From ee3909c42bfb174da183b7ccfba0a37c37040623 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 31 Jan 2018 16:35:42 -0800 Subject: [PATCH 5/5] Just to be perfectly clear.... --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 76181a866f..2d0cc71542 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3439,8 +3439,8 @@ of the cryptographic handshake. (That is, in Initial, Retry, and Handshake packets.) However, once the handshake is complete, endpoints MUST NOT send additional data beyond the peer's permitted offset. If the amount of data sent during the handshake exceeds the peer's maximum offset, the endpoint cannot send -additional data until the peer has sent a MAX_STREAM_DATA frame indicating a -larger maximum offset. +additional data on stream 0 until the peer has sent a MAX_STREAM_DATA frame +indicating a larger maximum offset. ## Stream Limit Increment