draft-ietf-quic-transport-12.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: November 23, 2018 Mozilla Expires: November 24, 2018 Mozilla
May 22, 2018 May 23, 2018
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-12 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
Note to Readers Note to Readers
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 November 23, 2018. This Internet-Draft will expire on November 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 43, line 18 skipping to change at page 43, line 18
frame. frame.
An endpoint might need to send packets on multiple networks without An endpoint might need to send packets on multiple networks without
receiving any response from its peer. To ensure that the endpoint is receiving any response from its peer. To ensure that the endpoint is
not linkable across each of these changes, a new connection ID is not linkable across each of these changes, a new connection ID is
needed for each network. To support this, multiple NEW_CONNECTION_ID needed for each network. To support this, multiple NEW_CONNECTION_ID
messages are needed. Each NEW_CONNECTION_ID is marked with a messages are needed. Each NEW_CONNECTION_ID is marked with a
sequence number. Connection IDs MUST be used in the order in which sequence number. Connection IDs MUST be used in the order in which
they are numbered. they are numbered.
An endpoint that to break linkability upon changing networks MUST use Upon changing networks an endpoint MUST use a previously unused
a previously unused connection ID provided by its peer. Protection connection ID provided by its peer. This eliminates the use of the
of packet numbers ensures that packet numbers cannot be used to connection ID for linking activity from the same connection on
correlate connections. Other properties of packets, such as timing different networks. Protection of packet numbers ensures that packet
and size, might be used to correlate activity, but no explicit numbers cannot be used to correlate activity. This does not prevent
correlation can be used to link activity across paths. other properties of packets, such as timing and size, from being used
to correlate activity.
Clients MAY change connection ID at any time based on implementation- Clients MAY change connection ID at any time based on implementation-
specific concerns. For example, after a period of network inactivity specific concerns. For example, after a period of network inactivity
NAT rebinding might occur when the client begins sending data again. NAT rebinding might occur when the client begins sending data again.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
skipping to change at page 96, line 38 skipping to change at page 96, line 38
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-12 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[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-
tls-12 (work in progress). latest (work in progress).
[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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 97, line 36 skipping to change at page 97, line 36
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-12 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
 End of changes. 7 change blocks. 
15 lines changed or deleted 16 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/