RFC 7584

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

📅 published July 2015, from ietf

RFC 7584 🎀 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)

okay bestie, this RFC is from the IETF, and it's a Standards Track document, so it's a real spec people build against 💅. It's RFC 7584, published July 2015, and the authors are R. Ravindranath, T. Reddy, and G. Salgueiro, all from Cisco. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates. 🦋

Abstract

okay so B2BUAs (Back-to-Back User Agents, the SIP boxes that sit in the middle of a call) are often built to be on the media path and not just poking at signaling 👀. That means they often handle the media themselves, which creates separate media legs that the B2BUA ties together and bridges. 🌉 When a B2BUA is doing media-path stuff, it's pretty likely to get STUN packets while ICE (Interactive Connectivity Establishment) is running ✨.

This doc says how a B2BUA should handle ICE. The whole goal is making sure B2BUAs handle SIP messages carrying ICE stuff in SDP, plus the STUN messages that show up during ICE, for NAT and firewall traversal of multimedia sessions 🌸.

Status of This Memo

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🧚.

Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7584 💜.

Copyright (c) 2015 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) as they were in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled from this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  SDP-Modifying Signaling-only B2BUA  . . . . . . . . . . . . .   5
4.  Media Plane B2BUAs  . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.2.  Mandatory ICE Termination with B2BUA  . . . . . . . . . .   6
  4.3.  Optional ICE Termination with B2BUA . . . . . . . . . . .   9
  4.4.  STUN Handling in B2BUA with Forked Signaling  . . . . . .  11
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

in a lot of SIP deployments, there are SIP entities sitting in the signaling and media path between the originating and final terminating endpoints 👑. They go beyond what a regular SIP proxy does. These are the B2BUAs described in [RFC7092], and they often do stuff that isn't defined in Standards Track RFCs 💅.

[RFC3261] (that's SIP) and other session control protocols that try to use a direct media path usually struggle with NATs 😭. They put IP addresses and transport port numbers in the signaling, like SDP [RFC4566] and, for SIP, a bunch of header fields. If peers are separated by NATs, those addresses and ports just aren't reachable.

STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245] didn't exist yet when protocols like SIP started getting deployed 🕰️. Early STUN versions showed up, but they were unreliable and had lots of the problems that come with UNilateral Self-Address Fixing (UNSAF), as [RFC3424] describes. So B2BUAs got used by SIP domains for SIP and media stuff, and they use proprietary mechanisms to let SIP devices behind NATs talk across the NAT 🦋.

[RFC7362] explains how B2BUAs can do Hosted NAT Traversal (HNT) in certain deployments 🌈. Section 5 of [RFC7362] covers some issues with Session Border Controllers (SBCs) doing HNT and suggests some mitigations. The most common fix is "restricted-latching," which is defined in Section 5 of [RFC7362]. With it, the B2BUA won't latch onto packets from any source public IP address except the one the SIP User Agent (UA) uses for SIP signaling. The catch is that an attacker who can see the UA's source IP address could send packets using that same IP address 😬. Section 5 of [RFC7362] lists other threats too, and Secure Real-time Transport Protocol (SRTP) [RFC3711] can help with those. The problem is that it means B2BUAs have to terminate and re-originate SRTP, and that's not always what you want 🙃.

This doc describes how B2BUAs should behave when they do ICE processing 🔥. It sets consistent handling for SIP messages that carry ICE semantics in SDP, and for STUN messages that come in during the ICE procedures on the media path for NAT and firewall traversal of multimedia sessions 💖.

A B2BUA can use ICE [RFC5245], which gives you authentication tokens (sent in the ice-ufrag and ice-pwd attributes). Those let you confirm a peer's identity before any media gets exchanged, which can fix some of the security concerns with the HNT solution 🔐. ICE has other perks too: it picks an address when more than one is available (like a dual-stack host with both IPv4 and IPv6 addresses), it checks that a path works before the call connects, and more 🌸. That's why endpoints often use ICE to pick a candidate pair for media between two agents.

