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
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
Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
Syslog的数据报传输层安全性（DTLS）传输映射
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.
本文档描述通过数据报传输层安全（DTLS）协议传输系统日志消息。在需要无连接传输的情况下，它为syslog消息提供安全传输。
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 Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6012.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6012.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Requirements for Syslog . . . . . . . . . . . . . . . 4
4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . 4
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Port and Service Code Assignment . . . . . . . . . . . . . 5
5.3. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3.1. Certificate-Based Authentication . . . . . . . . . . . 6
5.4. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. Message Size . . . . . . . . . . . . . . . . . . . . . 7
5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. DTLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
9.2. Message Loss . . . . . . . . . . . . . . . . . . . . . . . 9
9.3. Private Key Generation . . . . . . . . . . . . . . . . . . 9
9.4. Trust Anchor Installation and Storage . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Requirements for Syslog . . . . . . . . . . . . . . . 4
4. Using DTLS to Secure Syslog . . . . . . . . . . . . . . . . . 4
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Port and Service Code Assignment . . . . . . . . . . . . . 5
5.3. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3.1. Certificate-Based Authentication . . . . . . . . . . . 6
5.4. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. Message Size . . . . . . . . . . . . . . . . . . . . . 7
5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. DTLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
9.2. Message Loss . . . . . . . . . . . . . . . . . . . . . . . 9
9.3. Private Key Generation . . . . . . . . . . . . . . . . . . 9
9.4. Trust Anchor Installation and Storage . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
The syslog protocol [RFC5424] 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 [RFC4347].
syslog协议[RFC5424]设计用于针对不同环境运行不同的传输。本文档定义了通过数据报传输层安全（DTLS）协议[RFC4347]传输系统日志消息。
The Datagram Transport Layer Security (DTLS) protocol [RFC4347] is designed to meet the requirements of applications that need secure datagram transport. DTLS has been mapped onto different transports, including UDP [RFC0768] and the Datagram Congestion Control Protocol (DCCP) [RFC4340]. This memo defines both options, namely syslog over DTLS over UDP, and syslog over DTLS over DCCP.
数据报传输层安全（DTLS）协议[RFC4347]旨在满足需要安全数据报传输的应用程序的要求。DTL已映射到不同的传输，包括UDP[RFC0768]和数据报拥塞控制协议（DCCP）[RFC4340]。此备忘录定义了两个选项，即通过UDP的DTLS系统日志和通过DCCP的DTLS系统日志。
The following definitions from [RFC5424] are used in this document:
本文件中使用了[RFC5424]中的以下定义：
o An "originator" generates syslog content to be carried in a message.
o “发起者”生成要在消息中携带的系统日志内容。
o A "collector" gathers syslog content for further analysis.
o “收集器”收集系统日志内容以供进一步分析。
o A "relay" forwards messages, accepting messages from originators or other relays, and sending them to collectors or other relays.
o “中继”转发消息，接受发起者或其他中继发送的消息，并将其发送给收集器或其他中继。
o A "transport sender" passes syslog messages to a specific transport protocol.
o “传输发送方”将系统日志消息传递给特定的传输协议。
o A "transport receiver" takes syslog messages from a specific transport protocol.
o “传输接收器”从特定的传输协议获取系统日志消息。
This document adds the following definitions:
本文件添加了以下定义：
o A "DTLS client" is an application that can initiate a DTLS Client Hello to a server.
o “DTLS客户端”是一个应用程序，它可以启动DTLS客户端向服务器的问候。
o A "DTLS server" is an application that can receive a DTLS Client Hello from a client and reply with a Server Hello.
o “DTLS服务器”是一个应用程序，它可以从客户机接收DTLS客户机Hello，并用服务器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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The security requirements for the transport of syslog messages are discussed in Section 2 of [RFC5425]. These also apply to this specification.
[RFC5425]第2节讨论了系统日志消息传输的安全要求。这些也适用于本规范。
The following secondary threat is also considered in this document:
本文件还考虑了以下次要威胁：
o 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.
o [RFC5424]中讨论了拒绝服务，其中指出攻击者向传输接收器发送的消息可能超过传输接收器所能处理的数量。使用安全传输协议握手时，攻击者可能会使用伪造的IP源让服务器参与加密握手，故意消耗服务器的资源。
DTLS can be used as a secure transport to counter all the primary threats to syslog described in [RFC5425]:
DTL可用作安全传输，以应对[RFC5425]中所述的对系统日志的所有主要威胁：
o Confidentiality to counter disclosure of the message contents.
o 信息内容的保密性。
o Integrity checking to counter modifications to a message on a hop-by-hop basis.
o 完整性检查，以逐跳方式对消息的修改进行计数器。
o Server or mutual authentication to counter masquerade.
o 服务器或相互身份验证来对抗伪装。
In addition, DTLS also provides:
此外，DTLS还提供：
o A cookie exchange mechanism during handshake to counter Denial of Service attacks.
o 握手过程中的cookie交换机制，用于抵御拒绝服务攻击。
o A sequence number in the header to counter replay attacks.
o 报头中用于抵抗重播攻击的序列号。
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, [RFC5848] can be used.
注意：此安全传输（即DTLS）仅以逐跳方式保护系统日志传输，与系统日志消息的内容无关。特别是，传输发送方的经过身份验证的标识（例如，证书中的使用者名称）不一定与syslog消息的HOSTNAME字段相关。当需要对系统日志消息源进行身份验证时，可以使用[RFC5848]。
DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. 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.
DTL可以在多个传输上运行。本规范的实现必须支持UDP上的DTL，并应支持DCCP上的DTL[RFC5238]。UDP或DCCP等传输不提供会话多路复用和会话解多路复用。在这种情况下，应用程序实现者通过将远程地址、远程端口号、本地地址和本地端口号的唯一组合映射到会话来提供此功能。
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.
每个系统日志消息都由DTLS记录协议传递，该协议为每个DTLS记录分配一个序列号。尽管DTLS实现者可以采用队列机制来解决重新排序问题，但在UDP传输上进行映射时，可能无法确保所有消息都按顺序传递。
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.
当DTL在不可靠的传输（如UDP）上运行时，不提供可靠性。对于DTLS，发起者或中继可能没有意识到收集器已关闭或失去其DTLS连接状态，因此消息可能会丢失。
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 [RFC5425].
不能使用TCP上DTLS上的系统日志。如果TCP需要安全传输，则适当的安全机制是syslog over transport Layer security（TLS），如[RFC5425]所述。
A syslog transport sender is always a DTLS client, and a transport receiver is always a DTLS server.
系统日志传输发送方始终是DTLS客户端，传输接收方始终是DTLS服务器。
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.
UDP和DCCP端口6514已被分配为本文档中定义的DTL上syslog的默认端口。服务代码SYLG（1398361159）已分配给syslog。
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.
传输发送方通过向传输接收方发送DTLS客户端Hello来启动DTLS连接。实现必须支持DTL定义的拒绝服务对策。当使用这些对策时，传输接收器会响应一个包含cookie的DTLS Hello Verify请求。传输发送方使用一个DTLS客户端Hello进行响应，该客户端Hello包含接收到的cookie，该cookie启动DTLS握手。在DTLS握手成功完成之前，传输发送方不得发送任何系统日志消息。
Implementations MUST support DTLS 1.0 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA as specified in [RFC5246]. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL integrity or authentication algorithms.
实现必须支持DTLS 1.0[RFC4347]，并且必须支持强制实现密码套件，即[RFC5246]中指定的TLS_RSA_和_AES_128_CBC_SHA。如果支持其他密码套件，则实现不得协商使用空完整性或身份验证算法的密码套件。
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 [RFC5424], Section 8, 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.
然而，正如[RFC5424]第8节所指出的，“在大多数情况下，如果操作人员嗅探来自线路的数据包，则传递明文信息对操作人员是有利的”，因此，在不要求隐私的情况下，使用空加密算法是有利的。
The mandatory to implement cipher suites for DTLS use certificates [RFC5280] 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 4.2.1 and 4.2.2 of [RFC5425] SHALL be implemented.
必须为DTL实现密码套件，并使用证书[RFC5280]对对等方进行身份验证。系统日志传输发送方（DTLS客户端）和系统日志传输接收方（DTLS服务器）都必须实现基于证书的身份验证。这包括验证证书和验证对等方是否具有相应的私钥。后一部分由DTLS执行。为确保客户端和服务器之间的互操作性，应实施[RFC5425]第4.2.1节和第4.2.2节中定义的证书验证方法。
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.
传输接收方和传输发送方应提供机制来记录远程端点使用的证书或证书指纹，以便将身份与发送或接收的数据关联起来。
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:
所有系统日志消息必须作为DTL“应用程序数据”发送。可能在一个DTLS记录中包含多个系统日志消息，或者在多个DTLS记录中传输一个系统日志消息。应用程序数据由以下ABNF[RFC5234]表达式定义：
APPLICATION-DATA = 1*SYSLOG-FRAME
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
MSG-LEN=非零位*位
SP = %d32
SP = %d32
NONZERO-DIGIT = %d49-57
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
DIGIT = %d48 / NONZERO-DIGIT
SYSLOG-MSG is defined in the syslog [RFC5424] protocol.
SYSLOG-MSG在SYSLOG[RFC5424]协议中定义。
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], a DTLS record MUST NOT span multiple datagrams. When mapping onto different transports, DTLS has different record size limitations. For UDP, see Section 3.2 of [RFC5426]. For DCCP, the application implementer SHOULD determine the maximum record size allowed by the DTLS protocol running over DCCP, as specified in [RFC4340]. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. To be consistent with [RFC5425], 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.
消息长度是SYSLOG-FRAME中SYSLOG-MSG的八位字节计数。传输接收方必须使用消息长度来分隔系统日志消息。消息长度本身没有上限。如[RFC4347]所述，DTLS记录不得跨越多个数据报。当映射到不同的传输时，DTL具有不同的记录大小限制。有关UDP，请参见[RFC5426]的第3.2节。对于DCCP，应用程序实现者应确定通过DCCP运行的DTLS协议允许的最大记录大小，如[RFC4340]中所述。消息大小不应超过DTLS最大记录大小限制2^14字节。为了与[RFC5425]保持一致，在建立互操作性基线时，本规范要求传输接收器必须能够处理长度不超过2048个八位字节的消息。传输接收器应能够处理长度不超过8192个八位字节的消息。
See Appendix A.2 of [RFC5424] for implementation guidance on message length, including fragmentation.
有关消息长度（包括分段）的实施指南，请参见[RFC5424]的附录A.2。
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.
如果以后不希望连接传递任何系统日志消息，则传输发送方必须关闭关联的DTLS连接。它必须在关闭连接之前发送DTLS close_notify警报。传输发送方（DTLS客户端）可以选择不等待传输接收方的关闭通知警报，而只关闭DTLS连接。一旦传输接收方收到来自传输发送方的关闭通知，它必须回复关闭通知。
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
当长时间没有从DTLS连接接收到数据时（应用程序决定“long”是什么意思），传输接收器可能会关闭连接。传输接收器（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.
服务器）必须在关闭连接之前尝试与传输发件人交换close_notify警报。未做好接收更多数据准备的传输接收器可在发送close_notify警报后关闭连接。
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.
尽管关闭警报是TLS和DTL的一个组成部分，但与所有警报一样，它们不会由DTL重新传输，因此可能会在不可靠的网络上丢失。
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 [RFC2914] and [RFC5405]).
由于syslog可以生成无限量的数据，因此通过UDP传输这些数据通常是有问题的，因为UDP缺乏拥塞控制机制。通过降低流量率和在共享同一路径的流之间建立一定程度的公平性来应对拥塞的拥塞控制机制对于互联网的稳定运行至关重要（参见[RFC2914]和[RFC5405]）。
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.
DCCP具有拥塞控制功能。如果DCCP可用，建议使用DCCP上DTLS上的系统日志，而不是UDP上DTLS上的系统日志。DCCP上DTLS上的syslog实现必须支持拥塞控制标识符（CCID）3，并应支持CCID 2以确保互操作性。
The congestion control considerations from Section 4.3 of [RFC5426] also apply to syslog over DTLS over UDP.
[RFC5426]第4.3节中的拥塞控制注意事项也适用于UDP上DTLS上的syslog。
Syslog transport over DTLS has been designed to minimize the security and operational differences for environments where both syslog over TLS [RFC5425] and syslog over DTLS are supported. The security policies for syslog over DTLS are the same as those described in [RFC5425], and all the normative requirements of Section 5 of [RFC5425] apply.
DTLS上的Syslog传输旨在最大限度地减少支持TLS上的Syslog[RFC5425]和DTLS上的Syslog的环境的安全性和操作差异。DTL上syslog的安全策略与[RFC5425]中描述的相同，并且[RFC5425]第5节中的所有规范性要求均适用。
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:
IANA已为DTL上的syslog分配了一个已注册的UDP和DCCP端口号。这些值与TLS上的syslog的值相同。也就是说，注册表已更新如下：
syslog-tls 6514/udp syslog over DTLS [RFC6012] syslog-tls 6514/dccp syslog over DTLS [RFC6012]
syslog tls 6514/udp syslog over DTLS[RFC6012]syslog tls 6514/dccp syslog over DTLS[RFC6012]
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:
IANA已将服务代码SYLG分配给syslog，以便与DCCP一起使用。数据报拥塞控制协议（DCCP）参数注册表的服务代码子区中的分配如下：
1398361159 SYLG Syslog Protocol [RFC6012]
1398361159 SYLG系统日志协议[RFC6012]
The security considerations in [RFC4347], [RFC5246], [RFC5425], and [RFC5280] apply to this document.
[RFC4347]、[RFC5246]、[RFC5425]和[RFC5280]中的安全注意事项适用于本文档。
TLS and DTLS renegotiation may be vulnerable to attacks described in [RFC5746]. Although RFC 5746 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 RFC 5746 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.
TLS和DTL重新协商可能容易受到[RFC5746]中所述的攻击。尽管RFC 5746为一些问题提供了修复方案，但重新协商仍然会给应用程序带来问题，因为连接安全参数可能会在应用程序不知情的情况下更改。因此，建议通过DTL禁用syslog的重新协商。如果允许重新协商，则必须遵循RFC 5746中的规范，并且实现必须确保连接仍然具有足够的安全性，并且从客户端和服务器证书提取的任何标识在重新协商期间不会更改。
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. [RFC5424] notes that implementers who wish a lossless stream should be using tls/tcp as their transport. In addition, the use of signed syslog messages [RFC5848] can also provide an indication of message loss.
本文件中描述的传输不可靠。攻击者可能会在接收方不知情的情况下丢失或删除消息。[RFC5424]注意到，希望实现无损流的实现者应该使用tls/tcp作为传输。此外，使用签名的系统日志消息[RFC5848]也可以指示消息丢失。
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 [RFC4086] for random number generation guidance.
传输接收方和传输发送方实现通常生成它们自己的密钥对。生成这些密钥的随机数生成器（RNG）或伪随机数生成器（PRNG）不足可能会导致很少或没有安全性。有关随机数生成指南，请参见[RFC4086]。
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
信任锚的安装和存储至关重要。将信任锚（尤其是用作信任锚的自签名证书）从传输接收方传输到传输发送方以进行安装需要一个或多个带外步骤。必须注意确保安装的信任锚实际上是正确的信任锚。这个
fingerprint mechanism mentioned in Section 5.3.1 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.
传输发送方可以使用第5.3.1节中提到的指纹机制，以确保正确安装传输接收方的自签名证书。信任锚信息必须安全存储。对信任锚信息的更改可能导致接受应拒绝的证书。
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.
作者要感谢Wes Hardaker对本提案的审查，并就DTL的使用提出了宝贵的建议。还要感谢Pasi Eronen、David Harrington、Chris Lonvick、Eliot Lear、Anton Okmyanskiy、Juergen Schoenwaeld、Richard Graveman、syslog工作组成员和IESG成员的审查、评论和建议。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[RFC5238]Phelan，T.，“数据报拥塞控制协议（DCCP）上的数据报传输层安全性（DTLS）”，RFC 5238，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[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.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5425]Miao，F.，Ma，Y.，和J.Salowey，“系统日志的传输层安全性（TLS）传输映射”，RFC 54252009年3月。
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426]Okmianski，A.，“通过UDP传输系统日志消息”，RFC 5426，2009年3月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, <"Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，《传输层安全（TLS）重新协商指示扩展》，RFC 5746，2010年2月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog Messages", RFC 5848, May 2010.
[RFC5848]Kelsey，J.，Callas，J.，和A.Clemm，“签名系统日志消息”，RFC 5848，2010年5月。
Authors' Addresses
作者地址
Joseph Salowey Cisco Systems, Inc. 2901 3rd Ave. Seattle, WA 98121 USA
Joseph Salowey Cisco Systems，Inc.美国华盛顿州西雅图第三大道2901号，邮编98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm, Cheshire WA13 0NQ UK
Tom Petch工程网络有限公司18 Parkwood Close Lymm，柴郡WA13 0NQ英国
EMail: tomSecurity@network-engineer.co.uk
EMail: tomSecurity@network-engineer.co.uk
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld，BW 97950德国
EMail: rgerhards@adiscon.com
EMail: rgerhards@adiscon.com
Hongyan Feng Huaweisymantec Technologies 20245 Stevens Creek Blvd. Cupertino, CA 95014
红岩峰华威赛门铁克科技有限公司史蒂文斯溪大道20245号。加利福尼亚州库珀蒂诺，邮编95014
EMail: fhyfeng@gmail.com
EMail: fhyfeng@gmail.com