[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fairhurst-dccp-serv-codes) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5595

DCCP WG                                                     G.Fairhurst
Internet Draft                                   University of Aberdeen
Expires: September 2007                                   June 19, 2007



                           The DCCP Service Code
                     draft-ietf-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 December 19, 2007.

Abstract

   This document describes the usage of Service Codes by the Datagram
   Congestion Control Protocol, RFC 4340. 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 behind network address translators and firewalls. This
   document motivates the setting of Service Codes by applications,
   rather than assigning a default Service Code value of zero. This
   updates the description provided in RFC4 4340.



G. Fairhurst          Expires December 19, 2007                [Page 1]

Internet-Draft            DCCP Service Codes                  June 2007


Table of Contents

   1. Introduction...................................................3
      1.1. Conventions used in this document.........................4
   2. An Architecture for supporting Service Codes...................5
      2.1. IANA Port Numbers.........................................5
      2.2. DCCP Service Code Values..................................6
      2.3. Zero Service Code.........................................6
      2.4. Reception of a DCCP-Request with a bound Service Code.....8
      2.5. Reception of a DCCP-Request with an unbound Service Code
      ....................................Error! Bookmark not defined.
      2.6. SDP for describing Service Codes..........................6
      2.7. Service Code Registry.....................................7
   3. Use of the DCCP Service Code...................................7
      3.1. Setting Service Codes at the Sender.......................7
      3.2. Using Service Codes in the Network........................7
      3.3. Using Service Codes at the Receiver.......................8
      3.4. Multiple Associations of Service Codes and Ports at Sender9
      3.5. Summary of Service Code and Port Handling.................9
   4. Implementation Support for Service Codes......................10
      4.1. Minimal Support..........................................10
      4.2. Standard Support.........................................10
      4.3. Enhanced Support.........................................11
      4.4. Tests to indicate the level of Support...................11
   5. Changes required to the API to support Service Codes..........12
      5.1. Interactions with IPsec..................................15
   6. Service Code Registry.........................................12
   7. Benchmarking Services Described in this document..............13
      7.1. Echo.....................................................13
      7.2. Daytime..................................................13
      7.3. Character generator......................................13
      7.4. Time service.............................................14
      7.5. PerfTest service.........................................14
   8. Security Considerations.......................................14
      8.1. Interactions of Service Codes and port numbers...........15
   9. IANA Considerations...........................................16
      9.1. Port number values allocated by this document............16
      9.2. Service Code values allocated by this document...........17
   10. Conclusions..................................................17
   11. Acknowledgments..............................................18
   12. References...................................................19
      12.1. Normative References....................................19
      12.2. Informative References..................................19
   13. Author's Addresses...........................................21
      13.1. Intellectual Property Statement.........................21
      13.2. Disclaimer of Validity..................................21
      13.3. Copyright Statement.....................................22


Fairhurst             Expires December 19, 2007                [Page 2]

Internet-Draft            DCCP Service Codes                  June 2007


   APPENDIX A: Informative Examples of Host Configuration...........23


1. Introduction

   Most Internet transport protocols use "well-known" port numbers
   [RFC814] to indicate which application service is associated with a
   connection or message; this includes TCP [RFC793], UDP [RFC768], SCTP
   [RFC2960], UDP-Lite [RFC3828], 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). A Service Code
   identifies the protocol (or a standard profile, e.g. [ID.DCCP.RTP])
   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.

   Service Codes allow a flexible correspondence between application-
   layer services and port numbers, which affects how applications
   interact with DCCP. This decouples the use of ports for connection
   demultiplexing and state management from their use to indicate a
   desired service. Only one application may listen on a specific port
   at any time, however when accepting a new connection, a port may be
   associated with more than one Service Code (the requested Service
   Code may then select the application).

   The use of Service Codes can assist in identifying the intended
   service when the server is located behind a network address
   translator (NAT) [RFC2663], [RFC2766] that modifies the port numbers
   associated with a flow. Middle-boxes (e.g. NATs, Firewalls) that
   desire to identify the type of data being transported by a flow,
   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).

   Use of a Service Code value, instead of binding a service to a
   particular publicly-known port number, permits a larger number of
   concurrent connections for a particular service. For example, this
   may be useful for applications where servers need to handle very
   large numbers of simultaneous open ports to the same service.



