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
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.
本文档描述了实时通信（RTC）部署（有时称为会话边界控制器（SBC））中信令中介在执行托管NAT遍历（HNT）时的行为。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的一个组成部分，这里讨论了许多安全问题。因此，除非考虑并解决了此处解释的所有安全问题，否则IETF建议不要在互联网上使用锁存机制，并推荐其他解决方案，如交互式连接建立（ICE）协议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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行为各不相同，但本文档使用术语“NAT”来表示将任何IPv4或IPv6地址和传输端口号映射到另一个IPv4或IPv6地址和传输端口号的设备。这包括消费者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
NAT的会话遍历实用程序（STUN）[RFC5389]、NAT周围使用中继的遍历（TURN）[RFC5766]和交互式连接建立（ICE）[RFC5245]等机制不存在
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".
当像SIP这样的协议开始部署时。一些机制，如STUN的早期版本[RFC3489]已经开始出现，但它们不可靠，并且出现了一些单边自地址修复（UNSAF）的典型问题，如[RFC3424]所述。出于这些和其他原因，会话边界控制器（SBC）已经被SIP域用于其他SIP和媒体相关目的，开始使用专有机制，使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，尽管媒体网关和“媒体代理”等其他系统有时也执行相同的角色。在本文档中，所有此类系统称为SBCs，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使SIP设备能够跨NAT进行通信，尽管发布了ICE。原因很多，但这些原因与本文件的目的无关，将不予讨论。然而，值得指出的是，目前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.
本文件的目的是描述在SDP和媒体层通常用于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建议使用交互式连接建立（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也有纯粹的信令层组件。[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使用许多表达原语进行消息路由。因此，与SDP和媒体组件相比，SIP的HNT组件通常更具体于实现和部署。因此，为了本文档的目的，假设信令中介以允许诸如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].
本文档的其余部分主要关注HNT在SIP中的使用。然而，这里描述的机制是相对通用的，并且通常与其他协议一起使用，例如可扩展消息和存在协议（XMPP）[RFC6120]、媒体网关控制协议（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. 用户代理（UAs）在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。图1显示了HNT和SBCs的示例部署模型。
+-----+ +-----+
| SBC |-------| SBC |
+-----+ +-----+
/ \
/ Public Net \
/ \
+-----+ +-----+
|NAT-A| |NAT-B|
+-----+ +-----+
/ \
/ Private Net Private Net \
/ \
+------+ +------+
| UA-A | | UA-B |
+------+ +------+
+-----+ +-----+
| 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地址族相同的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
报盘/应答媒体协商模型[RFC3264]是这样的，一旦发送报盘，报盘的生成器需要准备好接收广告地址/端口上的媒体。实际上，根据参与给定会话的实现、本地策略和呼叫场景，可以接收也可以不接收此类媒体。例如，如果SIP SDP提供最初来自NAT后面的UA，则SIP SBC无法向其发送媒体，直到向UA给出SDP应答并发生闭锁（第4节）。另一个例子是，当SIP SBC在SIP INVITE中向用户发送SDP要约时
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).
住宅客户的UA并在18x响应中接收回SDP，出于政策原因，SBC可决定在收到SIP 200响应之前不向该客户UA发送媒体（例如，防止收费欺诈）。
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将从仅在其本地网络中有效的地址和端口号（地址：端口元组）流式传输媒体。一旦数据包通过NAT，地址：端口元组将映射到公共元组。然而，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. 在收到来自Alice（位于NAT后面的用户代理客户端（UAC））的报价后，位于公共互联网上的信令中介将在媒体中继上分配一组IP地址：端口元组。然后，该集合将被通告给Bob（用户代理服务器（UAS）），以便他将这些媒体中继地址：端口元组用于他希望发送到Alice（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. 接下来，在从Bob（UAS）收到对其报价的答复后，信令服务器将在媒体中继上分配第二个地址：端口集。在对Alice（UAC）的回答中，SBC将用第二组替换Bob的地址：port。通过这种方式，Alice将媒体发送到此媒体中继地址：端口。
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）将媒体流传输到媒体中继时，它将在第二个地址上接收：端口元组。源地址：她的通信端口将属于Alice的NAT的公共接口，而中继发送回该地址的任何内容：端口都将找到Alice的路径。
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. 类似地，Bob（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. 锁存通常每个对等方只执行一次，并且在交换新的提供和应答之前（例如，在后续呼叫中或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描述了当HNT由连接到两个网络的SBC提供时，SIP如何发生闭锁：203.0.113/24朝向UAC网络，198.51.100/24朝向UAS网络。
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=====| |
| | | |
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: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实现通常依赖ICE来处理NAT遍历，但也有一些支持称为XMPP-Jingle原始UDP传输方法[XEP-0177]的非ICE传输。图3描述了一个这样的XMPP实现是如何发生锁存的，其中HNT由公共Internet上的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=========| |
| | | |
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: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.
数据包源信息，以防止恶意攻击或错误锁定到以前的媒体发送者——在业界通常称为“rogue 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穿越方式的情况下被NAD客户机联系。
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客户端都是这样。此外，UAs需要确保他们可以开始独立发送媒体数据包，而无需等待数据包首先到达。理论上，一些UAs可能不会首先发送数据包，例如，如果SIP会话从NAT后面的UA以“非活动”或“recvonly”SDP模式开始。然而，在实践中，由于显而易见的原因，来自常规UAs（NAT后面可以找到的那种）的SIP会话实际上从未以“非活动”或“recvonly”模式开始。如果SBC侧在向UA发送SDP时指示“非活动”或“仅发送”模式，则媒体方向也会有问题。然而，提供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的不同信令中介时，可能会发生这种情况。在这种情况下，由信令服务器控制的媒体中继器可能会各自等待对方启动流传输。为了防止这种情况发生，中继通常会尝试在接收任何入站流量之前就开始向提供/应答中提供的地址：端口元组进行流式传输。如果他们要流到的实体是另一台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的媒体会话的两个UAs都位于NAT之后，则SBC通常会强制两个UAs成为TCP客户端，并且SBC会将TCP连接拼接在一起。TCP拼接是一种众所周知的技术，如[TCP-splicing]中所述。
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参与者通常提出的第一个问题是UAs没有意识到它的发生。这使得该机制不可能与诸如ICE之类的协议一起使用，ICE尝试各种遍历技术以选择最适合特定情况的遍历技术。由于[RFC5245]中描述的ICE不匹配规则，覆盖报价和应答中的地址信息实际上可能会完全阻止UAs使用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参与者提出的第二个问题是，它导致媒体通过中继，而不是直接通过两个参与UAs之间的IP路由路径。虽然这增加了明显的缺点，如可扩展性降低和延迟增加，但SBC管理员也认为这是一个好处：例如，如果客户为“电话”服务付费，则媒体才是真正付费的对象，管理员通常希望能够检测到媒体是否正常流动，评估其质量，了解其是否出现故障以及故障原因等。此外，在某些情况下，通过操作员控制的中继路由媒体可能会通过为媒体明确优化的路径路由媒体，从而提供比常规Internet路由更好的性能。
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
一个常见的问题是，实现HNT的SBC（或XMPP服务器——所有安全注意事项都适用于两者）可能会锁定到不正确且可能是恶意的源。例如，ICE[RFC5245]协议提供身份验证令牌（在ICE ufrag和ICE pwd属性中传送），允许在与对等方进行媒体交换之前确认对等方的身份。如果没有这种身份验证，恶意源可能会通过淹没SBC上所有可能的媒体锁定UDP端口来尝试资源耗尽攻击，以防止调用成功。SBC有各种机制来防止这种情况发生，或者在发生时提醒管理员。不过，一个足够老练的攻击者可能会绕过它们一段时间。最常见的示例通常被称为“受限锁存”，由此，SBC将不会锁存到来自源公共IP地址（SIP UA用于SIP信令的地址除外）的任何分组。这样，SBC就会忽略来自攻击者的数据包，而不会锁定这些数据包。在某些情况下，可以放宽限制以允许来自属于同一网络的一系列IP地址的媒体，以便允许诸如分解ua和各种形式的第三方呼叫控制之类的用例。但是，由于以这种方式放松限制可能会为攻击者提供更大的攻击
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.
表面上，此类配置通常仅在个案基础上执行，因此可以考虑单个部署的具体情况。
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，上述所有问题仍然会出现。这将允许攻击者仍然使用SIP UA公共源IP地址的数据包欺骗SBC的所有公共IP地址和端口。但是，这只会影响来自该IP（或IP地址范围）的媒体，而不会影响SBC正在服务的所有呼叫。
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.
恶意源可能会将媒体数据包发送到SBC媒体锁定UDP端口，希望被锁定以接收给定SIP会话的媒体。SBC也有各种机制来防止这种情况。例如，限制锁定在这种情况下也会有所帮助，因为攻击者无法让SBC将媒体数据包发送回自己，因为SBC不会锁定攻击者的媒体数据包，而不会首先看到相应的信令数据包。如果攻击者恰好位于（1）IP路由路径中，从而可以欺骗与真实UA相同的IP并使媒体返回，则仍然可能存在问题，在这种情况下，攻击者几乎不需要从一开始就进行攻击，或者（2）在与合法SIP UA相同的NAT后面，在这种情况下，SBC将锁定攻击者的数据包，并将媒体发送回攻击者。在后一种情况下，可能特别关注载波级NAT，当没有听到任何声音的人类用户挂断时，合法的SIP UA可能无论如何都会结束呼叫。对于非人工呼叫参与者，如应答机，这可能不会发生（尽管许多此类自动UAs在没有收到任何媒体时也会挂断）。攻击者还可以在收到所有媒体后将其重定向到真实的SIP UA，在这种情况下，攻击很可能未被发现并成功。同样，这对于服务于许多不同端点（例如载波级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.
当然，安全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将对从运营商级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不知道它发生了。在某些情况下，它可能是可检测的，例如当SIP UA支持ICE并且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；因此，除非SBC重新签署请求，否则SIP UA不能使用S/MIME[RFC5751]，也不能签署发送请求，或使用SIP标识机制[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地址屏蔽通常被认为很重要。然而，这不再是HNT的独有优势，因为如果客户明确希望这样做，它也可以通过客户机控制的中继机制（如TURN[RFC5766]）来实现。
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：会话启动协议”，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]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年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：会话描述协议”，RFC4566，2006年7月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播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，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年4月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年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]贝达，J.，圣安德烈，P.，希尔德布兰德，J.，和S.伊根，“XEP-0177：叮当原始UDP传输方法”，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，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435]Andreasen，F.和B.Foster，“媒体网关控制协议（MGCP）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-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，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，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]Taylor，T.，“将RFC 3525重新分类为历史”，RFC 51252008年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.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年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，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年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.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，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-拼接]Maltz，D.和P.Bhagwat，“应用层代理性能的TCP拼接”，《高速网络杂志》第8卷，第3期，1999年，第225-240页，1999年3月。
Authors' Addresses
作者地址
Emil Ivov Jitsi Strasbourg 67000 France
埃米尔·伊沃夫·吉茨·斯特拉斯堡67000法国
EMail: emcho@jitsi.org
EMail: emcho@jitsi.org
Hadriel Kaplan Oracle 100 Crosby Drive Bedford, MA 01730 USA
美国马萨诸塞州贝德福德克罗斯比大道100号Hadriel Kaplan Oracle 01730
EMail: hadrielk@yahoo.com
EMail: hadrielk@yahoo.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com