idnits 2.17.1 draft-ietf-speermint-requirements-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 756. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-Malas-sip-performance - is the name correct? == Outdated reference: A later version (-06) exists of draft-gurbani-sip-domain-certs-03 -- No information found for draft-ietf-enum-experiences - is the name correct? == Outdated reference: A later version (-05) exists of draft-wing-media-security-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 3603 (Obsoleted by RFC 5503) -- 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: 4 errors (**), 0 flaws (~~), 5 warnings (==), 15 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 Expires: April 26, 2007 October 23, 2006 6 SPEERMINT Requirements for SIP-based VoIP Interconnection 7 draft-ietf-speermint-requirements-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 26, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes high-level guidelines and general 41 requirements for Session PEERing for Multimedia INTerconnect. It 42 also defines a minimum set of requirements applicable to session 43 peering for Voice over IP interconnects. It is intended to become 44 best current practices based on the use cases discussed in the 45 speermint working group. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. General Requirements . . . . . . . . . . . . . . . . . . . . . 5 52 4. Requirements for SIP-based VoIP Interconnection . . . . . . . 8 53 4.1. DNS, Call Addressing Data (CAD) and ENUM . . . . . . . . . 8 54 4.2. Minimum set of SIP-SDP-related requirements . . . . . . . 8 55 4.3. Media-related Requirements . . . . . . . . . . . . . . . . 9 56 4.4. Security Requirements . . . . . . . . . . . . . . . . . . 9 57 4.4.1. Security in today's VoIP networks . . . . . . . . . . 9 58 4.4.2. TLS Considerations for session peering . . . . . . . . 10 59 5. Annex A - List of Policy Parameters for VoIP 60 Interconnections . . . . . . . . . . . . . . . . . . . . . . . 12 61 5.1. Categories of parameters and Justifications . . . . . . . 12 62 5.2. Summary of Parameters for Consideration in Session 63 Peering Policies . . . . . . . . . . . . . . . . . . . . . 14 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 Intellectual Property and Copyright Statements . . . . . . . . . . 22 72 1. Introduction 74 The Session PEERing for Multimedia INTerconnect (SPEERMINT) Working 75 Group is chartered to focus on architectures to identify, signal, and 76 route delay-sensitive communication sessions. These sessions use the 77 Session Initiation Protocol (SIP) protocol to enable peering between 78 two or more administrative domains over IP networks. 80 This document describes high-level guidelines and general 81 requirements for session peering; these requirements are applicable 82 to any type of multimedia session peering such as Voice over IP 83 (VoIP), video telephony, and instant messaging. The document also 84 defines a minimum set of requirements for a sub-set of the session 85 peering use cases: VoIP interconnects. 87 The intent of this version of this document is to describe what 88 mechanisms are used for establishing SIP session peering with a 89 special look at VoIP interconnects, and in doing so, it defines some 90 of requirements associated with the secure establishment of VoIP 91 interconnects between a large number of peers. 92 The primary focus is on the requirements applicable to the boundaries 93 of layer-5 SIP networks: SIP UA or end-device requirements are 94 considered out of scope. 95 It is also not the goal of this document to mandate any particular 96 use of any IETF protocols to establish session peering by users or 97 service providers. However, when protocol mechanisms are used, the 98 document aims at providing guidelines or best current practices on 99 how they should be implemented, or configured and enabled in order to 100 facilitate session peering. 102 Finally, a list of parameters for the definition of a session peering 103 policy is provided in an informative annex. It should be considered 104 as an example of the information a Voice Service Provider, or 105 Application Service Provider may require in order to connect to 106 another using SIP. 108 2. Terminology 110 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 111 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 112 and "OPTIONAL" are to be interpreted as described in RFC 2119 113 [RFC2119]. 115 This specification makes use of terms defined in 116 [I-D.ietf-speermint-terminology], the Session Description Protocol 117 (SDP) [RFC4566] and the Session Initiation Protocol (SIP) [RFC3261]. 118 We also use the terms Voice Service Provider (VSP) and Application 119 Service Provider (ASP) as defined in [I-D.ietf-ecrit-requirements]. 121 3. General Requirements 123 The following section defines general guidelines and requirements 124 applicable to session peering for multimedia sessions. 126 o Session peering should be independent of lower layers. The 127 mechanisms used to establish session peering SHOULD accommodate 128 diverse supporting lower layers. 130 Motivations: 131 Session peering is about layer 5 mechanisms. It should not matter 132 whether lower layers rely on the public Internet or are 133 implemented by private L3 connectivity, using firewalls or L2/L3 134 Virtual Private Networks (VPNs), IPSec tunnels or Transport Layer 135 Security (TLS) connections [RFC3546]... 137 o Session Peering Policies and Extensibility: 138 Policies developed for session peering SHOULD be flexible and 139 extensible to cover existing and future session peering models. 140 It is also RECOMMENDED that policies be published via local 141 configuration choices in a distributed system like DNS rather than 142 in a centralized system like a 'peering registry'. 143 In the context of session peering, a policy is defined as the set 144 of parameters and other information needed by one VSP/ASP to 145 connect to another. Some of the session policy parameters may be 146 statically exchanged and set throughout the lifetime of the 147 peering relationship. Others parameters may be discovered and 148 updated dynamically using by some explicit protocol mechanisms. 149 These dynamic parameters may also relate to a VSP/ASP's session- 150 dependent or session independent policies as defined in 151 [I-D.ietf-sipping-session-policy-framework]. 153 Motivations: 154 It is critical that the solutions be flexible and extensible given 155 the various emerging models: layer 5 peering may involve open 156 federations of SIP proxies, or closed environments with systems 157 that only accept incoming calls from selected peers based on a set 158 of bilateral trust relationships. Federations may also be based 159 on memberships in peering fabrics or voice service provider clubs, 160 etc. Session peering may be direct or indirect. 161 The maintenance of the "system" should scale beyond simple lists 162 of peering partners. In particular, it must incorporate 163 aggregation mechanisms which avoid O(n^2) scaling (where n is the 164 number of participating peers). The distributed management of the 165 DNS is a good example for the scalability of this approach. 167 o Administrative and Technical Policies: 168 Various types of policy information may need to be discovered or 169 exchanged in order to establish session peering. At a minimum, a 170 policy SHOULD specify information related to call addressing data 171 in order to avoid session establishment failures. A policy MAY 172 also include information related to QoS, billing and accounting, 173 layer-3 related interconnect requirements which are out of the 174 scope of this document. 176 Motivations: 177 The reasons for declining or accepting incoming calls from a 178 prospective peering partner can be both administrative 179 (contractual, legal, commercial, or business decisions) and 180 technical (certain QoS parameters, TLS keys, domain keys, ...). 181 The objectives are to provide a baseline framework to define, 182 publish and optionally retrieve policy information so that a 183 session establishment does not need to be attempted to know that 184 imcompatible policy parameters will cause the session to fail 185 (this was originally referred to as "no blocked calls"). 187 o URIs and Domain-Based Peering Context: 188 Call Addressing Data SHOULD rely on URIs (Uniform Resource 189 Identifiers, RFC 3986 [RFC3986]) for call routing and SIP URIs 190 SHOULD be preferred over tel URIs (RFC 3966 [RFC3966]). Although 191 the initial call addressing data may be based on E.164 numbers for 192 voice interconnects, a generic peering methodology SHOULD NOT rely 193 on such E.164 numbers. 195 Motivations: 196 Telephone numbers commonly appear in the username portion of a SIP 197 URI. When telephone numbers are in tel URIs, SIP requests cannot 198 be routed in accordance with the traditional DNS resolution 199 procedures standardized for SIP as indicated in RFC 3824 200 [RFC3824]. Furthermore, we assume that all SIP URIs with the same 201 domain-part share the same set of peering policies, thus the 202 domain of the SIP URI may be used as the primary key to any 203 information regarding the reachability of that SIP URI. 205 o URI Reachability and Minimal additional cost on call initiation: 206 Based on a well-known URI (for e.g. sip, pres, or im URIs), it 207 MUST be possible to determine whether the domain servicing the URI 208 (VSP/ASP) allows for session peering, and if it does, it SHOULD be 209 possible to locate and retrieve the domain's policy and signaling 210 functions. For example, an originating service provider must be 211 able to determine whether a SIP URI is open for direct 212 interconnection without requiring to initiate a SIP request. 213 Furthermore, since each call setup implies the execution of any 214 proposed algorithm, the establishment of a SIP session via peering 215 SHOULD incur minimal overhead and delay, and employ caching 216 wherever possible to avoid extra protocol round trips. 218 Motivations: 219 This requirement is important as unsuccessful call attempts are 220 highly undesirable since they can introduce high delays due to 221 timeouts and can act as an unintended denial of service attack 222 (e.g., by repeated TLS handshakes). There should be a high 223 probability of successful call completion for policy-conforming 224 peers. 226 o Variability of the Call Address Data: 227 A terminating VSP/ASP or user SHOULD be able to indicate its 228 domain ingress points (Signaling Path Border Element(s)) based on 229 the identity of the originating VSP/ASP or user. 230 The mechanisms recommended for the use and resolution of the call 231 addressing data SHOULD allow for variability or customization of 232 the response(s) depending on various elements, such as the 233 identity of the originating or terminating user or user domain. 235 4. Requirements for SIP-based VoIP Interconnection 237 This section defines some requirements for SIP-based VoIP 238 Interconnection. It should be considered as the minimal set of 239 requirements to be implemented to perform SIP VoIP interconnects. 241 4.1. DNS, Call Addressing Data (CAD) and ENUM 243 Call Addressing Data can be derived from various mechanisms available 244 to the user, such as ENUM when the input is a telephone number, or 245 other DNS queries using SRV and NAPTR resource records when the entry 246 is a SIP URI for example. The SPEERMINT Working Group is focused on 247 the use of CAD. 249 The following requirements are best current practices for VoIP 250 session peering: 252 o SIP URIs SHOULD be preferred over tel URIs when establishing a SIP 253 session for voice interconnects. 255 o The recommendations defined in [RFC3824] SHOULD be followed by 256 implementers when using E.164 numbers with SIP, and by authors of 257 NAPTR records for ENUM for records with an 'E2U+sip' service 258 field. Other ENUM implementation issues and experiences are 259 described in [I-D.ietf-enum-experiences] that may be relevant for 260 VoIP interconnects using ENUM. 262 o The use of DNS domain names and hostnames is RECOMMENDED in SIP 263 URIs and they MUST be resolvable on the public Internet. 265 o The DNS procedures specified in [RFC3263] SHOULD be followed to 266 resolve a SIP URI into a reachable host (IP address and port), and 267 transport protocol. Note that RFC 3263 relies on DNS SRV 268 [RFC2782] and NAPTR Resource Records [RFC2915]. 270 4.2. Minimum set of SIP-SDP-related requirements 272 The main objective of VoIP interconnects being the establishment of 273 successful SIP calls between peer VSPs/ASPs, this section provides a 274 minimum set of SIP-related requirements. 276 o The Core SIP Specifications as defined in [RFC3261] and 277 [I-D.ietf-sip-hitchhikers-guide] MUST be supported by Signaling 278 Path Border Elements and any other SIP implementations involved in 279 session peering. 280 Justifications: 281 The specifications contained in the Core SIP group provide the 282 fundamental and basic mechanisms required to enable VoIP 283 interconnects. This includes: the SIP protocol for session 284 establishment and its updates such as RFC 3853 and RFC 4320, SDP 285 [RFC4566] and its Offer/Answer model [RFC3264] for VoIP media 286 session descriptions and codec negotiations, SIP Asserted Identity 287 for caller ID services, and various other extensions to support 288 NAT traversal, etc. 290 o The following RFCs SHOULD be supported: Reliability of Provisional 291 Responses in SIP - PRACK [RFC3262], the SIP UPDATE method (for 292 e.g. for codec changes during a session) [RFC3311], the Reason 293 header field [RFC3326]. 295 In the context of session peering where peers desire to maximize the 296 chances of successful call establishment, the recommendations 297 contained in RFC 3261 regarding the use of the Supported and Require 298 headers MUST be followed. Signaling Path Border Elements SHOULD 299 include the supported SIP extensions in the Supported header and the 300 use of the Require header must be configurable on a per target domain 301 basis in order to match a network peer policy and to maximize 302 interoperability. 304 4.3. Media-related Requirements 306 VSPs engaged in session peering SHOULD support of compatible codecs 307 and include media-related parameters in their domain's policy. 308 Transcoding SHOULD be avoided by proposing commonly agreed codecs. 310 Motivations: The media capabilities of a VSP's network are either a 311 property of the SIP end-devices, or, a combination of the property of 312 end-devices and Data Path Border Elements that may provide media 313 transcoding. The choice of one or more common codecs for VoIP 314 sessions between VSPs is therefore outside the scope of speermint. 315 Indeed, as stated in introduction, requirements applicable to end- 316 devices of a VSP are considered out of scope. A list of media- 317 related policy parameters are provided in the informative Section 5. 319 4.4. Security Requirements 321 4.4.1. Security in today's VoIP networks 323 In today's VoIP deployments, various approaches exist to secure 324 exchanges between VSPs/ASPs. Signaling and media security are the 325 two primary topics for consideration in most deployments. A number 326 of transport-layer and network-layer mechanisms are widely used by 327 some categories of VSPs: TLS in the enterprise networks for 328 applications such as VoIP and secure Instant Messaging, IPSec and 329 L2/L3 VPNs in some VSP networks where there is a desire to secure all 330 signaling and media traffic at or below the IP layer. Media level 331 security is not widely deployed for RTP, even though it is in use in 332 few deployments where the privacy of voice communications is 333 critical. 334 A detailed security threat analysis of session peering exchanges 335 should provide more guidance on what scalable and efficient methods 336 should be used to help mitigate the the main security risks in large- 337 scale session peering. 339 A recent IETF BoF at IETF 66 (rtpsec) was organized to analyze SIP 340 requirements for SRTP keying; a number of security requirements for 341 VoIP were discussed. A few Internet-Drafts have since been released 342 and focus on media security requirements for SIP sessions 343 ([I-D.ietf-wing-media-security-requirements]). Some of these 344 scenarios may be applicable to interdomain VSP/ASP session peering or 345 they may be augmented in the future by interdomain scenarios. 347 4.4.2. TLS Considerations for session peering 349 The remaining of Section 4 covers some details on how TLS could be 350 deployed and used between 2 VSPs/ASPs to secure SIP exchanges. The 351 intent is to capture what two VSPs/ASPs should discuss and agree on 352 in order to establish TLS connections for SIP session peering. 354 1. Peers SHOULD agree on one or more Certificate Authorities 355 (CAs) to trust for securing session peering exchanges. 356 Motivations: 357 A VSP/ASP should have control over which root CA it trusts for SIP 358 communications. This may imply creating a certificate trust list 359 and including the peer's CA for each authorized domain. This 360 requirement allows for the initiating side to verify that the 361 server certificate chains up to a trusted root CA. This also 362 means that SIP servers SHOULD allow the configuration of a 363 certificate trust list in order to allow a VSP/ASP to control 364 which peer's CAs are trusted for TLS connections. Note that these 365 considerations seem to be around two themes: one is trusting a 366 root, the other is trusting intermediate CAs. 368 2. Peers SHOULD indicate whether their domain policies require 369 proxy servers to inspect and verify the identity provided in SIP 370 requests as defined in [RFC4474]. 372 3. SIP servers involved in the secure session establishment over 373 TLS MUST have valid X.509 certificates and MUST be able to receive 374 a TLS connection on a well-known port. 376 4. The following TLS/SIP Protocol parameters SHOULD be agreed 377 upon as part of session peering policies: the version of TLS 378 supported by Signaling Border Elements (TLSv1, TLSv1.1), the SIP 379 TLS port (default 5061), the server-side session timeout (default 380 300 seconds), the list of supported or recommended ciphersuites, 381 and the list of trusted root CAs. 383 5. SIP servers involved in the session establishment over TLS 384 MUST verify and validate the client certificates: the client 385 certificate MUST contain a DNS or URI choice type in the 386 subjectAltName which corresponds to the domain asserted in the 387 host portion of the URI contained in the From header. It is also 388 recommended that VSPs/ASPs convey the domain identity in the 389 certificates using both a canonical name of the SIP server(s) and 390 the SIP URI for the domain as described in section 4 of 391 [I-D.gurbani-sip-domain-certs]. On the client side, it is also 392 critical for the TLS client to authenticate the server as defined 393 in [RFC3261] and in section 9 of draft-ietf-sip-certs-01.txt. 395 6. A session peering policy SHOULD include details on SIP session 396 establishment over TLS if TLS is supported. 398 5. Annex A - List of Policy Parameters for VoIP Interconnections 400 This informative annex lists the various types of parameters that 401 should be considered when discussing the technical aspects of a VoIP 402 Peering policy . 404 5.1. Categories of parameters and Justifications 406 It is intended as an initial list of topics that should be addressed 407 by peers when establishing a VoIP peering relationship. 409 o IP Network Connectivity: 410 It is assumed that IP network connectivity exists between peers. 411 While this is out of scope of session peering, VSPs must agree 412 upon a common mechanism for IP transport of Layer 5 session 413 signaling and media. This may be accomplish via private (e.g. 414 IPVPN, IPSEC, etc.) or public IP networks. 416 o Media-related Parameters: 418 * Media Codecs: list of supported media codecs for audio, real- 419 time fax (version of T.38, if applicable), real-time text (RFC 420 4103), DTMF transport, voice band data communications (as 421 applicable) along with the supported or recommended codec 422 packetization rates, level of RTP paylod redundancy, audio 423 volume levels, etc. 425 * Media Transport: level of support for RTP-RTCP [RFC3550], RTP 426 Redundancy (RTP Payload for Redundant Audio Data - [RFC2198]) , 427 T.38 transport over RTP, etc. 429 * Other: support of the VoIP metric block as defined in RTP 430 Control Protocol Extended Reports [RFC3611] , etc. 432 o SIP: 434 * A session peering policy SHOULD include the list of supported 435 and required SIP RFCs, supported and required SIP methods 436 (including p headers if applicable), error response codes, 437 supported or recommended format of some header field values , 438 etc. 440 * It should also be possible to describe the list of supported 441 SIP RFCs by various functional groupings. A group of SIP RFCs 442 may represent how a call feature is implemented (call hold, 443 transfer, conferencing, etc.), or it may indicate a functional 444 grouping as in [I-D.ietf-sip-hitchhikers-guide]. 446 o Accounting: 447 Call accounting may be required for tracking session usage on a 448 peer's network. It is critical for peers to determine whether the 449 support of any SIP extensions for accounting is a pre-requisite 450 for SIP interoperability. In some cases, call accounting may feed 451 data for billing purposes but not always: some operators may 452 decide to use accounting as a 'bill and keep' model to track 453 session usage and monitor usage against service level agreements. 454 [RFC3702] defines the terminology and basic requirements for 455 accounting of SIP sessions. A few private SIP extensions have 456 also been defined and used over the years to enable call 457 accounting between VSP domains such as the P-Charging* headers in 458 [RFC3455], the P-DCS-Billing-Info header in [RFC3603], etc. 460 o Performance Metrics: 461 Layer-5 performance metrics should be defined and shared between 462 peers. The performance metrics apply directly to signaling or 463 media; they may be used pro-actively to help avoid congestion, 464 call quality issues or call signaling failures, and as part of 465 monitoring techniques, they can be used to evaluate the 466 performance of peering exchanges. 467 Examples of SIP performance metrics include the maximum number of 468 SIP transactions per second on per domain basis, Session 469 Completion Rate (SCR), Session Establishment Rate (SER), etc. 470 Some SIP end-to-end performance metrics are defined in 471 [I-D.Malas-sip-performance]; a subset of these may be applicable 472 to session peering and interconnects. 473 Some media-related metrics for monitoring VoIP calls have been 474 defined in the VoIP Metrics Report Block, in Section 4.7 of 475 [RFC3611]. 477 o Security: 478 A VSP/ASP SHOULD describe the security requirements that other 479 peers must meet in order to terminate calls to its network. While 480 such a list of security-related policy parameters often depends on 481 the security models pre-agreed to by peers, it is expected that 482 these parameters will be discoverable or signaled in the future to 483 allow session peering outside VSP clubs. The list of security 484 parameters may be long and composed of high-level requirements 485 (e.g. authentication, privacy, secure transport) and low level 486 protocol configuration elements like TLS parameters. 487 The following list is not intended to be complete, it provides a 488 preliminary list in the form of examples: 490 * Call admission requirements: for some providers, sessions can 491 only be admitted if certain criteria are met. For example, for 492 some providers' networks, only incoming SIP sessions signaled 493 over established IPSec tunnels or presented to the well-known 494 TLS ports are admitted. Other call admission requirements may 495 be related to some performance metrics as descrived above. 496 Finally, it is possible that some requiremetns be imposed on 497 lower layers, but these are considered out of scope of session 498 peering. 500 * Call authorization requirements and validation: the presence of 501 a caller or user identity MAY be required by a VSP/ASP. 502 Indeed, some VSPs/ASPs may further authorize an incoming 503 session request by validating the caller's identity against 504 white/black lists maintained by the service provider or users 505 (traditional caller ID screening applications or IM white 506 list). 508 * Privacy requirements: a VSP/ASP MAY demand that its SIP 509 messages be securely transported by its peers for privacy 510 reasons so that the calling/called party information be 511 protected. Media sessions may also require privacy and some 512 ASP/VSP policies may include requirements on the use of secure 513 media transport protocols such as sRTP, along with some 514 contraints on the minimum authentication/encryption options for 515 use in sRTP. 517 * Network-layer security parameters: this covers how IPSec 518 security associated may be established, the IPSec key exchange 519 mechanisms to be used and any keying materials, the lifetime of 520 timed Security Associated if applicable, etc. 522 * Transport-layer security parameters: this covers how TLS 523 connections should be established as described in Section 4.4.2 525 5.2. Summary of Parameters for Consideration in Session Peering 526 Policies 528 The following is a summary of the parameters mentioned in the 529 previous section. They may be part of a session peering policy and 530 appear with a level of requirement (mandatory, recommended, 531 supported, ...). 533 o IP Network Connectivity (assumed, requirements out of scope of 534 this document) 536 o Media session parameters: 538 * Codecs for audio, video, real time text, instant messaging 539 media sessions 541 * Modes of communications for audio (voice, fax, DTMF), IM (page 542 mode, MSRP) 544 * Media transport and means to establish secure media sessions 546 o SIP 548 * SIP RFCs, methods and error responses 550 * headers and header values 552 * possibly, list of SIP RFCs supported by groups (e.g. by call 553 feature) 555 o Accounting 557 o Performance Metrics: SIP signaling performance metrics; media- 558 level VoIP metrics. 560 o Security: Call admission control, call authorization, network and 561 transport layer security parameters, media security parameters 563 6. Acknowledgments 565 This document is a work-in-progress and it is based on the input and 566 contributions made by a large number of people in the SPEERMINT 567 working group, including: Scott Brim, Mike Hammer, Richard Shocky, 568 Henry Sinnreich, Richard Stastny, Patrik Faltstrom, Otmar Lendl, 569 Daryl Malas, Dave Meyer, Jason Livingood, Bob Natale, Brian Rosen, 570 Eric Rosenfeld and Adam Uzelac. 572 7. Security Considerations 574 Securing session peering communications involves numerous protocol 575 exchanges, first and foremost, the securing of SIP signaling and 576 media sessions. The security considerations contained in RF 3261, 577 RFC 4474 are applicable to the SIP protocol exchanges. A number of 578 security considerations are also described in Section 4.4 for VoIP 579 Interconnects. 581 8. References 583 8.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 8.2. Informative References 590 [I-D.Malas-sip-performance] 591 Malas, D., "SIP End-to-End Performance Metrics", 592 September 2006. 594 [I-D.gurbani-sip-domain-certs] 595 Gurbani, V., Jeffrey, A., and S. Lawrence, "Domain 596 Certificates in the Session Initiation Protocol (SIP)", 597 draft-gurbani-sip-domain-certs-03 (work in progress), 598 August 2006. 600 [I-D.ietf-ecrit-requirements] 601 Schulzrinne, H. and R. Marshall, "Requirements for 602 Emergency Context Resolution with Internet Technologies", 603 August 2006. 605 [I-D.ietf-enum-experiences] 606 Conroy, L. and K. Fujiwara, "ENUM Implementation Issues 607 and Experiences", June 2006. 609 [I-D.ietf-sip-hitchhikers-guide] 610 Rosenberg, J., "A Hitchhikers Guide to the Session 611 Initiation Protocol (SIP)", October 2006. 613 [I-D.ietf-sipping-session-policy-framework] 614 Hilt, V., "A Framework for Session Initiation Protocol 615 (SIP) Session Policies", 616 draft-ietf-sipping-session-policy-framework-01 (work in 617 progress), June 2006. 619 [I-D.ietf-speermint-terminology] 620 Meyer, R., "SPEERMINT Terminology", September 2006. 622 [I-D.ietf-wing-media-security-requirements] 623 Wing, D., Fries, S., and H. Tschofenig, "A Framework for 624 Session Initiation Protocol (SIP) Session Policies", 625 draft-wing-media-security-requirements-00 (work in 626 progress), October 2006. 628 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 629 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 630 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 631 September 1997. 633 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 634 specifying the location of services (DNS SRV)", RFC 2782, 635 February 2000. 637 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 638 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 640 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 641 A., Peterson, J., Sparks, R., Handley, M., and E. 642 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 643 June 2002. 645 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 646 Provisional Responses in Session Initiation Protocol 647 (SIP)", RFC 3262, June 2002. 649 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 650 Protocol (SIP): Locating SIP Servers", RFC 3263, 651 June 2002. 653 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 654 with Session Description Protocol (SDP)", RFC 3264, 655 June 2002. 657 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 658 UPDATE Method", RFC 3311, October 2002. 660 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 661 Header Field for the Session Initiation Protocol (SIP)", 662 RFC 3326, December 2002. 664 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 665 Header (P-Header) Extensions to the Session Initiation 666 Protocol (SIP) for the 3rd-Generation Partnership Project 667 (3GPP)", RFC 3455, January 2003. 669 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 670 and T. Wright, "Transport Layer Security (TLS) 671 Extensions", RFC 3546, June 2003. 673 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 674 Jacobson, "RTP: A Transport Protocol for Real-Time 675 Applications", STD 64, RFC 3550, July 2003. 677 [RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation 678 Protocol (SIP) Proxy-to-Proxy Extensions for Supporting 679 the PacketCable Distributed Call Signaling Architecture", 680 RFC 3603, October 2003. 682 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 683 Protocol Extended Reports (RTCP XR)", RFC 3611, 684 November 2003. 686 [RFC3702] Loughney, J. and G. Camarillo, "Authentication, 687 Authorization, and Accounting Requirements for the Session 688 Initiation Protocol (SIP)", RFC 3702, February 2004. 690 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 691 E.164 numbers with the Session Initiation Protocol (SIP)", 692 RFC 3824, June 2004. 694 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 695 RFC 3966, December 2004. 697 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 698 Resource Identifier (URI): Generic Syntax", STD 66, 699 RFC 3986, January 2005. 701 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 702 Authenticated Identity Management in the Session 703 Initiation Protocol (SIP)", RFC 4474, August 2006. 705 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 706 Description Protocol", RFC 4566, July 2006. 708 Author's Address 710 Jean-Francois Mule 711 CableLabs 712 858 Coal Creek Circle 713 Louisville, CO 80027 714 USA 716 Email: jf.mule@cablelabs.com 718 Full Copyright Statement 720 Copyright (C) The Internet Society (2006). 722 This document is subject to the rights, licenses and restrictions 723 contained in BCP 78, and except as set forth therein, the authors 724 retain all their rights. 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 729 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 730 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 731 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 Intellectual Property 736 The IETF takes no position regarding the validity or scope of any 737 Intellectual Property Rights or other rights that might be claimed to 738 pertain to the implementation or use of the technology described in 739 this document or the extent to which any license under such rights 740 might or might not be available; nor does it represent that it has 741 made any independent effort to identify any such rights. Information 742 on the procedures with respect to rights in RFC documents can be 743 found in BCP 78 and BCP 79. 745 Copies of IPR disclosures made to the IETF Secretariat and any 746 assurances of licenses to be made available, or the result of an 747 attempt made to obtain a general license or permission for the use of 748 such proprietary rights by implementers or users of this 749 specification can be obtained from the IETF on-line IPR repository at 750 http://www.ietf.org/ipr. 752 The IETF invites any interested party to bring to its attention any 753 copyrights, patents or patent applications, or other proprietary 754 rights that may cover technology that may be required to implement 755 this standard. Please address the information to the IETF at 756 ietf-ipr@ietf.org. 758 Acknowledgment 760 Funding for the RFC Editor function is currently provided by the 761 Internet Society.