RFC 3195 - Reliable Delivery for syslog 日本語訳

URL : https://tools.ietf.org/html/rfc3195
タイトル : RFC 3195 - syslogのための信頼性の高い配信
翻訳編集 : 自動生成

Network Working Group                                             D. New
Request for Comments: 3195                                       M. Rose
Category: Standards Track                   Dover Beach Consulting, Inc.
                                                           November 2001

                      Reliable Delivery for 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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2001）。全著作権所有。

Abstract

抽象

The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. The first provides a trivial mapping maximizing backward compatibility. The second provides a more complete mapping. Both provide a degree of robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol.

BSDのsyslogプロトコルは、イベントメッセージを伝播に関連するサービスオプションの数を示します。このメモは、イベントメッセージの信頼性の送達に有用な、両方のTCPコネクションにsyslogプロトコルの2つのマッピングを説明しています。最初は下位互換性を最大に些細なマッピングを提供します。第二は、より完全なマッピングを提供します。どちらも、コネクション指向のプロトコルを介して暗号化と認証を提供することで、通常のUDPベースのsyslogプロトコルに使用できないメッセージ配信における堅牢性とセキュリティの度合いを提供しています。

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    The Model  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    The RAW Profile  . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   RAW Profile Overview . . . . . . . . . . . . . . . . . . . .  7
   3.2   RAW Profile Identification and Initialization  . . . . . . .  9
   3.3   RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
   3.4   RAW Profile Message Semantics  . . . . . . . . . . . . . . . 10
   4.    The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
   4.1   COOKED Profile Overview  . . . . . . . . . . . . . . . . . . 11
   4.2   COOKED Profile Identification and Initialization . . . . . . 11
   4.3   COOKED Profile Message Syntax  . . . . . . . . . . . . . . . 11
   4.4   COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
   4.4.1 The IAM Element  . . . . . . . . . . . . . . . . . . . . . . 12
   4.4.2 The ENTRY Element  . . . . . . . . . . . . . . . . . . . . . 14
   4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
   5.    Additional Provisioning  . . . . . . . . . . . . . . . . . . 25
   5.1   Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
   5.2   Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
   5.3   Message Integrity  . . . . . . . . . . . . . . . . . . . . . 25
   5.4   Message Observation  . . . . . . . . . . . . . . . . . . . . 26
   5.5   Summary of Recommended Practices . . . . . . . . . . . . . . 26
   6.    Initial Registrations  . . . . . . . . . . . . . . . . . . . 27
   6.1   Registration: The RAW Profile  . . . . . . . . . . . . . . . 27
   6.2   Registration: The COOKED Profile . . . . . . . . . . . . . . 27
   7.    The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
   8.    Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . . 32
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 33
   9.1   Registration: BEEP Profiles  . . . . . . . . . . . . . . . . 33
   9.2   Registration: The System (Well-Known) TCP port number for
            syslog-conn . . . . . . . . . . . . . . . . . . . . . . . 33
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 34
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36

1. Introduction

1. はじめに

The syslog protocol [1] presents a spectrum of service options for provisioning an event-based logging service over a network. Each option has associated benefits and costs. Accordingly, the choice as to what combination of options is provisioned is both an engineering and administrative decision. This memo describes how to realize the syslog protocol when reliable delivery is selected as a required service. It is beyond the scope of this memo to argue for, or against, the use of reliable delivery for the syslog protocol.

syslogプロトコル[1]は、ネットワークを介して、イベントベースのロギングサービスをプロビジョニングするためのサービスオプションのスペクトルを示します。各オプションにはメリットとコストを関連付けられています。したがって、オプションのどの組み合わせがプロビジョニングされるような選択は、エンジニアリングと管理の決定の両方です。このメモは、信頼性の高い配信が必要なサービスとして選択されたときのsyslogプロトコルを実現する方法について説明します。それはのために、またはsyslogプロトコルのための信頼性の高い配信の使用、反論するために、このメモの範囲を超えています。

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 [2].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。

2. The Model

2.モデル

The syslog service supports three roles of operation: device, relay, and collector.

デバイス、リレー、およびコレクター：syslogサービスは、操作の3つの役割をサポートしています。

Devices and collectors act as sources and sinks, respectively, of syslog entries. In the simplest case, only a device and collector are present. E.g.,

デバイスやコレクターは、syslogのエントリで、それぞれ、ソースとシンクとして機能します。最も単純なケースでは、専用デバイスとコレクタが存在しています。例えば。、

     +--------+        +-----------+
     | Device | -----> | Collector |
     +--------+        +-----------+

The relationship between devices and collectors is potentially many-to-many. I.e., a device might communicate with many collectors; similarly, a collector might communicate with many devices.

デバイスとコレクターとの間の関係は、潜在的に多対多です。すなわち、デバイスは、多くのコレクターと通信可能性があります。同様に、コレクタは、多くのデバイスと通信することがあります。

A relay operates in both modes, accepting syslog entries from devices and other relays and forwarding those entries to collectors and other relays.

リレーは、デバイスと他のリレーからのsyslogエントリを受け入れ、コレクターや他のリレーにこれらのエントリを転送し、両方のモードで動作します。

For example,

例えば、

     +--------+      +-------+        +-------+      +-----------+
     | Device | ---> | Relay | -...-> | Relay | ---> | Collector |
     +--------+      +-------+        +-------+      +-----------+

As shown, more than one relay may be present between any particular device and collector.

示されるように、複数の中継器は、任意の特定のデバイスとコレクタとの間に存在してもよいです。

A relay may be necessary for administrative reasons. For example, a relay might run as an application proxy on a firewall. Also, there might be one relay per company department, which authenticates all the devices in the department, and which in turn authenticates itself to a company-wide collector.

リレーは、管理上の理由で必要になることがあります。例えば、リレーは、ファイアウォール上のアプリケーションプロキシとして実行される可能性があります。また、順番に全社コレクタに自分自身を認証する1つの部門内のすべてのデバイスを認証し、会社の部門ごとにリレーと、そこにあるかもしれません。

A relay can also serve to filter messages. For example, one relay may collect the syslog information from an entire web server farm, summarizing hit counts for report generation, forwarding "page not found" messages (indicating a possible broken link) to a collector that presents it to the webmaster, and sending more urgent messages (such as hardware failure reports) to a collector that gateways them to a pager. A relay may also be used to convert formats from a device's output to a collector's input.

リレーはまた、メッセージをフィルタ処理するのに役立つことができます。例えば、1つのリレーは、「ページが見つかりません」メッセージを転送するウェブマスターに提示コレクタに（可能な壊れたリンクを示す）、および送信、レポート作成のためのヒット数をまとめ、全体のWebサーバーファームからのsyslog情報を収集することがありますポケットベルにそれらをゲートウェイコレクタに（たとえば、ハードウェア障害レポートなど）より緊急メッセージ。リレーはまた、コレクターの入力デバイスの出力からのフォーマットに変換するために使用することができます。

It should be noted that a role of device, relay, or collector is relevant only to a particular BEEP channel (q.v., below). A single server can serve as a device, a relay, and a collector, all at once, if so configured. It can even serve as a relay and a collector to the same device at the same time using different BEEP channels over the same connection-oriented session; this might be useful to collect status yet relay urgent error messages.

デバイス、リレー、又はコレクタの役割は（以下、q.v.）のみ特定BEEPチャンネルに関連していることに留意すべきです。ように設定されている場合、単一のサーバは、すべて一度に、デバイス、リレー、およびコレクタとして機能することができます。それも、リレーと同じコネクション指向セッションを超える異なるBEEPチャネルを使用して同時に同じデバイスにコレクタとして機能することができます。これはまだ状況を収集し、緊急のエラーメッセージを中継するために役に立つかもしれません。

To provide reliable delivery when realizing the syslog protocol, this memo defines two BEEP profiles. BEEP [3] is a generic application protocol framework for connection-oriented, asynchronous interactions. Within BEEP, features such as authentication, privacy, and reliability through retransmission are provided. There are two profiles defined in this memo:

syslogプロトコルを実現する際に信頼できる配信を提供するために、このメモは、二つのBEEPプロファイルを定義します。 BEEP [3]は、接続指向、非同期相互作用のための汎用アプリケーション・プロトコル・フレームワークです。 BEEP内で、そのような再送信による認証、プライバシー、および信頼性などの機能が設けられています。このメモで定義された2つのプロファイルがあります。

o The RAW profile is designed to provide a high-performance, low-impact footprint, using essentially the same format as the existing UDP-based syslog service.

O RAWプロファイルは、本質的に、既存のUDPベースのsyslogサービスと同じ形式を使用して、高性能、低衝撃のフットプリントを提供するように設計されています。

o The COOKED profile is designed to provide a structured entry format, in which individual entries are acknowledged (either positively or negatively).

O COOKEDプロファイルは、個々のエントリは、（正または負のいずれか）確認応答された構造化エントリフォーマットを提供するように設計されています。

Note that both profiles run over BEEP. BEEP defines "transport mappings," specifying how BEEP messages are carried over the underlying transport technologies. At the time of this writing, only one such transport is defined, in [4], which specifies BEEP over TCP. All transport mappings are required to support enough reliability and sequencing to allow all BEEP messages on a given channel to be delivered reliably and in order. Hence, both the RAW and COOKED profile provide reliable delivery of their messages.

両方のプロファイルがBEEP上で実行することに注意してください。 BEEPは、基礎となるトランスポート技術の上に搭載されているかBEEPメッセージを指定する「トランスポート・マッピング」を定義します。 [4]、TCP上でBEEPを指定するには、この記事の執筆時点では、一つだけ、そのような輸送は、定義されます。すべてのトランスポートマッピングは、指定されたチャネル上のすべてのBEEPメッセージが確実かつ順番に配信されるのに十分な信頼性とシーケンシングをサポートする必要があります。したがって、RAW調理済みのプロファイルの両方が彼らのメッセージ配信の信頼性を提供します。

The choice of profile is independent of the operational roles discussed above.

プロファイルの選択は、上述の業務の役割とは無関係です。

For example, in

例えば、中

     +--------+        +-------+        +-----------+
     | Device | -----> | Relay | -----> | Collector |
     +--------+        +-------+        +-----------+

the device-to-relay link could be configured to use the RAW profile, while the relay-to-collector link could be configured to use the COOKED profile. (For example, the relay may be parsing the RAW syslog messages from the device, knowing the details of their formats, before passing them to a more generic collector.) Indeed, the same device may use different profiles, depending on the collector to which it is sending entries.

リレー・ツー・コレクターリンク調理プロファイルを使用するように構成することができるが、デバイスへリレーリンクは、RAWプロファイルを使用するように構成することができます。（例えば、リレーは、より一般的なコレクタに渡す前に、その形式の詳細を知る装置からRAW syslogメッセージを解析してもよい。）実際には、同じデバイスが異なるプロファイルを使用することができ、集電体に応じましたそれは、エントリを送信しています。

