draft-ietf-straw-b2bua-stun-06.txt   draft-ietf-straw-b2bua-stun-07.txt 
STRAW Ram. Ravindranath STRAW Ram. Ravindranath
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track G. Salgueiro Intended status: Standards Track G. Salgueiro
Expires: November 15, 2015 Cisco Expires: November 18, 2015 Cisco
May 14, 2015 May 17, 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-06 draft-ietf-straw-b2bua-stun-07
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 November 15, 2015. This Internet-Draft will expire on November 18, 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 3, line 24 skipping to change at page 3, line 24
reasons, B2BUAs are being used by SIP domains for SIP and media- reasons, B2BUAs are being used by SIP domains for SIP and media-
related purposes. These B2BUAs use proprietary mechanisms to enable related purposes. These B2BUAs use proprietary mechanisms to enable
SIP devices behind 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 SBCs implementing HNT and offers some mitigation
strategies. The most commonly used approach to solve these issues is strategies. The most commonly used approach to solve these issues is
restricted-latching defined in section 5 of [RFC7362], whereby the restricted-latching defined in section 5 of [RFC7362], whereby the
B2BUA will not latch to any packets from a source public IP address B2BUA will not latch to any packets from a source public IP address
other than the one the SIP UA uses for SIP signalling. However, this other than the one the SIP UA uses for SIP signaling. However, this
is susceptible to attacks, where an attacker who is able to see the is susceptible to attacks, where an attacker who is able to see the
source IP address of the SIP UA may generate packets using the same source IP address of the SIP UA may generate packets using the same
IP address. There are other threats described in Section 5 of IP address. There are other threats described in Section 5 of
[RFC7362] for which Secure Real-time Transport Protocol (SRTP) [RFC7362] for which Secure Real-time Transport Protocol (SRTP)
[RFC3711] can be used as a solution. However, this would require the [RFC3711] can be used as a solution. However, this would require the
B2BUAs to terminate and re-originate SRTP, which is not always B2BUAs to terminate and re-originate SRTP, which is not always
desirable. 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
skipping to change at page 5, line 49 skipping to change at page 5, line 49
Transport Protocol(RTP)/RTP Control Protocol (RTCP) port. Transport Protocol(RTP)/RTP Control Protocol (RTCP) 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 may be in optional ICE side after adding its own candidates. A B2BUA MAY 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 describes 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 the below
steps: 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
skipping to change at page 11, line 40 skipping to change at page 11, line 40
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.
4.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.
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
skipping to change at page 12, line 20 skipping to change at page 12, line 20
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, Ari Keranen and Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen and
Parthasarathi R for their constructive comments, suggestions, and Parthasarathi R for their constructive comments, suggestions, and
early reviews that were critical to the formulation and refinement of early reviews that were critical to the formulation and refinement of
this document. this document.
Thanks to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins, Thanks to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins,
Sam Hartman, Stephen Farrell and Kathleen Moriarty for their Sam Hartman, Stephen Farrell, Kathleen Moriarty and Francis Dupont
thoughtful review comments. for their thoughtful review comments.
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.
[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)",
skipping to change at page 13, line 42 skipping to change at page 13, line 42
Traversal (HNT) for Media in Real-Time Communication", RFC Traversal (HNT) for Media in Real-Time Communication", RFC
7362, September 2014. 7362, September 2014.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Cisco
Cessna Business Park Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India IN
Email: rmohanr@cisco.com Email: rmohanr@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Cisco
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
India IN
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 US
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
 End of changes. 9 change blocks. 
12 lines changed or deleted 12 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/