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メッセージの輸送を説明しています。これは、コネクションレス輸送を希望される場合は、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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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]を超えるsyslogメッセージのトランスポートを定義します。
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]は、安全なデータグラムの輸送を必要とするアプリケーションの要件を満たすように設計されています。 DTLSはUDP [RFC0768]及びデータグラム輻輳制御プロトコル（DCCP）[RFC4340]を含む異なるトランスポート上にマッピングされています。このメモは、両方のオプションを定義する、すなわち、DCCPの上にDTLS上でUDP上でDTLS上のsyslog、およびsyslog。
The following definitions from [RFC5424] are used in this document:
[RFC5424]から以下の定義は、この文書で使用されています。
o An "originator" generates syslog content to be carried in a message.
O「発信者は」メッセージで運ばれるsyslogの内容を生成します。
o A "collector" gathers syslog content for further analysis.
O「コレクター」は、さらに分析のためのsyslogの内容を収集します。
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「トランスポート送信者は、」特定のトランスポートプロトコルにsyslogメッセージを渡します。
o A "transport receiver" takes syslog messages from a specific transport protocol.
O「トランスポート・レシーバは、」特定のトランスポートプロトコルからのsyslogメッセージをとります。
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クライアントのHelloを開始することができるアプリケーションです。
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を受信して、こんにちはサーバーを使用して返信することができるアプリケーションです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The security requirements for the transport of syslog messages are discussed in Section 2 of [RFC5425]. These also apply to this specification.
syslogメッセージの輸送のためのセキュリティ要件は、[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]:
DTLSは、[RFC5425]で説明syslogにすべての主要な脅威に対抗するために、安全なトランスポートとして使用することができます。
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ハンドシェーク中のクッキー交換メカニズムは、サービス拒否攻撃に対抗します。
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の輸送を確保し、システムログメッセージの内容に関係しません。具体的には、トランスポート送信者の認証されたアイデンティティ（例えば、証明書のサブジェクト名が）必ずしもシスログメッセージのホスト名フィールドには関係しません。 Syslogメッセージの発信元の認証が必要な場合は、[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.
DTLSは、複数のトランスポート上で実行することができます。この仕様の実装は、UDP上のDTLSをサポートしなければならないとDCCP [RFC5238]の上にDTLSをサポートする必要があります。 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.
DTLSは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以上のSyslogを使用してはいけません。セキュアなトランスポートがTCPで必要とされている場合は、[RFC5425]で説明したように、適切なセキュリティメカニズムは、トランスポート層セキュリティ（TLS）経由のsyslogです。
A syslog transport sender is always a DTLS client, and a transport receiver is always a DTLS server.
syslogのトランスポート送信者は、常に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は、DTLS以上の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接続を開始します。実装はDTLSによって定義されたサービス対策の拒否をサポートしなければなりません。これらの対策が使用される場合、トランスポート受信機は、クッキーを含むリクエストを確認しDTLSこんにちはで応答します。トランスポート送信者はDTLSハンドシェイクを開始受け取ったクッキーを含むDTLSクライアントこんにちは、で応答します。 DTLSハンドシェイクが正常に完了する前に、トランスポート送信者は、任意のsyslogメッセージを送ってはいけません。
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_WITH_AES_128_CBC_SHAある暗号スイートを実装するために必須のをサポートしなければなりません。追加の暗号スイートがサポートされている場合、実装はNULL整合性や認証アルゴリズムを採用して暗号スイートを交渉してはなりません。
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.
プライバシーが必要な場合、その実装は非NULL暗号化アルゴリズムを採用して暗号スイートを交渉するか、他、このような物理的に安全なネットワークのような他の手段によってプライバシーを達成しなければならないのいずれか。
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と、指摘し、「クリアテキストのメッセージを渡すほとんどのケースでは、彼らは、ワイヤからのパケットを盗聴している場合は、運用スタッフに利点です」、そしてのでプライバシーが要件でない場合、 NULL暗号化アルゴリズムを使用することが有利です。
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.
DTLSはピアを認証するための証明書[RFC5280]を使用するために必須の暗号スイートを実装します。 syslogのトランスポート送信者（DTLSクライアント）およびSyslog転送受信機（DTLSサーバ）の両方が証明書ベースの認証を実装しなければなりません。これは、証明書を検証し、ピアが対応する秘密鍵を持っていることを確認することで構成されています。後者の部分は、DTLSによって行われます。クライアントとサーバ間の相互運用性を確保するために、セクション4.2.1および[RFC5425]の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:
すべてのsyslogメッセージがDTLS「アプリケーション・データ」として送らなければなりません。複数のsyslogメッセージが1つのDTLSレコードに含まれていること、またはsyslogメッセージが複数の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 = NONZERO-DIGIT * DIGIT
SP = %d32
SP =％のD32
NONZERO-DIGIT = %d49-57
NONZERO-DIGIT =％d49-57
DIGIT = %d48 / NONZERO-DIGIT
DIGIT =％のD48 /非ゼロ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フレーム内SYSLOG-MSGのオクテット数です。トランスポート・レシーバは、syslogメッセージを区切るためにメッセージ長を使用しなければなりません。それ自体がメッセージの長さの上限はありません。 [RFC4347]で述べたように、DTLSレコードは、複数のデータグラムをまたがってはなりません。異なるトランスポートにマッピングする場合、DTLSは異なるレコードサイズの制限があります。 UDPの場合は、[RFC5426]の3.2節を参照してください。 DCCPのために、アプリケーション実装は[RFC4340]で指定されるように、DCCPにわたって実行DTLSプロトコルによって許容される最大レコード・サイズを決定する必要があります。メッセージサイズは2 ^ 14バイトのDTLS最大レコード・サイズ制限を超えてはなりません。 [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.
接続は、後に任意のsyslogメッセージを届けることが予想されていない場合は、トランスポート送信者は、関連するDTLS接続を閉じる必要があります。これは、接続を閉じる前に、DTLSは、close_notifyを送らなければなりません。トランスポート送信者（DTLSクライアント）は、トランスポートレシーバのは、close_notifyを待って、単にDTLS接続を閉じないことを選択できます。トランスポート・レシーバは、トランスポート送信者からは、close_notifyを取得したら、それはは、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 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.
全くデータが（アプリケーションがどのような「長い」手段を決定する）長時間DTLS接続から受信されない場合、トランスポート受信機は接続を閉じます。トランスポート・レシーバ（DTLSサーバ）が接続を閉じる前に、トランスポートの送信者とは、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の構成要素とDTLSのようですが、彼らは、すべてのアラートのように、DTLSによって再送されていないので、信頼性の低いネットワーク上で失われることがあります。
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以上のsyslogはUDP上のDTLS上でsyslogに優先的に推奨されます。 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がサポートされています。 DTLS以上の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は、DTLS以上の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 DTLS [RFC6012]のsyslog TLS 6514 DTLSの/のsyslog DCCP [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はDCCPで使用するためにsyslogにサービスコードSYLGが割り当てられています。次のようにデータグラム輻輳制御プロトコル（DCCP）パラメータレジストリのサービスコードの副登録で割り当ては次のとおりです。
1398361159 SYLG Syslog Protocol [RFC6012]
1398361159 SYLGのSyslogプロトコル[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とDTLS再ネゴシエーションは、[RFC5746]に記載の攻撃に対して脆弱であり得ます。 RFC 5746は、問題のいくつかの修正を提供していますが、接続のセキュリティパラメータがそれを知っアプリケーションなしに変更することができるので、再交渉はまだアプリケーションで問題を引き起こす可能性があります。したがって、再交渉がDTLS以上の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を使用する必要があることを指摘しています。また、署名されたsyslogメッセージ[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.
著者は、この提案の彼のレビューのためにとDTLSの使用上の彼の貴重な提案を貢献するためウェスHardakerに感謝したいと思います。おかげでまたパシEronen、デヴィッド・ハリントン、クリスLonvick、エリオット・リア、アントンOkmyanskiy、ユルゲンSchoenwaelder、リチャードGraveman、syslogのワーキンググループのメンバー、及びそのレビュー、コメント、および提案のためのIESGのメンバーに。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、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]クロッカー、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]フェラン、T.、RFC 5238、2008年5月、 "データグラム輻輳制御プロトコル（DCCP）を超えるデータグラムトランスポート層セキュリティ（DTLS）"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards氏、R.、 "Syslogのプロトコル"、RFC 5424、2009年3月。
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5425]ミャオ族、F.、馬、Y.、およびJ. Salowey、 "トランスポート層セキュリティ（TLS）Syslogのための交通のマッピング"、RFC 5425、2009年3月。
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426] Okmianski、A.、 "UDP上のSyslogメッセージの送信"、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]レスコラ、E.、レイ、M.、Dispensa、S.、およびN. Oskov、< "トランスポート層セキュリティ（TLS）再ネゴシエーション指示拡張子"、RFC 5746、2010年2月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、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]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]エッゲルト、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]ケルシー、J.、カラス、J.、およびA. Clemm、 "署名付きシスログメッセージ"、RFC 5848、2010年5月。
Authors' Addresses
著者のアドレス
Joseph Salowey Cisco Systems, Inc. 2901 3rd Ave. Seattle, WA 98121 USA
ジョセフSaloweyシスコシステムズ株式会社2901年第三アベニュー。シアトル、WA 98121 USA
EMail: jsalowey@cisco.com
メールアドレス：jsalowey@cisco.com
Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm, Cheshire WA13 0NQ UK
トム・ペッチエンジニアリングネットワークス株式会社18パークウッドクローズリム、チェシャーWA13 0NQ英国
EMail: tomSecurity@network-engineer.co.uk
メールアドレス：tomSecurity@network-engineer.co.uk
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
レイナー・ガーハーズAdiscon社Mozartstrasse 21頭の大きな牛フィールド、BW 97950ドイツ
EMail: rgerhards@adiscon.com
メールアドレス：rgerhards@adiscon.com
Hongyan Feng Huaweisymantec Technologies 20245 Stevens Creek Blvd. Cupertino, CA 95014
香港F工学HUシマンテックの技術20245スティーブンスクリークブルバードクパチーノ、CA 95014のための饗宴
EMail: fhyfeng@gmail.com
メールアドレス：fhyfeng@gmail.com