idnits 2.17.1 draft-montenegro-quic-negotiate-pnp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2018) is 2053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 162 -- Looks like a reference, but probably isn't: '2' on line 164 -- Looks like a reference, but probably isn't: '3' on line 166 -- No information found for draft-ietf-quic-tls-latest - is the name correct? -- No information found for draft-ietf-quic-transport-latest - is the name correct? Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC G. Montenegro 3 Internet-Draft N. Banks 4 Intended status: Informational P. Balasubramanian 5 Expires: March 17, 2019 Microsoft Corporation 6 September 13, 2018 8 QUIC Negotiation for Packet Number Protection 9 draft-montenegro-quic-negotiate-pnp-02 11 Abstract 13 This document defines an extension to reduce the cost of QUIC 14 deployment in environments like datacenters by allowing packet number 15 protection to be optionally disabled. 17 Note to Readers 19 Discussion of this draft takes place on the QUIC working group 20 mailing list (quic@ietf.org), which is archived at 21 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 23 Working Group information can be found at https://github.com/quicwg 24 [2]; source code and issues list for this draft can be found at 25 https://github.com/quicwg/base-drafts/labels/-recovery [3]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 17, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 63 3. Transport Parameter to Disable Packet Number Protection . . . 3 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 72 1. Introduction 74 QUIC is a new transport for the internet. In its generality, there 75 are features which are not well suited for some environments. In 76 particular, QUIC uses Packet Number Protection (PNP) to prevent 77 ossification and to provide unlinkability upon (voluntary) migration. 78 However, there are environments where these are not a concern, in 79 particular, connections within a datacenter. 81 This document defines a negotiation mechanism using transport 82 parameters to disable PNP. Internet facing nodes SHOULD NOT disable 83 PNP, so browsers, for example, should not implement this extension. 84 On the other hand, configured nodes within a datacenter could turn 85 off PNP in their exchanges to avoid the CPU cost that PNP implies. 87 2. Conventions and Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 3. Transport Parameter to Disable Packet Number Protection 97 This document defines a new transport parameter for QUIC 98 [QUIC-TRANSPORT]: 100 disable_packet_number_protection (0x000c ?, value TBD): The endpoint 101 is disabling packet number protection as specified in [QUIC-TLS]. 102 This parameter is a zero-length value. This parameter only 103 affects short headers. 105 A successful negotiation of the "disable_packet_number_protection" 106 parameter requires both peers to send this transport parameter as 107 well as the "disable_migration" parameter. 109 An endpoint MUST treat receipt of "disable_packet_number_protection" 110 without the "disable_migration" parameter as a connection error of 111 type TRANSPORT_PARAMETER_ERROR. 113 Peers that have successfully negotiated the 114 "disable_packet_number_protection" parameter MUST NOT use packet 115 number protection on short header packets. 117 4. Security Considerations 119 Per section 6.11.5 of [QUIC-TLS], PNP is used as a partial mitigation 120 against linkability, and to prevent ossification. The 121 "disable_packet_number_protection" parameter should be negotiated in 122 environments in which these are not a concern. 124 5. IANA Considerations 126 Per section 13.1 of [QUIC-TLS], this document requests IANA assign a 127 value for the new transport parameter and record it in the registry 128 for "QUIC Transport Parameters" under the "QUIC Protocol" heading. 129 IANA is further requested to assign a value with the first byte in 130 the range 0x00 to 0xfe (in hexadecimal) as follows: 132 +--------+----------------------------------+---------------+ 133 | Value | Parameter Name | Specification | 134 +--------+----------------------------------+---------------+ 135 | 0x000c | disable_packet_number_protection | This document | 136 +--------+----------------------------------+---------------+ 138 6. References 139 6.1. Normative References 141 [QUIC-TLS] 142 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 143 Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls- 144 latest (work in progress). 146 [QUIC-TRANSPORT] 147 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 148 Multiplexed and Secure Transport", draft-ietf-quic- 149 transport-latest (work in progress). 151 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 152 Requirement Levels", BCP 14, RFC 2119, 153 DOI 10.17487/RFC2119, March 1997, 154 . 156 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 157 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 158 May 2017, . 160 6.2. URIs 162 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 164 [2] https://github.com/quicwg 166 [3] https://github.com/quicwg/base-drafts/labels/-recovery 168 Acknowledgments 170 Thanks to the following individuals for useful discussions: Christian 171 Huitema, Martin Thomson, Mikkel Fahnoee Joergensen, Ian Swett, Martin 172 Duke, Lucas Pardue. 174 Authors' Addresses 176 Gabriel Montenegro 177 Microsoft Corporation 179 Email: Gabriel.Montenegro@Microsoft.com 181 Nick Banks 182 Microsoft Corporation 184 Email: NiBanks@Microsoft.com 185 Praveen Balasubramanian 186 Microsoft Corporation 188 Email: PravB@Microsoft.com