draft-ietf-straw-b2bua-stun-00.txt   draft-ietf-straw-b2bua-stun-01.txt 
STRAW R. Ravindranath STRAW R. Ravindranath
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track G. Salgueiro Intended status: Standards Track G. Salgueiro
Expires: April 3, 2015 Cisco Expires: August 6, 2015 Cisco
September 30, 2014 February 2, 2015
Session Traversal Utilities for NAT (STUN) Message Handling for Session Session Traversal Utilities for NAT (STUN) Message Handling for Session
Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-stun-00 draft-ietf-straw-b2bua-stun-01
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.
It is critical that B2BUAs handle these STUN messages properly. It is critical that B2BUAs handle these STUN messages properly.
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 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 3, 2015. This Internet-Draft will expire on August 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 21 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5 3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ICE Termination with B2BUA . . . . . . . . . . . . . . . 5 3.2. ICE Termination with B2BUA . . . . . . . . . . . . . . . 5
3.3. ICE Passthrough with B2BUAs . . . . . . . . . . . . . . . 8 3.3. ICE Passthrough with B2BUAs . . . . . . . . . . . . . . . 8
3.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11 3.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In many SIP deployments, SIP entities exist in the SIP signaling path In many SIP deployments, SIP entities exist in the SIP signaling and
between the originating and final terminating endpoints, which go media path between the originating and final terminating endpoints,
beyond the definition of a SIP proxy, performing functions not which go beyond the definition of a traditional SIP proxy. These SIP
defined in Standards Track RFCs. These SIP entities, commonly known entities, commonly known as Back-to-Back User Agents (B2BUAs), are
as Back-to-Back User Agents (B2BUAs) are described in [RFC7092]. described in [RFC7092] and often perform functions not defined in
Standards Track RFCs.
The Session Initiation Protocol (SIP) [RFC3261], and other session The Session Initiation Protocol (SIP) [RFC3261], and other session
control protocols that try to use direct path for media, are control protocols that try to use direct path for media, are
typically difficult to use across Network Address Translators (NATs). typically difficult to use across Network Address Translators (NATs).
These protocols use IP addresses and transport port numbers encoded These protocols use IP addresses and transport port numbers encoded
in the signaling, such as the Session Description Protocol (SDP) in the signaling, such as the Session Description Protocol (SDP)
[RFC4566] and, in the case of SIP, various header fields. Such [RFC4566] and, in the case of SIP, various header fields. Such
addresses and ports are unreachable unless all peers in a session are addresses and ports are unreachable unless all peers in a session are
located behind the same NAT. located behind the same NAT.
skipping to change at page 3, line 9 skipping to change at page 3, line 18
[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
Interactive Connectivity Establishment (ICE) [RFC5245] did not exist Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
when protocols like SIP began being deployed. Some mechanisms, such when protocols like SIP began being deployed. Some mechanisms, such
as the early versions of STUN [RFC3489], started appearing but they as the early versions of STUN [RFC3489], started appearing but they
were unreliable and suffered a number of issues typical for were unreliable and suffered a number of issues typical for
UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424].
For these and other reasons, Session Border Controllers (SBCs) that For these and other reasons, Session Border Controllers (SBCs) that
were already being used by SIP domains for other SIP and media- were already being used by SIP domains for other SIP and media-
related purposes began to use proprietary mechanisms to enable SIP related purposes began to use proprietary mechanisms to enable SIP
devices behind NATs to communicate across the NAT. [RFC7362] devices behind NATs to communicate across the NAT. [RFC7362]
describes how B2BUAs can perform Hosted NAT Traversal (HNT) to solve describes how B2BUAs can perform Hosted NAT Traversal (HNT) in
the NAT traversal problem. certain deployments.
Section 5 of [RFC7362] describes some of the issues with SBCs Section 5 of [RFC7362] describes some of the issues with SBCs
implementing HNT and offers some mitigation strategies. The most implementing HNT and offers some mitigation strategies. The most
commonly used approach to solve these issues is "restricted- commonly used approach to solve these issues is "restricted-
latching", whereby the B2BUA will not latch to any packets from a 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 source public IP address other than the one the SIP UA uses for SIP
signaling. However, this is susceptible to attacks, where an signaling. However, this is susceptible to attacks, where an
attacker who is able to see the source IP address of the SIP UA may 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 generate packets using the same IP address. There are other threats
described in Section 5 of [RFC7362] for which Secure Real-time described in Section 5 of [RFC7362] for which Secure Real-time
Transport Protocol (SRTP) [RFC3711] can be used as a solution. Transport Protocol (SRTP) [RFC3711] can be used as a solution.
However, this would require the B2BUAs to be terminating/re- However, this would require the B2BUAs to be terminating/re-
originating SRTP, which is not always possible. A B2BUA can use ICE originating SRTP, which is not always desirable. A B2BUA can use ICE
[RFC5245], which provides authentication tokens (conveyed in the ice- [RFC5245], which provides authentication tokens (conveyed in the ice-
ufrag and ice-pwd attributes) that allow the identity of a peer to be 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 confirmed before engaging in media exchange. This can solve some of
the security concerns with HNT solution. Further, ICE has other the security concerns with HNT solution. Further, ICE has other
benefits like selecting an address when more than one address is benefits like selecting an address when more than one address is
available (e.g. dual-stack), verifying that a path works before available (e.g., dual-stack environment where host can have both IPv4
connecting the call etc. For these reasons endpoints often use ICE and IPv6 addresses), verifying that a path works before connecting
to pick a candidate pair for media traffic between two agents. 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 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. There are other types of B2BUAs that media packet headers as well. Section 18.6 of ICE [RFC5245] explains
modify the media payload (e.g., a media transcoder). Section 18.6 of two different behaviors when B2BUAs are present. Some B2BUAs are
ICE [RFC5245] explains two different behaviors when B2BUAs are likely to remove all the SDP ICE attributes before sending the SDP
present. Some B2BUAs are likely to remove all the SDP ICE attributes across to the other side. Consequently, the call will appear to both
before sending the SDP across to the other side. Consequently, the endpoints as though the other side doesn't support ICE. There are
call will appear to both endpoints as though the other side doesn't other types of B2BUAs that pass the ICE attributes without
support ICE. There are other types of B2BUAs that pass the ICE modification, yet modify the default destination for media contained
attributes without modification, yet modify the default destination in the m= and c= lines and rtcp attribute (defined in [RFC3605]).
for media (contained in the m= and c= lines and rtcp attribute) This This will be detected as an ICE mismatch and ICE processing is
will be detected as an ICE mismatch and ICE processing is aborted for aborted for the call. The call may continue if the endpoints are
the call. The call may continue if the endpoints are able to reach able to reach each other over the default candidate (sent in m= and
each other over the default candidate (sent in m= and c= lines). c= lines).
[RFC7092] describes three different categories of such B2BUAs, Section 3.2 of [RFC7092] describes three different categories of
according to the level of activities performed on the media plane: B2BUAs that operates on both signaling(SIP and SDP) and media plane
according to the level of involvement and active participation in the
media plane:
A B2BUA that acts as a simple media relay effectively unaware of o A B2BUA that acts as a simple media relay effectively unaware of
anything that is transported and only modifies the transport anything that is transported and only modifies the transport
header (could be UDP/IP) of the media packets. header (could be UDP/IP) of the media packets.
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.
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 such a B2BUA operating on a media plane is involved in a call When such a B2BUA operating on a media plane is involved in a call
between two endpoints performing ICE, then it SHOULD follow the between two endpoints performing ICE, then it MUST follow the
behavior described in this specification. 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 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].
The following generalized terms are defined in [RFC3261], Section 6. The following generalized terms are defined in [RFC3261], Section 6.
B2BUA: A SIP Back-to-Back User Agent, which is the logical B2BUA: A SIP Back-to-Back User Agent, which is the logical
skipping to change at page 5, line 20 skipping to change at page 5, line 35
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 Real-time
Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. Transport Protocol(RTP)/RTP Control Protocol (RTCP) port.
The subsequent sections describe the behavior B2BUA's MUST follow for The subsequent sections describe the behavior B2BUA's 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.,
media transcoding, media recording, address hiding etc.) A B2BUA can address hiding for privacy, etc.) A B2BUA can also be in ICE
also be in ICE passthrough mode and passes across the candidate list passthrough mode and passes across the candidate list from one
from one endpoint to the other side. A B2BUA may be in ICE endpoint to the other side. A B2BUA may be in ICE passthrough mode
passthrough mode when it does not have a need to be on the media when it does not have a need to be on the media path. The below
path. The below sections describes the behaviors for these two sections describes the behaviors for these two cases.
cases.
3.2. ICE Termination with B2BUA 3.2. ICE Termination with B2BUA
A B2BUA that wishes to be in the media path follows the below steps: A B2BUA that wishes to be in the media path follows the below steps:
When a B2BUA sends out SDP, it MUST advertise support for ICE and o When a B2BUA sends out SDP, it MUST advertise support for ICE and
MAY include B2BUA candidates of different types for each component MAY include B2BUA candidates of different types for each component
of each media stream. of each media stream.
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 a=ice-lite attribute and MUST include
B2BUAs host candidates for each component of each media stream. B2BUAs host candidates for each component of each media stream.
If the B2BUA supports full ICE then it MAY include B2BUAs o If the B2BUA supports full ICE then it MAY include B2BUAs
candidates of different types for each component of each media candidates of different types for each component of each media
stream. stream.
The B2BUA MUST generate new username, password values for ice- o The B2BUA MUST generate new username, 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. B2BUA terminates the ICE messages on each leg and does
not propagate them. not propagate them.
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. In this way the B2BUA will be always in media candidate list. In this way the B2BUA will be always in the media
path. path.
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 | | Mediaplane 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) | (B2BUA's IP, port) | | (Alice's IP, port) | (B2BUA's IP, port) |
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA
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 are
not shown. Also the STUN messages exchanged as part of ICE not shown. Also the STUN messages exchanged as part of 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:
1. Alice sends an INVITE with SDP having ICE candidates. o Alice sends an INVITE with SDP having ICE candidates.
2. B2BUA modifies the received SDP from Alice by removing the o B2BUA modifies the received SDP from Alice by removing the
received candidate list, gathers its own candidates, generates received candidate list, gathers its own candidates, generates new
new username, password values for ice-ufrag and ice-pwd username, password values for ice-ufrag and ice-pwd attributes and
attributes and forwards the INVITE (3) to Bob. forwards the INVITE (3) to Bob.
3. Bobs responds (5) to the INVITE with his own list of candidates. o Bob responds (5) to the INVITE with his own list of candidates.
4. B2BUA responds to the INVITE from Alice with SDP having B2BUA's o B2BUA responds to the INVITE from Alice with SDP having B2BUA's
candidate list. B2BUA generates new username, password values candidate list. B2BUA generates new username, password values for
for ice-ufrag and ice-pwd attributes in the 200 OK response (6). ice-ufrag and ice-pwd attributes in the 200 OK response (6).
5. ICE Connectivity checks happen between Alice and the B2BUA in o ICE Connectivity checks happen between Alice and the B2BUA in step
step 9. Depending on whether the B2BUA supports ICE or ICE lite 9. Depending on whether the B2BUA supports ICE or ICE lite it
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. Step 9 and 10 happen in parallel. The B2BUA always
terminates the ICE messages on each leg and have two independent terminates the ICE messages on each leg and have two independent
ICE contexts running. ICE contexts running.
6. Media flows between Alice and Bob via B2BUA (Step 13, 14). o Media flows between Alice and Bob via B2BUA (Step 13, 14).
7. STUN keepalives would be used between Alice and B2BUA (step 15) o STUN keepalives would be used between Alice and B2BUA (step 15)
and between Bob and B2BUA (step 16) to keep NAT, Firewall and between Bob and B2BUA (step 16) 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 before
concluding on the other side. This could result in an ongoing media 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 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 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). side on the default candidate address (that was sent in c= line).
3.3. ICE Passthrough with B2BUAs 3.3. ICE Passthrough with B2BUAs
If a B2BUA does not see a need to be in media path, it can do the If a B2BUA does not see a need to be in the media path, it can do the
following steps mentioned in this section. following steps mentioned in this section.
When a B2BUA receives an incoming SDP with ICE semantics it copies o When a B2BUA receives an incoming SDP with ICE semantics it copies
the received candidate list, adds its own candidate list in the the received candidate list and appends its own candidate list in
outgoing SDP. The B2BUA also copies the ufrag/password values it the outgoing SDP. The B2BUA also copies the ufrag/password values
received in the incoming SDP to the outgoing SDP and then sends it received in the incoming SDP to the outgoing SDP and then sends
out the SDP. out the SDP.
The B2BUAs candidates will have lower-priority than the candidates o The B2BUAs candidates MAY have lower-priority than the candidates
provided by the endpoint, this way endpoint and remote peer provided by the endpoint, this way 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 candidates.
After offer/answer is complete, the endpoints will have both the o After offer/answer is complete, the endpoints will have both the
B2BUA's and remote peer candidates. It will then use ICE B2BUA's and remote peer candidates. It will then use ICE
procedures described in [RFC5245] to nominate a candidate pair for procedures described in [RFC5245] to nominate a candidate pair for
sending and receiving media streams. sending and receiving media streams.
With this approach the B2BUA will be in media path only if the ICE o With this approach the B2BUA will be in the media path only if the
checks between all the candidate pairs formed from the both the ICE checks between all the candidate pairs formed from both the
endpoints fails. endpoints fail.
+-------+ +------------------+ +-----+ +-------+ +------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob | | Alice | | Mediaplane 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) | (Alices's IP, port) |
|(Alice's candidate list )| (Alice's Candidate list + | |(Alice's candidate list )| (Alice's Candidate list + |
| B2BUA's candidate list1)| | B2BUA's candidate list1)|
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in
ICE Passthrough mode ICE Passthrough 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 are
not shown. Also the STUN messages exchanged as part of ICE not shown. Also the STUN messages exchanged as part of 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:
1. 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.
2. B2BUA propagates the received candidate list in incoming SDP from o B2BUA propagates the received candidate list in incoming SDP from
Alice after adding its own candidate list. The B2BUA also Alice after adding its own candidate list. The B2BUA also
propagates the received ice-ufrag, ice-password attributes from propagates the received ice-ufrag, ice-password attributes from
Alice in the INVITE (3) to Bob. Alice in the INVITE (3) to Bob.
3. Bob responds (5) to the INVITE with his own list of candidates. o Bob responds (5) to the INVITE with his own list of candidates.
4. B2BUA responds to the INVITE from Alice with an SDP having o B2BUA responds to the INVITE from Alice with an SDP having B2BUA's
B2BUA's candidate list and the candidate list received from Bob. candidate list and the candidate list received from Bob. The
The B2BUA would also propagate the received ice-ufrag, ice- B2BUA would also propagate the received ice-ufrag, ice-password
password attributes from Bob in step (5) to Alice in the 200 OK attributes from Bob in step (5) to Alice in the 200 OK response
response (6). (6).
5. 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 happens between Alice and B2BUA and
Bob and B2BUA as shown in step 10, 11. Step 9, 10 and 11 happen 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 in parallel. In this example Alice and Bob conclude ICE with a
candidate pair that enables them to send media directly. candidate pair that enables them to send media directly.
6. Media flows between Alice and Bob in Step 12. o Media flows between Alice and Bob in Step 12.
3.4. STUN Handling in B2BUA with Forked Signaling 3.4. STUN Handling in B2BUA with Forked Signaling
Because of forking a B2BUA may receive multiple answers for a single Because of forking a B2BUA may receive multiple answers for a single
outbound INVITE. When this occurs the B2BUA should follow section outbound INVITE. When this occurs the B2BUA should follow section
3.2 or 3.3 for all of those received answers. 3.2 or 3.3 for all of those received answers.
4. Security Considerations 4. SDP-Modifying Signaling-only B2BUA
TBD 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 line and ICE semantics of SDP as
doing so can cause ICE-mismatch.
5. IANA Considerations 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. This document makes no request of IANA.
6. Acknowledgments 7. Acknowledgments
Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit- Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-
Huguenin, Simon Perreault and Lorenzo Miniero for their constructive Huguenin, Simon Perreault, Lorenzo Miniero and Ari Keranen for their
comments, suggestions, and early reviews that were critical to the constructive comments, suggestions, and early reviews that were
formulation and refinement of this document. critical to the formulation and refinement of this document.
7. References 8. References
7.1. Normative References 8.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, March 1997.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
skipping to change at page 12, line 38 skipping to change at page 13, line 13
2010. 2010.
[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. October 2008.
[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, April 2010.
7.2. Informative References 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 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022, January
2001. 2001.
[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. 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 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013. (CGNs)", BCP 127, RFC 6888, April 2013.
[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, December 2013.
 End of changes. 51 change blocks. 
112 lines changed or deleted 158 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/