Fairhurst             Expires December 19, 2007                [Page 3]

Internet-Draft            DCCP Service Codes                  June 2007


   If an application does not set a Service Code, the connection is
   associated with a Service Code of zero, with the intended server
   identified only by the destination port number.

1.1. 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].

   All protocol code points and values are transmitted in network byte
   order (most significant byte first), with the most significant bit of
   each byte is placed in the left-most position of an 8-bit field.




































Fairhurst             Expires December 19, 2007                [Page 4]

Internet-Draft            DCCP Service Codes                  June 2007


2. An Architecture for supporting Service Codes

   DCCP defines the use of a combination of ports and Service Codes to
   identify the server application ([RFC4340], 8.1.2). These are
   described in the following sections. Section 3 describes the use of
   Service Codes by 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, SSH). 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 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 December 19, 2007                [Page 5]

Internet-Draft            DCCP Service Codes                  June 2007


   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] in TCP. Such
   methods may be applicable to other 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), a four character ASCII string, or an eight digit hexadecimal
   number.

   The Service Code identifies the application-level service to which a
   client application wishes to connect. Examples of services are RTP,
   TIME, ECHO. In a different example, DTLS provides a transport-service
   (not an application-layer service), therefore applications using DTLS
   are individually identified by a set of corresponding service codes.

   The Service Code is present only in DCCP-Request and DCCP-Response
   packets and 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). This decouples the
   use of ports for connection demultiplexing and state management, from
   their use to indicate a desired endpoint service.

   Service Codes allow a larger number of concurrent connections for a
   particular service than possible using well-known port numbers, by
   allowing endpoints to use a set of port numbers for the 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-service (section 2.1).

2.4. 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].




Fairhurst             Expires December 19, 2007                [Page 6]

Internet-Draft            DCCP Service Codes                  June 2007


2.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].
   Associations of Service Code with Ports may also be defined in the
   IANA DCCP Port Registry.



3. Use of the DCCP Service Code

   Like UDP, DCCP uses port numbers to demultiplex connections. Upon
   receipt of a DCCP-Request the Service Code value is matched against a
   list of available services.

3.1. Setting Service Codes at the Sender

   A client application SHOULD associate a DCCP-Request packet with a
   Service Code value that identifies the intended application-service
   to be used. Valid Service Codes are selected from the set of values
   assigned in the DCCP Service Code Registry maintained by IANA [IANA-
   SC], or from the uncoordinated private space ([RFC4340], 8.1.2.). An
   application that does not set a Service Code, MUST be associated with
   a Service Code value of zero.

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-service (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 in 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 NATs [RFC2663],
   [RFC2776]. 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


Fairhurst             Expires December 19, 2007                [Page 7]

Internet-Draft            DCCP Service Codes                  June 2007


   translate Service Codes. This document therefore recommends that
   Middleboxes SHOULD NOT modify the Service Code, unless they also
   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

   A Service Code is used by the host that receives a DCCP-Request to
   associate a DCCP connection with the corresponding application-
   service. At the server, this association must be explicit, i.e. if
   the connection is accepted, the requested Service Code MUST have been
   previously associated with the destination port at the server.

   An implementation MUST allow a server to be associated with 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 also allow a server to set a Service Code that applies to a set
   of acceptable destination port values.

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 Reset Code "Connection Refused". A host
   MAY also use the Reset Code "Too Busy" ([RFC4340], 8.1.3).

   When the destination port is bound to a server, the host MUST also
   verify that the port has been associated with the specified Service
   Code. A Service Code of zero MUST only be accepted for servers that
   have no associated Service Code or are explicitly associated with the
   Service Code value of zero. Two cases can occur:

   o  If the receiving host is listening on the specified destination
      port number and the Service Code of the DCCP-Request matches one
      of the Service Codes associated with this 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].





Fairhurst             Expires December 19, 2007                [Page 8]

Internet-Draft            DCCP Service Codes                  June 2007


   o  If the port is not associated with the requested Service Code,
      then the host MUST reject the connection by issuing a DCCP-Reset
      with the reset code "Bad Service Code"([RFC4340], 8.1.2).



