idnits 2.17.1 draft-duke-quic-natsupp-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 : ---------------------------------------------------------------------------- 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 (March 9, 2020) is 1509 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 March 9, 2020 5 Expires: September 10, 2020 7 Network Address Translation Support for QUIC 8 draft-duke-quic-natsupp-02 10 Abstract 12 Network Address Translators (NATs) are widely deployed to share 13 scarce public IPv4 addresses among multiple end hosts. They 14 overwrite IP addresses and ports in IP packets to do so. QUIC is a 15 protocol on top of UDP that provides transport-like services. QUIC 16 is better-behaved in the presence of NATs than older protocols, and 17 existing UDP NATs should operate without incident if unmodified. 18 QUIC offers additional features that may tempt NAT implementers as 19 potential optimizations. However, in practice, leveraging these 20 features will lead to new connection failure modes and security 21 vulnerabilities. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 10, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. QUIC and NAT Rebinding . . . . . . . . . . . . . . . . . . . 3 60 4. The Lure of the Connection ID . . . . . . . . . . . . . . . . 3 61 4.1. Resource Conservation . . . . . . . . . . . . . . . . . . 3 62 4.2. "Helping" with routing infrastructure issues . . . . . . 4 63 5. Filtering behavior . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 8. Informative References . . . . . . . . . . . . . . . . . . . 5 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 68 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 6 69 B.1. since draft-duke-quic-natsupp-01 . . . . . . . . . . . . 6 70 B.2. since draft-duke-quic-natsupp-00 . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Network Address Translators (NATs) are a widely deployed means of 76 multiplexing multiple private IP addresses over scarce IPv4 public 77 address space by replacing those addresses and using ports to 78 distinguish those connections. The new address can also guarantee 79 that packets move through a proxy throughout the life of a 80 connection, so that the connection can continue with the required 81 state at that proxy. 83 This document uses the colloquial term NAT to mean NAPT (section 2.2 84 of [RFC3022]), which overloads several IP addresses to one IP address 85 or to an IP address pool, as commonly deployed in carrier-grade NATs 86 or residential NATs. 88 QUIC [QUIC-TRANSPORT] is a protocol, operating over UDP, that 89 provides many transport-like services to the application layer. 90 Among these services is the mapping of multiple endpoint IP addresses 91 to a single connection through use of a Connection ID (CID). 92 Connection IDs are opaque byte fields that are expressed consistently 93 across all QUIC versions [QUIC-INVARIANTS]. This feature may appear 94 to present opportunities to optimize NAT port usage and simplify the 95 work of the QUIC server. In fact, NAT behavior that relies on CID 96 may instead cause connection failure when endpoints change Connection 97 ID, and disable important protocol security features. 99 The remainder of this document explains how QUIC supports NATs better 100 than other connection-oriented protocols, why NAT use of Connection 101 ID might appear attractive, and how NAT use of CID can create serious 102 problems for the endpoints. The conclusion of this document is that 103 NATs should retain their existing 4-tuple-based operation and refrain 104 from parsing or otherwise using QUIC connection IDs. 106 [RFC4787] contains some guidance on building NATs to interact 107 constructively with a wide range of applications. This document 108 extends the discussion to QUIC. 110 2. Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. QUIC and NAT Rebinding 118 An explicit goal of QUIC is to be robust to NAT rebinding. When a 119 connection is idle for a long time, the NAT may guess it has 120 terminated and assign the client port to a new connection. As TCP 121 defines a connection by its address and port 4-tuple, a TCP packet 122 will not appear to belong to any existing connection at the receiver. 124 QUIC endpoints identify their connections using a CID that is encoded 125 in every packet. If the client attempts to resume communication, the 126 packet will be assigned a new source IP and/or port. Incoming 127 packets from the server will be misrouted and dropped until the 128 client sends a packet from its new address. 130 Therefore, QUIC connections can survive NAT rebindings as long as no 131 routing function in the path is dependent on client IP address and 132 port to deliver packets between server and NAT. 134 4. The Lure of the Connection ID 136 There are a few reasons that CID-aware NATs could seemingly appear 137 attractive. 139 4.1. Resource Conservation 141 NATs sometimes hit an operational limit where they exhaust available 142 public IP addresses and ports, and must evict flows from their 143 address/port mapping. CIDs offer a way to multiplex many connections 144 over a single address and port. 146 However, QUIC endpoints may negotiate new connection IDs inside 147 cryptographically protected packets, and begin using them at will. 148 Imagine two clients behind a NAT that are sharing the same public IP 149 address and port. The NAT is differentiating them using the incoming 150 Connection ID. If one client secretly changes its connection ID, 151 there will be no mapping for the NAT, and the connection will 152 suddenly break. 154 While mid-connection failure in some cases may seem superior to 155 rejecting QUIC outright, HTTP/3 over QUIC falls back to TCP. This is 156 preferable to a connection suddenly black holing and timing out. 157 Furthermore, wide deployment of NATs with this behavior would make it 158 risky to change Connection IDs in the internet, which would thwart 159 various important protocol properties. 161 It is possible, in principle, to encode the client's identity in a 162 connection ID using [QUIC-LB] and explicit coordination with the NAT. 163 However, QUIC-LB makes assumptions about endpoint mobility and common 164 configuration in server infrastructure that are almost never valid in 165 client/NAT architectures. Deploying such a system would include the 166 administrative overhead while not solving the problem described in 167 this section if the client changes networks. 169 Note that using connection IDs in this manner would anyway violate 170 the best common practice to avoid "port overloading" as described in 171 [RFC4787]. 173 4.2. "Helping" with routing infrastructure issues 175 One problem in QUIC deployment is router and switch server 176 infrastructures that direct traffic based on address-port 4-tuple 177 rather than connection ID. The use of source IP address means that a 178 NAT rebinding or address migration will deliver packets to the wrong 179 server. For the reasons described above, routers and switches will 180 not have access to negotiated CIDs. This is a particular problem for 181 low-state load balancers, and a QUIC extension exists [QUIC-LB] to 182 allow some server-load balancer coordination for routable CIDs. 184 A NAT at the front of this infrastructure might save the effort of 185 converting all these devices by decoding routable connection IDs and 186 rewriting the packet IP addresses to allow consistent routing by 187 legacy devices. 189 Unfortunately, the change of IP address or port is an important 190 signal to QUIC endpoints. It requires a review of path-dependent 191 variables like congestion control parameters. It can also signify 192 various attacks that mislead one endpoint about the best peer address 193 for the connection (see section 9 of [QUIC-TRANSPORT]). The QUIC 194 PATH_CHALLENGE and PATH_RESPONSE frames are intended to detect and 195 mitigate these attacks and verify connectivity to the new address. 196 This mechanism cannot work if the NAT is bleaching peer address 197 changes. 199 For example, an attacker might copy a legitimate QUIC packet and 200 change the source address to match its own. In the absence of a 201 bleaching NAT, the receiving endpoint would interpret this as a 202 potential NAT rebinding and use a PATH_CHALLENGE frame to prove that 203 the peer endpoint is not truly at the new address, thus thwarting the 204 attack. A bleaching NAT has no means of sending an encrypted 205 PATH_CHALLENGE frame, so it might start redirecting all QUIC traffic 206 to the attacker address and thus allow an observer to break the 207 connection. 209 5. Filtering behavior 211 [RFC4787] describes possible packet filtering behaviors that relate 212 to NATs. Though thes guidance there holds, a particularly unwise 213 behavior is to admit a handful of UDP packets and then make a 214 decision as to whether or not to filter it. QUIC applications are 215 encouraaged to fail over to TCP if early packets do not arrive at 216 their destination. Admitting a few packets allows the QUIC endpoint 217 to determine that the path accepts QUIC. Sudden drops afterwards 218 will result in slow and costly timeouts before abandoning the 219 connection. 221 6. Security Considerations 223 This document proposes no change in behavior in the internet, so 224 there are no new security implications. However, ignoring the 225 recommendations here could prevent existing security mechanisms in 226 QUIC from working properly. 228 7. IANA Considerations 230 There are no IANA requirements. 232 8. Informative References 234 [QUIC-INVARIANTS] 235 Thomson, M., "Version-Independent Properties of QUIC", 236 draft-ietf-quic-invariants-latest (work in progress). 238 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 239 Connection IDs", draft-duke-quic-load-balancers-latest 240 (work in progress). 242 [QUIC-TRANSPORT] 243 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 244 Multiplexed and Secure Transport", draft-ietf-quic- 245 transport-latest (work in progress). 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, 249 DOI 10.17487/RFC2119, March 1997, 250 . 252 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 253 Address Translator (Traditional NAT)", RFC 3022, 254 DOI 10.17487/RFC3022, January 2001, 255 . 257 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 258 Translation (NAT) Behavioral Requirements for Unicast 259 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 260 2007, . 262 Appendix A. Acknowledgments 264 Thanks to Dmitri Tikhonov, who first recognized that certain NAT 265 behaviors could create problems for QUIC. 267 Appendix B. Change Log 269 *RFC Editor's Note:* Please remove this section prior to$ 270 publication of a final version of this document.$ 272 B.1. since draft-duke-quic-natsupp-01 274 o Added brief discussion of impact of filtering. 276 o Added references to RFC 4787. 278 o Corrected normative reference to be informative. 280 B.2. since draft-duke-quic-natsupp-00 282 o Tightened NAT terminology 284 o Added additional clarfying examples 285 o Added warning against using QUIC-LB for NATs that front clients. 287 Author's Address 289 Martin Duke 290 F5 Networks, Inc. 292 Email: martin.h.duke@gmail.com