[要約] RFC 6714は、MSRPのためのメディアアンカリングの接続確立（CEMA）に関する規格であり、MSRPセッションの確立と制御を改善することを目的としています。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6714 S. Blau
Category: Standards Track Ericsson
ISSN: 2070-1721 E. Burger
Georgetown University
August 2012
Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
メッセージセッションリレープロトコル（MSRP）のメディアアンカー（CEMA）の接続確立
Abstract
概要
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.
このドキュメントでは、メッセージセッションリレープロトコル（MSRP）拡張、メディアアンカー（CEMA）の接続確立を定義します。この拡張機能のサポートはオプションです。この拡張により、ミドルボックスがMSRPメッセージを変更する必要なく、ミドルボックスがMSRP接続を固定できます。したがって、このようなミドルボックスが展開されているネットワークで、エンドツーエンドの安全なMSRP通信も可能になります。このドキュメントでは、MSRPエンドポイントがCEMA拡張のサポートを示すために使用するセッション記述プロトコル（SDP）属性「msrp-cema」も定義しています。
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/rfc6714.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6714で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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
2. Conventions .....................................................5
3. Applicability Statement .........................................6
4. Connection Establishment for Media Anchoring Mechanism ..........7
4.1. General ....................................................7
4.2. MSRP SDP Offerer Procedures ................................8
4.3. MSRP SDP Answerer Procedures ...............................9
4.4. Address Information Matching ..............................11
4.5. Usage with the Alternative Connection Model ...............12
5. The SDP 'msrp-cema' Attribute ..................................12
5.1. General ...................................................12
5.2. Syntax ....................................................12
6. Middlebox Assumptions ..........................................13
6.1. General ...................................................13
6.2. MSRP Awareness ............................................13
6.3. TCP Connection Reuse ......................................13
6.4. SDP Integrity .............................................14
6.5. TLS .......................................................14
7. Security Considerations ........................................14
7.1. General ...................................................14
7.2. Man-in-the-Middle (MITM) Attacks ..........................15
7.3. TLS Usage without Middleboxes .............................16
7.4. TLS Usage with Middleboxes ................................16
7.5. Authentication, Credentials, and Key Management ...........16
7.6. Endpoint Procedures for TLS Negotiation ...................17
7.7. Fingerprint-Based Authentication ..........................18
8. IANA Considerations ............................................19
8.1. IANA Registration of the SDP 'msrp-cema' Attribute ........19
9. Acknowledgements ...............................................20
10. References ....................................................20
10.1. Normative References .....................................20
10.2. Informative References ...................................21
The Message Session Relay Protocol (MSRP) [RFC4975] expects to use MSRP relays [RFC4976] as a means for Network Address Translation (NAT) traversal and policy enforcement. However, many Session Initiation Protocol (SIP) [RFC3261] networks, which deploy MSRP, contain middleboxes. These middleboxes anchor and control media; perform tasks such as NAT traversal, performance monitoring, and address domain bridging; interconnect Service Level Agreement (SLA) policy enforcement; and so on. One example is the Interconnection Border Control Function (IBCF) [GPP23228], defined by the 3rd Generation Partnership Project (3GPP). The IBCF controls a media relay that handles all types of SIP session media, such as voice, video, MSRP, etc.
メッセージセッションリレープロトコル（MSRP）[RFC4975]は、ネットワークアドレス変換（NAT）トラバーサルおよびポリシー実施の手段としてMSRPリレー[RFC4976]を使用することを期待しています。ただし、MSRPを展開する多くのセッション開始プロトコル（SIP）[RFC3261]ネットワークにはミドルボックスが含まれています。これらのミドルボックスは、メディアを固定および制御します。 NATトラバーサル、パフォーマンス監視、アドレスドメインブリッジングなどのタスクを実行します。相互接続サービスレベルアグリーメント（SLA）ポリシーの実施。等々。 1つの例は、第3世代パートナーシッププロジェクト（3GPP）によって定義された相互接続ボーダーコントロール機能（IBCF）[GPP23228]です。 IBCFは、音声、ビデオ、MSRPなど、あらゆるタイプのSIPセッションメディアを処理するメディアリレーを制御します。
MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot anchor through middleboxes. The reason is that MSRP messages have routing information embedded in the message. Without an extension such as CEMA, middleboxes must read the message to change the routing information. This occurs because middleboxes modify the address:port information in the Session Description Protocol (SDP) [RFC4566] c/m-line in order to anchor media. An "active" [RFC6135] MSRP User Agent (UA) establishes the MSRP TCP or Transport Layer Security (TLS) connection based on the MSRP URI of the SDP 'path' attribute. This means that the MSRP connection will not be routed through the middlebox unless the middlebox also modifies the MSRP URI of the topmost SDP 'path' attribute. In many scenarios, this will prevent the MSRP connection from being established. In addition, if the middlebox modifies the MSRP URI of the SDP 'path' attribute, then the MSRP URI comparison procedure [RFC4975], which requires consistency between the address information in the MSRP messages and the address information carried in the MSRP URI of the SDP 'path' attribute, will fail.
MSRPは、RFC 4975 [RFC4975]およびRFC 4976 [RFC4976]で定義されているように、ミドルボックスを介してアンカーできません。その理由は、MSRPメッセージにはルーティング情報がメッセージに埋め込まれているためです。 CEMAなどの拡張機能がない場合、ミドルボックスはメッセージを読み取ってルーティング情報を変更する必要があります。これは、ミドルボックスがメディアをアンカーするためにセッション記述プロトコル（SDP）[RFC4566] c / m-lineのアドレス：ポート情報を変更するために発生します。 「アクティブ」な[RFC6135] MSRPユーザーエージェント（UA）は、SDP 'path'属性のMSRP URIに基づいて、MSRP TCPまたはトランスポート層セキュリティ（TLS）接続を確立します。これは、ミドルボックスが最上位のSDP「パス」属性のMSRP URIも変更しない限り、MSRP接続はミドルボックスを介してルーティングされないことを意味します。多くのシナリオでは、これによりMSRP接続が確立されなくなります。さらに、ミドルボックスがSDPの「パス」属性のMSRP URIを変更する場合、MSRP URI比較手順[RFC4975]では、MSRPメッセージのアドレス情報と、 SDP「パス」属性、失敗します。
The only way to achieve interoperability in this situation is for the middlebox to act as an MSRP back-to-back User Agent (B2BUA). Here, the MSRP B2BUA acts as the endpoint for the MSRP signaling and media, performs the corresponding modification in the associated MSRP messages, and originates a new MSRP session toward the actual remote endpoint. However, the enabling of MSRP B2BUA functionality requires substantially more resource usage in the middlebox, which normally results in a negative impact on performance. In addition, the MSRP message needs to be exposed in cleartext to the MSRP B2BUA, which violates the end-to-end principle [RFC3724].
この状況で相互運用性を実現する唯一の方法は、ミドルボックスがMSRPバックツーバックユーザーエージェント（B2BUA）として機能することです。ここで、MSRP B2BUAはMSRPシグナリングとメディアのエンドポイントとして機能し、関連するMSRPメッセージで対応する変更を実行し、実際のリモートエンドポイントに向けて新しいMSRPセッションを開始します。ただし、MSRP B2BUA機能を有効にするには、ミドルボックスでかなり多くのリソースを使用する必要があるため、通常はパフォーマンスに悪影響を及ぼします。さらに、MSRPメッセージはクリアテキストでMSRP B2BUAに公開される必要があり、これはエンドツーエンドの原則[RFC3724]に違反しています。
This specification defines an MSRP extension, Connection Establishment for Media Anchoring (CEMA). In most cases, CEMA allows MSRP endpoints to communicate through middleboxes as defined in Section 2, without a need for the middleboxes to be MSRP B2BUAs. In such cases, middleboxes that want to anchor the MSRP connection simply modify the SDP c/m-line address information, similar to what the middleboxes do for non-MSRP media types. MSRP endpoints that support the CEMA extension will use the SDP c/m-line address information for establishing the TCP or TLS connection for sending and receiving MSRP messages.
この仕様は、MSRP拡張、メディアアンカー（CEMA）の接続確立を定義します。ほとんどの場合、CEMAにより、セクション2で定義されているミドルボックスを介してMSRPエンドポイントが通信できます。ミドルボックスをMSRP B2BUAにする必要はありません。このような場合、MSRP接続をアンカーするミドルボックスは、非MSRPメディアタイプのミドルボックスと同様に、SDP c / m-lineアドレス情報を変更するだけです。 CEMA拡張をサポートするMSRPエンドポイントは、SDP c / m-lineアドレス情報を使用して、MSRPメッセージを送受信するためのTCPまたはTLS接続を確立します。
The CEMA extension is backward compatible, meaning that CEMA-enabled MSRP endpoints can communicate with non-CEMA-enabled endpoints. In scenarios where MSRP endpoints do not support the CEMA extension, an MSRP endpoint that supports the CEMA extension behaves in the same way as an MSRP endpoint that does not support it. The CEMA extension only provides an alternative mechanism for negotiating and providing address information for the MSRP TCP connection. After the creation of the MSRP connection, an MSRP endpoint that supports the CEMA extension acts according to the procedures for creating MSRP messages, performing checks when receiving MSRP messages defined in RFC 4975 and, when it is using a relay for MSRP communications, RFC 4976.
CEMA拡張は下位互換性があります。つまり、CEMA対応のMSRPエンドポイントはCEMA非対応のエンドポイントと通信できます。 MSRPエンドポイントがCEMA拡張をサポートしないシナリオでは、CEMA拡張をサポートするMSRPエンドポイントは、それをサポートしないMSRPエンドポイントと同じように動作します。 CEMA拡張は、MSRP TCP接続のアドレス情報をネゴシエートおよび提供するための代替メカニズムのみを提供します。 MSRP接続の作成後、CEMA拡張をサポートするMSRPエンドポイントは、MSRPメッセージの作成手順に従って動作し、RFC 4975で定義されたMSRPメッセージを受信するときにチェックを実行し、MSRP通信にリレーを使用している場合は、RFC 4976を実行します。
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 BCP 14, RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈されます。
Definitions:
定義：
Fingerprint-Based TLS Authentication: An MSRP endpoint that uses a self-signed certificate and sends a fingerprint (i.e., a hash of the self-signed certificate) in SDP to the other MSRP endpoint. This fingerprint binds the TLS key exchange to the signaling plane and authenticates the other endpoint based on trust in the signaling plane.
指紋ベースのTLS認証：自己署名証明書を使用し、SDP内の指紋（つまり、自己署名証明書のハッシュ）を他のMSRPエンドポイントに送信するMSRPエンドポイント。このフィンガープリントは、TLS鍵交換をシグナリングプレーンにバインドし、シグナリングプレーンの信頼に基づいて他のエンドポイントを認証します。
Name-Based TLS Authentication: An MSRP endpoint that uses a certificate that is bound to the endpoint's hostname or SIP address of record. In the TLS session setup, the other MSRP endpoint verifies that the identity associated with the certificate corresponds to that of the peer (as indicated in SIP/ SDP) and that the binding of the identity to the public key was done by a party that the endpoint trusts. This definition includes traditional certificates issued by a well-known certification authority as well as self-signed certificates published via the SIP Certificate Management Service [RFC6072] and other similar mechanisms.
名前ベースのTLS認証：エンドポイントのホスト名またはレコードのSIPアドレスにバインドされている証明書を使用するMSRPエンドポイント。 TLSセッションのセットアップでは、他のMSRPエンドポイントは、証明書に関連付けられたIDがピアのID（SIP / SDPに示されている）に対応していること、およびIDの公開鍵へのバインドが、エンドポイントの信頼。この定義には、有名な証明機関によって発行された従来の証明書と、SIP証明書管理サービス[RFC6072]および他の同様のメカニズムを介して発行された自己署名証明書が含まれます。
B2BUA: This is an abbreviation for back-to-back user agent.
B2BUA：これは、連続したユーザーエージェントの略語です。
MSRP B2BUA: A network element that terminates an MSRP connection from one MSRP endpoint and reoriginates that connection toward another MSRP endpoint. Note that the MSRP B2BUA is distinct from a SIP B2BUA. A SIP B2BUA terminates a SIP session and reoriginates that session toward another SIP endpoint. In the context of MSRP, a SIP endpoint initiates a SIP session toward another SIP endpoint. However, that INVITE may go through, for example, an outbound proxy or inbound proxy to route to the remote SIP endpoint. As part of that SIP session, an MSRP session that may follow the SIP session path is negotiated. However, there is no requirement to co-locate the SIP network elements with the MSRP network elements.
MSRP B2BUA：1つのMSRPエンドポイントからのMSRP接続を終了し、その接続を別のMSRPエンドポイントに向けて再発信するネットワーク要素。 MSRP B2BUAはSIP B2BUAとは異なることに注意してください。 SIP B2BUAはSIPセッションを終了し、そのセッションを別のSIPエンドポイントに向けて再発信します。 MSRPのコンテキストでは、SIPエンドポイントは別のSIPエンドポイントに向けてSIPセッションを開始します。ただし、そのINVITEは、たとえば、アウトバウンドプロキシまたはインバウンドプロキシを経由してリモートSIPエンドポイントにルーティングする場合があります。そのSIPセッションの一部として、SIPセッションパスをたどるMSRPセッションがネゴシエートされます。ただし、SIPネットワーク要素をMSRPネットワーク要素と同じ場所に配置する必要はありません。
TLS B2BUA: A network element that terminates security associations (SAs) from endpoints and establishes separate SAs between itself and each endpoint.
TLS B2BUA：エンドポイントからのセキュリティアソシエーション（SA）を終了し、それ自体と各エンドポイントの間に個別のSAを確立するネットワーク要素。
Middlebox: A SIP network device that modifies SDP media address:port information in order to steer or anchor media flows described in the SDP, including TCP and TLS connections used for MSRP communication, through a media proxy function controlled by the SIP endpoint. In most cases, the media proxy function relays the MSRP messages without modification, while in some circumstances it acts as an MSRP B2BUA. Other SIP-related functions -- such as those related to routing, modification of SIP information, etc. -- performed by the Middlebox, and whether it acts as a SIP B2BUA or not, are outside the scope of this document. Section 6 describes additional assumptions regarding how the Middlebox handles MSRP in order to support the extension defined in this document.
Middlebox：SIPエンドポイントによって制御されるメディアプロキシ機能を介して、MSRP通信に使用されるTCPおよびTLS接続を含む、SDPで記述されたメディアフローを誘導または固定するためにSDPメディアアドレス：ポート情報を変更するSIPネットワークデバイス。ほとんどの場合、メディアプロキシ機能は変更なしでMSRPメッセージを中継しますが、状況によってはMSRP B2BUAとして機能します。 Middleboxによって実行されるルーティングやSIP情報の変更などの他のSIP関連機能、およびそれがSIP B2BUAとして機能するかどうかは、このドキュメントの範囲外です。セクション6では、このドキュメントで定義されている拡張機能をサポートするために、MiddleboxがMSRPを処理する方法に関する追加の前提条件について説明します。
Media anchor: An entity that performs media anchoring inserts itself in the media path of a media communication session between two entities. The media anchor will receive, and forward, the media sent between the entities.
メディアアンカー：メディアアンカーを実行するエンティティは、2つのエンティティ間のメディア通信セッションのメディアパスにそれ自体を挿入します。メディアアンカーは、エンティティ間で送信されたメディアを受信して転送します。
This document reuses the terms "answer", "answerer", "offer", and "offerer" as defined in [RFC3264].
このドキュメントでは、[RFC3264]で定義されている「answer」、「answerer」、「offer」、および「offerer」という用語を再利用します。
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows Middleboxes to anchor the MSRP connection, without the need for Middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such Middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.
このドキュメントでは、メッセージセッションリレープロトコル（MSRP）拡張、メディアアンカー（CEMA）の接続確立を定義します。この拡張機能のサポートはオプションです。この拡張により、MiddleboxがMSRPメッセージを変更する必要なく、MiddleboxがMSRP接続を固定できます。したがって、このようなミドルボックスが展開されているネットワークで、エンドツーエンドの安全なMSRP通信も可能になります。このドキュメントでは、MSRPエンドポイントがCEMA拡張のサポートを示すために使用するセッション記述プロトコル（SDP）属性「msrp-cema」も定義しています。
The CEMA extension is primarily intended for MSRP endpoints that operate in networks in which Middleboxes that want to anchor media connections are deployed, without the need for the Middleboxes to enable MSRP B2BUA functionality. An example of such a network is the IP Multimedia Subsystem (IMS), defined by the 3rd Generation Partnership Project (3GPP), which also has the capability for all endpoints to use name-based TLS authentication. The extension is also useful for other MSRP endpoints that operate in other networks but that communicate with MSRP endpoints in networks with such Middleboxes, unless there is a gateway between these networks that by default always enables MSRP B2BUA functionality.
CEMA拡張は主に、ミドルボックスでMSRP B2BUA機能を有効にする必要なしに、メディア接続をアンカーするミドルボックスが展開されているネットワークで動作するMSRPエンドポイントを対象としています。このようなネットワークの例は、第3世代パートナーシッププロジェクト（3GPP）によって定義されたIPマルチメディアサブシステム（IMS）です。これには、すべてのエンドポイントが名前ベースのTLS認証を使用する機能もあります。拡張機能は、他のネットワークで動作する他のMSRPエンドポイントにも役立ちますが、これらのネットワーク間にデフォルトで常にMSRP B2BUA機能を有効にするゲートウェイがない限り、そのようなミドルボックスを持つネットワークのMSRPエンドポイントと通信します。
This document assumes certain behaviors on the part of Middleboxes, as described in Section 6. These behaviors are not standardized. If Middleboxes do not behave as assumed, then the CEMA extension does not add any value over base MSRP behavior. MSRP endpoints that support CEMA are required to use RFC 4975 behavior in cases where they detect that the CEMA extension cannot be enabled.
このドキュメントでは、セクション6で説明されているMiddleboxの一部の動作を想定しています。これらの動作は標準化されていません。 Middleboxesが想定どおりに動作しない場合、CEMA拡張機能は基本のMSRP動作に値を追加しません。 CEMAをサポートするMSRPエンドポイントは、CEMA拡張を有効にできないことを検出した場合にRFC 4975の動作を使用する必要があります。
This section defines how an MSRP endpoint that supports the CEMA extension generates SDP offers and answers for MSRP, and which SDP information elements the MSRP endpoint uses when creating the TCP or TLS connection for sending and receiving MSRP messages.
このセクションでは、CEMA拡張をサポートするMSRPエンドポイントがMSRPのSDPオファーと応答を生成する方法、およびMSRPメッセージを送受信するためのTCPまたはTLS接続を作成するときにMSRPエンドポイントが使用するSDP情報要素を定義します。
Based on the procedures described in Sections 4.2 and 4.3, in the following cases the CEMA extension will not be enabled, and there will be a fallback to the MSRP connection establishment procedures defined in RFC 4975 and RFC 4976:
セクション4.2および4.3で説明されている手順に基づいて、次の場合はCEMA拡張が有効にならず、RFC 4975およびRFC 4976で定義されているMSRP接続確立手順へのフォールバックがあります。
- A non-CEMA-enabled MSRP endpoint becomes "active" [RFC6135] (no matter whether it uses a relay for its MSRP communication or not), as it will always establish the MSRP connection using the SDP 'path' attribute, which contains the address information of the remote MSRP endpoint, instead of using the SDP c/m-line, which contains the address information of the Middlebox.
- 非CEMA対応のMSRPエンドポイントは「アクティブ」になります[RFC6135]（MSRP通信にリレーを使用するかどうかに関係なく）。これは、SRP 'path'属性を使用してMSRP接続を常に確立するため、 Middleboxのアドレス情報を含むSDP c / m-lineを使用する代わりに、リモートMSRPエンドポイントのアドレス情報。
- A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "passive" [RFC6135], as it cannot be assumed that the MSRP endpoint inserts the address information of the relay in the SDP c/m-line.
- MSRPエンドポイントがSDP c / m-lineにリレーのアドレス情報を挿入するとは想定できないため、MSRP通信にリレーを使用する非CEMA対応のMSRPエンドポイントは「パッシブ」になります[RFC6135]。
- A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "active", since if it adds the received SDP c/m-line address information to the ToPath header field of the MSRP message (in order for the relay to establish the MSRP connection toward the Middlebox), the session matching [RFC4975] performed by the remote MSRP endpoint will fail.
- MSRP通信にリレーを使用するCEMA対応のMSRPエンドポイントは、受信したSDP c / m-lineアドレス情報をMSRPメッセージのToPathヘッダーフィールドに追加すると（リレーが確立するため）、「アクティブ」になりますMiddleboxへのMSRP接続）、リモートMSRPエンドポイントによって実行される[RFC4975]に一致するセッションは失敗します。
When a CEMA-enabled offerer sends an SDP offer for MSRP, it generates the SDP offer according to the procedures in RFC 4975. In addition, the offerer follows RFC 4976 if it is using a relay for MSRP communication. The offerer also performs the following additions and modifications:
CEMA対応のオファーがMSRPのSDPオファーを送信すると、RFC 4975の手順に従ってSDPオファーを生成します。さらに、オファーがMSRP通信にリレーを使用している場合、RFC 4976に従います。提案者は、次の追加および変更も実行します。
1. The offerer MUST include an SDP 'msrp-cema' attribute in the MSRP media description of the SDP offer.
1. オファー提供者は、SDPオファーのMSRPメディア記述にSDP 'msrp-cema'属性を含める必要があります。
2. If the offerer is not using a relay for MSRP communication, it MUST include an SDP 'setup' attribute in the MSRP media description of the SDP offer, according to the procedures in RFC 6135 [RFC6135].
2. 提供者がMSRP通信にリレーを使用していない場合、RFC 6135 [RFC6135]の手順に従って、SDP提供のMSRPメディア記述にSDP 'setup'属性を含める必要があります。
3. If the offerer is using a relay for MSRP communication, it MUST, in addition to including the address information of the relay in the topmost SDP 'path' attribute, also include the address information of the relay, rather than its own address information, in the SDP c/m-line associated with the MSRP media description. In addition, it MUST include an SDP 'setup:actpass' attribute in the MSRP media description of the SDP offer.
3. 提供者がMSRP通信にリレーを使用している場合は、リレーのアドレス情報を最上位のSDP「パス」属性に含めることに加えて、自身のアドレス情報ではなく、リレーのアドレス情報を含める必要があります。 MSRPメディア記述に関連付けられたSDP c / m行。さらに、SDPオファーのMSRPメディア記述にSDP 'setup：actpass'属性を含める必要があります。
When the offerer receives an SDP answer, if the MSRP media description of the SDP answer does not contain an SDP 'msrp-cema' attribute, and if any one or more of the criteria below are met, the offerer MUST fall back to RFC 4975 behavior by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976. The new offer MUST NOT contain an SDP 'msrp-cema' attribute.
提案者がSDP回答を受け取ったとき、SDP回答のMSRPメディア記述にSDP 'msrp-cema'属性が含まれておらず、以下の基準の1つ以上が満たされている場合、提供者はRFC 4975にフォールバックする必要がありますRFC 4975およびRFC 4976の手順に従って新しいSDPオファーを送信することによる動作。新しいオファーにSDP 'msrp-cema'属性を含めることはできません。
1. The SDP c/m-line address information associated with the MSRP media description does not match (see Section 4.4) the information in the MSRP URI of the 'path' attribute(s) (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the MSRP endpoint will become "passive" (if the MSRP media description of the SDP answer contains an SDP 'setup: active' attribute).
1. MSRPメディアの説明に関連付けられているSDP c / m-lineアドレス情報が、「パス」属性のMSRP URIの情報と一致しません（セクション4.4を参照）（この場合、SDP c / m-lineにはMiddleboxのアドレスが含まれます）、MSRPエンドポイントは「パッシブ」になります（SDP回答のMSRPメディア記述にSDP 'setup：active'属性が含まれている場合）。
NOTE: If an MSRP URI contains a domain name, it needs to be resolved into an IP address and port before it is checked against the SDP c/m-line address information, in order to determine whether the address information matches.
注：MSRP URIにドメイン名が含まれている場合、アドレス情報が一致するかどうかを判断するために、SDP c / m-lineアドレス情報と照合する前に、IPアドレスとポートに解決する必要があります。
2. The offerer uses a relay for its MSRP communication, the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP 'path' attribute(s) (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the offerer will become "active" (either by default or if the MSRP media description of the SDP answer contains an SDP 'setup:passive' attribute).
2.提供者がMSRP通信にリレーを使用している場合、MSRPメディア記述に関連付けられているSDP c / m-lineアドレス情報が、SDP 'path'属性のMSRP URIの情報と一致しません（この場合） SDP c / m-lineにMiddleboxのアドレスが含まれていると想定されています）、提供者は「アクティブ」になります（デフォルトで、またはSDP回答のMSRPメディア記述にSDP 'setup：passive'属性が含まれている場合） ）。
3. The remote MSRP endpoint, acting as an answerer, uses a relay for its MSRP communication, the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP 'path' attributes (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the MSRP offerer will become "active" (either by default or if the MSRP media description of the SDP answer contains an SDP 'setup:passive' attribute).
3. 応答側として機能するリモートMSRPエンドポイントは、MSRP通信にリレーを使用します。MSRPメディア記述に関連付けられたSDP c / m-lineアドレス情報は、SDP「パス」属性のMSRP URIの情報と一致しません（その場合、SDP c / m-lineにMiddleboxのアドレスが含まれていると想定され、MSRPオファーは「アクティブ」になります（デフォルトで、またはSDP回答のMSRPメディア記述にSDPセットアップが含まれている場合） ：passive '属性）。
NOTE: As described in Section 6, in the absence of the SDP 'msrp-cema' attribute in the new offer, it is assumed that a Middlebox will act as an MSRP B2BUA in order to anchor MSRP media.
注：セクション6で説明されているように、新しいオファーにSDP 'msrp-cema'属性がない場合、MiddleboxがMSRPメディアをアンカーするためにMSRP B2BUAとして機能すると想定されています。
The offerer can send the new offer within the existing early dialog [RFC3261], or it can terminate the early dialog and establish a new dialog by sending the new offer in a new initial INVITE request.
提案者は、既存の初期ダイアログ[RFC3261]内で新しいオファーを送信できます。または、初期ダイアログを終了して、新しい初期INVITEリクエストで新しいオファーを送信することにより、新しいダイアログを確立できます。
The offerer MAY choose to terminate the session establishment if it can detect that a Middlebox acting as an MSRP B2BUA is not the desired remote MSRP endpoint.
オファー提供者は、MSRP B2BUAとして機能するミドルボックスが望ましいリモートMSRPエンドポイントではないことを検出できる場合、セッションの確立を終了することを選択できます。
If the answerer uses a relay for its MSRP communication, and the SDP c/m-line address information associated with the MSRP media description matches one of the SDP 'path' attributes, it is assumed that there is no Middlebox in the network. In that case, the offerer MUST fall back to RFC 4975 behavior, but it does not need to send a new SDP offer.
回答者がMSRP通信にリレーを使用し、MSRPメディア記述に関連付けられたSDP c / m-lineアドレス情報がSDPの「パス」属性の1つと一致する場合、ネットワークにミドルボックスがないと見なされます。その場合、提供者はRFC 4975の動作にフォールバックする必要がありますが、新しいSDPオファーを送信する必要はありません。
In other cases, where none of the criteria above are met, and where the MSRP offerer becomes "active", it MUST use the SDP c/m-line for establishing the MSRP TCP connection. If the offerer becomes "passive", it will wait for the answerer to establish the TCP connection, according to the procedures in RFC 4975.
上記のいずれの基準も満たさず、MSRP提供者が「アクティブ」になる他の場合では、MSRP TCP接続を確立するためにSDP c / m-lineを使用する必要があります。 RFC 4975の手順に従って、オファー側が「パッシブ」になると、オファー側はTCP接続を確立するのを待ちます。
If the MSRP media description of the SDP offer does not contain an SDP 'msrp-cema' attribute, and the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP 'path' attribute(s), the answerer MUST either reject the offered MSRP connection (by using a zero port value number in the generated SDP answer) or reject the whole SIP request that carries the SDP offer with a 488 Not Acceptable Here [RFC3261] response.
SDPオファーのMSRPメディア記述にSDP 'msrp-cema'属性が含まれておらず、MSRPメディア記述に関連付けられているSDP c / m-lineアドレス情報がSDPのMSRP URIの情報と一致しない場合パスの属性、アンサーは、提供されたMSRP接続を拒否する（生成されたSDP回答でゼロのポート値番号を使用する）か、488 Not Acceptable Here [RFC3261]でSDPオファーを運ぶSIPリクエスト全体を拒否する必要があります。応答。
NOTE: The reason for the rejection is that the answerer assumes that a middlebox that does not support the CEMA extension has modified the c/m-line address information of the SDP offer without enabling MSRP B2BUA functionality.
注：拒否の理由は、CEMA拡張をサポートしないミドルボックスがMSRP B2BUA機能を有効にせずにSDPオファーのc / m-lineアドレス情報を変更したと回答者が想定しているためです。
NOTE: If an MSRP URI contains a domain name, it needs to be resolved into an IP address and port before it is checked against the SDP c/m-line address information, in order to determine whether the address information matches.
注：MSRP URIにドメイン名が含まれている場合、アドレス情報が一致するかどうかを判断するために、SDP c / m-lineアドレス情報と照合する前に、IPアドレスとポートに解決する必要があります。
If any one or more of the criteria below are met, the answerer MUST fall back to RFC 4975 behavior and generate the associated SDP answer according to the procedures in RFC 4975 and RFC 4976. The answerer MUST NOT insert an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer.
以下の基準の1つ以上が満たされた場合、回答者はRFC 4975の動作にフォールバックし、RFC 4975およびRFC 4976の手順に従って関連するSDP回答を生成する必要があります。回答者はSDP 'msrp-cema'を挿入してはなりません（MUST NOT） SDP回答のMSRPメディア記述の属性。
1. Both MSRP endpoints are using relays for their MSRP communication. The answerer can detect if the remote MSRP endpoint, acting as an offerer, is using a relay for its MSRP communication if the MSRP media description of the SDP offer contains multiple SDP 'path' attributes.
1. 両方のMSRPエンドポイントは、MSRP通信にリレーを使用しています。 SDPオファーのMSRPメディア記述に複数のSDP「パス」属性が含まれている場合、回答者は、提供者として機能しているリモートMSRPエンドポイントがMSRP通信にリレーを使用しているかどうかを検出できます。
2. The offerer uses a relay for its MSRP communication and will become "active" (either by default or if the MSRP media description of the SDP offer contains an SDP 'setup:active' attribute). Note that a CEMA-enabled offerer would include an SDP 'setup:actpass' attribute in the SDP offer, as described in Section 4.2.
2. 提供者は、MSRP通信にリレーを使用し、「アクティブ」になります（デフォルトで、またはSDPオファーのMSRPメディア記述にSDP 'setup：active'属性が含まれている場合）。セクション4.2で説明されているように、CEMA対応の提供者はSDP提供にSDP 'setup：actpass'属性を含めることに注意してください。
3. The answerer uses a relay for MSRP communication and is not able to become "passive" (if the MSRP media description of the offer contains an SDP 'setup:passive' attribute). Note that an offerer is not allowed to include an SDP 'setup:passive' attribute in an SDP offer, as described in RFC 6135.
3. 回答者はMSRP通信にリレーを使用し、「パッシブ」になることはできません（オファーのMSRPメディア記述にSDP 'setup：passive'属性が含まれている場合）。 RFC 6135で説明されているように、SDPオファーにSDPの「setup：passive」属性を含めることは許可されていません。
In all other cases, the answerer generates the associated SDP answer according to the procedures in RFC 4975 and RFC 4976, with the following additions and modifications:
他のすべての場合、アンサーは、RFC 4975およびRFC 4976の手順に従って、関連するSDP回答を生成します。以下の追加および変更が行われます。
1. The answerer MUST include an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer.
1. 回答者は、SDP回答のMSRPメディア記述にSDP 'msrp-cema'属性を含める必要があります。
2. If the answerer is not using a relay for MSRP communication, it MUST include an SDP 'setup' attribute in the MSRP media description of the answer, according to the procedures in RFC 6135.
2. 回答者がMSRP通信にリレーを使用していない場合、RFC 6135の手順に従って、回答のMSRPメディアの説明にSDP 'setup'属性を含める必要があります。
3. If the answerer is using a relay for MSRP communication, it MUST, in addition to including the address information of the relay in the topmost SDP 'path' attribute, also include the address information of the relay, rather than its own address information, in the SDP c/m-line associated with the MSRP media description. In addition, the answerer MUST include an SDP 'setup:passive' attribute in the MSRP media description of the SDP answer.
3. 回答者がMSRP通信にリレーを使用している場合、最上位のSDP 'path'属性にリレーのアドレス情報を含めることに加えて、自身のアドレス情報ではなく、リレーのアドレス情報を含める必要があります。 MSRPメディア記述に関連付けられたSDP c / m行。さらに、回答者は、SDP回答のMSRPメディア記述にSDP 'setup：passive'属性を含める必要があります。
If the answerer included an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer, and if the answerer becomes "active", it MUST use the received SDP c/m-line for establishing the MSRP TCP or TLS connection. If the answerer becomes "passive", it will wait for the offerer to establish the MSRP TCP or TLS connection, according to the procedures in RFC 4975.
回答者がSDP回答のMSRPメディア記述にSDP 'msrp-cema'属性を含め、回答者が「アクティブ」になった場合、MSRP TCPまたはTLS接続を確立するために受信したSDP c / m-lineを使用する必要があります。回答者が「パッシブ」になると、RFC 4975の手順に従って、提供者がMSRP TCPまたはTLS接続を確立するのを待ちます。
When comparing address information in the SDP c/m-line and an MSRP URI, for address and port equivalence, the address and port values are retrieved in the following ways:
SDP c / m-lineとMSRP URIのアドレス情報を比較する場合、アドレスとポートの同等性について、アドレスとポートの値は次の方法で取得されます。
- SDP c/m-line address information: The IP address is retrieved from the SDP c-line, and the port from the associated SDP m-line for MSRP.
- SDP c / m-lineアドレス情報：IPアドレスはSDP c-lineから取得され、ポートはMSRPの関連するSDP m-lineから取得されます。
- In case the SDP c-line contains a Fully Qualified Domain Name (FQDN), the IP address is retrieved using DNS.
- SDP c-lineに完全修飾ドメイン名（FQDN）が含まれている場合、IPアドレスはDNSを使用して取得されます。
- MSRP URI address information: The IP address and port are retrieved from the authority part of the MSRP URI.
- MSRP URIアドレス情報：IPアドレスとポートは、MSRP URIの機関部分から取得されます。
- In case the authority part of the MSRP URI contains an FQDN, the IP address is retrieved using DNS, according to the procedures in Section 6.2 of RFC 4975.
- MSRP URIの機関部分にFQDNが含まれている場合、RFC 4975のセクション6.2の手順に従って、DNSを使用してIPアドレスが取得されます。
NOTE: According to RFC 4975, the authority part of the MSRP URI must always contain a port.
注：RFC 4975によれば、MSRP URIの機関部分には常にポートが含まれている必要があります。
Before IPv6 addresses are compared for equivalence, they need to be converted into the same representation, using the mechanism defined in RFC 5952 [RFC5952].
IPv6アドレスの同等性を比較する前に、RFC 5952 [RFC5952]で定義されたメカニズムを使用して、それらを同じ表現に変換する必要があります。
NOTE: In case the DNS returns multiple records, each needs to be compared against the SDP c/m-line address information, in order to find at least one match.
注：DNSが複数のレコードを返す場合、少なくとも1つの一致を見つけるために、それぞれをSDP c / m-lineアドレス情報と比較する必要があります。
NOTE: If the authority part of the MSRP URI contains special characters, they are handled according to the procedures in Section 6.1 of RFC 4975.
注：MSRP URIの機関部分に特殊文字が含まれている場合、それらはRFC 4975のセクション6.1の手順に従って処理されます。
An MSRP endpoint that supports the CEMA extension MUST support the mechanism defined in RFC 6135, as it extends the number of scenarios where one can use the CEMA extension. An example is where an MSRP endpoint is using a relay for MSRP communication, and it needs to be "passive" in order to use the CEMA extension, instead of doing a fallback to RFC 4975 behavior.
CEMA拡張をサポートするMSRPエンドポイントは、CEMA拡張を使用できるシナリオの数を拡張するため、RFC 6135で定義されたメカニズムをサポートする必要があります。例としては、MSRPエンドポイントがMSRP通信にリレーを使用しており、RFC 4975の動作にフォールバックするのではなく、CEMA拡張を使用するために「パッシブ」である必要があります。
The SDP 'msrp-cema' attribute is used by MSRP entities to indicate support of the CEMA extension, according to the procedures in Sections 4.2 and 4.3.
SDP 'msrp-cema'属性は、セクション4.2および4.3の手順に従って、CEMA拡張のサポートを示すためにMSRPエンティティによって使用されます。
This section describes the syntax extensions to the ABNF syntax defined in RFC 4566 required for the SDP 'msrp-cema' attribute. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
このセクションでは、SDP 'msrp-cema'属性に必要なRFC 4566で定義されたABNF構文の構文拡張について説明します。この仕様で定義されているABNFは、RFC 5234 [RFC5234]に準拠しています。
attribute =/ msrp-cema-attr ;attribute defined in RFC 4566 msrp-cema-attr = "msrp-cema"
属性= / msrp-cema-attr; RFC 4566で定義された属性msrp-cema-attr = "msrp-cema"
This document does not specify explicit Middlebox behavior, even though Middleboxes enable some of the procedures described here. However, as MSRP endpoints are expected to operate in networks where Middleboxes that want to anchor media are present, this document makes certain assumptions regarding how such Middleboxes behave.
Middleboxはここで説明されている手順の一部を有効にしますが、このドキュメントでは、Middleboxの明示的な動作を指定していません。ただし、MSRPエンドポイントは、メディアをアンカーするミドルボックスが存在するネットワークで動作することが想定されているため、このドキュメントでは、そのようなミドルボックスの動作について特定の仮定を行います。
In order to support interoperability between UAs that support the CEMA extension and UAs that do not support the extension, the Middlebox is MSRP aware. This means that it implements MSRP B2BUA functionality. The Middlebox enables that functionality in cases where the offerer does not support the CEMA extension. In cases where the SDP offer indicates support of the CEMA extension, the Middlebox can simply modify the SDP c/m-line address information for the MSRP connection.
CEMA拡張をサポートするUAと拡張をサポートしないUAの間の相互運用性をサポートするために、MiddleboxはMSRP対応です。つまり、MSRP B2BUA機能を実装しています。 Middleboxは、提供者がCEMA拡張をサポートしていない場合にその機能を有効にします。 SDPオファーがCEMA拡張のサポートを示している場合、Middleboxは、MSRP接続のSDP c / m-lineアドレス情報を単に変更できます。
In cases where the Middlebox enables MSRP B2BUA functionality, it acts as an MSRP endpoint. If it does not use the CEMA procedures, it will never forward the SDP 'msrp-cema' attribute in SDP offers and answers.
MiddleboxがMSRP B2BUA機能を有効にする場合、MSRPエンドポイントとして機能します。 CEMA手順を使用しない場合、SDPオファーおよびアンサーのSDP 'msrp-cema'属性は転送されません。
If the Middlebox does not implement MSRP B2BUA functionality, or does not enable it when the SDP 'msrp-cema' attribute is not present in the SDP offer, CEMA-enabled MSRP endpoints will in some cases be unable to interoperate with non-CEMA-enabled endpoints across the Middlebox.
MiddleboxがMSRP B2BUA機能を実装していない場合、またはSDPオファーにSDP 'msrp-cema'属性が存在しない場合に有効にしない場合、CEMA対応のMSRPエンドポイントは、非CEMA-と相互運用できない場合があります。ミドルボックス全体で有効なエンドポイント。
Middleboxes do not need to parse and modify the MSRP payload when endpoints use the CEMA extension. A Middlebox that does not parse the MSRP payload probably will not be able to reuse TCP connections for multiple MSRP sessions. Instead, in order to associate an MSRP message with a specific session, the Middlebox often assigns a unique local address:port combination for each MSRP session. Due to this, between two Middleboxes there might be a separate connection for each MSRP session.
エンドポイントがCEMA拡張を使用する場合、ミドルボックスはMSRPペイロードを解析および変更する必要はありません。 MSRPペイロードを解析しないミドルボックスは、複数のMSRPセッションでTCP接続を再利用できない可能性があります。代わりに、MSRPメッセージを特定のセッションに関連付けるために、Middleboxは多くの場合、各MSRPセッションに一意のローカルアドレス：ポートの組み合わせを割り当てます。このため、2つのミドルボックスの間には、MSRPセッションごとに個別の接続がある場合があります。
If the Middlebox does not assign a unique address:port combination for each MSRP session, and does not parse MSRP messages, it might end up forwarding MSRP messages toward the wrong destination.
Middleboxが各MSRPセッションに一意のアドレスとポートの組み合わせを割り当てず、MSRPメッセージを解析しない場合、MSRPメッセージが誤った宛先に転送される可能性があります。
This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media.
このドキュメントでは、MiddleboxがMSRPメディアに関連付けられたSDPアドレス情報を変更できることを前提としています。
NOTE: Even though the CEMA extension as such works with end-to-end SDP protection, the main advantage of the extension is in networks where Middleboxes are deployed.
注：CEMA拡張自体はエンドツーエンドのSDP保護で機能しますが、拡張の主な利点は、ミドルボックスが展開されているネットワークにあります。
If the Middlebox is unable to modify SDP payloads due to end-to-end integrity protection, it will be unable to anchor MSRP media, as the SIP signaling would fail due to integrity violations.
エンドツーエンドの整合性保護のためにMiddleboxがSDPペイロードを変更できない場合、整合性違反によりSIPシグナリングが失敗するため、MSRPメディアを固定できません。
When UAs use the CEMA extension, this document assumes that Middleboxes relay MSRP media packets at the transport layer. The TLS handshake and resulting security association (SA) can be established peer-to-peer between the MSRP endpoints. The Middlebox will see encrypted MSRP media packets but is unable to inspect the cleartext content.
UAがCEMA拡張を使用する場合、このドキュメントでは、ミドルボックスがトランスポート層でMSRPメディアパケットをリレーすると想定しています。 TLSハンドシェイクとその結果のセキュリティアソシエーション（SA）は、MSRPエンドポイント間でピアツーピアで確立できます。 Middleboxは暗号化されたMSRPメディアパケットを認識しますが、クリアテキストコンテンツを検査できません。
When UAs fall back to RFC 4975 behavior, Middleboxes act as TLS B2BUAs. The Middlebox decrypts MSRP media packets received from one MSRP endpoint and then re-encrypts them before sending them toward the other MSRP endpoint. Middleboxes can inspect and modify the MSRP message content.
UAがRFC 4975の動作にフォールバックすると、MiddleboxはTLS B2BUAとして機能します。 Middleboxは、1つのMSRPエンドポイントから受信したMSRPメディアパケットを復号化してから、他のMSRPエンドポイントに送信する前に再暗号化します。ミドルボックスは、MSRPメッセージの内容を検査および変更できます。
Unless otherwise stated, the security considerations in RFC 4975 and RFC 4976 still apply. This section only describes additions and changes introduced by the CEMA extension.
特に明記しない限り、RFC 4975およびRFC 4976のセキュリティに関する考慮事項が引き続き適用されます。このセクションでは、CEMA拡張によって導入された追加と変更についてのみ説明します。
The purpose of CEMA is to enable MSRP communication over Middleboxes. These Middleboxes are commonly deployed by SIP network operators, who also commonly deploy firewall and routing policies that prevent media sessions from working unless they traverse the Middleboxes.
CEMAの目的は、Middleboxを介したMSRP通信を可能にすることです。これらのミドルボックスは、SIPネットワークオペレーターによって一般的に展開されます。また、ミドルボックスを通過しない限りメディアセッションが機能しないようにするファイアウォールおよびルーティングポリシーも一般的に展開されます。
CEMA makes it possible for Middleboxes to tunnel TLS to allow end-to-end SAs between endpoints. This is an improvement over the status quo, since without CEMA, the Middleboxes would be forced to both read and modify the cleartext MSRP messages, which would make end-to-end confidentiality and integrity protection of the MSRP transport channel impossible.
CEMAを使用すると、MiddleboxがTLSをトンネリングして、エンドポイント間のエンドツーエンドのSAを許可できます。これは現状を改善したものです。CEMAがないと、ミドルボックスはクリアテキストMSRPメッセージの読み取りと変更の両方を強制されるため、MSRPトランスポートチャネルのエンドツーエンドの機密性と整合性の保護が不可能になります。
RFC 4975 suggests two ways for MSRP endpoints to verify that the TLS connection is established end to end. The first option is to use certificates from a well-known certification authority and verify that the SubjectAltName matches the MSRP URI of the other side. The second option is to use self-signed certificates and include a fingerprint of the certificate in the SDP offer/answer. Provided the signaling is integrity protected, both endpoints can verify that the TLS SA is established with the correct host by matching the received certificate against the received fingerprint.
RFC 4975は、MSRPエンドポイントがTLS接続がエンドツーエンドで確立されていることを確認する2つの方法を提案しています。最初のオプションは、よく知られた証明機関からの証明書を使用して、SubjectAltNameが相手側のMSRP URIと一致することを確認することです。 2番目のオプションは、自己署名証明書を使用し、SDPオファー/アンサーに証明書のフィンガープリントを含めることです。シグナリングが整合性保護されている場合、両方のエンドポイントは、受信した証明書を受信したフィンガープリントと照合することにより、TLS SAが正しいホストで確立されていることを確認できます。
Fingerprint-based authentication is expected to be common for end clients. In order to ensure the integrity of the fingerprint, RFC 4975 recommends using the SIP Identity mechanism [RFC4474]. However, this mechanism may not be compatible with CEMA, which operates under the assumption that Middleboxes will modify the contents of SDP offers and answers. Until a mechanism is available that enables a subset of the SDP to be signed, end clients that support CEMA and use fingerprint-based authentication are forced to trust the entire signaling path. In other words, end clients must accept the fact that every signaling proxy could potentially replace the fingerprints and insert a Middlebox that acts as a TLS B2BUA.
指紋ベースの認証は、エンドクライアントで一般的であると予想されます。フィンガープリントの整合性を確保するために、RFC 4975はSIP IDメカニズム[RFC4474]の使用を推奨しています。ただし、このメカニズムは、MiddleboxesがSDPオファーおよびアンサーのコンテンツを変更するという前提の下で動作するCEMAと互換性がない場合があります。 SDPのサブセットに署名できるメカニズムが利用可能になるまで、CEMAをサポートし、指紋ベースの認証を使用するエンドクライアントは、シグナリングパス全体を信頼する必要があります。言い換えると、エンドクライアントは、すべてのシグナリングプロキシがフィンガープリントを置き換え、TLS B2BUAとして機能するミドルボックスを挿入する可能性があるという事実を受け入れる必要があります。
An alternative solution that only requires a limited trust in the signaling plane is to use self-signed certificates together with the SIP Certificate Management Service [RFC6072]. The security provided by this solution is roughly equivalent to SIP Identity and fingerprint-based authentication (in fact, RFC 6072 is based on RFC 4474). Section 7.5 discusses this approach further.
シグナリングプレーンでの限られた信頼のみを必要とする代替ソリューションは、SIP証明書管理サービス[RFC6072]と共に自己署名証明書を使用することです。このソリューションによって提供されるセキュリティは、SIP IDおよび指紋ベースの認証とほぼ同等です（実際、RFC 6072はRFC 4474に基づいています）。セクション7.5では、このアプローチについてさらに説明します。
In the remainder of this section, we will assume that fingerprint-based authentication is used without SIP Identity or similar mechanisms that protect the SDP across several hops.
このセクションの残りの部分では、SIP IDや、いくつかのホップにまたがるSDPを保護する同様のメカニズムなしで、指紋ベースの認証が使用されると想定します。
If TLS is not used to protect MSRP, the CEMA extension might make it easier for a MITM to transparently insert itself in the communication between MSRP endpoints in order to monitor or record unprotected MSRP communication. This can be mitigated by the use of TLS. It is therefore RECOMMENDED that TLS [RFC5246] be used. It is also recommended that TLS be used end to end, which CEMA enables even in the case of Middleboxes. According to RFC 4975, MSRP endpoints are required to support TLS. This also applies to CEMA-enabled endpoints.
TLSを使用してMSRPを保護しない場合、CEMA拡張により、保護されていないMSRP通信を監視または記録するために、MITMがMSRPエンドポイント間の通信に自分自身を透過的に挿入しやすくなります。これは、TLSを使用することで軽減できます。したがって、TLS [RFC5246]を使用することをお勧めします。 TLSをエンドツーエンドで使用することもお勧めします。これは、ミドルボックスの場合でもCEMAが有効にします。 RFC 4975によれば、TLSをサポートするにはMSRPエンドポイントが必要です。これは、CEMA対応のエンドポイントにも適用されます。
If TLS is used without Middleboxes, the security considerations in RFC 4975 and RFC 4976 still apply unchanged. Note that this is not the main use case for the CEMA extension.
MiddleboxesなしでTLSを使用する場合でも、RFC 4975およびRFC 4976のセキュリティに関する考慮事項は変更されずに適用されます。これはCEMA拡張の主な使用例ではないことに注意してください。
This is the main use case for the CEMA extension; the endpoints expect one or more Middleboxes.
これはCEMA拡張の主な使用例です。エンドポイントは1つ以上のMiddleboxを想定しています。
The CEMA extension supports the usage of both name-based authentication and fingerprint-based authentication for TLS in the presence of Middleboxes. The use of fingerprint-based authentication requires signaling integrity protection. This can, for example, be hop-by-hop cryptographic protection or cryptographic access protection combined with a suitably protected core network. As stated in Section 6.4, this document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media.
CEMA拡張は、ミドルボックスの存在下でのTLSの名前ベース認証と指紋ベース認証の両方の使用をサポートしています。指紋ベースの認証を使用するには、シグナリング完全性保護が必要です。これは、たとえば、適切に保護されたコアネットワークと組み合わせたホップバイホップ暗号化保護または暗号化アクセス保護にすることができます。セクション6.4で述べたように、このドキュメントでは、MiddleboxがMSRPメディアに関連付けられたSDPアドレス情報を変更できることを前提としています。
If a Middlebox acts as a TLS B2BUA, the security considerations are the same as those without the CEMA extension. In such a case, the Middlebox acts as a TLS endpoint.
MiddleboxがTLS B2BUAとして機能する場合、セキュリティに関する考慮事項は、CEMA拡張がない場合と同じです。このような場合、MiddleboxはTLSエンドポイントとして機能します。
If a Middlebox does not act as a TLS B2BUA, TLS is end to end and the Middlebox just forwards the TLS packets. This requires that both peers support the CEMA extension.
MiddleboxがTLS B2BUAとして機能しない場合、TLSはエンドツーエンドであり、MiddleboxはTLSパケットを転送するだけです。これには、両方のピアがCEMA拡張をサポートしている必要があります。
If fingerprint-based authentication is used, the MSRP endpoints might not be able to decide whether or not the Middlebox acts as a TLS B2BUA. But this is not an issue, as the signaling network is considered trusted by the endpoint (a requirement to use fingerprint-based authentication).
指紋ベースの認証が使用されている場合、MSRPエンドポイントは、ミドルボックスがTLS B2BUAとして機能するかどうかを決定できない場合があります。ただし、シグナリングネットワークはエンドポイントによって信頼されていると見なされるため、これは問題ではありません（指紋ベースの認証を使用するための要件）。
One issue with the usage of TLS (not specific to CEMA) is the availability of a PKI. Endpoints can always provide self-signed certificates and include fingerprints in the SDP offer and answer. However, this relies on SDP signaling being integrity protected, which may not always be the case.
TLS（CEMAに固有ではない）の使用に関する1つの問題は、PKIの可用性です。エンドポイントは常に自己署名証明書を提供し、SDPオファーおよびアンサーにフィンガープリントを含めることができます。ただし、これは完全性が保護されているSDPシグナリングに依存しています。
Therefore, in addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also support self-signed certificates together with the Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints.
したがって、RFC 4975で定義されている認証メカニズムに加えて、CEMA対応のMSRPエンドポイントは、自己署名証明書を発行する証明書管理サービス[RFC6072]とともに自己署名証明書もサポートすることをお勧めします。他のエンドポイントの自己署名証明書をオンデマンドでフェッチします。
Alternate key distribution mechanisms, such as DNS-Based Authentication of Named Entities (DANE) [DANE], Pretty Good Privacy (PGP) [RFC6091], Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY-TICKET) [RFC6043], or some other technology, might become ubiquitous enough to solve the key distribution problem in the future.
名前付きエンティティのDNSベースの認証（DANE）[DANE]、Pretty Good Privacy（PGP）[RFC6091]、マルチメディアインターネットキーイングでのキー配布のチケットベースのモード（MIKEY-TICKET）[RFC6043]などの代替キー配布メカニズムやその他のテクノロジーは、将来の主要な配布問題を解決するのに十分なユビキタスになる可能性があります。
One of the target deployments for CEMA is the 3GPP IMS SIP network. In this environment, authentication and credential management are less of a problem, as the SDP signaling is mostly considered trusted, service providers provision signed certificates or manage signed certificates on behalf of their subscribers, and MIKEY-TICKET is available. Some of these options require trusting the service provider, but those issues are beyond the scope of this document.
CEMAのターゲット展開の1つは、3GPP IMS SIPネットワークです。この環境では、SDPシグナリングはほとんど信頼されていると見なされ、サービスプロバイダーは署名済み証明書をプロビジョニングするか、サブスクライバーに代わって署名済み証明書を管理します。MIKEY-TICKETが利用可能です。これらのオプションの一部はサービスプロバイダーを信頼する必要がありますが、それらの問題はこのドキュメントの範囲外です。
The CEMA extension does not change the endpoint procedures for TLS negotiation. As in RFC 4975, the MSRP endpoint uses the negotiation mechanisms in SDP and then the TLS handshake to agree on mechanisms and algorithms that both support. The mechanisms can be divided into three different security levels:
CEMA拡張は、TLSネゴシエーションのエンドポイント手順を変更しません。 RFC 4975と同様に、MSRPエンドポイントはSDPのネゴシエーションメカニズムを使用し、次にTLSハンドシェイクを使用して、両方がサポートするメカニズムとアルゴリズムについて合意します。メカニズムは、3つの異なるセキュリティレベルに分類できます。
1. MSRPS: Security mechanisms that do not rely on trusted signaling, such as name-based authentication
1. MSRPS：名前ベースの認証など、信頼されたシグナリングに依存しないセキュリティメカニズム
2. MSRPS: Mechanisms that do rely on trusted signaling, such as fingerprint-based authentication
2. MSRPS：指紋ベースの認証など、信頼できるシグナリングに依存するメカニズム
3. MSRP: Unprotected
3. MSRP：無保護
If the endpoint uses security mechanisms that do not rely on trusted signaling, the endpoint can detect if a Middlebox that acts as a B2BUA is inserted. It is therefore RECOMMENDED that such a mechanism be used.
エンドポイントがトラステッドシグナリングに依存しないセキュリティメカニズムを使用している場合、エンドポイントは、B2BUAとして機能するミドルボックスが挿入されているかどうかを検出できます。したがって、このようなメカニズムを使用することをお勧めします。
If the endpoint uses security mechanisms that rely on trusted signaling, the endpoint may not be able to detect if a Middlebox that acts as a B2BUA is inserted (by the trusted network operator). To be able to eavesdrop, a Middlebox must do an active "attack" on the setup signaling. A Middlebox cannot insert itself at a later point.
エンドポイントが信頼できるシグナリングに依存するセキュリティメカニズムを使用している場合、B2BUAとして機能するミドルボックスが（信頼できるネットワークオペレーターによって）挿入されているかどうかをエンドポイントが検出できない場合があります。盗聴できるようにするには、Middleboxがセットアップシグナリングに対してアクティブな「攻撃」を行う必要があります。 Middleboxは、後でそれ自体を挿入することはできません。
If unprotected MSRP is used, the endpoint cannot detect if a Middlebox that acts as a B2BUA is inserted and Middleboxes may be inserted at any time during the session.
保護されていないMSRPが使用されている場合、エンドポイントは、B2BUAとして機能するミドルボックスが挿入されているかどうかを検出できず、ミドルボックスはセッション中いつでも挿入できます。
The mechanism in RFC 6072 [RFC6072] provides end-to-end security without relying on trust in the signaling plane and eases the use and deployment of name-based authentication.
RFC 6072 [RFC6072]のメカニズムは、シグナリングプレーンでの信頼に依存することなくエンドツーエンドのセキュリティを提供し、名前ベースの認証の使用と展開を容易にします。
The procedures for choosing and offering name-based authentication, fingerprint-based authentication, and unprotected MSRP as described in RFC 4975 still apply.
RFC 4975で説明されている、名前ベースの認証、指紋ベースの認証、および保護されていないMSRPを選択して提供する手順は、引き続き適用されます。
If the endpoint cannot use a key management protocol that does not rely on trust in the signaling plane, such as name-based authentication, the only alternative is fingerprint-based authentication.
エンドポイントが、名前ベースの認証など、シグナリングプレーンでの信頼に依存しないキー管理プロトコルを使用できない場合、唯一の代替策は指紋ベースの認証です。
The use of fingerprint-based authentication requires integrity protection of the signaling plane. This can, for example, be hop-by-hop cryptographic protection or cryptographic access protection combined with a suitably protected core network. Unless cryptographic end-to-end SDP integrity protection or encryption is used, this may be hard for the endpoint to decide. In the end, it is up to the endpoint to decide whether the signaling path is trusted or not.
指紋ベースの認証を使用するには、シグナリングプレーンの整合性保護が必要です。これは、たとえば、適切に保護されたコアネットワークと組み合わせたホップバイホップ暗号化保護または暗号化アクセス保護にすることができます。暗号化のエンドツーエンドのSDP整合性保護または暗号化を使用しない限り、これはエンドポイントが判断するのが難しい場合があります。最後に、シグナリングパスが信頼できるかどうかを決定するのはエンドポイントです。
How this decision is done is implementation specific, but normally, signaling over the Internet SHOULD NOT be trusted. Signaling over a local or closed network might be trusted. Such networks can, for example, be a closed enterprise network or a network operated by an operator that the end user trusts. In IMS, for example, the signaling traffic in the access network is integrity protected and the traffic is routed over a closed network separated from the Internet. If the network is not trusted, the endpoints SHOULD NOT use fingerprint-based authentication.
この決定がどのように行われるかは実装固有ですが、通常、インターネット上のシグナリングは信頼すべきではありません。ローカルまたは閉じたネットワークを介したシグナリングは信頼できる場合があります。このようなネットワークは、たとえば、閉じた企業ネットワークや、エンドユーザーが信頼する事業者が運営するネットワークにすることができます。たとえば、IMSでは、アクセスネットワークのシグナリングトラフィックは完全性が保護されており、トラフィックはインターネットから分離された閉じたネットワークを介してルーティングされます。ネットワークが信頼されていない場合、エンドポイントは指紋ベースの認証を使用してはなりません。
When an endpoint receives a fingerprint, that fingerprint represents a binding between the identity as established by TLS and that established via SDP. As previously noted, the fingerprint is vulnerable to an active MITM attack from any on-path proxy. Endpoints SHOULD therefore locally store fingerprints associated with the relevant identities when first seen and SHOULD provide a warning when a new fingerprint is seen for what otherwise appears to be the same peer identity. While there are valid reasons for keys to change from time to time, that ought to be the exception -- hence the suggested warning.
エンドポイントがフィンガープリントを受信すると、そのフィンガープリントは、TLSによって確立されたIDとSDPを介して確立されたID間のバインディングを表します。前述のように、フィンガープリントは、パス上のプロキシからのアクティブなMITM攻撃に対して脆弱です。したがって、エンドポイントは、最初に表示されたときに関連するIDに関連付けられた指紋をローカルに格納する必要があり（SHOULD）、同じピアIDであると思われるものについて新しい指紋が表示されたときに警告を提供する必要があります。キーが時々変更される正当な理由はありますが、それは例外であるべきです-したがって、推奨される警告です。
It should, however, be noted that using fingerprint-based authentication over an insecure network increases the security compared to unencrypted MSRP. In order to intercept the plaintext media when fingerprint-based authentication is used, the attacker is required to be present on both the signaling and media paths and actively modify the traffic. It is very hard for the endpoints to detect when such an attack is taking place, though. A client using DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP) extension for Datagram Transport Layer Security (DTLS)) [RFC5764] for Voice over IP (VoIP) media security might wish to use fingerprint-based authentication also for MSRP media security.
ただし、安全でないネットワーク上で指紋ベースの認証を使用すると、暗号化されていないMSRPと比較してセキュリティが向上することに注意してください。指紋ベースの認証が使用されているときにプレーンテキストメディアを傍受するには、攻撃者がシグナリングパスとメディアパスの両方に存在し、トラフィックを積極的に変更する必要があります。ただし、エンドポイントがそのような攻撃が行われていることを検出することは非常に困難です。 Voice over IP（VoIP）メディアセキュリティにDTLS-SRTP（データグラムトランスポート層セキュリティ（DTLS）のセキュアリアルタイムトランスポートプロトコル（SRTP）拡張）を使用するクライアントは、MSRPにも指紋ベースの認証を使用したい場合があります。メディアセキュリティ。
MSRPS with fingerprint-based authentication is vulnerable to attacks due to vulnerabilities in the SIP signaling. If there are weaknesses in the integrity protections on the SIP signaling, an attacker may insert malicious Middleboxes to alter, record, or otherwise harm the media. With insecure signaling, it can be difficult for an endpoint to even be aware that the remote endpoint has any relationship to the expected endpoint. Securing the SIP signaling does not solve all problems. For example, in a SIP Secure (SIPS) environment, the endpoints have no cryptographic way of validating that one or more SIP proxies in the proxy chain are not, in fact, malicious.
指紋ベースの認証を使用するMSRPSは、SIPシグナリングの脆弱性が原因で攻撃に対して脆弱です。 SIPシグナリングの整合性保護に弱点がある場合、攻撃者は悪意のあるミドルボックスを挿入して、メディアを変更、記録、またはその他の方法で害する可能性があります。安全でないシグナリングでは、エンドポイントがリモートエンドポイントと予期されたエンドポイントとの関係があることを認識することさえ難しい場合があります。 SIPシグナリングを保護しても、すべての問題が解決するわけではありません。たとえば、SIPセキュア（SIPS）環境では、エンドポイントには、プロキシチェーン内の1つ以上のSIPプロキシが実際には悪意のないものであることを検証する暗号化の方法がありません。
IANA has added an attribute to the 'att-field (media level only)' registry of the Session Description Protocol (SDP) Parameters registry, according to the information provided in this section.
このセクションで提供される情報に従って、IANAは、Session Description Protocol（SDP）パラメータレジストリの「att-field（メディアレベルのみ）」レジストリに属性を追加しました。
This section registers a new SDP attribute, 'msrp-cema'. The required information for this registration, as specified in RFC 4566, is as follows:
このセクションでは、新しいSDP属性「msrp-cema」を登録します。 RFC 4566で指定されている、この登録に必要な情報は次のとおりです。
Contact name: Christer Holmberg
連絡先名：Christer Holmberg
Contact email: christer.holmberg@ericsson.com
連絡先メールアドレス：christer.holmberg@ericsson.com
Attribute name: msrp-cema
属性名：msrp-cema
Type of attribute: media level Purpose: This attribute is used to indicate support of the MSRP Connection Establishment for Media Anchoring (CEMA) extension defined in RFC 6714. When present in an MSRP media description of an SDP body, it indicates that the creator of the SDP supports the CEMA mechanism.
属性のタイプ：メディアレベル目的：この属性は、RFC 6714で定義されたメディアアンカー（CEMA）拡張のMSRP接続確立のサポートを示すために使用されます。SDP本体のMSRPメディア記述に存在する場合、 SDPはCEMAメカニズムをサポートします。
Values: The attribute does not carry a value.
値：属性には値がありません。
Charset dependency: none
文字セットの依存関係：なし
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, Ted Hardie, Richard L. Barnes, Inaki Baz Castillo, Saul Ibarra Corretge, Cullen Jennings, Adrian Georgescu, Miguel Garcia, and Paul Kyzivat for their guidance and input in order to produce this document.
ベン・キャンベル、レミ・デニス＝クールモント、ナンシー・グリーン、ハドリエル・カプラン、アダム・ローチ、ロバート・スパークス、サルヴァトーレ・ロレート、シダ・シューベルト、テッド・ハーディ、リチャード・L・バーンズ、イナキ・バズ・カスティージョ、ソール・イバラ・コレッジ、カレン・ジェニングス、アドリアン・ジョルジェスク、このドキュメントを作成するためのガイダンスと意見を提供してくれたMiguel GarciaとPaul Kyzivat。
Thanks to John Mattsson, Oscar Ohlsson, Ben Campbell, and Stephen Farrell for their help in restructuring the Security Considerations section, based on feedback from the IESG.
IESGからのフィードバックに基づいて、「セキュリティに関する考慮事項」セクションの再構築に協力してくれたJohn Mattsson、Oscar Ohlsson、Ben Campbell、および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月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[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月。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Ed。、Mahy、R.、Ed。、and C. Jennings、Ed。、 "The Message Session Relay Protocol（MSRP）"、RFC 4975、September 2007。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[RFC4976] Jennings、C.、Mahy、R。、およびA. Roach、「Relay Extensions for the Message Sessions Relay Protocol（MSRP）」、RFC 4976、2007年9月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC6072] Jennings, C. and J. Fischl, Ed., "Certificate Management Service for the Session Initiation Protocol (SIP)", RFC 6072, February 2011.
[RFC6072] Jennings、C.およびJ. Fischl、Ed。、「Certificate Management Service for the Session Initiation Protocol（SIP）」、RFC 6072、2011年2月。
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, February 2011.
[RFC6135] Holmberg、C。およびS. Blau、「メッセージセッションリレープロトコル（MSRP）の代替接続モデル」、RFC 6135、2011年2月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724] Kempf、J.、Ed。、Austein、R.、Ed。、およびIAB、「中間の台頭とエンドツーエンドの未来：インターネットアーキテクチャの進化に関する考察」、RFC 3724 、2004年3月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月。
[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, May 2010.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのデータグラムトランスポート層セキュリティ（DTLS）拡張」、RFC 5764、2010年5月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010。
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
[RFC6043] Mattsson、J。およびT. Tian、「MIKEY-TICKET：チケットベースモードのマルチメディアインターネットキーイング（MIKEY）でのキー配布」、RFC 6043、2011年3月。
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, February 2011.
[RFC6091] Mavrogiannopoulos、N。およびD. Gillmor、「Using OpenPGP Keys for Transport Layer Security（TLS）Authentication」、RFC 6091、2011年2月。
[GPP23228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 11.5.0, June 2012, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[GPP23228] 3GPP、「IPマルチメディアサブシステム（IMS）;ステージ2」、3GPP TS 23.228 11.5.0、2012年6月、<http://www.3gpp.org/ftp/Specs/html-info/23228.htm> 。
[DANE] "DNS-Based Authentication of Named Entities (DANE) Working Group", <https://datatracker.ietf.org/wg/dane/charter/>.
[DANE]「名前付きエンティティのDNSベースの認証（DANE）ワーキンググループ」、<https://datatracker.ietf.org/wg/dane/charter/>。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com
Staffan Blau Ericsson Stockholm 12637 Sweden
Staffan Blau Ericssonストックホルム12637スウェーデン
EMail: staffan.blau@ericsson.com
Eric Burger Georgetown University Department of Computer Science 37th and O Streets, NW Washington, DC 20057-1232 United States of America
エリックバーガージョージタウン大学コンピュータサイエンス学部37th and O Streets、NWワシントンDC 20057-1232アメリカ合衆国
Fax: +1 530 267 7447
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com