3.3.2. Multiple Associations of Service Codes and Ports at the Server

   A Service Code MAY be associated with more than one destination port
   (wildcarding a set of port values). Also a single destination port
   MAY be associated with multiple Service Codes (wildcarding a set of
   Service Codes), although an active (open) connection can only be
   associated with a single Service Code [RFC4340].

   A 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 can only be used for a pre-specified service.

   When the service associated with a port is not permanently running
   at the Server, the arrival of a DCCP-Request may require launching
   an application server to accept messages from the DCCP connection.
   This operation could resemble that of "inetd". The server needs to
   provide a method to ensure that the DCCP-Request is associated with
   a server that handles the corresponding Service Code. This 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.

3.4. Summary of Service Code and Port Handling

   The basic operation of the Service Codes is as follows:

   o  A source host may:

       .  issue a DCCP-Request with a Service Code of zero and choose
          either a well-known/reserved destination port or a port number
          announced by some other means.

       .  issue a DCCP-Request with a non-zero Service Code and choose a
          destination port number that is associated with the specified
          Service Code at the destination.



Fairhurst             Expires December 19, 2007                [Page 9]

Internet-Draft            DCCP Service Codes                  June 2007


   o  A server may receive a DCCP-Request with a:

       .  zero Service Code. It validates that the port supports a
          Service Code of zero and then uses the destination port to
          identify the associated server.

       . non-zero Service Code, It determines whether an available
          service matching the Service Code is supported for the
          specified destination port. The session is associated with a
          corresponding server, and a DCCP-Response is returned.

   o  If the service is not available, the session is rejected and a
      DCCP-Reset packet is returned.



4. Implementation Support for Service Codes

   This document does not define how to implement Service Codes on a
   particular platform or using a specific operating system. It does
   define three levels of support that may be offered.

4.1. Minimal Support

   All Servers MUST be capable of accepting a DCCP-Request that contains
   a zero Service Code. These may be handled in the same way as other
   transport connections (e.g. UDP, TCP). At this level, a DCCP-Request
   with a non-zero Service Code MUST result in the connection being
   rejected. This limits interoperability with other levels. This model
   is suitable for platforms with limited capability, but is NOT
   RECOMMENDED for general use.

4.2. Standard Support

   At this level of support, a server accepts a DCCP-Request that
   contains any value of Service Code, including zero. The Service Code
   specified in a DCCP-Request message is checked against an internal
   database to determine whether the Service Code is associated with the
   port. This model is RECOMMENDED for general use.

   The design could be simplified if a single default Service Code were
   to be associated with a set of specific well-known ports, allowing a
   port to be mapped via a library or operating system function to a
   corresponding default Service Code (simplifying the association).
   Such a system however also MUST provide a way to allow a sending
   and/or receiving application to associate a non-default Service Code
   (specified by the application). Some higher layer protocols (e.g. RTP


Fairhurst             Expires December 19, 2007               [Page 10]

Internet-Draft            DCCP Service Codes                  June 2007


   [ID.DCCP.RTP]) are not associated with a single well-known port and
   must therefore use this latter method.

4.3. Enhanced Support

   A server offering Enhanced Support provides finer and more flexible
   control of the use of Service Codes and port numbers. This permits a
   receiver to accept DCCP-Requests with arbitrary mappings between
   Service Codes and port ranges, associating each connection with the
   appropriate application server (section 3.3.2). A single destination
   port number may be associated with more than one Service Code value.
   These may be associated with one or different server applications.

   This level of support may require operating systems to use a modified
   process to handle in-coming DCCP-Request packets and may allow
   policies to be defined. Appendix A provides some examples of methods
   that may be used to configure this support.

4.4. Tests to indicate the level of Support

   This section defines a series of tests that may be used to identify
   the level of support provided by a remote DCCP host.

   o  A client should always be able to contact a remote server using
      DCCP with a Service Code of zero on the port associated with the
      test service. A server offering Minimal Support will accept this
      connection and return a single packet response. A server offering
      Standard or Enhanced Support will reset the connection.

   o  A client testing for Standard Support could initiate a DCCP
      connection to a server using the port associated with the test
      service, and specifying a Service Code of TEST. A server offering
      either Standard Support or Enhanced Support will accept this
      connection and return a single packet response. A server offering
      only Minimal Support will reset the connection.

   o  A client testing for Enhanced Support could initiate a DCCP
      connection to a server using the port associated with the DISC
      service, but which specifies a Service Code of TEST (identifying
      the test service). A server offering Enhanced Support server that
      allows the TEST service to run on this port will accept the
      connection and return a single packet response. Other servers will
      reset the connection.

   The above tests require services to be supported by the server and
   permitted by the network and host security policies (see section 8).



