[要約] RFC 7197は、セッション記述プロトコル（SDP）における重複遅延属性に関する仕様です。このRFCの目的は、SDPを使用してリアルタイム通信セッションの重複遅延を制御するための標準化を提供することです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7197 Cisco
Category: Standards Track Y. Cai
ISSN: 2070-1721 Microsoft
H. Ou
Cisco
April 2014
Duplication Delay Attribute in the Session Description Protocol
セッション記述プロトコルの複製遅延属性
Abstract
概要
A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.
最長T時間単位のネットワーク停止によるパケット損失に対する保護を提供する簡単なアプローチは、元のパケットを複製し、少なくともT時間単位だけ時間を置いて各コピーを送信することです。このアプローチは、一般に「タイムシフト冗長」、「時間的冗長」、または単に「遅延複製」と呼ばれます。このドキュメントでは、一時的に冗長なメディアストリームの存在とセッション記述プロトコルの複製遅延を示す属性を定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7197.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7197で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................4
3. The 'duplication-delay' Attribute ...............................5
4. SDP Examples ....................................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
6.1. Registration of SDP Attributes .............................9
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Inside an IP network, packet delivery may be interrupted due to failure of a physical link, interface, or device. To reduce the impact of such interruptions, some networks are built in a resilient manner, allowing for multiple alternative paths between two endpoints. However, if there is no resiliency in the network or the failure happens in a non-resilient part of the network, a temporary outage will occur (i.e., packets will get dropped). The outage will last until network reconvergence takes place (i.e., until connectivity is restored) around the failure. Typically, network reconvergence takes between tens and hundreds of milliseconds, depending on the size and features of the network.
IPネットワーク内では、物理リンク、インターフェース、またはデバイスの障害により、パケット配信が中断される場合があります。このような中断の影響を減らすために、一部のネットワークは復元力のある方法で構築され、2つのエンドポイント間の複数の代替パスを可能にします。ただし、ネットワークに復元力がない場合、またはネットワークの復元力のない部分で障害が発生した場合、一時的な停止が発生します（つまり、パケットがドロップされます）。停止は、障害の前後でネットワークの再収束が行われるまで（つまり、接続が復元されるまで）続きます。通常、ネットワークの再収束は、ネットワークのサイズと機能に応じて、数十から数百ミリ秒かかります。
There are a number of network-reconvergence technologies available today, such as IP Fast Convergence, MPLS Traffic Engineering Fast Reroute, and Multicast Only Fast Reroute. These technologies can be augmented by different types of application-layer loss-repair methods such as Forward Error Correction (FEC), retransmission, temporal redundancy, and spatial redundancy to minimize (and sometimes totally eliminate) the impact of outages. Each combination has its distinct requirements in terms of bandwidth consumption and results in a different network complexity. Thus, a network operator has to carefully consider what combination to deploy for different parts of a network (e.g., core vs. edge). A detailed overview of network-convergence technologies and loss-repair methods is provided in [IC2011].
IP高速コンバージェンス、MPLSトラフィックエンジニアリング高速リルート、マルチキャストのみ高速リルートなど、現在利用可能なネットワーク再コンバージェンステクノロジーは多数あります。これらのテクノロジーは、フォワードエラー訂正（FEC）、再送信、時間的冗長性、空間的冗長性などのさまざまなタイプのアプリケーションレイヤー損失修復方法で補強して、停止の影響を最小限に抑える（場合によっては完全に排除する）ことができます。それぞれの組み合わせには、帯域幅の消費に関して異なる要件があり、ネットワークが複雑になります。したがって、ネットワークオペレーターは、ネットワークのさまざまな部分（コアとエッジなど）に展開する組み合わせを慎重に検討する必要があります。ネットワークコンバージェンステクノロジーと損失修復方法の詳細な概要は、[IC2011]に記載されています。
One of the loss-repair methods is temporal redundancy, also known as delayed duplication. A media sender using this method transmits an original source packet and transmits its duplicate after a certain delay following the original transmission. If a network outage hits the original transmission, the expectation is that the second transmission arrives at the receiver (with a high probability). Alternatively, the second transmission may be hit by an outage and so gets dropped, and the original transmission completes successfully. Also, both transmissions can arrive on the receiver side; in that case, the receiver (or the node that does the duplicate suppression) needs to identify the duplicate packets and discard them appropriately, thereby producing a duplicate-free stream.
損失修復方法の1つは、遅延複製とも呼ばれる一時的な冗長性です。この方法を使用するメディアセンダーは、元のソースパケットを送信し、元の送信に続く一定の遅延の後に複製を送信します。ネットワークの停止が元の送信にヒットした場合、2番目の送信が受信機に到着することが予想されます（高い確率で）。あるいは、2番目の送信が停止に見舞われてドロップされ、元の送信が正常に完了する場合もあります。また、両方の送信が受信側に到着する可能性があります。その場合、レシーバー（または重複抑制を行うノード）は、重複パケットを識別して適切に破棄する必要があり、それによって重複のないストリームが生成されます。
Delayed duplication can be used in a variety of multimedia applications where there is sufficient bandwidth for the duplicated traffic and the application can tolerate the introduced delay. However, it must be used with care, since it might easily result in a new series of denial-of-service attacks. Delayed duplication is harmful in cases where the primary cause of packet loss is congestion, rather than a network outage due to a temporary link or network element failure. Duplication should only be used by endpoints that want to protect against network failures; protection against congestion must be achieved through other means, as duplication will only make congestion worse.
遅延複製は、複製されたトラフィックに十分な帯域幅があり、アプリケーションが導入された遅延を許容できるさまざまなマルチメディアアプリケーションで使用できます。ただし、新しい一連のサービス拒否攻撃を簡単に引き起こす可能性があるため、注意して使用する必要があります。遅延複製は、一時的なリンクまたはネットワーク要素の障害によるネットワークの停止ではなく、パケット損失の主な原因が輻輳である場合に有害です。複製は、ネットワーク障害から保護したいエンドポイントのみが使用する必要があります。重複は混雑を悪化させるだけなので、混雑に対する保護は他の手段によって達成されなければなりません。
One particular use case for delayed duplication is to improve the reliability of real-time video feeds inside a core IP network where bandwidth is plentiful and maximum reliability (preferably zero loss) is desired [IC2011]. Compared to other redundancy approaches such as FEC [RFC6363] and redundant data encoding (e.g., [RFC2198]), delayed duplication is easy to implement, since it does not require any special type of encoding or decoding.
遅延複製の1つの特定の使用例は、帯域幅が豊富で最大の信頼性（できれば損失ゼロ）が望まれるコアIPネットワーク内のリアルタイムビデオフィードの信頼性を向上させることです[IC2011]。 FEC [RFC6363]や冗長データエンコーディング（[RFC2198]など）などの他の冗長アプローチと比較して、遅延複製は特別なタイプのエンコーディングやデコーディングを必要としないため、実装が簡単です。
For duplicate suppression, the receiver has to be able to identify the identical packets. This is straightforward for media packets that carry one or more unique identifiers such as the sequence number field in the RTP header [RFC3550]. In non-RTP applications, the receiver can use unique sequence numbers if available or other alternative approaches to compare the incoming packets and discard the duplicate ones.
重複抑制の場合、受信側は同一のパケットを識別できる必要があります。これは、RTPヘッダーのシーケンス番号フィールド[RFC3550]などの1つ以上の一意の識別子を運ぶメディアパケットの場合は簡単です。 RTP以外のアプリケーションでは、受信側は、使用可能な場合は一意のシーケンス番号を使用するか、他の代替アプローチを使用して着信パケットを比較し、重複するものを破棄できます。
This specification introduces a new Session Description Protocol (SDP) [RFC4566] attribute for applications/services using the delayed duplication method to indicate the relative delay for each additional duplication. The attribute is used with the duplication grouping semantics defined in [RFC7104].
この仕様では、遅延複製方法を使用してアプリケーション/サービスの新しいセッション記述プロトコル（SDP）[RFC4566]属性を導入し、追加の複製ごとに相対的な遅延を示します。この属性は、[RFC7104]で定義されている複製グループ化セマンティクスで使用されます。
This specification does not explain how to select the duplication delay that a sender should use; the selection technique depends on the underlying network and the reconvergence technologies used inside such a network. This specification does not explain how the receiver should suppress the duplicate packets and merge the incoming streams to produce a loss-free and duplication-free output stream (a process commonly called "stream merging"), either. An application or a transport service that will use the delayed duplication method must determine its own rules about stream merging.
この仕様では、送信者が使用する必要がある複製遅延の選択方法については説明していません。選択手法は、基盤となるネットワークと、そのようなネットワーク内で使用される再収束テクノロジーによって異なります。この仕様では、レシーバーが重複パケットを抑制し、着信ストリームをマージして、ロスのない重複のない出力ストリーム（一般に「ストリームマージ」と呼ばれるプロセス）を生成する方法についても説明していません。遅延複製方法を使用するアプリケーションまたはトランスポートサービスは、ストリームのマージに関する独自のルールを決定する必要があります。
In practice, more than two redundant streams are unlikely to be used, since the additional delay and increased overhead are not easily justified. However, we define the new attribute in a general way so that it could be used with more than two redundant streams (i.e., multiple duplications), if needed. While the primary focus in this specification is the RTP-based transport, the new attribute is applicable to both RTP and non-RTP streams. Protocol issues and details on duplicating RTP streams are presented in [RFC7198].
実際には、2つ以上の冗長ストリームが使用されることはほとんどありません。これは、追加の遅延とオーバーヘッドの増加が簡単に正当化されないためです。ただし、必要に応じて、2つ以上の冗長ストリーム（つまり、複数の複製）で使用できるように、新しい属性を一般的な方法で定義します。この仕様の主な焦点はRTPベースのトランスポートですが、新しい属性はRTPストリームと非RTPストリームの両方に適用できます。プロトコルの問題とRTPストリームの複製に関する詳細は、[RFC7198]に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
The following ABNF [RFC5234] syntax formally describes the 'duplication-delay' attribute:
次のABNF [RFC5234]構文は、 'duplication-delay'属性を正式に説明しています。
delaying-attribute = "a=duplication-delay:" periods CRLF
periods = period *( SP period)
period = 1*DIGIT ; in milliseconds
ABNF Syntax for the 'duplication-delay' Attribute
'duplication-delay'属性のABNF構文
The 'duplication-delay' attribute is defined as both a media-level and session-level attribute. It specifies the relative delay with respect to the previous transmission of each duplication in milliseconds (ms) at the time of transmission. The following rules apply:
'duplication-delay'属性は、メディアレベルとセッションレベルの両方の属性として定義されます。送信時の各複製の前の送信に対する相対的な遅延をミリ秒（ms）で指定します。次の規則が適用されます。
o If used as a media-level attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" grouping semantics as defined in [RFC7104]. When used as a media-level attribute, the relative delay value(s) it specifies SHALL apply to every Synchronization Source (SSRC)-based duplication grouping in the same media description. In other words, one cannot specify different duplication delay values for different duplication groups in the same media description.
o メディアレベルの属性として使用する場合は、[RFC7104]で定義されている「ssrc-group」属性および「DUP」グループ化セマンティクスとともに使用する必要があります。メディアレベルの属性として使用する場合、指定する相対遅延値は、同じメディア記述内のすべての同期ソース（SSRC）ベースの複製グループに適用する必要があります（SHALL）。つまり、同じメディア記述内の異なる複製グループに異なる複製遅延値を指定することはできません。
o If used as a session-level attribute, it MUST be used with 'group' attribute and "DUP" grouping semantics as defined in [RFC7104]. When used as a session-level attribute, the relative delay value(s) it specifies SHALL apply to every duplication grouping in the same SDP description. In other words, one cannot specify different duplication delay values for different duplication groups in the same SDP description. If one needs to specify different duplication delay values for different duplication groups, then one MUST use different SDP descriptions for each or MUST use the 'duplication-delay' attribute at the media level. In that case, the 'duplication-delay' attribute MUST NOT be used at the session level.
o セッションレベルの属性として使用する場合は、[RFC7104]で定義されている「グループ」属性および「DUP」グループ化セマンティクスとともに使用する必要があります。セッションレベルの属性として使用する場合、指定する相対遅延値は、同じSDP記述内のすべての複製グループに適用する必要があります（SHALL）。つまり、同じSDP記述内の異なる複製グループに異なる複製遅延値を指定することはできません。異なる複製グループに異なる複製遅延値を指定する必要がある場合は、それぞれに異なるSDP記述を使用するか、メディアレベルで 'duplication-delay'属性を使用する必要があります。その場合、 'duplication-delay'属性をセッションレベルで使用してはなりません（MUST NOT）。
o For offer/answer model considerations, refer to [RFC7104].
o オファー/アンサーモデルの考慮事項については、[RFC7104]を参照してください。
In the first example below, the multicast stream consists of two RTP streams, each duplicated once, resulting in two sets of two-stream groups. The same duplication delay of 100 ms is applied to each grouping. The first set's streams have SSRCs of 1000 and 1010, and the second set's streams have SSRCs of 1020 and 1030.
以下の最初の例では、マルチキャストストリームは2つのRTPストリームで構成されており、それぞれが1回複製されるため、2セットの2ストリームグループになります。 100ミリ秒の同じ複製遅延が各グループに適用されます。最初のセットのストリームのSSRCは1000と1010で、2番目のセットのストリームのSSRCは1020と1030です。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100 101
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=rtpmap:101 MP2T/90000
a=ssrc:1020 cname:ch1b@example.com
a=ssrc:1030 cname:ch1b@example.com
a=ssrc-group:DUP 1020 1030
a=duplication-delay:100
a=mid:Ch1
Note that in actual use, SSRC values, which are random 32-bit numbers, could be much larger than the ones shown in this example.
実際の使用では、ランダムな32ビットの数値であるSSRC値は、この例に示されている値よりはるかに大きくなる可能性があることに注意してください。
In the second example below, the multicast stream is duplicated twice. 50 ms after the original transmission, the first duplicate is transmitted, and 100 ms after that, the second duplicate is transmitted. In other words, the same packet is transmitted three times over a period of 150 ms.
次の2番目の例では、マルチキャストストリームが2回複製されています。最初の送信から50ミリ秒後に最初の複製が送信され、その後100ミリ秒後に2番目の複製が送信されます。つまり、同じパケットが150 msの期間に3回送信されます。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1c@example.com
a=ssrc:1010 cname:ch1c@example.com
a=ssrc:1020 cname:ch1c@example.com
a=ssrc-group:DUP 1000 1010 1020
a=duplication-delay:50 100
a=mid:Ch1
In the third example below, the multicast UDP stream is duplicated with a duplication delay of 50 ms. Redundant streams are sent in separate source-specific multicast (SSM) sessions, so the receiving host has to join both SSM sessions if it wants to receive both streams.
次の3番目の例では、マルチキャストUDPストリームが複製され、複製遅延は50ミリ秒です。冗長ストリームは個別のSource-Specific Multicast（SSM）セッションで送信されるため、両方のストリームを受信する場合、受信ホストは両方のSSMセッションに参加する必要があります。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
a=group:DUP S1a S1b
a=duplication-delay:50
m=audio 30000 udp mp4
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=mid:S1a
m=audio 40000 udp mp4
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=mid:S1b
The 'duplication-delay' attribute is not believed to introduce any significant security risk to multimedia applications. A malevolent third party could use this attribute to misguide the receiver(s) about the duplication delays and/or the number of redundant streams. For example, if the malevolent third party increases the value of the duplication delay, the receiver(s) will unnecessarily incur a longer delay, since they will have to wait for the entire period. Or, if the duplication delay is reduced by the malevolent third party, the receiver(s) might not wait long enough for the duplicated transmission and incur unnecessary packet losses. However, these require intercepting and rewriting the packets carrying the SDP description; if an interceptor can do that, many more attacks are also possible.
'duplication-delay'属性は、マルチメディアアプリケーションに重大なセキュリティリスクをもたらすとは考えられていません。悪意のある第三者がこの属性を使用して、複製の遅延や冗長ストリームの数について受信者に誤解を与える可能性があります。たとえば、悪意のある第三者が複製遅延の値を増やす場合、受信者は期間全体を待たなければならないため、不必要に長い遅延が発生します。または、悪意のあるサードパーティによって複製の遅延が減少した場合、受信者は複製の送信を十分に長く待たず、不必要なパケット損失が発生する可能性があります。ただし、これらはSDP記述を含むパケットを傍受して書き換える必要があります。インターセプターがそれを実行できる場合、さらに多くの攻撃も可能です。
In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well.
この種の攻撃を回避するには、SDP記述を整合性保護し、ソース認証を提供する必要があります。これは、たとえば、S / MIME [RFC5652] [RFC5751]を使用してエンドツーエンドで、MIMEタイプ（application / sdp）を使用するシグナリングパケットでSDPが使用されている場合に実現できます。あるいは、HTTPS [RFC2818]またはSession Announcement Protocol（SAP）[RFC2974]の認証方法も使用できます。
Another security risk is due to possible software misconfiguration or a software bug where a large number of duplicates could be unwillingly signaled in the 'duplication-delay' attribute. Similarly, an attacker can use this attribute to start a denial-of-service attack by signaling and sending too many duplicated streams. In applications where this attribute is to be used, it is a good practice to put a hard limit on both the number of duplicate streams and the total delay introduced due to duplication, regardless of what the SDP description specifies.
もう1つのセキュリティリスクは、ソフトウェアの誤設定の可能性、または「duplication-delay」属性で大量の重複が意に反して通知される可能性があるソフトウェアのバグが原因です。同様に、攻撃者はこの属性を使用して、重複したストリームをシグナリングして送信することにより、サービス拒否攻撃を開始できます。この属性が使用されるアプリケーションでは、SDPの説明で何が指定されているかに関係なく、複製ストリームの数と、複製によって導入される合計遅延の両方にハード制限を設定することをお勧めします。
Since this mechanism causes duplication of media packets, if those packets are also cryptographically protected (e.g., encrypted) then such duplication could act as an accelerator if any Million Message [RFC3218] or similar attack such as Lucky 13 [Lucky13] exists against the security mechanism that is in use. Such acceleration could turn an otherwise infeasible attack into one that is practical; however, assuming that the amount of duplication is small and that such weak or broken security mechanisms should really not be used, the overall security impact of the duplication should be minimal. If, however, a bad actor were in control of the SDP but did not have access to the keying material used for media, then such a bad actor could potentially use the SDP to cause the media handling to use a weak or broken mechanism with a lot of duplication, in which case the duplication could be significant. Deployments where the SDP is controlled by an actor who should not have access to the media keying material should therefore be cautious in their use of this duplication mechanism.
このメカニズムはメディアパケットの複製を引き起こすため、これらのパケットも暗号で保護（暗号化など）されている場合、ミリオンメッセージ[RFC3218]または同様の攻撃（ラッキー13 [Lucky13]など）がセキュリティに対して存在する場合、そのような複製はアクセラレータとして機能する可能性があります使用中のメカニズム。そのような加速は、そうでなければ実行不可能な攻撃を実用的なものに変える可能性があります。ただし、複製の量が少なく、そのような弱いまたは壊れたセキュリティメカニズムを実際に使用するべきではないと仮定すると、複製の全体的なセキュリティへの影響は最小限に抑えられます。ただし、悪意のあるアクターがSDPを制御していても、メディアに使用されるキーイング情報にアクセスできなかった場合、そのような悪意のあるアクターはSDPを使用して、メディア処理で脆弱なメカニズムまたは壊れたメカニズムを使用する可能性があります。多くの重複。その場合、重複は重要になる可能性があります。そのため、メディアキーイング資料にアクセスできないアクターによってSDPが制御される配置では、この複製メカニズムの使用に注意する必要があります。
If this mechanism were used in conjunction with a source description (SDES) and if the key being used for media protection is derived from a human-memorable or otherwise dictionary-attackable secret, then the duplication done here could allow for a more efficient dictionary attack against the media. The right countermeasure is to use proper keying or, if using an SDES, to ensure that the keys used are not dictionary-attackable.
このメカニズムがソース記述（SDES）と組み合わせて使用され、メディア保護に使用されているキーが人間が記憶できる、またはその他の方法で辞書攻撃可能なシークレットから派生している場合、ここで行われる複製により、より効率的な辞書攻撃が可能になります。メディアに対して。適切な対策は、適切なキーイングを使用するか、SDESを使用している場合は、使用するキーが辞書攻撃を受けないようにすることです。
The following contact information shall be used for the registration in this document:
この文書への登録には、次の連絡先情報を使用するものとします。
Ali Begen abegen@cisco.com
Ali Begen abegen@cisco.com
This document registers a new attribute name in SDP.
このドキュメントでは、SDPに新しい属性名を登録します。
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name: duplication-delay Long form: Duplication delay for temporally redundant streams Type of name: att-field Type of attribute: Media or session level Subject to charset: No Purpose: Specifies the relative duplication delay(s) for redundant stream(s) Reference: [RFC7197] Values: See [RFC7197]
属性名：複製遅延長い形式：時間的に冗長なストリームの複製遅延名前のタイプ：att-field属性のタイプ：メディアまたはセッションレベル文字セットの対象：いいえ目的：冗長ストリームの相対複製遅延を指定します）参照：[RFC7197]値：[RFC7197]を参照
The authors would like to thank Colin Perkins, Paul Kyzivat, and Stephen Farrell for their suggestions and reviews.
著者は、提案とレビューをしてくれたColin Perkins、Paul Kyzivat、Stephen Farrellに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, January 2014.
[RFC7104] Begen、A.、Cai、Y。、およびH. Ou、「Session Description Protocolの重複グループ化セマンティクス」、RFC 7104、2014年1月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]パーキンス、C。、クーベラス、I。、ホドソン、O。、ハードマン、V。、ハンドラリー、M。、ボロット、J。、ベガ-ガルシア、A。、およびS.フォセ-パリシス、「RTPペイロードfor Redundant Audio Data」、RFC 2198、1997年9月。
[RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC 7198, April 2014.
[RFC7198] Begen、A。およびC. Perkins、「Duplicating RTP Streams」、RFC 7198、2014年4月。
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport", IEEE Internet Computing, Vol. 15, No. 6, pp. 48-57, November 2011.
[IC2011] Evans、J.、Begen、A.、Greengrass、J.、and C. Filsfils、 "Toward Lossless Video Transport"、IEEE Internet Computing、Vol。 15、No。6、pp。48-57、2011年11月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.
[RFC3218] Rescorla、E。、「Preventing the Million Message Attack on Cryptographic Message Syntax」、RFC 3218、2002年1月。
[Lucky13] AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols", IEEE Symposium on Security and Privacy, May 2013, <http://ieeexplore.ieee.org/xpl/articleDetails.jsp? tp=&arnumber=6547131&queryText%3DLucky+Thirteen>.
[Lucky13] AlFardan、N。およびK. Paterson、「Lucky Thirteen：Breaking the TLS and DTLS Record Protocols」、IEEE Symposium on Security and Privacy、2013年5月、<http://ieeexplore.ieee.org/xpl/articleDetails。 jsp？ tp =＆arnumber = 6547131＆queryText％3DLucky + Thirteen>。
Authors' Addresses
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Streetトロント、ON M5J 2T3カナダ
EMail: abegen@cisco.com
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
Y IグループCAI Microsoft 1065 LA av EN IDAマウンテンビュー、CA 94043米国
EMail: yiqunc@microsoft.com
Heidi Ou Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA
Heidi Ou Cisco 170 W. Tasman Dr. San Jose、CA 95134 USA
EMail: hou@cisco.com