idnits 2.17.1 draft-wing-quic-network-req-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 (June 14, 2016) is 2844 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) ** Downref: Normative reference to an Informational draft: draft-tsvwg-quic-protocol (ref. 'I-D.tsvwg-quic-protocol') ** Downref: Normative reference to an Informational RFC: RFC 5927 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC D. Wing 3 Internet-Draft J. Hildebrand 4 Intended status: Standards Track Cisco 5 Expires: December 16, 2016 June 14, 2016 7 Network Path Requirements for QUIC 8 draft-wing-quic-network-req-00 10 Abstract 12 As QUIC is deployed in more networks, some existing network path 13 infrastructure will need to be updated. This document describes a 14 few ways QUIC might be modified to make these updates possible and 15 palatable to the developers and operators that will need to make the 16 changes. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 16, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Consent to Receive and Rate Limiting . . . . . . . . . . . . 2 54 3. Association with Existing Consent . . . . . . . . . . . . . . 3 55 4. Long-lived Connections and HTTP Server Push . . . . . . . . . 3 56 5. Identification . . . . . . . . . . . . . . . . . . . . . . . 4 57 6. Spurious Packets . . . . . . . . . . . . . . . . . . . . . . 4 58 7. Path State Loss . . . . . . . . . . . . . . . . . . . . . . . 5 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 10.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Middleboxes, especially firewalls and NATs, have contributed to the 69 inability of the Internet to evolve 70 [I-D.hildebrand-middlebox-erosion]. There is a strong desire to 71 avoid this ossification with QUIC. At the same time, there is a 72 desire to treat QUIC better than normal UDP traffic; that is, to 73 treat QUIC as well as TCP traffic. Unfortunately, the lack of header 74 information in QUIC prevents the network path from identifying QUIC 75 traffic and prevents the path from treating QUIC as a transport 76 protocol on par with TCP. 78 Although it might be possible for path elements to heuristically 79 perform their traditional roles, explicitly making the path a part of 80 the QUIC architecture will generate a superior user experience. Note 81 that the information required to be exposed is *less* than TCP 82 exposes, in order to enable future QUIC extensibility. 84 This paper assumes that QUIC will use TLS 1.3 and that QUIC will not 85 perform TLS session resumption when switching interfaces. 87 2. Consent to Receive and Rate Limiting 89 On many networks UDP is rate-limited or completely blocked, or a per- 90 host or per-link basis. The limits are imposed to prevent 91 compromised hosts from generating high volumes of UDP traffic towards 92 a victim [I-D.byrne-opsec-udp-advisory]. Some protocols are request/ 93 response and could have higher rate limits because consent to receive 94 is visible to the path (e.g., DNS, NTP) but others are send-only 95 (e.g., SNMP traps, SYSLOG). The configuration expense and fear of 96 ossification involved in deeper packet inspection is not commensurate 97 with the benefit of higher rate limits for those request/response 98 protocols, so many networks simply rate limit or block UDP. 100 Unlike UDP, TCP has a clear consent-to-receive indicator, which is 101 why TCP is not subjected to rate-limits on those same networks. For 102 TCP, the path can observe the consent to receive by patching 103 acknowledgement numbers with their associated sequence numbers. 104 WebRTC's data channel runs over UDP and has path-observable Consent 105 Freshness [RFC7675] packets. Multipath TCP (MPTCP [RFC6824]) sends 106 its acknowledgements on the (reverse) path of the data, which 107 provides a clear consent-to-receive indicator to the path. 109 However, QUIC does not provide consent information visible to the 110 path, and QUIC is silent if its own acknowledgements would be sent on 111 the (reverse) path of the data. Without this visibility, QUIC 112 traffic that a host wants to receive cannot be distinguished from 113 attack traffic. 115 Recommendation: Provide path-visible consent request and consent 116 acknowledgement for a given 5-tuple. 118 3. Association with Existing Consent 120 Once a consent to receive is established, multiple packets will 121 usually be received in response to a single request. In TCP, both 122 the 5-tuple and the sequence numbers on a given packet are used to 123 provide hints to the path about this association, in an attempt make 124 the job of off-path attackers more difficult. If QUIC does not allow 125 the path to associate packets with a consent at greater assurance 126 than just matching the 5-tuple (relying on the endpoint software to 127 filter all attacks) the network cannot filter attacks such as denials 128 of service. 130 Recommendation: QUIC should allow path elements to associate every 131 packet after the consent to receive with that consent, with more 132 assurance than the 5-tuple. 134 4. Long-lived Connections and HTTP Server Push 136 Although the recommended UDP timeout for arbitrary ports is two 137 minutes (Section 4.3 of [RFC4787]), some residential CPE devices have 138 a 30 second timeout and a majority have a three minute timeout 139 ([homeCPE], [tsvarea]). Longer timeouts are provided to connection- 140 oriented TCP -- 4 minutes during connection establishment and 2 hours 141 after connection establishment [homeCPE]. 143 Such short timers are not a problem if the mapping is destroyed and 144 the client sends data first, as a new mapping will be created and 145 QUIC handles a new mapping (on a new UDP port or even on a new IP 146 address) without an additional round-trip with its Connection Id. 147 However, if the mapping is destroyed and the server sends data first, 148 the server's packets will be dropped by the firewall or NAT. This 149 problem can be mitigated by (a) the client identifying its long-lived 150 connections to the path (e.g., using PCP or UPnP IGD) or (b) by using 151 an easily-identified QUIC header so the pat can hopefully identify 152 that header and apply a longer, TCP-like mapping. Neither is a 153 perfect solution. Note that heuristic NAT / firewall behavior 154 discovery is tempting, but imperfect [RFC5780], leaving QUIC with 155 sending occasional keepalives as the best assurance against mapping 156 destruction (Section 8.10 of [I-D.tsvwg-quic-protocol]). 158 Experience with TCP is that state needs to be retained after 159 processing the initial session shutdown packet, to avoid half-closed 160 sessions on the TCP endpoints. Although QUIC's termination mechanism 161 is simpler than TCP's, it is desirable to avoid causing half-closed 162 sessions with QUIC. 164 Recommendation: QUIC's public reset facility needs to describe 165 timing recommendations for path state expiry. 167 5. Identification 169 The externally-visible QUIC version number is useful for future 170 protocol agility. However, as this is visible to the path, it is 171 likely to ossify around that value. Thus, having something else to 172 identify QUIC is useful, so that the version number can change while 173 retaining the same identification of a QUIC packet. 175 Recommendation: Provide path-visible mechanism to identify a QUIC 176 packet. 178 Recommendation: Have a path-invisible version number. 180 6. Spurious Packets 182 A spurious packet may arrive when an endpoint (client or server): 184 o loses state due to a reboot 186 o experiences a QUIC application crash 188 o acquires another host's prior IP address 190 o receives a malicious or accidental QUIC packet. 192 In those cases, the host might have a QUIC application listening on 193 that port, a non-QUIC application listening on that port, or no 194 application listening on that port. These are described below. 196 QUIC application listening: If the application is expecting QUIC 197 traffic and receives a spurious QUIC packet, the QUIC Connection ID 198 will not match an existing Connection ID, and it should notify the 199 QUIC sender. However, QUIC cannot notify the sender because it lacks 200 the necessary cryptographic information and may lack the full 201 Connection ID (if the spurious packet used a truncated Connection 202 ID). 204 Recommendation: QUIC should have a mechanism for a QUIC 205 application to send a hint to the remote system that its packet 206 was not processed. 208 Non-QUIC application listening: A non-QUIC application will not 209 expect to receive a QUIC packet. Upon receiving a QUIC packet, the 210 application will attempt to parse the packet. If the application 211 generates a response, it will not match the QUIC Connection ID of the 212 sender, and will be dropped by the QUIC sender. It is unknown if 213 receiving unsolicited QUIC packets causes problems for commonly- 214 deployed UDP applications. 216 Recommendation: Evaluate if receiving unsolicited QUIC packets 217 causes new problems for existing UDP clients or UDP servers. 219 No application listening: If there is no process listening on that 220 UDP port, the host will generate an ICMP or ICMP6 error (destination 221 unreachable, port unreachable), or due to policy reasons may not 222 react at all. Most operating systems allow non-privileged 223 applications to receive and parse ICMP errors, allowing the QUIC 224 stack to (partially) validate the returned ICMP error [ICMPTest], 225 depending on the length of the returned ICMP message. 227 Recommendation: QUIC applications should honor an ICMP hard error 228 matching the 5-tuple of the remote peer and its recently-sent 229 Connection ID, in a fashion similar to TCP's handling of ICMP hard 230 errors (Section 4 of [RFC5927]). 232 7. Path State Loss 234 If a firewall, NAT, or load balancer discards its mapping state 235 without notifying the endpoint, both endpoints can take a long time 236 to discover the path state has been lost. To avoid this delay, it is 237 desirable to send a signal that the path state will be lost or has 238 been lost. 240 Recommendation: QUIC should provide a way for on-path middleboxes 241 to signal that their mapping will be lost or has been lost. 243 8. Security Considerations 245 This document describes how QUIC needs to be distinguished from non- 246 QUIC UDP traffic, so networks can defend themselves from attack and 247 networks can defend hosts from attack. 249 While beyond the scope of this document, there are a few other QUIC 250 security considerations: 252 o Examine impact of CORS [CORS] to generate new UDP attacks against 253 both clients and servers. 255 o Due to TCP attacks, TCP initial sequence numbers are now 256 randomized. QUIC should be analyzed if it would similarly benefit 257 from randomized initial sequence numbers. 259 9. IANA Considerations 261 None. 263 10. References 265 10.1. Normative References 267 [I-D.tsvwg-quic-protocol] 268 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 269 A UDP-Based Secure and Reliable Transport for HTTP/2", 270 draft-tsvwg-quic-protocol-02 (work in progress), January 271 2016. 273 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 274 10.17487/RFC5927, July 2010, 275 . 277 10.2. Informative References 279 [CORS] W3C, "Cross-Origin Resource Sharing", January 2014, 280 . 282 [homeCPE] various, "An Experimental Study of Home Gateway 283 Characteristics", November 2010, 284 . 286 [I-D.byrne-opsec-udp-advisory] 287 Byrne, C. and J. Kleberg, "Advisory Guidelines for UDP 288 Deployment", draft-byrne-opsec-udp-advisory-00 (work in 289 progress), July 2015. 291 [I-D.hildebrand-middlebox-erosion] 292 Hildebrand, J. and P. McManus, "Erosion of the moral 293 authority of transparent middleboxes", draft-hildebrand- 294 middlebox-erosion-01 (work in progress), November 2014. 296 [ICMPTest] 297 Pal-Erik Martinsen, "ICMPTest", March 2015, 298 . 300 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 301 Translation (NAT) Behavioral Requirements for Unicast 302 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 303 2007, . 305 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 306 Using Session Traversal Utilities for NAT (STUN)", RFC 307 5780, DOI 10.17487/RFC5780, May 2010, 308 . 310 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 311 "TCP Extensions for Multipath Operation with Multiple 312 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 313 . 315 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 316 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 317 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 318 October 2015, . 320 [tsvarea] Google, "Quick UDP Internet Connections: Multiplexed 321 Stream Transport over UDP", November 2013, 322 . 325 Authors' Addresses 327 Dan Wing 328 Cisco Systems, Inc. 329 170 West Tasman Drive 330 San Jose, California 95134 331 USA 333 Email: dwing@cisco.com 334 Joe Hildebrand 335 Cisco Systems, Inc. 337 Email: jhildebr@cisco.com