| QUIC | D. Wing |
| Internet-Draft | J. Hildebrand |
| Intended status: Standards Track | Cisco |
| Expires: December 16, 2016 | June 14, 2016 |
Network Path Requirements for QUIC
draft-wing-quic-network-req-00
As QUIC is deployed in more networks, some existing network path infrastructure will need to be updated. This document describes a few ways QUIC might be modified to make these updates possible and palatable to the developers and operators that will need to make the changes.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Middleboxes, especially firewalls and NATs, have contributed to the inability of the Internet to evolve [I-D.hildebrand-middlebox-erosion]. There is a strong desire to avoid this ossification with QUIC. At the same time, there is a desire to treat QUIC better than normal UDP traffic; that is, to treat QUIC as well as TCP traffic. Unfortunately, the lack of header information in QUIC prevents the network path from identifying QUIC traffic and prevents the path from treating QUIC as a transport protocol on par with TCP.
Although it might be possible for path elements to heuristically perform their traditional roles, explicitly making the path a part of the QUIC architecture will generate a superior user experience. Note that the information required to be exposed is *less* than TCP exposes, in order to enable future QUIC extensibility.
This paper assumes that QUIC will use TLS 1.3 and that QUIC will not perform TLS session resumption when switching interfaces.
On many networks UDP is rate-limited or completely blocked, or a per-host or per-link basis. The limits are imposed to prevent compromised hosts from generating high volumes of UDP traffic towards a victim [I-D.byrne-opsec-udp-advisory]. Some protocols are request/response and could have higher rate limits because consent to receive is visible to the path (e.g., DNS, NTP) but others are send-only (e.g., SNMP traps, SYSLOG). The configuration expense and fear of ossification involved in deeper packet inspection is not commensurate with the benefit of higher rate limits for those request/response protocols, so many networks simply rate limit or block UDP.
Unlike UDP, TCP has a clear consent-to-receive indicator, which is why TCP is not subjected to rate-limits on those same networks. For TCP, the path can observe the consent to receive by patching acknowledgement numbers with their associated sequence numbers. WebRTC's data channel runs over UDP and has path-observable Consent Freshness [RFC7675] packets. Multipath TCP (MPTCP [RFC6824]) sends its acknowledgements on the (reverse) path of the data, which provides a clear consent-to-receive indicator to the path.
However, QUIC does not provide consent information visible to the path, and QUIC is silent if its own acknowledgements would be sent on the (reverse) path of the data. Without this visibility, QUIC traffic that a host wants to receive cannot be distinguished from attack traffic.
Once a consent to receive is established, multiple packets will usually be received in response to a single request. In TCP, both the 5-tuple and the sequence numbers on a given packet are used to provide hints to the path about this association, in an attempt make the job of off-path attackers more difficult. If QUIC does not allow the path to associate packets with a consent at greater assurance than just matching the 5-tuple (relying on the endpoint software to filter all attacks) the network cannot filter attacks such as denials of service.
Although the recommended UDP timeout for arbitrary ports is two minutes (Section 4.3 of [RFC4787]), some residential CPE devices have a 30 second timeout and a majority have a three minute timeout ([homeCPE], [tsvarea]). Longer timeouts are provided to connection-oriented TCP -- 4 minutes during connection establishment and 2 hours after connection establishment [homeCPE].
Such short timers are not a problem if the mapping is destroyed and the client sends data first, as a new mapping will be created and QUIC handles a new mapping (on a new UDP port or even on a new IP address) without an additional round-trip with its Connection Id. However, if the mapping is destroyed and the server sends data first, the server's packets will be dropped by the firewall or NAT. This problem can be mitigated by (a) the client identifying its long-lived connections to the path (e.g., using PCP or UPnP IGD) or (b) by using an easily-identified QUIC header so the pat can hopefully identify that header and apply a longer, TCP-like mapping. Neither is a perfect solution. Note that heuristic NAT / firewall behavior discovery is tempting, but imperfect [RFC5780], leaving QUIC with sending occasional keepalives as the best assurance against mapping destruction (Section 8.10 of [I-D.tsvwg-quic-protocol]).
Experience with TCP is that state needs to be retained after processing the initial session shutdown packet, to avoid half-closed sessions on the TCP endpoints. Although QUIC's termination mechanism is simpler than TCP's, it is desirable to avoid causing half-closed sessions with QUIC.
The externally-visible QUIC version number is useful for future protocol agility. However, as this is visible to the path, it is likely to ossify around that value. Thus, having something else to identify QUIC is useful, so that the version number can change while retaining the same identification of a QUIC packet.
A spurious packet may arrive when an endpoint (client or server):
In those cases, the host might have a QUIC application listening on that port, a non-QUIC application listening on that port, or no application listening on that port. These are described below.
QUIC application listening: If the application is expecting QUIC traffic and receives a spurious QUIC packet, the QUIC Connection ID will not match an existing Connection ID, and it should notify the QUIC sender. However, QUIC cannot notify the sender because it lacks the necessary cryptographic information and may lack the full Connection ID (if the spurious packet used a truncated Connection ID).
Non-QUIC application listening: A non-QUIC application will not expect to receive a QUIC packet. Upon receiving a QUIC packet, the application will attempt to parse the packet. If the application generates a response, it will not match the QUIC Connection ID of the sender, and will be dropped by the QUIC sender. It is unknown if receiving unsolicited QUIC packets causes problems for commonly- deployed UDP applications.
No application listening: If there is no process listening on that UDP port, the host will generate an ICMP or ICMP6 error (destination unreachable, port unreachable), or due to policy reasons may not react at all. Most operating systems allow non-privileged applications to receive and parse ICMP errors, allowing the QUIC stack to (partially) validate the returned ICMP error [ICMPTest], depending on the length of the returned ICMP message.
If a firewall, NAT, or load balancer discards its mapping state without notifying the endpoint, both endpoints can take a long time to discover the path state has been lost. To avoid this delay, it is desirable to send a signal that the path state will be lost or has been lost.
This document describes how QUIC needs to be distinguished from non-QUIC UDP traffic, so networks can defend themselves from attack and networks can defend hosts from attack.
While beyond the scope of this document, there are a few other QUIC security considerations:
None.
| [I-D.tsvwg-quic-protocol] | Hamilton, R., Iyengar, J., Swett, I. and A. Wilk, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Internet-Draft draft-tsvwg-quic-protocol-02, January 2016. |
| [RFC5927] | Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010. |