[要約] RFC 7362は、リアルタイムコミュニケーションにおけるメディアのためのホストされたNATトラバーサル（HNT）に関するものです。このRFCの目的は、ホストされたNATトラバーサルの仕組みを提供し、リアルタイムコミュニケーションにおけるメディアの接続性を向上させることです。
Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 7362 Jitsi
Category: Informational H. Kaplan
ISSN: 2070-1721 Oracle
D. Wing
Cisco
September 2014
Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication
ラッチング：リアルタイム通信におけるメディア用のホスト型NATトラバーサル（HNT）
Abstract
概要
This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.
このドキュメントでは、ホスト型NATトラバーサル（HNT）を実行するときの、リアルタイムコミュニケーション（RTC）展開（セッションボーダーコントローラー（SBC）とも呼ばれる）での信号仲介の動作について説明します。 HNTは、NATの背後にある他のRTCデバイスが相互に通信できるようにするために、メディアリレーやラッチなどのメカニズムのセットです。
This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.
このドキュメントは非規範的であり、インターネットコミュニティへの参照と製造業者およびユーザーに有益な説明を提供するためにHNTを説明するためにのみ記述されています。
Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.
HNTコンポーネントの1つであるラッチには、ここで説明する多くのセキュリティ問題があります。そのため、ここで説明するすべてのセキュリティ上の考慮事項を考慮して解決しない限り、IETFはインターネット経由のラッチメカニズムの使用を推奨せず、Interactive Connectivity Establishment（ICE）プロトコルなどの他のソリューションを推奨します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7362.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7362で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5
4. Media Behavior and Latching . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Network Address Translators (NATs) are widely used in the Internet by consumers and organizations. Although specific NAT behaviors vary, this document uses the term "NAT" for devices that map any IPv4 or IPv6 address and transport port number to another IPv4 or IPv6 address and transport port number. This includes consumer NATs, firewall/NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc.
ネットワークアドレストランスレータ（NAT）は、消費者や組織によってインターネットで広く使用されています。特定のNAT動作は異なりますが、このドキュメントでは、IPv4またはIPv6アドレスとトランスポートポート番号を別のIPv4またはIPv6アドレスとトランスポートポート番号にマップするデバイスに対して「NAT」という用語を使用します。これには、コンシューマーNAT、ファイアウォール/ NAT、IPv4-IPv6 NAT、キャリアグレードNAT（CGN）[RFC6888]などが含まれます。
The Session Initiation Protocol (SIP) [RFC3261], and others that try to use a more direct path for media than with signaling, are difficult to use across NATs. These protocols use IP addresses and transport port numbers encoded in bodies such as the Session Description Protocol (SDP) [RFC4566] and, in the case of SIP, various header fields. Such addresses and ports are unusable unless all peers in a session are located behind the same NAT.
セッション開始プロトコル（SIP）[RFC3261]、およびシグナリングよりもメディアに直接的なパスを使用しようとする他のプロトコルは、NAT全体で使用することが困難です。これらのプロトコルは、セッション記述プロトコル（SDP）[RFC4566]などの本文にエンコードされたIPアドレスとトランスポートポート番号を使用し、SIPの場合はさまざまなヘッダーフィールドを使用します。このようなアドレスとポートは、セッション内のすべてのピアが同じNATの背後に配置されていない限り使用できません。
Mechanisms such as Session Traversal Utilities for NAT (STUN) [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC5245] did not exist when protocols like SIP began being deployed. Some mechanisms, such as the early versions of STUN [RFC3489], had started appearing, but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing (UNSAF), as described in [RFC3424]. For these and other reasons, Session Border Controllers (SBCs) that were already being used by SIP domains for other SIP and media-related purposes began to use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NATs. These mechanisms are often transparent to endpoints and rely on a dynamic address and port discovery technique called "latching".
NATなどのセッショントラバーサルユーティリティ（STUN）[RFC5389]、NAT周りのリレーを使用したトラバーサル（TURN）[RFC5766]、インタラクティブ接続確立（ICE）[RFC5245]などのメカニズムは、SIPのようなプロトコルの展開が始まったときには存在しませんでした。 STUN [RFC3489]の初期バージョンなど、いくつかのメカニズムが出現し始めましたが、[RFC3424]で説明されているように、信頼性が低く、UNilateral Self-Address Fixing（UNSAF）に典型的な多くの問題がありました。これらの理由やその他の理由により、他のSIPおよびメディア関連の目的でSIPドメインによってすでに使用されていたセッションボーダーコントローラー（SBC）は、NATの背後にあるSIPデバイスがNATを介して通信できるようにする独自のメカニズムを使用し始めました。これらのメカニズムは多くの場合、エンドポイントに対して透過的であり、「ラッチング」と呼ばれる動的アドレスおよびポート検出技術に依存しています。
The term often used for this behavior is "Hosted NAT Traversal (HNT)"; a number of manufacturers sometimes use other names such as "Far-end NAT Traversal" or "NAT assist" instead. The systems that perform HNT are frequently SBCs as described in [RFC5853], although other systems such as media gateways and "media proxies" sometimes perform the same role. For the purposes of this document, all such systems are referred to as SBCs and the NAT traversal behavior is called HNT.
この動作でよく使用される用語は「ホスト型NATトラバーサル（HNT）」です。多くのメーカーは、代わりに「遠端NATトラバーサル」や「NATアシスト」などの他の名前を使用することがあります。 HNTを実行するシステムは、[RFC5853]で説明されているように、多くの場合SBCですが、メディアゲートウェイや「メディアプロキシ」などの他のシステムが同じ役割を実行することもあります。このドキュメントでは、このようなシステムをすべてSBCと呼び、NATトラバーサル動作をHNTと呼びます。
At the time of this document's publication, a vast majority of SIP domains use HNT to enable SIP devices to communicate across NATs despite the publication of ICE. There are many reasons for this, but those reasons are not relevant to this document's purpose and will not be discussed. It is, however, worth pointing out that the current deployment levels of HNT and NATs make the complete extinction of this practice highly unlikely in the foreseeable future.
このドキュメントの公開時点では、SIPドメインの大部分はHNTを使用して、ICEの公開にもかかわらずSIPデバイスがNAT間で通信できるようにしています。これには多くの理由がありますが、それらの理由はこのドキュメントの目的には関係がないため、説明しません。ただし、HNTとNATの現在の展開レベルによって、このプラクティスが完全に消滅する可能性は、近い将来にはほとんどないことを指摘しておく必要があります。
The purpose of this document is to describe the mechanisms often used for HNT at the SDP and media layer in order to aid understanding the implications and limitations imposed by it. Although the mechanisms used in HNT are well known in the community, publication in an IETF document is useful as a means of providing common terminology and a reference for related documents.
このドキュメントの目的は、SNTおよびメディア層でHNTによく使用されるメカニズムについて説明し、HNTによって課される影響と制限を理解するのに役立ちます。 HNTで使用されるメカニズムはコミュニティでよく知られていますが、IETFドキュメントでの公開は、一般的な用語と関連ドキュメントのリファレンスを提供する手段として役立ちます。
This document does not attempt to make a case for HNT or present it as a solution that is somehow better than alternatives such as ICE. Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet unless all security considerations are taken into account and solved. The IETF is instead advising for the use of the Interactive Connectivity Establishment (ICE) [RFC5245] and Traversal Using Relays around NAT (TURN) [RFC5766] protocols.
このドキュメントでは、HNTの事例を作成したり、ICEなどの代替策よりも優れたソリューションとして提示したりすることは試みていません。セクション5で示したセキュリティの問題のため、すべてのセキュリティ上の考慮事項を考慮して解決しない限り、ラッチングメカニズムはインターネットでの一般的な使用には不適切と見なされます。代わりに、IETFはInteractive Connectivity Establishment（ICE）[RFC5245]およびNATを介したリレーを使用したトラバーサル（TURN）[RFC5766]プロトコルの使用を推奨しています。
It is also worth mentioning that there are purely signaling-layer components of HNT as well. One such component is briefly described for SIP in [RFC5853], but that is not the focus of this document.
また、HNTには純粋にシグナリング層のコンポーネントがあることにも言及する価値があります。そのようなコンポーネントの1つは[RFC5853]でSIPについて簡単に説明されていますが、それはこのドキュメントの焦点ではありません。
SIP uses numerous expressive primitives for message routing. As a result, the HNT component for SIP is typically more implementation-specific and deployment-specific than the SDP and media components. For the purposes of this document it is hence assumed that signaling intermediaries handle traffic in a way that allows protocols such as SIP to function correctly across the NATs.
SIPはメッセージルーティングに多数の表現力豊かなプリミティブを使用します。その結果、SIPのHNTコンポーネントは通常、SDPおよびメディアコンポーネントよりも実装固有および配置固有です。したがって、このドキュメントの目的上、シグナリング仲介者は、SIPなどのプロトコルがNAT全体で正しく機能できるようにトラフィックを処理すると想定されています。
The rest of this document focuses primarily on the use of HNT for SIP. However, the mechanisms described here are relatively generic and are often used with other protocols such as the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], Megaco/H.248 [RFC5125], and H.323 [H.323].
このドキュメントの残りの部分では、主にSIPでのHNTの使用に焦点を当てています。ただし、ここで説明するメカニズムは比較的一般的で、Extensible Messaging and Presence Protocol（XMPP）[RFC6120]、Media Gateway Control Protocol（MGCP）[RFC3435]、Megaco / H.248 [RFC5125]などの他のプロトコルでよく使用されます、およびH.323 [H.323]。
The general problems with NAT traversal for protocols such as SIP are:
SIPなどのプロトコルのNATトラバーサルに関する一般的な問題は次のとおりです。
1. The addresses and port numbers encoded in SDP bodies (or their equivalents) by NATed User Agents (UAs) are not usable across the Internet because they represent the private network addressing information of the UA rather than the addresses/ports that will be mapped to/from by the NAT.
1. NATされたユーザーエージェント（UA）によってSDP本体（またはそれに相当するもの）でエンコードされたアドレスとポート番号は、マッピングされるアドレス/ポートではなく、UAのプライベートネットワークアドレス情報を表すため、インターネット全体で使用できません。 NATによる。
2. The policies inherent in NATs, and explicit in firewalls, are such that packets from outside the NAT cannot reach the UA until the UA sends packets out first.
2. NATに固有のポリシー、およびファイアウォールでは明示的なポリシーは、UAが最初にパケットを送信するまで、NAT外からのパケットがUAに到達できないようにするものです。
3. Some NATs apply endpoint-dependent filtering on incoming packets, as described in [RFC4787]; thus, a UA may only be able to receive packets from the same remote peer IP:port as it sends packets out to.
3. [RFC4787]で説明されているように、一部のNATは着信パケットにエンドポイント依存のフィルタリングを適用します。したがって、UAは、パケットを送信するときと同じリモートピアIP：ポートからのみパケットを受信できる場合があります。
In order to overcome these issues, signaling intermediaries such as SIP SBCs on the public side of the NATs perform HNT for both signaling and media. An example deployment model of HNT and SBCs is shown in Figure 1.
これらの問題を克服するために、NATのパブリック側のSIP SBCなどのシグナリング仲介者は、シグナリングとメディアの両方に対してHNTを実行します。 HNTとSBCの配置モデルの例を図1に示します。
+-----+ +-----+
| SBC |-------| SBC |
+-----+ +-----+
/ \
/ Public Net \
/ \
+-----+ +-----+
|NAT-A| |NAT-B|
+-----+ +-----+
/ \
/ Private Net Private Net \
/ \
+------+ +------+
| UA-A | | UA-B |
+------+ +------+
Figure 1: Signaling and Media Flows in a Common Deployment Scenario
図1：一般的な展開シナリオでのシグナリングとメディアフロー
Along with codec and other media-layer information, session establishment signaling also conveys potentially private and non-globally routable addressing information. Signaling intermediaries would hence modify such information so that peer UAs are given the (public) addressing information of a media relay controlled by the intermediary.
コーデックやその他のメディア層情報に加えて、セッション確立シグナリングは、潜在的にプライベートであり、グローバルにルーティングできないアドレッシング情報も伝えます。したがって、シグナリング仲介者はそのような情報を変更して、ピアUAが仲介者によって制御されるメディアリレーの（パブリック）アドレッシング情報を与えられるようにします。
In typical deployments, the media relay and signaling intermediary (i.e., the SBC) are co-located, thereby sharing the same IP address. Also, the address of the media relay would typically belong to the same IP address family as the one used for signaling (as it is known to work for that UA). In other words, signaling and media would both travel over either IPv4 or IPv6.
典型的な展開では、メディアリレーとシグナリング中間（つまり、SBC）が同じ場所に配置され、同じIPアドレスを共有します。また、メディアリレーのアドレスは、通常、シグナリングに使用されるものと同じIPアドレスファミリに属します（そのUAで機能することが知られているため）。つまり、シグナリングとメディアの両方がIPv4またはIPv6のいずれかを介して伝送されます。
The port numbers introduced in the signaling by the intermediary are typically allocated dynamically. Allocation strategies are entirely implementation dependent and they often vary from one product to the next.
仲介者によってシグナリングで導入されたポート番号は、通常、動的に割り当てられます。割り当て戦略は完全に実装依存であり、製品ごとに異なる場合がよくあります。
The offer/answer media negotiation model [RFC3264] is such that once an offer is sent, the generator of the offer needs to be prepared to receive media on the advertised address/ports. In practice, such media may or may not be received depending on the implementations participating in a given session, local policies, and the call scenario. For example, if a SIP SDP offer originally came from a UA behind a NAT, the SIP SBC cannot send media to it until an SDP answer is given to the UA and latching (Section 4) occurs. Another example is, when a SIP SBC sends an SDP offer in a SIP INVITE to a residential customer's UA and receives back SDP in a 18x response, the SBC may decide, for policy reasons, not to send media to that customer UA until a SIP 200 response has been received (e.g., to prevent toll fraud).
オファー/アンサーメディアネゴシエーションモデル[RFC3264]は、オファーが送信されると、アドバタイズされたアドレス/ポートでメディアを受信できるようにオファーのジェネレーターを準備する必要があるモデルです。実際には、そのようなメディアは、特定のセッションに参加している実装、ローカルポリシー、およびコールシナリオに応じて受信される場合と受信されない場合があります。たとえば、SIP SDPオファーが元々NATの背後にあるUAから来た場合、SIP SBCは、UAにSDP応答が与えられ、ラッチング（セクション4）が発生するまで、メディアを送信できません。別の例として、SIP SBCがSIP INVITEでSDPオファーを住宅顧客のUAに送信し、18x応答でSDPを受信すると、SBCはポリシー上の理由から、SIPまでその顧客のUAにメディアを送信しないことを決定する場合があります。 200応答が受信されました（たとえば、不正通話を防止するため）。
An UA that is behind a NAT would stream media from an address and a port number (an address:port tuple) that are only valid in its local network. Once packets cross the NAT, that address:port tuple will be mapped to a public one. The UA, however, is not typically aware of the public mapping and would often advertise the private address:port tuple in signaling. This way, while a session is still being set up, the signaling intermediary is not yet aware what addresses and ports the caller and the callee would end up using for media traffic: it has only seen them advertise the private addresses they use behind their respective NATs. Therefore, media relays used in HNT would often use a mechanism called "latching".
NATの背後にあるUAは、ローカルネットワークでのみ有効なアドレスとポート番号（address：portタプル）からメディアをストリーミングします。パケットがNATを通過すると、そのaddress：portタプルはパブリックタプルにマッピングされます。ただし、UAは通常、パブリックマッピングを認識せず、シグナリングでプライベートアドレス：ポートタプルをアドバタイズすることがよくあります。このように、セッションがまだセットアップされている間、シグナリング仲介者は、発信者と着信者がメディアトラフィックに使用するアドレスとポートをまだ認識していません。それぞれの背後で使用するプライベートアドレスをアドバタイズするのを見ただけです。 NAT。したがって、HNTで使用されるメディアリレーは、「ラッチング」と呼ばれるメカニズムを使用することがよくあります。
Historically, "latching" only referred to the process by which SBCs "latch" onto UDP packets from a given UA for security purposes, and "symmetric-latching" is when the latched address:port tuples are used to send media back to the UA. Today, most people talk about them both as "latching"; thus, this document does as well.
歴史的に、「ラッチング」とは、セキュリティ上の理由から、SBCが特定のUAからのUDPパケットに「ラッチ」するプロセスのみを指し、「対称ラッチング」は、ラッチされたアドレス：ポートタプルを使用してメディアをUAに送り返すときに使用されます。 。今日、ほとんどの人がそれらの両方を「ラッチング」として話します。したがって、このドキュメントも同様です。
The latching mechanism works as follows:
ラッチメカニズムは次のように機能します。
1. After receiving an offer from Alice (User Agent Client (UAC) located behind a NAT), a signaling intermediary located on the public Internet would allocate a set of IP address:port tuples on a media relay. The set would then be advertised to Bob (User Agent Server (UAS)) so that he would use those media relay address:port tuples for all media he wished to send toward Alice (UAC).
1. アリス（NATの背後にあるユーザーエージェントクライアント（UAC））からオファーを受け取った後、パブリックインターネット上にあるシグナリング仲介者は、メディアリレー上にIPアドレス：ポートタプルのセットを割り当てます。次に、セットはボブ（ユーザーエージェントサーバー（UAS））にアドバタイズされ、アリス（UAC）に送信したいすべてのメディアにこれらのメディアリレーアドレス：ポートタプルを使用します。
2. Next, after receiving from Bob (UAS) an answer to its offer, the signaling server would allocate a second address:port set on the media relay. In its answer to Alice (UAC), the SBC will replace Bob's address:port with this second set. This way, Alice will send media to this media relay address:port.
2. 次に、ボブ（UAS）からのオファーに対する回答を受け取った後、シグナリングサーバーは、メディアリレーに設定された2番目のアドレス：ポートを割り当てます。アリス（UAC）に対する回答では、SBCはボブのアドレス：ポートをこの2番目のセットに置き換えます。このようにして、アリスはこのメディアリレーアドレス：ポートにメディアを送信します。
3. The media relay receives the media packets on the allocated ports and uses their respective source address:ports as a destination for all media bound in the opposite direction. In other words, it "latches" or locks on these source address:port tuples.
3. メディアリレーは、割り当てられたポートでメディアパケットを受信し、それぞれの送信元アドレス：ポートを、反対方向にバインドされたすべてのメディアの宛先として使用します。つまり、これらの送信元アドレス：ポートタプルを「ラッチ」またはロックします。
4. This way, when Alice (UAC) streams media toward the media relay, it would be received on the second address:port tuple. The source address:port of her traffic would belong to the public interface of Alice's NAT, and anything that the relay sends back to that address:port would find its way to Alice.
4. このように、Alice（UAC）がメディアリレーに向けてメディアをストリーミングする場合、2番目のaddress：portタプルで受信されます。彼女のトラフィックのソースアドレス：ポートは、アリスのNATのパブリックインターフェイスに属し、リレーがそのアドレス：ポートに送り返すものはすべて、アリスへの経路を見つけます。
5. Similarly, the source of the media packets that Bob (UAS) is sending would be latched upon and used for media going in that direction.
5. 同様に、ボブ（UAS）が送信しているメディアパケットのソースがラッチされ、その方向に進むメディアに使用されます。
6. Latching is usually done only once per peer and not allowed to change or cause a re-latching until a new offer and answer get exchanged (e.g., in a subsequent call or after a SIP peer has gone on and off hold). The reasons for such restrictions are mostly related to security: once a session has started, a user agent is not expected to suddenly start streaming from a different port without sending a new offer first. A change may indicate an attempt to hijack the session. In some cases, however, a port change may be caused by a re-mapping in a NAT device standing between the SBC and the UA. More advanced SBCs may therefore allow some level of flexibility on the re-latching restrictions while carefully considering the potential security implications of doing so.
6. ラッチングは通常、ピアごとに1回だけ行われ、新しいオファーとアンサーが交換されるまで（たとえば、後続のコールで、またはSIPピアがオン/オフ状態になった後）変更または再ラッチを引き起こすことはできません。このような制限の理由は、主にセキュリティに関連しています。セッションが開始されると、ユーザーエージェントは、最初に新しいオファーを送信せずに別のポートから突然ストリーミングを開始することは想定されていません。変更は、セッションをハイジャックする試みを示している可能性があります。ただし、場合によっては、SBCとUAの間にあるNATデバイスでの再マッピングが原因で、ポートが変更されることがあります。したがって、より高度なSBCは、潜在的なセキュリティへの影響を慎重に考慮しながら、再ラッチ制限にある程度の柔軟性を与えることができます。
Figure 2 describes how latching occurs for SIP where HNT is provided by an SBC connected to two networks: 203.0.113/24 facing towards the UAC network and 198.51.100/24 facing towards the UAS network.
図2は、2つのネットワークに接続されたSBCによってHNTが提供されるSIPのラッチングがどのように発生するかを示しています。UACネットワークに面する203.0.113 / 24とUASネットワークに面する198.51.100 / 24です。
192.0.2.1 192.0.2.9/203.0.113.4 198.51.100.33
Alice NAT 203.0.113.9-SBC-198.51.100.2 Bob
------- --- --- -------
| | | |
1. |--SIP INVITE+offer c=192.0.2.1--->| |
| | | |
2. | | (SBC allocates 198.51.100.2:22007 |
| | for inbound RTP from Bob) |
| | | |
3. | | |-----INVITE+offer----->|
| | | c=198.51.100.2:22007 |
| | | |
4. | | |<------180 Ringing-----|
| | | |
| | | |
5. |<------180 Ringing----------------| |
| | | |
6. | | |<------200+answer------|
| | | |
7. | | (SBC allocates 203.0.113.9:36010 |
| | for inbound RTP from Alice) |
| | | |
8. |<-200+answer,c=203.0.113.9:36010--| c=198.51.100.33 |
| | | |
9. |------------ACK------------------>| |
10. | | |----------ACK--------->|
| | | |
11. |=====RTP,dest=203.0.113.9:36010==>| |
| | | |
12. | | (SBC latches to |
| | source IP address and |
| | port seen at (11)) |
| | | |
13. | | |<======= RTP ==========|
| | |dest:198.51.100.2:22007|
14. |<=====RTP, to latched address=====| |
| | | |
Figure 2: Latching by a SIP SBC across Two Interfaces
図2：2つのインターフェイス間でのSIP SBCによるラッチ
While XMPP implementations often rely on ICE to handle NAT traversal, there are some that also support a non-ICE transport called XMPP Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how latching occurs for one such XMPP implementation where HNT is provided by an XMPP server on the public Internet.
XMPP実装はしばしばNATトラバーサルを処理するためにICEに依存しますが、XMPPジングルRaw UDPトランスポートメソッド[XEP-0177]と呼ばれるICE以外のトランスポートをサポートするものもあります。図3は、HNTがパブリックインターネット上のXMPPサーバーによって提供される、このようなXMPP実装のラッチングがどのように発生するかを示しています。
192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
Romeo NAT XMPP Server Juliet
----- --- --- -----
| | | |
1. |----session-initiate cand=192.0.2.1--->| |
| | | |
2. |<------------ack-----------------------| |
| | | |
3. | | (Server allocates 203.0.113.9:2200 |
| | for inbound RTP from Juliet) |
| | | |
4. | | |--session-initiate-->|
| | |cand=203.0.113.9:2200|
| | | |
5. | | |<--------ack---------|
| | | |
| | | |
6. | | |<---session-accept---|
| | | cand=198.51.100.8 |
| | | |
7. | | |---------ack-------->|
| | | |
8. | | (Server allocates 203.0.113.9:3300 |
| | for inbound RTP from Romeo) |
| | | |
9. |<-session-accept cand=203.0.113.9:3300-| |
| | | |
10. |-----------------ack------------------>| |
| | | |
| | | |
11. |======RTP, dest=203.0.113.9:3300======>| |
| | | |
12. | | (XMPP server latches to |
| | src IP 203.0.113.4 and |
| | src port seen at (11)) |
| | | |
13. | | |<======= RTP ========|
| | |dest=203.0.113.9:2200|
14. |<======RTP, to latched address=========| |
| | | |
Figure 3: Latching by an XMPP Server across Two Interfaces
図3：2つのインターフェイス間のXMPPサーバーによるラッチ
The above is a general description, and some details vary between implementations or configuration settings. For example, some intermediaries perform additional logic before latching on received packet source information to prevent malicious attacks or latching erroneously to previous media senders -- often called "rogue-rtp" in the industry.
上記は一般的な説明であり、一部の詳細は実装または構成設定によって異なります。たとえば、一部の仲介者は、悪意のある攻撃や以前のメディア送信者への誤ったラッチ（業界では「ローグRTP」と呼ばれることが多い）を防ぐために、受信したパケットソース情報をラッチする前に追加のロジックを実行します。
It is worth pointing out that latching is not exclusively a "server affair", and some clients may also use it in cases where they are configured with a public IP address and are contacted by a NATed client with no other NAT traversal means.
ラッチングは「サーバーアフェア」に限定されないことに注意する必要があります。一部のクライアントは、パブリックIPアドレスで構成され、他のNATトラバーサル手段を使用せずにNATされたクライアントからアクセスされる場合にも使用できます。
In order for latching to function correctly, the UA behind the NAT needs to support symmetric RTP. That is, it needs to use the same ports for sending data as the ones it listens on for inbound packets. Today, this is the case with almost all SIP and XMPP clients. Also, UAs need to make sure they can begin sending media packets independently without waiting for packets to arrive first. In theory, it is possible that some UAs would not send packets out first, for example, if a SIP session begins in 'inactive' or 'recvonly' SDP mode from the UA behind the NAT. In practice, however, SIP sessions from regular UAs (the kind that one could find behind a NAT) virtually never begin in 'inactive' or 'recvonly' mode, for obvious reasons. The media direction would also be problematic if the SBC side indicated 'inactive' or 'sendonly' modes when it sent SDP to the UA. However, SBCs providing HNT would always be configured to avoid this.
ラッチングが正しく機能するためには、NATの背後にあるUAが対称RTPをサポートする必要があります。つまり、データの送信には、受信パケットをリッスンするポートと同じポートを使用する必要があります。今日、これはほとんどすべてのSIPおよびXMPPクライアントに当てはまります。また、UAは、パケットが最初に到着するのを待たずに、独立してメディアパケットの送信を開始できることを確認する必要があります。理論的には、NATの背後にあるUAからSIPセッションが「非アクティブ」または「recvonly」SDPモードで開始された場合など、一部のUAが最初にパケットを送信しない可能性があります。ただし、実際には、通常のUA（NATの背後にあるようなもの）からのSIPセッションは、明らかな理由により、「非アクティブ」モードまたは「recvonly」モードでは事実上開始されません。 SDPをUAに送信したときにSBC側が「非アクティブ」または「送信専用」モードを示した場合、メディアの方向性も問題になります。ただし、HNTを提供するSBCは常にこれを回避するように構成されます。
Given that, in order for latching to work properly, media relays need to begin receiving media before they start sending, it is possible for deadlocks to occur. This can happen when the UAC and the UAS in a session are connected to different signaling intermediaries that both provide HNT. In this case, the media relays controlled by the signaling servers could end up each waiting upon the other to initiate the streaming. To prevent this, relays would often attempt to start streaming toward the address:port tuples provided in the offer/answer even before receiving any inbound traffic. If the entity they are streaming to is another HNT performing server, it would have provided its relay's public address and ports, and the early stream would find its target.
ラッチが適切に機能するためには、メディアリレーが送信を開始する前にメディアの受信を開始する必要があるため、デッドロックが発生する可能性があります。これは、セッション内のUACとUASが、両方がHNTを提供する異なるシグナリング仲介者に接続されている場合に発生する可能性があります。この場合、シグナリングサーバーによって制御されるメディアリレーは、ストリーミングを開始するために他のサーバーを待機することになります。これを防ぐために、リレーはインバウンドトラフィックを受信する前であっても、オファー/アンサーで提供されたaddress：portタプルに向けてストリーミングを開始しようとすることがよくあります。ストリーミング先のエンティティが別のHNT実行サーバーである場合、リレーのパブリックアドレスとポートが提供され、初期のストリームがそのターゲットを見つけます。
Although many SBCs only support UDP-based media latching (in particular, RTP/RTCP), many SBCs support TCP-based media latching as well. TCP-based latching is more complicated; it involves forcing the UA behind the NAT to be the TCP client and sending the initial SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of a TCP-based media session). If both UAs of a TCP-based media session are behind NATs, then SBCs typically force both UAs to be the TCP clients, and the SBC splices the TCP connections together. TCP splicing is a well-known technique, as described in [TCP-SPLICING].
多くのSBCはUDPベースのメディアラッチ（特に、RTP / RTCP）のみをサポートしていますが、多くのSBCはTCPベースのメディアラッチもサポートしています。 TCPベースのラッチはより複雑です。これには、NATの背後にあるUAを強制的にTCPクライアントにして、最初のSYNフラグの付いたTCPパケットをSBCに送信する（つまり、TCPベースのメディアセッションの「アクティブ」モード側にする）必要があります。 TCPベースのメディアセッションの両方のUAがNATの背後にある場合、SBCは通常、両方のUAを強制的にTCPクライアントにし、SBCはTCP接続を一緒にスプライスします。 [TCP-SPLICING]で説明されているように、TCPスプライシングはよく知られた手法です。
HNT and latching, in particular, are generally found to work reliably, but they do have obvious caveats. The first one usually raised by IETF participants is that UAs are not aware of it occurring. This makes it impossible for the mechanism to be used with protocols such as ICE that try various traversal techniques in an effort to choose the one that best suits a particular situation. Overwriting address information in offers and answers may actually completely prevent UAs from using ICE because of the ice-mismatch rules described in [RFC5245].
特に、HNTとラッチは一般に信頼性の高い動作をすることがわかっていますが、明らかな警告があります。 IETFの参加者が通常提起する最初の問題は、UAがその発生を認識していないことです。これにより、特定の状況に最も適したものを選択するために、さまざまなトラバーサル手法を試行するICEなどのプロトコルでこのメカニズムを使用することができなくなります。 [RFC5245]で説明されている氷の不一致ルールにより、オファーとアンサーのアドレス情報を上書きすると、UAがICEを完全に使用できなくなる可能性があります。
The second issue raised by IETF participants is that it causes media to go through a relay instead of directly over the IP-routed path between the two participating UAs. While this adds obvious drawbacks such as reduced scalability and increased latency, it is also considered a benefit by SBC administrators: if a customer pays for "phone" service, for example, the media is what is truly being paid for, and the administrators usually like to be able to detect that the media is flowing correctly, evaluate its quality, know if and why it failed, etc. Also, in some cases, routing media through operator controlled relays may route media over paths explicitly optimized for media and hence offer better performance than regular Internet routing.
IETF参加者が提起した2番目の問題は、メディアが、2つの参加しているUA間のIPルーティングパスを直接経由するのではなく、リレーを通過することです。これにより、スケーラビリティの低下やレイテンシの増加などの明らかな欠点が追加されますが、SBC管理者にとっても利点と見なされます。たとえば、顧客が「電話」サービスの料金を支払う場合、メディアは実際に支払われるものであり、管理者は通常、メディアが正しく流れていることを検出し、その品質を評価し、失敗したかどうかとその理由を知ることができます。また、場合によっては、オペレーター制御のリレーを介してメディアをルーティングすると、メディア用に明示的に最適化されたパスを介してメディアがルーティングされるため、通常のインターネットルーティングよりも優れたパフォーマンス。
A common concern is that an SBC (or an XMPP server -- all security considerations apply to both) that implements HNT may latch to incorrect and possibly malicious sources. The ICE [RFC5245] protocol, for example, provides authentication tokens (conveyed in the ice-ufrag and ice-pwd attributes) that allow the identity of a peer to be confirmed before engaging in media exchange with her. Without such authentication, a malicious source could attempt a resource exhaustion attack by flooding all possible media-latching UDP ports on the SBC in order to prevent calls from succeeding. SBCs have various mechanisms to prevent this from happening or to alert an administrator when it does. Still, a sufficiently sophisticated attacker may be able to bypass them for some time. The most common example is typically referred to as "restricted-latching", whereby the SBC will not latch to any packets from a source public IP address other than the one the SIP UA uses for SIP signaling. This way, the SBC simply ignores and does not latch onto packets coming from the attacker. In some cases, the limitation may be loosened to allow media from a range of IP addresses belonging to the same network in order to allow for use cases such as decomposed UAs and various forms of third-party call control. However, since relaxing the restrictions in such a way may provide attackers with a larger attack surface, such configurations are generally performed only on a case-by-case basis so that the specifics of individual deployments can be taken into account.
一般的な懸念は、HNTを実装するSBC（またはXMPPサーバー-すべてのセキュリティの考慮事項が両方に適用されます）が誤った、場合によっては悪意のあるソースにラッチされる可能性があることです。たとえば、ICE [RFC5245]プロトコルは、ピアとのメディア交換を行う前にピアのIDを確認できる認証トークン（ice-ufragおよびice-pwd属性で伝達される）を提供します。このような認証がない場合、悪意のあるソースは、SBC上のすべてのメディアラッチUDPポートをフラッディングして、リソースの枯渇攻撃を試み、コールが成功しないようにする可能性があります。 SBCには、これが発生しないようにするため、または発生したときに管理者に警告するためのさまざまなメカニズムがあります。それでも、十分に高度な攻撃者は、しばらくの間それらを迂回できる可能性があります。最も一般的な例は、通常「制限付きラッチ」と呼ばれ、SBCは、SIP UAがSIPシグナリングに使用するアドレス以外の送信元パブリックIPアドレスからのパケットにラッチしません。このように、SBCは単に無視し、攻撃者からのパケットをラッチしません。場合によっては、分解されたUAやさまざまな形式のサードパーティコール制御などの使用例に対応するために、制限が緩和され、同じネットワークに属するIPアドレスの範囲のメディアを許可することができます。ただし、このような方法で制限を緩和すると、攻撃者に大きな攻撃対象領域が提供される可能性があるため、通常、このような構成はケースバイケースでのみ実行され、個々の展開の詳細を考慮することができます。
All of the above problems would still arise if the attacker knows the public source IP of the UA that is actually making the call. This would allow attackers to still flood all of the SBC's public IP addresses and ports with packets spoofing that SIP UA's public source IP address. However, this would only impact media from that IP (or range of IP addresses) rather than all calls that the SBC is servicing.
上記の問題はすべて、攻撃者が実際に呼び出しを行っているUAのパブリックソースIPを知っている場合にも発生します。これにより、攻撃者は、SBCのすべてのパブリックIPアドレスとポートに、そのSIP UAのパブリックソースIPアドレスをスプーフィングするパケットをフラッディングする可能性があります。ただし、これは、SBCが処理しているすべてのコールではなく、そのIP（またはIPアドレスの範囲）からのメディアにのみ影響します。
A malicious source could send media packets to an SBC media-latching UDP port in the hopes of being latched to for the purpose of receiving media for a given SIP session. SBCs have various mechanisms to prevent this as well. Restricted latching, for example, would also help in this case because the attacker can't make the SBC send media packets back to themselves since the SBC will not latch onto the attacker's media packets, not having seen the corresponding signaling packets first. There could still be an issue if the attacker happens to be either (1) in the IP routing path where it can thus spoof the same IP as the real UA and get the media coming back, in which case the attacker hardly needs to attack at all to begin with, or (2) behind the same NAT as the legitimate SIP UA, in which case the attacker's packets will be latched to by the SBC and the SBC will send media back to the attacker. In the latter case, which may be of particular concern with Carrier-Grade NATs, the legitimate SIP UA will likely end the call anyway when a human user who does not hear anything hangs up. In the case of a non-human call participant, such as an answering machine, this may not happen (although many such automated UAs would also hang up when they do not receive any media). The attacker could also redirect all media to the real SIP UA after receiving it, in which case the attack would likely remain undetected and succeed. Again, this would be of particular concern with larger-scale NATs serving many different endpoints, such as Carrier-Grade NATs. The larger the number of devices fronted by a NAT is, the more use cases would vary, and the more the number of possible attack vectors would grow.
悪意のあるソースは、特定のSIPセッションのメディアを受信する目的でラッチされることを期待して、メディアパケットをSBCメディアラッチUDPポートに送信する可能性があります。 SBCには、これを防ぐためのさまざまなメカニズムもあります。たとえば、制限されたラッチは、SBCが攻撃者のメディアパケットにラッチしないため、SBCがメディアパケットを自分に送り返すことができないため、対応するシグナリングパケットが最初に見られないため、この場合にも役立ちます。攻撃者が（1）IPルーティングパスのいずれかにいる場合でも問題が発生する可能性があり、実際のUAと同じIPをスプーフィングしてメディアを取り戻すことができます。この場合、攻撃者は攻撃する必要がほとんどありません。まず、（2）正規のSIP UAと同じNATの背後にあります。この場合、攻撃者のパケットはSBCによってラッチされ、SBCはメディアを攻撃者に送り返します。キャリアグレードのNATで特に懸念される可能性がある後者の場合、何も聞こえない人間のユーザーが電話を切ると、正当なSIP UAはとにかく通話を終了します。留守番電話などの人間以外の通話参加者の場合、これは発生しない可能性があります（そのような自動化されたUAの多くは、メディアを受信しないとハングアップします）。攻撃者はまた、すべてのメディアを受信後に実際のSIP UAにリダイレクトする可能性があります。その場合、攻撃は検出されずに成功する可能性があります。繰り返しになりますが、これは、Carrier-Grade NATなどの多くの異なるエンドポイントにサービスを提供する大規模なNATでは特に問題になります。 NATの前にあるデバイスの数が多いほど、変化するユースケースが多くなり、可能な攻撃ベクトルの数が増えます。
Naturally, Secure RTP (SRTP) [RFC3711] would help mitigate such threats and, if used with the appropriate key negotiation mechanisms, would protect the media from monitoring while in transit. It should therefore be used independently of HNT. Section 26 of [RFC3261] provides an overview of additional threats and solutions on monitoring and session interception.
当然、Secure RTP（SRTP）[RFC3711]はそのような脅威を軽減するのに役立ち、適切なキーネゴシエーションメカニズムと共に使用される場合、転送中の監視からメディアを保護します。したがって、HNTとは別に使用する必要があります。 [RFC3261]のセクション26は、監視とセッション傍受に関する追加の脅威とソリューションの概要を提供します。
With SRTP, if the SBC that performs the latching is actually participating in the SRTP key exchange, then it would simply refuse to latch onto a source unless it can authenticate it. Failing to implement and use SRTP would represent a serious threat to users connecting from behind Carrier-Grade NATs [RFC6888] and is considered a harmful practice.
SRTPでは、ラッチを実行するSBCが実際にSRTP鍵交換に参加している場合、認証できる場合を除き、ソースへのラッチを拒否します。 SRTPの実装と使用に失敗すると、Carrier-Grade NAT [RFC6888]の背後から接続しているユーザーにとって深刻な脅威となり、有害な行為と見なされます。
For SIP clients, HNT is usually transparent in the sense that the SIP UA does not know it occurs. In certain cases, it may be detectable, such as when ICE is supported by the SIP UA and the SBC modifies the default connection address and media port numbers in SDP, thereby disabling ICE due to the mismatch condition. Even in that case, however, the SIP UA only knows that a middlebox is relaying media but not necessarily that it is performing latching/HNT.
SIPクライアントの場合、HNTは通常、SIP UAが発生を認識しないという意味で透過的です。 ICEがSIP UAによってサポートされ、SBCがSDPのデフォルトの接続アドレスとメディアポート番号を変更する場合など、特定の状況で検出可能になる場合があります。これにより、不一致状態のためにICEが無効になります。ただし、その場合でも、SIP UAはミドルボックスがメディアをリレーしていることだけを認識していますが、必ずしもラッチング/ HNTを実行しているとは限りません。
In order to perform HNT, the SBC has to modify SDP to and from the SIP UA behind a NAT; thus, the SIP UA cannot use S/MIME [RFC5751], and it cannot sign a sending request, or verify a received request using the SIP Identity mechanism [RFC4474] unless the SBC re-signs the request. However, neither S/MIME nor SIP Identity are widely deployed; thus, not being able to sign/verify requests appears not to be a concern at this time.
HNTを実行するために、SBCはNATの背後にあるSIP UAとの間でSDPを変更する必要があります。したがって、SIP UAはS / MIME [RFC5751]を使用できず、SBCが要求に再署名しない限り、送信要求に署名したり、SIP IDメカニズム[RFC4474]を使用して受信した要求を検証したりできません。ただし、S / MIMEもSIPアイデンティティも広く展開されていません。したがって、現時点ではリクエストに署名/検証できないことは問題ではないようです。
From a privacy perspective, media relaying is sometimes seen as a way of protecting one's IP address and not revealing it to the remote party. That kind of IP address masking is often perceived as important. However, this is no longer an exclusive advantage of HNT since it can also be accomplished by client-controlled relaying mechanisms such as TURN [RFC5766] if the client explicitly wishes to do so.
プライバシーの観点から、メディアリレーは、自分のIPアドレスを保護し、それをリモートパーティに公開しない方法と見なされる場合があります。この種のIPアドレスマスキングは、重要であるとしばしば認識されています。ただし、クライアントが明示的に希望する場合は、TURN [RFC5766]などのクライアント制御のリレーメカニズムによって実現できるため、これはHNTの唯一の利点ではありません。
The authors would like to thank Flemming Andreasen, Miguel A. Garcia, Alissa Cooper, Vijay K. Gurbani, Ari Keranen, and Paul Kyzivat for their reviews and suggestions on improving this document.
このドキュメントを改善するためのレビューと提案を提供してくれたFlemming Andreasen、Miguel A. Garcia、Alissa Cooper、Vijay K. Gurbani、Ari Keranen、およびPaul Kyzivatに感謝します。
[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月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]オーデットF.およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments from Requirements」、RFC 5853、4月2010。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[XEP-0177] Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, "XEP-0177: Jingle Raw UDP Transport Method", XSF XEP 0177, December 2009.
[XEP-0177] Beda、J.、Saint-Andre、P.、Hildebrand、J。、およびS. Egan、「XEP-0177：Jingle Raw UDP Transport Method」、XSF XEP 0177、2009年12月。
[H.323] International Telecommunication Union, "Packet-based multimedia communication systems", ITU-T Recommendation H.323, December 2009.
[H.323]国際電気通信連合、「パケットベースのマルチメディア通信システム」、ITU-T勧告H.323、2009年12月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（MGCP）Version 1.0」、RFC 3435、2003年1月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「STUN-Simple Data Traversal of User Datagram Protocol（UDP）Through Network Address Translators（NATs）」、RFC 3489、2003年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月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]テイラーT。、「RFC 3525の歴史的分類への再分類」、RFC 5125、2008年2月。
[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月。
[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月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P.、J。Rosenberg、「NAT周辺のリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、2010年4月。
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888] Perreault、S。、山形、I。、宮川、S。、中川、A。、およびH. Ashida、「Common Requirements for Carrier-Grade NATs（CGNs）」、BCP 127、RFC 6888、2013年4月。
[TCP-SPLICING] Maltz, D. and P. Bhagwat, "TCP Splice for application layer proxy performance", Journal of High Speed Networks Vol. 8, No. 3, 1999, pp. 225-240, March 1999.
[TCP-SPLICING] Maltz、D。およびP. Bhagwat、「アプリケーション層プロキシパフォーマンスのためのTCPスプライス」、Journal of High Speed Networks Vol。 8、No。3、1999年、pp.225-240、1999年3月。
Authors' Addresses
著者のアドレス
Emil Ivov Jitsi Strasbourg 67000 France
Emil Ivov Jitsiストラスブール67000フランス
EMail: emcho@jitsi.org
Hadriel Kaplan Oracle 100 Crosby Drive Bedford, MA 01730 USA
Hadriel Kaplan Oracle 100 Crosby Drive Bedford、MA 01730 USA
EMail: hadrielk@yahoo.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134 USA
EMail: dwing@cisco.com