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