RFC 5595

The Datagram Congestion Control Protocol (DCCP) Service Codes

📅 published September 2009, from ietf

RFC 5595: The Datagram Congestion Control Protocol (DCCP) Service Codes 🎀

Part 1 of 5 💖

  • RFC number: 5595 🔢
  • Author: G. Fairhurst, University of Aberdeen 🧑‍🎓
  • Working group: Network Working Group 👯
  • Date: September 2009 📅
  • Category: Standards Track 👑
  • Updates: RFC 4340 🔧 (this one's a tiny glow-up of RFC 4340, bestie)

Abstract ✨

okay so this doc is all about how Service Codes get used by the Datagram Congestion Control Protocol, aka RFC 4340 💅 It explains why apps should actually bother setting a Service Code. A Service Code basically tells the server which service or app should handle a DCCP connection request 🎯 That gives you way more flexibility when it comes to assigning port numbers and multiplexing connections 🦋 Service Codes can also help middleboxes like NATs and firewalls coordinate with services in a more explicit way 🛡️ And yes, this document updates RFC 4340 🌸

Status of This Memo 📜

This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want the official standardization state of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 🔍 Also, distribution of this memo is unlimited 🌈

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) as they're in effect on the date this document was published 📖 Please read those carefully, because they spell out your rights and restrictions for this document 🧐 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 💻 They come with no warranty, as described in the BSD License 🙅‍♀️

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 💜 The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😬 So unless you get an adequate license from whoever controls the copyright in those 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 🚫 The exceptions are formatting it for publication as an RFC or translating 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

1. Introduction ✨

okay bestie, let's start with the basics 💖 DCCP defines a Service Code as a 4-byte value, which is 32 bits 🔢 It describes the application-level service that a client app wants to connect to ([RFC4340], Section 8.1.2) 🎯 A Service Code tells you which protocol gets used at the application layer, or which standard profile does, like [RTP-DCCP] 🎀 It is not meant to specify a variant of an application or a specific variant of a protocol (Section 2.2) 🙅‍♀️ That's a whole different job!

The Service Code mechanism lets an application declare the set of services linked to its server port numbers 🌸 This can change how an app talks to DCCP, which is kind of a big deal 👑 It also decouples two roles that port numbers usually have: indicating the service you want, and handling demultiplexing and state management 🧩 Now a DCCP app names the service it wants by putting the Service Code value in a DCCP-Request packet 📦 So each app ends up associating one or more Service Codes with each listening port ([RFC4340], Section 8.1.2) 🦋

Service Codes can help a firewall figure out the intended service, and they might also help other middleboxes, like a proxy server or a network address translator (NAT) [RFC2663] 🛡️ If a middlebox wants to know what type of data a flow claims to carry, it should use the Service Code to find out 🔍 When Service Codes are used consistently, they give a much more specific picture of the actual service than you'd get from the server port value alone ✨ For example, a Service Code can show the type of multimedia flow or the intended application behaviour 🎬 Honestly, that's so much more informative 😭

Using server ports more flexibly is also a win for applications where servers need to handle huge numbers of simultaneous-open ports to the same service 🚀 It's giving scalability 💅

Here's the tea though: RFC 4340 doesn't explain the motivation behind Service Codes 🫠 It also doesn't properly describe how Well Known and Registered server ports relate to Service Codes 🙈 This document is here to clear all that up, periodt 💜

Last thing: RFC 4340 says Service Codes aren't meant to be DCCP-specific 🌈 So Service Codes, or similar concepts, might be useful to other IETF transport protocols too 🧚 Main character energy for the whole idea 👑✨

1.1. History 🦋

okay so to get why Service Codes exist at all, we have to do a little DCCP history tea ☕

