idnits 2.17.1 draft-ietf-dccp-simul-open-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 18, 2008) is 5905 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) -- 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-05 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 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 Intended status: Standards Track University of Aberdeen 5 Expires: August 21, 2008 February 18, 2008 7 DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal 8 draft-ietf-dccp-simul-open-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies an update to the Datagram Congestion Control 42 Protocol (DCCP), a connection-oriented and datagram-based transport 43 protocol. 45 The update assists DCCP applications which need to communicate 46 through one or more middleboxes (e.g. Network Address Translators or 47 firewalls), where establishing necessary middlebox state requires 48 peering endpoints to initiate communication in a near-simultaneous 49 manner. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 55 1.2. Scope of the Problem to be Tackled . . . . . . . . . . . . 4 56 1.3. Discussion of Existing NAT Traversal Techniques . . . . . 4 57 1.3.1. Near Simultaneous-Open of Connections . . . . . . . . 5 58 1.3.2. Role Reversal . . . . . . . . . . . . . . . . . . . . 6 59 2. Procedure for Near-Simultaneous Open . . . . . . . . . . . . . 8 60 2.1. Conventions and Terminology . . . . . . . . . . . . . . . 8 61 2.2. DCCP-Listen Packet Format . . . . . . . . . . . . . . . . 8 62 2.3. Protocol Method . . . . . . . . . . . . . . . . . . . . . 10 63 2.3.1. Protocol Method for DCCP-Server Endpoints . . . . . . 10 64 2.3.2. Protocol Method for DCCP-Client Endpoints . . . . . . 12 65 2.3.3. Processing by Routers and Middleboxes . . . . . . . . 12 66 2.4. Examples of Use . . . . . . . . . . . . . . . . . . . . . 12 67 2.5. Backwards Compatibility with RFC 4340 . . . . . . . . . . 14 68 3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 15 69 3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 15 70 3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 16 71 3.3. Repetition of Listen Packets . . . . . . . . . . . . . . . 16 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 6.1. Normative References . . . . . . . . . . . . . . . . . . . 21 76 6.2. Informative References . . . . . . . . . . . . . . . . . . 21 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 79 Intellectual Property and Copyright Statements . . . . . . . . . . 25 81 1. Introduction 83 UDP Network Address Translator (NAT) traversal is well understood and 84 widely implemented. NAT traversal for connection-oriented protocols 85 (e.g. TCP) uses similar principles, but in some cases requires more 86 complex and expensive solutions, such as data relay servers [TURN]. 88 DCCP [RFC4340] is both datagram-based and connection-oriented; and 89 thus NAT traversal of DCCP faces the same problems as TCP NAT 90 traversal, without being able to simply reuse UDP-based NAT traversal 91 techniques. In addition, DCCP has the disadvantage of not being able 92 to perform a simultaneous-open, a TCP-inherent characteristic which 93 greatly simplifies NAT traversal. 95 After discussing the problem space for DCCP, this document specifies 96 an extension to facilitate DCCP NAT traversal, by explicitly 97 supporting a widely implemented traversal principle known as 'hole 98 punching'. This extension produces the same outward effect as an 99 simultaneous-open, but without internal changes to the standard 100 operational procedure of DCCP. The extension uses a dedicated 101 indicator message, whose usage is tied to a specific condition, can 102 thus be turned off, and is inter-operable with non-extended hosts. 104 The object of this extension is in built-in support for middlebox 105 traversal, to reduce reliance on external aids such as data relay 106 servers. 108 1.1. Scope of this Document 110 The technique described by this document applies to scenarios where 111 one or both DCCP peers are located behind a middlebox. 113 This document is specifically targeted at NAT traversal. However, 114 due to the similarity of involved principles, the technique and 115 presented extension of DCCP may also be of similar use to the 116 traversal of other types of middlebox, such as firewalls. 118 The proposed extension is relevant to both client/server and peer-to- 119 peer applications, such as VoIP, file sharing, or online gaming. It 120 assists connections that utilise prior out-of-band signaling (e.g. 121 via a well-known rendezvous server ([RFC3261], [H.323])) to notify 122 both endpoints of the connection parameters ([RFC3235], [NAT-APP]). 124 For the scope of this document we assume traditional (outbound) types 125 of NAT as defined in [RFC2663] and further discussed in [RFC3022]. 126 We understand NAT traversal as involving one or more NAT devices of 127 this type in the path (i.e. hierarchies of nested NAT devices are 128 possible). It is assumed that all NATs in the path between endpoints 129 are BEHAVE-compliant [NAT-APP]. 131 This memo does not discuss behavioural requirements of NAT devices to 132 support DCCP traversal. These may be described by a separate 133 document. We further assume that NAT devices provide only a minimum 134 of DCCP protocol support, in that layer-4 checksums are updated to 135 account for changes in the pseudo-header. 137 1.2. Scope of the Problem to be Tackled 139 We refer to DCCP hosts located behind one or more NAT devices as 140 having "private" addresses, and to DCCP hosts located in the global 141 address realm as having "public" addresses. 143 We consider DCCP NAT traversal for the following scenarios: 145 1. Private client connects to public server. 147 2. Public server connects to private client. 149 3. Private client connects to private server. 151 A defining characteristic of traditional NAT devices [RFC3022] is 152 that private hosts can connect to external hosts, but not vice versa. 153 Hence the case (1) is always possible, whereas cases (2) and (3) 154 require NAT traversal techniques. In this document we do not 155 consider use of pre-configured static NAT address maps, which would 156 also allow outside hosts to connect to the private network in cases 157 (2) and (3). 159 A DCCP implementation conforming to [RFC4340] can perform NAT 160 traversal with the help of an external data relay server. The 161 extension described in this document facilitates NAT traversal 162 without indirection via relay servers. 164 1.3. Discussion of Existing NAT Traversal Techniques 166 This section is a brief review of existing techniques to establish 167 connectivity across NAT devices, the basic idea being to make peer- 168 to-peer sessions look like "outbound" sessions on each NAT device. 170 Often a rendezvous server, located in the public address realm, is 171 used to enable clients to discover their NAT topology and the 172 addresses of peers. 174 The term 'hole punching' was coined in [FSK05] and refers to creating 175 soft state in a traditional NAT device by initiating an outbound 176 connection. A well-behaved NAT can subsequently exploit this to 177 allow a reverse connection back to the host in the private address 178 realm. 180 The adaptation of the basic hole punching principle to TCP NAT 181 traversal was introduced in section 4 of [FSK05] and relies on the 182 simultaneous-open feature of TCP [RFC0793]. UDP and TCP hole 183 punching use nearly the same technique. The main difference lies in 184 the way the clients perform connectivity checks, after obtaining the 185 address pairs from the server. Whereas in UDP a single socket is 186 sufficient, TCP clients require several sockets for the same address 187 / port tuple: 189 o a passive socket to listen for connectivity tests from peers and 191 o multiple active connections from the same address to test 192 connectivity of other peers. 194 The SYN sent out by client A to its peer B creates soft state in A's 195 NAT. At the same time, B tries to connect to A: 197 o if the SYN from B has left B's NAT before the arrival of A's SYN, 198 both endpoints perform simultaneous-open (4-way handshake of SYN/ 199 SYNACK); 201 o otherwise A's SYN may not enter B's NAT, which leads to B 202 performing a normal open (SYN_SENT => ESTABLISHED) and A 203 performing a simultaneous-open (SYN_SENT => SYN_RCVD => 204 ESTABLISHED). 206 In the latter case it is necessary that the NAT does not interfere 207 with a RST segment (REQ-4 in [GBF+07]). The simultaneous-open 208 solution is convenient due to its simplicity, and is thus a preferred 209 mode of operation in the TCP extension for ICE (section 2 of 210 [Ros07]). 212 We note that a simultaneous-open is not the only existing solution 213 for TCP NAT traversal [GTF04], [GF05]; other approaches are reviewed 214 in the next subsection. 216 1.3.1. Near Simultaneous-Open of Connections 218 Among the various TCP NAT traversal approaches, simultaneous-open 219 suggests itself due to its simplicity [GF05], [NAT-APP]. A 220 characteristic of simultaneous-open is that the clear distinction 221 between client and server is erased: both sides enter through active 222 (SYN_SENT) as well as passive (SYN_RCVD) states. This characteristic 223 is in conflict with several ideas underlying DCCP, as a clear 224 separation between client and server has been one of the initial 225 design decisions ([RFC4340], 4.6). Furthermore, several mechanisms 226 implicitly rely on clearly-defined client/server roles: 228 o Feature Negotiation: with few exceptions, almost all of DCCP's 229 negotiable features use the "server-priority" reconciliation rule 230 ([RFC4340], 6.3.1), whereby peers exchange their preference lists 231 of feature values, and the server decides the outcome. 233 o Closing States: only servers may generate CloseReq packets (asking 234 the peer to hold timewait state), while clients are only permitted 235 to send Close or Reset packets to terminate a connection 236 ([RFC4340], 8.3). 238 o Service Codes: servers may be associated with multiple service 239 codes, while clients must be associated with exactly one 240 ([RFC4340], 8.1.2). 242 o Init Cookies: may only be used by the server and on DCCP-Response 243 packets ([RFC4340], 8.1.4). 245 The latter two points are not obstacles per se, but hinder the 246 transition from a passive to an active socket. The assumption that 247 "all DCCP hosts are clients", on the other hand, must be dismissed 248 since it limits application programming. As a consequence, retro- 249 fitting simultaneous-open into DCCP does not seem a very sensible 250 idea. 252 1.3.2. Role Reversal 254 After the simultaneous-open, one of the simplest TCP NAT traversal 255 schemes involves role traversal ([Epp05] and [GTF04]), where a peer 256 first opens an active connection for the single purpose of punching a 257 hole in the firewall, and then reverts to a listening socket, to 258 accept incoming connections arriving via the new path. 260 This solution has several disadvantages for DCCP. First, a DCCP 261 server would be required to change its role temporarily to 'client'. 262 This requires modification of settings, in particular service codes 263 and perhaps Init Cookies. 265 Further, the the server must not yet have started feature 266 negotiation, since its choice of initial options may rely on its role 267 (i.e. if an endpoint knows it is the server, it can make a priori 268 assumptions about the preference lists of features it is negotiating 269 with the client, thereby enforcing a particular policy). 271 Lastly, the server needs additional processing to ensure that the 272 connection coming through the listening socket matches the one for 273 which it previously opened an active connection. 275 We therefore do not recommend this approach for DCCP. 277 2. Procedure for Near-Simultaneous Open 279 This section presents the packet-processing details of the 280 simultaneous-open technique for DCCP. The technique does not employ 281 role reversal - both endpoints start out with their designated roles, 282 as specified in [RFC4340]. Neither does it require protocol support 283 for a genuinely simultaneous handshake. 285 The presented extension updates the connection-establishment 286 procedures of [RFC4340]. 288 2.1. Conventions and Terminology 290 The document uses the terms and definitions provided in [RFC4340]. 291 Familiarity with this specification is assumed. In particular, the 292 following convention from ([RFC4340], 3.2) is used: 294 "Each DCCP connection runs between two hosts, which we often name 295 DCCP A and DCCP B. Each connection is actively initiated by one of 296 the hosts, which we call the client; the other, initially passive 297 host is called the server." 299 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 300 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 301 document are to be interpreted as described in [RFC2119]. 303 2.2. DCCP-Listen Packet Format 305 The document updates DCCP by adding a new packet type, DCCP-Listen, 306 whose format is shown below 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Source Port | Dest Port | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Data Offset | CCVal | CsCov | Checksum | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Res | Type |X| Reserved | Sequence Number High Bits | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sequence Number Low Bits | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Service Code | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 DCCP-Listen Packet Format 324 A DCCP-Listen Packet MUST NOT include any DCCP options (since this 325 packet does not modify the receiver protocol state) and also MUST NOT 326 include application data. Therefore Data Offset MUST be set to 5, 327 the length of the DCCP-Listen packet in 32-bit words. 329 Furthermore, the following protocol fields MUST all be set to zero: 331 CCVal (the connection has not been established), 333 CsCov (there is no payload). 335 A server conforming to this revision of the specification SHOULD set 336 both Sequence Number fields to 0; clients MUST ignore the value of 337 the Sequence Number fields; and middleboxes SHOULD NOT interpret 338 sequence numbers on DCCP-Listen packets. 340 The "Res" and "Reserved" fields are specified by [RFC4340] and its 341 successors. The interpretation of these fields is not modified by 342 this document. 344 The Type field has the value XX-IANA-assigned-XX, which indicates 345 that this is a DCCP-Listen packet. 347 Note to the RFC Editor: 349 Please replace XX-IANA-assigned-XX in the above paragraph with the 350 value assigned in the registry and remove this note. 352 ==> End of note to the RFC Editor. <== 354 DCCP-Listen packets use a single format only and therefore do not 355 support the alternative use of short sequence numbers defined in 356 section 5.1 of [RFC4340]. Hence X MUST be set to 1, and all DCCP- 357 Listen packets with X=0 MUST be ignored. 359 The Service Code field contains the service code ([RFC4340], 8.1.2) 360 that the client peer wants to use for this connection. This value 361 MUST correspond to a service code that the server is actually 362 offering for connections identified by the same source IP address and 363 the same Source Port as the DCCP-Listen packet. Since the server may 364 use multiple service codes, the value of the Service Code field needs 365 to be communicated out-of-band, from client to server, prior to 366 sending the DCCP-Listen packet. 368 2.3. Protocol Method 370 We use the term "session" as defined in ([RFC2663], 2.3): DCCP 371 sessions are uniquely identified by the tuple of . 374 DCCP, in addition, introduces service codes which can be used to 375 identify different services that may be offered via the same port. 377 We call the five-tuple a fully specified DCCP connection, 379 and refer to an endpoints that has been assigned all five parameters 380 as a "fully specified endpoint". DCCP-Listen packets are only sent 381 for the specific case of fully specified DCCP-server endpoints. 383 2.3.1. Protocol Method for DCCP-Server Endpoints 385 This document updates [RFC4340] for the case of fully specified DCCP- 386 server endpoints. The update conditionally applies to the way the 387 server performs passive-open. 389 Prior to connection setup, it is common for DCCP-server endpoints to 390 not be fully specified: before the connection is established, a 391 server usually sets the target IP-address:port to wildcard numbers 392 (i.e. leaves these unspecified); the endpoint only becomes fully 393 specified after performing the handshake with an incoming connection. 394 For such cases, this document does not update [RFC4340], i.e. the 395 server adheres to the existing state transitions in the left half of 396 Figure 2 (CLOSED => LISTEN => RESPOND). 398 A fully specified DCCP-server endpoint permits exactly one client, 399 identified by target IP-address:port plus service code, to set up the 400 connection. Such a server SHOULD perform the actions and state 401 transitions shown in the right half of Figure 2, and specified below. 403 unspecified remote +--------+ fully specified remote 404 +---------------------| CLOSED |---------------------+ 405 | +--------+ send DCCP-Listen | 406 | | 407 | | 408 v v 409 +--------+ timeout +---------+ 410 | LISTEN |<------------------------------+-----------| INVITED | 411 +--------+ more than 2 retransmissions | +---------+ 412 | | 1st / 2nd ^ | 413 | | retransm. | | 414 | +-------------+ | 415 | resend Listen | 416 | | 417 | | 418 | receive Request +---------+ receive Request | 419 +------------------->| RESPOND |<--------------------+ 420 send Response +---------+ send Response 422 Figure 2: Updated state transition diagram for DCCP-Listen 424 A fully-specified server endpoint performs passive-open from CLOSED 425 by inviting the remote client to connect, via a single DCCP-Listen 426 packet. The packet is sent to the specified remote IP-adress:port, 427 using the format specified in Section 2.2. The server then 428 transitions to INVITED. (The INVITED state is, like LISTEN, a 429 passive state, characterised by waiting in the absence of an 430 established connection.) 432 If the server endpoint in state INVITED receives a DCCP-Request, it 433 transitions to RESPOND; where further processing resumes as specified 434 in [RFC4340]. 436 The server SHOULD repeat sending a DCCP-Listen packet while in state 437 INVITED, at a 200 millisecond interval and up to at most 2 438 repetitions. The retransmission timer is restarted with the same 439 200ms interval after the second retransmission. When, upon the next 440 timeout, the server is still in the INVITED state, it SHOULD progress 441 to LISTEN, and resume processing as per [RFC4340]. 443 Fully-specified server endpoints SHOULD treat ICMP error messages 444 received in reply to a DCCP-Listen packet as "soft errors" that do 445 not cause a state transition. 447 Any server receiving a DCCP-Listen packet in the LISTEN state MUST 448 reply with a Reset (using Reset Code 7, "Connection Refused"), which 449 is the expected behaviour with regard to [RFC4340]. Listen packets 450 received in any other state MUST be ignored (cf. next subsection). 452 Further details on the rationale are discussed in Section 3. 454 2.3.2. Protocol Method for DCCP-Client Endpoints 456 This document updates [RFC4340], by adding the following rules for 457 the reception of DCCP-Listen packets by clients. 459 Clients MUST silently discard any received DCCP-Listen packets, 460 regardless of their current state. The packet indicates only a 461 willingness to accept a connection: if the client has already 462 established a connection (OPEN or PARTOPEN), this has no meaning. 464 If a client is awaiting the response to a DCCP-Request, it does not 465 need to take specific action. While in state REQUEST, other than 466 ignoring DCCP-Listen packets, it MUST use the protocol method defined 467 in [RFC4340]. This ensures that retransmissions will happen in the 468 expected manner. 470 2.3.3. Processing by Routers and Middleboxes 472 Routers and middleboxes both act as forwarding agents for DCCP 473 packets. This document does not specify rules for forwarding DCCP 474 packets. We note, however, that DCCP-Listen packets do not require 475 special treatment, and should therefore be forwarded end-to-end 476 across Internet paths. 478 Middleboxes may utilise the connection information (address, port, 479 Service Code) to establish local forwarding state. This has been the 480 main motivation for adding the Service Code field to the DCCP-Listen 481 packet: in combination with the source and destination addresses 482 found in the enclosing IP-header, the DCCP-Listen packet thereby 483 communicates all the information necessary to uniquely identify a 484 DCCP session. 486 2.4. Examples of Use 488 In the examples below, DCCP A is the client and DCCP B is the server. 489 NAT/Firewall device NA is placed before DCCP A, and NAT/Firewall 490 device NB is placed before DCCP B. 492 Both NA and NB use a policy that permits DCCP packets to traverse the 493 device for outgoing links, but only permit incoming DCCP packets when 494 a previous packet has been sent out for the same connection. 496 DCCP A and DCCP B decide to communicate using some out-of-band 497 mechanism, whereupon the client and server are started. DCCP A 498 initiates a connection by sending a DCCP-Request. DCCP B actively 499 indicates its state by sending a Listen message. This fulfils the 500 requirement of punching a hole in NB so that DCCP A can retransmit 501 the DCCP-Request and connect through it. 503 DCCP A DCCP B 504 ------ NA NB ------ 505 +------------------+ +-+ +-+ +-----------------+ 506 |(1) Initiation | | | | | | | 507 |DCCP-Request --> +--+-+---X| | | | 508 | |<-+-+----+-+--+<-- DCCP-Listen | 509 | | | | | | | | 510 |DCCP-Request --> +--+-+----+-+->| | 511 | |<-+-+----+-+--+<-- DCCP-Response| 512 |DCCP-Ack --> +--+-+----+-+->| | 513 | | | | | | | | 514 |(2) Data transfer | | | | | | | 515 |DCCP-Data --> +--+-+----+-+->| | 516 +------------------+ +-+ +-+ +-----------------+ 518 Sequence of events when a client is started before the server 520 The diagram below reverses this sequencing: 522 DCCP A DCCP B 523 ------ NA NB ------ 524 +------------------+ +-+ +-+ +-----------------+ 525 |(1) Initiation | | | | | | | 526 | | | |X---+-+--+<-- DCCP-Listen | 527 |DCCP-Request --> +--+-+----+-+->| | 528 | | <+-+----+-+--+<-- DCCP-Response| 529 |DCCP-Ack --> +--+-+----+-+> | | 530 | | | | | | | | 531 |(2) Data transfer | | | | | | | 532 |DCCP-Data --> +--+-+----+-+> | | 533 +------------------+ +-+ +-+ +-----------------+ 535 Sequence of events when a server is started before the client 537 2.5. Backwards Compatibility with RFC 4340 539 This document updates the connection-establishment procedures of 540 [RFC4340]. 542 There are no changes if a client implementing the extensions 543 described in this document communicates with a server conforming to 544 [RFC4340]. 546 This document also does not modify communication for any server that 547 implements a passive-open without fully binding the addresses, ports 548 and service codes to be used. 550 The receipt of a DCCP-Listen packet by a client that implements only 551 [RFC4340] would lead to a DCCP-Reset (likely using code 4, "Packet 552 Error" if the unknown packet type passes through). This would abort 553 the connection. 555 The authors do not however expect these compatibility issues to 556 introduce practical deployment problems. 558 3. Discussion of Design Decisions 560 3.1. Rationale for a New Packet Type 562 The DCCP-Listen packet specified in Section 2.2 has the same format 563 as the DCCP-Request packet ([RFC4340], sec. 5.1), the only difference 564 is in the value of the Type field. 566 The usage however differs, since the DCCP-Listen serves as advisory 567 message, not as part of the actual connection setup: sequence numbers 568 have no meaning, and neither options nor payload are present. 570 It is important to point out that a DCCP-Request packet could in 571 theory also serve as indicator message, in the same way as the DCCP- 572 Listen packet. The following arguments were against this 573 alternative. 575 The first problem is that of semantic overloading: the Request is 576 defined in [RFC4340] to serve a well-defined purpose, as the first 577 packet of the 3-way handshake. Additionally using it in the way as 578 here specified for the DCCP-Listen packet would require DCCP 579 processors to have two different processing paths: one where a 580 Request is interpreted as part of the initial handshake, and one 581 where the same packet is interpreted as indicator message. This 582 complicates packet processing in hosts and in particular stateful 583 middleboxes (which may have restricted computational resources). 585 The second problem is that a client receiving a DCCP-Request from a 586 server could generate a Reset if it has not yet entered the REQUEST 587 state. This document addresses that issue by asking clients to 588 ignore DCCP-Listen packets in any state. Adding a similar rule for 589 the Request packet is more cumbersome: clients can not distinguish 590 between a Request meant to be an indicator message and a genuinely 591 erratic connection initiation. 593 The third problem is similar and refers to a client receiving the 594 DCCP-Listen after having itself sent a (connection-initiation) 595 Request. Step 7 in section 8.5 of [RFC4340] requires the client to 596 reply to an (indicator message) Request from the server with a Sync. 597 However, sequence numbers are ignored for this type of message, so 598 additional and complicating processing becomes necessary: either to 599 ask the client not to respond to a Request when the Request of type 600 "indicator message"; or ask middleboxes and servers to ignore Sync 601 packets generated in response to Request packets serving as indicator 602 message. Furthermore, since no initial sequence numbers have been 603 negotiated yet, sending a SyncAck would not be meaningful. 605 Using a separate packet type allows simpler and clearer processing. 607 The rationale for ignoring the Sequence Number fields on DCCP-Listen 608 packets is that endpoints have not yet entered connection setup: the 609 Listen packet is sent out while the server is still in the passive- 610 open (INVITED) state, i.e. it has not yet allocated state other than 611 binding to the client's IP-address:port and service code. 613 Although the Sequence Number fields thus do not serve a purpose, both 614 have been retained, to reuse the generic header format from section 615 5.1 of [RFC4340]. 617 3.2. Generation of Listen Packets 619 Since DCCP-Listen packets solve a particular problem (NAT and/or 620 firewall traversal), the generation of DCCP-Listen packets on passive 621 sockets has been tied to a condition (binding to an a priori known 622 remote address and service code), so as to not interfere with the 623 general case of "normal" DCCP connections (where client addresses are 624 generally not known in advance). 626 In the TCP world, the analogue is a transition from LISTEN to 627 SYN_SENT by virtue of sending data: "A fully specified passive call 628 can be made active by the subsequent execution of a SEND" ([RFC0793], 629 3.8). 631 Unlike TCP, this proposal does not perform a role-change from passive 632 to active. 634 Like TCP, we require that DCCP-Listen packets are only sent by a 635 DCCP-server when the endpoint is fully specified (Section 2.3). 637 3.3. Repetition of Listen Packets 639 Repetition is a necessary requirement to increase robustness and the 640 chance of successful connection establishment, in case a Listen 641 packet is lost due to congestion, link loss or some other reason. 643 Recommending a maximum number of 3 timeouts (2 repetitions) is due to 644 the following considerations. The repeated copies need to be spaced 645 sufficiently far apart in time to avoid suffering from correlated 646 loss. The interval of 200ms has been chosen to accommodate a wide 647 range of wired and wireless network paths. 649 Another constraint is given by the retransmission interval for the 650 DCCP-Request. To establish state, intermediate systems need to 651 receive a (retransmitted) DCCP-Listen packet before the DCCP-Request 652 times out (1 second, cf. section 8.1.1 of [RFC4340]). With three 653 timeouts, each spaced 200 milliseconds apart, the overall time is 654 still less than this value. On the other hand, the sum of 600 655 milliseconds is sufficiently large to provide for large one-way 656 delays, such as e.g. found on some wireless links. 658 The rationale behind transitioning to the LISTEN state after two 659 retransmissions is that other problems, independent of establishing 660 middlebox state, may occur (such as (delay or loss of the initial 661 DCCP-Request). Any late or retransmitted DCCP-Request packets will 662 in such cases still reach the server, thus allowing connection 663 establishment to succeed. 665 4. IANA Considerations 667 This document requires IANA action by allocation of a new Packet Type 668 from the IANA DCCP Packet Types Registry. The name of the Packet 669 Type is "DCCP-Listen" packet, and its type field is set to XX-IANA- 670 assigned-XX. 672 The Registry entry is to reference this document. 674 Note to the RFC Editor: 676 Please replace XX-IANA-assigned-XX in the above paragraph with the 677 value assigned in the registry and remove this note. 679 5. Security Considerations 681 The method specified in this document exposes the state of a DCCP 682 server that has been explicitly configured to accept a connection 683 from a known client. Establishing this state requires prior out-of- 684 band signaling between the client and server (e.g. via SIP). The 685 technique generates a packet addressed to the expected client. 687 This increases the vulnerability of the DCCP server, by revealing 688 which ports are in a passive listening state (the information is not 689 encrypted and therefore could be seen on the path to the client 690 through the network). 692 This document requires endpoint nodes to ignore reception of DCCP- 693 Listen packets in any state other than LISTEN. 695 We do not believe these changes significantly increase the complexity 696 or vulnerability of a DCCP implementation that conforms to [RFC4340]. 698 6. References 700 6.1. Normative References 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 706 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 708 6.2. Informative References 710 [Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software 711 Approach to Solving the NAT Problem", Carnegie Mellon 712 University/ISRI Technical Report CMU-ISRI-05-104, 713 January 2005. 715 [FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 716 Communication Across Network Address Translators", 717 Proceedings of USENIX-05, pages 179-192, 2005. 719 [GBF+07] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 720 Srisuresh, "NAT Behavioral Requirements for TCP", Work In 721 Progress, draft-ietf-behave-tcp-07, April 2007. 723 [GF05] Guha, S. and P. Francis, "Characterization and Measurement 724 of TCP Traversal through NATs and Firewalls", Proceedings 725 of Internet Measurement Conference (IMC-05), pages 199- 726 211, 2005. 728 [GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based 729 approach to UDP and TCP connectivity", Proceedings of 730 SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004. 732 [H.323] ITU-T, "Packet-based Multimedia Communications Systems", 733 Recommendation H.323, July 2003. 735 [NAT-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design 736 Guidelines for Traversal through Network Address 737 Translators", Work In Progress, draft-ford-behave-app-05, 738 March 2007. 740 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 741 RFC 793, September 1981. 743 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 744 Translator (NAT) Terminology and Considerations", 745 RFC 2663, August 1999. 747 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 748 Address Translator (Traditional NAT)", RFC 3022, 749 January 2001. 751 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 752 Application Design Guidelines", RFC 3235, January 2002. 754 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 755 A., Peterson, J., Sparks, R., Handley, M., and E. 756 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 757 June 2002. 759 [Ros07] Rosenberg, J., "TCP Candidates with Interactive 760 Connectivity Establishment (ICE)", Work In 761 Progress, draft-ietf-mmusic-ice-tcp-05, November 2007. 763 [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 764 Relays around NAT (TURN): Relay Extensions to Session 765 Traversal Utilities for NAT (STUN)", Work In 766 Progress, draft-ietf-behave-turn-06, January 2008. 768 Appendix A. Change Log 770 Revision 00 retrieved from previous individual submission 771 draft-fairhurst-dccp-behave-update-01 by the same authors. 773 Authors' Addresses 775 Godred Fairhurst 776 University of Aberdeen 777 School of Engineering 778 Fraser Noble Building 779 Aberdeen AB24 3UE 780 Scotland 782 Email: gorry@erg.abdn.ac.uk 783 URI: http://www.erg.abdn.ac.uk 785 Gerrit Renker 786 University of Aberdeen 787 School of Engineering 788 Fraser Noble Building 789 Aberdeen AB24 3UE 790 Scotland 792 Email: gerrit@erg.abdn.ac.uk 793 URI: http://www.erg.abdn.ac.uk 795 Full Copyright Statement 797 Copyright (C) The IETF Trust (2008). 799 This document is subject to the rights, licenses and restrictions 800 contained in BCP 78, and except as set forth therein, the authors 801 retain all their rights. 803 This document and the information contained herein are provided on an 804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 806 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 807 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 808 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 811 Intellectual Property 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at 833 ietf-ipr@ietf.org. 835 Acknowledgment 837 Funding for the RFC Editor function is provided by the IETF 838 Administrative Support Activity (IASA).