Section 18. Security Considerations

DCCP does not provide cryptographic security guarantees.
   Applications desiring cryptographic security services (integrity,
   authentication, confidentiality, access control, and anti-replay
   protection) should use IPsec or end-to-end security of some kind;
   Secure RTP is one candidate protocol [RFC3711].
   Nevertheless, DCCP is intended to protect against some classes of
   attackers: Attackers cannot hijack a DCCP connection (close the
   connection unexpectedly, or cause attacker data to be accepted by an
   endpoint as if it came from the sender) unless they can guess valid
   sequence numbers.  Thus, as long as endpoints choose initial sequence
   numbers well, a DCCP attacker must snoop on data packets to get any
   reasonable probability of success.  Sequence number validity checks
   provide this guarantee.  Section 7.5.5 describes sequence number
   security further.  This security property only holds assuming that
   DCCP's random numbers are chosen according to the guidelines in
   [RFC4086].
   DCCP also provides mechanisms to limit the potential impact of some
   denial-of-service attacks.  These mechanisms include Init Cookie
   (Section 8.1.4), the DCCP-CloseReq packet (Section 5.5), the
   Application Not Listening Drop Code (Section 11.7.2), limitations on
   the processing of options that might cause connection reset (Section
   7.5.5), limitations on the processing of some ICMP messages (Section
   14.1), and various rate limits, which let servers avoid extensive
   computation or packet generation (Sections 7.5.3, 8.1.3, and others).
   DCCP provides no protection against attackers that can snoop on data
   packets.
18.1.  Security Considerations for Partial Checksums
   The partial checksum facility has a separate security impact,
   particularly in its interaction with authentication and encryption
   mechanisms.  The impact is the same in DCCP as in the UDP-Lite
   protocol, and what follows was adapted from the corresponding text in
   the UDP-Lite specification [RFC3828].
   When a DCCP packet's Checksum Coverage field is not zero, the
   uncovered portion of a packet may change in transit.  This is
   contrary to the idea behind most authentication mechanisms:
   authentication succeeds if the packet has not changed in transit.
   Unless authentication mechanisms that operate only on the sensitive
   part of packets are developed and used, authentication will always
   fail for partially-checksummed DCCP packets whose uncovered part has
   been damaged.
   The IPsec integrity check (Encapsulation Security Protocol, ESP, or
   Authentication Header, AH) is applied (at least) to the entire IP
   packet payload.  Corruption of any bit within that area will then
   result in the IP receiver's discarding a DCCP packet, even if the
   corruption happened in an uncovered part of the DCCP application
   data.
   When IPsec is used with ESP payload encryption, a link can not
   determine the specific transport protocol of a packet being forwarded
   by inspecting the IP packet payload.  In this case, the link MUST
   provide a standard integrity check covering the entire IP packet and
   payload.  DCCP partial checksums provide no benefit in this case.
   Encryption (e.g., at the transport or application levels) may be
   used.  Note that omitting an integrity check can, under certain
   circumstances, compromise confidentiality [B98].
   If a few bits of an encrypted packet are damaged, the decryption
   transform will typically spread errors so that the packet becomes too
   damaged to be of use.  Many encryption transforms today exhibit this
   behavior.  There exist encryption transforms, stream ciphers, that do
   not cause error propagation.  Proper use of stream ciphers can be
   quite difficult, especially when authentication checking is omitted
   [BB01].  In particular, an attacker can cause predictable changes to
   the ultimate plaintext, even without being able to decrypt the
   ciphertext.