Fairhurst             Expires December 19, 2007               [Page 11]

Internet-Draft            DCCP Service Codes                  June 2007


   >>> These tests could encourage open deployment of the test service,
   which may result in a security vulnerability -                                                     - is this OK? <<<



5. Changes required to the API to support Service Codes

   The use of Service Codes requires an API that allows a service to be
   associated with a Service Code in addition to 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 also select a specific Service Code
      where desired.

   o  Extend the existing socket parameterization command (e.g., Unix
      setsockopt()) to set a service-code option. This is implemented in
      the present Linux API for a DCCP socket (where the Service Code
      should be wrapped by htonl/ntohl to ensure network byte order).

   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.

   >>> Author note:

   May need to discuss:

   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], 6.1).

   Functions such as getnameinfo and getservent may also need to be
   updated.

   >>> End Author Note.

6. 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].



Fairhurst             Expires December 19, 2007               [Page 12]

Internet-Draft            DCCP Service Codes                  June 2007


   Service Code bindings to Ports may also be defined in the IANA DCCP
   Port Registry.



7. Benchmarking Services Described in this document

   A number of simple services are commonly supported by systems using
   DCCP and UDP, this section defines corresponding services for DCCP.
   These services are useful to debug and benchmark bidirectional DCCP
   connections. The IANA section of this document allocates a
   corresponding set of code points for these services.

7.1. Echo

   The operation of the DCCP echo service follows that specified for UDP
   [RFC862]: a server listens for DCCP connections; once a client has
   set up a connection, each data packet sent to the server will be
   copied (echoed) back to the client.

7.2. Test

   The operation of the DCCP test service is as follows: a server
   listens for DCCP connections; once a client has set up a connection,
   one data packet is returned to the client. The server then resets the
   connection.

   This service may be provided with a Service Code of zero, when a
   server provides Basic Support, to facilitate testing. To facilitate
   testing of a server provides Enhanced Support, this service may be
   provided as an additional service on port 9.

7.3. Daytime

   The DCCP daytime service is operationally equivalent to the
   connection-based TCP daytime service [RFC867]: any data received is
   discarded by the server; and generates a response sent in a DCCP data
   packet containing the current time and data as an ASCII string; after
   which the connection is closed.

7.4. Character generator

   The operation of the DCCP chargen service corresponds to the
   connection-based TCP chargen protocol [RFC864]: A server listens for
   incoming requests and, once a client has established a connection,
   continuously sends datagrams containing a random number (between 0
   and 512, up to the current path MTU) of characters. The service


Fairhurst             Expires December 19, 2007               [Page 13]

Internet-Draft            DCCP Service Codes                  June 2007


   terminates when the user either closes or aborts the connection.
   Congestion control is enforced using the mechanisms [RFC4340] and
   related documents.

   If necessary the receiver can enforce flow control on this service by
   using either or both of the Slow Receiver ([RFC4340], 11.6) and Data
   Dropped ([RFC4340], 11.7) options to signal the server to slow down.

   The chargen protocol provides a useful service that may be used for
   testing and measurement of bidirectional DCCP connectivity, as well
   as congestion control responsiveness. The datagram-based variant of
   chargen can be emulated with the DCCP ECHO service by changing the
   format of the datagrams sent by the client, hence these services
   complement each other.

7.5. Time service

   The format of timestamps and the operation of the DCCP time service
   is equivalent with the TCP time protocol variant [RFC868]: a server
   listens for incoming connections; after a client has established a
   new connection, the server sends a 4-byte timestamp; whereupon the
   client closes the connection.

7.6. PerfTest service

   The PerfTest concept specified by this document provides a generic
   service that may be used to benchmark and measure both unidirectional
   and bidirectional DCCP connections, as well as server and host DCCP
   stacks.

   This document defines a generic PerfTest service. The payload of DCCP
   packets associated with the DCCP PerfTest service are silently
   discarded by the receiver, and used only for gathering numerical
   performance data.

   The PerfTest server is identified by a combination of the port number
   and DCCP Service Code. It does not recommend a specific benchmarking
   software to use, but does allocate a port number specified that
   currently coincides with that of the open-source iperf benchmarking
   program [iperf].



8. Security Considerations

   This document does not describe new protocol functions.



Fairhurst             Expires December 19, 2007               [Page 14]

Internet-Draft            DCCP Service Codes                  June 2007


   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. Interpretation of DCCP Service Codes over-riding traditional use
      of reserved/well-known port numbers (see section 8.1)

   3. Interaction with IPsec and DTLS security (see section 8.2, on use
      of IPsec).

   4. Services used for benchmarking and testing may also be used to
      generate traffic for other purposes, and pose an opportunity for a
      Denial of Service attack. Care needs to be exercised when enabling
      these services in an operational network, or appropriate rate-
      limits should be provided to mitigate these effects.

8.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.

8.2. 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.



Fairhurst             Expires December 19, 2007               [Page 15]

Internet-Draft            DCCP Service Codes                  June 2007


   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 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.

   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].

9. IANA Considerations

   A set of new services are defined in section 6 and are summarized in
   this section.

9.1. Port number values allocated by this document

   IANA action is required to assign ports for use by DCCP. This
   document requests allocation of the following code points from the
   IANA DCCP Port numbers registry:

   >>>>>> IANA ACTION Please replace IANA THIS RFC, with the allocated
   RFC  number. <<<

   >>>>>> IANA ACTION Please assign a port number for use by the test
   method <<<

   echo      7/dccp   Echo SC:ECHO
   # IETF dccp WG, [IANA - THIS RFC]
   echo      [IANA-Assign a value] /dccp   test SC:TEST
   # IETF dccp WG, [IANA - THIS RFC]
   daytime   13/dccp  DayTime    SC:DTIM
   # IETF dccp WG, [IANA - THIS RFC]
   chatgen   19/dccp  Chargen    SC:CHAR
   # IETF dccp WG, [IANA - THIS RFC]
   time      37/dccp  Timeserver SC:TIME
   # IETF dccp WG, [IANA - THIS RFC]
   perf    5001/dccp  PerfTest   SC:PERF
   # IETF dccp WG, [IANA - THIS RFC]





Fairhurst             Expires December 19, 2007               [Page 16]

Internet-Draft            DCCP Service Codes                  June 2007


9.2. Service Code values allocated by this document

   This document solicits IANA action to allocate the following code
   points from the Service Code registry [IANA-SC]. The requested
   assignments are listed below and summarized in table 1. This set of
   Service Codes may be utilized for testing DCCP implementations and
   transmission paths.

   >>> IANA Please replace tbd by the assigned a port number in section
   9.1.

    +----------+------+----+-------------------------------+----------+
    | Service  | ASCII|Port|          Description          |   Ref    |
    | Code (SC)| Code |    |                               |          |
    +----------+------+----+-------------------------------+----------+
    |0x4543484f| ECHO |   7| Echo service                  | [RFC862] |
    |0x54455354| TEST | tbd| Test Service                  | [THISRFC]|
    |0x4454494d| DTIM |  13| Daytime server                | [RFC867] |
    |0x43484152| CHAR |  19| Character generator (chargen) | [RFC864] |
    |0x54494d45| TIME |  37| Timeserver                    | [RFC868] |
    |0x50455246| PERF |5001| Performance tests (e.g.       | *        |
    |          |      |    | iperf, ttcp, ...)             |          |
    +----------+------+----+-------------------------------+----------+
     Table 1: Allocation of Service Codes by this document.

     Notes:
     1)  Port is the default port associated with this service.
     2)  * Reference is this document.


   >> Author note, the I-D should finally use decimal allocations of the
   Service Code Valus.

   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 (e.g.
   [ID.DTLS.DCCP], [ID.DCCP.RTP]).


10. 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 updates, but does not obsolete, the
   protocol defined in RFC4340.


Fairhurst             Expires December 19, 2007               [Page 17]

Internet-Draft            DCCP Service Codes                  June 2007


   Service Codes, or similar concepts may also be useful to other IETF
   transport protocols [ID.Portnames]).

11. 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, and the DCCP WG for helpful
   comments on this topic, and Gerrit Renker for his help in determining
   DCCP behaviour, review of the document, and compilation of useful
   test applications defined in the IANA section of this document.





































Fairhurst             Expires December 19, 2007               [Page 18]

Internet-Draft            DCCP Service Codes                  June 2007


12. References