B2BUAs often sit on the media path and can modify SIP headers and SDP bodies as part of normal operation 💅. When they're on the media path, they're likely to take an active role in the session signaling, depending on how active they are on the media path. For example, some B2BUAs change parts of the SDP body (like the IP address and port) and then change the media packet headers too 🧚. [RFC5245] Section 18.6 explains two different behaviors when B2BUAs are around 👀. Some B2BUAs remove all the SDP ICE attributes before they send the SDP to the other side. So the call looks to both endpoints like the other side doesn't support ICE 💀. Other B2BUAs pass the ICE attributes through unchanged, but they change the default media destination in the "m=" and "c=" lines and in the RTCP attribute (defined in [RFC3605]). That gets detected as an ice-mismatch, and ICE processing is aborted for the session 😭. The session can still continue if the endpoints can reach each other over the default candidate (the one sent in the "m=" and "c=" lines) 🫶.

Section 3.1.3 of [RFC7092] defines an SDP-Modifying Signaling-only B2BUA. It works only in the signaling plane and isn't in the media path, but it does modify SDP bodies, so it knows and understands SDP syntax and semantics 🎀. Such a B2BUA MUST follow the behavior in Section 3.

Section 3.2 of [RFC7092] describes three categories of B2BUAs that work on both the signaling (SIP and SDP) and media planes, depending on how involved they are in the media plane 🌈:

  • A B2BUA that acts as a simple media relay. It's basically unaware of what's being transported, and it only changes the transport header (which could be UDP/IP) of the media packets.
  • A B2BUA that does a media-aware role. It inspects and possibly modifies RTP or RTP Control Protocol (RTCP) headers, but it doesn't modify the RTP/RTCP payload.
  • A B2BUA that does a media-termination role and works at the media payload layer, like an RTP/RTCP payload (for example, a transcoder).

When B2BUAs that work on the media plane (media relay, media aware, or media termination) are involved in a session between two endpoints doing ICE, they MUST follow the behavior described in Section 4 🦋.

2. Terminology 💜

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] 📖.

All the B2BUA terminology and taxonomy used in this document is defined in [RFC7092] 🧠.

NATs are everywhere on the Internet, used by consumers and organizations alike 🏠. Specific NAT behaviors vary, but 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 🌸. That term maps to the NAT and Network Address Port Translation (NAPT) terms from [RFC3022]. It covers consumer NATs, Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888], and so on.

3. SDP-Modifying Signaling-only B2BUA 🧚

An SDP-Modifying Signaling-only B2BUA works only in the signaling plane and isn't in the media path. It does modify SDP bodies, as Section 3.1.3 of [RFC7092] describes 📝. Such B2BUAs MUST NOT change the IP address in the "c=" line, the port in the "m=" line, or the ICE semantics of SDP, because doing so can cause an ice-mismatch 🚫.

4. Media Plane B2BUAs 🌊

4.1. Overview ✨

When one or both endpoints are behind a NAT and there's a B2BUA between them, the B2BUAs MUST support ICE, or at minimum support ICE lite functionality as described in [RFC5245] 🫶. Such B2BUAs MUST use the mechanism in Section 2.2 of [RFC5245] to demultiplex STUN packets that arrive on the RTP/RTCP port 🔍.

The subsequent sections describe the behavior B2BUAs MUST follow when handling ICE messages 💅. A B2BUA can terminate ICE, which means it has two ICE contexts, one with each endpoint 👯. The reason for ICE termination could be that the B2BUA needs to be on the media path, like for address hiding for privacy, or interworking between ICE and no-ICE, and so on 🙈. A B2BUA can also be in optional ICE termination mode. In that mode it passes the candidate list and the STUN short-term credentials (ice-ufrag and ice-pwd attributes) from one endpoint to the other side, after adding its own candidates 🦋. A B2BUA can be in optional ICE termination mode when it doesn't need to be on the media path. The sections below describe the behaviors for these two cases 💖.

