From 5b8fc24c5e085cc07e3d482972c6bd36523503ec Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 28 Feb 2017 14:57:21 -0800 Subject: [PATCH 01/13] Partial commit of new header format --- draft-ietf-quic-transport.md | 234 ++++++++++++++++++++++------------- 1 file changed, 145 insertions(+), 89 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 316743060a..de54855ac3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -322,114 +322,170 @@ all field sizes are in bits. When discussing individual bits of fields, the least significant bit is referred to as bit 0. Hexadecimal notation is used for describing the value of fields. +QUIC packet headers can be separated into long and short headers. Long headers +are expected to be used for the initial phase of the connection and are used for +version negotiation, connection establishment, 0-RTT, and public reset +packets. Short headers are minimal version-specific headers, which MAY be used +after version negotiation and 1-RTT keys are established, and MUST NOT be used +earlier. -## Common Header +## Long Header -All QUIC packets begin with a QUIC Common header, as shown below. - -~~~ +``` 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 +-+-+-+-+-+-+-+-+ -| Flags (8) | +|1| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | -+ [Connection ID (64)] + ++ Connection ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Type-Dependent Fields (*) ... +| Packet Number / Proof | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~ - -The fields in the Common Header are the following: - -* Flags: - - * 0x01 = VERSION. The semantics of this flag depends on whether the packet - is sent by the server or the client. A client MAY set this flag and - include exactly one proposed version. A server may set this flag when the - client-proposed version was unsupported, and may then provide a list (0 or - more) of acceptable versions as a part of version negotiation (described in - {{version-negotiation}}.) - - * 0x02 = PUBLIC_RESET. Set to indicate that the packet is a Public Reset - packet. - - * 0x04 = KEY_PHASE. This is used by the QUIC packet protection to identify - the correct packet protection keys, see {{QUIC-TLS}}. - - * 0x08 = CONNECTION_ID. Indicates the Connection ID is present in the - packet. This must be set in all packets until negotiated to a different - value for a given direction. For instance, if a client indicates that the - 5-tuple fully identifies the connection at the client, the connection ID is - optional in the server-to-client direction. The negotiation is described in - {{transport-parameter-definitions}}. - - * 0x30 = PACKET_NUMBER_SIZE. These two bits indicate the number of - low-order-bytes of the packet number that are present in each packet. - - + 11 indicates that 6 bytes of the packet number are present - + 10 indicates that 4 bytes of the packet number are present - + 01 indicates that 2 bytes of the packet number are present - + 00 indicates that 1 byte of the packet number is present - - * 0x40 = MULTIPATH. This bit is reserved for multipath use. - - * 0x80 is currently unused, and must be set to 0. - -* Connection ID: An unsigned 64-bit random number chosen by the client, used as - the identifier of the connection. Connection ID is tied to a QUIC connection, - and remains consistent across client and/or server IP and port changes. - - -### Identifying Packet Types - -While all QUIC packets have the same common header, there are three types of -packets: Regular packets, Version Negotiation packets, and Public Reset packets. -The flowchart below shows how a packet is classified into one of these three -packet types: - -~~~ -Check the flags in the common header - | - | - V - +--------------+ - | PUBLIC_RESET | YES - | flag set? |-------> Public Reset packet - +--------------+ - | - | NO - V - +------------+ +-------------+ - | VERSION | YES | Packet sent | YES Version - | flag set? |-------->| by server? |--------> Negotiation - +------------+ +-------------+ packet - | | - | NO | NO - V V - Regular packet with Regular packet with - no QUIC Version in header QUIC Version in header -~~~ -{: #packet-types title="Types of QUIC Packets"} +| Version | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Payload ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +``` + +Long headers are used for packets that are sent prior to the completion of +version negotiation or are not encrypted with 1-RTT keys. Once both conditions +are met, a sender SHOULD switch to sending short-form headers. While +inefficient, long headers MAY be used for 1-RTT packets. The long form allows +for special packets, such as the version negotiation and the public reset +packets to be represented in this uniform fixed-length packet format. + +The first octet (octet 0) contains the following fields. +* Bit 0 (0x80): Header form. Set to 1 for long headers. +* Bits 1-7: Packet Type, indicating one of 128 packet types. The following types + are currently defined. + * 01: Version Negotiation packet + * 02: Public Reset packet + * 03: 0-RTT packet + * 04: Server cleartext packet + * 05: Client cleartext packet + * 06: 1-RTT packet with version field, connection ID, + and 2-byte packet number + +The remainder of the packet layout is the same regardless of type, but the +semantics of the fields are specific to each type, as described next. + +### Version Negotiation Packet + +A Version Negotiation packet is sent by the server in response to a client +packet of an unsupported version. It contains: + +* Octets 1-8: Connection ID (server-selected value, may be used in a subsequent + connection to reach the same server) +* Octets 9-12: Proof (first 4 octets of client-selected connection ID) +* Octets 13-16: Version (echoed) +* Octets 17+: Payload (version list, containing 0 or more acceptable versions) + +See {{version-negotiation}} for a description of the version negotiation +process. + +### Public Reset Packet + +A Public Reset packet is sent when the server has no state for a received +packet. A server may therefore have to respond to either a long-form or a +short-form packet. A public reset packet contains: + +* Octets 1-12: Proof (octets 1-12 of received packet) +* Octets 13-16: Version (server version) + +For a client that sends a connection ID on every packet, a Public Reset +packet received in response can be simply interpreted as: + +* Octets 1-8: Connection ID (echoed) +* Octets 9-12: Proof (echoed packet number, which could be 1, 2, or 4 bytes + depending on the packet number size used by the client, followed by 0, 2, or 3 + subsequent bytes from the client packet) +* Octets 13-16: Version (server version) + +### Client Cleartext Packet + +A client cleartext packet may be sent during the handshake. It contains: +* Octets 1-8: Connection ID (randomly chosen) +* Octets 9-12: Packet number (low 4 octets, starts at a random 31-bit value) +* Octets 13-16: Version +* Octets 17+: Payload + +The client MUST choose a random value and use it as the Connection ID until the +server replies with a server-selected Connection ID. The client's Connection ID +is a suggestion to the server, as described further in {{connection-id}}. + +### Server Cleartext Packet + +A server cleartext packet may be sent during the handshake. It contains: +* Octets 1-8: Connection ID (server-selected value) +* Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) +* Octets 13-16: Version (echoed) +* Octets 17+: Payload + +### Encrypted Packet Types + +Packets encrypted with either 0-RTT or 1-RTT keys may be sent with long headers. +Different packet types explicitly indicate the encryption level for ease of +decryption. These packets contain: +* Octets 1-8: Connection ID (client or server-selected, see {{connectionid}}) +* Octets 9-12: Packet Number (low 4 octets) +* Octets 13-16: Version +* Octets 17+: Payload + +## Short Header + +``` + 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 ++-+-+-+-+-+-+-+-+ +|0|C|K| Type | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | ++ Connection ID (optional) + +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Packet Number (1/2/4) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Payload ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +``` + +The short header is used after the version and 1-RTT keys are negotiated. This +header has the following version-independent fields: +* Octet 0: Flags + * Bit 0 (0x80): Header form, set to 0 for short headers. + * Bit 1: CONNECTION_ID. Indicates presence of Connection ID field following + the Flags byte. +* Octets 1-8: Connection ID (optional) + +The remainder of the short header is defined to be specific to a version. In +this version, it contains: +* Octet 0: Flags + * Bit 2: KEY_PHASE. Used by the QUIC packet protection to identify + the correct packet protection keys after the 1-RTT keys are initially + established. See {{QUIC-TLS}}. + * Bit 3-7: Packet Type, indicating one of 32 packet types. The following types + are currently defined. + * 01: 1-RTT packet (packet number size = 1) + * 02: 1-RTT packet (packet number size = 2) + * 03: 1-RTT packet (packet number size = 4) +* Octets 1-2/3/4 or 9-10/11/12: Packet Number (lower 8, 16, or 32 bits) +* Remainder of this packet: Payload. ### Handling Packets from Different Versions -Version negotiation ({{version-negotiation}}) is performed using packets that -have the VERSION bit set. This bit is always set on packets that are sent prior -to connection establishment. When receiving a packet that is not associated -with an existing connection, packets without a VERSION bit MUST be discarded. +When receiving a packet that is not associated with an existing connection, +packets with a short header MUST be discarded. Implementations MUST assume that an unsupported version uses an unknown packet -format. - -Between different versions the following things are guaranteed to remain -constant are: +format with the exception of the following. Between different versions the +following things are guaranteed to remain constant are: * the location and size of the Flags field, -* the location and value of the VERSION bit in the Flags field, +* the location and value of the Version Field * the location and size of the Connection ID field, and From 62a3d7b3a0fcee23cbce560dc9ec495fcedcb59e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 13:06:25 -0800 Subject: [PATCH 02/13] Everything except connection ID. --- draft-ietf-quic-transport.md | 411 ++++++++++++++++------------------- 1 file changed, 191 insertions(+), 220 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index de54855ac3..1cbf0fd2f2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -357,81 +357,23 @@ for special packets, such as the version negotiation and the public reset packets to be represented in this uniform fixed-length packet format. The first octet (octet 0) contains the following fields. -* Bit 0 (0x80): Header form. Set to 1 for long headers. +* Bit 0 (0x80): HEADER_FORM, set to 1 for long headers. * Bits 1-7: Packet Type, indicating one of 128 packet types. The following types are currently defined. - * 01: Version Negotiation packet - * 02: Public Reset packet - * 03: 0-RTT packet - * 04: Server cleartext packet - * 05: Client cleartext packet - * 06: 1-RTT packet with version field, connection ID, - and 2-byte packet number + * 01: Version Negotiation packet (see {{version-negotiation-packet}}.) + * 02: Public Reset packet (see {{public-reset-packet}}.) + * 03: Server Cleartext packet (see {{cleartext-packet}}.) + * 04: Client Cleartext packet (see {{cleartext-packet}}.) + * 05: 0-RTT encrypted packet (see {{encrypted-packet}}.) + * 06: 1-RTT encrypted packet (see {{encrypted-packet}}.) The remainder of the packet layout is the same regardless of type, but the -semantics of the fields are specific to each type, as described next. +semantics of the fields are specific to each type (see corresponding sections +for type-specific semantics.) -### Version Negotiation Packet - -A Version Negotiation packet is sent by the server in response to a client -packet of an unsupported version. It contains: - -* Octets 1-8: Connection ID (server-selected value, may be used in a subsequent - connection to reach the same server) -* Octets 9-12: Proof (first 4 octets of client-selected connection ID) -* Octets 13-16: Version (echoed) -* Octets 17+: Payload (version list, containing 0 or more acceptable versions) - -See {{version-negotiation}} for a description of the version negotiation -process. - -### Public Reset Packet - -A Public Reset packet is sent when the server has no state for a received -packet. A server may therefore have to respond to either a long-form or a -short-form packet. A public reset packet contains: - -* Octets 1-12: Proof (octets 1-12 of received packet) -* Octets 13-16: Version (server version) - -For a client that sends a connection ID on every packet, a Public Reset -packet received in response can be simply interpreted as: - -* Octets 1-8: Connection ID (echoed) -* Octets 9-12: Proof (echoed packet number, which could be 1, 2, or 4 bytes - depending on the packet number size used by the client, followed by 0, 2, or 3 - subsequent bytes from the client packet) -* Octets 13-16: Version (server version) - -### Client Cleartext Packet - -A client cleartext packet may be sent during the handshake. It contains: -* Octets 1-8: Connection ID (randomly chosen) -* Octets 9-12: Packet number (low 4 octets, starts at a random 31-bit value) -* Octets 13-16: Version -* Octets 17+: Payload - -The client MUST choose a random value and use it as the Connection ID until the -server replies with a server-selected Connection ID. The client's Connection ID -is a suggestion to the server, as described further in {{connection-id}}. - -### Server Cleartext Packet - -A server cleartext packet may be sent during the handshake. It contains: -* Octets 1-8: Connection ID (server-selected value) -* Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) -* Octets 13-16: Version (echoed) -* Octets 17+: Payload - -### Encrypted Packet Types - -Packets encrypted with either 0-RTT or 1-RTT keys may be sent with long headers. -Different packet types explicitly indicate the encryption level for ease of -decryption. These packets contain: -* Octets 1-8: Connection ID (client or server-selected, see {{connectionid}}) -* Octets 9-12: Packet Number (low 4 octets) -* Octets 13-16: Version -* Octets 17+: Payload +Connection ID considerations are discussed in {{connection-id}}. Each packet is +assigned a packet number by the sender, as described further in +{{packet-number}}. ## Short Header @@ -447,14 +389,14 @@ decryption. These packets contain: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (1/2/4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Payload ... +| Encrypted Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` The short header is used after the version and 1-RTT keys are negotiated. This header has the following version-independent fields: * Octet 0: Flags - * Bit 0 (0x80): Header form, set to 0 for short headers. + * Bit 0 (0x80): HEADER_FORM, set to 0 for short headers. * Bit 1: CONNECTION_ID. Indicates presence of Connection ID field following the Flags byte. * Octets 1-8: Connection ID (optional) @@ -470,83 +412,157 @@ this version, it contains: * 01: 1-RTT packet (packet number size = 1) * 02: 1-RTT packet (packet number size = 2) * 03: 1-RTT packet (packet number size = 4) -* Octets 1-2/3/4 or 9-10/11/12: Packet Number (lower 8, 16, or 32 bits) -* Remainder of this packet: Payload. +* Octets 1 (if C bit is 0) or 8 (otherwise) onwards: Packet Number (lower 8, + 16, or 32 bits) +* Remainder of this packet: Encrypted Payload (see {{encrypted-payload}}.) -### Handling Packets from Different Versions +## Version Negotiation Packet {version-negotiation-packet} -When receiving a packet that is not associated with an existing connection, -packets with a short header MUST be discarded. - -Implementations MUST assume that an unsupported version uses an unknown packet -format with the exception of the following. Between different versions the -following things are guaranteed to remain constant are: +A Version Negotiation packet is sent by only the server and is a response to a +client packet of an unsupported version. It uses a long header and contains: -* the location and size of the Flags field, - -* the location and value of the Version Field - -* the location and size of the Connection ID field, and - -* the Version (or Supported Versions, {{version-negotiation-packet}}) field. - -All other values MUST be ignored when processing a packet that contains an -unsupported version. - - -## Regular Packets +* Octet 0: 0x81 (Flags indicating long header and Version Negotiation packet + type) +* Octets 1-8: Connection ID (server-selected value, may be used in a subsequent + connection to reach the same server) +* Octets 9-12: Proof (first 4 octets of client-selected connection ID) +* Octets 13-16: Version (echoed) +* Octets 17+: Payload (version list, containing 0 or more acceptable versions) -Each Regular packet contains additional header fields followed by an encrypted -payload, as shown below: +The payload of the Version Negotiation packet is a list of 32-bit versions which +the server supports, as shown below. ~~~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| [Version (32)] | +| Supported Version 1 (32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Packet Number (8/16/32/48) ... +| Supported Version 2 (32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| {Encrypted Payload (*)} ... + ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Supported Version N (32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ -{: #regular-packet-format title="Regular Packet"} +{: #version-negotiation-format title="Version Negotiation Packet"} -The fields in a Regular packet past the Common Header are the following: +A server that generates a version negotiation packet SHOULD include one of the +reserved version numbers (those following the pattern 0x?a?a?a?a). This ensures +that clients are able to correctly handle an unsupported version. -* QUIC Version: A 32-bit opaque tag that represents the version of the QUIC - protocol. Only present in the client-to-server direction, and if the VERSION - flag is set. Version Negotiation is described in {{version-negotiation}}. +The design of version negotiation permits a server to avoid maintaining state +for packets that it rejects in this fashion. However, when the server generates +a version negotiation packet, it cannot randomly generate a reserved version +number. This is because the server is required to include the same value in its +transport parameters (see {{version-validation}}). To avoid the selected +version number changing during connection establishment, the reserved version +can be generated as a function of values that will be available to the server +when later generating its handshake packets. -* Packet Number: The lower 8, 16, 32, or 48 bits of the packet number, based on - the PACKET_NUMBER_SIZE flag. Each Regular packet is assigned a packet number - by the sender. The first packet number is randomized (see - {{initial-packet-number}}). +A pseudorandom function that takes client address information (IP and port) and +the client selected version as input would ensure that there is sufficient +variability in the values that a server uses. -* Encrypted Payload: The remainder of a Regular packet is both authenticated and - encrypted once packet protection keys are available. {{QUIC-TLS}} describes - packet protection in detail. After decryption, the plaintext consists of a - sequence of frames, as shown in {{regular-packet-frames}}. Frames are - described in {{frames}}. +A client MAY send a packet using a reserved version number. This can be used to +solicit a list of supported versions from a server. -~~~ - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Frame 1 (*) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Frame 2 (*) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Frame N (*) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~ -{: #regular-packet-frames title="Contents of Encrypted Payload"} +See {{version-negotiation}} for a description of the version negotiation +process. + +## Public Reset Packet {#public-reset-packet} + +A Public Reset packet is sent by only a server and is used to abruptly terminate +communications. Public Reset is provided as an option of last resort for a +server that does not have access to the state of a connection. This is intended +for use by a server that has lost state (for example, through a crash or +outage). A server that wishes to indicate fatal errors with a connection MUST +use a CONNECTION_CLOSE frame in preference to Public Reset if it has sufficient +state to do so. + +A public reset packet contains: + +* Octet 0: 0x82 (Flags indicating long header and Public Reset packet type) +* Octets 1-12: Echoed data (octets 1-12 of received packet) +* Octets 13-16: Version (server version) +* Octets 17+: Public Reset Proof (optional, TBD) + +For a client that sends a connection ID on every packet, a Public Reset +packet received in response can be simply interpreted as: + +* Octets 1-8: Connection ID (echoed) +* Octets 9-12: Echoed packet number, which could be 1, 2, or 4 bytes depending + on the packet number size used by the client, followed by 0, 2, or 3 + subsequent bytes from the client packet. +* Octets 13-16: Version (server version) +* Octets 17+: Public Reset Proof (optional, TBD) + +Whether the Public Reset Proof field is included in a Public Reset packet +depends on the entity that generates the packet. + +A Public Reset packet sent by an endpoint indicates that it does not have the +state necessary to continue with a connection. In this case, the endpoint will +include the fields that prove that it originally participated in the connection +(see {{public-reset-proof}} for details). + +Upon receipt of a Public Reset packet that contains a valid proof, an endpoint +MUST tear down state associated with the connection. The endpoint MUST then +cease sending packets on the connection and SHOULD discard any subsequent +packets that arrive. A Public Reset that does not contain a valid proof MUST be +ignored. + + +### Public Reset Proof +Details to be added. + + +## Cleartext Packets {#cleartext-packet} + +Cleartext packets are sent during the handshake prior to key negotiation. A +server cleartext packet contains: + +* Octet 0: 0x83 (Flags indicating Long header and server cleartext packet type) +* Octets 1-8: Connection ID (server-selected value) +* Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) +* Octets 13-16: Version (echoed) +* Octets 17+: Payload + +A client cleartext packet contains: +* Octet 0: 0x84 (Flags indicating long header and client cleartext packet type) +* Octets 1-8: Connection ID (randomly chosen) +* Octets 9-12: Packet number (low 4 octets, starts at a random 31-bit value) +* Octets 13-16: Version +* Octets 17+: Payload -## Packet Numbers +The client MUST choose a random value and use it as the Connection ID until the +server replies with a server-selected Connection ID. The client's Connection ID +is a suggestion to the server, as described further in {{connection-id}}. The +payload of cleartext packets contains frames, as described in {{frames}}. + +## Encrypted Packets {#encrypted-packet} + +Packets encrypted with either 0-RTT or 1-RTT keys may be sent with long headers. +Different packet types explicitly indicate the encryption level for ease of +decryption. These packets contain: +* Octet 0: 0x85 or 0x86 (Flags indicating long header and one of the two + encrypted packet types) +* Octets 1-8: Connection ID (client or server-selected, see {{connectionid}}) +* Octets 9-12: Packet Number (low 4 octets) +* Octets 13-16: Version +* Octets 17+: Encrypted Payload (see {{encrypted-payload}}.) + +The encrypted payload is both authenticated and encrypted using packet +protection keys. {{QUIC-TLS}} describes packet protection in detail. After +decryption, the plaintext consists of a sequence of frames, as described in +{{frames}}. + +## Connection ID {#connection-id} +Describe how to distinguish between client-generated and server-generated +connection IDs. + +## Packet Numbers {#packet-numbers} The packet number is a 64-bit unsigned number and is used as part of a cryptographic nonce for packet encryption. Each endpoint maintains a separate @@ -585,7 +601,6 @@ lowest outstanding packet number, the next packet uses a 16-bit or larger packet number encoding; whereas a 32-bit packet number is needed if packet 0x6AF0F7 is outstanding. - ### Initial Packet Number The initial value for packet number MUST be a 31-bit random number. That is, @@ -597,12 +612,54 @@ packet number. Once any packet has been acknowledged, subsequent packets can use a shorter packet number encoding. -## Frames and Frame Types {#frames} +## Handling Packets from Different Versions + +Between different versions the following things are guaranteed to remain +constant: + +* the location and size of the Flags field in both header forms, + +* the location of the HEADER_FORM bit in the Flags field in both header forms, -A Regular packet MUST contain at least one frame, and MAY contain multiple -frames and multiple frame types. Frames MUST fit within a single QUIC packet -and MUST NOT span a QUIC packet boundary. Each frame begins with a Frame Type -byte, indicating its type, followed by additional type-dependent fields: +* the location of the CONNECTION_ID bit in the Flags field in short headers, + +* the location and size of the Connection ID field in both header forms, + +* the location and value of the Version field in long headers, and + +* the location and value of the Packet Number field in long headers. + +Implementations MUST assume that an unsupported version uses an unknown packet +format. All other values MUST be ignored when processing a packet that contains +an unsupported version. + + +# Frames and Frame Types {#frames} + +The payload of cleartext packets and the plaintext after decryption of encrypted +packets consists of a sequence of frames, as shown in {{packet-frames}}. + +~~~ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Frame 1 (*) ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Frame 2 (*) ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Frame N (*) ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~~~ +{: #packet-frames title="Contents of Encrypted Payload"} + +Encrypted payload MUST contain at least one frame, and MAY contain multiple +frames and multiple frame types. + +Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet +boundary. Each frame begins with a Frame Type byte, indicating its type, +followed by additional type-dependent fields: ~~~ 0 1 2 3 @@ -634,92 +691,6 @@ document. | 0x80 - 0xff | STREAM | {{frame-stream}} | |------------------|--------------------|----------------------------| -## Version Negotiation Packet - -A Version Negotiation packet is only sent by the server, MUST have the VERSION -flag set, and MUST include the full 64-bit Connection ID. The remainder of the -Version Negotiation packet is a list of 32-bit versions which the server -supports, as shown below. - -~~~ - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Supported Version 1 (32) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Supported Version 2 (32) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Supported Version N (32) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~ -{: #version-negotiation-format title="Version Negotiation Packet"} - -A server that generates a version negotiation packet SHOULD include one of the -reserved version numbers (those following the pattern 0x?a?a?a?a). This ensures -that clients are able to correctly handle an unsupported version. - -The design of version negotiation permits a server to avoid maintaining state -for packets that it rejects in this fashion. However, when the server generates -a version negotiation packet, it cannot randomly generate a reserved version -number. This is because the server is required to include the same value in its -transport parameters (see {{version-validation}}). To avoid the selected -version number changing during connection establishment, the reserved version -can be generated as a function of values that will be available to the server -when later generating its handshake packets. - -A pseudorandom function that takes client address information (IP and port) and -the client selected version as input would ensure that there is sufficient -variability in the values that a server uses. - -A client MAY send a packet using a reserved version number. This can be used to -solicit a list of supported versions from a server. - - -## Public Reset Packet - -A Public Reset packet MUST have the PUBLIC_RESET flag set, and MUST include the -full 64-bit connection ID. The content of the Public Reset packet is TBD. - -~~~ - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Public Reset Proof (*) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~ -{: #public-reset-format title="Public Reset Packet"} - -A Public Reset packet is used to abruptly terminate communications. Public -Reset is provided as an option of last resort for endpoints that do not have -access to the state of a connection. This is intended for use by an endpoint -that has lost state (for example, through a crash or outage), or middleboxes -that wish to indicate that a path is no longer usable. - -Endpoints that wish to indicate fatal errors with a connection MUST use a -CONNECTION_CLOSE frame in preference to Public Reset if they have sufficient -state to do so. - -Whether the Public Reset Proof field is included in a Public Reset packet -depends on the entity that generates the packet. - -A Public Reset packet sent by an endpoint indicates that it does not have the -state necessary to continue with a connection. In this case, the endpoint will -include the fields that prove that it originally participated in the connection -(see {{public-reset-proof}} for details). - -Upon receipt of a Public Reset packet that contains a valid proof, an endpoint -MUST tear down state associated with the connection. The endpoint MUST then -cease sending packets on the connection and SHOULD discard any subsequent -packets that arrive. A Public Reset that does not contain a valid proof MUST be -ignored. - - -### Public Reset Proof - -Details to be added. - # Life of a Connection From f1e1cfc77ab0c0c66b6c058a148ca36514f8ecdd Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 14:27:36 -0800 Subject: [PATCH 03/13] Connection ID added. --- draft-ietf-quic-transport.md | 68 +++++++++++++++++++++++++++--------- 1 file changed, 52 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1cbf0fd2f2..2b1e3df5c6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -362,10 +362,12 @@ The first octet (octet 0) contains the following fields. are currently defined. * 01: Version Negotiation packet (see {{version-negotiation-packet}}.) * 02: Public Reset packet (see {{public-reset-packet}}.) - * 03: Server Cleartext packet (see {{cleartext-packet}}.) - * 04: Client Cleartext packet (see {{cleartext-packet}}.) - * 05: 0-RTT encrypted packet (see {{encrypted-packet}}.) - * 06: 1-RTT encrypted packet (see {{encrypted-packet}}.) + * 03: Client Cleartext packet (see {{cleartext-packet}}.) + * 04: Server Cleartext packet indicating successful handshake (see + {{cleartext-packet}}.) + * 05: Other Server Cleartext packet (see {{cleartext-packet}}.) + * 06: 0-RTT Encrypted packet (see {{encrypted-packet}}.) + * 07: 1-RTT Encrypted packet (see {{encrypted-packet}}.) The remainder of the packet layout is the same regardless of type, but the semantics of the fields are specific to each type (see corresponding sections @@ -521,32 +523,48 @@ Details to be added. ## Cleartext Packets {#cleartext-packet} Cleartext packets are sent during the handshake prior to key negotiation. A -server cleartext packet contains: +client Cleartext packet contains: -* Octet 0: 0x83 (Flags indicating Long header and server cleartext packet type) +* Octet 0: 0x83 (Flags indicating long header and client Cleartext packet type) +* Octets 1-8: Connection ID (randomly chosen) +* Octets 9-12: Packet number (low 4 octets, starts at a random 31-bit value) +* Octets 13-16: Version +* Octets 17+: Payload + +A server Cleartext packet indicating a successful handshake contains: + +* Octet 0: 0x84 (Flags indicating Long header and appropriate server Cleartext + packet type) * Octets 1-8: Connection ID (server-selected value) * Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) * Octets 13-16: Version (echoed) * Octets 17+: Payload -A client cleartext packet contains: -* Octet 0: 0x84 (Flags indicating long header and client cleartext packet type) -* Octets 1-8: Connection ID (randomly chosen) -* Octets 9-12: Packet number (low 4 octets, starts at a random 31-bit value) -* Octets 13-16: Version +Other server Cleartext packets contain: + +* Octet 0: 0x85 (Flags indicating Long header and appropriate server Cleartext + packet type) +* Octets 1-8: Connection ID (client-selected value) +* Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) +* Octets 13-16: Version (echoed) * Octets 17+: Payload + The client MUST choose a random value and use it as the Connection ID until the server replies with a server-selected Connection ID. The client's Connection ID -is a suggestion to the server, as described further in {{connection-id}}. The -payload of cleartext packets contains frames, as described in {{frames}}. +is a suggestion to the server, as described further in {{connection-id}}. A +server may respond to a client Cleartext packet with one of the two server +Cleartext packets, using the server-selected Connection ID on only the final +Cleartext packet that indicates successful handshake completion. + +The payload of Cleartext packets contains frames, as described in {{frames}}. ## Encrypted Packets {#encrypted-packet} Packets encrypted with either 0-RTT or 1-RTT keys may be sent with long headers. Different packet types explicitly indicate the encryption level for ease of decryption. These packets contain: -* Octet 0: 0x85 or 0x86 (Flags indicating long header and one of the two +* Octet 0: 0x86 or 0x87 (Flags indicating long header and one of the two encrypted packet types) * Octets 1-8: Connection ID (client or server-selected, see {{connectionid}}) * Octets 9-12: Packet Number (low 4 octets) @@ -559,8 +577,26 @@ decryption, the plaintext consists of a sequence of frames, as described in {{frames}}. ## Connection ID {#connection-id} -Describe how to distinguish between client-generated and server-generated -connection IDs. +QUIC connections are identified by their 64-bit Connection ID. All long headers +contain a Connection ID. Short headers indicate the presence of a Connection ID +using the CONNECTION_ID flag. When present, the Connection ID is in the same +location in all packet headers, making it straightforward for middleboxes, such +as load balancers, to locate and use it. + +When a connection is initiated, the client MUST choose a random value and use it +as the Connection ID in all Cleartext packets and all 0-RTT Encrypted +packets. The client's Connection ID is a suggestion to the server. The server +echoes this value in all packets until the handshake is successful (see +{{QUIC-TLS}}. In its final successful handshake completion packet, the server +MUST use a server-selected Connection ID. All subsequent packets from the server +MUST contain this value. + +When a server's successful handshake completion packet is received by the +client, it MUST switch to using the server-selected Connection ID for all +subsequent packets. + +The Connection ID in all packets following a successful handshake---all 1-RTT +encrypted packets---is the server-selected value. ## Packet Numbers {#packet-numbers} From 31844de01c850ea0f1c3532a172d715712297d81 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 14:46:11 -0800 Subject: [PATCH 04/13] Two key phases for long headers --- draft-ietf-quic-transport.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2b1e3df5c6..58b4ed9cf5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -325,7 +325,7 @@ describing the value of fields. QUIC packet headers can be separated into long and short headers. Long headers are expected to be used for the initial phase of the connection and are used for version negotiation, connection establishment, 0-RTT, and public reset -packets. Short headers are minimal version-specific headers, which MAY be used +packets. Short headers are minimal version-specific headers, which can be used after version negotiation and 1-RTT keys are established, and MUST NOT be used earlier. @@ -367,7 +367,8 @@ The first octet (octet 0) contains the following fields. {{cleartext-packet}}.) * 05: Other Server Cleartext packet (see {{cleartext-packet}}.) * 06: 0-RTT Encrypted packet (see {{encrypted-packet}}.) - * 07: 1-RTT Encrypted packet (see {{encrypted-packet}}.) + * 07: 1-RTT Encrypted packet with key phase 0 (see {{encrypted-packet}}.) + * 08: 1-RTT Encrypted packet with key phase 1 (see {{encrypted-packet}}.) The remainder of the packet layout is the same regardless of type, but the semantics of the fields are specific to each type (see corresponding sections @@ -395,8 +396,8 @@ assigned a packet number by the sender, as described further in +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` -The short header is used after the version and 1-RTT keys are negotiated. This -header has the following version-independent fields: +The short header can be used after the version and 1-RTT keys are negotiated. +This header has the following version-independent fields: * Octet 0: Flags * Bit 0 (0x80): HEADER_FORM, set to 0 for short headers. * Bit 1: CONNECTION_ID. Indicates presence of Connection ID field following @@ -407,8 +408,8 @@ The remainder of the short header is defined to be specific to a version. In this version, it contains: * Octet 0: Flags * Bit 2: KEY_PHASE. Used by the QUIC packet protection to identify - the correct packet protection keys after the 1-RTT keys are initially - established. See {{QUIC-TLS}}. + the correct packet protection keys after the 1-RTT keys are established. + See {{QUIC-TLS}} for more details. * Bit 3-7: Packet Type, indicating one of 32 packet types. The following types are currently defined. * 01: 1-RTT packet (packet number size = 1) @@ -564,13 +565,18 @@ The payload of Cleartext packets contains frames, as described in {{frames}}. Packets encrypted with either 0-RTT or 1-RTT keys may be sent with long headers. Different packet types explicitly indicate the encryption level for ease of decryption. These packets contain: -* Octet 0: 0x86 or 0x87 (Flags indicating long header and one of the two - encrypted packet types) +* Octet 0: 0x86, 0x87 or 0x88 (Flags indicating long header and an encrypted + packet type) * Octets 1-8: Connection ID (client or server-selected, see {{connectionid}}) * Octets 9-12: Packet Number (low 4 octets) * Octets 13-16: Version * Octets 17+: Encrypted Payload (see {{encrypted-payload}}.) +A flags octet of 0x86 indicates a 0-RTT packet. Key phases are used by the QUIC +packet protection to identify the correct packet protection keys after the 1-RTT +keys are established. The default initial value key phase is 0. See {{QUIC-TLS}} +for more details. + The encrypted payload is both authenticated and encrypted using packet protection keys. {{QUIC-TLS}} describes packet protection in detail. After decryption, the plaintext consists of a sequence of frames, as described in From d84cdbcde0a5f409655d76ec35f884e3981afe81 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 14:51:16 -0800 Subject: [PATCH 05/13] Nits. --- 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 58b4ed9cf5..3b8511cf48 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -427,8 +427,7 @@ client packet of an unsupported version. It uses a long header and contains: * Octet 0: 0x81 (Flags indicating long header and Version Negotiation packet type) -* Octets 1-8: Connection ID (server-selected value, may be used in a subsequent - connection to reach the same server) +* Octets 1-8: Connection ID (echoed) * Octets 9-12: Proof (first 4 octets of client-selected connection ID) * Octets 13-16: Version (echoed) * Octets 17+: Payload (version list, containing 0 or more acceptable versions) @@ -484,10 +483,11 @@ outage). A server that wishes to indicate fatal errors with a connection MUST use a CONNECTION_CLOSE frame in preference to Public Reset if it has sufficient state to do so. -A public reset packet contains: +A Public Reset packet contains: * Octet 0: 0x82 (Flags indicating long header and Public Reset packet type) -* Octets 1-12: Echoed data (octets 1-12 of received packet) +* Octets 1-8: Echoed data (octets 1-8 of received packet) +* Octets 9-12: Echoed data (octets 9-12 of received packet) * Octets 13-16: Version (server version) * Octets 17+: Public Reset Proof (optional, TBD) @@ -545,7 +545,7 @@ Other server Cleartext packets contain: * Octet 0: 0x85 (Flags indicating Long header and appropriate server Cleartext packet type) -* Octets 1-8: Connection ID (client-selected value) +* Octets 1-8: Connection ID (echoed) * Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) * Octets 13-16: Version (echoed) * Octets 17+: Payload From 0df55bfa0553d82b4f173ade04964b91d3819a2a Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 16:39:21 -0800 Subject: [PATCH 06/13] Clarifications. --- draft-ietf-quic-transport.md | 50 +++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 21 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3b8511cf48..0187c8d36a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -341,7 +341,7 @@ earlier. + Connection ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Packet Number / Proof | +| Packet Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -356,27 +356,35 @@ inefficient, long headers MAY be used for 1-RTT packets. The long form allows for special packets, such as the version negotiation and the public reset packets to be represented in this uniform fixed-length packet format. -The first octet (octet 0) contains the following fields. +The Flags field (octet 0) contains the following version-independent fields. * Bit 0 (0x80): HEADER_FORM, set to 1 for long headers. * Bits 1-7: Packet Type, indicating one of 128 packet types. The following types are currently defined. * 01: Version Negotiation packet (see {{version-negotiation-packet}}.) * 02: Public Reset packet (see {{public-reset-packet}}.) * 03: Client Cleartext packet (see {{cleartext-packet}}.) - * 04: Server Cleartext packet indicating successful handshake (see - {{cleartext-packet}}.) + * 04: Server Cleartext End-of-Handshake packet (see {{cleartext-packet}}.) * 05: Other Server Cleartext packet (see {{cleartext-packet}}.) * 06: 0-RTT Encrypted packet (see {{encrypted-packet}}.) * 07: 1-RTT Encrypted packet with key phase 0 (see {{encrypted-packet}}.) * 08: 1-RTT Encrypted packet with key phase 1 (see {{encrypted-packet}}.) -The remainder of the packet layout is the same regardless of type, but the -semantics of the fields are specific to each type (see corresponding sections -for type-specific semantics.) +A long-header packet has the following version-independent fields: +* Octets 1-9: Connection ID +* Octets 10-14: Packet Number +* Octets 15-19: Version -Connection ID considerations are discussed in {{connection-id}}. Each packet is -assigned a packet number by the sender, as described further in -{{packet-number}}. +The remainder of the long-header packet is defined to be specific to a version. +In this version, the rest of the packet contains: +* Octets 20+: Payload + +The packet layout is the same for all long-header packet types, but the +semantics of the fields are specific to each packet type. Type-specific +semantics are described in {{version-negotiation-packet}}, +{{public-reset-packet}}, {{cleartext-packet}}, and {{encrypted-packet}}. + +Connection ID considerations are discussed in {{connection-id}} and packet +number considerations in {{packet-number}}. ## Short Header @@ -420,7 +428,7 @@ this version, it contains: * Remainder of this packet: Encrypted Payload (see {{encrypted-payload}}.) -## Version Negotiation Packet {version-negotiation-packet} +## Version Negotiation Packet {#version-negotiation-packet} A Version Negotiation packet is sent by only the server and is a response to a client packet of an unsupported version. It uses a long header and contains: @@ -428,7 +436,7 @@ client packet of an unsupported version. It uses a long header and contains: * Octet 0: 0x81 (Flags indicating long header and Version Negotiation packet type) * Octets 1-8: Connection ID (echoed) -* Octets 9-12: Proof (first 4 octets of client-selected connection ID) +* Octets 9-12: Packet Number (echoed) * Octets 13-16: Version (echoed) * Octets 17+: Payload (version list, containing 0 or more acceptable versions) @@ -524,7 +532,7 @@ Details to be added. ## Cleartext Packets {#cleartext-packet} Cleartext packets are sent during the handshake prior to key negotiation. A -client Cleartext packet contains: +Client Cleartext packet contains: * Octet 0: 0x83 (Flags indicating long header and client Cleartext packet type) * Octets 1-8: Connection ID (randomly chosen) @@ -532,7 +540,7 @@ client Cleartext packet contains: * Octets 13-16: Version * Octets 17+: Payload -A server Cleartext packet indicating a successful handshake contains: +A Server Cleartext End-of-Handshake packet contains: * Octet 0: 0x84 (Flags indicating Long header and appropriate server Cleartext packet type) @@ -541,7 +549,7 @@ A server Cleartext packet indicating a successful handshake contains: * Octets 13-16: Version (echoed) * Octets 17+: Payload -Other server Cleartext packets contain: +Other Server Cleartext packets contain: * Octet 0: 0x85 (Flags indicating Long header and appropriate server Cleartext packet type) @@ -550,15 +558,15 @@ Other server Cleartext packets contain: * Octets 13-16: Version (echoed) * Octets 17+: Payload - The client MUST choose a random value and use it as the Connection ID until the -server replies with a server-selected Connection ID. The client's Connection ID -is a suggestion to the server, as described further in {{connection-id}}. A -server may respond to a client Cleartext packet with one of the two server -Cleartext packets, using the server-selected Connection ID on only the final -Cleartext packet that indicates successful handshake completion. +server replies with a server-selected Connection ID. Server-selected Connection +IDs are used after a successful handshake, cleanly distinguishing packets that +use them from packets using client-selected Connection IDs. All packets +including and following a Server Cleartext End-of-Handshake packet use a +server-selected Connection ID, as described in {{connection-id}}. The payload of Cleartext packets contains frames, as described in {{frames}}. +(TODO: Add hash before frames.) ## Encrypted Packets {#encrypted-packet} From 644c2c7dfbfd398c6d9c41b90dc36981f1f1575d Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 16:44:12 -0800 Subject: [PATCH 07/13] Public reset proof not optional. --- draft-ietf-quic-transport.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0187c8d36a..d2462415de 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -497,7 +497,7 @@ A Public Reset packet contains: * Octets 1-8: Echoed data (octets 1-8 of received packet) * Octets 9-12: Echoed data (octets 9-12 of received packet) * Octets 13-16: Version (server version) -* Octets 17+: Public Reset Proof (optional, TBD) +* Octets 17+: Public Reset Proof For a client that sends a connection ID on every packet, a Public Reset packet received in response can be simply interpreted as: @@ -507,23 +507,19 @@ packet received in response can be simply interpreted as: on the packet number size used by the client, followed by 0, 2, or 3 subsequent bytes from the client packet. * Octets 13-16: Version (server version) -* Octets 17+: Public Reset Proof (optional, TBD) +* Octets 17+: Public Reset Proof -Whether the Public Reset Proof field is included in a Public Reset packet -depends on the entity that generates the packet. - -A Public Reset packet sent by an endpoint indicates that it does not have the -state necessary to continue with a connection. In this case, the endpoint will +A Public Reset packet sent by a server indicates that it does not have the +state necessary to continue with a connection. In this case, the server will include the fields that prove that it originally participated in the connection (see {{public-reset-proof}} for details). -Upon receipt of a Public Reset packet that contains a valid proof, an endpoint -MUST tear down state associated with the connection. The endpoint MUST then +Upon receipt of a Public Reset packet that contains a valid proof, a client +MUST tear down state associated with the connection. The client MUST then cease sending packets on the connection and SHOULD discard any subsequent packets that arrive. A Public Reset that does not contain a valid proof MUST be ignored. - ### Public Reset Proof Details to be added. From c3dedf335c8a280019abbdac8b4240aa63c37796 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 7 Mar 2017 12:28:16 +1100 Subject: [PATCH 08/13] Fix formatting of long- and short-form headers --- draft-ietf-quic-transport.md | 174 +++++++++++++++++++++++------------ 1 file changed, 116 insertions(+), 58 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d2462415de..f6a3e9a562 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -356,35 +356,63 @@ inefficient, long headers MAY be used for 1-RTT packets. The long form allows for special packets, such as the version negotiation and the public reset packets to be represented in this uniform fixed-length packet format. -The Flags field (octet 0) contains the following version-independent fields. -* Bit 0 (0x80): HEADER_FORM, set to 1 for long headers. -* Bits 1-7: Packet Type, indicating one of 128 packet types. The following types - are currently defined. - * 01: Version Negotiation packet (see {{version-negotiation-packet}}.) - * 02: Public Reset packet (see {{public-reset-packet}}.) - * 03: Client Cleartext packet (see {{cleartext-packet}}.) - * 04: Server Cleartext End-of-Handshake packet (see {{cleartext-packet}}.) - * 05: Other Server Cleartext packet (see {{cleartext-packet}}.) - * 06: 0-RTT Encrypted packet (see {{encrypted-packet}}.) - * 07: 1-RTT Encrypted packet with key phase 0 (see {{encrypted-packet}}.) - * 08: 1-RTT Encrypted packet with key phase 1 (see {{encrypted-packet}}.) - -A long-header packet has the following version-independent fields: -* Octets 1-9: Connection ID -* Octets 10-14: Packet Number -* Octets 15-19: Version - -The remainder of the long-header packet is defined to be specific to a version. -In this version, the rest of the packet contains: -* Octets 20+: Payload +A long header contains the following fields: + +Header Form: + +: The most significant bit (0x80) of the first octet (octet 0) is set to 1 for + long headers and 0 for short headers. + +Long Packet Type: + +: The remaining seven bits of octet 0 of a long packet is the packet type. This + field can indicate one of 128 packet types. The types specified for this + version are listed in {{long-packet-types}}. + +Connection ID: + +: Octets 1 through 8 include a connection ID. {{connection-id}} describes the + use of this field in more details. + +Packet Number: + +: Octets 9 to 12 contain a packet number. {{packet-numbers} describes the use of + packet numbers. + +Version: + +: Octets 13 to 16 contain the selected protocol version. This field indicates + which version of QUIC is in use and determines how the some protocol fields + are interpreted. + +Payload: + +: Octets from 17 onwards are the payload of the packet. + +The following packet types are defined: + +| Type | Name | Section | +|:-----|:-----------------------|:-------------------------------| +| 01 | Version Negotiation | {{version-negotiation-packet}} | +| 02 | Public Reset | {{public-reset-packet}} | +| 03 | Client Cleartext | {{cleartext-packet}} | +| 04 | Final Server Cleartext | {{cleartext-packet}} | +| 05 | Other Server Cleartext | {{cleartext-packet}} | +| 06 | 0-RTT Encrypted | {{encrypted-packet}} | +| 07 | 1-RTT Encrypted (key phase 0) | {{encrypted-packet}} | +| 08 | 1-RTT Encrypted (key phase 1) | {{encrypted-packet}} | +{: #long-packet-types title="Long Header Packet Types"} + +The type, connection ID, packet number and version fields of a long header +packet are version independent. The payload is specific to a version. See +{{version-specific}} for details on how packets from different versions of QUIC +are interpreted. The packet layout is the same for all long-header packet types, but the -semantics of the fields are specific to each packet type. Type-specific +semantics of the fields are specific to each packet type. Type-specific semantics are described in {{version-negotiation-packet}}, {{public-reset-packet}}, {{cleartext-packet}}, and {{encrypted-packet}}. -Connection ID considerations are discussed in {{connection-id}} and packet -number considerations in {{packet-number}}. ## Short Header @@ -405,27 +433,54 @@ number considerations in {{packet-number}}. ``` The short header can be used after the version and 1-RTT keys are negotiated. -This header has the following version-independent fields: -* Octet 0: Flags - * Bit 0 (0x80): HEADER_FORM, set to 0 for short headers. - * Bit 1: CONNECTION_ID. Indicates presence of Connection ID field following - the Flags byte. -* Octets 1-8: Connection ID (optional) - -The remainder of the short header is defined to be specific to a version. In -this version, it contains: -* Octet 0: Flags - * Bit 2: KEY_PHASE. Used by the QUIC packet protection to identify - the correct packet protection keys after the 1-RTT keys are established. - See {{QUIC-TLS}} for more details. - * Bit 3-7: Packet Type, indicating one of 32 packet types. The following types - are currently defined. - * 01: 1-RTT packet (packet number size = 1) - * 02: 1-RTT packet (packet number size = 2) - * 03: 1-RTT packet (packet number size = 4) -* Octets 1 (if C bit is 0) or 8 (otherwise) onwards: Packet Number (lower 8, - 16, or 32 bits) -* Remainder of this packet: Encrypted Payload (see {{encrypted-payload}}.) +This header form has the following fields: + +Header Form: + +: The most significant bit (0x80) of the first octet (octet 0) of a packet is the header form. + This bit is set to 0 for the short header. + +Connection ID Flag: + +: The second bit (0x40) of octet 0 indicates whether the connection ID field + is present. If set to 1, then the connection ID field is present; if set to + 0, the connection ID field is zero length. + +Key Phase Bit: + +: The third bit (0x20) of octet 0 indicates the key phase, which allows a + recipient of a packet to identify the packet protection keys that are used to + protect the packet. See {{QUIC-TLS}} for details. + +Short Packet Type: + +: The remaining 5 bits of octet 0 include one of 32 packet types. + {{short-packet-types}} lists the types that are defined for short packets. + +Connection ID: + +: If the Connection ID Flag is set, a connection ID occupies octets 1 through 8 + of the packet. See {{connection-id}} for more details. + +Packet Number: + +: The length of the packet number field depends on the packet type. This field + can be 1, 2 or 4 octets long depending on the short packet type. + +Encrypted Payload: + +: Packets with a short header always include a 1-RTT protected payload. + +The packet type in a short header currently determines only the size of the +packet number field. Additional types can be used to signal the presence of +other fields. + +| Type | Packet Number Size | +|:-----|:-----------------------| +| 01 | 1 octet | +| 02 | 2 octets | +| 03 | 4 octets | +{: #short-packet-types title="Short Header Packet Types"} ## Version Negotiation Packet {#version-negotiation-packet} @@ -433,7 +488,7 @@ this version, it contains: A Version Negotiation packet is sent by only the server and is a response to a client packet of an unsupported version. It uses a long header and contains: -* Octet 0: 0x81 (Flags indicating long header and Version Negotiation packet +* Octet 0: 0x81 (Flags indicating long header and Version Negotiation packet type) * Octets 1-8: Connection ID (echoed) * Octets 9-12: Packet Number (echoed) @@ -493,7 +548,7 @@ state to do so. A Public Reset packet contains: -* Octet 0: 0x82 (Flags indicating long header and Public Reset packet type) +* Octet 0: 0x82 (Flags indicating long header and Public Reset packet type) * Octets 1-8: Echoed data (octets 1-8 of received packet) * Octets 9-12: Echoed data (octets 9-12 of received packet) * Octets 13-16: Version (server version) @@ -527,7 +582,7 @@ Details to be added. ## Cleartext Packets {#cleartext-packet} -Cleartext packets are sent during the handshake prior to key negotiation. A +Cleartext packets are sent during the handshake prior to key negotiation. A Client Cleartext packet contains: * Octet 0: 0x83 (Flags indicating long header and client Cleartext packet type) @@ -538,7 +593,7 @@ Client Cleartext packet contains: A Server Cleartext End-of-Handshake packet contains: -* Octet 0: 0x84 (Flags indicating Long header and appropriate server Cleartext +* Octet 0: 0x84 (Flags indicating Long header and appropriate server Cleartext packet type) * Octets 1-8: Connection ID (server-selected value) * Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) @@ -547,7 +602,7 @@ A Server Cleartext End-of-Handshake packet contains: Other Server Cleartext packets contain: -* Octet 0: 0x85 (Flags indicating Long header and appropriate server Cleartext +* Octet 0: 0x85 (Flags indicating Long header and appropriate server Cleartext packet type) * Octets 1-8: Connection ID (echoed) * Octets 9-12: Packet Number (low 4 octets, random 31-bit initial value) @@ -564,17 +619,18 @@ server-selected Connection ID, as described in {{connection-id}}. The payload of Cleartext packets contains frames, as described in {{frames}}. (TODO: Add hash before frames.) + ## Encrypted Packets {#encrypted-packet} Packets encrypted with either 0-RTT or 1-RTT keys may be sent with long headers. Different packet types explicitly indicate the encryption level for ease of decryption. These packets contain: -* Octet 0: 0x86, 0x87 or 0x88 (Flags indicating long header and an encrypted +* Octet 0: 0x86, 0x87 or 0x88 (Flags indicating long header and an encrypted packet type) -* Octets 1-8: Connection ID (client or server-selected, see {{connectionid}}) +* Octets 1-8: Connection ID (client or server-selected, see {{connection-id}}) * Octets 9-12: Packet Number (low 4 octets) * Octets 13-16: Version -* Octets 17+: Encrypted Payload (see {{encrypted-payload}}.) +* Octets 17+: Encrypted Payload A flags octet of 0x86 indicates a 0-RTT packet. Key phases are used by the QUIC packet protection to identify the correct packet protection keys after the 1-RTT @@ -586,10 +642,12 @@ protection keys. {{QUIC-TLS}} describes packet protection in detail. After decryption, the plaintext consists of a sequence of frames, as described in {{frames}}. + ## Connection ID {#connection-id} + QUIC connections are identified by their 64-bit Connection ID. All long headers contain a Connection ID. Short headers indicate the presence of a Connection ID -using the CONNECTION_ID flag. When present, the Connection ID is in the same +using the CONNECTION_ID flag. When present, the Connection ID is in the same location in all packet headers, making it straightforward for middleboxes, such as load balancers, to locate and use it. @@ -603,10 +661,10 @@ MUST contain this value. When a server's successful handshake completion packet is received by the client, it MUST switch to using the server-selected Connection ID for all -subsequent packets. +subsequent packets. -The Connection ID in all packets following a successful handshake---all 1-RTT -encrypted packets---is the server-selected value. +The Connection ID in all packets following a successful handshake - all 1-RTT +encrypted packets - is the server-selected value. ## Packet Numbers {#packet-numbers} @@ -658,7 +716,7 @@ packet number. Once any packet has been acknowledged, subsequent packets can use a shorter packet number encoding. -## Handling Packets from Different Versions +## Handling Packets from Different Versions {#version-specific} Between different versions the following things are guaranteed to remain constant: From d37a977eca0bb8f81b5fbc19f88c2a823a815cc8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 7 Mar 2017 12:44:38 +1100 Subject: [PATCH 09/13] Add version specific fields to short form --- draft-ietf-quic-transport.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f6a3e9a562..49f815ec6c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -403,10 +403,10 @@ The following packet types are defined: | 08 | 1-RTT Encrypted (key phase 1) | {{encrypted-packet}} | {: #long-packet-types title="Long Header Packet Types"} -The type, connection ID, packet number and version fields of a long header -packet are version independent. The payload is specific to a version. See -{{version-specific}} for details on how packets from different versions of QUIC -are interpreted. +The header form, long packet type, connection ID, packet number and version +fields of a long header packet are version independent. The payload is specific +to a version. See {{version-specific}} for details on how packets from +different versions of QUIC are interpreted. The packet layout is the same for all long-header packet types, but the semantics of the fields are specific to each packet type. Type-specific @@ -437,14 +437,14 @@ This header form has the following fields: Header Form: -: The most significant bit (0x80) of the first octet (octet 0) of a packet is the header form. - This bit is set to 0 for the short header. +: The most significant bit (0x80) of the first octet (octet 0) of a packet is + the header form. This bit is set to 0 for the short header. Connection ID Flag: -: The second bit (0x40) of octet 0 indicates whether the connection ID field - is present. If set to 1, then the connection ID field is present; if set to - 0, the connection ID field is zero length. +: The second bit (0x40) of octet 0 indicates whether the connection ID field is + present. If set to 1, then the connection ID field is present; if set to 0, + the connection ID field is zero length. Key Phase Bit: @@ -482,6 +482,11 @@ other fields. | 03 | 4 octets | {: #short-packet-types title="Short Header Packet Types"} +The header form, connection ID flag and connection ID of a short header packet +are version independent. The remaining fields are specific to the selected QUIC +version. See {{version-specific}} for details on how packets from different +versions of QUIC are interpreted. + ## Version Negotiation Packet {#version-negotiation-packet} From a5e65dae63efaab5936d2357fdaba51a5873fd3e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 6 Mar 2017 17:53:49 -0800 Subject: [PATCH 10/13] Nits. --- 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 49f815ec6c..d6470160da 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -376,8 +376,8 @@ Connection ID: Packet Number: -: Octets 9 to 12 contain a packet number. {{packet-numbers} describes the use of - packet numbers. +: Octets 9 to 12 contain a packet number. {{packet-numbers} describes the use + of packet numbers. Version: @@ -404,9 +404,9 @@ The following packet types are defined: {: #long-packet-types title="Long Header Packet Types"} The header form, long packet type, connection ID, packet number and version -fields of a long header packet are version independent. The payload is specific -to a version. See {{version-specific}} for details on how packets from -different versions of QUIC are interpreted. +fields of a long header packet are version independent. The rest of the packet +is specific to a version. See {{version-specific}} for details on how packets +from different versions of QUIC are interpreted. The packet layout is the same for all long-header packet types, but the semantics of the fields are specific to each packet type. Type-specific From da76d3a497bf1cd68057dced0f65cc8f53a3697e Mon Sep 17 00:00:00 2001 From: Brian Trammell Date: Tue, 7 Mar 2017 09:48:40 +0100 Subject: [PATCH 11/13] reapply packet number echo to full new header branch --- draft-ietf-quic-transport.md | 50 +++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d6470160da..e7abbbdceb 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -376,7 +376,7 @@ Connection ID: Packet Number: -: Octets 9 to 12 contain a packet number. {{packet-numbers} describes the use +: Octets 9 to 12 contain a packet number. {{packet-numbers}} describes the use of packet numbers. Version: @@ -423,11 +423,13 @@ semantics are described in {{version-negotiation-packet}}, |0|C|K| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | -+ Connection ID (optional) + ++ [Connection ID] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (1/2/4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| [Packet Number Echo (1/2/4)] | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` @@ -465,7 +467,13 @@ Connection ID: Packet Number: : The length of the packet number field depends on the packet type. This field - can be 1, 2 or 4 octets long depending on the short packet type. + can be 1, 2 or 4 octets long depending on the short packet type; see {{packet-numbers}}. + +Packet Number Echo: + +: The packet number echo field, if present, contains the highest packet number +seen in the opposite direction. This field can be absent, or 1, 2, or 4 octets +long depending on the short packet type; see {{packet-number-echo}}. Encrypted Payload: @@ -475,11 +483,14 @@ The packet type in a short header currently determines only the size of the packet number field. Additional types can be used to signal the presence of other fields. -| Type | Packet Number Size | -|:-----|:-----------------------| -| 01 | 1 octet | -| 02 | 2 octets | -| 03 | 4 octets | +| Type | Packet Number Size | Packet Number Echo Size | +|:-----|:-----------------------|-------------------------| +| 01 | 1 octet | not present | +| 02 | 2 octets | not present | +| 03 | 4 octets | not present | +| 05 | 1 octet | 1 octet | +| 06 | 2 octets | 2 octets | +| 07 | 4 octets | 4 octets | {: #short-packet-types title="Short Header Packet Types"} The header form, connection ID flag and connection ID of a short header packet @@ -686,7 +697,7 @@ CONNECTION_CLOSE frame with the error code QUIC_SEQUENCE_NUMBER_LIMIT_REACHED To reduce the number of bits required to represent the packet number over the wire, only the least significant bits of the packet number are transmitted over -the wire, up to 48 bits. The actual packet number for each packet is +the wire, up to 32 bits. The actual packet number for each packet is reconstructed at the receiver based on the largest packet number received on a successfully authenticated packet. @@ -720,6 +731,27 @@ The first set of packets sent by an endpoint MUST include the low 32-bits of the packet number. Once any packet has been acknowledged, subsequent packets can use a shorter packet number encoding. +### Packet Number Echo {#packet-number-echo} + +If present, the Packet Number Echo field contains the least significant 8, 16, +or 32 bits of the highest packet number seen in the opposite direction before +this packet was sent. This allows devices along the path to estimate round-trip +times and observe indications of loss, for passive performance measurement of +QUIC flows equivalent to present techniques using TCP sequence and +acknowledgement numbers and/or timestamps. + +The Packet Number Echo field SHOULD be present on 1-RTT packets containing at +least one ACK frame (see {{frame-ack}}). For efficiency's sake, it MAY be +omitted if a 1-RTT packet containing an ACK frame has already been sent during a +time interval equal to the sender's current estimate of the RTT. + +Since the Packet Number and Packet Number Echo fielda are of the same size, a +sender sending a packet containing a Packet Number Echo determines the size to use as follows: + +- Let `SIZE_P` be the size of the packet number to be sent, as determined in {{packet-numbers}} above. +- Let `SIZE_E` be the size of the packet number sent in the packet whose packet number is to be echoed. +- Let `SIZE_S` be the size of the packet number dictated by the difference between the packet number echo to be sent and the last packet number echo sent; if no packet number echo has yet been sent, then let SIZE_S be 4. +- Choose the packet number and packet number echo size to send as `max(SIZE_P, SIZE_E, SIZE_S). ## Handling Packets from Different Versions {#version-specific} From ea49db5b4f95d2cefb2e3c67bc9c2dfd1c7d0e23 Mon Sep 17 00:00:00 2001 From: Brian Trammell Date: Tue, 7 Mar 2017 14:20:29 +0100 Subject: [PATCH 12/13] reflow for 80col --- draft-ietf-quic-transport.md | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e7abbbdceb..a5345a06d9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -466,8 +466,9 @@ Connection ID: Packet Number: -: The length of the packet number field depends on the packet type. This field - can be 1, 2 or 4 octets long depending on the short packet type; see {{packet-numbers}}. +: The length of the packet number field depends on the packet type. + This field can be 1, 2 or 4 octets long depending on the short packet type; + see {{packet-numbers}}. Packet Number Echo: @@ -746,12 +747,18 @@ omitted if a 1-RTT packet containing an ACK frame has already been sent during a time interval equal to the sender's current estimate of the RTT. Since the Packet Number and Packet Number Echo fielda are of the same size, a -sender sending a packet containing a Packet Number Echo determines the size to use as follows: - -- Let `SIZE_P` be the size of the packet number to be sent, as determined in {{packet-numbers}} above. -- Let `SIZE_E` be the size of the packet number sent in the packet whose packet number is to be echoed. -- Let `SIZE_S` be the size of the packet number dictated by the difference between the packet number echo to be sent and the last packet number echo sent; if no packet number echo has yet been sent, then let SIZE_S be 4. -- Choose the packet number and packet number echo size to send as `max(SIZE_P, SIZE_E, SIZE_S). +sender sending a packet containing a Packet Number Echo determines the size to +use as follows: + +- Let `SIZE_P` be the size of the packet number to be sent, as determined in + {{packet-numbers}} above. +- Let `SIZE_E` be the size of the packet number sent in the packet whose packet + number is to be echoed. +- Let `SIZE_S` be the size of the packet number dictated by the difference + between the packet number echo to be sent and the last packet number echo + sent; if no packet number echo has yet been sent, then let SIZE_S be 4. +- Choose the packet number and packet number echo size to send as `max(SIZE_P, + SIZE_E, SIZE_S). ## Handling Packets from Different Versions {#version-specific} From 03139cd347b2d24d9b3d13c1945131056d8b1951 Mon Sep 17 00:00:00 2001 From: Brian Trammell Date: Tue, 7 Mar 2017 14:24:27 +0100 Subject: [PATCH 13/13] trim trailing whitespace --- 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 a5345a06d9..5c55986f72 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -467,7 +467,7 @@ Connection ID: Packet Number: : The length of the packet number field depends on the packet type. - This field can be 1, 2 or 4 octets long depending on the short packet type; + This field can be 1, 2 or 4 octets long depending on the short packet type; see {{packet-numbers}}. Packet Number Echo: