idnits 2.17.1 draft-ietf-dccp-serv-codes-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 992. 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 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 (April 22, 2008) is 5845 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 424 -- Looks like a reference, but probably isn't: '1' on line 424 -- Looks like a reference, but probably isn't: '2' on line 424 -- Looks like a reference, but probably isn't: '3' on line 427 == Outdated reference: A later version (-06) exists of draft-ietf-dccp-dtls-05 == Outdated reference: A later version (-08) exists of draft-ietf-dccp-simul-open-00 -- 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 4346 (ref. 'RFC4347') (Obsoleted by RFC 5246) -- 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 (~~), 4 warnings (==), 17 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 April 22, 2008 4 Expires: July 18, 2008 5 Updates: RFC 4340 7 The DCCP Service Code 8 draft-ietf-dccp-serv-codes-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on October 22, 2008. 36 Abstract 38 This document describes the usage of Service Codes by the Datagram 39 Congestion Control Protocol, RFC 4340. It motivates the setting of a 40 Service Code by applications. Service Codes provide a method to 41 identify the intended service/application to process a DCCP 42 connection request. This provides improved flexibility in the use and 43 assignment of port numbers for connection multiplexing. The use of a 44 DCCP Service Code can also enable more explicit coordination of 45 services with middleboxes (e.g. network address translators and 46 firewalls). It updates the specification provided in RFC 4340. 48 Table of Contents 50 1. Introduction...................................................3 51 1.1. History...................................................3 52 1.2. Conventions used in this document.........................6 53 2. An Architecture for Service Codes..............................6 54 2.1. IANA Port Numbers.........................................6 55 2.2. DCCP Service Code Values..................................7 56 2.2.1. New versions of Applications or Protocols............8 57 2.3. Service Code Registry.....................................8 58 2.4. Zero Service Code.........................................9 59 2.5. Invalid Service Code......................................9 60 2.6. SDP for describing Service Codes..........................9 61 2.7. A method to hash the Service Code to a Dynamic Port.......9 62 3. Use of the DCCP Service Code..................................10 63 3.1. Setting Service Codes at the Client......................11 64 3.2. Using Service Codes in the Network.......................11 65 3.3. Using Service Codes at the Server........................12 66 3.3.1. Reception of a DCCP-Request.........................12 67 3.3.2. Multiple Associations of a Service Code with Ports..13 68 3.3.3. Automatically launching a Server....................13 69 4. DCCP Benchmarking Services....................................14 70 4.1. Echo.....................................................14 71 4.2. Daytime..................................................14 72 4.3. Character generator......................................14 73 4.4. Time service.............................................15 74 4.5. Generic PerfTest service.................................15 75 4.6. PERF service.............................................15 76 5. Security Considerations.......................................15 77 5.1. Server Port number re-use................................16 78 5.2. Association of applications with Service Codes...........16 79 5.3. Interactions with IPsec..................................16 80 5.4. Security Considerations for Benchmarking Services........17 81 6. IANA Considerations...........................................17 82 6.1. IANA Assignments for Benchmarking Applications...........17 83 6.1.1. Port number values allocated by this document.......18 84 6.1.2. Service Code values allocated by this document......18 85 7. Acknowledgments...............................................19 86 8. References....................................................19 87 8.1. Normative References.....................................19 88 8.2. Informative References...................................20 89 9. Author's Addresses............................................22 90 9.1. Intellectual Property Statement..........................22 91 9.2. Disclaimer of Validity...................................22 92 9.3. Copyright Statement......................................23 93 A.1. Service Code Registry..........Error! Bookmark not defined. 94 A.2. Port Numbers Registry..........Error! Bookmark not defined. 96 1. Introduction 98 DCCP specifies a Service Code as a 4-byte value (32 bits) that 99 describes the application-level service to which a client application 100 wishes to connect ([RFC4340], Section 8.1.2). A Service Code 101 identifies the protocol (or a standard profile, e.g. [ID.RTP]) to be 102 used at the application layer. It is not intended to be used to 103 specify a variant of an application, or a specific variant of a 104 protocol (section 2.2). 106 Service Codes allow a flexible correspondence between application- 107 layer services and server port numbers, which affects how 108 applications interact with DCCP. This decouples the use of ports for 109 connection demultiplexing and state management from their use to 110 indicate a desired service. An application identifies the requested 111 service by the Service Code value in a DCCP-Request packet. Each 112 application may listen on one or more ports associated with one or 113 more Service Codes ([RFC4340], 8.1.2). 115 The use of Service Codes can assist in identifying the intended 116 service by a firewall and may assist other Middleboxes (e.g., a proxy 117 server, network address translator (NAT) [RFC2663]). Middleboxes that 118 desire to identify the type of data being transported by a flow, 119 should utilize the Service Code for this purpose. When consistently 120 used, the Service Code can provide a more specific indication of the 121 actual service (e.g. indicating the type of multimedia flow, or 122 intended application behaviour). 124 The more flexible use of server ports can also offer benefit to 125 applications where servers need to handle very large numbers of 126 simultaneous open ports to the same service. 128 RFC 4340 omits to describe the motivation behind Service Codes, nor 129 does it properly describe how Well Known and Registered server ports 130 relate to Service Codes. The intent of this document is to clarify 131 these issues. 133 1.1. History 135 It is simplest to understand the motivation for defining Service 136 Codes by describing the history of the DCCP protocol. 138 Most current Internet transport protocols (TCP [RFC793], UDP 139 [RFC768], SCTP [RFC4960], UDP-Lite [RFC3828]) used "Published" port 140 numbers from the Well Known or registered number spaces [RFC814]. 141 These 16-bit values indicate the application service associated with 142 a connection or message. The server port must be known to the client 143 to allow a connection to be established. This may be achieved using 144 out-of-band signaling (e.g. described using SDP [RFC4566]), but more 145 commonly a Published port is allocated to a particular protocol or 146 application; for example HTTP commonly uses port 80 and SMTP commonly 147 uses port 25. Making a port number Published [RFC1122] involves 148 registration with the Internet Assigned Numbers Authority (IANA), 149 which includes defining a service by a unique keyword and reserving a 150 port number from among a fixed pool [IANA]. 152 In the earliest draft of DCCP, the authors wanted to address the 153 issue of Published ports in a future-proof manner, since this method 154 suffers from several problems: 156 o The port space is not sufficiently large for ports to be easily 157 allocated (e.g. in an unregulated manner). Thus, many 158 applications operate using unregistered ports, possibly colliding 159 with use by other applications. 161 o The use of port-based firewalls encourages application-writers to 162 disguise one application as another in an attempt to bypass 163 firewall filter rules. This motivates firewall writers to use deep 164 packet inspection in an attempt to identify the service associated 165 with a port number. 167 o ISPs often deploy transparent proxies, primarily to improve 168 performance and reduce costs. For example, TCP requests destined 169 to TCP port 80 are often redirected to a web proxy. 171 These issues are coupled. When applications collide on the same 172 Published, but unregistered port, there is no simple way for network 173 security equipment to tell them apart, with the likelihood of 174 introducing problems with interaction of features. 176 There is little that a transport protocol designer can do about 177 applications that attempt to masquerade as other applications. For 178 ones that are not attempting to hide, the problem may be simply that 179 they cannot trivially obtain a Published port. Ideally, it should be 180 sufficiently easy that every application-writer can request a Well 181 Known or registered port and receive one instantly with no questions 182 asked. The 16-bit port space traditionally used is not large enough 183 to support such a trivial allocation of ports. 185 Thus, the design of DCCP sought an alternative solution. The idea 186 was simple. A 32-bit server port space should be sufficiently large 187 that it enables use of very simple allocation policies. However, 188 overhead considerations made a 32-bit port value undesirable (DCCP 189 needed to be useful for low rate applications). 191 The solution in DCCP to this problem was the use of a 32-bit Service 192 Code [RFC4340] that is included only in the DCCP-Request packet. This 193 was intended to perform the primary role of a Published server port, 194 in that it would be trivially simply to obtain a unique value for 195 each application. Placing the value in a request packet, requires no 196 additional overhead for the actual data flow. It is however 197 sufficient for both the end systems, and provides any stateful 198 middleboxe(s) along the path with additional information to 199 understand what applications are being used. 201 The original draft of the DCCP specification did not use traditional 202 ports; instead the client allocated a 32-bit identifier to uniquely 203 identify the connection. The server listened on a socket bound only 204 to a Service Code. This solution was unambiguous; the Service Code 205 was the only identifier for a listening socket at the server side. 206 The DCCP client included a Service Code in the request, allowing it 207 to reach the corresponding listening application. One downside was 208 that this prevented deployment of two servers for the same service on 209 a single machine, something that is trivial with ports. The design 210 also suffered from the downside of being sufficiently different from 211 existing protocols that there were concerns that it would hinder the 212 use of DCCP through NATs and other middleboxes. 214 RFC 4340 abandoned the use of a 32-bit connection identifier in favor 215 of two traditional 16-bit ports, one chosen by the server and one by 216 the client. This allows middleboxes to utilize similar techniques for 217 DCCP, UDP, TCP, etc. However, it introduced a new problem: "How does 218 the server port relate to the Service Code?" The intent was that the 219 Service Code identified the application or protocol using DCCP, 220 providing middleboxes with information about the intended use of a 221 connection, and that the pair of ports effectively formed a 32-bit 222 connection identifier, which was unique between a pair of end- 223 systems. 225 The large number of available unique Service Code values allows all 226 applications to be assigned a unique Service Code. However, there 227 remains a current problem: The server port is chosen by the server, 228 but the client needs to know this to establish a connection. It was 229 undesirable to mandate out-of-band communication to discover the 230 server port. A solution is to register DCCP server ports. The 231 limited availability of DCCP server ports appears to contradict the 232 benefits of DCCP Service Codes, because although it may be trivial to 233 obtain a Service Code, it has not traditionally been trivial to 234 obtain a registered port from IANA and in the long-run it may not be 235 possible to uniquely allocate a unique registered DCCP port to new 236 applications. As port numbers become scarce, this motivates the need 237 to associate more than one Service Code with a listening port (e.g. 239 two different applications could be assigned the same server port, 240 and need to run on the same host at the same time, differentiated by 241 their different associated Service Codes. 243 Service Codes provide flexibility in the way clients identify the 244 server application to which they wish to communicate. The mechanism 245 allows a server to associate a set of server ports with a service. 246 The set may be common with other services available at the same 247 server host, allowing a larger number of concurrent connections for a 248 particular service than possible when the service is identified by a 249 single Published port number. 251 There has been confusion concerning how server ports relate to 252 Service Codes. The goal of this document is to clarify this and the 253 issues concerning the use of Service Codes. 255 RFC4340 states that Service Codes are not intended to be DCCP- 256 specific. Service Codes, or similar concepts may therefore also be 257 useful to other IETF transport protocols. 259 1.2. Conventions used in this document 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in RFC 2119 [RFC2119]. 265 2. An Architecture for Service Codes 267 DCCP defines the use of a combination of ports and Service Codes to 268 identify the server application ([RFC4340], 8.1.2). These are 269 described in the following sections. 271 2.1. IANA Port Numbers 273 In DCCP, the packets belonging to a connection are de-multiplexed 274 based on a combination of four values {source IP address, source 275 port, dest IP address, dest port}, as in TCP. An endpoint address is 276 associated with a port number, (e.g. forming a socket); and a pair of 277 associations uniquely identifies each connection. Ports provide the 278 fundamental per-packet de-multiplexing function. 280 The Internet Assigned Numbers Authority currently manages the set of 281 globally reserved port numbers [IANA]. The source port associated 282 with a connection request, often known as the "ephemeral port", 283 traditionally is in the range 49152-65535, and also includes the 284 range 1024-49151. The value used for the ephemeral port is usually 285 chosen by the client operating system. It has been suggested that a 286 randomized choice of port number value can help defend against 287 "blind" attacks [ID.Rand] in TCP. This method may be applicable to 288 other IETF-defined transport protocols, including DCCP. 290 Traditionally, the destination (server) port value associated with a 291 service is determined either by an operating system index to a copy 292 of the IANA table (e.g., getportbyname() in Unix, which indexes the 293 /etc/services file), or directly mapped by the application. 295 The UDP and TCP port number space: 0..65535, is split into three 296 ranges [RFC2780]: 298 o 0..1023 "Well Known", also called "system" ports, 300 o 1024..49151 "registered", also called "user" ports, 302 o 49152..65535 "dynamic", also called "private" ports. 304 DCCP supports Well Known and registered ports. These are allocated in 305 the DCCP IANA port numbers registry ([RFC4340], 19.9). Each 306 registered DCCP port MUST be associated with at least one pre-defined 307 Service Code. 309 Applications that do not need to use a server port in the Well Known 310 or registered range SHOULD use a dynamic server port (i.e. that does 311 not require to be registered in the DCCP port registry). Clients can 312 identify the server port value for the services to which they wish to 313 connect using a range of methods. One common method is by reception 314 of a SDP record (section 2.6) exchanged out-of-band (e.g. using SIP 315 [RFC3261] or RTSP [RFC2326]). DNS SRV resource records also provide a 316 way to identify a server port for a particular service based on the 317 services string name [RFC2782]. 319 Applications that do not use out-of-band signalling can still 320 communicate, providing both client and server agree the port value 321 to be used. This eliminates the need for each registered Service 322 Code to be allocated an IANA-assigned server port (see also section 323 2.7). 325 2.2. DCCP Service Code Values 327 DCCP specifies a 4 byte Service Code ([RFC4340], 8.1.2) represented 328 in one of three forms: a decimal number (the canonical method), a 329 four character ASCII string, or an eight digit hexadecimal number. 331 The Service Code identifies the application-level service to which a 332 client application wishes to connect. Examples of services are RTP 334 [ID.RTP], TIME (this document), ECHO (this document). In a different 335 example, DTLS [ID.DTLS] provides a transport-service (not an 336 application-layer service), therefore applications using DTLS are 337 individually identified by a set of corresponding Service Code 338 values. 340 Endpoints MUST associate a Service Code with every DCCP socket 341 [RFC4340], both actively and passively opened. The application will 342 generally supply this Service Code. A single passive listening port 343 may be associated with more than one Service Code value. The set of 344 Service Codes could be associated with one or more server 345 applications. This permits a more flexible correspondence between 346 services and port numbers than possible using the corresponding 347 socket pair (4-tuple of layer-3 addresses and layer-4 ports). In the 348 currently defined set of packet types, the Service Code value is 349 present only in DCCP-Request ([RFC4340],5.2)and DCCP-Response packets 350 ([RFC4340],5.3). Note new DCCP packet types (e.g. [ID.Simul]) could 351 also carry a Service Code value. 353 2.2.1. New versions of Applications or Protocols 355 Applications/protocols that provide version negotiation or indication 356 in the protocol operating over DCCP do not require a new server port 357 or new Service Code for each new protocol version. New versions of 358 such applications/protocols SHOULD continue to use the same Service 359 Code. If the application developers feel that the new version 360 provides significant new capabilities (e.g. that will change the 361 behavior of middleboxes), they MAY allocate a new Service Code 362 associated with the same or a different set of Well Known ports. If 363 the new Service Code is associated with a Well Known or registered 364 port, the DCCP Ports registry MUST also be updated to include the new 365 Service Code value, but MAY share the same server port assignment(s). 367 2.3. Service Code Registry 369 The set of registered Service Codes specified for use within the 370 general Internet are defined in an IANA-controlled name space. IANA 371 manages new allocations of Service Codes in this space ([RFC4340]). 372 Private Service Codes are not centrally allocated and are denoted by 373 the range 1056964608-1073741823 (i.e. whose first hexadecimal digit 374 has the ASCII value for '?'). 376 Associations of Service Code with Well Known Ports are also defined 377 in the IANA DCCP Port Registry (section 2.1). 379 2.4. Zero Service Code 381 A Service Code of zero is "permanently reserved (it represents the 382 absence of a meaningful Service Code)" [RFC4340]. This indicates that 383 no application information was provided. RFC 4340 states that 384 applications MAY be associated with this Service Code in the same way 385 as other Service Code values. This use is permitted for any server 386 port. 388 This document clarifies section 19.8 of RFC 4340 in the following 389 way: 391 "Applications SHOULD NOT use a Service Code of zero. 393 Application writers that need a temporary Service Code value SHOULD 394 choose a value from the private range (Section 2.3). 396 Applications intended for deployment in the Internet are encouraged 397 to use an IANA-defined Service Code. If no specific Service Code 398 exists, they SHOULD request a new assignment from the IANA." 400 2.5. Invalid Service Code 402 RFC4340 defines the Service Code value of 0xFFFFFFFF as Invalid. This 403 is provided so implementations can use a special four-byte value to 404 indicate "no valid Service Code". Implementations MUST NOT accept a 405 DCCP-Request with this value, and SHOULD NOT allow applications to 406 bind to this Service Code value [RFC4340]. 408 2.6. SDP for describing Service Codes 410 Methods that currently signal destination port numbers, such as the 411 Session Description Protocol (SDP) [RFC4566] require extension to 412 support DCCP Service Codes [ID.RTP]. 414 2.7. A method to hash the Service Code to a Dynamic Port 416 Applications that do not use out-of-band signalling, or an IANA- 417 assigned port still require both the client and server to agree the 418 server port value to be used. This section describes an optional 419 method that allows an application to derive a default server port 420 number from the Service Code. The returned value is in the dynamic 421 port range [RFC4340]: 423 int s_port; /* server port */ 424 s_port = (sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3] | 0xC000; 425 if (s_port==0xFFFF) {s_port = 0xC000} 427 Where sc[] represents the four bytes of the Service Code, and sc[3] 428 is the least significant byte, for example this function associates 429 SC:fdpz with the server port 64634. 431 This algorithm has the following properties: 433 o It identifies a default server port for each service. 435 o It seeks to assign different Service Codes to different ports, but 436 does not guarantee an assignment is unique. 438 o It preserves the four bits of the final bytes of the Service Code, 439 allowing mapping common series of Service Codes to adjacent ports, 440 e.g. Foo1, and Foo2; and Fooa and Foob would be assigned adjacent 441 ports. 443 o It avoids the port 0xFFFF, which is not accessible on all host 444 platforms. 446 Applications and higher-layer protocols that have been assigned a 447 Service Code (or use a Service Code from the unassigned private 448 space) may use this method. It does not preclude other applications 449 using the selected server port, since DCCP servers are 450 differentiated by the Service Code value. 452 3. Use of the DCCP Service Code 454 The basic operation of Service Codes is as follows: 456 A client initiating a connection: 458 . issues a DCCP-Request with a Service Code and chooses a 459 destination (server) port number that is expected to be 460 associated with the specified Service Code at the destination. 462 o A server that receives a DCCP-Request: 464 . determines whether an available service matching the Service 465 Code is supported for the specified destination server port. 466 The session is associated with the Service Code and a 467 corresponding server. A DCCP-Response is returned. 469 . if the service is not available, the session is rejected and a 470 DCCP-Reset packet is returned. 472 3.1. Setting Service Codes at the Client 474 A client application MUST associate every DCCP connection (and hence 475 every DCCP active socket) with a single Service Code value 476 [RFC4340]). This value is used in the corresponding DCCP-Request 477 packet. 479 3.2. Using Service Codes in the Network 481 DCCP connections identified by the Service Code continue to use IP 482 addresses and ports, although neither port number may be Published. 484 Port numbers and IP addresses are the traditional methods to identify 485 a flow within an IP network. Middlebox [RFC3234] implementors 486 therefore need to note that new DCCP connections are identified by 487 the pair of Server Port and Service Code. This means that the IANA 488 may allocate a server port to more than one application. 490 Network address and port translators, known collectively as NATs 491 [RFC2663], may interpret DCCP ports [RFC2993]. They may also 492 interpret DCCP Service Codes. Interpreting DCCP Service Codes can 493 reduce the need to correctly interpret port numbers, leading to new 494 opportunities for network address and port translators. Although it 495 is encouraged to associate specific delivery properties with the 496 Service Code, e.g. to identify the real-time nature of a flow that 497 claims to be using RTP, there is no guarantee that the actual 498 connection data corresponds to the associated Service Code. A 499 middlebox implementor may still use deep packet inspection, and other 500 means, in an attempt to verify the content of a connection. 502 The use of the DCCP Service Code can potentially lead to interactions 503 with other protocols that interpret or modify DCCP port numbers 504 [RFC3234]. The following clarifications are provided to Section 16 of 505 RFC 4340: 507 o "A middlebox that intends to differentiate applications SHOULD 508 test the Service Code as well as the destination or source port on 509 a DCCP-Request or DCCP-Response packet. 511 o A middlebox that does not modify the intended application (e.g. 512 NATs and Firewalls), MUST NOT change the Service Code. 514 o A middlebox MAY send a DCCP-Reset in response to a packet with a 515 Service Code that is considered unsuitable." 517 3.3. Using Service Codes at the Server 519 A Service Code is used by a Server that receives a DCCP-Request to 520 associate a new DCCP connection with the corresponding application 521 service. A number of options are presented for servers using 522 passively listening sockets. Four cases can arise when two DCCP 523 server applications listen on the same host: 525 o The simplest case arises when two servers are associated with 526 different Service Codes and are bound to different server ports 527 (section 3.3.1). 529 o Two servers may be associated with the same DCCP Service Code 530 value, but be bound to different server ports (section 3.3.1). 532 o Two servers could use different DCCP Service Code values, and be 533 bound to the same server port (section 3.3.2). 535 o Two servers could attempt to use the same DCCP Service Code and 536 bind to the same server port. A DCCP implementation must disallow 537 this, since there is no way for the DCCP host to direct a new 538 connection to the correct server application. 540 RFC 4340 (8.1.2) states that an implementation: 542 o MUST associate each active socket with exactly one Service Code on 543 a specified server port. 545 o MAY, at the discretion of an implementation, associate more than 546 one Service Code with a passive socket. 548 This document updates RFC4340, section 8.1.2 in the following way: 550 o "An implementation SHOULD allow more than one Service Code to be 551 associated with a passive server port, enabling multiple 552 applications, or multiple versions of an application, to listen on 553 the same port, differentiated by the associated Service Code. 555 o An implementation SHOULD provide a method that informs a server of 556 the Service Code value that was selected by an active connection." 558 3.3.1. Reception of a DCCP-Request 560 When a DCCP-Request is received, and the specified destination port 561 is not bound to a server, the host MUST reject the connection by 562 issuing a DCCP-Reset with Reset Code "Connection Refused". A host MAY 563 also use the Reset Code "Too Busy" ([RFC4340], 8.1.3). 565 When the requested destination port is bound to a server, the host 566 MUST also verify that the server port has been associated with the 567 specified Service Code. Two cases can occur: 569 o If the receiving host is listening on a server port and the DCCP- 570 Request uses a Service Code previously associated with the port, 571 the host accepts the connection. Once connected, the server 572 returns a copy of the Service Code in the DCCP-Response packet 573 completing the initial handshake [RFC4340]. 575 o If the server port is not associated with the requested Service 576 Code, the server SHOULD reject the request by sending a DCCP-Reset 577 packet with Reset Code 8, "Bad Service Code" ([RFC4340], 8.1.2), 578 but MAY use the reason "Connection Refused". 580 A single application may wish to accept connections for more than one 581 Service Code using the same server port. This may allow a server to 582 offer more than the limit of 65,536 services determined by the size 583 of the Port field. The upper limit is based solely on the number of 584 unique connections between two hosts (i.e., 4,294,967,296). 586 After a connection has been accepted, the protocol control block is 587 associated with a pair of ports and a pair of IP addresses and a 588 single Service Code value. 590 3.3.2. Multiple Associations of a Service Code with Ports 592 RFC4340 states that a single passively opened (listening) port MAY be 593 associated with multiple Service Codes, although an active (open) 594 connection can only be associated with a single Service Code. 596 3.3.3. Automatically launching a Server 598 A host implementation may permit a service to be associated with a 599 server port (or range of ports) that is not permanently running at 600 the Server. In this case, the arrival of a DCCP-Request may require a 601 method to associate a DCCP-Request with a server that handles the 602 corresponding Service Code. This operation could resemble that of 603 "inetd" [inetd]. 605 As in the previous section, when the specified Service Code is not 606 associated with the specified server port, the connection MUST be 607 aborted and a DCCP Reset message sent [RFC4340]. 609 4. DCCP Benchmarking Services 611 A number of simple services are commonly supported by systems using 612 TCP and UDP, this section defines corresponding services for DCCP 613 [RFC4340]. These services are useful for debugging DCCP 614 implementations and deployment, and for benchmarking bidirectional 615 DCCP connections. The IANA section of this document allocates a 616 corresponding set of code points for these services. 618 4.1. Echo 620 The operation of the DCCP echo service follows that specified for UDP 621 [RFC862]: a server listens for DCCP connections; once a client has 622 set up a connection, each data packet sent to the server will be 623 copied (echoed) back to the client. 625 4.2. Daytime 627 The DCCP daytime service is operationally equivalent to the 628 connection-based TCP daytime service [RFC867]: any data received is 629 discarded by the server; and generates a response sent in a DCCP data 630 packet containing the current time and data as an ASCII string; after 631 which the connection is closed. 633 4.3. Character generator 635 The operation of the DCCP chargen service corresponds to the 636 connection-based TCP chargen protocol [RFC864]: A server listens for 637 incoming requests and, once a client has established a connection, 638 continuously sends datagrams containing a random number (between 0 639 and 512, not exceeding the current DCCP Maximum Packet Size, MPS) of 640 characters. The service terminates when the user either closes or 641 aborts the connection. Congestion control is enforced using the 642 mechanisms [RFC4340] and related documents. 644 If necessary, the receiver can enforce flow control on this service 645 by using either or both of the Slow Receiver ([RFC4340], 11.6) and 646 Data Dropped ([RFC4340], 11.7) DCCP options to signal the server to 647 slow-down. 649 The chargen protocol provides a service that may be used for testing 650 and measurement of bidirectional DCCP connectivity, as well as 651 congestion control responsiveness. The datagram-based variant of 652 chargen can be emulated with the DCCP ECHO service by changing the 653 format of the datagrams sent by the client, hence these services 654 complement each other. 656 4.4. Time service 658 The format of timestamps and the operation of the DCCP time service 659 is equivalent to the TCP time protocol variant [RFC868]: a server 660 listens for incoming connections; after a client has established a 661 new connection, the server sends a 4-byte timestamp; whereupon the 662 client closes the connection. 664 4.5. Generic PerfTest service 666 The PerfTest service specified by this document provides a generic 667 service that may be used to benchmark and measure both unidirectional 668 and bidirectional DCCP connections, as well as server and host DCCP 669 stacks. These services are identified by the Service Code "XPER". 670 This document does not specify a specific port number for this 671 service. 673 The payload of DCCP packets associated with this service do not have 674 a specified format. They are silently discarded by the receiver, and 675 used only for gathering numerical performance data. Tools that have 676 specific payload formats should register their own Service Code value 677 with IANA (e.g. section 4.6). 679 This Service Code is for benchmarking applications that transmit data 680 in one-direction only, with DCCP control traffic flowing in the 681 opposite direction. A benchmarking application that expects data 682 responses to the messages it sends would require a different Service 683 Code. (This could result in different Middlebox treatment.) 685 4.6. PERF service 687 The PERF service specified by this document describes the service 688 supported by the open-source iperf benchmarking program [iperf]. 689 This may be used to benchmark and measure both unidirectional and 690 bidirectional DCCP connections, as well as server and host DCCP 691 stacks. This service is identified by a Service Code "PERF" and is 692 associated with a well-known port number that currently coincides 693 with the UDP port used by the iperf benchmarking program [iperf]. 695 5. Security Considerations 697 This document discusses the usage of Service Codes. It does not 698 describe new protocol functions. There are four areas of security 699 that are important: 701 1. Server Port number reuse (5.1). 703 2. Interaction with NATs and firewalls (section 3.2 describes 704 middlebox behaviour). 706 3. Interpretation of DCCP Service Codes over-riding traditional use 707 of reserved/Well Known port numbers (section 5.2). 709 4. Interaction with IPsec and DTLS security (section 5.3). 711 5.1. Server Port number re-use 713 Service Codes are used in addition to ports when demultiplexing 714 incoming connections. This changes the service model to be used by 715 applications and middleboxes. The port-numbers registry already 716 contains instances of multiple application registrations for a single 717 port number for TCP and UDP. These are relatively rare. Since the 718 DCCP Service Code allows multiple applications to safely share the 719 same port number, even on the same host, server port number reuse in 720 DCCP may be more common than in TCP and UDP. 722 5.2. Association of applications with Service Codes 724 Care needs to be exercised when interpreting the mapping of a Service 725 Code value to the corresponding service. The same service 726 (application) may be accessed using more than one Service Code. 727 Examples include the use of separate Service Codes for an application 728 layered directly upon DCCP and one using DTLS transport over DCCP. 729 Other possibilities include the use of a private Service Code that 730 maps to the same application as assigned to an IANA-defined Service 731 Code value, or a single application that provides more than one 732 service. Different versions of a service (application) may also be 733 mapped to a corresponding set of Service Code values. 735 Processing of Service Codes may imply more processing than currently 736 associated with incoming port numbers. Implementers need to guard 737 against increasing opportunities for Denial of Service attack. 739 5.3. Interactions with IPsec 741 IPsec uses port numbers to perform access control in transport mode 742 [RFC4301]. Security policies can define port-specific access control 743 (PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and 744 keys. Similarly, firewall policies allow or block traffic based on 745 port numbers. 747 Use of port numbers in IPsec selectors and firewalls may assume that 748 the numbers correspond to Well Known services. It is useful to note 749 that there is no such requirement; any service may run on any port, 750 subject to mutual agreement between the endpoint hosts. Use of the 751 Service Code may interfere with this assumption both within IPsec and 752 in other firewall systems, but it does not add a new vulnerability. 753 New implementations of IPsec and firewall systems may interpret the 754 Service Code when implementing policy rules, but should not rely on 755 either port numbers or Service Codes to indicate a specific service. 757 This is not an issue for IPsec because the entire DCCP header and 758 payload are protected by all IPsec modes. None of the DCCP header is 759 protected by application-layer security, e.g., DTLS [ID.DTLS], so 760 again this is not an issue [RFC4347]. 762 5.4. Security Considerations for Benchmarking Services 764 Services used for benchmarking and testing may also be used to 765 generate traffic for other purposes. They can therefore pose an 766 opportunity for a Denial of Service attack. Care needs to be 767 exercised when enabling these services in an operational network. 768 Appropriate rate-limits should be provided to mitigate these effects 769 for servers provided for testing. In this respect, the security 770 considerations are the same as those for other IETF-defined transport 771 protocols. 773 6. IANA Considerations 775 This document does not update the IANA allocation procedures for the 776 DCCP Port Number and DCCP Service Codes Registries as defined in RFC 777 4340. 779 6.1. IANA Assignments for Benchmarking Applications 781 A set of new services are defined in section 4. Their corresponding 782 IANA assignments are summarized in this section. 784 This document notes that it is not required to supply an approved 785 document (e.g. a published RFC) to support an application for a DCCP 786 Service Code or port number value, although RFCs may be used to 787 request Service Code values via the IANA Considerations section. A 788 specification is however required to allocate a Service Code that 789 uses a combination of ASCII digits, uppercase letters, and character 790 space, '-', '.', and '/') [RFC4340]. 792 6.1.1. Port number values allocated by this document 794 IANA action is required to assign server ports for use by DCCP. This 795 document requests allocation of the following code points from the 796 IANA DCCP Port numbers registry: 798 >>>>>> IANA ACTION Please replace IANA THIS RFC, with the allocated 799 RFC number. <<< 801 echo 7/dccp Echo SC:ECHO 802 # IETF dccp WG, [IANA - THIS RFC] 803 daytime 13/dccp DayTime SC:DTIM 804 # IETF dccp WG, [IANA - THIS RFC] 805 chatgen 19/dccp Chargen SC:CHAR 806 # IETF dccp WG, [IANA - THIS RFC] 807 time 37/dccp Timeserver SC:TIME 808 # IETF dccp WG, [IANA - THIS RFC] 809 Perf 5001/dccp iPerf SC:PERF 810 # IETF dccp WG, [IANA - THIS RFC] 812 6.1.2. Service Code values allocated by this document 814 This document solicits IANA action to allocate the following code 815 points from the Service Code registry [IANA.SC]. The requested 816 assignments are listed below and summarized in table 1. This set of 817 Service Codes may be utilized for testing DCCP implementations and 818 transmission paths. 820 >>>IANA Please confirm these allocations. >>> 821 +----------+------+----+-------------------------------+----------+ 822 | Service | ASCII|Port| Description | Ref | 823 | Code (SC)| Code | | | | 824 +----------+------+----+-------------------------------+----------+ 825 |1162037327| ECHO | 7| Echo service | [RFC862] | 826 |0x4543484f| | | | | 827 |1146374477| DTIM | 13| Daytime server | [RFC867] | 828 |0x4454494d| | | | | 829 |1128808786| CHAR | 19| Character generator (chargen) | [RFC864] | 830 |0x43484152| | | | | 831 |1414090053| TIME | 37| Timeserver | [RFC868] | 832 |0x54494d45| | | | | 833 |1346720326| PERF |5001| iPerf | [*] | 834 |0x50455246| | | | | 835 |1481655634| XPER | - | Generic Performance Service | [*] | 836 |0x58504552| | | | | 837 +----------+------+----+-------------------------------+----------+ 838 Table 1: Allocation of Service Codes by this document. 840 Notes: 841 1) Port is the default port associated with this service. 842 2) * Reference is this document. 844 7. Acknowledgments 846 This work has been supported by the EC IST SatSix Project. 847 Significant contributions to this document resulted from discussion 848 with Joe Touch, and this is gratefully acknowledged. The author also 849 thanks Ian McDonald, Fernando Gont, Eddie Kohler, and the DCCP WG for 850 helpful comments on this topic, and Gerrit Renker for his help in 851 determining DCCP behaviour and review of this document. Mark Handley 852 provided significant input to the text on definition of Service Codes 853 and their usage. He also contributed much of the material that has 854 formed the historical background section. 856 8. References 858 8.1. Normative References 860 [RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts: 861 Communication Layers, " STD 3, RFC 1122, Oct. 1989 862 (STANDARD). 864 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 865 Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST 866 CURRENT PRACTICE). 868 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 869 Control Protocol (DCCP)", RFC 4340, Mar. 2006 (PROPOSED 870 STANDARD). 872 8.2. Informative References 874 [IANA] Internet Assigned Numbers Authority, www.iana.org 876 [IANA.SC] IANA DCCP Service Code Registry 877 http://www.iana.org/assignments/service-codes 879 [ID.DTLS] T.Phelan, "Datagram Transport Layer Security (DTLS) over 880 the Datagram Congestion Control Protocol (DCCP)", IETF Work 881 in Progress, draft-ietf-dccp-dtls-05.txt. 883 [ID.Simul] G. Fairhurst, G. Renker, "DCCP Simultaneous-Open Technique 884 to Facilitate NAT/Middlebox Traversal", IETF Work in 885 Progress, draft-ietf-dccp-simul-open-00.txt. 887 [ID.RTP] C. Perkins, "RTP and the Datagram Congestion Control 888 Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp- 889 rtp-07.txt. 891 [ID.Rand] M. Larsen, F. Gont, "Port Randomization", IETF Work in 892 Progress, draft-larsen-tsvwg-port-randomization-02.xt 894 [inetd] The extended intetd project, http://xinetd.org/ 896 [iperf] http//dast.nlanr.net/Projects/Iperf/ 898 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 899 August 1980. 901 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 902 793, Sept. 1981 (STANDARD). 904 [RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES", RFC 814, 905 July 1982 (UNKNOWN). 907 [RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983. 909 [RFC864] Postel, J., "Character Generator Protocol", STD 22, RFC 910 864, May 1983. 912 [RFC867] Postel, J., "Daytime Protocol", STD 25, RFC 867, May 1983. 914 [RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 915 868, May 1983. 917 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 919 Streaming Protocol (RTSP)", RFC 2326, April 1998. 921 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 922 Translator (NAT) Terminology and Considerations", RFC 2663, 923 August 1999. 925 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 926 Values In the Internet Protocol and Related Headers", BCP 927 37, RFC 2780, March 2000. 929 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 930 specifying the location of services (DNS SRV)", RFC 2782, 931 February 2000. 933 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 934 November 2000. 936 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 937 Issues", RFC 3234, February 2002. 939 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 940 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 941 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 943 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 944 G. Fairhurst, "The Lightweight User Datagram Protocol (UDP- 945 Lite)", RFC 3828, July 2004. 947 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 948 Internet Protocol", RFC 4301, December 2005. 950 [RFC4347] Dierks, T. and E. Rescorla, "The Transport Layer Security 951 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 953 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 954 Description Protocol", RFC 4566, July 2006. 956 [RFC4960] Stewart, R., Ed., "Stre Control Transmission Protocol RFC 957 4960, September 2007. 959 9. Author's Addresses 961 Godred (Gorry) Fairhurst, 962 School of Engineering, 963 University of Aberdeen, 964 Kings College, 965 Aberdeen, AB24 3UE, 966 UK 967 Email: gorry@erg.abdn.ac.uk 968 URL: http://www.erg.abdn.ac.uk/users/gorry 970 9.1. Intellectual Property Statement 972 The IETF takes no position regarding the validity or scope of any 973 Intellectual Property Rights or other rights that might be claimed to 974 pertain to the implementation or use of the technology described in 975 this document or the extent to which any license under such rights 976 might or might not be available; nor does it represent that it has 977 made any independent effort to identify any such rights. Information 978 on the procedures with respect to rights in RFC documents can be 979 found in BCP 78 and BCP 79. 981 Copies of IPR disclosures made to the IETF Secretariat and any 982 assurances of licenses to be made available, or the result of an 983 attempt made to obtain a general license or permission for the use of 984 such proprietary rights by implementers or users of this 985 specification can be obtained from the IETF on-line IPR repository at 986 http://www.ietf.org/ipr. 988 The IETF invites any interested party to bring to its attention any 989 copyrights, patents or patent applications, or other proprietary 990 rights that may cover technology that may be required to implement 991 this standard. Please address the information to the IETF at 992 ietf-ipr@ietf.org. 994 9.2. Disclaimer of Validity 996 This document and the information contained herein are provided on 997 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 998 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 999 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1000 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1001 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1002 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1003 FOR A PARTICULAR PURPOSE. 1005 9.3. Copyright Statement 1007 Copyright (C) The IETF Trust (2008). 1009 This document is subject to the rights, licenses and restrictions 1010 contained in BCP 78, and except as set forth therein, the authors 1011 retain all their rights. 1013 >>> RFC Editor please remove this section prior to publication. 1015 Change Log. 1017 01 introduced: 1019 - a replacement of the word *range* when referring to sets of dccp 1020 ports (they are not necessarily contiguous), noted by E. Kohler. 1022 - Addition of some Service Codes in IANA section. 1024 02 introduced: 1026 - add the use of profiles with DCCP, identified by Service Code, but 1027 not the use of protocol variants. 1029 - further detail on implementation levels (more input would be good) 1031 - added security consideration for traffic generators 1033 - added ref to UDPL for completeness 1035 - Corrected NiTs found by Gerrit Renker 1037 +++++++++++++++++++++++++++ 1039 WG 00 (first WG version) 1041 This introduced revisions to make it a WG document. 1043 - Corrected language and responded to many helpful comments from 1044 Fernando Gont and Ian McDonald. 1046 - Added a test for which server behaviour is used. 1048 - Added some speculative text on how to implement the SC. 1050 - More input and discussion is requested from the WG. 1052 - Added an informative appendix on host configuration. 1054 - Merging of some sections to remove repetition and clarify wording. 1056 +++++++++++++++++++++++++++ 1057 WG 01 1059 Historical material was added. 1061 Comments from the list have been included. 1063 The concept of adding weak semantics to a SC=0 was removed. This was 1064 added at the request of implementers, with the aim of offering easier 1065 implementation on at least one target platform. It has been removed 1066 in this document because it weakens interoperability and complicates 1067 the Spec. 1069 The proposal to allow several levels of support was introduced in 1070 previous drafts following suggestions from the WG, but was removed in 1071 this revision. The method was seen to introduce complexity, and 1072 resulted in complex interoperability scenarios. 1074 Removed "test" method, this was no longer required. 1076 Draft was reorganized to improve clarity and simplify concepts. 1078 ---- 1080 WG 02 1082 Updated following comments from Eddie Kohler. 1084 ---- 1086 WG 03 1088 Fixed NiTs and addressed issues marked in previous version. 1090 Added 2 para at end of port section saying how to use Well Known 1091 ports and that you do not need to register them. 1093 ----- 1095 WG 04 1097 Cleaned English (removing duplication) 1099 Checked text that updates RFC4340 (and remove duplicates). 1101 Updated hash algorithm for SC->s_port 1103 Updated to IANA section. 1105 Edits in response to feedback from Tom Phelan, et al. 1107 WG-05: 1109 Various sections were updated following feedback from the list, some 1110 specific comments were: 1112 Tom Phelan suggested clarification was needed for the usage of well- 1113 known ports in section 1, and various other clarifications. 1115 Eddie Kohler suggested reworking the midbox section. 1117 Eddie noted the hash function included the highest numbered port, 1118 which is not accessible on all OS. 1120 There was also discussion about the proper server port range to be 1121 used with this method. After previous concerns that using registered 1122 ports could have some (unknown) side effect, use was recommended in 1123 the dynamic range. Text was added to this section. 1125 Discussions at IETF-71 lead to the idea to removing the IANA guidance 1126 on maintaining the registries to a new document that defines the 1127 policy across the set of transport registries. 1129 Eddie noted that port-reuse is likely to be more common with DCCP 1130 (security considerations). 1132 Lars noted that rate-limiting benchmarking tools may be somewhat 1133 undesirable, and this related to services for testing. 1135 The text recommending an update to the IANA procedures for ports and 1136 service codes has been moved to a TSV WG draft. 1138 ----