Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
updated by
Extracted elements (29)
DCCP is preferred over UDP for syslog over DTLS because UDP lacks congestion control; unrestricted syslog data over UDP is problematic for stable Internet operation. DCCP's built-in congestion control (CCID 3 required, CCID 2 recommended) addresses this.
DTLS secures syslog only on a hop-by-hop basis; the authenticated identity of the transport sender (e.g., certificate subject name) is not necessarily related to the HOSTNAME field of the syslog message. RFC 5848 (Signed Syslog Messages) should be used when end-to-end message origin authentication is required.
Where privacy is not a requirement, using a NULL encryption algorithm is advantageous because, as RFC 5424 notes, 'passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire'. This justifies allowing NULL encryption as an option.
A DTLS record MUST NOT span multiple datagrams. For UDP, message size limits are governed by RFC 5426 Section 3.2; for DCCP, the implementer SHOULD determine the maximum record size from RFC 4340. The common interoperability baseline requires receivers to handle at least 2048-octet messages.
Syslog over DTLS is designed to minimize security and operational differences from syslog over TLS (RFC 5425). All normative requirements of RFC 5425 Section 5 apply to this specification, and the two share port 6514.
A transport receiver MUST be able to process messages with a length up to and including 2048 octets. Transport receivers SHOULD be able to process messages up to and including 8192 octets. Message size SHOULD NOT exceed the DTLS maximum record size of 2^14 bytes.
A transport sender MUST close the DTLS connection when no more syslog messages are expected and MUST send a DTLS close_notify alert before closing. Once the transport receiver gets a close_notify, it MUST reply with a close_notify.
All syslog messages MUST be sent as DTLS 'application data'. A transport receiver MUST use the message length field to delimit a syslog message.
Both the syslog transport sender (DTLS client) and the transport receiver (DTLS server) MUST implement certificate-based authentication, including certificate validation per RFC 5425 Sections 4.2.1 and 4.2.2.
Both transport receiver and transport sender implementations MUST provide means to generate a key pair and self-signed certificate in case a key pair and certificate are not available through another mechanism.
If DCCP is available, syslog over DTLS over DCCP is RECOMMENDED in preference to syslog over DTLS over UDP. Implementations of syslog over DTLS over DCCP MUST support CCID 3 and SHOULD support CCID 2.
If DTLS renegotiation is allowed, the specification in RFC 5746 MUST be followed, and the implementation MUST ensure the connection retains adequate security and that certificate identities do not change during renegotiation.
Implementations MUST support DTLS 1.0 (RFC 4347) and MUST support the mandatory cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (RFC 5246). Implementations MUST NOT negotiate a cipher suite that employs NULL integrity or authentication algorithms.
Implementations MUST support DTLS over UDP and SHOULD support DTLS over DCCP. Syslog over DTLS over TCP MUST NOT be used; TLS over TCP (RFC 5425) is the appropriate mechanism when a reliable secure transport is required.
Implementations MUST support the DoS countermeasures (cookie exchange) defined by DTLS. The transport sender MUST NOT send any syslog messages before the DTLS handshake has successfully completed.
The transport receiver and transport sender SHOULD provide mechanisms to record the certificate or certificate fingerprint used by the remote endpoint for correlating an identity with sent or received data.
The transport receiver (DTLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing a connection it decides to terminate due to inactivity.
Where privacy is REQUIRED, implementations must negotiate a cipher suite with a non-NULL encryption algorithm or achieve privacy by other means such as a physically secured network.
DTLS provides a cookie exchange mechanism during the handshake to counter DoS attacks, and a sequence number in the record header to counter replay attacks, both of which address key syslog security threats.
The default port for syslog over DTLS is UDP and DCCP port 6514, the same value used for syslog over TLS. The DCCP service code assigned to syslog is SYLG (numeric value 1398361159).
The syslog transport sender is always the DTLS client and the transport receiver is always the DTLS server. Session demultiplexing in UDP or DCCP is achieved by the application mapping a unique (remote address, remote port, local address, local port) tuple to a session.
IANA assigned DCCP service code SYLG (1398361159) for the Syslog Protocol in the Service Code subregistry of the DCCP Parameters registry, referencing RFC 6012.
IANA updated the port registry to assign port 6514/udp (syslog-tls) and 6514/dccp (syslog-tls) for syslog over DTLS, referencing RFC 6012.
An attacker may use a spoofed IP source to engage a DTLS server in a cryptographic handshake to deliberately consume server resources (DoS). The DTLS cookie exchange mechanism is the primary countermeasure.
An inadequate RNG or PRNG used to generate key pairs can result in little or no security. RFC 4086 guidance on random number generation MUST be followed when generating transport sender and receiver key pairs.
DTLS renegotiation may be vulnerable to attacks described in RFC 5746. It is RECOMMENDED that renegotiation be disabled for syslog over DTLS; if allowed, RFC 5746 must be followed and certificate identities must not change across renegotiation.
The DTLS transports described are unreliable; messages may be lost or removed by an attacker without the receiver's knowledge. Implementers requiring a lossless stream should use TLS/TCP, and signed syslog messages (RFC 5848) can provide indication of message loss.
Trust anchor installation and storage is critical. Self-signed certificates used as trust anchors must be transmitted via out-of-band steps and verified (e.g., via certificate fingerprint per Section 5.3.1). Changes to trust anchor information can cause acceptance of certificates that should be rejected.
DTLS application data for syslog consists of one or more SYSLOG-FRAMEs. Each SYSLOG-FRAME is MSG-LEN SP SYSLOG-MSG, where MSG-LEN is a decimal octet count (nonzero leading digit) and SP is ASCII 0x20. Multiple messages may share a single DTLS record or a message may span multiple DTLS records.