Most current transport protocols, like 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 are 16-bit values that tell you which application a connection or message is for. The client has to know the server port before it can set up a connection. You can get that info through out-of-band signalling (SDP [RFC4566] is one example), but usually a Published port just gets assigned to a particular protocol or app. HTTP typically lives on port 80 and SMTP on port 25, for example. Making a port Published [RFC1122] means registering with the Internet Assigned Numbers Authority (IANA). That includes defining a service with a unique keyword and reserving a port from a fixed pool [IANA] 📋

Back in the very first DCCP draft, the authors wanted to fix the Published port situation in a future-proof way, because the old method has some real problems 💀

  • The port space is not big enough for ports to be easily allocated (e.g., in an unregulated manner). So lots of applications run on unregistered ports, possibly colliding with other apps using them.
  • Port-based firewalls encourage app writers to disguise one application as another to sneak past firewall filter rules. That pushes firewall writers toward deep packet inspection to figure out which service a port number is really for. 🕵️‍♀️
  • ISPs often deploy transparent proxies, mainly to improve performance and cut costs. For example, TCP requests going to TCP port 80 often get redirected to a web proxy.

These issues are tangled together. When apps collide on the same Published-but-unregistered port, network security equipment has no simple way to tell them apart, so problems are pretty likely to pop up when features interact. It's giving chaos 🌪️

A transport protocol designer can't do much about apps that try to masquerade as other apps. For the ones that aren't hiding, the problem can be as simple as not being able to easily get a Published port. Honestly, the dream would be that every app writer can request a Well Known or Registered port and get one instantly, no questions asked. The 16-bit port space that's traditionally been used is just not big enough for that kind of easy allocation ✨

So the DCCP designers went looking for a different solution, and the idea was simple. A 32-bit server port space would be big enough to support very simple allocation policies. The catch is that a 32-bit port value was undesirable because of overhead (DCCP needed to be useful for low-rate applications) 🐢

The DCCP solution was a 32-bit Service Code [RFC4340] that's included only in the DCCP-Request packet. The 32-bit size was meant to make it trivially simple to get a unique value for each application. Putting the value in a DCCP-Request packet adds no extra overhead to the actual data flow. It's still enough for the end systems, and it gives any stateful middleboxes along the path extra information about which applications are in use 👑

Early discussion of DCCP also looked at an alternative to traditional ports. Instead, a client would use a 32-bit identifier to uniquely identify each connection, and the server would listen on a socket bound only to a Service Code. This was unambiguous, because the Service Code was the only identifier for a listening socket on the server side. The DCCP client put a Service Code in its request, which let it reach the matching listening application. The downside was that this prevented two servers for the same service from running on a single machine, which is trivial with ports. The design was also different enough from existing protocols that people worried it would make DCCP hard to use through NATs and other middleboxes 🙈

RFC 4340 dropped the 32-bit connection identifier in favor of two traditional 16-bit port values, one chosen by the server and one by the client. This lets middleboxes use similar techniques for DCCP, UDP, TCP, and so on. But it created a new question: "How does the server port relate to the Service Code?" The intent was that the Service Code identifies the application or protocol using DCCP, giving middleboxes info about what the connection is for. The pair of ports effectively forms a 32-bit connection identifier that's unique between a pair of end systems. 🧩

The large number of available, unique Service Code values means every application can be assigned its own unique Service Code. But there was still a problem. The server picks its port, yet the client needs to know that port to connect. Requiring out-of-band communication just to discover the server port was undesirable, so the chosen solution was to register DCCP server ports. That seems to clash with the whole point of Service Codes. It's trivial to get a Service Code, but it hasn't traditionally been trivial to get a Registered port from IANA. In the long run, it may not be possible to give each new application its own unique Registered DCCP port. As port numbers get scarce, that's a strong reason to associate more than one Service Code with a listening port. For example, two different applications could share the same server port and run on the same host at the same time, told apart by their different Service Codes 🎀

Service Codes give clients flexibility in how they identify the server application they want to talk to. The mechanism lets a server associate a set of server ports with a service. That set can be shared with other services on the same server host, which allows a larger number of concurrent connections for a particular service than you'd get when a service is identified by a single Published port number 🌈

