Session Traversal Utilities for NAT (STUN) Message Handling for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)

In many Session Initiation Protocol (SIP) deployments, SIP entities exist in the SIP signaling and media path between the originating and final terminating endpoints, which go beyond the definition of a traditional SIP proxy. These SIP entities, commonly known as Back-to-Back User Agents (B2BUAs), are described in and often perform functions not defined in Standards Track RFCs. SIP , 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) and, in the case of SIP, various header fields. Such addresses and ports are unreachable if any peers are separated by NATs. Mechanisms such as Session Traversal Utilities for NAT (STUN) , Traversal Using Relays around NAT (TURN) , and Interactive Connectivity Establishment (ICE) did not exist when protocols like SIP began being deployed. Some mechanisms, such as the early versions of STUN, started appearing but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing (UNSAF) and described in . For these reasons, B2BUAs are being used by SIP domains for SIP and media-related purposes. These B2BUAs use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NAT. describes how B2BUAs can perform Hosted NAT Traversal (HNT) in certain deployments. Section 5 of 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 defined in section 5 of , 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 for which Secure Real-time Transport Protocol (SRTP) can be used as a solution. However, this would require the B2BUAs to terminate and re-originate SRTP, which is not always desirable. This document describes proper behavior of B2BUAs performing ICE processing. This includes defining consistent handling of SIP messages carrying ICE semantics in SDP and STUN messages received as part of the ICE procedures performed on the media path for NAT and Firewall traversal of multimedia sessions. A B2BUA can use ICE , 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 environment where host can have both IPv4 and IPv6 addresses), 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. Section 18.6 of ICE 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 (defined in ). This will be detected as an ICE mismatch and ICE processing will be aborted for the session. The session may continue if the endpoints are able to reach each other over the default candidate (sent in m= and c= lines). Section 3.1.3 of defines a SDP-Modifying Signaling-only B2BUA that operates in the signaling plane only and is not in the media path, but it does modify SDP bodies and is thus aware of and understands SDP syntax and semantics. Such B2BUA MUST follow the behavior mentioned in Section 3. Section 3.2 of describes three different categories of B2BUAs that operates on both signaling(SIP and SDP) and media plane according to the level of involvement and active participation in the media plane: A B2BUA that acts as a simple media relay effectively unaware of anything that is transported and only modifies the transport header (could be UDP/IP) of the media packets. A B2BUA that performs a media-aware role. It inspects and potentially modifies RTP or RTP Control Protocol (RTCP) headers; but it does not modify the payload of RTP/RTCP. A B2BUA that performs a media-termination role and operates at the media payload layer, such as RTP/RTCP payload (e.g., a transcoder). When B2BUAs that operate on media plane (media relay, media-aware or media-termination) is involved in a session between two endpoints performing ICE, then it MUST follow the behavior described in .

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 . All of the pertinent B2BUA terminology and taxonomy used in this document is defined in . 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 , 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) , etc.

An SDP-Modifying Signaling-only B2BUA is one that operates in the signaling plane only and is not in the media path, but it modifies SDP bodies as described in section 3.1.3 of . Such B2BUAs MUST NOT change IP address in c= line, port in m= line and ICE semantics of SDP as doing so can cause ICE-mismatch.

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 . Such B2BUAs MUST use the mechanism described in Section 2.2 of to demultiplex STUN packets that arrive on the Real-time Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. The subsequent sections describe the behavior B2BUAs 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., address hiding for privacy, interworking between ICE to no-ICE, etc.). A B2BUA can also be in optional ICE termination mode and passes across the candidate list and STUN short-term credentials (ice-ufrag and ice-pwd attributes) from one endpoint to the other side after adding its own candidates. A B2BUA MAY be in optional ICE termination 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 always be in the media path follows the below steps: When a B2BUA sends out SDP, it MUST advertise support for ICE and MAY include B2BUA candidates of different types for each component of each media stream. If the B2BUA is in ICE lite mode as described in Section 2.7 of then it MUST send a=ice-lite attribute and MUST include B2BUAs host candidates for each component of each media stream. If the B2BUA supports full ICE then it MAY include B2BUAs candidates of different types for each component of each media stream. The B2BUA MUST generate new username, password values for ice-ufrag and ice-pwd attributes when it sends out the SDP and MUST NOT propagate the ufrag, password values it received in the incoming SDP. This ensures that the short-term credentials used for both the legs are different. The short-term credentials include authentication tokens (conveyed in the ice-ufrag and ice-pwd attributes), which the B2BUA can use to verify the identity of the peer. B2BUA terminates the ICE messages on each leg and does not propagate them. The B2BUA MUST NOT propagate the candidate list received in the incoming SDP to the outbound SDP and instead only advertise its candidate list. The B2BUA MUST also add its default candidate in the c= line (IP address) and m= line (port). In this way the B2BUA will be always in the media path. Depending on whether the B2BUA supports ICE lite or full ICE it implements the appropriate procedures mentioned in for ICE connectivity checks.

