idnits 2.17.1 draft-pauly-quic-address-extension-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1872 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft C. Wood 4 Intended status: Standards Track E. Kinnear 5 Expires: September 12, 2019 Apple Inc. 6 March 11, 2019 8 QUIC Address Extension 9 draft-pauly-quic-address-extension-00 11 Abstract 13 This document defines an extension to the QUIC transport protocol 14 that adds support for requesting and receiving the public network 15 address of an endpoint from its peer. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 12, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2.1. Connection Lifetime Optimizations . . . . . . . . . . . . 3 55 2.2. Privacy Stance Enhancements . . . . . . . . . . . . . . . 3 56 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 3 57 4. Address Request and Response Frame Types . . . . . . . . . . 3 58 5. Address Frame Usage . . . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a 67 secure, multiplexed connection for transmitting reliable streams of 68 application data. Connections are associated with unique Connection 69 Identifiers (CIDs) that facilitate migration for clients that are 70 mobile or have multiple network associations. CIDs also help 71 connections survive Network Address Translator (NAT) port re- 72 bindings, provided that the client behind the NAT sends a new packet 73 with a known CID before the server drops the connection. 75 There is currently no explicit signal an endpoint can use to detect 76 the presence of NATs. This problematic as it can encourage endpoints 77 to aggressively send packets to keep NAT bindings alive. 79 This document describes an extension to QUIC that enables peers to 80 request their public address and port from peers. This can be used 81 to detect NATs and to help guide CID rotation policies. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 89 as shown here. 91 2. Motivation 93 There are several cases in which an endpoint might wish to know its 94 public network address. 96 2.1. Connection Lifetime Optimizations 98 Knowing whether or not an endpoint is behind a NAT can help guide 99 connection keepalive mechanisms. For example, peers that are not 100 behind NATs might not need to send frequent keepalive packets (such 101 as packets containing PING frames) to prevent NAT bindings 102 expiration. This is particularly useful for UDP-based protocols such 103 as QUIC, since UDP often has low idle timeouts configured on NATs or 104 other middleboxes. 106 Note that there may still be stateful firewalls present in the 107 network that have short timeouts, so NAT detection cannot be used as 108 the only heuristic for a QUIC client's keepalive algorithm. 110 2.2. Privacy Stance Enhancements 112 A QUIC endpoint might choose to rotate CIDs and UDP ports even over 113 the same network interface to decrease the linkability of its 114 traffic. However, the effectiveness of this approach can be limited 115 if the endpoint is communicating using a fixed public IP address. 116 Detecting a NAT increases the likelihood that rotating CIDs and UDP 117 ports will be an effective strategy to obscure client traffic 118 patterns. 120 3. Transport Parameter 122 Support for sending and receiving PUBLIC_ADDRESS_REQUEST and 123 PUBLIC_ADDRESS_RESPONSE frames is advertised by means of a QUIC 124 Transport Parameter (name=supports_address_request, value=0x000f). 125 An endpoint that includes this parameter supports both requests and 126 responses. Endpoints MUST NOT send requests or responses unless both 127 parties signal support for these frames. An endpoint that receives a 128 PUBLIC_ADDRESS_REQUEST or PUBLIC_ADDRESS_RESPONSE frame when it 129 without sending the supports_address_request parameter MUST terminate 130 the connection with error PROTOCOL_VIOLATION. 132 4. Address Request and Response Frame Types 134 A PUBLIC_ADDRESS_REQUEST frame has the following structure. 136 0 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Request ID | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Request ID is a randomly generated 32-bit identifier for the request. 144 A PUBLIC_ADDRESS_RESPONSE frame has the following structure. 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Request ID | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Address Type | Address Value (*) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Port | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 The fields of a PUBLIC_ADDRESS_RESPONSE frame are as follows: 158 Request ID: A 32-bit value indicating the ID of the corresponding 159 request. 161 Address Type: A single octet equal to 0x00 or 0x01, indicating that 162 the body carries an IPv4 or IPv6 address, respectively. 164 Address Value: A 32- or 128-bit value encoding an IPv4 or IPv6 165 address, respectively, depending on the value of Address Type. 167 Port: A 16-bit integer representing the peer's corresponding port. 169 5. Address Frame Usage 171 An endpoint MAY send a request or response frame at any point after 172 connection establishment. Endpoints SHOULD send address request 173 frames following connection migration to learn if there is a change 174 in its public address on the new path. 176 6. Security Considerations 178 PUBLIC_ADDRESS_REQUEST and PUBLIC_ADDRESS_RESPONSE frames are sent in 179 encrypted QUIC packets and are therefore not visible to passive 180 observers. Moreover, since endpoints can only request their public 181 address, peers cannot accidentally transmit their (possibly private) 182 address to a peer. 184 Endpoints that receive their perceived address from their peer cannot 185 assume that the address is correct or trusted. The peer is able to 186 send a fabricated address, so the result MUST NOT be used for any 187 security-related decisions. 189 7. IANA Considerations 191 This document registers a new value in the QUIC Transport Parameter 192 Registry: 194 Value: 0x000f (if this document is approved) 196 Parameter Name: supports_address_request 198 Specification: Indicates that the connection should enable support 199 for PUBLIC_ADDRESS_REQUEST and PUBLIC_ADDRESS_RESPONSE. An 200 endpoint that advertises this transport parameter can support both 201 sending and receiving these frames. 203 This document also registers two new values in the QUIC Frame Type 204 Registry: 206 Value: 0x1e (if this document is approved) 208 Frame Name: PUBLIC_ADDRESS_REQUEST 210 Specification: Requests that the peer sends back the public address 211 of sender 213 Value: 0x1f (if this document is approved) 215 Frame Name: PUBLIC_ADDRESS_RESPONSE 217 Specification: A response to a PUBLIC_ADDRESS_REQUEST containing the 218 requester's public address 220 8. Normative References 222 [I-D.ietf-quic-transport] 223 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 224 and Secure Transport", draft-ietf-quic-transport-18 (work 225 in progress), January 2019. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, 229 DOI 10.17487/RFC2119, March 1997, 230 . 232 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 233 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 234 May 2017, . 236 Authors' Addresses 238 Tommy Pauly 239 Apple Inc. 240 One Apple Park Way 241 Cupertino, California 95014 242 United States of America 244 Email: tpauly@apple.com 246 Christopher A. Wood 247 Apple Inc. 248 One Apple Park Way 249 Cupertino, California 95014 250 United States of America 252 Email: cawood@apple.com 254 Eric Kinnear 255 Apple Inc. 256 One Apple Park Way 257 Cupertino, California 95014 258 United States of America 260 Email: ekinnear@apple.com