DCCP WG G.Fairhurst Internet Draft University of Aberdeen Expires: May 2007 November 20, 2006 The DCCP Service Code draft-fairhurst-dccp-serv-codes-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 20, 2007. Abstract This document describes the usage of the Service Code for the Datagram Congestion Control Protocol, RFC 4340. Service Codes provide a method to identify the intended service/application to process a DCCP Connection Request. It provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The DCCP Service Code can also enable more explicit coordination of services behind NATs and firewalls. This document motivates the setting of Service Codes by applications, rather than assigning a default Service Code value of zero. Touch Expires May 20, 2007 [Page 1] Internet-Draft DCCP Service Codes November 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction...................................................3 2. An Architecture for supporting Service Codes...................4 2.1. IANA Port Numbers.........................................4 2.2. DCCP Service Code Values..................................5 2.3. Zero Service Code.........................................5 2.4. Reception of a DCCP-Request with a bound Service Code.....5 2.5. Reception of a DCCP-Request with an unbound Service Code..6 2.6. SDP for describing Service Codes..........................6 3. Use of the DCCP Service Code...................................6 3.1. Setting Service Codes at the Sender.......................6 3.2. Using Service Codes in the Network........................7 3.3. Using Service Codes at the Receiver.......................7 3.4. Multiple Associations of Service Codes and Ports..........8 3.5. Summary of Service Code and Port Handling.................9 4. Changes required to API to support Service Codes...............9 4.1. Interactions with IPsec..................................10 5. Service Code Registry.........................................10 6. Security Considerations.......................................11 7. IANA Considerations...........................................11 8. Conclusions...................................................12 9. Acknowledgments...............................................12 10. References...................................................13 10.1. Normative References....................................13 10.2. Informative References..................................13 Author's Addresses...............................................14 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................15 Copyright Statement..............................................15 Acknowledgment...................................................15 Fairhurst Expires May 20, 2007 [Page 2] Internet-Draft DCCP Service Codes November 2006 1. Introduction Most Internet transport protocols use "well-known" port numbers to indicate which application service is associated with a connection or message [RFC814]; this includes TCP [RFC793], UDP [RFC768], SCTP [RFC2960], and DCCP [RFC4340]. Making a port number well-known involves registration with the Internet Assigned Numbers Authority (IANA), which includes defining a service by a unique keyword and reserving a port number from among a fixed pool [IANA]. DCCP specifies a Service Code as a 4-byte value (32 bits). This describes the application-level service to which a client application wishes to connect (RFC4340, Section 8.1.2). Service Codes allow a flexible correspondence between application-layer services and port numbers, which affects how applications interact with DCCP, as well as how services can be deployed behind NATs and firewalls. If an application does not set a Service Code, the connection SHOULD be associated with a Service Code of zero, with the intended server identified only by the destination port number. Fairhurst Expires May 20, 2007 [Page 3] Internet-Draft DCCP Service Codes November 2006 2. An Architecture for supporting Service Codes DCCP defines the use of a combination of ports and Service Codes to identify the server application (RFC 4340, sec. 8.1.2). These are described in the following sections. Section 3 describes the use of Service Codes by end hosts and network middleboxes. 2.1. IANA Port Numbers In DCCP, an endpoint address is associated with a port number, forming a socket; and a pair of sockets uniquely identifies each connection. Ports provide the fundamental de-multiplexing function. Like DCCP, most Internet Transport Protocols (e.g. TCP [RFC793], UDP [RFC768]) also define publicly-known ports for most services, whether intended for public access (e.g., telnet, DNS) or for services typically used between pre-arranged pairs (e.g., X11, SSL). In TCP and UDP these are the primary means of identifying the required service when a connection request is received. The Internet Assigned Numbers Authority currently manages the set of globally reserved port numbers [IANA]. The destination port value that is associated with a service is determined either by an operating system index to a copy of the IANA table (e.g., getportbyname() in Unix, which indexes the /etc/services file), or directly mapped by the application. The UDP and TCP port number space - - 0..65535 - - is split into three ranges [RFC2780]: o 0..1023 "well-known", also called "system" ports o 1024..49151 "registered", also called "user" ports o 49152..65535 "dynamic", also called "private" ports One challenge with the use of IANA-managed ports is that this allocates ports globally, for all hosts on the public Internet, even though the association between a port and a service is of interest only to the end hosts participating in a connection. As a result, the fixed space of port numbers is being globally reserved unnecessarily. It is more useful to allocate this name space on a per-host basis [ID.portnames]. Well-known/Reserved DCCP ports are described in a separate IANA registry [RFC4340]. This registry may also associate ports with a pre-defined set of Service Codes (see section 2.2). Fairhurst Expires May 20, 2007 [Page 4] Internet-Draft DCCP Service Codes November 2006 The source port associated with a connection request, often known as the "ephemeral port", traditionally includes the range 49152-65535, and should also include the 1024-49151 range. The value used for the ephemeral port is usually chosen by the client operating system. It has been suggested that a randomized choice of port number value can help defend against "blind" attacks [ID.TSVWG.RAND]. Such methods may also be applicable to IETF-defined transport protocols, including DCCP. 2.2. DCCP Service Code Values DCCP specifies a 4 byte Service Code [RFC4340]. Service codes may be represented in one of three forms: as a decimal number (the canonical method), as a 4 character ASCII string, or as a hexadecimal number. The Service Code identifies the application-level service to which a client application wishes to connect. It is present only in DCCP- Connect and DCCP-Response packets and permits a more flexible correspondence between services and port numbers than possible using using the corresponding socket pair (4-tuple of layer-3 addresses and layer-4 ports). This decouples the use of ports for connection demultiplexing and state management, from their use to indicate a desired endpoint service. One method of operation is to assign one Service Code per Port, although multiple applications may be permitted on the same port (if a Server implementation permits this). Service Codes allow a larger number of concurrent connections for a particular service than possible using well-known port numbers, by allowing endpoints to allocate their own port numbers separately, based on services they deploy (c.f. section 2.1). 2.3. Zero Service Code A Service Code value of zero indicates that the Service Code function is not used by a client. A server uses only the destination port number to identify the required application (as in section 2.1). 2.4. Reception of a DCCP-Request with a bound Service Code A Service Code value may be associated by the client (initiator of the DCCP-Request), and is used by the server (recipient of the DCCP- Request) to associate the connection with the corresponding application. This association MUST be explicit (i.e. the requested Service Code MUST have been previously bound to the destination port at the server). Once connected, the server returns a copy of the Fairhurst Expires May 20, 2007 [Page 5] Internet-Draft DCCP Service Codes November 2006 Service Code in the DCCP-Response packet completing the initial handshake [RFC4340]. 2.5. Reception of a DCCP-Request with an unbound Service Code DCCP defines a number of possible error conditions that may arise in processing of a Connection Request: o Connection Refused (Invalid port) o Too Busy (Service Code/Port may be valid) o Bad Service Code (Invalid Service Code for specified port) Reception of a DCCP-Request with an invalid destination port MUST result in the DCCP-Request being rejected, and sending a DCCP-Reset with Reset Code "Connection Refused". A server MAY also use the Reset Code "Too Busy" (RFC 4340, sec. 8.1.3). Reception of a DCCP-Request for a port number where the Service Code that is not bound MUST result in the DCCP-Request being rejected, and returning a DCCP-Reset with Reset Code "Bad Service Code" (RFC 4340, sec. 8.1.2). 2.6. SDP for describing Service Codes Methods that currently signal the use of port numbers, such as the Session Description Protocol (SDP) require extension to support DCCP Service Codes [ID.DCCP.RTP]. 3. Use of the DCCP Service Code Like UDP, DCCP uses port numbers to demultiplex connections. Upon receipt of a DCCP-Request including the Service Code, the Code is matched against a list of available services. 3.1. Setting Service Codes at the Sender Applications SHOULD specify an appropriate Service Code when sending a DCCP-Request packet. Valid Service Codes should be selected from the set of values assigned in the DCCP Service Code Registry maintained by IANA [IANA-SC], or from the uncoordinated private space (RFC 4340, sec. 8.1.2.). An application that does not set a Service Code, SHOULD be associated with a Service Code value of zero. Fairhurst Expires May 20, 2007 [Page 6] Internet-Draft DCCP Service Codes November 2006 3.2. Using Service Codes in the Network Port numbers and IP addresses are the accepted methods to identify a flow within an IP network. When the DCCP header has not been encrypted, Middleboxes [RFC3234], such as firewalls, can instead use the Service Code to identify the application (even when running on a non-standard port). Middlebox devices are therefore expected to check Service Code values before port numbers for DCCP. The Service Code values on DCCP-Requests should be used for supplementary checks [RFC4340]. Section 4.1 describes some issues that may arise in this case. The use of the DCCP Service Code can potentially lead to interactions with other protocols that interpret or modify DCCP port numbers. This includes IPsec and other firewall systems, other security mechanisms, other in-band exchange of port numbers, and network address translators (NATs). Network address and port translators, known collectively as NATs, not only interpret DCCP ports, but may also translate/modify them [RFC2993]. This interferes with the use of ports for service identification [RFC3234]. The DCCP Service Code may allow services to be identified behind NATs if NATs are not further extended to translate Service Codes. Middleboxes should not modify the Service Code unless they change the service that a connection is accessing. DCCP connections identified by the Service Code continue to use IP addresses and ports, although neither port number may be well- known/reserved. Translation of these ports need to be considered in the operation of NATs. In addition, DCCP Service Codes can reduce the need to correctly interpret port numbers, leading to new opportunities for network address and port translators. 3.3. Using Service Codes at the Receiver An implementation MUST allow a server application to bind to a Service Code on a fixed port. The Service Code of zero may be the default, indicating that no specific Service Code is in use. An implementation MAY allow server applications to bind to a Service Code specifying a range of acceptable ports. The DCCP Service Codes associates a DCCP Connection with the service that the client expects to be running at the server. This value MUST take precedence over any service bound to the port number. Two cases can occur: Fairhurst Expires May 20, 2007 [Page 7] Internet-Draft DCCP Service Codes November 2006 o When a DCCP- -Request packet is received with a Service Code value of zero, the connection is associated with an application using the destination port number specified in the DCCP-Request. If there is no specific application associated with the destination port, then the connection MUST be aborted and a DCCP-RESET packet is returned. If the port is not associated with a zero Service Code, then the connection is aborted. o A DCCP-Request that is received with a non-zero Service Code MUST be checked to validate that the server has associated the Service Code with the specified destination port. If the Service Code is not associated with the port, the corresponding server application is used. If there is no associated application, the server MUST abort the connection by issuing a DCCP-Reset with the reset code "Bad Service Code". 3.4. Multiple Associations of Service Codes and Ports at the Sender A single Service Code MAY be bound to more than one destination port (wildcarding a range of port values). Also a single destination port MAY be bound to multiple Service Codes (wildcarding a set of Service Codes), although an active connection may only be associated with a single Service Code [RFC4340]. o An end host implementation may provide a method that only allows a single Service Code to be associated with each listening port. This means that a single port may be used only for a pre-specified service; however this service does not need to be permanently running at the Server. The arrival of a DCCP-Request may therefore require launching an application to accept messages from the DCCP connection. This operation could resemble that of "portmapper" or "inetd". o When a Connection Request is received with a port number that is associated with multiple Service Codes, the listening server needs to provide a method to ensure that the DCCP-Request is associated with an application server that handles the corresponding Service Code. This may require launching an application to accept messages from the DCCP connection. This use may allow a server to offer more than the limit of 65,536 services determined by the size of the Port field (fewer if system/user/dynamic boundaries are preserved). The limit is based solely on the number of unique connections between two hosts (i.e., 4,294,967,296). As in the previous section, when the specified Service Code is not associated with the specified port, the server MUST abort the connection and send a DCCP Reset message. Fairhurst Expires May 20, 2007 [Page 8] Internet-Draft DCCP Service Codes November 2006 3.5. Summary of Service Code and Port Handling The basic operation of the Service Codes is as follows: o A source host issues a DCCP-Request with a Service Code of zero, and chooses either a well-known/reserved destination port or a port number announced by some other means. o A source host issues a DCCP-Request with a non-zero Service Code and chooses a destination port number that is associated with the Service Code at the destination. o The destination host, upon receiving a DCCP-Request with a zero Service Code, validates the port is supports a Service Code of zero and then uses the destination port to identify the associated server. o The destination host, upon receiving a DCCP-Request with a non- zero Service Code, determines whether an available service matching the Service Code is running for the specified destination port. o If the service is not available, a DCCP-Reset packet is returned. 4. Changes required to API to support Service Codes The use of Service Codes requires an API to allow a service to bind to a Service Code as well as a port number. One approach is to use separate commands as follows: o Extend the existing port number indicator command (e.g., Unix bind() or connect() calls) to select a specific port number where desired. o Extend the existing socket parameterization command (e.g., Unix setsockopt()) to set a service-code option. o An information base (table) may be used by servers to identify the set of Service Codes that are associated with each port and the corresponding set of server applications. XXX Author note: May need to discuss: Fairhurst Expires May 20, 2007 [Page 9] Internet-Draft DCCP Service Codes November 2006 get_port_and_service_code_by_name(char *what_service_do_you_want) char *get_service_code_by_number(unsigned sc) and interactions with getadddrinfo() address/port lookup routine, which has been introduced to simplify the migration to IPv6 [RFC3493], sec. 6.1. XXX End Author Note. 4.1. Interactions with IPsec IPsec uses port numbers to perform access control in transport mode [RFC4301]. Security policies can define port-specific access control (PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and keys. Similarly, firewall policies allow or block traffic based on port numbers. Use of port numbers in IPsec selectors and firewalls may assume that the numbers correspond to well-known services. It is useful to note that there is no such requirement; any service may run on any port, subject to mutual agreement between the endpoint hosts. Use of the Service Code may interfere with this assumption both within IPsec and in other firewalling systems, but it does not add a new vulnerability. New implementations of IPsec and firewall systems may interpret the Service Code when implementing policy rules, but should not rely on either port numbers or Service Codes to indicate a specific service. This is not an issue for IPsec because the entire DCCP header and payload are protected by all IPsec modes. None of the DCCP header is protected by application-layer security, e.g., DTLS [ID.DTLS.DCCP], so again this is not an issue [RFC4347]. 5. Service Code Registry The set of Service Codes currently specified for use within the general Internet are defined in an IANA-controlled name space. IANA manages new allocations of Service Codes in this space [RFC4340]. Service Code bindings to Ports may also be defined in the IANA DCCP Port Registry. Fairhurst Expires May 20, 2007 [Page 10] Internet-Draft DCCP Service Codes November 2006 6. Security Considerations This document does not describe new protocol functions. The document discusses the usage of Service Codes. There are three areas of security that are important: 1. Interaction with NATs and firewalls (see section 3.2, on middlebox behaviour). 2. Interaction with IPsec and DTLS security (see section 4.1, on use of IPsec). 3. Interpretation of DCCP Service Codes over-riding traditional use of reserved/well-known port numbers (see section 6.1) 6.1 Interactions of Service Codes and port numbers The Service Code value may be used to over-ride the traditional way that operating systems consider low-numbered ports as privileged. This represents a change in the way operating systems respect this range of DCCP port numbers. The same service (application) may be potentially accessed using more than one Service Code. Examples include the use of separate Service Codes for an application layered directly upon DCCP and one using DTLS transport over DCCP. Other possibilities include the use of a private Service Code point that maps to the same application as assigned to an IANA-defined Service Code value. Different versions of a service (application) may also be mapped to a corresponding set of Service Code values. Care needs to be exercised when interpreting the mapping the Service Code value to the corresponding service. Processing of Service Codes may imply more processing than currently associated with incoming port numbers. Implementers need to guard against increasing opportunities for Denial of Service attack. 7. IANA Considerations This document does not specify a new IANA registry allocation, and does not solicit IANA action. It is NOT required to supply an approved document (e.g. a published RFC) to support an application Fairhurst Expires May 20, 2007 [Page 11] Internet-Draft DCCP Service Codes November 2006 for a DCCP Service Code value, although RFCs may be used to request Service Code values via the IANA Considerations section. XXX Author Note: Should this document allocate a set of well-known Service Codes ?? This document requests the assignment of the following codepoints from the Service Code registry: XXX End Author Note 8. Conclusions This document discusses the operation of service codes by the DCCP transport protocol [RFC4340] and motivates their use. The document augments and clarifies the way in which DCCP applications should use the Service Code Feature. It does not update or obsolete the protocol defined in RFC4340. Service Codes, or similar concepts may also be useful to other IETF Transport Protocols [ID.Portnames]. 9. Acknowledgments This work has been supported by the EC IST SatSix Project. Significant contributions to this document resulted from discussion with Joe Touch, and this is gratefully acknowledged. The author also thanks Ian McDonald and the DCCP WG for helpful comments on this topic. Fairhurst Expires May 20, 2007 [Page 12] Internet-Draft DCCP Service Codes November 2006 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST CURRENT PRACTICE). [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)," RFC 4340, Mar. 2006 (PROPOSED STANDARD). 10.2. Informative References [IANA] Internet Assigned Numbers Authority, www.iana.org [IANA-SC] IANA DCCP Service Code Registry http://www.iana.org/assignments/service-codes [ID.Portnames] J. Touch, "A TCP Option for Port Names", IETF Work in Progress, draft-touch-tcp-portnames-00.txt. [ID.DTLS.DCCP] T.Phelan, "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", IETF Work in Progress, draft-phelan-dccp-dtls-01.txt. [ID.DCCP.RTP] C. Perkins, "RTP and the Datagram Congestion Control Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp- rtp-01.txt. [ID.TSVWG.RAND] M. Larsen, F. Gont, "Port Randomization", IETF Work in Progress, draft-larsen-tsvwg-port-randomization-00. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC793] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, Sept. 1981 (STANDARD). [RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES," RFC 814, July 1982 (UNKNOWN). Fairhurst Expires May 20, 2007 [Page 13] Internet-Draft DCCP Service Codes November 2006 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000 (INFORMATIONAL). [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4347] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Author's Addresses Godred (Gorry) Fairhurst Department of Engineering University of Aberdeen Kings College Aberdeen, AB24 3UE UK Email: gorry@erg.abdn.ac.uk URL: http://www.erg.abdn.ac.uk/users/gorry Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information Fairhurst Expires May 20, 2007 [Page 14] Internet-Draft DCCP Service Codes November 2006 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fairhurst Expires May 20, 2007 [Page 15]