Devices and relays MAY discover relays and collectors via the DNS SRV algorithm [5]. If so configured, the service used is "syslog" and the protocol used is "tcp". This allows for central administration of addressing, fallback for failed relays and collectors, and static load balancing. Security policies and hardware configurations may be such that device configuration is more secure than the DNS server. Hardware devices may be of such limited resources that DNS SRV access is inappropriate. Firewalls and other restrictive routing mechanisms may need to be dealt with before a reliable syslog connection can be established. In these cases, DNS might not be the most appropriate configuration mechanism.

デバイスとリレーは、DNS SRVアルゴリズム[5]経由でリレーやコレクターを発見するかもしれません。そのように構成されている場合、使用されるサービスは、「syslogの」で、使用されるプロトコルは「TCP」です。これは失敗したリレーやコレクター、および静的負荷分散のためのフォールバック、アドレッシングの集中管理が可能になります。セキュリティポリシーとハードウェア構成は、デバイス構成は、DNSサーバーよりも安全であるようなものであってもよいです。ハードウェアデバイスは、DNS SRVアクセスが不適切である、そのような限られたリソースであってもよいです。ファイアウォールやその他の制限ルーティングメカニズムは、信頼できるsyslogの接続が確立する前に対処する必要があるかもしれません。これらのケースでは、DNSは、最も適切な設定メカニズムではないかもしれません。

3. The RAW Profile

3. RAWプロフィール

3.1 RAW Profile Overview

3.1 RAWプロファイルの概要

The RAW profile is designed for minimal implementation effort, high efficiency, and backwards compatibility. It is appropriate especially in cases where legacy syslog processing will be applied.

RAWプロファイルは、最小の実装作業、高効率、および後方互換性のために設計されています。これは、特に、従来のsyslog処理が適用される場合には適切です。

It should be noted that even though the RAW profile uses the same format for message payloads as the UDP version of syslog uses, delivery is reliable. The RAW syslog profile is a profile of BEEP [3], and BEEP guarantees ordered reliable delivery of messages within each individual channel.

RAWプロファイルはsyslogの用途のUDPバージョンとしてメッセージ・ペイロードに同じフォーマットを使用していても、配信は信頼性があることに留意すべきです。 RAW syslogのプロファイルは、[3] BEEPのプロファイルであり、そしてBEEP保証は、個々のチャネル内のメッセージの信頼できる配信を命じました。

When the profile is started, no piggyback data is supplied. All BEEP messages in the RAW profile are specified as having a MIME Content-Type [6] of application/octet-stream. Once the channel is open, the listener (not the initiator) sends a MSG message indicating it is ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for a discussion of roles that a BEEP peer may perform, including definitions of the terms "listener", "initiator", "client", and "server".)

プロファイルが開始されると、何もピギーバックデータが供給されていません。 RAWプロファイル内のすべてのBEEPメッセージは、MIMEコンテンツタイプを有するものとして規定されている[6]アプリケーション/オクテットストリームの。チャネルが開いたら、リスナー（ないイニシエータ）は、syslogのシンクとして作用する準備ができて示すMSGメッセージを送信します。（用語の定義『リスナー』、『開始』、『クライアント』および『サーバ』を含むBEEPピアが実行することができる役割の議論のために、[3]のセクション2.1を参照）。

The initiator uses ANS replies to supply one or more syslog entries in the current UDP format, as specified in [1]'s Section 3. When the initiator has no more entries to send, it finishes with a NUL reply and closes the channel.

イニシエータは、NUL応答で終了し、チャネルを閉じ、ANSは、[1]のセクション3で指定されるように、イニシエータが送信するこれ以上のエントリを有する場合、現在のUDPフォーマットで一個の以上のsyslogエントリを供給するように応答する使用します。

An example might appear as follows:

次のように例が表示されることがあります。

L: <wait for incoming connection> I: <establish connection> L: RPY 0 0 . 0 201 L: Content-type: application/beep+xml L: L: <greeting> L: <profile L: uri='http://xml.resource.org/profiles/syslog/COOKED' /> L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-type: application/beep+xml I: I: <greeting /> I: END I: MSG 0 1 . 52 133 I: Content-type: application/beep+xml

L：RPY 0 0：L <接続を確立>：I <着信接続を待ちます>。 0 201 L：コンテンツタイプ：アプリケーション/ビープ+ XMLのL：L <挨拶> L <プロフィールL：URI = 'HTTP：//xml.resource.org/profiles/syslog/COOKED' /> L <プロファイルのuri = 'のhttp：//xml.resource.org/profiles/syslog/RAW' /> L：</挨拶> L：END I：RPY 0 0。 0 52 I：コンテンツタイプ：アプリケーション/ビープ+ XML I：I：<挨拶/> I：END I：MSG 0 1。 52 133 I：コンテンツタイプ：アプリケーション/ビープ+ XML

I: I: <start number='1'> I: <profile uri='http://xml.resource.org/profiles/syslog/RAW' /> I: </start> I: END L: RPY 0 1 . 201 100 L: Content-type: application/beep+xml L: L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' /> L: END L: MSG 1 0 . 0 50 L: L: Central Services. This has not been a recording. L: END I: ANS 1 0 . 0 61 0 I: I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END I: ANS 1 0 . 61 58 1 I: I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END I: NUL 1 0 . 119 0 I: END L: MSG 0 3 . 301 70 L: Content-Type: application/beep+xml L: L: <close number='1' code='200' /> L: END I: RPY 0 3 . 185 46 I: Content-Type: application/beep+xml I: I: <ok /> I: END I: MSG 0 4 . 231 72 I: Content-Type: application/beep+xml I: I: <close number='0' code='200' /> I: END L: RPY 0 4 . 371 46 L: Content-type: application/beep+xml L: L: <ok /> L: END L: <closes connection> I: <closes connection> L: <awaits next connection>

I：I：<=番号を開始する '1'> I：<プロファイルのuri = 'のhttp：//xml.resource.org/profiles/syslog/RAW' /> I </スタート> I：ENDのL：RPY 0 1。 201 100 L：コンテンツタイプ：アプリケーション/ビープ+ XMLのL：L <プロファイルURI = 'HTTP：//xml.resource.org/profiles/syslog/RAW' /> L：ENDのL：MSG 1 0。 0 50 L：L：中央サービス。これは記録されていません。 L：END I：ANS 1 0。 0 61 0 I：I：<29> 10月27日午前13時21分08秒ダクト構造imxpd [141]：暖房emergency.END I：ANS 1 0。 61 58 1 I：I：<29> 10月27日夜1時22分15秒ダクト構造imxpd [141]：コンタクトTuttle.END I：NUL 1 0。 119 0 I：ENDのL：MSG 0 3。 301 70 L：コンテンツタイプ：アプリケーション/ビープ+ XMLのL：L <近い数= '1' コード= '200' /> L：END I：RPY 0 3。 185 46 I：のContent-Type：アプリケーション/ビープ音+ xmlのI：I：<OK /> I：END I：MSG 0 4。 231 72 I：コンテンツタイプ：アプリケーション/ビープ+ XML I：I：<近い数= '0' コード= '200' /> I：ENDのL：RPY 0 4。 371 46 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<OK /> L：ENDのL：<接続を閉じ> I：L <接続を閉じ>：<次の接続を待ち受けます>

Here we see a BEEP session established, followed by the use of the RAW profile. The initiator is a device, while the listener is a collector. The initiator opens the channel, but the listener sends the first MSG. This allows the initiator to send any number of ANS replies carrying syslog event messages. The initiator sends a NUL reply to indicate it is finished. Upon receiving the NUL, the listener closes the RAW channel. The initiator has the choice of closing the entire BEEP session or opening a new syslog channel (RAW or COOKED) for more transfers. In this example, the initiator chooses to close the entire BEEP session.

ここでは、RAWプロファイルの使用に続いて、確立BEEPセッションを参照してください。リスナーがコレクタであるが、イニシエータは、デバイスです。イニシエータは、チャネルを開きますが、リスナーは最初のMSGを送信します。これは、イニシエータは、syslogのイベントメッセージを運ぶANS返信の任意の数を送信することができます。イニシエータは、それが終了していることを示すためにNUL応答を送信します。 NULを受信すると、リスナーはRAWチャネルを閉じます。イニシエータは全体BEEPセッションを閉じる以上の転送用に新しいsyslogのチャンネル（生または調理）を開くの選択肢を持っています。この例では、開始剤は、全体BEEPセッションを終了することを選択しました。

The overhead for one ANS frame is about thirty octets, once the initial handshakes have been exchanged. If this overhead is too high, then messages are likely being generated at a high rate. In this case, multiple syslog messages can be aggregated into a single ANS frame, each separated by a CRLF sequence from the preceding. The final message still MUST NOT end with a CRLF.

最初のハンドシェイクが交換された後1つのANSフレームのためのオーバーヘッドは、約30オクテットです。このオーバーヘッドが高すぎる場合は、メッセージがおそらく高いレートで生成されています。この場合、複数のsyslogメッセージは、それぞれが前のCRLFシーケンスによって分離された、単一ANSフレームに集約することができます。最後のメッセージはまだCRLFで終了することはできません。

For example,

例えば、

L: MSG 1 0 . 0 50 L: L: Central Services. This has not been a recording. L: END I: ANS 1 0 . 0 119 0 I: I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency. I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.END I: NUL 1 0 . 119 0 I: END

L：MSG 1 0。 0 50 L：L：中央サービス。これは記録されていません。 L：END I：ANS 1 0。 0 119 0 I：I：<29> 10月27日午後01時21分08秒配管のimxpd [141]：暖房緊急事態。 I：<29> 10月27日午前13時21分09秒配管のimxpd [141]：連絡先Tuttle.END I：NUL 1 0。 119 0 I：END

3.2 RAW Profile Identification and Initialization

3.2 RAWプロファイル識別および初期化

The RAW syslog profile is identified as

RAW syslogのプロファイルがあると同定され

http://xml.resource.org/profiles/syslog/RAW

ｈっｔｐ：／／ｘｍｌ。れそうｒせ。おｒｇ／ｐろふぃぇｓ／ｓｙｓぉｇ／らＷ

in the BEEP "profile" element during channel creation.

チャネルの作成中にBEEP「プロファイル」要素インチ

No data is piggybacked during channel creation.

何のデータは、チャネルの作成中にピギーバックされません。

3.3 RAW Profile Message Syntax

3.3 RAWプロファイルメッセージ構文

All BEEP messages in this profile have a MIME content-type of application/octet-stream. The listener's first BEEP message is ignored and indeed may be empty except for headers; hence, any syntax is acceptable.