1.2. Conventions Used in This Document 💅

When you see the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, they're to be read as described in RFC 2119 [RFC2119]. 📖

2. An Architecture for Service Codes 🏛️

DCCP uses a combination of ports and Service Codes to identify the server application ([RFC4340], Section 8.1.2). We'll break those down in the sections below 🧚

2.1. IANA Port Numbers 🔢

In DCCP, packets that belong to a connection are demultiplexed based on a combination of four values, {source IP address, source port, dest IP address, dest port}, just like in TCP. Each endpoint address is tied to a port number (forming a socket), and a pair of those associations uniquely identifies each connection. Ports are the fundamental per-packet demultiplexing function 💜

The Internet Assigned Numbers Authority currently manages the set of globally reserved port numbers [IANA]. The source port tied to a connection request, often called the "ephemeral port", is traditionally in the range 49152-65535, and it also includes the range 1024-49151. The client operating system usually picks the value for the ephemeral port. It's been suggested that randomizing that choice can help defend against "blind" attacks [Rand] in TCP. That method may also apply to other IETF-defined transport protocols, including DCCP 🦋

Traditionally, the destination (server) port value for a service gets determined in one of two ways. Either an operating system index points to a copy of the IANA table (for example, getportbyname() in Unix, which indexes the /etc/services file), or the application specifies a direct mapping 🗂️

The UDP and TCP port number space, 0..65535, is split into three ranges [RFC2780]:

  • 0..1023 "Well Known", also called "system" ports,
  • 1024..49151 "Registered", also called "user" ports, and
  • 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 don't need a server port in the Well Known or Registered range SHOULD use a Dynamic server port (one that isn't required to be registered in the DCCP Port registry). Clients can find the server port value for the services they want to connect to in a few ways. A common one is receiving an SDP record (Section 2.6) exchanged out-of-band, for example using SIP [RFC3261] or the Real Time Streaming Protocol (RTSP) [RFC2326]. DNS SRV resource records are another way to find a server port for a particular service based on the service's string name [RFC2782] 📡

Applications that don't use out-of-band signalling can still communicate, as long as both client and server agree on the port value to be used. That removes the need for every registered Service Code to be tied to an IANA-assigned server port (see also Section 2.7). 🫶

2.2. DCCP Service Code Values ✨

okay bestie, so DCCP gives every Service Code 4 bytes (see [RFC4340], Section 8.1.2) and you can write one in three ways: a decimal number (the canonical way 💅), a 4-character ASCII string [ANSI.X3-4.1986], or an 8-digit hexadecimal number. All standards-assigned Service Codes, including every value IANA hands out, are required to use a value that can be written with a subset of the ASCII character set. Private Service Codes don't have to follow that rule, though RFC 4340 suggests that people pick ASCII-friendly ones too 🫶

The Service Code tells you which application-level service a client wants to connect to. Services have been defined for the Real-Time Protocol (RTP) [RTP-DCCP], for example. In a different example, Datagram Transport Layer Security (DTLS) [RFC5238] is a transport-service (not an application-layer service), so apps using DTLS get identified by a set of matching Service Code values 🧚

Endpoints MUST associate a Service Code with every DCCP socket [RFC4340], both actively and passively opened. The app will usually supply it. One passive-listening port can be tied to more than one Service Code value, and a set of Service Codes could be associated with one or more server applications. That's way more flexible for matching services to port numbers than the socket pair (4-tuple of layer-3 addresses and layer-4 ports) can be 🌸 In the packet types defined so far, the Service Code only shows up in DCCP-Request ([RFC4340], Section 5.2) and DCCP-Response packets ([RFC4340], Section 5.3). New packet types (e.g., [RFC5596]) could carry one too 🦋

2.2.1. New Versions of Applications or Protocols 💖

