Internet DRAFT - draft-kaplan-behave-twist
draft-kaplan-behave-twist
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]