12.1. Normative References

   [RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts:
             Communication Layers, " STD 3, RFC 1122, Oct. 1989
             (STANDARD).

   [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).

12.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-xx.txt.

   [ID.DCCP.RTP] C. Perkins, "RTP and the Datagram Congestion Control
             Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp-
             rtp-xx.txt.

   [ID.TSVWG.RAND] M. Larsen, F. Gont, "Port Randomization", IETF Work
             in Progress, draft-larsen-tsvwg-port-randomization-00.

   [iperf]   http://dast.nlanr.net/Projects/Iperf/

   [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 December 19, 2007               [Page 19]

Internet-Draft            DCCP Service Codes                  June 2007


   [RFC862]  Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.

   [RFC864]  Postel, J., "Character Generator Protocol", STD 22, RFC
             864, May 1983.

   [RFC867]  Postel, J., "Daytime Protocol", STD 25, RFC 867, May 1983.

   [RFC868]   Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
             RFC 868, May 1983.

   [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC 2663,
             August 1999.

   [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation
             - Protocol Translation (NAT-PT)", RFC 2766, February 2000.

   [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.

   [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.

   [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
             G. Fairhurst, "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] Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.1", RFC 4346, April 2006.




Fairhurst             Expires December 19, 2007               [Page 20]

Internet-Draft            DCCP Service Codes                  June 2007


13. 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


13.1. 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
   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.

13.2. 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, THE
   IETF TRUST 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.


Fairhurst             Expires December 19, 2007               [Page 21]

Internet-Draft            DCCP Service Codes                  June 2007


13.3. Copyright Statement


   Copyright (C) The IETF Trust (2007).

   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.









































Fairhurst             Expires December 19, 2007               [Page 22]

Internet-Draft            DCCP Service Codes                  June 2007


APPENDIX A: Informative Examples of Host Configuration

   >>> The author would particularly welcome comments on this draft
   section

   The IETF does not normally define the formats used by implementers to
   store configuration data. The following example is therefore
   illustrative, and not a normative definition of how this should be
   done.

   In the example below, an implementation uses the /etc/services format
   widely used in UNIX, but provides an additional field to specify the
   service code value permitted:

   An example could be:

      discard 9/dccp/DISC

   This raises the question of how to permit multiple Service Codes for
   the same port, which could be introduced as:

      discard 9/dccp/DISC

      fpp 9/dccp/fdpz

   Where ffp is a hypothetical example of an application using the
   Service Code: fpdz, that has the same port as PERF. In this example,
   PERF is defined first and would be the default association.

   One drawback of this approach is that a Service Code could be
   associated with a range of port values, (e.g. when used to identify
   RTP sessions). The above syntax would require one line for each
   possible port number, which is not compact.

   An alternative is therefore to define a file format that separately
   specified Service Codes and the range of Port Numbers that are
   permitted.

   >>> Can we recommend just one method?










Fairhurst             Expires December 19, 2007               [Page 23]

Internet-Draft            DCCP Service Codes                  June 2007


   >>> RFC Editor please remove this section prior to publication.

   Change Log.

   01 introduced:

   - a replacement of the word *range* when referring to sets of dccp
   ports (they are not necessarily contiguous), noted by E. Kohler.

   - Addition of some Service Codes in IANA section.

   02 introduced:

   - add the use of profiles with DCCP, identified by Service Code, but
   not the use of protocol variants.

   - further detail on implementation levels (more input would be good)

   - added security consideration for traffic generators

   - added ref to UDPL for completeness

   - Corrected NiTs found by Gerrit Renker

   +++++++++++++++++++++++++++

   WG 00 (first WG version)

   This introduced revisions to make it a WG document.

   - Corrected language and responded to many helpful comments from
   Fernando Gont and Ian McDonald.

   - Added a test for which server behaviour is used.

   - Added some speculative text on how to implement the SC.

   - More input and discussion is requested from the WG.

   - Added an informative appendix on host configuration.

   - Merging of some sections to remove repetition and clarify wording.

   +++++++++++++++++++++++++++

   RFC4340 states (Service Codes are not intended to be DCCP-specific
   and are allocated by IANA.)


Fairhurst             Expires December 19, 2007               [Page 24]

Internet-Draft            DCCP Service Codes                  June 2007



















































Fairhurst             Expires December 19, 2007               [Page 25]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/