SIPPING Working Group S. Sen Internet Draft F. Audet F Meijer C. Aoun Category: Informational Nortel Networks Expires on March 2003 Sept 2002 Identifying Intra-realm Calls using STUN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft proposes the use of STUN to determine whether two communicating endpoints are in the same realm. This draft describes the use of STUN in a peer- to-peer fashion between endpoints during call set-up. The call set-up may proceed in parallel with the STUN messaging, allowing the peers to initially exchange media using their public IP addresses. If the peers are in the same realm, then the media is switched to the private IP addresses using a SIP UPDATE or a SIP reINVITE SDP offer-answer exchange. With this proposal, media flows are kept within the same addressing realm whenever possible, thus avoiding certain network intermediaries and reducing bandwidth requirements on external links into the realm. 1 Introduction This draft proposes the use of [STUN] to identify if two communicating endpoints are in the same realm. Using this proposal, media flows are kept within the same Sen [Page 1] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 addressing realm whenever possible, thus avoiding usage of certain network intermediaries and reducing bandwidth requirements on external links into the realm. In a typical usage of STUN without the implementation of this proposal, two endpoints behind a NAT would send their media through the NAT even in the scenario where there is a direct path. This requires that the NAT loop back the media packets. This loop back approach is an inefficient use of resources and it may not be supported by all types of NATs. Thus, a simple, scalable and secure mechanism at the endpoints to detect this direct connectivity is required. This draft describes how STUN can be used in a peer-to-peer fashion along with the SIP session setup to detect intra-realm sessions. 1.1 Applicability The solution applies to the simple topology where there are one or more NATs between the endpoints that do not share a common root NAT. A more general case, typical of many cable service providers, is when the clients are behind NATs that are all connected to a NAT in the service provider network. The solution for this general case is NOT addressed by this memo. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3 Terminology Used Middle Box - refer to the terminology used in [FRMWRK] Tromboning: The NAT loops back packets sent from a client addressed to the public address of another client in the same realm behind the NAT 4 Motivation Figure 1 shows a complex partitioned intranet in a large Enterprise. Users at finance.us.x.com and finance.europe.x1.com are connected through the intranet and does not have to traverse the NATÆs (MB1 and MB4 in Fig 1). Similarly, calls between eng.europe.x.com and finance.europe.x1.com can be routed directly, instead of going through MB4 and MB3. In a more traditional use of STUN, users in finance.us.x.com would contact an external STUN server and receive a public address at the NAT MB1. The users in finance.europe.x1.com will similarly receive its public address on NAT MB4. The packets will be exchanged using these public addresses through the Internet although there is a direct path between the endpoints. This will generally lead to QoS degradation, unnecessarily overload the middleboxes and/or involve an intermediary when one is not required. +++++++++++++++++++ ++++++++++++++++ +++++++ +finance.us.x.com + + + + + + Internet +----STUN Server 1 Sen Informational - Expires March 2003 [Page 2] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 + ++++++ + + + +MB1 +-----+ + + ++++++ + + +++++++++++++++++++ + +-----STUN server n | ++++++++++++++++ +++++++ | / | | / | | ++++++++++++++++++ | | + +MB3+ + | | + +++++ + | | +eng.europe.x.com+ | | + + | | ++++++++++++++++++ | | | | | +++++++++++++ ++++++++++++++++++++++++++++ + x.com + + +MB4+ + + Intranet + + +++++ + + +---+ + +++++++++++++ + finance.europe.x1.com + +++++++++++++++++++++++++++ Figure 1. In case of a session between users behind the same Middlebox, the packets exchanged between the two endpoints need to be looped back by the Middlebox. This feature is called ætromboningÆ and is not supported by all types of NATÆs. Therefore, if the Middlebox does not support tromboning, a Middlebox traversal solution based on STUN will fail. It is of advantage, in the above scenarios, for the media endpoints to automatically detect whether there is any direct connectivity between them. 5 Solution The solution requires the endpoints to support both STUN client and server. The STUN server at the endpoints need to listen at address and port that is bound to its publicly advertised media address and port. The endpoints will exchange STUN probes in a peer-to-peer fashion before the media session is established to discover if there is any direct connectivity between them. The mechanism is illustrated with an example for user A establishing a session with user B using SIP (please refer to Fig 2 for an example flow). The same methodology could be done with other application protocols. 1) User A sends a SIP INVITE [Fig 2-(1)] with a Require: header with a new option tag ôconndetect-stunö. It is assumed that the INVITE contains an SDP carrying the public address and port (Pub-A) at which A wants to receive media. 2) Upon receipt of AÆs SDP, B sends two STUN BINDING_REQUEST messages to Pub-A. One of the BINDING_REQUEST messages will have its RESPONSE-ADDRESS Sen Informational - Expires March 2003 [Page 3] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 attribute set to the private IP address and port at B (Pvt-B) [Fig 2-(3)]. This is the private address/port at which B wishes to receive media. The other BINDING_REQUEST message MUST NOT contain a RESPONSE-ADDRESS attribute [Fig 2-(2)]. The two messages MUST contain different transaction IDs. 3) User A will respond to both the BINDING_REQUEST messages in the order that they are received [Fig 2-(4), Fig 2-(5)]. The BINDING_RESPONSE message in response to the request containing the RESPONSE_ADDRESS will be sent to the address Pvt-B [Fig 2-(5)]. 4) Based on the network connectivity between the two users, user B receives either (a) 2 BINDING_RESPONSES, or (b) 1 BINDING_RESPONSE, or (c) no BINDING_RESPONSE. Case (a) will happen when both users A and B are behind the same NAT and the NAT supports tromboning. Case (b) will happen when the users are in different realms (behind different NATÆs). Case (c) can happen only if the two users are behind the same NAT and the NAT does not support tromboning. If user B does not receive any BINDING_RESPONSE message then the retransmission mechanism in [STUN] is invoked. If no BINDING_RESPONSE is received, client B concludes that A and B are in the same realm. ISSUE: The real-time implication for this procedure needs to be further evaluated based on real network deployments. Are there any scenarios where this conclusion may not be correct? If the first BINDING_RESPONSE is received and it matches the transaction id of the BINDING_REQUEST that carried the RESPONSE-ADDRESS parameter, then B concludes that A and B are in the same realm and goes to step 5. If the transaction id of the first received BINDING_RESPONSE message matches that of the request not carrying the RESPONSE-ADDRESS parameter, client B waits for a timer period TNEXT (TBD) for the second BINDING_RESPONSE message. If B receives the second BINDING_RESPONSE message within this period, it concludes that the peer is in the same realm. If TNEXT expires, then it concludes that A and B are in different realms (behind different NATÆs). ISSUE: In case the endpoints are behind the same NAT and the NAT doesnÆt support tromboning, then media packets will be lost until the direct connectivity is detected and the endpoint addresses are updated. The value of TNEXT will be motivated, in this scenario, by how long the users will typically wait before they decide to terminate the session. 5) If user B determines (using the procedures in step 4) that its peer (user A) is in the same realm, then it sends an UPDATE [Fig 2-(8)] message (or a reINVITE, as appropriate) containing the private IP address and port at which it wants to receive media 6) User A, on receiving an SDP from B (e.g., either in 18x or 200 OK response to INVITE) [Fig 2-(6)], performs the exact same procedures [Fig 2- (7)] as B does in steps 2 to 5 to determine direct connectivity. If user A Sen Informational - Expires March 2003 [Page 4] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 determines that B and A are in the same realm, then it responds differently based on whether it has received an UPDATE (or reINVITE) from B, as follows: I) If A has received an UPDATE (or reINVITE) from B, then it responds with 200 OK [Fig 2-(9)] specifying its private IP address/port in the same m= line and c= line in the SDP where it had originally specified a public address/port. A continues to listen to its private address/port for the media. II) If A have not received an UPDATE (or reINVITE) from B, then it sends an UPDATE (or reINVITE) to B specifying its private IP address/port in the same m= line and c= line in the SDP where it had originally specified a public address/port. A continues to listen to its private address/port for the media. When any of the users receives an SDP offer (or SDP answer) with a new address/port for the media, it MUST start sending media to this updated address/port. 7) The original INVITE transaction is ended by an ACK [Fig 2-(10)] and media transmission begins. NOTES-1) All the steps described above are not sequential. For example, A can begin its intra-realm determination right after it receives a 200OK or 18x message containing an SDP from B, almost simultaneously to BÆs determination of the same (step 4). NOTES-2) The endpoints can start exchanging media through their publicly addressed IP address/port after the dialog (or early dialog) is established (e.g., after the INVITE/200OK or INVITE/18x exchange). After the connectivity detection takes place, the endpoints are expected switch to the new destination addresses. 6 An Example Call Flow Scenario: The users are in the same realm and NAT supports tromboning UAC / UAS / NAT STUN client/server STUN client/server private=10.0.1.1 private=10.0.2.2 public=1.2.3.4 public=1.2.4.5 | | | |(1) INVITE | | |Require:conndetect-stun | |rtp=1.2.3.4:5679 | | | | | |------------------>| | | | | | |(2) STUN Bind Req | | |src=10.0.2.2:5306 | | |dest=1.2.3.4:5679 | | |------------------>| | |(2) STUN Bind Req | | |src=1.2.4.5:5300 | | |dest=10.0.1.1:5600 | Sen Informational - Expires March 2003 [Page 5] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 |<--------------------------------------| | | | | | | | |(3) STUN Bind Req | | |src=10.0.2.2:5306 | | |dest=1.2.3.4:5679 | | |Response_addr=10.0.2.2:5306 | |------------------>| | |(3) STUN Bind Req | | |src=1.2.4.5:5300 | | |dest=10.0.1.1:5600 | | |Response_addr=10.0.2.2:5306 |<--------------------------------------| | | | | | | | (4) STUN Resp. | | | src=10.0.1.1:5600 | | | dst=1.2.4.5:5300 | | | Mapped_Addr=1.2.4.5:5300 | |-------------------------------------->| | | | | |(4) STUN Resp. | | | src=1.2.3.4:5679 | | | dst=10.0.2.2:5306 | | | Mapped_Addr=1.2.4.5:5300 | |<------------------| | | | | (5) STUN Resp. | | | src=10.0.1.1:5600 | | | dst=10.0.2.2:5306 | | | Mapped_Addr=1.2.4.5:5300 | |------------------>| | | | | |(6) 200 OK | | |rtp=1.2.4.5:6000 | | |<------------------| | | | | |----> (7) | | | | | | (8) UPDATE | | | rtp=10.0.2.2:5306 | |<------------------| | | | | | (9) 200 OK | | | rtp=10.0.1.1:5600 | |------------------>| | |(10) ACK | | |------------------>| | | | | |<=================>| | media Sen Informational - Expires March 2003 [Page 6] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 Figure 2. 7 References [FRMWRK] Srisuresh, Kuthan, Rosenberg, Molitor, Rayhan, "MIDCOM Architecture & Framework", RFC 3303 [STUN] Rosenberg,Weinberger,Huitema,Mahy, "STUN - Simple Traversal of UDP Through NATs", Internet draft, draft-rosenberg-midcom-stun-02.txt [OA] RFC 3264, ôAn Offer/Answer Model with SDPö 8 Acknowledgments The author would like to thank the following people for their useful comments and suggestions related to this draft: 9 Authors' Address {sanjoy, audet, meijer, aoun}@nortelnetworks.com 10 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Sen Informational - Expires March 2003 [Page 7] Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Sen Informational - Expires March 2003 [Page 8]