idnits 2.17.1 draft-ietf-dccp-simul-open-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 879. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4340, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4340, updated by this document, for RFC5378 checks: 2002-10-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2008) is 5790 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-dccp-serv-codes-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-06 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DCCP Working Group G. Fairhurst 3 Internet-Draft G. Renker 4 Updates: 4340 (if approved) University of Aberdeen 5 Intended status: Standards Track June 17, 2008 6 Expires: December 19, 2008 8 DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal 9 draft-ietf-dccp-simul-open-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 19, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies an update to the Datagram Congestion Control 43 Protocol (DCCP), a connection-oriented and datagram-based transport 44 protocol. 46 The update assists DCCP applications which need to communicate 47 through one or more middleboxes (e.g. Network Address Translators or 48 firewalls), where establishing necessary middlebox state requires 49 peering endpoints to initiate communication in a near-simultaneous 50 manner. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 56 1.2. Scope of the Problem to be Tackled . . . . . . . . . . . . 4 57 1.3. Structure of this Document . . . . . . . . . . . . . . . . 4 58 2. Procedure for Near-Simultaneous Open . . . . . . . . . . . . . 5 59 2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 60 2.2. DCCP-Listen Packet Format . . . . . . . . . . . . . . . . 5 61 2.3. Protocol Method . . . . . . . . . . . . . . . . . . . . . 7 62 2.3.1. Protocol Method for DCCP-Server Endpoints . . . . . . 7 63 2.3.2. Protocol Method for DCCP-Client Endpoints . . . . . . 9 64 2.3.3. Processing by Routers and Middleboxes . . . . . . . . 9 65 2.4. Examples of Use . . . . . . . . . . . . . . . . . . . . . 9 66 2.5. Backwards Compatibility with RFC 4340 . . . . . . . . . . 10 67 3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 12 68 3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 12 69 3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 13 70 3.3. Repetition of Listen Packets . . . . . . . . . . . . . . . 13 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Appendix A. Discussion of Existing NAT Traversal Techniques . . . 20 77 A.1. NAT traversal Based on Simultaneous-Open . . . . . . . . . 21 78 A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 21 79 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 81 Intellectual Property and Copyright Statements . . . . . . . . . . 26 83 1. Introduction 85 UDP Network Address Translator (NAT) traversal is well understood and 86 widely implemented. NAT traversal for connection-oriented protocols 87 (e.g. TCP) uses similar principles, but in some cases requires more 88 complex and expensive solutions, such as data relay servers [TURN]. 90 DCCP [RFC4340] is both datagram-based and connection-oriented. As 91 such it faces faces the same problems as TCP NAT traversal, without 92 the ability to simply reuse traversal solutions which work for UDP. 93 An additional issue is that DCCP can not perform a simultaneous-open, 94 a TCP-inherent characteristic which greatly simplifies NAT traversal. 96 After discussing the problem space for DCCP, this document specifies 97 a DCCP extension to facilitate DCCP NAT traversal, by explicitly 98 supporting a widely used principle known as 'hole punching'. This 99 extension produces the same outward effect as an simultaneous-open, 100 but without internal changes to the standard DCCP operational 101 procedure. The extension uses a dedicated indicator message, whose 102 usage is tied to a specific condition, can thus be turned off, and is 103 inter-operable with non-extended hosts. 105 The object of this extension is DCCP native support for middlebox 106 traversal, reducing dependence on external aids such as data relay 107 servers. 109 1.1. Scope of this Document 111 This document is specifically targeted at NAT traversal. However, 112 due to the similarity of involved principles, the technique and 113 presented extension of DCCP may also be of similar use to the 114 traversal of other types of middlebox, such as firewalls. 116 The technique described by this document applies to scenarios where 117 one or both DCCP peers are located behind a middlebox. 119 The proposed extension is relevant to both client/server and peer-to- 120 peer applications, such as VoIP, file sharing, or online gaming. It 121 assists connections that utilise prior out-of-band signaling (e.g. 122 via a well-known rendezvous server ([RFC3261], [H.323])) to notify 123 both endpoints of the connection parameters ([RFC3235], [NAT-APP]). 125 For the scope of this document we assume traditional (outbound) types 126 of NAT as defined in [RFC2663] and further discussed in [RFC3022]. 127 We understand NAT traversal as involving one or more NAT devices of 128 this type in the path (i.e. hierarchies of nested NAT devices are 129 possible). It is assumed that all NATs in the path between endpoints 130 are BEHAVE-compliant [NAT-APP]. 132 This document does not discuss specific behavioural requirements of 133 devices to support DCCP NAT traversal. These may be described by a 134 separate document. We further limit our assumptions regarding NAT 135 devices to a minimum of DCCP protocol support, in that layer-4 136 checksums are updated to account for changes in the pseudo-header. 138 1.2. Scope of the Problem to be Tackled 140 This document refers to DCCP hosts located behind one or more NAT 141 devices as having "private" addresses, and to DCCP hosts located in 142 the global address realm as having "public" addresses. 144 We consider DCCP NAT traversal for the following scenarios: 146 1. Private client connects to public server. 148 2. Public server connects to private client. 150 3. Private client connects to private server. 152 A defining characteristic of traditional NAT devices [RFC3022] is 153 that private hosts can connect to external hosts, but not vice versa. 154 Hence the case (1) is always possible, whereas cases (2) and (3) 155 require NAT traversal techniques. 157 In this document we do not consider use of pre-configured, static NAT 158 address maps, which would also allow outside hosts to connect to the 159 private network in cases (2) and (3). 161 A DCCP implementation conforming to [RFC4340] requires a relay server 162 to perform NAT traversal. The extension specified by this document 163 enables DCCP NAT traversal without the aid of relay servers. 165 1.3. Structure of this Document 167 For background information on existing NAT traversal techniques, 168 please consult Appendix A. 170 The normative specification of the extension is presented in the next 171 section. An informative discussion of underlying design decisions 172 then follows in Section 3. Security considerations are provided in 173 Section 4 and IANA considerations in the concluding Section 5. 175 2. Procedure for Near-Simultaneous Open 177 This section is normative and specifies the simultaneous-open 178 technique for DCCP. 180 The presented extension updates the connection-establishment 181 procedures of [RFC4340]. 183 2.1. Conventions and Terminology 185 The document uses the terms and definitions provided in [RFC4340]. 186 Familiarity with this specification is assumed. In particular, the 187 following convention from ([RFC4340], 3.2) is used: 189 "Each DCCP connection runs between two hosts, which we often name 190 DCCP A and DCCP B. Each connection is actively initiated by one of 191 the hosts, which we call the client; the other, initially passive 192 host is called the server." 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 2.2. DCCP-Listen Packet Format 200 This document updates DCCP by adding a new packet type, DCCP-Listen, 201 whose format is shown below. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Source Port | Dest Port | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Data Offset | CCVal | CsCov | Checksum | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Res | Type |X| Reserved | Sequence Number High Bits | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Sequence Number Low Bits | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Service Code | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 1: DCCP-Listen Packet Format 219 DCCP-Listen Packets MAY include header options ([RFC4340], sec. 5.8). 220 Note however that, at the time of this writing, there are no known 221 uses of header options for the DCCP-Listen packet. 223 Since DCCP-Listen packets are issued before an actual connection is 224 established, they SHALL NOT carry payload data, and endpoints MUST 225 ignore any payload data encountered on DCCP-Listen packets. 227 Servers SHOULD set both Sequence Number fields to 0; clients MUST 228 ignore the value of the Sequence Number fields; and middleboxes MUST 229 NOT interpret sequence numbers on DCCP-Listen packets. 231 Furthermore, the following protocol fields MUST all be set to zero: 233 CCVal (a connection has not been established), 235 CsCov (there is no payload). 237 The "Res" and "Reserved" fields are specified by [RFC4340] and its 238 successors. The interpretation of these fields is not modified by 239 this document. 241 The Type field has the value XX-IANA-assigned-XX, which indicates 242 that this is a DCCP-Listen packet. 244 Note to the RFC Editor: 246 Please replace XX-IANA-assigned-XX in the above paragraph with the 247 value assigned in the registry and remove this note. 249 ==> End of note to the RFC Editor. <== 251 Since the use of short sequence numbers ([RFC4340], 5.1) depends on 252 the value of the Allow Short Seqno feature ([RFC4340], 7.6.1) and 253 since DCCP-Listen packets are sent before a connection is 254 established, there is no way of negotiating the use of short sequence 255 numbers. Consequently, the default value of 0 for the Allow Short 256 Seqno feature ([RFC4340], 6.4) SHALL be used, X MUST be set to 1, and 257 DCCP-Listen packets with X=0 MUST be ignored. 259 The Service Code field contains the service code ([RFC4340], 8.1.2) 260 that the client peer wants to use for this connection. This value 261 MUST correspond to a service code that the server is actually 262 offering for connections identified by the same source IP address and 263 the same Source Port as that of the DCCP-Listen packet. Since the 264 server may use multiple service codes, the value of the Service Code 265 field needs to be communicated out-of-band, from client to server, 266 prior to sending the DCCP-Listen packet (e.g. using SDP). 268 2.3. Protocol Method 270 We use the term "session" as defined in ([RFC2663], 2.3): DCCP 271 sessions are uniquely identified by the tuple of . 274 DCCP, in addition, introduces service codes which can be used to 275 identify different services available via the same port [Fai08]. 277 We call the five-tuple a fully specified DCCP connection, 279 and refer to an endpoint that has been assigned all five parameters 280 as a "fully specified endpoint". DCCP-Listen packets are only sent 281 for the specific case of fully specified DCCP-server endpoints. 283 2.3.1. Protocol Method for DCCP-Server Endpoints 285 This document updates [RFC4340] for the case of fully specified DCCP- 286 server endpoints. The update is normative and applies to the way the 287 server performs passive-open. 289 Prior to connection setup, it is common for DCCP-server endpoints to 290 not be fully specified: before the connection is established, a 291 server usually sets the target IP-address:port to wildcard values 292 (i.e. leaves these unspecified); the endpoint only becomes fully 293 specified after performing the handshake with an incoming connection. 294 For such cases, this document does not update [RFC4340], i.e. the 295 server adheres to the existing state transitions in the left half of 296 Figure 2 (CLOSED => LISTEN => RESPOND). 298 A fully specified DCCP-server endpoint permits exactly one client, 299 identified by target IP-address:port plus service code, to set up the 300 connection. Such a server SHOULD perform the actions and state 301 transitions shown in the right half of Figure 2, and specified below. 303 unspecified remote +--------+ fully specified remote 304 +---------------------| CLOSED |---------------------+ 305 | +--------+ send DCCP-Listen | 306 | | 307 | | 308 v v 309 +--------+ timeout +---------+ 310 | LISTEN |<------------------------------+-----------| INVITED | 311 +--------+ more than 2 retransmissions | +---------+ 312 | | 1st / 2nd ^ | 313 | | retransm. | | 314 | +-------------+ | 315 | resend Listen | 316 | | 317 | | 318 | receive Request +---------+ receive Request | 319 +------------------->| RESPOND |<--------------------+ 320 send Response +---------+ send Response 322 Figure 2: Updated state transition diagram for DCCP-Listen 324 A fully-specified server endpoint performs passive-open from CLOSED 325 by inviting the remote client to connect. This is done by sending a 326 single DCCP-Listen packet to the specified remote IP-adress:port, 327 using the format specified in Section 2.2. The server then 328 transitions to INVITED. 330 The INVITED state is, like LISTEN, a passive state, characterised by 331 waiting in the absence of an established connection. If the server 332 endpoint in state INVITED receives a DCCP-Request, it transitions to 333 RESPOND, where further processing resumes as specified in [RFC4340]. 335 The server SHOULD repeat sending a DCCP-Listen packet while in state 336 INVITED, at a 200 millisecond interval and up to at most 2 337 repetitions (Section 3 discusses this choice of timer interval). The 338 retransmission timer is restarted with the same 200ms interval after 339 the second retransmission. When, upon the next timeout, the server 340 is still in the INVITED state, it SHOULD progress to LISTEN, and 341 resume processing as per [RFC4340]. 343 Fully-specified server endpoints SHOULD treat ICMP error messages 344 received in response to a DCCP-Listen packet as "soft errors" that do 345 not cause a state transition. 347 Server endpoints SHOULD in general ignore any incoming DCCP-Listen 348 packets. As an exception to this rule, a DCCP-Server in state LISTEN 349 MAY generate a Reset (Code 7, "Connection Refused") in response to a 350 DCCP-Listen packet. 352 Further details on the rationale are discussed in Section 3. 354 2.3.2. Protocol Method for DCCP-Client Endpoints 356 This document updates [RFC4340], by adding the following normative 357 rule for the reception of DCCP-Listen packets by clients. 359 Clients MUST silently discard any received DCCP-Listen packets, 360 regardless of their current state. 362 2.3.3. Processing by Routers and Middleboxes 364 DCCP-Listen packets do not require special treatment and should thus 365 be forwarded end-to-end across Internet paths, by routers and 366 middleboxes alike. 368 Middleboxes may utilise the connection information (address, port, 369 service code) to establish local forwarding state. This has been the 370 main motivation for adding the Service Code field: in combination 371 with the source and destination addresses (found in the enclosing IP- 372 header), the DCCP-Listen packet carries all necessary information to 373 uniquely identify a DCCP session. 375 2.4. Examples of Use 377 In the examples below, DCCP A is the client and DCCP B is the server. 378 NAT/Firewall device NA is placed before DCCP A, and NAT/Firewall 379 device NB is placed before DCCP B. 381 Both NA and NB use a policy that permits DCCP packets to traverse the 382 device for outgoing links, but only permit incoming DCCP packets when 383 a previous packet has been sent out for the same connection. 385 DCCP A and DCCP B decide to communicate using some out-of-band 386 mechanism, whereupon the client and server are started. DCCP A 387 initiates a connection by sending a DCCP-Request. DCCP B actively 388 indicates its listening state by sending a DCCP-Listen message. This 389 fulfils the requirement of punching a hole in NB, so that DCCP A can 390 retransmit the DCCP-Request and connect through it. 392 DCCP A DCCP B 393 ------ NA NB ------ 394 +------------------+ +-+ +-+ +-----------------+ 395 |(1) Initiation | | | | | | | 396 |DCCP-Request --> +--+-+---X| | | | 397 | |<-+-+----+-+--+<-- DCCP-Listen | 398 | | | | | | | | 399 |DCCP-Request --> +--+-+----+-+->| | 400 | |<-+-+----+-+--+<-- DCCP-Response| 401 |DCCP-Ack --> +--+-+----+-+->| | 402 | | | | | | | | 403 |(2) Data transfer | | | | | | | 404 |DCCP-Data --> +--+-+----+-+->| | 405 +------------------+ +-+ +-+ +-----------------+ 407 Figure 3: Event sequence when the client is started before the server 409 The diagram below shows the reverse sequence of events, where the 410 server sends the DCCP-Listen before the client sends a DCCP-Request: 412 DCCP A DCCP B 413 ------ NA NB ------ 414 +------------------+ +-+ +-+ +-----------------+ 415 |(1) Initiation | | | | | | | 416 | | | |X---+-+--+<-- DCCP-Listen | 417 |DCCP-Request --> +--+-+----+-+->| | 418 | | <+-+----+-+--+<-- DCCP-Response| 419 |DCCP-Ack --> +--+-+----+-+> | | 420 | | | | | | | | 421 |(2) Data transfer | | | | | | | 422 |DCCP-Data --> +--+-+----+-+> | | 423 +------------------+ +-+ +-+ +-----------------+ 425 Figure 4: Event sequence when the server is started before the client 427 2.5. Backwards Compatibility with RFC 4340 429 There are no changes if a client conforming to this document 430 communicates with a server conforming to [RFC4340]. 432 If a client implements only [RFC4340], incoming DCCP-Listen packets 433 would be ignored due to step 1 in [RFC4340], 8.1, which at the same 434 time also conforms to the behaviour specified by this document. 436 This document further does not modify communication for any server 437 that implements a passive-open without fully binding the addresses, 438 ports and service codes to be used. 440 The authors therefore do not expect practical deployment problems. 442 3. Discussion of Design Decisions 444 3.1. Rationale for a New Packet Type 446 The DCCP-Listen packet specified in Section 2.2 has the same format 447 as the DCCP-Request packet ([RFC4340], 5.1), the only difference is 448 in the value of the Type field. 450 The usage, however, differs. The DCCP-Listen packet serves as 451 advisory message, not as part of the actual connection setup: 452 sequence numbers have no meaning, and no payload may be present. 454 It is important to point out that a DCCP-Request packet could in 455 theory also be used for the same purpose. The following arguments 456 were against this. 458 The first problem is that of semantic overloading: the Request is 459 defined in [RFC4340] to serve a well-defined purpose, being the 460 initial packet of the 3-way handshake. Additionally using it in the 461 manner of a DCCP-Listen packet would require DCCP processors to have 462 two different processing paths: one where a Request is interpreted as 463 part of the initial handshake, and another where the same packet is 464 interpreted as indicator message. This complicates packet processing 465 in hosts and in particular stateful middleboxes (which may have 466 restricted computational resources). 468 The second problem is that a client receiving a DCCP-Request from a 469 server could generate a Reset if it has not yet entered the REQUEST 470 state (step 7 in [RFC4340], 8.5). This document lets client 471 endpoints ignore DCCP-Listen packets. Adding a similar rule for the 472 Request packet is more cumbersome: clients can not distinguish 473 between a Request meant to be an indicator message and a genuinely 474 erratic connection initiation. 476 The third problem is similar and refers to a client receiving the 477 DCCP-Listen after having itself sent a (connection-initiation) 478 Request. Step 7 in section 8.5 of [RFC4340] requires the client to 479 reply to an "indicator message" Request from the server with a Sync. 480 Since sequence numbers are ignored for this type of message, 481 additional and complex processing becomes necessary: either to ask 482 the client not to respond to a Request when the Request is of type 483 "indicator message"; or ask middleboxes and servers to ignore Sync 484 packets generated in response to "indicator message" Requests. 485 Furthermore, since no initial sequence numbers have been negotiated 486 at this stage, sending a SyncAck would not be meaningful. 488 Using a separate packet type allows simpler and clearer processing. 490 The rationale for ignoring the Sequence Number fields on DCCP-Listen 491 packets is that endpoints have not yet entered connection setup: the 492 Listen packet is sent out while the server is still in the passive- 493 open (INVITED) state, i.e. it has not yet allocated state other than 494 binding to the client's IP-address:port and service code. 496 Although the DCCP-Listen Sequence Number fields are ignored, they 497 have been retained to reuse the generic header format from section 498 5.1 of [RFC4340]. 500 3.2. Generation of Listen Packets 502 Since DCCP-Listen packets solve a particular problem (NAT and/or 503 firewall traversal), the generation of DCCP-Listen packets on passive 504 sockets is tied to a condition (binding to an a priori known remote 505 address and service code), so as to not interfere with the general 506 case of "normal" DCCP connections (where client addresses are 507 generally not known in advance). 509 In the TCP world, the analogue is a transition from LISTEN to 510 SYN_SENT by virtue of sending data: "A fully specified passive call 511 can be made active by the subsequent execution of a SEND" ([RFC0793], 512 3.8). 514 Unlike TCP, this proposal does not perform a role-change from passive 515 to active. 517 Like TCP, we require that DCCP-Listen packets are only sent by a 518 DCCP-server when the endpoint is fully specified (Section 2.3). 520 3.3. Repetition of Listen Packets 522 Repetition is a necessary requirement, to increase robustness and the 523 chance of successful connection establishment: in case a Listen 524 packet is lost due to congestion, link loss or some other reason. 526 Recommending a maximum number of 3 timeouts (2 repetitions) is due to 527 the following considerations. The repeated copies need to be spaced 528 sufficiently far apart in time to avoid suffering from correlated 529 loss. The interval of 200ms has been chosen to accommodate a wide 530 range of wireless and wired network paths. 532 Another constraint is given by the retransmission interval for the 533 DCCP-Request ([RFC4340], 8.1.1). To establish state, intermediate 534 systems need to receive a (retransmitted) DCCP-Listen packet before 535 the DCCP-Request times out (1 second). With three timeouts, each 536 spaced 200 milliseconds apart, the overall time is still below one 537 second. On the other hand, the sum of 600 milliseconds is 538 sufficiently large to provide for longer one-way delays, such as e.g. 539 found on some wireless links. 541 The rationale behind transitioning to the LISTEN state after two 542 retransmissions is that other problems, independent of establishing 543 middlebox state, may occur (such as delay or loss of the initial 544 DCCP-Request). Any late or retransmitted DCCP-Request packets will 545 then still reach the server, so that connection establishment 546 completes successfully. 548 4. Security Considerations 550 The method specified in this document exposes the state of a DCCP 551 server that has been explicitly pre-configured to accept a connection 552 from a known client. Establishing this state requires prior out-of- 553 band signalling between the client and server (e.g. via the Session 554 Initiation Protocol [RFC3261]). 556 The technique generates a packet addressed to the expected client. 557 This increases the vulnerability of the DCCP server, by revealing 558 which ports are in a passive listening state (the information is not 559 encrypted and therefore could be seen on the path to the client 560 through the network). 562 Servers that do not wish to disclose this information may refrain 563 from generating DCCP-Listen packets, without impacting subsequent 564 DCCP state transitions. 566 This document requires endpoint nodes to ignore reception of DCCP- 567 Listen packets (in any state other than LISTEN). 569 We do not believe these changes significantly increase the complexity 570 or vulnerability of a DCCP implementation that conforms to [RFC4340]. 572 5. IANA Considerations 574 This document requires IANA action by allocation of a new Packet Type 575 from the IANA DCCP Packet Types Registry. The name of the Packet 576 Type is the "DCCP-Listen" packet, and its type field is set to XX- 577 IANA-assigned-XX. 579 The Registry entry is to reference this document. 581 Note to the RFC Editor: 583 Please replace XX-IANA-assigned-XX throughout this document with the 584 value assigned in the registry and remove this note. 586 6. References 588 6.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 594 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 596 6.2. Informative References 598 [Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software 599 Approach to Solving the NAT Problem", Carnegie Mellon 600 University/ISRI Technical Report CMU-ISRI-05-104, 601 January 2005. 603 [FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 604 Communication Across Network Address Translators", 605 Proceedings of USENIX-05, pages 179-192, 2005. 607 [Fai08] Fairhurst, G., "The DCCP Service Code", Work In 608 Progress, draft-ietf-dccp-serv-codes-06, June 2008. 610 [GBF+07] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 611 Srisuresh, "NAT Behavioral Requirements for TCP", Work In 612 Progress, draft-ietf-behave-tcp-07, April 2007. 614 [GF05] Guha, S. and P. Francis, "Characterization and Measurement 615 of TCP Traversal through NATs and Firewalls", Proceedings 616 of Internet Measurement Conference (IMC-05), pages 199- 617 211, 2005. 619 [GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based 620 approach to UDP and TCP connectivity", Proceedings of 621 SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004. 623 [H.323] ITU-T, "Packet-based Multimedia Communications Systems", 624 Recommendation H.323, July 2003. 626 [NAT-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design 627 Guidelines for Traversal through Network Address 628 Translators", Work In Progress, draft-ford-behave-app-05, 629 March 2007. 631 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 632 RFC 793, September 1981. 634 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 635 Translator (NAT) Terminology and Considerations", 636 RFC 2663, August 1999. 638 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 639 Address Translator (Traditional NAT)", RFC 3022, 640 January 2001. 642 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 643 Application Design Guidelines", RFC 3235, January 2002. 645 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 646 A., Peterson, J., Sparks, R., Handley, M., and E. 647 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 648 June 2002. 650 [Ros08] Rosenberg, J., "TCP Candidates with Interactive 651 Connectivity Establishment (ICE)", Work In 652 Progress, draft-ietf-mmusic-ice-tcp-06, February 2008. 654 [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 655 Relays around NAT (TURN): Relay Extensions to Session 656 Traversal Utilities for NAT (STUN)", Work In 657 Progress, draft-ietf-behave-turn-07, February 2008. 659 Appendix A. Discussion of Existing NAT Traversal Techniques 661 This Appendix is a brief review of existing techniques to establish 662 connectivity across NAT devices, with the aim of providing background 663 information. 665 We first consider TCP NAT traversal based on simultaneous-open, and 666 then discuss a second technique based on role reversal. Further 667 information can be found in [GTF04] and [GF05]. 669 A central idea shared by these techniques is to make peer-to-peer 670 sessions look like "outbound" sessions on each NAT device. 672 Often a rendezvous server, located in the public address realm, is 673 used to enable clients to discover their NAT topology and the 674 addresses of peers. 676 The term 'hole punching' was coined in [FSK05] and refers to creating 677 soft state in a traditional NAT device by initiating an outbound 678 connection. A well-behaved NAT can subsequently exploit this to 679 allow a reverse connection back to the host in the private address 680 realm. 682 UDP and TCP hole punching use nearly the same technique. The 683 adaptation of the basic UDP hole punching principle to TCP NAT 684 traversal was introduced in section 4 of [FSK05] and relies on the 685 simultaneous-open feature of TCP [RFC0793]. A further difference 686 between UDP and TCP lies in the way the clients perform connectivity 687 checks, after obtaining suitable address pairs for connection 688 establishment. Whereas in UDP a single socket is sufficient, TCP 689 clients require several sockets for the same address / port tuple: 691 o a passive socket to listen for connectivity tests from peers and 693 o multiple active connections from the same address to test 694 reachability of other peers. 696 The SYN sent out by client A to its peer B creates soft state in A's 697 NAT. At the same time, B tries to connect to A: 699 o if the SYN from B has left B's NAT before the arrival of A's SYN, 700 both endpoints perform simultaneous-open (4-way handshake of SYN/ 701 SYNACK); 703 o otherwise A's SYN may not enter B's NAT, which leads to B 704 performing a normal open (SYN_SENT => ESTABLISHED) and A 705 performing a simultaneous-open (SYN_SENT => SYN_RCVD => 706 ESTABLISHED). 708 In the latter case it is necessary that the NAT does not interfere 709 with a RST segment (REQ-4 in [GBF+07]). The simultaneous-open 710 solution is convenient due to its simplicity, and is thus a preferred 711 mode of operation in the TCP extension for ICE ([Ros08], sec. 2). 713 A.1. NAT traversal Based on Simultaneous-Open 715 Among the various TCP NAT traversal approaches, simultaneous-open 716 suggests itself due to its simplicity [GF05], [NAT-APP]. 718 A characteristic of simultaneous-open is that the clear distinction 719 between client and server is erased: both sides enter through active 720 (SYN_SENT) as well as passive (SYN_RCVD) states. This characteristic 721 is in conflict with several ideas underlying DCCP, as a clear 722 separation between client and server has been one of the initial 723 design decisions ([RFC4340], 4.6). Furthermore, several mechanisms 724 implicitly rely on clearly-defined client/server roles: 726 o Feature Negotiation: with few exceptions, almost all of DCCP's 727 negotiable features use the "server-priority" reconciliation rule 728 ([RFC4340], 6.3.1), whereby peers exchange their preference lists 729 of feature values, and the server decides the outcome. 731 o Closing States: only servers may generate CloseReq packets (asking 732 the peer to hold timewait state), while clients are only permitted 733 to send Close or Reset packets to terminate a connection 734 ([RFC4340], 8.3). 736 o Service Codes: servers may be associated with multiple service 737 codes, while clients must be associated with exactly one 738 ([RFC4340], 8.1.2). 740 o Init Cookies: may only be used by the server and on DCCP-Response 741 packets ([RFC4340], 8.1.4). 743 The latter two points are not obstacles per se, but hinder the 744 transition from a passive to an active socket. The assumption that 745 "all DCCP hosts are clients", on the other hand, must be dismissed 746 since it limits application programming. As a consequence, retro- 747 fitting simultaneous-open into DCCP does not seem a very sensible 748 idea. 750 A.2. Role Reversal 752 After the simultaneous-open, one of the simplest TCP NAT traversal 753 schemes involves role traversal ([Epp05] and [GTF04]), where a peer 754 first opens an active connection for the single purpose of punching a 755 hole in the firewall; and then reverts to a listening socket, 756 accepting connections arriving via the new path. 758 This solution has several disadvantages for DCCP. First, a DCCP 759 server would be required to change its role temporarily to 'client'. 760 This requires modification of settings, in particular service codes 761 and perhaps Init Cookies. 763 Further, the the server must not yet have started feature 764 negotiation, since its choice of initial options may rely on its role 765 (i.e. if an endpoint knows it is the server, it can make a priori 766 assumptions about the preference lists of features it is negotiating 767 with the client, thereby enforcing a particular policy). 769 Lastly, the server needs additional processing to ensure that the 770 connection coming through the listening socket matches the one for 771 which it previously opened an active connection. 773 We therefore do not recommend this approach for DCCP. 775 Appendix B. Change Log 777 Revision 00 retrieved from previous individual submission 778 draft-fairhurst-dccp-behave-update-01 by the same authors. 780 Revision 01: 782 o introduced many format changes to improve readability 784 o migrated background information into the Appendix 786 o added Section 1.3 to summarize the document structure 788 o updated introductory paragraph of Section 2 to account for new 789 structure 791 o added captions to all figures 793 o updated the specification in Section 2 to (i) permit options on 794 DCCP-Listen packets; (ii) explain why the presence of payload data 795 is not useful; (iii) clarify that middleboxes must not interpret 796 sequence numbers on DCCP-Listen packets 798 o clarified that the default value of the Allow Short Seqno feature 799 is to be used 801 o added references to the service code draft [Fai08] 803 o clarified the processing of DCCP-Listen packets by server 804 endpoints 806 o corrected the reaction of a client implementing [RFC4340] only - 807 DCCP-Listen packets are treated as unknown and hence do not 808 generate a Reset 810 o swapped order of IANA / Security-Considerations sections 812 o added a note in the Security Considerations section that servers 813 may refrain from generating DCCP-Listen packets 815 Note to the RFC Editor: 817 Please remove this Change Log when done with the document. 819 Authors' Addresses 821 Godred Fairhurst 822 University of Aberdeen 823 School of Engineering 824 Fraser Noble Building 825 Aberdeen AB24 3UE 826 Scotland 828 Email: gorry@erg.abdn.ac.uk 829 URI: http://www.erg.abdn.ac.uk 831 Gerrit Renker 832 University of Aberdeen 833 School of Engineering 834 Fraser Noble Building 835 Aberdeen AB24 3UE 836 Scotland 838 Email: gerrit@erg.abdn.ac.uk 839 URI: http://www.erg.abdn.ac.uk 841 Full Copyright Statement 843 Copyright (C) The IETF Trust (2008). 845 This document is subject to the rights, licenses and restrictions 846 contained in BCP 78, and except as set forth therein, the authors 847 retain all their rights. 849 This document and the information contained herein are provided on an 850 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 851 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 852 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 853 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 854 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 855 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 857 Intellectual Property 859 The IETF takes no position regarding the validity or scope of any 860 Intellectual Property Rights or other rights that might be claimed to 861 pertain to the implementation or use of the technology described in 862 this document or the extent to which any license under such rights 863 might or might not be available; nor does it represent that it has 864 made any independent effort to identify any such rights. Information 865 on the procedures with respect to rights in RFC documents can be 866 found in BCP 78 and BCP 79. 868 Copies of IPR disclosures made to the IETF Secretariat and any 869 assurances of licenses to be made available, or the result of an 870 attempt made to obtain a general license or permission for the use of 871 such proprietary rights by implementers or users of this 872 specification can be obtained from the IETF on-line IPR repository at 873 http://www.ietf.org/ipr. 875 The IETF invites any interested party to bring to its attention any 876 copyrights, patents or patent applications, or other proprietary 877 rights that may cover technology that may be required to implement 878 this standard. Please address the information to the IETF at 879 ietf-ipr@ietf.org. 881 Acknowledgment 883 Funding for the RFC Editor function is provided by the IETF 884 Administrative Support Activity (IASA).