RFC2974 日本語訳
2974 Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. October 2000. (Format: TXT=40129 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Handley
Request for Comments: 2974 ACIRI
Category: Experimental C. Perkins
USC/ISI
E. Whelan
UCL
October 2000
コメントを求めるワーキンググループM.ハンドレー要求をネットワークでつないでください: 2974年のACIRIカテゴリ: 実験的なC.のパーキンスUSC/ISI E.ウィーランUCL2000年10月
Session Announcement Protocol
セッション発表プロトコル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
このドキュメントはマルチキャストセッションディレクトリ発表プロトコル、Session Announcementプロトコル(SAP)、セキュリティに影響する関連する問題、および作成者によって考慮に入れられるべきであるスケーラビリティのバージョン2について説明します。
1 Introduction
1つの序論
In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically multicasts packets containing a description of the session, and these advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session.
マルチキャストマルチメディア会議と他のマルチキャストセッションの広告を促進して、関連セッションセットアップ情報を参加予定者に伝えるために、分配されたセッションディレクトリは使用されるかもしれません。 インスタンス、そのようなセッションディレクトリでは、定期的に、あれほどそんなに潜在的のリモート関係者がセッション記述を使用できるディレクトリがツールを始める他のセッションでセッションの記述、および受け取られたこれらの広告を含むマルチキャストパケットがセッションのときに参加するのが必要です。
This memo describes the issues involved in the multicast announcement of session description information and defines an announcement protocol to be used. Sessions are described using the session description protocol which is described in a companion memo [4].
このメモは、セッション記述情報のマルチキャスト発表にかかわる問題について説明して、使用されるために発表プロトコルを定義します。 セッションは、仲間メモ[4]で説明されるセッション記述プロトコルを使用することで説明されます。
Handley, et al. Experimental [Page 1] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [1ページ]実験的なRFC2974セッション発表プロトコル2000年10月
2 Terminology
2 用語
A SAP announcer periodically multicasts an announcement packet to a well known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement are within the scope of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local.
SAPのアナウンサー、定期的である、よく知られているマルチキャストへの発表パケットが扱うマルチキャストとポート。 発表はそれが発表するセッションと同じ範囲があるマルチキャストです、発表の受取人が発表が説明するセッション(帯域幅と他のそのような規制の可能にする)の範囲の中にいるのを確実にして。 また、地方のセッション発表を地方に保つとき、プロトコルのスケーラビリティに、これも重要です。
A SAP listener learns of the multicast scopes it is within (for example, using the Multicast-Scope Zone Announcement Protocol [5]) and listens on the well known SAP address and port for those scopes. In this manner, it will eventually learn of all the sessions being announced, allowing those sessions to be joined.
SAPのリスナーが、それが中にあることをマルチキャスト範囲を学ぶ、(例えば、Multicast-範囲Zone Announcementプロトコル[5])を使用して、よく知られているSAPでそれらの範囲までアドレスとポートを聴きます。 この様に、それは、結局、接合されることをそれらのセッションを許容して、発表されるすべてのセッションを学ぶでしょう。
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 [1].
'キーワード'MUST'、[1]で説明されるように本書ではNOTと、'''REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'5月'、およびOPTIONAL'を解釈することになっていなければなりませんか?
3 Session Announcement
3セッション発表
As noted previously, a SAP announcer periodically sends an announcement packet to a well known multicast address and port. There is no rendezvous mechanism - the SAP announcer is not aware of the presence or absence of any SAP listeners - and no additional reliability is provided over the standard best-effort UDP/IP semantics.
以前に注意されるように、SAPのアナウンサーは定期的によく知られているマルチキャストアドレスとポートに発表パケットを送ります。 ランデブーメカニズムが全くありません、そして、(SAPのアナウンサーはどんなSAPのリスナーの存在か不在も意識していません)標準のベストエフォート型UDP/IP意味論の上にどんな追加信頼性も提供しません。
That announcement contains a session description and SHOULD contain an authentication header. The session description MAY be encrypted although this is NOT RECOMMENDED (see section 7).
その発表はセッション記述を含んでいます、そして、SHOULDは認証ヘッダーを含んでいます。 これはNOT RECOMMENDED(セクション7を見る)ですが、セッション記述は暗号化されるかもしれません。
A SAP announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement are within the scope of the session the announcement describes. There are a number of possibilities:
SAP発表はそれが発表するセッションと同じ範囲があるマルチキャストです、発表の受取人が発表が説明するセッションの範囲の中にいるのを確実にして。 多くの可能性があります:
IPv4 global scope sessions use multicast addresses in the range
224.2.128.0 - 224.2.255.255 with SAP announcements being sent to
224.2.127.254 (note that 224.2.127.255 is used by the obsolete
SAPv0 and MUST NOT be used).
IPv4の世界的規模の範囲セッションが範囲でマルチキャストアドレスを使用する、224.2、.128、.0、224.2、.255、SAP発表を224.2に送る.255、.127、.254、(その224.2に.127に注意してください、.255を時代遅れのSAPv0が使用して、使用してはいけない、)
Handley, et al. Experimental [Page 2] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [2ページ]実験的なRFC2974セッション発表プロトコル2000年10月
IPv4 administrative scope sessions using administratively scoped IP
multicast as defined in [7]. The multicast address to be used for
announcements is the highest multicast address in the relevant
administrative scope zone. For example, if the scope range is
239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP
announcements.
行政上使用されるIPv4の管理範囲セッションは[7]で定義されるようにIPマルチキャストを見ました。 発表に使用されるべきマルチキャストアドレスは関連管理範囲ゾーンで最も高いマルチキャストアドレスです。 範囲の範囲が例えばそうである、239.16 .32 .0--239.16 .33 .255、当時、239.16 .33 SAP発表において、.255は使用されています。
IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE
where X is the 4-bit scope value. For example, an announcement
for a link-local session assigned the address
FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address
FF02:0:0:0:0:0:2:7FFE.
IPv6セッションはアドレスFF0Xで発表されます:、0:0:0、:、0:0:2、: Xが4ビットの範囲値である7FFE。 例えば、リンク地方のセッションのための発表はアドレスFF02を割り当てました:、0:、0:0:0、:、0:1234:5678、SAPアドレスFF02に広告を出すべきです:、0:0:0、:、0:0:2、: 7FFE。
Ensuring that a description is not used by a potential participant outside the session scope is not addressed in this memo.
記述がセッション範囲の外の潜在的関係者によって使用されないのを確実にするのはこのメモで扱われません。
SAP announcements MUST be sent on port 9875 and SHOULD be sent with an IP time-to-live of 255 (the use of TTL scoping for multicast is discouraged [7]).
転送されたポートが9875とSHOULDであったに違いないなら生きるIP時間と共に255について送ってください。SAP発表、(TTLの見ることのマルチキャストの使用は妨げている[7])です。
If a session uses addresses in multiple administrative scope ranges, it is necessary for the announcer to send identical copies of the announcement to each administrative scope range. It is up to the listeners to parse such multiple announcements as the same session (as identified by the SDP origin field, for example). The announcement rate for each administrative scope range MUST be calculated separately, as if the multiple announcements were separate.
セッションが複数の管理範囲の範囲でアドレスを使用するなら、アナウンサーがそれぞれの管理範囲の範囲に発表の同一の複製物を送るのが必要です。 同じセッションのような複数の発表を分析するのは、リスナー次第(例えば、SDP発生源分野によって特定されるように)です。 まるで複数の発表が別々であるかのように別々にそれぞれの管理範囲の範囲の発表率について計算しなければなりません。
Multiple announcers may announce a single session, as an aid to robustness in the face of packet loss and failure of one or more announcers. The rate at which each announcer repeats its announcement MUST be scaled back such that the total announcement rate is equal to that which a single server would choose. Announcements made in this manner MUST be identical.
複数のアナウンサーが1人以上のアナウンサーのパケット損失と失敗に直面して丈夫さへの援助としてただ一つのセッションを発表するかもしれません。 各アナウンサーが発表を繰り返すレートが縮小しなければならないので、総発表率はただ一つのサーバが選ぶそれと等しいです。 この様にされた発表は同じであるに違いありません。
If multiple announcements are being made for a session, then each announcement MUST carry an authentication header signed by the same key, or be treated as a completely separate announcement by listeners.
セッションのために複数の発表をしているなら、各発表を同じキーによって署名される認証ヘッダーを運ばなければならないか、またはリスナーは完全に別々の発表として扱わなければなりません。
An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address and on the SAP addresses for each IPv4 administrative scope zone it is within. The discovery of administrative scope zones is outside the scope of this memo, but it is assumed that each SAP listener within a particular scope zone is aware of that scope zone. A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses.
SAPリスナーSHOULDが中でIPv4のグローバルな範囲SAPアドレスの上と、そして、それぞれのIPv4の管理範囲ゾーンへのSAPアドレスの上で聴くIPv4。 このメモの範囲の外に管理範囲ゾーンの発見がありますが、特定の範囲ゾーンの中のそれぞれのSAPのリスナーがその範囲ゾーンを意識していると思われます。 IPv6SAPがまたIPv6 SHOULDが聞くそれのサポートを扱うSAPのリスナー。
Handley, et al. Experimental [Page 3] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [3ページ]実験的なRFC2974セッション発表プロトコル2000年10月
3.1 Announcement Interval
3.1 発表間隔
The time period between repetitions of an announcement is chosen such that the total bandwidth used by all announcements on a single SAP group remains below a preconfigured limit. If not otherwise specified, the bandwidth limit SHOULD be assumed to be 4000 bits per second.
発表の反復の間の期間が選ばれているので、ただ一つのSAPグループにおけるすべての発表で使用される総帯域幅はあらかじめ設定された限界の下に残っています。 そうでなければ、別の方法で指定されていて、帯域幅はSHOULDを制限します。4000のbpsであると思われてください。
Each announcer is expected to listen to other announcements in order to determine the total number of sessions being announced on a particular group. Sessions are uniquely identified by the combination of the message identifier hash and originating source fields of the SAP header (note that SAP v0 announcers always set the message identifier hash to zero, and if such an announcement is received the entire message MUST be compared to determine uniqueness).
各アナウンサーが特定のグループで発表されるセッションの総数を測定するために他の発表を聞くと予想されます。 セッションは、メッセージ識別子ハッシュの組み合わせで唯一特定されて、SAPヘッダーのソースフィールドを溯源しています(SAPのv0アナウンサーがいつもメッセージ識別子ハッシュをゼロに設定して、そのような発表が受け取られているならユニークさを決定するために全体のメッセージをたとえなければならないことに注意してください)。
Announcements are made by periodic multicast to the group. The base interval between announcements is derived from the number of announcements being made in that group, the size of the announcement and the configured bandwidth limit. The actual transmission time is derived from this base interval as follows:
周期的なマルチキャストは発表をグループにします。 そのグループでされる発表の数、発表のサイズ、および構成された帯域幅限界から発表のベース間隔を得ます。 以下のこのベース間隔から実際のトランスミッション時間を得ます:
1. The announcer initializes the variable tp to be the last time a
particular announcement was transmitted (or the current time if
this is the first time this announcement is to be made).
1. アナウンサーは、特定の発表が伝えられた(現在の時間に、これが1回目であるならこの発表は作られていることです)最後の時になるように可変tpを初期化します。
2. Given a configured bandwidth limit in bits/second and an
announcement of ad_size bytes, the base announcement interval
in seconds is
2. ビット/秒における構成された帯域幅限界と広告_サイズバイトの発表を考えて、秒のベース発表間隔は考えます。
interval =max(300; (8*no_of_ads*ad_size)/limit)
間隔=最大(300; (_広告*広告_サイズの8*いいえ、_)/限界)
3. An offset is calculated based on the base announcement interval
3. オフセットはベース発表間隔に基づいて計算されます。
offset= rand(interval* 2/3)-(interval/3)
=底ならし革(間隔*2/3)を相殺してください、-(間隔/3)
4. The next transmission time for an announcement derived as
4. トランスミッションが引き出された発表のために調節する次
tn =tp+ interval+ offset
tn =tp+間隔+オフセット
The announcer then sets a timer to expire at tn and waits. At time tn the announcer SHOULD recalculate the next transmission time. If the new value of tn is before the current time, the announcement is sent immediately. Otherwise the transmission is rescheduled for the new tn. This reconsideration prevents transient packet bursts on startup and when a network partition heals.
アナウンサーは、次に、タイマにtnで期限が切れるように設定して、待ちます。 アナウンサーSHOULD recalculateの時間tnの次のトランスミッション時間。 tnの新しい値が現在の時間の前にあるなら、すぐに、発表を送ります。 さもなければ、トランスミッションは新しいtnのために時期変更されます。 この再考は始動とネットワークパーティションがいつ回復するかときの一時的なパケット炸裂を防ぎます。
Handley, et al. Experimental [Page 4] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [4ページ]実験的なRFC2974セッション発表プロトコル2000年10月
4 Session Deletion
4 セッション削除
Sessions may be deleted in one of several ways:
セッションはいくつかの方法の1つで削除されるかもしれません:
Explicit Timeout The session description payload may contain
timestamp information specifying the start- and end-times of the
session. If the current time is later than the end-time of the
session, then the session SHOULD be deleted from the receiver's
session cache.
明白なTimeout、セッション記述ペイロードはセッションの始めと終わり回を指定するタイムスタンプ情報を含むかもしれません。 時間セッション、次に、セッションSHOULDの終わり-時に受信機のセッションキャッシュから削除されるより現在の後半であるなら。
Implicit Timeout A session announcement message should be received
periodically for each session description in a receiver's session
cache. The announcement period can be predicted by the receiver
from the set of sessions currently being announced. If a session
announcement message has not been received for ten times the
announcement period, or one hour, whichever is the greater, then
the session is deleted from the receiver's session cache. The one
hour minimum is to allow for transient network partitionings.
受信機のセッションキャッシュにおけるそれぞれのセッション記述のために定期的に暗黙のTimeout Aセッション発表メッセージを受け取るべきです。 受信機は現在発表されるセッションのセットから発表の期間を予測できます。 どれがさらに大きいかならセッション発表メッセージが発表の10倍のために期間、または1時間受け取られていないなら、セッションは受信機のセッションキャッシュから削除されます。 1時間の最小限は一時的なネットワーク群分離を考慮することです。
Explicit Deletion A session deletion packet is received specifying
the session to be deleted. Session deletion packets SHOULD have a
valid authentication header, matching that used to authenticate
previous announcement packets. If this authentication is missing,
the deletion message SHOULD be ignored.
明白なDeletion Aセッション削除パケットは削除されるためにセッションを指定するのにおいて受け取られています。 セッション削除パケットSHOULDには、前の発表パケットを認証するのに使用されるそれを合わせて、有効な認証ヘッダーがあります。 この認証が取り逃がす削除がSHOULDを通信させるということであるなら、無視されてください。
5 Session Modification
5 セッション変更
A pre-announced session can be modified by simply announcing the modified session description. In this case, the version hash in the SAP header MUST be changed to indicate to receivers that the packet contents should be parsed (or decrypted and parsed if it is encrypted). The session itself, as distinct from the session announcement, is uniquely identified by the payload and not by the message identifier hash in the header.
単に変更されたセッション記述を発表することによって、あらかじめ発表されたセッションを変更できます。 この場合、パケットコンテンツが分析されるべきであるのを(または、それが暗号化されているなら、解読されて、分析されます)受信機に示すためにSAPヘッダーのバージョンハッシュを変えなければなりません。 セッション発表と異なるとして、セッション自体はヘッダーのメッセージ識別子ハッシュによって特定されるのではなく、ペイロードによって唯一特定されます。
The same rules apply for session modification as for session deletion:
同じ規則はセッション削除のようにセッション変更に申し込みます:
o Either the modified announcement must contain an authentication
header signed by the same key as the cached session announcement
it is modifying, or:
o または、変更された発表がそれが変更しているキャッシュされたセッション発表と同じキーによって署名される認証ヘッダーを含まなければならない、:
o The cached session announcement must not contain an authentication
header, and the session modification announcement must originate
from the same host as the session it is modifying.
o キャッシュされたセッション発表は認証ヘッダーを含んではいけません、そして、セッション変更発表はそれが変更しているセッションと同じホストから発しなければなりません。
Handley, et al. Experimental [Page 5] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [5ページ]実験的なRFC2974セッション発表プロトコル2000年10月
If an announcement is received containing an authentication header and the cached announcement did not contain an authentication header, or it contained a different authentication header, then the modified announcement MUST be treated as a new and different announcement, and displayed in addition to the un-authenticated announcement. The same should happen if a modified packet without an authentication header is received from a different source than the original announcement.
発表が認証ヘッダーを含むのにおいて受け取られていて、キャッシュされた発表が認証ヘッダーを含まなかったか、または異なった認証ヘッダーを含んだなら、変更された発表を新しくて異なった発表として扱って、不-認証された発表に加えて表示しなければなりません。 オリジナルの発表と異なったソースから認証ヘッダーのない変更されたパケットを受け取るなら、同じくらいは起こるべきです。
These rules prevent an announcement having an authentication header added by a malicious user and then being deleted using that header, and it also prevents a denial-of-service attack by someone putting out a spoof announcement which, due to packet loss, reaches some participants before the original announcement. Note that under such circumstances, being able to authenticate the message originator is the only way to discover which session is the correct session.
これらの規則は、発表が悪意あるユーザーに認証ヘッダーを加えさせて、次に、削除されるのをそのヘッダーを使用することで防ぎます、そして、また、それはホールアウトしているaがオリジナルの発表の前にパケット損失のため何人かの関係者に届く発表を偽造するだれかによるサービス不能攻撃を防ぎます。 これでは、メッセージ創始者を認証できるのが、どのセッションが正しいセッションであるかを発見する唯一の方法であることに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=1|A|R|T|E|C| auth len| msgイドハッシュ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ソース(32ビットか128ビット)を溯源します: : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 任意の認証データ| : .... : *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | 任意のペイロードタイプ| + +-+- - - - - - - - - -+ | |0| | + - - - - - - - - - - - - - - - - - - - - +-+ | | | : ペイロード: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet format
図1: パケット・フォーマット
6 Packet Format
6 パケット・フォーマット
SAP data packets have the format described in figure 1.
SAPデータ・パケットには、図1で説明された形式があります。
V: Version Number. The version number field MUST be set to 1 (SAPv2
announcements which use only SAPv1 features are backwards
compatible, those which use new features can be detected by other
means, so the SAP version number doesn't need to change).
V: バージョン番号。 バージョンナンバーフィールドを1に設定しなければならない、(SAPv1の特徴だけを使用するSAPv2発表が後方にそう、SAPバージョン番号が互換性があります、他の手段で新機能を使用するものは検出できるので変化する必要はない、)
Handley, et al. Experimental [Page 6] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [6ページ]実験的なRFC2974セッション発表プロトコル2000年10月
A: Address type. If the A bit is 0, the originating source field
contains a 32-bit IPv4 address. If the A bit is 1, the
originating source contains a 128-bit IPv6 address.
A: タイプに演説してください。 Aビットが0であるなら、起因するソースフィールドは32ビットのIPv4アドレスを含んでいます。 Aビットが1であるなら、起因しているソースは128ビットのIPv6アドレスを含んでいます。
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST
ignore the contents of this field.
R: 予約にされる。 SAPのアナウンサーは0にこれを設定しなければならなくて、SAPのリスナーはこの分野のコンテンツを無視しなければなりません。
T: Message Type. If the T field is set to 0 this is a session
announcement packet, if 1 this is a session deletion packet.
T: メッセージタイプ。 T分野が0に設定されるならセッション発表パケットである、1であるなら、これはセッション削除パケットです。
E: Encryption Bit. If the encryption bit is set to 1, the payload of
the SAP packet is encrypted. If this bit is 0 the packet is not
encrypted. See section 7 for details of the encryption process.
E: 暗号化に噛み付きました。 暗号化ビットが1に設定されるなら、SAPパケットのペイロードは暗号化されています。 このビットが0であるなら、パケットは暗号化されていません。 暗号化プロセスの細部に関してセクション7を見てください。
C: Compressed bit. If the compressed bit is set to 1, the payload is
compressed using the zlib compression algorithm [3]. If the
payload is to be compressed and encrypted, the compression MUST be
performed first.
C: 圧縮されたビット。 圧縮されたビットが1に設定されるなら、ペイロードは、zlib圧縮アルゴリズム[3]を使用することで圧縮されます。 ペイロードが圧縮されて、暗号化されることであるなら、最初に、圧縮を実行しなければなりません。
Authentication Length. An 8 bit unsigned quantity giving the number
of 32 bit words following the main SAP header that contain
authentication data. If it is zero, no authentication header is
present.
認証の長さ。 認証データを含む主なSAPヘッダーに続いて、32ビットの単語の数を与える8ビットの未署名の量。 それがゼロであるなら、どんな認証ヘッダーも出席していません。
Authentication data containing a digital signature of the packet,
with length as specified by the authentication length header
field. See section 8 for details of the authentication process.
指定されるとしての認証長さのヘッダーフィールドによる長さでパケットのデジタル署名を含む認証データ。 認証過程の詳細に関してセクション8を見てください。
Message Identifier Hash. A 16 bit quantity that, used in combination
with the originating source, provides a globally unique identifier
indicating the precise version of this announcement. The choice
of value for this field is not specified here, except that it MUST
be unique for each session announced by a particular SAP announcer
and it MUST be changed if the session description is modified (and
a session deletion message SHOULD be sent for the old version of
the session).
メッセージ識別子ハッシュ。 起因しているソースと組み合わせて使用されていた状態でこの発表の正確なバージョンを示すグローバルにユニークな識別子を提供する16ビットの量。 ここでこの分野への価値の選択を指定しないで、それぞれに、それがユニークであるに違いないのを除いて、セッションが特定のSAPのアナウンサーで発表して、セッション記述が変更しているならそれを変えなければならない、(セッション削除メッセージSHOULD、セッションの古いバージョンのために送ってください、)
Earlier versions of SAP used a value of zero to mean that the hash
should be ignored and the payload should always be parsed. This
had the unfortunate side-effect that SAP announcers had to study
the payload data to determine how many unique sessions were being
advertised, making the calculation of the announcement interval
more complex that necessary. In order to decouple the session
announcement process from the contents of those announcements, SAP
announcers SHOULD NOT set the message identifier hash to zero.
SAPの以前のバージョンは、ハッシュが無視されるべきであり、ペイロードがいつも分析されるべきであることを意味するのにゼロの値を使用しました。 これには、SAPのアナウンサーが発表間隔の計算をより複雑にして、いくつのユニークなセッションが広告を出していたかをそんなに必要な状態で決定するためにペイロードデータを研究するために持っていた不幸な副作用がありました。 セッション発表の衝撃を吸収するには、それらの発表(SHOULD NOTが、メッセージ識別子ハッシュがゼロに合わせるように設定するSAPのアナウンサー)のコンテンツから、処理してください。
SAP listeners MAY silently discard messages if the message
identifier hash is set to zero.
メッセージ識別子ハッシュがゼロに設定されるなら、SAPのリスナーは静かにメッセージを捨てるかもしれません。
Handley, et al. Experimental [Page 7] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [7ページ]実験的なRFC2974セッション発表プロトコル2000年10月
Originating Source. This gives the IP address of the original source
of the message. This is an IPv4 address if the A field is set to
zero, else it is an IPv6 address. The address is stored in
network byte order.
ソースを溯源します。 これはメッセージの一次資料のIPアドレスを与えます。 A分野がゼロに設定されるならこれがIPv4アドレスである、ほかに、それはIPv6アドレスです。 アドレスはネットワークバイトオーダーで保存されます。
SAPv0 permitted the originating source to be zero if the message
identifier hash was also zero. This practise is no longer legal,
and SAP announcers SHOULD NOT set the originating source to zero.
SAP listeners MAY silently discard packets with the originating
source set to zero.
SAPv0は、また、メッセージ識別子ハッシュがゼロであったなら起因しているソースがゼロであることを可能にしました。 これが練習される、SHOULD NOTが、起因しているソースがゼロに合わせるように設定するもう法的でなくてSAPのアナウンサーはそうです。 SAPのリスナーは起因しているソースセットで静かにゼロにパケットを捨てるかもしれません。
The header is followed by an optional payload type field and the payload data itself. If the E or C bits are set in the header both the payload type and payload are encrypted and/or compressed.
任意のペイロードタイプ分野とペイロードデータ自体はヘッダーのあとに続いています。 EかCビットがヘッダーの両方に設定されるなら、ペイロードタイプとペイロードは、暗号化される、そして/または、圧縮されます。
The payload type field is a MIME content type specifier, describing the format of the payload. This is a variable length ASCII text string, followed by a single zero byte (ASCII NUL). The payload type SHOULD be included in all packets. If the payload type is `application/sdp' both the payload type and its terminating zero byte MAY be omitted, although this is intended for backwards compatibility with SAP v1 listeners only.
ペイロードの形式について説明して、ペイロードタイプ分野はMIME content type特許説明書の作成書です。 これは可変長ASCIIテキスト文字列であり、シングルがあとに続いて、バイト(ASCII NUL)のゼロを合わせてください。 含まれていて、ペイロードはすべてのパケットにSHOULDをタイプします。 ペイロードタイプが'の'アプリケーション/sdp両方であるなら、ペイロードタイプとバイトを全く終えないのは省略されるかもしれません、これがSAPのv1リスナーだけとの遅れている互換性のために意図しますが。
The absence of a payload type field may be noted since the payload section of such a packet will start with an SDP `v=0' field, which is not a legal MIME content type specifier.
そのようなパケットのペイロード部分がSDP'v=0'野原(法的なMIME content type特許説明書の作成書でない)から始まるので、ペイロードタイプ分野の欠如は有名であるかもしれません。
All implementations MUST support payloads of type `application/sdp' [4]. Other formats MAY be supported although since there is no negotiation in SAP an announcer which chooses to use a session description format other than SDP cannot know that the listeners are able to understand the announcement. A proliferation of payload types in announcements has the potential to lead to severe interoperability problems, and for this reason, the use of non-SDP payloads is NOT RECOMMENDED.
すべての実装がタイプ'アプリケーション/sdp'[4]のペイロードを支えなければなりません。 SAPには交渉が全くないので、SDP以外のセッション記述形式を使用するのを選ぶアナウンサーは、リスナーが発表を理解できるのを知ることができませんが、他の形式はサポートされるかもしれません。 発表における、ペイロードタイプの増殖には、厳しい相互運用性問題を引き起こす可能性があります、そして、この理由で、非SDPペイロードの使用はNOT RECOMMENDEDです。
If the packet is an announcement packet, the payload contains a session description.
パケットが発表パケットであるなら、ペイロードはセッション記述を含んでいます。
If the packet is a session deletion packet, the payload contains a session deletion message. If the payload format is `application/sdp' the deletion message is a single SDP line consisting of the origin field of the announcement to be deleted.
パケットがセッション削除パケットであるなら、ペイロードはセッション削除メッセージを含んでいます。 ペイロード形式が'アプリケーション/sdp'であるなら、削除メッセージは削除されるために発表の発生源分野から成るただ一つのSDP系列です。
It is desirable for the payload to be sufficiently small that SAP packets do not get fragmented by the underlying network. Fragmentation has a loss multiplier effect, which is known to significantly affect the reliability of announcements. It is
ペイロードが十分わずかであることで、SAPパケットが基本的なネットワークによって断片化されないのは、望ましいです。 断片化には、損失乗数効果があります。(それは、発表の信頼性にかなり影響するのが知られています)。 それはそうです。
Handley, et al. Experimental [Page 8] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [8ページ]実験的なRFC2974セッション発表プロトコル2000年10月
RECOMMENDED that SAP packets are smaller than 1kByte in length, although if it is known that announcements will use a network with a smaller MTU than this, then that SHOULD be used as the maximum recommended packet size.
それが知られているならその発表が長さ望んでいますが、1kByteがこれより小さいMTUとのネットワークを使用するより小ささと、最大がパケットサイズを推薦したのでSHOULDが使用されるその時のSAPパケットがそうであるRECOMMENDED。
7 Encrypted Announcements
7 暗号化された発表
An announcement is received by all listeners in the scope to which it is sent. If an announcement is encrypted, and many of the receivers do not have the encryption key, there is a considerable waste of bandwidth since those receivers cannot use the announcement they have received. For this reason, the use of encrypted SAP announcements is NOT RECOMMENDED on the global scope SAP group or on administrative scope groups which may have many receivers which cannot decrypt those announcements.
発表はそれが送られる範囲ですべてのリスナーによって受けられます。 発表が暗号化されていて、受信機の多くが暗号化キーを持っていないなら、それらの受信機がそれらが受けた発表を使用できないので、帯域幅のかなりの浪費があります。 この理由で、暗号化されたSAP発表の使用はグローバルな範囲SAPグループの上、または、管理範囲グループの上のそれらの発表を解読することができない多くの受信機があるかもしれないNOT RECOMMENDEDです。
The opinion of the authors is that encrypted SAP is useful in special cases only, and that the vast majority of scenarios where encrypted SAP has been proposed may be better served by distributing session details using another mechanism. There are, however, certain scenarios where encrypted announcements may be useful. For this reason, the encryption bit is included in the SAP header to allow experimentation with encrypted announcements.
作者の意見は暗号化されたSAPが特別な場合だけで役に立って、別のメカニズムを使用することでセッションの詳細を分配することによって暗号化されたSAPが提案されたかなりの大多数のシナリオが役立たれるほうがよいということです。 しかしながら、あるシナリオが暗号化された発表が役に立つかもしれないところにあります。 この理由で、暗号化ビットは、暗号化された発表による実験を許すためにSAPヘッダーに含まれています。
This memo does not specify details of the encryption algorithm to be used or the means by which keys are generated and distributed. An additional specification should define these, if it is desired to use encrypted SAP.
このメモは使用されるべき暗号化アルゴリズムの詳細かキーが生成されて、分配される手段を指定しません。 暗号化されたSAPを使用するのが必要であるなら、追加仕様はこれらを定義するべきです。
Note that if an encrypted announcement is being announced via a proxy, then there may be no way for the proxy to discover that the announcement has been superseded, and so it may continue to relay the old announcement in addition to the new announcement. SAP provides no mechanism to chain modified encrypted announcements, so it is advisable to announce the unmodified session as deleted for a short time after the modification has occurred. This does not guarantee that all proxies have deleted the session, and so receivers of encrypted sessions should be prepared to discard old versions of session announcements that they may receive. In most cases however, the only stateful proxy will be local to (and known to) the sender, and an additional (local-area) protocol involving a handshake for such session modifications can be used to avoid this problem.
暗号化された発表がプロキシを通して発表されているならプロキシが、発表が取って代わられたと発見する方法が全くないかもしれないことに注意してくださいので、それは、新しい発表に加えた古い発表をリレーし続けるかもしれません。 SAPが変更された暗号化された発表をチェーニングするためにメカニズムを全く提供しないので、変更が起こった後に短い間削除される変更されていないセッションのときに発表するのは賢明です。 これは、すべてのプロキシがセッションを削除したので暗号化されたセッションの受信機が受信するかもしれないというセッション発表の古いバージョンを捨てるために準備されているべきであるのを保証しません。 多くの場合しかしながら、唯一のstatefulプロキシが(そして、知られています)送付者にとって地元になるでしょう、そして、この問題を避けるのにそのようなセッション変更のための握手にかかわる追加(局部)プロトコルは使用できます。
Session announcements that are encrypted with a symmetric algorithm may allow a degree of privacy in the announcement of a session, but it should be recognized that a user in possession of such a key can pass it on to other users who should not be in possession of such a key. Thus announcements to such a group of key holders cannot be
左右対称のアルゴリズムで暗号化されるセッション発表はセッションの発表における、プライバシーの度合いを許容するかもしれませんが、そのようなキーの所持のユーザがそのようなキーの所持にいるべきでない他のユーザにそれを渡すことができると認められるべきです。 したがって、主要な所有者のそのようなグループへの発表はそうであるはずがありません。
Handley, et al. Experimental [Page 9] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [9ページ]実験的なRFC2974セッション発表プロトコル2000年10月
assumed to have come from an authorized key holder unless there is an appropriate authentication header signed by an authorized key holder. In addition the recipients of such encrypted announcements cannot be assumed to only be authorized key holders. Such encrypted announcements do not provide any real security unless all of the authorized key holders are trusted to maintain security of such session directory keys. This property is shared by the multicast session tools themselves, where it is possible for an un-trustworthy member of the session to pass on encryption keys to un-authorized users. However it is likely that keys used for the session tools will be more short lived than those used for session directories.
認可された主要な所有者によって署名された適切な認証ヘッダーがない場合、認可された主要な所有者から来たと思われます。 さらに、認可された主要な所有者だけであるとそのような暗号化された発表の受取人を思うことができません。 認可された主要な所有者のすべてがそのようなセッションディレクトリキーのセキュリティを維持すると信じられない場合、そのような暗号化された発表は少しの物上担保も提供しません。 この特性はマルチキャストセッションツール自体によって共有されます、セッションの信頼できないメンバーが権限のないユーザの暗号化キーを伝えるのが、可能であるところで。 しかしながら、セッションツールに使用されるキーがセッションディレクトリに使用されるものよりさらに短く送られた状態でなるのは、ありそうです。
Similar considerations should apply when session announcements are encrypted with an asymmetric algorithm, but then it is possible to restrict the possessor(s) of the private key, so that announcements to a key-holder group can not be made, even if one of the untrusted members of the group proves to be un-trustworthy.
セッション発表が非対称のアルゴリズムで暗号化されるとき、同様の問題は適用されるべきですが、秘密鍵の所有者を制限するのは可能です、主要な所有者グループへの発表をすることができないように、グループの信頼されていないメンバーのひとりが、信頼できないと判明しても。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader |
: .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=1|P| Auth| | +-+-+-+-+-+-+-+-+ | | 形式特定の認証「副-ヘッダー」| : .................. : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the authentication data in the SAP header
図2: SAPヘッダーの認証データの形式
8 Authenticated Announcements
8 認証された発表
The authentication header can be used for two purposes:
2つの目的に認証ヘッダーを使用できます:
o Verification that changes to a session description or deletion of
a session are permitted.
o セッションのセッション記述か削除への変化が受入れられる検証。
o Authentication of the identity of the session creator.
o セッションクリエイターのアイデンティティの認証。
In some circumstances only verification is possible because a certificate signed by a mutually trusted person or authority is not available. However, under such circumstances, the session originator may still be authenticated to be the same as the session originator of previous sessions claiming to be from the same person. This may or may not be sufficient depending on the purpose of the session and the people involved.
いくつかの事情では、互いに信じられた人か権威によって署名される証明書が利用可能でないので、検証だけが可能です。 しかしながら、これでは、セッション創始者は、同じ人からあると主張する前のセッションのセッション創始者と同じになるようにまだ認証されているかもしれません。 セッションとかかわった人々の目的によって、これは十分であるかもしれません。
Handley, et al. Experimental [Page 10] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [10ページ]実験的なRFC2974セッション発表プロトコル2000年10月
Clearly the key used for the authentication should not be trusted to belong to the session originator unless it has been separately authenticated by some other means, such as being certified by a trusted third party. Such certificates are not normally included in an SAP header because they take more space than can normally be afforded in an SAP packet, and such verification must therefore take place by some other mechanism. However, as certified public keys are normally locally cached, authentication of a particular key only has to take place once, rather than every time the session directory retransmits the announcement.
明確に、別々にある他の手段でそれを認証していない場合、セッション創始者に属すと認証に使用されるキーを信じるべきではありません、信頼できる第三者機関によって公認されるのなどように。 通常、SAPパケットで都合することができるより多くのスペースを取るので、通常、そのような証明書はSAPヘッダーに含まれていません、そして、したがって、そのような検証はある他のメカニズムで行われなければなりません。 しかしながら、公認された公開鍵が通常局所的にキャッシュされるとき、特定のキーの認証だけが一度、セッションディレクトリが発表を再送する毎回よりむしろ行われなければなりません。
SAP is not tied to any single authentication mechanism. Authentication data in the header is self-describing, but the precise format depends on the authentication mechanism in use. The generic format of the authentication data is given in figure 2. The structure of the format specific authentication subheader, using both the PGP and the CMS formats, is discussed in sections 8.1 and 8.2 respectively. Additional formats may be added in future.
SAPはどんなただ一つの認証機構にも結ばれません。 ヘッダーの認証データは自己説明ですが、正確な形式は使用中の認証機構に依存します。 認証データのジェネリック形式は考えて、2が中で計算するということです。 PGPとCMS形式の両方を使用して、セクション8.1と8.2でそれぞれ形式特定の認証「副-ヘッダー」の構造について議論します。 追加書式はこれから、加えられるかもしれません。
Version Number, V: The version number of the authentication format
specified by this memo is 1.
バージョン番号、V: このメモで指定された認証形式のバージョン番号は1です。
Padding Bit, P: If necessary the authentication data is padded to be
a multiple of 32 bits and the padding bit is set. In this case
the last byte of the authentication data contains the number of
padding bytes (including the last byte) that must be discarded.
P、詰め物に噛み付きました: 必要なら認証データは32ビットの倍数になるように水増しされます、そして、詰め物ビットは設定されます。 この場合、認証データの最後のバイトは捨てなければならない詰め物バイト(最後のバイトを含んでいる)の数を含みます。
Authentication Type, Auth: The authentication type is a 4 bit
encoded field that denotes the authentication infrastructure the
sender expects the recipients to use to check the authenticity and
integrity of the information. This defines the format of the
authentication subheader and can take the values: 0 = PGP format,
1 = CMS format. All other values are undefined and SHOULD be
ignored.
認証タイプ、Auth: 認証タイプは情報の信憑性と保全をチェックするのに使用する送付者が受取人を予想する認証インフラストラクチャを指示する4ビットコード化された分野です。 これは、認証「副-ヘッダー」の書式を定義して、値を取ることができます: 0はPGP形式、1つの=CMS形式と等しいです。 他のすべての値が未定義である、SHOULD、無視されてください。
If a SAP packet is to be compressed or encrypted, this MUST be done before the authentication is added.
SAPパケットを圧縮するつもりであるか、または暗号化するつもりであるなら、認証を加える前にこれをしなければなりません。
The digital signature in the authentication data MUST be calculated over the entire packet, including the header. The authentication length MUST be set to zero and the authentication data excluded when calculating the digital signature.
ヘッダーを含む全体のパケットの上で認証データにおけるデジタル署名について計算しなければなりません。 ゼロとデジタル署名について計算するとき除かれた認証データに認証の長さを設定しなければなりません。
It is to be expected that sessions may be announced by a number of different mechanisms, not only SAP. For example, a session description may placed on a web page, sent by email or conveyed in a
セッションがSAPだけではなく、多くの異なったメカニズムによって発表されるかもしれないと予想されることになっています。 例えば、記述がそうするセッションは、ウェブページで入賞したか、メールで発信したか、または中までaを運びました。
Handley, et al. Experimental [Page 11] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [11ページ]実験的なRFC2974セッション発表プロトコル2000年10月
session initiation protocol. To ease interoperability with these other mechanisms, application level security is employed, rather than using IPsec authentication headers.
セッション開始プロトコル。 これらの他のメカニズムで相互運用性を緩和するために、アプリケーションレベルセキュリティはIPsec認証ヘッダーを使用するよりむしろ採用しています。
8.1 PGP Authentication
8.1 PGP認証
A full description of the PGP protocol can be found in [2]. When using PGP for SAP authentication the basic format specific authentication subheader comprises a digital signature packet as described in [2]. The signature type MUST be 0x01 which means the signature is that of a canonical text document.
[2]でPGPプロトコルの余すところのない解説を見つけることができます。 SAP認証にPGPを使用するとき、基本形式の特定の認証「副-ヘッダー」は[2]で説明されるようにデジタル署名パケットを包括します。 署名タイプは0×01であるに違いありません(署名が正準なテキストドキュメントのものであることを意味します)。
8.2 CMS Authentication
8.2 cm認証
A full description of the Cryptographic Message Syntax can be found in [6]. The format specific authentication subheader will, in the CMS case, have an ASN.1 ContentInfo type with the ContentType being signedData.
[6]でCryptographic Message Syntaxの余すところのない解説を見つけることができます。 CMS場合では、形式特定の認証「副-ヘッダー」はASN.1ContentInfoにsignedDataであるContentTypeでタイプさせるでしょう。
Use is made of the option available in PKCS#7 to leave the content itself blank as the content which is signed is already present in the packet. Inclusion of it within the SignedData type would duplicate this data and increase the packet length unnecessarily. In addition this allows recipients with either no interest in the authentication, or with no mechanism for checking it, to more easily skip the authentication information.
署名される内容がパケットに既に存在しているので内容自体を空白の状態でおくためにPKCS#7で利用可能なオプションで使用をします。 SignedDataタイプの中のそれの包含は、このデータをコピーして、不必要にパケット長を増強するでしょう。 さらに、これは、より容易に認証情報をスキップするためにそれをチェックするためにどちらかが無利子であることの認証も、またはメカニズムのない受取人を許容します。
There SHOULD be only one signerInfo and related fields corresponding to the originator of the SAP announcement. The signingTime SHOULD be present as a signedAttribute. However, due to the strict size limitations on the size of SAP packets, certificates and CRLs SHOULD NOT be included in the signedData structure. It is expected that users of the protocol will have other methods for certificate and CRL distribution.
そこでは、1signerInfoだけであり、関係づけられたSHOULDがSAP発表の創始者との文通をさばきます。 signingTime SHOULD、signedAttributeとして、存在してください。 しかしながら、SAPパケット、証明書、およびCRLs SHOULDのサイズにおける厳しいサイズ制限のためsignedData構造で含められないでください。 プロトコルのユーザには証明書のための他のメソッドとCRL分配があると予想されます。
9 Scalability and caching
9スケーラビリティとキャッシュ
SAP is intended to announce the existence of long-lived wide-area multicast sessions. It is not an especially timely protocol: sessions are announced by periodic multicast with a repeat rate on the order of tens of minutes, and no enhanced reliability over UDP. This leads to a long startup delay before a complete set of announcements is heard by a listener. This delay is clearly undesirable for interactive browsing of announced sessions.
SAPが長命の広い領域マルチキャストセッションの存在を発表することを意図します。 それは特にタイムリーなプロトコルではありません: セッションはUDPの上の反復率が何十分もの注文にある状態で周期的なマルチキャストによって発表された、高められなかった信頼性です。 完全なセットの発表がリスナーによって聞かれる前にこれは長い始動遅れに通じます。 発表されたセッションの対話的なブラウジングには、この遅れは明確に望ましくありません。
In order to reduce the delays inherent in SAP, it is recommended that proxy caches are deployed. A SAP proxy cache is expected to listen to all SAP groups in its scope, and to maintain an up-to-date list of
SAPに固有の遅れを減少させるために、プロキシキャッシュが配布されるのは、お勧めです。 SAPプロキシキャッシュは、範囲ですべてのSAPグループを聞いて、最新のリストを維持すると予想されます。
Handley, et al. Experimental [Page 12] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [12ページ]実験的なRFC2974セッション発表プロトコル2000年10月
all announced sessions along with the time each announcement was last received. When a new SAP listeners starts, it should contact its local proxy to download this information, which is then sufficient for it to process future announcements directly, as if it has been continually listening.
すべてが、それぞれの発表が最後であった時に伴うセッションが受信されたと発表しました。 新しいSAPリスナー始めであるときに、この次に直接今後の発表を処理するために十分な情報をダウンロードするために地元のプロキシに連絡するべきです、まるで絶えず聴いているかのように。
The protocol by which a SAP listener contacts its local proxy cache is not specified here.
SAPのリスナーがローカルなプロキシキャッシュに連絡するプロトコルはここで指定されません。
10 Security Considerations
10 セキュリティ問題
SAP contains mechanisms for ensuring integrity of session announcements, for authenticating the origin of an announcement and for encrypting such announcements (sections 7 and 8).
SAPはセッション発表の保全を確実にして、発表の発生源を認証して、そのような発表(セクション7と8)を暗号化するためのメカニズムを含みます。
As stated in section 5, if a session modification announcement is received that contains a valid authentication header, but which is not signed by the original creator of the session, then the session must be treated as a new session in addition to the original session with the same SDP origin information unless the originator of one of the session descriptions can be authenticated using a certificate signed by a trusted third party. If this were not done, there would be a possible denial of service attack whereby a party listens for new announcements, strips off the original authentication header, modifies the session description, adds a new authentication header and re-announces the session. If a rule was imposed that such spoof announcements were ignored, then if packet loss or late starting of a session directory instance caused the original announcement to fail to arrive at a site, but the spoof announcement did so, this would then prevent the original announcement from being accepted at that site.
セクション5で述べられているように、セッション変更発表が受け取られていて、(有効な認証ヘッダーを含みますが、セッションのオリジナルのクリエイターによって署名されません)信頼できる第三者機関によって署名された証明書を使用することでセッション記述の1つの創始者を認証できないなら、同じSDP発生源情報とのオリジナルのセッションに加えた新しいセッションとしてセッションを扱わなければなりません。 これをしないなら、パーティーが新しい発表の聞こうとして、オリジナルの認証ヘッダーを全部はぎ取って、セッション記述を変更して、新しい認証ヘッダーを加えて、セッションを再発表するサービス攻撃の可能な否定があるでしょうに。 そのようなパロディー発表が無視されたという規則が課されるなら、セッションディレクトリインスタンスのパケット損失か始めが遅かったのでオリジナルの発表がサイトに到着しませんでしたが、パロディー発表がそうするなら、これは、オリジナルの発表がそのサイトで受け入れられるのを防ぐでしょうに。
A similar denial-of-service attack is possible if a session announcement receiver relies completely on the originating source and hash fields to indicate change, and fails to parse the remainder of announcements for which it has seen the origin/hash combination before.
セッション発表受信機が変化を示すために起因しているソースとハッシュ分野を完全に当てにして、それが以前発生源/ハッシュ組み合わせを見たことがある発表の残りを分析しないなら、同様のサービス不能攻撃は可能です。
A denial of service attack is possible from a malicious site close to a legitimate site which is making a session announcement. This can happen if the malicious site floods the legitimate site with huge numbers of (illegal) low TTL announcements describing high TTL sessions. This may reduce the session announcement rate of the legitimate announcement to below a tenth of the rate expected at remote sites and therefore cause the session to time out. Such an attack is likely to be easily detectable, and we do not provide any mechanism here to prevent it.
サービス不能攻撃はセッション発表をしている正統のサイトの近くで悪意があるサイトから可能です。 悪意があるサイトが巨大な数の(不法)の低いTTL発表が高いTTLセッションについて説明している正統のサイトをあふれさせるなら、これは起こることができます。 これは、リモートサイトで予想されたレートの10分の1の正統の発表対セッション発表率を低下させて、したがって、タイムアウトにセッションを引き起こすかもしれません。 そのような攻撃は容易に検出可能である傾向があります、そして、私たちはそれを防ぐためにどんなメカニズムもここに前提としません。
Handley, et al. Experimental [Page 13] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [13ページ]実験的なRFC2974セッション発表プロトコル2000年10月
A. Summary of differences between SAPv0 and SAPv1
A。 SAPv0とSAPv1の違いの概要
For this purpose SAPv0 is defined as the protocol in use by version 2.2 of the session directory tool, sdr. SAPv1 is the protocol described in the 19 November 1996 version of this memo. The packet headers of SAP messages are the same in V0 and V1 in that a V1 tool can parse a V0 announcement header but not vice-versa. In SAPv0, the fields have the following values:
このためにSAPv0はセッションディレクトリツール、sdrのバージョン2.2で使用中のプロトコルと定義されます。 SAPv1はこのメモの1996年11月19日のバージョンで説明されたプロトコルです。 SAPメッセージのパケットのヘッダーは、V1ツールがV0発表ヘッダーを分析できるのでV0とV1で同じですが、逆もまた同様に同じであるというわけではありません。 SAPv0では、分野は以下の値を持っています:
o Version Number: 0
o バージョン番号: 0
o Message Type: 0 (Announcement)
o メッセージタイプ: 0 (発表)
o Authentication Type: 0 (No Authentication)
o 認証タイプ: 0 (認証がありません)
o Encryption Bit: 0 (No Encryption)
o 暗号化に噛み付きました: 0 (暗号化がありません)
o Compression Bit: 0 (No compression)
o 圧縮に噛み付きました: 0 (圧縮がありません)
o Message Id Hash: 0 (No Hash Specified)
o メッセージイドハッシュ: 0 (指定されなかったハッシュ全く)
o Originating Source: 0 (No source specified, announcement has
not been relayed)
o ソースを溯源します: 0 (どんなソースも指定しないで、また発表はリレーされていません)
B. Summary of differences between SAPv1 and SAPv2
B。 SAPv1とSAPv2の違いの概要
The packet headers of SAP messages are the same in V1 and V2 in that a V2 tool can parse a V1 announcement header but not necessarily vice-versa.
SAPメッセージのパケットのヘッダーは、V2ツールがV1発表ヘッダーを分析できるのでV1とV2で同じですが、必ず逆もまた同様に同じであるというわけではありません。
o The A bit has been added to the SAP header, replacing one of the
bits of the SAPv1 message type field. If set to zero the
announcement is of an IPv4 session, and the packet is backwards
compatible with SAPv1. If set to one the announcement is of an
IPv6 session, and SAPv1 listeners (which do not support IPv6) will
see this as an illegal message type (MT) field.
o AビットはSAPヘッダーに加えられます、SAPv1メッセージタイプ分野のビットの1つを取り替えて。 設定されるなら、発表のゼロを合わせるのは、IPv4セッションのものです、そして、パケットが後方にSAPv1と互換性があった状態であります。 1つに設定されるなら、発表はIPv6セッションのものです、そして、SAPv1リスナー(IPv6をサポートしません)は不法なメッセージタイプ(MT)分野であるとこれをみなすでしょう。
o The second bit of the message type field in SAPv1 has been
replaced by a reserved, must-be-zero, bit. This bit was unused in
SAPv1, so this change just codifies existing usage.
o SAPv1における、メッセージタイプ分野の2番目のビットを予約されて、ゼロでなければならないビットに取り替えました。 このビットはSAPv1で未使用であり、したがって、この変化がただ既存の用法を成文化するということでした。
o SAPv1 specified encryption of the payload. SAPv2 includes the E
bit in the SAP header to indicate that the payload is encrypted,
but does not specify any details of the encryption.
o SAPv1はペイロードの暗号化を指定しました。 SAPv2はペイロードが暗号化されているのを示すためにSAPヘッダーにEビットを含んでいますが、暗号化の少しの詳細も指定しません。
o SAPv1 allowed the message identifier hash and originating source
fields to be set to zero, for backwards compatibility. This is no
longer legal.
o SAPv1は、メッセージ識別子ハッシュとソースフィールドを溯源したら互換性のゼロが後方にように合うように設定されるのを許容しました。 これはもう法的ではありません。
Handley, et al. Experimental [Page 14] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [14ページ]実験的なRFC2974セッション発表プロトコル2000年10月
o SAPv1 specified gzip compression. SAPv2 uses zlib (the only known
implementation of SAP compression used zlib, and gzip compression
was a mistake).
o SAPv1はgzip圧縮を指定しました。 SAPv2はzlibを使用します(SAP圧縮の唯一の知られている実装がzlibを使用しました、そして、gzip圧縮は誤りでした)。
o SAPv2 provides a more complete specification for authentication.
o SAPv2は認証のための、より完全な仕様を提供します。
o SAPv2 allows for non-SDP payloads to be transported. SAPv1
required that the payload was SDP.
o SAPv2は、非SDPペイロードが輸送されるのを許容します。 SAPv1は、ペイロードがSDPであることを必要としました。
o SAPv1 included a timeout field for encrypted announcement, SAPv2
does not (and relies of explicit deletion messages or implicit
timeouts).
o SAPv1を含んでいて、暗号化された発表、SAPv2のためのタイムアウト分野はそうしません(そして、明白な削除メッセージか暗黙のタイムアウトを当てにします)。
C. Acknowledgements
C。 承認
SAP and SDP were originally based on the protocol used by the sd session directory from Van Jacobson at LBNL. Version 1 of SAP was designed by Mark Handley as part of the European Commission MICE (Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 includes authentication features developed by Edmund Whelan, Goli Montasser-Kohsari and Peter Kirstein as part of the European Commission ICE-TEL project (Telematics 1005), and support for IPv6 developed by Maryann P. Maher and Colin Perkins.
SAPとSDPは元々、LBNLでヴァン・ジェーコブソンからのsdセッションディレクトリによって使用されるプロトコルに基づきました。 欧州委員会MICE(エスプリ7602)とメルチィ(テレマティックス1007)の一部が突出するとき、SAPのバージョン1はマーク・ハンドレーによって設計されました。 バージョン2は欧州委員会ICE-TELプロジェクト(テレマティックス1005)の一部、およびマリアン・P.マーヘルとコリン・パーキンスによって開発されたIPv6のサポートとしてエドモンド・ウィーラン、Goli Montasser-Kohsari、およびピーター・カースタインによって発生された認証機能を含んでいます。
Handley, et al. Experimental [Page 15] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [15ページ]実験的なRFC2974セッション発表プロトコル2000年10月
D. Authors' Addresses
D。 作者のアドレス
Mark Handley AT&T Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA
ICSIでのインターネット調査のためのマークハンドレーAT&Tセンター、国際電子計算機科学協会、1947は通り、スイート600、バークレー、カリフォルニア 94704、米国を中心に置きます。
EMail: mjh@aciri.org
メール: mjh@aciri.org
Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive, Suite 620 Arlington, VA 22203, USA
コリンパーキンスUSC情報科学は4350年のN.フェアファクスのドライブ、アーリントン、ヴァージニア 22203、Suite620米国を設けます。
EMail: csp@isi.edu
メール: csp@isi.edu
Edmund Whelan Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK
エドモンドウィーランコンピュータサイエンス学部、ユニバーシティ・カレッジロンドン、ガウアー・ストリート、ロンドンWC1E 6BT、イギリス
EMail: e.whelan@cs.ucl.ac.uk
メール: e.whelan@cs.ucl.ac.uk
Handley, et al. Experimental [Page 16] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [16ページ]実験的なRFC2974セッション発表プロトコル2000年10月
References
参照
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP
message format", RFC 2440, November 1998.
[2] カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー。 「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format
specification version 3.3", RFC 1950, May 1996.
[3] ドイツ語、P.、およびJ.-L。 ゲイルに、「Zlibは1996年5月にデータの形式仕様バージョン3.3インチ、RFC1950を圧縮しました」。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[4] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone
announcement protocol (MZAP)", RFC 2776, February 2000.
[5] ハンドレーとM.とThalerとD.とR.カーモード、「マルチキャスト範囲ゾーン発表プロトコル(MZAP)」、RFC2776 2000年2月。
[6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.
[6]Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July
1998.
[7] マイヤー、D.、「行政上見られたIPマルチキャスト」、RFC2365、1998年7月。
Handley, et al. Experimental [Page 17] RFC 2974 Session Announcement Protocol October 2000
ハンドレー、他 [17ページ]実験的なRFC2974セッション発表プロトコル2000年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Handley, et al. Experimental [Page 18]
ハンドレー、他 実験的[18ページ]
一覧
スポンサーリンク
