[要約] RFC 5426は、UDPを介してSyslogメッセージを転送するためのプロトコル仕様です。このRFCの目的は、セキュアで信頼性の高いSyslogメッセージの転送を実現することです。
Network Working Group A. Okmianski
Request for Comments: 5426 Cisco Systems, Inc.
Category: Standards Track March 2009
Transmission of Syslog Messages over UDP
UDPを介したsyslogメッセージの送信
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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としての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping.
このドキュメントでは、UDP/ IPv4またはUDP/ IPv6を介したSYSLOGメッセージの輸送について説明します。Syslogプロトコル層状アーキテクチャは、任意の数の輸送マッピングのサポートを提供します。ただし、相互運用性のために、このトランスポートマッピングをサポートするには、Syslogプロトコルの実装者が必要です。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Transport Protocol ..............................................3
3.1. One Message Per Datagram ...................................3
3.2. Message Size ...............................................3
3.3. Source and Target Ports ....................................4
3.4. Source IP Address ..........................................4
3.5. UDP/IP Structure ...........................................4
3.6. UDP Checksums ..............................................4
4. Reliability Considerations ......................................5
4.1. Lost Datagrams .............................................5
4.2. Message Corruption .........................................5
4.3. Congestion Control .........................................5
4.4. Sequenced Delivery .........................................5
5. Security Considerations .........................................6
5.1. Sender Authentication and Message Forgery ..................6
5.2. Message Observation ........................................7
5.3. Replaying ..................................................7
5.4. Unreliable Delivery ........................................7
5.5. Message Prioritization and Differentiation .................7
5.6. Denial of Service ..........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Informational RFC 3164 [8] describes the syslog protocol as it was observed in existing implementations. It describes both the format of syslog messages and a UDP [1] transport. Subsequently, a Standards-Track syslog protocol has been defined in RFC 5424 [2].
Informational RFC 3164 [8]は、既存の実装で観察されたSyslogプロトコルを説明しています。Syslogメッセージの形式とUDP [1]トランスポートの両方を説明しています。その後、RFC 5424 [2]で標準トラックのSyslogプロトコルが定義されています。
RFC 5424 specifies a layered architecture that provides for support of any number of transport layer mappings for transmitting syslog messages. This document describes the UDP transport mapping for the syslog protocol.
RFC 5424 Syslogメッセージを送信するための任意の数の輸送層マッピングのサポートを提供する層状アーキテクチャを指定します。このドキュメントでは、SyslogプロトコルのUDPトランスポートマッピングについて説明します。
The transport described in this document can be used for transmitting syslog messages over both IPv4 [3] and IPv6 [4].
このドキュメントに記載されているトランスポートは、IPv4 [3]とIPv6 [4]の両方にSyslogメッセージを送信するために使用できます。
Network administrators and architects should be aware of the significant reliability and security issues of this transport, which stem from the use of UDP. They are documented in this specification. However, this transport is lightweight and is built upon the existing popular use of UDP for syslog.
ネットワーク管理者とアーキテクトは、UDPの使用に起因するこの輸送の重要な信頼性とセキュリティの問題を認識する必要があります。これらはこの仕様に文書化されています。ただし、このトランスポートは軽量であり、syslog用の既存の人気のあるUDPの使用に基づいて構築されています。
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 RFC 2119 [5].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [5]に記載されているように解釈される。
Each syslog UDP datagram MUST contain only one syslog message, which MAY be complete or truncated. The message MUST be formatted and truncated according to RFC 5424 [2]. Additional data MUST NOT be present in the datagram payload.
各syslog UDPデータグラムには、完全または切り捨てられる場合があるSyslogメッセージが1つだけ含まれている必要があります。メッセージは、RFC 5424 [2]に従ってフォーマットおよび切り捨てられる必要があります。Datagramペイロードに追加のデータが存在しないでください。
This transport mapping supports transmission of syslog messages up to 65535 octets minus the UDP header length. This limit stems from the maximum supported UDP size of 65535 octets specified in RFC 768 [1]. For IPv4, the maximum payload size is 65535 octets minus the UDP header and minus the IP header because IPv4 has a 16-bit length field that also includes the header length.
このトランスポートマッピングは、最大65535オクテットからUDPヘッダーの長さを差し引いてSyslogメッセージの送信をサポートします。この制限は、RFC 768で指定された65535オクテットの最大サポートされているUDPサイズに由来します[1]。IPv4の場合、最大ペイロードサイズは65535オクテットからUDPヘッダーを差し引いてIPヘッダーを引いたものです。IPv4には、ヘッダーの長さも含まれる16ビットの長さフィールドがあるためです。
IPv4 syslog receivers MUST be able to receive datagrams with message sizes up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message sizes up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams with message sizes of up to and including 2048 octets. The ability to receive larger messages is encouraged.
IPv4 syslogレシーバーは、480オクテットを含むメッセージサイズのデータグラムを受信できる必要があります。IPv6 syslogレシーバーは、1180オクテットを含むメッセージサイズのデータグラムを受信できる必要があります。すべてのSYSLOGレシーバーは、2048オクテットを含むメッセージサイズのデータグラムを受信できるはずです。より大きなメッセージを受信する機能が奨励されます。
The above restrictions and recommendations establish a baseline for interoperability. The minimum required message size support was determined based on the minimum MTU size that Internet hosts are required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 [4]. Datagrams that conform to these limits have the greatest chance of being delivered because they do not require fragmentation.
上記の制限と推奨事項は、相互運用性のベースラインを確立します。必要なメッセージサイズの最小サポートは、インターネットホストがサポートするために必要な最小MTUサイズに基づいて決定されました：IPv4 [3]の場合は576オクテット、IPv6 [4]の1280オクテット。これらの制限に準拠するデータグラムは、断片化を必要としないため、配信される可能性が最も高くなります。
It is RECOMMENDED that syslog senders restrict message sizes such that IP datagrams do not exceed the smallest MTU of the network in use. This avoids datagram fragmentation and possible issues surrounding fragmentation such as incorrect MTU discovery.
Syslog送信者は、IPデータグラムが使用中のネットワークの最小のMTUを超えないようにメッセージサイズを制限することをお勧めします。これにより、データグラムの断片化や、誤ったMTU発見などの断片化を取り巻く可能性のある問題が回避されます。
Fragmentation can be undesirable because it increases the risk of the message being lost due to loss of just one datagram fragment. Syslog has no acknowledgement facility, and therefore there is no effective way to handle retransmission. This makes it impossible for syslog to utilize packetization layer path MTU discovery [9]. When network MTU is not known in advance, the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6.
断片化は、1つのデータグラムフラグメントのみを失ったためにメッセージが失われるリスクを高めるため、望ましくない場合があります。Syslogには承認施設がないため、再送信を処理する効果的な方法はありません。これにより、SyslogはPacketization Layer Path MTU Discovery [9]を利用することが不可能になります。ネットワークMTUが事前に知られていない場合、最も安全な仮定は、メッセージをIPv4の480オクテットとIPv6の1180オクテットに制限することです。
Syslog receivers MUST support accepting syslog datagrams on the well-known UDP port 514, but MAY be configurable to listen on a different port. Syslog senders MUST support sending syslog message datagrams to the UDP port 514, but MAY be configurable to send messages to a different port. Syslog senders MAY use any source UDP port for transmitting messages.
Syslogレシーバーは、よく知られているUDPポート514のSyslogデータグラムの受け入れをサポートする必要がありますが、別のポートでリッスンするように構成できる場合があります。syslog送信者は、syslogメッセージデータグラムの送信をUDPポート514にサポートする必要がありますが、メッセージを別のポートに送信するように設定できる場合があります。Syslog送信者は、メッセージを送信するために任意のソースUDPポートを使用できます。
The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host that originated the syslog message. The entity sending the syslog message could be merely a relay. The syslog message itself contains the identifier of the originator of the message.
UDPデータグラムのソースIPアドレスは、syslogメッセージを発信したホストの識別子として解釈されるべきではありません。Syslogメッセージを送信するエンティティは、単なるリレーにすぎない可能性があります。Syslogメッセージ自体には、メッセージの発信者の識別子が含まれています。
Each UDP/IP datagram sent by the transport layer MUST completely adhere to the structure specified in the UDP RFC 768 [1] and either the IPv4 RFC 791 [3] or IPv6 RFC 2460 [4], depending on which protocol is used.
輸送層によって送信される各UDP/IPデータグラムは、UDP RFC 768 [1]およびIPv4 RFC 791 [3]またはIPv6 RFC 2460 [4]で指定された構造に完全に接着する必要があります。
Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums when sending messages. Note that RFC 2460 [4] mandates the use of UDP checksums when sending UDP datagrams over IPv6.
Syslog送信者は、UDPチェックサムを無効にしてはなりません。IPv4 Syslog送信者は、メッセージを送信するときにUDPチェックサムを使用する必要があります。RFC 2460 [4]は、IPv6を介してUDPデータグラムを送信する際にUDPチェックサムの使用を義務付けていることに注意してください。
Syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog receivers SHOULD check UDP checksums and SHOULD accept a syslog message with a zero checksum. Note that RFC 2460 [4] mandates the use of checksums for UDP over IPv6.
Syslogレシーバーは、UDPチェックサムチェックを無効にしてはなりません。IPV4 SYSLOGレシーバーは、UDPチェックサムをチェックし、ゼロチェックサムでSyslogメッセージを受け入れる必要があります。RFC 2460 [4]は、IPv6を介したUDPのチェックサムの使用を義務付けていることに注意してください。
The UDP is an unreliable, low-overhead protocol. This section discusses reliability issues inherent in UDP that implementers and users should be aware of.
UDPは信頼できない低オーバーヘッドプロトコルです。このセクションでは、実装者とユーザーが認識すべきUDPに固有の信頼性の問題について説明します。
This transport mapping does not provide any mechanism to detect and correct loss of datagrams. Datagrams can be lost in transit due to congestion, corruption, or any other intermittent network problem. IP fragmentation exacerbates this problem because loss of a single fragment will result in the entire message being discarded.
このトランスポートマッピングは、データグラムの損失を検出および修正するメカニズムを提供しません。渋滞、腐敗、またはその他の断続的なネットワークの問題により、輸送中にデータグラムが失われる可能性があります。IPフラグメンテーションは、単一のフラグメントを失うとメッセージ全体が破棄されるため、この問題を悪化させます。
The UDP/IP datagrams can get corrupted in transit due to software, hardware, or network errors. This transport mapping specifies use of UDP checksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols. However, checksums do not guarantee corruption detection, and this transport mapping does not provide for message acknowledgement or retransmission mechanism.
UDP/IPデータグラムは、ソフトウェア、ハードウェア、またはネットワークエラーにより、トランジットで破損する可能性があります。このトランスポートマッピングは、IPおよびレイヤー2プロトコルで使用されるチェックサムに加えて、腐敗検出を可能にするためにUDPチェックサムの使用を指定します。ただし、チェックサムは腐敗の検出を保証するものではなく、このトランスポートマッピングはメッセージの確認または再送信メカニズムを提供しません。
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 establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet [6]. This is why the syslog TLS transport [7] is REQUIRED to implement and RECOMMENDED for general use.
Syslogは無制限の量のデータを生成できるため、UDPには混雑制御メカニズムがないため、UDPを介してこのデータを転送することは一般に問題があります。交通率を下げて混雑に反応し、同じパスを共有するフロー間の程度の公平性を確立することにより、混雑に応答するメカニズムは、インターネットの安定した動作に不可欠です[6]。これが、Syslog TLSトランスポート[7]が実装に必要であり、一般的な使用に推奨される理由です。
The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport [7] SHOULD be used.
SYSLOG UDPトランスポートをTLSトランスポートの代替として使用できる唯一の環境は、レートの制限や容量の予約など、トラフィックエンジニアリングメカニズムを通じてUDP SYSLOGトラフィック用に明示的にプロビジョニングされているネットワークが管理されています。他のすべての環境では、TLS輸送[7]を使用する必要があります。
The IP transport used by the UDP does not guarantee that the sequence of datagram delivery will match the order in which the datagrams were sent. The time stamp contained within each syslog message can serve as a rough guide in establishing sequence order. However, it will not help in cases where multiple messages were generated during the same time slot, the sender could not generate a time stamp, or messages originated from different hosts whose clocks were not synchronized. The order of syslog message arrival via this transport SHOULD NOT be used as an authoritative guide in establishing an absolute or relative sequence of events on the syslog sender hosts.
UDPが使用するIPトランスポートは、データグラム配信のシーケンスがデータグラムが送信された順序と一致することを保証するものではありません。各syslogメッセージに含まれるタイムスタンプは、シーケンス順序を確立する際の大まかなガイドとして機能します。ただし、同じ時間スロットで複数のメッセージが生成された場合、送信者がタイムスタンプを生成できなかった場合、またはクロックが同期されていないさまざまなホストから発信されるメッセージでは役に立ちません。このトランスポートを介したSyslogメッセージの到着の到着は、Syslog送信者ホストに絶対的または相対的なイベントシーケンスを確立する際の権威あるガイドとして使用すべきではありません。
Using this specification on an unsecured network is NOT RECOMMENDED. Several syslog security considerations are discussed in RFC 5424 [2]. This section focuses on security considerations specific to the syslog transport over UDP. Some of the security issues raised in this section can be mitigated through the use of IPsec as defined in RFC 4301 [10].
保護されていないネットワークでこの仕様を使用することは推奨されません。いくつかのSYSLOGセキュリティ上の考慮事項については、RFC 5424 [2]で説明しています。このセクションでは、UDPを介したSyslog輸送に固有のセキュリティ上の考慮事項に焦点を当てています。このセクションで提起されたセキュリティの問題のいくつかは、RFC 4301 [10]で定義されているように、IPSECの使用を通じて軽減できます。
This transport mapping does not provide for strong sender authentication. The receiver of the syslog message will not be able to ascertain that the message was indeed sent from the reported sender, or whether the packet was sent from another device. This can also lead to a case of mistaken identity if an inappropriately configured machine sends syslog messages to a receiver representing itself as another machine.
このトランスポートマッピングは、強力な送信者認証を提供しません。Syslogメッセージの受信者は、メッセージが実際に報告された送信者から送信されたこと、またはパケットが別のデバイスから送信されたかどうかを確認することはできません。これは、不適切に構成されたマシンが別のマシンとして自分自身を表すレシーバーにsyslogメッセージを送信する場合、誤ったアイデンティティのケースにつながる可能性があります。
This transport mapping does not provide protection against syslog message forgery. An attacker can transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a receiver.
このトランスポートマッピングは、Syslog Message Forgeryに対する保護を提供しません。攻撃者は、syslogメッセージ（メッセージが送信されるとされるマシンから、または他のマシンから）を受信者に送信できます。
In one case, an attacker can hide the true nature of an attack amidst many other messages. As an example, an attacker can start generating forged messages indicating a problem on some machine. This can get the attention of the system administrators, who will spend their time investigating the alleged problem. During this time, the attacker could be able to compromise a different machine or a different process on the same machine.
あるケースでは、攻撃者は他の多くのメッセージの中で攻撃の本質を隠すことができます。例として、攻撃者は、一部のマシンで問題を示す偽造メッセージの生成を開始できます。これにより、システム管理者が注意を払うことができます。システム管理者は、問題を調査するために時間を費やします。この間、攻撃者は同じマシンで異なるマシンまたは別のプロセスを妥協できる可能性があります。
Additionally, an attacker can generate false syslog messages to give untrue indications of the status of systems. As an example, an attacker can stop a critical process on a machine, which could generate a notification of exit. The attacker can subsequently generate a forged notification that the process had been restarted. The system administrators could accept that misinformation and not verify that the process had indeed not been restarted.
さらに、攻撃者は誤ったsyslogメッセージを生成して、システムのステータスの真実ではない兆候を与えることができます。例として、攻撃者はマシンで重要なプロセスを停止し、出口の通知を生成することができます。攻撃者は、その後、プロセスが再開されたという偽造通知を生成できます。システム管理者は、その誤った情報を受け入れ、プロセスが実際に再起動されていないことを確認できません。
This transport mapping does not provide confidentiality of the messages in transit. If syslog messages are in clear text, this is how they will be transferred. In most cases, passing clear-text, human-readable messages is a benefit to the administrators. Unfortunately, an attacker could also be able to observe the human-readable contents of syslog messages. The attacker could then use the knowledge gained from these messages to compromise a machine. It is RECOMMENDED that no sensitive information be transmitted via this transport mapping or that transmission of such information be restricted to properly secured networks.
このトランスポートマッピングは、輸送中のメッセージの機密性を提供しません。Syslogメッセージが明確なテキストにある場合、これがそれらの転送方法です。ほとんどの場合、クリアテキストを通過すると、人間が読みやすいメッセージは、管理者にとって利益です。残念ながら、攻撃者は、syslogメッセージの人間が読みやすい内容を観察することもできます。攻撃者は、これらのメッセージから得られた知識を使用して、マシンを妥協することができます。このトランスポートマッピングを介して伝達される情報を送信したり、そのような情報の送信を適切にセキュリティで固定したネットワークに制限することをお勧めします。
Message forgery and observation can be combined into a replay attack. An attacker could record a set of messages that indicate normal activity of a machine. At a later time, an attacker could remove that machine from the network and replay the syslog messages with new time stamps. The administrators could find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine.
メッセージの偽造と観察を再生攻撃に結合することができます。攻撃者は、マシンの通常のアクティビティを示す一連のメッセージを記録できます。後で、攻撃者はネットワークからそのマシンを削除し、新しいタイムスタンプでsyslogメッセージを再生できます。管理者は、受信したメッセージで珍しいものを見つけることができず、領収書はマシンの通常のアクティビティを誤って示しています。
As was previously discussed in Section 4, Reliability Considerations, the UDP transport is not reliable, and packets containing syslog message datagrams can be lost in transit without any notice. There can be security consequences to the loss of one or more syslog messages. Administrators could be unaware of a developing and potentially serious problem. Messages could also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
セクション4、信頼性の考慮事項で以前に説明したように、UDPトランスポートは信頼できず、Syslogメッセージデータグラムを含むパケットは、通知なしに輸送中に失われる可能性があります。1つまたは複数のSyslogメッセージの喪失にセキュリティの影響がある可能性があります。管理者は、発展し、潜在的に深刻な問題を知らない可能性があります。また、許可されていないアクティビティを隠す方法として、攻撃者によってメッセージを傍受および破棄することもできます。
This transport mapping does not mandate prioritization of syslog messages either on the wire or when processed on the receiving host based on their severity. Unless some prioritization is implemented by sender, receiver, and/or network, the security implication of such behavior is that the syslog receiver or network devices could get overwhelmed with low-severity messages and be forced to discard potentially high-severity messages.
このトランスポートマッピングは、ワイヤー上で、またはその重大度に基づいて受信ホストで処理された場合のSyslogメッセージの優先順位付けを義務付けません。ある程度の優先順位付けが送信者、受信機、および/またはネットワークによって実装されない限り、そのような動作のセキュリティの意味は、Syslogレシーバーまたはネットワークデバイスが低悪性メッセージで圧倒され、潜在的に高重度のメッセージを捨てることを余儀なくされる可能性があることです。
An attacker could overwhelm a receiver by sending more messages to it than could be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat, such as optionally restricting reception of messages to a set of known source IP addresses.
攻撃者は、インフラストラクチャまたはデバイス自体で処理できるよりも多くのメッセージを送信することにより、受信機を圧倒することができます。実装者は、既知のソースIPアドレスのセットへのメッセージの受信をオプションに制限するなど、この脅威を最小限に抑える機能を提供しようとする必要があります。
This transport uses UDP port 514 for syslog, as recorded in the IANA port-numbers registry.
このトランスポートは、IANAポート番号レジストリに記録されているように、SyslogにUDPポート514を使用します。
The author gratefully acknowledges the contributions of: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch, Richard Graveman, and all others who have commented on the various versions of this proposal.
著者は、クリス・ロンヴィック、レイナー・ゲルハード、デビッド・ハリントン、アンドリュー・ロス、アルバート・マイエトゥス、バーニー・ヴォルツ、ミカエル・グラハム、グレッグ・モリス、アレクサンドラ・フェドロヴァ、デヴィン・コワッチ、リチャード・グレイブマンなどの貢献を感謝して認めています。この提案のバージョン。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[2] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[2] Gerhards、R。、「Syslog Protocol」、RFC 5424、2009年3月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[6] フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[7] Miao, F. and Y. Ma, "TLS Transport Mapping for Syslog", RFC 5425, March 2009.
[7] Miao、F。およびY. Ma、「SyslogのTLS輸送マッピング」、RFC 5425、2009年3月。
[8] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[8] Lonvick、C。、「The BSD Syslog Protocol」、RFC 3164、2001年8月。
[9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[9] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[10] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[10] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
Author's Address
著者の連絡先
Anton Okmianski Cisco Systems, Inc. 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada
Anton Okmianski Cisco Systems、Inc。595 Burrard St.、Suite 2123 Vancouver、BC V7X 1J1 Canada
Phone: +1-978-936-1612
EMail: aokmians@cisco.com