Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
draft-ietf-syslog-dtls-00.txt

Abstract

This document describes the transport of syslog messages over DTLS (Datagram Transport Level Security). It provides a secure transport for syslog messages in cases where a connection-less transport is desired.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

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

Copyright Notice

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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such 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, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Security Requirements for Syslog
• 4. Using DTLS to Secure Syslog
• 5. Protocol Elements
• 5.1. Transport
• 5.1.1. Congestion Control
• 5.1.2. Reliability
• 5.1.3. Reordering
• 5.2. Port Assignment
• 5.3. Initiation
• 5.3.1. Certificate-Based Authentication
• 5.3.2. Cryptographic Level
• 5.4. Sending data
• 5.4.1. Message Size
• 5.5. Closure
• 6. Security Policies
• 7. IANA Consideration
• 8. Security Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

The Syslog protocol [RFC5424] is designed to run over different transports for different environments. [RFC5425] provides a combination of TCP transport reliability with TLS security [RFC5246].

However, TCP performance can be a problem when a network has a high rate of lost packets. In these circumstances, an operator might prefer using UDP to TCP as transport. Transmission of Syslog Messages over UDP [RFC5426] defines how to provide unreliable, non-secure datagram transport for SYSLOG.

The datagram transport layer security protocol (DTLS) [RFC4347] is designed to meet the requirements of applications that need secure datagram transport, by combining UDP transport with TLS security [RFC5246]. DTLS has been mapped onto different transports (i.e. UDP, DCCP, SCTP), to secure syslog in more situations.

This document describes how to use SYSLOG with a DTLS transport.

2. Terminology

The following definitions from [RFC5424] are used in this document:

• An "originator" generates syslog content to be carried in a message.
• A "collector" gathers syslog content for further analysis.
• A "relay" forwards messages, accepting messages from originators or other relays, and sending them to collectors or other relays.
• A "transport sender" passes SYSLOG messages to a specific transport protocol.
• A "transport receiver" takes SYSLOG messages from a specific transport protocol.
• A "DTLS client" is an application that can initiate a DTLS Client Hello to a server.
• A "DTLS server" is an application that can receive a Client Hello from a client and reply with a Server Hello.

The term "connection" used in this document is used to refer to a secure association between transport sender and transport receiver that permits the transmission of one or more SYSLOG messages within the lifetime of the connection.

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

3. Security Requirements for Syslog

Syslog messages are secured in a hop-by-hop manner. The security requirements for Syslog are discussed in [RFC5425].

The following secondary threat is also considered in this document:

• Denial of Service. Denial of service is discussed in [RFC5424], which states that an attacker may send more messages to a transport receiver than the transport receiver could handle. When using a secure transport protocol handshake, an attacker may use a spoofed IP source to engage the server in a cryptographic handshake to deliberately consume the server's resources.

4. Using DTLS to Secure Syslog

DTLS can be used as a secure transport to counter all the primary threats to SYSLOG described in [RFC5425]:

• Confidentiality to counter disclosure of the message contents.
• Integrity checking to counter modifications to a message on a hop- by-hop basis.
• Server or mutual authentication to counter masquerade.

In addition DTLS also provides:

• A cookie exchange mechanism during handshake to counter Denial of Service attacks
• A sequence number in the header to counter replay attacks.

Note: This secure transport (i.e., DTLS) only secures syslog transport in a hop-by-hop manner, and is not concerned with the contents of syslog messages. In particular, the authenticated identity of the transport sender (e.g., subject name in the certificate) is not necessarily related to the HOSTNAME field of the syslog message. When authentication of syslog message origin is required, [I-D.ietf-syslog-sign] can be used.

5. Protocol Elements

5.1. Transport

DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP. Transports, such as UDP or DCCP do not provide session multiplexing and session-demultiplexing. In such case, the application implementer provides this functionality by mapping a unique combination of the remote address, remote port number, local address and local port number to a session.

When TCP is used syslog over DTLS MUST NOT be used. If a secure transport is required with TCP then the appropriate mechanism is syslog over TLS.

5.1.1. Congestion Control

The DTLS mapping on UDP transport does not provide congestion control mechanism, so, SYSLOG transport over DTLS have the same congestion control problems with transport over UDP. [RFC5426] has state such problems, when generated unlimited amounts of log transport on the internet, could influence the stable operation of the internet. [RFC5405] has guideline for an application SHOULD perform congestion control over UDP transport, referring to [RFC5405] for details.

