draft-ietf-quic-invariants-06.txt   draft-ietf-quic-invariants-07.txt 
QUIC M. Thomson QUIC M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track July 10, 2019 Intended status: Standards Track September 12, 2019
Expires: January 11, 2020 Expires: March 15, 2020
Version-Independent Properties of QUIC Version-Independent Properties of QUIC
draft-ietf-quic-invariants-06 draft-ietf-quic-invariants-07
Abstract Abstract
This document defines the properties of the QUIC transport protocol This document defines the properties of the QUIC transport protocol
that are expected to remain unchanged over time as new versions of that are expected to remain unchanged over time as new versions of
the protocol are developed. the protocol are developed.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2020. This Internet-Draft will expire on March 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. An Extremely Abstract Description of QUIC . . . . . . . . . . 3 3. An Extremely Abstract Description of QUIC . . . . . . . . . . 3
4. QUIC Packet Headers . . . . . . . . . . . . . . . . . . . . . 3 4. QUIC Packet Headers . . . . . . . . . . . . . . . . . . . . . 3
4.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Connection ID . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Connection ID . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 6 5. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 6
6. Security and Privacy Considerations . . . . . . . . . . . . . 7 6. Security and Privacy Considerations . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Incorrect Assumptions . . . . . . . . . . . . . . . 8 Appendix A. Incorrect Assumptions . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
In addition to providing secure, multiplexed transport, QUIC In addition to providing secure, multiplexed transport, QUIC
[QUIC-TRANSPORT] includes the ability to negotiate a version. This [QUIC-TRANSPORT] includes the ability to negotiate a version. This
allows the protocol to change over time in response to new allows the protocol to change over time in response to new
requirements. Many characteristics of the protocol will change requirements. Many characteristics of the protocol will change
between versions. between versions.
This document describes the subset of QUIC that is intended to remain This document describes the subset of QUIC that is intended to remain
skipping to change at page 4, line 30 skipping to change at page 4, line 30
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ... |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: QUIC Long Header Figure 1: 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 (see Section 4.4). The next four bytes include a 32-bit Version field (see Section 4.4).
The next byte contains the length in bytes of the two Connection IDs The next byte contains the length in bytes of the Destination
(see Section 4.3) that follow. Each length is encoded as a 4-bit Connection ID (see Section 4.3) field that follows it. This length
unsigned integer. The length of the Destination Connection ID (DCIL) is encoded as an 8-bit unsigned integer. The Destination Connection
occupies the high bits of the byte and the length of the Source ID field follows the DCID Len field and is between 0 and 255 bytes in
Connection ID (SCIL) occupies the low bits of the byte. An encoded length.
length of 0 indicates that the connection ID is also 0 bytes in
length. Non-zero encoded lengths are increased by 3 to get the full
length of the connection ID; the final value is therefore either 0 or
between 4 and 18 bytes in length (inclusive). For example, a byte
with the value 0xe0 describes a 17 byte Destination Connection ID and
a zero byte Source Connection ID.
The connection ID lengths are followed by two connection IDs. The The next byte contains the length in bytes of the Source Connection
connection ID associated with the recipient of the packet (the ID field that follows it. This length is encoded as a 8-bit unsigned
Destination Connection ID) is followed by the connection ID integer. The Source Connection ID field follows the SCID Len field
associated with the sender of the packet (the Source Connection ID). and is between 0 and 255 bytes in length.
The remainder of the packet contains version-specific content. The remainder of the packet contains version-specific content.
4.2. Short Header 4.2. Short Header
Short headers take the form described in Figure 2. Bits that have Short headers take the form described in Figure 2. Bits that have
version-specific semantics are marked with an X. version-specific semantics are marked with an X.
0 1 2 3 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 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
skipping to change at page 5, line 26 skipping to change at page 5, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ... |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: QUIC Short Header Figure 2: QUIC Short Header
A QUIC packet with a short header has the high bit of the first byte A QUIC packet with a short header has the high bit of the first byte
set to 0. set to 0.
A QUIC packet with a short header includes a Destination Connection A QUIC packet with a short header includes a Destination Connection
ID. The short header does not include the Connection ID Lengths, ID immediately following the first byte. The short header does not
Source Connection ID, or Version fields. include the Connection ID Lengths, Source Connection ID, or Version
fields. The length of the Destination Connection ID is not specified
in packets with a short header and is not constrained by this
specification.
The remainder of the packet has version-specific semantics. The remainder of the packet has version-specific semantics.
4.3. Connection ID 4.3. Connection ID
A connection ID is an opaque field of arbitrary length. A connection ID is an opaque field of arbitrary length.
The primary function of a connection ID is to ensure that changes in The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP, and below) don't cause addressing at lower protocol layers (UDP, IP, and below) don't cause
packets for a QUIC connection to be delivered to the wrong endpoint. packets for a QUIC connection to be delivered to the wrong endpoint.
skipping to change at page 8, line 16 skipping to change at page 8, line 12
This document makes no request of IANA. This document makes no request of IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-23 (work in progress), July 2019. transport-23 (work in progress), September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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 Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-23 (work in progress), July 2019. tls-23 (work in progress), September 2019.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
8.3. URIs 8.3. URIs
[1] https://mailarchive.ietf.org/arch/search/?email_list=quic [1] https://mailarchive.ietf.org/arch/search/?email_list=quic
[2] https://github.com/quicwg [2] https://github.com/quicwg
 End of changes. 11 change blocks. 
26 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/