idnits 2.17.1 draft-ietf-dccp-serv-codes-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 26, 2009) is 5441 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 415 -- Looks like a reference, but probably isn't: '1' on line 415 -- Looks like a reference, but probably isn't: '2' on line 415 -- Looks like a reference, but probably isn't: '3' on line 418 == Unused Reference: 'RFC862' is defined on line 787, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DCCP WG G.Fairhurst 2 Internet-Draft University of Aberdeen 3 Intended status: Proposed Standard May 26, 2009 4 Expires: October 31, 2009 5 Updates: RFC 4340 7 The DCCP Service Code 8 draft-ietf-dccp-serv-codes-11.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 26, 2009. 33 Abstract 35 This document describes the usage of Service Codes by the Datagram 36 Congestion Control Protocol, RFC 4340. It motivates the setting of a 37 Service Code by applications. Service Codes provide a method to 38 identify the intended service/application to process a DCCP 39 connection request. This provides improved flexibility in the use and 40 assignment of port numbers for connection multiplexing. The use of a 41 DCCP Service Code can also enable more explicit coordination of 42 services with middleboxes (e.g. network address translators and 43 firewalls). This document updates the specification provided in RFC 44 4340. 46 Table of Contents 48 1. Introduction...................................................3 49 1.1. History...................................................3 50 1.2. Conventions used in this document.........................6 51 2. An Architecture for Service Codes..............................6 52 2.1. IANA Port Numbers.........................................6 53 2.2. DCCP Service Code Values..................................8 54 2.2.1. New versions of Applications or Protocols............8 55 2.3. Service Code Registry.....................................9 56 2.4. Zero Service Code.........................................9 57 2.5. Invalid Service Code......................................9 58 2.6. SDP for describing Service Codes..........................9 59 2.7. A method to hash the Service Code to a Dynamic Port......10 60 3. Use of the DCCP Service Code..................................10 61 3.1. Setting Service Codes at the Client......................11 62 3.2. Using Service Codes in the Network.......................11 63 3.3. Using Service Codes at the Server........................12 64 3.3.1. Reception of a DCCP-Request.........................13 65 3.3.2. Multiple Associations of a Service Code with Ports..14 66 3.3.3. Automatically launching a Server....................14 67 4. Security Considerations.......................................14 68 4.1. Server Port number re-use................................15 69 4.2. Association of applications with Service Codes...........15 70 4.3. Interactions with IPsec..................................16 71 5. IANA Considerations...........................................16 72 6. Acknowledgments...............................................16 73 7. References....................................................17 74 7.1. Normative References.....................................17 75 7.2. Informative References...................................17 76 8. Author's Addresses............................................19 77 8.1. Disclaimer...............................................19 78 8.2. Copyright Notice.........................................19 80 1. Introduction 82 DCCP specifies a Service Code as a 4-byte value (32 bits) that 83 describes the application-level service to which a client application 84 wishes to connect ([RFC4340], section 8.1.2). A Service Code 85 identifies the protocol (or a standard profile, e.g. [ID.RTP]) to be 86 used at the application layer. It is not intended to be used to 87 specify a variant of an application, or a specific variant of a 88 protocol (Section 2.2). 90 The Service Code mechanism allows an application to declare the set 91 of services that are associated with server port numbers. This can 92 affect how an application interacts with DCCP. It allows decoupling 93 the role of port numbers to indicate a desired service from the role 94 in connection demultiplexing and state management. A DCCP application 95 identifies the requested service by the Service Code value in a DCCP- 96 Request packet. Each application therefore associates one or more 97 Service Codes with each listening port ([RFC4340], section 8.1.2). 99 The use of Service Codes can assist in identifying the intended 100 service by a firewall and may assist other middleboxes (e.g., a proxy 101 server, network address translator (NAT) [RFC2663]). Middleboxes that 102 desire to identify the type of data a flow claims to transport, 103 should utilize the Service Code for this purpose. When consistently 104 used, the Service Code can provide a more specific indication of the 105 actual service (e.g. indicating the type of multimedia flow, or 106 intended application behaviour). 108 The more flexible use of server ports can also offer benefit to 109 applications where servers need to handle very large numbers of 110 simultaneous open ports to the same service. 112 RFC 4340 omits to describe the motivation behind Service Codes, nor 113 does it properly describe how Well Known and Registered server ports 114 relate to Service Codes. The intent of this document is to clarify 115 these issues. 117 1.1. History 119 It is simplest to understand the motivation for defining Service 120 Codes by describing the history of the DCCP protocol. 122 Most current Internet transport protocols (TCP [RFC793], UDP 123 [RFC768], SCTP [RFC4960], UDP-Lite [RFC3828]) used "Published" port 124 numbers from the Well Known or registered number spaces [RFC814]. 126 These 16-bit values indicate the application service associated with 127 a connection or message. The server port must be known to the client 128 to allow a connection to be established. This may be achieved using 129 out-of-band signaling (e.g. described using SDP [RFC4566]), but more 130 commonly a Published port is allocated to a particular protocol or 131 application; for example HTTP commonly uses port 80 and SMTP commonly 132 uses port 25. Making a port number Published [RFC1122] involves 133 registration with the Internet Assigned Numbers Authority (IANA), 134 which includes defining a service by a unique keyword and reserving a 135 port number from among a fixed pool [IANA]. 137 In the earliest draft of DCCP, the authors wanted to address the 138 issue of Published ports in a future-proof manner, since this method 139 suffers from several problems: 141 o The port space is not sufficiently large for ports to be easily 142 allocated (e.g. in an unregulated manner). Thus, many 143 applications operate using unregistered ports, possibly colliding 144 with use by other applications. 146 o The use of port-based firewalls encourages application-writers to 147 disguise one application as another in an attempt to bypass 148 firewall filter rules. This motivates firewall writers to use deep 149 packet inspection in an attempt to identify the service associated 150 with a port number. 152 o ISPs often deploy transparent proxies, primarily to improve 153 performance and reduce costs. For example, TCP requests destined 154 to TCP port 80 are often redirected to a web proxy. 156 These issues are coupled. When applications collide on the same 157 Published, but unregistered port, there is no simple way for network 158 security equipment to tell them apart, with the likelihood of 159 introducing problems with interaction of features. 161 There is little that a transport protocol designer can do about 162 applications that attempt to masquerade as other applications. For 163 ones that are not attempting to hide, the problem may be simply that 164 they cannot trivially obtain a Published port. Ideally, it should be 165 sufficiently easy that every application-writer can request a Well 166 Known or registered port and receive one instantly with no questions 167 asked. The 16-bit port space traditionally used is not large enough 168 to support such a trivial allocation of ports. 170 Thus, the design of DCCP sought an alternative solution. The idea 171 was simple. A 32-bit server port space should be sufficiently large 172 that it enables use of very simple allocation policies. However, 173 overhead considerations made a 32-bit port value undesirable (DCCP 174 needed to be useful for low rate applications). 176 The solution in DCCP to this problem was to use a 32-bit Service Code 177 [RFC4340] that is included only in the DCCP-Request packet. The use 178 of a 32-bit value was intended to make it trivially simple to obtain 179 a unique value for each application. Placing the value in a DCCP- 180 Request packet, requires no additional overhead for the actual data 181 flow. It is however sufficient for both the end systems, and 182 provides any stateful middleboxes along the path with additional 183 information to understand what applications are being used. 185 Early discussion of the DCCP protocol considered an alternative to 186 the use of traditional ports; instead it was suggested that a client 187 used a 32-bit identifier to uniquely identify each connection. The 188 server listened on a socket bound only to a Service Code. This 189 solution was unambiguous; the Service Code was the only identifier 190 for a listening socket at the server side. The DCCP client included a 191 Service Code in the request, allowing it to reach the corresponding 192 listening application. One downside was that this prevented 193 deployment of two servers for the same service on a single machine, 194 something that is trivial with ports. The design also suffered from 195 the downside of being sufficiently different from existing protocols 196 that there were concerns that it would hinder the use of DCCP through 197 NATs and other middleboxes. 199 RFC 4340 abandoned the use of a 32-bit connection identifier in favor 200 of two traditional 16-bit port values, one chosen by the server and 201 one by the client. This allows middleboxes to utilize similar 202 techniques for DCCP, UDP, TCP, etc. However, it introduced a new 203 problem: "How does the server port relate to the Service Code?" The 204 intent was that the Service Code identified the application or 205 protocol using DCCP, providing middleboxes with information about the 206 intended use of a connection, and that the pair of ports effectively 207 formed a 32-bit connection identifier, which was unique between a 208 pair of end-systems. 210 The large number of available unique Service Code values allows all 211 applications to be assigned a unique Service Code. However, there 212 remains a current problem: The server port is chosen by the server, 213 but the client needs to know this to establish a connection. It was 214 undesirable to mandate out-of-band communication to discover the 215 server port. A solution is to register DCCP server ports. The 216 limited availability of DCCP server ports appears to contradict the 217 benefits of DCCP Service Codes, because although it may be trivial to 218 obtain a Service Code, it has not traditionally been trivial to 219 obtain a registered port from IANA and in the long-run it may not be 220 possible to uniquely allocate a unique registered DCCP port to new 221 applications. As port numbers become scarce, this motivates the need 222 to associate more than one Service Code with a listening port (e.g. 223 two different applications could be assigned the same server port, 224 and need to run on the same host at the same time, differentiated by 225 their different associated Service Codes. 227 Service Codes provide flexibility in the way clients identify the 228 server application to which they wish to communicate. The mechanism 229 allows a server to associate a set of server ports with a service. 230 The set may be common with other services available at the same 231 server host, allowing a larger number of concurrent connections for a 232 particular service than possible when the service is identified by a 233 single Published port number. 235 There has been confusion concerning how server ports relate to 236 Service Codes. The goal of this document is to clarify this and the 237 issues concerning the use of Service Codes. 239 RFC4340 states that Service Codes are not intended to be DCCP- 240 specific. Service Codes, or similar concepts may therefore also be 241 useful to other IETF transport protocols. 243 1.2. Conventions used in this document 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [RFC2119]. 249 2. An Architecture for Service Codes 251 DCCP defines the use of a combination of ports and Service Codes to 252 identify the server application ([RFC4340], section 8.1.2). These are 253 described in the following Sections. 255 2.1. IANA Port Numbers 257 In DCCP, the packets belonging to a connection are de-multiplexed 258 based on a combination of four values {source IP address, source 259 port, dest IP address, dest port}, as in TCP. An endpoint address is 260 associated with a port number, (e.g. forming a socket); and a pair of 261 associations uniquely identifies each connection. Ports provide the 262 fundamental per-packet de-multiplexing function. 264 The Internet Assigned Numbers Authority currently manages the set of 265 globally reserved port numbers [IANA]. The source port associated 266 with a connection request, often known as the "ephemeral port", is 267 traditionally in the range 49152-65535, and also includes the range 268 1024-49151. The value used for the ephemeral port is usually chosen 269 by the client operating system. It has been suggested that a 270 randomized choice of port number value can help defend against 271 "blind" attacks [ID.Rand] in TCP. This method may be applicable to 272 other IETF-defined transport protocols, including DCCP. 274 Traditionally, the destination (server) port value associated with a 275 service is determined either by an operating system index to a copy 276 of the IANA table (e.g., getportbyname() in Unix, which indexes the 277 /etc/services file), or directly mapped by the application. 279 The UDP and TCP port number space: 0..65535, is split into three 280 ranges [RFC2780]: 282 o 0..1023 "Well Known", also called "system" ports, 284 o 1024..49151 "registered", also called "user" ports, 286 o 49152..65535 "dynamic", also called "private" ports. 288 DCCP supports Well Known and registered ports. These are allocated in 289 the DCCP IANA port numbers registry ([RFC4340], Section 19.9). Each 290 registered DCCP port MUST be associated with at least one pre-defined 291 Service Code. 293 Applications that do not need to use a server port in the Well Known 294 or registered range SHOULD use a dynamic server port (i.e. that does 295 not require to be registered in the DCCP port registry). Clients can 296 identify the server port value for the services to which they wish to 297 connect using a range of methods. One common method is by reception 298 of a SDP record (Section 2.6) exchanged out-of-band (e.g. using SIP 299 [RFC3261] or RTSP [RFC2326]). DNS SRV resource records also provide a 300 way to identify a server port for a particular service based on the 301 services string name [RFC2782]. 303 Applications that do not use out-of-band signalling can still 304 communicate, providing that both client and server agree the port 305 value to be used. This eliminates the need for each registered 306 Service Code to be allocated an IANA-assigned server port (see also 307 Section 2.7). 309 2.2. DCCP Service Code Values 311 DCCP specifies a 4 byte Service Code ([RFC4340], section 8.1.2) 312 represented in one of three forms: a decimal number (the canonical 313 method), a four character ASCII string [ANSI.X3-4.1986], or an eight 315 digit hexadecimal number. All standards assigned Service Codes, 316 including all values assigned by IANA, are required to use a value 317 that may be represented using a subset of the ASCII character set. 318 Private Service Codes do not need to follow this convention, although 319 RFC 4340 suggests that users also choose Service Codes that may also 320 be represented in ASCII. 322 The Service Code identifies the application-level service to which a 323 client application wishes to connect. Examples of services are RTP 324 [ID.RTP], TIME (this document), ECHO (this document). In a different 325 example, DTLS [RFC5238] provides a transport-service (not an 326 application-layer service), therefore applications using DTLS are 327 individually identified by a set of corresponding Service Code 328 values. 330 Endpoints MUST associate a Service Code with every DCCP socket 331 [RFC4340], both actively and passively opened. The application will 332 generally supply this Service Code. A single passive listening port 333 may be associated with more than one Service Code value. The set of 334 Service Codes could be associated with one or more server 335 applications. This permits a more flexible correspondence between 336 services and port numbers than possible using the corresponding 337 socket pair (4-tuple of layer-3 addresses and layer-4 ports). In the 338 currently defined set of packet types, the Service Code value is 339 present only in DCCP-Request ([RFC4340], section 5.2) and DCCP- 340 Response packets ([RFC4340], section 5.3). Note new DCCP packet types 341 (e.g. [ID.Simul]) could also carry a Service Code value. 343 2.2.1. New versions of Applications or Protocols 345 Applications/protocols that provide version negotiation or indication 346 in the protocol operating over DCCP do not require a new server port 347 or new Service Code for each new protocol version. New versions of 348 such applications/protocols SHOULD continue to use the same Service 349 Code. If the application developers feel that the new version 350 provides significant new capabilities (e.g. that will change the 351 behavior of middleboxes), they MAY allocate a new Service Code 352 associated with the same or a different set of Well Known ports. If 353 the new Service Code is associated with a Well Known or registered 354 port, the DCCP Ports registry MUST also be updated to include the new 355 Service Code value, but MAY share the same server port assignment(s). 357 2.3. Service Code Registry 359 The set of registered Service Codes specified for use within the 360 general Internet are defined in an IANA-controlled name space. IANA 361 manages new allocations of Service Codes in this space ([RFC4340]). 362 Private Service Codes are not centrally allocated and are denoted by 363 the decimal range 1056964608-1073741823 (i.e. 32-bit values with the 364 high-order byte equal to a value of 63, corresponding to the ASCII 365 character '?'). 367 Associations of Service Code with Well Known Ports are also defined 368 in the IANA DCCP Port Registry (section 2.1). 370 2.4. Zero Service Code 372 A Service Code of zero is "permanently reserved (it represents the 373 absence of a meaningful Service Code)" [RFC4340]. This indicates that 374 no application information was provided. RFC 4340 states that 375 applications MAY be associated with this Service Code in the same way 376 as other Service Code values. This use is permitted for any server 377 port. 379 This document clarifies section 19.8 of RFC 4340, by adding the 380 following: 382 "Applications SHOULD NOT use a Service Code of zero. 384 Application writers that need a temporary Service Code value SHOULD 385 choose a value from the private range (section 2.3). 387 Applications intended for deployment in the Internet are encouraged 388 to use an IANA-defined Service Code. If no specific Service Code 389 exists, they SHOULD request a new assignment from the IANA." 391 2.5. Invalid Service Code 393 RFC4340 defines the Service Code value of 0xFFFFFFFF as Invalid. This 394 is provided so implementations can use a special four-byte value to 395 indicate "no valid Service Code". Implementations MUST NOT accept a 396 DCCP-Request with this value, and SHOULD NOT allow applications to 397 bind to this Service Code value [RFC4340]. 399 2.6. SDP for describing Service Codes 401 Methods that currently signal destination port numbers, such as the 402 Session Description Protocol (SDP) [RFC4566] require extension to 403 support DCCP Service Codes [ID.RTP]. 405 2.7. A method to hash the Service Code to a Dynamic Port 407 Applications that do not use out-of-band signalling, or an IANA- 408 assigned port still require both the client and server to agree the 409 server port value to be used. This Section describes an optional 410 method that allows an application to derive a default server port 411 number from the Service Code. The returned value is in the dynamic 412 port range [RFC4340]: 414 int s_port; /* server port */ 415 s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000; 416 if (s_port==0xFFFF) {s_port = 0xC000;} 418 Where sc[] represents the four bytes of the Service Code, and sc[3] 419 is the least significant byte, for example this function associates 420 SC:fdpz with the server port 64634. 422 This algorithm has the following properties: 424 o It identifies a default server port for each service. 426 o It seeks to assign different Service Codes to different ports, but 427 does not guarantee an assignment is unique. 429 o It preserves the four bits of the final bytes of the Service Code, 430 allowing mapping common series of Service Codes to adjacent ports, 431 e.g. Foo1, and Foo2; and Fooa and Foob would be assigned adjacent 432 ports. (Note: this consecutive numbering only applies to 433 characters in the range 0-9 and A-O and P-Z. When the characters 434 cross a range boundary, the algorithm introduces a discontinuity, 435 resulting in mapping to non-consecutive ports. Hence Fooo and Foop 436 respectively map to the decimal values of 65015 and 65000). 438 o It avoids the port 0xFFFF, which is not accessible on all host 439 platforms. 441 Applications and higher-layer protocols that have been assigned a 442 Service Code (or use a Service Code from the unassigned private 443 space) may use this method. It does not preclude other applications 444 using the selected server port, since DCCP servers are 445 differentiated by the Service Code value. 447 3. Use of the DCCP Service Code 449 The basic operation of Service Codes is as follows: 451 A client initiating a connection: 453 . issues a DCCP-Request with a Service Code and chooses a 454 destination (server) port number that is expected to be 455 associated with the specified Service Code at the destination. 457 o A server that receives a DCCP-Request: 459 . determines whether an available service matching the Service 460 Code is supported for the specified destination server port. 461 The session is associated with the Service Code and a 462 corresponding server. A DCCP-Response is returned. 464 . if the service is not available, the session is rejected and a 465 DCCP-Reset packet is returned. 467 3.1. Setting Service Codes at the Client 469 A client application MUST associate every DCCP connection (and hence 470 every DCCP active socket) with a single Service Code value 471 [RFC4340]). This value is used in the corresponding DCCP-Request 472 packet. 474 3.2. Using Service Codes in the Network 476 DCCP connections identified by the Service Code continue to use IP 477 addresses and ports, although neither port number may be Published. 479 Port numbers and IP addresses are the traditional methods to identify 480 a flow within an IP network. Middlebox [RFC3234] implementors 481 therefore need to note that new DCCP connections are identified by 482 the pair of Server Port and Service Code in addition to the IP 483 address. This means that the IANA may allocate a server port to more 484 than one DCCP application [RFC4340]. 486 Network address and port translators, known collectively as NATs 487 [RFC2663], may interpret DCCP ports [RFC2993] [ID.Behave-DCCP]. They 488 may also interpret DCCP Service Codes. Interpreting DCCP Service 489 Codes can reduce the need to correctly interpret port numbers, 490 leading to new opportunities for network address and port 491 translators. Although it is encouraged to associate specific delivery 492 properties with the Service Code, e.g. to identify the real-time 493 nature of a flow that claims to be using RTP, there is no guarantee 494 that the actual connection data corresponds to the associated Service 495 Code. A middlebox implementor may still use deep packet inspection, 496 and other means, in an attempt to verify the content of a connection. 498 The use of the DCCP Service Code can potentially lead to interactions 499 with other protocols that interpret or modify DCCP port numbers 500 [RFC3234]. The following additional clarifications update the 501 description provided in section 16 of RFC 4340: 503 o "A middlebox that intends to differentiate applications SHOULD 504 test the Service Code in addition to the destination or source 505 port of a DCCP-Request or DCCP-Response packet. 507 o A middlebox that does not modify the intended application (e.g. 508 NATs [ID.Behave-DCCP] and Firewalls), MUST NOT change the Service 509 Code. 511 o A middlebox MAY send a DCCP-Reset in response to a packet with a 512 Service Code that is considered unsuitable." 514 3.3. Using Service Codes at the Server 516 The combination of the Service Code and server port disambiguates 517 incoming DCCP-Requests received by a server. The Service Code is used 518 to associate a new DCCP connection with the corresponding application 519 service. Four cases can arise when two DCCP server applications 520 passively listen on the same host: 522 o The simplest case arises when two servers are associated with 523 different Service Codes and are bound to different server ports 524 (section 3.3.1). 526 o Two servers may be associated with the same DCCP Service Code 527 value, but be bound to different server ports (section 3.3.2). 529 o Two servers could use different DCCP Service Code values, and be 530 bound to the same server port (section 3.3.1). 532 o Two servers could attempt to use the same DCCP Service Code and 533 bind to the same server port. A DCCP implementation MUST disallow 534 this, since there is no way for the DCCP host to direct a new 535 connection to the correct server application. 537 RFC 4340 (section 8.1.2) states that an implementation: 539 o MUST associate each active socket with exactly one Service Code on 540 a specified server port. 542 In addition, section 8.1.2 also states: 544 o "Passive sockets MAY, at the implementation's discretion, be 545 associated with more than one Service Code; this might let 546 multiple applications, or multiple versions of the same 547 application, listen on the same port, differentiated by Service 548 Code." 550 This document updates this text in RFC 4340 by replacing this with 551 the following: 553 o "An implementation SHOULD allow more than one Service Code to be 554 associated with a passive server port, enabling multiple 555 applications, or multiple versions of an application, to listen on 556 the same port, differentiated by the associated Service Code." 558 It also adds: 560 o "An implementation SHOULD provide a method that informs a server 561 of the Service Code value that was selected by an active 562 connection." 564 A single passively opened (listening) port MAY therefore be 565 associated with multiple Service Codes, although an active (open) 566 connection can only be associated with a single Service Code. A 567 single application may wish to accept connections for more than one 568 Service Code using the same server port. This may allow a server to 569 offer more than the limit of 65,536 services determined by the size 570 of the Port field. The upper limit is based solely on the number of 571 unique connections between two hosts (i.e., 4,294,967,296). 573 3.3.1. Reception of a DCCP-Request 575 When a DCCP-Request is received, and the specified destination port 576 is not bound to a server, the host MUST reject the connection by 577 issuing a DCCP-Reset with Reset Code "Connection Refused". A host MAY 578 also use the Reset Code "Too Busy" ([RFC4340], section 8.1.3). 580 When the requested destination port is bound to a server, the host 581 MUST also verify that the server port is associated with the 582 specified Service Code (there could be multiple Service Code values 583 associated with the same server port). Two cases can occur: 585 o If the receiving host is listening on a server port and the DCCP- 586 Request uses a Service Code that is associated with the port, the 587 host accepts the connection. Once connected, the server returns a 588 copy of the Service Code in the DCCP-Response packet completing 589 the initial handshake [RFC4340]. 591 o If the server port is not associated with the requested Service 592 Code, the server SHOULD reject the request by sending a DCCP-Reset 593 packet with Reset Code 8, "Bad Service Code" ([RFC4340], Section 594 8.1.2), but MAY use the reason "Connection Refused". 596 After a connection has been accepted, the protocol control block is 597 associated with a pair of ports and a pair of IP addresses and a 598 single Service Code value. 600 3.3.2. Multiple Associations of a Service Code with Ports 602 DCCP Service Codes are not restricted to specific ports, although 603 they may be associated with a specific well-known port. This allows 604 the same DCCP Service Code value to be associated with more than one 605 server port (in either the active or passive state). 607 3.3.3. Automatically launching a Server 609 A host implementation may permit a service to be associated with a 610 server port (or range of ports) that is not permanently running at 611 the server. In this case, the arrival of a DCCP-Request may require a 612 method to associate a DCCP-Request with a server that handles the 613 corresponding Service Code. This operation could resemble that of 614 "inetd" [inetd]. 616 As in the previous Section, when the specified Service Code is not 617 associated with the specified server port, the connection MUST be 618 aborted and a DCCP Reset message sent [RFC4340]. 620 4. Security Considerations 622 The security considerations of RFC 4340 identifies and offers 623 guidance on security issues relating to DCCP. This document discusses 624 the usage of Service Codes. It does not describe new protocol 625 functions. 627 All IPsec modes protect the integrity of the DCCP header. This 628 protects the Service Code field from undetected modification within 629 the network. In addition, the IPsec Encapsulated Security Payload 630 (ESP) mode may be used to encrypt the Service Code field, hiding the 631 Service Code value within the network and also preventing 632 interpretation by middleboxes. The DCCP header is not protected by 633 application-layer security, (e.g., the use DTLS [RFC5238] as 634 specified in DTLS/DCCP [RFC4347]). 636 There are four areas of security that are important: 638 1. Server Port number reuse (section 5.1). 640 2. Interaction with NATs and firewalls (section 3.2 describes 641 middlebox behaviour). Requirements relating to DCCP are described 642 in [ID.Behave-DCCP]. 644 3. Interpretation of DCCP Service Codes over-riding traditional use 645 of reserved/Well Known port numbers (Section 5.2). 647 4. Interaction with IPsec and DTLS security (section 5.3). 649 4.1. Server Port number re-use 651 Service Codes are used in addition to ports when demultiplexing 652 incoming connections. This changes the service model to be used by 653 applications and middleboxes. The port-numbers registry already 654 contains instances of multiple application registrations for a single 655 port number for TCP and UDP. These are relatively rare. Since the 656 DCCP Service Code allows multiple applications to safely share the 657 same port number, even on the same host, server port number reuse in 658 DCCP may be more common than in TCP and UDP. 660 4.2. Association of applications with Service Codes 662 The use of Service Codes provides more ready feedback that a concrete 663 service is associated with a given port on a servers, than for a 664 service that does not employing service codes. By responding to an 665 inbound connection request, systems not using these codes may 666 indicate that some service is, or is not, available on a given port, 667 but systems using this mechanism immediately provide confirmation (or 668 denial) that a particular service is present. This may have 669 implications in terms of port scanning and reconnaissance. 671 Care needs to be exercised when interpreting the mapping of a Service 672 Code value to the corresponding service. The same service 673 (application) may be accessed using more than one Service Code. 674 Examples include the use of separate Service Codes for an application 675 layered directly upon DCCP and one using DTLS transport over DCCP 676 [RFC5238]. Other possibilities include the use of a private Service 677 Code that maps to the same application as assigned to an IANA-defined 678 Service Code value, or a single application that provides more than 679 one service. Different versions of a service (application) may also 680 be mapped to a corresponding set of Service Code values. 682 Processing of Service Codes may imply more processing than currently 683 associated with incoming port numbers. Implementers need to guard 684 against increasing opportunities for Denial of Service attack. 686 4.3. Interactions with IPsec 688 The Internet Key Exchange protocol (IKEv2), does not currently 689 specify a method to use DCCP Service Codes as a part of the 690 information used to setup an IPsec security association. 692 IPsec uses port numbers to perform access control in transport mode 693 [RFC4301]. Security policies can define port-specific access control 694 (PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and 695 keys. Similarly, firewall policies allow or block traffic based on 696 port numbers. 698 Use of port numbers in IPsec selectors and firewalls may assume that 699 the numbers correspond to Well Known services. It is useful to note 700 that there is no such requirement; any service may run on any port, 701 subject to mutual agreement between the endpoint hosts. Use of the 702 Service Code may interfere with this assumption both within IPsec and 703 in other firewall systems, but it does not add a new vulnerability. 704 New implementations of IPsec and firewall systems may interpret the 705 Service Code when implementing policy rules, but should not rely on 706 either port numbers or Service Codes to indicate a specific service. 708 5. IANA Considerations 710 This document does not update the IANA allocation procedures for the 711 DCCP Port Number and DCCP Service Codes Registries as defined in RFC 712 4340. 714 For completeness, the document notes that it is not required to 715 supply an approved document (e.g. a published RFC) to support an 716 application for a DCCP Service Code or port number value, although 717 RFCs may be used to request Service Code values via the IANA 718 Considerations Section. A specification is however required to 719 allocate a Service Code that uses a combination of ASCII digits, 720 uppercase letters, and character space, '-', '.', and '/') [RFC4340]. 722 6. Acknowledgments 724 This work has been supported by the EC IST SatSix Project. 725 Significant contributions to this document resulted from discussion 726 with Joe Touch, and this is gratefully acknowledged. The author also 727 thanks Ian McDonald, Fernando Gont, Eddie Kohler, and the DCCP WG for 728 helpful comments on this topic, and Gerrit Renker for his help in 729 determining DCCP behaviour and review of this document. Mark Handley 730 provided significant input to the text on definition of Service Codes 731 and their usage. He also contributed much of the material that has 732 formed the historical background Section. 734 7. References 736 7.1. Normative References 738 [RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts: 739 Communication Layers, " STD 3, RFC 1122, Oct. 1989 740 (STANDARD). 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST 744 CURRENT PRACTICE). 746 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 747 Control Protocol (DCCP)", RFC 4340, Mar. 2006 (PROPOSED 748 STANDARD). 750 [ID.Behave-DCCP] R. Denis-Courmont, "Network Address Translation 751 (NAT) Behavioral Requirements for DCCP", IETF Work in 752 Progress, draft-ietf-behave-dccp-05.txt. 754 7.2. Informative References 756 [ANSI.X3-4.1986] American National Standards Institute, "Coded 757 Character Set - 7-bit American Standard Code for 758 Information Interchange", ANSI X3.4, 1986. 760 [IANA] Internet Assigned Numbers Authority, www.iana.org 762 [IANA.SC] IANA DCCP Service Code Registry 763 http://www.iana.org/assignments/service-codes 765 [ID.Simul] G. Fairhurst, G. Renker, "DCCP Simultaneous-Open Technique 766 to Facilitate NAT/Middlebox Traversal", IETF Work in 767 Progress, draft-ietf-dccp-simul-open-08.txt. 769 [ID.RTP] C. Perkins, "RTP and the Datagram Congestion Control 770 Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp- 771 rtp-07.txt. 773 [ID.Rand] M. Larsen, F. Gont, "Port Randomization", IETF Work in 774 Progress, draft-larsen-tsvwg-port-randomization-02.txt 776 [inetd] The extended inetd project, http://xinetd.org/ 778 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 779 August 1980. 781 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 782 793, Sept. 1981 (STANDARD). 784 [RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES", RFC 814, 785 July 1982 (UNKNOWN). 787 [RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983. 789 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 791 Streaming Protocol (RTSP)", RFC 2326, April 1998. 793 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 794 Translator (NAT) Terminology and Considerations", RFC 2663, 795 August 1999. 797 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 798 Values In the Internet Protocol and Related Headers", BCP 799 37, RFC 2780, March 2000. 801 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 802 specifying the location of services (DNS SRV)", RFC 2782, 803 February 2000. 805 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 806 November 2000. 808 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 809 Issues", RFC 3234, February 2002. 811 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 812 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 813 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 815 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 816 G. Fairhurst, "The Lightweight User Datagram Protocol (UDP- 817 Lite)", RFC 3828, July 2004. 819 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 820 Internet Protocol", RFC 4301, December 2005. 822 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 823 Security", RFC 4347, April 2006. 825 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 826 Description Protocol", RFC 4566, July 2006. 828 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol RFC 829 4960, September 2007. 831 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 832 the Datagram Congestion Control Protocol (DCCP)", RFC 5238, 833 May 2008. 835 8. Author's Addresses 837 Godred (Gorry) Fairhurst, 838 School of Engineering, 839 University of Aberdeen, 840 Kings College, 841 Aberdeen, AB24 3UE, 842 UK 843 Email: gorry@erg.abdn.ac.uk 844 URL: http://www.erg.abdn.ac.uk/users/gorry 846 8.1. Disclaimer 848 This document may contain material from IETF Documents or IETF 849 Contributions published or made publicly available before November 850 10, 2008. The person(s) controlling the copyright in some of this 851 material may not have granted the IETF Trust the right to allow 852 modifications of such material outside the IETF Standards Process. 853 Without obtaining an adequate license from the person(s) controlling 854 the copyright in such materials, this document may not be modified 855 outside the IETF Standards Process, and derivative works of it may 856 not be created outside the IETF Standards Process, except to format 857 it for publication as an RFC or to translate it into languages other 858 than English. 860 8.2. Copyright Notice 862 Copyright (c) 2009 IETF Trust and the persons identified as the 863 document authors. All rights reserved. 865 This document is subject to BCP 78 and the IETF Trust's Legal 866 Provisions Relating to IETF Documents in effect on the date of 867 publication of this document (http://trustee.ietf.org/license-info). 868 Please review these documents carefully, as they describe your rights 869 and restrictions with respect to this document. 871 >>> RFC Editor please remove this Section prior to publication. 873 Change Log. 875 01 introduced: 877 - a replacement of the word *range* when referring to sets of dccp 878 ports (they are not necessarily contiguous), noted by E. Kohler. 880 - Addition of some Service Codes in IANA Section. 882 02 introduced: 884 - add the use of profiles with DCCP, identified by Service Code, but 885 not the use of protocol variants. 887 - further detail on implementation levels (more input would be good) 889 - added security consideration for traffic generators 891 - added ref to UDPL for completeness 893 - Corrected NiTs found by Gerrit Renker 895 +++++++++++++++++++++++++++ 897 WG 00 (first WG version) 899 This introduced revisions to make it a WG document. 901 - Corrected language and responded to many helpful comments from 902 Fernando Gont and Ian McDonald. 904 - Added a test for which server behaviour is used. 906 - Added some speculative text on how to implement the SC. 908 - More input and discussion is requested from the WG. 910 - Added an informative appendix on host configuration. 912 - Merging of some Sections to remove repetition and clarify wording. 914 +++++++++++++++++++++++++++ 915 WG 01 917 Historical material was added. 919 Comments from the list have been included. 921 The concept of adding weak semantics to a SC=0 was removed. This was 922 added at the request of implementers, with the aim of offering easier 923 implementation on at least one target platform. It has been removed 924 in this document because it weakens interoperability and complicates 925 the Spec. 927 The proposal to allow several levels of support was introduced in 928 previous drafts following suggestions from the WG, but was removed in 929 this revision. The method was seen to introduce complexity, and 930 resulted in complex interoperability scenarios. 932 Removed "test" method, this was no longer required. 934 Draft was reorganized to improve clarity and simplify concepts. 936 ---- 938 WG 02 940 Updated following comments from Eddie Kohler. 942 ---- 944 WG 03 946 Fixed NiTs and addressed issues marked in previous version. 948 Added 2 para at end of port Section saying how to use Well Known 949 ports and that you do not need to register them. 951 ----- 953 WG 04 955 Cleaned English (removing duplication) 957 Checked text that updates RFC4340 (and remove duplicates). 959 Updated hash algorithm for SC->s_port 961 Updated to IANA Section. 963 Edits in response to feedback from Tom Phelan, et al. 965 ----- 967 WG-05: 969 Various Sections were updated following feedback from the list, some 970 specific comments were: 972 Tom Phelan suggested clarification was needed for the usage of well- 973 known ports in Section 1, and various other clarifications. 975 Eddie Kohler suggested reworking the midbox Section. 977 Eddie noted the hash function included the highest numbered port, 978 which is not accessible on all OS. 980 There was also discussion about the proper server port range to be 981 used with this method. After previous concerns that using registered 982 ports could have some (unknown) side effect, use was recommended in 983 the dynamic range. Text was added to this Section. 985 Discussions at IETF-71 lead to the idea to removing the IANA guidance 986 on maintaining the registries to a new document that defines the 987 policy across the set of transport registries. 989 Eddie noted that port-reuse is likely to be more common with DCCP 990 (security considerations). 992 Lars noted that rate-limiting benchmarking tools may be somewhat 993 undesirable, and this related to services for testing. 995 The text recommending an update to the IANA procedures for ports and 996 service codes has been moved to a TSV WG draft. 998 ----- 1000 WG-06: 1002 Updated the updating paragraphs to clarify the specific clauses of 1003 RFC 4340 are changed. Comments from Eddie and Colin. 1005 Very minor editorial corrections. 1007 ----- 1009 WG-07: 1011 Portname for Perf in registry changed to all lower case. 1013 Replaced para 2 of intro and updated later parts of the introduction 1014 (feedback in LC from Eddie). 1016 Added citation to the Behave WG Requirements for NATs (now in LC). 1018 ----- 1020 WG-08: 1022 New text to address editorial corrections proposed by Alfred Hoenes. 1024 ----- 1026 WG-09:Update following review feedback 1028 Gen-ART 1030 Section 3.2: Middlebox [RFC3234] implementors therefore need to note 1031 that new DCCP connections are identified by the pair of Server Port 1032 and Service Code. - Added "in addition to the IP address" to the end 1033 of the above sentence for clarity. 1035 Section 3.2: Updated sentence to read: This means that the IANA may 1036 allocate a server port to more than one DCCP application [RFC4340]. 1038 Section 3.3.2 rewritten as: DCCP Service Codes are not restricted to 1039 specific ports, although they may be associated with a specific well- 1040 known port. The same DCCP Service Code value may therefore be 1041 associated with more than one server port (in either the active or 1042 passive state). 1044 Section 5.3: Added: The Internet Key Exchange protocol (IKEv2), does 1045 not currently specify a method to use DCCP Service Codes as a part of 1046 the information used to setup an IPsec security association. 1048 Sec-Dir 1050 Section 5: Added: The security considerations of RFC 4340 identifies 1051 and offers guidance on security issues relating to DCCP. 1053 Section 5.2: Added new paragraph: The use of Service Codes provides 1054 more ready feedback that a concrete service is associated with a 1055 given port on a servers, than for a service that does not employing 1056 service codes. By responding to an inbound connection request, 1057 systems not using these codes may indicate that some service is, or 1058 is not, available on a given port, but systems using this mechanism 1059 immediately provide confirmation (or denial) that a particular 1060 service is present. This may have implications in terms of port 1061 scanning and reconnaissance. 1063 ----- 1065 WG-10:Update following IESG review feedback 1067 Typo reported by Iain Calder was fixed: simply to obtain 1068 s/simply/simple/. 1070 Fixed syntax error reported by Jari in the sample pseudo code, and 1071 added more discussion of the algorithm. 1073 A clarification of ASCII usage, suggested by: 1075 Added text: /a four character ASCII string [ANSI.X3-4.1986], or an 1076 eight digit hexadecimal number. All standards assigned values, 1077 including all values assigned by IANA, are required to use a value 1078 that may be represented using a subset of the ASCII character set. 1079 Private Service Codes do not need to follow this convention, although 1080 RFC 4340 suggests that users also choose Service Codes that may also 1081 be represented in ASCII./ 1083 Added new informational reference: 1085 American National Standards Institute, "Coded 1087 Character Set - 7-bit American Standard Code for 1089 Information Interchange", ANSI X3.4, 1986. 1091 URL to iperf changed, since we note CAIDA intends to shutdown all 1092 services associated with the NLANR.NET domain in May 2009. 1094 section 3.3 changed to correct section references (error noted by 1095 Ralph Droms) and additional text added to clarify sections 3.3.1 and 1096 3.3.2. New text includes: 1098 /The combination of the Service Code and server port disambiguates 1099 incoming DCCP-Requests received by a server. The Service Code is used 1100 to associate a new DCCP connection with the corresponding application 1101 service. Four cases can arise when two DCCP server applications 1102 passively listen on the same host:/ 1103 WG-11: Update following discussion with AD 1105 After discussion, the section on benchmarking was removed, and will 1106 be addressed separately. 1108 Note: This I-D will be a normative reference in draft-ietf-dccp- 1109 simul-open.