draft-ietf-straw-b2bua-stun-08.txt   rfc7584.txt 
STRAW Ram. Ravindranath Internet Engineering Task Force (IETF) R. Ravindranath
Internet-Draft T. Reddy Request for Comments: 7584 T. Reddy
Intended status: Standards Track G. Salgueiro Category: Standards Track G. Salgueiro
Expires: November 19, 2015 Cisco ISSN: 2070-1721 Cisco
May 18, 2015 July 2015
Session Traversal Utilities for NAT (STUN) Message Handling for Session Session Traversal Utilities for NAT (STUN) Message Handling
Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) for SIP Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-stun-08
Abstract Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
are often designed to be on the media path, rather than just are often designed to be on the media path rather than just
intercepting signaling. This means that B2BUAs often act on the intercepting signaling. This means that B2BUAs often act on the
media path leading to separate media legs that the B2BUA correlates media path leading to separate media legs that the B2BUA correlates
and bridges together. When acting on the media path, B2BUAs are and bridges together. When acting on the media path, B2BUAs are
likely to receive Session Traversal Utilities for NAT (STUN) packets likely to receive Session Traversal Utilities for NAT (STUN) packets
as part of Interactive Connectivity Establishment (ICE) processing. as part of Interactive Connectivity Establishment (ICE) processing.
This document defines behavior for a B2BUA performing ICE processing. This document defines behavior for a B2BUA performing ICE processing.
The goal of this draft is to ensure that B2BUAs properly handles SIP The goal of this document is to ensure that B2BUAs properly handle
messages that carry ICE semantics in Session Description SIP messages that carry ICE semantics in Session Description Protocol
Protocol(SDP) and STUN messages received as part of the ICE (SDP) and STUN messages received as part of the ICE procedures for
procedures for NAT and Firewall traversal of multimedia sessions. NAT and Firewall traversal of multimedia sessions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 19, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7584.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5 3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5
4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5 4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 6 4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 6
4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 8 4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 9
4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11 4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In many Session Initiation Protocol (SIP) deployments, SIP entities In many SIP deployments, SIP entities exist in the SIP signaling and
exist in the SIP signaling and media path between the originating and media path between the originating and final terminating endpoints,
final terminating endpoints, which go beyond the definition of a which go beyond the definition of a traditional SIP proxy. These SIP
traditional SIP proxy. These SIP entities, commonly known as Back- entities, commonly known as B2BUAs, are described in [RFC7092] and
to-Back User Agents (B2BUAs), are described in [RFC7092] and often often perform functions not defined in Standards Track RFCs.
perform functions not defined in Standards Track RFCs.
SIP [RFC3261], and other session control protocols that try to use SIP [RFC3261] and other session control protocols that try to use a
direct path for media, are typically difficult to use across Network direct path for media are typically difficult to use across Network
Address Translators (NATs). These protocols use IP addresses and Address Translators (NATs). These protocols use IP addresses and
transport port numbers encoded in the signaling, such as the Session transport port numbers encoded in the signaling, such as SDP
Description Protocol (SDP) [RFC4566] and, in the case of SIP, various [RFC4566] and, in the case of SIP, various header fields. Such
header fields. Such addresses and ports are unreachable if any peers addresses and ports are unreachable if any peers are separated by
are separated by NATs. NATs.
Mechanisms such as Session Traversal Utilities for NAT (STUN) Mechanisms such as STUN [RFC5389], Traversal Using Relays around NAT
[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and (TURN) [RFC5766], and ICE [RFC5245] did not exist when protocols like
Interactive Connectivity Establishment (ICE) [RFC5245] did not exist SIP began to be deployed. Some mechanisms, such as the early
when protocols like SIP began being deployed. Some mechanisms, such versions of STUN, started appearing, but they were unreliable and
as the early versions of STUN, started appearing but they were suffered a number of issues typical for UNilateral Self-Address
unreliable and suffered a number of issues typical for UNilateral Fixing (UNSAF) as described in [RFC3424]. For these reasons, B2BUAs
Self-Address Fixing (UNSAF) and described in [RFC3424]. For these are being used by SIP domains for SIP and media-related purposes.
reasons, B2BUAs are being used by SIP domains for SIP and media- These B2BUAs use proprietary mechanisms to enable SIP devices behind
related purposes. These B2BUAs use proprietary mechanisms to enable NATs to communicate across the NAT.
SIP devices behind NATs to communicate across the NAT.
[RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT) [RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT)
in certain deployments. Section 5 of [RFC7362] describes some of the in certain deployments. Section 5 of [RFC7362] describes some of the
issues with SBCs implementing HNT and offers some mitigation issues with Session Border Controllers (SBCs) implementing HNT and
strategies. The most commonly used approach to solve these issues is offers some mitigation strategies. The most commonly used approach
restricted-latching defined in section 5 of [RFC7362], whereby the to solve these issues is "restricted-latching", defined in Section 5
B2BUA will not latch to any packets from a source public IP address of [RFC7362], whereby the B2BUA will not latch to any packets from a
other than the one the SIP UA uses for SIP signaling. However, this source public IP address other than the one the SIP User Agent (UA)
is susceptible to attacks, where an attacker who is able to see the uses for SIP signaling. However, this is susceptible to attacks
source IP address of the SIP UA may generate packets using the same where an attacker who is able to see the source IP address of the SIP
IP address. There are other threats described in Section 5 of UA may generate packets using the same IP address. There are other
[RFC7362] for which Secure Real-time Transport Protocol (SRTP) threats described in Section 5 of [RFC7362] for which Secure Real-
[RFC3711] can be used as a solution. However, this would require the time Transport Protocol (SRTP) [RFC3711] can be used as a solution.
B2BUAs to terminate and re-originate SRTP, which is not always However, this would require the B2BUAs to terminate and reoriginate
desirable. SRTP, which is not always desirable.
This document describes proper behavior of B2BUAs performing ICE This document describes proper behavior of B2BUAs performing ICE
processing. This includes defining consistent handling of SIP processing. This includes defining consistent handling of SIP
messages carrying ICE semantics in SDP and STUN messages received as messages carrying ICE semantics in SDP and STUN messages received as
part of the ICE procedures performed on the media path for NAT and part of the ICE procedures performed on the media path for NAT and
Firewall traversal of multimedia sessions. Firewall traversal of multimedia sessions.
A B2BUA can use ICE [RFC5245], which provides authentication tokens A B2BUA can use ICE [RFC5245], which provides authentication tokens
(conveyed in the ice-ufrag and ice-pwd attributes) that allow the (conveyed in the ice-ufrag and ice-pwd attributes) that allow the
identity of a peer to be confirmed before engaging in media exchange. identity of a peer to be confirmed before engaging in media exchange.
This can solve some of the security concerns with HNT solution. This can solve some of the security concerns with HNT solution.
Further, ICE has other benefits like selecting an address when more Further, ICE has other benefits like selecting an address when more
than one address is available (e.g., dual-stack environment where than one address is available (e.g., a dual-stack environment where
host can have both IPv4 and IPv6 addresses), verifying that a path the host can have both IPv4 and IPv6 addresses), verifying that a
works before connecting the call etc. For these reasons endpoints path works before connecting the call, etc. For these reasons,
often use ICE to pick a candidate pair for media traffic between two endpoints often use ICE to pick a candidate pair for media traffic
agents. between two agents.
B2BUAs often operate on the media path and have the ability to modify 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 SIP headers and SDP bodies as part of their normal operation. Such
entities, when present on the media path, are likely to take an entities, when present on the media path, are likely to take an
active role in the session signaling depending on their level of active role in the session signaling depending on their level of
activity on the media path. For example, some B2BUAs modify portions activity on the media path. For example, some B2BUAs modify portions
of the SDP body (e.g., IP address, port) and subsequently modify the 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 media packet headers as well. Section 18.6 of ICE [RFC5245] explains
two different behaviors when B2BUAs are present. Some B2BUAs are two different behaviors when B2BUAs are present. Some B2BUAs are
likely to remove all the SDP ICE attributes before sending the SDP likely to remove all the SDP ICE attributes before sending the SDP
across to the other side. Consequently, the call will appear to both across to the other side. Consequently, the call will appear to both
endpoints as though the other side doesn't support ICE. There are endpoints as though the other side doesn't support ICE. There are
other types of B2BUAs that pass the ICE attributes without other types of B2BUAs that pass the ICE attributes without
modification, yet modify the default destination for media contained modification, yet modify the default destination for media contained
in the m= and c= lines and rtcp attribute (defined in [RFC3605]). in the "m=" and "c=" lines and the RTCP attribute (defined in
This will be detected as an ICE mismatch and ICE processing will be [RFC3605]). This will be detected as an ice-mismatch, and ICE
aborted for the session. The session may continue if the endpoints processing will be aborted for the session. The session may continue
are able to reach each other over the default candidate (sent in m= if the endpoints are able to reach each other over the default
and c= lines). candidate (sent in "m=" and "c=" lines).
Section 3.1.3 of [RFC7092] defines a SDP-Modifying Signaling-only 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 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 media path, but it does modify SDP bodies and is thus aware of and
understands SDP syntax and semantics. Such B2BUA MUST follow the understands SDP syntax and semantics. Such B2BUA MUST follow the
behavior mentioned in Section 3. behavior mentioned in Section 3.
Section 3.2 of [RFC7092] describes three different categories of Section 3.2 of [RFC7092] describes three different categories of
B2BUAs that operates on both signaling(SIP and SDP) and media plane B2BUAs that operate on both the signaling (SIP and SDP) and media
according to the level of involvement and active participation in the planes according to the level of involvement and active participation
media plane: in the media plane:
o A B2BUA that acts as a simple media relay effectively unaware of o A B2BUA that acts as a simple media relay. It is effectively
anything that is transported and only modifies the transport unaware of anything that is transported and only modifies the
header (could be UDP/IP) of the media packets. transport header (could be UDP/IP) of the media packets.
o A B2BUA that performs a media-aware role. It inspects and o A B2BUA that performs a media-aware role. It inspects and
potentially modifies RTP or RTP Control Protocol (RTCP) headers; potentially modifies RTP or RTP Control Protocol (RTCP) headers;
but it does not modify the payload of RTP/RTCP. but it does not modify the payload of RTP/RTCP.
o A B2BUA that performs a media-termination role and operates at the o A B2BUA that performs a media-termination role and operates at the
media payload layer, such as RTP/RTCP payload (e.g., a media payload layer, such as RTP/RTCP payload (e.g., a
transcoder). transcoder).
When B2BUAs that operate on media plane (media relay, media-aware or When B2BUAs that operate on the media plane (media relay, media
media-termination) is involved in a session between two endpoints aware, or media termination) are involved in a session between two
performing ICE, then it MUST follow the behavior described in endpoints performing ICE, then it MUST follow the behavior described
Section 4. in Section 4.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
All of the pertinent B2BUA terminology and taxonomy used in this All of the pertinent B2BUA terminology and taxonomy used in this
document is defined in [RFC7092]. document is defined in [RFC7092].
Network Address Translators (NATs) are widely used in the Internet by NATs are widely used in the Internet by consumers and organizations.
consumers and organizations. Although specific NAT behaviors vary, Although specific NAT behaviors vary, this document uses the term
this document uses the term "NAT", which maps to NAT and NAPT terms "NAT", which maps to NAT and Network Address Port Translation (NAPT)
from [RFC3022], for devices that map any IPv4 or IPv6 address and terms from [RFC3022], for devices that map any IPv4 or IPv6 address
transport port number to another IPv4 or IPv6 address and transport and transport port number to another IPv4 or IPv6 address and
port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 transport port number. This includes consumer NATs, Firewall-NATs,
NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc. IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc.
3. SDP-Modifying Signaling-only B2BUA 3. SDP-Modifying Signaling-only B2BUA
An SDP-Modifying Signaling-only B2BUA is one that operates in the 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 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 SDP bodies as described in Section 3.1.3 of [RFC7092]. Such B2BUAs
MUST NOT change IP address in c= line, port in m= line and ICE MUST NOT change the IP address in the "c=" line, the port in the "m="
semantics of SDP as doing so can cause ICE-mismatch. line, and the ICE semantics of SDP, as doing so can cause an ice-
mismatch.
4. Media Plane B2BUAs 4. Media Plane B2BUAs
4.1. Overview 4.1. Overview
When one or both of the endpoints are behind a NAT, and there is a 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 B2BUA between the endpoints, the B2BUAs MUST support ICE or at a
minimum support ICE LITE functionality as described in [RFC5245]. minimum support ICE lite functionality as described in [RFC5245].
Such B2BUAs MUST use the mechanism described in Section 2.2 of Such B2BUAs MUST use the mechanism described in Section 2.2 of
[RFC5245] to demultiplex STUN packets that arrive on the Real-time [RFC5245] to demultiplex STUN packets that arrive on the RTP/RTCP
Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. port.
The subsequent sections describe the behavior B2BUAs MUST follow for The subsequent sections describe the behavior B2BUAs MUST follow for
handling ICE messages. A B2BUA can terminate ICE and thus have two handling ICE messages. A B2BUA can terminate ICE and thus have two
ICE contexts with either endpoint. The reason for ICE termination 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., 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, address hiding for privacy, interworking between ICE to no-ICE,
etc.). A B2BUA can also be in optional ICE termination mode and etc.). A B2BUA can also be in optional ICE termination mode and
passes across the candidate list and STUN short-term credentials passes across the candidate list and STUN short-term credentials
(ice-ufrag and ice-pwd attributes) from one endpoint to the other (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 side after adding its own candidates. A B2BUA can be in optional ICE
termination mode when it does not have a need to be on the media termination mode when it does not have a need to be on the media
path. The below sections describes the behaviors for these two path. The below sections describe the behaviors for these two cases.
cases.
4.2. Mandatory ICE Termination with B2BUA 4.2. Mandatory ICE Termination with B2BUA
A B2BUA that wishes to always be in the media path follows the below A B2BUA that wishes to always be in the media path follows these
steps: steps:
o When a B2BUA sends out SDP, it MUST advertise support for ICE and o When a B2BUA sends out the SDP, it MUST advertise support for ICE
MAY include B2BUA candidates of different types for each component and MAY include B2BUA's candidates of different types for each
of each media stream. component of each media stream.
o If the B2BUA is in ICE lite mode as described in Section 2.7 of 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 [RFC5245], then it MUST send an a=ice-lite attribute and MUST
B2BUAs host candidates for each component of each media stream. include B2BUA host candidates for each component of each media
stream.
o If the B2BUA supports full ICE then it MAY include B2BUAs o If the B2BUA supports full ICE, then it MAY include B2BUA's
candidates of different types for each component of each media candidates of different types for each component of each media
stream. stream.
o The B2BUA MUST generate new username, password values for ice- o The B2BUA MUST generate new username and password values for ice-
ufrag and ice-pwd attributes when it sends out the SDP and MUST ufrag and ice-pwd attributes when it sends out the SDP and MUST
NOT propagate the ufrag, password values it received in the NOT propagate the ufrag password values it received in the
incoming SDP. This ensures that the short-term credentials used incoming SDP. This ensures that the short-term credentials used
for both the legs are different. The short-term credentials for both the legs are different. The short-term credentials
include authentication tokens (conveyed in the ice-ufrag and ice- include authentication tokens (conveyed in the ice-ufrag and ice-
pwd attributes), which the B2BUA can use to verify the identity of pwd attributes), which the B2BUA can use to verify the identity of
the peer. B2BUA terminates the ICE messages on each leg and does the peer. The B2BUA terminates the ICE messages on each leg and
not propagate them. does not propagate them.
o The B2BUA MUST NOT propagate the candidate list received in the o The B2BUA MUST NOT propagate the candidate list received in the
incoming SDP to the outbound SDP and instead only advertise its incoming SDP to the outbound SDP and instead only advertise its
candidate list. The B2BUA MUST also add its default candidate in candidate list. The B2BUA MUST also add its default candidate in
the c= line (IP address) and m= line (port). In this way the the "c=" line (IP address) and "m=" line (port). In this way, the
B2BUA will be always in the media path. B2BUA will be always in the media path.
o Depending on whether the B2BUA supports ICE lite or full ICE it o Depending on whether the B2BUA supports ICE lite or full ICE, it
implements the appropriate procedures mentioned in [RFC5245] for implements the appropriate procedures mentioned in [RFC5245] for
ICE connectivity checks. ICE connectivity checks.
+-------+ +------------------+ +-----+ +-------+ +-------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob | | Alice | | Media Plane B2BUA | | Bob |
+-------+ +------------------+ +-----+ +-------+ +-------------------+ +-----+
|(1) INVITE | (3)INVITE | |(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag2 | | a=ice-ufrag1 | a=ice-ufrag2 |
| a=ice-pwd1 | a=ice-pwd2 | | a=ice-pwd1 | a=ice-pwd2 |
| (Alice's IP, port) | (B2BUAs IP, port) | | (Alice's IP, port) | (B2BUA's IP, port) |
|(Alice's candidate list )| (B2BUAs candidate list) | | (Alice's candidate list)| (B2BUA's candidate list)|
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| | | | | |
| (2) 100 trying | | |(2) 100 trying | |
|<------------------------| | |<------------------------| |
| | (4) 100 trying | | |(4) 100 trying |
| |<--------------------------| | |<--------------------------|
| | (5)200 OK | | | |
| | a=ice-ufrag3 | | |(5) 200 OK |
| | a=ice-ufrag3 |
| | a=ice-pwd3 | | | a=ice-pwd3 |
| | (Bob's IP, port) | | | (Bob's IP, port) |
| | (Bob's candidate list) | | | (Bob's candidate list) |
| |<--------------------------| | |<--------------------------|
| (6) 200 OK | | |(6) 200 OK | |
| a=ice-ufrag4 |-----------ACK------------>| | a=ice-ufrag4 |-----------ACK------------>|
| a=ice-pwd4 | (7) | | a=ice-pwd4 | (7) |
| B2BUAs IP,port | | | (B2BUA's IP, port) | |
| (B2BUAs cand list1) | | |(B2BUA's candidate list1)| |
|<------------------------| | |<------------------------| |
| | |
|--------ACK------------->| | |--------ACK------------->| |
| (8) | | | (8) | |
| | | | | |
|<----ICE Connectivity 1->| | |<----ICE Connectivity 1->| |
| checks+conclusion |<-----ICE Connectivity 2-->| | checks+conclusion |<-----ICE Connectivity 2-->|
| (9) | checks +conclusion | | (9) | checks+conclusion |
| | (10) | | | (10) |
|<-------Media packets -->|<----Media packets-------->| | | |
| (13) | (14) | |<-------Media packets--->|<----Media packets-------->|
| (11) | (12) |
| | | | | |
|<---ICE keepalives 1---->| | |<---ICE keepalives 1---->| |
| (15) |<----ICE keep alives 2---->| | (13) |<----ICE keepalives 2----->|
(16) (13)
Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA Figure 1: INVITE with SDP Having ICE and with a
terminating ICE Media Plane B2BUA Terminating ICE
The above figure shows an example call flow with two endpoints Alice 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 and Bob, using ICE processing, and a B2BUA handing STUN messages from
endpoints. For the sake of brevity the entire ICE SDP attributes are both the endpoints. For the sake of brevity, the entire list of ICE
not shown. Also the STUN messages exchanged as part of ICE SDP attributes are not shown. Also, the STUN messages exchanged as
connectivity checks are not shown. Key steps to note from the call part of ICE connectivity checks are not shown. Key steps to note
flow are: from the call flow are:
o Alice sends an INVITE with SDP having ICE candidates. o Alice sends an INVITE with SDP having ICE candidates.
o B2BUA modifies the received SDP from Alice by removing the o The B2BUA modifies the received SDP from Alice by removing the
received candidate list, gathers its own candidates, generates new received candidate list, gathering its own candidates, and
username, password values for ice-ufrag and ice-pwd attributes. generating new username and password values for ice-ufrag and ice-
The B2BUA also changes the c= line and m= line to have its default pwd attributes. The B2BUA also changes the "c=" line and "m="
candidate and forwards the INVITE (3) to Bob. line to have its default candidate and forwards the INVITE (Step
3) to Bob.
o Bob responds (5) to the INVITE with his own list of candidates. o Bob responds (Step 5) to the INVITE with his own list of
candidates.
o B2BUA responds to the INVITE from Alice with SDP having B2BUAs o The B2BUA responds to the INVITE from Alice with SDP having a
candidate list. B2BUA generates new username, password values for B2BUA candidate list. The B2BUA generates new username and
ice-ufrag and ice-pwd attributes in the 200 OK response (6). password values for ice-ufrag and ice-pwd attributes in the 200 OK
response (Step 6).
o ICE Connectivity checks happen between Alice and the B2BUA in step o ICE Connectivity checks happen between Alice and the B2BUA in Step
9. Depending on whether the B2BUA supports ICE or ICE lite it 9. Depending on whether the B2BUA supports ICE or ICE lite, it
will follow the appropriate procedures mentioned in [RFC5245]. will follow the appropriate procedures mentioned in [RFC5245].
ICE Connectivity checks also happen between Bob and the B2BUA in ICE Connectivity checks also happen between Bob and the B2BUA in
step 10. Step 9 and 10 happen in parallel. The B2BUA always Step 10. Steps 9 and 10 happen in parallel. The B2BUA always
terminates the ICE messages on each leg and has two independent terminates the ICE messages on each leg and has two independent
ICE contexts running. ICE contexts running.
o Media flows between Alice and Bob via B2BUA (Step 13, 14). o Media flows between Alice and Bob via B2BUA (Steps 11 and 12).
o STUN keepalives would be used between Alice and B2BUA (step 15) o STUN keepalives would be used between Alice and B2BUA (Step 13)
and between Bob and B2BUA (step 16) to keep NAT and Firewall and between Bob and B2BUA (Step 14) to keep NAT and Firewall
bindings alive. bindings alive.
Since there are two independent ICE contexts on either side of the 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 B2BUA, it is possible that ICE checks will conclude on one side
concluding on the other side. This could result in an ongoing media before concluding on the other side. This could result in an ongoing
session for one end, while the other is still being set up. Any such media session for one end while the other is still being set up. Any
media received by the B2BUA would continue to be sent to the other such media received by the B2BUA would continue to be sent to the
side on the default candidate address (that was sent in c= line). other side on the default candidate address (that was sent in "c="
line).
4.3. Optional ICE Termination with B2BUA 4.3. Optional ICE Termination with B2BUA
A B2BUA willing to be in the media path only for NAT traversal, but 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 that does not otherwise require to be in the media path, can do the
following steps mentioned in this section. following steps mentioned in this section.
o When a B2BUA receives an incoming SDP with ICE semantics it copies o When a B2BUA receives an incoming SDP with ICE semantics, it
the received candidate list and appends its own candidate list in copies the received candidate list and appends its own candidate
the outgoing SDP. The B2BUA also copies the ufrag/password values list in the outgoing SDP. The B2BUA also copies the ufrag/
it received in the incoming SDP to the outgoing SDP and then sends password values it received in the incoming SDP to the outgoing
out the SDP. SDP and then sends out the SDP.
o The B2BUAs candidates MAY have lower-priority than the candidates o The B2BUA's candidates MAY have lower priority than the candidates
provided by the endpoint, this way endpoint and remote peer provided by the endpoint, this way the endpoint and remote peer
candidate pairs are tested first before trying candidate pairs candidate pairs are tested first before trying candidate pairs
with B2BUA candidates. with B2BUA's candidates.
o After offer/answer is complete, the endpoints will have both the o After offer/answer is complete, the endpoints will have both the
B2BUAs and remote peer candidates. It will then use ICE B2BUAs and remote peer candidates. It will then use ICE
procedures described in Section 8 of [RFC5245] to nominate a procedures described in Section 8 of [RFC5245] to nominate a
candidate pair for sending and receiving media streams. candidate pair for sending and receiving media streams.
o With this approach the B2BUA will be in the media path only if the o With this approach, the B2BUA will be in the media path only if
ICE checks between all the candidate pairs formed from both the the ICE checks between all the candidate pairs formed from both
endpoints fail. the endpoints fail.
+-------+ +------------------+ +-----+ +-------+ +-------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob | | Alice | | Media Plane B2BUA | | Bob |
+-------+ +------------------+ +-----+ +-------+ +-------------------+ +-----+
|(1) INVITE | (3)INVITE | |(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag1 | | a=ice-ufrag1 | a=ice-ufrag1 |
| a=ice-pwd1 | a=ice-pwd1 | | a=ice-pwd1 | a=ice-pwd1 |
| (Alice's IP, port) | (Alices's IP, port) | | (Alice's IP, port) | (Alice's IP, port) |
|(Alice's candidate list )| (Alice's Candidate list + | |(Alice's candidate list) | (Alice's candidate list + |
| | B2BUAs candidate list1) | | | B2BUA's candidate list1) |
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| | | | | |
| (2) 100 trying | | |(2) 100 trying | |
|<------------------------| | |<------------------------| |
| | (4) 100 trying | | |(4) 100 trying |
| |<--------------------------| | |<--------------------------|
| | (5)200 OK | | | |
| | a=ice-ufrag2 | | |(5) 200 OK |
| | a=ice-ufrag2 |
| | a=ice-pwd2 | | | a=ice-pwd2 |
| | (Bob's IP, port) | | | (Bob's IP, port) |
| | (Bob's candidate list) | | | (Bob's candidate list) |
| |<--------------------------| | |<--------------------------|
| (6) 200 OK | | |(6) 200 OK | |
| a=ice-ufrag2 |-----------ACK------------>| | a=ice-ufrag2 |-----------ACK------------>|
| a=ice-pwd2 | (7) | | a=ice-pwd2 | (7) |
| (Bobs's IP,port) | | | (Bob's IP,port) | |
| (B2BUAs cand list2 + | | |(B2BUA's candidate list2 | |
| Bob's Candidate list) | | | + Bob's candidate list) | |
|<------------------------| | |<------------------------| |
| | |
|----------ACK----------->| | |----------ACK----------->| |
| (8) | | | (8) | |
| | | | | |
|<----ICE Connectivity 1 (9)------------------------->| |<----ICE Connectivity 1 (9)------------------------->|
| | | | | |
|<----ICE Connectivity 2->| | |<----ICE Connectivity 2->| |
| checks+conclusion |<-----ICE Connectivity 2-->| | checks+conclusion |<-----ICE Connectivity 2-->|
| (10) | checks +conclusion | | (10) | checks+conclusion |
| | (11) | | | (11) |
| | |
|<-------------------Media packets------------------->| |<-------------------Media packets------------------->|
| (12) | | (12) |
| | | | | |
|<------------------ICE keepalives------------------->| |<------------------ICE keepalives------------------->|
(13) (13)
Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in Figure 2: INVITE with SDP Having ICE and with a
optional ICE termination mode Media Plane B2BUA in Optional ICE Termination Mode
The above figure shows a sample call flow with two endpoints Alice 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 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 endpoints. For the sake of brevity, the entire ICE SDP attributes
not shown. Also the STUN messages exchanged as part of ICE are not shown. Also, the STUN messages exchanged as part of the ICE
connectivity checks are not shown. Key steps to note from the call connectivity checks are not shown. Key steps to note from the call
flow are: flow are:
o Alice sends an INVITE with an SDP having its own candidate list. o Alice sends an INVITE with an SDP having its own candidate list.
o B2BUA propagates the received candidate list in incoming SDP from o The B2BUA propagates the received candidate list in incoming SDP
Alice after adding its own candidate list. The B2BUA also from Alice after adding its own candidate list. The B2BUA also
propagates the received ice-ufrag, ice-password attributes from propagates the received ice-ufrag and ice-pwd attributes from
Alice in the INVITE (3) to Bob. In this example, the B2BUA does Alice in the INVITE (Step 3) to Bob. In this example, the B2BUA
not modify the default candidate sent in the c= line and m= line does not modify the default candidate sent in the "c=" line and
and retains the values sent originally from Alice. If B2BUA wants "m=" line and retains the values sent originally from Alice. If
to be in the media path when ICE connectivity checks between B2BUA wants to be in the media path when ICE connectivity checks
endpoints fails or one of the endpoints does not support ICE, then between endpoints fails or one of the endpoints does not support
it overwrites its candidate address and port as a default ICE, then it overwrites its candidate address and port as a
candidate in the m= and c= lines. default candidate in the "m=" and "c=" lines.
o Bob responds (5) to the INVITE with his own list of candidates. o Bob responds (Step 5) to the INVITE with his own list of
candidates.
o B2BUA responds to the INVITE from Alice with an SDP having B2BUAs o The B2BUA responds to the INVITE from Alice with an SDP having a
candidate list and the candidate list received from Bob. The B2BUA's candidate list and the candidate list received from Bob.
B2BUA would also propagate the received ice-ufrag, ice-password The B2BUA would also propagate the received ice-ufrag and ice-pwd
attributes from Bob in step (5) to Alice in the 200 OK response attributes from Bob in (Step 5) to Alice in the 200 OK response
(6). (Step 6).
o ICE Connectivity checks happen between Alice and Bob in step 9. o ICE Connectivity checks happen between Alice and Bob in (Step 9).
ICE Connectivity checks also happens between Alice and B2BUA and ICE Connectivity checks also happen between Alice and the B2BUA
Bob and B2BUA as shown in step 10, 11. Step 9, 10 and 11 happen and Bob and the B2BUA as shown in Steps 10 and 11. Steps 9, 10,
in parallel. In this example Alice and Bob conclude ICE with a and 11 happen in parallel. In this example, Alice and Bob
candidate pair that enables them to send media directly. conclude ICE with a candidate pair that enables them to send media
directly.
o Media flows between Alice and Bob in Step 12. o Media flows between Alice and Bob in Step 12.
4.4. STUN Handling in B2BUA with Forked Signaling 4.4. STUN Handling in B2BUA with Forked Signaling
Because of forking, a B2BUA might receive multiple answers for a Because of forking, a B2BUA might receive multiple answers for a
single outbound INVITE. When this occurs the B2BUA SHOULD follow single outbound INVITE. When this occurs, the B2BUA SHOULD follow
section 3.2 or 3.3 for all of those received answers. Sections 3.2 or 3.3 for all of those received answers.
5. Security Considerations 5. Security Considerations
ICE as described in Section 2.5 of [RFC5245] uses STUN short-term As described in Section 2.5 of [RFC5245], ICE uses the STUN short-
credential mechanism for authentication and message integrity. STUN term credential mechanism for authentication and message integrity.
connectivity checks include MESSAGE-INTEGRITY attribute that contains STUN connectivity checks include the MESSAGE-INTEGRITY attribute that
HMAC-SHA1 of the STUN message and the HMAC is computed using the key contains HMAC-SHA1 of the STUN message, and the Hashed Message
exchanged in the signaling channel. The signaling channel between Authentication Code (HMAC) is computed using the key exchanged in the
the endpoints and B2BUA MUST be encrypted so that the key is not signaling channel. The signaling channel between the endpoints and
visible to eavesdropper otherwise the security benefits of short-term B2BUA MUST be encrypted so that the key is not visible to
eavesdroppers, otherwise the security benefits of short-term
authentication would be lost. authentication would be lost.
6. IANA Considerations 6. References
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, 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.
8. References
8.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", RFC Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013. 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>.
8.2. Informative References 6.2. Informative References
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022,
2001. DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
Self-Address Fixing (UNSAF) Across Network Address UNilateral Self-Address Fixing (UNSAF) Across Network
Translation", RFC 3424, November 2002. Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605,
2003. DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
and H. Ashida, "Common Requirements for Carrier-Grade NATs A., and H. Ashida, "Common Requirements for Carrier-Grade
(CGNs)", BCP 127, RFC 6888, April 2013. NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", RFC Traversal (HNT) for Media in Real-Time Communication", RFC
7362, September 2014. 7362, DOI 10.17487/RFC7362, September 2014,
<http://www.rfc-editor.org/info/rfc7362>.
Acknowledgements
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 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.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Cisco Systems, Inc.
Cessna Business Park Cessna Business Park, Varthur Hobli
Sarjapur-Marathahalli Outer Ring Road Sarjapur Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
IN India
Email: rmohanr@cisco.com Email: rmohanr@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
IN India
Email: tireddy@cisco.com Email: tireddy@cisco.com
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US United States
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
 End of changes. 101 change blocks. 
282 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/