Network Working Group T. Pauly Internet-Draft C. Wood Intended status: Standards Track E. Kinnear Expires: September 12, 2019 Apple Inc. March 11, 2019 QUIC Address Extension draft-pauly-quic-address-extension-00 Abstract This document defines an extension to the QUIC transport protocol that adds support for requesting and receiving the public network address of an endpoint from its peer. Status of This Memo 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 https://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 September 12, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. Pauly, et al. Expires September 12, 2019 [Page 1] Internet-Draft QUIC Address Extension March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Connection Lifetime Optimizations . . . . . . . . . . . . 3 2.2. Privacy Stance Enhancements . . . . . . . . . . . . . . . 3 3. Transport Parameter . . . . . . . . . . . . . . . . . . . . . 3 4. Address Request and Response Frame Types . . . . . . . . . . 3 5. Address Frame Usage . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a secure, multiplexed connection for transmitting reliable streams of application data. Connections are associated with unique Connection Identifiers (CIDs) that facilitate migration for clients that are mobile or have multiple network associations. CIDs also help connections survive Network Address Translator (NAT) port re- bindings, provided that the client behind the NAT sends a new packet with a known CID before the server drops the connection. There is currently no explicit signal an endpoint can use to detect the presence of NATs. This problematic as it can encourage endpoints to aggressively send packets to keep NAT bindings alive. This document describes an extension to QUIC that enables peers to request their public address and port from peers. This can be used to detect NATs and to help guide CID rotation policies. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Motivation There are several cases in which an endpoint might wish to know its public network address. Pauly, et al. Expires September 12, 2019 [Page 2] Internet-Draft QUIC Address Extension March 2019 2.1. Connection Lifetime Optimizations Knowing whether or not an endpoint is behind a NAT can help guide connection keepalive mechanisms. For example, peers that are not behind NATs might not need to send frequent keepalive packets (such as packets containing PING frames) to prevent NAT bindings expiration. This is particularly useful for UDP-based protocols such as QUIC, since UDP often has low idle timeouts configured on NATs or other middleboxes. Note that there may still be stateful firewalls present in the network that have short timeouts, so NAT detection cannot be used as the only heuristic for a QUIC client's keepalive algorithm. 2.2. Privacy Stance Enhancements A QUIC endpoint might choose to rotate CIDs and UDP ports even over the same network interface to decrease the linkability of its traffic. However, the effectiveness of this approach can be limited if the endpoint is communicating using a fixed public IP address. Detecting a NAT increases the likelihood that rotating CIDs and UDP ports will be an effective strategy to obscure client traffic patterns. 3. Transport Parameter Support for sending and receiving PUBLIC_ADDRESS_REQUEST and PUBLIC_ADDRESS_RESPONSE frames is advertised by means of a QUIC Transport Parameter (name=supports_address_request, value=0x000f). An endpoint that includes this parameter supports both requests and responses. Endpoints MUST NOT send requests or responses unless both parties signal support for these frames. An endpoint that receives a PUBLIC_ADDRESS_REQUEST or PUBLIC_ADDRESS_RESPONSE frame when it without sending the supports_address_request parameter MUST terminate the connection with error PROTOCOL_VIOLATION. 4. Address Request and Response Frame Types A PUBLIC_ADDRESS_REQUEST frame has the following structure. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request ID is a randomly generated 32-bit identifier for the request. Pauly, et al. Expires September 12, 2019 [Page 3] Internet-Draft QUIC Address Extension March 2019 A PUBLIC_ADDRESS_RESPONSE frame has the following structure. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Address Value (*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of a PUBLIC_ADDRESS_RESPONSE frame are as follows: Request ID: A 32-bit value indicating the ID of the corresponding request. Address Type: A single octet equal to 0x00 or 0x01, indicating that the body carries an IPv4 or IPv6 address, respectively. Address Value: A 32- or 128-bit value encoding an IPv4 or IPv6 address, respectively, depending on the value of Address Type. Port: A 16-bit integer representing the peer's corresponding port. 5. Address Frame Usage An endpoint MAY send a request or response frame at any point after connection establishment. Endpoints SHOULD send address request frames following connection migration to learn if there is a change in its public address on the new path. 6. Security Considerations PUBLIC_ADDRESS_REQUEST and PUBLIC_ADDRESS_RESPONSE frames are sent in encrypted QUIC packets and are therefore not visible to passive observers. Moreover, since endpoints can only request their public address, peers cannot accidentally transmit their (possibly private) address to a peer. Endpoints that receive their perceived address from their peer cannot assume that the address is correct or trusted. The peer is able to send a fabricated address, so the result MUST NOT be used for any security-related decisions. Pauly, et al. Expires September 12, 2019 [Page 4] Internet-Draft QUIC Address Extension March 2019 7. IANA Considerations This document registers a new value in the QUIC Transport Parameter Registry: Value: 0x000f (if this document is approved) Parameter Name: supports_address_request Specification: Indicates that the connection should enable support for PUBLIC_ADDRESS_REQUEST and PUBLIC_ADDRESS_RESPONSE. An endpoint that advertises this transport parameter can support both sending and receiving these frames. This document also registers two new values in the QUIC Frame Type Registry: Value: 0x1e (if this document is approved) Frame Name: PUBLIC_ADDRESS_REQUEST Specification: Requests that the peer sends back the public address of sender Value: 0x1f (if this document is approved) Frame Name: PUBLIC_ADDRESS_RESPONSE Specification: A response to a PUBLIC_ADDRESS_REQUEST containing the requester's public address 8. Normative References [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-18 (work in progress), January 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Pauly, et al. Expires September 12, 2019 [Page 5] Internet-Draft QUIC Address Extension March 2019 Authors' Addresses Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: tpauly@apple.com Christopher A. Wood Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: cawood@apple.com Eric Kinnear Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: ekinnear@apple.com Pauly, et al. Expires September 12, 2019 [Page 6]