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]