├── .editorconfig ├── .github ├── in-solidarity.yml └── workflows │ ├── archive.yml │ ├── ghpages.yml │ └── publish.yml ├── .gitignore ├── CONTRIBUTING.md ├── Makefile ├── README.md ├── draft-ietf-quic-applicability.md ├── draft-ietf-quic-manageability.md └── writeups ├── quic-applicability.txt └── quic-manageability.txt /.editorconfig: -------------------------------------------------------------------------------- 1 | # See http://editorconfig.org 2 | 3 | root = true 4 | 5 | [*.md] 6 | charset = utf-8 7 | end_of_line = lf 8 | indent_size = 2 9 | indent_style = space 10 | insert_final_newline = true 11 | max_line_length = 80 12 | trim_trailing_whitespace = true 13 | -------------------------------------------------------------------------------- /.github/in-solidarity.yml: -------------------------------------------------------------------------------- 1 | _extends: ietf/terminology 2 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | 9 | jobs: 10 | build: 11 | name: "Archive Issues and Pull Requests" 12 | runs-on: ubuntu-latest 13 | steps: 14 | - name: "Checkout" 15 | uses: actions/checkout@v2 16 | 17 | - name: "Update Archive" 18 | uses: martinthomson/i-d-template@v1 19 | with: 20 | make: archive 21 | token: ${{ secrets.GITHUB_TOKEN }} 22 | 23 | - name: "Update GitHub Pages" 24 | uses: martinthomson/i-d-template@v1 25 | with: 26 | make: gh-archive 27 | token: ${{ secrets.GITHUB_TOKEN }} 28 | 29 | - name: "Save Archive" 30 | uses: actions/upload-artifact@v2 31 | with: 32 | path: archive.json 33 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v2 24 | 25 | - name: "Cache Setup" 26 | id: cache-setup 27 | run: | 28 | mkdir -p "$HOME"/.cache/xml2rfc 29 | echo "::set-output name=path::$HOME/.cache/xml2rfc" 30 | date -u "+::set-output name=date::%FT%T" 31 | 32 | - name: "Cache References" 33 | uses: actions/cache@v2 34 | with: 35 | path: ${{ steps.cache-setup.outputs.path }} 36 | key: refcache-${{ steps.cache-setup.outputs.date }} 37 | restore-keys: | 38 | refcache-${{ steps.cache-setup.outputs.date }} 39 | refcache- 40 | 41 | - name: "Build Drafts" 42 | uses: martinthomson/i-d-template@v1 43 | 44 | - name: "Update GitHub Pages" 45 | uses: martinthomson/i-d-template@v1 46 | if: ${{ github.event_name == 'push' }} 47 | with: 48 | make: gh-pages 49 | token: ${{ secrets.GITHUB_TOKEN }} 50 | 51 | - name: "Save HTML" 52 | uses: actions/upload-artifact@v2 53 | with: 54 | path: "*.html" 55 | 56 | - name: "Save Text" 57 | uses: actions/upload-artifact@v2 58 | with: 59 | path: "*.txt" 60 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | 8 | jobs: 9 | build: 10 | name: "Publish New Draft Version" 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: "Checkout" 14 | uses: actions/checkout@v2 15 | 16 | # See https://github.com/actions/checkout/issues/290 17 | - name: "Get Tag Annotations" 18 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 19 | 20 | - name: "Cache Setup" 21 | id: cache-setup 22 | run: | 23 | mkdir -p "$HOME"/.cache/xml2rfc 24 | echo "::set-output name=path::$HOME/.cache/xml2rfc" 25 | date -u "+::set-output name=date::%FT%T" 26 | 27 | - name: "Cache References" 28 | uses: actions/cache@v2 29 | with: 30 | path: ${{ steps.cache-setup.outputs.path }} 31 | key: refcache-${{ steps.date.outputs.date }} 32 | restore-keys: | 33 | refcache-${{ steps.date.outputs.date }} 34 | refcache- 35 | 36 | - name: "Build Drafts" 37 | uses: martinthomson/i-d-template@v1 38 | 39 | - name: "Upload to Datatracker" 40 | uses: martinthomson/i-d-template@v1 41 | with: 42 | make: upload 43 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.redxml 2 | *.txt 3 | *.html 4 | *.pdf 5 | *~ 6 | *.swp 7 | /*-[0-9][0-9].xml 8 | .refcache 9 | .targets.mk 10 | venv/ 11 | issues.json 12 | lib 13 | draft-kuehlewind-quic-appman.md 14 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to the QUIC Operations drafts 2 | 3 | Before submitting feedback, please familiarize yourself with the working group [charter](https://datatracker.ietf.org/wg/quic/about/), the [base drafts](https://github.com/quicwg/base-drafts/) on which the operations drafts are based, and our current [issues list](https://github.com/quicwg/ops-drafts/issues). If you're 4 | new to this, you may also want to read the [Tao of the IETF](https://www.ietf.org/tao.html). 5 | 6 | **Be aware that all contributions fall under the "NOTE WELL" terms outlined below.** 7 | 8 | ## Following Discussion 9 | 10 | The Working Group has a few venues for discussion: 11 | 12 | * We plain 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/). 13 | 14 | * 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. 15 | 16 | * We also discuss specific issues on the appropriate issues list in [GitHub](https://github.com/quicwg/). If you don't want to use GitHub to follow these discussions, you can subscribe to the [issue announce list](https://www.ietf.org/mailman/listinfo/quic-issues). 17 | 18 | To be active in the Working Group, you can participate in any of these places. Most activity takes 19 | place on the mailing list, but if you just want to comment on and raise issues, that's fine too. 20 | 21 | ## Raising Issues 22 | 23 | We use our [GitHub](https://github.com/quicwg/ops-drafts) issues lists to track items for discussion and 24 | their resolution. 25 | 26 | Before filing a new issue on the operations drafts, please consider a few things: 27 | 28 | * Issues should be just that; issues with our deliverables, **not questions or support requests**. 29 | * Please review the issues list to make sure that you aren't filing a duplicate. 30 | * The operations drafts are intended to track applicability and manageability aspects of the QUIC protocol as defined by the latest version of the [base drafts](https://github.com/quicwg/base-drafts). Discussion about changing the definition of the protocol to support a particular application and/or to change the manageability aspects of the protocol should be discussed as [issues](https://github.com/quicwg/base-drafts) there. 31 | * If you're not sure how to phrase your issue, please ask on the [mailing list](https://www.ietf.org/mailman/listinfo/quic). 32 | 33 | Issues can also be raised on the [Working Group mailing 34 | list](https://www.ietf.org/mailman/listinfo/quic) by clearly marking them as such (e.g., "New 35 | Issue" in the `Subject:` line). 36 | 37 | Be aware that issues might be rephrased, changed in scope, or combined with others, so that the 38 | group can focus its efforts. If you feel that such a change loses an important part of your 39 | original issue, please bring it up, either in comments or on the list. 40 | 41 | Off-topic and duplicate issues will be closed without discussion. Note that comments on individual 42 | commits will only be responded to with best effort, and may not be seen. 43 | 44 | 45 | ## Resolving Issues 46 | 47 | Issues will be labeled by the Chairs as either `editorial` or `design`: 48 | 49 | * **Design** issues require discussion and consensus in the Working Group. This discussion can happen both in the issue and on the [Working Group mailing list](https://www.ietf.org/mailman/listinfo/quic), as outlined below. Note that design issues on the ops drafts primarily concern the scope of the drafts themselves (i.e., whether a certain aspect of management or a certain application should be considered by the draft). Design proposals impacting applicability and manageability of the QUIC protocol should be discussed as [issues](https://github.com/quicwg/base-drafts) on the base drafts. 50 | 51 | * **Editorial** issues can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself. 52 | 53 | The `open` design issues in the issues list are those that we are currently or plan to discuss. When a design issue is `closed`, it implies that the issue has a proposed resolution that is reflected in the drafts; if a `closed` design issue is labeled with `has-consensus`, it means that the incorporated resolution has Working Group consensus. 54 | 55 | Design issues can be discussed on the mailing list or the issues list. The editors can also propose resolutions to design issues for the group's consideration by incorporating them into the draft(s). 56 | 57 | When a new draft is published, the design issues that have been closed since the last draft will be highlighted on the mailing list, to aid reviewers. Once consensus is confirmed, those issues will be labeled with [`has-consensus`](https://github.com/quicwg/base-drafts/issues?utf8=✓&q=label%3Ahas-consensus%20). 58 | 59 | Note that whether or not a design issue is closed does **not** reflect consensus of the Working Group; an issue's `open`/`closed` state is only used to organise our discussions. If you have a question or problem with an issue in the `closed` state, please comment on it (either in the issues list or mailing list), and we'll adjust its state accordingly. Note that reopening issues with `has-consensus` requires new information. 60 | 61 | 62 | ## Pull Requests 63 | 64 | We welcome pull requests, both for editorial suggestions and to resolve open issues. In the latter 65 | case, please identify the relevant issue. 66 | 67 | Please do not use a pull request to open a new issue; it may not be noticed. 68 | 69 | 70 | ## Code of Conduct 71 | 72 | The [IETF Guidelines for Conduct](https://tools.ietf.org/html/rfc7154) applies to all Working Group 73 | communications and meetings. 74 | 75 | 76 | ## NOTE WELL 77 | 78 | Any submission to the [IETF](https://www.ietf.org/) intended by the Contributor for publication as 79 | all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF 80 | activity is considered an "IETF Contribution". Such statements include oral statements in IETF 81 | sessions, as well as written and electronic communications made at any time or place, which are 82 | addressed to: 83 | 84 | * The IETF plenary session 85 | * The IESG, or any member thereof on behalf of the IESG 86 | * Any IETF mailing list, including the IETF list itself, any working group 87 | or design team list, or any other list functioning under IETF auspices 88 | * Any IETF working group or portion thereof 89 | * Any Birds of a Feather (BOF) session 90 | * The IAB or any member thereof on behalf of the IAB 91 | * The RFC Editor or the Internet-Drafts function 92 | * All IETF Contributions are subject to the rules of 93 | [RFC 5378](https://tools.ietf.org/html/rfc5378) and 94 | [RFC 8179](https://tools.ietf.org/html/rfc8179). 95 | 96 | Statements made outside of an IETF session, mailing list or other function, that are clearly not 97 | intended to be input to an IETF activity, group or function, are not IETF Contributions in the 98 | context of this notice. 99 | 100 | Please consult [RFC 5378](https://tools.ietf.org/html/rfc5378) and [RFC 8179](https://tools.ietf.org/html/rfc8179) for details. 101 | 102 | A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in 103 | Best Current Practices RFCs and IESG Statements. 104 | 105 | A participant in any IETF activity acknowledges that written, audio and video records of meetings 106 | may be made and may be available to the public. 107 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | MD_PREPROCESSOR := sed -e 's/{DATE}/$(shell date '+%Y-%m')/g' 2 | 3 | include lib/main.mk 4 | 5 | lib/main.mk: 6 | ifneq (,$(shell git submodule status lib 2>/dev/null)) 7 | git submodule sync 8 | git submodule update --init 9 | else 10 | git clone -q --depth 10 -b main https://github.com/martinthomson/i-d-template.git lib 11 | endif 12 | 13 | latest:: 14 | @err=0; for f in draft-*.md ; do \ 15 | if grep -n ' $$' "$$f"; then \ 16 | echo "$$f contains trailing whitespace"; err=1; \ 17 | fi; \ 18 | if cat "$$f" | (l=0; while read -r a; do l=$$(($$l + 1)); echo -E "$$l:$$a"; done) | \ 19 | sed -e '1,/--- abstract/d;/^[0-9]*: *|/d' | tr -d '\r' | grep '^[0-9]*:.\{81\}'; then \ 20 | echo "$$f contains a line with >80 characters"; err=1; \ 21 | fi; \ 22 | if cat "$$f" | (l=0; while read -r a; do l=$$(($$l + 1)); echo -E "$$l:$$a"; done) | \ 23 | sed -e '/^[0-9]*:~~~/,/^[0-9]*:~~~/p;/^[0-9]*:```/,/^[0-9]*:```/p;d' | \ 24 | tr -d '\r' | grep '^[0-9]*:.\{70\}'; then \ 25 | echo "$$f contains a figure with >69 characters"; err=1; \ 26 | fi; \ 27 | done; [ "$$err" -eq 0 ] 28 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # QUIC Operations Drafts 2 | 3 | This is the working area for the IETF QUIC Working Group documents covering 4 | the applicability and manageability of the QUIC transport protocol. 5 | 6 | ## Applicability 7 | 8 | * [Editor's copy](https://quicwg.github.io/ops-drafts/draft-ietf-quic-applicability.html) 9 | * [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-applicability) 10 | * [Compare Individual Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-applicability.txt&url2=https://quicwg.github.io/ops-drafts/draft-ietf-quic-applicability.txt) 11 | 12 | ## Manageability 13 | 14 | * [Editor's copy](https://quicwg.github.io/ops-drafts/draft-ietf-quic-manageability.html) 15 | * [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-manageability) 16 | * [Compare Individual Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-manageability.txt&url2=https://quicwg.github.io/ops-drafts/draft-ietf-quic-manageability.txt) 17 | 18 | ## Building the Draft 19 | 20 | Formatted text and HTML versions of the draft can be built using `make`. 21 | 22 | ```sh 23 | $ make 24 | ``` 25 | 26 | This requires that you have the necessary software installed. See [the 27 | instructions](https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md). 28 | 29 | 30 | ## Contributing 31 | 32 | See our 33 | [guidelines for contribution](https://github.com/quicwg/ops-drafts/blob/master/CONTRIBUTING.md). 34 | -------------------------------------------------------------------------------- /draft-ietf-quic-applicability.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Applicability of the QUIC Transport Protocol 3 | abbrev: QUIC Applicability 4 | docname: draft-ietf-quic-applicability-latest 5 | date: 6 | category: info 7 | 8 | ipr: trust200902 9 | keyword: Internet-Draft 10 | 11 | stand_alone: yes 12 | pi: [toc, sortrefs, symrefs] 13 | 14 | author: 15 | - 16 | ins: M. Kühlewind 17 | name: Mirja Kühlewind 18 | org: Ericsson 19 | email: mirja.kuehlewind@ericsson.com 20 | - 21 | ins: B. Trammell 22 | name: Brian Trammell 23 | org: Google 24 | email: ietf@trammell.ch 25 | street: Gustav-Gull-Platz 1 26 | city: 8004 Zurich 27 | country: Switzerland 28 | 29 | informative: 30 | Trammell16: 31 | title: Internet Path Transparency Measurements using RIPE Atlas (RIPE72 MAT presentation) 32 | author: 33 | - 34 | ins: B. Trammell 35 | - 36 | ins: M. Kühlewind 37 | target: https://ripe72.ripe.net/wp-content/uploads/presentations/86-atlas-udpdiff.pdf 38 | date: 2016-05-25 39 | Edeline16: 40 | title: Using UDP for Internet Transport Evolution (arXiv preprint 1612.07816) 41 | author: 42 | - 43 | ins: K. Edeline 44 | - 45 | ins: M. Kühlewind 46 | - 47 | ins: B. Trammell 48 | - 49 | ins: E. Aben 50 | - 51 | ins: B. Donnet 52 | target: https://arxiv.org/abs/1612.07816 53 | date: 2016-12-22 54 | Swett16: 55 | title: QUIC Deployment Experience at Google (IETF96 QUIC BoF presentation) 56 | author: 57 | - 58 | ins: I. Swett 59 | target: https://www.ietf.org/proceedings/96/slides/slides-96-quic-3.pdf 60 | date: 2016-07-20 61 | PaaschNanog: 62 | title: Network Support for TCP Fast Open (NANOG 67 presentation) 63 | author: 64 | - 65 | ins: C. Paasch 66 | target: https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf 67 | date: 2016-06-13 68 | Hatonen10: 69 | title: An experimental study of home gateway characteristics (Proc. ACM IMC 2010) 70 | date: 2010-10 71 | author: 72 | - 73 | ins: S. Hatonen 74 | - 75 | ins: A. Nyrhinen 76 | - 77 | ins: L. Eggert 78 | - 79 | ins: S. Strowes 80 | - 81 | ins: P. Sarolahti 82 | - 83 | ins: M. Kojo 84 | RFC5077: 85 | QUIC-HTTP: I-D.ietf-quic-http 86 | RFC8085: 87 | SSDP: 88 | title: UPnP Device Architecture 2.0 89 | date: 2020-04-17 90 | author: 91 | - 92 | ins: A. Donoho 93 | - 94 | ins: B. Roe 95 | - 96 | ins: M. Bodlaender 97 | - 98 | ins: J. Gildred 99 | - 100 | ins: A. Messer 101 | - 102 | ins: Y. Kim 103 | - 104 | ins: B. Fairman 105 | - 106 | ins: J. Tourzan 107 | target: https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf 108 | 109 | 110 | --- abstract 111 | 112 | This document discusses the applicability of the QUIC transport protocol, 113 | focusing on caveats impacting application protocol development and deployment 114 | over QUIC. Its intended audience is designers of application protocol mappings 115 | to QUIC, and implementors of these application protocols. 116 | 117 | --- middle 118 | 119 | # Introduction 120 | 121 | QUIC {{!QUIC=RFC9000}} is a new transport protocol providing a number of 122 | advanced features. While initially designed for the HTTP use case, it provides 123 | capabilities that can be used with a much wider variety of applications. QUIC is 124 | encapsulated in UDP. QUIC version 1 integrates TLS 1.3 {{?TLS13=RFC8446}} to 125 | encrypt all payload data and most control information. The version of HTTP that 126 | uses QUIC is known as HTTP/3 {{QUIC-HTTP}}. 127 | 128 | This document provides guidance for application developers that want to use 129 | the QUIC protocol without implementing it on their own. This includes general 130 | guidance for applications operating over HTTP/3 or directly over QUIC. 131 | 132 | In the following sections, we discuss specific caveats to QUIC's applicability 133 | and issues that application developers must consider when using QUIC as a 134 | transport for their applications. 135 | 136 | # The Necessity of Fallback {#fallback} 137 | 138 | QUIC uses UDP as a substrate. This enables userspace implementation and permits 139 | traversal of network middleboxes (including NAT) without requiring updates to 140 | existing network infrastructure. 141 | 142 | Measurement studies have shown between 3% {{Trammell16}} and 143 | 5% {{Swett16}} of networks block all UDP traffic, though there 144 | is little evidence of other forms of systematic disadvantage to UDP traffic 145 | compared to TCP {{Edeline16}}. This blocking implies that all applications 146 | running on top of QUIC must either be prepared to accept connectivity failure 147 | on such networks or be engineered to fall back to some other transport 148 | protocol. In the case of HTTP, this fallback is TLS over TCP. 149 | 150 | The IETF TAPS specifications {{?TAPS-ARCH=I-D.ietf-taps-arch}} describe a 151 | system with a common API for multiple protocols. This is particularly 152 | relevant for QUIC as it addresses the implications of fallback among 153 | multiple protocols. 154 | 155 | Specifically, fallback to insecure protocols or to weaker versions of secure 156 | protocols needs to be avoided. In general, an application that implements 157 | fallback needs to consider the security consequences. A fallback to TCP and 158 | TLS exposes control information to modification and manipulation in the 159 | network. Additionally, downgrades to TLS versions older than 1.3, which is 160 | used in QUIC version 1, might result in significantly weaker 161 | cryptographic protection. For example, the results of protocol negotiation 162 | {{?RFC7301}} only have confidentiality protection if TLS 1.3 is used. 163 | 164 | These applications must operate, perhaps with impaired functionality, in the 165 | absence of features provided by QUIC not present in the fallback protocol. For 166 | fallback to TLS over TCP, the most obvious difference is that TCP does not 167 | provide stream multiplexing, and therefore stream multiplexing would need to be 168 | implemented in the application layer if needed. Further, TCP implementations 169 | and network paths often do not support the Fast Open option {{?RFC7413}}, which 170 | enables sending of payload data together with the first control packet of a new 171 | connection as also provided by 0-RTT session resumption in QUIC. Note that 172 | there is some evidence of middleboxes blocking SYN data even if TFO was 173 | successfully negotiated (see {{PaaschNanog}}). And even if Fast Open 174 | successfully operates end to end, it is limited to a single packet of TLS 175 | handshake and application data, unlike QUIC 0-RTT. 176 | 177 | Moreover, while encryption (in this case TLS) is inseparably integrated with 178 | QUIC, TLS negotiation over TCP can be blocked. If TLS over TCP cannot be 179 | supported, the connection should be aborted, and the application then ought 180 | to present a suitable prompt to the user that secure communication is 181 | unavailable. 182 | 183 | In summary, any fallback mechanism is likely to impose a degradation of 184 | performance and can degrade security; however, fallback must not silently 185 | violate the application's expectation of confidentiality or integrity of its 186 | payload data. 187 | 188 | # 0-RTT {#zero-rtt} 189 | 190 | QUIC provides for 0-RTT connection establishment. Though the same facility 191 | exists in TLS 1.3 with TCP, 0-RTT presents opportunities and challenges for 192 | applications using QUIC. 193 | 194 | A transport protocol that provides 0-RTT connection establishment is 195 | qualitatively different from one that does not from the point of view of the 196 | application using it. Relative trade-offs between the cost of closing and 197 | reopening a connection and trying to keep it open are different; see 198 | {{resumption-v-keepalive}}. 199 | 200 | An application needs to deliberately choose to use 0-RTT, as 0-RTT carries a 201 | risk of replay attack. Application protocols that use 0-RTT require a profile 202 | that describes the types of information that can be safely sent. For HTTP, this 203 | profile is described in {{?HTTP-REPLAY=RFC8470}}. 204 | 205 | ## Replay Attacks 206 | 207 | Retransmission or malicious replay of data contained in 0-RTT packets could 208 | cause the server side to receive multiple copies of the same data. 209 | 210 | Application data sent by the client in 0-RTT packets could be processed more 211 | than once if it is replayed. Applications need to be aware of what is safe to 212 | send in 0-RTT. Application protocols that seek to enable the use of 0-RTT need 213 | a careful analysis and a description of what can be sent in 0-RTT; see Section 214 | 5.6 of {{!QUIC-TLS}}. 215 | 216 | In some cases, it might be sufficient to limit application data sent in 0-RTT 217 | to data that does not cause actions with lasting effects at a server. 218 | Initiating data retrieval or establishing configuration are 219 | examples of actions that could be safe. Idempotent operations -- those for which 220 | repetition has the same net effect as a single operation -- might be safe. 221 | However, it is also possible to combine individually idempotent operations into 222 | a non-idempotent sequence of operations. 223 | 224 | Once a server accepts 0-RTT data, there is no means of selectively discarding 225 | data that is received. However, protocols can define ways to reject individual 226 | actions that might be unsafe if replayed. 227 | 228 | Some TLS implementations and deployments might be able to provide partial or 229 | even complete replay protection, which could be used to manage replay risk. 230 | 231 | ## Session Resumption versus Keep-Alive {#resumption-v-keepalive} 232 | 233 | Because QUIC is encapsulated in UDP, applications using QUIC must deal with 234 | short network idle timeouts. Deployed stateful middleboxes will generally 235 | establish state for UDP flows on the first packet sent and keep state for 236 | much shorter idle periods than for TCP. {{?RFC5382}} suggests a TCP idle 237 | period of at least 124 minutes, though there is no evidence of widespread 238 | implementation of this guideline in the literature. However, short 239 | network timeout for UDP is well-documented. According to a 2010 study 240 | ({{Hatonen10}}), UDP applications can assume that any NAT binding or other 241 | state entry can expire after just thirty seconds of inactivity. 242 | {{Section 3.5 of RFC8085}} further discusses keep-alive intervals for UDP: 243 | it requires that there is a minimum value of 15 seconds, but recommends 244 | larger values, or that keep-alive is omitted entirely. 245 | 246 | By using a connection ID, QUIC is designed to be robust to NAT 247 | rebinding after a timeout. However, this only helps if one endpoint maintains 248 | availability at the address its peer uses, and the peer is the one to send 249 | after the timeout occurs. 250 | 251 | Some QUIC connections might not be robust to NAT rebinding because the routing 252 | infrastructure (in particular, load balancers) uses the address/port 4-tuple 253 | to direct traffic. Furthermore, middleboxes with functions other than address 254 | translation could still affect the path. In particular, some firewalls do not 255 | admit server traffic for which the firewall has no recent state for a 256 | corresponding packet sent from the client. 257 | 258 | QUIC applications can adjust idle periods to manage the risk of timeout. Idle 259 | periods and the network idle timeout are distinct from the connection idle 260 | timeout, which is defined as the minimum of either endpoint's idle timeout 261 | parameter; see {{Section 10.1 of QUIC}}). There are three options: 262 | 263 | - Ignore the issue if the application-layer protocol consists only of 264 | interactions with no or very short idle periods or if the protocol's 265 | resistance to NAT rebinding is sufficient. 266 | - Ensure there are no long idle periods. 267 | - Resume the session after a long idle period, using 0-RTT resumption when 268 | appropriate. 269 | 270 | The first strategy is the easiest, but it only applies to certain applications. 271 | 272 | Either the server or the client in a QUIC application can send PING frames as 273 | keep-alives to prevent the connection and any on-path state from timing out. 274 | Recommendations for the use of keep-alives are application specific, mainly 275 | depending on the latency requirements and message frequency of the application. 276 | In this case, the application mapping must specify whether the client or server 277 | is responsible for keeping the application alive. While {{Hatonen10}} suggests 278 | that 30 seconds might be a suitable value for the public Internet when a NAT 279 | is on path, larger values are preferable if the deployment can consistently 280 | survive NAT rebinding or is known to be in a controlled environment (e.g., 281 | data centers) in order to lower network and computational load. 282 | 283 | Sending PING frames more frequently than every 30 seconds over long idle 284 | periods may result in excessive unproductive traffic in some situations and 285 | unacceptable power usage for power-constrained (mobile) devices. Additionally, 286 | timeouts shorter than 30 seconds can make it harder to handle transient network 287 | interruptions, such as VM migration or coverage loss during mobility. 288 | See {{RFC8085}}, especially Section 3.5. 289 | 290 | Alternatively, the client (but not the server) can use session resumption 291 | instead of sending keep-alive traffic. In this case, a client that wants to send 292 | data to a server over a connection that has been idle longer than the server's 293 | idle timeout (available from the idle_timeout transport parameter) can simply 294 | reconnect. When possible, this reconnection can use 0-RTT session resumption, 295 | reducing the latency involved with restarting the connection. Of course, this 296 | approach is only valid in cases in which it is safe to use 0-RTT and when the 297 | client is the restarting peer. 298 | 299 | The trade-offs between resumption and keep-alives need to be evaluated on a 300 | per-application basis. In general, applications should use keep-alives only in 301 | circumstances where continued communication is highly likely; {{QUIC-HTTP}}, for 302 | instance, recommends using keep-alives only when a request is outstanding. 303 | 304 | # Use of Streams 305 | 306 | QUIC's stream multiplexing feature allows applications to run multiple streams 307 | over a single connection without head-of-line blocking between streams. Stream 308 | data is carried within frames where one QUIC packet on the wire can carry one 309 | or multiple stream frames. 310 | 311 | Streams can be unidirectional or bidirectional, and a stream may be initiated 312 | either by client or server. Only the initiator of a unidirectional stream can 313 | send data on it. 314 | 315 | Streams and connections can each carry a maximum of 316 | 262-1 bytes in each direction due to encoding limitations on 317 | stream offsets and connection flow control limits. In the presently unlikely 318 | event that this limit is reached by an application, a new connection would 319 | need to be established. 320 | 321 | Streams can be independently opened and closed, gracefully or abruptly. An 322 | application can gracefully close the egress direction of a stream by instructing 323 | QUIC to send a FIN bit in a STREAM frame. It cannot gracefully close the ingress 324 | direction without a peer-generated FIN, much like in TCP. However, an endpoint 325 | can abruptly close the egress direction or request that its peer abruptly close 326 | the ingress direction; these actions are fully independent of each other. 327 | 328 | QUIC does not provide an interface for exceptional handling of any stream. 329 | If a stream that is critical for an application is closed, the application can 330 | generate error messages on the application layer to inform the other end and/or 331 | the higher layer, which can eventually terminate the QUIC connection. 332 | 333 | Mapping of application data to streams is application specific and described for 334 | HTTP/3 in {{QUIC-HTTP}}. There are a few general principles to apply when 335 | designing an application's use of streams: 336 | 337 | - A single stream provides ordering. If the application requires certain data to 338 | be received in order, that data should be sent on the same stream. There is 339 | no guarantee of transmission, reception, or delivery order across streams. 340 | 341 | - Multiple streams provide concurrency. Data that can be processed 342 | independently, and therefore would suffer from head-of-line blocking if forced 343 | to be received in order, should be transmitted over separate streams. 344 | 345 | - Streams can provide message orientation and allow messages to be canceled. 346 | If one message is mapped to a single stream, resetting the stream to expire an 347 | unacknowledged message can be used to emulate partial reliability 348 | for that message. 349 | 350 | If a QUIC receiver has opened the maximum allowed concurrent 351 | streams, and the sender indicates that more streams are needed, it 352 | does not automatically lead to an increase of the maximum number of 353 | streams by the receiver. Therefore, an application should consider the 354 | maximum number of allowed, currently open, and currently used streams when 355 | determining how to map data to streams. 356 | 357 | QUIC assigns a numerical identifier, called the stream ID, to each stream. 358 | While the relationship between these identifiers and stream types is 359 | clearly defined in version 1 of QUIC, future versions might change this 360 | relationship for various reasons. QUIC implementations should expose the 361 | properties of each stream 362 | (which endpoint initiated the stream, whether the stream is unidirectional or 363 | bidirectional, the stream ID used for the stream); applications should query for 364 | these properties rather than attempting to infer them from the stream ID. 365 | 366 | The method of allocating stream identifiers to streams opened by the application 367 | might vary between transport implementations. Therefore, an application should 368 | not assume a particular stream ID will be assigned to a stream that has not yet 369 | been allocated. For example, HTTP/3 uses stream IDs to refer to streams that 370 | have already been opened but makes no assumptions about future stream IDs or 371 | the way in which they are assigned (see {{Section 6 of QUIC-HTTP}}). 372 | 373 | ## Stream versus Flow Multiplexing 374 | 375 | Streams are meaningful only to the application; since stream information is 376 | carried inside QUIC's encryption boundary, a given packet exposes 377 | no information about which 378 | stream(s) are carried within the packet. 379 | Therefore, stream multiplexing is not intended to be used for differentiating 380 | streams in terms of network treatment. Application traffic requiring different 381 | network treatment should therefore be carried over different 5-tuples (i.e., 382 | multiple QUIC connections). Given QUIC's ability to send application data in 383 | the first RTT of a connection (if a previous connection to the same host has 384 | been successfully established to provide the necessary credentials), the cost 385 | of establishing another connection is extremely low. 386 | 387 | ## Prioritization 388 | 389 | Stream prioritization is not exposed to either the network or the receiver. 390 | Prioritization is managed by the sender, and the QUIC transport should 391 | provide an interface for applications to prioritize streams {{QUIC}}. 392 | Applications can implement their own prioritization scheme on top of QUIC: an 393 | application protocol that runs on top of QUIC can define explicit messages 394 | for signaling priority, such as those defined in 395 | {{?RFC9218}} for HTTP. An application protocol can define rules 396 | that allow an endpoint to determine priority based on context or it can 397 | provide a higher-level interface and leave the determination to the 398 | application on top. 399 | 400 | Priority handling of retransmissions can be implemented by the sender in the 401 | transport layer. {{QUIC}} recommends retransmitting lost data before new data, 402 | unless indicated differently by the application. When a QUIC endpoint uses 403 | fully reliable streams for transmission, prioritization of retransmissions will 404 | be beneficial in most cases, filling in gaps and freeing up the flow 405 | control window. For partially reliable or unreliable streams, 406 | priority scheduling of retransmissions over data of higher-priority streams 407 | might not be desirable. For such streams, QUIC could either provide an 408 | explicit interface to control prioritization or derive the prioritization 409 | decision from the reliability level of the stream. 410 | 411 | ## Ordered and Reliable Delivery 412 | 413 | QUIC streams enable ordered and reliable delivery. Though it is possible for an 414 | implementation to provide options that use streams for partial reliability 415 | or out-of-order delivery, most implementations will assume that data is 416 | reliably delivered in order. 417 | 418 | Under this assumption, an endpoint that receives stream data might not make 419 | forward progress until data that is contiguous with the start of a stream is 420 | available. In particular, a receiver might withhold flow control credit until 421 | contiguous data is delivered to the application; see {{Section 2.2 of QUIC}}. 422 | To support this receive logic, an endpoint will send stream data until it is 423 | acknowledged, ensuring that data at the start of the stream is sent and 424 | acknowledged first. 425 | 426 | An endpoint that uses a different sending behavior and does not negotiate that 427 | change with its peer might encounter performance issues or deadlocks. 428 | 429 | ## Flow Control Deadlocks {#flow-control-deadlocks} 430 | 431 | QUIC flow control ({{Section 4 of QUIC}}) provides a means of managing access 432 | to the limited buffers endpoints have for incoming data. This mechanism limits 433 | the amount of data that can be in buffers in endpoints or in transit on the 434 | network. However, there are several ways in which limits can produce conditions 435 | that can cause a connection to either perform suboptimally or become deadlocked. 436 | 437 | Deadlocks in flow control are possible for any protocol that uses QUIC, though 438 | whether they become a problem depends on how implementations consume data and 439 | provide flow control credit. Understanding what causes deadlocking might help 440 | implementations avoid deadlocks. 441 | 442 | The size and rate of updates to flow control credit can affect 443 | performance. Applications that use QUIC often have a data consumer that reads 444 | data from transport buffers. Some implementations might have independent 445 | buffers at the transport layer and application layer. Consuming data does not 446 | always imply it is immediately processed. However, a common implementation 447 | technique is to extend flow control credit to the sender by emitting MAX_DATA 448 | and/or MAX_STREAM_DATA frames as data is consumed. Delivery of these frames 449 | is affected by the latency of the back channel from the receiver to the data 450 | sender. If credit is not extended in a timely manner, the 451 | sending application can be blocked, effectively throttling the sender. 452 | 453 | Large application messages can produce deadlocking if the recipient does not 454 | read data from the transport incrementally. If the message is larger than the 455 | flow control credit available and the recipient does not release additional flow 456 | control credit until the entire message is received and delivered, a deadlock 457 | can occur. This is possible even where stream flow control limits are not 458 | reached because connection flow control limits can be consumed by other streams. 459 | 460 | A length-prefixed message format makes it easier for a data consumer to leave 461 | data unread in the transport buffer and thereby withhold flow control credit. If 462 | flow control limits prevent the remainder of a message from being sent, a 463 | deadlock will result. A length prefix might also enable the detection of this 464 | sort of deadlock. Where application protocols have messages that might be 465 | processed as a single unit, reserving flow control credit for the entire message 466 | atomically makes this style of deadlock less likely. 467 | 468 | A data consumer can eagerly read all data as it becomes available in order to 469 | make the receiver extend flow control credit and reduce the chances of a 470 | deadlock. However, such a data consumer might need other means for holding a 471 | peer accountable for the additional state it keeps for partially processed 472 | messages. 473 | 474 | Deadlocking can also occur if data on different streams is interdependent. 475 | Suppose that data on one stream arrives before the data on a second stream on 476 | which it depends. A deadlock can occur if the first stream is left unread, 477 | preventing the receiver from extending flow control credit for the second 478 | stream. To reduce the likelihood of deadlock for interdependent data, the 479 | sender should ensure that dependent data is not sent until the data 480 | it depends on has been accounted for in both stream- and connection-level flow 481 | control credit. 482 | 483 | Some deadlocking scenarios might be resolved by canceling affected streams with 484 | STOP_SENDING or RESET_STREAM. Canceling some streams results in the connection 485 | being terminated in some protocols. 486 | 487 | ## Stream Limit Commitments 488 | 489 | QUIC endpoints are responsible for communicating the cumulative limit of streams 490 | they would allow to be opened by their peer. Initial limits are advertised using 491 | the initial_max_streams_bidi and initial_max_streams_uni transport parameters. 492 | As streams are opened and closed, they are consumed, and the cumulative total is 493 | incremented. Limits can be increased using the MAX_STREAMS frame, but there is 494 | no mechanism to reduce limits. Once stream limits are reached, no more streams 495 | can be opened, which prevents applications using QUIC from making further 496 | progress. At this stage, connections can be terminated via idle timeout or 497 | explicit close; see {{sec-termination}}. 498 | 499 | An application that uses QUIC and communicates a cumulative stream limit might 500 | require the connection to be closed before the limit is reached, e.g., 501 | to stop the server in order to perform scheduled maintenance. Immediate 502 | connection close causes abrupt closure of actively used streams. Depending 503 | on how an application uses QUIC streams, this could be undesirable or 504 | detrimental to behavior or performance. 505 | 506 | A more graceful closure technique is to stop sending increases to 507 | stream limits and allow the connection to naturally terminate once remaining 508 | streams are consumed. However, the period of time it takes to do so is dependent 509 | on the peer, and an unpredictable closing period might not fit application or 510 | operational needs. Applications using QUIC can be conservative with open stream 511 | limits in order to reduce the commitment and indeterminism. However, being 512 | overly conservative with stream limits affects stream concurrency. Balancing 513 | these aspects can be specific to applications and their deployments. 514 | 515 | Instead of relying on stream limits to avoid abrupt closure, an application 516 | layer's graceful close mechanism can be used to communicate the intention to 517 | explicitly close the connection at some future point. HTTP/3 provides such a 518 | mechanism using the GOAWAY frame. In HTTP/3, when the GOAWAY frame is received 519 | by a client, it stops opening new streams even if the cumulative stream limit 520 | would allow. Instead, the client would create a new connection on which to open 521 | further streams. Once all streams are closed on the old connection, it can be 522 | terminated safely by a connection close or after expiration of the idle time out 523 | (see also {{sec-termination}}). 524 | 525 | # Packetization and Latency 526 | 527 | QUIC exposes an interface that provides multiple streams to the application; 528 | however, the application usually cannot control how data transmitted over those 529 | streams is mapped into frames or how those frames are bundled into packets. 530 | 531 | By default, many implementations will try to pack STREAM frames from 532 | from one or more streams into each QUIC packet, in order to minimize 533 | bandwidth consumption and computational costs (see {{Section 13 of QUIC}}). 534 | If there is not enough data 535 | available to fill a packet, an implementation might wait for a short time to 536 | optimize bandwidth efficiency instead of latency. This delay can either be 537 | preconfigured or dynamically adjusted based on the observed sending pattern of 538 | the application. 539 | 540 | If the application requires low latency, with only small chunks of data to 541 | send, it may be valuable to indicate to QUIC that all data should be sent out 542 | immediately. Alternatively, if the application expects to use a specific 543 | sending pattern, it can also provide a suggested delay to QUIC for how long to 544 | wait before bundling frames into a packet. 545 | 546 | Similarly, an application usually has no control over the length of a QUIC 547 | packet on the wire. QUIC provides the ability to add a PADDING frame to 548 | arbitrarily increase the size of packets. Padding is used by QUIC to ensure that 549 | the path is capable of transferring datagrams of at least a certain size during 550 | the handshake (see {{Sections 8.1 and 14.1 of QUIC}}) and for path validation 551 | after connection migration (see {{Section 8.2 of QUIC}}) as well as for Datagram 552 | Packetization Layer PMTU Discovery (DPLPMTUD) (see {{Section 14.3 of QUIC}}). 553 | 554 | Padding can also be used by an application to reduce leakage of 555 | information about the data that is sent. A QUIC implementation can expose an 556 | interface that allows an application layer to specify how to apply padding. 557 | 558 | # Error Handling 559 | 560 | QUIC recommends that endpoints signal any detected errors to 561 | the peer. Errors can occur at the transport layer and the application layer. 562 | Transport errors, such as a protocol violation, affect the entire connection. 563 | Applications that use QUIC can define their own error detection and signaling 564 | (see, for example, {{Section 8 of QUIC-HTTP}}). Application errors can affect an 565 | entire connection or a single stream. 566 | 567 | QUIC defines an error code space that is used for error handling at the 568 | transport layer. QUIC encourages endpoints to use the most specific code, 569 | although any applicable code is permitted, including generic ones. 570 | 571 | Applications using QUIC define an error 572 | code space that is independent of QUIC or other applications (see, for 573 | example, {{Section 8.1 of QUIC-HTTP}}). The values in an application error code 574 | space can be reused across connection-level and stream-level errors. 575 | 576 | Connection errors lead to connection termination. They are signaled using a 577 | CONNECTION_CLOSE frame, which contains an error code and a reason field that can 578 | be zero length. Different types of CONNECTION_CLOSE frames are used to 579 | signal transport and application errors. 580 | 581 | Stream errors lead to stream termination. These are signaled using 582 | STOP_SENDING or 583 | RESET_STREAM frames, which contain only an error code. 584 | 585 | # Acknowledgment Efficiency 586 | 587 | QUIC version 1 without extensions uses an acknowledgment strategy 588 | adopted from TCP (see {{Section 13.2 of QUIC}}). 589 | That is, it recommends every other packet is acknowledged. 590 | However, generating and processing QUIC acknowledgments consumes resources 591 | at a sender and receiver. Acknowledgments also incur forwarding costs and 592 | contribute to link utilization, which can impact performance over some 593 | types of network. 594 | Applications might be able to improve overall performance 595 | by using alternative strategies that reduce the rate of acknowledgments. 596 | {{?QUIC-ACK-FREQUENCY=I-D.ietf-quic-ack-frequency}} describes an extension 597 | to signal the desired delay of acknowledgments and discusses use cases as 598 | well as implications for congestion control and recovery. 599 | 600 | 601 | # Port Selection and Application Endpoint Discovery {#ports} 602 | 603 | In general, port numbers serve two purposes: "first, they provide a 604 | demultiplexing identifier to differentiate transport sessions between the same 605 | pair of endpoints, and second, they may also identify the application protocol 606 | and associated service to which processes connect" ({{Section 3 of ?RFC6335}}). 607 | The assumption that an application can be identified in the network based on 608 | the port number is less true today due to encapsulation and mechanisms for 609 | dynamic port assignments, as noted in {{?RFC6335}}. 610 | 611 | As QUIC is a general-purpose transport protocol, there are no requirements that 612 | servers use a particular UDP port for QUIC. 613 | For an application with a fallback to TCP that does not already have an 614 | alternate mapping to UDP, it is usually appropriate to register (if 615 | necessary) and use of the UDP port number corresponding to the TCP 616 | port already registered for the application. For example, 617 | the default port for HTTP/3 {{QUIC-HTTP}} is UDP port 443, analogous to HTTP/1.1 618 | or HTTP/2 over TLS over TCP. 619 | 620 | Given the prevalence of the assumption in network management 621 | practice that a port number maps unambiguously to an application, the 622 | use of ports that cannot easily be mapped to a registered service name 623 | might lead to blocking or other changes to the forwarding behavior by network 624 | elements such as firewalls that use the port number for application 625 | identification. 626 | 627 | Applications could define an alternate endpoint discovery mechanism to allow 628 | the usage of ports other than the default. For example, HTTP/3 ({{Sections 3.2 629 | and 3.3 of QUIC-HTTP}}) specifies the use of HTTP Alternative Services 630 | {{?RFC7838}} for an HTTP origin to advertise the availability of an equivalent 631 | HTTP/3 endpoint on a certain UDP port by using "h3" as the Application-Layer 632 | Protocol Negotiation (ALPN) {{?RFC7301}} token. 633 | 634 | ALPN permits the 635 | client and server to negotiate which of several protocols will be used on a 636 | given connection. Therefore, multiple applications might be supported on a 637 | single UDP port based on the ALPN token offered. Applications using QUIC 638 | are required to register an ALPN token for use in the TLS handshake. 639 | 640 | As QUIC version 1 deferred defining a complete version negotiation mechanism, 641 | HTTP/3 requires QUIC version 1 and defines the 642 | ALPN token ("h3") to only apply to that version. 643 | So far, no single approach has been selected for 644 | managing the use of different QUIC versions, neither in HTTP/3 nor in general. 645 | Application protocols that use QUIC need to 646 | consider how the protocol will manage different QUIC versions. 647 | Decisions for those protocols might be informed by choices made by other 648 | protocols, like HTTP/3. 649 | 650 | ## Source Port Selection 651 | 652 | Some UDP protocols are vulnerable to reflection attacks, where an attacker is 653 | able to direct traffic to a third party as a denial of service. For example, 654 | these source ports are associated with applications known to be vulnerable to 655 | reflection attacks, often due to server misconfiguration: 656 | 657 | * port 53 - DNS {{?RFC1034}} 658 | * port 123 - NTP {{?RFC5905}} 659 | * port 1900 - SSDP {{SSDP}} 660 | * port 5353 - mDNS {{?RFC6762}} 661 | * port 11211 - memcache 662 | 663 | Services might block source ports associated with protocols known to be 664 | vulnerable to reflection attacks to avoid the overhead of processing large 665 | numbers of packets. However, this practice has negative effects on 666 | clients -- not only does it require establishment of a new connection but in 667 | some instances might cause the client to avoid using QUIC for that service for 668 | a period of time and downgrade to a non-UDP protocol (see {{fallback}}). 669 | 670 | As a result, client implementations are encouraged to avoid using source ports 671 | associated with protocols known to be vulnerable to reflection attacks. Note 672 | that following the general guidance for client implementations given in 673 | {{?RFC6335}}, to use ephemeral ports in the range 49152–65535, has the 674 | effect of avoiding these ports. Note that other source ports might be 675 | reflection vectors as well. 676 | 677 | # Connection Migration 678 | 679 | QUIC supports connection migration by the client. If the client's IP address 680 | changes, a QUIC endpoint can still associate packets 681 | with an existing transport connection using the Destination Connection ID 682 | field (see {{connid}}) in the QUIC header. This supports cases where the 683 | address information changes, such as NAT rebinding, the 684 | intentional change of the local interface, the expiration of a temporary 685 | IPv6 address {{?RFC8981}}, or the indication from the server of a preferred 686 | address ({{Section 9.6 of QUIC}}). 687 | 688 | Use of a non-zero-length connection ID for the server is strongly recommended if 689 | any clients are or could be behind a NAT. A non-zero-length connection ID is 690 | also strongly recommended when active migration is supported. If a connection 691 | is intentionally migrated to new path, a new connection ID is used to minimize 692 | linkability by network observers. The other QUIC endpoint uses the 693 | connection ID to link different addresses to the same connection 694 | and entity if a non-zero-length connection ID is provided. 695 | 696 | The base specification of QUIC version 1 only supports the use of a single 697 | network path at a time, which 698 | enables failover use cases. Path validation is required so that endpoints 699 | validate paths before use to avoid address spoofing attacks. Path validation 700 | takes at least one RTT, and congestion control will also be reset after path 701 | migration. Therefore, migration usually has a performance impact. 702 | 703 | QUIC probing packets, which can be sent on multiple paths at once, are used to 704 | perform address validation as well as measure path characteristics. Probing 705 | packets cannot carry application data but likely contain padding frames. 706 | Endpoints can use information about their receipt as input to congestion control 707 | for that path. Applications could use information learned from probing to inform 708 | a decision to switch paths. 709 | 710 | Only the client can actively migrate in version 1 of QUIC. However, servers can 711 | indicate during the handshake that they prefer to transfer the connection to a 712 | different address after the handshake. For instance, this could be used to move 713 | from an address that is shared by multiple servers to an address that is unique 714 | to the server instance. The server can provide an IPv4 and an IPv6 address in a 715 | transport parameter during the TLS handshake, and the client can select between 716 | the two if both are provided. See {{Section 9.6 of QUIC}}. 717 | 718 | # Connection Termination {#sec-termination} 719 | 720 | QUIC connections are terminated in one of three ways: implicit idle timeout, 721 | explicit immediate close, or explicit stateless reset. 722 | 723 | QUIC does not provide any mechanism for graceful connection termination; 724 | applications using QUIC can define their own graceful termination process (see, 725 | for example, {{Section 5.2 of QUIC-HTTP}}). 726 | 727 | QUIC idle timeout is enabled via transport parameters. The client and server 728 | announce a timeout period, and the effective value for the connection is the 729 | minimum of the two values. After the timeout period elapses, the connection is 730 | silently closed. An application therefore should be able to configure its own 731 | maximum value, as well as have access to the computed minimum value for this 732 | connection. An application may adjust the maximum idle timeout for new 733 | connections based on the number of open or expected connections since shorter 734 | timeout values may free-up resources more quickly. 735 | 736 | Application data exchanged on streams or in datagrams defers the QUIC idle 737 | timeout. Applications that provide their own keep-alive mechanisms will 738 | therefore keep a QUIC connection alive. Applications that do not provide their 739 | own keep-alive can use transport-layer mechanisms (see {{Section 740 | 10.1.2 of QUIC}} and {{resumption-v-keepalive}}). However, QUIC implementation 741 | interfaces for controlling such transport behavior can vary, affecting the 742 | robustness of such approaches. 743 | 744 | An immediate close is signaled by a CONNECTION_CLOSE frame (see 745 | {{error-handling}}). Immediate close causes all streams to become immediately 746 | closed, which may affect applications; see {{stream-limit-commitments}}. 747 | 748 | A stateless reset is an option of last resort for an endpoint that does not have 749 | access to connection state. Receiving a stateless reset is an indication of an 750 | unrecoverable error distinct from connection errors in that there is no 751 | application-layer information provided. 752 | 753 | 754 | # Information Exposure and the Connection ID {#connid} 755 | 756 | QUIC exposes some information to the network in the unencrypted part of the 757 | header either before the encryption context is established or because the 758 | information is intended to be used by the network. For more information on 759 | manageability of QUIC, see also 760 | {{?QUIC-MANAGEABILITY=I-D.ietf-quic-manageability}}. 761 | QUIC has a long header that 762 | exposes some additional information (the version and the source connection ID), 763 | while the short header exposes only the destination connection ID. 764 | In QUIC version 1, the long header is used during connection establishment, 765 | while the short header is used for data transmission in an established 766 | connection. 767 | 768 | The connection ID can be zero length. Zero-length connection IDs can be 769 | chosen on each endpoint individually and on any packet except the first packets 770 | sent by clients during connection establishment. 771 | 772 | An endpoint that selects a zero-length connection ID will receive packets with a 773 | zero-length destination connection ID. The endpoint needs to use other 774 | information, such as the source and destination IP address and port number to 775 | identify which connection is referred to. This could mean that the endpoint is 776 | unable to match datagrams to connections successfully if these values change, 777 | making the connection effectively unable to survive NAT rebinding or migrate to 778 | a new path. 779 | 780 | ## Server-Generated Connection ID 781 | 782 | QUIC supports a server-generated connection ID that is transmitted to the 783 | client during connection establishment (see {{Section 7.2 of QUIC}}). 784 | Servers behind load 785 | balancers may need to change the connection ID during the handshake, encoding 786 | the identity of the server or information about its load balancing pool, in 787 | order to support stateless load balancing. 788 | 789 | Server deployments with load balancers and other routing infrastructure need to 790 | ensure that this infrastructure consistently routes packets to the server 791 | instance that has the connection state, even if addresses, ports, or 792 | connection IDs change. This might require coordination between servers and 793 | infrastructure. One method of achieving this involves encoding routing 794 | information into the connection ID. For an example of this technique, see 795 | {{?QUIC-LB=I-D.ietf-quic-load-balancers}}. 796 | 797 | ## Mitigating Timing Linkability with Connection ID Migration 798 | 799 | If QUIC endpoints do not issue fresh connection IDs, then clients cannot 800 | reduce the linkability of address migration by using them. 801 | Choosing values that are unlinkable to an outside observer 802 | ensures that activity on different paths cannot be trivially correlated 803 | using the connection ID. 804 | 805 | While sufficiently robust connection ID generation schemes will mitigate 806 | linkability issues, they do not provide full protection. Analysis of 807 | the lifetimes of 6-tuples (source and destination addresses as well as the 808 | migrated Connection ID) may expose these links anyway. 809 | 810 | In the case where connection migration in a server pool is rare, it is trivial 811 | for an observer to associate two connection IDs. Conversely, where every 812 | server handles multiple simultaneous migrations, even an exposed server 813 | mapping may be insufficient information. 814 | 815 | The most efficient mitigations for these attacks are through network design 816 | and/or operational practices, by using a load-balancing architecture that 817 | loads more flows onto a single server-side address, by coordinating the 818 | timing of migrations in an attempt to increase the number of simultaneous 819 | migrations at a given time, or by using other means. 820 | 821 | ## Using Server Retry for Redirection 822 | 823 | QUIC provides a Retry packet that can be sent by a server in response to 824 | the client Initial packet. The server may choose a new connection ID in that 825 | packet, and the client will retry by sending another client Initial packet with 826 | the server-selected connection ID. This mechanism can be used to redirect a 827 | connection to a different server, e.g., due to performance reasons or when 828 | servers in a server pool are upgraded gradually and therefore may support 829 | different versions of QUIC. 830 | 831 | In this case, it is assumed that all servers belonging to a certain pool are 832 | served in cooperation with load balancers that forward the traffic based on the 833 | connection ID. A server can choose the connection ID in the Retry packet such 834 | that the load balancer will redirect the next Initial packet to a different 835 | server in that pool. Alternatively, the load balancer can directly offer a 836 | Retry offload as further described in 837 | {{?QUIC-RETRY=I-D.duke-quic-retry-offload}}. 838 | 839 | The approach described in 840 | {{Section 4 of RFC5077}} for constructing 841 | TLS resumption tickets provides an example that can also be applied to 842 | validation tokens. However, the use of more modern cryptographic algorithms 843 | than those presented in this example is highly recommended. 844 | 845 | # Quality of Service (QoS) and Diffserv Code Point (DSCP) 846 | 847 | QUIC, as defined in {{QUIC}}, has a single congestion controller and 848 | recovery handler. This design 849 | assumes that all packets of a QUIC connection, or at least with the 850 | same 5-tuple {dest addr, source addr, protocol, dest port, source port}, 851 | that have the same Diffserv Code Point (DSCP) {{?RFC2475}} will 852 | receive similar network treatment since feedback about loss or delay 853 | of each packet is used as input to the congestion controller. Therefore, 854 | packets belonging to the same connection should use a single DSCP. 855 | Section 5.1 of {{?RFC7657}} provides a discussion of DiffServ interactions 856 | with datagram transport protocols {{?RFC7657}} (in this respect, the 857 | interactions with QUIC resemble those of Stream Control Transmission 858 | Protocol (SCTP)). 859 | 860 | When multiplexing multiple flows 861 | over a single QUIC connection, the selected DSCP value should be the one 862 | associated with the highest priority requested for all multiplexed flows. 863 | 864 | If differential network treatment is desired, 865 | e.g., by the use of different DSCPs, multiple QUIC 866 | connections to the same server may be used. In general it is 867 | recommended to minimize the number of QUIC connections to the same server to 868 | avoid increased overhead and, more importantly, competing congestion control. 869 | 870 | As in other uses of Diffserv, 871 | when a packet enters a network segment that does not support the DSCP value, 872 | this could result in the connection not receiving the network treatment 873 | it expects. The DSCP value in this packet could also be remarked as the 874 | packet travels along the network path, changing the requested treatment. 875 | 876 | # Use of Versions and Cryptographic Handshake 877 | 878 | Versioning in QUIC may change the protocol's behavior completely, except 879 | for the meaning of a few header fields that have been declared to be invariant 880 | {{!QUIC-INVARIANTS=RFC8999}}. A version of QUIC 881 | with a higher version number will not necessarily provide a better service 882 | but might simply provide a different feature set. As such, an application needs 883 | to be able to select which versions of QUIC it wants to use. 884 | 885 | A new version could use an encryption scheme other than TLS 1.3 or higher. 886 | {{QUIC}} specifies requirements for the cryptographic handshake as currently 887 | realized by TLS 1.3 and described in a separate specification 888 | {{!QUIC-TLS=RFC9001}}. This split is performed to enable 889 | lightweight versioning with different cryptographic handshakes. 890 | 891 | The "QUIC Versions" registry established in {{QUIC}} allows for 892 | provisional registrations for experimentation. Registration, also of 893 | experimental versions, is important to avoid collision. Experimental 894 | versions should not be used long-term or registered as permanent to minimize 895 | the risk of fingerprinting based on the version number. 896 | 897 | # Enabling Deployment of New Versions 898 | 899 | QUIC version 1 does not specify a version negotiation mechanism in the base 900 | specification, but 901 | {{?QUIC-VERSION-NEGOTIATION=I-D.draft-ietf-quic-version-negotiation}} 902 | proposes an extension that provides compatible version negotiation. 903 | 904 | This approach uses a three-stage deployment mechanism, enabling 905 | progressive rollout and experimentation with multiple versions across 906 | a large server deployment. In this approach, all servers in the deployment 907 | must accept connections using a new version (stage 1) before any server 908 | advertises it (stage 2), and authentication of the new version (stage 3) 909 | only proceeds after advertising of that version is completely deployed. 910 | 911 | See {{Section 5 of QUIC-VERSION-NEGOTIATION}} for details. 912 | 913 | 914 | # Unreliable Datagram Service over QUIC 915 | 916 | {{?RFC9221}} specifies a QUIC extension to enable sending 917 | and receiving unreliable datagrams over QUIC. Unlike operating directly over 918 | UDP, applications that use the QUIC datagram service do not need to implement 919 | their own congestion control, per {{RFC8085}}, as QUIC datagrams are 920 | congestion controlled. 921 | 922 | QUIC datagrams are not flow controlled, and as such data chunks may be dropped 923 | if the receiver is overloaded. While the reliable transmission service of QUIC 924 | provides a stream-based interface to send and receive data in order over 925 | multiple QUIC streams, the datagram service has an unordered message-based 926 | interface. If needed, an application-layer framing can be used on top to 927 | allow separate flows of unreliable datagrams to be multiplexed on one QUIC 928 | connection. 929 | 930 | 931 | # IANA Considerations 932 | 933 | This document has no actions for IANA; however, note that {{ports}} 934 | recommends that an application that has already registered a TCP port 935 | but wants to specify QUIC as a transport should register a UDP port 936 | analogous to their existing TCP registration. 937 | 938 | # Security Considerations 939 | 940 | See the security considerations in {{QUIC}} and {{!QUIC-TLS}}; the security 941 | considerations for the underlying transport protocol are relevant for 942 | applications using QUIC. Considerations on linkability, replay attacks, 943 | and randomness discussed in {{!QUIC-TLS}} should be taken into account when 944 | deploying and using QUIC. 945 | 946 | Further, migration to a new address exposes 947 | a linkage between client addresses to the server and may expose this linkage 948 | also to the path if the connection ID cannot be changed or flows can 949 | otherwise be correlated. When migration is supported, this needs to be 950 | considered with respective to user privacy. 951 | 952 | Application developers should note that any fallback they use when QUIC cannot 953 | be used due to network blocking of UDP should guarantee the same security 954 | properties as QUIC. If this is not possible, the connection should fail to 955 | allow the application to explicitly handle fallback to a less-secure 956 | alternative. See {{fallback}}. 957 | 958 | Further, {{QUIC-HTTP}} provides security considerations specific to HTTP. 959 | However, discussions such as on cross-protocol attacks, traffic analysis 960 | and padding, or migration might be relevant for other applications using QUIC 961 | as well. 962 | 963 | # Contributors 964 | 965 | The following people have contributed significant text to and/or feedback 966 | on this document: 967 | 968 | * Gorry Fairhurst 969 | * Ian Swett 970 | * Igor Lubashev 971 | * Lucas Pardue 972 | * Mike Bishop 973 | * Mark Nottingham 974 | * Martin Duke 975 | * Martin Thomson 976 | * Sean Turner 977 | * Tommy Pauly 978 | 979 | # Acknowledgments 980 | 981 | Special thanks to last-call reviewers Chris Lonvick and Ines Robles. 982 | 983 | This work was partially supported by the European Commission under Horizon 2020 984 | grant agreement no. 688421 Measurement and Architecture for a Middleboxed 985 | Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and 986 | Innovation under contract no. 15.0268. This support does not imply endorsement. 987 | -------------------------------------------------------------------------------- /draft-ietf-quic-manageability.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Manageability of the QUIC Transport Protocol 3 | abbrev: QUIC Manageability 4 | docname: draft-ietf-quic-manageability-latest 5 | date: 6 | category: info 7 | 8 | ipr: trust200902 9 | keyword: Internet-Draft 10 | 11 | stand_alone: yes 12 | pi: [toc, sortrefs, symrefs] 13 | 14 | 15 | author: 16 | - 17 | ins: M. Kuehlewind 18 | name: Mirja Kuehlewind 19 | org: Ericsson 20 | email: mirja.kuehlewind@ericsson.com 21 | - 22 | ins: B. Trammell 23 | name: Brian Trammell 24 | org: Google Switzerland GmbH 25 | email: ietf@trammell.ch 26 | street: Gustav-Gull-Platz 1 27 | city: 8004 Zurich 28 | country: Switzerland 29 | 30 | normative: 31 | 32 | informative: 33 | TMA-QOF: 34 | title: Inline Data Integrity Signals for Passive Measurement (in Proc. TMA 2014) 35 | author: 36 | - 37 | ins: B. Trammell 38 | - 39 | ins: D. Gugelmann 40 | - 41 | ins: N. Brownlee 42 | date: 2014-04 43 | IPIM: 44 | title: In-Protocol Internet Measurement (arXiv preprint 1612.02902) 45 | author: 46 | - 47 | ins: M. Allman 48 | - 49 | ins: R. Beverly 50 | - 51 | ins: B. Trammell 52 | target: https://arxiv.org/abs/1612.02902 53 | date: 2016-12-09 54 | QUIC-TIMEOUT: 55 | title: QUIC (IETF-88 TSV Area Presentation) 56 | author: 57 | - 58 | ins: J. Roskind 59 | target: https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf 60 | date: 2013-11-07 61 | RFC7605: 62 | QUIC-RECOVERY: RFC9002 63 | QUIC-GREASE: I-D.ietf-quic-bit-grease 64 | RFC4459: 65 | 66 | --- abstract 67 | 68 | This document discusses manageability of the QUIC transport protocol, focusing 69 | on the implications of QUIC's design and wire image on network operations 70 | involving QUIC traffic. It is intended as a "user's manual" for the wire image, 71 | providing guidance for network operators and equipment vendors who rely on the 72 | use of transport-aware network functions. 73 | 74 | --- middle 75 | 76 | # Introduction 77 | 78 | QUIC {{?QUIC-TRANSPORT=RFC9000}} is a new transport protocol 79 | that is encapsulated in UDP. QUIC integrates TLS 80 | {{?QUIC-TLS=RFC9001}} to encrypt all payload data and most control 81 | information. QUIC version 1 was designed primarily as a transport for HTTP, with 82 | the resulting protocol being known as HTTP/3 {{?QUIC-HTTP=I-D.ietf-quic-http}}. 83 | 84 | This document provides guidance for network operations that manage QUIC 85 | traffic. This includes guidance on how to interpret and utilize information that 86 | is exposed by QUIC to the network, requirements and assumptions of the QUIC 87 | design with respect to network treatment, and a description of how common 88 | network management practices will be impacted by QUIC. 89 | 90 | QUIC is an end-to-end transport protocol; therefore, no information in 91 | the protocol header is intended to be mutable by the network. This 92 | property is 93 | enforced through integrity protection of the wire image {{?WIRE-IMAGE=RFC8546}}. 94 | Encryption of most transport-layer control signaling means that less information 95 | is visible to the network than is the case with TCP. 96 | 97 | Integrity protection can also simplify troubleshooting at the end points as none 98 | of the nodes on the network path can modify transport layer information. 99 | However, it means in-network operations that depend on modification of data 100 | (for examples, see {{?RFC9065}}) are not possible without the cooperation of 101 | a QUIC endpoint. Such cooperation might be possible with the introduction of 102 | a proxy which authenticates as an endpoint. Proxy operations are not in scope 103 | for this document. 104 | 105 | Network management is not a one-size-fits-all endeavour: practices considered 106 | necessary or even mandatory within enterprise networks with certain compliance 107 | requirements, for example, would be impermissible on other networks without 108 | those requirements. The presence of a particular practice in this document 109 | should therefore not be construed as a recommendation to apply it. For each 110 | practice, this document describes what is and is not possible with the QUIC 111 | transport protocol as defined. 112 | 113 | This document focuses solely on network management practices that observe 114 | traffic on the wire. Replacement of troubleshooting based on observation 115 | with active measurement techniques, for example, is therefore out of scope. 116 | A more generalized treatment of network management operations on encrypted 117 | transports is given in {{?RFC9065}}. 118 | 119 | QUIC-specific terminology used in this document is defined 120 | in {{QUIC-TRANSPORT}}. 121 | 122 | # Features of the QUIC Wire Image {#sec-wire-image} 123 | 124 | This section discusses those aspects of the QUIC transport protocol that 125 | have an impact on the design and operation of devices that forward QUIC packets. 126 | This section is therefore primarily considering the unencrypted part of QUIC's 127 | wire image {{WIRE-IMAGE}}, which is defined as the information available in the 128 | packet header in each QUIC packet, and the dynamics of that information. Since 129 | QUIC is a versioned protocol, the wire image of the header format can also 130 | change from version to version. However, the field that identifies the QUIC 131 | version in some packets, and the format of the Version Negotiation Packet, 132 | are both inspectable and invariant 133 | {{?QUIC-INVARIANTS=RFC8999}}. 134 | 135 | This document addresses version 1 of the QUIC protocol, whose wire image 136 | is fully defined in {{QUIC-TRANSPORT}} and {{?QUIC-TLS}}. Features of the wire 137 | image described herein may change in future versions of the protocol, except 138 | when specified as an invariant {{QUIC-INVARIANTS}}, 139 | and cannot be used to identify QUIC as a protocol or 140 | to infer the behavior of future versions of QUIC. 141 | 142 | ## QUIC Packet Header Structure {#public-header} 143 | 144 | QUIC packets may have either a long header or a short header. The first bit 145 | of the QUIC header is the Header Form bit, and indicates which type of header 146 | is present. The purpose of this bit is invariant across QUIC versions. 147 | 148 | The long header exposes more information. It contains a version number, as well 149 | as source and destination connection IDs for associating packets with a QUIC 150 | connection. The definition and location of these fields in the QUIC long header 151 | are invariant for future versions of QUIC, although future versions of QUIC may 152 | provide additional fields in the long header {{QUIC-INVARIANTS}}. 153 | 154 | In version 1 of QUIC, the long header is used during connection establishment 155 | to transmit crypto handshake data, perform version negotiation, retry, and 156 | send 0-RTT data. 157 | 158 | Short headers are used after connection establishment in version 1 of QUIC, 159 | and expose only an optional destination connection ID and the initial flags 160 | byte with the spin bit for RTT measurement. 161 | 162 | The following information is exposed in QUIC packet headers in all versions of 163 | QUIC (as specified in {{QUIC-INVARIANTS}}): 164 | 165 | - version number: the version number is present in the long header, and 166 | identifies the version used for that packet. During Version 167 | Negotiation (see {{Section 17.2.1 of QUIC-TRANSPORT}} and {{version}}), the 168 | version number field has a special value (0x00000000) that identifies the 169 | packet as a Version Negotiation packet. QUIC 170 | version 1 uses version 0x00000001. Operators should expect to observe 171 | packets with other version numbers as a result of various Internet 172 | experiments, future standards, and greasing ({{?RFC7801}}). An IANA registry 173 | contains the values of all standardized versions of QUIC, and may contain some 174 | proprietary versions (see {{Section 22.2 of QUIC-TRANSPORT}}). However, other 175 | versions of QUIC can be expected to be seen in the Internet at any given time. 176 | 177 | - source and destination connection ID: short and long headers carry a 178 | destination connection ID, a variable-length field which, if not zero-length, 179 | can be used to 180 | identify the connection associated with a QUIC packet, for load-balancing and 181 | NAT rebinding purposes; see {{sec-loadbalancing}} and {{rebinding}}. Long 182 | packet headers additionally carry a source connection ID. The source 183 | connection ID corresponds to the destination connection ID the source would 184 | like to have on packets sent to it, and is only present on long 185 | headers. On long header packets, the length of the connection 186 | IDs is also present; on short header packets, the length of the destination 187 | connection ID is implicit and as such need to be known from the long header 188 | packets. 189 | 190 | In version 1 of QUIC, the following additional information is exposed: 191 | 192 | - "fixed bit": The second-most-significant bit of the first octet of most QUIC 193 | packets of the current version is set to 1, enabling endpoints to demultiplex 194 | with other UDP-encapsulated protocols. Even though this bit is fixed in the 195 | version 1 specification, endpoints might use an extension that varies the bit 196 | [QUIC-GREASE]. Therefore, observers cannot reliably use it as an identifier 197 | for QUIC. 198 | 199 | - latency spin bit: The third-most-significant bit of the first octet in the 200 | short header for version 1. The spin bit is set by endpoints such that 201 | tracking edge transitions can be used to passively observe end-to-end RTT. See 202 | {{spin-usage}} for further details. 203 | 204 | - header type: The long header has a 2 bit packet type field following the 205 | Header Form and fixed bits. Header types correspond to stages of the 206 | handshake; see {{Section 17.2 of QUIC-TRANSPORT}} for details. 207 | 208 | - length: The length of the remaining QUIC packet after the length field, 209 | present on long headers. This field is used to implement coalesced packets 210 | during the handshake (see {{coalesced}}). 211 | 212 | - token: Initial packets may contain a token, a variable-length opaque value 213 | optionally sent from client to server, used for validating the client's 214 | address. Retry packets also contain a token, which can be used by the client 215 | in an Initial packet on a subsequent connection attempt. The length of the 216 | token is explicit in both cases. 217 | 218 | Retry ({{Section 17.2.5 of QUIC-TRANSPORT}}) and Version Negotiation ({{Section 219 | 17.2.1 of QUIC-TRANSPORT}}) packets are not encrypted. Retry packets are 220 | (forgibly) integrity protected. Transport parameters are used 221 | authenticate the contents of Retry packets later in the handshake. For other 222 | kinds of packets, version 1 of QUIC cryptographically protects other 223 | information in the packet headers: 224 | 225 | - packet number: All packets except Version Negotiation and 226 | Retry packets have an associated packet number; however, this packet number 227 | is encrypted, and therefore not of use to on-path observers. The offset of the 228 | packet number can be decoded in long headers, while it 229 | is implicit (depending on destination connection ID length) in short headers. 230 | The length of the packet number is cryptographically protected. 231 | 232 | - key phase: The Key Phase bit, present in short headers, specifies the keys 233 | used to encrypt the packet to support key rotation. The Key Phase bit is 234 | cryptographically protected. 235 | 236 | ## Coalesced Packets {#coalesced} 237 | 238 | Multiple QUIC packets may be coalesced into a single UDP datagram, 239 | with a datagram 240 | carrying one or more long header packets followed by zero or one short header 241 | packets. When packets are coalesced, the Length fields in the long headers are 242 | used to separate QUIC packets; see {{Section 12.2 of QUIC-TRANSPORT}}. 243 | The Length field is variable length, and its position in the header is 244 | also variable depending on the length of the source and destination connection 245 | ID; see {{Section 17.2 of QUIC-TRANSPORT}}. 246 | 247 | ## Use of Port Numbers 248 | 249 | Applications that have a mapping for TCP as well as QUIC are expected to 250 | use the same port number for both services. However, as for all other IETF 251 | transports {{?RFC7605}}, there is no guarantee that a specific application 252 | will use a given registered port, or that a given port carries traffic belonging 253 | to the respective registered service, especially when application layer 254 | information is encrypted. For example, {{QUIC-HTTP}} specifies the use of the 255 | HTTP Alternative Services mechanism {{?RFC7838}} for discovery of HTTP/3 256 | services on other ports. 257 | 258 | Further, as QUIC has a connection ID, it is also possible to maintain multiple 259 | QUIC connections over one 5-tuple (protocol, source and destination IP address, 260 | and source and destination port). However, if the connection ID is zero-length, 261 | all packets of the 5-tuple likely belong to the same QUIC connection. 262 | 263 | ## The QUIC Handshake {#handshake} 264 | 265 | New QUIC connections are established using a handshake, which is distinguishable 266 | on the wire (see {{sec-identifying}} for details), and contains some information 267 | that can be passively observed. 268 | 269 | To illustrate the information visible in the QUIC wire image during the 270 | handshake, we first show the general communication pattern visible in the UDP 271 | datagrams containing the QUIC handshake, then examine each of the datagrams in 272 | detail. 273 | 274 | The QUIC handshake can normally be recognized on the wire through four flights 275 | of datagrams labelled "Client Initial", "Server Initial", "Client Completion", 276 | and "Server Completion", as illustrated in {{fig-handshake}}. 277 | 278 | A handshake starts with the client sending one or more datagrams containing 279 | Initial packets, detailed in {{fig-client-initial}}, which elicits the 280 | Server Initial response detailed in {{fig-server-initial}} typically containing 281 | three types of packets: Initial packet(s) with the beginning of the server's 282 | side of the TLS handshake, Handshake packet(s) with the rest of the server's 283 | portion of the TLS handshake, and 1-RTT packet(s), if present. 284 | 285 | ~~~~~ 286 | Client Server 287 | | | 288 | +----Client Initial----------------------->| 289 | +----(zero or more 0-RTT)----------------->| 290 | | | 291 | |<-----------------------Server Initial----+ 292 | |<--------(1-RTT encrypted data starts)----+ 293 | | | 294 | +----Client Completion-------------------->| 295 | +----(1-RTT encrypted data starts)-------->| 296 | | | 297 | |<--------------------Server Completion----+ 298 | | | 299 | ~~~~~ 300 | {: #fig-handshake 301 | title="General communication pattern visible in the QUIC handshake"} 302 | 303 | As shown here, the client can send 0-RTT data as soon as it has sent its Client 304 | Hello, and the server can send 1-RTT data as soon as it has sent its Server 305 | Hello. The Client Completion flight contains at least one Handshake packet and 306 | could also include an Initial packet. QUIC packets in separate contexts during 307 | the handshake can be coalesced (see {{coalesced}}) in order to reduce the 308 | number of UDP datagrams sent during the handshake. 309 | 310 | Handshake packets can arrive out-of-order without impacting the handshake as 311 | long as the reordering was not accompanied by extensive delays that trigger a 312 | spurious Probe Timeout ({Section 6.2 of RFC9002}). 313 | If QUIC packets get lost or reordered, packets belonging 314 | to the same flight might not be observed in close time succession, though 315 | the sequence of the flights will not change, because one flight depends 316 | upon the peer's previous flight. 317 | 318 | Datagrams that contain an Initial packet (Client Initial, Server 319 | Initial, and some Client Completion) contain at least 1200 octets of UDP 320 | payload. This protects against amplification attacks and verifies that the 321 | network path meets the requirements for the minimum QUIC IP packet size; 322 | see {{Section 14 of QUIC-TRANSPORT}}. This is accomplished by either adding 323 | PADDING frames within the Initial packet, coalescing other packets with the 324 | Initial packet, or leaving unused payload in the UDP packet after the Initial 325 | packet. A network path needs to be able to forward at least this size of 326 | packet for QUIC to be used. 327 | 328 | The content of Initial packets is encrypted using Initial Secrets, 329 | which are derived from a per-version constant and the client's 330 | destination connection ID. That content is therefore observable by 331 | any on-path device that knows the per-version constant and is 332 | considered visible in this illustration. The content of QUIC 333 | Handshake packets is encrypted using keys established during the 334 | initial handshake exchange, and is therefore not visible. 335 | 336 | Initial, Handshake, and 1-RTT packets belong to different cryptographic and 337 | transport contexts. The Client Completion ({{fig-init-complete}}) and the 338 | Server Completion ({{fig-hs-complete}}) flights conclude the Initial 339 | and Handshake contexts, by sending final acknowledgments and 340 | CRYPTO frames. 341 | 342 | ~~~~~ 343 | +----------------------------------------------------------+ 344 | | UDP header (source and destination UDP ports) | 345 | +----------------------------------------------------------+ 346 | | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 347 | +----------------------------------------------------------+ | 348 | | QUIC CRYPTO frame header | | 349 | +----------------------------------------------------------+ | 350 | | | TLS Client Hello (incl. TLS SNI) | | | 351 | +----------------------------------------------------------+ | 352 | | QUIC PADDING frames | | 353 | +----------------------------------------------------------+<-+ 354 | ~~~~~ 355 | {: #fig-client-initial title="Example Client Initial datagram without 0-RTT"} 356 | 357 | A Client Initial packet exposes the version, source and destination 358 | connection IDs without encryption. The payload of the Initial 359 | packet is protected using the Initial secret. The complete TLS 360 | Client Hello, including any TLS Server Name Indication (SNI) 361 | present, is sent in one or more CRYPTO frames across one or more 362 | QUIC Initial packets. 363 | 364 | ~~~~~ 365 | +------------------------------------------------------------+ 366 | | UDP header (source and destination UDP ports) | 367 | +------------------------------------------------------------+ 368 | | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 369 | +------------------------------------------------------------+ | 370 | | QUIC CRYPTO frame header | | 371 | +------------------------------------------------------------+ | 372 | | TLS Server Hello | | 373 | +------------------------------------------------------------+ | 374 | | QUIC ACK frame (acknowledging client hello) | | 375 | +------------------------------------------------------------+<-+ 376 | | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 377 | +------------------------------------------------------------+ | 378 | | encrypted payload (presumably CRYPTO frames) | | 379 | +------------------------------------------------------------+<-+ 380 | | QUIC short header | 381 | +------------------------------------------------------------+ 382 | | 1-RTT encrypted payload | 383 | +------------------------------------------------------------+ 384 | ~~~~~ 385 | {: #fig-server-initial title="Coalesced Server Initial datagram pattern"} 386 | 387 | The Server Initial datagram also exposes version number, source and destination 388 | connection IDs in the clear; the payload of the Initial packet(s) is 389 | protected using the Initial secret. 390 | 391 | ~~~~~ 392 | +------------------------------------------------------------+ 393 | | UDP header (source and destination UDP ports) | 394 | +------------------------------------------------------------+ 395 | | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 396 | +------------------------------------------------------------+ | 397 | | QUIC ACK frame (acknowledging Server Initial) | | 398 | +------------------------------------------------------------+<-+ 399 | | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 400 | +------------------------------------------------------------+ | 401 | | encrypted payload (presumably CRYPTO/ACK frames) | | 402 | +------------------------------------------------------------+<-+ 403 | | QUIC short header | 404 | +------------------------------------------------------------+ 405 | | 1-RTT encrypted payload | 406 | +------------------------------------------------------------+ 407 | ~~~~~ 408 | {: #fig-init-complete title="Coalesced Client Completion datagram pattern"} 409 | 410 | The Client Completion flight does not expose any additional information; 411 | however, as the destination connection ID is server-selected, it usually 412 | is not the same ID that is sent in the Client Initial. Client Completion 413 | flights contain 1-RTT packets which indicate the handshake has completed 414 | (see {{sec-confirm}}) on the client, and for three-way handshake RTT 415 | estimation as in {{sec-rtt}}. 416 | 417 | ~~~~~ 418 | +------------------------------------------------------------+ 419 | | UDP header (source and destination UDP ports) | 420 | +------------------------------------------------------------+ 421 | | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 422 | +------------------------------------------------------------+ | 423 | | encrypted payload (presumably ACK frame) | | 424 | +------------------------------------------------------------+<-+ 425 | | QUIC short header | 426 | +------------------------------------------------------------+ 427 | | 1-RTT encrypted payload | 428 | +------------------------------------------------------------+ 429 | ~~~~~ 430 | {: #fig-hs-complete title="Coalesced Server Completion datagram pattern"} 431 | 432 | Similar to Client Completion, Server Completion also exposes no additional 433 | information; observing it serves only to determine that the handshake has 434 | completed. 435 | 436 | When the client uses 0-RTT data, the Client Initial 437 | flight can also include one or more 0-RTT packets, as shown in 438 | {{fig-client-initial-0rtt}}. 439 | 440 | ~~~~~ 441 | +----------------------------------------------------------+ 442 | | UDP header (source and destination UDP ports) | 443 | +----------------------------------------------------------+ 444 | | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 445 | +----------------------------------------------------------+ | 446 | | QUIC CRYPTO frame header | | 447 | +----------------------------------------------------------+ | 448 | | TLS Client Hello (incl. TLS SNI) | | 449 | +----------------------------------------------------------+<-+ 450 | | QUIC long header (type = 0-RTT, Version, DCID, SCID) (Length) 451 | +----------------------------------------------------------+ | 452 | | 0-RTT encrypted payload | | 453 | +----------------------------------------------------------+<-+ 454 | ~~~~~ 455 | {: #fig-client-initial-0rtt 456 | title="Coalesced 0-RTT Client Initial datagram"} 457 | 458 | When a 0-RTT packet is coalesced with an Initial packet, the datagram 459 | will be padded to 1200 bytes. Additional datagrams containing only 0-RTT 460 | packets with long headers can be sent after the client Initial packet(s), 461 | containing more 0-RTT data. The amount of 0-RTT protected data that 462 | can be sent in the first flight is limited by the initial congestion 463 | window, typically to around 10 packets (see {{Section 7.2 of 464 | QUIC-RECOVERY}}). 465 | 466 | ## Integrity Protection of the Wire Image {#wire-integrity} 467 | 468 | As soon as the cryptographic context is established, all information in the QUIC 469 | header, including exposed information, is integrity protected. Further, 470 | information that was exposed in packets sent before the cryptographic context 471 | was established is validated during the cryptographic handshake. Therefore, 472 | devices on path cannot alter any information or bits in QUIC packets. Such 473 | alterations would cause the integrity check to fail, which results in the 474 | receiver discarding the packet. Some parts of Initial packets could be altered 475 | by removing and re-applying the authenticated encryption without immediate 476 | discard at the receiver. However, the cryptographic handshake validates most 477 | fields and any modifications in those fields will result in connection 478 | establishment failing later. 479 | 480 | ## Connection ID and Rebinding {#rebinding} 481 | 482 | The connection ID in the QUIC packet headers allows association of QUIC 483 | packets using information independent of the 5-tuple. This allows 484 | rebinding of a connection after one of the endpoints - usually the 485 | client - has experienced an address change. Further it can be used by 486 | in-network devices to ensure that related 5-tuple flows are appropriately 487 | balanced together (see Section {{sec-loadbalancing}}). 488 | 489 | Client and server each choose a connection ID during the handshake; for 490 | example, a server might request that a client use a connection ID, whereas the 491 | client might choose a zero-length value. Connection IDs for either endpoint may 492 | change during the lifetime of a connection, with the new connection ID being 493 | supplied via encrypted frames (see {{Section 5.1 of QUIC-TRANSPORT}}). 494 | Therefore, observing a new connection ID does not necessarily indicate a new 495 | connection. 496 | 497 | {{?QUIC-LB=I-D.ietf-quic-load-balancers}} specifies algorithms for 498 | encoding the server mapping in a connection ID in order to share this 499 | information with selected on-path devices such as load balancers. Server 500 | mappings should only be exposed to selected entities. Uncontrolled exposure 501 | would allow linkage of multiple IP addresses to the same host if the server 502 | also supports migration that opens an attack vector on specific servers or 503 | pools. The best way to obscure an encoding is to appear random to any other 504 | observers, which is most rigorously achieved with encryption. As a result, 505 | any attempt to infer information from specific parts of a connection ID is 506 | unlikely to be useful. 507 | 508 | 509 | ## Packet Numbers {#packetnumber} 510 | 511 | The Packet Number field is always present in the QUIC packet header in version 512 | 1; however, it is always encrypted. The encryption key for packet number 513 | protection on Initial packets -- which are sent before cryptographic context 514 | establishment -- is specific to the QUIC version, while packet number protection 515 | on subsequent packets uses secrets derived from the end-to-end cryptographic 516 | context. Packet numbers are therefore not part of the wire image that is visible 517 | to on-path observers. 518 | 519 | 520 | ## Version Negotiation and Greasing {#version} 521 | 522 | Version Negotiation packets are used by the server to indicate that a requested 523 | version from the client is not supported (see {{Section 6 of QUIC-TRANSPORT}}. 524 | Version Negotiation packets are not intrinsically protected, but future QUIC 525 | versions could use later encrypted messages to verify that they were authentic. 526 | Therefore, any modification of this list will be detected and may cause the 527 | endpoints to terminate the connection attempt. 528 | 529 | Also note that the list of versions in the Version Negotiation packet may 530 | contain reserved versions. This mechanism is used to avoid ossification in the 531 | implementation of the selection mechanism. Further, a client may send an Initial 532 | packet with a reserved version number to trigger version negotiation. In 533 | the Version Negotiation packet, the connection IDs of the client's 534 | Initial packet 535 | are reflected to provide a proof of return-routability. Therefore, changing this 536 | information will also cause the connection to fail. 537 | 538 | QUIC is expected to evolve rapidly, so new versions, both experimental and IETF 539 | standard versions, will be deployed on the Internet more often than with 540 | other commonly deployed Internet- and transport-layer protocols. Use 541 | of the version number field for traffic recognition will therefore behave 542 | differently than with these protocols. Using a particular version number 543 | to recognize valid QUIC traffic is likely to persistently miss a fraction of 544 | QUIC flows, 545 | and completely fail in the near future. Reliance on the version number field 546 | for the purposes of admission control is similarly likely to rapidly lead to 547 | unintended failure modes. Admission of QUIC traffic regardless of version 548 | avoids these failure modes, avoids unnecessary deployment delays, and 549 | supports continuous version-based evolution. 550 | 551 | 552 | # Network-Visible Information about QUIC Flows 553 | 554 | This section addresses the different kinds of observations and inferences that 555 | can be made about QUIC flows by a passive observer in the network based on the 556 | wire image in {{sec-wire-image}}. Here we assume a bidirectional observer (one 557 | that can see packets in both directions in the sequence in which they are 558 | carried on the wire) unless noted, but typically without access to any keying 559 | information. 560 | 561 | 562 | ## Identifying QUIC Traffic {#sec-identifying} 563 | 564 | The QUIC wire image is not specifically designed to be distinguishable 565 | from other UDP traffic by a passive observer in the network. While certain 566 | QUIC applications may be heuristically identifiable on a per-application 567 | basis, there is no general method for distinguishing QUIC traffic from 568 | otherwise-unclassifiable UDP traffic on a given link. Any unrecognized UDP 569 | traffic may therefore be QUIC traffic. 570 | 571 | At the time of writing, two application bindings for QUIC have been published 572 | or adopted by the IETF: HTTP/3 {{?QUIC-HTTP}} and DNS over Dedicated QUIC 573 | Connections {{?I-D.ietf-dprive-dnsoquic}}. These are both known at the time 574 | of writing to have active Internet deployments, so an assumption that all 575 | QUIC traffic is HTTP/3 is not valid. HTTP/3 uses UDP port 443 by 576 | convention but various methods can be used to specify alternate port numbers. 577 | Other applications (e.g., Microsoft's SMB over QUIC) also use UDP port 443 by 578 | default. Therefore, simple assumptions about whether a given flow is using 579 | QUIC, or indeed which application it might be using QUIC, based solely upon 580 | a UDP port number may not hold; see also {{Section 5 of RFC7605}}. 581 | 582 | While the second-most-significant bit (0x40) of the first octet is set to 1 in 583 | most QUIC packets of the current version (see {{public-header}} and {{Section 17 584 | of QUIC-TRANSPORT}}), this method of recognizing QUIC traffic is not reliable. 585 | First, it only provides one bit of information and is prone to collision with 586 | UDP-based protocols other than those considered in {{?RFC7983}}. Second, this 587 | feature of the wire image is not invariant {{QUIC-INVARIANTS}} and may change in 588 | future versions of the protocol, or even be negotiated during the handshake via 589 | the use of an extension {{QUIC-GREASE}}. 590 | 591 | Even though transport parameters transmitted in the client's Initial packet are 592 | observable by the network, they cannot be modified by the network without 593 | causing connection failure. Further, the reply from the server cannot be 594 | observed, so observers on the network cannot know which parameters are actually 595 | in use. 596 | 597 | ### Identifying Negotiated Version 598 | 599 | An in-network observer assuming that a set of packets belongs to a QUIC flow 600 | might infer the version number in use by observing the handshake. If the 601 | version number in an Initial packet of the server response is subsequently 602 | seen in a packet from the client, that version has been accepted by both 603 | endpoints to be used for the rest of the connection (see 604 | {{Section 2 of ?I-D.ietf-quic-version-negotiation}}). 605 | 606 | The negotiated version cannot be identified for flows for which a handshake is 607 | not observed, such as in the case of connection migration; however, it might be 608 | possible to associate a flow with a flow for which a version has been 609 | identified; see {{sec-flow-association}}. 610 | 611 | ### First Packet Identification for Garbage Rejection {#sec-garbage} 612 | 613 | A related question is whether the first packet of a given flow on a port known 614 | to be associated with QUIC is a valid QUIC packet. This determination supports 615 | in-network filtering of garbage UDP packets (reflection attacks, random 616 | backscatter, etc.). While heuristics based on the first byte of the packet 617 | (packet type) could be used to separate valid from invalid first packet types, 618 | the deployment of such heuristics is not recommended, as bits in the first byte 619 | may have different meanings in future versions of the protocol. 620 | 621 | ## Connection Confirmation {#sec-confirm} 622 | 623 | This document focuses on QUIC version 1, and this Connection Confirmation 624 | section applies only to packets belonging to QUIC version 1 flows; for purposes 625 | of on-path observation, it assumes that these packets have been identified as 626 | such through the observation of a version number exchange as described above. 627 | 628 | Connection establishment uses Initial and Handshake packets containing a 629 | TLS handshake, and Retry packets that do not contain parts of the handshake. 630 | Connection establishment can therefore be detected using heuristics similar to 631 | those used to detect TLS over TCP. A client initiating a connection may 632 | also send data in 0-RTT packets directly after the Initial 633 | packet containing the TLS Client Hello. Since packets may be reordered or lost 634 | in the network, 0-RTT packets could be seen before the Initial 635 | packet. 636 | 637 | Note that in this version of QUIC, clients send Initial packets before servers 638 | do, servers send Handshake packets before clients do, and only clients send 639 | Initial packets with tokens. Therefore, an endpoint can be identified as a 640 | client or server by an on-path observer. An attempted connection after Retry can 641 | be detected by correlating the contents of the Retry packet with the Token and 642 | the Destination Connection ID fields of the new Initial packet. 643 | 644 | ## Distinguishing Acknowledgment Traffic 645 | 646 | Some deployed in-network functions distinguish packets that carry only 647 | acknowledgment (ACK-only) information 648 | from packets carrying upper-layer data in order to attempt to enhance 649 | performance, for example by queueing ACKs differently or manipulating ACK 650 | signaling {{?RFC3449}}. Distinguishing ACK packets is possible in TCP, 651 | but is not supported by 652 | QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, 653 | and ACK manipulation is impossible. Specifically, heuristics attempting to 654 | distinguish ACK-only packets from payload-carrying packets based on packet size 655 | are likely to fail, and are not recommended to use as a way to construe 656 | internals of QUIC's operation as those mechanisms can change, e.g., due to the 657 | use of extensions. 658 | 659 | ## Server Name Indication (SNI) {#sec-server} 660 | 661 | The client's TLS ClientHello may contain a Server Name Indication (SNI) 662 | {{?RFC6066}} extension, by which the client reveals the name of the server it 663 | intends to connect to, in order to allow the server to present a certificate 664 | based on that name. SNI information is available to unidirectional observers 665 | on the client-to-server path, if present. 666 | 667 | The TLS ClientHello may also contain an Application-Layer Protocol 668 | Negotiation (ALPN) {{?RFC7301}} extension, by which the client exposes the names 669 | of application-layer protocols it supports; an observer can deduce that one of 670 | those protocols will be used if the connection continues. 671 | 672 | Work is currently underway in the TLS working group to encrypt the contents of 673 | the ClientHello in TLS 1.3 {{?TLS-ECH=I-D.ietf-tls-esni}}. This would make 674 | SNI-based application identification impossible by on-path observation for QUIC 675 | and other protocols that use TLS. 676 | 677 | ### Extracting Server Name Indication (SNI) Information 678 | 679 | If the ClientHello is not encrypted, SNI can be derived from the client's 680 | Initial packet(s) by calculating the Initial secret to decrypt the packet 681 | payload and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello. 682 | 683 | As both the derivation of the Initial secret and the structure of the Initial 684 | packet itself are version-specific, the first step is always to parse the 685 | version number (the second through fifth bytes of the long header). Note that 686 | only long header packets carry the version number, so it is necessary to also 687 | check if the first bit of the QUIC packet is set to 1, indicating a long header. 688 | 689 | Note that proprietary QUIC versions, that have been deployed before 690 | standardization, might not set the first bit in a QUIC long header packet to 691 | 1. However, it is expected that these versions will 692 | gradually disappear over time and therefore do not require any special 693 | consideration or treatment. 694 | 695 | When the version has been identified as QUIC version 1, the packet type needs to 696 | be verified as an Initial packet by checking that the third and fourth bits of 697 | the header are both set to 0. Then the Destination Connection ID needs to be 698 | extracted from the packet. The Initial secret is calculated using the 699 | version-specific Initial salt, as described in {{Section 5.2 of QUIC-TLS}}. 700 | The length of the connection ID is indicated in the 6th byte of the header 701 | followed by the connection ID itself. 702 | 703 | Note that subsequent Initial packets might contain a Destination Connection ID 704 | other than the one used to generate the Initial secret. Therefore, attempts to 705 | decrypt these packets using the procedure above might fail unless the Initial 706 | secret is retained by the observer. 707 | 708 | To determine the end of the packet header and find the start of the payload, 709 | the packet number length, the source connection ID length, and the token length 710 | need to be extracted. The packet number length is defined by the seventh and 711 | eight bits of the header as described in {{Section 17.2 of QUIC-TRANSPORT}}, 712 | but is protected as described in {{Section 5.4 of QUIC-TLS}}. The source 713 | connection ID length is specified in the byte after the destination 714 | connection ID. The token length, which follows the source connection ID, is 715 | a variable-length integer as specified in {{Section 16 of QUIC-TRANSPORT}}. 716 | 717 | After decryption, the client's Initial packet(s) can be parsed to detect the 718 | CRYPTO frame(s) that contains the TLS ClientHello, which then can be parsed 719 | similarly to TLS over TCP connections. Note that there can be multiple CRYPTO 720 | frames spread out over one or more Initial packets, and they might not be in 721 | order, so reassembling the CRYPTO stream by parsing offsets and lengths is 722 | required. Further, the client's Initial packet(s) may contain other frames, 723 | so the first bytes of each frame need to be checked to identify the frame 724 | type and determine whether the frame can be skipped over. Note that the 725 | length of the frames is dependent on the frame type; see 726 | {{Section 18 of QUIC-TRANSPORT}}. 727 | E.g., PADDING frames, each consisting of a single zero byte, may occur before, 728 | after, or between CRYPTO frames. However, extensions might define additional 729 | frame types. If an unknown frame type is encountered, it is impossible to 730 | know the length of that frame which prevents skipping over it, and therefore 731 | parsing fails. 732 | 733 | ## Flow Association {#sec-flow-association} 734 | 735 | The QUIC connection ID (see {{rebinding}}) is designed to allow a coordinating 736 | on-path device, such as a load-balancer, to associate two flows when one of the 737 | endpoints changes address. This change can be due to NAT rebinding or address 738 | migration. 739 | 740 | The connection ID must change upon intentional address change by an endpoint, 741 | and connection ID negotiation is encrypted, so it is not possible for a 742 | passive observer to link intended changes of address using the connection ID. 743 | 744 | When one endpoint's address unintentionally changes, as is the case with NAT 745 | rebinding, an on-path observer may be able to use the connection ID to 746 | associate the flow on the new address with the flow on the old address. 747 | 748 | A network function that attempts to use the connection ID to associate flows 749 | must be robust to the failure of this technique. Since the connection ID may 750 | change multiple times during the lifetime of a connection, packets with the 751 | same 5-tuple but different connection IDs might or might not belong to 752 | the same connection. Likewise, packets with the same connection ID but 753 | different 5-tuples might not belong to the same connection, either. 754 | 755 | Connection IDs should be treated as opaque; see {{sec-loadbalancing}} 756 | for caveats regarding connection ID selection at servers. 757 | 758 | ## Flow Teardown {#sec-teardown} 759 | 760 | QUIC does not expose the end of a connection; the only indication to on-path 761 | devices that a flow has ended is that packets are no longer observed. Stateful 762 | devices on path such as NATs and firewalls must therefore use idle timeouts to 763 | determine when to drop state for QUIC flows; see {{sec-stateful}}. 764 | 765 | 766 | ## Flow Symmetry Measurement {#sec-symmetry} 767 | 768 | QUIC explicitly exposes which side of a connection is a client and which side is 769 | a server during the handshake. In addition, the symmetry of a flow (whether 770 | primarily client-to-server, primarily server-to-client, or roughly 771 | bidirectional, as input to basic traffic classification techniques) can be 772 | inferred through the measurement of data rate in each direction. 773 | Note that QUIC packets containing only control frames (such as 774 | ACK-only packets) may be padded. Padding, though optional, 775 | may conceal connection roles or flow symmetry information. 776 | 777 | ## Round-Trip Time (RTT) Measurement {#sec-rtt} 778 | 779 | The round-trip time (RTT) of QUIC flows can be inferred 780 | by observation once per flow, 781 | during the handshake, as in passive TCP measurement; this requires parsing of 782 | the QUIC packet header and recognition of the handshake, as illustrated in 783 | {{handshake}}. It can also be inferred during the flow's lifetime, if the 784 | endpoints use the spin bit facility described below and in {{Section 17.3.1 of 785 | QUIC-TRANSPORT}}. RTT measurement is available to unidirectional observers 786 | when the spin bit is enabled. 787 | 788 | ### Measuring Initial RTT 789 | 790 | In the common case, the delay between the client's Initial packet (containing 791 | the TLS ClientHello) and the server's Initial packet (containing the TLS 792 | ServerHello) represents the RTT component on the path between the observer and 793 | the server. The delay between the server's first Handshake packet and the 794 | Handshake packet sent by the client represents the RTT component on the path 795 | between the observer and the client. While the client may send 0-RTT packets 796 | after the Initial packet during connection re-establishment, these can be 797 | ignored for RTT measurement purposes. 798 | 799 | Handshake RTT can be measured by adding the client-to-observer and 800 | observer-to-server RTT components together. This measurement necessarily 801 | includes all transport- and application-layer delay at both endpoints. 802 | 803 | ### Using the Spin Bit for Passive RTT Measurement {#spin-usage} 804 | 805 | The spin bit provides a version-specific method to measure per-flow RTT from 806 | observation points on the network path throughout the duration of a connection. 807 | See {{Section 17.4 of QUIC-TRANSPORT}} for the definition of the spin bit in 808 | Version 1 of QUIC. Endpoint participation in spin bit signaling is optional. 809 | That is, while its location is fixed in this version of QUIC, an endpoint can 810 | unilaterally choose to not support "spinning" the bit. 811 | 812 | Use of the spin bit for RTT measurement by devices on path is only possible when 813 | both endpoints enable it. Some endpoints may disable use of the spin bit by 814 | default, others only in specific deployment scenarios, e.g., for servers and 815 | clients where the RTT would reveal the presence of a VPN or proxy. To avoid 816 | making these connections identifiable based on the usage of the spin bit, all 817 | endpoints randomly disable "spinning" for at least one eighth of connections, 818 | even if otherwise enabled by default. An endpoint not participating in spin bit 819 | signaling for a given connection can use a fixed spin value for the duration of 820 | the connection, or can set the bit randomly on each packet sent. 821 | 822 | When in use, the latency spin bit in each direction changes value once per 823 | RTT any time that both endpoints are sending packets 824 | continuously. An on-path observer can observe the time difference between edges 825 | (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single direction to 826 | measure one sample of end-to-end RTT. This mechanism follows the principles of 827 | protocol measurability laid out in {{IPIM}}. 828 | 829 | Note that this measurement, as with passive RTT measurement for TCP, includes 830 | all transport protocol delay (e.g., delayed sending of acknowledgments) and/or 831 | application layer delay (e.g., waiting for a response to be generated). It 832 | therefore provides devices on path a good instantaneous estimate of the RTT as 833 | experienced by the application. 834 | 835 | However, application-limited and flow-control-limited senders can have 836 | application and transport layer delay, respectively, that are much greater than 837 | network RTT. When the sender is application-limited and e.g., only sends small 838 | amount of periodic application traffic, where that period is longer than the 839 | RTT, measuring the spin bit provides information about the application period, 840 | not the network RTT. 841 | 842 | Since the spin bit logic at each endpoint considers only samples from packets 843 | that advance the largest packet number, signal generation itself is 844 | resistant to reordering. However, reordering can cause problems at an observer 845 | by causing spurious edge detection and therefore inaccurate (i.e., lower) RTT 846 | estimates, if reordering occurs across a spin-bit flip in the stream. 847 | 848 | Simple heuristics based on the observed data rate per flow or changes in the RTT 849 | series can be used to reject bad RTT samples due to lost or reordered edges in 850 | the spin signal, as well as application or flow control limitation; for example, 851 | QoF {{TMA-QOF}} rejects component RTTs significantly higher than RTTs over the 852 | history of the flow. These heuristics may use the handshake RTT as an initial 853 | RTT estimate for a given flow. Usually such heuristics would also detect if 854 | the spin is either constant or randomly set for a connection. 855 | 856 | An on-path observer that can see traffic in both directions (from client to 857 | server and from server to client) can also use the spin bit to measure 858 | "upstream" and "downstream" component RTT; i.e, the component of the 859 | end-to-end RTT attributable to the paths between the observer and the server 860 | and the observer and the client, respectively. It does this by measuring the 861 | delay between a spin edge observed in the upstream direction and that observed 862 | in the downstream direction, and vice versa. 863 | 864 | Raw RTT samples generated using these techniques can be processed in various 865 | ways to generate useful network performance metrics. A simple linear smoothing 866 | or moving minimum filter can be applied to the stream of RTT samples to get a 867 | more stable estimate of application-experienced RTT. RTT samples measured from 868 | the spin bit can also be used to generate RTT distribution information, 869 | including minimum RTT (which approximates network RTT over longer time windows) 870 | and RTT variance (which approximates one-way packet delay variance as seen 871 | by an application end-point). 872 | 873 | # Specific Network Management Tasks 874 | 875 | In this section, we review specific network management and measurement 876 | techniques and how QUIC's design impacts them. 877 | 878 | ## Passive Network Performance Measurement and Troubleshooting 879 | 880 | Limited RTT measurement is possible by passive observation of QUIC traffic; 881 | see {{sec-rtt}}. No passive measurement of loss is possible with the present 882 | wire image. Limited observation of upstream congestion may be 883 | possible via the observation of Congestion Experienced (CE) markings in the 884 | IP header {{?RFC3168}} on ECN-enabled QUIC traffic. 885 | 886 | On-path devices can also make measurements of RTT, loss and other 887 | performance metrics when information is carried in an additional network-layer 888 | packet header (Section 6 of 889 | {{?RFC9065}} describes use of operations, 890 | administration and management (OAM) information). 891 | Using network-layer approaches also has the advantage that common observation 892 | and analysis tools can be consistently used for multiple transport protocols, 893 | however, these techniques are often limited to measurements within one or 894 | multiple cooperating domains. 895 | 896 | ## Stateful Treatment of QUIC Traffic {#sec-stateful} 897 | 898 | Stateful treatment of QUIC traffic (e.g., at a firewall or NAT middlebox) is 899 | possible through QUIC traffic and version identification ({{sec-identifying}}) 900 | and observation of the handshake for connection confirmation ({{sec-confirm}}). 901 | The lack of any visible end-of-flow signal ({{sec-teardown}}) means that this 902 | state must be purged either through timers or through least-recently-used 903 | eviction, depending on application requirements. 904 | 905 | While QUIC has no clear network-visible end-of-flow signal and therefore 906 | does require timer-based state removal, the QUIC handshake indicates 907 | confirmation by both ends of a valid bidirectional transmission. As soon 908 | as the handshake completed, timers should be set long enough to also 909 | allow for short idle time during a valid transmission. 910 | 911 | {{?RFC4787}} requires a network state timeout that is not less than 2 minutes 912 | for most UDP traffic. However, in practice, a QUIC endpoint can experience 913 | lower timeouts, in the range of 30 to 60 seconds {{QUIC-TIMEOUT}}. 914 | 915 | In contrast, {{?RFC5382}} recommends a state timeout of more than 2 916 | hours for TCP, given that TCP is a connection-oriented protocol with 917 | well-defined closure semantics. 918 | Even though QUIC has explicitly been designed to tolerate NAT rebindings, 919 | decreasing the NAT timeout is not recommended, as it may negatively impact 920 | application performance or incentivize endpoints to send very frequent 921 | keep-alive packets. 922 | 923 | The recommendation is therefore that, even when lower state timeouts are 924 | used for other UDP traffic, a state timeout of at least two minutes 925 | ought to be used for QUIC traffic. 926 | 927 | If state is removed too early, this could lead to black-holing of incoming 928 | packets after a short idle period. To detect this situation, a timer at the 929 | client needs to expire before a re-establishment can happen (if at all), which 930 | would lead to unnecessarily long delays in an otherwise working connection. 931 | 932 | Furthermore, not all endpoints use routing architectures where connections 933 | will survive a port or address change. So even when the client revives the 934 | connection, a NAT rebinding can cause a routing mismatch where a packet 935 | is not even delivered to the server that might support address migration. 936 | For these reasons, the limits in {{?RFC4787}} are important to avoid 937 | black-holing of packets (and hence avoid interrupting the flow of data to the 938 | client), especially where devices are able to distinguish QUIC traffic from 939 | other UDP payloads. 940 | 941 | The QUIC header optionally contains a connection ID which could provide 942 | additional entropy beyond the 5-tuple. The QUIC handshake needs 943 | to be observed in order to understand whether the connection ID is present and 944 | what length it has. However, connection IDs may be renegotiated 945 | after the handshake, and this renegotiation is not visible to the path. 946 | Therefore, using the connection ID as a flow key field for stateful treatment 947 | of flows is not recommended as connection ID changes will cause undetectable 948 | and unrecoverable loss of state in the middle of a connection. In particular, 949 | the use of the connection ID for functions that require state to make a 950 | forwarding decision is not viable as it will break connectivity, or at minimum 951 | cause long timeout-based delays before this problem is detected by the 952 | endpoints and the connection can potentially be re-established. 953 | 954 | Use of connection IDs is specifically discouraged for NAT applications. 955 | If a NAT hits an operational limit, it is recommended to rather drop the 956 | initial packets of a flow (see also {{sec-filtering}}), 957 | which potentially triggers TCP fallback. Use of the connection ID to 958 | multiplex multiple connections on the same IP address/port pair is not a 959 | viable solution as it risks connectivity breakage, in case the connection 960 | ID changes. 961 | 962 | ## Address Rewriting to Ensure Routing Stability 963 | 964 | While QUIC's migration capability makes it possible for a connection to survive 965 | client address changes, this does not work if the routers or switches in the 966 | server infrastructure route using the address-port 4-tuple. If infrastructure 967 | routes on addresses only, NAT rebinding or address migration will cause packets 968 | to be delivered to the wrong server. {{QUIC-LB}} describes a way to addresses 969 | this problem by coordinating the selection and use of connection IDs between 970 | load-balancers and servers. 971 | 972 | Applying address translation at a middlebox to maintain a stable 973 | address-port mapping for flows based on connection ID might seem 974 | like a solution to this problem. However, hiding information about the 975 | change of the IP address or port conceals important and security-relevant 976 | information from QUIC endpoints and as such would facilitate amplification 977 | attacks (see {{Section 8 of QUIC-TRANSPORT}}). A NAT function that hides 978 | peer address changes prevents the other end from 979 | detecting and mitigating attacks as the endpoint cannot verify connectivity 980 | to the new address using QUIC PATH_CHALLENGE and PATH_RESPONSE frames. 981 | 982 | In addition, a change of IP address or port is also an input signal to other 983 | internal mechanisms in QUIC. When a path change is detected, path-dependent 984 | variables like congestion control parameters will be reset protecting 985 | the new path from overload. 986 | 987 | ## Server Cooperation with Load Balancers {#sec-loadbalancing} 988 | 989 | In the case of networking architectures that include load balancers, 990 | the connection ID can be used as a way for the server to signal information 991 | about the desired treatment of a flow to the load balancers. Guidance on 992 | assigning connection IDs is given in 993 | {{?QUIC-APPLICABILITY=I-D.ietf-quic-applicability}}. {{QUIC-LB}} 994 | describes a system for coordinating selection and use of connection IDs between 995 | load-balancers and servers. 996 | 997 | ## Filtering Behavior {#sec-filtering} 998 | 999 | {{?RFC4787}} describes possible packet filtering behaviors that relate to NATs 1000 | but is often also used is other scenarios where packet filtering is desired. 1001 | Though the guidance there holds, a particularly unwise behavior admits a 1002 | handful of UDP packets and then makes a decision to whether or not filter 1003 | later packets in the same connection. 1004 | QUIC applications are encouraged to fall back to TCP if early packets do 1005 | not arrive at their destination {{?QUIC-APPLICABILITY}}, as QUIC is 1006 | based on UDP and there are known blocks of UDP traffic (see {{sec-udp-1312}}). 1007 | Admitting a few packets allows the QUIC endpoint to determine that the path 1008 | accepts QUIC. Sudden drops afterwards will result in slow and costly timeouts 1009 | before abandoning the connection. 1010 | 1011 | ## UDP Blocking, Throttling, and NAT Binding {#sec-udp-1312} 1012 | 1013 | Today, UDP is the most prevalent DDoS vector, since it is easy for compromised 1014 | non-admin applications to send a flood of large UDP packets (while with TCP the 1015 | attacker gets throttled by the congestion controller) or to craft reflection and 1016 | amplification attacks. Some networks therefore block UDP traffic. 1017 | With increased deployment of QUIC, there is also an increased need to allow 1018 | UDP traffic on ports used for QUIC. However, if UDP is generally enabled on 1019 | these ports, UDP flood attacks may also use the same ports. One possible 1020 | response to this threat is to throttle UDP traffic on the network, allocating a 1021 | fixed portion of the network capacity to UDP and blocking UDP datagrams over 1022 | that cap. As the portion of QUIC traffic compared to TCP is also expected to 1023 | increase over time, using such a limit is not recommended but if done, 1024 | limits might need to be adapted dynamically. 1025 | 1026 | Further, if UDP traffic is desired to be throttled, it is recommended to 1027 | block individual 1028 | QUIC flows entirely rather than dropping packets indiscriminately. 1029 | When the handshake is blocked, QUIC-capable applications may fall back 1030 | to TCP. However, blocking a random fraction of QUIC packets across 1031 | 4-tuples will allow many QUIC handshakes to complete, preventing TCP fallback, 1032 | but these connections will suffer from 1033 | severe packet loss (see also {{sec-filtering}}). Therefore, UDP throttling 1034 | should be realized by per-flow policing, as opposed to per-packet 1035 | policing. Note that this per-flow policing should be stateless to avoid 1036 | problems with stateful treatment of QUIC flows (see {{sec-stateful}}), 1037 | for example blocking a portion of the space of values of a hash function 1038 | over the addresses and ports in the UDP datagram. 1039 | While QUIC endpoints are often able to survive address changes, e.g., by NAT 1040 | rebindings, blocking a portion of the traffic based on 5-tuple hashing increases 1041 | the risk of black-holing an active connection when the address changes. 1042 | 1043 | Note that some source ports are assumed to be reflection attack vectors by some 1044 | servers; see {{Section 8.1 of QUIC-APPLICABILITY}}. As a result, NAT 1045 | binding to these source ports can result in that traffic being blocked. 1046 | 1047 | 1048 | ## DDoS Detection and Mitigation {#sec-ddos-dec} 1049 | 1050 | On-path observation of the transport headers of packets can be used for various 1051 | security functions. For example, Denial of Service (DoS) and Distributed DoS 1052 | (DDoS) attacks against the infrastructure or against an endpoint can be 1053 | detected and mitigated by characterising anomalous traffic. 1054 | Other uses include support for security audits (e.g., verifying the 1055 | compliance with ciphersuites); client and application fingerprinting for 1056 | inventory; and to provide alerts for network intrusion detection and other 1057 | next generation firewall functions. 1058 | 1059 | Current practices in detection and mitigation of DDoS 1060 | attacks generally involve classification of incoming traffic (as 1061 | packets, flows, or some other aggregate) into "good" (productive) and "bad" 1062 | (DDoS) traffic, and then differential treatment of this traffic to forward only 1063 | good traffic. This operation is often done in a separate specialized mitigation 1064 | environment through which all traffic is filtered; a generalized architecture 1065 | for separation of concerns in mitigation is given in 1066 | {{?DOTS-ARCH=RFC8811}}. 1067 | 1068 | Efficient classification of this DDoS traffic in the mitigation environment 1069 | is key to the success of this approach. Limited first-packet garbage detection 1070 | as in {{sec-garbage}} and stateful tracking of QUIC traffic as in 1071 | {{sec-stateful}} above may be useful during classification. 1072 | 1073 | Note that the use of a connection ID to support connection migration renders 1074 | 5-tuple based filtering insufficient to detect active flows and requires more 1075 | state to be maintained by DDoS defense systems if support of migration of QUIC 1076 | flows is desired. For the common case of NAT rebinding, where the client's 1077 | address changes without the client's intent or knowledge, DDoS defense systems 1078 | can detect a change in the client's endpoint address by linking flows based on 1079 | the server's connection IDs. However, QUIC's linkability resistance ensures that 1080 | a deliberate connection migration is accompanied by a change in the connection 1081 | ID. In this case, the connection ID can not be used to distinguish valid, active 1082 | traffic from new attack traffic. 1083 | 1084 | It is also possible for 1085 | endpoints to directly support security functions such as DoS 1086 | classification and mitigation. 1087 | Endpoints can cooperate with an in-network device directly by e.g., 1088 | sharing information about connection IDs. 1089 | 1090 | Another potential method could use an 1091 | on-path network device that relies on pattern inferences in the traffic and 1092 | heuristics or machine learning instead of processing observed header 1093 | information. 1094 | 1095 | However, it is questionable whether connection migrations must be supported 1096 | during a DDoS attack. While unintended migration without a connection ID 1097 | change can be more easily supported, it might be acceptable to not 1098 | support migrations of active QUIC connections that are not visible to 1099 | the network functions performing the DDoS detection. 1100 | As soon as the connection blocking is detected by the client, 1101 | the client may be able to rely on the 0-RTT data mechanism 1102 | provided by QUIC. When clients migrate to a new path, they should be prepared 1103 | for the migration to fail and attempt to reconnect quickly. 1104 | 1105 | Beyond in-network DDoS protection mechanisms, TCP syncookies {{?RFC4937}} 1106 | are a well-established method of mitigating some 1107 | kinds of TCP DDoS attacks. QUIC Retry packets are the functional analogue to 1108 | syncookies, forcing clients to prove possession of their IP address before 1109 | committing server state. However, there are safeguards in QUIC against 1110 | unsolicited injection of these packets by intermediaries who do not have consent 1111 | of the end server. See {{?QUIC-RETRY=I-D.duke-quic-retry-offload}} for standard 1112 | ways for intermediaries to send Retry packets on behalf of consenting servers. 1113 | 1114 | 1115 | ## Quality of Service Handling and ECMP Routing 1116 | 1117 | It is expected that any QoS handling in the network, e.g., based on use of 1118 | DiffServ Code Points (DSCPs) {{?RFC2475}} as well as Equal-Cost 1119 | Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) 1120 | and as such that all packets belonging to the same active QUIC connection 1121 | get uniform treatment. 1122 | 1123 | Using ECMP to distribute packets from a single flow across multiple 1124 | network paths or any other non-uniform treatment of packets belong to the same 1125 | connection could result in variations in order, delivery rate, and drop rate. 1126 | As feedback about loss or delay of each packet is used as input to 1127 | the congestion controller, these variations could adversely affect performance. 1128 | Depending on the loss recovery mechanism implemented, QUIC may be 1129 | more tolerant of packet re-ordering than typical TCP traffic (see 1130 | {{packetnumber}}). However, the recovery mechanism used by a flow cannot be 1131 | known by the network and therefore reordering tolerance should be 1132 | considered as unknown. 1133 | 1134 | Note that the 5-tuple of a QUIC connection can change due to migration. 1135 | In this case different flows are observed by the path and maybe be treated 1136 | differently, as congestion control is usually reset on migration (see also 1137 | {{sec-flow-association}}). 1138 | 1139 | ## Handling ICMP Messages 1140 | 1141 | Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by QUIC to 1142 | probe for the supported PMTU. PLPMTUD optionally uses ICMP messages (e.g., 1143 | IPv6 Packet Too Big messages). Given known attacks with the use of ICMP 1144 | messages, the use of PLPMTUD in QUIC has been designed to safely use but 1145 | not rely on receiving ICMP feedback (see 1146 | {{Section 14.2.1. of QUIC-TRANSPORT}}). 1147 | 1148 | Networks are recommended to forward these ICMP messages and retain as much of 1149 | the original packet as possible without exceeding the minimum MTU for the IP 1150 | version when generating ICMP messages as recommended in {{?RFC1812}} 1151 | and {{?RFC4443}}. 1152 | 1153 | ## Guiding Path MTU 1154 | 1155 | Some network segments support 1500-byte packets, 1156 | but can only do so by fragmenting at a 1157 | lower layer before traversing a network segment with a smaller MTU, 1158 | and then reassembling within the network segment. 1159 | This is permissible even when the IP layer is IPv6 or IPv4 with the DF bit set, 1160 | because fragmentation occurs below the IP layer. 1161 | However, this process can add to compute 1162 | and memory costs, leading to a bottleneck that limits network capacity. In such 1163 | networks this generates a desire to influence a majority of senders to use 1164 | smaller packets, to avoid exceeding limited reassembly capacity. 1165 | 1166 | For TCP, MSS clamping ({{Section 3.2 of RFC4459}}) is often used to change 1167 | the sender's TCP maximum segment size, but QUIC requires a different approach. 1168 | {{Section 14 of QUIC-TRANSPORT}} advises senders to probe larger sizes using 1169 | Datagram Packetization Layer PMTU Discovery ({{?DPLPMTUD=RFC8899}}) or Path 1170 | Maximum Transmission Unit Discovery (PMTUD: {{?RFC1191}} and {{?RFC8201}}). 1171 | This mechanism encourages senders to approach the maximum packet size, which 1172 | could then cause fragmentation within a network segment of which 1173 | they may not be aware. 1174 | 1175 | If path performance is limited when forwarding larger packets, an on-path 1176 | device should support a maximum packet size for a specific transport flow 1177 | and then consistently drop all packets that exceed the configured size 1178 | when the inner IPv4 packet has DF set, or IPv6 is used. 1179 | 1180 | Networks with configurations that would lead to fragmentation of large 1181 | packets within a network segment should drop such packets rather than 1182 | fragmenting them. Network operators who plan to implement a more 1183 | selective policy may start by focusing on QUIC. 1184 | 1185 | QUIC flows cannot always be easily distinguished from other UDP traffic, but 1186 | we assume at least some portion of QUIC traffic can be identified 1187 | (see {{sec-identifying}}). For networks supporting QUIC, it is recommended 1188 | that a path drops any packet larger than the fragmentation size. 1189 | When a QUIC endpoint uses DPLPMTUD, it will use a QUIC probe packet to 1190 | discover the PMTU. If this probe is lost, it will not impact the flow of 1191 | QUIC data. 1192 | 1193 | IPv4 routers generate an ICMP message when a packet is dropped because the 1194 | link MTU was exceeded. {{?RFC8504}} specifies how an IPv6 node generates an 1195 | ICMPv6 Packet Too Big message (PTB) in this case. PMTUD relies upon an 1196 | endpoint receiving such PTB messages {{?RFC8201}}, whereas DPLPMTUD does not 1197 | reply upon these messages, but still can optionally use these to improve 1198 | performance {{Section 4.6 of DPLPMTUD}}. 1199 | 1200 | A network cannot know in advance which discovery method is used by a QUIC 1201 | endpoint, so it should send a PTB message in addition to dropping an 1202 | oversized packet. A generated PTB message should be compliant with the 1203 | validation requirements of {{Section 14.2.1 of QUIC-TRANSPORT}}, otherwise 1204 | it will be ignored for PMTU discovery. This provides a signal to the 1205 | endpoint to prevent the packet size from growing too large, which can 1206 | entirely avoid network segment fragmentation for that flow. 1207 | 1208 | Endpoints can cache PMTU information, in the IP-layer cache. This short-term 1209 | consistency between the PMTU for flows can help avoid an endpoint using a 1210 | PMTU that is inefficient. The IP cache can also influence the PMTU value of 1211 | other IP flows that use the same path {{?RFC8201}}{{?DPLPMTUD}}, 1212 | including IP packets carrying 1213 | protocols other than QUIC. The representation of an IP path is 1214 | implementation-specific {{?RFC8201}}. 1215 | 1216 | # IANA Considerations 1217 | 1218 | This document has no actions for IANA. 1219 | 1220 | # Security Considerations 1221 | 1222 | QUIC is an encrypted and authenticated transport. That means, once the 1223 | cryptographic handshake is complete, QUIC endpoints discard most packets that 1224 | are not authenticated, greatly limiting the ability of an attacker to interfere 1225 | with existing connections. 1226 | 1227 | However, some information is still observable, as supporting manageability of 1228 | QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's 1229 | control information; this entire document is therefore security-relevant. 1230 | 1231 | More security considerations for QUIC are discussed in {{!QUIC-TRANSPORT}} 1232 | and {{!QUIC-TLS}}, generally considering active or passive attackers in the 1233 | network as well as attacks on specific QUIC mechanism. 1234 | 1235 | Version Negotiation packets do not contain any mechanism to prevent version 1236 | downgrade attacks. However, future versions of QUIC that use Version Negotiation 1237 | packets are required to define a mechanism that is robust against version 1238 | downgrade attacks. Therefore, a network node should not attempt to impact 1239 | version selection, as version downgrade may result in connection failure. 1240 | 1241 | # Contributors 1242 | 1243 | The following people have contributed significant text to and/or 1244 | feedback on this document: 1245 | 1246 | * Chris Box 1247 | * Dan Druta 1248 | * David Schinazi 1249 | * Gorry Fairhurst 1250 | * Ian Swett 1251 | * Igor Lubashev 1252 | * Jana Iyengar 1253 | * Jared Mauch 1254 | * Lars Eggert 1255 | * Lucas Purdue 1256 | * Marcus Ihlar 1257 | * Mark Nottingham 1258 | * Martin Duke 1259 | * Martin Thomson 1260 | * Matt Joras 1261 | * Mike Bishop 1262 | * Nick Banks 1263 | * Thomas Fossati 1264 | * Sean Turner 1265 | 1266 | # Acknowledgments 1267 | 1268 | Special thanks to last call reviewers Elwyn Davies, Barry Leiba, 1269 | Al Morton, and Peter Saint-Andre. 1270 | 1271 | This work was partially supported by the European Commission under Horizon 2020 1272 | grant agreement no. 688421 Measurement and Architecture for a Middleboxed 1273 | Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and 1274 | Innovation under contract no. 15.0268. This support does not imply endorsement. 1275 | -------------------------------------------------------------------------------- /writeups/quic-applicability.txt: -------------------------------------------------------------------------------- 1 | As required by RFC 4858, this is the current template for the Document 2 | Shepherd Write-Up. Changes are expected over time. 3 | 4 | This version is dated 1 November 2019. 5 | 6 | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 7 | Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about. 8 | 9 | (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 10 | 11 | Technical Summary: 12 | 13 | This document discusses applicability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. Its intended audience is those interested in understanding and developing new applications which use QUIC as their underlying transport protocol. 14 | 15 | Working Group Summary: 16 | 17 | This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes and non-HTTP applications running over QUIC. 18 | 19 | Document Quality: 20 | 21 | This document is informational and meant for application developers and deployers. There has been extensive feedback on the contents from implementers, QUIC deployments, and researchers. We believe it to be high quality information about QUIC for application developers. 22 | 23 | Personnel: 24 | 25 | Who is the Document Shepherd? Who is the Responsible Area Director? 26 | Matt Joras is the document shepherd, Zahed Sarker the AD. 27 | 28 | (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 29 | I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication. 30 | 31 | (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 32 | No, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far. 33 | 34 | (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 35 | I don't believe so. 36 | 37 | (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 38 | No specific concerns. 39 | 40 | (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? 41 | There are no IPR disclosures require for this document. 42 | 43 | (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 44 | No. 45 | 46 | (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 47 | It has received a wide diversity of review from implementers, deployers of QUIC, and researchers. There have been two WGLCs, where feedback from the first was integrated, thus the consensus is good though the engagement has overall been less than the original QUIC documents. 48 | 49 | (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 50 | No. 51 | 52 | (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 53 | 4 non-ascii characters, outdated references to documents now published as RFCs. 54 | 55 | (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 56 | N/A 57 | 58 | (13) Have all references within this document been identified as either normative or informative? 59 | Yes. 60 | 61 | (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 62 | No. 63 | 64 | (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 65 | No. 66 | 67 | (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 68 | No. 69 | 70 | (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 71 | N/A. 72 | 73 | (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 74 | N/A. 75 | 76 | (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. 77 | N/A 78 | 79 | (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? 80 | N/A 81 | -------------------------------------------------------------------------------- /writeups/quic-manageability.txt: -------------------------------------------------------------------------------- 1 | As required by RFC 4858, this is the current template for the Document 2 | Shepherd Write-Up. Changes are expected over time. 3 | 4 | This version is dated 1 November 2019. 5 | 6 | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 7 | Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about. 8 | 9 | (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 10 | 11 | Technical Summary: 12 | 13 | This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. 14 | 15 | Working Group Summary: 16 | 17 | This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes. 18 | 19 | Document Quality: 20 | 21 | This document is informational and meant for network operators. There has been extensive feedback on the contents from implementers, QUIC deployments, network operators, and researchers. We believe it to be high quality information about QUIC for network operators. 22 | 23 | Personnel: 24 | 25 | Who is the Document Shepherd? Who is the Responsible Area Director? 26 | Matt Joras is the document shepherd, Zahed Sarker the AD. 27 | 28 | (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 29 | I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication. 30 | 31 | (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 32 | No, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far. 33 | 34 | (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 35 | I don't believe so. 36 | 37 | (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 38 | No specific concerns. 39 | 40 | (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? 41 | There are no IPR disclosures require for this document. 42 | 43 | (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 44 | No. 45 | 46 | (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 47 | It has received a wide diversity of review from implementers, deployers of QUIC, network operators, and researchers. There have been two WGLCs, where feedback from the first was integrated, thus the consensus is good though the engagement has overall been less than the original QUIC documents. 48 | 49 | (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 50 | No. 51 | 52 | (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 53 | 4 non-ascii characters, outdated references to documents now published as RFCs. 54 | 55 | (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 56 | N/A 57 | 58 | (13) Have all references within this document been identified as either normative or informative? 59 | Yes. 60 | 61 | (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 62 | No. 63 | 64 | (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 65 | No. 66 | 67 | (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 68 | No. 69 | 70 | (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 71 | N/A. 72 | 73 | (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 74 | N/A. 75 | 76 | (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. 77 | N/A 78 | 79 | (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? 80 | N/A 81 | --------------------------------------------------------------------------------