[要約] RFC 6012は、SyslogのためのDatagram Transport Layer Security（DTLS）トランスポートマッピングに関するものであり、DTLSを使用してSyslogメッセージのセキュアな転送を提供することを目的としています。
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メッセージの輸送について説明します。Connectionless Transportが必要な場合に、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
Datagram Transport Layer Security（DTLS）プロトコル[RFC4347]は、安全なデータグラム輸送が必要なアプリケーションの要件を満たすように設計されています。DTLSは、UDP [RFC0768]やDatagramうっ血制御プロトコル（DCCP）[RFC4340]を含むさまざまなトランスポートにマッピングされています。このメモは、両方のオプション、つまりUDPを介したDTLを介したSyslog、およびDCCPを超えるDTLを超える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 「Originator」は、メッセージに掲載される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を受信し、サーバー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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]:
DTLは、[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.
注：この安全なトランスポート（つまり、DTL）は、ホップバイホップでのみSyslogトランスポートを保護し、Syslogメッセージの内容には関心がありません。特に、トランスポート送信者の認証されたID（例：証明書の件名）は、必ずしも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.
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.
各syslogメッセージは、各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を介したDTLを介したSyslogは使用しないでください。TCPで安全な輸送が必要な場合、[RFC5425]に記載されているように、適切なセキュリティメカニズムは輸送層セキュリティ（TLS）を超えるSyslogです。
A syslog transport sender is always a DTLS client, and a transport receiver is always a DTLS server.
Syslog Transport Senderは常に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.
Transport Senderは、DTLSクライアントをトランスポートレシーバーに送信することにより、DTLS接続を開始します。実装は、DTLSによって定義されたサービス拒否対策をサポートする必要があります。これらの対策を使用すると、輸送レシーバーは、Cookieを含むDTLS Hello Verifyリクエストで応答します。トランスポート送信者は、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であるCipher Suiteを実装するための必須をサポートする必要があります。追加の暗号スイートがサポートされている場合、実装はヌルの完全性または認証アルゴリズムを使用する暗号スイートをネゴシエートしてはなりません。
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]を使用します。Syslog Transport Sender（DTLSクライアント）とSyslog Transport Receiver（DTLS Server）の両方が、証明書ベースの認証を実装する必要があります。これは、証明書を検証し、ピアが対応する秘密鍵を持っていることを確認することで構成されています。後者の部分は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.
トランスポートレシーバーとトランスポート送信者は、IDを送信または受信したデータと相関させる目的で、リモートエンドポイントで使用される証明書または証明書指紋を記録するメカニズムを提供する必要があります。
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レコードに含めること、または複数のDTLSレコードでsyslogメッセージが転送される可能性があります。アプリケーションデータは、次のABNF [RFC5234]式で定義されます。
APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
msg-len = non zero-digit *桁
SP = %d32
NONZERO-DIGIT = %d49-57
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フレームの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 alertを送信する必要があります。トランスポート送信者（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のコンポーネントですが、すべてのアラートと同様に、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を介したDTLを介したSyslogは、UDPを介したDTLよりもSyslogを優先して推奨されます。DCCPを介したDTLを介した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 [RFC5425]とDTL上の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は、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 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は、DCCPで使用するためにSyslogにサービスコードSYLGを割り当てました。Datagramのサービスコードサブレジストリの割り当て渋滞制御プロトコル（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はいくつかの問題の修正を提供しますが、接続セキュリティパラメーターがアプリケーションを知らずに変更できるため、再交渉はアプリケーションに問題を引き起こす可能性があります。したがって、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を輸送として使用する必要があることに注意してください。さらに、署名された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.
アンカーのインストールとストレージを信頼することが重要です。信頼アンカー、特にトランスポートレシーバーからトランスポートセンダーまでの信頼アンカーとして使用される自己署名証明書の送信には、1つ以上のバンド外のステップが必要です。インストールされた信頼アンカーが実際に正しい信頼アンカーであることを確認するために注意する必要があります。セクション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の使用に関する彼の貴重な提案に貢献してくれたWes Hardakerに感謝したいと思います。Pasi Eronen、David Harrington、Chris Lonvick、Eliot Lear、Anton Okmyanskiy、Juergen Schoenwaelder、Richard Graveman、Syslog Working Groupのメンバー、および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、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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、「The Transport Layer Security（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 5280、2008年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslog Protocol」、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] Miao、F.、Ma、Y。、およびJ. Salowey、「Syslogの輸送層セキュリティ（TLS）輸送マッピング」、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] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、<"Transport Layer Security（TLS）Remegotiation Incosition Extension"、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] 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、「Signed Syslogメッセージ」、RFC 5848、2010年5月。
Authors' Addresses
著者のアドレス
Joseph Salowey Cisco Systems, Inc. 2901 3rd Ave. Seattle, WA 98121 USA
Joseph Salowey Cisco Systems、Inc。2901 3rd Ave. Seattle、WA 98121 USA
EMail: jsalowey@cisco.com
Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm, Cheshire WA13 0NQ UK
Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm、Cheshire WA13 0NQ UK
EMail: tomSecurity@network-engineer.co.uk
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
レイナー・ゲルハード・アディスコンGmbHモーツァルトスラセ21グロスリンダーフェルド、BW 97950ドイツ
EMail: rgerhards@adiscon.com
Hongyan Feng Huaweisymantec Technologies 20245 Stevens Creek Blvd. Cupertino, CA 95014
Hongyan Feng Huaweisymantec Technologies 20245 Stevens Creek Blvd.Cupertino、CA 95014
EMail: fhyfeng@gmail.com