Network Working Group S. Guha Internet-Draft Cornell U. Expires: June 11, 2005 December 11, 2004 STUNT - Simple Traversal of UDP Through NATs and TCP too draft-guha-STUNT-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/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 June 11, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Simple Traversal of UDP Through NATs and TCP too (STUNT), which extends STUN to include TCP functionality, is a lightweight protocol that allows applications running behind a NAT to determine external IP and port-binding properties, packet filtering rules and various timeouts associated with TCP connections through the NAT. Knowing these parameters allows applications to establish TCP sessions between two NAT'ed hosts. As a result P2P and other applications can work through existing NAT infrastructure without sacrificing the benefits of TCP. Guha Expires June 11, 2005 [Page 1] Internet-Draft STUNT December 2004 Table of Contents 1. Applicability Statement . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 4. NAT Variations . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 NAT Binding . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Binding Lifetime . . . . . . . . . . . . . . . . . . . . . 7 4.3 Endpoint Filtering . . . . . . . . . . . . . . . . . . . . 7 4.4 Hairpinning Behaviour . . . . . . . . . . . . . . . . . . 8 4.5 Packet Mangling . . . . . . . . . . . . . . . . . . . . . 8 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 9 6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 11 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . 12 7.1 Capture Request . . . . . . . . . . . . . . . . . . . . . 12 8. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Formulating the Capture Request . . . . . . . . . . . . . 15 8.2 Processing Capture Responses . . . . . . . . . . . . . . . 15 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1 Binding Behaviour . . . . . . . . . . . . . . . . . . . . 17 9.2 Binding Timeouts . . . . . . . . . . . . . . . . . . . . . 18 9.3 Endpoint Filtering Behaviour . . . . . . . . . . . . . . . 19 10. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 20 10.1 Message Header . . . . . . . . . . . . . . . . . . . . . 20 10.2 Message Attributes . . . . . . . . . . . . . . . . . . . 20 10.2.1 PACKET-REQUEST . . . . . . . . . . . . . . . . . . . 22 10.2.2 CAPTURE-TIMEOUTS . . . . . . . . . . . . . . . . . . 23 10.2.3 CAPTURED-PACKET . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . 25 11.1 Attacks . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1.1 Approach I: DoSing STUNT . . . . . . . . . . . . . . 25 11.1.2 Approach II: DoSing hosts . . . . . . . . . . . . . 25 11.1.3 Approach III: DoSing the host NAT . . . . . . . . . 25 11.2 Countermeasures . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 13. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . 29 Guha Expires June 11, 2005 [Page 2] Internet-Draft STUNT December 2004 1. Applicability Statement STUNT enables TCP setup between NAT'ed hosts, but only for a subset of existing NAT pairs. In particular, STUNT does not enable TCP setup between NATs with unpredictable port bindings. STUNT does not work when the STUNT server is not in a common shared address realm. For a more complete discussion of the limitations of STUNT, see Section 13. 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 [RFC2119]. Guha Expires June 11, 2005 [Page 3] Internet-Draft STUNT December 2004 2. Introduction Simple Traversal of UDP Through NATs (STUN) has enabled a new generation of peer-to-peer applications that can function in the presence of Network Address and Port Translators (NATs) devices. It allows applications to discover the presence and type of NAT and learn the binding allocated by the NAT without requiring any changes to the NATs themselves. However, STUN is limited to UDP and does not work for TCP. The behaviour of NATs when it comes to TCP is more complex and cannot be captured with the mechanisms provided by STUN. Lacking TCP support, many peer-to-peer applications fall back onto transferring data over UDP. As a result applications forfeit congestion avoidance in the form of Explicit Congestion Notification and instead each application must re-engineer TCP friendliness into its UDP based protocol. TCP friendliness often deviates from the application's primary goals and is subsequently ignored causing congestion problems later. Another approach is to run an entire TCP/IP stack encapsulated inside UDP datagrams. This approach incurs overheads introduced by encapsulation, decapsulation and transmission of extra header data. The protocol described here, Simple Traversal of UDP Through NAT and TCP too (STUNT), extends STUN allowing applications behind a NAT to discover the NATs behaviour for TCP packets and to learn the transport address binding allocated by the NAT. Using STUNT, applications can establish raw TCP sessions with other NAT'ed hosts without using encapsulation, tunelling, relaying or a userspace stack, and without forfeiting any of benefits of using TCP. Like STUN, STUNT requires no changes to NATs and works with a large majority of NATs currently present in the network architechture. Guha Expires June 11, 2005 [Page 4] Internet-Draft STUNT December 2004 3. Terminology STUNT Client A STUNT client (also referred to as a client) is an entity that generates STUNT requests. STUNT Server A STUNT server (also referred to as a server) is an entity that receives STUNT requests, and sends STUNT responses. STUNT servers may be attached to the public Internet or a private network and can serve networks that the server resides in or networks behind a NAT whose external network is served by the server. Transport Address A transport address (also referred to as an address) identifies a TCP endpoint as an IP address and TCP port. It is represented as 'a:p' where 'a' is an ip address and 'p' is a port. A transport address of the form 'p:q (P:Q)' represents the internal address and port p:q that is translated by the NAT to P:Q. Guha Expires June 11, 2005 [Page 5] Internet-Draft STUNT December 2004 4. NAT Variations It is assumed that the reader is familiar with NATs. It has been observed that NAT treament of TCP varies among implementations. 4.1 NAT Binding The NAT Binding allocated for new connections can be classified in the following four ways: Independent: When a NAT maps all outbound TCP connections originating from the same internal transport address to the same external transport address regardless of the destination transport address. If internal address p:q is allocated external address P:Q when connecting to R:S then such NATs allocate P:Q for a connection between p:q and any X:Y. Address Dependent: When a NAT maps all outbound TCP connections from the same internal transport address to the same external transport address only when the destination IP is the same. In the above example p:q is translated to P:Q only for subsequent connections to R:Y for any Y. Address and Port Dependent: When a NAT maps all outbound TCP conncetions from the same transport address to the same external transport address only when the destination IP and port are same. In the above example p:q is translated to P:Q only for subsequent connections to R:S. Session Dependent: When a NAT does not map all outbound TCP connections from the same transport address to the same external transport even when destination IP and port are the same. In the above example a new connection from p:q to R:S is translated to M:N. These four NAT Binding properties can be abbreviated as NB=I, NB=AD, NB=ADP and NB=SD respectively. In cases when the NAT allocates a fresh external binding (P:Q) when the last port allocation was (R:S) then the NAT's Binding Delta (R-P:S-Q) parameter represents the difference in allocations. This binding delta may be constant or may be random. If a NAT assigns an external port Q, when available, that is equal to the internal port (q=Q) then the NAT is port preserving. A weaker version is when the NAT allocates an external port binding that is in the same port range (LOW, HIGH and DYNAMIC) as the internal port. NATs may preserve zero or more port ranges. Guha Expires June 11, 2005 [Page 6] Internet-Draft STUNT December 2004 If a NAT assigns port P for internal port p and P is even if and only if p is even then the NAT preserves even-odd port parity. If the NAT assigns address P:Q and P:Q+1 for two connections initiated from internal ports p:q, p:q+1 then the NAT preserves next-higher port parity. If a NAT assigns the same external IP and port to two different internal transport addresses then the NAT is said to have port overloading behaviour. 4.2 Binding Lifetime A NAT may release an allocated binding after an idle period. The length of this idle period could depend on the connection state. For instance the idle timer can be short when the connection is in the SYN_SENT or LAST_ACK states and long when in the ESTABLISHED state. A NAT may or may not release bindings upon receiving certain packets such as TCP RST packets and ICMP errors for a connection. 4.3 Endpoint Filtering Open: The NAT does not filter any packets. Endpoint Independent: If a connection exists between p:q (P:Q) and R:S then NATs with endpoint independent filtering behaviour route incoming SYN packets with destination P:Q and source X:Y to p:q for any X and Y. Endpoint Address Dependent: In the above example NATs with endpoint address dependent filtering will route SYN packets from only R:Y to p:q for any Y. Endpoing Address and Port Dependent: In the above example NATs with endpoint address and port dependent behaviour will route new SYN packets only from R:S to p:q. Such SYN packets can only be generated after the previous connection between p:q (P:Q) and R:S is closed and before the NAT releases the binding. There four Endpoint Filtering properties can be abbreviated as EF=O, EF=I, EF=AD and EF=ADP respectively. A NAT may selectively filter certain TCP packets even from the IP and port to which a packet was sent recently. For instance after an internal host p:q (P:Q) sends a TCP SYN packet to a destination R:S, the NAT may filter out an incoming SYN from R:S to P:Q and all other TCP packets from R:S to P:Q except for a TCP SYNACK or TCP RSTACK. Guha Expires June 11, 2005 [Page 7] Internet-Draft STUNT December 2004 If a packet is filtered by the NAT, it may either drop it silently, or generate an ICMP error or a TCP RST packet to inform the sender. 4.4 Hairpinning Behaviour If an internal host p:q sends a packet to the external address M:N that is assigned to another internal address m:n then the NAT can filter the packet or route it to the intended destination with source address either the original internal address (p:q) or a translated address (P:Q). A NAT that supports hairpinning behaviour demonstrates the latter and translates the source to P:Q. 4.5 Packet Mangling A NAT may mangle packets by changing bytes that need not be changed for successful operation or by not changing bytes that should be changed. For instance a NAT may change the IP Identification of packets traversing the NAT. It may add a random offset to the TCP sequence number of outgoing TCP packets for a connection and subtract the same offset from the acknowledgement numbers in incoming packets. It may not correctly translate IP packets in the payload of ICMP packets. Instead of decrementing the IP time-to-live value by one, it may change the value to something different. It may even mangle payloads by translating byte sequences that look like the the internal or external transport address encoded as binary data or an ASCII string. Guha Expires June 11, 2005 [Page 8] Internet-Draft STUNT December 2004 5. Overview of Operation In a typical STUNT configuration presented in [RFC3489] a STUNT client is connected to private network 1. NAT 1 connects this network to private network 2. NAT 2 connects private network 2 to the public internet. The STUNT server resides on the public internet. This is illustrated in Figure 1. +--------------+ | STUNT Server | +--------------+ +--------------+ Public Internet .........| NAT 2 |............ +--------------+ +--------------+ Private NET 2 .........| NAT 1 |............ +--------------+ +--------------+ Private NET 1 | STUNT Client | +--------------+ Figure 1 A client sends a request to a server and the server returns a response. There are three types of requests - Binding Requests, sent over UDP for STUN and TCP for STUNT, Shared Secret Requests, sent over TLS over TCP and Capture Packet Requests, sent over TCP. As with STUN, the Shared Secret Request ask the server to return a temporary username and password. This username and password are used in subsequent Binding Requests and Capture Requests for the purpose of authentication and message integrity. Binding requests are used to determine the bindings allocated by the NATs. The client sends a Binding Request to the server, over TCP. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client. There are some parameters in the response to allow the client to discover servers at alternate ports and IP addresses that can return binding responses. Capture requests are used to determine the firewall rules of the NATs. The client sends a Capture Request to the server, over TCP. The request contains parameters for the firewall test including a packet-dialogue between the client and server. The server assigns transport addresses that the client can test firewall rules against. Guha Expires June 11, 2005 [Page 9] Internet-Draft STUNT December 2004 The assigned addresses are copied into a Capture acknowledgement response and sent to the client. Both the server and client engage in the packet dialogue for a set duration and each captures packets received relating to the dialogue. The server constructs a capture response that contains the packets sent and received and sends it to the client. A STUNT client is typically embedded inside an application. It can discover a STUNT server as specified in [RFC3489]. It then uses a Shared Secret Request to authenticate with the server and learn the TCP transport address of the binding and capture response server. The client can then initiate TCP connections to the binding response servers in order to learn the NATs binding properties. The client contacts one server multiple times to check if the binding changes. If it does not then the client checks if the binding changes for a different server at the same IP address but different port, and finally whether it changes for a third server at a different IP address and port. Once the NATs binding behaviour is known the client can find or predict the binding for new connections through a simlpe algorithm. A client typically also learns the filtering behaviour of the NATs to decide between TCP Traversal techniques. It does so by testing the NATs response to incoming TCP SYN packets in various situations. To conduct the test the client establishes a TCP connection to the capture response server and issues a capture request, processes the acknowledgement, initiates the test and processes the response. The filtering behaviour is learned once and is refreshed occasionally when the client suspects that the NAT device may have been changed. Guha Expires June 11, 2005 [Page 10] Internet-Draft STUNT December 2004 6. Message Overview STUNT messages, like STUN, are TLV (type-length-value) encoded using big endian (network ordered) binary. All STUNT messages start with a STUNT header, followed by the STUNT payload. The payload consists of attributes, which depend on the type of the message. The message header contains the message type, a transaction ID and length. The message type can be Binding Request, Binding Response, Shared Secret Request, Shared Secter Response, Capture Request, Capture Acknowledgement or Capture Response. The transaction ID is used to correlate requests and responses. In addition to the attributes defined by STUN, STUNT defines several attributes. The first is a PACKET-REQUEST attribute which encodes several packet types including TCP packets like SYN, SYNACK etc, ICMP packets or client-defined packets. It also contains flags indicating whether the server should send the packet or whether the client should send the packet, which server address the packet should be sent to or from and whether and how often it should be retransmitted. One or more such PACKET-REQUEST attributes are placed in a Capture Request. The second attribute is CAPTURE-TIMEOUTS which defines the duration of the capture test. It also constains a retransmit interval for selected packets. The third attribute is a CAPTURED-PACKET which contains the IP header and payload of a packet and whether it was sent or received by the server. It also contains when the packet was first sent or received and how many times it was retransmitted. Guha Expires June 11, 2005 [Page 11] Internet-Draft STUNT December 2004 7. Server Behaviour The server behaviour for Binding Requests and Shared Secret Requests is identical to STUN exept that the CHANGE-REQUEST and RESPONSE-ADDRESS attributes in Binding Requests are ignored and Shared Secret Responses include an additional SOURCE-ADDRESS for the non-TLS TCP transport address of the server. 7.1 Capture Request Capture Requests are received on TCP connections. It is RECOMMENDED that the server check the Capture Request for a MESSAGE-INTEGRITY attribute. If not present and the requires integrity checks on the request then it generates a Capture Error Response with an ERROR-CODE attribute with response code 401. If the message integrity is present the server computes the HMAC over the request as described in [RFC3489]. Assuming message integrity check passes, processing continues. The server MUST ensure that a CAPTURE-TIMEOUT attribute is present. The server MUST check the PACKET-REQUEST attributes in the message and ensure that it is possible to complete the request. The first TCP packet sent from any server endpoint or awaited at any server endpoint MUST have the TCP SYN flag set. Any requests to send ICMP errors that encapsulate the IP packet MUST come after some packet is received. If the server sends a SYN before receiveing any other packets then it MUST ensure that the request contains a RESPONSE-ADDRESS attribute. If the request includes client-defined packets, the server MUST ensure that the destination IP address of the packet matches the IP address sending the request. If any of the checks fail then the server MUST generate a Capture Error Response with an ERROR-CODE of 400. Assuming the request is correctly formed, the server MUST generate a single Capture Acknowledgement Response. For each unique combination of "change IP" and "change port" flag present in the PACKET-REQUEST attributes, the server MUST allocate an IP address and port that satisfy the flag requirements. These addresses MUST be advertised to the client in the Capture Acknowledgement as CHANGES-ADDRESS attributes in the order the flags were first encountered while processing PACKET-REQUESTS sequentialy from the first attribute onwards. The server MUST send the acknowledgement to the client through the TCP connection on which the request was received. After the acknowledgement is sent, the capture test begins. The server MUST process each PACKET-REQUEST attribute in order starting at the first such attribute. Guha Expires June 11, 2005 [Page 12] Internet-Draft STUNT December 2004 If the "send or receive" flag for the PACKET-REQUEST is set, then it must construct a packet of the appropriate type. The source IP and source port (for TCP packets) MUST reflect the address advertised by the server for the particular compbination of the "change IP" and "change port" flags. TCP packets with the ACK flag set MUST acknowledge the last TCP packet received. ICMP error packets MUST encapsulate the first 64 bytes of the last packet received. All TCP packets constructed by the server or defined by the client MUST include a TCP option with option 0xFF. The value MUST constain the string "STUNT:" without quotes followed by the IP address and port the request was sent from. The length of the option is chosen accordingly. All ICMP packets constructed by the server or defined by the client MUST contain the IP that the request was sent from in the used field (bytes 5 to 8) of the ICMP packet. If the "delay" flag is not set then the packet MUST be sent as soon as it is constructed. Otherwise it MUST be sent after the expiry of the delay interval specified in the CAPTURE-TIMEOUTS attribute. If the "send or receive" flag for the PACKET-REQUEST is not set, then the server must suspend processing the capture request until the required packet is received. While awaiting the packet the server SHOULD retransmit the last sent packet starting with a base interval and doubling it at every retransmit. The base interval for packets generated with the "delay" flag set SHOULD be the delay interval in the CAPTURE-TIMEOUTS attribute. For other packets it SHOULD be 3 seconds. A server MAY be configured to chose a longer interval. A TCP packet generated for a PACKET-REQUEST with the "retransmit ACK'ed" flag not set MUST NOT be retransmitted after it is acknowledged by the recipient. Once the server receives a packet that matches the PACKET-REQUEST it must check the IP and TCP checksum, if present, and discard corrupted packets. If the TCP ACK flag is set then it MUST acknowledge the last TCP packet sent by the server. The server continues processing the PACKET-REQUESTS after successfully matching the incoming packet. If the server receives a TCP packet with the RST flag set acknowledging the last TCP packet sent from a server endpoint, then the server should resume processing subsequent PACKET-REQUESTS and ignore all PACKET-REQUESTS for that endpoint. If the server finishes processing all the PACKET-REQUESTS before the capture timeout expires, it MUST restart processing the requests anew from the start. If the capture timeout, as specified in the CAPTURE-TIMEOUTS attribute, expires then the server MUST terminate the capture. Once the capture terminates, the server MUST generate a single Guha Expires June 11, 2005 [Page 13] Internet-Draft STUNT December 2004 Capture Response message. The message should include one CAPTURED-PACKET attribute for each unique packet sent or received, along with the number of times it was retransmitted and the time since the beginning of the capture it was first transmitted or received. The response MUST be sent to the client on the same TCP session on which the request was received. Guha Expires June 11, 2005 [Page 14] Internet-Draft STUNT December 2004 8. Client Behaviour The client behaviour for STUNT server discovery, obtaining a shared secret, formulating Binding requests and processing Binding response is similar to that for STUN. The first difference is that the shared secret response contains an additional SOURCE-ADDRESS parameter that advertises the non-TLS TCP server address the client can send binding requests to. The second difference is that the CHANGE-REQUEST and RESPONSE-ADDRESS parameters are not used for TCP Binding requests; instead the client MUST establish a separate TCP connection to the servers at alternate IPs and ports as advertised by the CHANGED-ADDRESS attribute in the first binding response and issue the binding requests over that connection. 8.1 Formulating the Capture Request The Capture Requests extends the functionality provided by RESPONSE-ADDRESS in STUN to TCP. Capture requests are sent over TCP to the same address and port as a binding request. The client MUST include a CAPTURE-TIMEOUTS attribute and one or more PACKET-REQUESTS in the message. The RESPONSE-ADDRESS MUST be present if the server is directed to send the first packet and optional otherwise. Since the client may not know the external address allocated by a NAT, it SHOULD first issue a Binding request on the same TCP connection that will carry the capture request to learn its binding. The MAPPED-ADDRESS (or XOR-MAPPED-ADDRESS) returned should be used as the response address. If the PACKET-REQUEST includes a client-defined packet then it must ensure that the destination IP of the packet matches the IP learned through the Binding response. 8.2 Processing Capture Responses A capture response can either be Capture Acknowledgement or a Capture Error Response. If the response is a Capture Error Response, it is processed similar to a Binding Error Responses as specified in [RFC3489]. If the response is a Capture Acknowledgement, the client continues with the test by sending and receiving packets in accordance to the PACKET-REQUEST attributes present in the request. After the expiry of the capture interval in the CAPTURE-TIMEOUTS, the client receives the Capture Response from the server on the TCP conncetion used to send the request. The client MAY issue additional requests within nine minutes. If it does not plan to send additional requests it MUST close the connection. If the client receives any packets at the port assigned for the test after it receives the Capture Response it SHOULD alert the user about Guha Expires June 11, 2005 [Page 15] Internet-Draft STUNT December 2004 a potential attack. Guha Expires June 11, 2005 [Page 16] Internet-Draft STUNT December 2004 9. Use Cases Here we describe how the client can accomplish useful tasks using STUNT. This is at the discretion of the client. 9.1 Binding Behaviour /\ +--------+ / \ N +--------+ | Test 1 |---->/Addr\---->| Test 1 | +--------+ \Same/ +--------+ \? / | \/ | | Y | V V /\ No NAT /\ / \ / \ N /Bind\ +--------+ Y /Bind\ NB=ADP <----\Same/<----| Test 2 |<----\Same/ \? / +--------+ \? / \/ \/ | Y | N | V V /\ NB=SD +--------+ / \ N | Test 3 |---->/Bind\----> NB=AD +--------+ \Same/ \? / \/ | Y | V NB=I To determine the Binding Behaviour for the NATs the client first initiates Test 1. In test 1, the client establishes a TCP connection from a particular socket X, bound to local address p:q, to the server at R:S. It sends a Binding Request over the connections and closes it after receiving the Binding Response. The response attribute XOR-MAPPED-ADDRESS indicates that the NAT assigned the port P:Q for the connection. If the address encoded in XOR-MAPPED-ADDRESS differes from that encoded in MAPPED-ADDRESS then the client infers that the NAT is mangling TCP payloads. If the address P:Q matches the socket X's address p:q then the client is not behind a NAT, but it could still be behind a firewall. If the client is behing a NAT then it repeats Test 1 with another socket X bound to p:q and learns that the NAT assigned the mapping Guha Expires June 11, 2005 [Page 17] Internet-Draft STUNT December 2004 M:N. If M:N is not the same as P:Q then the binding is session dependent. If it is not session dependent, the client initiates Test 2 that is similar to Test 1 but connects to server R:Y, the address resulting from using the first server's IP address and the port in the CHANGED-ADDRESS attribute from the binding response. It learns its binding, call it M:N. If M:N is not the same as P:Q, then the binding changed when the destination port changed; hence the binding behaviour is address and port dependent. If the binding did not change, then the client inititates Test 3, which is like Test 1 with X:Y as the server address. X:Y is alternate IP and port advertised in the CHANGED-ADDRESS attribute. If the new binding, M:N, is different from P:Q then the binding behaviour is address dependent, otherwise it is independent of the destination. 9.2 Binding Timeouts To determine the binding timeout of idle connections the client constructs a Capture Request message. It populates the message with a CAPTURE-TIMEOUTS attribute with the capture timeout set to 1 hour 10 minutes and a delay timeout of 15 seconds. It adds the following PACKET-REQUESTs in order: Wait TCP SYN, Send TCP SYNACK, Wait TCP ACK, Send TCP ACK delay retransmit ACK'ed. It sends the message to the server and upon receiving a Capture Acknowledgement initiates a TCP connection to the addresses advertised in the CHANGED-ADDRESS attribute of the acknowledgement. It also initializes a packet sniffer to capture packets addressed to the port used for the TCP connection. The operating system's stack at the client sends out a TCP SYN, which the server responds to with a SYNACK. The client's stack completes the handshake with an ACK. The server waits 15 seconds before sending an ACK packet. It then waits 30 seconds and sends another ACK packet at 45 seconds past the start of the test. Subsequent ACKs are sent at 1m 45s, 3m 45s, 7m 45s, 15m 45s, 31m 45s, 63m 45s since the start of the test. Depending on the last ACKs received by the client, it can determine the timeout value. For instance if the ACK at 15m 45s was received but the one at 31m 45s was not then the client can deduce that the timer value is more than 8 minutes but less than 16 minutes. Guha Expires June 11, 2005 [Page 18] Internet-Draft STUNT December 2004 9.3 Endpoint Filtering Behaviour /\ +--------+ / \ N +--------+ | Test 1 |---->/Recv\---->| Test 2 | +--------+ \ SYN/ +--------+ \? / | \/ | | Y | V | EF=O /\ /\ / \ Y / \ +--------+ N /Recv\ EF=AD <----/Recv\<----| Test 3 |<----\ SYN/ \ SYN/ +--------+ \? / \? / \/ \/ | Y | N V V EF=I EF=ADP To determine the endpoint filtering behaviour of the NATs the client first initiates Test 1. Test 1 is a Capture Request where the server sends an initial SYN from an alternate IP and port. The RESPONSE-ADDRESS in the message has the address set to the client's binding address learned previously the port is set to a random local port where the client can accept connections. If the SYN is received by the client then the firewall allows unsolicited incoming SYNs to the randomly chosen port. If the SYN is not received, then the client initiates Test 2 where it establishes a TCP connection with a server address; once it is established the server sends a SYN from a different address and port. It does so by using the PACKET-REQUEST sequence: Wait SYN, Send SYNACK, Wait ACK, Send SYN change-ip change-port. If the SYN from the second test is received then the NAT allows any host to contact the client once a mapping is established. Failing this test, the client initiates Test 3 which is identical to Test 2 but requests only "change-port". If the SYN sent from the same address but different port as the established connection is received then the NAT filters packets based on endpoint address, otherwise it filters packets based on endpoint address and port. Guha Expires June 11, 2005 [Page 19] Internet-Draft STUNT December 2004 10. Protocol Details This section presents the detailed encoding of a STUNT message. STUNT messages are encoded using binary fields. All integer fields are carried in network byte order (same as big-endian and most significant byte first). Unless otherwise noted, numeric constants are in decimal (base 10). Constants prepended with '0x' are in hexadecimal (base 16). 10.1 Message Header As with STUN, all STUNT messages consist of a 20 byte header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STUNT Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition to the message types defined for STUN, the type can take on the following values: 0x0003: Capture Request 0x0103: Capture Response 0x0113: Capture Error Response 0x0123: Capture Acknowledge Response The message length is the number of bytes in the message not including the 20 byte header. The transaction ID is a 128 bit identifier. All responses carry the same identifier as the request they correspond to. 10.2 Message Attributes 0 or more attributes may follows the STUNT header. Each attribute is encoded with a 16 bit type, 16 bit length and a value of variable size. Guha Expires June 11, 2005 [Page 20] Internet-Draft STUNT December 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition to the types defined for STUN, the following attribute types are defined: 0x0100: PACKET-REQUEST 0x0101: CAPTURE-TIMEOUTS 0x0102: CAPTURED-PACKET The length field is the length of the value field in bytes. The value field depends on the type of attribute and is defined later in this section. As with STUN, attributes types with value more than 0x7fff are optional, and the request or response can be processed even if the server or client does not understand these attributes. Attributes below 0x7fff are mandatory to understand and a server or client cannot process the message unless it understands all such mandatory attributes. Unexpected attributes in messages, such as CAPTURED-PACKET in a Capture Request, MUST be ignored. Table 1 indicates which attributes are present in which messages. An M indicates that the inclusion of the attribute in the message is mandatory, O means it is optional, C means it's conditional based on some other aspect of the message, and N/A means that the attribute is not applicable to the message type. +-----------------------+----------+----------+----------+----------+ | Attribute | Capture | Capture | Capture | Capture | | | Req. | Ack. | Resp. | Error | | | | | | Resp. | +-----------------------+----------+----------+----------+----------+ | PACKET-REQUEST | M | N/A | N/A | N/A | | | | | | | | CAPTURE-TIMEOUTS | M | N/A | N/A | N/A | | | | | | | | CAPTURED-PACKET | N/A | N/A | C | N/A | | | | | | | | CHANGED-ADDRESS | N/A | M | N/A | N/A | | | | | | | | RESPONSE-ADDRESS | C | N/A | N/A | N/A | | | | | | | Guha Expires June 11, 2005 [Page 21] Internet-Draft STUNT December 2004 | ERROR-CODE | N/A | N/A | N/A | M | | | | | | | | UNKNOWN-ATTRIBUTES | N/A | N/A | N/A | C | | | | | | | | SERVER | N/A | O | O | O | | | | | | | | MESSAGE-INTEGRITY | O | O | O | N/A | +-----------------------+----------+----------+----------+----------+ Table 1 10.2.1 PACKET-REQUEST Packet requests are used to request the server to send a particular type of packet, or wait until a particular packet is received. Among other uses, it allows the client to orchestrate a set of transitions through the TCP state machine. The attribute value is structured as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Type | Code | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol is the IP protocol number. When protocol is 0x06 (TCP) Type is the value of the TCP flag field and Code is 0. When protocol is 0x01 (ICMP), the Type and Code are the ICMP Type and Code fields respectively. The Data value for TCP and ICMP packets is empty. Two additional protocol types are defined: 0x00: This is a packet that can neither be sent nor matched successgully against any received packet. This may be used to request the server to wait until a capture timeout occurs. 0xFF: This is a packet supplied by the client. The Data must contain a valid IP packet padded with zeros for word alignment. The value of the IP total-length field is used to discard the padding at the server. The meaning of the flag in the PACKET-REQUEST attribute is as follows: +-+-+-+-+-+-+-+-+ Guha Expires June 11, 2005 [Page 22] Internet-Draft STUNT December 2004 |0 0 A B C D E 0| +-+-+-+-+-+-+-+-+ A This is the "send or receive" flag. If true, the server should send the specified packet; if false, the server should wait until the specified packet is received. B This is the "retransmit ACK'ed" flag. It is valid only for TCP packets with flag A set. When true, then the server should continually retransmit the packet even after it receives a TCP acknowledgement for it. C This is the "delay" flag. It is valid only for packets with flag A set. When true, the packet is delayed by the duration specified in the CAPTURE-TIMEOUTS attribute. D This is the "change IP" flag. If true, the packet is sent from or awaited at the alternate IP. The alternate IP assigned is communicated to the client through a CHANGED-ADDRESS attribute in the Response Acknowledgement. E This is the "change port" flag. If true, the packet is sent from or awaited at the alternate port. This is valid only for TCP packets. The alternate port assigned is communicated to the client through a CHANGED-ADDRESS attribute in the Response Acknowledgement. 10.2.2 CAPTURE-TIMEOUTS 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capture Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Capture Timeout is the total time in milliseconds that that server should send and receive packets for. Delay timeout is the time in milliseconds that packets marked with flag C above are delayed for. In addition, marked packets are retransmitted at the delay interval scaled by successive powers of 2. Guha Expires June 11, 2005 [Page 23] Internet-Draft STUNT December 2004 10.2.3 CAPTURED-PACKET 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Count | Packet Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type of 0x00 implies the packet was sent by the server and a type of 0x01 implies it was received by the server. Count is the number of times identical copies of the packet were sent or received. Packet time is the time in seconds since the initiation of the capture when the first copy of the packet was sent or received. Packet Data contains the IP packet padded with zeros for word-alignment. Guha Expires June 11, 2005 [Page 24] Internet-Draft STUNT December 2004 11. Security Considerations Many of the attacks on a STUNT server are identical to attacks on a STUN server; these attacks are protected against as mentioned in [RFC3489]. Additional attacks on STUNT attack the Capture mechanism provided by STUNT and may launch denial of service attacks against the STUNT server, or against other hosts. 11.1 Attacks 11.1.1 Approach I: DoSing STUNT An attacker may pose as multiple legitimate clients and send a large number of Capture Requests to server, with possibly a large number of PACKET-REQUESTs and long timeouts intending to use up server resources. 11.1.2 Approach II: DoSing hosts An attacker may send a Capture Request that directs the server to send a large number of packets to the target. 11.1.3 Approach III: DoSing the host NAT An attacker may send a Capture Request that directs the server to send a large number of packets to its own NAT. 11.2 Countermeasures Approach I requires the server deplete its resources. The STUNT server SHOULD deny or abort capture requests with a timeout greater than a configured value. It SHOULD also limit the number of simultaneous Capture Requests being processed by returning Capture Error Responses for new requests. Approach II requires the server to send packets to a random host. To prevent against this the server MUST send packets only to the IP address that originated the request. Since the client can request the binding response over the same connection through which it will send the capture request, the client can adapt its capture request based on the binding perceived by the server before sending it. This allows clients behind traditional NATs to use the capure service even when it may be assigned one of many external IP addresses. Approach III requires the server to send a large number of packets. Since it is not a distributed attack, rate limiting at the server mitigates this attack. To this effect packet retransmissions intervals double after each retransmit, and the server MAY choose a Guha Expires June 11, 2005 [Page 25] Internet-Draft STUNT December 2004 higher initial interval value than requested by the client. In addition, only one outstanding packet may be retransmitted. Retransmission is halted upon receiving RST packets in response. And lastly, the IP address and port of the originator of the request is carried by each packet allowing the attacker to be traced back. The countermeasures to approaches II and III assume that the attacker cannot spoof an entire TCP session with the server without being traced i.e the attacker cannot receive the packets sent to the spoofed address without being traced. Guha Expires June 11, 2005 [Page 26] Internet-Draft STUNT December 2004 12. IANA Considerations STUNT makes use of a TCP option to record the address that caused the packet to be sent. This is used to provide tracability if STUNT is used in an attack. Guha Expires June 11, 2005 [Page 27] Internet-Draft STUNT December 2004 13. IAB Considerations STUNT, like STUN, is an example of a protocol that performs "Unilateral Self Address Fixing" [RFC3424], where clients attempt to determine their address in another realm on the other side of a NAT. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. The specific problems being solved by STUNT in addition to those being solved by STUN is that STUNT provides a means for a client to obtain an address on from a NAT, for the express purpose of receiving incoming TCP traffic from another host, targeted to that address. STUNT inherits the Exit Strategy provided by STUN, and introduces the same Brittleness for TCP applications as introduced by STUN for UDP applications. Further STUNT does not change any of the requirements for a long term solution. 14 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. Author's Address Saikat Guha Cornell University Department of Computer Science 4130 Upson Hall Ithaca, NY 14853 US Phone: +1 607 255 1008 EMail: saikat@cs.cornell.edu URI: http://www.guha.cc Guha Expires June 11, 2005 [Page 28] Internet-Draft STUNT December 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Guha Expires June 11, 2005 [Page 29] Internet-Draft STUNT December 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Guha Expires June 11, 2005 [Page 30]