From 9138fd991036a0af2c1593ef96d75ad8ed9be07b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 19 Oct 2018 15:58:02 +1100 Subject: [PATCH 1/6] I decided to reword this after reading it. It missed a few key things. I think that the second piece to #1786, which was to make allowances for fatal errors arising from Initial packets won't be necessary. I'm happy to see a PR, of course, but the sentiment I've heard expressed is that it is very hard to manage this, and the spec wouldn't expressly prevent someone from trying to build a system that was resilient to maliciously-crafted Initial packets, but we wouldn't take steps in this document to deal with that. As previously agreed, if you are attacked and the attacker was able to modify Initial packets, then they can deny you the ability to connect. Closes #1818, #1786. --- draft-ietf-quic-transport.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 92009d9846..caa3043b9c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2313,6 +2313,12 @@ the application requests that the connection be closed. The application protocol can use an APPLICATION_CLOSE message with an appropriate error code to signal closure. +If the endpoint believes that a connection has been successfully established, it +MUST send any closing frames in a 1-RTT packet. Prior to connection +establishment, endpoints SHOULD send closing frames in a Handshake packet. An +endpoint MAY send closing frames in an Initial packet. Closing frames might be +replicated into packets at different encryption levels, which can then be +coalesced (see {{packet-coalesce}} to facilitate retransmission. ### Stateless Reset {#stateless-reset} From f94c3957f232fc644d6bcf1d83b0ea8745034d69 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 22 Oct 2018 10:24:28 +1100 Subject: [PATCH 2/6] Be less cagey --- 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 caa3043b9c..540b4d960d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2313,12 +2313,12 @@ the application requests that the connection be closed. The application protocol can use an APPLICATION_CLOSE message with an appropriate error code to signal closure. -If the endpoint believes that a connection has been successfully established, it -MUST send any closing frames in a 1-RTT packet. Prior to connection -establishment, endpoints SHOULD send closing frames in a Handshake packet. An -endpoint MAY send closing frames in an Initial packet. Closing frames might be -replicated into packets at different encryption levels, which can then be -coalesced (see {{packet-coalesce}} to facilitate retransmission. +If the connection has been successfully established, endpoints MUST send any +closing frames in a 1-RTT packet. Prior to connection establishment, endpoints +SHOULD send closing frames in a Handshake packet. An endpoint MAY send closing +frames in an Initial packet. Closing frames might be replicated into packets at +different encryption levels, which can then be coalesced (see +{{packet-coalesce}} to facilitate retransmission. ### Stateless Reset {#stateless-reset} From 8c2aaa3650e5cd214df3171c9b94b3aa4d4f2f2b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 22 Oct 2018 10:25:55 +1100 Subject: [PATCH 3/6] Remove #1818 changes as duplicates --- draft-ietf-quic-transport.md | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 540b4d960d..6e698d2b24 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2272,15 +2272,6 @@ An endpoint sends a closing frame (CONNECTION_CLOSE or APPLICATION_CLOSE) to terminate the connection immediately. Any closing frame causes all streams to immediately become closed; open streams can be assumed to be implicitly reset. -If the endpoint has received an ACK for a 1-RTT packet, it SHOULD send -CONNECTION_CLOSE in a 1-RTT packet. If not, and it has received a Handshake -packet from the peer, it SHOULD send CONNECTION_CLOSE in a Handshake packet. - -If the endpoint has received only Initial packets from the peer, it SHOULD -send CONNECTION_CLOSE in an Initial packet. If it has Handshake keys available, -it SHOULD also send the frame in a Handshake packet coalesced with the Initial -packet. - After sending a closing frame, endpoints immediately enter the closing state. During the closing period, an endpoint that sends a closing frame SHOULD respond to any packet that it receives with another packet containing a closing frame. @@ -2320,6 +2311,7 @@ frames in an Initial packet. Closing frames might be replicated into packets at different encryption levels, which can then be coalesced (see {{packet-coalesce}} to facilitate retransmission. + ### Stateless Reset {#stateless-reset} A stateless reset is provided as an option of last resort for an endpoint that From 86445c929cbc57ad010aeab7a717009d60152002 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 24 Oct 2018 10:32:12 +1100 Subject: [PATCH 4/6] Ian's suggestion --- 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 6e698d2b24..3e5e58c707 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2306,9 +2306,9 @@ signal closure. If the connection has been successfully established, endpoints MUST send any closing frames in a 1-RTT packet. Prior to connection establishment, endpoints -SHOULD send closing frames in a Handshake packet. An endpoint MAY send closing -frames in an Initial packet. Closing frames might be replicated into packets at -different encryption levels, which can then be coalesced (see +SHOULD send closing frames in a Handshake packet if possible. An endpoint MAY +send closing frames in an Initial packet. Closing frames might be replicated +into packets at different encryption levels, which can then be coalesced (see {{packet-coalesce}} to facilitate retransmission. From d513b05d9f3efb1442fae4e9ab0476fc9cdeaec7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 24 Oct 2018 10:41:07 +1100 Subject: [PATCH 5/6] Reword some with explanations --- 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 708ada7cdb..b389c64144 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2243,11 +2243,12 @@ protocol can use an APPLICATION_CLOSE message with an appropriate error code to signal closure. If the connection has been successfully established, endpoints MUST send any -closing frames in a 1-RTT packet. Prior to connection establishment, endpoints -SHOULD send closing frames in a Handshake packet if possible. An endpoint MAY -send closing frames in an Initial packet. Closing frames might be replicated -into packets at different encryption levels, which can then be coalesced (see -{{packet-coalesce}} to facilitate retransmission. +closing frames in a 1-RTT packet. Prior to connection establishment a peer +might not have 1-RTT keys, so endpoints SHOULD send closing frames in a +Handshake packet. If they are not certain that the peer has Handshake keys, an +endpoint MAY send closing frames in an Initial packet. If multiple packets are +sent, they can be coalesced (see {{packet-coalesce}}) to facilitate +retransmission. ## Stateless Reset {#stateless-reset} From 0169c8952a2f2e998e57ed8c98edcab7c726abe7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 24 Oct 2018 10:43:07 +1100 Subject: [PATCH 6/6] reword --- 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 b389c64144..2e0d1839a8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2245,10 +2245,10 @@ signal closure. If the connection has been successfully established, endpoints MUST send any closing frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send closing frames in a -Handshake packet. If they are not certain that the peer has Handshake keys, an -endpoint MAY send closing frames in an Initial packet. If multiple packets are -sent, they can be coalesced (see {{packet-coalesce}}) to facilitate -retransmission. +Handshake packet. If the endpoint does not have Handshake keys, or it is not +certain that the peer has Handshake keys, it MAY send closing frames in an +Initial packet. If multiple packets are sent, they can be coalesced (see +{{packet-coalesce}}) to facilitate retransmission. ## Stateless Reset {#stateless-reset}