Datagram Congestion Control Protocol [RFC4340] is designed and is usually be thought as UDP plus congestion control, which builds-in congestion control mechanism for datagram. DTLS can run over DCCP, [RFC5238] (Datagram Transport Layer Security over the Datagram Congestion Control Protocol) states such combination. To respond to congestion and establish a degree of fairness [RFC2914], it is RECOMMENDED that the implementer also support DCCP [RFC4340] for DTLS to provide congestion control.

5.1.2. Reliability

When DTLS runs over an unreliable transport such as UDP reliability is not provided. With DTLS, an originator or relay may not realize that a collector has gone down or lost its connection state so messages may be lost.

If reliability is required then Syslog over TLS may be used.

5.1.3. Reordering

Each SYSLOG message is delivered by DTLS record protocol, which has assigned a sequence number for each DTLS record. Although the DTLS implementer may adopt Queue mechanism to resolve reordering, it may not assure that all the messages delivered in order when mapping on UDP transport.

5.2. Port Assignment

A SYSLOG transport sender is always a DTLS client and a transport receiver is always a DTLS server.

The UDP and DCCP port [TBD] has been allocated as the default port for syslog over DTLS as defined in this document.

5.3. Initiation

The transport sender initiates a DTLS connection by sending a DTLS Client Hello to the transport receiver. It is RECOMMENDED that implementations support the denial of service countermeasures defined by DTLS. In this case, the transport receiver responds with a DTLS Hello Verify Request containing a cookie. The transport sender responds with a DTLS Client Hello containing the received cookie which initiates the DTLS handshake. When the DTLS handshake has finished, the transport sender MAY then send the first syslog message.

TLS typically uses certificates [RFC5280] to authenticate peers. Implementations MUST support DTLS 1.1 [RFC4347] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of DTLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported.

5.3.1. Certificate-Based Authentication

Both syslog transport sender (DTLS client) and syslog transport receiver (DTLS server) MUST implement certificate-based authentication. This consists of validating the certificate and verifying that the peer has the corresponding private key. The latter part is performed by DTLS. To ensure interoperability between clients and servers, the methods for certificate validation defined in [RFC5425] SHALL be implemented.

Both transport receiver and transport sender implementations MUST provide means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism.

The transport receiver and transport sender SHOULD provide mechanisms to record the end-entity certificate for the purpose of correlating it with the sent or received data.

5.3.2. Cryptographic Level

Syslog applications SHOULD be implemented in a manner that permits administrators, as a matter of local policy, to select the cryptographic level and authentication options they desire.

DTLS permits the resumption of an earlier DTLS session or the use of another active session when a new session is requested, in order to save the expense of another full DTLS handshake. The security parameters of the resumed session are reused for the requested session. The security parameters SHOULD be checked against the security requirements of the requested session to make sure that the resumed session provides proper security.

5.4. Sending data

All syslog messages MUST be sent as DTLS "application data". It is possible that multiple syslog messages be contained in one DTLS record, or that a syslog message be transferred in multiple DTLS records. The application data is defined with the following ABNF [RFC5234] expression:

APPLICATION-DATA = 1*SYSLOG-FRAME

SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG

MSG-LEN = NONZERO-DIGIT *DIGIT

SP = %d32

NONZERO-DIGIT = %d49-57

DIGIT = %d48 / NONZERO-DIGIT

SYSLOG-MSG is defined in syslog [RFC5424] protocol.

5.4.1. Message Size

The message length is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME. A transport receiver MUST use the message length to delimit a syslog message. There is no upper limit for a message length per se. As stated in [RFC4347], each DTLS record must fit within a single DTLS datagram. When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size to that allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the maximum record size limitation by DTLS.

5.5. Closure

A transport sender MUST close the associated DTLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a DTLS close_notify alert before closing the connection. A transport sender (DTLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the connection. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify.

When no data is received from a connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (DTLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert.

Although closure alerts form part of DTLS, they, like all alerts, are not retransmitted by DTLS and so may be lost over an unreliable network.

6. Security Policies

Syslog transport over DTLS has been designed to minimize the security and operational differences for environments where both [RFC5425] and SYSLOG over DTLS are supported. The security policies for SYSLOG over DTLS are the same as those described in [RFC5425].

7. IANA Consideration

IANA is requested to assign a registered UDP and DCCP port number for SYSLOG over DTLS.

8. Security Considerations

The security considerations in [RFC5425], [RFC5246] and [RFC4347] apply to this document.

9. Acknowledgements

The authors would like to thank Wes Hardaker for his review on this proposal and contributing his valuable suggestions on the use of DTLS. Thanks also to Pasi Eronen and David Harrington for their comments, suggestions and review.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses