[要約] RFC 7345は、UDPTLをDTLSで保護するためのプロトコル仕様です。目的は、セキュアな通信を提供し、データの機密性と完全性を確保することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7345 I. Sedlacek
Category: Standards Track Ericsson
ISSN: 2070-1721 G. Salgueiro
Cisco
August 2014
UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
データグラムトランスポート層セキュリティ（DTLS）上のUDPトランスポート層（UDPTL）
Abstract
概要
This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).
このドキュメントでは、T.38 FAXの主要なトランスポートプロトコルであるUDPトランスポート層（UDPTL）プロトコルを、データグラムトランスポート層セキュリティ（DTLS）プロトコルを介して転送する方法、およびセッションの説明でUDPTLを介したUDPTLの使用法を示す方法について説明します。プロトコル（SDP）、およびセッション開始プロトコル（SIP）を使用して確立されたセッションでUDPTL over DTLSがネゴシエートされる方法。
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/rfc7345.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7345で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................5
3. Secure Channel ..................................................5
4. SDP Offerer/Answerer Procedures .................................6
4.1. General ....................................................6
4.2. Generating the Initial Offer ...............................7
4.3. Generating the Answer ......................................7
4.4. Offerer Processing of the Answer ...........................7
4.5. Modifying the Session ......................................7
5. Miscellaneous Considerations ....................................8
5.1. Anonymous Calls ............................................8
5.2. NAT Traversal ..............................................8
5.2.1. ICE Usage ...........................................8
5.2.2. STUN Interaction ....................................8
5.3. Rekeying ...................................................9
5.4. Compatibility with UDPTL over UDP ..........................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Examples .............................................13
A.1. General ...................................................13
A.2. Basic Message Flow ........................................13
A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in
an Existing Audio-Only Session ............................20
While it is possible to transmit highly sensitive documents using traditional telephony encryption devices, secure fax on the Public Switched Telephone Network (PSTN) was never widely considered or prioritized. This was mainly because of the challenges involved with malevolent physical access to telephony equipment. As real-time communications transition to IP networks, where information might potentially be intercepted or spoofed, an appropriate level of security for fax that offers integrity and confidentiality protection is vital.
従来のテレフォニー暗号化デバイスを使用して機密性の高いドキュメントを送信することは可能ですが、公衆交換電話網（PSTN）での安全なFAXが広く検討または優先されることはありませんでした。これは主に、電話機器への悪意のある物理的アクセスに伴う課題が原因でした。リアルタイムの通信がIPネットワークに移行すると、情報が傍受またはなりすまされる可能性があるため、完全性と機密性の保護を提供する適切なレベルのFAXのセキュリティが不可欠です。
The overwhelmingly predominant fax transport protocol is UDPTL-based, as described in Section 9.1 of [ITU.T38.2010]. The protocol stack for fax transport using UDPTL is shown in Figure 1.
[ITU.T38.2010]のセクション9.1で説明されているように、圧倒的に圧倒的なFAXトランスポートプロトコルはUDPTLベースです。 UDPTLを使用したFAXトランスポートのプロトコルスタックを図1に示します。
+-----------------------------+
| Internet facsimile protocol |
+-----------------------------+
| UDPTL |
+-----------------------------+
| UDP |
+-----------------------------+
| IP |
+-----------------------------+
Figure 1: Protocol Stack for UDPTL over UDP
図1：UDPTL over UDPのプロトコルスタック
The following mechanisms are available for securing fax:
FAXを保護するために次のメカニズムを使用できます。
o Annex H of [ITU.T30.2005] specifies an application-layer integrity and confidentiality protection of fax that is independent of the transport protocol and is based on the RSA algorithm for use with the T.30 telephony protocol by Group 3 facsimile equipment (G3FE).
o [ITU.T30.2005]のAnnex Hは、トランスポートプロトコルに依存せず、グループ3ファクシミリ装置によるT.30テレフォニープロトコルで使用するためのRSAアルゴリズムに基づく、アプリケーションレイヤーの完全性とファックスの機密保護を規定しています（ G3FE）。
o [ITU.T38.2010] specifies fax transport over RTP/SAVP, which enables integrity and confidentiality protection of fax in IP networks.
o [ITU.T38.2010]は、RTP / SAVPを介したFAXトランスポートを指定します。これにより、IPネットワークでFAXの整合性と機密性を保護できます。
Both of these mechanisms have been available for many years and never gained any significant adoption in the market. This has prompted an effort to develop an approach, based on open standards, for securing fax communications over an IP-based transport.
これらのメカニズムはどちらも長年使用可能であり、市場で大きな採用はありませんでした。これにより、IPベースのトランスポートを介したFAX通信をセキュリティで保護するための、オープンスタンダードに基づくアプローチを開発する取り組みが促進されました。
Telephony-based protocols like T.30 offer application-level security options like the RSA-based approach detailed in Annex H of the T.30 specification [ITU.T30.2005]. The problem is that it is very sparingly implemented and not enforced at the transport level.
T.30のようなテレフォニーベースのプロトコルは、T.30仕様の付録Hに詳述されているRSAベースのアプローチのようなアプリケーションレベルのセキュリティオプションを提供します[ITU.T30.2005]。問題は、それが非常に控えめに実装されており、トランスポートレベルで強制されていないことです。
It is worth noting that while T.38 over RTP offers a very viable option for such standards-based IP security solution using Secure Realtime Transport Protocol (SRTP), this fax-over-IP transport never gained any traction in the marketplace and accounts for a negligible percentage of fax-over-IP implementations.
T.38 over RTPは、セキュアリアルタイムトランスポートプロトコル（SRTP）を使用するこのような標準ベースのIPセキュリティソリューションに非常に実行可能なオプションを提供しますが、このFAX-over-IPトランスポートは、市場で牽引力を獲得したことは決してありません。 fax-over-IP実装のごくわずかな割合。
Thus, security mechanisms offering integrity and confidentiality protection should be limited to UDPTL-based fax transport, which is the only broad-based fax-over-IP solution. The 3rd Generation Partnership Project (3GPP) launched a study on how best to provide secure fax in the IP Multimedia Subsystem (IMS) for UDPTL. Results of the study confirmed that this security was best achieved by using UDPTL over DTLS.
したがって、整合性と機密保護を提供するセキュリティメカニズムは、UDPTLベースのFAXトランスポートに限定する必要があります。これは、唯一の広範なベースのFAX over IPソリューションです。第3世代パートナーシッププロジェクト（3GPP）は、UDPTLのIPマルチメディアサブシステム（IMS）で安全なFAXを提供するための最良の方法に関する調査を開始しました。調査の結果、このセキュリティはUDPTLS over DTLSを使用することで最もよく達成されることが確認されました。
This document specifies fax transport using UDPTL over DTLS [RFC6347], which enables integrity and confidentiality protection of fax in IP networks. The protocol stack that enhances fax transport to offer integrity and confidentiality using UDPTL over DTLS is shown in Figure 2.
このドキュメントでは、UDPTL over DTLS [RFC6347]を使用したFAXトランスポートを指定します。これにより、IPネットワークでFAXの整合性と機密性を保護できます。 FTLSトランスポートを拡張して、UDPTL over DTLSを使用して整合性と機密性を提供するプロトコルスタックを図2に示します。
+-----------------------------+
| Internet facsimile protocol |
+-----------------------------+
| UDPTL |
+-----------------------------+
| DTLS |
+-----------------------------+
| UDP |
+-----------------------------+
| IP |
+-----------------------------+
Figure 2: Protocol Stack for UDPTL over DTLS over UDP
図2：UDPTLS over UDPのプロトコルスタック
The primary motivations for the mechanism in this document are:
このドキュメントのメカニズムの主な動機は次のとおりです。
o The design of DTLS [RFC6347] is clearly defined and well understood, and implementations are widely available.
o DTLS [RFC6347]の設計は明確に定義され、よく理解されており、実装は広く利用可能です。
o No DTLS extensions are required in order to enable UDPTL transport over DTLS.
o DTLSを介したUDPTLトランスポートを有効にするために、DTLS拡張は必要ありません。
o Fax transport using UDPTL over DTLS only requires insertion of the DTLS layer between the UDPTL layer and the UDP layer, as shown in Figure 2. The UDPTL layer and the layers above the UDPTL layer require no modifications.
o UDPTL over DTLSを使用するFAXトランスポートでは、図2に示すように、UDPTLレイヤーとUDPレイヤーの間にDTLSレイヤーを挿入するだけで済みます。UDPTLレイヤーとUDPTLレイヤーの上のレイヤーは変更する必要がありません。
o UDPTL [ITU.T38.2010] is by far the most widely deployed fax transport protocol in IP networks.
o UDPTL [ITU.T38.2010]は、IPネットワークでこれまでで最も広く展開されているFAXトランスポートプロトコルです。
o 3GPP and the IP fax community need a mechanism to transport UDPTL over DTLS in order to provide secure fax in SIP-based networks (including IMS).
o 3GPPおよびIPファックスコミュニティには、SIPベースのネットワーク（IMSを含む）でセキュアなファックスを提供するために、UDPTL over DTLSを転送するメカニズムが必要です。
This document specifies the transport of UDPTL over DTLS using the DTLS record layer "application_data" packets [RFC5246] [RFC6347].
このドキュメントは、DTLSレコードレイヤー「application_data」パケットを使用したDTLSを介したUDPTLのトランスポートを指定します[RFC5246] [RFC6347]。
Since the DTLS record layer "application_data" packet does not indicate whether it carries UDPTL or some other protocol, the usage of a dedicated DTLS association for transport of UDPTL needs to be negotiated, e.g., using the Session Description Protocol (SDP) [RFC4566] and the SDP offer/answer mechanism [RFC3264].
DTLSレコードレイヤーの「application_data」パケットは、UDPTLと他のプロトコルのどちらを伝送するかを示していないため、UDPTLのトランスポート用の専用DTLSアソシエーションの使用は、例えば、Session Description Protocol（SDP）[RFC4566]を使用してネゴシエートする必要があります。 SDPオファー/アンサーメカニズム[RFC3264]。
Therefore, this document specifies a new <proto> value [RFC4566] for the SDP media description ("m=" line) [RFC3264], in order to indicate UDPTL over DTLS in SDP messages [RFC4566].
したがって、このドキュメントでは、SDPメッセージ[RFC4566]でDTLS上のUDPTLを示すために、SDPメディアの説明（ "m ="行）[RFC3264]に新しい<proto>値[RFC4566]を指定しています。
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]で説明されているように解釈されます。
DTLS uses the term "session" to refer to a long-lived set of keying material that spans DTLS associations. In this document, in order to be consistent with SIP/SDP usage of "session" terminology, we use "session" to refer to a multimedia session and use the term "DTLS session" to refer to the DTLS construct. We use the term "DTLS association" to refer to a particular DTLS cipher suite and keying material set that is associated with a single host/port quartet. The same DTLS session can be used to establish the keying material for multiple DTLS associations. For consistency with other SIP/SDP usage, we use the term "connection" when what's being referred to is a multimedia stream that is not specifically DTLS.
DTLSは、「セッション」という用語を使用して、DTLSアソシエーションにまたがる長期間有効な鍵情報のセットを指します。このドキュメントでは、「セッション」という用語のSIP / SDP使用法と一致させるために、「セッション」を使用してマルチメディアセッションを指し、「DTLSセッション」という用語を使用してDTLS構造を指します。 「DTLSアソシエーション」という用語は、特定のDTLS暗号スイートと、単一のホスト/ポートカルテットに関連付けられているキー情報セットを指すために使用します。同じDTLSセッションを使用して、複数のDTLSアソシエーションのキー情報を確立できます。他のSIP / SDPの使用との一貫性を保つために、言及されているのが特にDTLSではないマルチメディアストリームである場合は、「接続」という用語を使用します。
The UDPTL-over-DTLS media stream is negotiated using the SDP offer/ answer mechanism [RFC3264]. See Section 4 for more details.
UDPTL-over-DTLSメディアストリームは、SDPオファー/アンサーメカニズム[RFC3264]を使用してネゴシエートされます。詳細については、セクション4を参照してください。
DTLS is used as specified in [RFC6347]. Once the DTLS handshake is successfully completed (in order to prevent facsimile data from being transmitted insecurely), the UDPTL packets MUST be transported in DTLS record layer "application_data" packets.
[RFC6347]で指定されているとおりにDTLSが使用されます。 DTLSハンドシェイクが正常に完了すると（ファクシミリデータが安全に送信されないようにするため）、UDPTLパケットをDTLSレコードレイヤーの "application_data"パケットで転送する必要があります。
An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each UDPTL-over-DTLS media stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the "proto" field of the "m=" line.
エンドポイント（つまり、提供者と回答者の両方）は、UDPTL-over-DTLSメディアストリームごとにSDPメディア記述（ "m ="行）を作成し、UDP / TLS / UDPTL値（表1を参照）を割り当てなければなりません（表1を参照）。 「m =」行の「proto」フィールド。
The procedures in this section apply to an "m=" line associated with a UDPTL-over-DTLS media stream.
このセクションの手順は、UDPTL-over-DTLSメディアストリームに関連付けられた「m =」行に適用されます。
In order to negotiate a UDPTL-over-DTLS media stream, the following SDP attributes are used:
UDPTL-over-DTLSメディアストリームをネゴシエートするために、次のSDP属性が使用されます。
o The SDP attributes defined for UDPTL over UDP, as described in [ITU.T38.2010]; and
o [ITU.T38.2010]で説明されているUDPTL over UDPに対して定義されたSDP属性。そして
o The SDP attributes, defined in [RFC4145] and [RFC4572], as described in this section.
o このセクションで説明されている[RFC4145]および[RFC4572]で定義されているSDP属性。
The endpoint MUST NOT use the SDP "connection" attribute [RFC4145].
エンドポイントは、SDPの「接続」属性を使用してはなりません[RFC4145]。
In order to negotiate the TLS roles for the UDPTL-over-DTLS transport connection, the endpoint MUST use the SDP "setup" attribute [RFC4145].
UDPTL-over-DTLSトランスポート接続のTLSロールをネゴシエートするために、エンドポイントはSDPの「セットアップ」属性[RFC4145]を使用する必要があります。
If the endpoint supports, and is willing to use, a cipher suite with an associated certificate, the endpoint MUST include an SDP "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 for generating and verifying the SDP "fingerprint" attribute value. The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward Secrecy (PFS) cipher suites over non-PFS cipher suites. Implementations SHOULD disable TLS-level compression.
エンドポイントが証明書と関連付けられた暗号スイートをサポートし、使用する意思がある場合、エンドポイントはSDPの「フィンガープリント」属性[RFC4572]を含める必要があります。エンドポイントは、SDP「フィンガープリント」属性値を生成および検証するためにSHA-256をサポートする必要があります。 SHA-256の使用が推奨されます。 UDPTLS over DTLSは、少なくともTLS_DHE_RSA_WITH_AES_128_GCM_SHA256をサポートする必要があり、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256をサポートする必要があります。 UDPTL over DTLSは、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256およびその他のPFS（Perfect Forward Secrecy）暗号スイートを非PFS暗号スイートよりも優先する必要があります。実装はTLSレベルの圧縮を無効にする必要があります（SHOULD）。
If a cipher suite with an associated certificate is selected during the DTLS handshake, the certificate received during the DTLS handshake MUST match the fingerprint received in the SDP "fingerprint" attribute. If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects.
関連する証明書を持つ暗号スイートがDTLSハンドシェイク中に選択された場合、DTLSハンドシェイク中に受信された証明書は、SDPの「フィンガープリント」属性で受信されたフィンガープリントと一致する必要があります。フィンガープリントがハッシュされた証明書と一致しない場合、エンドポイントはメディアセッションを直ちに破棄する必要があります。接続を確立する前に、相手側の指紋が受信されるまで待つことは許容されることに注意してください。ただし、これには望ましくない遅延の影響がある可能性があります。
The offerer SHOULD assign the SDP "setup" attribute with a value of "actpass", unless the offerer insists on being either the sender or receiver of the DTLS ClientHello message, in which case the offerer can use either a value of "active" (the offerer will be the sender of ClientHello) or "passive" (the offerer will be the receiver of ClientHello). The offerer MUST NOT assign an SDP "setup" attribute with a "holdconn" value.
提供者は、DTLS ClientHelloメッセージの送信者または受信者のいずれかであると主張しない限り、SDPの「設定」属性に「actpass」の値を割り当てる必要があります。この場合、提供者は「アクティブ」の値を使用できます（提供者はClientHelloの送信者になります）または "パッシブ"（提供者はClientHelloの受信者になります）。提案者は、「holdconn」値を使用してSDPの「セットアップ」属性を割り当ててはなりません（MUST NOT）。
If the offerer assigns the SDP "setup" attribute with a value of "actpass" or "passive", the offerer MUST be prepared to receive a DTLS ClientHello message before it receives the SDP answer.
オファー提供者が「actpass」または「パッシブ」の値でSDP「セットアップ」属性を割り当てる場合、オファー提供者は、SDP回答を受信する前に、DTLS ClientHelloメッセージを受信する準備ができていなければなりません。
If the answerer accepts the offered UDPTL-over-DTLS transport connection, in the associated SDP answer, the answerer MUST assign an SDP "setup" attribute with a value of either "active" or "passive", according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP "setup" attribute with a value of "holdconn".
回答者が提供されたUDPTL-over-DTLSトランスポート接続を受け入れる場合、関連するSDP回答で、回答者は[RFC4145]の手順に従って、「アクティブ」または「パッシブ」のいずれかの値を持つSDP「セットアップ」属性を割り当てる必要があります。 ]。回答者は、 "holdconn"の値を持つSDP "setup"属性を割り当ててはなりません（MUST NOT）。
If the answerer assigns an SDP "setup" attribute with a value of "active" value, the answerer MUST initiate a DTLS handshake by sending a DTLS ClientHello message on the negotiated media stream, towards the IP address and port of the offerer.
回答者が「アクティブ」値の値を持つSDP「セットアップ」属性を割り当てる場合、回答者は、交渉されたメディアストリームで、提供者のIPアドレスとポートに向けてDTLS ClientHelloメッセージを送信することにより、DTLSハンドシェイクを開始する必要があります。
When the offerer receives an SDP answer, if the offerer ends up being active it MUST initiate a DTLS handshake by sending a DTLS ClientHello message on the negotiated media stream, towards the IP address and port of the answerer.
オファー提供者がSDP応答を受信すると、オファー提供者がアクティブになると、交渉済みメディアストリームでDTLS ClientHelloメッセージを送信して、回答者のIPアドレスとポートに向けてDTLSハンドシェイクを開始する必要があります。
Once an offer/answer exchange has been completed, either endpoint MAY send a new offer in order to modify the session. The endpoints can reuse the existing DTLS association if the key fingerprint values and transport parameters indicated by each endpoint are unchanged. Otherwise, following the rules for the initial offer/answer exchange, the endpoints can negotiate and create a new DTLS association and, once created, delete the previous DTLS association, following the same rules for the initial offer/answer exchange. Each endpoint needs to be prepared to receive data on both the new and old DTLS associations as long as both are alive.
オファー/アンサーの交換が完了すると、どちらかのエンドポイントがセッションを変更するために新しいオファーを送信する場合があります。各エンドポイントによって示されるキーフィンガープリント値とトランスポートパラメータが変更されていない場合、エンドポイントは既存のDTLSアソシエーションを再利用できます。それ以外の場合、エンドポイントは、最初のオファー/アンサー交換のルールに従って、新しいDTLSアソシエーションをネゴシエートして作成し、最初のオファー/アンサー交換の同じルールに従って、以前のDTLSアソシエーションを削除できます。各エンドポイントは、両方が有効である限り、新しいDTLSアソシエーションと古いDTLSアソシエーションの両方でデータを受信できるように準備する必要があります。
When making anonymous calls, a new self-signed certificate SHOULD be used for each call, and attributes inside the certificate MUST NOT contain information that allows either correlation or identification of the user making anonymous calls. This is particularly important for the "subjectAltName" and "commonName" attributes.
匿名の呼び出しを行う場合、新しい自己署名証明書を呼び出しごとに使用する必要があります（SHOULD）。証明書内の属性には、匿名の呼び出しを行うユーザーの相関または識別を可能にする情報を含めてはなりません。これは、「subjectAltName」属性と「commonName」属性で特に重要です。
When Interactive Connectivity Establishment (ICE) [RFC5245] is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. User Agents (UAs) MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream. In the case of an ICE restart, the DTLS handshake procedure is repeated, and a new DTLS association is created. Once the DTLS handshake is completed and the new DTLS association has been created, the previous DTLS association is deleted.
インタラクティブ接続確立（ICE）[RFC5245]が使用されている場合、DTLSハンドシェイクが開始する前にICE接続チェックが実行されます。積極的な指名モードが使用されている場合、ICEが最終的に単一の候補ペアに収束する前に、複数の候補ペアが有効とマークされる場合があることに注意してください。ユーザーエージェント（UA）は、単一のコンポーネントに関連付けられているすべてのICE候補ペアを、同じDTLSアソシエーションの一部として扱う必要があります。したがって、有効な候補ペアが複数ある場合でも、DTLSハンドシェイクは1つしかありません。これは、DTLSパケットが通常のメディアストリームであるかのように、選択した候補ペアがシフトした場合、エンドポイントIPアドレスを調整することを意味する場合があることに注意してください。 ICEの再起動の場合、DTLSハンドシェイク手順が繰り返され、新しいDTLSアソシエーションが作成されます。 DTLSハンドシェイクが完了し、新しいDTLSアソシエーションが作成されると、以前のDTLSアソシエーションは削除されます。
The UA MUST send the Session Traversal Utilities for NAT (STUN) packets [RFC5389] directly over UDP, not over DTLS.
UAは、DTLSではなくUDPを介して、NAT（STUN）パケット[RFC5389]のセッショントラバーサルユーティリティを直接送信する必要があります。
The UA MUST support the following mechanism for demultiplexing packets arriving on the IP address and port associated with the DTLS association:
UAは、DTLSアソシエーションに関連付けられたIPアドレスとポートに到着するパケットを逆多重化するための次のメカニズムをサポートする必要があります。
o If the value of the first byte of the packet is 0 or 1, then the packet is STUN.
o パケットの最初のバイトの値が0または1の場合、パケットはSTUNです。
o If the value of the first byte of the packet is between 20 and 63 (inclusive), the packet is DTLS.
o パケットの最初のバイトの値が20〜63（両端を含む）の場合、パケットはDTLSです。
During rekeying, packets protected by the previous set of keys can arrive after the DTLS handshake caused by rekeying has completed, because packets can be reordered on the wire. To compensate for this fact, receivers MUST maintain both sets of keys for some time in order to be able to decrypt and verify older packets. The duration of maintaining the previous set of keys after the finish of the DTLS handshake is out of the scope of this document.
キーの再生成中、パケットはワイヤ上で並べ替えられるため、キーの再生成によって発生したDTLSハンドシェイクの完了後に、前のキーセットで保護されたパケットが到着する可能性があります。この事実を補うために、受信者は古いパケットを解読して検証できるように、両方のキーのセットをしばらくの間維持する必要があります。 DTLSハンドシェイクの完了後、以前のキーのセットを維持する期間は、このドキュメントの範囲外です。
If a user requires fax to be transported securely using UDPTL over DTLS, and if the remote user does not support UDPTL over DTLS, then a fax media stream cannot be established.
ユーザーがUDPTLS over DTLSを使用してFAXを安全に転送する必要があり、リモートユーザーがUDPTL over DTLSをサポートしていない場合、FAXメディアストリームを確立できません。
If a user prefers fax to be transported securely using UDPTL over DTLS but is willing to transport the fax insecurely in case the remote user does not support UDPTL over DTLS, then the SDP Capability Negotiation mechanism [RFC5939] can be used to offer both UDPTL over DTLS and UDPTL over UDP. Alternatively, if the remote user rejects an SDP offer for UDPTL over DTLS, a new SDP offer for a UDPTL-over-UDP media stream can be sent.
ユーザーがUDPTLS over DTLSを使用して安全にFAXを転送することを好むが、リモートユーザーがUDPTLS over DTLSをサポートしていない場合に備えて、安全でない方法でFAXを転送する場合は、SDP機能ネゴシエーションメカニズム[RFC5939]を使用して、両方のUDPTLを提供できます。 UDP上のDTLSおよびUDPTL。あるいは、リモートユーザーがUDPTL over DTLSのSDPオファーを拒否した場合、UDPTL-over-UDPメディアストリームの新しいSDPオファーを送信できます。
Fax may be used to transmit a wide range of sensitive data, including personal, corporate, and governmental information. It is therefore critical to be able to protect against threats to the confidentiality and integrity of the transmitted data.
FAXは、個人情報、企業情報、政府情報など、さまざまな機密データの送信に使用できます。したがって、送信データの機密性と完全性に対する脅威から保護できることが重要です。
The mechanism in this document provides integrity and confidentiality protection for fax by specifying fax transport using UDPTL over DTLS [RFC6347].
このドキュメントのメカニズムは、UDPTL over DTLS [RFC6347]を使用してFAXトランスポートを指定することにより、FAXの整合性と機密性を保護します。
DTLS media stream negotiated using SIP/SDP requires a mechanism to ensure that the certificate received via DTLS was issued by the remote party of the SIP session.
SIP / SDPを使用してネゴシエートされたDTLSメディアストリームには、DTLSを介して受信した証明書がSIPセッションのリモートパーティによって発行されたことを確認するメカニズムが必要です。
The standard DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC5280] certificate. The client then verifies the certificate and checks that the name in the certificate matches the server's domain name. This works because there are a relatively small number of servers and the cost for issuing and deploying PKIX certificates can be justified. Issuing and deploying PKIX certificates to all clients is not realistic in most deployment scenarios.
通信相手を認証するための標準のDTLS戦略は、サーバー（およびオプションでクライアント）にPKIX [RFC5280]証明書を与えることです。次に、クライアントは証明書を検証し、証明書内の名前がサーバーのドメイン名と一致することを確認します。これが機能するのは、サーバーの数が比較的少なく、PKIX証明書の発行と展開のコストを正当化できるためです。 PKIX証明書を発行してすべてのクライアントに展開することは、ほとんどの展開シナリオでは現実的ではありません。
The design described in this document is intended to leverage the integrity protection of the SIP signaling, while not requiring confidentiality. As long as each side of the connection can verify the integrity of the SDP received from the other side, then the DTLS handshake cannot be hijacked via a man-in-the-middle attack. This integrity protection is easily provided by the caller to the callee via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as the S/MIME mechanism [RFC3261] or perhaps future mechanisms yet to be specified, could also serve this purpose.
このドキュメントで説明する設計は、SIPシグナリングの完全性保護を活用することを目的としていますが、機密性は必要ありません。接続の両側で相手側から受信したSDPの整合性を確認できる限り、DTLSハンドシェイクは中間者攻撃を介してハイジャックできません。この完全性保護は、SIP ID [RFC4474]メカニズムを介して、呼び出し元から呼び出し先に簡単に提供されます。 S / MIMEメカニズム[RFC3261]や、おそらくまだ明記されていない将来のメカニズムなど、他のメカニズムもこの目的に役立ちます。
While this mechanism can still be used without such integrity mechanisms, the security provided is limited to defense against passive attack by intermediaries. An active attack on the signaling plus an active attack on the media plane can allow an attacker to attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
このメカニズムは、このような整合性メカニズムがなくても使用できますが、提供されるセキュリティは、仲介者による受動的な攻撃に対する防御に限定されます。シグナリングに対するアクティブな攻撃とメディアプレーンに対するアクティブな攻撃により、攻撃者が接続を攻撃する可能性があります（[RFC5479]の表記ではR-SIG-MEDIA）。
This document updates the "Session Description Protocol (SDP) Parameters" registry as specified in Section 8.2.2 of [RFC4566]. Specifically, the values in Table 1 have been added to the SDP "proto" field registry.
このドキュメントは、[RFC4566]のセクション8.2.2で指定されている「Session Description Protocol（SDP）Parameters」レジストリを更新します。具体的には、表1の値がSDPの「proto」フィールドレジストリに追加されています。
+-------+---------------+-----------+
| Type | SDP Name | Reference |
+-------+---------------+-----------+
| proto | UDP/TLS/UDPTL | [RFC7345] |
+-------+---------------+-----------+
Table 1: SDP "proto" Field Values
表1：SDPの「proto」フィールドの値
Special thanks to Peter Dawes, who provided comments on the initial draft version of the document, and to Paul E. Jones, James Rafferty, Albrecht Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler, Ari Keranen, Flemming Andreasen, John Mattsson, and Marc Petit-Huguenin, who provided valuable feedback and input. Barry Leiba, Spencer Dawkins, Pete Resnick, Kathleen Moriarty, and Stephen Farrell provided valuable feedback during the IESG review. Thanks to Scott Brim for performing the Gen-ART review. Thanks to Alissa Cooper for her help as sponsoring Area Director.
ドキュメントの最初のドラフトバージョンにコメントを提供してくれたPeter Dawes、Paul E. Jones、James Rafferty、Albrecht Schwarz、Oscar Ohlsson、David Hanes、Adam Gensler、Ari Keranen、Flemming Andreasen、John Mattsson、および貴重なフィードバックとインプットを提供してくれたMarc Petit-Huguenin。 IESGレビューでは、バリーレイバ、スペンサードーキンス、ピートレズニック、キャスリーンモリアーティ、スティーブンファレルが貴重なフィードバックを提供してくれました。 Gen-ARTレビューを実行してくれたScott Brimに感謝します。エリアディレクターのスポンサーとして支援してくれたアリッサクーパーに感謝します。
[ITU.T30.2005] International Telecommunications Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, September 2005.
[ITU.T30.2005]国際電気通信連合、「一般交換電話網における文書ファクシミリ伝送の手順」、ITU-T勧告T.30、2005年9月。
[ITU.T38.2010] International Telecommunications Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, September 2010.
[ITU.T38.2010]国際電気通信連合、「IPネットワークを介したリアルタイムグループ3ファクシミリ通信の手順」、ITU-T勧告T.38、2010年9月。
[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月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。、およびG. Camarillo、「セッション記述プロトコル（SDP）におけるTCPベースのメディア転送」、RFC 4145、2005年9月。
[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月。
[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月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox、J。、「Session Description Protocol（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年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月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479] Wing、D.、Fries、S.、Tschofenig、H。、およびF. Audet、「要件とメディアセキュリティ管理プロトコルの分析」、RFC 5479、2009年4月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939] Andreasen、F。、「Session Description Protocol（SDP）Capability Negotiation」、RFC 5939、2010年9月。
Prior to establishing the session, both Alice and Bob generate self-signed certificates that are used for a single session or, more likely, reused for multiple sessions.
セッションを確立する前に、アリスとボブの両方が、単一のセッションで使用される、または多くの場合、複数のセッションで再利用される自己署名証明書を生成します。
The SIP signaling from Alice to her proxy is transported over TLS to ensure an integrity-protected channel between Alice and her identity service. Alice's identity service asserts identity of Alice and protects the SIP message, e.g., using SIP Identity. Transport between proxies should also be protected, e.g., by use of TLS.
Aliceから彼女のプロキシへのSIPシグナリングは、TLSを介して転送され、Aliceと彼女のアイデンティティサービス間の完全性保護されたチャネルを保証します。アリスのアイデンティティサービスは、アリスのアイデンティティをアサートし、たとえばSIPアイデンティティを使用してSIPメッセージを保護します。プロキシ間の転送も、たとえばTLSを使用して保護する必要があります。
In order to simplify the flow, only one element is shown for Alice's and Bob's proxies.
フローを簡略化するために、アリスとボブのプロキシには1つの要素のみが表示されています。
For the sake of brevity and simplicity, only the mandatory SDP T.38 attributes are shown.
簡潔さと簡潔さのために、必須のSDP T.38属性のみが示されています。
Figure 3 shows an example message flow of session establishment for T.38 fax securely transported using UDPTL over DTLS.
図3は、UDPTL over DTLSを使用して安全に転送されたT.38 FAXのセッション確立のメッセージフローの例を示しています。
In this example flow, Alice acts as the passive endpoint of the DTLS association, and Bob acts as the active endpoint of the DTLS association.
このフロー例では、アリスがDTLSアソシエーションのパッシブエンドポイントとして機能し、ボブがDTLSアソシエーションのアクティブエンドポイントとして機能します。
Alice Proxies Bob
| (1) SIP INVITE | |
|----------------------->| |
| | (2) SIP INVITE |
| |----------------------->|
| | (3) DTLS ClientHello |
|<------------------------------------------------|
| (4) remaining messages of DTLS handshake |
|<----------------------------------------------->|
| | |
| | |
| | (5) SIP 200 OK |
| |<-----------------------|
| (6) SIP 200 OK | |
|<-----------------------| |
| (7) SIP ACK | |
|------------------------------------------------>|
| (8) T.38 message using UDPTL over DTLS |
|<----------------------------------------------->|
| | |
Figure 3: Basic Message Flow
図3：基本的なメッセージフロー
Message (1):
メッセージ（1）：
Figure 4 shows the initial INVITE request sent by Alice to Alice's proxy. The initial INVITE request contains an SDP offer.
図4は、アリスがアリスのプロキシに送信した最初のINVITEリクエストを示しています。最初のINVITE要求にはSDPオファーが含まれています。
The "m=" line in the SDP offer indicates T.38 fax using UDPTL over DTLS.
SDPオファーの「m =」行は、UDPTL over DTLSを使用するT.38ファックスを示しています。
The SDP "setup" attribute with a value of "actpass" in the SDP offer indicates that Alice has requested to be either the active or passive endpoint.
SDPオファーの値が「actpass」のSDP「セットアップ」属性は、アリスがアクティブまたはパッシブエンドポイントのいずれかになることを要求したことを示します。
The SDP "fingerprint" attribute in the SDP offer contains the certificate fingerprint computed from Alice's self-signed certificate.
SDPオファーのSDP "fingerprint"属性には、Aliceの自己署名証明書から計算された証明書のフィンガープリントが含まれています。
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=image 6056 UDP/TLS/UDPTL t38
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=T38FaxRateManagement:transferredTCF
Figure 4: Message (1)
図4：メッセージ（1）
Message (2):
メッセージ（2）：
Figure 5 shows the SIP INVITE request sent by Bob's proxy to Bob.
図5は、ボブのプロキシからボブに送信されたSIP INVITE要求を示しています。
When received, Bob verifies the identity provided in the SIP INVITE request.
受信すると、BobはSIP INVITE要求で提供されたIDを確認します。
INVITE sip:bob@ua2.example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=image 6056 UDP/TLS/UDPTL t38
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=T38FaxRateManagement:transferredTCF
Figure 5: Message (2)
図5：メッセージ（2）
Message (3):
メッセージ（3）：
Assuming that Alice's identity is valid, Bob sends a DTLS ClientHello directly to Alice.
アリスのIDが有効であると想定すると、ボブはDTLS ClientHelloを直接アリスに送信します。
Message (4):
メッセージ（4）：
Alice and Bob exchange further messages of DTLS handshake (HelloVerifyRequest, ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone, Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished).
アリスとボブは、DTLSハンドシェイク（HelloVerifyRequest、ClientHello、ServerHello、Certificate、ServerKeyExchange、CertificateRequest、ServerHelloDone、Certificate、ClientKeyExchange、CertificateVerify、ChangeCipherSpec、およびFinished）のメッセージをさらに交換します。
When Bob receives the certificate of Alice via DTLS, Bob checks whether the certificate fingerprint calculated from Alice's certificate received via DTLS matches the certificate fingerprint received in the a=fingerprint SDP attribute of Figure 5. In this message flow, the check is successful; thus, session setup continues.
ボブはDTLS経由でアリスの証明書を受信すると、DTLS経由で受信したアリスの証明書から計算された証明書フィンガープリントが、図5のa = fingerprint SDP属性で受信した証明書フィンガープリントと一致するかどうかをチェックします。このメッセージフローでは、チェックは成功しています。したがって、セッションのセットアップが続行されます。
Note that, unlike in this example, it is not necessary to wait for the DTLS handshake to finish before the SDP answer is sent. If Bob has sent the SIP 200 (OK) response and later detects that the certificate fingerprints do not match, he will terminate the session.
この例とは異なり、SDP応答が送信される前にDTLSハンドシェイクが完了するのを待つ必要はないことに注意してください。ボブがSIP 200（OK）応答を送信し、後で証明書のフィンガープリントが一致しないことを検出した場合、ボブはセッションを終了します。
Message (5):
メッセージ（5）：
Figure 6 shows a SIP 200 (OK) response to the initial SIP INVITE request, sent by Bob to Bob's proxy. The SIP 200 (OK) response contains an SDP answer.
図6は、ボブからボブのプロキシに送信された最初のSIP INVITE要求に対するSIP 200（OK）応答を示しています。 SIP 200（OK）応答には、SDP応答が含まれています。
The "m=" line in the SDP answer indicates T.38 fax using UDPTL over DTLS.
SDP回答の「m =」行は、UDPTL over DTLSを使用するT.38 FAXを示しています。
The SDP "setup" attribute with a value of "active" in the SDP answer indicates that Bob has requested to be the active endpoint.
SDP回答の「アクティブ」の値を持つSDP「セットアップ」属性は、ボブがアクティブなエンドポイントになることを要求したことを示しています。
The SDP "fingerprint" attribute in the SDP answer contains the certificate fingerprint computed from Bob's self-signed certificate.
SDP回答のSDP "fingerprint"属性には、Bobの自己署名証明書から計算された証明書のフィンガープリントが含まれています。
SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 8965454521 2105372818 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=image 12000 UDP/TLS/UDPTL t38
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=T38FaxRateManagement:transferredTCF
Figure 6: Message (5)
図6：メッセージ（5）
Message (6):
メッセージ（6）：
Figure 7 shows a SIP 200 (OK) response to the initial SIP INVITE request, sent by Alice's proxy to Alice. Alice checks if the certificate fingerprint calculated from the Bob's certificate received via DTLS is the same as the certificate fingerprint received in the a=fingerprint SDP attribute of Figure 7. In this message flow, the check is successful; thus, the session setup continues.
図7は、アリスのプロキシからアリスに送信された、最初のSIP INVITE要求に対するSIP 200（OK）応答を示しています。アリスは、DTLSを介して受信したボブの証明書から計算された証明書フィンガープリントが、図7のa = fingerprint SDP属性で受信した証明書フィンガープリントと同じかどうかを確認します。このメッセージフローでは、チェックは成功しています。したがって、セッションのセットアップが続行されます。
SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 8965454521 2105372818 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=image 12000 UDP/TLS/UDPTL t38
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=T38FaxRateManagement:transferredTCF
Figure 7: Message (6)
図7：メッセージ（6）
Message (7):
メッセージ（7）：
Alice sends the SIP ACK request to Bob.
アリスはボブにSIP ACK要求を送信します。
Message (8):
メッセージ（8）：
At this point, Bob and Alice can exchange T.38 fax securely transported using UDPTL over DTLS.
この時点で、ボブとアリスはUDPTLS over DTLSを使用して安全に転送されたT.38 FAXを交換できます。
A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in an Existing Audio-Only Session
A.3. 既存のオーディオのみのセッションでオーディオメディアストリームを置き換えるT.38 FAXのメッセージフロー
Traditionally, most sessions with non-secure transport of T.38 fax, transported using UDPTL, are established by modifying an ongoing audio session into a fax session. Figure 8 shows an example message flow of modifying an existing audio session into a session with T.38 fax securely transported using UDPTL over DTLS.
伝統的に、UDPTLを使用して転送されるT.38 FAXの非セキュア転送を伴うほとんどのセッションは、進行中のオーディオセッションをFAXセッションに変更することによって確立されます。図8は、既存のオーディオセッションを、UDPTL over DTLSを使用して安全に転送されるT.38 FAXを使用するセッションに変更するメッセージフローの例を示しています。
In this example flow, Alice acts as the passive endpoint of the DTLS association, and Bob acts as the active endpoint of the DTLS association.
このフロー例では、アリスがDTLSアソシエーションのパッシブエンドポイントとして機能し、ボブがDTLSアソシエーションのアクティブエンドポイントとして機能します。
Alice Proxies Bob
| | |
| (1) Audio-only session initiation |
|<-----------------------+----------------------->|
| | |
| (2) SIP re-INVITE | |
|------------------------------------------------>|
| | (3) DTLS ClientHello |
|<------------------------------------------------|
| (4) remaining messages of DTLS handshake |
|<----------------------------------------------->|
| | |
| | |
| | (5) SIP 200 OK |
|<------------------------------------------------|
| (6) SIP ACK | |
|------------------------------------------------>|
| (7) T.38 message using UDPTL over DTLS |
|<----------------------------------------------->|
| | |
Figure 8: Message Flow of T.38 Fax Replacing Audio Media Stream in an Existing Audio-Only Session
図8：既存のオーディオのみのセッションでオーディオメディアストリームを置き換えるT.38 FAXのメッセージフロー
Message (1):
メッセージ（1）：
Session establishment of audio-only session. The proxies decide not to record-route.
音声のみのセッションのセッション確立。プロキシはルートを記録しないことを決定します。
Message (2):
メッセージ（2）：
Alice sends SIP re-INVITE request. The SDP offer included in the SIP re-INVITE request is shown in Figure 9.
アリスはSIP re-INVITE要求を送信します。 SIP re-INVITE要求に含まれるSDPオファーを図9に示します。
The first "m=" line in the SDP offer indicates audio media stream being removed. The second "m=" line in the SDP offer indicates T.38 fax using UDPTL over DTLS being added.
SDPオファーの最初の「m =」行は、オーディオメディアストリームが削除されていることを示しています。 SDPオファーの2番目の「m =」行は、UDPTL over DTLSを使用したT.38 FAXが追加されていることを示しています。
The SDP "setup" attribute with a value of "actpass" in the SDP offer indicates that Alice has requested to be either the active or passive endpoint.
SDPオファーの値が「actpass」のSDP「セットアップ」属性は、アリスがアクティブまたはパッシブエンドポイントのいずれかになることを要求したことを示します。
The SDP "fingerprint" attribute in the SDP offer contains the certificate fingerprint computed from Alice's self-signed certificate.
SDPオファーのSDP "fingerprint"属性には、Aliceの自己署名証明書から計算された証明書のフィンガープリントが含まれています。
v=0
o=- 2465353433 3524244442 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=audio 0 UDP/TLS/RTP/SAVP 0
m=image 46056 UDP/TLS/UDPTL t38
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=T38FaxRateManagement:transferredTCF
Figure 9: SDP Offer of Message (2)
図9：メッセージのSDPオファー（2）
Message (3):
メッセージ（3）：
Bob sends a DTLS ClientHello directly to Alice.
ボブはDTLS ClientHelloを直接アリスに送信します。
Message (4):
メッセージ（4）：
Alice and Bob exchange further messages of DTLS handshake (HelloVerifyRequest, ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone, Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished).
アリスとボブは、DTLSハンドシェイク（HelloVerifyRequest、ClientHello、ServerHello、Certificate、ServerKeyExchange、CertificateRequest、ServerHelloDone、Certificate、ClientKeyExchange、CertificateVerify、ChangeCipherSpec、およびFinished）のメッセージをさらに交換します。
When Bob receives the certificate of Alice via DTLS, Bob checks whether the certificate fingerprint calculated from Alice's certificate received via DTLS matches the certificate fingerprint received in the SDP "fingerprint" attribute of Figure 9. In this message flow, the check is successful; thus, session setup continues.
ボブはDTLSを介してアリスの証明書を受信すると、DTLSを介して受信したアリスの証明書から計算された証明書フィンガープリントが、図9のSDP「fingerprint」属性で受信した証明書フィンガープリントと一致するかどうかを確認します。このメッセージフローでは、チェックは成功しています。したがって、セッションのセットアップが続行されます。
Message (5):
メッセージ（5）：
Bob sends a SIP 200 (OK) response to the SIP re-INVITE request. The SIP 200 (OK) response contains an SDP answer shown in Figure 10.
ボブはSIP 200（OK）応答をSIP re-INVITE要求に送信します。 SIP 200（OK）応答には、図10に示すSDP応答が含まれています。
The first "m=" line in the SDP offer indicates audio media stream being removed. The second "m=" line in the SDP answer indicates T.38 fax using UDPTL over DTLS being added.
SDPオファーの最初の「m =」行は、オーディオメディアストリームが削除されていることを示しています。 SDP回答の2番目の「m =」行は、UDPTL over DTLSを使用したT.38 FAXが追加されていることを示しています。
The SDP "setup" attribute with a value of "active" in the SDP answer indicates that Bob has requested to be the active endpoint.
SDP回答の「アクティブ」の値を持つSDP「セットアップ」属性は、ボブがアクティブなエンドポイントになることを要求したことを示しています。
The SDP "fingerprint" attribute in the SDP answer contains the certificate fingerprint computed from Bob's self-signed certificate.
SDP回答のSDP "fingerprint"属性には、Bobの自己署名証明書から計算された証明書のフィンガープリントが含まれています。
v=0
o=- 4423478999 5424222292 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=audio 0 UDP/TLS/RTP/SAVP 0
m=image 32000 UDP/TLS/UDPTL t38
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=T38FaxRateManagement:transferredTCF
Figure 10: SDP Answer of Message (5)
図10：メッセージのSDP応答（5）
Message (6):
メッセージ（6）：
Alice sends the SIP ACK request to Bob.
アリスはボブにSIP ACK要求を送信します。
Message (7):
メッセージ（7）：
At this point, Bob and Alice can exchange T.38 fax securely transported using UDPTL over DTLS.
この時点で、ボブとアリスはUDPTLS over DTLSを使用して安全に転送されたT.38 FAXを交換できます。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com
Ivo Sedlacek Ericsson Sokolovska 79 Praha 18600 Czech Republic
Ivo Sedlacek Ericsson Sokolovska 79 Praha 18600チェコ共和国
EMail: ivo.sedlacek@ericsson.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: gsalguei@cisco.com