Network Working Group H. Feng
Internet-Draft Huaweisymantec, Inc.
Intended status: Standards Track April 10, 2009
Expires: October 12, 2009
Transmission of SYSLOG message over DTLS
draft-feng-syslog-transport-dtls-01.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 October 12, 2009.
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
Feng Expires October 12, 2009 [Page 1]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
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.
Abstract
This document describes a Transport for the Syslog Protocol, that
uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS
protocol provides authentication and privacy services for SYSLOG
applications. This document describes how using DTLS to transport
SYSLOG messages makes this protection possible in an interoperable
way.
This transport is designed to meet the security and operational needs
of network administrators, operate in environments where a datagram
transport is preferred, and integrates well into existing public
keying infrastructures.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . . 4
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Security Policies . . . . . . . . . . . . . . . . . . . . . 4
4.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Message Process . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Port . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Message Size . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Session Demultiplexing . . . . . . . . . . . . . . . . . . 5
5.3.1. Outgoing Message Process . . . . . . . . . . . . . . . 5
5.3.2. Incoming Message Process . . . . . . . . . . . . . . . 5
6. Applicable Scenarios . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7.1. Authentication of message origin . . . . . . . . . . . . . 6
7.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 7
7.4. Congestion Control . . . . . . . . . . . . . . . . . . . . 7
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Feng Expires October 12, 2009 [Page 2]
Internet-Draft Transmission of SYSLOG message over DTLS April 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.
2. Terminology
The following definitions from [RFC5424] are used in this document:
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 "session" 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 session.
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].
Feng Expires October 12, 2009 [Page 3]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
3. Threats
Syslog messages are secured in a hop-by-hop manner. The threats
during transmission have been discussed in [RFC5425].
The following secondary threat is addressed 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 request for the server's certificate information to
deliberately consume the server's resources.
4. Using DTLS to Secure Syslog
4.1. Security
DTLS can be used as a secure transport to counter all the primary
threats to SYSLOG described above:
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.
The extra security features that DTLS can provide:
o A cookie exchange mechanism during handshake to counter Denial of
Service attacks
o A sequence number in the header to counter replay attacks.
4.2. 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].
When a transport sender initiate a hello request to a transport
receiver, cookie exchange mechanism (borrow from Internet Key
Exchange [RFC2521] ) is RECOMMENDED for transport receiver to use to
mitigate Denial of Service by spoofed IP address.
Feng Expires October 12, 2009 [Page 4]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
4.3. Transport
With DTLS transport, each message is secure and private within the
lifetime of a session. TLS can use the TCP connection identifier to
identify a session, and to uniquely associate messages with a session
ID, i.e., TCP supports session-demultiplexing. DTLS mapping on UDP
or DCCP does not provide an association mechanism to identify which
message belongs to which session. In such case, the application
implementer SHOULD support session-demultiplexing.
5. Message Process
5.1. Port
A SYSLOG transport sender is always a DTLS client and a transport
receiver is always a DTLS server. Any port could be configured by
the user to send or receive SYSLOG message. The SYSLOG receiver MUST
support listening on the default port which IANA assigned for SYSLOG
over DTLS, but MAY be configurable to listen on a different port.
5.2. Message Size
As stated in [RFC4347], each DTLS record must fit within a single
datagram. When mapping onto different transports, DTLS has different
record size limitations. The application implementer SHOULD get the
maximum limitation by the DTLS protocol. The message size SHOULD NOT
exceed the maximum record size limitation by DTLS.
5.3. Session Demultiplexing
As stated above, the implementer SHOULD deal with session-
demultiplexing when DTLS maps onto UDP. The implementer SHOULD
maintain the mapping relationship between messages and sessions
during the session lifetime, in an implemntation-dependent manner.
5.3.1. Outgoing Message Process
For a SYSLOG transport sender, the messages from application will be
treated as the application data by DTLS in the record layer. When
DTLS mapping on UDP transport, the transport sender MUST use
different sending port for the transport receiver to distinguish
which session it belongs.
5.3.2. Incoming Message Process
A SYSLOG transport receiver MUST decide which an incoming message
belongs to which session. Each session identified by a session id in
DTLS, maintains a series of security parameters, which is used to
Feng Expires October 12, 2009 [Page 5]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
decrypt the message in secret to the application in upper layer.
When mapping on UDP, DTLS does not support multi-session, which
means, DTLS does not provide equivalent method to associate an
incoming message with a session id. The application implementer
SHOULD resolve it. Usually, an Address-Port pair (source address,
source port, destination address and destination port) could be used
to decide a unique session. When the destination address and
destination port is decided, different source port can be used to
identify different session from same source address.
6. Applicable Scenarios
Syslog over DTLS is applicable in such scenarios as below:
1. In managed networks, the environment where UDP transport is
applicable and security is required, where the network path has been
explicitly provisioned for UDP SYSLOG traffic through traffic
engineering mechanisms, such as rate limiting or capacity
reservations. Reference from [RFC5426].
2. In network environment where using congestion control mechanism,
SYSLOG application can benefit from a datagram-based approach rather
than a TCP-based approach.
2.1 Bulk transmission of logs: SYSLOG over dtls has more lower delay
that could meet the great amount of logs delivery situation.
2.2 The logs transmission is kind of intermittent: keeping TCP
connections alive for an occasional poll is not necessarily a good
approach. Trying to connection each time in transmission could incur
the overhead of TCP connection, especially setting up a TCP
connection to get one SYSLOG message.
7. Security Considerations
7.1. Authentication of message origin
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.
Feng Expires October 12, 2009 [Page 6]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
7.2. Reliability
DTLS is a datagram-based transport protocol, when mapping on a
reliable transport (like SCTP), reliability is assurable.
7.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 does
not assure that all the messages delivered in order when mapping on
UDP transport. When mapping on SCTP transport, reordering is
avoidable.
7.4. 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.
8. IANA Consideration
IANA is requested to assign a registered UDP port number for SYSLOG
over DTLS that mapping on UDP.
IANA is requested to assign a registered SCTP port number for SYSLOG
over DTLS that mapping on SCTP.
9. Acknowledgements
Much of this document draws heavily from [RFC5425]. The draft also
borrow from Wes Hardaker's [I-D.hardaker-isms-dtls-tm], when using
dtls as transport, SYSLOG and SNMP face same situation to resolve.
Thanks for his review on this proposal and contributing his valuable
suggestions. Thanks also give to Pasi.Eronen for his contribution on
Feng Expires October 12, 2009 [Page 7]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
review and comments. Particular thanks are due to David Harrinting
for thorough review, who gives great much direction and suggestion,
the author is very grateful.
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.
[RFC2914] Floyd, S., "Congestion Control
Principles", BCP 41, RFC 2914,
September 2000.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram
Transport Layer Security", RFC 4347,
April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS) Protocol
Version 1.2", RFC 5246, Augest 2008.
[RFC5424] Gerhards, R., "The SYSLOG Protocol",
RFC 5424, March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "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.hardaker-isms-dtls-tm] Hardaker, W., "Datagram Transport Layer
Security Transport Model for SNMP",
draft-hardaker-isms-syslog-tm-03 (work
in progress), March 2009.
[I-D.ietf-syslog-sign] Kelsey, J., Callas, J., and A. Clemm,
"Signed SYSLOG Messages",
draft-ietf-syslog-sign-25 (work in
progress) (work in progress), March
30 2009.
Feng Expires October 12, 2009 [Page 8]
Internet-Draft Transmission of SYSLOG message over DTLS April 2009
[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 for Application
Designers", RFC RFC5405, November 2008.
Author's Address
Hongyan. Feng
Huaweisymantec, Inc.
EMail: hongyanfeng@huaweisymantec.com
Feng Expires October 12, 2009 [Page 9]