From 32fc567f44c02e3468d3cff727dfcbab18919fbf Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 5 Jun 2020 09:17:46 +1000 Subject: [PATCH] Use 'message' less The PMTUD one I will add to #3702. The others I don't plan to fix. Closes #3724. --- draft-ietf-quic-transport.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1a51d72b82..5b6934057a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1027,12 +1027,13 @@ NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). ### Issuing Connection IDs {#issue-cid} -Each Connection ID has an associated sequence number to assist in deduplicating -messages. The initial connection ID issued by an endpoint is sent in the Source -Connection ID field of the long packet header ({{long-header}}) during the -handshake. The sequence number of the initial connection ID is 0. If the -preferred_address transport parameter is sent, the sequence number of the -supplied connection ID is 1. +Each Connection ID has an associated sequence number to assist in detecting when +NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer to the same value. The +initial connection ID issued by an endpoint is sent in the Source Connection ID +field of the long packet header ({{long-header}}) during the handshake. The +sequence number of the initial connection ID is 0. If the preferred_address +transport parameter is sent, the sequence number of the supplied connection ID +is 1. Additional connection IDs are communicated to the peer using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}). The sequence number on each newly-issued @@ -1255,8 +1256,8 @@ establish a shared secret using the cryptographic handshake protocol ({{transport-parameters}}). An application protocol can also operate in a limited fashion during the -handshake phase. 0-RTT allows application messages to be sent by a client -before receiving any messages from the server. However, 0-RTT lacks certain key +handshake phase. 0-RTT allows application data to be sent by a client before +receiving any response from the server. However, 0-RTT lacks certain key security guarantees. In particular, there is no protection against replay attacks in 0-RTT; see {{QUIC-TLS}}. Separately, a server can also send application data to a client before it receives the final cryptographic @@ -6183,9 +6184,9 @@ streams. ## Peer Denial of Service {#useless} -QUIC and TLS both contain messages that have legitimate uses in some contexts, -but that can be abused to cause a peer to expend processing resources without -having any observable impact on the state of the connection. +QUIC and TLS both contain frames or messages that have legitimate uses in some +contexts, but that can be abused to cause a peer to expend processing resources +without having any observable impact on the state of the connection. Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow control limits.