このプロファイルのすべてのBEEPメッセージは、アプリケーション/オクテットストリームのMIMEコンテンツタイプを持っています。リスナーの最初のBEEPメッセージは無視され、実際のヘッダーを除いて空でもよいです。したがって、任意の構文は許容可能です。

The ANS replies the initiator sends in response MUST be formatted according to Section 4 of [1]. In particular, If the receiver is acting as a relay, then it MUST follow the rules as laid out in Section 4.2.2 of [1].

ANSは、イニシエータが、[1]のセクション4に従ってフォーマットされなければならない応じて送信する返信。受信機が中継として機能している場合、[1]のセクション4.2.2にレイアウトとして、特に、それはルールに従わなければなりません。

If multiple syslog messages are included in a single ANS reply, each is separated from the preceding with a CRLF. There is no ending delimiter, but each syslog event message body length MUST be 1024 bytes or less, excluding BEEP framing overhead. Note that there MUST NOT be a CRLF between the text of the final syslog event message and the "END" marking the trailer of the BEEP frame.

複数のsyslogメッセージが単一のANS応答に含まれている場合、それぞれがCRLFで先行から分離されます。そこには、終了区切り文字はありませんが、各syslogのイベントメッセージボディの長さはBEEPフレーミングオーバーヘッドを除く、1024バイト以下でなければなりません。 BEEPフレームのトレーラーをマーキング最終のsyslogイベントメッセージのテキストおよび「END」の間にCRLFがあってはならないことに注意してください。

3.4 RAW Profile Message Semantics

3.4 RAWプロファイルメッセージの意味

The listener's opening BEEP MSG message has no semantics. (It is a good place to put in an identifying greeting.) The initiator's ANS replies MUST specify a facility, severity, and textual message, as described in [1].

リスナーのオープニングBEEP MSGメッセージは何の意味を持っていません。（これは、特定のグリーティングに置くのに適した場所である。）[1]に記載のようにイニシエータのANSの応答が、施設、重症度、およびテキストメッセージを指定しなければなりません。

4. The COOKED Profile

4. COOKEDプロフィール

4.1 COOKED Profile Overview

4.1 COOKEDプロファイルの概要

The COOKED profile is designed for new implementations of syslog protocol handlers. It provides a much finer grain of information tagging, allowing a better degree of automation in processing. Naturally, it includes more overhead as well in support of this.

COOKEDプロファイルは、syslogプロトコルハンドラの新しい実装のために設計されています。これは、処理中自動化のより良い度をできるように、情報のタグ付けの非常に細かい結晶粒を提供します。当然、それはこれを支持しても同様に多くのオーバーヘッドが含まれています。

The COOKED profile supports three elements of interest:

COOKEDプロファイルは、関心のある三つの要素をサポートしています。

o The "iam" element identifies the sender to the receiver, allowing each peer to name itself for the other, and specifying the roles (device, relay, or collector) each is taking on.

O「IAM」要素は、それぞれが他のために自身の名前をピアできるように、受信機に送信者を識別し、それぞれが上で取ってロール（デバイス、リレー、又はコレクタ）を指定します。

o The "entry" element provides a parsed version of the syslog entry, with the various fields of interest broken out.

関心の様々な分野が出て壊れてO「エントリ」要素は、syslogのエントリの解析されたバージョンを提供します。

o The "path" element identifies a list of relays through which a tagged collection of "entry" elements has passed, along with a set of flags indicating what assurances of security have been in effect throughout its delivery.

O「パス」要素は、「エントリ」要素のタグ付けされたコレクションは、その送達を通して有効にされているセキュリティのどの保証示すフラグのセットと共に、通過したリレーのリストを識別する。

4.2 COOKED Profile Identification and Initialization

4.2 COOKEDプロファイル識別および初期化

The COOKED syslog profile is identified as

COOKED syslogのプロファイルは次のように識別されます

http://xml.resource.org/profiles/syslog/COOKED

ｈっｔｐ：／／ｘｍｌ。れそうｒせ。おｒｇ／ｐろふぃぇｓ／ｓｙｓぉｇ／こおけＤ

in the BEEP "profile" element during channel creation.

チャネルの作成中にBEEP「プロファイル」要素インチ

During channel creation, the corresponding "profile" element in the BEEP "start" element may contain an "iam" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "iam" element and includes the resulting response in the reply. This response will be an "ok" element or an "error" element. The choice of which element is returned is dependent on local provisioning of the recipient. Including an "iam" in the initial "start" element has exactly the same semantics as passing it as the first MSG message on the channel.

チャネルの作成時に、BEEP「スタート」要素で対応する「プロファイル」要素は、「IAM」元素を含んでいてもよいです。チャネルの作成が成功した場合、対応する応答を送信する前に、BEEPピアは、「IAM」要素を処理し、応答で得られた応答とを含みます。この応答は、「OK」要素または「エラー」の要素となります。要素が返されるの選択は、受信者のローカルプロビジョニングに依存しています。最初の「スタート」要素の「IAM」を含めると、チャネル上の最初のMSGメッセージとして渡すとまったく同じ意味を持っています。

4.3 COOKED Profile Message Syntax

4.3 COOKEDプロフィールメッセージの構文

All BEEP messages in this profile have a MIME Content-Type [6] of application/beep+xml. The syntax of the individual elements is specified in Section 7.

このプロファイルのすべてのBEEPメッセージは、MIMEのContent-Typeを持っている[6]アプリケーション/ビープ音+ XMLの。個々の要素の構文はセクション7で指定されています。

4.4 COOKED Profile Message Semantics

4.4 COOKEDプロフィールメッセージセマンティクス

