Skip to content

Commit

Permalink
Script updating gh-pages from 1b61c54. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jul 9, 2019
1 parent ec91918 commit afb6fbd
Show file tree
Hide file tree
Showing 5 changed files with 1,294 additions and 1,350 deletions.
4 changes: 2 additions & 2 deletions draft-ietf-quic-invariants.html
View file
Expand Up @@ -445,8 +445,8 @@ <h2 id="rfc.section.4.1">
<p class="figure">Figure 1: QUIC Long Header</p>
<p id="rfc.section.4.1.p.2">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.</p>
<p id="rfc.section.4.1.p.3">The next four bytes include a 32-bit Version field (see <a href="#version" class="xref">Section 4.4</a>).</p>
<p id="rfc.section.4.1.p.4">The next byte contains the length in bytes of the two Connection IDs (see <a href="#connection-id" class="xref">Section 4.3</a>) that follow. Each length is encoded as a 4-bit unsigned integer. The length of the Destination Connection ID (DCIL) occupies the high bits of the byte and the length of the Source Connection ID (SCIL) occupies the low bits of the byte. An encoded 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.</p>
<p id="rfc.section.4.1.p.5">The connection ID lengths are followed by two connection IDs. The connection ID associated with the recipient of the packet (the Destination Connection ID) is followed by the connection ID associated with the sender of the packet (the Source Connection ID).</p>
<p id="rfc.section.4.1.p.4">The next byte contains the length in bytes of the Destination Connection ID (see <a href="#connection-id" class="xref">Section 4.3</a>) field that follows it. This length is encoded as an 8-bit unsigned integer. The Destination Connection ID field follows the DCID Len field and is between 0 and 255 bytes in length.</p>
<p id="rfc.section.4.1.p.5">The next byte contains the length in bytes of the Source Connection ID field that follows it. This length is encoded as a 8-bit unsigned integer. The Source Connection ID field follows the SCID Len field and is between 0 and 255 bytes in length.</p>
<p id="rfc.section.4.1.p.6">The remainder of the packet contains version-specific content.</p>
<h2 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#short-header" id="short-header">Short Header</a>
Expand Down
146 changes: 45 additions & 101 deletions draft-ietf-quic-invariants.txt
View file
Expand Up @@ -75,18 +75,18 @@ Table of Contents
3. An Extremely Abstract Description of QUIC . . . . . . . . . . 3
4. QUIC Packet Headers . . . . . . . . . . . . . . . . . . . . . 3
4.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Connection ID . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 6
6. Security and Privacy Considerations . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Incorrect Assumptions . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9

1. Introduction

Expand Down Expand Up @@ -195,25 +195,25 @@ Internet-Draft QUIC Invariants July 2019

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
(see Section 4.3) that follow. Each length is encoded as a 4-bit
unsigned integer. The length of the Destination Connection ID (DCIL)
occupies the high bits of the byte and the length of the Source
Connection ID (SCIL) occupies the low bits of the byte. An encoded
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
connection ID associated with the recipient of the packet (the
Destination Connection ID) is followed by the connection ID
associated with the sender of the packet (the Source Connection ID).
The next byte contains the length in bytes of the Destination
Connection ID (see Section 4.3) field that follows it. This length
is encoded as an 8-bit unsigned integer. The Destination Connection
ID field follows the DCID Len field and is between 0 and 255 bytes in
length.

The next byte contains the length in bytes of the Source Connection
ID field that follows it. This length is encoded as a 8-bit unsigned
integer. The Source Connection ID field follows the SCID Len field
and is between 0 and 255 bytes in length.

The remainder of the packet contains version-specific content.

4.2. Short Header

Short headers take the form described in Figure 2. Bits that have
version-specific semantics are marked with an X.





Expand All @@ -226,11 +226,6 @@ Thomson Expires January 10, 2020 [Page 4]
Internet-Draft QUIC Invariants July 2019


4.2. Short Header

