From 3aafa6e683390d0c53abe9311b9106b7a441d5e9 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 25 Sep 2017 04:50:41 -0700 Subject: [PATCH 01/46] Require that parameters only appear once. --- draft-ietf-quic-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3247cc3b93..f6f1f8cc81 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1061,7 +1061,8 @@ MUST be validated (see {{version-validation}}) before the connection establishment is considered properly complete. Definitions for each of the defined transport parameters are included in -{{transport-parameter-definitions}}. +{{transport-parameter-definitions}}. Any given parameter MUST appear +at most once in a given transport parameters extension. ### Transport Parameter Definitions From 0a9c534c518cb121209a5eb5e11bcdf209250e56 Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Tue, 26 Sep 2017 11:03:34 +0200 Subject: [PATCH 02/46] reference format --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1e0482ca07..950a29bad8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -159,7 +159,7 @@ QUIC packet: ## Notational Conventions -Packet and frame diagrams use the format described in {{?RFC2360}} Section 3.1, +Packet and frame diagrams use the format described in Section 3.1 of {{?RFC2360}}, with the following additional conventions: \[x\] @@ -1422,7 +1422,7 @@ Gap = HKDF-Expand-Label(packet_number_secret, The output of HKDF-Expand-Label is interpreted as a big-endian number. "packet_number_secret" is derived from the TLS key exchange, -as described in {{QUIC-TLS}} Section 5.6. +as described in Section 5.6 of {{QUIC-TLS}}. ### Address Validation for Migrated Connections From ad02c0239e5a0b3a371ed9b9ce88a1c7a7097ee6 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 28 Sep 2017 12:10:40 +1000 Subject: [PATCH 03/46] Correct formatting error --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 950a29bad8..990db57c87 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -159,8 +159,8 @@ QUIC packet: ## Notational Conventions -Packet and frame diagrams use the format described in Section 3.1 of {{?RFC2360}}, -with the following additional conventions: +Packet and frame diagrams use the format described in Section 3.1 of +{{?RFC2360}}, with the following additional conventions: \[x\] : Indicates that x is optional From 0f80d255b2a311389a47febfb712a32c74c17f68 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 28 Sep 2017 12:34:10 +1000 Subject: [PATCH 04/46] Error code for duplicate parameters A friendly amendment to your PR. --- draft-ietf-quic-transport.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f6f1f8cc81..e0cf931794 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1061,8 +1061,10 @@ MUST be validated (see {{version-validation}}) before the connection establishment is considered properly complete. Definitions for each of the defined transport parameters are included in -{{transport-parameter-definitions}}. Any given parameter MUST appear -at most once in a given transport parameters extension. +{{transport-parameter-definitions}}. Any given parameter MUST appear +at most once in a given transport parameters extension. An endpoint MUST +treat receipt of duplicate transport parameters as a connection error of +type TRANSPORT_PARAMETER_ERROR. ### Transport Parameter Definitions From aa0a4d71c6d99e6adeb278407c4c211b88c83c29 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 28 Sep 2017 14:25:31 -0700 Subject: [PATCH 05/46] Don't retransmit old MAX_STREAM_DATA and MAX_DATA --- draft-ietf-quic-transport.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8326d39ed1..0dfa8ee609 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2420,6 +2420,11 @@ When a packet is detected as lost, the sender re-sends any frames as necessary: * STOP_SENDING frames MUST be retransmitted, unless the stream has become closed in the appropriate direction. See {{solicited-state-transitions}}. +* The most recent MAX_STREAM_DATA and MAX_DATA frames MUST be retransmitted + until acked. Any previous unacknowledged MAX_STREAM_DATA and MAX_DATA frames + SHOULD NOT be retransmitted since the newer frames obviate the need for + delivering the older ones. + * All other frames MUST be retransmitted. Upon detecting losses, a sender MUST take appropriate congestion control action. From d704d00613a2ff9de3d0f96288c5cececca6027e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 28 Sep 2017 14:29:57 -0700 Subject: [PATCH 06/46] reflow --- draft-ietf-quic-transport.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0dfa8ee609..1e7c7f84dd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2420,10 +2420,11 @@ When a packet is detected as lost, the sender re-sends any frames as necessary: * STOP_SENDING frames MUST be retransmitted, unless the stream has become closed in the appropriate direction. See {{solicited-state-transitions}}. -* The most recent MAX_STREAM_DATA and MAX_DATA frames MUST be retransmitted - until acked. Any previous unacknowledged MAX_STREAM_DATA and MAX_DATA frames - SHOULD NOT be retransmitted since the newer frames obviate the need for - delivering the older ones. +* The most recent MAX_STREAM_DATA frame for a stream MUST be retransmitted. Any + previous unacknowledged MAX_STREAM_DATA frame for the same stream SHOULD NOT + be retransmitted since a newer MAX_STREAM_DATA frame for a stream obviates the + need for delivering older ones. Similarly, the most recent MAX_DATA frame MUST + be retransmitted; previous unacknowledged ones SHOULD NOT be retransmitted. * All other frames MUST be retransmitted. From 00c5a74a062c1147ec036d5f0be73da4b6a6ae0d Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 19 Sep 2017 12:43:51 -0700 Subject: [PATCH 07/46] Allow RST_STREAM to be sent and received after FIN --- draft-ietf-quic-transport.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8326d39ed1..2d5cb6d02d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2635,8 +2635,10 @@ Any frame type that mentions a stream ID can be sent in this state. A stream that is in the "half-closed (local)" state MUST NOT be used for sending on new STREAM frames. Retransmission of data that has already been sent on -STREAM frames is permitted. An endpoint MAY also send MAX_STREAM_DATA and -STOP_SENDING in this state. +STREAM frames is permitted. If the stream is canceled or reset while in this +state, a RST_STREAM frame MAY be sent. A RST_STREAM frame sent in this state +MUST carry the stream's final offset. An endpoint MAY also send MAX_STREAM_DATA +and STOP_SENDING in this state. An endpoint that closes a stream MUST NOT send data beyond the final offset that it has chosen, see {{state-closed}} for details. @@ -2668,6 +2670,10 @@ closes a stream SHOULD be discarded. An endpoint MAY choose to limit the period over which it ignores frames and treat frames that arrive after this time as being in error. +An endpoint may receive a RST_STREAM after a FIN if the peer resets the stream +after sending a FIN on it. In this case, the endpoint MAY discard any data that +it already received on that stream. + An endpoint will know the final offset of the data it receives on a stream when it reaches the "half-closed (remote)" state, see {{final-offset}} for details. From b516f913f4a1cd89faf676b64bc52afcc0f08c63 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 19 Sep 2017 12:56:57 -0700 Subject: [PATCH 08/46] Rephrase. --- draft-ietf-quic-transport.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2d5cb6d02d..d34bb207a7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2635,10 +2635,12 @@ Any frame type that mentions a stream ID can be sent in this state. A stream that is in the "half-closed (local)" state MUST NOT be used for sending on new STREAM frames. Retransmission of data that has already been sent on -STREAM frames is permitted. If the stream is canceled or reset while in this -state, a RST_STREAM frame MAY be sent. A RST_STREAM frame sent in this state -MUST carry the stream's final offset. An endpoint MAY also send MAX_STREAM_DATA -and STOP_SENDING in this state. +STREAM frames is permitted. An endpoint MAY also send MAX_STREAM_DATA and +STOP_SENDING in this state. + +If application resets a stream in this state, a RST_STREAM frame MAY be sent. +The final offset carried in a RST_STREAM frame sent in this state MUST be the +same as any previously indicated final offset. An endpoint that closes a stream MUST NOT send data beyond the final offset that it has chosen, see {{state-closed}} for details. From c425056f599ed5203a13ed9a6ab51b470d032847 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 19 Sep 2017 14:20:30 -0700 Subject: [PATCH 09/46] ekr/ianswett comments --- draft-ietf-quic-transport.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d34bb207a7..f06b80d6a1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2638,9 +2638,10 @@ on new STREAM frames. Retransmission of data that has already been sent on STREAM frames is permitted. An endpoint MAY also send MAX_STREAM_DATA and STOP_SENDING in this state. -If application resets a stream in this state, a RST_STREAM frame MAY be sent. -The final offset carried in a RST_STREAM frame sent in this state MUST be the -same as any previously indicated final offset. +An application with a stream in this state may no longer care about data sent on +the stream and may choose to reset the stream. To permit this behavior, a +RST_STREAM frame MAY be sent in this state. The final offset carried in this +RST_STREAM frame MUST be the same as the previously established final offset. An endpoint that closes a stream MUST NOT send data beyond the final offset that it has chosen, see {{state-closed}} for details. @@ -2672,9 +2673,11 @@ closes a stream SHOULD be discarded. An endpoint MAY choose to limit the period over which it ignores frames and treat frames that arrive after this time as being in error. -An endpoint may receive a RST_STREAM after a FIN if the peer resets the stream -after sending a FIN on it. In this case, the endpoint MAY discard any data that -it already received on that stream. +An endpoint may receive a RST_STREAM in this state, such as when the peer resets +the stream after sending a FIN on it. In this case, the endpoint MAY discard any +data that it already received on that stream. The endpoint SHOULD close the +connection with a FINAL_OFFSET_ERROR if the received RST_STREAM carries a +different offset from the one already established. An endpoint will know the final offset of the data it receives on a stream when it reaches the "half-closed (remote)" state, see {{final-offset}} for details. From 0bd005341a2c5d9b1d78059e61f665911c441ba5 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 19 Sep 2017 16:27:28 -0700 Subject: [PATCH 10/46] mike's comment --- draft-ietf-quic-transport.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f06b80d6a1..9aec9a5b3a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2695,11 +2695,12 @@ A stream also becomes "closed" when the endpoint sends a RST_STREAM frame. ### closed {#state-closed} -The "closed" state is the terminal state for a stream. +The "closed" state is the terminal state for a stream. Reordering might cause +frames to be received after closing, see {{state-hc-remote}}. -Once a stream reaches this state, no frames can be sent that mention the stream. -Reordering might cause frames to be received after closing, see -{{state-hc-remote}}. +If the application resets a stream that is already in the "closed" state, a +RST_STREAM frame MAY still be sent in order to cancel retransmissions of +previously-sent STREAM frames. ## Solicited State Transitions From 842cc28bcb8f34a001f3c091ff5b19410349595e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 28 Sep 2017 15:21:18 -0700 Subject: [PATCH 11/46] martin's nits --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9aec9a5b3a..5ea87bcb8d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2638,10 +2638,10 @@ on new STREAM frames. Retransmission of data that has already been sent on STREAM frames is permitted. An endpoint MAY also send MAX_STREAM_DATA and STOP_SENDING in this state. -An application with a stream in this state may no longer care about data sent on -the stream and may choose to reset the stream. To permit this behavior, a -RST_STREAM frame MAY be sent in this state. The final offset carried in this -RST_STREAM frame MUST be the same as the previously established final offset. +An application can decide to abandon a stream in this state. An endpoint can +send RST_STREAM for a stream that was closed with the FIN flag. The final offset +carried in this RST_STREAM frame MUST be the same as the previously established +final offset. An endpoint that closes a stream MUST NOT send data beyond the final offset that it has chosen, see {{state-closed}} for details. From eb39a2a78a5e19a497617b66a05208050fb0c611 Mon Sep 17 00:00:00 2001 From: EKR Date: Thu, 28 Sep 2017 09:23:27 +0200 Subject: [PATCH 12/46] A tiny nit: the ClientHello is not subject to MAX_STREAM_DATA. --- draft-ietf-quic-transport.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5ea87bcb8d..f7043ea1ed 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2771,10 +2771,16 @@ ordered byte-stream. Data received out of order MUST be buffered for later delivery, as long as it is not in violation of the receiver's flow control limits. -An endpoint MUST NOT send data on any stream without ensuring that it is within -the data limits set by its peer. The cryptographic handshake stream, Stream 0, -is exempt from the connection-level data limits established by MAX_DATA. Stream -0 is still subject to stream-level data limits and MAX_STREAM_DATA. +An endpoint MUST NOT send data on any stream without ensuring that it +is within the data limits set by its peer. The cryptographic +handshake stream, Stream 0, is exempt from the connection-level data +limits established by MAX_DATA. Data on stream 0 other than the +TLS ClientHello is still subject to stream-level data limits and +MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control because it needs +to be sent in one piece regardless of the server's flow control +state. This rule applies even for 0-RTT handshakes where the +remembered value of MAX_STREAM_DATA would not permit sending +a full ClientHello. Flow control is described in detail in {{flow-control}}, and congestion control is described in the companion document {{QUIC-RECOVERY}}. From 47bd32597ebce89de2a30978f38c03780e172727 Mon Sep 17 00:00:00 2001 From: EKR Date: Thu, 28 Sep 2017 23:19:12 +0200 Subject: [PATCH 13/46] Nits from Jana --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f7043ea1ed..0a72f84709 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2777,9 +2777,9 @@ handshake stream, Stream 0, is exempt from the connection-level data limits established by MAX_DATA. Data on stream 0 other than the TLS ClientHello is still subject to stream-level data limits and MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control because it needs -to be sent in one piece regardless of the server's flow control +to be sent in a single packet regardless of the server's flow control state. This rule applies even for 0-RTT handshakes where the -remembered value of MAX_STREAM_DATA would not permit sending +remembered value of MAX_STREAM_DATA does not permit sending a full ClientHello. Flow control is described in detail in {{flow-control}}, and congestion control From 866b88fb8fc4e1735257f1be78996775968a8d3d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 29 Sep 2017 08:53:02 +1000 Subject: [PATCH 14/46] reflow --- draft-ietf-quic-transport.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0a72f84709..0be5cf0a5e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2771,16 +2771,14 @@ ordered byte-stream. Data received out of order MUST be buffered for later delivery, as long as it is not in violation of the receiver's flow control limits. -An endpoint MUST NOT send data on any stream without ensuring that it -is within the data limits set by its peer. The cryptographic -handshake stream, Stream 0, is exempt from the connection-level data -limits established by MAX_DATA. Data on stream 0 other than the -TLS ClientHello is still subject to stream-level data limits and -MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control because it needs -to be sent in a single packet regardless of the server's flow control -state. This rule applies even for 0-RTT handshakes where the -remembered value of MAX_STREAM_DATA does not permit sending -a full ClientHello. +An endpoint MUST NOT send data on any stream without ensuring that it is within +the data limits set by its peer. The cryptographic handshake stream, Stream 0, +is exempt from the connection-level data limits established by MAX_DATA. Data on +stream 0 other than the TLS ClientHello is still subject to stream-level data +limits and MAX_STREAM_DATA. The TLS ClientHello is exempt from flow control +because it needs to be sent in a single packet regardless of the server's flow +control state. This rule applies even for 0-RTT handshakes where the remembered +value of MAX_STREAM_DATA does not permit sending a full ClientHello. Flow control is described in detail in {{flow-control}}, and congestion control is described in the companion document {{QUIC-RECOVERY}}. From f83d06cde4eb8e42a58a773428294fdbdfeb01b8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 29 Sep 2017 09:46:37 +1000 Subject: [PATCH 15/46] Test with circle v2 infrastructure, which should be faster --- .circleci/config.yml | 55 ++++++++++++++++++++++++++++++++++++++++++++ Makefile | 12 ++++++---- circle.yml | 32 -------------------------- 3 files changed, 62 insertions(+), 37 deletions(-) create mode 100644 .circleci/config.yml delete mode 100644 circle.yml diff --git a/.circleci/config.yml b/.circleci/config.yml new file mode 100644 index 0000000000..02e412ae8e --- /dev/null +++ b/.circleci/config.yml @@ -0,0 +1,55 @@ +version: 2 +jobs: + build: + docker: + - image: martinthomson/i-d-template:latest + + working_directory: ~/id + + steps: + - checkout + + - restore_cache: + keys: + - template + + - run: + name: Update Template + command: git -C ~/i-d-template remote update --prune + + - save_cache: + key: template + paths: + - ~/i-d-template + + - restore_cache: + keys: + - refcache + + - run: + name: Build Drafts + command: make 'CLONE_ARGS=--reference ~/i-d-template' + + - save_cache: + key: refcache + paths: + - ~/.cache/xml2rfc + + - run: + name: Create Artifacts + command: make artifacts CI_ARTIFACTS=/tmp/artifacts + + - store_artifacts: + path: /tmp/artifacts + + - run: + name: Update GitHub Pages + command: make gh-pages + + - run: + name: Upload to Datatracker + command: [ -n "$CIRCLE_TAG" ] && make upload + + - run: + name: Save Issues + command: make gh-pages diff --git a/Makefile b/Makefile index 1d03b33826..4c21c17f86 100644 --- a/Makefile +++ b/Makefile @@ -1,13 +1,15 @@ MD_PREPROCESSOR := sed -e 's/{DATE}/$(shell date '+%Y-%m')/g' -include lib/main.mk +LIBDIR := lib +include $(LIBDIR)/main.mk -lib/main.mk: -ifneq (,$(shell git submodule status lib 2>/dev/null)) +$(LIBDIR)/main.mk: +ifneq (,$(shell git submodule status $(LIBDIR) 2>/dev/null)) git submodule sync - git submodule update --init + git submodule update $(CLONE_ARGS) --init else - git clone -q --depth 10 -b master https://github.com/martinthomson/i-d-template.git lib + git clone -q --depth 10 $(CLONE_ARGS) \ + -b master https://github.com/martinthomson/i-d-template $(LIBDIR) endif latest:: lint diff --git a/circle.yml b/circle.yml deleted file mode 100644 index 59a3b29592..0000000000 --- a/circle.yml +++ /dev/null @@ -1,32 +0,0 @@ -machine: - environment: - GOPATH: "${HOME}/${CIRCLE_PROJECT_REPONAME}/.go_workspace" - mmark_src: github.com/miekg/mmark/mmark - mmark: ./mmark - python: - version: 3.5.2 - -checkout: - post: - - if [ -e .git/shallow ]; then git fetch origin --unshallow; fi - - git fetch origin gh-pages - -dependencies: - pre: - - pip install xml2rfc - - if head -1 -q *.md | grep '^\-\-\-' >/dev/null 2>&1; then gem install --no-doc kramdown-rfc2629; fi - - if head -1 -q *.md | grep '^%%%' >/dev/null 2>&1; then go get "$mmark_src" && go build "$mmark_src"; fi - cache_directories: - - "/opt/circleci/.rvm/gems" - -test: - override: - - make - -deployment: - production: - branch: /.*/ - commands: - - make artifacts - - make ghpages || make ghpages - - make ghissues || true From eb8f61b52ee61f41e592ab29630be4582c23025e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 29 Sep 2017 09:57:33 +1000 Subject: [PATCH 16/46] Maybe this is the problem with the syntax --- .circleci/config.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index 02e412ae8e..ba54acdd66 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -48,7 +48,7 @@ jobs: - run: name: Upload to Datatracker - command: [ -n "$CIRCLE_TAG" ] && make upload + command: if [ -n "$CIRCLE_TAG" ]; then make upload; fi - run: name: Save Issues From 075702b3c6e4ca73ddc85f3c28f3e616bb887c7e Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 29 Sep 2017 16:18:13 +1000 Subject: [PATCH 17/46] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 12e969b60c..3108fadcda 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -41,7 +41,7 @@ their resolution. Before filing a new issue, please consider a few things: -* Issues should be just that; issues with our deliverables, **not questions or support requests**. +* Issues should be just that; issues with our deliverables, **not proposals, questions or support requests**. * Please review the issues list to make sure that you aren't filing a duplicate. * If you're not sure how to phrase your issue, please ask on the [mailing list](https://www.ietf.org/mailman/listinfo/quic). From 9a899efefeb2777fd12b2764792e6be6cccca98c Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 29 Sep 2017 16:19:07 +1000 Subject: [PATCH 18/46] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3108fadcda..fb407c95c8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -24,7 +24,7 @@ new to this, you may also want to read the [Tao of the IETF](https://www.ietf.or The Working Group has a few venues for discussion: -* We plan to meet at all [IETF meetings](https://www.ietf.org/meeting/) for the foreseeable future, and hold interim meetings between them, at least through 2017. See our [meeting materials repository](https://github.com/quicwg/wg-materials) and the [official proceedings](https://datatracker.ietf.org/wg/quic/meetings/). +* We plan to meet at all [IETF meetings](https://www.ietf.org/meeting/) for the foreseeable future, and hold interim meetings between them. See our [meeting materials repository](https://github.com/quicwg/wg-materials) and the [official proceedings](https://datatracker.ietf.org/wg/quic/meetings/). * Our [mailing list](https://www.ietf.org/mailman/listinfo/quic) is used for most communication, including notifications of meetings, new drafts, consensus calls and other business, as well as issue discussion. From 0d64361be2aed3a2e83f1dbd04d516754da303f9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 29 Sep 2017 20:23:39 +1000 Subject: [PATCH 19/46] Update YAML file and hope that it's OK --- .circleci/config.yml | 45 +++++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 21 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index ba54acdd66..83128c4d6b 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -3,53 +3,56 @@ jobs: build: docker: - image: martinthomson/i-d-template:latest - - working_directory: ~/id - + working_directory: ~/draft steps: - checkout + # Prime caches for faster checkout - restore_cache: keys: - - template - + - template - run: - name: Update Template - command: git -C ~/i-d-template remote update --prune - + name: "Update Template" + command: "git -C ~/i-d-template remote update --prune" - save_cache: key: template paths: - ~/i-d-template + # Build txt and html versions of drafts - restore_cache: keys: - - refcache - + - refcache - run: - name: Build Drafts - command: make 'CLONE_ARGS=--reference ~/i-d-template' - + name: "Build Drafts" + command: "make 'CLONE_ARGS=--reference ~/i-d-template'" - save_cache: key: refcache paths: - ~/.cache/xml2rfc + # Create and store artifacts - run: - name: Create Artifacts - command: make artifacts CI_ARTIFACTS=/tmp/artifacts + name: "Create Artifacts" + command: "make artifacts CI_ARTIFACTS=/tmp/artifacts" - store_artifacts: path: /tmp/artifacts + # Update gh-pages and gh-issues branches - run: - name: Update GitHub Pages - command: make gh-pages + name: "Update GitHub Pages" + command: "make gh-pages" + - run: - name: Upload to Datatracker - command: if [ -n "$CIRCLE_TAG" ]; then make upload; fi + name: "Save Issues" + command: "make gh-issues" + # For tagged builds, upload to the datatracker. - run: - name: Save Issues - command: make gh-pages + name: "Upload to Datatracker" + command: | + if [ "${CIRCLE_TAG#draft-}" != "${CIRCLE_TAG}" ]; then + make upload + fi From 131141a53469ecc20a172d49ca7fd9881ba9252b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 29 Sep 2017 23:24:29 +1000 Subject: [PATCH 20/46] Ignore result of gh-issues --- .circleci/config.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index 83128c4d6b..b356adebd3 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -47,7 +47,7 @@ jobs: - run: name: "Save Issues" - command: "make gh-issues" + command: "make gh-issues || true" # For tagged builds, upload to the datatracker. - run: From 585d504599905b2b275d3b9bc2d469ada7c3be19 Mon Sep 17 00:00:00 2001 From: Marten Seemann Date: Sun, 1 Oct 2017 22:30:02 +0700 Subject: [PATCH 21/46] close connection when receiving unprotected ACKs for protected packets (#810) --- draft-ietf-quic-recovery.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 0eb8bcba1c..19f6681369 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -529,7 +529,8 @@ largest acked packet is supplied. #### Handshake Packets -The receiver MUST ignore unprotected packets that ack protected packets. +The receiver MUST close the connection with an error of type OPTIMISTIC_ACK +when receiving an unprotected packet that acks protected packets. The receiver MUST trust protected acks for unprotected packets, however. Aside from this, loss detection for handshake packets when an ack is processed is identical to other packets. From 83576f39d960c1c9d0195cd83eb858d3eb98977f Mon Sep 17 00:00:00 2001 From: EKR Date: Sun, 1 Oct 2017 16:04:21 -0700 Subject: [PATCH 22/46] Specify what to do with bogus streams. Fixes #791 --- draft-ietf-quic-transport.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0be5cf0a5e..a407850dfa 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2501,7 +2501,10 @@ for some applications. Streams are identified by an unsigned 32-bit integer, referred to as the Stream ID. To avoid Stream ID collision, clients MUST initiate streams using odd-numbered Stream IDs; servers MUST initiate streams using -even-numbered Stream IDs. +even-numbered Stream IDs. If an endpoint receives a frame which +corresponds to a stream which is allocated to it (i.e., odd-numbered for +the client or even-numbered for the server) but which it has not yet +created, it MUST close the connection with error code STREAM_STATE_ERROR. Stream ID 0 (0x0) is reserved for the cryptographic handshake. Stream 0 MUST NOT be used for application data, and is the first client-initiated stream. From 4ff84a03e1fd47cdc8d50d23ccb4bb3df309b699 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 1 Oct 2017 20:02:14 -0400 Subject: [PATCH 23/46] Retransmit stream data, not stream frames --- 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 0be5cf0a5e..828aa4c0a9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2820,7 +2820,7 @@ authentication messages. STREAM frames that are determined to be lost SHOULD be retransmitted before sending new data, unless application priorities indicate otherwise. -Retransmitting lost STREAM frames can fill in gaps, which allows the peer to +Retransmitting lost stream data can fill in gaps, which allows the peer to consume already received data and free up flow control window. From 1feb357ed0d1ec0b8e0770cfc1b1a4ba94870c0e Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 1 Oct 2017 20:10:58 -0400 Subject: [PATCH 24/46] Fixes the definition of recovery No longer talk about retransmitting frames and more exactly specify the end. --- draft-ietf-quic-recovery.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 19f6681369..47b8f1a3c4 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -608,10 +608,12 @@ window and sets the slow start threshold to the new congestion window. ## Recovery Period Recovery is a period of time beginning with detection of a lost packet. -Because QUIC retransmits frames, not packets, it defines the end of -recovery as all packets outstanding at the start of recovery being -acknowledged or lost. This is slightly different from TCP's definition of -recovery ending when the lost packet that started recovery is acknowledged. +Because QUIC retransmits stream data and control frames, not packets, +it defines the end of recovery as a packet sent after the start of +recovery being acknowledged. This is slightly different from TCP's +definition of recovery ending when the lost packet that started +recovery is acknowledged. + During recovery, the congestion window is not increased or decreased. As such, multiple lost packets only decrease the congestion window once as long as they're lost before exiting recovery. This causes QUIC to decrease From 92d3e46a7fac397b89851aee4583240794f56a5e Mon Sep 17 00:00:00 2001 From: ekr Date: Sun, 1 Oct 2017 19:06:43 -0700 Subject: [PATCH 25/46] typo fix (#811) * typo fix * Line length --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0be5cf0a5e..0ce74f69fa 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -578,8 +578,8 @@ The payload of a Client Initial packet consists of a STREAM frame (or frames) for stream 0 containing a cryptographic handshake message, with enough PADDING frames that the packet is at least 1200 octets (see {{packetization}}). The stream in this packet always starts at an offset of 0 (see {{stateless-retry}}) -and the complete cyptographic handshake message MUST fit in a single packet (see -{{handshake}}). +and the complete cryptographic handshake message MUST fit in a single packet +(see {{handshake}}). The client uses the Client Initial Packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new From d93dd90fc1d8e9fffaac54b99fcd406fec141bd6 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 2 Oct 2017 12:53:54 -0400 Subject: [PATCH 26/46] Must not ack acks --- 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 0ce74f69fa..2356abc956 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1992,7 +1992,7 @@ Error Code: Receivers send ACK frames to inform senders which packets they have received and processed, as well as which packets are considered missing. The ACK frame contains between 1 and 256 ACK blocks. ACK blocks are ranges of acknowledged -packets. Implementations SHOULD NOT generate ACK packets in response to packets +packets. Implementations MUST NOT generate ACK packets in response to packets which only contain ACKs. However, they SHOULD ACK those packets when sending ACKs for other packets. From 9aa2a109a901ada3adc86ff72543edb2b8631c70 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 2 Oct 2017 13:36:34 -0400 Subject: [PATCH 27/46] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2356abc956..adb7b9241e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1992,9 +1992,10 @@ Error Code: Receivers send ACK frames to inform senders which packets they have received and processed, as well as which packets are considered missing. The ACK frame contains between 1 and 256 ACK blocks. ACK blocks are ranges of acknowledged -packets. Implementations MUST NOT generate ACK packets in response to packets -which only contain ACKs. However, they SHOULD ACK those packets when sending -ACKs for other packets. +packets. Implementations MUST NOT generate packets that only contain ACK frames +in response to packets which only contain ACK frames. However, they SHOULD ACK +packets containing only ack frames when sending ACK frames in response to other +packets. To limit ACK blocks to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer. Once From 9105969d8ee23d51129a43f4879e1a01fd98efb4 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 2 Oct 2017 14:12:01 -0400 Subject: [PATCH 28/46] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index adb7b9241e..b4b53af2a1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1993,9 +1993,9 @@ Receivers send ACK frames to inform senders which packets they have received and processed, as well as which packets are considered missing. The ACK frame contains between 1 and 256 ACK blocks. ACK blocks are ranges of acknowledged packets. Implementations MUST NOT generate packets that only contain ACK frames -in response to packets which only contain ACK frames. However, they SHOULD ACK -packets containing only ack frames when sending ACK frames in response to other -packets. +in response to packets which only contain ACK frames. However, they SHOULD +acknowledge packets containing only ack frames when sending ACK frames in +response to other packets. To limit ACK blocks to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer. Once From 7edf4e0e0735a9e1ffb2645f1a1e4e91e819aee5 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 2 Oct 2017 15:22:10 -0700 Subject: [PATCH 29/46] Simplify stateless retry. There's no reason for it to contain ACKs or padding. --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 62d424eec6..0f51aed43a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -618,10 +618,10 @@ any version negotiation that occurred (see {{version-negotiation}}). The client MAY also retain any observed RTT or congestion state that it has accumulated for the flow, but other transport state MUST be discarded. -The payload of the Server Stateless Retry packet contains STREAM frames and -could contain PADDING and ACK frames. A server can only send a single Server -Stateless Retry packet in response to each Client Initial packet that is -receives. +The payload of the Server Stateless Retry packet contains a single +STREAM frame with offset 0 containing the server's cryptographic stateless retry +material. It MUST NOT contain any other frames. Any future messages from +the server will also start at stream offset 0. ### Server Cleartext Packet {#packet-server-cleartext} From 03db4e3ffc8aee5cba8bd78535db7e291fd7a5d2 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 2 Oct 2017 15:23:39 -0700 Subject: [PATCH 30/46] Revise text a bit --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0f51aed43a..077dead9dc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -619,8 +619,8 @@ MAY also retain any observed RTT or congestion state that it has accumulated for the flow, but other transport state MUST be discarded. The payload of the Server Stateless Retry packet contains a single -STREAM frame with offset 0 containing the server's cryptographic stateless retry -material. It MUST NOT contain any other frames. Any future messages from +STREAM frame on stream 0 with offset 0 containing the server's cryptographic stateless retry +material. It MUST NOT contain any other frames. Any future stream frames from the server will also start at stream offset 0. From fcb91e33ada1c14743fb268decb2c4691fafe8a3 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 2 Oct 2017 15:25:02 -0700 Subject: [PATCH 31/46] Grrr... Line length --- draft-ietf-quic-transport.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 077dead9dc..a0291f75a2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -619,9 +619,10 @@ MAY also retain any observed RTT or congestion state that it has accumulated for the flow, but other transport state MUST be discarded. The payload of the Server Stateless Retry packet contains a single -STREAM frame on stream 0 with offset 0 containing the server's cryptographic stateless retry -material. It MUST NOT contain any other frames. Any future stream frames from -the server will also start at stream offset 0. +STREAM frame on stream 0 with offset 0 containing the server's +cryptographic stateless retry material. It MUST NOT contain any other +frames. Any future stream frames from the server will also start at +stream offset 0. ### Server Cleartext Packet {#packet-server-cleartext} From badce41a3d996b9353ce57e0a4b46fc77a52f584 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 3 Oct 2017 10:03:51 -0700 Subject: [PATCH 32/46] Correct statement on padding --- 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 62d424eec6..cd12b6dc2a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1267,7 +1267,7 @@ use the server to send more data toward the victim than it would be able to send on its own. Several methods are used in QUIC to mitigate this attack. Firstly, the initial -handshake packet is padded to at least 1280 octets. This allows a server to +handshake packet is padded to at least 1200 octets. This allows a server to send a similar amount of data without risking causing an amplification attack toward an unproven remote address. From ca81183b9c1c7042c36b0e282f57cad6831b0e3c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 3 Oct 2017 15:27:16 -0700 Subject: [PATCH 33/46] Capitalize ACK --- 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 b4b53af2a1..d64d7f14c4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1994,7 +1994,7 @@ processed, as well as which packets are considered missing. The ACK frame contains between 1 and 256 ACK blocks. ACK blocks are ranges of acknowledged packets. Implementations MUST NOT generate packets that only contain ACK frames in response to packets which only contain ACK frames. However, they SHOULD -acknowledge packets containing only ack frames when sending ACK frames in +acknowledge packets containing only ACK frames when sending ACK frames in response to other packets. To limit ACK blocks to those that have not yet been received by the sender, the From 378fa42424be49a5c162a5d78d6ced3f9a79c1be Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 3 Oct 2017 16:05:41 -0700 Subject: [PATCH 34/46] Clarify the first flight, explicitly excluding NST --- draft-ietf-quic-tls.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index eff99dfe85..793b4376dc 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -966,7 +966,8 @@ employed by an attacker to exhaust server resources. Limiting the number of packets that are saved might be necessary. The server transitions to using 1-RTT keys after sending its first flight of TLS -handshake messages. From this point, the server protects all packets with 1-RTT +handshake messages, ending in the Finished. +From this point, the server protects all packets with 1-RTT keys. Future packets are therefore protected with 1-RTT keys. Initially, these are marked with a KEY_PHASE of 0. From 11539390136fa36270807b5335a1be714d746787 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 5 Oct 2017 10:18:44 -0700 Subject: [PATCH 35/46] Update CONTRIBUTING.md --- CONTRIBUTING.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fb407c95c8..f4e9546c9c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,6 +1,8 @@ # Contributing to QUIC -Before submitting feedback, please familiarize yourself with our current [issues list](https://github.com/quicwg/base-drafts/issues) and [charter](https://datatracker.ietf.org/wg/quic/about/). If you're +Anyone can contribute to QUIC; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work, as outlined below, is part of the QUIC Working Group. + +Before doing so, it's a good idea to familiarize yourself with our current [issues list](https://github.com/quicwg/base-drafts/issues) and [charter](https://datatracker.ietf.org/wg/quic/about/). If you're new to this, you may also want to read the [Tao of the IETF](https://www.ietf.org/tao.html). **Be aware that all contributions fall under the "NOTE WELL" terms outlined below.** From f0034b4fa1a63b657054a8fbadeea85b6bf38cea Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 5 Oct 2017 11:49:32 -0700 Subject: [PATCH 36/46] Split error code space (#722) * Split error code space This creates two orthogonal spaces for error codes. Application error codes can be used for both connection and stream errors and are under the control of the application protocol. Transport error codes are QUIC-controlled, but can only terminate the connection. To fix this, I had to add IANA considerations for error codes, plus a few extra tweaks. I think that the error code space could be narrowed to 16 bits after this, if only to keep things sane. Closes #132. * s/Public Reset/Stateless Reset/ * Get codes consistent * Make STOP_SENDING application-specific as well * Split errors in HTTP too * Refine description of HTTP codes * Move TLS errors closer * Match the names * Add HTTP_NO_ERROR * Review comments * Jana's comments * Small tweak at Mike's suggestion * Reword STOP_SENDING text to avoid implication of mandatory RST_STREAM * Better track changes on master * Reword advice on application error codes * Steal a code from the application * Simply reserve the RST_STREAM code of 0. * Application error code missed * We really should just call this STOPPING --- draft-ietf-quic-http.md | 101 ++++++------ draft-ietf-quic-tls.md | 46 ++++-- draft-ietf-quic-transport.md | 296 +++++++++++++++++++++-------------- 3 files changed, 266 insertions(+), 177 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 180452b952..90ddbce398 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -872,74 +872,81 @@ establishment to servers. QUIC allows the application to abruptly terminate (reset) individual streams or the entire connection when an error is encountered. These are referred to as "stream errors" or "connection errors" and are described in more detail in -[QUIC-TRANSPORT]. +{{QUIC-TRANSPORT}}. This section describes HTTP-specific error codes which can be used to express the cause of a connection or stream error. -## HTTP-Defined QUIC Error Codes {#http-error-codes} +## HTTP/QUIC Error Codes {#http-error-codes} -QUIC allocates error codes 0x0000-0x3FFF to application protocol definition. The -following error codes are defined by HTTP for use in QUIC RST_STREAM and -CONNECTION_CLOSE frames. +The following error codes are defined for use in QUIC RST_STREAM and +APPLICATION_CLOSE frames when using HTTP/QUIC. -HTTP_PUSH_REFUSED (0x01): +STOPPING (0x00): +: This value is reserved by the transport to be used in response to QUIC + STOP_SENDING frames. + +HTTP_NO_ERROR (0x01): +: No error. This is used when the connection or stream needs to be closed, but + there is no error to signal. + +HTTP_PUSH_REFUSED (0x02): : The server has attempted to push content which the client will not accept on this connection. -HTTP_INTERNAL_ERROR (0x02): +HTTP_INTERNAL_ERROR (0x03): : An internal error has occurred in the HTTP stack. -HTTP_PUSH_ALREADY_IN_CACHE (0x03): +HTTP_PUSH_ALREADY_IN_CACHE (0x04): : The server has attempted to push content which the client has cached. -HTTP_REQUEST_CANCELLED (0x04): +HTTP_REQUEST_CANCELLED (0x05): : The client no longer needs the requested data. -HTTP_HPACK_DECOMPRESSION_FAILED (0x05): +HTTP_HPACK_DECOMPRESSION_FAILED (0x06): : HPACK failed to decompress a frame and cannot continue. -HTTP_CONNECT_ERROR (0x06): +HTTP_CONNECT_ERROR (0x07): : The connection established in response to a CONNECT request was reset or abnormally closed. -HTTP_EXCESSIVE_LOAD (0x07): +HTTP_EXCESSIVE_LOAD (0x08): : The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load. -HTTP_VERSION_FALLBACK (0x08): +HTTP_VERSION_FALLBACK (0x09): : The requested operation cannot be served over HTTP/QUIC. The peer should retry over HTTP/2. -HTTP_MALFORMED_HEADERS (0x09): +HTTP_MALFORMED_HEADERS (0x0A): : A HEADERS frame has been received with an invalid format. -HTTP_MALFORMED_PRIORITY (0x0A): +HTTP_MALFORMED_PRIORITY (0x0B): : A PRIORITY frame has been received with an invalid format. -HTTP_MALFORMED_SETTINGS (0x0B): +HTTP_MALFORMED_SETTINGS (0x0C): : A SETTINGS frame has been received with an invalid format. -HTTP_MALFORMED_PUSH_PROMISE (0x0C): +HTTP_MALFORMED_PUSH_PROMISE (0x0D): : A PUSH_PROMISE frame has been received with an invalid format. -HTTP_MALFORMED_DATA (0x0D): +HTTP_MALFORMED_DATA (0x0E): : A DATA frame has been received with an invalid format. -HTTP_INTERRUPTED_HEADERS (0x0E): +HTTP_INTERRUPTED_HEADERS (0x0F): : A HEADERS frame without the End Header Block flag was followed by a frame other than HEADERS. -HTTP_WRONG_STREAM (0x0F): +HTTP_WRONG_STREAM (0x10): : A frame was received on stream where it is not permitted. -HTTP_MULTIPLE_SETTINGS (0x10): +HTTP_MULTIPLE_SETTINGS (0x11): : More than one SETTINGS frame was received. -HTTP_MALFORMED_PUSH (0x11): +HTTP_MALFORMED_PUSH (0x12): : A push stream header was malformed or included an invalid Push ID. -HTTP_MALFORMED_MAX_PUSH_ID (0x12): +HTTP_MALFORMED_MAX_PUSH_ID (0x13): : A MAX_PUSH_ID frame has been received with an invalid format. @@ -1089,11 +1096,11 @@ QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 provides. However, because the error code space is shared between multiple components, there is no direct portability of HTTP/2 error codes. -The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error -codes as follows: +The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to the HTTP over +QUIC error codes as follows: NO_ERROR (0x0): -: QUIC_NO_ERROR +: HTTP_NO_ERROR in {{http-error-codes}}. PROTOCOL_ERROR (0x1): : No single mapping. See new HTTP_MALFORMED_* error codes defined in @@ -1270,7 +1277,7 @@ The entries in the following table are registered by this document. ## Error Codes {#iana-error-codes} This document establishes a registry for HTTP/QUIC error codes. The -"HTTP/QUIC Error Code" registry manages a 30-bit space. The "HTTP/QUIC +"HTTP/QUIC Error Code" registry manages a 32-bit space. The "HTTP/QUIC Error Code" registry operates under the "Expert Review" policy {{?RFC5226}}. @@ -1285,7 +1292,7 @@ Name: : A name for the error code. Specifying an error code name is optional. Code: -: The 30-bit error code value. +: The 32-bit error code value. Description: : A brief description of the error code semantics, longer if no detailed @@ -1299,24 +1306,26 @@ The entries in the following table are registered by this document. |-----------------------------------|--------|----------------------------------------|----------------------| | Name | Code | Description | Specification | |-----------------------------------|--------|----------------------------------------|----------------------| -| HTTP_PUSH_REFUSED | 0x01 | Client refused pushed content | {{http-error-codes}} | -| HTTP_INTERNAL_ERROR | 0x02 | Internal error | {{http-error-codes}} | -| HTTP_PUSH_ALREADY_IN_CACHE | 0x03 | Pushed content already cached | {{http-error-codes}} | -| HTTP_REQUEST_CANCELLED | 0x04 | Data no longer needed | {{http-error-codes}} | -| HTTP_HPACK_DECOMPRESSION_FAILED | 0x05 | HPACK cannot continue | {{http-error-codes}} | -| HTTP_CONNECT_ERROR | 0x06 | TCP reset or error on CONNECT request | {{http-error-codes}} | -| HTTP_EXCESSIVE_LOAD | 0x07 | Peer generating excessive load | {{http-error-codes}} | -| HTTP_VERSION_FALLBACK | 0x08 | Retry over HTTP/2 | {{http-error-codes}} | -| HTTP_MALFORMED_HEADERS | 0x09 | Invalid HEADERS frame | {{http-error-codes}} | -| HTTP_MALFORMED_PRIORITY | 0x0A | Invalid PRIORITY frame | {{http-error-codes}} | -| HTTP_MALFORMED_SETTINGS | 0x0B | Invalid SETTINGS frame | {{http-error-codes}} | -| HTTP_MALFORMED_PUSH_PROMISE | 0x0C | Invalid PUSH_PROMISE frame | {{http-error-codes}} | -| HTTP_MALFORMED_DATA | 0x0D | Invalid DATA frame | {{http-error-codes}} | -| HTTP_INTERRUPTED_HEADERS | 0x0E | Incomplete HEADERS block | {{http-error-codes}} | -| HTTP_WRONG_STREAM | 0x0F | A frame was sent on the wrong stream | {{http-error-codes}} | -| HTTP_MULTIPLE_SETTINGS | 0x10 | Multiple SETTINGS frames | {{http-error-codes}} | -| HTTP_MALFORMED_PUSH | 0x11 | Invalid push stream header | {{http-error-codes}} | -| HTTP_MALFORMED_MAX_PUSH_ID | 0x12 | Invalid MAX_PUSH_ID frame | {{http-error-codes}} | +| STOPPING | 0x00 | Reserved by QUIC | {{QUIC-TRANSPORT}} | +| HTTP_NO_ERROR | 0x01 | No error | {{http-error-codes}} | +| HTTP_PUSH_REFUSED | 0x02 | Client refused pushed content | {{http-error-codes}} | +| HTTP_INTERNAL_ERROR | 0x03 | Internal error | {{http-error-codes}} | +| HTTP_PUSH_ALREADY_IN_CACHE | 0x04 | Pushed content already cached | {{http-error-codes}} | +| HTTP_REQUEST_CANCELLED | 0x05 | Data no longer needed | {{http-error-codes}} | +| HTTP_HPACK_DECOMPRESSION_FAILED | 0x06 | HPACK cannot continue | {{http-error-codes}} | +| HTTP_CONNECT_ERROR | 0x07 | TCP reset or error on CONNECT request | {{http-error-codes}} | +| HTTP_EXCESSIVE_LOAD | 0x08 | Peer generating excessive load | {{http-error-codes}} | +| HTTP_VERSION_FALLBACK | 0x09 | Retry over HTTP/2 | {{http-error-codes}} | +| HTTP_MALFORMED_HEADERS | 0x0A | Invalid HEADERS frame | {{http-error-codes}} | +| HTTP_MALFORMED_PRIORITY | 0x0B | Invalid PRIORITY frame | {{http-error-codes}} | +| HTTP_MALFORMED_SETTINGS | 0x0C | Invalid SETTINGS frame | {{http-error-codes}} | +| HTTP_MALFORMED_PUSH_PROMISE | 0x0D | Invalid PUSH_PROMISE frame | {{http-error-codes}} | +| HTTP_MALFORMED_DATA | 0x0E | Invalid DATA frame | {{http-error-codes}} | +| HTTP_INTERRUPTED_HEADERS | 0x0F | Incomplete HEADERS block | {{http-error-codes}} | +| HTTP_WRONG_STREAM | 0x10 | A frame was sent on the wrong stream | {{http-error-codes}} | +| HTTP_MULTIPLE_SETTINGS | 0x11 | Multiple SETTINGS frames | {{http-error-codes}} | +| HTTP_MALFORMED_PUSH | 0x12 | Invalid push stream header | {{http-error-codes}} | +| HTTP_MALFORMED_MAX_PUSH_ID | 0x13 | Invalid MAX_PUSH_ID frame | {{http-error-codes}} | |-----------------------------------|--------|----------------------------------------|----------------------| diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 793b4376dc..af9214e2ee 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1506,42 +1506,54 @@ SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack. -# Error codes {#errors} +# Error Codes {#errors} -The portion of the QUIC error code space allocated for the crypto handshake is -0xC0000000-0xFFFFFFFF. The following error codes are defined when TLS is used -for the crypto handshake: +This section defines error codes from the error code space used in +{{QUIC-TRANSPORT}}. -TLS_HANDSHAKE_FAILED (0xC000001C): +The following error codes are defined when TLS is used for the crypto handshake: + +TLS_HANDSHAKE_FAILED (0x201): : The TLS handshake failed. -TLS_FATAL_ALERT_GENERATED (0xC000001D): +TLS_FATAL_ALERT_GENERATED (0x202): : A TLS fatal alert was sent, causing the TLS connection to end prematurely. -TLS_FATAL_ALERT_RECEIVED (0xC000001E): +TLS_FATAL_ALERT_RECEIVED (0x203): : A TLS fatal alert was received, causing the TLS connection to end prematurely. # IANA Considerations -This document does not create any new IANA registries, but it does utilize the -following registries: +This document does not create any new IANA registries, but it registers the +values in the following registries: -* QUIC Transport Parameter Registry - IANA is to register the three values found - in {{errors}}. +* QUIC Transport Error Codes Registry {{QUIC-TRANSPORT}} - IANA is to register + the three error codes found in {{errors}}, these are summarized in + {{iana-errors}}. -* TLS ExtensionsType Registry - IANA is to register the - quic_transport_parameters extension found in {{quic_parameters}}. Assigning - 26 to the extension would be greatly appreciated. The Recommended column is - to be marked Yes. +* TLS ExtensionsType Registry + {{!TLS-REGISTRIES=I-D.ietf-tls-iana-registry-updates}} - IANA is to register + the quic_transport_parameters extension found in {{quic_parameters}}. + Assigning 26 to the extension would be greatly appreciated. The Recommended + column is to be marked Yes. -* TLS Exporter Label Registry - IANA is requested to register - "EXPORTER-QUIC 0-RTT Secret" from {{zero-rtt-secrets}}; +* TLS Exporter Label Registry {{!TLS-REGISTRIES}} - IANA is requested to + register "EXPORTER-QUIC 0-RTT Secret" from {{zero-rtt-secrets}}; "EXPORTER-QUIC client 1-RTT Secret" and "EXPORTER-QUIC server 1-RTT Secret" from {{one-rtt-secrets}}; "EXPORTER-QUIC Packet Number Secret" {{packet-number-gaps}}. The DTLS column is to be marked No. The Recommended column is to be marked Yes. +| Value | Error | Description | Specification | +|:------|:--------------------------|:----------------------|:--------------| +| 0x201 | TLS_HANDSHAKE_FAILED | TLS handshake failure | {{errors}} | +| 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS alert | {{errors}} | +| 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS alert | {{errors}} | +{: #iana-errors title="QUIC Transport Error Codes for TLS"} + + + --- back # Contributors diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 29699e3a92..cb6251b173 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -846,6 +846,7 @@ explained in more detail as they are referenced later in the document. | 0x00 | PADDING | {{frame-padding}} | | 0x01 | RST_STREAM | {{frame-rst-stream}} | | 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | +| 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | | 0x04 | MAX_DATA | {{frame-max-data}} | | 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | | 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | @@ -1500,19 +1501,19 @@ signal the timeout using an immediate close. ### Immediate Close -An endpoint sends a CONNECTION_CLOSE frame to terminate the connection -immediately. A CONNECTION_CLOSE causes all open streams to immediately become -closed; open streams can be assumed to be implicitly reset. After sending or -receiving a CONNECTION_CLOSE frame, endpoints immediately enter a draining -period. +An endpoint sends a CONNECTION_CLOSE or APPLICATION_CLOSE frame to terminate the +connection immediately. Either frame causes all open streams to immediately +become closed; open streams can be assumed to be implicitly reset. After +sending or receiving a CONNECTION_CLOSE frame, endpoints immediately enter a +draining period. -During the draining period, an endpoint that sends a CONNECTION_CLOSE frame -SHOULD respond to any subsequent packet that it receives with another packet -containing a CONNECTION_CLOSE frame. To reduce the state that an endpoint -maintains in this case, it MAY send the exact same packet. However, endpoints -SHOULD limit the number of CONNECTION_CLOSE messages they generate. For -instance, an endpoint could progressively increase the number of packets that it -receives before sending additional CONNECTION_CLOSE frames. +During the draining period, an endpoint that sends a CONNECTION_CLOSE or +APPLICATION_CLOSE frame SHOULD respond to any subsequent packet that it receives +with another packet containing either close frame. To reduce the state that an +endpoint maintains in this case, it MAY send the exact same packet. However, +endpoints SHOULD limit the number of packets they generate containing either +close frame. For instance, an endpoint could progressively increase the number +of packets that it receives before sending additional packets. Note: @@ -1522,9 +1523,9 @@ Note: control, which are not expected to be relevant for a closed connection. Retransmitting the final packet requires less state. -An endpoint can cease sending CONNECTION_CLOSE frames if it receives either a -CONNECTION_CLOSE or an acknowledgement for a packet that contained a -CONNECTION_CLOSE. +An endpoint can cease sending CONNECTION_CLOSE or APPLICATION_CLOSE frames if it +receives either a CONNECTION_CLOSE, APPLICATION_CLOSE or an acknowledgement for +a packet that contained a either close frame. ### Stateless Reset {#stateless-reset} @@ -1533,7 +1534,8 @@ A stateless reset is provided as an option of last resort for a server that does not have access to the state of a connection. A server crash or outage might result in clients continuing to send data to a server that is unable to properly continue the connection. A server that wishes to communicate a fatal connection -error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so. +error MUST use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has +sufficient state to do so. To support this process, the server sends a stateless_reset_token value during the handshake in the transport parameters. This value is protected by @@ -1587,7 +1589,7 @@ indistinguishable from a regular packet. A stateless reset is not appropriate for signaling error conditions. An endpoint that wishes to communicate a fatal connection error MUST use a -CONNECTION_CLOSE frame if it has sufficient state to do so. +CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so. #### Detecting a Stateless Reset @@ -1673,7 +1675,7 @@ The RST_STREAM frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| Application Protocol Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Final Offset (64) + @@ -1687,11 +1689,12 @@ Stream ID: : The 32-bit Stream ID of the stream being terminated. -Error code: +Application Protocol Error Code: -: A 32-bit error code which indicates why the stream is being closed. +: A 32-bit application protocol error code (see {{app-error-codes}}) which + indicates why the stream is being closed. -Final offset: +Final Offset: : A 64-bit unsigned integer indicating the absolute byte offset of the end of data written on this stream by the RST_STREAM sender. @@ -1700,15 +1703,19 @@ Final offset: ## CONNECTION_CLOSE frame {#frame-connection-close} An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its peer that -the connection is being closed. If there are open streams that haven't been -explicitly closed, they are implicitly closed when the connection is closed. -The frame is as follows: +the connection is being closed. CONNECTION_CLOSE is used to signal errors at +the QUIC layer, or the absence of errors (with the NO_ERROR code). + +If there are open streams that haven't been explicitly closed, they are +implicitly closed when the connection is closed. + +The CONNECTION_CLOSE frame is as follows: ~~~ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase Length (16) | [Reason Phrase (*)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1719,6 +1726,9 @@ The fields of a CONNECTION_CLOSE frame are as follows: Error Code: : A 32-bit error code which indicates the reason for closing this connection. + CONNECTION_CLOSE uses codes from the space defined in {{error-codes}} + (APPLICATION_CLOSE uses codes from the application protocol error code space, + see {{app-error-codes}}). Reason Phrase Length: @@ -1734,6 +1744,17 @@ Reason Phrase: This SHOULD be a UTF-8 encoded string {{!RFC3629}}. +## APPLICATION_CLOSE frame {#frame-application-close} + +An APPLICATION_CLOSE frame (type=0x03) uses the same format as the +CONNECTION_CLOSE frame ({{frame-connection-close}}), except that it uses error +codes from the application protocol error code space ({{app-error-codes}}) +instead of the transport error code space. + +Other than the error code space, the format and semantics of the +APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame. + + ## MAX_DATA Frame {#frame-max-data} The MAX_DATA frame (type=0x04) is used in flow control to inform the peer of @@ -1966,8 +1987,9 @@ Stateless Reset Token: An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate that incoming data is being discarded on receipt at application request. This -signals a peer to abruptly terminate transmission on a stream. The frame is as -follows: +signals a peer to abruptly terminate transmission on a stream. + +The STOP_SENDING frame is as follows: ~~~ 0 1 2 3 @@ -1975,17 +1997,21 @@ follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| Application Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields are: Stream ID: + : The 32-bit Stream ID of the stream being ignored. -Error Code: -: The application-specified reason the sender is ignoring the stream. +Application Error Code: + +: A 32-bit, application-specified reason the sender is ignoring the stream (see + {{app-error-codes}}). + ## ACK Frame {#frame-ack} @@ -2709,23 +2735,25 @@ previously-sent STREAM frames. ## Solicited State Transitions -If an endpoint is no longer interested in the data being received, it MAY send a -STOP_SENDING frame on a stream in the "open" or "half-closed (local)" state to -prompt closure of the stream in the opposite direction. This typically -indicates that the receiving application is no longer reading from the stream, -but is not a guarantee that incoming data will be ignored. +If an endpoint is no longer interested in the data it is receiving on a stream, +it MAY send a STOP_SENDING frame identifying that stream to prompt closure of +the stream in the opposite direction. This typically indicates that the +receiving application is no longer reading data it receives from the stream, but +is not a guarantee that incoming data will be ignored. STREAM frames received after sending STOP_SENDING are still counted toward the connection and stream flow-control windows, even though these frames will be discarded upon receipt. This avoids potential ambiguity about which STREAM frames count toward flow control. -Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed -(remote)" states, an endpoint MUST send a RST_STREAM with an error code of -QUIC_RECEIVED_RST. If the STOP_SENDING frame is received on a stream that is -already in the "half-closed (local)" or "closed" states, a RST_STREAM frame MAY -still be sent in order to cancel retransmission of previously-sent STREAM -frames. +STOP_SENDING can only be sent for any stream that is not "idle", however it is +mostly useful for streams in the "open" or "half-closed (local)" states. A +STOP_SENDING frame requests that the receiving application send a RST_STREAM +frame. An endpoint that receives a STOP_SENDING frame MUST send a RST_STREAM +frame for that stream with an error code of STOPPING. If the STOP_SENDING frame +is received on a stream that is already in the "half-closed (local)" or "closed" +states, a RST_STREAM frame MAY still be sent in order to cancel retransmission +of previously-sent STREAM frames. While STOP_SENDING frames are retransmittable, an implementation MAY choose not to retransmit a lost STOP_SENDING frame if the stream has already been closed @@ -3003,32 +3031,39 @@ frame that signals the error. Where this specification identifies error conditions, it also identifies the error code that is used. A stateless reset ({{stateless-reset}}) is not suitable for any error that can -be signaled with a CONNECTION_CLOSE or RST_STREAM frame. A stateless reset MUST -NOT be used by an endpoint that has the state necessary to send a frame on the -connection. +be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame. A +stateless reset MUST NOT be used by an endpoint that has the state necessary to +send a frame on the connection. ## Connection Errors Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire -connection, MUST be signaled using a CONNECTION_CLOSE frame -({{frame-connection-close}}). An endpoint MAY close the connection in this -manner, even if the error only affects a single stream. - -A CONNECTION_CLOSE frame could be sent in a packet that is lost. An endpoint -SHOULD be prepared to retransmit a packet containing a CONNECTION_CLOSE frame if -it receives more packets on a terminated connection. Limiting the number of -retransmissions and the time over which this final packet is sent limits the -effort expended on terminated connections. +connection, MUST be signaled using a CONNECTION_CLOSE or APPLICATION_CLOSE frame +({{frame-connection-close}}, {{frame-application-close}}). An endpoint MAY close +the connection in this manner even if the error only affects a single stream. + +Application protocols can signal application-specific protocol errors using the +APPLICATION_CLOSE frame. Errors that are specific to the transport, including +all those described in this document, are carried in a CONNECTION_CLOSE frame. +Other than the type of error code they carry, these frames are identical in +format and semantics. + +A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is +lost. An endpoint SHOULD be prepared to retransmit a packet containing either +frame type if it receives more packets on a terminated connection. Limiting the +number of retransmissions and the time over which this final packet is sent +limits the effort expended on terminated connections. An endpoint that chooses not to retransmit packets containing CONNECTION_CLOSE -risks a peer missing the first such packet. The only mechanism available to an -endpoint that continues to receive data for a terminated connection is to use -the stateless reset process ({{stateless-reset}}). +or APPLICATION_CLOSE risks a peer missing the first such packet. The only +mechanism available to an endpoint that continues to receive data for a +terminated connection is to use the stateless reset process +({{stateless-reset}}). -An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the -existence of the error to its peer. +An endpoint that receives an invalid CONNECTION_CLOSE or APPLICATION_CLOSE frame +MUST NOT signal the existence of the error to its peer. ## Stream Errors @@ -3042,74 +3077,46 @@ Stream 0 is critical to the functioning of the entire connection. If stream 0 is closed with either a RST_STREAM or STREAM frame bearing the FIN flag, an endpoint MUST generate a connection error of type PROTOCOL_VIOLATION. -Some application protocols make other streams critical to that protocol. An -application protocol does not need to inform the transport that a stream is -critical; it can instead generate appropriate errors in response to being -notified that the critical stream is closed. +RST_STREAM MUST be instigated by the application and MUST carry an application +error code. Resetting a stream without knowledge of the application protocol +could cause the protocol to enter an unrecoverable state. Application protocols +might require certain streams to be reliably delivered in order to guarantee +consistent state between endpoints. -An endpoint MAY send a RST_STREAM frame in the same packet as a CONNECTION_CLOSE -frame. +## Transport Error Codes {#error-codes} -## Error Codes - -Error codes are 32 bits long, with the first two bits indicating the source of -the error code: - -0x00000000-0x3FFFFFFF: -: Application-specific error codes. Defined by each application-layer protocol. - -0x40000000-0x7FFFFFFF: -: Reserved for host-local error codes. These codes MUST NOT be sent to a peer, - but MAY be used in API return codes and logs. - -0x80000000-0xBFFFFFFF: -: QUIC transport error codes, including packet protection errors. Applicable to - all uses of QUIC. - -0xC0000000-0xFFFFFFFF: -: Cryptographic error codes. Defined by the cryptographic handshake protocol - in use. +Transport error codes are 32 bits long. This section lists the defined QUIC transport error codes that may be used in a -CONNECTION_CLOSE or RST_STREAM frame. Error codes share a common code space. -Some error codes apply only to either streams or the entire connection and have -no defined semantics in the other context. +CONNECTION_CLOSE frame. These errors apply to the entire connection. -NO_ERROR (0x80000000): +NO_ERROR (0x0): : An endpoint uses this with CONNECTION_CLOSE to signal that the connection is - being closed abruptly in the absence of any error. An endpoint uses this with - RST_STREAM to signal that the stream is no longer wanted or in response to the - receipt of a RST_STREAM for that stream. + being closed abruptly in the absence of any error. -INTERNAL_ERROR (0x80000001): +INTERNAL_ERROR (0x1): : The endpoint encountered an internal error and cannot continue with the connection. -CANCELLED (0x80000002): - -: An endpoint sends this with RST_STREAM to indicate that the stream is not - wanted and that no application action was taken for the stream. This error - code is not valid for use with CONNECTION_CLOSE. - -FLOW_CONTROL_ERROR (0x80000003): +FLOW_CONTROL_ERROR (0x3): : An endpoint received more data than it permitted in its advertised data limits (see {{flow-control}}). -STREAM_ID_ERROR (0x80000004): +STREAM_ID_ERROR (0x4): : An endpoint received a frame for a stream identifier that exceeded its advertised maximum stream ID. -STREAM_STATE_ERROR (0x80000005): +STREAM_STATE_ERROR (0x5): : An endpoint received a frame for a stream that was not in a state that permitted that frame (see {{stream-states}}). -FINAL_OFFSET_ERROR (0x80000006): +FINAL_OFFSET_ERROR (0x6): : An endpoint received a STREAM frame containing data that exceeded the previously established final offset. Or an endpoint received a RST_STREAM @@ -3117,40 +3124,51 @@ FINAL_OFFSET_ERROR (0x80000006): that was already received. Or an endpoint received a RST_STREAM frame containing a different final offset to the one already established. -FRAME_FORMAT_ERROR (0x80000007): +FRAME_FORMAT_ERROR (0x7): : An endpoint received a frame that was badly formatted. For instance, an empty STREAM frame that omitted the FIN flag, or an ACK frame that has more acknowledgment ranges than the remainder of the packet could carry. This is a generic error code; an endpoint SHOULD use the more specific frame format - error codes (0x800001XX) if possible. + error codes (0x1XX) if possible. -TRANSPORT_PARAMETER_ERROR (0x80000008): +TRANSPORT_PARAMETER_ERROR (0x8): : An endpoint received transport parameters that were badly formatted, included an invalid value, was absent even though it is mandatory, was present though it is forbidden, or is otherwise in error. -VERSION_NEGOTIATION_ERROR (0x80000009): +VERSION_NEGOTIATION_ERROR (0x9): : An endpoint received transport parameters that contained version negotiation parameters that disagreed with the version negotiation that it performed. This error code indicates a potential version downgrade attack. -PROTOCOL_VIOLATION (0x8000000A): +PROTOCOL_VIOLATION (0xA): : An endpoint detected an error with protocol compliance that was not covered by more specific error codes. -QUIC_RECEIVED_RST (0x80000035): - -: Terminating stream because peer sent a RST_STREAM or STOP_SENDING. - -FRAME_ERROR (0x800001XX): +FRAME_ERROR (0x1XX): : An endpoint detected an error in a specific frame type. The frame type is included as the last octet of the error code. For example, an error in a - MAX_STREAM_ID frame would be indicated with the code (0x80000106). + MAX_STREAM_ID frame would be indicated with the code (0x106). + +See {{iana-error-codes}} for details of registering new error codes. + + +## Application Protocol Error Codes {#app-error-codes} + +Application protocol error codes are 32-bits long, but the management of +application error codes are left to application protocols. Application protocol +error codes are used for the RST_STREAM ({{frame-rst-stream}}) and +APPLICATION_CLOSE ({{frame-application-close}}) frames. + +There is no restriction on the use of the 16-bit error code space for +application protocols. However, QUIC reserves the error code with a value of 0 +to mean STOPPING. The application error code of STOPPING (0) is used by the +transport to cancel a stream in response to receipt of a STOP_SENDING frame. # Security and Privacy Considerations @@ -3271,8 +3289,7 @@ accessible. The expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). -The initial contents of this registry are shown in -{{iana-tp-table}}. +The initial contents of this registry are shown in {{iana-tp-table}}. | Value | Parameter Name | Specification | |:-------|:------------------------|:------------------------------------| @@ -3286,6 +3303,57 @@ The initial contents of this registry are shown in {: #iana-tp-table title="Initial QUIC Transport Parameters Entries"} +## QUIC Transport Error Codes Registry {#iana-error-codes} + +IANA \[SHALL add/has added] a registry for "QUIC Transport Error Codes" under a +"QUIC Protocol" heading. + +The "QUIC Transport Error Codes" registry governs a 32-bit space. This space is +split into two spaces that are governed by different policies. Values with the +first byte in the range 0x00 to 0xfe (in hexadecimal) are assigned via the +Specification Required policy {{!RFC5226}}. Values with the first byte 0xff are +reserved for Private Use {{!RFC5226}}. + +Registrations MUST include the following fields: + +Value: + +: The numeric value of the assignment (registrations will be between 0x00000000 + and 0xfeffffff). + +Code: + +: A short mnemonic for the parameter. + +Description: + +: A brief description of the error code semantics, which MAY be a summary if a + specification reference is provided. + +Specification: + +: A reference to a publicly available specification for the value. + +The initial contents of this registry are shown in {{iana-error-table}}. Note +that FRAME_ERROR takes the range from 0x100 to 0x1FF and private use occupies +the range from 0XFE000000 to 0XFFFFFFFF. + +| Value | Error | Description | Specification | +|:------------|:--------------------------|:------------------------------|:----------------| +| 0x0 | NO_ERROR | No error | {{error-codes}} | +| 0x1 | INTERNAL_ERROR | Implementation error | {{error-codes}} | +| 0x3 | FLOW_CONTROL_ERROR | Flow control error | {{error-codes}} | +| 0x4 | STREAM_ID_ERROR | Invalid stream ID | {{error-codes}} | +| 0x5 | STREAM_STATE_ERROR | Frame received in invalid stream state | {{error-codes}} | +| 0x6 | FINAL_OFFSET_ERROR | Change to final stream offset | {{error-codes}} | +| 0x7 | FRAME_FORMAT_ERROR | Generic frame format error | {{error-codes}} | +| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | +| 0x9 | VERSION_NEGOTIATION_ERROR | Version negotiation failure | {{error-codes}} | +| 0xA | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | +| 0x100-0x1FF | FRAME_ERROR | Specific frame format error | {{error-codes}} | +{: #iana-error-table title="Initial QUIC Transport Error Codes Entries"} + + --- back # Contributors From 5cc00feb3ff006e79677cd3632149b29a6c2daf7 Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 5 Oct 2017 23:41:17 -0400 Subject: [PATCH 37/46] Remove Timestamps --- draft-ietf-quic-transport.md | 75 +----------------------------------- 1 file changed, 1 insertion(+), 74 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cb6251b173..285be2deb7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2048,14 +2048,6 @@ A client MUST NOT acknowledge Version Negotiation or Server Stateless Retry packets. These packet types contain packet numbers selected by the client, not the server. -QUIC ACK frames contain a timestamp section with up to 255 timestamps. -Timestamps enable better congestion control, but are not required for correct -loss recovery, and old timestamps are less valuable, so it is not guaranteed -every timestamp will be received by the sender. A receiver SHOULD send a -timestamp exactly once for each received packet containing retransmittable -frames. A receiver MAY send timestamps for non-retransmittable packets. -A receiver MUST not send timestamps in unprotected packets. - A sender MAY intentionally skip packet numbers to introduce entropy into the connection, to avoid opportunistic acknowledgement attacks. The sender SHOULD close the connection if an unsent packet number is acknowledged. The format of @@ -2085,7 +2077,7 @@ An ACK frame is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|[Num Blocks(8)]| NumTS (8) | +|[Num Blocks(8)]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Acknowledged (8/16/32/64) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -2093,8 +2085,6 @@ An ACK frame is shown below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Block Section (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Timestamp Section (*) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ {: #ack-format title="ACK Frame Format"} @@ -2106,11 +2096,6 @@ Num Blocks (opt): blocks (besides the required First ACK Block) in this ACK frame. Only present if the 'N' flag bit is 1. -Num Timestamps: - -: An unsigned 8-bit number specifying the total number of pairs in the Timestamp Section. - Largest Acknowledged: : A variable-sized unsigned value representing the largest packet number the @@ -2128,11 +2113,6 @@ ACK Block Section: : Contains one or more blocks of packet numbers which have been successfully received, see {{ack-block-section}}. -Timestamp Section: - -: Contains zero or more timestamps reporting transit delay of received packets. - See {{timestamp-section}}. - ### ACK Block Section {#ack-block-section} @@ -2179,59 +2159,6 @@ ACK Block Length (opt, repeated): Repeated "Num Blocks" times. -### Timestamp Section {#timestamp-section} - -The Timestamp Section contains between zero and 255 measurements of packet -receive times relative to the beginning of the connection. - -~~~ - 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 -+-+-+-+-+-+-+-+-+ -| [Delta LA (8)]| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| [First Timestamp (32)] | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|[Delta LA 1(8)]| [Time Since Previous 1 (16)] | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|[Delta LA 2(8)]| [Time Since Previous 2 (16)] | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|[Delta LA N(8)]| [Time Since Previous N (16)] | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~ -{: #timestamp-format title="Timestamp Section"} - -The fields in the Timestamp Section are: - -Delta Largest Acknowledged (opt): - -: An optional 8-bit unsigned packet number delta specifying the delta between - the largest acknowledged and the first packet whose timestamp is being - reported. In other words, this first packet number may be computed as - (Largest Acknowledged - Delta Largest Acknowledged.) - -First Timestamp (opt): - -: An optional 32-bit unsigned value specifying the time delta in microseconds, - from the beginning of the connection to the arrival of the packet indicated by - Delta Largest Acknowledged. - -Delta Largest Acked 1..N (opt, repeated): - -: This field has the same semantics and format as "Delta Largest Acknowledged". - Repeated "Num Timestamps - 1" times. - -Time Since Previous Timestamp 1..N(opt, repeated): - -: An optional 16-bit unsigned value specifying time delta from the previous - reported timestamp. It is encoded in the same format as the ACK Delay. - Repeated "Num Timestamps - 1" times. - -The timestamp section lists packet receipt timestamps ordered by timestamp. - - #### Time Format DISCUSS_AND_REPLACE: Perhaps make this format simpler. From 94d820a9b5a7e9798ed90689881b373be06a6508 Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 5 Oct 2017 23:44:40 -0400 Subject: [PATCH 38/46] Remove timestamps from Recovery --- draft-ietf-quic-recovery.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 47b8f1a3c4..fa10c964f6 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -102,8 +102,7 @@ important to the loss detection and congestion control machinery below. machinery of QUIC underneath. * ACK frames contain acknowledgment information. QUIC uses a SACK-based - scheme, where acks express up to 256 ranges. The ACK frame also includes a - receive timestamp for each packet newly acked. + scheme, where acks express up to 256 ranges. ## Relevant Differences Between QUIC and TCP From a0c571b42e22bdbf2f8e49f9fec03c2be6816ab5 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 9 Oct 2017 12:05:34 -0700 Subject: [PATCH 39/46] AEAD all packets. Fixed #693, Fixes #840. This makes the change we discussed in Seattle where all Cleartext packets are encrypted with AES-GCM using a key derived from the client connection ID and a random per-version value. Note: I generated this value using randomness.org. --- draft-ietf-quic-tls.md | 100 ++++++++++++----------------------- draft-ietf-quic-transport.md | 16 ++++-- 2 files changed, 46 insertions(+), 70 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index af9214e2ee..60e2b1eef4 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -632,6 +632,33 @@ QUIC uses HKDF with the same hash function negotiated by TLS for key derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the SHA-256 hash function is used. +### Cleartext Packet Secrets {#cleartext-secrets} + +Cleartext packets are protected with secrets derived from the client's +connection ID. Specifically: + +~~~ + quic_version_1_salt = ed 1d a2 c6 0b ae 80 03 eb db 17 d8 92 5d 95 92 + 4a 6e 87 57 cd 48 d9 bf d2 41 c7 19 cb 80 81 ef + + cleartext_secret = HKDF-Extract(quic_version_1_salt, + client_connection_id) + + client_cleartext_secret = + HKDF-Expand-Label(cleartext_secret, + "QUIC client cleartext Secret", + "", Hash.length) + server_cleartext_secret = + HKDF-Expand-Label(cleartext_secret, + "QUIC server cleartext Secret", + "", Hash.length) +~~~ + +Future versions of QUIC SHOULD generate a new salt value, thus ensuring +that the keys are different for each version of QUIC. This prevents +a middlebox that only recognizes one version of QUIC from seeing or +modifying the contents of cleartext packets from future versions. + ### 0-RTT Secret {#zero-rtt-secrets} @@ -758,8 +785,11 @@ used for QUIC packet protection is AEAD that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. -Regular QUIC packets are protected by an AEAD algorithm {{!RFC5116}}. Version -negotiation and public reset packets are not protected. +All QUIC packets other than version negotiation and public reset packets are +protected with an AEAD algorithm {{!RFC5116}}. Cleartext packets are protected +with the AEAD_AES_128_GCM and a key derived from the client's connection ID. +This provides protection against off-path attackers and robustness against +QUIC version unaware middleboxes, but not against on-path attackers. Once TLS has provided a key, the contents of regular QUIC packets immediately after any TLS messages have been sent are protected by the AEAD selected by TLS. @@ -838,64 +868,6 @@ number gaps on connection ID transitions. That secret is computed as: "", Hash.length) ~~~ -# Unprotected Packets - -QUIC adds an integrity check to all cleartext packets. Cleartext packets are -not protected by the negotiated AEAD (see {{packet-protection}}), but instead -include an integrity check. This check does not prevent the packet from being -altered, it exists for added resilience against data corruption and to provide -added assurance that the sender intends to use QUIC. - -Cleartext packets all use the long form of the QUIC header and so will include a -version number. For this version of QUIC, the integrity check uses the 64-bit -FNV-1a hash (see {{fnv1a}}). The output of this hash is appended to the payload -of the packet. - -The integrity check algorithm MAY change for other versions of the protocol. - - -## Integrity Check Processing - -An endpoint sending a packet that has a long header and a type that does not -indicate that the packet will be protected (that is, 0-RTT Encrypted (0x05), -1-RTT Encrypted (key phase 0) (0x06), or 1-RTT Encrypted (key phase 1) (0x07)) -first constructs the packet that it sends without the integrity check. - -The sender then calculates the integrity check over the entire packet, starting -from the type field. The output of the hash is appended to the packet. - -A receiver that receives an unprotected packet first checks that the version is -correct, then removes the trailing 8 octets. It calculates the integrity check -over the remainder of the packet. Unprotected packets that do not contain a -valid integrity check MUST be discarded. - - -## The 64-bit FNV-1a Algorithm {#fnv1a} - -QUIC uses the 64-bit version of the alternative Fowler/Noll/Vo hash (FNV-1a) -{{?FNV=I-D.eastlake-fnv}}. - -FNV-1a can be expressed in pseudocode as: - -~~~ -hash := offset basis -for each input octet: - hash := hash XOR input octet - hash := hash * prime -~~~ - -That is, a 64-bit unsigned integer is initialized with an offset basis. Then, -for each octet of the input, the exclusive binary OR of the value is taken, then -multiplied by a prime. Any overflow from multiplication is discarded. - -The offset basis for the 64-bit FNV-1a is the decimal value 14695981039346656037 -(in hex, 0xcbf29ce484222325). The prime is 1099511628211 (in hex, -0x100000001b3; or as an expression 2^40 + 2^8 + 0xb3). - -Once all octets have been processed in this fashion, the final integer value is -encoded as 8 octets in network byte order. - - # Key Phases As TLS reports the availability of 0-RTT and 1-RTT keys, new keying material can @@ -924,10 +896,8 @@ ensure that TLS handshake messages are sent with the correct packet protection. ## Packet Protection for the TLS Handshake {#cleartext-hs} -The initial exchange of packets are sent without protection. These packets use -a cleartext packet type. - -TLS handshake messages MUST NOT be protected using QUIC packet protection. All +The initial exchange of packets are sent using a cleartext packet type and +AEAD-protected using the initial key as described in {{cleartext-secrets}}. All TLS handshake messages up to the TLS Finished message sent by either endpoint use cleartext packets. @@ -944,7 +914,7 @@ client in cleartext packets. ### Initial Key Transitions {#first-keys} Once the TLS handshake is complete, keying material is exported from TLS and -QUIC packet protection commences. +used to protect QUIC packets. Packets protected with 1-RTT keys initially have a KEY_PHASE bit set to 0. This bit inverts with each subsequent key update (see {{key-update}}). diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 285be2deb7..3e6a99edcf 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -555,8 +555,11 @@ Cleartext packets are sent during the handshake prior to key negotiation. All cleartext packets contain the current QUIC version in the version field. -The payload of cleartext packets also includes an integrity check, which is -described in {{QUIC-TLS}}. +In order to prevent tampering by version-unaware middleboxes, Cleartext +packets are protected with a connection and version specific key, as +described in {{QUIC-TLS}}. This protection does not provide confidentiality +or integrity against on-path attackers, but provides some level of +protection against off-path attackers. ### Client Initial Packet {#packet-client-initial} @@ -926,8 +929,9 @@ Version Negotiation packet. A client MUST ignore a Version Negotiation packet that lists the client's chosen version. -Version negotiation uses unprotected data. The result of the negotiation MUST be -revalidated as part of the cryptographic handshake (see {{version-validation}}). +Version negotiation packets have no cryptographic protection. The +result of the negotiation MUST be revalidated as part of the +cryptographic handshake (see {{version-validation}}). ### Using Reserved Versions @@ -1638,6 +1642,8 @@ connection that is reset by revealing the Stateless Reset Token cannot be reused for new connections at the same server without first changing to use a different static key or server identifier. +Note that Stateless Reset messages do not have any cryptographic protection. + # Frame Types and Formats @@ -3316,7 +3322,7 @@ Issue and pull request numbers are listed with a leading octothorp. ## Since draft-ietf-quic-transport-06 -Nothing yet. +- Replaced FNV-1a with AES-GCM for all "Cleartext" packets. ## Since draft-ietf-quic-transport-05 From cf605489cedb96ccc796ba5735d132e81b5e56c4 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 9 Oct 2017 16:58:17 -0700 Subject: [PATCH 40/46] Update salt. This salt isn't random but rather is the git hash of the revision corresponding to the -06 drafts. It's still essentially arbitrary but now it's predictable arbitrary. --- draft-ietf-quic-tls.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 60e2b1eef4..8f560c528a 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -638,8 +638,7 @@ Cleartext packets are protected with secrets derived from the client's connection ID. Specifically: ~~~ - quic_version_1_salt = ed 1d a2 c6 0b ae 80 03 eb db 17 d8 92 5d 95 92 - 4a 6e 87 57 cd 48 d9 bf d2 41 c7 19 cb 80 81 ef + quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639 cleartext_secret = HKDF-Extract(quic_version_1_salt, client_connection_id) @@ -896,10 +895,10 @@ ensure that TLS handshake messages are sent with the correct packet protection. ## Packet Protection for the TLS Handshake {#cleartext-hs} -The initial exchange of packets are sent using a cleartext packet type and -AEAD-protected using the initial key as described in {{cleartext-secrets}}. All -TLS handshake messages up to the TLS Finished message sent by either endpoint -use cleartext packets. +The initial exchange of packets are sent using a cleartext packet type +and AEAD-protected using the cleartext key generated as described in +{{cleartext-secrets}}. All TLS handshake messages up to the TLS +Finished message sent by either endpoint use cleartext packets. Any TLS handshake messages that are sent after completing the TLS handshake do not need special packet protection rules. Packets containing these messages use From 66ab0da60e2f91a8ac2c141c4ca9e9834a9bf1ad Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Oct 2017 12:05:35 +1100 Subject: [PATCH 41/46] Followup for cleartext AEAD change The change in #844 didn't mention the hash function used with HKDF. It is pretty obviously SHA-256, but we need to write that down. Also a few editorial changes. --- draft-ietf-quic-tls.md | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 8f560c528a..888685ed5e 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -44,6 +44,14 @@ normative: org: Mozilla role: editor + FIPS180: + title: NIST FIPS 180-4, Secure Hash Standard + author: + name: NIST + ins: National Institute of Standards and Technology, U.S. Department of Commerce + date: 2012-03 + target: http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf + informative: AEBounds: @@ -632,6 +640,7 @@ QUIC uses HKDF with the same hash function negotiated by TLS for key derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the SHA-256 hash function is used. + ### Cleartext Packet Secrets {#cleartext-secrets} Cleartext packets are protected with secrets derived from the client's @@ -653,10 +662,14 @@ connection ID. Specifically: "", Hash.length) ~~~ -Future versions of QUIC SHOULD generate a new salt value, thus ensuring -that the keys are different for each version of QUIC. This prevents -a middlebox that only recognizes one version of QUIC from seeing or -modifying the contents of cleartext packets from future versions. +The HKDF for the cleartext packet protection keys uses the SHA-256 hash function +{{FIPS180}}. + +The salt value is a 16 octet sequence shown in the figure in hexadecimal +notation. Future versions of QUIC SHOULD generate a new salt value, thus +ensuring that the keys are different for each version of QUIC. This prevents a +middlebox that only recognizes one version of QUIC from seeing or modifying the +contents of cleartext packets from future versions. ### 0-RTT Secret {#zero-rtt-secrets} @@ -784,11 +797,12 @@ used for QUIC packet protection is AEAD that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. -All QUIC packets other than version negotiation and public reset packets are +All QUIC packets other than Version Negotiation and Stateless Reset packets are protected with an AEAD algorithm {{!RFC5116}}. Cleartext packets are protected -with the AEAD_AES_128_GCM and a key derived from the client's connection ID. -This provides protection against off-path attackers and robustness against -QUIC version unaware middleboxes, but not against on-path attackers. +with AEAD_AES_128_GCM and a key derived from the client's connection ID (see +{{cleartext-secrets}}). This provides protection against off-path attackers and +robustness against QUIC version unaware middleboxes, but not against on-path +attackers. Once TLS has provided a key, the contents of regular QUIC packets immediately after any TLS messages have been sent are protected by the AEAD selected by TLS. From 372c1e6c942ec496474677a1e141d4c2afcd8702 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Oct 2017 09:41:14 +1100 Subject: [PATCH 42/46] capitalize STREAM --- 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 a0291f75a2..15d5ba854f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -621,7 +621,7 @@ the flow, but other transport state MUST be discarded. The payload of the Server Stateless Retry packet contains a single STREAM frame on stream 0 with offset 0 containing the server's cryptographic stateless retry material. It MUST NOT contain any other -frames. Any future stream frames from the server will also start at +frames. Any future STREAM frames from the server will also start at stream offset 0. From 7aca15726ef848fbc7705347d664e6cbde41b5b3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Oct 2017 09:45:01 +1100 Subject: [PATCH 43/46] Version Negotiation packet format is version-invariant (#819) Otherwise, version negotiation doesn't work. --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 72d1ecc1b3..8e3eb597b3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -428,8 +428,6 @@ a long header packet are version-independent. The types of packets defined in {{long-packet-types}} are version-specific. See {{version-specific}} for details on how packets from different versions of QUIC are interpreted. -(TODO: Should the list of packet types be version-independent?) - The interpretation of the fields and the payload are specific to a version and packet type. Type-specific semantics for this version are described in the following sections. @@ -795,9 +793,11 @@ constant: * the location and size of the Connection ID field in both header forms, -* the location and size of the Version field in long headers, and +* the location and size of the Version field in long headers, + +* the location and size of the Packet Number field in long headers, and -* the location and size of the Packet Number field in long headers. +* the type, format and semantics of the Version Negotiation packet. Implementations MUST assume that an unsupported version uses an unknown packet format. All other fields MUST be ignored when processing a packet that contains From 871ec714d8e162e21e023181fa9b73c4eaef79c6 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Oct 2017 09:45:12 +1100 Subject: [PATCH 44/46] Fixup for #817 --- draft-ietf-quic-transport.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8e3eb597b3..f8b70e9042 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -619,11 +619,10 @@ any version negotiation that occurred (see {{version-negotiation}}). The client MAY also retain any observed RTT or congestion state that it has accumulated for the flow, but other transport state MUST be discarded. -The payload of the Server Stateless Retry packet contains a single -STREAM frame on stream 0 with offset 0 containing the server's -cryptographic stateless retry material. It MUST NOT contain any other -frames. Any future STREAM frames from the server will also start at -stream offset 0. +The payload of the Server Stateless Retry packet contains a single STREAM frame +on stream 0 with offset 0 containing the server's cryptographic stateless retry +material. It MUST NOT contain any other frames. The next STREAM frame sent by +the server will also start at stream offset 0. ### Server Cleartext Packet {#packet-server-cleartext} From 552b6bc82363895d9bda73fd7598381ee4667609 Mon Sep 17 00:00:00 2001 From: Patrick McManus Date: Thu, 21 Sep 2017 17:38:49 -0400 Subject: [PATCH 45/46] HTTP Integration Error Nits * error codes can be used with stop_sending --- draft-ietf-quic-http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 90ddbce398..fc092c3220 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -879,8 +879,8 @@ the cause of a connection or stream error. ## HTTP/QUIC Error Codes {#http-error-codes} -The following error codes are defined for use in QUIC RST_STREAM and -APPLICATION_CLOSE frames when using HTTP/QUIC. +The following error codes are defined for use in QUIC RST_STREAM, STOP_SENDING, +and CONNECTION_CLOSE frames when using HTTP/QUIC. STOPPING (0x00): : This value is reserved by the transport to be used in response to QUIC From 8c08acc0251010f8d98118b651bf28ce2263ae54 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 5 Oct 2017 12:22:08 -0700 Subject: [PATCH 46/46] Make error codes smaller --- draft-ietf-quic-http.md | 4 ++-- draft-ietf-quic-transport.md | 35 ++++++++++++++++++----------------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index fc092c3220..1640a3ae6a 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1277,7 +1277,7 @@ The entries in the following table are registered by this document. ## Error Codes {#iana-error-codes} This document establishes a registry for HTTP/QUIC error codes. The -"HTTP/QUIC Error Code" registry manages a 32-bit space. The "HTTP/QUIC +"HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/QUIC Error Code" registry operates under the "Expert Review" policy {{?RFC5226}}. @@ -1292,7 +1292,7 @@ Name: : A name for the error code. Specifying an error code name is optional. Code: -: The 32-bit error code value. +: The 16-bit error code value. Description: : A brief description of the error code semantics, longer if no detailed diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8bef871f0e..801fe0f21c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1681,7 +1681,7 @@ The RST_STREAM frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Application Protocol Error Code (32) | +| Application Error Code (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Final Offset (64) + @@ -1697,7 +1697,7 @@ Stream ID: Application Protocol Error Code: -: A 32-bit application protocol error code (see {{app-error-codes}}) which +: A 16-bit application protocol error code (see {{app-error-codes}}) which indicates why the stream is being closed. Final Offset: @@ -1721,9 +1721,9 @@ The CONNECTION_CLOSE frame is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| Error Code (16) | Reason Phrase Length (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Reason Phrase Length (16) | [Reason Phrase (*)] ... +| Reason Phrase Length (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ @@ -1731,7 +1731,7 @@ The fields of a CONNECTION_CLOSE frame are as follows: Error Code: -: A 32-bit error code which indicates the reason for closing this connection. +: A 16-bit error code which indicates the reason for closing this connection. CONNECTION_CLOSE uses codes from the space defined in {{error-codes}} (APPLICATION_CLOSE uses codes from the application protocol error code space, see {{app-error-codes}}). @@ -2003,8 +2003,8 @@ The STOP_SENDING frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Application Error Code (32) | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Application Error Code (16) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields are: @@ -2015,7 +2015,7 @@ Stream ID: Application Error Code: -: A 32-bit, application-specified reason the sender is ignoring the stream (see +: A 16-bit, application-specified reason the sender is ignoring the stream (see {{app-error-codes}}). @@ -3025,7 +3025,7 @@ consistent state between endpoints. ## Transport Error Codes {#error-codes} -Transport error codes are 32 bits long. +QUIC error codes are 16 bit unsigned integers. This section lists the defined QUIC transport error codes that may be used in a CONNECTION_CLOSE frame. These errors apply to the entire connection. @@ -3099,10 +3099,11 @@ See {{iana-error-codes}} for details of registering new error codes. ## Application Protocol Error Codes {#app-error-codes} -Application protocol error codes are 32-bits long, but the management of -application error codes are left to application protocols. Application protocol -error codes are used for the RST_STREAM ({{frame-rst-stream}}) and -APPLICATION_CLOSE ({{frame-application-close}}) frames. +Application protocol error codes are 16 bit unsigned integers, but the +management of application error codes are left to application protocols. +Application protocol error codes are used for the RST_STREAM +({{frame-rst-stream}}) and APPLICATION_CLOSE ({{frame-application-close}}) +frames. There is no restriction on the use of the 16-bit error code space for application protocols. However, QUIC reserves the error code with a value of 0 @@ -3247,7 +3248,7 @@ The initial contents of this registry are shown in {{iana-tp-table}}. IANA \[SHALL add/has added] a registry for "QUIC Transport Error Codes" under a "QUIC Protocol" heading. -The "QUIC Transport Error Codes" registry governs a 32-bit space. This space is +The "QUIC Transport Error Codes" registry governs a 16-bit space. This space is split into two spaces that are governed by different policies. Values with the first byte in the range 0x00 to 0xfe (in hexadecimal) are assigned via the Specification Required policy {{!RFC5226}}. Values with the first byte 0xff are @@ -3257,8 +3258,8 @@ Registrations MUST include the following fields: Value: -: The numeric value of the assignment (registrations will be between 0x00000000 - and 0xfeffffff). +: The numeric value of the assignment (registrations will be between 0x0000 and + 0xfeff). Code: @@ -3275,7 +3276,7 @@ Specification: The initial contents of this registry are shown in {{iana-error-table}}. Note that FRAME_ERROR takes the range from 0x100 to 0x1FF and private use occupies -the range from 0XFE000000 to 0XFFFFFFFF. +the range from 0xFE00 to 0xFFFF. | Value | Error | Description | Specification | |:------------|:--------------------------|:------------------------------|:----------------|