4.2. Mandatory ICE Termination with B2BUA 💖

okay so a B2BUA that wants to be in the media path always 💅 follows these steps:

  • When a B2BUA sends out the SDP, it MUST advertise support for ICE and MAY include B2BUA's 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 [RFC5245], then it MUST send an a=ice-lite attribute and MUST include B2BUA host candidates for each component of each media stream.
  • If the B2BUA supports full ICE, then it MAY include B2BUA's candidates of different types for each component of each media stream.
  • The B2BUA MUST generate new username and 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. The 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 [RFC5245] for ICE connectivity checks.

Here's the call flow, and it's giving main character energy 👑

       +-------+            +-------------------+             +-----+
       | Alice |            | Media Plane 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 candidate list1)|                           |
           |<------------------------|                           |
           |                         |                           |
           |--------ACK------------->|                           |
           |        (8)              |                           |
           |                         |                           |
           |<----ICE Connectivity 1->|                           |
           |      checks+conclusion  |<-----ICE Connectivity 2-->|
           |           (9)           |      checks+conclusion    |
           |                         |           (10)            |
           |                         |                           |
           |<-------Media packets--->|<----Media packets-------->|
           |           (11)          |         (12)              |
           |                         |                           |
           |<---ICE keepalives 1---->|                           |
           |          (13)           |<----ICE keepalives 2----->|
                                                (13)

              Figure 1: INVITE with SDP Having ICE and with a
                     Media Plane B2BUA Terminating ICE