Apps and protocols that handle version negotiation or indication over DCCP don't need a new server port or a new Service Code for every version. New versions SHOULD continue to use the same Service Code. If the devs feel a new version brings significant new capabilities (e.g., ones that will change the behavior of middleboxes), they MAY allocate a new Service Code associated with the same or a 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 it MAY share the same server port assignment(s) 🎀

2.3. Service Code Registry 🗂️

The registered Service Codes for the general Internet are defined in an IANA-controlled name space, and IANA manages new allocations in that space [RFC4340]. Private Service Codes aren't centrally allocated. They live in the decimal range 1056964608-1073741823 (i.e., 32-bit values with the high-order byte equal to 63, corresponding to the ASCII character '?') 🔮

Service Code associations with Well Known ports are also defined in the IANA DCCP Port registry (Section 2.1).

2.4. Zero Service Code 🙈

A Service Code of zero is "permanently reserved (it represents the absence of a meaningful Service Code)" [RFC4340]. It basically means no application info was provided. RFC 4340 says applications MAY be associated with this Service Code in the same way as other Service Code values, and this use is permitted for any server port. Iconic flexibility 👑

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 4294967295 in decimal (0xFFFFFFFF) as "invalid". This exists so implementations can use a special 4-byte value to mean "no valid Service Code" 🙅‍♀️ Implementations MUST NOT accept a DCCP-Request with this value, and they SHOULD NOT allow applications to bind to this Service Code value [RFC4340]. Non-negotiable, periodt 😤

2.6. SDP for Describing Service Codes 📄

Methods that currently signal destination port numbers, such as the Session Description Protocol (SDP) [RFC4566], need an extension to support DCCP Service Codes [RTP-DCCP] ✨

2.7. A Method to Hash the Service Code to a Dynamic Port 🧚‍♀️

Apps that don't use out-of-band signalling or an IANA-assigned port still need both the client and the server to agree on the server port value. This section describes an optional method that lets an app derive a default server port number from the Service Code. The returned value is in the Dynamic port range [RFC4340]:

     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;}

Here 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:

  • It identifies a default server port for each service.
  • It seeks to assign different Service Codes to different ports, but it does not guarantee an assignment is unique.
  • 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 🤯)
  • It avoids the port 0xFFFF, which is not accessible on all host platforms.

Apps 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 from 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 goes like this:

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.

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 way 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]. Main character energy 👑

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 Service Codes can reduce the need to correctly interpret port numbers, which opens up 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:

  • 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.
  • A middlebox that does not modify the intended application (e.g., NATs [RFC5597] and Firewalls) MUST NOT change the Service Code.
  • 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 ✨

okay so the combo of the Service Code and the server port is how a server figures out who a new DCCP-Request is for 👑. The Service Code is what hooks a new connection up to the right application service 🦋. Four cases can happen when two DCCP server apps are passively listening on the same host 💅:

  • the simplest one: two servers have different Service Codes and are bound to different server ports (Section 3.3.1) 🌸
  • two servers share the same DCCP Service Code value but are bound to different server ports (Section 3.3.2) 🧚
  • two servers use different DCCP Service Code values but are bound to the same server port (Section 3.3.1) 💜
  • two servers try 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) says an implementation:

  • 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 says:

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

This document updates the above text from RFC 4340 by replacing it with the following:

  • 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:

  • An implementation SHOULD provide a method that informs a server of the Service Code value that was selected by an active connection.

So 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:

  • 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] ✨.
  • 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" 💀.

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 ✨

this section is serious, bestie 😭 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].
  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 🔐.

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

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 ✨

okay so these are the informative refs, bestie 📚 they're not required reading to implement the thing, but they give you the backstory. here's the whole squad:

  • [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. 🎬
  • [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. 🦋

Author's Address 🧚

The author is Godred Fairhurst, and the contact details are below. 💖

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
📦 where this page comes from