Session Traversal Utilities for NAT (STUN) Message Handling for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-stun-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7584.
|
|
|---|---|---|---|
| Authors | Ram R , Tirumaleswar Reddy.K , Gonzalo Salgueiro | ||
| Last updated | 2015-05-14 (Latest revision 2015-04-28) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
SECDIR Last Call review
by Sam Hartman
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Victor Pascual | ||
| Shepherd write-up | Show Last changed 2015-03-16 | ||
| IESG | IESG state | Became RFC 7584 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Ben Campbell | ||
| Send notices to | draft-ietf-straw-b2bua-stun.ad@ietf.org, draft-ietf-straw-b2bua-stun.shepherd@ietf.org, draft-ietf-straw-b2bua-stun@ietf.org, straw-chairs@ietf.org, "Victor Pascual" <victor.pascual.avila@gmail.com> | ||
| IANA | IANA review state | IANA OK - No Actions Needed |
draft-ietf-straw-b2bua-stun-05
STRAW Ram. Ravindranath
Internet-Draft T. Reddy
Intended status: Standards Track G. Salgueiro
Expires: October 30, 2015 Cisco
April 28, 2015
Session Traversal Utilities for NAT (STUN) Message Handling for Session
Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-stun-05
Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
are often designed to be on the media path, rather than just
intercepting signaling. This means that B2BUAs often act on the
media path leading to separate media legs that the B2BUA correlates
and bridges together. When acting on the media path, B2BUAs are
likely to receive Session Traversal Utilities for NAT (STUN) packets
as part of Interactive Connectivity Establishment (ICE) processing.
This document defines behavior for a B2BUA performing ICE processing.
The goal of this draft is to ensure that B2BUAs properly handle STUN
messages received as part of the ICE procedures used for NAT and
Firewall traversal of multimedia sessions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ravindranath, et al. Expires October 30, 2015 [Page 1]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5
4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 5
4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 8
4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
In many Session Initiation Protocol (SIP) deployments, SIP entities
exist in the SIP signaling and media path between the originating and
final terminating endpoints, which go beyond the definition of a
traditional SIP proxy. These SIP entities, commonly known as Back-
to-Back User Agents (B2BUAs), are described in [RFC7092] and often
perform functions not defined in Standards Track RFCs.
SIP [RFC3261], and other session control protocols that try to use
direct path for media, are typically difficult to use across Network
Address Translators (NATs). These protocols use IP addresses and
transport port numbers encoded in the signaling, such as the Session
Description Protocol (SDP) [RFC4566] and, in the case of SIP, various
header fields. Such addresses and ports are unreachable if any peers
are separated by NATs.
Mechanisms such as Session Traversal Utilities for NAT (STUN)
[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
Ravindranath, et al. Expires October 30, 2015 [Page 2]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
when protocols like SIP began being deployed. Some mechanisms, such
as the early versions of STUN, started appearing but they were
unreliable and suffered a number of issues typical for UNilateral
Self-Address Fixing (UNSAF) and described in [RFC3424]. For these
and other reasons, B2BUAs were already being used by SIP domains for
other SIP and media-related purposes began to use proprietary
mechanisms to enable SIP devices behind NATs to communicate across
the NAT.
[RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT)
in certain deployments. Section 5 of [RFC7362] describes some of the
issues with SBCs implementing HNT and offers some mitigation
strategies. The most commonly used approach to solve these issues is
"restricted-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 signaling. However, this 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 IP address. There are other
threats described in Section 5 of [RFC7362] for which Secure Real-
time Transport Protocol (SRTP) [RFC3711] can be used as a solution.
However, this would require the B2BUAs to terminate and re-originate
SRTP, which is not always desirable.
A B2BUA can use ICE [RFC5245], which provides authentication tokens
(conveyed in the ice-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 the security concerns with HNT solution.
Further, ICE has other benefits like selecting an address when more
than one address is available (e.g., dual-stack environment where
host can have both IPv4 and IPv6 addresses), verifying that a path
works before connecting 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
SIP headers and SDP bodies as part of their normal operation. Such
entities, when present on the media path, are likely to take an
active role in the session signaling depending on their level of
activity on the media path. For example, some B2BUAs modify portions
of the SDP body (e.g., IP address, port) and subsequently modify the
media packet headers as well. Section 18.6 of ICE [RFC5245] explains
two different behaviors when B2BUAs are present. Some B2BUAs are
likely to remove all the SDP ICE attributes before sending the SDP
across to the other side. Consequently, the call will appear to both
endpoints as though the other side doesn't support ICE. There are
other types of B2BUAs that pass the ICE attributes without
modification, yet modify the default destination for media contained
in the m= and c= lines and rtcp attribute (defined in [RFC3605]).
Ravindranath, et al. Expires October 30, 2015 [Page 3]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
This will be detected as an ICE mismatch and ICE processing will be
aborted for the session. The session may continue if the endpoints
are able to reach each other over the default candidate (sent in m=
and 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.
Section 3.2 of [RFC7092] describes three different categories of
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:
o A B2BUA that acts as a simple media relay effectively unaware of
anything that is transported and only modifies the transport
header (could be UDP/IP) of the media packets.
o A B2BUA that performs a media-aware role. It inspects and
potentially modifies RTP or RTP Control Protocol (RTCP) headers;
but it does not modify the payload of RTP/RTCP.
o A B2BUA that performs a media-termination role and operates at the
media payload layer, such as RTP/RTCP payload (e.g., a
transcoder).
When such a B2BUA operating on a media plane is involved in a session
between two endpoints performing ICE, then it MUST follow the
behavior described in Section 4.
2. Terminology
The key words "MUST", "Container for recipient routing tables.";
list recipient-routing-table {
key "name";
description
"List of routing tables that receive routes from this
routing table.";
leaf name {
type routing-table-state-ref;
description
"The name of the recipient routing table.";
}
leaf filter {
type route-filter-state-ref;
description
"A route filter which is applied to the routes passed
to the recipient routing table.";
}
}
}
}
}
container route-filters {
description
"Container for route filters.";
list route-filter {
key "name";
description
"Route filters are used for filtering and/or manipulating
routes that are passed between a routing protocol and a
routing table and vice versa, or between two routing
tables.
It is expected that other modules augment this list with
contents specific for a particular route filter type.
";
leaf name {
type string;
description
"The name of the route filter.";
}
leaf type {
type identityref {
Lhotka Expires January 14, 2014 [Page 34]
Internet-Draft YANG Routing Management July 2013
base route-filter;
}
mandatory "true";
description
"Type of the route-filter - an identity derived from the
'route-filter' base identity.";
}
}
}
}
/* Configuration Data */
container routing {
description
"Configuration parameters for the routing subsystem.";
list router {
key "name";
description
"Configuration of a router instance.
";
leaf name {
type string;
description
"The name of the router instance.
The names for system-created router instances are assigned
by the system. The same name then has to be used in the
configuration.
An arbitrary name may be chosen if the router instance is
created in the configuration.
";
}
leaf type {
type identityref {
base router-type;
}
default "rt:standard-router";
description
"The router type.";
}
leaf enabled {
type boolean;
default "true";
description
"Enable/disable the router instance.
Lhotka Expires January 14, 2014 [Page 35]
Internet-Draft YANG Routing Management July 2013
If this parameter is false, the parent router instance is
disabled and does not appear in operational state data,
despite any other configuration that might be present.
";
}
uses router-id {
description
"Configuration of the global router ID.";
}
leaf description {
type string;
description
"Textual description of the router instance.";
}
container default-routing-tables {
if-feature user-defined-routing-tables;
description
"Configuration of the default routing tables used by the
router instance.
The default routing table for an addressed family if by
default connected to all routing protocol instances
supporting that address family, and always receives direct
routes.
";
list default-routing-table {
must "address-family=/routing/routing-tables/"
+ "routing-table[name=current()/name]/"
+ "address-family and safi=/routing/routing-tables/"
+ "routing-table[name=current()/name]/safi" {
error-message "Address family mismatch.";
description
"The entry's address family MUST match that of the
referenced routing table.";
}
key "address-family safi";
description
"Each list entry configures the default routing table for
one address family.";
uses afn-safi;
leaf name {
type string;
mandatory "true";
description
"Name of an existing routing table to be used as the
default routing table for the given router instance
and address family.";
}
Lhotka Expires January 14, 2014 [Page 36]
Internet-Draft YANG Routing Management July 2013
}
}
container interfaces {
description
"Configuration of router interface parameters.";
list interface {
key "name";
description
"List of network layer interfaces assigned to the router
instance.";
leaf name {
type if:interface-ref;
description
"A reference to the name of a configured network layer
interface.";
}
}
}
container routing-protocols {
description
"Configuration of routing protocol instances.";
list routing-protocol {
key "name";
description
"Each entry contains configuration of a routing protocol
instance.";
leaf name {
type string;
description
"An arbitrary name of the routing protocol instance.";
}
leaf description {
type string;
description
"Textual description of the routing protocol
instance.";
}
leaf enabled {
type boolean;
default "true";
description
"Enable/disable the routing protocol instance.
If this parameter is false, the parent routing
protocol instance is disabled and does not appear in
operational state data, despite any other
configuration that might be present.
";
Lhotka Expires January 14, 2014 [Page 37]
Internet-Draft YANG Routing Management July 2013
}
leaf type {
type identityref {
base routing-protocol;
}
mandatory "true";
description
"Type of the routing protocol - an identity derived
from the 'routing-protocol' base identity.";
}
container connected-routing-tables {
if-feature user-defined-routing-tables;
description
"Configuration of connected routing tables.
";
list connected-routing-table {
must "not(/routing/routing-tables/"
+ "routing-table[name=current()/"
+ "preceding-sibling::connected-routing-table/"
+ "name and address-family=/routing/routing-tables/"
+ "routing-table[name=current()/name]/"
+ "address-family and safi=/routing/routing-tables/"
+ "routing-table[name=current()/name]/safi])" {
error-message "Duplicate address family for "
+ "connected routing tables.";
description
"For each AFN/SAFI pair there MUST NOT be more than
one connected routing table.";
}
key "name";
description
"List of routing tables to which the routing protocol
instance is connected (at most one routing table per
address family).
If no connected routing table is configured for an
address family, the routing protocol is connected to
the default routing table for that address family.
";
leaf name {
type routing-table-ref;
must "../../../type != 'rt:direct' or "
+ "../../../../../default-routing-tables/ "
+ "default-routing-table/name=." {
error-message "The 'direct' protocol can be "
+ "connected only to a default "
+ "routing table.";
description
quot;MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All of the pertinent B2BUA terminology and taxonomy used in this
document is defined in [RFC7092].
Network Address Translators (NATs) are widely used in the Internet by
consumers and organizations. Although specific NAT behaviors vary,
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
transport port number to another IPv4 or IPv6 address and transport
port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6
NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc.
Ravindranath, et al. Expires October 30, 2015 [Page 4]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
3. 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 NOT 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
B2BUA between the endpoints, the B2BUAs MUST support ICE or at a
minimum support ICE LITE functionality as described in [RFC5245].
Such B2BUAs MUST use the mechanism described in Section 2.2 of
[RFC5245] to demultiplex STUN packets that arrive on the Real-time
Transport Protocol(RTP)/RTP Control Protocol (RTCP) port.
The subsequent sections describe the behavior B2BUA's MUST follow for
handling ICE messages. A B2BUA can terminate ICE and thus have two
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.,
address hiding for privacy, interworking between ICE to no-ICE,
etc.). A B2BUA can also be in optional ICE termination mode and
passes across the candidate list and STUN short-term credentials
(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
termination mode when it does not have a need to be on the media
path. The below sections describes the behaviors for these two
cases.
4.2. Mandatory ICE Termination with B2BUA
A B2BUA that wishes to always be in the media path follows the below
steps:
o When a B2BUA sends out SDP, it MUST advertise support for ICE and
MAY include B2BUA candidates of different types for each component
of each media stream.
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
B2BUAs host candidates for each component of each media stream.
o If the B2BUA supports full ICE then it MAY include B2BUAs
candidates of different types for each component of each media
stream.
Ravindranath, et al. Expires October 30, 2015 [Page 5]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
o The B2BUA MUST generate new username, password values for ice-
ufrag and ice-pwd attributes when it sends out the SDP and MUST
NOT propagate the ufrag, password values it received in the
incoming SDP. This ensures that the short-term credentials used
for both the legs are different. The short-term credentials
include authentication tokens (conveyed in the ice-ufrag and ice-
pwd attributes), which the B2BUA can use to verify the identity of
the peer. B2BUA terminates the ICE messages on each leg and does
not propagate them.
o The B2BUA MUST NOT propagate the candidate list received in the
incoming SDP to the outbound SDP and instead only advertise its
candidate list. The B2BUA MUST also add its default candidate in
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
implements the appropriate procedures mentioned in [RFC5245] for
ICE connectivity checks.
Ravindranath, et al. Expires October 30, 2015 [Page 6]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
+-------+ +------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob |
+-------+ +------------------+ +-----+
|(1) INVITE | (3)INVITE |
| a=ice-ufrag1 | a=ice-ufrag2 |
| a=ice-pwd1 | a=ice-pwd2 |
| (Alice's IP, port) | (B2BUA's IP, port) |
|(Alice's candidate list )| (B2BUA's candidate list)|
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | (5)200 OK |
| | a=ice-ufrag3 |
| | a=ice-pwd3 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
| (6) 200 OK | |
| a=ice-ufrag4 |-----------ACK------------>|
| a=ice-pwd4 | (7) |
| B2BUA's IP,port | |
| (B2BUA's cand list1) | |
|<------------------------| |
|--------ACK------------->| |
| (8) | |
| | |
|<----ICE Connectivity 1->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (9) | checks +conclusion |
| | (10) |
|<-------Media packets -->|<----Media packets-------->|
| (13) | (14) |
| | |
|<---ICE keepalives 1---->| |
| (15) |<----ICE keep alives 2---->|
(16)
Figure 1: INVITE with SDP having ICE and with a Media Plane B2BUA
terminating ICE
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
endpoints. For the sake of brevity the entire ICE SDP attributes are
not shown. Also the STUN messages exchanged as part of ICE
Ravindranath, et al. Expires October 30, 2015 [Page 7]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
connectivity checks are not shown. Key steps to note from the call
flow are:
o Alice sends an INVITE with SDP having ICE candidates.
o B2BUA modifies the received SDP from Alice by removing the
received candidate list, gathers its own candidates, generates new
username, password values for ice-ufrag and ice-pwd attributes.
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 B2BUA responds to the INVITE from Alice with SDP having B2BUA's
candidate list. B2BUA generates new username, password values for
ice-ufrag and ice-pwd attributes in the 200 OK response (6).
o ICE Connectivity checks happen between Alice and the B2BUA in step
9. Depending on whether the B2BUA supports ICE or ICE lite it
will follow the appropriate procedures mentioned in [RFC5245].
ICE Connectivity checks also happen between Bob and the B2BUA in
step 10. Step 9 and 10 happen in parallel. The B2BUA always
terminates the ICE messages on each leg and have two independent
ICE contexts running.
o Media flows between Alice and Bob via B2BUA (Step 13, 14).
o STUN keepalives would be used between Alice and B2BUA (step 15)
and between Bob and B2BUA (step 16) to keep NAT and Firewall
bindings alive.
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
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
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).
4.3. Optional ICE Termination with B2BUA
If a B2BUA is willing to be in the media path if needed for NAT
traversal, but does not otherwise require it can do the following
steps mentioned in this section.
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 outgoing SDP. The B2BUA also copies the ufrag/password values
Ravindranath, et al. Expires October 30, 2015 [Page 8]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
it received in the incoming SDP to the outgoing SDP and then sends
out the SDP.
o The B2BUAs candidates MAY have lower-priority than the candidates
provided by the endpoint, this way endpoint and remote peer
candidate pairs are tested first before trying candidate pairs
with B2BUA candidates.
o After offer/answer is complete, the endpoints will have both the
B2BUA's and remote peer candidates. It will then use ICE
procedures described in Section 8 of [RFC5245] to nominate a
candidate pair for sending and receiving media streams.
o With this approach the B2BUA will be in the media path only if the
ICE checks between all the candidate pairs formed from both the
endpoints fail.
Ravindranath, et al. Expires October 30, 2015 [Page 9]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
+-------+ +------------------+ +-----+
| Alice | | Mediaplane B2BUA | | Bob |
+-------+ +------------------+ +-----+
|(1) INVITE | (3)INVITE |
| a=ice-ufrag1 | a=ice-ufrag1 |
| a=ice-pwd1 | a=ice-pwd1 |
| (Alice's IP, port) | (Alices's IP, port) |
|(Alice's candidate list )| (Alice's Candidate list + |
| B2BUA's candidate list1)|
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | (5)200 OK |
| | a=ice-ufrag2 |
| | a=ice-pwd2 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
| (6) 200 OK | |
| a=ice-ufrag2 |-----------ACK------------>|
| a=ice-pwd2 | (7) |
| (Bobs's IP,port) | |
| (B2BUA's cand list2 + | |
| Bob's Candidate list) | |
|<------------------------| |
|----------ACK----------->| |
| (8) | |
| | |
|<----ICE Connectivity 1 (9)------------------------->|
| | |
|<----ICE Connectivity 2->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (10) | checks +conclusion |
| | (11) |
|<-------------------Media packets------------------->|
| (12) |
| | |
|<------------------ICE keepalives------------------->|
(13)
Figure 2: INVITE with SDP having ICE and with a Media Plane B2BUA in
optional ICE termination mode
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
Ravindranath, et al. Expires October 30, 2015 [Page 10]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
Lhotka Expires January 14, 2014 [Page 38]
Internet-Draft YANG Routing Management July 2013
"For the 'direct' pseudo-protocol, the connected
routing table must always be a default routing
table.";
}
description
"Name of an existing routing table.";
}
leaf import-filter {
type route-filter-ref;
description
"Configuration of import filter.";
}
leaf export-filter {
type route-filter-ref;
description
"Configuration of export filter.";
}
}
}
container static-routes {
when "../type='rt:static'" {
description
"This container is only valid for the 'static'
routing protocol.";
}
description
"Configuration of the 'static' pseudo-protocol.
Address family specific modules augment this node with
their lists of routes.
";
}
}
}
}
container routing-tables {
description
"Configured routing tables.";
list routing-table {
key "name";
description
"Each entry represents a configured routing table
identified by the 'name' key.
Entries having the same key as a system-provided entry of
the list /routing-state/routing-tables/routing-tables are
used for configuring parameters of that entry. Other
entries define additional user-provided routing tables.
Lhotka Expires January 14, 2014 [Page 39]
Internet-Draft YANG Routing Management July 2013
";
leaf name {
type string;
description
"The name of the routing table.";
}
uses afn-safi;
leaf description {
type string;
description
"Textual description of the routing table.";
}
container recipient-routing-tables {
if-feature user-defined-routing-tables;
description
"Configuration of recipient routing tables.";
list recipient-routing-table {
must "name != ../../name" {
error-message "Source and recipient routing tables "
+ "are identical.";
description
"A routing table MUST NOT appear among its recipient
routing tables.";
}
must "/routing/routing-tables/"
+ "routing-table[name=current()/name]/"
+ "address-family=../../address-family and /routing/"
+ "routing-tables/routing-table[name=current()/name]/"
+ "safi=../../safi" {
error-message "Address family mismatch.";
description
"Address family of the recipient routing table MUST
match the source table.";
}
key "name";
description
"Each entry configures a recipient routing table.";
leaf name {
type routing-table-ref;
description
"The name of the recipient routing table.";
}
leaf filter {
type route-filter-ref;
description
"A route filter which is applied to the routes passed
to the recipient routing table.";
}
Lhotka Expires January 14, 2014 [Page 40]
Internet-Draft YANG Routing Management July 2013
}
}
}
}
container route-filters {
description
"Configuration of route filters.";
list route-filter {
key "name";
description
"Each entry configures a named route filter.";
leaf name {
type string;
description
"The name of the route filter.";
}
leaf description {
type string;
description
"Textual description of the route filter.";
}
leaf type {
type identityref {
base route-filter;
}
mandatory "true";
description
"Type of the route filter..";
}
}
}
}
}
<CODE ENDS>
Lhotka Expires January 14, 2014 [Page 41]
Internet-Draft YANG Routing Management July 2013
7. IPv4 Unicast Routing YANG Module
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number and all occurrences of the revision date below with
the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2013-07-13.yang"
module ietf-ipv4-unicast-routing {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";
prefix "v4ur";
import ietf-routing {
prefix "rt";
}
import ietf-inet-types {
prefix "inet";
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens
<mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>
";
description
"This YANG module augments the 'ietf-routing' module with basic
configuration and operational state data for IPv4 unicast
routing.
Copyright (c) 2013 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
Lhotka Expires January 14, 2014 [Page 42]
Internet-Draft YANG Routing Management July 2013
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.
";
revision 2013-07-13 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for Routing Management";
}
/* Groupings */
grouping route-content {
description
"Parameters of IPv4 unicast routes.";
leaf dest-prefix {
type inet:ipv4-prefix;
description
"IPv4 destination prefix.";
}
leaf next-hop {
type inet:ipv4-address;
description
"IPv4 address of the next hop.";
}
}
/* RPC Methods */
augment "/rt:active-route/rt:input/rt:destination-address" {
when "rt:address-family='ipv4' and rt:safi='nlri-unicast'" {
description
"This augment is valid only for IPv4 unicast.";
}
description
"The 'address' leaf augments the 'rt:destination-address'
parameter of the 'rt:active-route' operation.";
leaf address {
type inet:ipv4-address;
description
"IPv4 destination address.";
Lhotka Expires January 14, 2014 [Page 43]
endpoints. For the sake of brevity the entire ICE SDP attributes are
not shown. Also the STUN messages exchanged as part of ICE
connectivity checks are not shown. Key steps to note from the call
flow are:
o Alice sends an INVITE with an SDP having its own candidate list.
o B2BUA propagates the received candidate list in incoming SDP from
Alice after adding its own candidate list. The B2BUA also
propagates the received ice-ufrag, ice-password attributes from
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 B2BUA responds to the INVITE from Alice with an SDP having B2BUA's
candidate list and the candidate list received from Bob. The
B2BUA would also propagate the received ice-ufrag, ice-password
attributes from Bob in step (5) to Alice in the 200 OK response
(6).
o ICE Connectivity checks happen between Alice and Bob in step 9.
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
in parallel. In this example Alice and Bob conclude ICE with a
candidate pair that enables them to send media directly.
o Media flows between Alice and Bob in Step 12.
4.4. STUN Handling in B2BUA with Forked Signaling
Because of forking, a B2BUA may receive multiple answers for a single
outbound INVITE. When this occurs the B2BUA should follow section
3.2 or 3.3 for all of those received answers.
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
Ravindranath, et al. Expires October 30, 2015 [Page 11]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
visible to eavesdropper otherwise the security benefits of short-term
authentication would be lost.
6. IANA Considerations
This document makes no request of IANA.
7. Acknowledgments
Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-
Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen and
Parthasarathi R for their constructive comments, suggestions, and
early reviews that were critical to the formulation and refinement of
this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013.
8.2. Informative References
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
Ravindranath, et al. Expires October 30, 2015 [Page 12]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 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
Description Protocol", RFC 4566, July 2006.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", RFC
7362, September 2014.
Authors' Addresses
Ram Mohan Ravindranath
Cisco
Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: rmohanr@cisco.com
Tirumaleswar Reddy
Cisco
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Ravindranath, et al. Expires October 30, 2015 [Page 13]
Internet-Draft STUN Handling in SIP B2BUAs April 2015
Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: gsalguei@cisco.com
Ravindranath, et al. Expires October 30, 2015 [Page 14]