summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5595.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5595.txt')
-rw-r--r--doc/rfc/rfc5595.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5595.txt b/doc/rfc/rfc5595.txt
new file mode 100644
index 0000000..64a7e06
--- /dev/null
+++ b/doc/rfc/rfc5595.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group G. Fairhurst
+Request for Comments: 5595 University of Aberdeen
+Updates: 4340 September 2009
+Category: Standards Track
+
+
+ The Datagram Congestion Control Protocol (DCCP) Service Codes
+
+Abstract
+
+ This document describes the usage of Service Codes by the Datagram
+ Congestion Control Protocol, RFC 4340. It motivates the setting of a
+ Service Code by applications. Service Codes provide a method to
+ identify the intended service/application to process a DCCP
+ connection request. This provides improved flexibility in the use
+ and assignment of port numbers for connection multiplexing. The use
+ of a DCCP Service Code can also enable more explicit coordination of
+ services with middleboxes (e.g., network address translators and
+ firewalls). This document updates the specification provided in RFC
+ 4340.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright and License Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+
+
+
+Fairhurst Standards Track [Page 1]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. History ....................................................3
+ 1.2. Conventions Used in This Document ..........................6
+ 2. An Architecture for Service Codes ...............................6
+ 2.1. IANA Port Numbers ..........................................6
+ 2.2. DCCP Service Code Values ...................................7
+ 2.2.1. New Versions of Applications or Protocols ...........8
+ 2.3. Service Code Registry ......................................8
+ 2.4. Zero Service Code ..........................................9
+ 2.5. Invalid Service Code .......................................9
+ 2.6. SDP for Describing Service Codes ...........................9
+ 2.7. A Method to Hash the Service Code to a Dynamic Port ........9
+ 3. Use of the DCCP Service Code ...................................10
+ 3.1. Setting Service Codes at the Client .......................11
+ 3.2. Using Service Codes in the Network ........................11
+ 3.3. Using Service Codes at the Server .........................12
+ 3.3.1. Reception of a DCCP-Request ........................13
+ 3.3.2. Multiple Associations of a Service Code
+ with Ports .........................................14
+ 3.3.3. Automatically Launching a Server ...................14
+ 4. Security Considerations ........................................14
+ 4.1. Server Port Number Reuse ..................................15
+ 4.2. Association of Applications with Service Codes ............15
+ 4.3. Interactions with IPsec ...................................15
+ 5. IANA Considerations ............................................16
+ 6. Acknowledgments ................................................16
+ 7. References .....................................................17
+ 7.1. Normative References ......................................17
+ 7.2. Informative References ....................................17
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst Standards Track [Page 2]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+1. Introduction
+
+ DCCP specifies a Service Code as a 4-byte value (32 bits) that
+ describes the application-level service to which a client application
+ wishes to connect ([RFC4340], Section 8.1.2). A Service Code
+ identifies the protocol (or the standard profile, e.g., [RTP-DCCP])
+ to be used at the application layer. It is not intended to be used
+ to specify a variant of an application or a specific variant of a
+ protocol (Section 2.2).
+
+ The Service Code mechanism allows an application to declare the set
+ of services that are associated with server port numbers. This can
+ affect how an application interacts with DCCP. It also allows
+ decoupling of the role of port numbers to indicate a desired service
+ from the role of port numbers in demultiplexing and state management.
+ A DCCP application identifies the requested service by the Service
+ Code value in a DCCP-Request packet. Each application therefore
+ associates one or more Service Codes with each listening port
+ ([RFC4340], Section 8.1.2).
+
+ The use of Service Codes can assist in identifying the intended
+ service by a firewall and may assist other middleboxes (e.g., a proxy
+ server or network address translator (NAT) [RFC2663]). Middleboxes
+ that desire to identify the type of data a flow claims to transport
+ should utilize the Service Code for this purpose. When consistently
+ used, the Service Code can provide a more specific indication of the
+ actual service (e.g., indicating the type of multimedia flow or
+ intended application behaviour) than deriving this information from
+ the server port value.
+
+ The more flexible use of server ports can also offer benefits to
+ applications where servers need to handle very large numbers of
+ simultaneous-open ports to the same service.
+
+ RFC 4340 omits a description of the motivation behind Service Codes,
+ and it does not properly describe how Well Known and Registered
+ server ports relate to Service Codes. The intent of this document is
+ to clarify these issues.
+
+ RFC 4340 states that Service Codes are not intended to be DCCP-
+ specific. Service Codes, or similar concepts, may therefore also be
+ useful to other IETF transport protocols.
+
+1.1. History
+
+ It is simplest to understand the motivation for defining Service
+ Codes by describing the history of the DCCP protocol.
+
+
+
+
+Fairhurst Standards Track [Page 3]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ Most current Internet transport protocols (TCP [RFC793], UDP
+ [RFC768], SCTP (the Stream Control Transmission Protocol) [RFC4960],
+ and UDP-Lite [RFC3828]) use "Published" port numbers from the Well
+ Known or Registered number spaces [RFC814]. These 16-bit values
+ indicate the application service associated with a connection or
+ message. The server port must be known to the client to allow a
+ connection to be established. This may be achieved using out-of-band
+ signalling (e.g., described using SDP [RFC4566]), but more commonly a
+ Published port is allocated to a particular protocol or application;
+ for example, HTTP commonly uses port 80 and SMTP commonly uses port
+ 25. Making a port number Published [RFC1122] 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].
+
+ In the earliest draft of DCCP, the authors wanted to address the
+ issue of Published ports in a future-proof manner, since this method
+ suffers from several problems:
+
+ o The port space is not sufficiently large for ports to be easily
+ allocated (e.g., in an unregulated manner). Thus, many
+ applications operate using unregistered ports, possibly colliding
+ with use by other applications.
+
+ o The use of port-based firewalls encourages application writers to
+ disguise one application as another in an attempt to bypass
+ firewall filter rules. This motivates firewall writers to use
+ deep packet inspection in an attempt to identify the service
+ associated with a port number.
+
+ o ISPs often deploy transparent proxies, primarily to improve
+ performance and reduce costs. For example, TCP requests destined
+ to TCP port 80 are often redirected to a web proxy.
+
+ These issues are coupled. When applications collide on the same
+ Published-but-unregistered port, there is no simple way for network
+ security equipment to tell them apart, and thus it is likely that
+ problems will be introduced through the interaction of features.
+
+ There is little that a transport protocol designer can do about
+ applications that attempt to masquerade as other applications. For
+ ones that are not attempting to hide, the problem may be simply that
+ they cannot trivially obtain a Published port. Ideally, it should be
+ sufficiently easy that every application writer can request a Well
+ Known or Registered port and receive one instantly with no questions
+ asked. The 16-bit port space traditionally used is not large enough
+ to support such a trivial allocation of ports.
+
+
+
+
+Fairhurst Standards Track [Page 4]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ Thus, the designers of DCCP sought an alternative solution. The idea
+ was simple. A 32-bit server port space should be sufficiently large
+ to enable use of very simple allocation policies. However, overhead
+ considerations made a 32-bit port value undesirable (DCCP needed to
+ be useful for low-rate applications).
+
+ The solution in DCCP to this problem was to use a 32-bit Service Code
+ [RFC4340] that is included only in the DCCP-Request packet. The use
+ of a 32-bit value was intended to make it trivially simple to obtain
+ a unique value for each application. Placing the value in a DCCP-
+ Request packet requires no additional overhead for the actual data
+ flow. It is however sufficient for both the end systems, and
+ provides any stateful middleboxes along the path with additional
+ information to understand what applications are being used.
+
+ Early discussion of the DCCP protocol considered an alternative to
+ the use of traditional ports; instead, it was suggested that a client
+ use a 32-bit identifier to uniquely identify each connection and that
+ the server listen on a socket bound only to a Service Code. This
+ solution was unambiguous; the Service Code was the only identifier
+ for a listening socket at the server side. The DCCP client included
+ a Service Code in the request, allowing it to reach the corresponding
+ listening application. One downside was that this prevented
+ deployment of two servers for the same service on a single machine,
+ something that is trivial with ports. The design also suffered from
+ the downside of being sufficiently different from existing protocols
+ that there were concerns that it would hinder the use of DCCP through
+ NATs and other middleboxes.
+
+ RFC 4340 abandoned the use of a 32-bit connection identifier in favor
+ of two traditional 16-bit port values, one chosen by the server and
+ one by the client. This allows middleboxes to utilize similar
+ techniques for DCCP, UDP, TCP, etc. However, it introduced a new
+ problem: "How does the server port relate to the Service Code?" The
+ intent was that the Service Code identified the application or
+ protocol using DCCP, providing middleboxes with information about the
+ intended use of a connection, and that the pair of ports effectively
+ formed a 32-bit connection identifier, which was unique between a
+ pair of end systems.
+
+ The large number of available, unique Service Code values allows all
+ applications to be assigned a unique Service Code. However, there
+ remained a problem: the server port was chosen by the server, but the
+ client needed to know this port to establish a connection. It was
+ undesirable to mandate out-of-band communication to discover the
+ server port. The chosen solution was to register DCCP server ports.
+ The limited availability of DCCP server ports appears to contradict
+ the benefits of DCCP Service Codes because, although it may be
+
+
+
+Fairhurst Standards Track [Page 5]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ trivial to obtain a Service Code, it has not traditionally been
+ trivial to obtain a Registered port from IANA and, in the long-run,
+ it may not be possible to allocate a unique Registered DCCP port to
+ new applications. As port numbers become scarce, this motivates the
+ need to associate more than one Service Code with a listening port
+ (e.g., two different applications could be assigned the same server
+ port and need to run on the same host at the same time,
+ differentiated by their different associated Service Codes).
+
+ Service Codes provide flexibility in the way clients identify the
+ server application to which they wish to communicate. The mechanism
+ allows a server to associate a set of server ports with a service.
+ The set may be common with other services available at the same
+ server host, allowing a larger number of concurrent connections for a
+ particular service than possible when the service is identified by a
+ single Published port number.
+
+1.2. 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 [RFC2119].
+
+2. An Architecture for Service Codes
+
+ DCCP defines the use of a combination of ports and Service Codes to
+ identify the server application ([RFC4340], Section 8.1.2). These
+ are described in the following sections.
+
+2.1. IANA Port Numbers
+
+ In DCCP, the packets belonging to a connection are demultiplexed
+ based on a combination of four values {source IP address, source
+ port, dest IP address, dest port}, as in TCP. An endpoint address is
+ associated with a port number (e.g., forming a socket) and a pair of
+ associations uniquely identifies each connection. Ports provide the
+ fundamental per-packet demultiplexing function.
+
+ The Internet Assigned Numbers Authority currently manages the set of
+ globally reserved port numbers [IANA]. The source port associated
+ with a connection request, often known as the "ephemeral port", is
+ traditionally in the range 49152-65535 and also includes the range
+ 1024-49151. The value used for the ephemeral port is usually chosen
+ by the client operating system. It has been suggested that a
+ randomized choice port number value can help defend against "blind"
+ attacks [Rand] in TCP. This method may be applicable to other IETF-
+ defined transport protocols, including DCCP.
+
+
+
+
+Fairhurst Standards Track [Page 6]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ Traditionally, the destination (server) port value associated with a
+ service is determined either by an operating system index that points
+ to a copy of the IANA table (e.g., getportbyname() in Unix, which
+ indexes the /etc/services file) or by the application specifying a
+ direct mapping.
+
+ 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, and
+
+ o 49152..65535 "Dynamic", also called "private" ports.
+
+ DCCP supports Well Known and Registered ports. These are allocated
+ in the DCCP IANA Port Numbers registry ([RFC4340], Section 19.9).
+ Each Registered DCCP port MUST be associated with at least one pre-
+ defined Service Code.
+
+ Applications that do not need to use a server port in the Well Known
+ or Registered range SHOULD use a Dynamic server port (i.e., one not
+ required to be registered in the DCCP Port registry). Clients can
+ identify the server port value for the services to which they wish to
+ connect using a range of methods. One common method is by reception
+ of an SDP record (Section 2.6) exchanged out-of-band (e.g., using SIP
+ [RFC3261] or the Real Time Streaming Protocol (RTSP) [RFC2326]). DNS
+ SRV resource records also provide a way to identify a server port for
+ a particular service based on the service's string name [RFC2782].
+
+ Applications that do not use out-of-band signalling can still
+ communicate, provided that both client and server agree on the port
+ value to be used. This eliminates the need for each registered
+ Service Code to be allocated to an IANA-assigned server port (see
+ also Section 2.7).
+
+2.2. DCCP Service Code Values
+
+ DCCP specifies a 4-byte Service Code ([RFC4340], Section 8.1.2)
+ represented in one of three forms: a decimal number (the canonical
+ method), a 4-character ASCII string [ANSI.X3-4.1986], or an 8-digit
+ hexadecimal number. All standards assigned Service Codes, including
+ all values assigned by IANA, are required to use a value that may be
+ represented using a subset of the ASCII character set. Private
+ Service Codes do not need to follow this convention, although RFC
+ 4340 suggests that users choose Service Codes that may also be
+ represented in ASCII.
+
+
+
+
+Fairhurst Standards Track [Page 7]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ The Service Code identifies the application-level service to which a
+ client application wishes to connect. For example, services have
+ been defined for the Real-Time Protocol (RTP) [RTP-DCCP]. In a
+ different example, Datagram Transport Layer Security (DTLS) [RFC5238]
+ provides a transport-service (not an application-layer service);
+ therefore, applications using DTLS are individually identified by a
+ set of corresponding Service Code values.
+
+ Endpoints MUST associate a Service Code with every DCCP socket
+ [RFC4340], both actively and passively opened. The application will
+ generally supply this Service Code. A single passive-listening port
+ may be associated with more than one Service Code value. The set of
+ Service Codes could be associated with one or more server
+ applications. This permits a more flexible correspondence between
+ services and port numbers than is possible using the corresponding
+ socket pair (4-tuple of layer-3 addresses and layer-4 ports). In the
+ currently defined set of packet types, the Service Code value is
+ present only in DCCP-Request ([RFC4340], Section 5.2) and DCCP-
+ Response packets ([RFC4340], Section 5.3). Note that new DCCP packet
+ types (e.g., [RFC5596]) could also carry a Service Code value.
+
+2.2.1. New Versions of Applications or Protocols
+
+ Applications/protocols that provide version negotiation or indication
+ in the protocol operating over DCCP do not require a new server port
+ or new Service Code for each new protocol version. New versions of
+ such applications/protocols SHOULD continue to use the same Service
+ Code. If the application developers feel that the new version
+ provides significant new capabilities (e.g., that will change the
+ behavior of middleboxes), they MAY allocate a new Service Code
+ associated with the same or different set of Well Known ports. If
+ the new Service Code is associated with a Well Known or Registered
+ port, the DCCP Ports registry MUST also be updated to include the new
+ Service Code value, but MAY share the same server port assignment(s).
+
+2.3. Service Code Registry
+
+ The set of registered Service Codes 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].
+ Private Service Codes are not centrally allocated and are denoted by
+ the decimal range 1056964608-1073741823 (i.e., 32-bit values with the
+ high-order byte equal to a value of 63, corresponding to the ASCII
+ character '?').
+
+ Associations of Service Code with Well Known ports are also defined
+ in the IANA DCCP Port registry (Section 2.1).
+
+
+
+
+Fairhurst Standards Track [Page 8]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+2.4. Zero Service Code
+
+ A Service Code of zero is "permanently reserved (it represents the
+ absence of a meaningful Service Code)" [RFC4340]. This indicates
+ that no application information was provided. RFC 4340 states that
+ applications MAY be associated with this Service Code in the same way
+ as other Service Code values. This use is permitted for any server
+ port.
+
+ This document clarifies Section 19.8 of RFC 4340 by adding the
+ following:
+
+ Applications SHOULD NOT use a Service Code of zero.
+
+ Application writers that need a temporary Service Code value
+ SHOULD choose a value from the private range (Section 2.3).
+
+ Applications intended for deployment in the Internet are
+ encouraged to use an IANA-defined Service Code. If no specific
+ Service Code exists, they SHOULD request a new assignment from the
+ IANA.
+
+2.5. Invalid Service Code
+
+ RFC 4340 defines the Service Code value of 4294967295 in decimal
+ (0xFFFFFFFF) as "invalid". This is provided so implementations can
+ use a special 4-byte value to indicate "no valid Service Code".
+ Implementations MUST NOT accept a DCCP-Request with this value, and
+ SHOULD NOT allow applications to bind to this Service Code value
+ [RFC4340].
+
+2.6. SDP for Describing Service Codes
+
+ Methods that currently signal destination port numbers, such as the
+ Session Description Protocol (SDP) [RFC4566], require an extension to
+ support DCCP Service Codes [RTP-DCCP].
+
+2.7. A Method to Hash the Service Code to a Dynamic Port
+
+ Applications that do not use out-of-band signalling or an IANA-
+ assigned port still require both the client and server to agree on
+ the server port value to be used. This section describes an optional
+ method that allows an application to derive a default server port
+ number from the Service Code. The returned value is in the Dynamic
+ port range [RFC4340]:
+
+
+
+
+
+
+Fairhurst Standards Track [Page 9]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ int s_port; /* server port */
+ s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000;
+ if (s_port==0xFFFF) {s_port = 0xC000;}
+
+ where sc[] represents the 4 bytes of the Service Code, and sc[3] is
+ the least significant byte. For example, this function associates
+ SC:fdpz with the server port 64634.
+
+ This algorithm has the following properties:
+
+ o It identifies a default server port for each service.
+
+ o It seeks to assign different Service Codes to different ports, but
+ does not guarantee an assignment is unique.
+
+ o It preserves the 4 lowest bits of the final bytes of the Service
+ Code, which allows many common series of Service Codes to be
+ mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
+ Fooa and Foob would be assigned adjacent ports. (Note: this
+ consecutive numbering only applies to characters in the range 0-9
+ and A-O and P-Z. When the characters cross a range boundary, the
+ algorithm introduces a discontinuity, resulting in mapping to
+ non-consecutive ports. Hence, Fooo and Foop respectively map to
+ the decimal values of 65015 and 65000).
+
+ o It avoids the port 0xFFFF, which is not accessible on all host
+ platforms.
+
+ Applications and higher-layer protocols that have been assigned a
+ Service Code (or use a Service Code from the unassigned private
+ space) may use this method. It does not preclude other applications
+ using the selected server port, since DCCP servers are differentiated
+ by the Service Code value.
+
+3. Use of the DCCP Service Code
+
+ The basic operation of Service Codes is as follows:
+
+ A client initiating a connection:
+
+ - issues a DCCP-Request with a Service Code and chooses a
+ destination (server) port number that is expected to be
+ associated with the specified Service Code at the destination.
+
+
+
+
+
+
+
+
+Fairhurst Standards Track [Page 10]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ A server that receives a DCCP-Request:
+
+ - determines whether an available service matching the Service
+ Code is supported for the specified destination server port.
+ The session is associated with the Service Code and a
+ corresponding server. A DCCP-Response is returned.
+
+ - if the service is not available, the session is rejected and a
+ DCCP-Reset packet is returned.
+
+3.1. Setting Service Codes at the Client
+
+ A client application MUST associate every DCCP connection (and hence
+ every DCCP active socket) with a single Service Code value
+ [RFC4340]). This value is used in the corresponding DCCP-Request
+ packet.
+
+3.2. Using Service Codes in the Network
+
+ DCCP connections identified by the Service Code continue to use IP
+ addresses and ports, although neither port number may be Published.
+
+ Port numbers and IP addresses are the traditional methods to identify
+ a flow within an IP network. Middlebox [RFC3234] implementors
+ therefore need to note that new DCCP connections are identified by
+ the pair of server port and Service Code in addition to the IP
+ address. This means that the IANA may allocate a server port to more
+ than one DCCP application [RFC4340].
+
+ Network address and port translators, known collectively as NATs
+ [RFC2663], may interpret DCCP ports ([RFC2993] and [RFC5597]). They
+ may also interpret DCCP Service Codes. Interpreting DCCP Service
+ Codes can reduce the need to correctly interpret port numbers,
+ leading to new opportunities for network address and port
+ translators. Although it is encouraged to associate specific
+ delivery properties with the Service Code, e.g., to identify the
+ real-time nature of a flow that claims to be using RTP, there is no
+ guarantee that the actual connection data corresponds to the
+ associated Service Code. A middlebox implementor may still use deep
+ packet inspection, and other means, in an attempt to verify the
+ content of a connection.
+
+ The use of the DCCP Service Code can potentially lead to interactions
+ with other protocols that interpret or modify DCCP port numbers
+ [RFC3234]. The following additional clarifications update the
+ description provided in Section 16 of RFC 4340:
+
+
+
+
+
+Fairhurst Standards Track [Page 11]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ o A middlebox that intends to differentiate applications SHOULD
+ test the Service Code in addition to the destination or source
+ port of a DCCP-Request or DCCP-Response packet.
+
+ o A middlebox that does not modify the intended application
+ (e.g., NATs [RFC5597] and Firewalls) MUST NOT change the
+ Service Code.
+
+ o A middlebox MAY send a DCCP-Reset in response to a packet with
+ a Service Code that is considered unsuitable.
+
+3.3. Using Service Codes at the Server
+
+ The combination of the Service Code and server port disambiguates
+ incoming DCCP-Requests received by a server. The Service Code is
+ used to associate a new DCCP connection with the corresponding
+ application service. Four cases can arise when two DCCP server
+ applications passively listen on the same host:
+
+ o The simplest case arises when two servers are associated with
+ different Service Codes and are bound to different server ports
+ (Section 3.3.1).
+
+ o Two servers may be associated with the same DCCP Service Code
+ value but be bound to different server ports (Section 3.3.2).
+
+ o Two servers could use different DCCP Service Code values and be
+ bound to the same server port (Section 3.3.1).
+
+ o Two servers could attempt to use the same DCCP Service Code and
+ bind to the same server port. A DCCP implementation MUST
+ disallow this, since there is no way for the DCCP host to
+ direct a new connection to the correct server application.
+
+ RFC 4340 (Section 8.1.2) states that an implementation:
+
+ o MUST associate each active socket with exactly one Service Code
+ on a specified server port.
+
+ In addition, Section 8.1.2 of RFC 4340 also states:
+
+ o Passive sockets MAY, at the implementation's discretion, be
+ associated with more than one Service Code; this might let
+ multiple applications, or multiple versions of the same
+ application, listen on the same port, differentiated by Service
+ Code.
+
+
+
+
+
+Fairhurst Standards Track [Page 12]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ This document updates the above text from RFC 4340 by replacing it
+ with the following:
+
+ o An implementation SHOULD allow more than one Service Code to be
+ associated with a passive server port, enabling multiple
+ applications, or multiple versions of an application, to listen
+ on the same port, differentiated by the associated Service
+ Code.
+
+ It also adds:
+
+ o An implementation SHOULD provide a method that informs a server
+ of the Service Code value that was selected by an active
+ connection.
+
+ A single passively opened (listening) port MAY therefore be
+ associated with multiple Service Codes, although an active (open)
+ connection can only be associated with a single Service Code. A
+ single application may wish to accept connections for more than one
+ Service Code using the same server port. This may allow a server to
+ offer more than the limit of 65,536 services depending on the size of
+ the Port field. The upper limit is based solely on the number of
+ unique connections between two hosts (i.e., 4,294,967,296).
+
+3.3.1. Reception of a DCCP-Request
+
+ When a DCCP-Request is received and the specified destination port is
+ not bound to a server, the host MUST reject the connection by issuing
+ a DCCP-Reset with the Reset Code "Connection Refused". A host MAY
+ also use the Reset Code "Too Busy" ([RFC4340], Section 8.1.3).
+
+ When the requested destination port is bound to a server, the host
+ MUST also verify that the server port is associated with the
+ specified Service Code (there could be multiple Service Code values
+ associated with the same server port). Two cases can occur:
+
+ o If the receiving host is listening on a server port and the DCCP-
+ Request uses a Service Code that is associated with the port, the
+ host accepts the connection. Once connected, the server returns a
+ copy of the Service Code in the DCCP-Response packet, completing
+ the initial handshake [RFC4340].
+
+ o If the server port is not associated with the requested Service
+ Code, the server SHOULD reject the request by sending a DCCP-Reset
+ packet with the Reset Code 8, "Bad Service Code" ([RFC4340],
+ Section 8.1.2), but MAY use the reason "Connection Refused".
+
+
+
+
+
+Fairhurst Standards Track [Page 13]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ After a connection has been accepted, the protocol control block is
+ associated with a pair of ports, a pair of IP addresses, and a single
+ Service Code value.
+
+3.3.2. Multiple Associations of a Service Code with Ports
+
+ DCCP Service Codes are not restricted to specific ports, although
+ they may be associated with a specific Well Known port. This allows
+ the same DCCP Service Code value to be associated with more than one
+ server port (in either the active or passive state).
+
+3.3.3. Automatically Launching a Server
+
+ A host implementation may permit a service to be associated with a
+ server port (or range of ports) that is not permanently running at
+ the server. In this case, the arrival of a DCCP-Request may require
+ a method to associate a DCCP-Request with a server that handles the
+ corresponding Service Code. This operation could resemble that of
+ "inetd" [inetd].
+
+ As in the previous section, when the specified Service Code is not
+ associated with the specified server port, the connection MUST be
+ aborted and a DCCP Reset message sent [RFC4340].
+
+4. Security Considerations
+
+ The security considerations of RFC 4340 identify and offer guidance
+ on security issues relating to DCCP. This document discusses the
+ usage of Service Codes. It does not describe new protocol functions.
+
+ All IPsec modes protect the integrity of the DCCP header. This
+ protects the Service Code field from undetected modification within
+ the network. In addition, the IPsec Encapsulated Security Payload
+ (ESP) mode may be used to encrypt the Service Code field, hiding the
+ Service Code value within the network and also preventing
+ interpretation by middleboxes. The DCCP header is not protected by
+ application-layer security (e.g., the use of DTLS [RFC5238] as
+ specified in DTLS/DCCP [RFC4347]).
+
+ There are four areas of security that are important:
+
+ 1. Server Port number reuse (Section 4.1).
+
+ 2. Interaction with NATs and firewalls (Section 3.2 describes
+ middlebox behavior). Requirements relating to DCCP are described
+ in [RFC5597].
+
+
+
+
+
+Fairhurst Standards Track [Page 14]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ 3. Interpretation of DCCP Service Codes overriding traditional use of
+ reserved/Well Known port numbers (Section 4.2).
+
+ 4. Interaction with IPsec and DTLS security (Section 4.3).
+
+4.1. Server Port Number Reuse
+
+ Service Codes are used in addition to ports when demultiplexing
+ incoming connections. This changes the service model to be used by
+ applications and middleboxes. The Port Numbers registry already
+ contains instances of multiple application registrations for a single
+ port number for TCP and UDP. These are relatively rare. Since the
+ DCCP Service Code allows multiple applications to safely share the
+ same port number, even on the same host, server port number reuse in
+ DCCP may be more common than in TCP and UDP.
+
+4.2. Association of Applications with Service Codes
+
+ The use of Service Codes provides more ready feedback that a concrete
+ service is associated with a given port on a server than for a
+ service that does not employ Service Codes. By responding to an
+ inbound connection request, systems not using these codes may
+ indicate that some service is, or is not, available on a given port,
+ but systems using this mechanism immediately provide confirmation (or
+ denial) that a particular service is present. This may have
+ implications in terms of port scanning and reconnaissance.
+
+ Care needs to be exercised when interpreting the mapping of a Service
+ Code value to the corresponding service. The same service
+ (application) may be 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
+ [RFC5238]. Other possibilities include the use of a private Service
+ Code to map to an application that has already been assigned an IANA-
+ defined Service Code value, or multiple Service Code values that map
+ to a single application providing more than one service. Different
+ versions of a service (application) may also be mapped to a
+ corresponding set of Service Code values.
+
+ Processing of Service Codes may imply more processing than currently
+ associated with incoming port numbers. Implementors need to guard
+ against increasing opportunities for Denial of Service attacks.
+
+4.3. Interactions with IPsec
+
+ The Internet Key Exchange protocol (IKEv2) does not currently specify
+ a method to use DCCP Service Codes as a part of the information used
+ to set up an IPsec security association.
+
+
+
+Fairhurst Standards Track [Page 15]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ 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
+ within other firewall 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.
+
+5. IANA Considerations
+
+ This document does not update the IANA allocation procedures for the
+ DCCP Port Number and DCCP Service Codes Registries as defined in RFC
+ 4340.
+
+ For completeness, the document notes that it is not required to
+ supply an approved document (e.g., a published RFC) to support an
+ application for a DCCP Service Code or port number value, although
+ RFCs may be used to request Service Code values via the IANA
+ Considerations section. A specification is however required to
+ allocate a Service Code that uses a combination of ASCII digits,
+ uppercase letters, and character space, '-', '.', and '/') [RFC4340].
+
+6. 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, Fernando Gont, Eddie Kohler, and the DCCP WG for
+ helpful comments on this topic, and Gerrit Renker for his help in
+ determining DCCP behavior and review of this document. Mark Handley
+ provided significant input to the text on the definition of Service
+ Codes and their usage. He also contributed much of the material that
+ has formed the historical background section.
+
+
+
+
+
+
+
+
+
+Fairhurst Standards Track [Page 16]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
+ Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
+
+ [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT)
+ Behavioral Requirements for the Datagram Congestion
+ Control Protocol", BCP 150, RFC 5597, September 2009.
+
+7.2. Informative References
+
+ [ANSI.X3-4.1986]
+ American National Standards Institute, "Coded Character
+ Set - 7-bit American Standard Code for Information
+ Interchange", ANSI X3.4, 1986.
+
+ [IANA] Internet Assigned Numbers Authority, www.iana.org.
+
+ [RTP-DCCP] Perkins, C., "RTP and the Datagram Congestion Control
+ Protocol (DCCP)", Work in Progress, June 2007.
+
+ [Rand] Larsen, M. and F. Gont, "Port Randomization", Work in
+ Progress, March 2009.
+
+ [inetd] The extended inetd project, http://xinetd.org.
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC814] Clark, D., "Name, addresses, ports, and routes", RFC 814,
+ July 1982.
+
+ [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+ Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+
+
+
+
+
+Fairhurst Standards Track [Page 17]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations", RFC
+ 2663, August 1999.
+
+ [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+ Values In the Internet Protocol and Related Headers", BCP
+ 37, RFC 2780, March 2000.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
+ November 2000.
+
+ [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+ Issues", RFC 3234, February 2002.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
+ and G. Fairhurst, Ed., "The Lightweight User Datagram
+ Protocol (UDP-Lite)", RFC 3828, July 2004.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
+ RFC 4960, September 2007.
+
+ [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
+ the Datagram Congestion Control Protocol (DCCP)", RFC
+ 5238, May 2008.
+
+ [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol
+ (DCCP) Simultaneous-Open Technique to Facilitate
+ NAT/Middlebox Traversal", RFC 5596, September 2009.
+
+
+
+
+
+Fairhurst Standards Track [Page 18]
+
+RFC 5595 DCCP Service Codes September 2009
+
+
+Author's Address
+
+ Godred Fairhurst,
+ School 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst Standards Track [Page 19]
+