Short headers take the form described in Figure 2. Bits that have
version-specific semantics are marked with an X.

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
+-+-+-+-+-+-+-+-+
Expand Down Expand Up @@ -274,6 +269,11 @@ Internet-Draft QUIC Invariants July 2019
network byte order. Version 0 is reserved for version negotiation
(see Section 5). All other version numbers are potentially valid.

The properties described in this document apply to all versions of
QUIC. A protocol that does not conform to the properties described
in this document is not QUIC. Future documents might describe
additional properties which apply to a specific QUIC version, or to a
range of QUIC versions.



Expand All @@ -282,12 +282,6 @@ Thomson Expires January 10, 2020 [Page 5]
Internet-Draft QUIC Invariants July 2019


The properties described in this document apply to all versions of
QUIC. A protocol that does not conform to the properties described
in this document is not QUIC. Future documents might describe
additional properties which apply to a specific QUIC version, or to a
range of QUIC versions.

5. Version Negotiation

A QUIC endpoint that receives a packet with a long header and a
Expand Down Expand Up @@ -330,6 +324,12 @@ Internet-Draft QUIC Invariants July 2019
fields, each identifying a version that the endpoint sending the
packet supports. The Supported Version fields follow the Version
field. A Version Negotiation packet contains no other fields. An
endpoint MUST ignore a packet that contains no Supported Version
fields, or a truncated Supported Version.

Version Negotiation packets do not use integrity or confidentiality
protection. A specific QUIC version might authenticate the packet as
part of its connection establishment process.



Expand All @@ -338,13 +338,6 @@ Thomson Expires January 10, 2020 [Page 6]
Internet-Draft QUIC Invariants July 2019


endpoint MUST ignore a packet that contains no Supported Version
fields, or a truncated Supported Version.

Version Negotiation packets do not use integrity or confidentiality
protection. A specific QUIC version might authenticate the packet as
part of its connection establishment process.

An endpoint MUST include the value from the Source Connection ID
field of the packet it receives in the Destination Connection ID
field. The value for Source Connection ID MUST be copied from the
Expand Down Expand Up @@ -384,21 +377,22 @@ Internet-Draft QUIC Invariants July 2019
by off-path attackers. QUIC versions MUST define a mechanism that
authenticates the values it contains.

7. IANA Considerations

This document makes no request of IANA.

8. References



Thomson Expires January 10, 2020 [Page 7]

Internet-Draft QUIC Invariants July 2019


7. IANA Considerations

This document makes no request of IANA.

8. References
Thomson Expires January 10, 2020 [Page 7]

Internet-Draft QUIC Invariants July 2019


8.1. Normative References

Expand Down Expand Up @@ -441,7 +435,13 @@ Appendix A. Incorrect Assumptions
not protected from observation, but are nonetheless considered to be
changeable when a new version is deployed.

This section lists a sampling of incorrect assumptions that might be
made based on knowledge of QUIC version 1. Some of these statements
are not even true for QUIC version 1. This is not an exhaustive
list, it is intended to be illustrative only.

The following statements are NOT guaranteed to be true for every QUIC
version:



Expand All @@ -450,14 +450,6 @@ Thomson Expires January 10, 2020 [Page 8]
Internet-Draft QUIC Invariants July 2019


This section lists a sampling of incorrect assumptions that might be
made based on knowledge of QUIC version 1. Some of these statements
are not even true for QUIC version 1. This is not an exhaustive
list, it is intended to be illustrative only.

The following statements are NOT guaranteed to be true for every QUIC
version:

o QUIC uses TLS [QUIC-TLS] and some TLS messages are visible on the
wire

Expand Down Expand Up @@ -498,14 +490,6 @@ Internet-Draft QUIC Invariants July 2019
o Only one connection at a time is established between any pair of
QUIC endpoints




Thomson Expires January 10, 2020 [Page 9]

Internet-Draft QUIC Invariants July 2019


Author's Address

Martin Thomson
Expand All @@ -517,44 +501,4 @@ Author's Address











