So this figure shows an example call flow with two endpoints, Alice and Bob, using ICE processing, plus a B2BUA handling STUN messages from both endpoints 🧚. For the sake of brevity, the entire list of ICE SDP attributes is not shown, and neither are the STUN messages exchanged as part of the ICE connectivity checks (no cap, that's a lot of messages to draw 😭). The key steps to note from the call flow are:

  • Alice sends an INVITE with SDP having ICE candidates. 🎀
  • The B2BUA modifies the received SDP from Alice by removing the received candidate list, gathering its own candidates, and generating new username and 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 (Step 3) to Bob.
  • Bob responds (Step 5) to the INVITE with his own list of candidates.
  • The B2BUA responds to the INVITE from Alice with SDP having a B2BUA candidate list. The B2BUA generates new username and password values for ice-ufrag and ice-pwd attributes in the 200 OK response (Step 6).
  • ICE connectivity checks happen between Alice and the B2BUA in Step 9. Depending on whether the B2BUA supports ICE or ICE lite, it follows the appropriate procedures mentioned in [RFC5245]. ICE connectivity checks also happen between Bob and the B2BUA in Step 10. Steps 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 the B2BUA (Steps 11 and 12). 💜
  • STUN keepalives would be used between Alice and the B2BUA (Step 13) and between Bob and the B2BUA (Step 14) to keep NAT and firewall bindings alive. ⭐
Heads up bestie: because there are two independent ICE contexts on either side of the B2BUA, ICE checks can conclude on one side before they conclude on the other side 💀. That can leave one end with an ongoing media session while the other end is still being set up. Any such media the B2BUA receives would keep going to the other side on the default candidate address (the one that was sent in the c= line). periodt 🍓

4.3. Optional ICE Termination with B2BUA ✨

okay so this one is for a B2BUA that wants to be in the media path ONLY for NAT traversal 🦋 and doesn't otherwise need to be in the middle of the call. here's what it does, bestie:

  • 💖 when the B2BUA gets an incoming SDP with ICE semantics, it copies the received candidate list and tacks on its own candidate list in the outgoing SDP. it also copies the ufrag/password values it got in the incoming SDP into the outgoing SDP, and then sends it out 📨
  • 🌸 the B2BUA's candidates MAY have lower priority than the endpoint's candidates, so the endpoint and remote peer candidate pairs get tested FIRST before the pairs with B2BUA candidates. main character energy for the direct path 👑
  • 🫶 after offer/answer is complete, the endpoints have both the B2BUA's and the remote peer's candidates. then they use the ICE procedures from Section 8 of [RFC5245] to nominate a candidate pair for sending and receiving media 🎀
  • ✨ so the B2BUA only ends up in the media path if the ICE checks between all the candidate pairs from both endpoints FAIL. iykyk 💅
   +-------+            +-------------------+             +-----+
   | Alice |            | Media Plane B2BUA |             | Bob |
   +-------+            +-------------------+             +-----+
       |(1) INVITE               |(3)  INVITE                |
       |   a=ice-ufrag1          |     a=ice-ufrag1          |
       |   a=ice-pwd1            |     a=ice-pwd1            |
       |  (Alice's IP, port)     | (Alice'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)             |
       |  (Bob's IP,port)        |                           |
       |(B2BUA's candidate 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 Optional ICE Termination Mode

ok so this little diagram shows a sample call with two endpoints, Alice and Bob, both doing ICE, and a B2BUA handling STUN messages from both of them 🧚 the entire ICE SDP attributes aren't shown (too long, bestie 🙈) and neither are the STUN messages from the connectivity checks. the key steps to notice:

  • 🍓 Alice sends an INVITE with an SDP that has her own candidate list
  • 💜 the B2BUA passes along Alice's candidate list after adding its own. it also passes Alice's ice-ufrag and ice-pwd along to Bob in the INVITE (Step 3). in this example the B2BUA does NOT change the default candidate in the "c=" and "m=" lines, it keeps the values Alice originally sent 🌈
  • > ⚠️ tea alert: if the B2BUA DOES want to be in the media path when the ICE connectivity checks between the endpoints fail, or when one endpoint doesn't support ICE, then it overwrites its own candidate address and port as the default candidate in the "m=" and "c=" lines 💀
  • 🎀 Bob answers the INVITE (Step 5) with his own list of candidates
  • ✨ the B2BUA replies to Alice's INVITE with an SDP that has its own candidate list plus Bob's candidate list. it also passes Bob's ice-ufrag and ice-pwd (from Step 5) to Alice in the 200 OK (Step 6) 🫶
  • 🦋 ICE connectivity checks happen between Alice and Bob in Step 9. checks ALSO happen between Alice and the B2BUA, and between Bob and the B2BUA, in Steps 10 and 11. Steps 9, 10, and 11 all happen in parallel 🔥
  • 👑 in this example, Alice and Bob conclude ICE with a candidate pair that lets them send media directly 💖
  • 🌸 media flows between Alice and Bob in Step 12 🍓

4.4. STUN Handling in B2BUA with Forked Signaling 🌈

okay so forking is a thing, and it means a B2BUA might get MULTIPLE answers for one outbound INVITE 🙃 when that happens, the B2BUA SHOULD follow Sections 3.2 or 3.3 for ALL of those answers 💅

5. Security Considerations 🔐

okay bestie, this part is SERIOUS 😭 ICE uses the STUN short-term credential mechanism for authentication and message integrity, as described in Section 2.5 of [RFC5245] 🫶 STUN connectivity checks include the MESSAGE-INTEGRITY attribute, which contains an HMAC-SHA1 of the STUN message. the HMAC is computed using the key exchanged in the signaling channel. the signaling channel between the endpoints and the B2BUA MUST be encrypted so the key is NOT visible to eavesdroppers 🙈 otherwise the security benefits of short-term authentication would be totally lost 💀 so yeah, encrypt that signaling, periodt 🔥

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 🫶

okay the people who made this doc happen 💖 special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen, and Parthasarathi Ravindran for their constructive comments, suggestions, and early reviews that were critical to formulating and refining this document 👑

thanks also to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins, Sam Hartman, Stephen Farrell, Kathleen Moriarty, and Francis Dupont for their thoughtful review comments 🌸

Authors' Addresses 📮

Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India

Email: rmohanr@cisco.com

Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India

Email: tireddy@cisco.com

Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States

Email: gsalguei@cisco.com

📦 where this page comes from