draft-ietf-speermint-requirements-06.txt   draft-ietf-speermint-requirements-07.txt 
SPEERMINT Working Group J-F. Mule SPEERMINT Working Group J-F. Mule
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Informational July 14, 2008 Intended status: Informational October 17, 2008
Expires: January 15, 2009 Expires: April 20, 2009
SPEERMINT Requirements for SIP-based Session Peering SPEERMINT Requirements for SIP-based Session Peering
draft-ietf-speermint-requirements-06.txt draft-ietf-speermint-requirements-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on April 20, 2009.
Abstract Abstract
This memo captures protocol requirements to enable session peering of This memo captures protocol requirements to enable session peering of
voice, presence, instant messaging and other types of multimedia voice, presence, instant messaging and other types of multimedia
traffic. It is based on the use cases that have been described in traffic. It is based on the use cases that have been described in
the speermint working group. This informational document is intended the SPEERMINT working group. This informational document is intended
to link the session peering use cases to protocol solutions. to link the session peering use cases to protocol solutions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Requirements . . . . . . . . . . . . . . . . . . . . . 5 3. General Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Border Elements . . . . . . . . . . . . . . . . . . . . . 5 3.2. Border Elements . . . . . . . . . . . . . . . . . . . . . 5
3.3. Session Establishment Data . . . . . . . . . . . . . . . . 8 3.3. Session Establishment Data . . . . . . . . . . . . . . . . 8
3.3.1. User Identities and SIP URIs . . . . . . . . . . . . . 8 3.3.1. User Identities and SIP URIs . . . . . . . . . . . . . 8
3.3.2. URI Reachability . . . . . . . . . . . . . . . . . . . 9 3.3.2. URI Reachability . . . . . . . . . . . . . . . . . . . 9
4. Considerations and Requirements for Session Peering of 4. Requirements for Session Peering of Presence and Instant
Presence and Instant Messaging . . . . . . . . . . . . . . . . 10 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. Security Properties for the Acquisition of Session 5.1. Security Properties for the Acquisition of Session
Establishment Data . . . . . . . . . . . . . . . . . . . . 12 Establishment Data . . . . . . . . . . . . . . . . . . . . 12
5.2. Security Properties for the SIP signaling exchanges . . . 13 5.2. Security Properties for the SIP signaling exchanges . . . 13
5.3. End-to-End Media Security . . . . . . . . . . . . . . . . 14 5.3. End-to-End Media Security . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Policy Parameters for Session Peering . . . . . . . . 20
Appendix A. Policy Parameters for Session Peering . . . . . . . . 22
A.1. Categories of Parameters for VoIP Session Peering and A.1. Categories of Parameters for VoIP Session Peering and
Justifications . . . . . . . . . . . . . . . . . . . . . . 22 Justifications . . . . . . . . . . . . . . . . . . . . . . 20
A.2. Summary of Parameters for Consideration in Session A.2. Summary of Parameters for Consideration in Session
Peering Policies . . . . . . . . . . . . . . . . . . . . . 25 Peering Policies . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
Peering at the session level represents an agreement between parties Peering at the session level represents an agreement between parties
to allow the exchange of multimedia traffic. It is assumed that to exchange multimedia traffic. It is assumed that these sessions
these sessions use the Session Initiation Protocol (SIP) protocol to use the Session Initiation Protocol (SIP) protocol to enable peering
enable peering between two or more actors. These actors are called between two or more actors. These actors are called SIP Service
SIP Service Providers (SSPs) and they are typically represented by Providers (SSPs) and they are typically represented by users, user
users, user groups such as enterprises, real-time collaboration groups such as enterprises, real-time collaboration service
service communities, or other service providers offering voice or communities, or other service providers offering voice or multimedia
multimedia services using SIP. services using SIP.
A reference architecture for SIP session peering is described in A reference architecture for SIP session peering is described in
[I-D.ietf-speermint-architecture]. A number of use cases describe [I-D.ietf-speermint-architecture]. A number of use cases describe
how session peering has been or could be deployed based on the how session peering has been or could be deployed based on the
reference architecture reference architecture
([I-D.ietf-speermint-voip-consolidated-usecases] and ([I-D.ietf-speermint-voip-consolidated-usecases] and
[I-D.ietf-speermint-consolidated-presence-im-usecases]). [I-D.ietf-speermint-consolidated-presence-im-usecases]).
Peering at the session layer can be achieved on a bilateral basis Peering at the session layer can be achieved on a bilateral basis
(direct peering established directly between two SSPs), or on an (direct peering established directly between two SSPs), or on an
indirect basis via a session intermediary (indirect peering via a indirect basis via a session intermediary (indirect peering via a
third-party SSP that has a trust relationship with the SSPs) - see third-party SSP that has a trust relationship with the SSPs) - see
the terminology document for more details. the terminology document for more details.
This document first describes general requirements. The use cases This document first describes general requirements. The use cases
are then analyzed in the spirit of extracting relevant protocol are then analyzed in the spirit of extracting relevant protocol
requirements that must be met to accomplish the use cases. These requirements that must be met to accomplish the use cases. These
requirements are intended to be independent of the type of media requirements are intended to be independent of the type of media
exchanged such as Voice over IP (VoIP), video telephony, and instant exchanged such as Voice over IP (VoIP), video telephony, and instant
messaging. Media-specific requirements are defined in separate messaging. Requirements specific to presence and instant messaging
sections. are defined in Section 4.
It is not the goal of this document to mandate any particular use of It is not the goal of this document to mandate any particular use of
IETF protocols by SIP Service Providers in order to establish session IETF protocols by SIP Service Providers in order to establish session
peering. Instead, the document highlights what requirements should peering. Instead, the document highlights what requirements should
be met and what protocols may be used to define the solution space. be met and what protocols may be used to define the solution space.
Finally, we conclude with a list of parameters for the definition of Finally, we conclude with a list of parameters for the definition of
a session peering policy, provided in an informative appendix. It a session peering policy, provided in an informative appendix. It
should be considered as an example of the information SIP Service should be considered as an example of the information SIP Service
Providers may have to discuss or agree on to exchange SIP traffic. Providers may have to discuss or agree on to exchange SIP traffic.
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].
This document also reuses the terminology defined in [I-D.ietf- This document also reuses the terminology defined in
speermint-terminology]. It is assumed that the reader is familiar [I-D.ietf-speermint-terminology]. It is assumed that the reader is
with the Session Description Protocol (SDP) [RFC4566] and the Session familiar with the Session Description Protocol (SDP) [RFC4566] and
Initiation Protocol (SIP) [RFC3261]. Finally, when used with capital the Session Initiation Protocol (SIP) [RFC3261]. Finally, when used
letters, the terms 'Authentication Service' are to be understood as with capital letters, the terms 'Authentication Service' are to be
defined by SIP Identity [RFC4474]. understood as defined by SIP Identity [RFC4474].
3. General Requirements 3. General Requirements
The following sub-sections contain general requirements applicable to The following sub-sections contain general requirements applicable to
multiple use cases for multimedia session peering. multiple use cases for multimedia session peering.
3.1. Scope 3.1. Scope
The primary focus of this document is on the requirements applicable The primary focus of this document is on the requirements applicable
to the boundaries of Layer 5 SIP networks: SIP entities, Signaling to the boundaries of Layer 5 SIP networks: SIP entities, Signaling
path Border Elements (SBEs), and the associated protocol requirements path Border Elements (SBEs), and the associated protocol requirements
for the look-up and location routing of the session establishment for the look-up and location routing of the session establishment
data. The requirements related to SIP UAs, the provisioning of the data. The requirements applicable to SIP UAs or related to the
session data are considered out of scope. provisioning of the session data are considered out of scope.
SSPs desiring to establish session peering relationships have to SSPs desiring to establish session peering relationships have to
reach an agreement on numerous points. reach an agreement on numerous points.
This document highlights only certain aspects of a session peering This document highlights only certain aspects of a session peering
agreement, mostly the requirements relevant to protocols: the agreement, mostly the requirements relevant to protocols: the
declaration, advertisement and management of ingress and egress for declaration, advertisement and management of ingress and egress
session signaling and media, information related to the Session border elements for session signaling and media, information related
Establishment Data (SED), and the security mechanisms a peer may use to the Session Establishment Data (SED), and the security properties
to accept and secure session exchanges. that may be desirable for secure session exchanges.
Numerous other considerations of session peering arrangement are Numerous other considerations of session peering arrangements are
critical to reach a successful agreement but they are considered out critical to reach a successful agreement but they are considered out
of scope of the SPEERMINT working group. They include information of scope of the SPEERMINT working group. They include information
about SIP protocol support (e.g. SIP extensions and field about SIP protocol support (e.g. SIP extensions and field
conventions), media (e.g., type of media traffic to be exchanged, conventions), media (e.g., type of media traffic to be exchanged,
compatible media codecs and media transport protocols, mechanisms to compatible media codecs and transport protocols, mechanisms to ensure
ensure differentiated quality of service for media), SIP layer-3 IP differentiated quality of service for media), layer-3 IP connectivity
connectivity between the Signaling Path and Data Path Border between the Signaling and Data path Border Elements, accounting and
Elements, traffic capacity control (e.g. maximum number of SIP traffic capacity control (e.g. the maximum number of SIP sessions at
sessions at each ingress point, maximum number of concurrent IM or each ingress point, or the maximum number of concurrent IM or VoIP
VoIP sessions), and accounting. sessions).
The informative Appendix A lists parameters that may be considered The informative Appendix A lists parameters that may be considered
when discussing the technical parameters of SIP session peering. The when discussing the technical parameters of SIP session peering. The
purpose of this list is to capture the parameters that are considered purpose of this list is to capture the parameters that are considered
outside the scope of the protocol requirements. outside the scope of the protocol requirements.
3.2. Border Elements 3.2. Border Elements
For border elements to be operationally manageable, maximum For border elements to be operationally manageable, maximum
flexibility should be given for how they are declared or dynamically flexibility should be given for how they are declared or dynamically
advertised. advertised. Indeed, in any session peering environment, there is a
need for a SIP Service Provider to declare or dynamically advertise
Indeed, in any session peering environment, there is a need for a SIP the SIP entities that will face the peer's network. The data path
Service Provider to declare or dynamically advertise the SIP entities border elements are typically signaled dynamically in the session
that will face the peer's network. The data path border elements are description.
typically signaled dynamically in the session description.
The use cases defined The use cases defined in
([I-D.ietf-speermint-voip-consolidated-usecases]) catalog the various [I-D.ietf-speermint-voip-consolidated-usecases] catalog the various
border elements between SIP Service Providers; they include Signaling border elements between SIP Service Providers; they include Signaling
Path Border Elements (SBEs) and SIP proxies (or any SIP entity at the path Border Elements (SBEs) and SIP proxies (or any SIP entity at the
boundary of the Layer 5 network). boundary of the Layer 5 network).
o Requirement #1: o Requirement #1:
Protocol mechanisms must exist for a SIP Service Provider to Protocol mechanisms MUST be provided to enable a SIP Service
communicate the ingress Signaling Path Border Elements of its Provider to communicate the ingress Signaling Path Border Elements
service domain. of its service domain.
Notes on solution space: Notes on solution space:
The SBEs may be advertised to session peers using static The SBEs may be advertised to session peers using static
mechanisms or they may be dynamically advertised. There is mechanisms or they may be dynamically advertised. There is
general agreement that [RFC3263] provides a solution for general agreement that [RFC3263] provides a solution for
dynamically advertising ingress SBEs in most cases of Direct or dynamically advertising ingress SBEs in most cases of Direct or
Indirect peering. However, this DNS-based solution may be limited Indirect peering. However, this DNS-based solution may be limited
in cases where the DNS response varies based on who sends the in cases where the DNS response varies based on who sends the
query (peer-dependent SBEs, see below). query (peer-dependent SBEs, see below).
o Requirement #2: o Requirement #2:
Protocol mechanisms must exist for a SIP Service Provider to Protocol mechanisms MUST be provided to enable a SIP Service
communicate the egress SBEs of its service domain. Provider to communicate the egress SBEs of its service domain.
Notes on motivations for this requirement: Notes on motivations for this requirement:
For the purposes of capacity planning, traffic engineering and For the purposes of capacity planning, traffic engineering and
call admission control, a SIP Service Provider may be asked where call admission control, a SIP Service Provider may be asked where
it will generate SIP calls from. The SSP accepting calls from a it will generate SIP calls from. The SSP accepting calls from a
peer may wish to know where SIP calls will originate from (this peer may wish to know where SIP calls will originate from (this
information is typically used by the terminating SSP). information is typically used by the terminating SSP).
While provisioning requirements are out-of-scope of this document, While provisioning requirements are out-of-scope, some SSPs may
some SSPs may find use for a mechanism to dynamically advertise or find use for a mechanism to dynamically advertise or discover the
discover the egress SBEs of a peer. egress SBEs of a peer.
If the SSP also provides media streams to its users as shown in the If the SSP also provides media streams to its users as shown in the
use cases for "Originating" and "Terminating" SSPs, a mechanism use cases for "Originating" and "Terminating" SSPs, a mechanism must
should exist to allow SSPs to advertise their egress and ingress data exist to allow SSPs to advertise their egress and ingress data path
path border elements (DBEs), if applicable. While some SSPs may have border elements (DBEs), if applicable. While some SSPs may have open
open policies and accept media traffic from anywhere outside their policies and accept media traffic from anywhere outside their network
network to anywhere inside their network, some SSPs may want to to anywhere inside their network, some SSPs may want to optimize
optimize media delivery and identify media paths between peers prior media delivery and identify media paths between peers prior to
to traffic being sent (layer 5 to layer 3 QoS mapping). traffic being sent (layer 5 to layer 3 QoS mapping).
o Requirement #3: o Requirement #3:
Protocol mechanisms must allow a SIP Service Provider to Protocol mechanisms MUST be provided to allow a SIP Service
communicate its DBEs to its peers. Provider to communicate its DBEs to its peers.
Notes: Some SSPs engaged in SIP interconnects do exchange this Notes: Some SSPs engaged in SIP interconnects do exchange this
type of DBE information today in a static manner. Some SSPs do type of DBE information today in a static manner. Some SSPs do
not. not.
Some SSPs may have some restrictions on the type of media traffic In some SIP networks, SSPs operate the same border elements for all
their SIP entities acting as SBEs are capable of establishing. In peers. In other SIP networks, it is common for SSPs to advertise
order to avoid a failed attempt to establish a session, a mechanism specific SBEs and DBEs to certain peers: the advertisement of SBEs
may be provided to allow SSPs to indicate if some restrictions exist and DBEs may be peer-dependent.
on the type of media traffic: ingress and egress SBE points may be
peer-dependent, and/or media-dependent.
o Requirement #4: o Requirement #4:
The mechanisms recommended for the declaration or advertisement of The mechanisms recommended for the declaration or advertisement of
SBE and DBE entities MUST allow for peer variability. SBE and DBE entities MUST allow for peer variability.
Notes on solution space: Notes on solution space:
For advertising peer-dependent SBEs (peer variability), the For advertising peer-dependent SBEs (peer variability), the
solution space based on [RFC3263] is under specified and there are solution space based on [RFC3263] is under specified and there are
no know best current practices. Is DNS the right place for no know best current practices. Is DNS the right place for
putting data that varies based on who asks? putting data that varies based on who asks?
In the use cases provided as part of direct and indirect scenarios, Notes on media-variability of such advertisements:
an SSP deals with multiple SIP entities and multiple SBEs in its own Some SSPs may have some restrictions on the type of media traffic
domain. There is often a many-to-many relationship between SIP their SBEs can accept. For SIP sessions however, it is not
Proxies and Signaling path Border Elements. possible to communicate those restrictions in advance of the
session initiation: a SIP target may support voice-only media,
voice and video, or voice and instant messaging communications.
While the inability to find out whether a particular type of SIP
session can be terminated by a certain SBE can cause failed
session establishment attempts, there is consensus to not add a
new requirement for this. These aspects are essentially covered
by SSPs when discussing traffic exchange policies (out of scope of
this document).
In the use cases provided as part of direct and indirect peering
scenarios, an SSP deals with multiple SIP entities and multiple SBEs
in its own domain. There is often a many-to-many relationship
between the SIP Proxies considered inside the trusted network
boundary of the SSP and its Signaling path Border Elements at the
network boundaries.
It should be possible for an SSP to define which egress SBE a SIP It should be possible for an SSP to define which egress SBE a SIP
entity must use based on a given peer destination. For example, in entity must use based on a given peer destination.
the case of an indirect peering scenario (section 5.1.5 of For example, in the case of an indirect peering scenario (section 5.
[I-D.ietf-speermint-voip-consolidated-usecases], Figure 5), it should of [I-D.ietf-speermint-voip-consolidated-usecases], Figure 5), it
be possible for the O-Proxy to choose the appropriate O-SBE based on should be possible for the SIP proxy in the originating network
the information the O-Proxy receives from the Lookup Function (LUF) (O-Proxy) to select the appropriate egress SBE (O-SBE) to reach the
and/or Location Routing Function (LRF) - message response labeled SIP target based on the information the proxy receives from the
(3). Note that this example also applies to the case of Direct Lookup Function (O-LUF) and/or Location Routing Function (O-LRF) -
Peering when a service provider has multiple service areas and each message response labeled (2). Note that this example also applies to
service area involves multiple SIP Proxies and a few SBEs. the case of Direct Peering when a service provider has multiple
service areas and each service area involves multiple SIP Proxies and
a few SBEs.
o Requirement #5: o Requirement #5:
The mechanisms recommended for the lookup and location routing The mechanisms recommended for the Look-Up Function (LUF) and the
functions MUST be capable of returning both a target URI Location Routing Functions (LRF) MUST be capable of returning both
destination and a value for the SIP Route header. a target URI destination and a value providing the next SIP
hop(s).
Notes: solutions exist if the protocol used between the Proxy and Notes: solutions may exist depending on the choice of the protocol
the LUF/LRF is SIP; if ENUM is used, the author of this document used between the Proxy and its LUF/LRF. The idea is for the
does not know of any solution today. O-Proxy to be provided with the next SIP hop and the equivalent of
one or more SIP Route header values. If ENUM is used as a
protocol for the LUF, the solution space is undefined.
It is desirable for an SSP to be able to communicate how It is desirable for an SSP to be able to communicate how
authentication of a peer's SBEs will occur (see the security authentication of a peer's SBEs will occur (see the security
requirements for more details). requirements for more details).
o Requirement #6: o Requirement #6:
The mechanisms recommended for locating a peer's SBE MUST be able The mechanisms recommended for locating a peer's SBE MUST be able
to convey how a peer should initiate secure session establishment. to convey how a peer should initiate secure session establishment.
Notes : certain mechanisms exist; for example, the required Notes : some mechanisms exist. For example, the required protocol
protocol use of SIP over TLS may be discovered via [RFC3263]. use of SIP over TLS may be discovered via [RFC3263].
3.3. Session Establishment Data 3.3. Session Establishment Data
The Session Establishment Data (SED) is defined in The Session Establishment Data (SED) is defined in
[I-D.ietf-speermint-terminology] as the data used to route a call to [I-D.ietf-speermint-terminology] as the data used to route a call to
the next hop associated with the called domain's ingress point. The the next hop associated with the called domain's ingress point. The
following paragraphs capture some general requirements on the SED following paragraphs capture some general requirements on the SED
data. data.
3.3.1. User Identities and SIP URIs 3.3.1. User Identities and SIP URIs
skipping to change at page 9, line 14 skipping to change at page 9, line 32
identifiers such as Service Provider IDs (SPIDs) or Trunk Group identifiers such as Service Provider IDs (SPIDs) or Trunk Group
IDs (they should not be precluded but solutions should not be IDs (they should not be precluded but solutions should not be
limited to these). limited to these).
Motivations: Motivations:
Although SED data may be based on E.164-based SIP URIs for voice Although SED data may be based on E.164-based SIP URIs for voice
interconnects, a generic peering methodology should not rely on interconnects, a generic peering methodology should not rely on
such E.164 numbers. such E.164 numbers.
3.3.2. URI Reachability 3.3.2. URI Reachability
Based on a well-known URI type (for e.g. sip, pres, or im URIs), it Based on a well-known URI type (for e.g. sip:, pres:, or im: URIs),
must be possible to determine whether the SSP domain servicing the it must be possible to determine whether the SSP domain servicing the
URI allows for session peering, and if it does, it should be possible URI allows for session peering, and if it does, it should be possible
to locate and retrieve the domain's policy and SBE entities. to locate and retrieve the domain's policy and SBE entities.
For example, an originating service provider must be able to For example, an originating service provider must be able to
determine whether a SIP URI is open for direct interconnection determine whether a SIP URI is open for direct interconnection
without requiring an SBE to initiate a SIP request. Furthermore, without requiring an SBE to initiate a SIP request. Furthermore,
since each call setup implies the execution of any proposed since each call setup implies the execution of any proposed
algorithm, the establishment of a SIP session via peering should algorithm, the establishment of a SIP session via peering should
incur minimal overhead and delay, and employ caching wherever incur minimal overhead and delay, and employ caching wherever
possible to avoid extra protocol round trips. possible to avoid extra protocol round trips.
o Requirement #9: o Requirement #9:
The mechanisms for session peering MUST allow an SBE to locate its The mechanisms for session peering MUST allow an SBE to locate its
peer SBE given a URI type and the target SSP domain name. peer SBE given a URI type and the target SSP domain name.
4. Considerations and Requirements for Session Peering of Presence and 4. Requirements for Session Peering of Presence and Instant Messaging
Instant Messaging
This section describes requirements for presence and instant This section describes requirements for presence and instant
messaging session peering. Several use cases for presence and messaging session peering. Several use cases for presence and
instant messaging peering are described in instant messaging peering are described in
[I-D.ietf-speermint-consolidated-presence-im-usecases], a document [I-D.ietf-speermint-consolidated-presence-im-usecases], a document
authored by A. Houri, E. Aoki and S. Parameswar. Credits for this authored by A. Houri, E. Aoki and S. Parameswar. Credits for this
section must go to A. Houri, E. Aoki and S. Parameswar. section must go to A. Houri, E. Aoki and S. Parameswar.
The following requirements for presence and instant messaging session The following requirements for presence and instant messaging session
peering are derived from peering are derived from
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Early deployments of SIP based presence and IM gateways are done Early deployments of SIP based presence and IM gateways are done
in front of legacy proprietary systems that use different names in front of legacy proprietary systems that use different names
for different properties that exist in PIDF. For example "Do Not for different properties that exist in PIDF. For example "Do Not
Disturb" may be translated to "Busy" in another system. In order Disturb" may be translated to "Busy" in another system. In order
to make sure that the meaning of the status is preserved, there is to make sure that the meaning of the status is preserved, there is
a need that either each system will translate its internal a need that either each system will translate its internal
statuses to standard PIDF based statuses of a translation table of statuses to standard PIDF based statuses of a translation table of
proprietary statuses to standard based PIDF statuses will be proprietary statuses to standard based PIDF statuses will be
provided from one system to the other. provided from one system to the other.
5. Security Requirements 5. Security Considerations
This section describes the security properties that are desirable for This section describes the security properties that are desirable for
the protocol exchanges in scope of session peering. Three types of the protocol exchanges in scope of session peering. Three types of
information flows are described in the architecture and use case information flows are described in the architecture and use case
documents: the acquisition of the Session Establishment Data (SED) documents: the acquisition of the Session Establishment Data (SED)
based on a destination target via the Lookup and Location Routing based on a destination target via the Lookup and Location Routing
Functions (LUF and LRF), the SIP signaling between SIP Service Functions (LUF and LRF), the SIP signaling between SIP Service
Providers, and the associated media exchanges. Providers, and the associated media exchanges.
This section is focused on three security services, authentication, This section is focused on three security services, authentication,
data confidentiality and data integrity as summarized in [RFC3365]. data confidentiality and data integrity as summarized in [RFC3365].
However, this text does not specify the mandatory-to-implement However, this text does not specify the mandatory-to-implement
security mechanisms as required by [RFC3365]; this is left for future security mechanisms as required by [RFC3365]; this is left for future
protocol solutions that meet the requirements. protocol solutions that meet the requirements.
A security threat analysis provides guidance for session peering A security threat analysis provides additional guidance for session
([I-D.niccolini-speermint-voipthreats]). peering ([I-D.niccolini-speermint-voipthreats]).
5.1. Security Properties for the Acquisition of Session Establishment 5.1. Security Properties for the Acquisition of Session Establishment
Data Data
The Look-Up Function (LUF) and Location Routing Function (LRF) are The Look-Up Function (LUF) and Location Routing Function (LRF) are
defined in [I-D.ietf-speermint-terminology]. They provide mechanisms defined in [I-D.ietf-speermint-terminology]. They provide mechanisms
for determining the SIP target address and domain the request should for determining the SIP target address and domain the request should
be sent to, and the associated SED to route the request to that be sent to, and the associated SED to route the request to that
domain. domain.
o Requirement #15: o Requirement #15:
The protocols used to query the Lookup and Location Routing The protocols used to query the Lookup and Location Routing
Functions MUST support mutual authentication. Functions MUST support mutual authentication.
Motivations: Motivations:
A mutual authentication service is desirable for the LUF and LRF A mutual authentication service is desirable for the LUF and LRF
protocol exchanges. The response from the LUF and LRF may depend protocol exchanges. The content of the response returned by the
on the identity of the requestor: the authentication of the LUF/ LUF and LRF may depend on the identity of the requestor: the
LRF requests is therefore a desirable property. Mutual authentication of the LUF & LRF requests is therefore a desirable
authentication is also desirable: the requestor may verify the property. Mutual authentication is also desirable: the requestor
identity of the systems that provided the LUF/LRF responses given may verify the identity of the systems that provided the LUF & LRF
the nature of the data returned in those responses. responses given the nature of the data returned in those
Authentication also provides some protection for the availability responses. Authentication also provides some protection for the
of the LUF and LRF against attackers that would attempt to launch availability of the LUF and LRF against attackers that would
DoS attacks by sending bogus requests causing the LUF to perform a attempt to launch DoS attacks by sending bogus requests causing
lookup and consume resources. the LUF to perform a lookup and consume resources.
o Requirement #16: o Requirement #16:
The protocols used to query the Lookup and Location Routing The protocols used to query the Lookup and Location Routing
Functions MUST provide support for data confidentiality and Functions MUST provide support for data confidentiality and
integrity. integrity.
Motivations: Motivations:
Given the sensitive nature of the session establishment data Given the sensitive nature of the session establishment data
exchanged with the LUF and LRF functions, the protocol mechanisms exchanged with the LUF and LRF functions, the protocol mechanisms
chosen for the lookup and location routing should offer data chosen for the lookup and location routing should offer data
skipping to change at page 13, line 23 skipping to change at page 13, line 23
o Notes on the solution space for Requirements #15 and #16: ENUM, o Notes on the solution space for Requirements #15 and #16: ENUM,
SIP and proprietary protocols are typically used today for SIP and proprietary protocols are typically used today for
accessing these functions. Even though SSPs may use lower layer accessing these functions. Even though SSPs may use lower layer
security mechanisms to guarantee some of those security security mechanisms to guarantee some of those security
properties, candidate protocols for the LUF and LRF must meet the properties, candidate protocols for the LUF and LRF must meet the
above requirements. above requirements.
5.2. Security Properties for the SIP signaling exchanges 5.2. Security Properties for the SIP signaling exchanges
While the SIP signaling exchanges are out of scope of speermint, this The SIP signaling exchanges are out of scope of this document. This
section describes some of the security properties that are desirable section describes some of the security properties that are desirable
in the context of SIP interconnects between SSPs. in the context of SIP interconnects between SSPs without formulating
any normative requirements.
In general, the security properties desirable for the SIP exchanges In general, the security properties desirable for the SIP exchanges
in an inter-domain context apply to session peering. These include: in an inter-domain context apply to session peering. These include:
o securing the transport of SIP messages between the peers' SBEs. o securing the transport of SIP messages between the peers' SBEs.
Authentication of SIP communications is desirable, especially in Authentication of SIP communications is desirable, especially in
the context of session peering involving SIP intermediaries. Data the context of session peering involving SIP intermediaries. Data
confidentiality and integrity of the SIP message body may be confidentiality and integrity of the SIP message body may be
desirable as well given some of the levels of session peering desirable as well given some of the levels of session peering
indirection (indirect/assisted peering), but they could be harmful indirection (indirect/assisted peering), but they could be harmful
skipping to change at page 14, line 5 skipping to change at page 14, line 5
The fundamental mechanisms for securing SIP between proxy servers The fundamental mechanisms for securing SIP between proxy servers
intra- and inter-domain are applicable to session peering; refer to intra- and inter-domain are applicable to session peering; refer to
Section 26.2 of [RFC3261] for transport-layer security of SIP Section 26.2 of [RFC3261] for transport-layer security of SIP
messages using TLS, [I-D.ietf-sip-connect-reuse] for establishing TLS messages using TLS, [I-D.ietf-sip-connect-reuse] for establishing TLS
connections between proxies, [RFC4474] for the protocol mechanisms to connections between proxies, [RFC4474] for the protocol mechanisms to
verify the identity of the senders of SIP requests in an inter-domain verify the identity of the senders of SIP requests in an inter-domain
context, and [RFC4916] for verifying the identity of the sender of context, and [RFC4916] for verifying the identity of the sender of
SIP responses). SIP responses).
o Requirement #17:
The security properties provided by the protocol mechanisms
defined in Section 26.2 of [RFC3261] and
[I-D.ietf-sip-connect-reuse] for transport-layer security, and by
[RFC4474], and [RFC4916] for SIP identity MUST be met in the
context of the speermint architecture.
Motivations:
The motivations for this requirement are provided in the above
paragraphs.
o Discussion points around Requirement #17:
The above text captures the super-set of security properties that
2 SSPs would ever want. The question is why would SSPs need RFC
4474 if they have hop-by-hop security and connection reuse
underneath? What additional properties would RFC4474 provide in
this context?
On a different note, is it reasonable to say that SSPs need the
validation of the sender of the request using SIP Identity RFC
4474 for every request? If yes, have folks considered the impact
of requiring the computation and verification of the SIP Identity
field value for every request?
5.3. End-to-End Media Security 5.3. End-to-End Media Security
Media security is critical to guarantee end-to-end confidentiality of Media security is critical to guarantee end-to-end confidentiality of
the communication between the end-users' devices, independently of the communication between the end-users' devices, independently of
how many direct or indirect peers are present along the signaling how many direct or indirect peers are present along the signaling
path. A number of desirable security properties emerge from this path. A number of desirable security properties emerge from this
goal. goal.
The establishment of media security may be achieved along the media The establishment of media security may be achieved along the media
path and not over the signaling path given the indirect peering use path and not over the signaling path given the indirect peering use
skipping to change at page 14, line 50 skipping to change at page 14, line 27
secured using secure RTP (SRTP [RFC3711]). A framework for secured using secure RTP (SRTP [RFC3711]). A framework for
establishing SRTP security using Datagram TLS [RFC4347] is described establishing SRTP security using Datagram TLS [RFC4347] is described
in [I-D.ietf-sip-dtls-srtp-framework]: it allows for end-to-end media in [I-D.ietf-sip-dtls-srtp-framework]: it allows for end-to-end media
security establishment using extensions to DTLS security establishment using extensions to DTLS
([I-D.ietf-avt-dtls-srtp]). ([I-D.ietf-avt-dtls-srtp]).
It should also be noted that media can be carried in numerous It should also be noted that media can be carried in numerous
protocols other than RTP such as SIP (SIP MESSAGE method), MSRP, protocols other than RTP such as SIP (SIP MESSAGE method), MSRP,
XMPP, etc., over TCP ([RFC4571]), and that it can be encrypted over XMPP, etc., over TCP ([RFC4571]), and that it can be encrypted over
secure connection-oriented transport sessions over TLS ([RFC4572]). secure connection-oriented transport sessions over TLS ([RFC4572]).
A desirable security property for session peering is that SIP A desirable security property for session peering is for SIP entities
to be transparent to the end-to-end media security negotiations: SIP
entities should not intervene in the Session Description Protocol entities should not intervene in the Session Description Protocol
(SDP) exchanges for end-to-end media security. (SDP) exchanges for end-to-end media security.
o Requirement #18: o Requirement #17:
The protocols used to enable session peering MUST NOT interfere The protocols used to enable session peering MUST NOT interfere
with the exchanges of media security attributes in SDP. Media with the exchanges of media security attributes in SDP. Media
attribute lines that are not understood by SBEs MUST be ignored attribute lines that are not understood by SBEs MUST be ignored
and passed along the signaling path untouched. and passed along the signaling path untouched.
6. Acknowledgments 6. Acknowledgments
This document is based on the input and contributions made by a large This document is based on the input and contributions made by a large
number of people in the SPEERMINT working group, including: Edwin number of people in the SPEERMINT working group, including: Edwin
Aoki, Scott Brim, John Elwell, Mike Hammer, Avshalom Houri, Richard Aoki, Scott Brim, John Elwell, Mike Hammer, Avshalom Houri, Richard
skipping to change at page 18, line 5 skipping to change at page 17, line 5
initial drafts describing guidelines or best current practices in initial drafts describing guidelines or best current practices in
various environments, to Avshalom Houri, Edwin Aoki and Sriram various environments, to Avshalom Houri, Edwin Aoki and Sriram
Parameswar for authoring the presence and instant messaging Parameswar for authoring the presence and instant messaging
requirements and to Dan Wing for providing detailed feedback on the requirements and to Dan Wing for providing detailed feedback on the
security consideration sections. security consideration sections.
7. IANA Considerations 7. IANA Considerations
This document does not register any values in IANA registries. This document does not register any values in IANA registries.
8. Security Considerations 8. References
Securing session peering communications involves numerous protocol
exchanges, first and foremost, the securing of SIP signaling and
media sessions. The security considerations contained in [RFC3261],
and [RFC4474] are applicable to the SIP protocol exchanges. A number
of security considerations are also described in Section Section 5.
9. References
9.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.
9.2. Informative References 8.2. Informative References
[I-D.ietf-avt-dtls-srtp] [I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-02 (work in progress), draft-ietf-avt-dtls-srtp-05 (work in progress),
February 2008. September 2008.
[I-D.ietf-pmol-sip-perf-metrics] [I-D.ietf-pmol-sip-perf-metrics]
Malas, D., "SIP End-to-End Performance Metrics", Malas, D., "SIP End-to-End Performance Metrics",
draft-ietf-pmol-sip-perf-metrics-01 (work in progress), draft-ietf-pmol-sip-perf-metrics-01 (work in progress),
June 2008. June 2008.
[I-D.ietf-sip-connect-reuse] [I-D.ietf-sip-connect-reuse]
Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-10 (work in progress), draft-ietf-sip-connect-reuse-11 (work in progress),
May 2008. July 2008.
[I-D.ietf-sip-dtls-srtp-framework] [I-D.ietf-sip-dtls-srtp-framework]
Fischl, J., Tschofenig, H., and E. Rescorla, "Framework Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing an SRTP Security Context using DTLS", for Establishing an SRTP Security Context using DTLS",
draft-ietf-sip-dtls-srtp-framework-01 (work in progress), draft-ietf-sip-dtls-srtp-framework-04 (work in progress),
February 2008. October 2008.
[I-D.ietf-sip-hitchhikers-guide] [I-D.ietf-sip-hitchhikers-guide]
Rosenberg, J., "A Hitchhiker's Guide to the Session Rosenberg, J., "A Hitchhiker's Guide to the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-ietf-sip-hitchhikers-guide-05 (work in progress), draft-ietf-sip-hitchhikers-guide-05 (work in progress),
February 2008. February 2008.
[I-D.ietf-speermint-architecture] [I-D.ietf-speermint-architecture]
Penno, R., "SPEERMINT Peering Architecture", Penno, R., "SPEERMINT Peering Architecture",
draft-ietf-speermint-architecture-06 (work in progress), draft-ietf-speermint-architecture-06 (work in progress),
skipping to change at page 20, line 13 skipping to change at page 18, line 13
draft-ietf-speermint-consolidated-presence-im-usecases-05 draft-ietf-speermint-consolidated-presence-im-usecases-05
(work in progress), July 2008. (work in progress), July 2008.
[I-D.ietf-speermint-terminology] [I-D.ietf-speermint-terminology]
Malas, D. and D. Meyer, "SPEERMINT Terminology", Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress), draft-ietf-speermint-terminology-16 (work in progress),
February 2008. February 2008.
[I-D.ietf-speermint-voip-consolidated-usecases] [I-D.ietf-speermint-voip-consolidated-usecases]
Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases",
draft-ietf-speermint-voip-consolidated-usecases-08 (work draft-ietf-speermint-voip-consolidated-usecases-10 (work
in progress), May 2008. in progress), August 2008.
[I-D.niccolini-speermint-voipthreats] [I-D.niccolini-speermint-voipthreats]
Niccolini, S., Chen, E., and J. Seedorf, "SPEERMINT Niccolini, S., Chen, E., and J. Seedorf, "SPEERMINT
Security BCPs", draft-niccolini-speermint-voipthreats-03 Security Threats and Suggested Countermeasures",
(work in progress), February 2008. draft-niccolini-speermint-voipthreats-04 (work in
progress), July 2008.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[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.
skipping to change at page 23, line 26 skipping to change at page 21, line 26
time fax (version of T.38, if applicable), real-time text (RFC time fax (version of T.38, if applicable), real-time text (RFC
4103), DTMF transport, voice band data communications (as 4103), DTMF transport, voice band data communications (as
applicable) along with the supported or recommended codec applicable) along with the supported or recommended codec
packetization rates, level of RTP payload redundancy, audio packetization rates, level of RTP payload redundancy, audio
volume levels, etc. volume levels, etc.
* Media Transport: level of support for RTP-RTCP [RFC3550], RTP * Media Transport: level of support for RTP-RTCP [RFC3550], RTP
Redundancy (RTP Payload for Redundant Audio Data - [RFC2198]) , Redundancy (RTP Payload for Redundant Audio Data - [RFC2198]) ,
T.38 transport over RTP, etc. T.38 transport over RTP, etc.
* Media variability at the Signaling path Border Elements: list
of media types supported by the various ingress points of a
peer's network.
* Other: support of the VoIP metric block as defined in RTP * Other: support of the VoIP metric block as defined in RTP
Control Protocol Extended Reports [RFC3611] , etc. Control Protocol Extended Reports [RFC3611] , etc.
o SIP: o SIP:
* A session peering policy should include the list of supported * A session peering policy should include the list of supported
and required SIP RFCs, supported and required SIP methods and required SIP RFCs, supported and required SIP methods
(including private p headers if applicable), error response (including private p headers if applicable), error response
codes, supported or recommended format of some header field codes, supported or recommended format of some header field
values , etc. values , etc.
 End of changes. 47 change blocks. 
165 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/