Network Working GroupInternet Engineering Task Force (IETF) E. IvovInternet-DraftRequest for Comments: 7362 JitsiIntended status:Category: Informational H. KaplanExpires: December 19, 2014ISSN: 2070-1721 Oracle D. Wing CiscoJune 17,September 2014 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communicationdraft-ietf-mmusic-latching-08Abstract This document describes the behavior of signaling intermediaries inReal- TimeReal-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. This document isnon-normative,non-normative and is only written to explain HNT in order to provide a reference to theIETF community, as well asInternet community and an informative description tomanufacturers,manufacturers and users. Latching, which is one of thecomponents of theHNT 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 othersolutionssolutions, such as the Interactive Connectivity Establishment (ICE) protocol. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe 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 amaximumcandidate for any level of Internet Standard; see Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 19, 2014.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. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5 4. MediaBehavior,Behavior and Latching . . . . . . . . . . . . . . . . ..6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 138.7. References . . . . . . . . . . . . . . . . . . . . . . . . .13 8.1. Key14 7.1. Normative References . . . . . . . . . . . . . . . . . .. . . 13 8.2. Additional14 7.2. Informative References . . . . . . . . . . . . . . . . ..14Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151. Introduction 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,firewall/NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc. 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. 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 startedappearingappearing, but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing(UNSAF) and(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". The term often used for this behavior isHosted"Hosted NAT Traversal(HNT), although(HNT)"; a number of manufacturers sometimes use other names such as "Far-end NAT Traversal" or "NAT assist" instead. The systemswhichthat 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 asSBCs,SBCs and the NAT traversal behavior is called HNT.AsAt the time of this document'screation time,publication, a vast majority of SIP domains use HNT to enable SIP devices to communicate acrossNATs,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. Itis howeveris, 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. The purpose of this document is to describe the mechanisms often used for HNT at the SDP and medialayer,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. 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. 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. 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. The rest of this documentis going to focusfocuses primarily on the use of HNT for SIP. However, the mechanisms described here are relatively generic and are often used with otherprotocols,protocols such asXMPPthe Extensible Messaging and Presence Protocol (XMPP) [RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435],H.248/ MEGACOMegaco/H.248 [RFC5125], and H.323 [H.323]. 2. Background The general problems with NAT traversal for protocols such as SIP are: 1. The addresses and port numbers encoded in SDP bodies (or their equivalents) by NATed User Agents (UAs) are not usable across theInternet,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. 2. The policies inherent in NATs, and explicit inFirewalls,firewalls, are such that packets from outside the NAT cannot reach the UA until the UA sends packets out first. 3. Some NATs applyendpoint dependentendpoint-dependent filtering on incoming packets, as described in[RFC4787] and thus[RFC4787]; thus, a UA may only be able to receive packets from the same remote peer IP:port as it sends packets out to. 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. +-----+ +-----+ | 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 3. Impact on Signaling Along with codec and other media-layer information, session establishment signaling alsoconveys,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. 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 forsignaling, assignaling (as it is known to work for thatUA.UA). In other words,signallingsignaling and media wouldeitherboth travel over either IPv4 or 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. Inpracticepractice, such media may or may not bereceived,received depending on the implementations participating in a given session, local policies, and the call scenario. Forexampleexample, if a SIP SDPOfferoffer originally came from a UA behind a NAT, the SIP SBC cannot send media to it until an SDPAnsweranswer is given to the UA and latching (Section 4) occurs. Another exampleisis, when a SIP SBC sends an SDPOfferoffer 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 preventtoll-toll fraud). 4. MediaBehavior,Behavior and Latching 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. TheUA howeverUA, 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 beingsetup,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.ThereforeTherefore, media relays used in HNT would often use a mechanism called "latching". 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.TodayToday, most people talk about them both as"latching", and thus"latching"; thus, this document does as well. The latching mechanism works as follows: 1. After receiving an offer from Alice(UAC(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(UAS)(User Agent Server (UAS)) so that he would use those media relay address:port tuples for all mediaithe wished to send toward 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. Init's theits answer to Alice(UAC)(UAC), the SBC will replace Bob's address:port with this second set. Thiswayway, Alice will send media to this media relay address:port. 3. The media relay receives the media packets on the allocatedports,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:porttuple.tuples. 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'sNATNAT, and anything that the relay sends back to thataddress:port,address:port would find its way to Alice. 5.SimilarlySimilarly, the source of the media packets that Bob (UAS) is sending would be latched upon and used for media going in that direction. 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 hasstartedstarted, 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 somecasescases, 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. 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 theUser Agent Client (UAC)UAC network and 198.51.100/24 facing towards theUser Agent Server (UAS)UAS network. 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 acrosstwo interfacesTwo Interfaces 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 publicinternet.Internet. 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 XMPPserverServer acrosstwo interfacesTwo Interfaces 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. It is worth pointing out that latching is notanexclusively a "serveraffair"affair", and some clients may also use it in cases where they are configured with a public IP address andtheyare contacted by a NATed client with no other NAT traversal means. 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.TodayToday, this is the casefor with, for example,with almost all SIP and XMPP clients.AlsoAlso, UAs need to make sure they can begin sending media packets independentlyandwithout waiting for packets to arrive first. In theory, it is possible that some UAs would not send packets outfirst;first, forexampleexample, 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 beginan inactivein '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.HoweverHowever, SBCs providing HNT would always be configured to avoid this. 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 thiscasecase, the media relays controlled by the signaling servers could end up each waiting upon the other to initiate the streaming. To preventthisthis, 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 performingserverserver, it would have provided its relay's public address andportsports, and the early stream would find its target. Although many SBCs only support UDP-based medialatching, and in particular RTP/RTCP,latching (in particular, RTP/RTCP), many SBCs support TCP-based media latching as well. TCP-based latching is morecomplicated, andcomplicated; 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].[TCP-SPLICING]. HNT andlatchinglatching, inparticularparticular, are generally found tobe working reliablywork 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][RFC5245]. 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 andoftenincreased 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.AlsoAlso, in somecasescases, routing media through operator controlled relays may route media over paths explicitly optimized for media and hence offer better performance than regular Internet routing. 5. Security Considerations A common concern is that an SBC (or an XMPPserver,server -- all security considerations apply to both) that implements HNT may latch to incorrect and possibly malicious sources. The ICE [RFC5245]protocolprotocol, for example, provides authentication tokens (conveyed in theice- ufragice-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 sourcecould, for example,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 fromhappening,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. Thiswayway, the SBC simply ignores and does not latch onto packets coming from the attacker. In somecasescases, 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 ofthird partythird-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 deploymentswouldcan 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 allowthemattackers 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. A malicious source could send media packets to an SBC media-latching UDP port in the hopes of beinglatched-tolatched to for the purpose of receiving media for a given SIP session. SBCs have various mechanisms to prevent this as well. Restrictedlatchinglatching, forexampleexample, would also help in this casesincebecause 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 pathand thuswhere 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)the attacker isbehind the same NAT as the legitimate SIP UA, in which case the attacker's packets will belatched-tolatched to by the SBC and the SBC will send media back to the attacker. Inthisthe 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 withlarger scalelarger-scale NATs serving many differentendpointsendpoints, such as Carrier-Grade NATs. The larger the number of devices fronted by a NAT is, the more use cases wouldvaryvary, and the more the number of possible attack vectors would grow. Naturally,SRTPSecure 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.[RFC3261]Section 26 of [RFC3261] provides an overview of additional threats and solutions on monitoring and session interception. 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. For SIP clients, HNT is usually transparent in the sense that the SIP UA does not know it occurs. In certaincasescases, 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 amiddle boxmiddlebox is relayingmedia,media but not necessarily that it is performing latching/HNT. In order to perform HNT, the SBC has to modify SDP to and from the SIP UA behind aNAT, and thusNAT; thus, the SIP UA cannot use S/MIME [RFC5751], and it cannot sign a sendingrequestrequest, or verify a received request using the SIP Identity mechanism [RFC4474] unless the SBC re-signs the request. However, neither S/MIMEor [RFC4474]nor SIP Identity are widelydeployed, thusdeployed; thus, not being able to sign/verify requestsappearappears not to be a concern at this time. 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],[RFC5766] if the client explicitly wishes to do so. 6.IANA Considerations This document has no actions for IANA. Note to the RFC-Editor: please remove this section prior to publication as an RFC. 7.Acknowledgements The authors would like to thank Flemming Andreasen, Miguel A. Garcia, Alissa Cooper, Vijay K. Gurbani, AriKeranenKeranen, and Paul Kyzivat for their reviews and suggestions on improving this document.8.7. References8.1. Key7.1. Normative References [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. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [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. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [XEP-0177] Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, "XEP-0177: Jingle Raw UDP Transport Method", XSF XEPXEP-0177,0177, December 2009.8.2. Additional7.2. Informative References [H.323] International Telecommunication Union,"Packet Based Multimedia Communication Systems","Packet-based multimedia communication systems", ITU-T Recommendation H.323,July 2003.December 2009. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [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. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [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. [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.[tcp-splicing][TCP-SPLICING] Maltz, D. and P. Bhagwat, "TCP Splice for application layer proxy performance", Journal of High Speed Networksvol.Vol. 8,no.No. 3, 1999, pp.235-240,225-240, March 1999. Authors' Addresses Emil Ivov Jitsi Strasbourg 67000 FranceEmail:EMail: emcho@jitsi.org Hadriel Kaplan Oracle 100 Crosby Drive Bedford, MA 01730 USAEmail: hadriel.kaplan@oracle.comEMail: hadrielk@yahoo.com Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USAEmail:EMail: dwing@cisco.com