|-------------------------->| | | | | (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) | | B2BUAs IP,port | | | (B2BUAs 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) ]]> The above figure shows an example 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: Alice sends an INVITE with SDP having ICE candidates. B2BUA modifies the received SDP from Alice by removing the received candidate list, gathers its own candidates, generates new username, password values for ice-ufrag and ice-pwd attributes. The B2BUA also changes the c= line and m= line to have its default candidate and forwards the INVITE (3) to Bob. Bob responds (5) to the INVITE with his own list of candidates. B2BUA responds to the INVITE from Alice with SDP having B2BUAs candidate list. B2BUA generates new username, password values for ice-ufrag and ice-pwd attributes in the 200 OK response (6). ICE Connectivity checks happen between Alice and the B2BUA in step 9. Depending on whether the B2BUA supports ICE or ICE lite it will follow the appropriate procedures mentioned in . ICE Connectivity checks also happen between Bob and the B2BUA in step 10. Step 9 and 10 happen in parallel. The B2BUA always terminates the ICE messages on each leg and has two independent ICE contexts running. Media flows between Alice and Bob via B2BUA (Step 13, 14). STUN keepalives would be used between Alice and B2BUA (step 15) and between Bob and B2BUA (step 16) to keep NAT and Firewall bindings alive. 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).

A B2BUA willing to be in the media path only for NAT traversal, but does not otherwise require to be in the media path can do the following steps mentioned in this section. When a B2BUA receives an incoming SDP with ICE semantics it copies the received candidate list and appends its own candidate list in the outgoing SDP. The B2BUA also copies the ufrag/password values it received in the incoming SDP to the outgoing SDP and then sends out the SDP. The B2BUAs candidates MAY have lower-priority than the candidates provided by the endpoint, this way endpoint and remote peer candidate pairs are tested first before trying candidate pairs with B2BUA candidates. After offer/answer is complete, the endpoints will have both the B2BUAs and remote peer candidates. It will then use ICE procedures described in Section 8 of to nominate a candidate pair for sending and receiving media streams. With this approach the B2BUA will be in the media path only if the ICE checks between all the candidate pairs formed from both the endpoints fail.

|-------------------------->| | | | | (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) | | | (B2BUAs 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) ]]> 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: Alice sends an INVITE with an SDP having its own candidate list. B2BUA propagates the received candidate list in incoming SDP from Alice after adding its own candidate list. The B2BUA also propagates the received ice-ufrag, ice-password attributes from Alice in the INVITE (3) to Bob. In this example, the B2BUA does not modify the default candidate sent in the c= line and m= line and retains the values sent originally from Alice. If B2BUA wants to be in the media path when ICE connectivity checks between endpoints fails or one of the endpoints does not support ICE, then it overwrites its candidate address and port as a default candidate in the m= and c= lines. Bob responds (5) to the INVITE with his own list of candidates. B2BUA responds to the INVITE from Alice with an SDP having B2BUAs candidate list and the candidate list received from Bob. The B2BUA would also propagate the received ice-ufrag, ice-password attributes from Bob in step (5) to Alice in the 200 OK response (6). ICE Connectivity checks happen between Alice and Bob in step 9. ICE Connectivity checks also happens between Alice and B2BUA and Bob and B2BUA as shown in step 10, 11. Step 9, 10 and 11 happen in parallel. In this example Alice and Bob conclude ICE with a candidate pair that enables them to send media directly. Media flows between Alice and Bob in Step 12.

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.

ICE as described in Section 2.5 of uses STUN short-term credential mechanism for authentication and message integrity. STUN connectivity checks include MESSAGE-INTEGRITY attribute that contains HMAC-SHA1 of the STUN message and the HMAC is computed using the key exchanged in the signaling channel. The signaling channel between the endpoints and B2BUA MUST be encrypted so that the key is not visible to eavesdropper otherwise the security benefits of short-term authentication would be lost.

This document makes no request of IANA.

Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen and Parthasarathi R for their constructive comments, suggestions, and early reviews that were critical to the formulation and refinement of this document. Thanks to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins, Sam Hartman, Stephen Farrell, Kathleen Moriarty and Francis Dupont for their thoughtful review comments.