Threat Advisory - DCCP for (D)DoS
Executive summary
Recent attacks against Akamai customers have leveraged a networking protocol known as protocol 33, or Datagram Congestion Control Protocol (DCCP). These attacks prompted the Akamai SIRT team to look into the protocol further and offer insights and mitigation strategies for network defenders.
DCCP: TL;DR
The intended DCCP use case is for long-lived or large data flows that would typically be handled via User Datagram Protocol (UDP). In most UDP implementations, the network congestion control mechanisms implemented by DCCP aren't handled at all. And when they are, they're implemented at the application layer on a case-by-case basis.
In a sense, DCCP is a more reliable "unreliable" network protocol. It was designed to minimize data and processing overhead of time-sensitive (real-time/streaming) data delivery (typically associated with UDP), while providing improved congestion control and data exchange that typically aren't associated with UDP flows. It serves as a sweet spot between the UDP and the Transmission Control Protocol (TCP), aiming to provide the speed and ease of UDP, with the added benefit of congestion and flow control typically associated with TCP.
While DCCP does have some features akin to TCP, it is far less featureful than actual TCP implementations, in part to reduce processing overhead for lower powered devices. Additionally, it was engineered to work well on networks with high levels of bandwidth fluctuation where congestion problems could arise, such as mobile networks, but generally across the Internet where a lack of congestion control in UDP and a pile on from wide-spread UDP usage for large/prolonged data flows raised concerns of overwhelming networks.
The protocol
DCCP, like TCP, requires a three-way handshake before it can begin data transmission. The diagram below is an example data flow using DCCP that was taken directly from RFC4340 (Section 4.1).
The connection is established using a DCCP-Request packet, which expects a DCCP-Response packet, triggering an DCCP-Ack packet from the initiator. Once this handshake is completed, data transmission begins with a series of other purpose built protocol control packets. Unlike TCP, DCCP has specially-designed protocol packet structures for the individual components of the protocol and doesn't utilize flags, options, or other conventions typically associated with TCP. Below is a list of the various packet types of the DCCP protocol, taken directly from RFC4340 (Section 4.1).
In the attacks against Akamai customers I observed, 100% of the traffic consisted of DCCP-Request packets. These packets are essentially SYN floods of the DCCP protocol variety. Seeing as none of the attacked customers are exposing applications that utilize DCCP, these attacks appear to be volumetric in nature and likely geared towards bypassing defenses that focus on TCP and UDP workflows.
The attacks of tomorrrow?
Having only seen DCCP-Request floods thus far doesn't mean we won't see additional abuse of this protocol in the future. A DCCP-Request is just one of multiple packet formats, shown in Figure 2, within the protocol that could be leveraged for abuse, and as these attacks appear to be volumetric in nature, even junk padding will likely suffice for attackers going forward.
So long as attackers properly configure IP headers in the packet, they'll successfully route attack traffic to intended victims and fly under the radar of TCP/UDP-centric defense strategies and technologies.
Reflection & amplification potential
As outlined above, the DCCP protocol requires a three-way handshake before data transmission will take place. This means at first glance that a reflection/amplification attack is unlikely. When looking over actual data flows, however, it does appear there is a small reflection and amplification potential with this protocol's own handshake.
A reflected attack using DCCP would be akin to a SYN-ACK reflection. The attack would look like a spoofed DCCP-Request (54 bytes) flood to actual DCCP listening hosts. The DCCP enabled host would in turn attempt to complete the handshake with the spoofed source, resulting in a DCCP-Response (62 bytes) reflection.
This is different from a SYN-ACK reflection because DCCP packets contain data, whereas a SYN/SYN-ACK handshake typically consists of length 0 packet exchanges using bitmask flags. In DCCP, these purpose built packets do require data for the handshake to occur, and by default the DCCP-Response packet is 8 bytes longer than the DCCP-Request packet that triggers it. This does provide a small amount of amplification, but not a huge concern.
The primary reason that we're unlikely to see these types of attacks in the wild in a reflection/amplification capacity today is due to the lack of hosts on the internet utilizing this protocol. If widespread adoption of the protocol takes place, which would be impractical, this could be one of the attack variations we encounter as the pool of suitable reflectors grows.
Landscape
The DCCP landscape is a relatively young one. While the project appears to have made it through RFC processes, and initial development was introduced in 2007, it appears that it hasn't really found adoption.
While attempting to identify real world use cases, we were unable to find a single application that actually utilizes the protocol. This includes source code searches against GitHub for SOCK_DCCP declarations, a programmatic constant used when setting up a Socket in source code of multiple supported languages.
Although DCCP capabilities have been present in the Linux Kernel since 2.6.14, it doesn't appear that DCCP sockets are supported/enabled by all "mainstream" Linux distros out of the box. Others do include it, and have it enabled by default, but it isn't as ubiquitous as other supported protocols. Windows on the other hand doesn't appear to support the protocol at all.
Mitigation today
All networks are created and used differently. Organizations may opt to do baseline flow analysis for DCCP traffic across their edge before enacting the advice presented here as it is a very aggressive defensive posture. However, given the lack of widespread adoption of DCCP (protocol 33), a blanket ACL DROP seems reasonable as a mitigation and possibly even a pre-mitigation strategy for organizations under active or anticipated attack.
Mitigation tomorrow
DCCP could see adoption in the future across streaming media and gaming applications. Given the nature of the protocol, we'll need to keep an eye on adoption going forward. If adoption of the protocol makes blanket mitigation techniques impossible, DCCP-Request challenges will likely need to be developed to mitigate the risks of over-mitigation and application breakage.
Sample flows
Sample PCAPs of the protocol can be found in the WireShark sample traffic repository for mitigation teams to review what a real world traffic flow looks like.
Closing
Attackers are always probing for new methods to hurt their intended victims. DCCP is just the latest trial run from an attacker trying to maximize damage in new and creative ways. There are over 140 standardized protocols numbers encompassed by the Internet Protocol (IP) as of today, and there will likely be more added as technology continues to evolve. While DCCP appears to be the latest protocol probed for abuse capabilities, its lack of adoption prevents it from being a major concern, outside of volumetric attacks or myopic defense strategies that fail to account for abuse of and mitigation capabilities for less common network protocols.
