<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!--rfc category="info" ipr="full3978"-->
<rfc category="std" docName="draft-ram-straw-b2bua-stun-00" ipr="trust200902">
  <front>
    <title abbrev="STUN Handling in SIP B2BUAs">Session Traversal Utilities
    for NAT (STUN) Message Handling for Session Initiation Protocol (SIP)
    Back-to-Back User Agents (B2BUAs)</title>

    <author fullname="Ram Mohan Ravindranath" initials="R."
            surname="Ravindranath">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>Cessna Business Park</street>

          <street>Sarjapur-Marathahalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>rmohanr@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>

          <city>Research Triangle Park</city>

          <region>NC</region>

          <code>27709</code>

          <country>US</country>
        </postal>

        <email>gsalguei@cisco.com</email>
      </address>
    </author>

    <date year="2014" />

    <area>Real-time Applications and Infrastructre (RAI)</area>

    <workgroup>STRAW</workgroup>

    <abstract>
      <t>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.</t>

      <t>This document defines behavior for a B2BUA performing ICE
      processing.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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 <xref
      target="RFC7092"></xref>.</t>

      <t>The Session Initiation Protocol (SIP) <xref target="RFC3261"></xref>,
      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)
      <xref target="RFC4566"></xref> 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.</t>

      <t>Mechanisms such as Session Traversal Utilities for NAT (STUN) <xref
      target="RFC5389"></xref>, Traversal Using Relays around NAT (TURN) <xref
      target="RFC5766"></xref>, and Interactive Connectivity Establishment
      (ICE) <xref target="RFC5245"></xref> did not exist when protocols like
      SIP began being deployed. Some mechanisms, such as the early versions of
      STUN <xref target="RFC3489"></xref>, started appearing but they were
      unreliable and suffered a number of issues typical for UNilateral
      Self-Address Fixing (UNSAF) and described in <xref
      target="RFC3424"></xref>. 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. <xref
      target="I-D.ietf-mmusic-latching"></xref> describes how B2BUAs can
      perform Hosted NAT Traversal (HNT) to solve the NAT traversal
      problem.</t>

      <t>Section 5 of <xref target="I-D.ietf-mmusic-latching"></xref>
      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 <xref
      target="I-D.ietf-mmusic-latching"></xref> for which Secure Real-time
      Transport Protocol (SRTP) 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 <xref target="RFC5245"></xref>,
      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.</t>

      <t>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 <xref
      target="RFC5245"></xref> 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).</t>

      <t><xref target="RFC7092"></xref> describes three different categories
      of such B2BUAs, according to the level of activities performed on the
      media plane:</t>

      <t><list style="hanging">
          <t>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.</t>

          <t>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.</t>

          <t>A B2BUA that performs a media-termination role and operates at
          the media payload layer, such as RTP/RTCP payload (e.g., a
          transcoder).</t>
        </list></t>

      <t>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.</t>
    </section>

    <section anchor="sec-term" title="Terminology">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t>The following generalized terms are defined in <xref
      target="RFC3261"></xref>, Section 6.</t>

      <t><list style="hanging">
          <t>B2BUA: A SIP Back-to-Back User Agent, which is the logical
          combination of a User Agent Server (UAS) and User Agent Client
          (UAC).</t>

          <t>UAS: A SIP User Agent Server.</t>

          <t>UAC: A SIP User Agent Client.</t>
        </list></t>

      <t>All of the pertinent B2BUA terminology and taxonomy used in this
      document is based on <xref target="RFC7092"></xref>.</t>

      <t>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
      <xref target="RFC3022"></xref>, 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) <xref
      target="RFC6888"></xref>, etc.</t>
    </section>

    <section title="Media Plane B2BUAs">
      <section title="Overview">
        <t>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 <xref
        target="RFC5245"></xref>. Such B2BUAs MUST use the mechanism described
        in Section 2.2 of <xref target="RFC5245"></xref> to demultiplex STUN
        packets that arrive on the Real-time Transport Protocol(RTP)/RTP
        Control Protocol (RTCP) port.</t>

        <t>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.</t>
      </section>

      <section title="ICE Termination with B2BUA">
        <t>A B2BUA that wishes to be in the media path follows the below
        steps:</t>

        <t><list style="hanging">
            <t>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.</t>

            <t>If the B2BUA is in ICE lite mode as described in section 2.7 of
            <xref target="RFC5245"></xref> then it MUST send a=ice-lite
            attribute and MUST include B2BUAs host candidates for each
            component of each media stream.</t>

            <t>If the B2BUA supports full ICE then it MAY include B2BUAs
            candidates of different types for each component of each media
            stream.</t>

            <t>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.</t>

            <t>The B2BUA MUST NOT propagate the candidate list received in the
            incoming SDP to the outbound SDP and instead only advertise its
            candidate list. In this way the B2BUA will be always in media
            path.</t>

            <t>Depending on whether the B2BUA supports ICE lite or full ICE it
            implements the appropriate procedures mentioned in <xref
            target="RFC5245"></xref> for ICE connectivity checks.</t>
          </list></t>

        <t><figure anchor="Figure1"
            title="INVITE with SDP having ICE and with a Media Plane B2BUA">
            <artwork align="center"><![CDATA[
 +-------+            +------------------+              +-----+         
 | 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)
          ]]></artwork>
          </figure></t>

        <t>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:</t>

        <t><list style="numbers">
            <t>Alice sends an INVITE with SDP having ICE candidates.</t>

            <t>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 and
            forwards the INVITE (3) to Bob.</t>

            <t>Bobs responds (5) to the INVITE with his own list of
            candidates.</t>

            <t>B2BUA responds to the INVITE from Alice with SDP having B2BUA's
            candidate list. B2BUA generates new username, password values for
            ice-ufrag and ice-pwd attributes in the 200 OK response (6).</t>

            <t>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 <xref
            target="RFC5245"></xref>. 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 have two independent ICE contexts running.</t>

            <t>Media flows between Alice and Bob via B2BUA (Step 13, 14).</t>

            <t>STUN keepalives would be used between Alice and B2BUA (step 15)
            and between Bob and B2BUA (step 16) to keep NAT, Firewall bindings
            alive.</t>
          </list></t>

        <t>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).</t>
      </section>

      <section title="ICE Passthrough with B2BUAs ">
        <t>If a B2BUA does not see a need to be in media path, it can do the
        following steps mentioned in this section.</t>

        <t><list style="hanging">
            <t>When a B2BUA receives an incoming SDP with ICE semantics it
            copies the received candidate list, adds 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.</t>

            <t>The B2BUAs candidates will 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.</t>

            <t>After offer/answer is complete, the endpoints will have both
            the B2BUA's and remote peer candidates. It will then use ICE
            procedures described in <xref target="RFC5245"></xref> to nominate
            a candidate pair for sending and receiving media streams.</t>

            <t>With this approach the B2BUA will be in media path only if the
            ICE checks between all the candidate pairs formed from the both
            the endpoints fails.</t>
          </list></t>

        <t><figure anchor="Figure2"
            title="INVITE with SDP having ICE and with a Media Plane B2BUA in ICE Passthrough mode">
            <artwork align="center"><![CDATA[
 +-------+            +------------------+              +-----+         
 | 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)
          ]]></artwork>
          </figure></t>

        <t>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:</t>

        <t><list style="numbers">
            <t>Alice sends an INVITE with an SDP having its own candidate
            list.</t>

            <t>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.</t>

            <t>Bob responds (5) to the INVITE with his own list of
            candidates.</t>

            <t>B2BUA responds to the INVITE from Alice with an SDP having
            B2BUA's 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).</t>

            <t>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.</t>

            <t>Media flows between Alice and Bob in Step 12.</t>
          </list></t>
      </section>

      <section title="STUN Handling in B2BUA with Forked Signaling">
        <t>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.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="sec.iana-considerations" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section title="Acknowledgments">
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.5763"?>

      <?rfc include="reference.RFC.5764"?>

      <?rfc include="reference.RFC.5766"?>

      <?rfc include="reference.RFC.3711"?>

      <?rfc include="reference.RFC.5389"?>

      <?rfc include="reference.RFC.3489"?>

      <?rfc include="reference.RFC.5245"?>

      <?rfc include="reference.RFC.4086"?>

      <?rfc include="reference.RFC.3424"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.3261"?>

      <?rfc include="reference.I-D.ram-straw-b2bua-dtls-srtp"?>

      <?rfc include="reference.RFC.4566"?>

      <?rfc include="reference.RFC.7092"?>

      <?rfc include="reference.RFC.3022"?>

      <?rfc include="reference.I-D.ietf-mmusic-latching"?>

      <?rfc include="reference.RFC.6888"?>
    </references>
  </back>
</rfc>
