Behave Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track Expires: September 26, 2008 March 26, 2008 Traversal With Internet Server Transports (TWIST): Relay Extensions to Session Traversal Utilities for NAT (STUN) draft-kaplan-behave-twist-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id- abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kaplan Expires September 26, 2007 [Page 1] TWIST March 2008 Abstract If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers) located behind other NATs. In these situations, it is necessary for the host to use the services of an intermediate node on the Internet that acts as a communication relay. Likewise, if a host of one IP address family wants to communicate with the host of another address family, through one or more NATs, an intermediate node may be necessary. This specification defines a protocol, called TWIST (Traversal With Internet Server Transports), that allows the host to control the operation of a TWIST relay and to exchange packets with its peers using the relay, or directly between each other. This is similar to TURN, but defines an alternative mechanism which is more scalable, cheaper to deploy, and is thus more likely to succeed in achieving wide- spread use. TWIST is not meant to replace TURN, but rather to provide an alternative. This document is a straw-man proposal, to stimulate discussion, not a fully defined draft. Table of Contents 1. Introduction...............................................3 1.1. Requirements...............................................4 2. Terminology................................................5 3. Applicability..............................................5 4. Definitions................................................5 5. Overview of Operation......................................5 6. TWIST-transport mode encapsulation.........................7 7. TWIST-tunnel mode encapsulation............................7 8. TWIST Client Stacks and Shims..............................8 8.1. TWIST Shim.................................................8 8.2. TWIST Stack...............................................10 9. TWIST Relay Operation.....................................10 10. Keepalive Behavior........................................11 11. Finding a TWIST server....................................12 12. TWIST Failures............................................12 13. Direct communication with TWIST Peers.....................13 14. IPv4-IPv6 Interworking....................................13 15. Security Considerations...................................14 16. IANA Considerations.......................................14 17. Acknowledgements..........................................14 18. References................................................14 18.1. Normative References......................................14 18.2. Informative References....................................15 Author's Address.................................................15 Intellectual Property Statement..................................16 Full Copyright Statement.........................................16 Acknowledgment...................................................16 Appendix A: TURN vs. TWIST Scalability...........................16 Kaplan Expires - September 2008 [Page 2] TWIST March 2008 1. Introduction Session Traversal Utilities for NAT (STUN) [STUN-bis] provides a suite of tools for facilitating the traversal of NATs and Firewalls. Traversal Using Relays around NAT (TURN) [turn], defines extensions for STUN that enable a client to request relayed transport address(es), and relay application data to/from the client and one or more peers. In this respect it is not much different from SOCKS [socks] architecturally, except that the TURN draft currently supports multiplexing multiple peer connections in one TURN connection, can use UDP transport to the TURN server for UDP application data, and uses STUN messages for control. TURN-tcp, defined in [turn-tcp], is currently being proposed to enable TURN servers to perform a relay function for TCP-based application data. In order to accomplish this, TCP is the transport mechanism for the TURN connection itself, and TCP application data between one or more peers and the relay is multiplexed over that TURN TCP connection to/from the client, using 8-byte channel-ID headers or STUN messages as carriers. This draft proposes an alternative relay transport mechanism, based on a TWIST relay server. A TWIST relay is similar to a TURN relay, but has requirements for which the TURN mechanism is unsuitable. These requirements are defined later in this document, but the major one is being implementable in broadly available and inexpensive hardware, for least cost and maximum scalability. A rationale for why hardware-based TWIST servers are more scalable and available than TURN servers is described in Appendix A. The net effect of needing hardware support or highly scalable software support is that TWIST performs relaying at a layer below TURN. TURN relays application data segments, where its logical relay shim lies above the UDP or TCP layer. TWIST relays UDP or TCP packet segments themselves, or even entire IP packets, depending on the encapsulation scheme used. Whereas TURN is more of a SOCKS model, TWIST is closer to a Mobile-IP Home Agent model, except the relaying is port-specific instead of IP-specific, for obvious reasons. The main motivation for TWIST is to put as little processing burden on the TWIST servers as possible, regardless of whether they are implemented in hardware or software, to increase the capacity and scalability on such servers. The reason for this is to reduce operator cost, because the business case for a network provider deploying TURN or [TEREDO] or any network relay server type is very weak. [for example, there are no public TEREDO relays available currently, as far as this author is aware] Relaying is mainly for the application's benefit, and thus the major brunt of the work should be performed by the application or host it resides on, rather than the relay server. Another factor which drives the need for a TWIST relay mechanism is the need for greater probability of success for direct client-peer connections, *without* a Kaplan Expires - September 2008 [Page 3] TWIST March 2008 TWIST relay. Today, getting a client and peer to connect directly to each other through NATs using TCP has low probability of success, as noted in [nat-tcp- study]. Part of the reason for this is the nature of TCP connection establishment and NAT policy behavior. It has been proposed that encapsulating TCP inside of UDP/IP, or TCP/IP inside of UDP/IP, will have a greater chance of success of establishing TCP connections directly between the client and peer, and avoid using a relay. Assuming one of those encapsulation schemes is adopted, the obvious next step is to simply perform the same encapsulation to/from the relay itself, for any transport. Lastly, TWIST provides an IPv4-IPv6 interworking function. In fact, TWIST could be the envisioned tunnel service mechanism outlined for future extensions to TEREDO, in section 6 of [teredo]. TEREDO as defined is designed for IPv6 connectivity over IPv4 when the TEREDO client is behind non-symmetric IPv4 NATs, whereas TWIST provides any-to-any connectivity when the TWIST client is behind IPv4 or IPv6 NATs of any type. Furthermore, TEREDO does not use STUN messages for its control communication - whether TWIST should follow TEREDO's message syntax and "bubble" packets instead of STUN for some (or all) cases is TBD. It should be noted that a TWIST relay server is still implementable by applications at the OS user-layer of common personal computers, for example for P2P applications, with caveats. The TWIST client can also be implemented in applications using standard TCP/IP stacks found in major Operating Systems, albeit with a sub-layer shim similar to IPSEC VPN software; or it can be integrated into a TCP/IP stack as a new socket type with less application involvement; or it can be implemented in a fully-integrated system. This document mainly describes the behavior of a new TCP/IP stack called a "TWIST Stack" and a VPN-style shim called a "TWIST Shim". 1.1. Requirements The following are the requirements for a network-based NAT and IPv4/IPv6 relay service: 1. The mechanism must enable IPv4 hosts, whether behind a NAT/firewall or not, to communicate with IPv4 or IPv6 hosts. 2. The mechanism must enable IPv6 hosts, whether behind a NAT/firewall or not, to communicate with IPv4 or IPv6 hosts. 3. The mechanism must work for all NAT types: full-cone, restricted-cone, symmetric, etc. 4. The mechanism must not subvert typical Enterprise policies employed by firewalls. In particular, it must allow firewalls to restrict the number of connections to or from a client to or from the external public Internet. 5. The mechanism must provide a means for the owner administrator of a host system to decide whether to support the mechanism, and whether to be a potential relay or not. 6. The mechanism must be implementable in a scalable fashion on commonly available and inexpensive hardware, such as those found in router services cards, firewalls, security gateways, and so on. Kaplan Expires - September 2008 [Page 4] TWIST March 2008 7. The mechanism must provide a way for a server/relay to perform client authentication. 8. The mechanism should provide a way for a client to authenticate the server relay. 9. The mechanism should support a High-Availability failover model on the relay servers, such that VRRP-style protection can be employed. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft proposes an alternative to [turn], [turn-tcp], and [teredo], using [stun-bis]. It is also applicable to [ice] and [nice]. 4. Definitions TWIST Relay Server: a TWIST relay server is similar to a TURN server or TEREDO relay, but with some important differences noted in this document. TWIST Client: a host device needing to use a TWIST relay server for crossing NATs, Firewalls, or interworking IPv4/IPv6. The client would have either a TWIST Stack or a TWIST Shim running on it. TWIST Stack: an integrated TCP/IP stack with TWIST support built in, used on a TWIST client. TWIST Shim: a VPN-like shim layer, below the operating system TCP/IP stack, which appears as a virtual interface to it, used on a TWIST client. Peer: a regular (non-TWIST) IPv4 or IPv6 host reached through a TWIST relay. TWIST Peer: another host on the Internet, possibly behind the same or a different NAT/Firewall or in a different address family, which implements a TWIST Stack or TWIST shim. Note this is different from a normal "peer", which does not need to implement anything new. A TWIST Peer is only needed when one does not wish to use a TWIST relay server. 5. Overview of Operation In a typical configuration, a TWIST client is connected to a private network [RFC1918] and through one or more NATs to the public Internet. On the public Internet is a TWIST server. Elsewhere in the Internet are one or more peers that the TWIST client wishes to communicate with. These peers may or may not be behind one or more NATs. Kaplan Expires - September 2008 [Page 5] TWIST March 2008 Terminology and figures follow those in [turn], which the reader is expected to be familiar with. The basic concept for the TWIST client is as follows: 1. A TWIST client determines the address of a TWIST relay server, through some unspecified means (configuration, DNS, DHCP, etc. - TBD). 2. The TWIST client sends a STUN Binding request to the server, and follows the procedures defined in STUN [STUN-bis] for STUN over UDP, potentially including authorization. 3. The TWIST client sends a STUN Allocate request to ask for a relayed transport address, similar to TURN, but with some new attributes for specific TWIST operations, defined later. This provides a single public IPv4 or IPv6 transport address on the TWIST server, based on the request. The TWIST client can use this transport address with peers, for example as a candidate for ICE or NICE (or TWICE?), or simply for its own use. The response also contains the type of encapsulation to use for data packets. 4. If the response indicated a "TWIST-transport mode", then the client encapsulates all UDP or TCP data messages inside of this same UDP flow used for STUN. In other words, it will be App/TCP/UDP/IP or App/UDP/UDP/IP on the wire. Whether to remove the inner UDP header for the latter case is TBD. 5. If the response indicated a "TWIST-tunnel mode", then the client encapsulates all UDP or TCP application data messages inside of IPSEC ESP inside of the UDP flow, following [RFC3948] IPSEC ESP tunnel-mode encapsulation formatting. In other words, it will be App/TCP/IP/Esp/UDP/IP or App/UDP/IP/Esp/UDP/IP, with an ESP pad trailer. The encryption and authentication is typically set to NULL (not encrypted or authenticated), but may be otherwise based on the STUN request/response (TBD). In other words the packet looks like UDP-encapsulated IPSEC ESP, but is not secure at the IP layer. Note that the inner and outer IP headers may not be of the same address family, and thus of different type/size. 6. Once the binding is complete and encapsulation mode begins, STUN control messages are demultiplexed from application data using encapsulated UDP port values. The address and port for the outer headers in application data messages sent from the client to the TWIST server are the TWIST server's address and port for destination, and TWIST client's address/port as source (which will be NATted), and will be the opposite on receiving packets from the TWIST server. In other words, what one would expect. For TWIST-tunnel mode, the address and port of the inner headers sent by the client to the TWIST server are the peer's for the destination, and TWIST server's relay addressing as source. In other words the sent inner packet appears as if it had been sent by the TWIST server to the peer. However, this does NOT mean the application sets the addressing this way - it doesn't. The TWIST-capable stack on the client performs this, or the VPN-like TWIST shim performs it. If a TWIST shim is used, the application actually believes it is communicating with the TWIST shim's well-known address only at its data socket - the reason for this is explained later. It is only noted here not to confuse the reader regarding Kaplan Expires - September 2008 [Page 6] TWIST March 2008 addressing on the wire vs. addressing in the application. For application data sent by the TWIST server to the client, it is the exact reverse of the above. For TWIST-transport mode, there is no IP inner header, just UDP or TCP. The inner UDP or TCP header's ports for application data sent from the client are set to the TWIST server's relay addressing as source, and peer's as destination. In other words, it appears as if it had been sent by the TWIST server to the peer, the same as in the TWIST-tunnel mode (but without the ESP/IP encapsulation). For application data sent in the opposite direction from the TWIST server to the client, it is the exact reverse of the above. 6. TWIST-transport mode encapsulation TWIST-transport-mode encapsulation should not be confused with IPSEC ESP transport-mode, whch is a different encapsulation format. TWIST-transport is simply the TCP or UDP data packet encapsulated in a UDP/IP packet. For TCP data, the encapsulated TCP header is the same one used by the TWIST server to send to the peer, or received from the peer, and its port numbers are therefore based on the Allocate response from the TWIST server. The checksum must be calculated by the client, based on the IP pseudo-header of the TWIST server's relay and peer IP Addresses, though they are not in the encapsulation packet sent between the client and TWIST server. [note: this is TBD] One can imagine as if the IP headers existed, but were removed to save packet size overhead. For UDP data, the encapsulated UDP header follows the same behavior as TCP. Note: for reducing packet size overhead, we could simply define that the UDP header is replaced by a TWIST demux header, which happens to look exactly like TURN's channel header in [turn]. That way TWIST using TWIST-transport encapsulation for UDP data *is* TURN, and this draft is simply an extension for TURN TCP and an alternate encapsulation format (TWIST-tunnel). For encapsulated TCP and UDP data, the destination port sent from the client, and the source port when sent by the TWIST server to the client, must not be TWIST's well-known port number. This allows the STUN messages for TWIST to be demultiplexed, as they will be using that port value. Note this means that a TWIST client cannot send TWIST STUN messages through a TWIST server to another peer which is a TWIST server. That is by design - creation of multiple relayed hops serves no useful benefit, but enables malicious parties to obfuscate their source. [or is it needed?] 7. TWIST-tunnel mode encapsulation TWIST-tunnel mode encapsulation looks like [RFC3948] UDP encapsulated IPSEC ESP packets on the wire, with the entire IP packet wrapped in ESP (header and trailer), and encapsulated in an UDP/IP packet. The encryption and authentication modes are NULL, meaning no encryption or authentication. The main purpose for Kaplan Expires - September 2008 [Page 7] TWIST March 2008 this is for TWIST servers which can use IPSEC hardware to perform a relay function. [TBD: ESP could be used to secure the TWIST connection if we want] The inner, encapsulated IP packet appears as it would based on the TWIST server sending or receiving the packets to/from a peer using its address and port. The setting of the SPI and such is still TBD. 8. TWIST Client Stacks and Shims An important concept to understand is the differences between a TWIST Stack and a TWIST shim are purely internal to the client end host system implementing them - on the wire and to the TWIST Relay or a TWIST Peer they look identical. The internal differences are necessary in order to provide a short-term easily- deployed installation package (the shim), and a long-term evolution to an integrated stack in the OS. At the beginning, there will be no TWIST-capable integrated TCP/IP stack. Therefore, in order for deployment to succeed, the user must be able to use the normal stack built into their OS. Application vendors which wish to cross NATs or support IPv4/v6 interworking will then be faced with either writing their own stack, or performing all the work in their application. No matter what, the application will need to "know" or support such a concept - the question is just how much work it needs to do. With a TWIST shim, the application needs to do more work, because it needs to support STUN and potentially know the TWIST server address(es). With a TWIST stack, the application does not support STUN at all, and the allocated relay address/port is returned by the stack using socket calls. The application will still need to know it wants to use TWIST, vs. normal behavior, but that is both unavoidable and appropriate in this author's opinion. 8.1. TWIST Shim With a TWIST shim model, the shim needs to be provided as a separate component from the application itself, either by the application vendor or third parties. There is a concern that a VPN-like shim raises the bar on deployment, because on many systems only the system administrator can install such drivers. This author feels that is actually appropriate: TWIST (or TURN for that matter) essentially make NAT and Firewall policies more difficult to enforce, and thus for organizations which own the systems their employees use, it is appropriate that only administrators be allowed to enable use of TWIST. Otherwise, TWIST or TURN are simply variants of RFC 3093 FEP. The main concept of a TWIST shim is to enable a knowledgeable application to use its standard TCP/IP stack, and offload the encapsulation and keepalive work to the shim. To accomplish this, this draft proposes a shim act like a local TWIST relay in a way, in that the application communicates to the shim using STUN itself, allocating and de-allocating flows in the shim. The main difference is that the shim does not need STUN and application TCP or UDP data to be multiplexed in the same port(s), therefore this draft performs the STUN messaging between an Kaplan Expires - September 2008 [Page 8] TWIST March 2008 application and the shim using a UDP flow, while the TCP or UDP data can be on a separate port/socket. A TWIST shim would operate by having a small amount of configuration, but mostly be dynamic in nature. The configuration it needs is the address of one or more TWIST relays. This could be either configured in the shim, or provided by the application through STUN messages to the shim. The other potential configuration of the TWIST shim is authorization information, used in STUN exchanges the TWIST server, and possibly other information if IPSEC is actually used in the TWIST- tunnel mode for real encryption and authentication. [all TBD] One of the common issues with using shims is addressing and routing inside the host. Typical VPN software adds routes for corporate networks to the host route table, so that packets from the OS TCP/IP stack destined to the corporate LAN are sent to the VPN shim, which then encapsulates them with the VPN server's address and routes them using the host's route table to reach that VPN server address. Clearly a TWIST shim needs to be able to operate such that it does not overlap with other VPN-style shims. It is tempting to make the TWIST shim simply add the TWIST relay server's address into the host route table, as a /32 host route, so that application messages sent to the TWIST relay server go to the TWIST shim instead, but then there is no way for the TWIST shim to reach that same address (it would loop back to the shim). Instead, this draft recommends the TWIST shim defined in this draft be allocated a well-known IPv4 and IPv6 address, allocated by IANA, so that any application can easily direct their messages to the TWIST shim without requiring configuration. Otherwise, it will have to be given a loopback-range address and the user will have to provision their applications to know the specific loopback address (it would not be 127.0.0.1, for example). When the application wishes to get a TWIST relay address for use, it sends a STUN Allocate request to the TWIST shim over its UDP stack using the well-defined STUN UDP port, which is routed through to the TWIST shim. The TWIST shim then first adds the source UDP port from the application to an alias table, performs a STUN Binding exchange with any necessary authorization info to a TWIST relay server, and then performs the Allocate request on behalf of the application. The returned address is added to the alias table in the shim, tying the source UDP port of the application with the allocated address and STUN transaction. This lets the shim know which subsequent application data goes over which UDP TWIST encapsulated flow, and so it can de-allocate them later. For TCP-based relay use, and possibly UDP data use, the application's STUN allocate request (always over UDP) would include the source TCP port in a new attribute. This lets the TWIST shim know which TCP-based packets are from which application, to tie to the correct UDP TWIST flow. At this point on, any non-STUN messages sent from the application from the same UDP source port to the same TWIST address/port, or from the TCP port identified in the Allocate, will be relayed by the shim by encapsulating the message based on the TWIST relay's preferred encapsulation method. Kaplan Expires - September 2008 [Page 9] TWIST March 2008 8.2. TWIST Stack The concept of a TWIST stack is simply an integrated TWIST-capable TCP/IP stack, most likely provided by the OS manufacturer or third parties. It would have the regular socket interfaces, as well as one for TWIST support. Such a TWIST-capable socket for UDP or TCP, or any transport, would internally perform all STUN interactions with a TWIST server or TWIST peer. Based on the type of socket call, it would provide a way for the application user to learn of the allocated TWIST relay address and port, so that it can use them for application-level needs. The stack would handle the right encapsulation mode based on the TWIST server's needs. The stack may allow the user application to set the possible TWIST servers to use, and any necessary authorization info, or it may be configured/determined through some other means. The benefit of a TWIST stack is it removes additional overhead and work from the application, to ease implementation. The application will still need to "know" that it is happening, because it will need to set the right socket type it wants to use, but that is both unavoidable and appropriate. 9. TWIST Relay Operation A TWIST relay acts as a STUN server for the purpose of supporting TWIST relaying. It may also be a general STUN server per [STUN-bis]. Whether the TWIST server listen port should be the same as STUN's is still TBD. The general behavior is as follows: 1) The TWIST server receives a STUN Binding request from a TWIST client, and possibly performs authorization per [STUN-bis]. The Binding request must include a new TWIST-CAPS attribute, which tells the server that the client is TWIST-capable plus some other potential info. 2) The TWIST server receives a STUN Allocate request from the TWIST client. One new attribute is included in the Allocate request: REQUESTED-TYPE, which indicates if the client wants a "listen" or "connect" relay type. The Allocate request must include a PEER-ADDRESS attribute for relay type of "connect", and optionally may do so for "listen" type. The allocate request must also include a REQUESTED-TRANSPORT attribute. (See [turn] for a definition of these attributes). 3) Based on the request attributes, the TWIST server returns a public IPv4 or IPv6 relay transport address. This relay address/port is bound to the UDP encapsulation flow from the TWIST client that the STUN exchange was in. 4) The TWIST server also returns the type of encapsulation it requires the TWIST client to use, in a new ENCAP-TYPE attribute. 5) If the REQUESTED-TYPE relay type is "listen", then when the TWIST server receives a TCP SYN (or UDP packet if that was the REQUESTED-TRANSPORT type) on its relay address/port, it encapsulates the TCP SYN or UDP packet in the encapsulation type it is using and sends it to the TWIST client. If the PEER- ADDRESS was not set by the client for this flow, the TWIST server "latches" that peer's address/port to the relay entry, such that only TCP or UDP data Kaplan Expires - September 2008 [Page 10] TWIST March 2008 from the same peer Address/port are relayed to the TWIST client over the same encapsulation flow. The client must open a new TWIST flow to listen for another connection, but can indicate it wants to use the same relay address/port by re-using a cookie given to it by the TWIST server's STUN Allocate response. 6) If the relay type is "connect", then when the TWIST server receives encapsulated TCP packets (SYN or whatever) or UDP from the TWIST client, it forwards them to the peer, the address of which was indicated in the STUN Allocate request PEER-ADDRESS attribute; and it does the same for all TCP or UDP data packets from the peer for the same flow tuples. Note that for the IPSEC-style encapsulation, the peer address/port will also be indicated in the encapsulated inner IP header as well. 7) After the successful Allocate response is received by the client, any STUN messages to/from the server must be over the same encapsulation mode, and are demultiplexed from the application data by using the well-known UDP port for TWIST. In other words, STUN is a UDP flow within the encapsulation scheme, but who's inner encapsulated destination port number to the TWIST server and source port from the TWIST server is the deinfed port for TWIST (wich may be STUN's port - TBD). In summary, the TWIST client asks for a relay address using STUN over UDP to the TWIST server, which responds on that same UDP "flow". This flow is for one and one relay type only: listen or connect. Regardless of the type, there will only be one application-to-peer connection using this one flow. This 1:1 mapping allows firewall administrators to allow TWIST flows, but restrict how many flows each client can use, or at least monitor the number of them for suspicious usage. This is by design, to prevent clients from using a TWIST server as a public server service and bypassing firewall policy. Otherwise, such a mechanism will simply be blocked by a firewall, if its policies cannot be enforced. This is in contrast to TURN, which basically has no such restriction in place, other than written recommendations. It should be noted that the IPSEC-style "twist-tunnel" encapsulation clearly could be used for hardware-based multiplexing of multiple peer connections in one client TWIST flow. Hardware for that is readily available, because it is how IPSEC works. Indeed, even the "twist-transport" mode could support such using TURN- style channel-id's, in most hardware. Whether TWIST should allow such multiplexing, and if so how it would allow firewall policy control, is TBD. 10. Keepalive Behavior Generation of keepalives to keep the TWIST flow active and any intermediate NAT pinholes open is performed by the TWIST Stack or Shim. The actual mechanism depends on what the TWIST server supports, and returns in its ENCAP-TYPE attribute in the Allocate response. This draft recommends the server be allowed to choose from one of two "keepalive modes": 1. "RFC3948" mode, whereby the client sends the value 0xFF in a UDP packet, as per [RFC3948]. Kaplan Expires - September 2008 [Page 11] TWIST March 2008 2. "STUN Binding" mode, whereby the client sends STUN Binding requests, as defined in [ice]. Note that "RFC3948" mode does not cause a response to be generated by the TWIST server, and is discarded by the server; whereas "STUN Binding" mode does generate a response from the server. For TCP-based TWIST relayed flows, the client may also send TCP Keepalives, which will be relayed to the far-end peer, to get a TCP response from the peer through the relay and verify end-end connectivity. However since not all client stacks can generate such keepalives, or set the timer for them, it is not a valid TWIST server keep-alive mode. As long as a TWIST keepalive is received by the server, or data is relayed from the client to the peer (including TCP keepalives), the relay flow will be kept alive. Thus the TWIST keepalives only need to be generated if there is no client generated relayed traffic for a period of 20 seconds or more. A STUN Refresh request may still need to be sent using a much longer timer to keep the TWIST Shim and TWIST server allocation refreshed, but this is TBD. 11. Finding a TWIST server The TWIST server address may be provisioned on the client, learned through some means such as DHCP and DNS SRV, or IANA may allocate a reserved IPv4 and IPv6 address, for example for anycasting use. This is TBD. 12. TWIST Failures Since the relay mechanism is performed at a lower layer than TURN, TWIST servers can employ VRRP-style protection mechanisms, whereby a virtual IP Address is used, which is shared by a primary and backup using VRRP or similar means for failure detection and role shifting. The mechanism for sharing relay flow tuples and state information is out of scope of this draft. Note that a TWIST server pair would need to switch over fast enough to avoid detection by clients. If a client discovers a particular TWIST encapsulation flow has failed, due to lack of STUN response or possibly keepalive response (depending on the keepalive mode), then it should close the application layer connection (close the socket) and try to open a new one on the same TWIST server address. If a client discovers the TWIST server has failed, due to lack of STUN response for an initial Binding or Allocate request, then if it is using a TWIST server address it learned through an ALTERNATE-SERVER STUN attribute, it should try the previous server address. If that also fails, or it did not learn of the server through an ALTERNATE-SERVER attribute, it should try any alternate servers it knows about (through provisioning or discovery). Kaplan Expires - September 2008 [Page 12] TWIST March 2008 13. Direct communication with TWIST Peers Using TWIST encapsulation for direct TWIST client to TWIST Peer use is left for another draft to define. It is possible for the TWIST Shim to be used for such a model, as well as a TWIST Stack. 14. IPv4-IPv6 Interworking It should be clear from this TWIST concept that IPv4-IPv6 interworking - the ability for a host on the IPv4 Internet to reach a host on the IPv6 Internet address space, and vice-versa - is based on the type of address family the client asks for from the TWIST relay server. What may not be clear is why this is any better than other IPv6 transition schemes proposed thus far. The purpose of this section is to describe some of the benefits. Most of the IPv6 transition mechanisms proposed thus far have assumed it is in the best interest of hosts and networks to migrate to IPv6 as quickly as possible. They readily expect application developers to support IPv6 or dual-stacks, and network providers to run dual-stack networks and systems. This is far from reality. The reality is virtually all "services" need to support IPv4, because all users are currently reachable directly or through servers (email, web, etc.) via IPv4. No one would develop an IPv6-only service, given all of the potential users are not reachable on it, unless they can provide a way to reach and be reached from IPv4 hosts. And there can be absolutely no expectation made that IPv4 hosts will change to support reaching IPv6 hosts - it is in fact the other way around - it is incumbent upon the IPv6 hosts/servers to make themselves work seamlessly with IPv4 hosts/servers, without the IPv4 hosts being the wiser. One way proposed thus far to enable IPv6 hosts to communicate with IPv4 hosts is for the IPv6 host to be dual-stacked - in other words for it to have an IPv4 address. A concern with this idea is: once a host has an IPv4 address, why would it need an IPv6 one? One answer to this is the IPv4 address it gets is an RFC 1918 private one, and the host is behind a NAT, and the benefit of IPv6 is it can have a public one. But that does not solve the problem of IPv4 NAT traversal, which this draft does, as does [turn], [stun], and [ice]. Another answer could be: the host gets a public IPv4 host/port combination, only when it needs it, for the application which needs it, and uses IPv6 otherwise if it can. TWIST enables this to occur, similar in concept to the DSTM mechanism in [draft-dstm]. Furthermore, TWIST resolves some of the issues documented in [RFC4966] regarding the IPv4/v6 NAT-PT mechanism in [RFC2766]. Some of the issues are inherent in protocol translators. However, with regards to the documented issues of applications using IP Addresses inside their protocols, and the DNS-ALG issues, TWIST does provide a solution. For the former, TWIST (and TURN) lets the application discover the address it was allocated. For the latter, a DNS-ALG is not needed, because TWIST is not intended to be a transparent translator. The TWIST client knowingly requests a transport address and uses one or more TWIST servers, even though the peer(s) does not know it is communicating through one. Kaplan Expires - September 2008 [Page 13] TWIST March 2008 This means an IPv6-only host can request an IPv4 TWIST relay transport address, to reach IPv4-only resources it discovered - for example perhaps they only had DNS A records. In fact, it could use a TWIST relay to perform the DNS query through for IPv4-only DNS servers, if it had to, and yet the TWIST relay server would not need to modify the DNS contents. If an IPv6-only host is a server, it could even be given longer-lasting IPv4 listen-mode transport addresses on a TWIST server, which it could publish in DNS SRV records on dual-stack DNS servers, for example, so IPv4 hosts could reach it. The benefit of TWIST, then, is it lets network operators deploy IPv6-only or IPv6- mostly networks, either with or without RFC 1918 addresses for IPv4 in those networks, while providing on-demand public IPv4 addresses to applications in those IPv6 networks which need it. And it allows those dual-stack hosts which have a private IPv4 address behind an IPv4 NAT, communicate with other IPv4 hosts if it finds they are not reachable through IPv6 or if they too are behind IPv6 NATs or Firewalls. 15. Security Considerations There are plenty of security implications for TWIST, similar to those for TURN and STUN. They will be documented here if this draft finds interest. Use of TWIST- tunnel mode encapsulation's IPSEC layer for actual IPSEC encryption and authentication, and what key management mechanism to use for such, is also TBD. 16. IANA Considerations This document makes no request of Internet Assigned Numbers Authority (IANA) currently, but may request an IPv4 and IPv6 address to be reserved for a TWIST Shim address in a future revision. 17. Acknowledgements Thanks to Dan Wing for bouncing some ideas off of. 18. References 18.1. Normative References [STUN-bis] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-15.txt, February 2008. [turn] Rosenberg, J., Mahy, R., Matthews, P., "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-07.txt, February 2008. [RFC3948] Huttunen, A., et al, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. Kaplan Expires - September 2008 [Page 14] TWIST March 2008 [ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19.txt, October 2007. 18.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3519] Levkowetz, H., Vaarala, S., "Mobile IP Traversal of Network Address Translator (NAT) Devices", RFC 3519, April 2003. [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translators (NATs)", RFC 4380, February 2006. [RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC4966] Aoun, C., Davies, E., "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [turn-tcp] Rosenberg, J., Mahy, R., "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", draft-ietf-behave-turn-tcp-00.txt, November 2007. [nice] Rosenberg, J., "NICE: Non Session Initiation Protocol (SIP) usage of Interactive Connectivity Establishment (ICE)", draft-rosenberg-mmusic-ice- nonsip-00.txt, February 2008. [nat-tcp-study] Guha, S., Francis, P., "Characterization and Measurement of TCP Traversal through NATs and Firewalls", http://saikat.guha.cc/pub/imc05- tcpnat.pdf. [draft-dstm] Bound, Jim, et al, "Dual Stack Transition Mechanism (DSTM)", draft- ietf-ngtrans-dstm-08.txt, July 2002 (expired). Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 US Email: hkaplan@acmepacket.com Kaplan Expires - September 2008 [Page 15] TWIST March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Appendix A: TURN vs. TWIST Scalability Using TURN for TCP-based applications, or UDP-based applications with a TCP TURN connection, has a non-trivial relay cost burden, not unlike that of SOCKS. Part of the reason it is expensive for relays is it is performed at a layer above TCP, Kaplan Expires - September 2008 [Page 16] TWIST March 2008 meaning a TCP connection is maintained by the TURN relay for each client and peer data stream. The advantage is it makes P2P applications, which rely on user systems to be a relay, to be easily deployable, since user applications sit at the user layer of the operating system and do not typically have access to relay data below the user layer. SOCKS implementations, however, typically perform "TCP-slicing", which is a well- known technique to "stitch" together two TCP connections and perform a data stream relay function without actually maintaining TCP socket timers and not all state information. Instead, the SOCKS relay simply rewrites certain TCP header values, and relies on the true TCP endpoints to perform TCP segmentation, retransmissions, back-off, etc. Unlike SOCKS, TURN-tcp can accept multiple peer connections and relay them through a single TURN connection. While TURN-tcp may still allow a modified form of TCP- splicing to be used to reduce the burden on the TURN-tcp relay, it presents no significant scalability advantage over using multiple SOCKS sockets. The type of context state that must be maintained on a TURN-tcp relay vs. a SOCKS relay is virtually identical. If anything, the processing burden is likely to be slightly higher on TURN-tcp than SOCKS, because TURN-tcp adds a channel header or STUN message in front of the TCP segment payload, which must be removed on its way to the peer, and added on its way to the client. Because STUN requests/responses can be sent at any time on the TURN connection, stitching also becomes a bit more complicated, and the TURN server may not actually be able to avoid having TCP retransmission timers or perform segmentation in certain situations. Regardless of whether stitching can be performed or not, relaying at the TCP layer is more expensive than relaying below it, for both software and hardware. For hardware in particular, it may require new hardware components, which is a significant burden on network providers. Even for hardware which can do it, it typically reduces total scalability compared with doing it at lower layers, and thus still affects overall cost. Without an equally strong business case, such expense will simply not be justifiable. Therefore this draft tries to allow for as many hardware types as reasonably possible, including the functions capable in most router "services" cards, firewalls, load-balancers, mobile-ip home agents, security gateways, etc. The goal is not to require new hardware to be designed or deployed, but simply to be able to re-use existing hardware with software/firmware upgrades. Clearly one cannot know a priori all the hardware capabilities of every type of device, as they often include ASICs or FPGAs with limited flexibility. The idea then is to play the probability game, and reduce the overhead to as simple a form as possible; this is one of the reasons for the IPSEC tunnel-mode encapsulation scheme, because hardware which supports UDP encapsulated IPSEC tunnels is readily available and deployed on many platforms. The TWIST-transport mode (not to be confused with IPSEC transport-mode), is offered to reduce the message size overhead of IPSEC encapsulation, for those relay servers that can do so, which this author believes is also a large population. Whether the Mobile-IP specific UDP encapsulation methods in [RFC3519] should also be supported is TBD. Kaplan Expires - September 2008 [Page 17] TWIST March 2008 Furthermore, server protection schemes employed at a lower layer are typically more scalable and effective than protection schemes which try to keep TCP state. Keeping TCP segment information synchronized typically requires either an inline protection scheme which constrains the topology of protection, or a processing- intensive lock-step synchronization replication model. Performing synchronization of low-level relays is far cheaper, because very little information has to be exchanged and it does not change during a flow's lifetime. Kaplan Expires - September 2008 [Page 18]