draft-ietf-straw-b2bua-stun-01.txt   draft-ietf-straw-b2bua-stun-02.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 6, 2015 Cisco Expires: August 13, 2015 Cisco
February 2, 2015 February 9, 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-01 draft-ietf-straw-b2bua-stun-02
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 6, 2015. This Internet-Draft will expire on August 13, 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 11 4. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
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 5, line 35 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.,
address hiding for privacy, etc.) A B2BUA can also be in ICE address hiding for privacy, interworking between ICE to no-ICE, etc.)
passthrough mode and passes across the candidate list from one A B2BUA can also be in ICE passthrough mode and passes across the
endpoint to the other side. A B2BUA may be in ICE passthrough mode candidate list from one endpoint to the other side. A B2BUA may be
when it does not have a need to be on the media path. The below in ICE passthrough mode when it does not have a need to be on the
sections describes the behaviors for these two cases. media path. The below sections describes the behaviors for these two
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:
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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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.
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. In this way the B2BUA will be always in the media candidate list. The B2BUA MUST also add its default candidate in
path. the c= line (IP address) and m= line (port). In this way the
B2BUA will be always in the media path.
o Depending on whether the B2BUA supports ICE lite or full ICE it 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 |
skipping to change at page 7, line 47 skipping to change at page 7, line 47
| | (10) | | | (10) |
|<-------Media packets -->|<----Media packets-------->| |<-------Media packets -->|<----Media packets-------->|
| (13) | (14) | | (13) | (14) |
| | | | | |
|<---ICE keepalives 1---->| | |<---ICE keepalives 1---->| |
| (15) |<----ICE keep alives 2---->| | (15) |<----ICE keep alives 2---->|
(16) (16)
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 an example 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:
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 B2BUA modifies the received SDP from Alice by removing the
received candidate list, gathers its own candidates, generates new received candidate list, gathers its own candidates, generates new
username, password values for ice-ufrag and ice-pwd attributes and username, password values for ice-ufrag and ice-pwd attributes.
forwards the INVITE (3) to Bob. The B2BUA also changes the c= line and m= line to have its default
candidate and forwards the INVITE (3) to Bob.
o Bob responds (5) to the INVITE with his own list of candidates. o Bob responds (5) to the INVITE with his own list of candidates.
o B2BUA responds to the INVITE from Alice with SDP having B2BUA's o B2BUA responds to the INVITE from Alice with SDP having B2BUA's
candidate list. B2BUA generates new username, password values for candidate list. B2BUA generates new username, password values 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).
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].
skipping to change at page 11, line 14 skipping to change at page 11, line 14
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:
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 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. In this example, the B2BUA does
not modify the default candidate sent in the c= line and m= line
and retains the values sent originally from Alice. If B2BUA wants
to be in the media path when ICE connectivity checks between
endpoints fails or one of the endpoints does not support ICE, then
it overwrites its candidate address and port as a default
candidate in the m= and c= lines.
o Bob responds (5) to the INVITE with his own list of candidates. o Bob responds (5) to the INVITE with his own list of candidates.
o B2BUA responds to the INVITE from Alice with an SDP having B2BUA's o B2BUA responds to the INVITE from Alice with an SDP having B2BUA's
candidate list and the candidate list received from Bob. The candidate list and the candidate list received from Bob. The
B2BUA would also propagate the received ice-ufrag, ice-password B2BUA would also propagate the received ice-ufrag, ice-password
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). (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 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. SDP-Modifying Signaling-only B2BUA 4. 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 ensure that they dont change C line and ICE semantics of SDP as MUST ensure that they dont change IP address in c= line, port in m=
doing so can cause ICE-mismatch. 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
skipping to change at page 12, line 23 skipping to change at page 12, line 30
procedures mentioned in [I-D.ram-straw-b2bua-dtls-srtp] to ensure procedures mentioned in [I-D.ram-straw-b2bua-dtls-srtp] to ensure
that Man-in-the-Middle attacks are not possible. that Man-in-the-Middle attacks are not possible.
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
7. 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, Lorenzo Miniero and Ari Keranen for their Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen and
constructive comments, suggestions, and early reviews that were Parthasarathi R for their constructive comments, suggestions, and
critical to the formulation and refinement of this document. early reviews that were critical to the formulation and refinement of
this document.
8. References 8. References
8.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
 End of changes. 12 change blocks. 
22 lines changed or deleted 32 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/