Initiators issue two elements: "iam" and "entry", each using a "MSG" message. The listener issues "ok" in "RPY" messages and "error" in "ERR" messages. (See [3]'s Section 2.3.1 for the definitions of the "error" and "ok" elements.)

イニシエータ問題の二つの要素：「IAM」と「エントリー」、「MSG」メッセージを使用して、各。「RPY」メッセージと「ERR」のメッセージに「エラー」で「OK」リスナーの問題。（『エラー』の定義と『OK』要素について[3]のセクション2.3.1を参照）。

4.4.1 The IAM Element

IAM要素は、4.4.1

The "iam" element serves to identify a device, relay, or collector at one end of the BEEP channel to the device, relay, or collector at the other end of the channel. The "iam" element includes the type of peer (device, relay, or collector), the fully qualified domain name of the peer, and an IP address of the peer. (The IP address chosen SHOULD be the IP address associated with the underlying transport protocol carrying the channel.) The character data of the element is free-form human-readable text. It may be used to further identify the peer, such as by describing the physical location of the machine.

「IAM」要素は、チャネルの他端にデバイス、リレー、又はコレクタにBEEPチャネルの一端にデバイス、リレー、又はコレクタを識別するのに役立ちます。「IAM」要素は、ピアのタイプ（デバイス、リレー、又はコレクタ）、ピアの完全修飾ドメイン名、及びピアのIPアドレスを含みます。（選択されたIPアドレスは、チャネルを搬送する基礎となるトランスポートプロトコルに関連付けられたIPアドレスでなければなりません。）素子の文字データは、自由形式の人間可読テキストです。そのような機械の物理的な位置を記述することなどによって、更なるピアを識別するために使用され得ます。

An "iam" element may be sent by the initiator of the channel at any time. The listener responds to an "iam" element with an "ok" (indicating acceptance), or an "error" (indicating rejection). The identity and role in effect is specified by the most recent "iam" answered with an "ok".

「IAM」要素は、任意の時点でチャネルのイニシエータによって送信されてもよいです。リスナーは、「OK」（指示受付）と「IAM」要素に応答する、又は「エラー」（拒否を示します）。効果におけるアイデンティティと役割は、最新の「IAM」「OK」との答えによって指定されます。

An "iam" could be rejected (with an "error" element) by the listener if the privacy or authentication that has been negotiated is inadequate or if the authenticated user does not have authorization to serve in the specified role. It is expected that most installations will require an "iam" from the peer before accepting any "entry" messages.

「IAM」で交渉されたプライバシーや認証が不十分である場合には、リスナーによって（「エラー」の要素を）拒否したりすることができ、認証されたユーザーは、指定されたロールに奉仕する権限を持っていない場合。ほとんどのインストールは任意の「エントリー」のメッセージを受け入れる前に、ピアから「IAM」が必要になることが期待されます。

For example, a successful creation might look like this:

例えば、正常な作成は次のようになります。

I: MSG 0 10 . 1832 259 I: Content-type: application/beep+xml I: I: <start number='1'> I: <profile I: uri='http://xml.resource.org/profiles/syslog/COOKED'> I: <![CDATA[ <iam fqdn='lowry.example.com' ip='10.0.0.27' I: type='device'/> ]]> I: </profile> I: </start> L: END L: RPY 0 10 . 704 138 L: Content-type: application/beep+xml L: L: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'> L: <![CDATA[ <ok /> ]]> L: </profile> L: END

I：MSG 0 10。 1832 259 I：コンテンツタイプ：アプリケーション/ビープ音+ xmlのは、I：I：<開始番号= '1'>私は<私のプロフィール：URI = 'はhttp：//xml.resource.org/profiles/syslog/COOKED' > I：<！[CDATA [<IAM FQDN = 'lowry.example.comのIP = '10 .0.0.27' I：タイプ= 'デバイス'/>]]> I：</プロフィール> I </スタート> L：ENDのL：RPY 0 10。 704 138 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<プロファイルのuri = 'のhttp：//xml.resource.org/profiles/syslog/COOKED'> L <！[CDATA [<OK /> ]]> L </プロフィール> L：END

A creation with an embedded "iam" that fails might look like this:

このようになります失敗埋め込ま「IAM」で作成：

C: MSG 0 12 . 1832 259 C: Content-type: application/beep+xml C: C: <start number='1'> C: <profile C: uri='http://xml.resource.org/profiles/syslog/COOKED'> C: <![CDATA[ <iam fqdn='tuttle.example.com' ip='10.0.0.29' C: type='relay'/> ]]> C: </profile> C: </start> C: END S: RPY 0 12 . 704 241 S: Content-type: application/beep+xml S: S: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'> S: <![CDATA[ S: <error code='535'>User 'buttle.example.com' not allowed S: to "iam" for 'tuttle.example.com'</error> ]]> S: </profile> S: END

C：MSG 0 12。 1832 259 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<開始番号= '1'> C <プロフィールC：URI = 'HTTP：//xml.resource.org/profiles/syslog/COOKED' > C：<！[CDATA [<IAM FQDN = 'tuttle.example.comのIP = '10 .0.0.29' C：タイプ= 'リレー'/>]]> C：</プロフィール> C：</スタート> C：END S：RPY 0 12。 704 241 S：コンテンツタイプ：アプリケーション/ビープ音+のxml S：S：<プロファイルのuri = 'のhttp：//xml.resource.org/profiles/syslog/COOKED'> S：<[CDATA [S：！<エラーコード= '535'>ユーザー 'buttle.example.com' 許可されていないS：に "IAM" のための 'tuttle.example.com' </エラー>]]> S </プロフィール> S：END

In this case, the error code indicates that the user "buttle.example.com" has logged in via some SASL profile, but the syslog COOKED profile implementation is claiming to be "tuttle.example.com", a mismatch that the server is disallowing.

この場合、エラーコードは、ユーザー「buttle.example.comは」いくつかのSASLプロファイル経由でログインしているが、syslogのCOOKEDプロファイルの実装は、「tuttle.example.com」であると主張されていることをサーバーがある不一致を示し許可しません。

4.4.2 The ENTRY Element

ENTRY要素は、4.4.2

The "entry" element carries the details of a single syslog entry. The attributes of an "entry" element include "facility", "severity", "timestamp", "hostname", and "tag". "Facility" and "severity" have the semantics defined in [1]'s 4.1. The other attributes have the semantics as in Sections 4.2.1 and 4.2.3 of [1]. An "entry" element can also contain a "pathID" attribute, described below.

「エントリ」の要素は、単一のsyslogエントリの詳細を運びます。「エントリ」要素の属性は、「施設」、「重要度」、「タイムスタンプ」、「ホスト名」、および「タグ」が含まれます。「施設」および「重症度」は、[1]の4.1で定義された意味を有します。他の属性は、セクション4.2.1と[1]の4.2.3のような意味を有しています。「エントリ」の要素は、以下で説明する「PATHID」属性を含めることができます。

If the client is a relay, the "entry" SHOULD also contain the attributes "deviceFQDN" and "deviceIP", specifying the FQDN and IP address of the device that originally created the entry. These attributes may be added by either the relay or the originating device. If possible, the device SHOULD add these entries, referring to the interface most closely associated with the syslog entry. Before a relay forwards an entry from a device that does not carry these attributes, it SHOULD add them based on the "iam" element it has received from the device, or based on the underlying transport connection address. A relay MUST NOT add these fields if they are missing and an "iam" element on the channel has indicated that messages are coming from another relay.

クライアントがリレーの場合は、「エントリ」も、もともとのエントリを作成したデバイスのFQDNとIPアドレスを指定して、属性「deviceFQDN」と「deviceIP」を含むべきです。これらの属性は、リレーや発信側デバイスのいずれかによって添加することができます。可能な場合、デバイスは最も密接にsyslogのエントリに関連付けられたインターフェイスを参照して、これらのエントリを追加する必要があります。リレーは、これらの属性を有していないデバイスからの入力を転送する前に、それがデバイスから受信、または基礎となるトランスポート接続アドレスに基づいた「IAM」の要素に基づいて、それらを追加する必要があります。彼らが不足しているとチャンネルの「IAM」の要素がメッセージを他の中継から来ていることを示した場合、リレーは、これらのフィールドを追加してはなりません。

The "pathID" attribute indicates the path over which this entry has travelled, from device through relays to the final collector. Syntactically, its value is a string of digits that must match the "pathID" attribute of a "path" element sent earlier over the current channel. Semantically, it indicates that the list of relays and flags indicated in that earlier "path" element apply to this "entry" element.

「PATHID」属性は、このエントリが最終コレクタにリレーを介してデバイスから、走行した経路上を示します。構文的には、その値は、現在のチャネルを介して送信される以前の「パス」要素の「PATHID」属性と一致しなければなりません数字の文字列です。意味的には、その先に「パス」要素に示されているリレーやフラグのリストは、この「エントリ」の要素に適用することを示しています。

The character data for the element is the unstructured syslog event message being logged. If the original device delivers the message for the first time via the COOKED profile, it may have any structure inside the CDATA. However, for maximum compatibility, the device SHOULD format the CDATA of the message in accordance with Sections 4.2.1 through 4.2.3 of [1].

要素の文字データが記録されている非構造化のsyslogイベントメッセージです。元のデバイス調理プロファイルを介して第1の時間にメッセージを配信する場合は、CDATA内の任意の構造を有していてもよいです。しかし、最大の互換性のために、デバイスは、[1]の4.2.3を介してセクション4.2.1に従ってメッセージのCDATAをフォーマットすべきです。

In the message is being relayed, "tag" SHOULD be those of the original device generating the entry (unless the device cannot supply a tag). The "timestamp" SHOULD be that of the original entry generation time, rather than the time the entry was passed outward from the relay. The "hostname" SHOULD be the host name or IP address by which the device knows itself; this MUST follow the rules established in Sections 4.2.1 through 4.2.3 of [1]. The original contents of the syslog message MUST be preserved in the CDATA of the "entry" element; this includes preservation of exact content during translation from the UDP or RAW formats. In particular, the timestamps MUST NOT be rewritten in the CDATA of the "entry" element, the tag MUST NOT be removed from the CDATA even if presented in the "entry" attributes as well, and so on.

（デバイスがタグを供給できない場合を除き）メッセージが中継されて、「タグ」に元のデバイスエントリを生成するものであるべきです。「タイムスタンプ」とは、むしろエントリがリレーから外側に渡された時間よりも、元エントリ生成時間のであるべきです。「ホスト名は」デバイスが自分自身を知っていることにより、ホスト名またはIPアドレスでなければなりません。これは、4.2.1の[1]の4.2.3節に確立された規則に従わなければなりません。シスログメッセージの元の内容は、「エントリ」要素のCDATAに保存されなければなりません。これは、UDPまたはRAWフォーマットからの変換時に正確な内容の保存を含んでいます。タイムスタンプは、「エントリ」要素のCDATAに書き換えてはいけません、特に、タグは、「エントリ」で提示てもCDATAから除去されない必要があるようにも属性、および。

To be consistent with the spirit of [1], a relay receiving a message that does not contain a valid priority, timestamp or hostname will follow the same general rules as described in section 4.2.2 of [1] while including the exact contents of the received syslog packet as the CDATA. The values of the facility and severity will be construed to be 8 and 6 respectively and will be placed into the appropriate attributes of the "entry" element. The hostname will be the name of the device as it is known to the relay and will also be inserted into the "entry" element's attributes. The timestamp would be set to the received time, inserted only into the attributes of the "entry" element. As an example, consider this message received on UDP port 514 and interpreted as a traditional syslog message, assuming the underlying IP source address is that of the "pipeworks" machine:

、[1]の正確な内容を含めてのセクション4.2.2に記載したように、有効な優先順位、タイムスタンプまたはホスト名が同じ一般的なルールに従うが含まれていないメッセージを受信した中継[1]の精神と一致するようにCDATAとして受け取ったsyslogパケット。施設及び重症度の値は、それぞれ8および6であると解釈され、「エントリ」要素の適切な属性の中に配置されます。ホスト名は、それがリレーに知られており、また、「エントリ」要素の属性に挿入されるように、デバイスの名前になります。タイムスタンプは、「エントリ」要素の属性に挿入され、受信された時刻に設定されることになります。一例として、このメッセージは、基礎となるIP送信元アドレスが「pipeworks」マシンの場合であると仮定すると、UDPポート514で受信され、従来のsyslogメッセージとして解釈考えます。

<.....eeeek!

<..... EDYVI！

To be relayed, it must be modified as follows:

次のように中継されるためには、それが修正されなければなりません。

         C: MSG 1 0 . 2079 156
         C: Content-Type: application/beep+xml
         C:
         C: <entry facility='8' severity='6'
         C:   hostname='pipeworks'
         C:   timestamp='Oct 31 23:59:59'
         C:  >&lt;.....eeeek!</entry>
         C: END
         S: RPY 1 0 . 933 45
         S: Content-Type: application/beep+xml
         S:
         S: <ok/>
         S: END

As another example, consider a message being received that does not properly adhere to the conventions described in Section 4.2.2 of [1]. In particular, the timestamp has a year, making it a nonstandard format:

別の例として、適切に[1]のセクション4.2.2に記載の規則に付着していない受信されたメッセージを検討します。特に、タイムスタンプは、非標準フォーマット作り、年があります。

<166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!

<166> 1990年10月22日午前1時○○分00秒爆弾ティック[0]：BOOM！

This would be relayed as follows:

これは次のように中継されます：

         C: MSG 1 0 . 2235 242
         C: Content-Type: application/beep+xml
         C:
         C: <entry facility='160' severity='6'
         C:   hostname='bomb'
         C:   deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
         C:   timestamp='Oct 22 01:00:04'
         C:  >&lt;166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
         C: END
         S: RPY 1 0 . 978 45
         S: Content-Type: application/beep+xml
         S:
         S: <ok/>
         S: END

Note that the tag value was not readily apparent from the received message (due to the failed parsing of the timestamp), so it was not included in the "entry" element.

タグ値が（これは、タイムスタンプの失敗解析に）受信したメッセージから容易に明らかではなかったので、それは「エントリ」要素に含まれていなかったことに留意されたいです。

It is explicitly permitted for a relay to parse raw messages in a more sophisticated way, but all implementations MUST be able to parse messages presented in the format described in [1]. A more sophisticated relay could have recognized the year and completely parsed out the correct time, tag, and hostname, but such additional parsing capability is OPTIONAL.

これは、明示的に、より洗練された方法で生のメッセージを解析するための中継のために許可されているが、すべての実装は、[1]に記載のフォーマットで提示メッセージを解析できなければなりません。より洗練されたリレーは年間認識され、完全に正しい時間、タグ、およびホスト名を解析されたが、そのような追加的な解析機能は、オプションであるかもしれません。

Consider the following example, in contrast:

対照的に、次の例を考えてみます。

<166> Oct 22 01:00:00 bomb tick[0]: BOOM!

<166> 10月22日1時00分○○秒爆弾ティック[0]：BOOM！

This conformant message would be relayed as follows:

以下のように、この準拠のメッセージを中継することになります。

         C: MSG 1 0 . 2477 248
         C: Content-Type: application/beep+xml
         C:
         C: <entry facility='160' severity='6'
         C:   hostname='bomb'
         C:   deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
         C:   timestamp='Oct 22 01:00:00' tag='tick'
         C:  >&lt;166> Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
         C: END
         S: RPY 1 0 . 1023 45
         S: Content-Type: application/beep+xml
         S:
         S: <ok/>
         S: END

In this case, the tag is detected and the timestamp represents the message generation time rather than the message reception time.

この場合には、タグが検出され、タイムスタンプは、メッセージ生成時ではなく、メッセージ受信時間を表しています。

Finally, the "entry" element may also contain an "xml:lang" attribute, indicating the language in which the CDATA content of the tag is presented, as described in [7].

〔7〕に記載されているように、タグのCDATAコンテンツが提示されている言語を示す属性：最後に、「エントリ」要素は、「langのXML」を含んでいてもよいです。

The "entry" element is answered with either an empty "ok" element if everything was successful, or a standard "error" element if there was a problem. An "entry" element can be rejected if no "iam" element has been accepted by the listener. It can also be rejected if the user authenticated on the BEEP session (if any) does not have the authority to generate (as a device) or relay that entry. An error is also possible if the "pathID" attribute refers to an unknown (or rejected) "path" element.

問題があった場合、「エントリ」の要素は、すべてが成功した場合は、空の「OK」要素のいずれかで答え、または標準の「エラー」の要素です。何の「IAM」要素は、リスナーによって受け入れられていない場合は、「エントリ」の要素は拒否することができます。 BEEPセッションに認証されたユーザは、（もしあれば）（デバイスなど）を生成する権限を持っているか、そのエントリを中継しない場合にも拒否することができます。「PATHID」属性が不明（または拒否）「パス」の要素を参照する場合、エラーも可能です。

A successful exchange of an "entry" element may look like this:

「エントリ」要素の成功の交換は、次のようになります。

C: MSG 1 0 . 2725 173 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' C: timestamp='Jan 26 15:16:17' C: hostname='pipework' tag='imxp'> C: No 27B/6 available</entry> C: END S: RPY 1 0 . 1068 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END

C：MSG 1 0。 2725 173 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<エントリ施設= '24' 重症度= '5' C：タイムスタンプ= '1月26日15時16分17秒' C：ホスト名= '配管' タグ= 'imxp'> C：なし27B / 6 </エントリ> C：ENDのS：RPY 1 0。 1068年45 S：コンテンツタイプ：アプリケーション/ビープ音+のxml S：S：<OK /> S：END

Here, the device IP address and FQDN are taken from the "iam" element, if any, or from the underlying connection information.

ここでは、デバイスのIPアドレスとFQDNが存在する場合、または基になる接続情報から、「IAM」要素から取得されます。

An example where an "entry" element is rejected with an "error" element:

「エントリ」要素が「エラー」の要素で拒否された例：

C: MSG 1 2 . 2898 223 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' timestamp='Jan 02 13:22:15' C: deviceFQDN='jack.example.net' deviceIP='10.0.0.83' C: tag='imxpd'> C: Replacement device found in nostril. C: </entry> C: END S: ERR 1 2 . 1113 111 S: Content-Type: application/beep+xml S: S: <error code='554'>Not allowed to relay for S: jack.example.net</error> S: END

C：MSG 1 2。 2898 223 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<エントリが施設= '24' 重症度= '5' のタイムスタンプ= '1月2日夜01時22分15秒' C：deviceFQDN = 'jack.example.net 'deviceIP = '10 .0.0.83' C：タグ= 'imxpd'> C：鼻孔に見出さ交換装置。 C：</エントリ> C：ENDのS：1 2 ERR。 1113 111 S：コンテンツタイプ：アプリケーション/ビープ+ XMLのS：S：<エラーコード= '554'> Sリレーを許可されていない：jack.example.net </エラー> S：END

Here, the client attempts to relay an entry on behalf of jack.example.com, but the entry is refused by the collector for administrative reasons. This may occur, for example, if lowry.example.com is in a different department than jack.example.com.

ここでは、クライアントはjack.example.comの代わりにエントリを中継しようとしますが、エントリが管理上の理由のためにコレクタによって拒否されます。 lowry.example.comがjack.example.com異なる部門である場合、これは、例えば、起こり得ます。

4.4.3 The PATH Element

パス要素を4.4.3

The "path" element serves to describe a list of the relays through which that element has passed, along with a set of flags that indicate the properties that all links from the device to the relay have shared in common. Each "path" element contains either another "path" element or is empty. An empty "path" element identifies a device, while a "path" element with a nested "path" element identifies a relay. Each "path" element names a FQDN and IP address of the interface that sent the element. Each "path" element also names a FQDN and IP address for the interface that received the element. Each "path" element also carries a "linkprops" attribute, specifying the properties of the link it describes.

「パス」要素は、リレーのデバイスからすべてのリンクが共通に共有している特性を示すフラグのセットと一緒に、その要素が通過したリレーのリストを記述するのに役立ちます。各「パス」の要素は、別の「パス」要素のいずれかが含まれているか、空です。ネストされた「パス」要素と「パス」要素は、リレーを識別しながら、空の「パス」要素は、デバイスを識別する。各「パス」要素名の要素を送られたインターフェースのFQDNとIPアドレス。また、各「パス」の要素は、名前の要素を受信したインターフェイスのためのFQDNとIPアドレスを。各「パス」要素はまた、説明のリンクのプロパティを指定し、「linkprops」属性を運びます。

Each "path" element has a "pathID" attribute which must be unique for all "path" elements sent on this channel since its inception. Syntactically, the "pathID" attribute is a string of digits. Semantically, it serves to identify one "path" element out of many, and it serves to link a "path" element with one or more "entry" elements. Any "pathID" attribute is unrelated to any "pathID" attribute in nested "path" elements or on other channels.

各「パス」の要素は、創業以来、このチャネルで送信されたすべての「パス」の要素に対して一意でなければなりません「PATHID」属性を持っています。構文的には、「PATHID」属性は、数字の文字列です。意味的に、それは多くのうちの一つの「パス」の要素を識別するためのものであり、それは1つまたは複数の「エントリ」要素と「パス」要素をリンクするのに役立ちます。どれ「PATHID」属性は、ネストされた「パス」の要素や他のチャネル上で任意の「PATHID」属性とは関係ありません。

Each "path" element has a "fromFQDN" attribute and an "fromIP" attribute. The "fromFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was sent. (The "fromFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "fromIP" attribute MUST be the IP address of the interface over which the "path" element was sent.

各「パス」の要素は、「fromFQDN」属性と「fromIP」属性を持っています。「fromFQDN」属性は、「パス」の要素が送られた先のインターフェースの完全修飾ドメイン名である必要があります。（そのインターフェイスがないDNSエントリがない場合、「fromFQDN」は省略することができる。）同様に、「fromIP」属性は、「パス」要素が送られた先のインターフェイスのIPアドレスでなければなりません。

Each "path" element has a "toFQDN" attribute and an "toIP" attribute. The "toFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was received. (The "toFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "toIP" attribute MUST be the IP address of the interface over which the "path" element was received.

各「パス」の要素は、「toFQDN」属性と「TOIP」属性を持っています。「toFQDN」属性は、「パス」の要素が受信された上でのインタフェースの完全修飾ドメイン名である必要があります。（そのインターフェイスがないDNSエントリがない場合、「toFQDN」は省略することができる。）同様に、「TOIP」属性が「パス」要素を受信した上インターフェイスのIPアドレスでなければなりません。

Finally, each "path" element carries a "linkprops" attribute. This is syntactically a string of individual characters, each indicating one property of the channel over which this "path" element is being carried. Note that outer "path" elements may have stronger guarantees than inner "path" elements; care should be taken in the interpretation of flags. The semantics of each possible character in this string are as follows: o: When present, "o" (lower-case letter "o") indicates that weak privacy has been negotiated over this link, weakly protecting from observation the content of entries associated with this "path" element. (Weak privacy is encryption with less than 80 bits of key.)

最後に、それぞれの「パス」の要素は、「linkprops」属性を運びます。これは、構文的に個々の文字列は、この「パス」要素が実施されている上にチャネルの各々示す1つの特性です。外側の「パス」要素は、内側「パス」要素より強い保証を有していてもよいことに留意されたいです。ケアは、フラグの解釈に注意が必要です。次のようにこのストリングにおけるそれぞれの可能な文字の意味は次のとおりO：存在する場合には、「O」（小文字の文字「O」）が弱く観察からの関連するエントリの内容を保護し、弱いプライバシーこのリンクを介してネゴシエートされたことを示しこの「パス」の要素を持ちます。（弱いプライバシーはキー未満の80ビットの暗号化です。）

O: When present, "O" (upper-case letter "O") indicates that strong privacy has been negotiated over this link, strongly protecting from observation the content of entries associated with this "path" element. (Strong privacy is encryption with 80 bits or more of key, or a transfer mechanism that is otherwise impossible to eavesdrop upon.)

O：存在する場合、「O」（大文字「O」）は、強力なプライバシーが強く観測から、この「パス」要素に関連付けられたエントリの内容を保護し、このリンクを介して交渉されたことを示しています。（強いプライバシーは80ビット以上のキー、または時に盗聴すること、さもなければ不可能である搬送機構と暗号化です。）

U: When present, "U" indicates that a valid user has been authenticated (via SASL or TLS) and an "iam" element has been accepted.

U：存在する場合、「U」は、有効なユーザが（SASLまたはTLSを介して）認証されており、「IAM」要素が受け入れられたことを示しています。

A: When present, "A" indicates that this link has been protected by an authentication layer, authenticating the source of every "entry" associated with this path.

A：存在する場合、「」このリンクは、このパスに関連付けられたすべての「エントリ」のソースを認証する、認証層によって保護されていることを示しています。

R: When present, "R" indicates that this link has been protected against message replay.

R：存在する場合、「R」は、このリンクは、メッセージのリプレイから保護されていることを示しています。

I: When present, "I" indicates that this link has been protected against modifications of messages in passing. ("I" stands for message Integrity.)

I：「私は」このリンクは合格で、メッセージの変更から保護されていることを示している存在。（「私は、」メッセージの整合性を表します。）

L: When present, "L" indicates that this link has been protected against loss of messages. That is, this is a reliable delivery link.

L：存在する場合、「L」は、このリンクは、メッセージの損失から保護されていることを示しています。つまり、これは信頼性の高い配信のリンクです。

D: When present, "D" indicates that the "from" side of this link is a device. If this is not present on the innermost "path" element, "entry" elements associated with this path have not been carried by the COOKED profile for their entire lifetime.

D：現在、「D」は、このリンクの「から」側の装置であることを示す場合。これは、最も内側の「パス」要素上に存在しない場合、このパスに関連する「エントリ」の要素は、それらの全体寿命調理プロファイルによって行われていません。

Upon receiving a "path" element, the peer MUST perform the following checks:

「パス」要素を受信すると、ピアは次のチェックを実行する必要があります。

o The "fromFQDN" and "fromIP" must match the underlying transport connection.

「fromFQDN」と「fromIP」O基礎となるトランスポート接続と一致する必要があります。

o The flags in the "linkprops" attribute must match the attributes of the session.

O「linkprops」属性のフラグは、セッションの属性と一致する必要があります。

o The "toFQDN" and "toIP" must match the underlying transport connection.

O「toFQDN」と「TOIPは」基礎となるトランスポート接続と一致する必要があります。

o The "pathID" attribute must be unique with respect to all other "path" elements received on this channel.

O「PATHID」属性は、このチャネルで受信した他のすべての「パス」の要素に対して一意でなければなりません。

If all these checks pass, the "path" element is accepted with an "ok" element. Otherwise, an "error" element is generated with an appropriate code. In addition, if any of the nested "path" elements refer to the machine receiving the element, it may indicate a routing loop in the configuration for the so-identified path, and appropriate measures should be taken.

すべてのこれらのチェックに合格した場合は、「パス」要素は、「OK」要素で受け入れられています。そうでなければ、「エラー」要素は、適切なコードを生成します。ネストされた「パス」要素のいずれかは、受光素子マシンを参照する場合に加えて、それはそのように識別されたパスの構成にルーティングループを示してもよいし、適切な措置が取られるべきです。

If the peer receiving an "entry" element is receiving it directly from a device via either syslog-conn profile, and the device has not generated a "path" element, the receiver may itself generate an appropriate "path" element, either to be recorded in the logs (if this peer is a collector) or passed to the next peer (if this peer is a relay). If a peer receives a syslog message via UDP, it may optionally generate an appropriate "peer" element based on any cryptographic information provided in the message itself.

「エントリ」要素を受信するピアはSYSLOG-CONNプロファイルのいずれかを介してデバイスから直接受信され、デバイスが「パス」要素を生成していない場合、受信機は、それ自体のいずれかであることが、適切な「パス」要素を生成することができますログに記録されている（このピアがコレクタである場合）、または次のピアに渡す（このピアが中継である場合）。ピアがUDPを介してシステムログメッセージを受信した場合、それは、必要に応じて、メッセージ自体に提供される任意の暗号情報に基づいて、適切な「ピア」要素を生成することができます。

When a peer receives a "path" element, it remembers it for future use. A collector will store it in the log for later reference. A relay will remember it. When an "entry" arrives referencing the received "path" element, and that entry needs to be forwarded to another relay or collector, and no appropriate "path" element has already been generated, an appropriate "path" element is generated and sent over the outbound channel before the entry is forwarded. An appropriate "path" element is created by taking the received "path" element, wrapping it in a new "path" element with the appropriate attributes, and assigning it a new "pathID" attribute. When future "entry" elements arrive with the same incoming "pathID" attribute, and they need to be forwarded to a channel over which an appropriate "pathID" attribute has already been sent, only the "pathID" attribute of the "entry" element needs to be rewritten to refer to the "path" element on the outgoing channel.

ピアは、「パス」の要素を受信すると、それは将来の使用のためにそれを覚えています。コレクタは、後で参照するためにログに格納されます。リレーはそれを覚えています。「エントリ」は、受信した「パス」要素を参照到達し、そのエントリが別のリレーまたはコレクターに転送する必要があり、いかなる適切な「パス」要素がすでに生成されていない、適切な「パス」要素が生成され、上に送信された場合エントリの前にアウトバウンドチャネルが転送されます。適切な「パス」要素は、受信した「パス」の要素を取って適切な属性を持つ新しい「パス」要素でラップし、それを新しい「PATHID」属性を割り当てることによって作成されます。将来の「エントリ」の要素は、同じ着信「PATHID」属性に到着し、それらが適切な「PATHID」属性が既に送信されたチャネル上に、唯一の「PATHID」「エントリ」要素の属性に転送する必要がある場合出力チャネル上で「パス」の要素を参照するように書き換える必要があります。

It should be noted that the majority of the complexity in managing "path" elements arises only in relays. In particular, devices never need to generate "path" elements and collectors need only verify them, log them, and possibly use them in displays and reports. Collectors do not need to generate "path" elements or rewrite "entry" elements. Hence, only in complex configurations (where they are most useful) do complex "path" configurations occur.

「パス」の要素を管理する際の複雑さの大半は、リレーでのみ発生することに留意すべきです。具体的には、「パス」の要素やコレクターを生成する必要はありませんデバイスは、それらを検証し、それらをログに記録し、そしておそらくディスプレイやレポートでそれらを使用する必要があります。コレクターは、「エントリ」の要素「パス」の要素や書き換えを生成する必要はありません。したがって、唯一の（彼らが最も便利です）複雑な構成では、複雑な「パス」構成が発生します。

For example, here is a path element sent from lowry.records.example.com to kurtzman.records.example.com. It indicates that entries from lowry to kurtzman tagged with pathID='173' originated from screen.lowry.records.example.com. It indicates that screen.lowry.records.example.com is believed by lowry.records.example.com to be the originating device, and that entries over this path are delivered without loss and without modification, although messages might be replayed or observed. The link between lowry and kurtzman, however, avoids replay attacks, lost messages, and modifications to messages. While screen.lowry.records.example.com has not authenticated itself to lowry.records.example.com, lowry claims to have authenticated itself to kurtzman.

例えば、ここにkurtzman.records.example.comにlowry.records.example.comから送られたパス要素です。それはローリーからkurtzmanへのエントリーは=「173」のscreen.lowry.records.example.com由来PATHIDでタグ付けされたことを示しています。メッセージが再生または観察されるかもしれないが、それはscreen.lowry.records.example.comが発信デバイスであるとlowry.records.example.comによって考えられていることを示しており、この経路上のエントリが損失することなく、変更なしに送達されます。ローリーとkurtzman間のリンクは、しかし、リプレイ攻撃、失われたメッセージ、およびメッセージの変更を回避することができます。 screen.lowry.records.example.comはlowry.records.example.com、ローリーに自分自身を認証されなかったがkurtzmanに自分自身を認証したと主張。

C: MSG 2 1 . 3121 426 C: Content-type: application/beep+xml C: C: <path fromFQDN='lowry.records.example.com' C: fromIP='10.0.0.50' C: toFQDN='kurtzman.records.example.com' C: toIP='10.0.0.51' C: linkprops='ULRI' C: pathID='173'> C: <path fromFQDN='screen.lowry.records.example.com' C: fromIP='10.0.0.47' C: toFQDN='lowry.records.example.com' C: toIP='10.0.0.50' C: linkprops='DLI' C: pathID='24'> C: </path> C: </path> C: END S: ERR 2 1 . 1224 114 S: Content-type: application/beep+xml S: S: <error code='530'>linkprops includes 'U' S: but no 'iam' received</error> S: END

C：MSG 2 1。 3121 426 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<パスfromFQDN = 'lowry.records.example.com' C：fromIP = '10 .0.0.50' C：toFQDN = 'kurtzman.records.example。 COM」C：TOIP = '10 .0.0.51' C：linkpropsの= 'ULRI' C：PATHID = '173'> C <パスfromFQDN = 'screen.lowry.records.example.com' C：fromIP = '10 .0。 0.47' C：toFQDNは= 'lowry.records.example.com' C：TOIP = '10 .0.0.50' C：PATHID = '24' > C：</パス> C </パス= 'DLI' C linkprops > C：エンドS：ERR 2 1。 1224 114 S：コンテンツタイプ：アプリケーション/ビープ+ XML S：S：<エラーコード= '530'> linkpropsは 'U' Sを含む：がない 'IAM' は受信</エラー> S：END

However, kurtzman.records.example.com rejects the "path" element, since the "linkprops" attribute claims that lowry has authenticated itself, but kurtzman disagrees, not having received an "iam" element.

「linkprops」属性は、ローリーは自身を認証したと主張するが、kurtzmanが一致しない、「IAM」要素を受信していないので、kurtzman.records.example.comは、「パス」要素を拒否します。

In a second example, this "path" element informs collector.example.com that the records department's firewall will be forwarding "entry" elements with a "pathID" attribute whose value is "17". These "entry" elements will be coming in on the "10.0.0.2" interface of the firewall, to be forwarded out the "134.130.74.56" interface of the firewall. The final hop has all possible guarantees, although the entries transferred within the records department (behind the firewall) may have been observed in passing.

2番目の例では、この「パス」の要素は、レコード部門のファイアウォールは、値「17」である「PATHID」属性を持つ「エントリ」の要素を転送されることをcollector.example.com知らせます。これらの「エントリ」の要素がファイアウォールの「134.130.74.56」のインターフェイスを転送する、ファイアウォールの「10.0.0.2」のインターフェイスに着信します。（ファイアウォールの背後）レコード部門内で転送エントリが通過中で観察されているかもしれないが、最終的なホップは、可能なすべての保証を持っています。

C: MSG 2 2 . 3547 813 C: Content-type: application/beep+xml C: C: <path fromFQDN='fwall.records.example.com' C: fromIP='134.130.74.56' C: toFQDN='collector.example.com' C: toIP='134.130.74.12' C: linkprops='OUARIL' C: pathID='17'> C: <path fromFQDN='kurtzman.records.example.com' C: fromIP='10.0.0.50' C: toFQDN='fwall.records.example.com' C: toIP='10.0.0.2' C: linkprops='ULRI' C: pathID='120'> C: <path fromFQDN='lowry.records.example.com' C: fromIP='10.0.0.50' C: toFQDN='kurtzman.records.example.com' C: toIP='10.0.0.51' C: linkprops='ULRI' C: pathID='173'> C: <path fromFQDN='screen.lowry.records.example.com' C: fromIP='10.0.0.47' C: toFQDN='lowry.records.example.com' C: toIP='10.0.0.50' C: linkprops='DLI' C: pathID='24'> C: </path></path></path></path> C: END S: RPY 2 2 . 1338 45 S: Content-type: application/beep+xml S: S: <ok/> S: END

C：MSG 2 2。 3547 813 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<パスfromFQDN = 'fwall.records.example.com' C：fromIP = '134.130.74.56' C：toFQDN = 'collector.example.com' C：TOIP = '134.130.74.12' C：linkpropsの= 'OUARIL' C：PATHID = '17 '> C <パスfromFQDN =' kurtzman.records.example.com」C：fromIP = '10 .0.0.50' C： toFQDNは= 'fwall.records.example.com' C：TOIP = '10 .0.0.2' C：linkpropsの= 'ULRI' C：PATHID = '120'> C <パスfromFQDN = 'lowry.records.example.com' C：fromIPは= '10 .0.0.50' C：toFQDN = 'kurtzman.records.example.com' C：TOIP = '10 .0.0.51' C：linkpropsの= 'ULRI' C：PATHID = '173'> C <パスfromFQDN = 'screen.lowry.records.example.com' C：fromIPは= '10 .0.0.47' C：toFQDNは= 'lowry.records.example.com' C：TOIP = '10 .0.0.50' C：= 'DLI linkprops 'C：PATHID = '24'> C </パス> </ path>の</パス> </パス> C：ENDのS：RPY 2 2。 1338年45 S：コンテンツタイプ：アプリケーション/ビープ音+のxml S：S：<OK /> S：END

As a final example, an "entry" element from Lowry's screen arrives at the firewall. The "path" attribute is rewritten, and it is forwarded on to the collector.

最後の例として、ローリーの画面から「エントリー」の要素は、ファイアウォールに到着します。「パス」属性が書き換えられ、それはコレクターに転送されます。

The entry arrives on the 10.0.0.2 interface:

エントリは10.0.0.2インターフェイスに到着しました。

C: MSG 2 3 . 4360 250 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' C: timestamp='Oct 27 13:24:12' C: deviceFQDN='screen.lowry.records.example.com' C: deviceIP='10.0.0.47' C: pathID='173' C: tag='dvd'> C: Job paused - Boss watching. C: </entry> C: END S: RPY 2 3 . 1383 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END

C：MSG 2 3。 4360 250 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<エントリ施設= '24' 重症度= '5' C：タイムスタンプ= '10月27日午前13時24分12秒' C：deviceFQDN = 'screen.lowry .records.example.com」C：deviceIP = '10 .0.0.47' C：PATHID = '173' C：タグ= 'DVD'> C：ジョブが一時停止 - ボスを見て。 C：</エントリ> C：ENDのS：RPY 2 3。 1383年45 S：コンテンツタイプ：アプリケーション/ビープ音+のxml S：S：<OK /> S：END

It is forwarded out the 134.130.74.56 interface:

それは、134.130.74.56インターフェイスから転送されます。

C: MSG 7 9 . 9375 276 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' C: timestamp='Oct 27 13:24:12' C: deviceFQDN='screen.lowry.records.example.com' C: deviceIP='10.0.0.47' C: pathID='17' C: tag='dvd'> C: Job paused - Boss watching. C: </entry> C: END S: RPY 7 9 . 338 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END

C：MSG 7 9。 9375 276 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：<エントリ施設= '24' 重症度= '5' C：タイムスタンプ= '10月27日午前13時24分12秒' C：deviceFQDN = 'screen.lowry .records.example.com」C：deviceIPは= '10 .0.0.47' C：PATHIDは= '17' C：タグ= 'DVD'> C：ジョブが一時停止 - ボスを見て。 C：</エントリ> C：ENDのS：RPY 7 9。 338 45 S：コンテンツタイプ：アプリケーション/ビープ音+のxml S：S：<OK /> S：END

A discussion of the wisdom of configuring Lowry's machine to forward such messages via Kurtzman's machine is beyond the scope of this document.

Kurtzmanのマシンを経由して、このようなメッセージを転送するためにローリーのマシンを構成する知恵の議論は、この文書の範囲を超えています。

5. Additional Provisioning

5.追加のプロビジョニング

In more advanced configurations, syslog devices, relays, and collectors can be configured to support various delivery priorities. Multiple channels running the same profile can be opened between two peers, with higher priority syslog messages routed to a channel that is given more bandwidth. Such provisioning is a local matter.

より高度な構成では、Syslogデバイス、リレー、コレクターでは、様々な配信の優先順位をサポートするように設定することができます。優先度の高いsyslogメッセージは、多くの帯域幅を与えているチャンネルにルーティングして、同じプロファイルを実行している複数のチャネルは、2つのピア間で開くことができます。このようなプロビジョニングは、ローカルの問題です。

syslog [1] discusses a number of reasons why privacy and authentication of syslog entry messages may be important in a networked computing environment. The nature of BEEP allows for convenient layering of authentication and privacy over any BEEP channel.

syslogが[1]のsyslogエントリメッセージのプライバシーと認証は、ネットワークコンピューティング環境において重要であるかもしれない多くの理由を説明します。 BEEPの性質は、任意のBEEPチャネルを介して認証とプライバシーの便利なレイヤーが可能になります。

5.1 Message Authenticity

5.1メッセージの真正

Section 6.2 of [1] discusses the dangers of unauthenticated syslog entries. To prevent inauthentic syslog event messages from being accepted, configure syslog peers to require the use of a strong authentication technology for the BEEP session.

6.2節には、[1]認証されていないのsyslogエントリの危険性について説明します。受け入れられているから本物でないのsyslogイベントメッセージを防止するため、BEEPセッションのための強力な認証技術の使用を必要とするようにsyslogのピアを設定。

If provisioned for message authentication, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.

メッセージ認証にプロビジョニングした場合、実装が提供〜[8]このサービスをSASL機構DIGEST-MD5を使用するべきです。

5.2 Message Replay

5.2メッセージリプレイ

Section 6.3.4 of [1] discusses the dangers of syslog message replay. To prevent syslog event messages from being replayed, configure syslog peers to require the use of a strong authentication technology for the BEEP session.

セクション6.3.4は、[1]のsyslogメッセージのリプレイの危険性について説明します。再生されてからのsyslogイベントメッセージを防止するため、BEEPセッションのための強力な認証技術の使用を必要とするようにsyslogのピアを設定。

If provisioned to detect message replay, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.

メッセージのリプレイを検出するようにプロビジョニングした場合、実装が提供〜[8]このサービスをSASL機構DIGEST-MD5を使用するべきです。

5.3 Message Integrity

5.3メッセージ整合

Section 6.5 of [1] discusses the dangers of syslog event messages being maliciously altered by an attacker. To prevent messages from being altered, configure syslog peers to require the use of a strong authentication technology for the BEEP session.

[1]のsyslogイベントメッセージの危険性を説明のセクション6.5は、悪意の攻撃者によって変更されます。変更されることからメッセージを防止するため、BEEPセッションのための強力な認証技術の使用を必要とするようにsyslogのピアを設定。

If provisioned to protect message integrity, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.

メッセージの完全性を保護するためにプロビジョニングした場合、実装が提供するこのサービスをSASLメカニズムDIGEST-MD5 [8]を使用すべきです。

5.4 Message Observation

5.4メッセージ観測

Section 6.6 of [1] discusses the dangers (and benefits) of syslog messages being visible at intermediate points along the transmission path between device and collector. To prevent messages from being viewed by an attacker, configure syslog peers to require the use of a transport security profile for the BEEP session. (However, other traffic characteristics, e.g., volume and timing of transmissions, remain observable.)

[1]デバイスとコレクタとの間の伝送路に沿った中間点において可視であるsyslogメッセージの危険性（および利点）を説明のセクション6.6。攻撃者が見ているからメッセージを防止するため、BEEPセッションのトランスポート・セキュリティ・プロファイルの使用を必要とするようにsyslogのピアを設定。（しかし、他のトラフィック特性は、例えば、ボリュームおよび送信のタイミングは、観察可能なままです。）

If provisioned to secure messages against unauthorized observation, implementations SHOULD use the TLS profile [3] to provision this service. The cipher algorithm used SHOULD be TLS_RSA_WITH_3DES_EDE_CBC_SHA.

不正観測に対するメッセージを保護するためにプロビジョニングした場合、実装が提供するこのサービスを[3] TLSプロファイルを使用すべきです。使用される暗号アルゴリズムは、TLS_RSA_WITH_3DES_EDE_CBC_SHAであるべきです。

5.5 Summary of Recommended Practices

推奨プラクティスの5.5まとめ

For the indicated protections, implementations SHOULD be configured to use the indicated mechanisms:

示された保護のために、実装が示されているメカニズムを使用するように構成されるべきです。

    Desired Protection  SHOULD tune using
    ------------------  -----------------
    Authentication      http://iana.org/beep/SASL/DIGEST-MD5
      + Replay          http://iana.org/beep/SASL/DIGEST-MD5
        + Integrity     http://iana.org/beep/SASL/DIGEST-MD5
          + Observation http://iana.org/beep/TLS

BEEP peer identities used for authentication SHOULD correspond to the FQDN of the initiating peer. That is, a relay running on relay.example.com should use a "user ID" of "relay.example.com" within the SASL authentication profiles, as well as in the FQDN of the "iam" element.

認証に使用BEEPピアのアイデンティティは、開始ピアのFQDNに対応している必要があります。すなわち、SASL認証プロファイル内、ならびに「IAM」要素のFQDNに「relay.example.com」の「ユーザID」を使用する必要がrelay.example.com上で実行されているリレーです。

6. Initial Registrations

6.初期登録

6.1 Registration: The RAW Profile

6.1登録：RAWプロフィール

Profile Identification: http://xml.resource.org/profiles/syslog/RAW

プロフィール同定：http://xml.resource.org/profiles/syslog/RAW

Messages exchanged during Channel Creation: None

メッセージはチャンネルの作成中に交換：なし

Messages starting one-to-one exchanges: Anything

何か：1対1の交換を開始するメッセージ

Messages in positive replies: None

正の返信のメッセージ：なし

Messages in negative replies: None

負の返信のメッセージ：なし

Messages in one-to-many exchanges: Anything

何か：1対多の交流のメッセージ

Message Syntax: See Section 3.3

メッセージの構文は：3.3節を参照してください。

Message Semantics: See Section 3.4

メッセージの意味：3.4節を参照してください。

Contact Information: See the "Authors' Addresses" section of this memo

お問い合わせ先：このメモの「著者のアドレス」を参照してください

6.2 Registration: The COOKED Profile

6.2登録：COOKEDプロフィール

Profile Identification: http://xml.resource.org/profiles/syslog/COOKED

プロフィール同定：http://xml.resource.org/profiles/syslog/COOKED

Messages exchanged during Channel Creation: iam

メッセージはチャンネルの作成中に交換：IAM

Messages starting one-to-one exchanges: iam, entry, path

IAM、エントリ、パス：一対一の交換を開始するメッセージ

Messages in positive replies: ok

正の返信のメッセージ：OK

Messages in negative replies: error

負の返信のメッセージ：エラー

Messages in one-to-many exchanges: None

1対多の交換におけるメッセージ：なし

Message Syntax: See Section 4.3

メッセージの構文は：セクション4.3を参照してください。

Message Semantics: See Section 4.4

メッセージの意味：セクション4.4を参照してください。

Contact Information: See the "Authors' Addresses" section of this memo

お問い合わせ先：このメモの「著者のアドレス」を参照してください

7. The syslog DTD

7. syslogのDTD

The following is the DTD defining the valid elements for the syslog over BEEP mapping.

以下は、BEEPマッピング経由のsyslogに有効な要素を定義するDTDです。

<!-- DTD for syslog over BEEP, as of 2000-10-10

<！ - DTD BEEP以上のsyslogのため、2000年10月10日のように

Refer to this DTD as:

このDTDとしてご参照ください：

<!ENTITY % SYSLOG PUBLIC "-//Blocks//DTD SYSLOGRELIABLE//EN" ""> %SYSLOG; -->

<！ENTITY％のSYSLOG PUBLIC " - //ブロック// DTD SYSLOGRELIABLE // EN" "">％のSYSLOG。 - >

<!-- Contents

<！ - 目次

Overview

概要

Includes Profile Summaries Entity Definitions

プロフィール概要エンティティ定義が含まれています

Operations iam entry path -->

操作IAMエントリーパス - >

<!-- Overview

<！ - 概要

Syslog packets delivered via BEEP

BEEPを介して配信のSyslogパケット

-->

ーー＞

<！ - 含みます - >

          <!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
                     "">
          %BEEP;

<!-- Profile summaries

<！ - プロファイルの概要

BEEP profile SYSLOG-RAW

BEEPプロファイルSYSLOG-RAW

role MSG ANS ERR ==== === === === L text text text

役割MSG ANS ERR ==== === === === Lテキストテキストテキスト

BEEP profile SYSLOG-COOKED

BEEPプロファイルSYSLOG調理

role MSG RPY ERR ==== === === === I or L iam ok error I or L entry ok error I or L path ok error

役割MSG RPY ERR ==== === === === IまたはLのIAM OKエラーIまたはLのエントリOKエラーIまたはLパスOKエラー

-->

ーー＞

<!-- Entity Definitions

<！ - エンティティ定義

           entity        syntax/reference     example
           ======        ================     =======
       a fully qualified domain name
           FQDN          See [RFC-1034]       www.example.com

a dotted-quad IP address IP 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 10.0.0.27 a syslog facility FACILITY See [1] 1*3DIGIT 80

ドット付きクワッドIPアドレスIP 1 * 3DIGIT "" 1 * 3DIGIT "" 1 * 3DIGIT "" 1 * 3DIGIT 10.0.0.27 syslogファシリティファシリティ[1] 1 * 3DIGIT 80を参照してください。

a syslog severity SEVERITY See [1] DIGIT 4

syslogの重大度SEVERITYは、[1] DIGIT 4を参照してください。

a timestamp See [1] Jan 03 18:43:12 TIMESTAMP

タイムスタンプは、[1] 1月3日午後6時43分12秒TIMESTAMPを参照してください。

an identifying integer IDINT 1*DIGIT 1027

識別整数IDINT 1 * DIGIT 1027

-->

ーー＞

<!ENTITY % FQDN "CDATA"> <!ENTITY % IP "CDATA"> <!ENTITY % FACILITY "CDATA"> <!ENTITY % SEVERITY "CDATA"> <!ENTITY % TIMESTAMP "CDATA"> <!ENTITY % IDINT "CDATA">

<！ENTITY％FQDN "CDATA"> <！ENTITY％のIP "CDATA"> <！ENTITY％のファシリティ "CDATA"> <！ENTITY％以下のSEVERITY "CDATA"> <！ENTITY％以下のTIMESTAMP "CDATA"> <！ENTITY％でIDINT "CDATA">

<!-- The iam element declares the role and identity of the peer issuing it. The contents of the element may include human-readable informative text, such as the physical location of the computer issuing the "iam".

<！ - IAM要素は、それを発行したピアの役割とアイデンティティを宣言します。要素の内容は、「IAM」を発行するコンピュータの物理的位置として人間可読情報テキストを含むことができます。

-->

ーー＞

<!ELEMENT iam (#PCDATA)> <!ATTLIST iam fqdn %FQDN; #REQUIRED ip %IP; #REQUIRED type (device|relay|collector) #REQUIRED>

<！ELEMENTのIAM（#PCDATA）> <ATTLIST IAM FQDN％FQDN！。 #REQUIRED IP％のIP; #REQUIREDタイプ（デバイス|リレー|コレクタ）#REQUIRED>

<！ - entry要素は、単一のsyslogメッセージを伝えます。 - >

<!ELEMENT entry (#PCDATA)> <!ATTLIST entry xml:lang %LANG; "i-default" facility %FACILITY; #REQUIRED severity %SEVERITY; #REQUIRED timestamp %TIMESTAMP; #IMPLIED tag %ATEXT; #IMPLIED deviceFQDN %FQDN; #IMPLIED deviceIP %IP; #IMPLIED pathID %IDINT; #IMPLIED>

<！ELEMENTエントリ（#PCDATA）> <ATTLISTエントリーのxml：！LANG LANG％。 "I-デフォルト" 施設％のFACILITY; #REQUIRED重大％の重症度; #REQUIREDタイムスタンプ％タイムスタンプ; #IMPLIEDタグ％のATEXT。 #IMPLIED deviceFQDN％FQDN。 #IMPLIED deviceIP％のIP; #IMPLIED PATHID％IDINT。 #IMPLIED>

<！ - パス要素は、エントリが通過したリレーのリストを伝えます。 - >

<!ELEMENT path (path?)> <!ATTLIST path pathID %IDINT; #REQUIRED fromFQDN %FQDN; #IMPLIED fromIP %IP; #REQUIRED toFQDN %FQDN; #IMPLIED toIP %IP; #REQUIRED linkprops %ATEXT; #REQUIRED>

<！ELEMENTパス（？パス）> <！ATTLISTパスPATHID％IDINT。 #REQUIRED fromFQDN％FQDN。 #IMPLIED fromIP％のIP; #REQUIRED toFQDN％FQDN。 #IMPLIED TOIP％IP; #REQUIREDは％ATEXTをlinkprops。 #REQUIRED>

<！ - DTDの終わり - >

8. Reply Codes

8.応答コード

The following error codes are used in the protocol:

以下のエラーコードは、プロトコルで使用されています。

code meaning ==== ======= 200 success

コードの意味==== ======= 200成功

421 service not available

421サービスは利用できません

451 requested action aborted (e.g., local error in processing)

中止451要求されたアクション（例えば、処理中にローカルエラー）

454 temporary authentication failure

454一時的な認証失敗

500 general syntax error (e.g., poorly-formed XML)

500一般的な構文エラー（例えば、不完全に形成されたXML）

501 syntax error in parameters (e.g., non-valid XML)

パラメータ501構文エラー（例えば、非有効XML）

504 parameter not implemented

504パラメータが実装されていません

530 authentication required

530認証が必要

534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.)

534認証機構不足（例えば、弱すぎる、シーケンス、等を排出）

535 authentication failure

535認証失敗

537 action not authorized for user

537アクションは、ユーザーのために許可されていません

538 authentication mechanism requires encryption

538認証機構は、暗号化が必要

550 requested action not taken (e.g., no requested profiles are acceptable)

550要求されたアクションが取られていない（例えば、ない要求されたプロファイルが許容可能です）

553 parameter invalid

無効なパラメータ553

554 transaction failed (e.g., policy violation)

554トランザクションが失敗した（例えば、ポリシー違反）

9. IANA Considerations

9. IANAの考慮事項

9.1 Registration: BEEP Profiles

9.1登録：BEEPプロファイル

The IANA registers the profiles specified in Section 6, and selects IANA-specific URIs "http://iana.org/beep/SYSLOG/RAW" and "http://iana.org/beep/SYSLOG/COOKED".

IANAはセクション6で指定されたプロファイルを登録し、IANA固有のURI「http://iana.org/beep/SYSLOG/RAW」および「http://iana.org/beep/SYSLOG/COOKED」を選択します。

9.2 Registration: The System (Well-Known) TCP port number for syslog-conn

9.2登録：syslogの-CONNのためのシステム（ウェルノウン）TCPポート番号

A single well-known port (601) is allocated to syslog-conn. In-band negotiation determines whether COOKED or RAW syslog-conn is in use.

単一の周知のポート（601）のsyslog-CONNに割り当てられます。インバンド交渉調理またはRAWのsyslog-connが使用中であるか否かを判断します。

Protocol Number: TCP

プロトコル番号：TCP

Message Formats, Types, Opcodes, and Sequences: See Section 3.3 and Section 4.4.

メッセージフォーマット、タイプ、オペコード、および順序：3.3節と4.4節を参照してください。

Functions: See Section 3.4 and Section 4.4.

機能：3.4節と4.4節を参照してください。

Use of Broadcast/Multicast: none

ブロードキャスト/マルチキャストの利用：なし

Proposed Name: Reliable syslog service

提案名：信頼性の高いsyslogサービス

Short name: syslog-conn

短い名前：syslogの-CONN

Contact Information: See the "Authors' Addresses" section of this memo

お問い合わせ先：このメモの「著者のアドレス」を参照してください

10. Security Considerations

10.セキュリティの考慮事項

Consult Section 6 of [1] for a discussion of security issues for the syslog service. In addition, since the RAW and COOKED profiles are defined using the BEEP framework, consult [3]'s Section 8 for a discussion of BEEP-specific security issues.

syslogのサービスのためのセキュリティ問題の議論については、[1]のセクション6を参照してください。また、RAW、温かいプロファイルためBEEP固有のセキュリティ問題の議論のために、[3]のセクション8を参照してください、BEEPフレームワークを使用して定義されています。

BEEP is used to provide communication security but not object integrity. In other words, the messages "on the wire" can be protected, but a compromised device may undetectably generate incorrect messages, and relays and collectors can modify, insert, or delete messages undetectably. Other techniques must be used to assure that such compromises are detectable.

BEEPは、通信のセキュリティを提供しますが、完全性を反対しないために使用されます。言い換えれば、「ワイヤー上」のメッセージを保護することができるが、損なわれたデバイスが検出不可能に間違ったメッセージを生成することができ、そしてリレーやコレクターは、変更の挿入、または検出できないメッセージを削除することができます。他の技術は、このような妥協が検出可能であることを保証するために使用されなければなりません。

11. Acknowledgements

11.謝辞

The authors gratefully acknowledge the contributions of Christopher Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman.

作者は感謝クリストファーカラブレーゼ、キースMcCloghrie、バラージュScheidler、そしてデビッドWaitzmanの貢献を認めます。

12. References

12.参考文献

[1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.

[1] Lonvick、C.、 "BSDシスログプロトコル"、RFC 3164、2001年8月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.

[3]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。

[4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.

[4]ローズ、M.、RFC 3081、 "TCP上にBEEPコアのマッピング" を、2001年3月。

[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[5] Gulbrandsenの、A.、いるVixie、P.およびL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782 2000年2月。

[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[6]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。

[7] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.

[7] Alvestrand、H.、 "言語識別のためのタグ"、BCP 47、RFC 3066、2001年1月。

[8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.

[8]、RFC 2831、2000年5月 "SASLメカニズムとしてダイジェスト認証を使用する" リーチ、P.とC.ニューマン、。

Authors' Addresses

著者のアドレス

Darren New 5390 Caminito Exquisito San Diego, CA 92130 US

ダレン新5390カミニートExquisitoサンディエゴ、CA 92130米国

Phone: +1 858 350 9733 EMail: dnew@san.rr.com

電話：+1 858 350 9733 Eメール：dnew@san.rr.com

Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US

マーシャルT.ローズドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268米

Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us

電話：+1 916 483 8878 Eメール：mrose@dbc.mtview.ca.us

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2001）。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。