[要約] RFC 7879は、SIPバックトゥバックユーザーエージェントでのDTLS-SRTP処理に関するガイドラインです。目的は、セキュアなメディア通信を提供するために、DTLS-SRTPプロトコルの適切な実装と処理方法を定義することです。
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7879 T. Reddy
Category: Standards Track G. Salgueiro
ISSN: 2070-1721 Cisco
V. Pascual
Oracle
P. Ravindran
Nokia Networks
May 2016
DTLS-SRTP Handling in SIP Back-to-Back User Agents
SIPバックツーバックユーザーエージェントでのDTLS-SRTP処理
Abstract
概要
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.
セッション開始プロトコル（SIP）バックツーバックユーザーエージェント（B2BUA）は、エンドポイント間のシグナリングおよびメディアパス上に存在します。このドキュメントでは、セキュアリアルタイムトランスポート（SRTP）セキュリティコンテキストがデータグラムトランスポート層セキュリティ（DTLS）プロトコルで設定されている場合のB2BUAの動作について説明します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7879.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7879で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Goals and Scope of this Document . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP . . . . . . . 5
4. Signaling-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . 5
4.1. Proxy-B2BUAs . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling-Only and SDP-Modifying Signaling-Only B2BUAs . 6
5. Media-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. RTP- and RTCP-Aware Media-Aware B2BUA . . . . . . . . 8
6. Forking Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
[RFC5763] describes how the Session Initiation Protocol (SIP) [RFC3261] can be used to establish a Secure Real-time Transport Protocol (SRTP) [RFC3711] security context with the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. It describes a mechanism for transporting a certificate fingerprint using the Session Description Protocol (SDP) [RFC4566]. The fingerprint identifies the certificate that will be presented during the DTLS handshake. DTLS-SRTP is currently defined for point-to-point media sessions, in which there are exactly two participants. Each DTLS-SRTP session (described in Section 3 of [RFC5764]) contains a single DTLS connection (if RTP and RTP Control Protocol (RTCP) are multiplexed) or two DTLS connections (if RTP and RTCP are not multiplexed), and either two SRTP contexts (if media traffic is flowing in both directions on the same 5-tuple) or one SRTP context (if media traffic is only flowing in one direction).
[RFC5763]は、Session Initiation Protocol（SIP）[RFC3261]を使用して、Secure Real-time Transport Protocol（SRTP）[RFC3711]セキュリティコンテキストをDatagram Transport Layer Security（DTLS）プロトコル[RFC6347]で確立する方法を説明しています。セッション記述プロトコル（SDP）[RFC4566]を使用して証明書のフィンガープリントを転送するメカニズムについて説明しています。フィンガープリントは、DTLSハンドシェイク中に提示される証明書を識別します。 DTLS-SRTPは現在、ポイントツーポイントメディアセッションに対して定義されており、参加者はちょうど2人です。各DTLS-SRTPセッション（[RFC5764]のセクション3で説明）には、単一のDTLS接続（RTPとRTP制御プロトコル（RTCP）が多重化されている場合）または2つのDTLS接続（RTPとRTCPが多重化されていない場合）、および2つSRTPコンテキスト（メディアトラフィックが同じ5タプルで双方向に流れる場合）または1つのSRTPコンテキスト（メディアトラフィックが一方向にのみ流れる場合）。
In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) entities exist on the SIP-signaling path between the endpoints. As described in [RFC7092], these B2BUAs can modify SIP and SDP information. For example, as described in Section 3.1.3 of [RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify the SDP. B2BUAs can also be present on the media path, in which case they modify parts of the SDP information (like IP address, port) and subsequently modify the RTP headers as well. Such B2BUAs are referred to as "media-plane B2BUAs". [RFC7092] describes two different categories of media-plane B2BUAs, according to the level of activities performed on the media plane.
多くのSIP展開では、エンドポイント間のSIPシグナリングパスにSIPバックツーバックユーザーエージェント（B2BUA）エンティティが存在します。 [RFC7092]で説明されているように、これらのB2BUAはSIPおよびSDP情報を変更できます。たとえば、[RFC7092]のセクション3.1.3で説明されているように、SDP変更シグナリングのみのB2BUAは、SDPを変更する可能性があります。 B2BUAは、メディアパス上にも存在できます。その場合、B2BUAはSDP情報の一部（IPアドレス、ポートなど）を変更し、続いてRTPヘッダーも変更します。このようなB2BUAは、「メディアプレーンB2BUA」と呼ばれます。 [RFC7092]は、メディアプレーンで実行されるアクティビティのレベルに応じて、メディアプレーンB2BUAの2つの異なるカテゴリについて説明しています。
When B2BUAs are present in a call between two SIP User Agents (UAs), they often make end-to-end DTLS-SRTP sessions impossible. An "end-to-end DTLS-SRTP session" means that man-in-the-middle devices cannot break the DTLS-SRTP session between the endpoints. In other words, the man-in-the-middle device cannot create a separate DTLS-SRTP session between the client and the middle device on one side, and the middle device and the remote peer on the other side. B2BUAs may be deployed for address hiding or media latching [RFC7362], although Traversal Using Relays around NAT (TURN) and Interactive Connectivity Establishment (ICE) are expected to be used more often for this purpose as it provides better security properties. Such B2BUAs are able to perform their functions without requiring termination of DTLS-SRTP sessions, i.e., these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.
2つのSIPユーザーエージェント（UA）間のコールにB2BUAが存在する場合、B2BUAによってエンドツーエンドのDTLS-SRTPセッションが不可能になることがよくあります。 「エンドツーエンドのDTLS-SRTPセッション」とは、中間者デバイスがエンドポイント間のDTLS-SRTPセッションを中断できないことを意味します。つまり、man-in-the-middleデバイスは、クライアントと中間デバイス、および中間デバイスとリモートピアの間に別のDTLS-SRTPセッションを作成できません。 B2BUAはアドレス隠蔽またはメディアラッチ[RFC7362]に展開できますが、NAT（TURN）とインタラクティブ接続確立（ICE）のリレーを使用したトラバーサルは、より優れたセキュリティプロパティを提供するため、この目的でより頻繁に使用されると予想されます。このようなB2BUAは、DTLS-SRTPセッションの終了を必要とせずに機能を実行できます。つまり、これらのB2BUAは、DTLSプロキシとして機能し、RTPペイロードを復号化する必要はありません。
A B2BUA could be deployed for address hiding or media latching as described in [RFC7362]. Such B2BUAs only terminate the media plane at the IP and transport (UDP/TCP) layers and may inspect the RTP headers or RTP Control Protocol (RTCP) packets. The goal of this specification is to provide guidance on how such B2BUAs function without breaking the end-to-end DTLS-SRTP session. A B2BUA could also terminate the media, or modify the RTP headers or RTP Control Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-SRTP. The recommendations made in this document are not expected to be applied by B2BUAs terminating DTLS-SRTP sessions given deployment reality.
[RFC7362]で説明されているように、B2BUAはアドレス非表示またはメディアラッチ用に展開できます。このようなB2BUAは、メディアプレーンをIPおよびトランスポート（UDP / TCP）レイヤーでのみ終端し、RTPヘッダーまたはRTP制御プロトコル（RTCP）パケットを検査する場合があります。この仕様の目標は、エンドツーエンドのDTLS-SRTPセッションを中断することなく、そのようなB2BUAがどのように機能するかについてのガイダンスを提供することです。 B2BUAは、メディアを終端したり、RTPヘッダーやRTP制御プロトコル（RTCP）パケットを変更したりすることもできます。このようなB2BUAは、エンドツーエンドのDTLS-SRTPを許可しません。このドキュメントで行われた推奨事項は、展開の現実を考慮して、DTLS-SRTPセッションを終了するB2BUAによって適用されることは想定されていません。
This specification assumes that a B2BUA is not providing identity assurance and is not authorized to terminate the DTLS-SRTP session. A B2BUA that provides identity assurance on behalf of endpoints behind it can modify any portion of SIP and SDP before it generates the identity signature. As the B2BUA is generating the identity signature, it is not possible to detect if a B2BUA has terminated the DTLS-SRTP session. B2BUAs providing identity assurance and terminating DTLS-SRTP sessions are out of scope of this document.
この仕様は、B2BUAがID保証を提供しておらず、DTLS-SRTPセッションの終了を許可されていないことを前提としています。背後のエンドポイントに代わってID保証を提供するB2BUAは、ID署名を生成する前にSIPおよびSDPの任意の部分を変更できます。 B2BUAがID署名を生成しているため、B2BUAがDTLS-SRTPセッションを終了したかどうかを検出することはできません。 ID保証を提供し、DTLS-SRTPセッションを終了するB2BUAは、このドキュメントの範囲外です。
The following sections describe the behavior B2BUAs can follow to avoid breaking end-to-end DTLS-SRTP sessions.
以下のセクションでは、エンドツーエンドのDTLS-SRTPセッションの中断を回避するためにB2BUAが従うことができる動作について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Transport Address: The combination of an IP address and port number.
トランスポートアドレス：IPアドレスとポート番号の組み合わせ。
The following generalized terms are defined in [RFC3261], Section 6.
次の一般的な用語は、[RFC3261]のセクション6で定義されています。
B2BUA: A SIP Back-to-Back User Agent, which is the logical combination of a User Agent Server (UAS) and a User Agent Client (UAC).
B2BUA：SIPバックツーバックユーザーエージェント。ユーザーエージェントサーバー（UAS）とユーザーエージェントクライアント（UAC）の論理的な組み合わせです。
UAS: A SIP User Agent Server.
UAS：SIPユーザーエージェントサーバー。
UAC: A SIP User Agent Client.
UAC：SIPユーザーエージェントクライアント。
All of the pertinent B2BUA terminology and taxonomy used in this document are based on [RFC7092].
このドキュメントで使用されている関連するすべてのB2BUA用語と分類法は、[RFC7092]に基づいています。
It is assumed the reader is already familiar with the fundamental concepts of the RTP protocol [RFC3550] and its taxonomy [RFC7656], as well as those of SRTP [RFC3711] and DTLS [RFC6347].
読者は、RTPプロトコル[RFC3550]とその分類法[RFC7656]、およびSRTP [RFC3711]とDTLS [RFC6347]の基本概念にすでに精通していることを前提としています。
A B2BUA MUST follow the rules mentioned below to allow end-to-end DTLS-SRTP sessions.
B2BUAは、エンドツーエンドのDTLS-SRTPセッションを許可するために、下記のルールに従う必要があります。
1. B2BUAs MUST forward the certificate fingerprint and SDP setup attribute it receives from one endpoint unmodified towards the other endpoint and vice versa.
1. B2BUAは、1つのエンドポイントから受信した証明書のフィンガープリントとSDPセットアップ属性を変更せずに他のエンドポイントに転送する必要があります。
2. The enhancements described in [RFC4474] provide a means for signing portions of SIP requests in order to provide identity assurance and certificate pinning by providing an identity signature over the SDP that carries the fingerprint of keying for DTLS-SRTP [RFC5763]. B2BUAs can identify that the enhancements in [RFC4474] are used for identity assurance if the SIP request contains both Identity and Identity-Info headers. In cases where endpoints use [RFC4474], B2BUAs MUST ensure that it does not modify any of the information used to construct the identity signature. This includes the entire SDP body and portions of the SIP header as described in [RFC4474]. In this case, a B2BUA cannot act as a media-relay B2BUA.
2. [RFC4474]で説明されている拡張機能は、DTLS-SRTP [RFC5763]のキーイングのフィンガープリントを運ぶSDPを介してID署名を提供することにより、ID保証と証明書ピン留めを提供するためにSIPリクエストの一部に署名する手段を提供します。 B2BUAは、[RFC4474]の拡張機能が、SIP要求にIdentityヘッダーとIdentity-Infoヘッダーの両方が含まれている場合、ID保証に使用されることを識別できます。エンドポイントが[RFC4474]を使用する場合、B2BUAは、アイデンティティ署名の構築に使用される情報を変更しないことを保証しなければなりません（MUST）。これには、[RFC4474]で説明されているように、SDP本体全体とSIPヘッダーの一部が含まれます。この場合、B2BUAはメディアリレーB2BUAとして機能できません。
3. [SIP-ID] is introduced to overcome the limitations of [RFC4474] (discussed in Section 1 of [SIP-ID]). Unlike [RFC4474], [SIP-ID] does not generate an identity signature over material that intermediaries in the field commonly alter. In this case, a B2BUA can act as a media-relay B2BUA. B2BUAs can identify that [SIP-ID] is used for identity assurance if the SIP request contains an Identity header but does not include an Identity-Info header. The Identity-Info header is deprecated in [SIP-ID]. A B2BUA MUST ensure that it does not modify any of the headers used to construct the identity signature.
3. [SIP-ID]は、[RFC4474]（[SIP-ID]のセクション1で説明）の制限を克服するために導入されました。 [RFC4474]とは異なり、[SIP-ID]は、現場の仲介者が一般的に変更する資料に対してID署名を生成しません。この場合、B2BUAはメディアリレーB2BUAとして機能できます。 B2BUAは、SIPリクエストにIdentityヘッダーが含まれているがIdentity-Infoヘッダーが含まれていない場合、[SIP-ID]がID保証に使用されていることを識別できます。 Identity-Infoヘッダーは[SIP-ID]で非推奨になりました。 B2BUAは、ID署名の構築に使用されるヘッダーが変更されないようにする必要があります。
4. Both media relays and media-aware relays MUST NOT modify the authenticated portion of RTP and RTCP packets, and MUST NOT modify the authentication tag in the RTP and RTCP packets.
4. メディアリレーとメディアアウェアリレーはどちらも、RTPパケットとRTCPパケットの認証済み部分を変更してはならず、RTPパケットとRTCPパケット内の認証タグを変更してはなりません。
Section 3.1 of [RFC7092] describes different categories of signaling-plane B2BUAs. This section explains how these B2BUAs are expected to comply with the recommendations in Section 3.
[RFC7092]のセクション3.1は、シグナリングプレーンB2BUAのさまざまなカテゴリについて説明しています。このセクションでは、これらのB2BUAがセクション3の推奨事項に準拠することが期待される方法について説明します。
Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only the Via and Record-Route SIP headers. These B2BUAs can continue to perform their function and still allow end-to-end DTLS-SRTP sessions since none of the headers used to construct the identity signature are modified.
[RFC7092]のセクション3.1.1で定義されているProxy-B2BUAは、ViaおよびRecord-Route SIPヘッダーのみを変更します。これらのB2BUAは、ID署名の作成に使用されるヘッダーが変更されていないため、引き続き機能を実行し、エンドツーエンドのDTLS-SRTPセッションを許可できます。
These categories of B2BUAs are likely to modify headers that are used to construct the identity signature. For example, a signaling-only B2BUA can modify the Contact URI. Such B2BUAs are likely to violate rule 2 or rule 3 in Section 3. Depending upon the application requirements, such a B2BUA may be able to limit modification of header fields to those allowed to be modified by [RFC4474] or [SIP-ID].
B2BUAのこれらのカテゴリは、ID署名の構築に使用されるヘッダーを変更する可能性があります。たとえば、シグナリングのみのB2BUAは連絡先URIを変更できます。このようなB2BUAは、セクション3のルール2またはルール3に違反する可能性があります。アプリケーション要件によっては、このようなB2BUAは、ヘッダーフィールドの変更を、[RFC4474]または[SIP-ID]による変更が許可されているフィールドに制限できる場合があります。
This section describes how the different types of media-plane B2BUAs defined in [RFC7092] are expected to comply with the recommendations in Section 3.
このセクションでは、[RFC7092]で定義されているさまざまなタイプのメディアプレーンB2BUAがセクション3の推奨事項にどのように準拠することが期待されるかについて説明します。
From an application-layer point of view, a media relay (as defined in Section 3.2.1 of [RFC7092]) forwards all packets it receives on a negotiated connection, without inspecting or modifying the packet contents. A media relay only modifies the transport layer (UDP/TCP) and IP headers.
アプリケーション層の観点から、メディアリレー（[RFC7092]のセクション3.2.1で定義）は、パケットの内容を検査または変更せずに、ネゴシエートされた接続で受信したすべてのパケットを転送します。メディアリレーは、トランスポート層（UDP / TCP）とIPヘッダーのみを変更します。
A media-relay B2BUA follows rule 1 mentioned in Section 3 and forwards the certificate fingerprint and SDP setup attribute it receives from one endpoint unmodified towards the other endpoint and vice versa. The following example shows a SIP call establishment flow, with both SIP endpoints (user agents) using DTLS-SRTP, and a media-relay B2BUA.
メディアリレーB2BUAは、セクション3で説明したルール1に従い、1つのエンドポイントから受信した証明書のフィンガープリントとSDPセットアップ属性を変更せずに他のエンドポイントに転送します。次の例は、DTLS-SRTPを使用するSIPエンドポイント（ユーザーエージェント）とメディアリレーB2BUAの両方を使用したSIPコール確立フローを示しています。
+-------+ +-------------------+ +-----+
| Alice | | Media-Relay B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE | (3) INVITE |
| a=setup:actpass | a=setup:actpass |
| a=fingerprint1 | a=fingerprint1 |
| (Alice's IP/port) | (B2BUAs IP/port) |
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | |
| | (5) 200 OK |
| | a=setup:active |
| | a=fingerprint2 |
| | (Bob's IP/port) |
|<------------------------|<--------------------------|
| (6) 200 OK | |
| a=setup:active | |
| a=fingerprint2 | |
| B2BUAs IP/port | |
| (7, 8) ClientHello + use_srtp |
|<----------------------------------------------------|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (9,10) ServerHello + use_srtp |
|---------------------------------------------------->|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (11) | |
| [Certificate exchange between Alice and Bob over |
| DTLS ] | |
| | |
| (12) | |
|<---------SRTP/SRTCP-----------SRTP/SRTCP----------->|
| [B2BUA changes transport(UDP/TCP) and IP headers] |
Figure 1: INVITE with SDP Call Flow for Media-Relay B2BUA
図1：Media-Relay B2BUAのSDPコールフローを使用したINVITE
Note: For brevity, the entire value of the SDP fingerprint attribute is not shown. The example here shows only one DTLS connection for the sake of simplicity. In reality, depending on whether the RTP and RTCP flows are multiplexed or demultiplexed, there will be one or two DTLS connections.
注：簡潔にするため、SDPフィンガープリント属性の値全体は表示されていません。ここの例では、簡単にするために1つのDTLS接続のみを示しています。実際には、RTPフローとRTCPフローが多重化されているか、逆多重化されているかに応じて、1つまたは2つのDTLS接続が存在します。
If RTP and RTCP traffic is multiplexed on a single port as described in [RFC5761], then only a single DTLS connection is required between the peers. If RTP and RTCP are not multiplexed, then the peers would have to establish two DTLS connections. In this case, after receiving an INVITE request, Bob triggers the establishment of a DTLS connection. Note that the DTLS handshake and the sending of the INVITE response can happen in parallel; thus, the B2BUA has to be prepared to receive DTLS, Session Traversal Utilities for NAT (STUN), and media on the ports it advertised to Bob in the SDP offer before it receives an SDP answer from Bob. Since a media-relay B2BUA does not differentiate between a DTLS message, RTP, or any packet it receives, it only changes the transport layer (UDP/TCP) and IP headers and forwards the packet towards the other endpoint. The B2BUA cannot decrypt the RTP payload, as the payload is encrypted using the SRTP keys derived from the DTLS connection setup between Alice and Bob.
[RFC5761]で説明されているように、RTPおよびRTCPトラフィックが単一のポートで多重化されている場合、ピア間に必要なのは単一のDTLS接続のみです。 RTPとRTCPが多重化されていない場合、ピアは2つのDTLS接続を確立する必要があります。この場合、INVITE要求を受信した後、BobはDTLS接続の確立をトリガーします。 DTLSハンドシェイクとINVITE応答の送信は並行して発生する可能性があることに注意してください。したがって、B2BUAは、ボブからSDP応答を受信する前に、DTLS、NAT用セッショントラバーサルユーティリティ（STUN）、およびボブにSDPオファーでアドバタイズしたポート上のメディアを受信する準備をする必要があります。メディアリレーB2BUAは、DTLSメッセージ、RTP、または受信するパケットを区別しないため、トランスポート層（UDP / TCP）とIPヘッダーのみを変更し、パケットを他のエンドポイントに転送します。 B2BUAはRTPペイロードを復号化できません。これは、ペイロードがAliceとBobの間のDTLS接続設定から派生したSRTPキーを使用して暗号化されているためです。
If the endpoints use [RFC4474], a B2BUA cannot function as a media-relay without violating rule 2 in Section 3. If [SIP-ID] is used, a B2BUA can modify the IP address in the c= line and the port in the m= line in the SDP as long as it does not otherwise violate rule 3 in Section 3.
エンドポイントが[RFC4474]を使用する場合、B2BUAはセクション3のルール2に違反しないとメディアリレーとして機能できません。[SIP-ID]が使用される場合、B2BUAはc =行のIPアドレスとセクション3のルール3に違反しない限り、SDPのm =行。
Unlike the media relay discussed in Section 5.1.1, a media-aware relay as defined in Section 3.2.2 of [RFC7092] is aware of the type of media traffic it is receiving. There are two types of media-aware relays, those that merely inspect the RTP headers and unencrypted portions of RTCP packets, and those that inspect and modify the RTP headers and unencrypted portions of RTCP packets.
セクション5.1.1で説明したメディアリレーとは異なり、[RFC7092]のセクション3.2.2で定義されているメディア認識リレーは、受信するメディアトラフィックのタイプを認識しています。メディア対応リレーには、RTPヘッダーとRTCPパケットの暗号化されていない部分を単に検査するリレーと、RTPヘッダーとRTCPパケットの暗号化されていない部分を検査して変更するリレーの2種類があります。
An RTP-/RTCP-aware media relay does not modify the RTP headers and RTCP packets but only inspects the packets. Such B2BUAs follow rule 4 in Section 3 and can continue to do their function while allowing end-to-end DTLS-SRTP. Inspection by the B2BUA will not reveal the clear-text for encrypted parts of the SRTP/SRTCP packets.
RTP / RTCP対応のメディアリレーは、RTPヘッダーとRTCPパケットを変更せず、パケットを検査するだけです。このようなB2BUAは、セクション3のルール4に従い、エンドツーエンドのDTLS-SRTPを許可しながら機能を継続できます。 B2BUAによる検査では、SRTP / SRTCPパケットの暗号化された部分のクリアテキストは明らかになりません。
A B2BUA cannot modify RTP headers or RTCP packets, as to do so it would need to act as a DTLS endpoint, terminate the DTLS-SRTP session, and decrypt/re-encrypt RTP packets. If a B2BUA modifies unencrypted or encrypted portions of the RTP or RTCP packets, then the integrity check will fail and the packet will be dropped by the endpoint. The unencrypted and encrypted portions of the RTP or RTCP packets are integrity protected using the HMAC algorithm negotiated during the DTLS handshake (discussed in Section 4.1.2 of [RFC5764]). B2BUAs have to follow the rules in Section 3 to avoid breaking the integrity of SRTP/SRTCP streams.
B2BUAは、RTPヘッダーまたはRTCPパケットを変更できません。そのためには、DTLSエンドポイントとして機能し、DTLS-SRTPセッションを終了し、RTPパケットを復号化/再暗号化する必要があります。 B2BUAがRTPまたはRTCPパケットの暗号化されていない部分または暗号化されている部分を変更すると、整合性チェックは失敗し、パケットはエンドポイントによってドロップされます。 RTPまたはRTCPパケットの暗号化されていない部分と暗号化されている部分は、DTLSハンドシェイク中にネゴシエートされたHMACアルゴリズムを使用して完全性が保護されます（[RFC5764]のセクション4.1.2で説明）。 B2BUAは、SRTP / SRTCPストリームの整合性を壊さないように、セクション3のルールに従う必要があります。
Due to forking [RFC3261], a SIP request carrying an SDP offer sent by an endpoint (offerer) can reach multiple remote endpoints. As a result, multiple DTLS-SRTP sessions can be established, one between the endpoint that sent the SIP request and each of the remote endpoints that received the request. B2BUAs have to follow rule 1 in Section 3 while handling offer/answer and forward the certificate fingerprints and SDP setup attributes it received in the SDP answer from each endpoint (answerer) unmodified towards the offerer. Since each DTLS connection is set up on a unique 5-tuple, B2BUA replaces the answerer's transport addresses in each answer with its unique transport addresses so that the offerer can establish a DTLS connection with each answerer. The B2BUA, acting as a media relay here, follows rule 4 mentioned in Section 3.
フォーク[RFC3261]により、エンドポイント（オファー）によって送信されたSDPオファーを運ぶSIPリクエストは、複数のリモートエンドポイントに到達できます。その結果、SIP要求を送信したエンドポイントと、要求を受信した各リモートエンドポイントの間に1つずつ、複数のDTLS-SRTPセッションを確立できます。 B2BUAは、オファー/アンサーを処理する間、セクション3のルール1に従い、変更されていない各エンドポイント（アンサー）からSDP回答で受け取った証明書フィンガープリントとSDPセットアップ属性を提供者に転送する必要があります。各DTLS接続は一意の5タプルに設定されているため、B2BUAは各回答の回答者のトランスポートアドレスを一意のトランスポートアドレスに置き換え、提供者が各回答者とのDTLS接続を確立できるようにします。ここでメディアリレーとして機能するB2BUAは、セクション3で述べたルール4に従います。
Bob (192.0.2.1:6666)
/
/
/ DTLS-SRTP=XXX
/
/
DTLS-SRTP=XXX v
<-----------> (192.0.2.3:7777)
Alice (192.0.2.0:5555) B2BUA
<-----------> (192.0.2.3:8888)
DTLS-SRTP=YYY ^
\
\ DTLS-SRTP=YYY
\
\
\
Charlie (192.0.2.2:6666)
Figure 2: B2BUA Handling Multiple Answers
図2：複数の回答を処理するB2BUA
For instance, as shown in Figure 2, Alice sends a request with an offer and the request is forked. Alice receives answers from both Bob and Charlie. The B2BUA advertises different B2BUA transport addresses in each answer, as shown in Figure 2, where XXX and YYY represent different DTLS-SRTP sessions. The B2BUA replaces Bob's transport address (192.0.2.1:6666) in the answer with its transport address (192.0.2.3:7777) and Charlie's transport address (192.0.2.2:6666) in the answer with its transport address (192.0.2.3:8888). The B2BUA tracks the remote sources (Bob and Charlie) and associates them to the local sources that are used to send packets to Alice.
たとえば、図2に示すように、アリスはオファーを含むリクエストを送信し、そのリクエストはフォークされます。アリスは、ボブとチャーリーの両方から回答を受け取ります。図2に示すように、B2BUAは各回答で異なるB2BUAトランスポートアドレスをアドバタイズします。ここで、XXXとYYYは異なるDTLS-SRTPセッションを表しています。 B2BUAは、回答のボブのトランスポートアドレス（192.0.2.1:6666）をそのトランスポートアドレス（192.0.2.3:7777）に置き換え、回答のチャーリーのトランスポートアドレス（192.0.2.2:6666）をそのトランスポートアドレス（192.0.2.3： 8888）。 B2BUAはリモートソース（ボブとチャーリー）を追跡し、パケットをアリスに送信するために使用されるローカルソースに関連付けます。
This document describes the behavior B2BUAs must follow to avoid breaking end-to-end DTLS-SRTP. Media relays that modify RTP or RTCP, or modify SIP header fields or SDP fields that are protected by the identity signature, are incompatible with end-to-end DTLS-SRTP. Such relays are out of scope for this document. Security considerations discussed in [RFC5763] are also applicable to this document. In addition, the B2BUA behaviors outlined in this document do not impact the security and integrity of a DTLS-SRTP session or the data exchanged over it. A malicious B2BUA can try to break into the DTLS connection, but such an attack can be prevented using the identity validation mechanism discussed in [RFC4474] or [SIP-ID]. Either the endpoints or the authentication service proxies involved in the call can use the identity validation mechanisms discussed in [RFC4474] or [SIP-ID] to validate the identity of peers and detect malicious B2BUAs that can attempt to terminate the DTLS connection to decrypt the RTP payload.
このドキュメントでは、エンドツーエンドのDTLS-SRTPの破壊を回避するためにB2BUAが従わなければならない動作について説明します。 RTPまたはRTCPを変更するメディアリレー、またはID署名によって保護されるSIPヘッダーフィールドまたはSDPフィールドを変更するメディアリレーは、エンドツーエンドのDTLS-SRTPと互換性がありません。そのようなリレーはこのドキュメントの範囲外です。 [RFC5763]で説明されているセキュリティの考慮事項は、このドキュメントにも適用されます。さらに、このドキュメントで概説されているB2BUAの動作は、DTLS-SRTPセッションのセキュリティと整合性、またはそれを介して交換されるデータには影響しません。悪意のあるB2BUAがDTLS接続に侵入しようとする可能性がありますが、このような攻撃は、[RFC4474]または[SIP-ID]で説明されているID検証メカニズムを使用して防止できます。コールに関係するエンドポイントまたは認証サービスプロキシは、[RFC4474]または[SIP-ID]で説明されているID検証メカニズムを使用して、ピアのIDを検証し、DTLS接続を終了して悪意のあるB2BUAを検出して、 RTPペイロード。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC5763] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「Datagram Transport Layer Security（DTLS）を使用したセキュアなリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、DOI 10.17487 / RFC5763、2010年5月、<http://www.rfc-editor.org/info/rfc5763>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <http://www.rfc-editor.org/info/rfc5764>.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張」、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<http ：//www.rfc-editor.org/info/rfc5764>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、DOI 10.17487 / RFC4474、2006年8月、<http：//www.rfc-editor。 org / info / rfc4474>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<http://www.rfc-editor.org/info / rfc5761>。
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092] Kaplan、H。およびV. Pascual、「A Taxonomy of Session Initiation Protocol（SIP）Back-to-Back User Agents」、RFC 7092、DOI 10.17487 / RFC7092、2013年12月、<http：//www.rfc -editor.org/info/rfc7092>。
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, DOI 10.17487/RFC7362, September 2014, <http://www.rfc-editor.org/info/rfc7362>.
[RFC7362] Ivov、E.、Kaplan、H。、およびD. Wing、「Latching：Hosted NAT Traversal（HNT）for Media in Real-Time Communication」、RFC 7362、DOI 10.17487 / RFC7362、2014年9月、<http： //www.rfc-editor.org/info/rfc7362>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイムの転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、 RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。
[SIP-ID] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-09, May 2016
[SIP-ID] Peterson、J.、Jennings、C.、Rescorla、E。、およびC. Wendt、「Session Initiation Protocol（SIP）での認証済みID管理」、作業中、draft-ietf-stir-rfc4474bis -09、2016年5月
Acknowledgments
謝辞
Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, Christer Holmberg, Colin Perkins, Ben Campbell, and Alissa Cooper for their constructive comments, suggestions, and early reviews that were critical to the formulation and refinement of this document. The authors would also like to thank Dan Romascanu, Vijay K. Gurbani, Francis Dupont, Paul Wouters, and Stephen Farrell for their review and feedback of this document.
Lorenzo Miniero、Ranjit Avarsala、Hadriel Kaplan、Muthu Arul Mozhi、Paul Kyzivat、Peter Dawes、Brett Tate、Dan Wing、Charles Eckel、Simon Perreault、Albrecht Schwarz、Jens Guballa、Christer Holmberg、Colin Perkins、Ben Campbell、アリッサクーパーの建設的なコメント、提案、およびこのドキュメントの作成と改良に欠かせない初期のレビュー。この文書のレビューとフィードバックを提供してくれたDan Romascanu、Vijay K. Gurbani、Francis Dupont、Paul Wouters、Stephen Farrellにも感謝します。
Contributors
貢献者
Rajeev Seth provided substantial contributions to this document.
Rajeev Sethは、このドキュメントに多大な貢献をしてくれました。
Authors' Addresses
著者のアドレス
Ram Mohan Ravindranath Cisco Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Sasna Business Park Sarajpur-Marthahalli Outer Ring Road Bangalore、Karnatakaインド
Email: rmohanr@cisco.com
Tirumaleswar Reddy Cisco Cessna Business Park Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Cessna Business Park Sarjapur Marathalli Outer Ring Road Bangalore、Karnatakaインド
Email: tireddy@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: gsalguei@cisco.com
Victor Pascual Oracle Barcelona, Spain
ビクターパスクアルオラクルバルセロナ、スペイン
Email: victor.pascual.avila@oracle.com
Parthasarathi Ravindran Nokia Networks Bangalore, Karnataka India
Parthasarathi Ravindran Nokia Networks Bangalore、Karnatakaインド
Email: partha@parthasarathi.co.in