httpbis B. Schwartz Internet-Draft Google Intended status: Standards Track June 25, 2018 Expires: December 27, 2018 Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM) draft-schwartz-httpbis-helium-00 Abstract HELIUM is a protocol that can be used to implement a UDP proxy, a VPN, or a hybrid of these. It is intended to run over a reliable, secure substrate transport. It can serve a variety of use cases, but its initial purpose is to enable HTTP proxies to forward non-TCP flows. 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 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 27, 2018. Copyright Notice Copyright (c) 2018 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. Schwartz Expires December 27, 2018 [Page 1] Internet-Draft HELIUM June 2018 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. HELIUM Inner Protocol (HIP) . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Abstract Structure . . . . . . . . . . . . . . . . . . . 4 2.3.1. Error codes . . . . . . . . . . . . . . . . . . . . . 6 2.4. CBOR-based Encoding (HIP-CBOR) . . . . . . . . . . . . . 7 2.5. Addressing . . . . . . . . . . . . . . . . . . . . . . . 8 2.5.1. IP Header . . . . . . . . . . . . . . . . . . . . . . 9 2.5.2. UDP Header . . . . . . . . . . . . . . . . . . . . . 9 2.6. Example Configurations . . . . . . . . . . . . . . . . . 9 2.6.1. Single IP tunnel . . . . . . . . . . . . . . . . . . 9 2.6.2. Multiple source IPs in one context . . . . . . . . . 9 2.6.3. Domain-based proxy . . . . . . . . . . . . . . . . . 10 2.6.4. UDP proxy with PMTUD and traceroute . . . . . . . . . 10 2.6.5. Advanced DNS queries . . . . . . . . . . . . . . . . 10 2.6.6. UDP Server Application . . . . . . . . . . . . . . . 11 2.6.7. High-Performance Delay-based Congestion Control . . . 11 2.7. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11 3. WebSocket as a HELIUM Substrate (HELIUM-WebSocket) . . . . . 12 3.1. Direct Configuration . . . . . . . . . . . . . . . . . . 12 3.2. Implicit Configuration from an HTTP proxy . . . . . . . . 12 3.3. Optimizations . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Overview This proposal describes a network tunnel that is intended as a natural extension or complement to existing HTTP proxies. It has two components o A flexible packet-oriented tunneling protocol that can act as either a VPN or a UDP proxy (Section 2) o A substrate for this protocol that allows it to run as part of an HTTPS server (Section 3) This design combines the benefits of several existing protocols, such as [OpenConnect] and [TURN]. Like OpenConnect, this protocol gains the privacy, authentication, and management benefits of HTTPS. Like Schwartz Expires December 27, 2018 [Page 2] Internet-Draft HELIUM June 2018 TURN, this protocol can be used as a UDP proxy for realtime and P2P applications. 2. HELIUM Inner Protocol (HIP) The protocol is designed to span two different use cases o a UDP tunnel (proxy) o an IP tunnel (VPN) These two use cases are normally handled by entirely separate protocols, like [TURN] and [L2TP]. However, UDP is fundamentally very similar to IP (differing mostly by the addition of a 2-byte "port number"), so it seems plausible that a single protocol may serve both purposes. Additionally, a UDP proxy can be enriched by partial support for ICMP (enabling [PMTUD], traceroute, etc.), so there may be configurations that benefit from blending these uses. The protocol is intended to run between a client and a proxy, on a substrate that provides confidentiality, integrity, flow control, congestion control, and reliability (at least optionally). It should take advantage of substrates that support out-of-order delivery, but still function acceptably on strictly ordered transports. 2.1. Terminology o Proxy: the server implementing this protocol, acting as a UDP proxy or IP tunnel endpoint o Client: the endpoint that is implementing this protocol on the client side o Destination: a service that the client is trying to reach through the proxy o Context: the identity of the transport session used to transfer messages between a client and the proxy (e.g. one WebSocket) o Substrate: the transport protocol used to transfer these messages (e.g. WebSocket) o Flow: a sequence of related packets between the client and a single destination 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 BCP Schwartz Expires December 27, 2018 [Page 3] Internet-Draft HELIUM June 2018 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Requirements o It shall be possible for a proxy to operate in an environment without elevated privileges. * Such a proxy might only support operating as a UDP tunnel. o It shall be possible for a proxy with elevated privileges to operate without any parsing of IP payloads. * Such a proxy would operate as an IP tunnel. o A client can direct the proxy to send multiple packets from the same IP (and UDP port). o A client can tell what IP address and port the proxy is using to communicate on its behalf. * A client can bind an address (or address:port) and learn it before emitting any packets. o A client can tell if the proxy doesn't support a feature it's trying to use. o New connections can be established without waiting for a roundtrip between client and proxy. o The protocol enables good performance when tunneling streams that use delay-based congestion control (e.g. TCP Vegas, [BBR], [RMCAT-GCC]). o The client has an option to let the proxy resolve DNS names itself, with a latency benefit. o The proxy can be implemented with tightly bounded memory usage. 2.3. Abstract Structure Each HIP message consists of a type, optional metadata, and at most one packet (or prefix of a packet). The packet (or prefix) is a standard [IPv4] or [IPv6] packet, starting with the IP header. There are three message types defined: "outbound", "inbound", and "meta". Schwartz Expires December 27, 2018 [Page 4] Internet-Draft HELIUM June 2018 A message from the client to the proxy is always of type "outbound". It always includes a complete packet for the proxy to send to the destination (potentially after header modifications). The possible metadata fields that this message may contain are as follows: o id (integer): An ID number identifying this message. If present, the client is implicitly requesting a "meta" message from the proxy. A client MUST NOT reuse an ID until a "meta" reply message is received. o domain (UTF-8 string): A DNS name to override the destination IP. The proxy will perform an A or AAAA lookup, depending on the IP version of the included packet. The proxy will buffer the packet until name lookup completes. The proxy SHOULD avoid creating duplicate outstanding DNS queries, and SHOULD cache the result to provide a consistent mapping. o dns (integer): The presence of this option indicates that the client wishes to direct the packet to one of the proxy's preferred DNS servers. Its value is an index into the proxy's list of preferred recursive resolvers for this IP version, modulo the length of the list. This option overrides the destination IP, and MUST NOT appear in a message with the "domain" option. A message from the proxy to the client may be of type "inbound" or "meta". An "inbound" message contains a packet that the proxy received from the destination, unmodified, including the IP header. It contains one metadata field: o timestamp (integer): A timestamp in microseconds modulo 2^32, indicating when the proxy received this packet from the destination. The absolute base time is unspecified, as this is only used for computing time differences. If the proxy reassembled the packet from fragments, this timestamp is the time when reassembly completed. A "meta" message is only sent by the proxy to a client after it receives an "outbound" message with an ID from the client. If the proxy modified the outbound packet in any way, the "meta" message MUST contain a prefix of the outbound packet as sent, including any parts that were modified. Changes might include the source IP, destination IP, TTL, DSCP priority, UDP source port, etc. If there was an error, the proxy MAY include a modified prefix that would not have encountered the error (e.g. by changing the protocol ID from an unsupported protocol (e.g. TCP) to a supported protocol (e.g. UDP)). The message contains the following metadata: Schwartz Expires December 27, 2018 [Page 5] Internet-Draft HELIUM June 2018 o id (integer): This is the ID number of the "outbound" message to which this is a reply. o error (Array of integer): If present, these error codes indicate why the proxy could not send the packet contained in the "outbound" message to the destination. o timestamp (integer): The time when the outbound packet was sent from the proxy to the destination, in the same format used for "inbound" messages. If there was an error, this is the time that the error was detected. If the proxy receives a message from the client of an unrecognized type, and the message has an "id" field, the server SHOULD reply with a "meta" message matching that ID and indicating an "Unsupported message type" error. If the proxy receives a message from the client with unknown metadata fields, it SHOULD ignore the unknown fields and process the message as normal. If the proxy receives an "outbound" message with an all-zero destination address and no address-overriding metadata, the proxy SHOULD rewrite the packet for transmission and establish any required address or port mappings, but not attempt to send the packet. If an ID number is present, the proxy SHOULD reply with a "meta" message indicating success unless a non-address-related error occurred. All messages can also include padding. Padding can be represented as a metadata field named "padding" whose value is discarded by the recipient. All integer values defined in this section are non-negative. All metadata keys defined here MUST NOT appear more than once. Recipients SHOULD treat negative numbers and repeated keys as metadata parsing errors. 2.3.1. Error codes These are the numeric error codes that the proxy may include in a "meta" message Schwartz Expires December 27, 2018 [Page 6] Internet-Draft HELIUM June 2018 +------+------------------------------------+ | Code | Error | +------+------------------------------------+ | 1 | Unsupported message type | | | | | 2 | Metadata parsing error | | | | | 3 | Unsupported IP version | | | | | 4 | Invalid IP header | | | | | 5 | Can't send fragment | | | | | 6 | Packet too large | | | | | 7 | Unsupported IP option | | | | | 8 | Unsupported protocol | | | | | 9 | No route to host | | | | | 10 | Network unreachable | | | | | 11 | Destination IP not allowed | | | | | 12 | Destination DNS name not allowed | | | | | 13 | DNS name has no address (NXDOMAIN) | | | | | 14 | DNS name resolution failed | | | | | 15 | General server failure | | | | | 16 | Usage limit exceeded | +------+------------------------------------+ Additional error codes may be defined in the future. 2.4. CBOR-based Encoding (HIP-CBOR) To encode abstract HIP messages into concrete form, we use a [CBOR]- based encoding. Other equivalent but incompatible encodings might be defined in the future. In this encoding, each message is formed by concatenating a one-byte type field, the metadata encoded in CBOR, and the packet or packet- prefix. Schwartz Expires December 27, 2018 [Page 7] Internet-Draft HELIUM June 2018 +------+----------+ | Byte | Type | +------+----------+ | 0x01 | outbound | | | | | 0x02 | inbound | | | | | 0x03 | meta | +------+----------+ Metadata is encoded in CBOR as a Map. For compactness, keys are integer-valued, with the following significance: +-----+-----------+ | Key | Field | +-----+-----------+ | 0 | padding | | | | | 1 | id | | | | | 2 | domain | | | | | 3 | dns | | | | | 4 | timestamp | | | | | 5 | error | +-----+-----------+ Additional message types and metadata fields may be defined in the future. When sending a message, endpoints SHOULD use the most compact available encoding of each metadata value. When receiving a message, recipients are NOT REQUIRED to accept extremely inefficient or obscure encodings that are allowed by CBOR (e.g. Bignums, Decimal Fractions). 2.5. Addressing There are two major modes of operation that a proxy might use: IP tunnel and UDP tunnel. Both operation modes require the proxy to inspect and possibly modify the IP header of the packet contained in an "outbound" message before sending the packet to the destination. The UDP tunnel mode in addition requires the proxy to inspect and possibly modify the UDP header in the IP payload. Schwartz Expires December 27, 2018 [Page 8] Internet-Draft HELIUM June 2018 2.5.1. IP Header Initially, the client does not know the IP address that the proxy will use as the source IP for packets it sends to the destination. The protocol does not require the client to correctly populate the source IP in its outbound packets to the proxy. Rather, the client chooses any IP address, and the proxy will rewrite this address into one of its own outbound IP addresses. Within a single context, the proxy MUST maintain a stable address mapping with a reasonable lifetime, similar to Network Address Translation [NAT]. In IP tunnel mode, the proxy MUST NOT map multiple contexts to the same outbound IP address at the same time, as it would then be impossible to determine unambiguously where to direct packets received from the destination. These outbound IP addresses MAY be publicly routable, or they MAY be in a reserved range (e.g. [RFC1918], [RFC4193]), using [NAT] to reach the public internet. 2.5.2. UDP Header In UDP tunnel mode, the proxy MAY also rewrite the UDP source port of a packet before sending it to the destination. The client has no way to initially know what source port the proxy will use in this mode, so the protocol does not require the client to correctly populate the source port in its outbound packets to the proxy. In UDP tunnel mode, the proxy MAY map the same outbound IP address to multiple contexts with overlapping lifetimes, but the proxy SHOULD ensure that each UDP port is only mapped to a single context (i.e. an endpoint- independent mapping policy as described in [RFC4787]). A proxy MAY violate this condition only if it serves a limited use case in which the correct context for an inbound packet will never be ambiguous. 2.6. Example Configurations 2.6.1. Single IP tunnel The client sends outbound IP packets to the server with empty metadata, and with various destinations and protocols (e.g. ICMP, TCP, UDP). The proxy rewrites the source address of all packets to match the reserved IP address for this client, and forwards all incoming packets to the client. 2.6.2. Multiple source IPs in one context A client sends IP packets to the proxy with various source addresses, and includes an ID number in each one. For each ID number, the server's "meta" reply reveals the proxy source IP that was mapped to the client's chosen source IP. Once the client has learned the Schwartz Expires December 27, 2018 [Page 9] Internet-Draft HELIUM June 2018 mapping, the client stops including an ID number in subsequent messages. 2.6.3. Domain-based proxy The client sends its initial flight of packets with an ID number and a domain in the metadata, and all zeroes in the destination IP address. The "meta" replies indicate the rewritten destination IP address, which is the resolved location of the destination. The client then emits subsequent packets with this destination IP address, and omits all metadata. If the proxy does not know the exact IP header used (e.g. because it is using the network through a UDP socket API), it will synthesize an approximate IP header for the "meta" replies. 2.6.4. UDP proxy with PMTUD and traceroute The client sends "outbound" UDP packets with the ID set and varying size or TTL. The proxy MUST NOT fragment unless the packet is IPv4 and the DONT-FRAGMENT bit is unset. If the proxy could not send the packet because it was too large, it MUST reply with an error (Packet too large) and SHOULD include a rewritten header indicating the maximum size. If the proxy fragmented the packet, it will reply with success and a prefix including the size of the first fragment. If the proxy modified the outbound TTL, it will indicate this in the reply prefix. If the proxy receives an ICMP response (e.g. Time Exceeded, Fragmentation Needed), it MAY forward it to the client. To support this use case, it MUST do so. A proxy with this behavior can be implemented without elevated permissions on most common operating systems (see [I-D.martinsen-tram-stuntrace]). 2.6.5. Advanced DNS queries The client sends an "outbound" UDP packet to port 53 with an ID number set, and a "dns" metadata value of 0. This packet is a DNS query, perhaps for a DNSKEY, TLSA, or TXT record. The proxy overwrites the destination IP address with the IP of its first DNS server and sends the outbound packet. It also sends a Schwartz Expires December 27, 2018 [Page 10] Internet-Draft HELIUM June 2018 "meta" message to the client, containing the IP header with this destination address, as well as the modified source address and port. The client is now waiting for an "inbound" message containing a reply from this DNS server to the modified source address and port. If no reply is received within some timeout, the client retries. This time, it sets a "dns" value of 1, indicating that the retry should use the proxy's second DNS server, if one exists. 2.6.6. UDP Server Application The client sends an "outbound" UDP packet with an ID number set and all zeros in the destination IP. The "meta" reply includes the rewritten source IP and port, which is bound to this context. The client can now inform third parties to send data to this IP and port. 2.6.7. High-Performance Delay-based Congestion Control The client is sending and receiving a flow that uses delay-based congestion control. Between client and proxy, this flow is transmitted according to the congestion control behaviors of the HELIUM substrate. From the proxy to the destination, congestion control is the responsibility of the client and destination. To monitor delay on the proxy-destination path, the client can include an ID number in every outbound message. This will cause the proxy to reply with a "meta" message, including the send timestamp. By comparing these send timestamps with the receive timestamps in inbound messages, the client can accurately monitor the round-trip time between proxy and destination. If the proxy-destination roundtrip time is gradually increasing, the client can reduce its send rate below the limit imposed by the HELIUM substrate. 2.7. Optimizations Proxies are NOT REQUIRED to perform reassembly of inbound IP fragments. Proxies MAY reassemble IP fragments, or they MAY forward each fragment independently to the client. This helps to limit proxy memory usage. When the client sends an "outbound" message with the "domain" metadata, the proxy has to buffer the corresponding packet until the domain name is resolved. To limit memory usage, the proxy can "peek" at the query without removing it from the transport's receive buffer. The transport's flow control will then limit the amount of memory that the client can consume. Schwartz Expires December 27, 2018 [Page 11] Internet-Draft HELIUM June 2018 3. WebSocket as a HELIUM Substrate (HELIUM-WebSocket) The HELIUM Inner Protocol (Section 2) requires a substrate transport to deliver messages between client and proxy. The WebSocket protocol is a suitable substrate. Each HIP-CBOR message (Section 2.4) can be sent as a WebSocket message of type "binary". If a browser is configured to act as a HELIUM client, communicating with the proxy over a WebSocket, the WebSocket is controlled and terminated by the browser itself, not associated with any particular origin or webpage. 3.1. Direct Configuration The location of a WebSocket HELIUM proxy is defined by a WebSocket URL, e.g. "wss://proxy.example/example-path". If the client knows the address of a WebSocket HELIUM proxy, then the client may simply connect to the proxy by establishing a WebSocket connection. The client's WebSocket handshake request MUST contain the "Sec-WebSocket- Protocol" header with value "helium-cbor" as well as an authorization header (e.g. Proxy-Authorization) if needed. 3.2. Implicit Configuration from an HTTP proxy Operators that run both an HTTP proxy, defined by some http or https URL, as well as a WebSocket HELIUM proxy, SHOULD return a response containing a new header, "Helium-Proxy-URL", when a client sends a proxy-specific request (e.g. HTTP CONNECT) to the operator's HTTP proxy. This new header, containing the WebSocket address of the HELIUM proxy, allows clients to discover the existence and location of a HELIUM proxy when they already know about an associated HTTP proxy. Clients can then connect to the discovered HELIUM proxy as described above. In cases where user-facing proxy configuration options are limited (e.g. a web browser's settings menu), a user may not be able to directly configure a HELIUM proxy even if they know its address. If an option for configuring a HTTP(S) proxy is available, however, the Helium-Proxy-URL header will allow a user to implicitly configure a WebSocket HELIUM proxy by entering an associated HTTP(S) proxy address. A client with access to both an HTTP(S) proxy and a HELIUM proxy SHOULD use the HTTP(S) proxy for all connections that it can support, and use the HELIUM proxy for all other network activity. Schwartz Expires December 27, 2018 [Page 12] Internet-Draft HELIUM June 2018 3.3. Optimizations After initiating the WebSocket connection, a client MAY send its initial HIP messages without waiting for the server's reply. This saves 1 RTT, similar to TLS False Start [FALSESTART]. Clients and proxies MAY negotiate WebSocket DEFLATE compression with context takeover (see Section 7 of [RFC7692]). This will replace consistent headers with back-references to the previous matching packet. On typical streams, this removes most of the IP and HIP-CBOR overhead, and can even compress the payload if it contains patterns that appear in each packet. However, implementers should use caution when combining compression and padding, as compression can render some padding schemes ineffective. 4. IANA Considerations The names and numbers of the HIP message types, metadata fields, and error codes will each require a new IANA registry. Additionally, HELIUM-WebSocket will require registration of a new WebSocket Protocol ("helium-cbor") and a new HTTP header ("Helium-Proxy-URL"). 5. Acknowledgements Many thanks to Katharine Daly and Lucas Pardue for their early and extensive review of this proposal. 6. References 6.1. Normative References [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Schwartz Expires December 27, 2018 [Page 13] Internet-Draft HELIUM June 2018 [RFC7692] Yoshino, T., "Compression Extensions for WebSocket", RFC 7692, DOI 10.17487/RFC7692, December 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [BBR] Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, "BBR Congestion Control", draft-cardwell-iccrg-bbr- congestion-control-00 (work in progress), July 2017. [FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, . [I-D.martinsen-tram-stuntrace] Martinsen, P. and D. Wing, "STUN Traceroute", draft- martinsen-tram-stuntrace-01 (work in progress), June 2015. [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, DOI 10.17487/RFC2661, August 1999, . [NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [OpenConnect] Mavrogiannopoulos, N., "The OpenConnect VPN Protocol Version 1.0", draft-mavrogiannopoulos-openconnect-00 (work in progress), September 2016. [PMTUD] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . Schwartz Expires December 27, 2018 [Page 14] Internet-Draft HELIUM June 2018 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, . [RMCAT-GCC] Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real- Time Communication", draft-ietf-rmcat-gcc-02 (work in progress), July 2016. [TURN] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, . Author's Address Ben Schwartz Google Email: bemasc@google.com Schwartz Expires December 27, 2018 [Page 15]