draft-ietf-straw-b2bua-stun-02.txt   draft-ietf-straw-b2bua-stun-03.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: August 13, 2015 Cisco Expires: September 5, 2015 Cisco
February 9, 2015 March 4, 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-02 draft-ietf-straw-b2bua-stun-03
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.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 13, 2015. This Internet-Draft will expire on September 5, 2015.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5 3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
3.2. ICE Termination with B2BUA . . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. ICE Passthrough with B2BUAs . . . . . . . . . . . . . . . 8 4.2. ICE Termination with B2BUA . . . . . . . . . . . . . . . 6
3.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11 4.3. ICE Passthrough with B2BUAs . . . . . . . . . . . . . . . 8
4. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 11 4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In many SIP deployments, SIP entities exist in the SIP signaling and In many SIP deployments, SIP entities exist in the SIP signaling and
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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 rtcp attribute (defined in [RFC3605]).
This will be detected as an ICE mismatch and ICE processing is This will be detected as an ICE mismatch and ICE processing is
aborted for the call. The call may continue if the endpoints are 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 able to reach each other over the default candidate (sent in m= and
c= lines). c= lines).
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 3 of this specification.
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 operates on both signaling(SIP and SDP) and media plane
according to the level of involvement and active participation in the according to the level of involvement and active participation in the
media plane: 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 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.
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 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 MUST follow the between two endpoints performing ICE, then it MUST follow the
behavior described in section 3 of this specification. behavior described in section 4 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 20
document is based on [RFC7092]. document is based on [RFC7092].
Network Address Translators (NATs) are widely used in the Internet by Network Address Translators (NATs) are widely used in the Internet by
consumers and organizations. Although specific NAT behaviors vary, consumers and organizations. Although specific NAT behaviors vary,
this document uses the term "NAT", which maps to NAT and NAPT terms 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 from [RFC3022], for devices that map any IPv4 or IPv6 address and
transport port number to another IPv4 or IPv6 address and transport transport port number to another IPv4 or IPv6 address and transport
port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6
NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc. NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc.
3. Media Plane B2BUAs 3. SDP-Modifying Signaling-only B2BUA
3.1. Overview 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 don't change IP address in c= line, port in m=
line and ICE semantics of SDP as doing so can cause ICE-mismatch.
4. Media Plane B2BUAs
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 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.,
address hiding for privacy, interworking between ICE to no-ICE, etc.) address hiding for privacy, interworking between ICE to no-ICE,
A B2BUA can also be in ICE passthrough mode and passes across the etc.). A B2BUA can also be in ICE passthrough mode and passes across
candidate list from one endpoint to the other side. A B2BUA may be the candidate list and STUN short-term credentials (ice-ufrag and
in ICE passthrough mode when it does not have a need to be on the ice-pwd attributes 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 media path. The below sections describes the behaviors for these two
cases. cases.
3.2. ICE Termination with B2BUA 4.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:
o 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.
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 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.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
and between Bob and B2BUA (step 16) to keep NAT and 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 4.3. ICE Passthrough with B2BUAs
If a B2BUA does not see a need to be in the 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.
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 copies
the received candidate list and appends its own candidate list in the received candidate list and appends its own candidate list in
the outgoing SDP. The B2BUA also copies the ufrag/password values the outgoing SDP. The B2BUA also copies the ufrag/password values
it 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.
skipping to change at page 11, line 38 skipping to change at page 11, line 38
(6). (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 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.
o 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 4.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. 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 IP address in c= line, port in m=
line and ICE semantics of SDP as doing so can cause ICE-mismatch.
5. Security Considerations 5. Security Considerations
ICE as described in Section 2.5 of [RFC5245] uses STUN short-term ICE as described in Section 2.5 of [RFC5245] uses STUN short-term
credential mechanism for authentication and message integrity. STUN credential mechanism for authentication and message integrity. STUN
connectivity checks include MESSAGE-INTEGRITY attribute that contains connectivity checks include MESSAGE-INTEGRITY attribute that contains
HMAC-SHA1 of the STUN message and the HMAC is computed using the key HMAC-SHA1 of the STUN message and the HMAC is computed using the key
exchanged in the signaling channel. The signaling channel between exchanged in the signaling channel. The signaling channel between
the endpoints and B2BUA MUST be encrypted so that the key is not the endpoints and B2BUA MUST be encrypted so that the key is not
visible to eavesdropper otherwise the security benefits of short-term visible to eavesdropper otherwise the security benefits of short-term
authentication would be lost. authentication would be lost.
skipping to change at page 13, line 28 skipping to change at page 13, line 19
[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.
8.2. Informative References 8.2. Informative References
[I-D.ram-straw-b2bua-dtls-srtp] [I-D.ram-straw-b2bua-dtls-srtp]
R, R., Reddy, T., Salgueiro, G., Pascual, V., and P. R, R., Reddy, T., Salgueiro, G., Pascual, V., and P.
Ravindran, "DTLS-SRTP Handling in Session Initiation Ravindran, "DTLS-SRTP Handling in Session Initiation
Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft- Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft-
ram-straw-b2bua-dtls-srtp-01 (work in progress), December ram-straw-b2bua-dtls-srtp-02 (work in progress), February
2014. 2015.
[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.
 End of changes. 14 change blocks. 
37 lines changed or deleted 38 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/