idnits 2.17.1 draft-ietf-speermint-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 995. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2008) is 5667 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-05 == Outdated reference: A later version (-07) exists of draft-ietf-pmol-sip-perf-metrics-01 == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-11 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-04 == Outdated reference: A later version (-06) exists of draft-ietf-sip-hitchhikers-guide-05 == Outdated reference: A later version (-19) exists of draft-ietf-speermint-architecture-06 == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 == Outdated reference: A later version (-19) exists of draft-ietf-speermint-voip-consolidated-usecases-10 == Outdated reference: A later version (-05) exists of draft-niccolini-speermint-voipthreats-04 -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) -- Obsolete informational reference (is this intentional?): RFC 3603 (Obsoleted by RFC 5503) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT Working Group J-F. Mule 3 Internet-Draft CableLabs 4 Intended status: Informational October 17, 2008 5 Expires: April 20, 2009 7 SPEERMINT Requirements for SIP-based Session Peering 8 draft-ietf-speermint-requirements-07.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 20, 2009. 35 Abstract 37 This memo captures protocol requirements to enable session peering of 38 voice, presence, instant messaging and other types of multimedia 39 traffic. It is based on the use cases that have been described in 40 the SPEERMINT working group. This informational document is intended 41 to link the session peering use cases to protocol solutions. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. General Requirements . . . . . . . . . . . . . . . . . . . . . 5 48 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.2. Border Elements . . . . . . . . . . . . . . . . . . . . . 5 50 3.3. Session Establishment Data . . . . . . . . . . . . . . . . 8 51 3.3.1. User Identities and SIP URIs . . . . . . . . . . . . . 8 52 3.3.2. URI Reachability . . . . . . . . . . . . . . . . . . . 9 53 4. Requirements for Session Peering of Presence and Instant 54 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 56 5.1. Security Properties for the Acquisition of Session 57 Establishment Data . . . . . . . . . . . . . . . . . . . . 12 58 5.2. Security Properties for the SIP signaling exchanges . . . 13 59 5.3. End-to-End Media Security . . . . . . . . . . . . . . . . 14 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 65 Appendix A. Policy Parameters for Session Peering . . . . . . . . 20 66 A.1. Categories of Parameters for VoIP Session Peering and 67 Justifications . . . . . . . . . . . . . . . . . . . . . . 20 68 A.2. Summary of Parameters for Consideration in Session 69 Peering Policies . . . . . . . . . . . . . . . . . . . . . 23 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 71 Intellectual Property and Copyright Statements . . . . . . . . . . 26 73 1. Introduction 75 Peering at the session level represents an agreement between parties 76 to exchange multimedia traffic. It is assumed that these sessions 77 use the Session Initiation Protocol (SIP) protocol to enable peering 78 between two or more actors. These actors are called SIP Service 79 Providers (SSPs) and they are typically represented by users, user 80 groups such as enterprises, real-time collaboration service 81 communities, or other service providers offering voice or multimedia 82 services using SIP. 84 A reference architecture for SIP session peering is described in 85 [I-D.ietf-speermint-architecture]. A number of use cases describe 86 how session peering has been or could be deployed based on the 87 reference architecture 88 ([I-D.ietf-speermint-voip-consolidated-usecases] and 89 [I-D.ietf-speermint-consolidated-presence-im-usecases]). 91 Peering at the session layer can be achieved on a bilateral basis 92 (direct peering established directly between two SSPs), or on an 93 indirect basis via a session intermediary (indirect peering via a 94 third-party SSP that has a trust relationship with the SSPs) - see 95 the terminology document for more details. 97 This document first describes general requirements. The use cases 98 are then analyzed in the spirit of extracting relevant protocol 99 requirements that must be met to accomplish the use cases. These 100 requirements are intended to be independent of the type of media 101 exchanged such as Voice over IP (VoIP), video telephony, and instant 102 messaging. Requirements specific to presence and instant messaging 103 are defined in Section 4. 105 It is not the goal of this document to mandate any particular use of 106 IETF protocols by SIP Service Providers in order to establish session 107 peering. Instead, the document highlights what requirements should 108 be met and what protocols may be used to define the solution space. 110 Finally, we conclude with a list of parameters for the definition of 111 a session peering policy, provided in an informative appendix. It 112 should be considered as an example of the information SIP Service 113 Providers may have to discuss or agree on to exchange SIP traffic. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This document also reuses the terminology defined in 122 [I-D.ietf-speermint-terminology]. It is assumed that the reader is 123 familiar with the Session Description Protocol (SDP) [RFC4566] and 124 the Session Initiation Protocol (SIP) [RFC3261]. Finally, when used 125 with capital letters, the terms 'Authentication Service' are to be 126 understood as defined by SIP Identity [RFC4474]. 128 3. General Requirements 130 The following sub-sections contain general requirements applicable to 131 multiple use cases for multimedia session peering. 133 3.1. Scope 135 The primary focus of this document is on the requirements applicable 136 to the boundaries of Layer 5 SIP networks: SIP entities, Signaling 137 path Border Elements (SBEs), and the associated protocol requirements 138 for the look-up and location routing of the session establishment 139 data. The requirements applicable to SIP UAs or related to the 140 provisioning of the session data are considered out of scope. 142 SSPs desiring to establish session peering relationships have to 143 reach an agreement on numerous points. 144 This document highlights only certain aspects of a session peering 145 agreement, mostly the requirements relevant to protocols: the 146 declaration, advertisement and management of ingress and egress 147 border elements for session signaling and media, information related 148 to the Session Establishment Data (SED), and the security properties 149 that may be desirable for secure session exchanges. 150 Numerous other considerations of session peering arrangements are 151 critical to reach a successful agreement but they are considered out 152 of scope of the SPEERMINT working group. They include information 153 about SIP protocol support (e.g. SIP extensions and field 154 conventions), media (e.g., type of media traffic to be exchanged, 155 compatible media codecs and transport protocols, mechanisms to ensure 156 differentiated quality of service for media), layer-3 IP connectivity 157 between the Signaling and Data path Border Elements, accounting and 158 traffic capacity control (e.g. the maximum number of SIP sessions at 159 each ingress point, or the maximum number of concurrent IM or VoIP 160 sessions). 162 The informative Appendix A lists parameters that may be considered 163 when discussing the technical parameters of SIP session peering. The 164 purpose of this list is to capture the parameters that are considered 165 outside the scope of the protocol requirements. 167 3.2. Border Elements 169 For border elements to be operationally manageable, maximum 170 flexibility should be given for how they are declared or dynamically 171 advertised. Indeed, in any session peering environment, there is a 172 need for a SIP Service Provider to declare or dynamically advertise 173 the SIP entities that will face the peer's network. The data path 174 border elements are typically signaled dynamically in the session 175 description. 177 The use cases defined in 178 [I-D.ietf-speermint-voip-consolidated-usecases] catalog the various 179 border elements between SIP Service Providers; they include Signaling 180 path Border Elements (SBEs) and SIP proxies (or any SIP entity at the 181 boundary of the Layer 5 network). 183 o Requirement #1: 184 Protocol mechanisms MUST be provided to enable a SIP Service 185 Provider to communicate the ingress Signaling Path Border Elements 186 of its service domain. 188 Notes on solution space: 189 The SBEs may be advertised to session peers using static 190 mechanisms or they may be dynamically advertised. There is 191 general agreement that [RFC3263] provides a solution for 192 dynamically advertising ingress SBEs in most cases of Direct or 193 Indirect peering. However, this DNS-based solution may be limited 194 in cases where the DNS response varies based on who sends the 195 query (peer-dependent SBEs, see below). 197 o Requirement #2: 198 Protocol mechanisms MUST be provided to enable a SIP Service 199 Provider to communicate the egress SBEs of its service domain. 201 Notes on motivations for this requirement: 202 For the purposes of capacity planning, traffic engineering and 203 call admission control, a SIP Service Provider may be asked where 204 it will generate SIP calls from. The SSP accepting calls from a 205 peer may wish to know where SIP calls will originate from (this 206 information is typically used by the terminating SSP). 207 While provisioning requirements are out-of-scope, some SSPs may 208 find use for a mechanism to dynamically advertise or discover the 209 egress SBEs of a peer. 211 If the SSP also provides media streams to its users as shown in the 212 use cases for "Originating" and "Terminating" SSPs, a mechanism must 213 exist to allow SSPs to advertise their egress and ingress data path 214 border elements (DBEs), if applicable. While some SSPs may have open 215 policies and accept media traffic from anywhere outside their network 216 to anywhere inside their network, some SSPs may want to optimize 217 media delivery and identify media paths between peers prior to 218 traffic being sent (layer 5 to layer 3 QoS mapping). 220 o Requirement #3: 221 Protocol mechanisms MUST be provided to allow a SIP Service 222 Provider to communicate its DBEs to its peers. 224 Notes: Some SSPs engaged in SIP interconnects do exchange this 225 type of DBE information today in a static manner. Some SSPs do 226 not. 228 In some SIP networks, SSPs operate the same border elements for all 229 peers. In other SIP networks, it is common for SSPs to advertise 230 specific SBEs and DBEs to certain peers: the advertisement of SBEs 231 and DBEs may be peer-dependent. 233 o Requirement #4: 234 The mechanisms recommended for the declaration or advertisement of 235 SBE and DBE entities MUST allow for peer variability. 237 Notes on solution space: 238 For advertising peer-dependent SBEs (peer variability), the 239 solution space based on [RFC3263] is under specified and there are 240 no know best current practices. Is DNS the right place for 241 putting data that varies based on who asks? 243 Notes on media-variability of such advertisements: 244 Some SSPs may have some restrictions on the type of media traffic 245 their SBEs can accept. For SIP sessions however, it is not 246 possible to communicate those restrictions in advance of the 247 session initiation: a SIP target may support voice-only media, 248 voice and video, or voice and instant messaging communications. 249 While the inability to find out whether a particular type of SIP 250 session can be terminated by a certain SBE can cause failed 251 session establishment attempts, there is consensus to not add a 252 new requirement for this. These aspects are essentially covered 253 by SSPs when discussing traffic exchange policies (out of scope of 254 this document). 256 In the use cases provided as part of direct and indirect peering 257 scenarios, an SSP deals with multiple SIP entities and multiple SBEs 258 in its own domain. There is often a many-to-many relationship 259 between the SIP Proxies considered inside the trusted network 260 boundary of the SSP and its Signaling path Border Elements at the 261 network boundaries. 262 It should be possible for an SSP to define which egress SBE a SIP 263 entity must use based on a given peer destination. 264 For example, in the case of an indirect peering scenario (section 5. 265 of [I-D.ietf-speermint-voip-consolidated-usecases], Figure 5), it 266 should be possible for the SIP proxy in the originating network 267 (O-Proxy) to select the appropriate egress SBE (O-SBE) to reach the 268 SIP target based on the information the proxy receives from the 269 Lookup Function (O-LUF) and/or Location Routing Function (O-LRF) - 270 message response labeled (2). Note that this example also applies to 271 the case of Direct Peering when a service provider has multiple 272 service areas and each service area involves multiple SIP Proxies and 273 a few SBEs. 275 o Requirement #5: 276 The mechanisms recommended for the Look-Up Function (LUF) and the 277 Location Routing Functions (LRF) MUST be capable of returning both 278 a target URI destination and a value providing the next SIP 279 hop(s). 281 Notes: solutions may exist depending on the choice of the protocol 282 used between the Proxy and its LUF/LRF. The idea is for the 283 O-Proxy to be provided with the next SIP hop and the equivalent of 284 one or more SIP Route header values. If ENUM is used as a 285 protocol for the LUF, the solution space is undefined. 287 It is desirable for an SSP to be able to communicate how 288 authentication of a peer's SBEs will occur (see the security 289 requirements for more details). 291 o Requirement #6: 292 The mechanisms recommended for locating a peer's SBE MUST be able 293 to convey how a peer should initiate secure session establishment. 295 Notes : some mechanisms exist. For example, the required protocol 296 use of SIP over TLS may be discovered via [RFC3263]. 298 3.3. Session Establishment Data 300 The Session Establishment Data (SED) is defined in 301 [I-D.ietf-speermint-terminology] as the data used to route a call to 302 the next hop associated with the called domain's ingress point. The 303 following paragraphs capture some general requirements on the SED 304 data. 306 3.3.1. User Identities and SIP URIs 308 User identities used between peers can be represented in many 309 different formats. Session Establishment Data should rely on URIs 310 (Uniform Resource Identifiers, [RFC3986]) and SIP URIs should be 311 preferred over tel URIs ([RFC3966]) for session peering of VoIP 312 traffic. 313 The use of DNS domain names and hostnames is recommended in SIP URIs 314 and they should be resolvable on the public Internet. As for the 315 user part of the SIP URIs, the mechanisms for session peering should 316 not require an SSP to be aware of which individual user identities 317 are valid within its peer's domain. 319 o Requirement #7: 320 The protocols used for session peering MUST accommodate the use of 321 different types of URIs. URIs with the same domain-part SHOULD 322 share the same set of peering policies, thus the domain of the SIP 323 URI may be used as the primary key to any information regarding 324 the reachability of that SIP URI. The host part of SIP URIs 325 SHOULD contain a fully-qualified domain name instead of a numeric 326 IPv4 or IPv6 address. 328 o Requirement #8: 329 The mechanisms for session peering should not require an SSP to be 330 aware of which individual user identities are valid within its 331 peer's domain. 333 o Notes on the solution space for #7 and #8: 334 This is generally well supported by IETF protocols. When 335 telephone numbers are in tel URIs, SIP requests cannot be routed 336 in accordance with the traditional DNS resolution procedures 337 standardized for SIP as indicated in [RFC3824]. This means that 338 the solutions built for session peering must not solely use PSTN 339 identifiers such as Service Provider IDs (SPIDs) or Trunk Group 340 IDs (they should not be precluded but solutions should not be 341 limited to these). 342 Motivations: 343 Although SED data may be based on E.164-based SIP URIs for voice 344 interconnects, a generic peering methodology should not rely on 345 such E.164 numbers. 347 3.3.2. URI Reachability 349 Based on a well-known URI type (for e.g. sip:, pres:, or im: URIs), 350 it must be possible to determine whether the SSP domain servicing the 351 URI allows for session peering, and if it does, it should be possible 352 to locate and retrieve the domain's policy and SBE entities. 353 For example, an originating service provider must be able to 354 determine whether a SIP URI is open for direct interconnection 355 without requiring an SBE to initiate a SIP request. Furthermore, 356 since each call setup implies the execution of any proposed 357 algorithm, the establishment of a SIP session via peering should 358 incur minimal overhead and delay, and employ caching wherever 359 possible to avoid extra protocol round trips. 361 o Requirement #9: 362 The mechanisms for session peering MUST allow an SBE to locate its 363 peer SBE given a URI type and the target SSP domain name. 365 4. Requirements for Session Peering of Presence and Instant Messaging 367 This section describes requirements for presence and instant 368 messaging session peering. Several use cases for presence and 369 instant messaging peering are described in 370 [I-D.ietf-speermint-consolidated-presence-im-usecases], a document 371 authored by A. Houri, E. Aoki and S. Parameswar. Credits for this 372 section must go to A. Houri, E. Aoki and S. Parameswar. 374 The following requirements for presence and instant messaging session 375 peering are derived from 376 [I-D.ietf-speermint-consolidated-presence-im-usecases] and an initial 377 set of related requirements published by A. Houri, E. Aoki and S. 378 Parameswar: 380 o Requirement #10: 381 The mechanisms recommended for the exchange of presence 382 information between SSPs MUST allow a user of one SSP's presence 383 community to subscribe presentities served by another SSP via its 384 local community, including subscriptions to a single presentity, a 385 personal, public or ad-hoc group list of presentities. 387 Notes: see section 2.2 of 388 [I-D.ietf-speermint-consolidated-presence-im-usecases]. 390 o Requirement #11: 391 The mechanisms recommended for Instant Messaging message exchanges 392 between SSPs MUST allow a user of one SSP's community to 393 communicate with users of the other SSP community via their local 394 community using various methods. Such methods include sending a 395 one-time IM message, initiating a SIP session for transporting 396 sessions of messages, participating in n-way chats using chat 397 rooms with users from the peer SSPs, sending a file or sharing a 398 document. 400 Notes: see section 2.6 of 401 [I-D.ietf-speermint-consolidated-presence-im-usecases]. 403 o Requirement #12: Privacy Sharing 404 In order to enable sending less notifications between communities, 405 there should be a mechanism that will enable sharing privacy 406 information of users between the communities. This will enable 407 sending a single notification per presentity that will be sent to 408 the appropriate watchers on the other community according to the 409 presentity's privacy information. 410 The privacy sharing mechanism must be done in a way that will 411 enable getting the consent of the user whose privacy will be sent 412 to the other community prior to sending the privacy information. 414 if user consent is not give, it should not be possible to this 415 optimization. In addition to getting the consent of users 416 regarding privacy sharing, the privacy data must be sent only via 417 secure channels between communities. 419 Notes: see section 2.3 of 420 [I-D.ietf-speermint-consolidated-presence-im-usecases]. 422 o Requirement #13: Multiple Recipients 423 It should be possible to send a presence document with a list of 424 watchers on the other community that should receive the presence 425 document notification. This will enable sending less presence 426 document notifications between the communities while avoiding the 427 need to share privacy information of presentities from one 428 community to the other. 430 o Requirement #14: Mappings 431 Early deployments of SIP based presence and IM gateways are done 432 in front of legacy proprietary systems that use different names 433 for different properties that exist in PIDF. For example "Do Not 434 Disturb" may be translated to "Busy" in another system. In order 435 to make sure that the meaning of the status is preserved, there is 436 a need that either each system will translate its internal 437 statuses to standard PIDF based statuses of a translation table of 438 proprietary statuses to standard based PIDF statuses will be 439 provided from one system to the other. 441 5. Security Considerations 443 This section describes the security properties that are desirable for 444 the protocol exchanges in scope of session peering. Three types of 445 information flows are described in the architecture and use case 446 documents: the acquisition of the Session Establishment Data (SED) 447 based on a destination target via the Lookup and Location Routing 448 Functions (LUF and LRF), the SIP signaling between SIP Service 449 Providers, and the associated media exchanges. 451 This section is focused on three security services, authentication, 452 data confidentiality and data integrity as summarized in [RFC3365]. 453 However, this text does not specify the mandatory-to-implement 454 security mechanisms as required by [RFC3365]; this is left for future 455 protocol solutions that meet the requirements. 457 A security threat analysis provides additional guidance for session 458 peering ([I-D.niccolini-speermint-voipthreats]). 460 5.1. Security Properties for the Acquisition of Session Establishment 461 Data 463 The Look-Up Function (LUF) and Location Routing Function (LRF) are 464 defined in [I-D.ietf-speermint-terminology]. They provide mechanisms 465 for determining the SIP target address and domain the request should 466 be sent to, and the associated SED to route the request to that 467 domain. 469 o Requirement #15: 470 The protocols used to query the Lookup and Location Routing 471 Functions MUST support mutual authentication. 473 Motivations: 474 A mutual authentication service is desirable for the LUF and LRF 475 protocol exchanges. The content of the response returned by the 476 LUF and LRF may depend on the identity of the requestor: the 477 authentication of the LUF & LRF requests is therefore a desirable 478 property. Mutual authentication is also desirable: the requestor 479 may verify the identity of the systems that provided the LUF & LRF 480 responses given the nature of the data returned in those 481 responses. Authentication also provides some protection for the 482 availability of the LUF and LRF against attackers that would 483 attempt to launch DoS attacks by sending bogus requests causing 484 the LUF to perform a lookup and consume resources. 486 o Requirement #16: 487 The protocols used to query the Lookup and Location Routing 488 Functions MUST provide support for data confidentiality and 489 integrity. 491 Motivations: 492 Given the sensitive nature of the session establishment data 493 exchanged with the LUF and LRF functions, the protocol mechanisms 494 chosen for the lookup and location routing should offer data 495 confidentiality and integrity protection (SED data may contain 496 user addresses, SIP URI, location of SIP entities at the 497 boundaries of SIP Service Provider domains, etc.). 499 o Notes on the solution space for Requirements #15 and #16: ENUM, 500 SIP and proprietary protocols are typically used today for 501 accessing these functions. Even though SSPs may use lower layer 502 security mechanisms to guarantee some of those security 503 properties, candidate protocols for the LUF and LRF must meet the 504 above requirements. 506 5.2. Security Properties for the SIP signaling exchanges 508 The SIP signaling exchanges are out of scope of this document. This 509 section describes some of the security properties that are desirable 510 in the context of SIP interconnects between SSPs without formulating 511 any normative requirements. 513 In general, the security properties desirable for the SIP exchanges 514 in an inter-domain context apply to session peering. These include: 516 o securing the transport of SIP messages between the peers' SBEs. 517 Authentication of SIP communications is desirable, especially in 518 the context of session peering involving SIP intermediaries. Data 519 confidentiality and integrity of the SIP message body may be 520 desirable as well given some of the levels of session peering 521 indirection (indirect/assisted peering), but they could be harmful 522 as they may prevent intermediary SSPs from "inserting" SBEs/DBEs 523 along the signaling and data paths. 525 o providing an Authentication Service to authenticate the identity 526 of connected users based on the SIP Service Provider domains (for 527 both the SIP requests and the responses). 529 The fundamental mechanisms for securing SIP between proxy servers 530 intra- and inter-domain are applicable to session peering; refer to 531 Section 26.2 of [RFC3261] for transport-layer security of SIP 532 messages using TLS, [I-D.ietf-sip-connect-reuse] for establishing TLS 533 connections between proxies, [RFC4474] for the protocol mechanisms to 534 verify the identity of the senders of SIP requests in an inter-domain 535 context, and [RFC4916] for verifying the identity of the sender of 536 SIP responses). 538 5.3. End-to-End Media Security 540 Media security is critical to guarantee end-to-end confidentiality of 541 the communication between the end-users' devices, independently of 542 how many direct or indirect peers are present along the signaling 543 path. A number of desirable security properties emerge from this 544 goal. 546 The establishment of media security may be achieved along the media 547 path and not over the signaling path given the indirect peering use 548 cases. 549 For example, media carried over the Real-Time Protocol (RTP) can be 550 secured using secure RTP (SRTP [RFC3711]). A framework for 551 establishing SRTP security using Datagram TLS [RFC4347] is described 552 in [I-D.ietf-sip-dtls-srtp-framework]: it allows for end-to-end media 553 security establishment using extensions to DTLS 554 ([I-D.ietf-avt-dtls-srtp]). 555 It should also be noted that media can be carried in numerous 556 protocols other than RTP such as SIP (SIP MESSAGE method), MSRP, 557 XMPP, etc., over TCP ([RFC4571]), and that it can be encrypted over 558 secure connection-oriented transport sessions over TLS ([RFC4572]). 560 A desirable security property for session peering is for SIP entities 561 to be transparent to the end-to-end media security negotiations: SIP 562 entities should not intervene in the Session Description Protocol 563 (SDP) exchanges for end-to-end media security. 565 o Requirement #17: 566 The protocols used to enable session peering MUST NOT interfere 567 with the exchanges of media security attributes in SDP. Media 568 attribute lines that are not understood by SBEs MUST be ignored 569 and passed along the signaling path untouched. 571 6. Acknowledgments 573 This document is based on the input and contributions made by a large 574 number of people in the SPEERMINT working group, including: Edwin 575 Aoki, Scott Brim, John Elwell, Mike Hammer, Avshalom Houri, Richard 576 Shocky, Henry Sinnreich, Richard Stastny, Patrik Faltstrom, Otmar 577 Lendl, Daryl Malas, Dave Meyer, Sriram Parameswar, Jon Peterson, 578 Jason Livingood, Bob Natale, Benny Rodrig, Brian Rosen, Eric 579 Rosenfeld, Adam Uzelac, and David Schwartz. 581 Specials thanks go to Rohan Mahy, Brian Rosen, John Elwell for their 582 initial drafts describing guidelines or best current practices in 583 various environments, to Avshalom Houri, Edwin Aoki and Sriram 584 Parameswar for authoring the presence and instant messaging 585 requirements and to Dan Wing for providing detailed feedback on the 586 security consideration sections. 588 7. IANA Considerations 590 This document does not register any values in IANA registries. 592 8. References 594 8.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 8.2. Informative References 601 [I-D.ietf-avt-dtls-srtp] 602 McGrew, D. and E. Rescorla, "Datagram Transport Layer 603 Security (DTLS) Extension to Establish Keys for Secure 604 Real-time Transport Protocol (SRTP)", 605 draft-ietf-avt-dtls-srtp-05 (work in progress), 606 September 2008. 608 [I-D.ietf-pmol-sip-perf-metrics] 609 Malas, D., "SIP End-to-End Performance Metrics", 610 draft-ietf-pmol-sip-perf-metrics-01 (work in progress), 611 June 2008. 613 [I-D.ietf-sip-connect-reuse] 614 Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in 615 the Session Initiation Protocol (SIP)", 616 draft-ietf-sip-connect-reuse-11 (work in progress), 617 July 2008. 619 [I-D.ietf-sip-dtls-srtp-framework] 620 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 621 for Establishing an SRTP Security Context using DTLS", 622 draft-ietf-sip-dtls-srtp-framework-04 (work in progress), 623 October 2008. 625 [I-D.ietf-sip-hitchhikers-guide] 626 Rosenberg, J., "A Hitchhiker's Guide to the Session 627 Initiation Protocol (SIP)", 628 draft-ietf-sip-hitchhikers-guide-05 (work in progress), 629 February 2008. 631 [I-D.ietf-speermint-architecture] 632 Penno, R., "SPEERMINT Peering Architecture", 633 draft-ietf-speermint-architecture-06 (work in progress), 634 May 2008. 636 [I-D.ietf-speermint-consolidated-presence-im-usecases] 637 Houri, A., "Presence & Instant Messaging Peering Use 638 Cases", 639 draft-ietf-speermint-consolidated-presence-im-usecases-05 640 (work in progress), July 2008. 642 [I-D.ietf-speermint-terminology] 643 Malas, D. and D. Meyer, "SPEERMINT Terminology", 644 draft-ietf-speermint-terminology-16 (work in progress), 645 February 2008. 647 [I-D.ietf-speermint-voip-consolidated-usecases] 648 Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 649 draft-ietf-speermint-voip-consolidated-usecases-10 (work 650 in progress), August 2008. 652 [I-D.niccolini-speermint-voipthreats] 653 Niccolini, S., Chen, E., and J. Seedorf, "SPEERMINT 654 Security Threats and Suggested Countermeasures", 655 draft-niccolini-speermint-voipthreats-04 (work in 656 progress), July 2008. 658 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 659 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 660 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 661 September 1997. 663 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 664 A., Peterson, J., Sparks, R., Handley, M., and E. 665 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 666 June 2002. 668 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 669 Protocol (SIP): Locating SIP Servers", RFC 3263, 670 June 2002. 672 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 673 Engineering Task Force Standard Protocols", BCP 61, 674 RFC 3365, August 2002. 676 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 677 Header (P-Header) Extensions to the Session Initiation 678 Protocol (SIP) for the 3rd-Generation Partnership Project 679 (3GPP)", RFC 3455, January 2003. 681 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 682 Jacobson, "RTP: A Transport Protocol for Real-Time 683 Applications", STD 64, RFC 3550, July 2003. 685 [RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation 686 Protocol (SIP) Proxy-to-Proxy Extensions for Supporting 687 the PacketCable Distributed Call Signaling Architecture", 688 RFC 3603, October 2003. 690 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 691 Protocol Extended Reports (RTCP XR)", RFC 3611, 692 November 2003. 694 [RFC3702] Loughney, J. and G. Camarillo, "Authentication, 695 Authorization, and Accounting Requirements for the Session 696 Initiation Protocol (SIP)", RFC 3702, February 2004. 698 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 699 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 700 RFC 3711, March 2004. 702 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 703 E.164 numbers with the Session Initiation Protocol (SIP)", 704 RFC 3824, June 2004. 706 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 707 RFC 3966, December 2004. 709 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 710 Resource Identifier (URI): Generic Syntax", STD 66, 711 RFC 3986, January 2005. 713 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 714 Security", RFC 4347, April 2006. 716 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 717 Authenticated Identity Management in the Session 718 Initiation Protocol (SIP)", RFC 4474, August 2006. 720 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 721 Description Protocol", RFC 4566, July 2006. 723 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 724 and RTP Control Protocol (RTCP) Packets over Connection- 725 Oriented Transport", RFC 4571, July 2006. 727 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 728 Transport Layer Security (TLS) Protocol in the Session 729 Description Protocol (SDP)", RFC 4572, July 2006. 731 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 732 Protocol (SIP)", RFC 4916, June 2007. 734 Appendix A. Policy Parameters for Session Peering 736 This informative section lists various types of parameters that 737 should be considered by implementers when deciding what configuration 738 variables to expose to system administrators or management stations, 739 as well as SSPs or federations of SSPs when discussing the technical 740 part of a session peering policy. 742 In the context of session peering, a policy can be defined as the set 743 of parameters and other information needed by an SSP to exchange 744 traffic with another peer. Some of the session policy parameters may 745 be statically exchanged and set throughout the lifetime of the 746 peering relationship. Others parameters may be discovered and 747 updated dynamically using by some explicit protocol mechanisms. 748 These dynamic parameters may be session-dependent, or the may apply 749 over multiple sessions or peers. 751 Various types of policy information may need to be discovered or 752 exchanged in order to establish session peering. At a minimum, a 753 policy should specify information related to session establishment 754 data in order to avoid session establishment failures. A policy may 755 also include information related to QoS, billing and accounting, 756 layer-3 related interconnect requirements which are out of the scope 757 of this document. 759 Some aspects of session peering policies must be agreed to and 760 manually implemented; they are static and are typically documented as 761 part of a business contract, technical document or agreement between 762 parties. For some parameters linked to protocol support and 763 capabilities, standard ways of expressing those policy parameters may 764 be defined among SSP and exchanged dynamically. For e.g., templates 765 could be created in various document formats so that it could be 766 possible to dynamically discover some of the domain policy. Such 767 templates could be initiated by implementers (for each software/ 768 hardware release, a list of supported RFCs, RFC parameters is 769 provided in a standard format) and then adapted by each SSP based on 770 its service description, server or device configurations and variable 771 based on peer relationships. 773 A.1. Categories of Parameters for VoIP Session Peering and 774 Justifications 776 The following list should be considered as an initial list of 777 "discussion topics" to be addressed by peers when initiating a VoIP 778 peering relationship. 780 o IP Network Connectivity: 781 Session peers should define how the IP network connectivity 782 between their respective SBEs and DBEs. While this is out of 783 scope of session peering, SSPs must agree on a common mechanism 784 for IP transport of session signaling and media. This may be 785 accomplish via private (e.g. IPVPN, IPsec, etc.) or public IP 786 networks. 788 o Media-related Parameters: 790 * Media Codecs: list of supported media codecs for audio, real- 791 time fax (version of T.38, if applicable), real-time text (RFC 792 4103), DTMF transport, voice band data communications (as 793 applicable) along with the supported or recommended codec 794 packetization rates, level of RTP payload redundancy, audio 795 volume levels, etc. 797 * Media Transport: level of support for RTP-RTCP [RFC3550], RTP 798 Redundancy (RTP Payload for Redundant Audio Data - [RFC2198]) , 799 T.38 transport over RTP, etc. 801 * Media variability at the Signaling path Border Elements: list 802 of media types supported by the various ingress points of a 803 peer's network. 805 * Other: support of the VoIP metric block as defined in RTP 806 Control Protocol Extended Reports [RFC3611] , etc. 808 o SIP: 810 * A session peering policy should include the list of supported 811 and required SIP RFCs, supported and required SIP methods 812 (including private p headers if applicable), error response 813 codes, supported or recommended format of some header field 814 values , etc. 816 * It should also be possible to describe the list of supported 817 SIP RFCs by various functional groupings. A group of SIP RFCs 818 may represent how a call feature is implemented (call hold, 819 transfer, conferencing, etc.), or it may indicate a functional 820 grouping as in [I-D.ietf-sip-hitchhikers-guide]. 822 o Accounting: 823 Methods used for call or session accounting should be specified. 824 An SSP may require a peer to track session usage. It is critical 825 for peers to determine whether the support of any SIP extensions 826 for accounting is a pre-requisite for SIP interoperability. In 827 some cases, call accounting may feed data for billing purposes but 828 not always: some operators may decide to use accounting as a 'bill 829 and keep' model to track session usage and monitor usage against 830 service level agreements. 831 [RFC3702] defines the terminology and basic requirements for 832 accounting of SIP sessions. A few private SIP extensions have 833 also been defined and used over the years to enable call 834 accounting between SSP domains such as the P-Charging* headers in 835 [RFC3455], the P-DCS-Billing-Info header in [RFC3603], etc. 837 o Performance Metrics: 838 Layer-5 performance metrics should be defined and shared between 839 peers. The performance metrics apply directly to signaling or 840 media; they may be used pro-actively to help avoid congestion, 841 call quality issues or call signaling failures, and as part of 842 monitoring techniques, they can be used to evaluate the 843 performance of peering exchanges. 844 Examples of SIP performance metrics include the maximum number of 845 SIP transactions per second on per domain basis, Session 846 Completion Rate (SCR), Session Establishment Rate (SER), etc. 847 Some SIP end-to-end performance metrics are defined in 848 [I-D.ietf-pmol-sip-perf-metrics]; a subset of these may be 849 applicable to session peering and interconnects. 850 Some media-related metrics for monitoring VoIP calls have been 851 defined in the VoIP Metrics Report Block, in Section 4.7 of 852 [RFC3611]. 854 o Security: 855 An SSP should describe the security requirements that other peers 856 must meet in order to terminate calls to its network. While such 857 a list of security-related policy parameters often depends on the 858 security models pre-agreed to by peers, it is expected that these 859 parameters will be discoverable or signaled in the future to allow 860 session peering outside SSP clubs. The list of security 861 parameters may be long and composed of high-level requirements 862 (e.g. authentication, privacy, secure transport) and low level 863 protocol configuration elements like TLS parameters. 864 The following list is not intended to be complete, it provides a 865 preliminary list in the form of examples: 867 * Call admission requirements: for some providers, sessions can 868 only be admitted if certain criteria are met. For example, for 869 some providers' networks, only incoming SIP sessions signaled 870 over established IPsec tunnels or presented to the well-known 871 TLS ports are admitted. Other call admission requirements may 872 be related to some performance metrics as described above. 873 Finally, it is possible that some requirements be imposed on 874 lower layers, but these are considered out of scope of session 875 peering. 877 * Call authorization requirements and validation: the presence of 878 a caller or user identity may be required by an SSP. Indeed, 879 some SSPs may further authorize an incoming session request by 880 validating the caller's identity against white/black lists 881 maintained by the service provider or users (traditional caller 882 ID screening applications or IM white list). 884 * Privacy requirements: an SSP may demand that its SIP messages 885 be securely transported by its peers for privacy reasons so 886 that the calling/called party information be protected. Media 887 sessions may also require privacy and some SSP policies may 888 include requirements on the use of secure media transport 889 protocols such as SRTP, along with some constraints on the 890 minimum authentication/encryption options for use in SRTP. 892 * Network-layer security parameters: this covers how IPsec 893 security associated may be established, the IPsec key exchange 894 mechanisms to be used and any keying materials, the lifetime of 895 timed Security Associated if applicable, etc. 897 * Transport-layer security parameters: this covers how TLS 898 connections should be established as described in Section 899 Section 5. 901 A.2. Summary of Parameters for Consideration in Session Peering 902 Policies 904 The following is a summary of the parameters mentioned in the 905 previous section. They may be part of a session peering policy and 906 appear with a level of requirement (mandatory, recommended, 907 supported, ...). 909 o IP Network Connectivity (assumed, requirements out of scope of 910 this document) 912 o Media session parameters: 914 * Codecs for audio, video, real time text, instant messaging 915 media sessions 917 * Modes of communications for audio (voice, fax, DTMF), IM (page 918 mode, MSRP) 920 * Media transport and means to establish secure media sessions 922 * List of ingress and egress DBEs where applicable, including 923 STUN Relay servers if present 925 o SIP 927 * SIP RFCs, methods and error responses 929 * headers and header values 931 * possibly, list of SIP RFCs supported by groups (e.g. by call 932 feature) 934 o Accounting 936 o Capacity Control and Performance Management: any limits on, or, 937 means to measure and limit the maximum number of active calls to a 938 peer or federation, maximum number of sessions and messages per 939 specified unit time, maximum number of active users or subscribers 940 per specified unit time, the aggregate media bandwidth per peer or 941 for the federation, specified SIP signaling performance metrics to 942 measure and report; media-level VoIP metrics if applicable. 944 o Security: Call admission control, call authorization, network and 945 transport layer security parameters, media security parameters 947 Author's Address 949 Jean-Francois Mule 950 CableLabs 951 858 Coal Creek Circle 952 Louisville, CO 80027 953 USA 955 Email: jf.mule@cablelabs.com 957 Full Copyright Statement 959 Copyright (C) The IETF Trust (2008). 961 This document is subject to the rights, licenses and restrictions 962 contained in BCP 78, and except as set forth therein, the authors 963 retain all their rights. 965 This document and the information contained herein are provided on an 966 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 967 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 968 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 969 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 970 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 971 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 973 Intellectual Property 975 The IETF takes no position regarding the validity or scope of any 976 Intellectual Property Rights or other rights that might be claimed to 977 pertain to the implementation or use of the technology described in 978 this document or the extent to which any license under such rights 979 might or might not be available; nor does it represent that it has 980 made any independent effort to identify any such rights. Information 981 on the procedures with respect to rights in RFC documents can be 982 found in BCP 78 and BCP 79. 984 Copies of IPR disclosures made to the IETF Secretariat and any 985 assurances of licenses to be made available, or the result of an 986 attempt made to obtain a general license or permission for the use of 987 such proprietary rights by implementers or users of this 988 specification can be obtained from the IETF on-line IPR repository at 989 http://www.ietf.org/ipr. 991 The IETF invites any interested party to bring to its attention any 992 copyrights, patents or patent applications, or other proprietary 993 rights that may cover technology that may be required to implement 994 this standard. Please address the information to the IETF at 995 ietf-ipr@ietf.org.