6012
PROPOSED STANDARD
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
Authors: J. Salowey, T. Petch, R. Gerhards, H. Feng
Date: October 2010
Area: sec
Working Group: syslog
Stream: IETF
Updated by:
RFC 8996
Abstract
This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired.
RFC 6012
PROPOSED STANDARD
Updated by: 8996, 9662
Internet Engineering Task Force (IETF) J. Salowey
Request for Comments: 6012 Cisco Systems, Inc.
Category: Standards Track T. Petch
ISSN: 2070-1721 Engineering Networks Ltd
R. Gerhards
Adiscon GmbH
H. Feng
Huaweisymantec Technologies
October 2010
<span class="h1">Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog</span>
Abstract
This document describes the transport of syslog messages over the
Datagram Transport Layer Security (DTLS) protocol. It provides a
secure transport for syslog messages in cases where a connectionless
transport is desired.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc6012">http://www.rfc-editor.org/info/rfc6012</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Salowey, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Security Requirements for Syslog . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. Transport . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.2">5.2</a>. Port and Service Code Assignment . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.3">5.3</a>. Initiation . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.3.1">5.3.1</a>. Certificate-Based Authentication . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.4">5.4</a>. Sending Data . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.4.1">5.4.1</a>. Message Size . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.5">5.5</a>. Closure . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Congestion Control . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Security Policies . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9.1">9.1</a>. DTLS Renegotiation . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9.2">9.2</a>. Message Loss . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9.3">9.3</a>. Private Key Generation . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9.4">9.4</a>. Trust Anchor Installation and Storage . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10">10</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Salowey, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The syslog protocol [<a href="./rfc5424" title=""The Syslog Protocol"">RFC5424</a>] is designed to run over different
transports for different environments. This document defines the
transport of syslog messages over the Datagram Transport Layer
Security (DTLS) protocol [<a href="./rfc4347" title=""Datagram Transport Layer Security"">RFC4347</a>].
The Datagram Transport Layer Security (DTLS) protocol [<a href="./rfc4347" title=""Datagram Transport Layer Security"">RFC4347</a>] is
designed to meet the requirements of applications that need secure
datagram transport. DTLS has been mapped onto different transports,
including UDP [<a href="./rfc0768" title=""User Datagram Protocol"">RFC0768</a>] and the Datagram Congestion Control Protocol
(DCCP) [<a href="./rfc4340" title=""Datagram Congestion Control Protocol (DCCP)"">RFC4340</a>]. This memo defines both options, namely syslog over
DTLS over UDP, and syslog over DTLS over DCCP.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The following definitions from [<a href="./rfc5424" title=""The Syslog Protocol"">RFC5424</a>] 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.
This document adds the following definitions:
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 DTLS Client
Hello from a client and reply with a Server Hello.
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Salowey, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Requirements for Syslog</span>
The security requirements for the transport of syslog messages are
discussed in <a href="./rfc5425#section-2">Section 2 of [RFC5425]</a>. These also apply to this
specification.
The following secondary threat is also considered in this document:
o Denial of service is discussed in [<a href="./rfc5424" title=""The Syslog Protocol"">RFC5424</a>], 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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Using DTLS to Secure Syslog</span>
DTLS can be used as a secure transport to counter all the primary
threats to syslog described in [<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>]:
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, [<a href="./rfc5848" title=""Signed Syslog Messages"">RFC5848</a>] can be used.
<span class="grey">Salowey, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Protocol Elements</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Transport</span>
DTLS can run over multiple transports. Implementations of this
specification MUST support DTLS over UDP and SHOULD support DTLS over
DCCP [<a href="./rfc5238" title=""Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)"">RFC5238</a>]. Transports such as UDP or DCCP do not provide
session multiplexing and session demultiplexing. In such cases, 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.
Each syslog message is delivered by the DTLS record protocol, which
assigns a sequence number to each DTLS record. Although the DTLS
implementer may adopt a queue mechanism to resolve reordering, it may
not assure that all the messages are delivered in order when mapping
on the UDP transport.
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 DTLS connection state, so
messages may be lost.
Syslog over DTLS over TCP MUST NOT be used. If a secure transport is
required with TCP, then the appropriate security mechanism is syslog
over Transport Layer Security (TLS) as described in [<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>].
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Port and Service Code Assignment</span>
A syslog transport sender is always a DTLS client, and a transport
receiver is always a DTLS server.
The UDP and DCCP port 6514 has been allocated as the default port for
syslog over DTLS as defined in this document. The service code SYLG
(1398361159) has been assigned to syslog.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Initiation</span>
The transport sender initiates a DTLS connection by sending a DTLS
Client Hello to the transport receiver. Implementations MUST support
the denial of service countermeasures defined by DTLS. When these
countermeasures are used, 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. The transport sender MUST NOT
send any syslog messages before the DTLS handshake has successfully
completed.
<span class="grey">Salowey, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
Implementations MUST support DTLS 1.0 [<a href="./rfc4347" title=""Datagram Transport Layer Security"">RFC4347</a>] and MUST support the
mandatory to implement cipher suite, which is
TLS_RSA_WITH_AES_128_CBC_SHA as specified in [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]. If
additional cipher suites are supported, then implementations MUST NOT
negotiate a cipher suite that employs NULL integrity or
authentication algorithms.
Where privacy is REQUIRED, then implementations must either negotiate
a cipher suite that employs a non-NULL encryption algorithm or else
achieve privacy by other means, such as a physically secured network.
However, as <a href="./rfc5424#section-8">[RFC5424], Section 8</a>, points out, "In most cases, passing
clear-text messages is a benefit to the operations staff if they are
sniffing the packets from the wire", and so where privacy is not a
requirement, then it is advantageous to use a NULL encryption
algorithm.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Certificate-Based Authentication</span>
The mandatory to implement cipher suites for DTLS use certificates
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] to authenticate peers. Both the syslog transport sender
(DTLS client) and the 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 Sections <a href="#section-4.2.1">4.2.1</a> and <a href="#section-4.2.2">4.2.2</a> of
[<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>] SHALL be implemented.
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.
The transport receiver and transport sender SHOULD provide mechanisms
to record the certificate or certificate fingerprint used by the
remote endpoint for the purpose of correlating an identity with the
sent or received data.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Sending Data</span>
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
[<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] expression:
<span class="grey">Salowey, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
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 the syslog [<a href="./rfc5424" title=""The Syslog Protocol"">RFC5424</a>] protocol.
<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Message Size</span>
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 [<a href="./rfc4347" title=""Datagram Transport Layer Security"">RFC4347</a>], a DTLS record MUST NOT span
multiple datagrams. When mapping onto different transports, DTLS has
different record size limitations. For UDP, see <a href="./rfc5426#section-3.2">Section 3.2 of
[RFC5426]</a>. For DCCP, the application implementer SHOULD determine
the maximum record size allowed by the DTLS protocol running over
DCCP, as specified in [<a href="./rfc4340" title=""Datagram Congestion Control Protocol (DCCP)"">RFC4340</a>]. The message size SHOULD NOT exceed
the DTLS maximum record size limitation of 2^14 bytes. To be
consistent with [<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>], in establishing a baseline for
interoperability, this specification requires that 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 with lengths up to and including 8192 octets.
See <a href="./rfc5424#appendix-A.2">Appendix A.2 of [RFC5424]</a> for implementation guidance on message
length, including fragmentation.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Closure</span>
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 DTLS
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 DTLS connection for a long time
(where the application decides what "long" means), a transport
receiver MAY close the connection. The transport receiver (DTLS
<span class="grey">Salowey, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
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 are a component of TLS and so of DTLS, they,
like all alerts, are not retransmitted by DTLS and so may be lost
over an unreliable network.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Congestion Control</span>
Because syslog can generate unlimited amounts of data, transferring
this data over UDP is generally problematic, because UDP lacks
congestion control mechanisms. Congestion control mechanisms that
respond to congestion by reducing traffic rates and establishing a
degree of fairness between flows that share the same path are vital
to the stable operation of the Internet (see [<a href="./rfc2914" title=""Congestion Control Principles"">RFC2914</a>] and
[<a href="./rfc5405" title=""Unicast UDP Usage Guidelines for Application Designers"">RFC5405</a>]).
DCCP has congestion control. 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 Congestion
Control Identifier (CCID) 3 and SHOULD support CCID 2 to ensure
interoperability.
The congestion control considerations from <a href="./rfc5426#section-4.3">Section 4.3 of [RFC5426]</a>
also apply to syslog over DTLS over UDP.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Policies</span>
Syslog transport over DTLS has been designed to minimize the security
and operational differences for environments where both syslog over
TLS [<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>] and syslog over DTLS are supported. The security
policies for syslog over DTLS are the same as those described in
[<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>], and all the normative requirements of <a href="./rfc5425#section-5">Section 5 of
[RFC5425]</a> apply.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA has assigned a registered UDP and DCCP port number for syslog
over DTLS. The values are the same as for syslog over TLS. That is,
the registry has been updated as follows:
syslog-tls 6514/udp syslog over DTLS [<a href="./rfc6012">RFC6012</a>]
syslog-tls 6514/dccp syslog over DTLS [<a href="./rfc6012">RFC6012</a>]
<span class="grey">Salowey, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
IANA has assigned the service code SYLG to syslog for use with DCCP.
The allocation in the Service Code subregistry of the Datagram
Congestion Control Protocol (DCCP) Parameters registry is as follows:
1398361159 SYLG Syslog Protocol [<a href="./rfc6012">RFC6012</a>]
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The security considerations in [<a href="./rfc4347" title=""Datagram Transport Layer Security"">RFC4347</a>], [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>], [<a href="./rfc5425" title=""Transport Layer Security (TLS) Transport Mapping for Syslog"">RFC5425</a>], and
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] apply to this document.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. DTLS Renegotiation</span>
TLS and DTLS renegotiation may be vulnerable to attacks described in
[<a href="./rfc5746" title=""Transport Layer Security (TLS) Renegotiation Indication Extension"">RFC5746</a>]. Although <a href="./rfc5746">RFC 5746</a> provides a fix for some of the issues,
renegotiation can still cause problems for applications since
connection security parameters can change without the application
knowing it. Therefore it is RECOMMENDED that renegotiation be
disabled for syslog over DTLS. If renegotiation is allowed, then the
specification in <a href="./rfc5746">RFC 5746</a> MUST be followed, and the implementation
MUST make sure that the connection still has adequate security and
that any identities extracted from client and server certificates do
not change during renegotiation.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Message Loss</span>
The transports described in this document are unreliable. It is
possible for messages to be lost or removed by an attacker without
the knowledge of the receiver. [<a href="./rfc5424" title=""The Syslog Protocol"">RFC5424</a>] notes that implementers who
wish a lossless stream should be using tls/tcp as their transport.
In addition, the use of signed syslog messages [<a href="./rfc5848" title=""Signed Syslog Messages"">RFC5848</a>] can also
provide an indication of message loss.
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Private Key Generation</span>
Transport receiver and transport sender implementations often
generate their own key pairs. An inadequate random number generator
(RNG) or an inadequate pseudo-random number generator (PRNG) to
generate these keys can result in little or no security. See
[<a href="./rfc4086" title=""Randomness Requirements for Security"">RFC4086</a>] for random number generation guidance.
<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>. Trust Anchor Installation and Storage</span>
Trust anchor installation and storage is critical. Transmission of a
trust anchor, especially self-signed certificates used as trust
anchors, from transport receiver to transport sender for installation
requires one or more out-of-band steps. Care must be taken to ensure
the installed trust anchor is in fact the correct trust anchor. The
<span class="grey">Salowey, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
fingerprint mechanism mentioned in <a href="#section-5.3.1">Section 5.3.1</a> can be used by the
transport sender to ensure the transport receiver's self-signed
certificate is properly installed. Trust anchor information must be
securely stored. Changes to trust anchor information can cause
acceptance of certificates that should be rejected.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The authors would like to thank Wes Hardaker for his review of this
proposal and for contributing his valuable suggestions on the use of
DTLS. Thanks also to Pasi Eronen, David Harrington, Chris Lonvick,
Eliot Lear, Anton Okmyanskiy, Juergen Schoenwaelder, Richard
Graveman, the members of the syslog working group, and the members of
the IESG for their review, comments, and suggestions.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC0768">RFC0768</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
August 1980.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4340">RFC4340</a>] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", <a href="./rfc4340">RFC 4340</a>, March 2006.
[<a id="ref-RFC4347">RFC4347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", <a href="./rfc4347">RFC 4347</a>, April 2006.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-RFC5238">RFC5238</a>] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
<a href="./rfc5238">RFC 5238</a>, May 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5280">RFC5280</a>] 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", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-RFC5424">RFC5424</a>] Gerhards, R., "The Syslog Protocol", <a href="./rfc5424">RFC 5424</a>, March 2009.
<span class="grey">Salowey, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
[<a id="ref-RFC5425">RFC5425</a>] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", <a href="./rfc5425">RFC 5425</a>,
March 2009.
[<a id="ref-RFC5426">RFC5426</a>] Okmianski, A., "Transmission of Syslog Messages over UDP",
<a href="./rfc5426">RFC 5426</a>, March 2009.
[<a id="ref-RFC5746">RFC5746</a>] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
<"Transport Layer Security (TLS) Renegotiation Indication
Extension", <a href="./rfc5746">RFC 5746</a>, February 2010.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC2914">RFC2914</a>] Floyd, S., "Congestion Control Principles", <a href="https://www.rfc-editor.org/bcp/bcp41">BCP 41</a>,
<a href="./rfc2914">RFC 2914</a>, September 2000.
[<a id="ref-RFC4086">RFC4086</a>] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>, June 2005.
[<a id="ref-RFC5405">RFC5405</a>] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", <a href="https://www.rfc-editor.org/bcp/bcp145">BCP 145</a>, <a href="./rfc5405">RFC 5405</a>,
November 2008.
[<a id="ref-RFC5848">RFC5848</a>] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog
Messages", <a href="./rfc5848">RFC 5848</a>, May 2010.
<span class="grey">Salowey, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc6012">RFC 6012</a> DTLS Transport Mapping for Syslog October 2010</span>
Authors' Addresses
Joseph Salowey
Cisco Systems, Inc.
2901 3rd Ave.
Seattle, WA 98121
USA
EMail: [email protected]
Tom Petch
Engineering Networks Ltd
18 Parkwood Close
Lymm, Cheshire WA13 0NQ
UK
EMail: [email protected]
Rainer Gerhards
Adiscon GmbH
Mozartstrasse 21
Grossrinderfeld, BW 97950
Germany
EMail: [email protected]
Hongyan Feng
Huaweisymantec Technologies
20245 Stevens Creek Blvd.
Cupertino, CA 95014
EMail: [email protected]
Salowey, et al. Standards Track [Page 12]
Annotations
Select text to annotate