From 95827872f54e34d9ba9d5dfe5c611efe92666bb8 Mon Sep 17 00:00:00 2001 From: ianswett Date: Fri, 10 May 2019 07:01:12 -0400 Subject: [PATCH 01/14] Clarify server CONNECTION_CLOSE with Handshake No new normative text, but clarifies that if the server wants the client to process a connection close, it may have to send one in Initial and Handshake. Came up in discussion on #2541 --- draft-ietf-quic-transport.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index dc044f6e8f..bc38f9901c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2307,10 +2307,14 @@ signal closure. If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames -in a Handshake packet. If the endpoint does not have Handshake keys, or it is -not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE -frames in an Initial packet. If multiple packets are sent, they can be -coalesced (see {{packet-coalesce}}) to facilitate retransmission. +in a Handshake packet.If the endpoint does not have Handshake keys, it MAY +send CONNECTION_CLOSE frames in an Initial packet. + +The server can have Handshake keys but not know that the client has Handshake +keys. In order to guarantee a CONNECTION_CLOSE is processed, it has to send +a CONNECTION_CLOSE in both Handshake and Initial, because the client discards +Initial keys as soon as it has Handshake keys. If multiple packets are sent, +they can be coalesced (see {{packet-coalesce}}) to facilitate retransmission. ## Stateless Reset {#stateless-reset} From 9bcc7fa068fdd7100c1f3bb5eff18184a3f09518 Mon Sep 17 00:00:00 2001 From: ianswett Date: Fri, 10 May 2019 10:59:31 -0400 Subject: [PATCH 02/14] Update draft-ietf-quic-transport.md Co-Authored-By: Nick Banks --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bc38f9901c..292f3c0659 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2307,7 +2307,7 @@ signal closure. If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames -in a Handshake packet.If the endpoint does not have Handshake keys, it MAY +in a Handshake packet. If the endpoint does not have Handshake keys, it MAY send CONNECTION_CLOSE frames in an Initial packet. The server can have Handshake keys but not know that the client has Handshake From ead6736c0daf7d2d90058a7eee0029f9a2f511f3 Mon Sep 17 00:00:00 2001 From: ianswett Date: Fri, 10 May 2019 11:05:50 -0400 Subject: [PATCH 03/14] Update draft-ietf-quic-transport.md Nick's comments. This now changes normative text. --- draft-ietf-quic-transport.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 292f3c0659..15cd7bef3c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2307,14 +2307,14 @@ signal closure. If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames -in a Handshake packet. If the endpoint does not have Handshake keys, it MAY +in a Handshake packet. If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. -The server can have Handshake keys but not know that the client has Handshake -keys. In order to guarantee a CONNECTION_CLOSE is processed, it has to send -a CONNECTION_CLOSE in both Handshake and Initial, because the client discards -Initial keys as soon as it has Handshake keys. If multiple packets are sent, -they can be coalesced (see {{packet-coalesce}}) to facilitate retransmission. +The server may not know whether the client has Handshake keys. In order to +guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE +in both Handshake and Initial, because the client discards Initial keys as soon +as it has Handshake keys. If multiple packets are sent, they can be coalesced +(see {{packet-coalesce}}). ## Stateless Reset {#stateless-reset} From 96c89135a1889e5209bc38e64026735d187b50c0 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 12 May 2019 20:16:04 -0400 Subject: [PATCH 04/14] Update draft-ietf-quic-transport.md Co-Authored-By: Martin Thomson --- draft-ietf-quic-transport.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 15cd7bef3c..962b6ffb50 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2304,6 +2304,13 @@ the application requests that the connection be closed. The application protocol can use an CONNECTION_CLOSE frame with an appropriate error code to signal closure. +When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process +the frame. Generally, this means sending the frame in a packet with the highest +level of packet protection to avoid the packet being discarded. However, during +the handshake, it is possible that more advanced packet protection keys are not +available to a peer, so the frame MAY be replicated in a packet that uses a +lower packet protection level. + If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames From e70eff7103fa457e16158dbf03f21d44672e1d76 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 12 May 2019 20:19:08 -0400 Subject: [PATCH 05/14] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 962b6ffb50..9856d2cacb 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2311,11 +2311,11 @@ the handshake, it is possible that more advanced packet protection keys are not available to a peer, so the frame MAY be replicated in a packet that uses a lower packet protection level. -If the connection has been successfully established, endpoints MUST send any -CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a -peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames -in a Handshake packet. If the endpoint does not have Handshake keys, it SHOULD -send CONNECTION_CLOSE frames in an Initial packet. +If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames +in a 1-RTT packet. Prior to handshake confirmation, a peer might not have +1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake +packet. If the endpoint does not have Handshake keys, it SHOULD send +CONNECTION_CLOSE frames in an Initial packet. The server may not know whether the client has Handshake keys. In order to guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE From cfa8de6f77ce88c84136eac6dc91398ec1445680 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 14 May 2019 19:17:56 -0400 Subject: [PATCH 06/14] Update draft-ietf-quic-transport.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9856d2cacb..8267b6b219 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2317,7 +2317,7 @@ in a 1-RTT packet. Prior to handshake confirmation, a peer might not have packet. If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. -The server may not know whether the client has Handshake keys. In order to +A client will always know whether the server has Handshake keys (see {{discard-initial}}), but it is possible that a server does not know whether the client has Handshake keys. guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE in both Handshake and Initial, because the client discards Initial keys as soon as it has Handshake keys. If multiple packets are sent, they can be coalesced From ab282cd9ed385732ecdef405f92e4840bfeee724 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 14 May 2019 19:20:01 -0400 Subject: [PATCH 07/14] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8267b6b219..85de25ab32 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2317,11 +2317,12 @@ in a 1-RTT packet. Prior to handshake confirmation, a peer might not have packet. If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. -A client will always know whether the server has Handshake keys (see {{discard-initial}}), but it is possible that a server does not know whether the client has Handshake keys. -guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE -in both Handshake and Initial, because the client discards Initial keys as soon -as it has Handshake keys. If multiple packets are sent, they can be coalesced -(see {{packet-coalesce}}). +A client will always know whether the server has Handshake keys +(see {{discard-initial}}), but it is possible that a server does not know +whether the client has Handshake keys. Under these circumstances, a server +SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets +to ensure that at least one of them is processable by the client. These packets +can be coalesced into a single UDP datagram (see {{packet-coalesce}}). ## Stateless Reset {#stateless-reset} From 1bb9ef09352cce9ed56c14058105a2029f111715 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 14 May 2019 20:48:02 -0400 Subject: [PATCH 08/14] Update draft-ietf-quic-transport.md --- 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 85de25ab32..ddc6f1aa0f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2321,8 +2321,8 @@ A client will always know whether the server has Handshake keys (see {{discard-initial}}), but it is possible that a server does not know whether the client has Handshake keys. Under these circumstances, a server SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets -to ensure that at least one of them is processable by the client. These packets -can be coalesced into a single UDP datagram (see {{packet-coalesce}}). +to ensure that at least one of them is processable by the client. These +packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}). ## Stateless Reset {#stateless-reset} From 4079e66c3b6663c49ea6ba0d78ca6a184724eb2a Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 5 Jun 2019 09:53:31 -0400 Subject: [PATCH 09/14] Update draft-ietf-quic-transport.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ddc6f1aa0f..a609adcb96 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2304,7 +2304,7 @@ the application requests that the connection be closed. The application protocol can use an CONNECTION_CLOSE frame with an appropriate error code to signal closure. -When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process +When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame. Generally, this means sending the frame in a packet with the highest level of packet protection to avoid the packet being discarded. However, during the handshake, it is possible that more advanced packet protection keys are not From 9dfb614cec93c5b860ccd06fd7e6a3d3fdcd53ed Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 5 Jun 2019 09:53:38 -0400 Subject: [PATCH 10/14] Update draft-ietf-quic-transport.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a609adcb96..ee55e77404 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2308,7 +2308,7 @@ When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame. Generally, this means sending the frame in a packet with the highest level of packet protection to avoid the packet being discarded. However, during the handshake, it is possible that more advanced packet protection keys are not -available to a peer, so the frame MAY be replicated in a packet that uses a +available to the peer, so the frame MAY be replicated in a packet that uses a lower packet protection level. If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames From 4029df2796f2426543d7becb051809a6ef94c262 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 5 Jun 2019 09:54:04 -0400 Subject: [PATCH 11/14] Update draft-ietf-quic-transport.md Co-Authored-By: MikkelFJ --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ee55e77404..78d633ff1d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2312,7 +2312,7 @@ available to the peer, so the frame MAY be replicated in a packet that uses a lower packet protection level. If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames -in a 1-RTT packet. Prior to handshake confirmation, a peer might not have +in a 1-RTT packet. Prior to handshake confirmation, the peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. From 68d1c8b3b1dd3b657de8a7b4580f7a8da0db509b Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 5 Jun 2019 09:54:20 -0400 Subject: [PATCH 12/14] Update draft-ietf-quic-transport.md Co-Authored-By: MikkelFJ --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 78d633ff1d..d52e66fd62 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2313,7 +2313,7 @@ lower packet protection level. If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to handshake confirmation, the peer might not have -1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake +1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. From b669d0f7c51fa100e2c7c76fe6ddffa1e2c495d9 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 5 Jun 2019 09:55:07 -0400 Subject: [PATCH 13/14] Update draft-ietf-quic-transport.md Co-Authored-By: MikkelFJ --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d52e66fd62..20423639ef 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2311,7 +2311,7 @@ the handshake, it is possible that more advanced packet protection keys are not available to the peer, so the frame MAY be replicated in a packet that uses a lower packet protection level. -If the handshake is confirmed, endpoints MUST send any CONNECTION_CLOSE frames +When the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to handshake confirmation, the peer might not have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the endpoint does not have Handshake keys, it SHOULD send From ce74eecbbc1228dc48a69b249126410eb597e0fa Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 5 Jun 2019 09:55:50 -0400 Subject: [PATCH 14/14] Update draft-ietf-quic-transport.md Once -> After --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 20423639ef..17ca5285d1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2311,10 +2311,10 @@ the handshake, it is possible that more advanced packet protection keys are not available to the peer, so the frame MAY be replicated in a packet that uses a lower packet protection level. -When the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE frames -in a 1-RTT packet. Prior to handshake confirmation, the peer might not have -1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a Handshake -packet. If the endpoint does not have Handshake keys, it SHOULD send +After the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE +frames in a 1-RTT packet. Prior to handshake confirmation, the peer might not +have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a +Handshake packet. If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. A client will always know whether the server has Handshake keys