idnits 2.17.1 draft-duke-quic-natsupp-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 25, 2019) is 1612 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-quic-invariants-latest - is the name correct? -- No information found for draft-duke-quic-load-balancers-latest - is the name correct? -- No information found for draft-ietf-quic-transport-latest - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Informational November 25, 2019 5 Expires: May 28, 2020 7 Network Address Translation Support for QUIC 8 draft-duke-quic-natsupp-00 10 Abstract 12 Network Address Translators (NATs) are widely deployed to share 13 scarce public IPv4 addresses among mutiple end hosts. They overwrite 14 IP addresses and ports in IP packets to do so. QUIC is a protocol on 15 top of UDP that provides transport-like services. QUIC is better- 16 behaved in the presence of NATs than older protocols, and existing 17 UDP NATs should operate without incident if unmodified. QUIC offers 18 additional features that may tempt NAT implementers as potential 19 optimizations. However, in practice, leveraging these features will 20 lead to new connection failure modes and security vulnerabilities. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 28, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. QUIC and NAT Rebinding . . . . . . . . . . . . . . . . . . . 3 59 4. The Lure of the Connection ID . . . . . . . . . . . . . . . . 3 60 4.1. Resource Conservation . . . . . . . . . . . . . . . . . . 3 61 4.2. "Helping" with routing infrastructure issues . . . . . . 3 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 7. Informative References . . . . . . . . . . . . . . . . . . . 4 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 Network Address Translators (NATs) are a widely deployed means of 71 multiplexing multiple private IP addresses over scarce IPv4 public 72 address space by replacing those addresses and using ports to 73 distinguish those connections. The new address can also guarantee 74 that packets move through a proxy throughout the life of a 75 connection, so that the connection can continue with the required 76 state at that proxy. 78 QUIC [QUIC-TRANSPORT] is a protocol, operating over UDP, that 79 provides many transport-like services to the application layer. 80 Among these services is the mapping of multiple endpoint IP addresses 81 to a single connection through use of a Connection ID (CID). 82 Connection IDs are opaque byte fields that are expressed consistently 83 across all QUIC versions [QUIC-INVARIANTS]. This feature may appear 84 to present opportunities to optimize NAT port usage and simplify the 85 work of the QUIC server. In fact, NAT behavior that relies on CID 86 may instead cause connection failure when endpoints change Connection 87 ID, and disable important protocol security features. 89 The remainder of this document explains how QUIC supports NATs better 90 than other connection-oriented protocols, why NAT use of Connection 91 ID might appear attractive, and how NAT use of CID can create serious 92 problems for the endpoints. The conclusion of this document is that 93 NATs should retain their existing 4-tuple-based operation and refrain 94 from parsing or otherwise using QUIC connection IDs. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. QUIC and NAT Rebinding 104 An explicit goal of QUIC is to be robust to NAT rebinding. When a 105 connection is idle for a long time, the NAT may guess it has 106 terminated and assign the client port to a new connection. If either 107 endpoint attempts to resume communication, the packet will be 108 assigned a new IP and/or port. As TCP defines a connection by its 109 address and port 4-tuple, the packet will not appear to belong to any 110 existing connection at the receiver. 112 As QUIC endpoints identify their connections using a CID that is 113 encoded in every packet, new IP addresses and ports will not affect 114 delivery as long as no routing function in the path is dependent on 115 source IP address and port. 117 4. The Lure of the Connection ID 119 There are a few reasons that CID-aware NATs may appear attractive. 121 4.1. Resource Conservation 123 NATs sometimes hit an operational limit where they exhaust available 124 public IP addresses and ports, and must evict flows from their 125 address/port mapping. CIDs offer a way to multiplex many connections 126 over a single address and port. 128 However, QUIC endpoints may negotiate new connection IDs inside 129 cryptographically protected packets, and begin using them at will. 130 Therefore, leveraging Connection IDs will cause sudden connection 131 breakage when an incoming packet uses CIDs with no clear mapping. 133 4.2. "Helping" with routing infrastructure issues 135 One problem in QUIC deployment is router and switch server 136 infrastructures that direct traffic based on address-port 4-tuple 137 rather than connection ID. The use of source IP address means that a 138 NAT rebinding or address migration will deliver packets to the wrong 139 server. For the reasons described above, routers and switches will 140 not have access to negotiated CIDs. This is a particular problem for 141 low-state load balancers, and a QUIC extension exists [QUIC-LB] to 142 allow some server-load balancer coordination for routable CIDs. 144 A NAT at the front of this infrastructure might save the effort of 145 converting all these devices by decoding routable connection IDs and 146 rewriting the packet IP addresses to allow consistent routing by 147 legacy devices. 149 Unfortunately, the change of IP address or port is an important 150 signal to QUIC endpoints. It requires a review of path-dependent 151 variables like congestion control parameters. It can also signify 152 various attacks that mislead one endpoint about the best peer address 153 for the connection (see section 9 of [QUIC-TRANSPORT]). The QUIC 154 PATH_CHALLENGE and PATH_RESPONSE frames are intended to detect and 155 mitigate these attacks and verify connectivity to the new address. 156 Obviously, this mechanism cannot work if the NAT is bleaching peer 157 address changes. 159 5. Security Considerations 161 This document proposes no change in behavior in the internet, so 162 there are no new security implications. Note, however, that ignoring 163 the recommendations here could prevent existing security mechanisms 164 in QUIC from working properly. 166 6. IANA Considerations 168 There are no IANA requirements. 170 7. Informative References 172 [QUIC-INVARIANTS] 173 Thomson, M., "Version-Independent Properties of QUIC", 174 draft-ietf-quic-invariants-latest (work in progress). 176 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 177 Connection IDs", draft-duke-quic-load-balancers-latest 178 (work in progress). 180 [QUIC-TRANSPORT] 181 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 182 Multiplexed and Secure Transport", draft-ietf-quic- 183 transport-latest (work in progress). 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 Appendix A. Acknowledgments 192 Thanks to Dmitri Tikhonov, who first recognized that certain NAT 193 behaviors could create problems for QUIC. 195 Author's Address 197 Martin Duke 198 F5 Networks, Inc. 200 Email: martin.h.duke@gmail.com