draft-ietf-quic-invariants-latest.txt		draft-ietf-quic-invariants-auth48.txt
	skipping to change at page 2, line 7 ¶		skipping to change at line 45 ¶
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. An Extremely Abstract Description of QUIC . . . . . . . . . . 2		1. An Extremely Abstract Description of QUIC
	2. Fixed Properties of All QUIC Versions . . . . . . . . . . . . 2		2. Fixed Properties of All QUIC Versions
	3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		3. Conventions and Definitions
	4. Notational Conventions . . . . . . . . . . . . . . . . . . . 3		4. Notational Conventions
	5. QUIC Packets . . . . . . . . . . . . . . . . . . . . . . . . 4		5. QUIC Packets
	5.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 4		5.1. Long Header
	5.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 5		5.2. Short Header
	5.3. Connection ID . . . . . . . . . . . . . . . . . . . . . . 6		5.3. Connection ID
	5.4. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.4. Version
	6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 6		6. Version Negotiation
	7. Security and Privacy Considerations . . . . . . . . . . . . . 8		7. Security and Privacy Considerations
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		8.1. Normative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References
	Appendix A. Incorrect Assumptions . . . . . . . . . . . . . . . 9		Appendix A. Incorrect Assumptions
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address
	1. An Extremely Abstract Description of QUIC		1. An Extremely Abstract Description of QUIC
	QUIC is a connection-oriented protocol between two endpoints. Those		QUIC is a connection-oriented protocol between two endpoints. Those
	endpoints exchange UDP datagrams. These UDP datagrams contain QUIC		endpoints exchange UDP datagrams. These UDP datagrams contain QUIC
	packets. QUIC endpoints use QUIC packets to establish a QUIC		packets. QUIC endpoints use QUIC packets to establish a QUIC
	connection, which is shared protocol state between those endpoints.		connection, which is shared protocol state between those endpoints.
	2. Fixed Properties of All QUIC Versions		2. Fixed Properties of All QUIC Versions
	skipping to change at page 4, line 13 ¶		skipping to change at line 147 ¶
	Figure 1 shows an example structure:		Figure 1 shows an example structure:
	Example Structure {		Example Structure {
	One-bit Field (1),		One-bit Field (1),
	7-bit Field with Fixed Value (7) = 61,		7-bit Field with Fixed Value (7) = 61,
	Arbitrary-Length Field (..),		Arbitrary-Length Field (..),
	Variable-Length Field (8..24),		Variable-Length Field (8..24),
	Repeated Field (8) ...,		Repeated Field (8) ...,
	}		}
	Figure 1: Example Format		Figure 1: Example Format
	5. QUIC Packets		5. QUIC Packets
	QUIC endpoints exchange UDP datagrams that contain one or more QUIC		QUIC endpoints exchange UDP datagrams that contain one or more QUIC
	packets. This section describes the invariant characteristics of a		packets. This section describes the invariant characteristics of a
	QUIC packet. A version of QUIC could permit multiple QUIC packets in		QUIC packet. A version of QUIC could permit multiple QUIC packets in
	a single UDP datagram, but the invariant properties only describe the		a single UDP datagram, but the invariant properties only describe the
	first packet in a datagram.		first packet in a datagram.
	QUIC defines two types of packet headers: long and short. Packets		QUIC defines two types of packet headers: long and short. Packets
	skipping to change at page 4, line 50 ¶		skipping to change at line 184 ¶
	Header Form (1) = 1,		Header Form (1) = 1,
	Version-Specific Bits (7),		Version-Specific Bits (7),
	Version (32),		Version (32),
	Destination Connection ID Length (8),		Destination Connection ID Length (8),
	Destination Connection ID (0..2040),		Destination Connection ID (0..2040),
	Source Connection ID Length (8),		Source Connection ID Length (8),
	Source Connection ID (0..2040),		Source Connection ID (0..2040),
	Version-Specific Data (..),		Version-Specific Data (..),
	}		}
	Figure 2: QUIC Long Header		Figure 2: QUIC Long Header
	A QUIC packet with a long header has the high bit of the first byte		A QUIC packet with a long header has the high bit of the first byte
	set to 1. All other bits in that byte are version specific.		set to 1. All other bits in that byte are version specific.
	The next four bytes include a 32-bit Version field. Versions are		The next four bytes include a 32-bit Version field. Versions are
	described in Section 5.4.		described in Section 5.4.
	The next byte contains the length in bytes of the Destination		The next byte contains the length in bytes of the Destination
	Connection ID field that follows it. This length is encoded as an		Connection ID field that follows it. This length is encoded as an
	8-bit unsigned integer. The Destination Connection ID field follows		8-bit unsigned integer. The Destination Connection ID field follows
	skipping to change at page 7, line 16 ¶		skipping to change at line 283 ¶
	Header Form (1) = 1,		Header Form (1) = 1,
	Unused (7),		Unused (7),
	Version (32) = 0,		Version (32) = 0,
	Destination Connection ID Length (8),		Destination Connection ID Length (8),
	Destination Connection ID (0..2040),		Destination Connection ID (0..2040),
	Source Connection ID Length (8),		Source Connection ID Length (8),
	Source Connection ID (0..2040),		Source Connection ID (0..2040),
	Supported Version (32) ...,		Supported Version (32) ...,
	}		}
	Figure 4: Version Negotiation Packet		Figure 4: Version Negotiation Packet
	Only the most significant bit of the first byte of a Version		Only the most significant bit of the first byte of a Version
	Negotiation packet has any defined value. The remaining 7 bits,		Negotiation packet has any defined value. The remaining 7 bits,
	labeled "Unused", can be set to any value when sending and MUST be		labeled "Unused", can be set to any value when sending and MUST be
	ignored on receipt.		ignored on receipt.
	After the Source Connection ID field, the Version Negotiation packet		After the Source Connection ID field, the Version Negotiation packet
	contains a list of Supported Version fields, each identifying a		contains a list of Supported Version fields, each identifying a
	version that the endpoint sending the packet supports. A Version		version that the endpoint sending the packet supports. A Version
	Negotiation packet contains no other fields. An endpoint MUST ignore		Negotiation packet contains no other fields. An endpoint MUST ignore
	skipping to change at page 8, line 42 ¶		skipping to change at line 357 ¶
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		8.2. Informative References
	[QUIC-TLS]		[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,		QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
	<https://www.rfc-editor.org/info/rfc9001>.		<https://www.rfc-editor.org/info/rfc9001>.
	[QUIC-TRANSPORT]		[QUIC-TRANSPORT]
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated		[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	skipping to change at page 9, line 23 ¶		skipping to change at line 385 ¶
	changeable when a new version is deployed.		changeable when a new version is deployed.
	This section lists a sampling of incorrect assumptions that might be		This section lists a sampling of incorrect assumptions that might be
	made about QUIC based on knowledge of QUIC version 1. Some of these		made about QUIC based on knowledge of QUIC version 1. Some of these
	statements are not even true for QUIC version 1. This is not an		statements are not even true for QUIC version 1. This is not an
	exhaustive list; it is intended to be illustrative only.		exhaustive list; it is intended to be illustrative only.
	*Any and all of the following statements can be false for a given		*Any and all of the following statements can be false for a given
	QUIC version:*		QUIC version:*
	o QUIC uses TLS [QUIC-TLS] and some TLS messages are visible on the		* QUIC uses TLS [QUIC-TLS], and some TLS messages are visible on the
	wire.		wire.
	o QUIC long headers are only exchanged during connection		* QUIC long headers are only exchanged during connection
	establishment.		establishment.
	o Every flow on a given 5-tuple will include a connection		* Every flow on a given 5-tuple will include a connection
	establishment phase.		establishment phase.
	o The first packets exchanged on a flow use the long header.		* The first packets exchanged on a flow use the long header.
	o The last packet before a long period of quiescence might be		* The last packet before a long period of quiescence might be
	assumed to contain only an acknowledgment.		assumed to contain only an acknowledgment.
	o QUIC uses an Authenticated Encryption with Associated Data (AEAD)		* QUIC uses an Authenticated Encryption with Associated Data (AEAD)
	function (AEAD_AES_128_GCM; see [RFC5116]) to protect the packets		function (AEAD_AES_128_GCM; see [RFC5116]) to protect the packets
	it exchanges during connection establishment.		it exchanges during connection establishment.
	o QUIC packet numbers are encrypted and appear as the first		* QUIC packet numbers are encrypted and appear as the first
	encrypted bytes.		encrypted bytes.
	o QUIC packet numbers increase by one for every packet sent.		* QUIC packet numbers increase by one for every packet sent.
	o QUIC has a minimum size for the first handshake packet sent by a		* QUIC has a minimum size for the first handshake packet sent by a
	client.		client.
	o QUIC stipulates that a client speak first.		* QUIC stipulates that a client speak first.
	o QUIC packets always have the second bit of the first byte (0x40)		* QUIC packets always have the second bit of the first byte (0x40)
	set.		set.
	o A QUIC Version Negotiation packet is only sent by a server.		* A QUIC Version Negotiation packet is only sent by a server.
	o A QUIC connection ID changes infrequently.		* A QUIC connection ID changes infrequently.
	o QUIC endpoints change the version they speak if they are sent a		* QUIC endpoints change the version they speak if they are sent a
	Version Negotiation packet.		Version Negotiation packet.
	o The Version field in a QUIC long header is the same in both		* The Version field in a QUIC long header is the same in both
	directions.		directions.
	o A QUIC packet with a particular value in the Version field means		* A QUIC packet with a particular value in the Version field means
	that the corresponding version of QUIC is in use.		that the corresponding version of QUIC is in use.
	o Only one connection at a time is established between any pair of		* Only one connection at a time is established between any pair of
	QUIC endpoints.		QUIC endpoints.
	Author's Address		Author's Address
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Email: mt@lowentropy.net		Email: mt@lowentropy.net
End of changes. 22 change blocks.
	38 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/