Network Working Group J. Salowey
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track H. Feng
Expires: April 17, 2010 Huaweisymantec, Inc.
T. Petch
Engineering Networks Ltd
R. Gerhards
Adiscon GmbH
October 14, 2009
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
draft-ietf-syslog-dtls-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2010.
Copyright Notice
Salowey, et al. Expires April 17, 2010 [Page 1]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Salowey, et al. Expires April 17, 2010 [Page 2]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Requirements for Syslog . . . . . . . . . . . . . . . 6
4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . 7
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Congestion Control . . . . . . . . . . . . . . . . . . 8
5.1.2. Reliability . . . . . . . . . . . . . . . . . . . . . 8
5.1.3. Reordering . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 9
5.3. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Certificate-Based Authentication . . . . . . . . . . . 9
5.3.2. Cryptographic Level . . . . . . . . . . . . . . . . . 10
5.4. Sending data . . . . . . . . . . . . . . . . . . . . . . . 10
5.4.1. Message Size . . . . . . . . . . . . . . . . . . . . . 10
5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Policies . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Salowey, et al. Expires April 17, 2010 [Page 3]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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.
Salowey, et al. Expires April 17, 2010 [Page 4]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
2. Terminology
The following definitions from [RFC5424] are used in this document:
o An "originator" generates syslog content to be carried in a
message.
o A "collector" gathers syslog content for further analysis.
o A "relay" forwards messages, accepting messages from originators
or other relays, and sending them to collectors or other relays.
o A "transport sender" passes SYSLOG messages to a specific
transport protocol.
o A "transport receiver" takes SYSLOG messages from a specific
transport protocol.
o A "DTLS client" is an application that can initiate a DTLS Client
Hello to a server.
o 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].
Salowey, et al. Expires April 17, 2010 [Page 5]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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:
o 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.
Salowey, et al. Expires April 17, 2010 [Page 6]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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]:
o Confidentiality to counter disclosure of the message contents.
o Integrity checking to counter modifications to a message on a hop-
by-hop basis.
o Server or mutual authentication to counter masquerade.
In addition DTLS also provides:
o A cookie exchange mechanism during handshake to counter Denial of
Service attacks
o 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.
Salowey, et al. Expires April 17, 2010 [Page 7]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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
Salowey, et al. Expires April 17, 2010 [Page 8]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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.
Salowey, et al. Expires April 17, 2010 [Page 9]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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.
Salowey, et al. Expires April 17, 2010 [Page 10]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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.
Salowey, et al. Expires April 17, 2010 [Page 11]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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].
Salowey, et al. Expires April 17, 2010 [Page 12]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
7. IANA Consideration
IANA is requested to assign a registered UDP and DCCP port number for
SYSLOG over DTLS.
Salowey, et al. Expires April 17, 2010 [Page 13]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
8. Security Considerations
The security considerations in [RFC5425], [RFC5246] and [RFC4347]
apply to this document.
Salowey, et al. Expires April 17, 2010 [Page 14]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
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.
Salowey, et al. Expires April 17, 2010 [Page 15]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", RFC 5425,
March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, March 2009.
10.2. Informative References
[I-D.ietf-syslog-sign]
Kelsey, J., Callas, J., and A. Clemm, "Signed syslog
Messages", draft-ietf-syslog-sign-27 (work in progress),
August 2009.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, May 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
Salowey, et al. Expires April 17, 2010 [Page 16]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
for Application Designers", BCP 145, RFC 5405,
November 2008.
Salowey, et al. Expires April 17, 2010 [Page 17]
Internet-Draft DTLS Transport Mapping for Syslog October 2009
Authors' Addresses
Joseph Salowey
Cisco Systems, Inc.
2901 3rd. Ave
Seattle, WA 98121
USA
Email: jsalowey@cisco.com
Hongyan. Feng
Huaweisymantec, Inc.
Email: hongyanfeng@huaweisymantec.com
Tom Petch
Engineering Networks Ltd
18 Parkwood Close
Lymm, Cheshire WA13 0NQ
UK
Email: tomSecurity@network-engineer.co.uk
Rainer Gerhards
Adiscon GmbH
Mozartstrasse 21
Grossrinderfeld, BW 97950
Germany
Email: rgerhards@adiscon.com
Salowey, et al. Expires April 17, 2010 [Page 18]