STRAW                                                    R. Ravindranath
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                            G. Salgueiro
Expires: August 6, 13, 2015                                           Cisco
                                                        February 2, 9, 2015

Session Traversal Utilities for NAT (STUN) Message Handling for Session
      Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
                     draft-ietf-straw-b2bua-stun-01
                     draft-ietf-straw-b2bua-stun-02

Abstract

   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.
   The goal of this draft is to ensure that ICE used for NAT and
   Firewall traversal of multimedia sessions works when there are B2BUAs
   in place and the B2BUAs handle STUN messages properly.

Status of This Memo

   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 August 6, 13, 2015.

Copyright Notice

   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) 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Media Plane B2BUAs  . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  ICE Termination with B2BUA  . . . . . . . . . . . . . . .   5
     3.3.  ICE Passthrough with B2BUAs . . . . . . . . . . . . . . .   8
     3.4.  STUN Handling in B2BUA with Forked Signaling  . . . . . .  11
   4.  SDP-Modifying Signaling-only B2BUA  . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   In many 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 [RFC7092] and often perform functions not defined in
   Standards Track RFCs.

   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) in
   certain deployments.

   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 desirable.  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 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 [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 (defined in [RFC3605]).
   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).

   Section 3.2 of [RFC7092] 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:

   o  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.

   o  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.

   o  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 such a B2BUA operating on a media plane is involved in a call
   between two endpoints performing ICE, then it MUST follow the
   behavior described in section 3 of this specification.

   Section 3.1.3 of [RFC7092] 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 4 of this specification.

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

   The following generalized terms are defined in [RFC3261], Section 6.

      B2BUA: A SIP Back-to-Back User Agent, which is the logical
      combination of a User Agent Server (UAS) and User Agent Client
      (UAC).

      UAS: A SIP User Agent Server.

      UAC: A SIP User Agent Client.

   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.

3.  Media Plane B2BUAs

3.1.  Overview

   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.,
   address hiding for privacy, interworking between ICE to no-ICE, 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.

3.2.  ICE Termination with B2BUA

   A B2BUA that wishes to be in the media path follows the below steps:

   o  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.

   o  If the B2BUA is in ICE lite mode as described in Section 2.7 of
      [RFC5245] then it MUST send a=ice-lite attribute and MUST include
      B2BUAs host candidates for each component of each media stream.

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

   o  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.

   o  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.

   o  Depending on whether the B2BUA supports ICE lite or full ICE it
      implements the appropriate procedures mentioned in [RFC5245] for
      ICE connectivity checks.

       +-------+            +------------------+              +-----+
       | 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 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:

   o  Alice sends an INVITE with SDP having ICE candidates.

   o  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 attributes.
      The B2BUA also changes the c= line and m= line to have its default
      candidate and forwards the INVITE (3) to Bob.

   o  Bob responds (5) to the INVITE with his own list of candidates.

   o  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).

   o  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 [RFC5245].
      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.

   o  Media flows between Alice and Bob via B2BUA (Step 13, 14).

   o  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).

3.3.  ICE Passthrough with B2BUAs

   If a B2BUA does not see a need to be in the media path, it can do the
   following steps mentioned in this section.

   o  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.

   o  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.

   o  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 [RFC5245] to nominate a candidate pair for
      sending and receiving media streams.

   o  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.

       +-------+            +------------------+              +-----+
       | 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:

   o  Alice sends an INVITE with an SDP having its own candidate list.

   o  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.

   o  Bob responds (5) to the INVITE with his own list of candidates.

   o  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).

   o  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.

   o  Media flows between Alice and Bob in Step 12.

3.4.  STUN Handling in B2BUA with Forked Signaling

   Because of forking 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.

4.  SDP-Modifying Signaling-only B2BUA

   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 [RFC7092].  Such B2BUAs
   MUST ensure that they dont change C IP address in c= line, port in m=
   line and ICE semantics of SDP as doing so can cause ICE-mismatch.

5.  Security Considerations

   ICE as described in Section 2.5 of [RFC5245] 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.

   The recommendations mentioned in Appendix of [RFC5245] for ICE and
   Lite Agents also apply to a B2BUA doing ICE.

   B2BUA when handling secure traffic (SRTP/SRTCP) SHOULD follow the
   procedures mentioned in [I-D.ram-straw-b2bua-dtls-srtp] to ensure
   that Man-in-the-Middle attacks are not possible.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Acknowledgments

   Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-
   Huguenin, Simon Perreault, Lorenzo Miniero and 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.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

8.2.  Informative References

   [I-D.ram-straw-b2bua-dtls-srtp]
              R, R., Reddy, T., Salgueiro, G., Pascual, V., and P.
              Ravindran, "DTLS-SRTP Handling in Session Initiation
              Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft-
              ram-straw-b2bua-dtls-srtp-01 (work in progress), December
              2014.

   [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.

   [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
              in Session Description Protocol (SDP)", RFC 3605, October
              2003.

   [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.

Authors' Addresses

   Ram Mohan Ravindranath
   Cisco
   Cessna Business Park
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Tirumaleswar Reddy
   Cisco
   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
   US

   Email: gsalguei@cisco.com