| STRAW | R. Ravindranath |
| Internet-Draft | T. Reddy |
| Intended status: Standards Track | G. Salgueiro |
| Expires: April 3, 2015 | Cisco |
| September 30, 2014 |
Session Traversal Utilities for NAT (STUN) Message Handling for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-stun-00
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path, rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing. It is critical that B2BUAs handle these STUN messages properly.
This document defines behavior for a B2BUA performing ICE processing.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 3, 2015.
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.
In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. These SIP entities, commonly known as Back-to-Back User Agents (B2BUAs) are described in [RFC7092].
The Session Initiation Protocol (SIP) [RFC3261], and other session control protocols that try to use direct path for media, are typically difficult to use across Network Address Translators (NATs). These protocols use IP addresses and transport port numbers encoded in the signaling, such as the Session Description Protocol (SDP) [RFC4566] and, in the case of SIP, various header fields. Such addresses and ports are unreachable 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], started appearing but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing (UNSAF) and 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 NAT. [RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT) to solve the NAT traversal problem.
Section 5 of [RFC7362] describes some of the issues with SBCs implementing HNT and offers some mitigation strategies. The most commonly used approach to solve these issues is "restricted-latching", whereby the B2BUA will not latch to any packets from a source public IP address other than the one the SIP UA uses for SIP signaling. However, this is susceptible to attacks, where an attacker who is able to see the source IP address of the SIP UA may generate packets using the same IP address. There are other threats described in Section 5 of [RFC7362] for which Secure Real-time Transport Protocol (SRTP) [RFC3711] can be used as a solution. However, this would require the B2BUAs to be terminating/re-originating SRTP, which is not always possible. A B2BUA can use ICE [RFC5245], which 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. This can solve some of the security concerns with HNT solution. Further, ICE has other benefits like selecting an address when more than one address is available (e.g. dual-stack), verifying that a path works before connecting the call etc. For these reasons endpoints often use ICE to pick a candidate pair for media traffic between two agents.
B2BUAs often operate on the media path and have the ability to modify SIP headers and SDP bodies as part of their normal operation. Such entities, when present on the media path, are likely to take an active role in the session signaling depending on their level of activity on the media path. For example, some B2BUAs modify portions of the SDP body (e.g., IP address, port) and subsequently modify the media packet headers as well. There are other types of B2BUAs that modify the media payload (e.g., a media transcoder). Section 18.6 of ICE [RFC5245] explains two different behaviors when B2BUAs are present. Some B2BUAs are likely to remove all the SDP ICE attributes before sending the SDP across to the other side. Consequently, the call will appear to both endpoints as though the other side doesn't support ICE. There are other types of B2BUAs that pass the ICE attributes without modification, yet modify the default destination for media (contained in the m= and c= lines and rtcp attribute) This will be detected as an ICE mismatch and ICE processing is aborted for the call. The call may continue if the endpoints are able to reach each other over the default candidate (sent in m= and c= lines).
[RFC7092] describes three different categories of such B2BUAs, according to the level of activities performed on the media plane:
When such a B2BUA operating on a media plane is involved in a call between two endpoints performing ICE, then it SHOULD follow the behavior described in this specification.
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 [RFC2119].
The following generalized terms are defined in [RFC3261], Section 6.
All of the pertinent B2BUA terminology and taxonomy used in this document is based on [RFC7092].
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", which maps to NAT and NAPT terms from [RFC3022], 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.
When one or both of the endpoints are behind a NAT, and there is a B2BUA between the endpoints, the B2BUAs MUST support ICE or at a minimum support ICE LITE functionality as described in [RFC5245]. Such B2BUAs MUST use the mechanism described in Section 2.2 of [RFC5245] to demultiplex STUN packets that arrive on the Real-time Transport Protocol(RTP)/RTP Control Protocol (RTCP) port.
The subsequent sections describe the behavior B2BUA's MUST follow for handling ICE messages. A B2BUA can terminate ICE and thus have two ICE contexts with either endpoint. The reason for ICE termination could be due to the need for B2BUA to be in the media path ( e.g., media transcoding, media recording, address hiding etc.) A B2BUA can also be in ICE passthrough mode and passes across the candidate list from one endpoint to the other side. A B2BUA may be in ICE passthrough mode when it does not have a need to be on the media path. The below sections describes the behaviors for these two cases.
A B2BUA that wishes to be in the media path follows the below steps:
+-------+ +------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob |
+-------+ +------------------+ +-----+
|(1) INVITE | (3)INVITE |
| a=ice-ufrag1 | a=ice-ufrag2 |
| a=ice-pwd1 | a=ice-pwd2 |
| (Alice's IP, port) | (B2BUA's IP, port) |
|(Alice's candidate list )| (B2BUA's candidate list)|
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | (5)200 OK |
| | a=ice-ufrag3 |
| | a=ice-pwd3 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
| (6) 200 OK | |
| a=ice-ufrag4 |-----------ACK------------>|
| a=ice-pwd4 | (7) |
| B2BUA's IP,port | |
| (B2BUA's cand list1) | |
|<------------------------| |
|--------ACK------------->| |
| (8) | |
| | |
|<----ICE Connectivity 1->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (9) | checks +conclusion |
| | (10) |
|<-------Media packets -->|<----Media packets-------->|
| (13) | (14) |
| | |
|<---ICE keepalives 1---->| |
| (15) |<----ICE keep alives 2---->|
(16)
Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA
The above figure shows a sample call flow with two endpoints Alice and Bob doing ICE and a B2BUA handing STUN messages from both the endpoints. For the sake of brevity the entire ICE SDP attributes are not shown. Also the STUN messages exchanged as part of ICE connectivity checks are not shown. Key steps to note from the call flow are:
Since there are two independent ICE contexts on either side of the B2BUA it is possible that ICE checks will conclude on one side before concluding on the other side. This could result in an ongoing media session for one end, while the other is still being set up. Any such media received by the B2BUA would continue to be sent to the other side on the default candidate address (that was sent in c= line).
If a B2BUA does not see a need to be in media path, it can do the following steps mentioned in this section.
+-------+ +------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob |
+-------+ +------------------+ +-----+
|(1) INVITE | (3)INVITE |
| a=ice-ufrag1 | a=ice-ufrag1 |
| a=ice-pwd1 | a=ice-pwd1 |
| (Alice's IP, port) | (Alices's IP, port) |
|(Alice's candidate list )| (Alice's Candidate list + |
| B2BUA's candidate list1)|
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | (5)200 OK |
| | a=ice-ufrag2 |
| | a=ice-pwd2 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
| (6) 200 OK | |
| a=ice-ufrag2 |-----------ACK------------>|
| a=ice-pwd2 | (7) |
| (Bobs's IP,port) | |
| (B2BUA's cand list2 + | |
| Bob's Candidate list) | |
|<------------------------| |
|----------ACK----------->| |
| (8) | |
| | |
|<----ICE Connectivity 1 (9)------------------------->|
| | |
|<----ICE Connectivity 2->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (10) | checks +conclusion |
| | (11) |
|<-------------------Media packets------------------->|
| (12) |
| | |
|<------------------ICE keepalives------------------->|
(13)
Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in ICE Passthrough mode
The above figure shows a sample call flow with two endpoints Alice and Bob doing ICE and a B2BUA handing STUN messages from both the endpoints. For the sake of brevity the entire ICE SDP attributes are not shown. Also the STUN messages exchanged as part of ICE connectivity checks are not shown. Key steps to note from the call flow are:
Because of forking a B2BUA may receive multiple answers for a single outbound INVITE. When this occurs the B2BUA should follow section 3.2 or 3.3 for all of those received answers.
TBD
This document makes no request of IANA.
Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-Huguenin, Simon Perreault and Lorenzo Miniero for their constructive comments, suggestions, and early reviews that were critical to the formulation and refinement of this document.
| [RFC3022] | Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. |
| [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. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |
| [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. |
| [RFC7092] | Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, December 2013. |
| [RFC7362] | Ivov, E., Kaplan, H. and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, September 2014. |