Thomson Expires January 10, 2020 [Page 10]
Thomson Expires January 10, 2020 [Page 9]
2 changes: 1 addition & 1 deletion draft-ietf-quic-transport.html
View file
Expand Up @@ -2316,7 +2316,7 @@ <h2 id="rfc.section.17.2">
<dt>Version:</dt>
<dd style="margin-left: 8">The QUIC Version is a 32-bit field that follows the first byte. This field indicates which version of QUIC is in use and determines how the rest of the protocol fields are interpreted.</dd>
<dt>DCID Len:</dt>
<dd style="margin-left: 8">The byte following the version contains the lengths of the two connection ID fields that follow it. These lengths are encoded as two 4-bit unsigned integers. The Destination Connection ID Length (DCIL) field occupies the 4 high bits of the byte and the Source Connection ID Length (SCIL) field occupies the 4 low bits of the byte. An encoded 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, producing a length between 4 and 18 bytes inclusive. For example, a byte with the value 0x50 describes an 8-byte Destination Connection ID and a zero-length Source Connection ID.</dd>
<dd style="margin-left: 8">The byte following the version contains the length in bytes of the Destination Connection ID field that follows it. This length is encoded as an 8-bit unsigned integer. In QUIC version 1, this value MUST NOT exceed 20. Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet. Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet.</dd>
<dt>Destination Connection ID:</dt>
<dd style="margin-left: 8">The Destination Connection ID field follows the DCID Len and is between 0 and 20 bytes in length. <a href="#negotiating-connection-ids" class="xref">Section 7.2</a> describes the use of this field in more detail.</dd>
<dt>SCID Len:</dt>
Expand Down
28 changes: 14 additions & 14 deletions draft-ietf-quic-transport.txt
View file
Expand Up @@ -4584,8 +4584,8 @@ Internet-Draft QUIC Transport Protocol July 2019
byte. This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted.

DCID Len: The byte following the version contains the lengths of the
two connection ID fields that follow it. These lengths are
DCID Len: The byte following the version contains the length in
bytes of the Destination Connection ID field that follows it.



Expand All @@ -4594,15 +4594,12 @@ Iyengar & Thomson Expires January 10, 2020 [Page 82]
Internet-Draft QUIC Transport Protocol July 2019


encoded as two 4-bit unsigned integers. The Destination
Connection ID Length (DCIL) field occupies the 4 high bits of the
byte and the Source Connection ID Length (SCIL) field occupies the
4 low bits of the byte. An encoded 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,
producing a length between 4 and 18 bytes inclusive. For example,
a byte with the value 0x50 describes an 8-byte Destination
Connection ID and a zero-length Source Connection ID.
This length is encoded as an 8-bit unsigned integer. In QUIC
version 1, this value MUST NOT exceed 20. Endpoints that receive
a version 1 long header with a value larger than 20 MUST drop the
packet. Servers SHOULD be able to read longer connection IDs from
other QUIC versions in order to properly form a version
negotiation packet.

Destination Connection ID: The Destination Connection ID field
follows the DCID Len and is between 0 and 20 bytes in length.
Expand Down Expand Up @@ -4641,6 +4638,9 @@ Internet-Draft QUIC Transport Protocol July 2019
The header form bit, connection ID lengths byte, Destination and
Source Connection ID fields, and Version fields of a long header
packet are version-independent. The other fields in the first byte
are version-specific. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted.




Expand All @@ -4650,9 +4650,6 @@ Iyengar & Thomson Expires January 10, 2020 [Page 83]
Internet-Draft QUIC Transport Protocol July 2019


are version-specific. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted.

The interpretation of the fields and the payload are specific to a
version and packet type. While type-specific semantics for this
version are described in the following sections, several long-header
Expand Down Expand Up @@ -4701,6 +4698,9 @@ Internet-Draft QUIC Transport Protocol July 2019






Iyengar & Thomson Expires January 10, 2020 [Page 84]

Internet-Draft QUIC Transport Protocol July 2019
Expand Down

0 comments on commit afb6fbd

Please sign in to comment.