DCCP Working Group G. Fairhurst Internet-Draft University of Aberdeen Updates: 4340 (if approved) Sept 29, 2008 Intended status: Standards Track Expires: April 2, 2009 DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal draft-ietf-dccp-simul-open-03 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/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 April 2, 2009. Fairhurst Expires April 2, 2009 [Page 1] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Abstract This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g. a DCCP server behind a firewall, or Network Address Port Translators), where establishing necessary middlebox state requires peering endpoints to initiate communication in a near-simultaneous manner. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.2. DCCP NAT Traversal . . . . . . . . . . . . . . . . . . . . 3 1.3. Structure of this Document . . . . . . . . . . . . . . . . 4 2. Procedure for Near-Simultaneous Open . . . . . . . . . . . . . 5 2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 2.2. Protocol Method . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Protocol Method for DCCP-Server Endpoints . . . . . . 5 2.2.2. Protocol Method for DCCP-Client Endpoints . . . . . . 7 2.2.3. Processing by Routers and Middleboxes . . . . . . . . 7 2.2.4. DCCP-Listen Packet Format . . . . . . . . . . . . . . 7 2.3. Examples of Use . . . . . . . . . . . . . . . . . . . . . 10 2.4. Backwards Compatibility with RFC 4340 . . . . . . . . . . 11 3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 12 3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 12 3.1.1. Use of sequence numbers . . . . . . . . . . . . . . . 13 3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 13 3.3. Repetition of DCCP-Listen Packets . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Discussion of Existing NAT Traversal Techniques . . . 21 A.1. NAT traversal Based on a Simultaneous-Request . . . . . . 22 A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Fairhurst Expires April 2, 2009 [Page 2] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 1. Introduction DCCP [RFC4340] is both datagram-based and connection-oriented. As such, it faces the same problems as TCP in sending packets through devices that require all connections to be initiated by a 'trusted' host. This is true of host-based firewalls, the default policy on many firewalls, and (due to port overloading) Network Address Port Translators, NAPTs [ID-Behave-DCCP]. DCCP can not simply reuse traversal solutions that work for UDP. In addition, the original specification of DCCP did not allow a server to perform a simultaneous-open, an inherent characteristic of TCP that greatly simplifies TCP Network Address Translator (NAT) traversal. After discussing the problem space for DCCP, this document specifies an update to the DCCP state machine to offer native DCCP support for middlebox traversal. This reduces dependence on external aids such as data relay servers [TURN] by explicitly supporting a widely used principle known as 'hole punching'. The method requires only a minor change to the standard DCCP operational procedure. The use of a dedicated DCCP packet type ties usage to a specific condition, ensuring the method is inter-operable with hosts that do not implement this update, or disable it. (e.g. a DCCP server that employs a security policy that does not wish to disclose the port on which it is listening can refrain from generating DCCP-Listen packets, without impacting subsequent DCCP state transitions.) 1.1. Scope of this Document This method is useful in scenarios when a DCCP server is located behind a middlebox. It is relevant to both client/server and peer- to-peer applications, such as VoIP, file sharing, or online gaming and assists connections that utilise prior out-of-band signaling (e.g. via a well-known rendezvous server ([RFC3261], [H.323])) to notify both endpoints of the connection parameters ([RFC3235], [NAT-APP]). 1.2. DCCP NAT Traversal The behavioural requirements for NAT devices supporting DCCP are described in [ID-Behave-DCCP]. A "traditional NAT" [RFC3022], that directly maps an IP address to a different IP address does not require the simultaneous open method described in this document. The method is required when the DCCP server is positioned behind one or more NAT devices in the path (i.e. hierarchies of nested NAT devices are possible). This document refers to DCCP hosts located Fairhurst Expires April 2, 2009 [Page 3] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 behind one or more NAT devices as having "private" addresses, and to DCCP hosts located in the global address realm as having "public" addresses. We consider DCCP NAT traversal for the following scenarios: 1. Private client connects to public server. 2. Public server connects to private client. 3. Private client connects to private server. A defining characteristic of traditional NAT devices [RFC3022] is that private hosts can connect to external hosts, but not vice versa. Hence the case (1) is possible using the protocol defined in [RFC4340]. A pre-configured, static NAT address map would allow outside hosts to connect to the private network in cases (2) and (3). This document describes a method to support cases (2) and (3) that require NAT traversal techniques. A DCCP implementation conforming to [RFC4340] and a NAT device conforming to [ID-Behave-DCCP] would require a DCCP relay server to perform NAT traversal for cases (2) and (3). The document updates RFC 4340 to enable DCCP NAT traversal without the aid of DCCP relay servers. This method requires the DCCP server to discover the IP address and the DCCP port that correspond to the DCCP Client. Such signalling may be performed out-of-band (e.g. using SDP [RFC4566]). 1.3. Structure of this Document For background information on existing NAT traversal techniques, please consult Appendix A. The normative specification of the update is presented in Section 2. An informative discussion of underlying design decisions then follows, in Section 3. Security considerations are provided in Section 4 and IANA considerations in the concluding Section 5. Fairhurst Expires April 2, 2009 [Page 4] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 2. Procedure for Near-Simultaneous Open This section is normative and specifies the simultaneous-open technique for DCCP. It updates the connection-establishment procedures of [RFC4340]. 2.1. Conventions and Terminology The document uses the terms and definitions provided in [RFC4340]. Familiarity with this specification is assumed. In particular, the following convention from ([RFC4340], 3.2) is used: "Each DCCP connection runs between two hosts, which we often name DCCP A and DCCP B. Each connection is actively initiated by one of the hosts, which we call the client; the other, initially passive host is called the server." 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]. 2.2. Protocol Method The term "session" is used as defined in ([RFC2663], 2.3): DCCP sessions are uniquely identified by the tuple of . DCCP, in addition, introduces service codes, which can be used to identify different services available via the same port [Fai08]. 2.2.1. Protocol Method for DCCP-Server Endpoints This document updates [RFC4340] for the case of a fully specified DCCP server endpoint. The update modifies the way the server performs a passive-open. Prior to connection setup, it is common for DCCP server endpoints to not be fully specified: before the connection is established, a server usually sets the target IP-address:port to wildcard values (i.e. leaves these unspecified); the endpoint only becomes fully specified after performing the handshake with an incoming connection. For such cases, this document does not update [RFC4340], i.e. the server adheres to the existing state transitions in the left half of Figure 1 (CLOSED => LISTEN => RESPOND). A fully specified DCCP server endpoint permits exactly one client, identified by target IP-address:port plus a single service code, to set up the connection. Such a server SHOULD perform the actions and Fairhurst Expires April 2, 2009 [Page 5] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 state transitions shown in the right half of Figure 1, and specified below. unspecified remote +--------+ fully specified remote +---------------------| CLOSED |---------------------+ | +--------+ send DCCP-Listen | | | | | v v +--------+ timeout +---------+ | LISTEN |<------------------------------+-----------| INVITED | +--------+ more than 2 retransmissions | +---------+ | | 1st / 2nd ^ | | | retransm. | | | +-------------+ | | resend Listen | | | | | | receive Request +---------+ receive Request | +------------------->| RESPOND |<--------------------+ send Response +---------+ send Response Figure 1: Updated state transition diagram for DCCP-Listen A fully-specified server endpoint performs a passive-open from the CLOSED state by inviting the remote client to connect. This is performed by sending a single DCCP-Listen packet to the specified remote IP-adress:port, using the format specified in Section 2.2.4. The server then transitions to the INVITED state. The INVITED state is, like LISTEN, a passive state, characterised by waiting in the absence of an established connection. If the server endpoint in state INVITED receives a DCCP-Request, it transitions to RESPOND, where further processing resumes as specified in [RFC4340]. The server SHOULD repeat sending a DCCP-Listen packet while in the INVITED state, at a 200 millisecond interval and up to at most 2 repetitions (Section 3 discusses this choice of timer interval). If the server is still in the INVITED state after a further period of 200ms following transmission of the second DCCP-Listen packet, it SHOULD progress to LISTEN, and resume processing as specified in [RFC4340]. Retransmission may be implemented using a retransmission timer when in the INVITED state. The timer is restarted with an interval of 200ms after sending each DCCP-Listen packet. It is cancelled when the server leaves the INVITED state. The first and second expiry of Fairhurst Expires April 2, 2009 [Page 6] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 this timer trigger transmission of the DCCP-Listen Packet. A third expiry of the timer results in the server leaving the INVITED state to progress to the LISTEN state. Fully-specified server endpoints SHOULD treat ICMP error messages received in response to a DCCP-Listen packet as "soft errors" that do not cause a state transition. Reception of an ICMP error message as a result of sending a DCCP-Listen packet does not necessarily indicate a failure of the following connection request, and therefore should not result in a server state change. This reaction to soft errors exploits the valuable feature of the Internet that for many network failures, the network can be dynamically reconstructed without any disruption of the endpoints. Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A DCCP Server in state LISTEN MAY generate a DCCP-Reset packet (Code 7, "Connection Refused") in response to a received DCCP-Listen packet. This DCCP-Reset packet is an indication that two servers are simultaneously awaiting connections on the same port. Further details on the design rationale are discussed in Section 3. 2.2.2. Protocol Method for DCCP-Client Endpoints This document updates [RFC4340], by adding the following rule for the reception of DCCP-Listen packets by clients: A client in any state MUST silently discard any received DCCP-Listen packet. 2.2.3. Processing by Routers and Middleboxes DCCP-Listen packets do not require special treatment and should thus be forwarded end-to-end across Internet paths, by routers and middleboxes alike. Middleboxes may utilise the connection information (address, port, service code) to establish local forwarding state. The DCCP-Listen packet carries the necessary information to uniquely identify a DCCP session in combination with the source and destination addresses (found in the enclosing IP-header), including the DCCP Service Code value. The processing of the DCCP-Listen packet by NAT devices is specified in [ID-Behave-DCCP]. 2.2.4. DCCP-Listen Packet Format This document adds a new DCCP packet type, DCCP-Listen, whose format is shown below. Fairhurst Expires April 2, 2009 [Page 7] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Dest Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Offset | CCVal | CsCov | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Type |X| Reserved | Sequence Number High Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Low Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of a DCCP-Listen Packet o The Source Port is the port on which the server is listening for a connection from the IP address that appears as the destination IP address in the packet. o The default value of 0 for the Allow Short Seqno feature MUST be used, X MUST be set to 1, and DCCP-Listen packets with X=0 MUST be ignored. Since the use of short sequence numbers ([RFC4340], 5.1) depends on the value of the Allow Short Seqno feature ([RFC4340], 7.6.1) and since DCCP-Listen packets are sent before a connection is established, there is no way of negotiating the use of short sequence numbers. o The sequence number of a DCCP-Listen packet is not related to the DCCP sequence number for normal DCCP messages Section 3. Thus, for DCCP-Listen packets: * DCCP servers should set both Sequence Number fields to 0. * DCCP clients MUST ignore the value of the Sequence Number fields. * Middleboxes MUST NOT interpret sequence numbers on DCCP-Listen packets. o The Service Code field contains the service code value for which the server is listening for a connections([RFC4340], 8.1.2). This value MUST correspond to a service code that the server is actually offering for connections identified by the same source IP address and the same Source Port as that of the DCCP-Listen packet. Since the server may use multiple service codes, the specific value of the Service Code field needs to be communicated out-of-band, from client to server, prior to sending the DCCP- Fairhurst Expires April 2, 2009 [Page 8] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Listen packet, e.g. described using the Session Description Protocol, SDP [RFC4566]. o At the time of writing, there are no known uses of the header option ([RFC4340] , sec. 5.8) with a DCCP-Listen packet. Clients MUST ignore all options in received DCCP-Listen packets. Therefore, option values can not be negotiated using a DCCP-Listen packet. o There is no payload data. Since DCCP-Listen packets are issued before an actual connection is established, they MUST NOT carry payload data. Endpoints MUST ignore any payload data encountered in DCCP-Listen packets. In addition, DCCP clients MUST ignore the value of the Sequence Number fields; and middleboxes MUST NOT interpret the sequence numbers of DCCP-Listen packets. o The following protocol fields are required to have specific values: * Data Offset MUST be zero (there is no payload). * CCVal MUST be zero (a connection has not been established). * CsCov MUST be zero (there is no payload). * Type has the value 10 (assigned by IANA to denote a DCCP-Listen packet). * X MUST be 1 (The Generic header must be used). The remaining fields, including the "Res" and "Reserved" fields are specified by [RFC4340] and its successors. The interpretation of these fields is not modified by this document. Fairhurst Expires April 2, 2009 [Page 9] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Note to the RFC Editor: This value assigned to the DCCP-Listen packet needs to be confirmed by IANA when this document is published. Please then remove this note. ==> End of note to the RFC Editor. <== 2.3. Examples of Use In the examples below, DCCP A is the client and DCCP B is the server. A middlebox device (NAT/Firewall), NA is placed before DCCP A, and another middlebox, NB, is placed before DCCP B. Both NA and NB use a policy that permits DCCP packets to traverse the device for outgoing links, but only permit incoming DCCP packets when a previous packet has been sent out for the same connection. In the figure below, DCCP A and DCCP B decide to communicate using an out-of-band mechanism, whereupon the client and server are started. DCCP A initiates a connection by sending a DCCP-Request. DCCP B actively indicates its listening state by sending a DCCP-Listen message. This fulfils the requirement of punching a hole in NB, so that DCCP A can retransmit the DCCP-Request and connect through it. DCCP A DCCP B ------ NA NB ------ +------------------+ +-+ +-+ +-----------------+ |(1) Initiation | | | | | | | |DCCP-Request --> +--+-+---X| | | | | |<-+-+----+-+--+<-- DCCP-Listen | | | | | | | | | |DCCP-Request --> +--+-+----+-+->| | | |<-+-+----+-+--+<-- DCCP-Response| |DCCP-Ack --> +--+-+----+-+->| | | | | | | | | | |(2) Data transfer | | | | | | | |DCCP-Data --> +--+-+----+-+->| | +------------------+ +-+ +-+ +-----------------+ Figure 3: Event sequence when the client is started before the server The diagram below shows the reverse sequence of events, where the server sends the DCCP-Listen before the client sends a DCCP-Request: Fairhurst Expires April 2, 2009 [Page 10] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 DCCP A DCCP B ------ NA NB ------ +------------------+ +-+ +-+ +-----------------+ |(1) Initiation | | | | | | | | | | |X---+-+--+<-- DCCP-Listen | |DCCP-Request --> +--+-+----+-+->| | | | <+-+----+-+--+<-- DCCP-Response| |DCCP-Ack --> +--+-+----+-+> | | | | | | | | | | |(2) Data transfer | | | | | | | |DCCP-Data --> +--+-+----+-+> | | +------------------+ +-+ +-+ +-----------------+ Figure 4: Event sequence when the server is started before the client 2.4. Backwards Compatibility with RFC 4340 No changes are required if a DCCP Client conforming to this document communicates with a DCCP Server conforming to [RFC4340]. If a client implements only [RFC4340], an incoming DCCP-Listen packet would be ignored due to step 1 in [RFC4340], 8.1, which at the same time also conforms to the behaviour specified by this document. This document further does not modify communication for any DCCP server that implements a passive-open without fully binding the addresses, ports and service codes to be used. The authors therefore do not expect practical deployment problems with existing conformant DCCP implementations. Fairhurst Expires April 2, 2009 [Page 11] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 3. Discussion of Design Decisions 3.1. Rationale for a New Packet Type This is an informative section that reviews the rationale for the design of this technique. The DCCP-Listen packet specified in Section 2.2.4 has the same format as the DCCP-Request packet ([RFC4340], 5.1), the only difference is in the value of the Type field. The usage, however, differs. The DCCP-Listen packet serves as advisory message, not as part of the actual connection setup: sequence numbers have no meaning, and no payload may be present. A DCCP-Request packet could in theory also have been used for the same purpose. The following arguments were against this: The first problem was that of semantic overloading: the DCCP-Request defined in [RFC4340] serves a well-defined purpose, being the initial packet of the 3-way handshake. Additional use in the manner of a DCCP-Listen packet would have required DCCP processors to have had two different processing paths: one where a DCCP-Request was interpreted as part of the initial handshake, and another where the same packet was interpreted as an indicator message. This would complicate packet processing in hosts and in particular stateful middleboxes (which may have restricted computational resources). The second problem is that a client receiving a DCCP-Request from a server could generate a DCCP-Reset packet if it had not yet entered the REQUEST state (step 7 in [RFC4340], 8.5). The method specified in this document lets client endpoints ignore DCCP-Listen packets. Adding a similar rule for the DCCP-Request packet would have been cumbersome: clients would not have been able to distinguish between a Request meant to be an indicator message and a genuinely erratic connection initiation. The third problem is similar, and refers to a client receiving the indication after having itself sent a (connection-initiation) Request. Step 7 in section 8.5 of [RFC4340] requires the client to reply to an "indicator message" Request from the server with a DCCP- Sync. Since sequence numbers are ignored for this type of message, additional and complex processing would become necessary: either to ask the client not to respond to a DCCP-Request when the request is of type "indicator message"; or ask middleboxes and servers to ignore Sync packets generated in response to "indicator message" DCCP- Requests. Furthermore, since no initial sequence numbers have been negotiated at this stage, sending a DCCP-SyncAck would not be meaningful. The use of a separate packet type therefore allows simpler and Fairhurst Expires April 2, 2009 [Page 12] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 clearer processing. 3.1.1. Use of sequence numbers Although the DCCP-Listen Sequence Number fields are ignored, they have been retained in the DCCP-Listen packet header to reuse the generic header format from section 5.1 of [RFC4340]. DCCP assigns a random initial value to the sequence number when a DCCP connection is established [RFC4340]. Howeve, a sender is required to set this value to zero for a DCCP-Listen packet. Both clients and middleboxes are also required to ignore this value. The rationale for ignoring the Sequence Number fields on DCCP-Listen packets is that at the time the DCCP-Listen is exchanged, the endpoints have not yet entered connection setup: the DCCP-Listen packet is sent while the server is still in the passive-open (INVITED) state, i.e. it has not yet allocated state, other than binding to the client's IP-address:port and service code. 3.2. Generation of Listen Packets Since DCCP-Listen packets solve a particular problem (NAT and/or firewall traversal), the generation of DCCP-Listen packets on passive sockets is tied to a condition (binding to an a priori known remote address and service code) to ensure this does not interfere with the general case of "normal" DCCP connections (where client addresses are generally not known in advance). In the TCP world, the analogue is a transition from LISTEN to SYN_SENT by virtue of sending data: "A fully specified passive call can be made active by the subsequent execution of a SEND" ([RFC0793], 3.8). Unlike TCP, this update does not perform a role-change from passive to active. Like TCP, DCCP-Listen packets are only sent by a DCCP-server when the endpoint is fully specified (Section 2.2). 3.3. Repetition of DCCP-Listen Packets Repetition is a necessary requirement, to increase robustness and the chance of successful connection establishment when a DCCP-Listen packet is lost due to congestion, link loss, or some other reason. The decision to recommend a maximum number of 3 timeouts (2 repeated copies of the original DCCP-Listen packet) results from the following considerations: The repeated copies need to be spaced sufficiently far apart in time to avoid suffering from correlated loss. The interval of 200 ms was chosen to accommodate a wide range of wireless and wired network paths. Fairhurst Expires April 2, 2009 [Page 13] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Another constraint is given by the retransmission interval for the DCCP-Request ([RFC4340], 8.1.1). To establish state, intermediate systems need to receive a (retransmitted) DCCP-Listen packet before the DCCP-Request times out (1 second). With three timeouts, each spaced 200 milliseconds apart, the overall time is still below one second. On the other hand, the sum of 600 milliseconds is sufficiently large to provide for longer one-way delays, such as e.g. found on some wireless links. The rationale behind transitioning to the LISTEN state after two retransmissions is that other problems, independent of establishing middlebox state, may occur (such as delay or loss of the initial DCCP-Request). Any late or retransmitted DCCP-Request packets will then still reach the server allowiing connection establishment to successfully complete. Fairhurst Expires April 2, 2009 [Page 14] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 4. Security Considerations The method specified in this document exposes the state of a DCCP server that is waiting to accept a connection from a known client. Establishing this state requires prior out-of-band signalling between the client and server (e.g. SDP [RFC4566]) information communicated via the Session Initiation Protocol [RFC3261]). The method generates a packet addressed to the expected client. This increases the vulnerability of a DCCP server, by revealing which ports are in a passive listening state (the information is not encrypted and therefore could be seen on the path to the client through the network). Servers that do not wish to disclose this information MAY refrain from generating DCCP-Listen packets, without impacting subsequent DCCP state transitions. We do not believe these changes significantly increase the complexity or vulnerability of a DCCP implementation that conforms to [RFC4340]. Fairhurst Expires April 2, 2009 [Page 15] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 5. IANA Considerations This document requires IANA action by allocation of a new Packet Type from the IANA DCCP Packet Types Registry. The decimal value 10 has been assigned to a "DCCP-Listen" packet. The Registry entry references this document. Fairhurst Expires April 2, 2009 [Page 16] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Note to the RFC Editor: This value must be confirmed by IANA in the registry when this document is published, please then remove this note. Fairhurst Expires April 2, 2009 [Page 17] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Acknowledgement This update was originally co-authored by Dr Gerrit Renker, University of Aberdeen, and the present author acknowledges his insight in design of the protocol mechanism and in careful review of the early revisions of the document text. Dan Wing assisted on issues relating to the use of NAT and NAPT. Fairhurst Expires April 2, 2009 [Page 18] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 6.2. Informative References [Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem", Carnegie Mellon University/ISRI Technical Report CMU-ISRI-05-104, January 2005. [FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", Proceedings of USENIX-05, pages 179-192, 2005. [Fai08] Fairhurst, G., "The DCCP Service Code", Work In Progress, draft-ietf-dccp-serv-codes-07, June 2008. [GBF+07] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", Work In Progress, draft-ietf-behave-tcp-07, April 2007. [GF05] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC-05), pages 199- 211, 2005. [GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based approach to UDP and TCP connectivity", Proceedings of SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004. [H.323] ITU-T, "Packet-based Multimedia Communications Systems", Recommendation H.323, July 2003. [ID-Behave-DCCP] "Network Address Translation (NAT) Behavioral Requirements for DCCP", Work in Progress draft-ietf-behave-dccp-02.txt, 2008. [NAT-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work In Progress, draft-ford-behave-app-05, Fairhurst Expires April 2, 2009 [Page 19] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 March 2007. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [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. [RFC4566] "SDP: Session Description Protocol", July 2006. [Ros08] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work In Progress, draft-ietf-mmusic-ice-tcp-07, February 2008. [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work In Progress, draft-ietf-behave-turn-09, February 2008. Fairhurst Expires April 2, 2009 [Page 20] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Appendix A. Discussion of Existing NAT Traversal Techniques This appendix provides a brief review of existing techniques to establish connectivity across NAT devices, with the aim of providing background information. This first considers TCP NAT traversal based on simultaneous-open, and then discuss a second technique based on role reversal. Further information can be found in [GTF04] and [GF05]. A central idea shared by these techniques is to make peer-to-peer sessions look like "outbound" sessions on each NAT device. Often a rendezvous server, located in the public address realm, is used to enable clients to discover their NAT topology and the addresses of peers. The term 'hole punching' was coined in [FSK05] and refers to creating soft state in a traditional NAT device, by initiating an outbound connection. A well-behaved NAT can subsequently exploit this to allow a reverse connection back to the host in the private address realm. UDP and TCP hole punching use nearly the same technique. The adaptation of the basic UDP hole punching principle to TCP NAT traversal was introduced in section 4 of [FSK05] and relies on the simultaneous-open feature of TCP [RFC0793]. A further difference between UDP and TCP lies in the way the clients perform connectivity checks, after obtaining suitable address pairs for connection establishment. Whereas in UDP a single socket is sufficient, TCP clients require several sockets for the same address / port tuple: o a passive socket to listen for connectivity tests from peers and o multiple active connections from the same address to test reachability of other peers. The SYN sent out by client A to its peer B creates soft state in A's NAT. At the same time, B tries to connect to A: o if the SYN from B has left B's NAT before the arrival of A's SYN, both endpoints perform simultaneous-open (4-way handshake of SYN/ SYNACK); o otherwise A's SYN may not enter B's NAT, which leads to B performing a normal open (SYN_SENT => ESTABLISHED) and A performing a simultaneous-open (SYN_SENT => SYN_RCVD => ESTABLISHED). In the latter case, it is necessary that the NAT does not interfere Fairhurst Expires April 2, 2009 [Page 21] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 with a RST segment (REQ-4 in [GBF+07]). The simultaneous-open solution is convenient due to its simplicity, and is thus a preferred mode of operation in the TCP extension for ICE ([Ros08], sec. 2). A.1. NAT traversal Based on a Simultaneous-Request Among the various TCP NAT traversal approaches, the one using simultaneous-open suggests itself as a candidate for DCCP due to its simplicity [GF05], [NAT-APP]. A characteristic of TCP simultaneous-open is that this erases the clear distinction between client and server: both sides enter through active (SYN_SENT) as well as passive (SYN_RCVD) states. . This characteristic conflicts with the DCCP design decision to provide a clear separation between client and server functions ([RFC4340], 4.6). Furthermore, several mechanisms implicitly rely on clearly- defined client/server roles: o Feature Negotiation: with few exceptions, almost all of DCCP's negotiable features use the "server-priority" reconciliation rule ([RFC4340], 6.3.1), whereby peers exchange their preference lists of feature values, and the server decides the outcome. o Closing States: only servers may generate DCCP-CloseReq packets (asking the peer to hold timewait state), while clients are only permitted to send DCCP-Close or DCCP-Reset packets to terminate a connection ([RFC4340], 8.3). o Service Codes [Fai08]: servers may be associated with multiple service codes, while clients must be associated with exactly one ([RFC4340], 8.1.2). o Init Cookies: may only be used by the server and on DCCP-Response packets ([RFC4340], 8.1.4). The latter two points are not obstacles per se, but would have hindered the transition from a passive to an active socket. In DCCP, a DCCP-Request is only generated by a client. The assumption that "all DCCP hosts may be clients", was dismissed, since it would require undersirable changes to the state machine and would limit application programming. As a consequence, the retro-fitting a TCP- style simultaneous-open into DCCP to allow simulatenous exchange of DCCP-Connect packets was not recommended. A.2. Role Reversal Another simple TCP NAT traversal schemes uses role traversal ([Epp05] and [GTF04]), where a peer first opens an active connection for the Fairhurst Expires April 2, 2009 [Page 22] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 single purpose of punching a hole in the firewall; and then reverts to a listening socket, accepting connections arriving via the new path. This solution would have had several disadvantages if used with DCCP. First, a DCCP server would be required to change its role to temporarily become a 'client'. This would have required modification to the state machine, in particular the trearment of service codes and perhaps Init Cookies. Further, the method must follow feature negotiation, since a host's choice of initial options can rely on its role (i.e. if an endpoint knows it is the server, it can make a priori assumptions about the preference lists of features it is negotiating with the client, thereby enforcing a particular policy). Finally, the server would have needed additional processing to ensure that the connection arriving at the listening socket matches the previously opened active connection. This approach was therefore not recommend for DCCP. Fairhurst Expires April 2, 2009 [Page 23] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Appendix B. Change Log Revision 00 was based on a previous individual submission draft-fairhurst-dccp-behave-update-01 by the same authors. Revision 01: o introduced many format changes to improve readability o migrated background information into the Appendix o added Section 1.3 to summarize the document structure o updated introductory paragraph of Section 2 to account for new structure o added captions to all figures o updated the specification in Section 2 to (i) permit options on DCCP-Listen packets; (ii) explain why the presence of payload data is not useful; (iii) clarify that middleboxes must not interpret sequence numbers on DCCP-Listen packets o clarified that the default value of the Allow Short Seqno feature is to be used o added references to the service code draft [Fai08] o clarified the processing of DCCP-Listen packets by server endpoints o corrected the reaction of a client implementing [RFC4340] only - DCCP-Listen packets are treated as unknown and hence do not generate a DCCP-Reset o swapped order of IANA / Security-Considerations sections o added a note in the Security Considerations section that servers may refrain from generating DCCP-Listen packets Revision 02: o minor edits following WG feedback at IETF meeting o updated to reflect ID.Behave-DCCP o update to reflect comments from Colin Perkins Fairhurst Expires April 2, 2009 [Page 24] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 o added a tentative IANA code point (as suggested at IETF-73) o Edits following editorial corrections and suggestions from Tom Phelan o Edits following comments from Dan Wing on role of NAT, retransmision, and other issues. o Revised authors list o Reworded abstract, reworded appendices to clarify what was not done o Checked spelling o Although this version includes significant changes to format and text it does not seek to modify the intended procedure for a server. Fairhurst Expires April 2, 2009 [Page 25] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Note to the RFC Editor: Please remove this Change Log when done with the document.A Fairhurst Expires April 2, 2009 [Page 26] Internet-Draft DCCP Simultaneous-Open Technique Sept 2008 Author's Address Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Fairhurst Expires April 2, 2009 [Page 27] Internet-Draft DCCP Simultaneous-Open Technique Sept 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 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. Fairhurst Expires April 2, 2009 [Page 28]