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