idnits 2.17.1 draft-garcia-sipping-3gpp-reqs-00.txt: ** The Abstract section seems to be numbered -(957): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1304): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 188 has weird spacing: '...ce. The addre...' == Line 343 has weird spacing: '...user is authe...' == Line 355 has weird spacing: '...ains an ident...' == Line 977 has weird spacing: '...terwork with ...' == Line 989 has weird spacing: '...to meet the a...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 19 looks like a reference -- Missing reference section? '3' on line 1206 looks like a reference -- Missing reference section? '2' on line 59 looks like a reference -- Missing reference section? '4' on line 1029 looks like a reference -- Missing reference section? '5' on line 133 looks like a reference -- Missing reference section? '6' on line 177 looks like a reference -- Missing reference section? '7' on line 972 looks like a reference -- Missing reference section? '15' on line 461 looks like a reference -- Missing reference section? '8' on line 565 looks like a reference -- Missing reference section? '21' on line 565 looks like a reference -- Missing reference section? '9' on line 596 looks like a reference -- Missing reference section? '10' on line 607 looks like a reference -- Missing reference section? '39' on line 629 looks like a reference -- Missing reference section? '11' on line 659 looks like a reference -- Missing reference section? '12' on line 689 looks like a reference -- Missing reference section? '13' on line 664 looks like a reference -- Missing reference section? '14' on line 695 looks like a reference -- Missing reference section? '22' on line 753 looks like a reference -- Missing reference section? '36' on line 901 looks like a reference -- Missing reference section? '16' on line 934 looks like a reference -- Missing reference section? '17' on line 971 looks like a reference -- Missing reference section? '19' on line 984 looks like a reference -- Missing reference section? '37' on line 984 looks like a reference -- Missing reference section? '38' on line 984 looks like a reference -- Missing reference section? '18' on line 988 looks like a reference -- Missing reference section? '20' on line 989 looks like a reference -- Missing reference section? '23' on line 1029 looks like a reference -- Missing reference section? '24' on line 1114 looks like a reference -- Missing reference section? '31' on line 1030 looks like a reference -- Missing reference section? '32' on line 1150 looks like a reference -- Missing reference section? '25' on line 1152 looks like a reference -- Missing reference section? '27' on line 1169 looks like a reference -- Missing reference section? '28' on line 1172 looks like a reference -- Missing reference section? '29' on line 1173 looks like a reference -- Missing reference section? '33' on line 1211 looks like a reference -- Missing reference section? '34' on line 1211 looks like a reference -- Missing reference section? '35' on line 1211 looks like a reference -- Missing reference section? '30' on line 1251 looks like a reference -- Missing reference section? '26' on line 1309 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 41 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia / Ericsson 3 Internet Draft D. Mills / Vodafone 4 Document: G. Bajko / Nokia 5 Network Working Group G. Mayer / Siemens 6 Date: October 2001 F. Derome / Alcatel 7 Expires: April 2002 H. Shieh / AWS 8 A. Allen / Motorola 9 S. Chotai / BT 10 K. Drage / Lucent 11 J. Bharatia / Nortel 13 3GPP requirements on SIP 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 The distribution of this memo is unlimited. 37 1. Abstract 39 The 3rd Generation Partnership Project (3GPP) has selected SIP [3] 40 as the session establishment protocol for the 3GPP IP Multimedia 41 Core Network Subsystem (IM CN Subsystem). 43 Although SIP is a protocol that fulfills most of the requirements to 44 establish a session in an IP network, the SIP protocol suite has 45 never been evaluated against the specific 3GPP requirements for 46 operation in a cellular network. 48 Network Working Group Expiration 04/30/02 1 49 3GPP requirements on SIP October 2001 51 In this document we express the requirements identified by 3GPP to 52 support SIP for IM CN Subsystem in cellular networks. 54 2. Conventions used in this document 56 This document does not specify any protocol of any kind. Therefore, 57 the use of te key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 58 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 59 "OPTIONAL" in this document, as described in RFC-2119 [2], does not 60 apply. 62 3. Table of Contents 64 Status of this Memo................................................1 65 1. Abstract........................................................1 66 2. Conventions used in this document...............................2 67 3. Table of Contents...............................................2 68 4. Introduction....................................................2 69 5. Overview of the 3GPP IM CN Subsystem............................3 70 6. 3GPP Requirements on SIP........................................5 71 6.1 General requirements...........................................5 72 6.2 SIP outbound proxy in the visited network......................6 73 6.3 Registration...................................................7 74 6.4 De-registration................................................8 75 6.5 Compression of SIP signaling...................................9 76 6.6 QoS requirements related to SIP...............................11 77 6.7 Prevention of theft of service................................11 78 6.8 Radio resource authorization..................................12 79 6.9 Prevention of denial of service...............................12 80 6.10 Identification of users......................................12 81 6.11 Identifiers used for routing.................................14 82 6.12 Hiding requirements..........................................14 83 6.13 Cell-ID......................................................14 84 6.14 Release of sessions..........................................15 85 6.15 Routing of SIP messages......................................15 86 6.16 Emergency sessions...........................................17 87 6.17 Identities on session establishment..........................18 88 6.18 Charging.....................................................19 89 6.19 IPv6.........................................................19 90 6.20 General support of additional capabilities...................19 91 6.21 Three-way handshake in the session description negotiation...19 92 6.22 Security Model...............................................20 93 6.23 Access Domain Security.......................................21 94 6.24 Network Domain Security......................................25 95 7. Security considerations........................................25 96 8. Author's Addresses.............................................25 97 9. Acknowledgments................................................27 98 10. References....................................................27 99 Full Copyright Statement..........................................29 101 4. Introduction 103 Network Working Group Expiration 04/30/02 2 104 3GPP requirements on SIP October 2001 106 3GPP has selected SIP [3] as the protocol to establish and tear down 107 multimedia sessions in the IP Multimedia Core Network Subsystem (IM 108 CN Subsystem). A description of the IM CN Subsystem can be found in 109 [4]. A comprehensive set of session flows can be found in [5]. 111 This document is an effort to define the requirements applicable to 112 the usage of the SIP protocol suite in cellular networks, and 113 particularly in the 3GPP IM CN Subsystem. 115 The rest of this document is structured as follows: 117 Section 5 offers an overview of the 3GPP IM CN Subsystem. Readers 118 who are not familiar with it should carefully read this section. 120 Section 6 contains the 3GPP requirements to SIP. Requirements are 121 grouped by categories. Some requirements include a statement on 122 possible solutions that would be able to fulfill the requirement. 123 Note also that, as a particular requirement might be fulfilled by 124 different solutions, not all the solutions might have an impact on 125 SIP. 127 5. Overview of the 3GPP IM CN Subsystem 129 This section gives the reader an overview of the 3GPP IM CN 130 Subsystem. It is not intended to be comprehensive. But it provides 131 enough information to understand the basis of the 3GPP IM CN 132 Subsystem. Readers are encouraged to find a more detailed 133 description in [4], [5] and [6]. 135 For a particular cellular device, the 3GPP IM CN Subsystem network 136 is further decomposed in a home network and a visited network. 138 An IM CN Subsystem subscriber belongs to his or her home network. 139 Services are triggered and may be executed in the home network. One 140 or more SIP servers are deployed in the SIP home network to support 141 the IP Multimedia Subsystem. Among those SIP servers, there is a SIP 142 serving proxy, which is also acting as a SIP registrar. 143 Authentication/Authorization servers may be part of the home network 144 as well. Users are authenticated in the home network. 146 The visited network contains a SIP outbound proxy to support the UA. 147 The SIP outbound proxy in the visited network may translate locally 148 dialed digits into international format, detect emergency sessions, 149 maintain security associations between itself and the terminals, and 150 interwork with the resource management in the packet network. 152 The SIP outbound proxy is assigned after the mobile has connected to 153 the access network. Once this proxy is assigned, it does not change 154 while the mobile remains connected to the access network. Thus the 155 mobile can move freely within the access network without SIP 156 outbound proxy reassignment. 158 Network Working Group Expiration 04/30/02 3 159 3GPP requirements on SIP October 2001 161 The home network may support also a SIP entry proxy. This node may 162 act as the first entry point for SIP signaling to the home network 163 and may decide (with the help of location servers) which SIP 164 registrar server to assign to a particular user. Typically the 165 address of the home network SIP entry proxy is configured in DNS in 166 the form of a DNS SRV record for SIP. 168 Additionally, home and visited networks may deploy, if required, a 169 SIP hiding proxy. The main purpose of the SIP hiding proxy is to 170 hide the network configuration. 172 The 3GPP IM CN Subsystem is designed to be access independent. 173 Access is granted from 3GPP cellular terminals or from other 174 terminals that use other accesses out of the scope of 3GPP. 176 3GPP cellular IP Multimedia terminals use the existing General 177 Packet Radio Service (GPRS) [6] as a transport network for IP 178 datagrams. The terminals first connect to the GPRS network to get an 179 IPv6 address. In order to do this, the terminals must perform a 180 (GPRS) Attach procedure followed by a (GPRS) PDP Context Activation 181 procedure. These GPRS procedures are required to be completed before 182 any IP Multimedia session can be established. 184 As a result of the above-mentioned GPRS procedures, the terminal has 185 got an IPv6 address. In the case of non-roaming terminals, the IPv6 186 address belongs to the home network address space. In the case of a 187 roaming terminal, the IPv6 address belongs to the visited network 188 address space. The address does not change as the mobile terminal 189 moves while still attached to the same network address space. 191 If the terminal moves from a GPRS access to another GPRS access, the 192 above-mentioned GPRS procedures needs to start from the beginning to 193 allocate an IPv6 address to the terminal. 195 Figure 1 shows an overview of the 3GPP architecture for IM CN 196 Subsystem. 198 +-------------+ +----------------+ +----------------+ 199 | | | | | | 200 | | | | | | 201 | | | | | +------+ | 202 | | | | | | SIP | | 203 | | | | | |server| | 204 | | | | | | +------+ | 205 +-|+ | | | | | / | 206 | | | | | +------+ | | +------+ | 207 | | | | | | SIP | | | | SIP | | 208 | | ---|-------------|--|----|server|----|---|-|server| | 209 +--+ | | | +------+ | | +------+ | 210 | | | | | | 211 SIP | GPRS access | | Visited Network| | Home Network | 212 dev. +-------------+ +----------------+ +----------------+ 214 Figure 1: Overview of the 3GPP IM CN Subsystem architecture 216 Network Working Group Expiration 04/30/02 4 217 3GPP requirements on SIP October 2001 219 Another possible configuration is depicted in Figure 2. In that 220 case, a general-purpose computer (e.g., a laptop computer) is 221 connected to a GPRS terminal. The computer hosts the Multimedia 222 application (comprising SIP, SDP, RTP, etc.). The GPRS terminal 223 handles the radio access and the GPRS connectivity. Note that, for 224 the sake of clarity, the home network has not been depicted in the 225 figure. 227 +-------------+ +----------------+ 228 | | | | 229 | | | | 230 | | | | 231 | | | | 232 | | | | 233 +-------+ | | | | 234 | | +-|+ | | | | 235 | | | | | | | +------+ | 236 +-------+ | | | | | | SIP | | 237 / / --------| | ---|-------------|-------|server|------ 238 /-------/ +--+ | | | +------+ | 239 | | | | 240 SIP GPRS | GPRS access | | Visited Network| 241 client terminal +-------------+ +----------------+ 243 Figure 2: A computer connected to a GPRS terminal 245 Services are typically executed in an application server. The 246 interface between the SIP server and the application server is based 247 on SIP. However, certain operators may want to reuse the existing 248 technology, and therefore, they may need to interoperate SIP with 249 protocols like CAMEL/Intelligent-Network or Open services 250 Architecture (OSA). 252 6. 3GPP Requirements on SIP 254 6.1 General requirements 256 This section does not specify any particular requirement to SIP. 257 However, it includes a list of general requirements that must be 258 considered when developing solutions to particular requirements. 260 6.1.1 Efficient use of the radio interface 262 The radio interface is a scarce resource. As such, the exchange of 263 signaling messages between the UA and the network should be 264 minimized. All the mechanisms developed should make an efficient use 265 of the radio interface. 266 See also the related requirements in section 6.5. 268 Network Working Group Expiration 04/30/02 5 269 3GPP requirements on SIP October 2001 271 6.1.2 Minimum session setup time 273 All the procedures and mechanisms should have a minimum impact on 274 the session setup time as perceived by the user. When there is 275 a choice between performing tasks at session establishment and in 276 transactions prior to session establishment, then the tasks should 277 be performed prior to session establishment. 278 See also the related requirements in section 6.5. 280 6.1.3 Minimum support required in the terminal 282 As terminals could be rather small devices, memory requirements, 283 power consumption, processing power, etc. should be kept to a 284 minimum. Mandating support for additional protocols in the terminal 285 must meet this requirement. 287 6.1.4 Roaming and non roaming 289 The developed solutions should work efficiently in roaming and non- 290 roaming scenarios. 292 6.1.5 Mobility management 294 As mobility management is managed by the access network, there is no 295 need to support mobility management in SIP. 297 6.1.6 IP version 6 299 The IP CN Subsystem is solely designed to use IP version 6 300 addresses. 302 6.2 SIP outbound proxy in the visited network 304 6.2.1 SIP outbound proxy in the visited network 306 A SIP outbound proxy, typically in the visited network, must be 307 supported in both roaming and non-roaming case, even when the SIP 308 serving proxy in the home network is located in the same network as 309 the SIP outbound proxy. 311 6.2.2 Discovery of the SIP outbound proxy 313 There must be a general mechanism to configure the UA with the 314 address of the SIP outbound proxy in the visited network. 316 Network Working Group Expiration 04/30/02 6 317 3GPP requirements on SIP October 2001 319 The Internet Draft "DHCP option for SIP servers" [7] may be a good 320 starting point to meet this requirement. However, there is no 321 support for IPv6 in this Internet Draft. 323 3GPP has another mechanism provided by the GPRS access network that 324 meets this requirement, in addition to the above one. 326 6.2.3 Removal of headers 328 The SIP outbound proxy must be able to remove the network generated 329 contents of the Via and Record-Route headers of the SIP requests to 330 be sent to the UA. These contents are reinserted in the appropriate 331 headers of the responses, as if they would have been included by the 332 UA. This increases security and reduces SIP message sizes and thus 333 transmission delay and peak bandwidth requirements over the radio 334 interface. 336 6.3 Registration 338 6.3.1 Registration required 340 A user must register to the IMS before he/she can initiate or 341 terminate any session. The rationale behind this is that: 342 1. The user must be reachable for terminating sessions and services; 343 2. The user is authenticated and possibly billed for the resources 344 that he/she is authorized to use. 346 The procedure should not have a penalty on the session setup time 347 (see also requirement 6.1.2). 349 6.3.2 Location of the SIP Registrar 351 The SIP registrar is located in the home network. The SIP registrar 352 authenticates and registers the user. 353 Once the terminal is switched on, the UA reads its configuration 354 data. This data may be stored in a SIM card or any other memory 355 device. The configuration data contains an identification of the 356 home network. The device finds the SIP registrar address from the 357 home network domain name. The terminal sends the registration 358 through the SIP outbound proxy. 359 In order to support the search of the registrar, the home network 360 contains one or more SIP servers that are configured in DNS with the 361 SRV record of SIP. These are the home network entry proxies. Their 362 mission is to serve as a first point of contact in the home network, 363 and decide (with the help of location servers) which SIP registrar 364 server to assign to a particular user. 366 The procedures specified in SIP [3], section 1.4.2, applied to a 367 REGISTER message seems to be sufficient to meet this requirement. 369 Network Working Group Expiration 04/30/02 7 370 3GPP requirements on SIP October 2001 372 6.3.3 Efficient registration 374 Due to the scarce radio interface resource, a single registration 375 must be used to register both with the SIP outbound proxy in the 376 visited network and the registrar in the home network. 378 A single REGISTER message, addressed to the registrar, may traverse 379 the SIP outbound proxy in the visited network. This can install, if 380 needed, soft registration states in the SIP outbound proxy. 382 6.3.4 Registration for roaming and non roaming cases 384 In order to facilitate roaming between different networks, the UA 385 must use the same registration procedure(s) within its home and 386 visited networks. 388 6.3.5 Visited domain name 390 The home network must be able to validate that there is a roaming 391 agreement between the home and the visited network. The home network 392 needs to validate that the user is allowed to roam to such a visited 393 network. Therefore, there must be a mechanism so that the visited 394 network identity is known at registration time in the home network. 395 As such, the visited network identity must be transported from the 396 SIP outbound proxy to the home network. 398 It is acceptable to represent the visited network identity as a 399 visited network domain name. 401 6.4 De-registration 403 6.4.1 De-registration of users 405 There must be a procedure for a user to de-register from the 406 network. This procedure may be used, e.g., when the user deactivates 407 the terminal. 409 We believe that a REGISTER with an expiration timer of 0 will meet 410 the requirement. 412 6.4.2 Types of network initiated de-registrations 414 Two types of network initiated de-registrations must be provided: 416 - To deal with registration expirations. 417 - To allow the network to force de-registrations following any 418 possible causes for this to occur. 420 6.4.3 Network initiated de-registration, network maintenance 422 Network Working Group Expiration 04/30/02 8 423 3GPP requirements on SIP October 2001 425 The IM CN Subsystem may initiate the network initiated de- 426 registration procedure due to forced re-registrations from 427 subscribers, e.g. in case of data inconsistency at node failure, in 428 case of SIM lost, etc. Canceling the current contexts of the user 429 spread among the network nodes at registration, and imposing a new 430 SIP registration solves this condition. 432 6.4.4 Network initiated de-registration, network/traffic determined 434 The system must support a mechanism to avoid inconsistent 435 information storage and remove any redundant registration 436 information. This case will occur when a subscriber roams to a 437 different network. This case occurs in normal mobility procedures 438 when the user roams from one access network to another one, or when 439 imposing new service conditions to roamers. 441 6.4.5 Network initiated de-registration, application layer 442 determined 444 The service capability offered by the system to the application 445 layers may have parameters specifying whether all SIP registrations 446 are to be removed, or only those from one or a group of terminals 447 from the user, etc. 449 6.4.6 Network initiated de-registration, administrative 451 For different reasons (e.g., subscription termination, lost 452 terminal, etc.) a home network administrative function may determine 453 a need to clear a user's SIP registration. This function initiates 454 the de-registration procedure and may reside in various elements 455 depending on the exact reason for initiating the de-registration. 457 There must be a procedure for an entity in the network to de- 458 register users. The de-registration information must be available at 459 all the proxies that keep registration state and the UA. 461 We believe that a procedure based on SIP events [15] and a 462 registration package will meet the requirement. 464 6.5 Compression of SIP signaling 466 As the radio interface is a scarce resource, the transport of SIP 467 messages over the radio interface must be done efficiently. 469 Therefore, there must be a mechanism to efficiently transport SIP 470 signaling packets over the radio interface, by compressing the SIP 471 signaling messages between the UA and the SIP outbound proxy, and by 472 compressing the IP and transport layer protocol headers that carry 473 these SIP messages. 475 Network Working Group Expiration 04/30/02 9 476 3GPP requirements on SIP October 2001 478 6.5.1 Extensibility of the SIP compression 480 The chosen solution(s) must be extensible to facilitate the 481 incorporation of new and improved compression algorithms in a 482 backward compatible way, as they become available. 484 6.5.2 SIP compression and roaming 486 The chosen solution(s) for SIP compression must work in roaming 487 scenarios. 489 6.5.3 Minimal impact of SIP compression on the network 491 Application specific compression shall minimize impacts on existing 492 3GPP network, e.g. the compression must be defined between the UA at 493 the SIP terminal and the outbound SIP Proxy in the visited network. 495 6.5.4 Optionality of SIP compression 497 It must be possible to leave the usage of compression for SIP 498 signaling optional. To facilitate mobile terminal roaming between 499 networks which are using compression, the mobile terminal should 500 always support ability to compress SIP signaling. If compression is 501 not supported, communication may continue without compression, 502 depending on the local policy of the visited network. 504 6.5.5 Default algorithm for SIP compression 506 If SIP signaling compression is used, a default algorithm must be 507 supported by the UA and the network elements involved for 508 compression. 510 6.5.6 Compression Negotiation 512 There must be a mechanism to negotiate between the UA and the first 513 SIP outbound proxy the compression algorithm to be used. The type of 514 negotiation mechanism that should be implemented is that the UAC 515 includes a list of compression algorithms and the first SIP outbound 516 proxy responds with the selected one. Subsequent SIP messages are 517 compressed based on the agreed algorithm. 519 Note: 3GPP is investigating if the compression of SIP signaling is 520 negotiated on a per call basis, on a per registration basis or 521 something completely different. More information will be provided in 522 future versions of this document. 524 Network Working Group Expiration 04/30/02 10 525 3GPP requirements on SIP October 2001 527 6.6 QoS requirements related to SIP 529 6.6.1 Independence between QoS signaling and SIP 531 The selection of QoS signaling and resource allocation schemes must 532 be independent of the selected session control protocols. This 533 allows for independent evolution of QoS control and SIP. 535 6.6.2 Coordination between SIP and QoS/Resource allocation 537 6.6.2.1 Allocation before alerting 539 In establishing a SIP session, it must be possible for an 540 application to request that the resources needed for bearer 541 establishment are successfully allocated before the destination user 542 is alerted. Note, however, that it must be also possible for an SIP 543 application in a terminal to alert the user before the radio 544 resources are established (e.g. if the user wants to participate in 545 the media negotiation). 547 We believe this requirement is met by [8] and [21]. 549 6.6.2.2 Destination user participates in the bearer negotiation 551 In establishing a SIP session, it must be possible for a terminating 552 application to allow the destination user to participate in 553 determining which bearers shall be established. 555 We believe this requirement is met by the standard SDP negotiation 556 described in [3] and the extensions described in [8] and [21]. 558 6.6.2.3 Successful bearer establishment 560 Successful bearer establishment must include the completion of any 561 required end-to-end QoS signaling, negotiation and resource 562 allocation. 564 We believe this requirement is met by the procedures described in 565 [8] and [21]. 567 6.7 Prevention of theft of service 569 The possibility for theft of service in the 3GPP IM CN Subsystem 570 shall be no higher than that for the corresponding GPRS and circuit 571 switched services. 573 We believe this requirement is met by the procedures described in 574 [9]. 576 Network Working Group Expiration 04/30/02 11 577 3GPP requirements on SIP October 2001 579 6.8 Radio resource authorization 581 As radio resources are very valuable the network must be able to 582 manage these in a controlled manner. The network must be able to 583 identify who is using these resources and be able to authorize their 584 usage. 586 We believe this requirement is met by the procedures described in 587 [9]. 589 6.9 Prevention of denial of service 591 The system unavailability due to denial of service attacks in the IM 592 CN subsystem shall be no greater than that for the corresponding 593 GPRS and circuit switched services. 595 We believe this requirement is met by the procedures described in 596 [9]. 598 6.10 Identification of users 600 6.10.1 Private user identity 602 To use the 3GPP IM CN Subsystem, a subscriber must have a private 603 user identity. The private identity is assigned by the home network 604 operator, and used, for example, for registration, authorization, 605 administration, and possibly accounting purposes. This identity 606 shall take the form of a Network Access Identifier (NAI) as defined 607 in RFC 2486 [10]. 609 The private user identity is not used for routing of SIP messages. 611 The private user identity is a unique global identity defined by the 612 Home Network Operator, which may be used within the home network to 613 uniquely identify the user from a network perspective. 615 The private user identity is not accessible by the user. Typically 616 this identity is stored in a SIM card. 618 The private user identity shall be permanently allocated to a user 619 (it is not a dynamic identity), and is valid for the duration of the 620 user�s subscription with the home network. 622 6.10.1.1 Private user ID in registrations 624 The UA must deliver the private user identity to the SIP outbound 625 proxy and the registrar at registration time. 626 The private user identity is used as the basis for authentication 627 during registration of the subscriber. The term authentication is 628 used in this document with the same meaning as it is defined in 629 [39]. 631 Network Working Group Expiration 04/30/02 12 632 3GPP requirements on SIP October 2001 634 The current working assumption is that this requirement is met by 635 populating the From: header value of the REGISTER message with the 636 private user ID. 638 6.10.2 Public user identities 640 To use the 3GPP IM CN Subsystem, a subscriber must have one or more 641 public user identities. The public user identity/identities are used 642 by any user for requesting communications to other users. For 643 example, this might be included on a business card. 645 Different public user identities may be grouped into a user profile. 646 A user may have different profiles, each one containing different 647 public user identities. A public user identity can be part of a 648 single user profile. 650 The current working assumption in 3GPP is that this requirement is 651 met by populating the To: header value of a REGISTER message with 652 the public user ID. In an outbound call, the From: and/or the 653 Remote-Party-ID header values are populated with any of the public 654 user identities. 656 6.10.2.1 Format of the public user identities 658 The public user identity/identities must take the form of a SIP URL 659 (as defined in SIP [3] and RFC2396 [11]) or the form of a E.164 660 number [12]. 662 We believe this requirement is met by using SIP URLs and telephone 663 numbers represented in SIP URLs as described in SIP [3]. In 664 addition, tel: URLs as specified in [13] can be used to fulfil the 665 requirement. 667 6.10.2.2 Registration of public user IDs 669 It must be possible to register globally (i.e. through one single UA 670 request) a subscriber that has more than one public identity that 671 belongs to the same user profile, via a mechanism within the IM CN 672 Subsystem. In this case, the user will be registered with all the 673 public identities associated to a user profile. This must not 674 preclude the user from registering individually some of his/her 675 public identities if needed. 677 6.10.2.3 Authentication of the public user ID 679 Public user identities are not authenticated by the network. However 680 the network authorizes that the public user identity is associated 681 to the registered private user identity.. 683 Network Working Group Expiration 04/30/02 13 684 3GPP requirements on SIP October 2001 686 6.11 Identifiers used for routing 688 Routing of SIP signaling within the IM CN Subsystem must use SIP 689 URLs as defined in [3]. E.164 [12] format public user identities 690 must not be used for routing within the IM CN Subsystem, and session 691 requests based upon E.164 format public user identities will require 692 conversion into SIP URL format for internal IM CN Subsystem usage. 694 We believe that this requirement is achieved by translating E.164 695 numbers into SIP URLs. A database, such as ENUM [14] might do the 696 job. 698 6.12 Hiding requirements 700 We believe that the requirements in this section are met by the 701 current SIP protocol [3]. 703 6.12.1 Hiding of the network structure 705 A network operator need not be required to reveal the internal 706 network structure to another network (in Via, Route, or other 707 headers) that may contain indication of the number of SIP proxies, 708 name of the SIP proxies, capabilities of the SIP proxies or capacity 709 of the network. Association of the node names of the same type of 710 entity and their capabilities and the number of nodes will be kept 711 within an operator�s network. However disclosure of the internal 712 architecture must not be prevented on a per agreement basis. 714 6.12.2 Hiding of IP addresses 716 A network need not be required to expose the explicit IP addresses 717 of the nodes within the network (excluding firewalls and border 718 gateways). 720 6.12.3 SIP hiding proxy 722 In order to support the hiding requirements, a SIP hiding proxy may 723 be included in the SIP signaling path. Such additional proxy may be 724 used to shield the internal structure of a network from other 725 networks. 727 6.13 Cell-ID 729 The identity of the cell through which the 3GPP UA is accessing the 730 IM CN Subsystem (Cell-ID) may be used by either the visited or the 731 home network to provide localized services or information on the 732 location of the terminal during an emergency call (see also 733 requirement 6.16.3). 735 Network Working Group Expiration 04/30/02 14 736 3GPP requirements on SIP October 2001 738 6.13.1 Cell-ID in signaling from the UA to the visited and home 739 networks 741 Assuming that the cell-ID is obtained by the UA by other mechanisms 742 outside the scope or beyond SIP, the cell-ID must be transported at 743 least in the following procedures: 745 - Registration 746 - Session Establishment (Mobile Originated) 747 - Session Establishment (Mobile Terminated) 748 - Session Release 750 6.13.2 Format of the cell-ID 752 The cell-ID must be sent in the format of a Cell Global ID, as 753 described in [22]. 755 6.14 Release of sessions 757 In addition to the normal mechanisms to release a SIP session (e.g. 758 BYE), two cases are considered in this section. The ungraceful 759 release of the session (e.g., the terminal moves to an out of 760 coverage zone) and the graceful session release ordered by the 761 network (e.g., pre-paid caller runs out of credit). 763 6.14.1 Ungraceful session release 765 If an ungraceful session termination occurs (e.g. flat battery or 766 mobile leaves coverage), when a call stateful SIP proxy server (such 767 as the SIP serving proxy at home) is involved in a session, memory 768 leaks and eventually server failure can occur due to hanging state 769 machines. To ensure stable proxy operation and carrier grade 770 service, a mechanism to handle the ungraceful session termination 771 issue must be provided. This mechanism should be at the SIP protocol 772 level in order to guarantee access independence for the system. 774 6.14.2 Graceful session release 776 There must be a mechanism so that an entity in the network may order 777 the release of resources to other entities. This may be used, e.g., 778 in pre-paid calls when the user runs out of credit. 780 This release must not involve any request to the UA to send out a 781 release request (BYE), as the UA might not follow this request. The 782 receiving entity needs the guarantee that resources are released 783 when requested by the ordering entity. 785 6.15 Routing of SIP messages 787 Network Working Group Expiration 04/30/02 15 788 3GPP requirements on SIP October 2001 790 In order to clarify the terminology, we introduce the term vector to 791 refer to the set of proxies that the INVITE has to traverse. 793 6.15.1 SIP outbound proxy in the visited network 795 As the SIP outbound proxy in the visited network is supporting the 796 UA in terms of limited dialed digits translation (i.e., local to 797 international), emergency calls, all sessions initiated in the 798 mobile terminal when using IM CN Subsystem, must first route the SIP 799 signaling to the SIP outbound proxy in the visited network, 800 independently of the destination of the session. 802 6.15.2 SIP serving proxy in the home network 804 As services are triggered in the home network, all sessions 805 initiated in the mobile terminal (except emergency calls) must route 806 the SIP signaling to the SIP serving proxy in the home network 807 allocated at registration time, independently of the destination of 808 the session. 810 6.15.3 INVITE might follow a different path than REGISTER 812 The path taken by the INVITE need not be restricted to the specific 813 path taken by the REGISTER. However, the path taken by the INVITE 814 may follow the same path taken by the REGISTER (e.g., the INVITE may 815 traverse just the SIP outbound proxy in the visited network and the 816 SIP serving proxy in the home network, without passing through any 817 other proxies). 819 6.15.4 Information of the vector 821 There must be some means of dynamically informing the node which 822 adds the vector (e.g., the SIP outbound proxy) of what that vector 823 should be, in the specific case where the vector is used to find a 824 SIP serving proxy in the home network. 826 Similarly, there must be some means of dynamically informing the 827 node which adds the vector (e.g., the SIP serving proxy) of what 828 that vector should be, in the specific case where the vector is used 829 to find a SIP inbound proxy in the visited network. 831 The hiding requirements expressed in section 6.12 also apply to the 832 vector. 834 6.15.5 SIP inbound proxy in the visited network 836 The visited network may apply certain local policies to incoming 837 sessions. Therefore, there is a need to have an SIP inbound proxy in 839 Network Working Group Expiration 04/30/02 16 840 3GPP requirements on SIP October 2001 842 the visited network for terminating sessions. In general, the SIP 843 inbound proxy and the SIP outbound proxy are the same entity in the 844 visited network. 846 6.16 Emergency sessions 848 It must be possible to place an emergency session using the IM CN 849 Subsystem. Emergency calls will be routed to the emergency services 850 in accordance with national regulations for where the subscriber is 851 located. 853 6.16.1 Registration is not required 855 It must be possible to place an emergency session using SIP, 856 independently on whether the user is registered to the IM CN 857 Subsystem or not. Note, however, that in certain countries, it might 858 be possible to reject an emergency call when the user is no 859 registered to the IM CN Subsystem. 861 6.16.2 SIP outbound proxy support 863 Emergency sessions must be handled by the SIP outbound proxy in the 864 visited network. 866 6.16.3 Cell Global ID in emergency sessions 868 It is required that location information including Cell Global ID 869 (see also requirement6.13) be made available in the initial INVITE 870 and the BYE message for the purpose of locating the user and routing 871 to the appropriate Emergency Call Center. 873 6.16.4 Types of emergency calls 875 It must be possible to initiated emergency calls to different 876 emergency call centers, depending on the type of emergency. The 877 following types of emergency calls are possible: 879 - Police 880 - Ambulance 881 - Fire brigade 882 - Marine guard 883 - Mountain rescue 884 - Spare, at least three different types 886 6.16.4 Default identifier for emergency calls 888 In order to support emergency calls in roaming situations, it must 889 be allowed to establish an emergency call without the need to dial a 891 Network Working Group Expiration 04/30/02 17 892 3GPP requirements on SIP October 2001 894 dedicated number or SIP URL. This allows to dial an emergency center 895 based on a menu, "red button" or a linkage to a car air bag control. 897 Additionally, it is desirable that the user interface for emergency 898 calls in 3GPP terminals is similar to the one in other SIP networks. 900 3GPP is currently investigating the applicability of the Universal 901 Emergency SIP URL described in [36]. 903 6.17 Identities on session establishment 905 6.17.1 Remote Party Identification presentation 907 It must be possible to present to the caller the identity of the 908 party to which he/she may dial back to return a call. 910 We believe this requirement is met by the procedures described in 911 [16]. 913 6.17.2 Remote Party Identification privacy 915 In addition to the previous requirement, the called party must be 916 able to request that his/her identity not be revealed to the caller. 918 We believe this requirement is met by the procedures described in 919 [16]. 921 6.17.3 Remote Party Identification blocking 923 Regulatory agencies, as well as subscribers, may require the ability 924 of a caller to block the display of their caller identification. 925 This function may be performed by the destination subscriber�s SIP 926 serving proxy. In this way, the destination subscriber is still able 927 to do a session-return, session-trace, transfer, or any other 928 supplementary service. 930 Therefore, it must be possible that the caller requests to block the 931 display of his/her identity at the callee's display. 933 We believe this requirement is met by the procedures described in 934 [16]. 936 6.17.4 Anonymity 938 Procedures are required for an anonymous session establishment. 939 However, sessions are not intended to be anonymous to the 940 originating or terminating network operators. 942 Note: 3GPP is still discussing whether the requirement is needed or 943 not. 945 Network Working Group Expiration 04/30/02 18 946 3GPP requirements on SIP October 2001 948 6.17.4.1 Anonymous session establishment 950 If the caller requests the session to be anonymous, the UAC must not 951 reveal any identity information to the UAS. 953 If the caller requests the session to be anonymous, the terminating 954 network must not reveal any identity or signaling routing 955 information to the destination endpoint. The terminating network 956 should distinguish at least two cases, first if the caller intended 957 the session to be anonymous, and second if the caller�s identity was 958 deleted by a transit network. 960 6.18 Charging 962 It must be possible to apply charging, in a flexible manner based on 963 any number of different charging models. Specific charging models 964 and requirements for charging are under study. 966 6.19 IPv6 968 As the 3GPP architecture is solely based on IP version 6, all 969 protocols must support IPv6 addresses. 971 We believe SIP [3] and SDP [17] meet this requirement. However, the 972 "DHCP option for SIP servers" [7] does not support IPv6. 974 6.19.1 Interworking IPv6 with IPv4 976 3GPP IM CN subsystem is based on IPv6. As external networks may be 977 based on IPv4 addresses, there is a need to interwork with such a 978 external networks. Therefore, interworking between IPv6 and IPv4 at 979 the SIP and SDP level (UAs and proxies) must be guaranteed. 981 6.20 General support of additional capabilities 983 3GPP is interested on applying and using additional services, like 984 those described in [19], [37] and [38]. Although 3GPP is not going 985 to standardize additional services, 3GPP may make sure that the 986 capabilities that enable those services are granted in the network. 988 As such we believe that the REFER method [18] and the Replaces 989 header [20] constitute the enablers in order to meet the above 990 requirement. 992 6.21 Three-way handshake in the session description negotiation 994 Network Working Group Expiration 04/30/02 19 995 3GPP requirements on SIP October 2001 997 Typically a session description protocol like SDP is used in SIP to 998 describe the media streams and codecs needed to establish the 999 session. SIP uses an offer/answer model of the session description 1000 where one of the parties offers his session description and the 1001 other answers to that offer. 1003 In 3GPP IM CN Subsystem, the terminals might have restrictions with 1004 the memory, DSP capacity, etc. As such, it is required that the 1005 Session Description negotiation concludes with one out of many 1006 single codecs per media stream. Both UAC and UAS must know, prior to 1007 any media is sent or received, which codec is used for each media 1008 stream. 1010 In 3GPP IM CN Subsystem, an efficient use of the network and radio 1011 resources is an important requirement. As such, the network must 1012 know in advance which codec is used for a particular media stream. 1013 The network may use this information to apply the most appropriate 1014 error correction mechanism depending on the selected codec. The 1015 network access control may use this information as well. 1017 Additionally, it is required that the party who pays for the 1018 resource utilization has the opportunity to decide the codec to use, 1019 once both end parties are aware of the capabilities supported at the 1020 remote UA. 1022 Therefore, it is required a three-way handshake model in the session 1023 description negotiation within SIP. This follows the model of 1024 offer/counter-offer/answer of the session description. 1026 6.22 Security Model 1028 Sections 6.22, 6.23 and 6.24 have been based on the 3GPP documents 1029 [23], [4], and [24], and the work done by Dirk Kroeselberg in the 1030 Internet-Draft [31] (now expired). 1032 The scope for security of the 3GPP IM CN Subsystem is securing the 1033 SIP signaling between the various SIP entities. Protecting the end- 1034 to-end media streams may be a future extension but is not considered 1035 in the first version of the IM CN Subsystem. 1037 It is expected that security for the underlying GPRS network and the 1038 IM CN Subsystem will be provided independent of each other. 1039 Therefore, SIP signaling security must be provided independently of 1040 underlying access network security mechanisms. In particular, it 1041 must be possible to access the IM CN Subsystem services securely 1042 from other accesses than GPRS. 1044 Each operator providing IM CN Subsystem services acts as its own 1045 domain of trust, and shares a long-term security association with 1046 its subscribers. Operators may enter into roaming agreements with 1047 other operators, in which case a certain level of trust exists 1048 between their respective domains. 1050 Network Working Group Expiration 04/30/02 20 1051 3GPP requirements on SIP October 2001 1053 SIP user agents must authenticate to their home network before the 1054 use of IM CN Subsystem resources is authorized. The current working 1055 assumption in the 3GPP is to perform authentication during 1056 registration and re-registrations. 1058 A hop-by-hop model must be used to protect actual SIP signaling. 1059 Looking at Figure 1 in Chapter 5, we can distinguish two main areas 1060 where security is needed: 1062 - Access Domain: Between the SIP user device and the visited 1063 network. 1064 - Network Domain: Between the visited and the home networks, or 1065 inside the home network. 1067 Characteristics needed in the Access Domain are quite different from 1068 those of the Network Domain because the terminal�s requirements on 1069 mobility, computation restriction, battery limit, bandwidth 1070 conservation and radio interface. SIP entities in the access domain 1071 should be able to maintain security contexts with a large group of 1072 users in parallel. Furthermore, Access Domain provides user specific 1073 security associations while Network Domain provides security 1074 associations between network nodes. Therefore the weight of 1075 protocols and algorithms and the compliance of them with compression 1076 mechanisms are very important to Access Domain Security. It is 1077 therefore required that the security solutions must allow different 1078 mechanisms in these two domains. 1080 Note that authentication, as used in this context, means entity 1081 authentication that enables two entities to verify the identity of 1082 the respective peer. This is different from message origin 1083 authentication, which allows a receiver to verify the origin of a 1084 single message and is provided by the same means as integrity 1085 protection. 1087 6.23 Access Domain Security 1089 6.23.1 Authentication 1091 Strong, mutual authentication method must be used. 1093 It must be possible to support different authentication methods. 1094 Therefore authentication using an extensible authentication 1095 framework must be provided. 1097 Authentication methods must support the secure storage of long-term 1098 authentication keys and the secure execution of authentication 1099 algorithms. 1101 The SIP client�s credentials must not be transferred as plain text. 1103 HTTP Basic Authentication sends the passwords as plain text, also, 1104 it is neither strong nor does it offer mutual authentication. HTTP 1105 Digest has an option for mutual authentication. It uses 1107 Network Working Group Expiration 04/30/02 21 1108 3GPP requirements on SIP October 2001 1110 cryptographic means for authentication, but does not protect against 1111 man-in-the-middle attacks where attackers modify the request while 1112 preserving the authentication headers. Lower layer mechanisms allow 1113 strong and mutual authentication (but do not fulfill other 1114 requirements). 3GPP intends to reuse UMTS AKA [24], but would prefer 1115 to a generic authentication framework at SIP level that supports 1116 UMTS AKA as well as other authentication mechanisms. UMTS AKA 1117 applies a symmetric cryptographic scheme, provides mutual 1118 authentication, and is typically implemented on a so-called SIM card 1119 that provides secure storage on the user�s side. 1121 Additional requirements related to delegation that apply to the 1122 authentication method are given in section 6.23.2.3. 1124 6.23.2 Scalability and Efficiency 1126 3GPP IM CN Subsystems will be characterized by a large subscriber 1127 base of up to a billion users, all of which must be treated in a 1128 secure manner. 1130 The security solutions must allow global roaming among a large 1131 number of administrative domains. 1133 6.23.2.1 Bandwidth and Roundtrips 1135 The wireless interface in 3GPP terminals is an expensive resource 1136 both in terms of power consumption and maximum utilization of scarce 1137 spectrum. Furthermore, cellular networks have typically long round- 1138 trip time delays, which must be taken in account in the design of 1139 the security solutions. 1141 Any security mechanism that involves 3GPP terminals should not 1142 unnecessarily increase the bandwidth needs. 1144 All security mechanisms that involve 3GPP terminals should minimize 1145 the number of necessary extra roundtrips. In particular, during 1146 normal call signaling there should not be any additional security 1147 related messages. 1149 The roundtrip requirements are particularly hard to satisfy. It 1150 seems that IKE [32] adds a number of roundtrips, particularly if run 1151 together with legacy authentication extensions developed in the 1152 IPSRA WG. TLS [25] uses less roundtrips, but on the other hand 1153 doesn't support UDP. 1155 6.23.2.2 Computation 1157 It must be possible for IM CN Subsystem terminals to provide 1158 security without requiring public key cryptography and/or 1159 certificates. There may, however, be optional security schemes that 1160 employ these techniques. 1162 Network Working Group Expiration 04/30/02 22 1163 3GPP requirements on SIP October 2001 1165 Current HTTP authentication methods use only symmetric cryptography 1166 as required here (but do not meet other requirements). Lower-layer 1167 security mechanisms all require the use of public key cryptography, 1168 or at least Diffie-Hellman as a mandatory part in their operation. 1169 HTTP EAP [27] is one candidate method to allow both symmetric 1170 cryptography and asymmetric cryptography based authentication within 1171 SIP, though there are probably other candidates as well, such as 1172 GSS_API [28]. However, definition of UMTS AKA under EAP is already 1173 in progress [29]. 1175 6.23.2.3 Delegation of Security Tasks 1177 Performing authentication on all SIP signaling messages would likely 1178 create bottlenecks in the authentication infrastructure. Therefore, 1179 a distributed implementation of security functions responsible for 1180 authentication is required. 1182 It must be possible to perform an initial authentication based on 1183 long-term authentication credentials, followed by subsequent 1184 protected signaling that uses short-term authentication credentials, 1185 such as session keys created during initial registration. The used 1186 authentication mechanisms must be able to provide such session keys. 1188 Initial authentication is performed between the SIP UA and the 1189 authenticating SIP serving proxy in the home network. However, the 1190 authentication mechanism must not require access to the long-term 1191 authentication credentials in these nodes. In the home network, the 1192 authenticating SIP serving proxy must support interaction with a 1193 dedicated authentication server in order to accomplish the 1194 authentication task. At the client side a secured (tamper-proof) 1195 device storing the long-term credentials of the user must perform 1196 the authentication. 1198 Additionally, the SIP serving proxy that performed the initial 1199 authentication must be able to securely delegate subsequent SIP 1200 signaling protection (e.g. session keys for integrity or encryption) 1201 to an authorized SIP proxy further downstream. The tamper-proof 1202 device at the client side must be able to securely delegate the 1203 session keys to the SIP user agent. 1205 Initial authentication can be performed with existing mechanisms 1206 such as HTTP Digest [3], but there exists no method to allow 1207 subsequent protection of the SIP signaling messages. There are also 1208 no proposals to allow secure delegation of signaling protection 1209 task. Currently the use of SIP together with an authentication 1210 server is not possible, though several proposals are under way to 1211 extend this [33, 34, 35]. However, the purpose of this document is 1212 not to discuss AAA requirements. They are discussed somewhere else. 1214 6.23.3 Negotiation of mechanisms 1216 Network Working Group Expiration 04/30/02 23 1217 3GPP requirements on SIP October 2001 1219 A method for secure negotiation of security must be provided, to 1220 negotiate the security services to be used in the access domain. 1222 This method must at least support the negotiation of different 1223 security services providing integrity protection and encryption, 1224 algorithms used within these services and additional parameters they 1225 require to be exchanged. 1227 The negotiation mechanism must protect against attackers who do not 1228 have access to authentication credentials. In particular, it must 1229 not be possible for man-in-the-middle attackers to influence the 1230 negotiation result such that services with lower or no security are 1231 negotiated. 1233 A negotiation mechanism is generally required in all secure 1234 protocols to decide which security services to use and when they 1235 should be started. This security mechanism serves algorithm and 1236 protocol development as well as interoperability. Often, the 1237 negotiation is handled within a security service. For example, the 1238 HTTP authentication scheme includes a selection mechanism for 1239 choosing among appropriate authentication methods and algorithms. 1240 Note that with the negotiation we mean just the negotiation, not all 1241 functions in protocols like IKE. For instance, we expect the session 1242 key generation is to be a part of the initial authentication. 1244 SIP entities may use the same security mode parameters to protect 1245 several SIP sessions without re-negotiation. For example, security 1246 mode parameters may be assumed to be valid within the lifetime of 1247 one registration. 1249 Existing lower-layer security mechanisms provide the above 1250 functionality as a part of them. We do not currently know of any 1251 mechanism that would allow this also at the SIP layer, [30] might 1252 perhaps be extended to perform secure negotiation. Note that such a 1253 mechanism is required not only for negotiation of security 1254 mechanisms, but for other services as well, e.g. for compression 1255 (see section 6.5.6). Although negotiation of security mechanisms is 1256 different due to the need for secure negotiation, all negotiation 1257 mechanisms could operate in a similar fashion. 1259 6.23.4 Message protection 1261 SIP entities (typically a SIP client and a SIP proxy) must be able 1262 to communicate using integrity and replay protection. By integrity, 1263 we mean the ability for receiver of a message to verify that the 1264 message has not been modified in transit. SIP entities should be 1265 able to communicate confidentially. These protection modes must be 1266 based on initial authentication. Integrity protection and 1267 confidentiality must be possible using symmetric cryptographic keys. 1269 It must be possible to handle also error conditions in a 1270 satisfactory manner as to allow recovery (see also 6.4.3 and 6.14). 1272 Network Working Group Expiration 04/30/02 24 1273 3GPP requirements on SIP October 2001 1275 It must be possible to provide this protection between two adjacent 1276 SIP entities. In future network scenarios it may also be necessary 1277 to provide this protection through proxies, though at the moment 1278 3GPP does not require this. . 1280 The security mechanism should not incur external limitations to any 1281 transport bearers carrying SIP message. 1283 All the lower layer security mechanisms offer these services for the 1284 hop-by-hop case, but currently we do not know of any mechanism that 1285 would allow also end-to-end operation. 1287 The security mechanism must be able to protect a complete SIP 1288 message. 1290 If header compression/removal or SIP compression is applied to SIP 1291 messages, it must be compatible with message protection. 1293 6.24 Network Domain Security 1295 Authentication, key agreement, integrity and replay protection, and 1296 confidentiality must be provided for communications between SIP 1297 network entities such as proxies and servers. 1299 Network domain security mechanisms must be scalable up to a large 1300 number of network elements. 1302 The 3GPP intends to make it mandatory to have protection discussed 1303 above at least between two operators, and optional within an 1304 operator�s own network. Security gateways exist between operator�s 1305 networks. 1307 We believe the above requirements to be fulfilled by applying 1308 security mechanisms as specified in the current IP Security 1309 standards [26]. 1311 7. Security considerations 1313 This document does not define a protocol, but still presents some 1314 security requirements to protocols. The main security requirements 1315 are in sections 6.22 "Security Model", 6.23 "Access Domain Security" 1316 and 6.24 "Network Domain Security". Additional security-related 1317 issues are discussed under 6.7 "Prevention of theft of service", 6.8 1318 "Radio resource authorization", 6.9 "Prevention of denial of 1319 service", 6.12 "Hiding requirements" and 6.10 "Identification of 1320 users". 1322 8. Author's Addresses 1324 Miguel A. Garcia 1325 Ericsson 1326 FIN-02420, Jorvas, Finland 1328 Network Working Group Expiration 04/30/02 25 1329 3GPP requirements on SIP October 2001 1331 Tel: +358 9299 3553 1332 e-mail: miguel.a.garcia@ericsson.com 1334 Duncan Mills 1335 Vodafone UK Ltd. 1336 The Courtyard, Newbury, Berkshire, RG14 1JX, UK 1337 Tel: +44 1635 676074 1338 Fax: +44 1635 234445 1339 e-mail: duncan.mills@vf.vodafone.co.uk 1341 Gabor Bajko 1342 Nokia 1343 H-1096 Budapest, Koztelek 6, Hungary 1344 Tel: +36 20 9849259 1345 e-mail: gabor.bajko@nokia.com 1347 Georg Mayer 1348 Siemens 1349 Hofmannstr. 51, 81359 Munich, Germany 1350 Tel: +49-172-5371233 1351 e-mail: georg.mayer@icn.siemens.de 1353 Francois-Xavier Derome 1354 Alcatel 1355 10 rue latecoere, F-78141 1356 tel: +33 130 773 834 1357 e-mail: francois-xavier.derome@alcatel.fr 1359 Hugh Shieh 1360 AT&T Wireless 1361 PO Box 97061, Redmond, WA 98073 1362 Tel: +1 425 580 6898 1363 e-mail: hugh.shieh@attws.com 1365 Andrew Allen 1366 Motorola, 1367 1501 W Shure Dr, 1368 Arlington Hts, IL 60004 1369 Phone: 847-435-0016 1370 e-mail: CAA019@motorola.com 1372 Sunil Chotai 1373 BT 1374 Adastral Park, Ipswich, UK. 1375 Tel: +44 1473 605603 1376 e-mail: sunil.chotai@bt.com 1378 Keith Drage 1379 Lucent Technologies 1380 Tel: +44 1793 776249 1381 e-mail: drage@lucent.com 1383 Jayshree Bharatia 1384 Nortel Networks 1386 Network Working Group Expiration 04/30/02 26 1387 3GPP requirements on SIP October 2001 1389 2201 Lakeside Blvd. 1390 Richardson, Texas 75082 1391 Tel: +1 972 684 5767 1392 e-mail: jayshree@nortelnetworks.com 1394 9. Acknowledgments 1396 The authors will like to thank the members of the 3GPP CN1 and SA3 1397 mailing lists for their collaborative effort. 1399 10. References 1401 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1402 9, RFC 2026, October 1996. 1404 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1405 Levels", BCP 14, RFC 2119, March 1997. 1407 3. Handley M, Schulzrinne H, Schooler E, Rosenberg J., "SIP, Session 1408 Initiation Protocol", draft-ietf-sip-rfc2543bis-04.txt, Work in 1409 Progress. 1411 4. 3GPP TS 23.228 "IP Multimedia (IM) Subsystem (Stage 2) - Release 1412 5". Version 5.1.0 is available at ftp://ftp.3gpp.org/Specs/2001- 1413 06/Rel-5/23_series/23228-510.zip 1415 5. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call 1416 control based on SIP and SDP". Version 1.5.0 is available at 1417 ftp://ftp.3gpp.org/Specs/Latest_drafts/24228-150.zip 1419 6. 3GPP TS 23.060: "General Packet Radio Service (GRPS); Service 1420 Description; Stage 2". Version 4.1.0 is available at 1421 ftp://ftp.3gpp.org/Specs/2001-06/Rel-4/23_series/23060-410.zip 1423 7. H. Schulzrinne, G. Nair. "DHCP Option for SIP Servers", draft- 1424 ietf-sip-dhcp-04.txt, Work in progress. 1426 8. W. Marshall et al. "Integration of Resource Management and SIP", 1427 draft-ietf-sip-manyfolks-resource-02.txt, Work in progress. 1429 9. W. Marshall et al. "SIP Extensions for Media Authorization", 1430 draft-ietf-sip-call-auth-02.txt, Work in progress. 1432 10. B. Aboba, M. Beadles, "The Network Access Identifier", RFC 1433 2486, January 1999. 1435 11. T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1436 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1438 12. ITU-T Recommendation E.164 (05/97): "The international public 1439 telecommunication numbering plan". 1441 Network Working Group Expiration 04/30/02 27 1442 3GPP requirements on SIP October 2001 1444 13. A. Vaha-Sipila, "URLs for Telephone calls", RFC 2806, April 1445 2000. 1447 14. P. Faltstrom, "E.164 number and DNS", RFC 2916, September 2000. 1449 15. A. Roach, "SIP-Specific Event Notification", draft-ietf-sip- 1450 events-00.txt, Work in progress. 1452 16. W. Marshall et al, "SIP Extensions for Caller Identity and 1453 Privacy", draft-ietf-sip-privacy-02.txt, Work in progress. 1455 17. M. Handley, V. Jacobson, C. Perkins: "SDP: Session Description 1456 Protocol", draft-ietf-mmusic-sdp-new-03.txt, Work in progress. 1458 18. R. Sparks: "The REFER method", draft-ietf-sip-refer-01.txt, 1459 Work in progress. 1461 19. R. Sparks: "SIP Call Control - Transfer", draft-ietf-sip-cc- 1462 transfer-05.txt, Work in progress. 1464 20. B. Biggs and R. Dean, "The SIP Replaces Header", draft-sip- 1465 replaces-00.txt, Work in progress. 1467 21. J. Rosenberg, H. Schulzrinne: "Reliability of Provisional 1468 Responses in SIP", draft-ietf-sip-100rel-03.txt, Work in progress. 1470 22. 3GPP TS 23.003, "Numbering, addressing and identification 1471 (Release 5)". Version 5.0.0 is available is available at 1472 ftp://ftp.3gpp.org/Specs/2001-06/Rel-5/23_series/23003-500.zip 1474 23. 3GPP TS 33.203 "Access Security for IP-Based Services", 1475 Version 0.5.0 is available at 1476 ftp://ftp.3gpp.org/tsg_sa/WG3_Security/TSGS3_ADHOC_MAP_IMS_Sophia/ 1477 Docs/PDF/S3z010089.pdf 1479 24. 3GPP TR 33.210 "Network Domain Security", Version 0.6.0. 1481 25. T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246, 1482 January 1999. 1484 26. S. Kent, R. Atkinson. "Security Architecture for the Internet 1485 Protocol", RFC 2401, November 1998. 1487 27. V. Torvinen, J. Arkko, A. Niemi. "HTTP Authentication with 1488 EAP", draft-torvinen-http-eap-00.txt, Work In Progress, June 2001. 1490 28. J. Linn. "Generic Security Service Application Program 1491 Interface Version 2, Update 1". RFC 2743, IETF. January 2000. 1493 29. J. Arkko, H. Haverinen. "EAP AKA Authentication", draft-arkko- 1494 pppext-eap-aka-00.txt, Work In Progress, May 2001. 1496 30. S. Parameswar, B. Stucker. "The SIP NEGOTIATE Method", draft- 1497 spbs-sip-negotiate-00.txt, Work In Progress, IETF, September 2001. 1499 Network Working Group Expiration 04/30/02 28 1500 3GPP requirements on SIP October 2001 1502 31. D. Kroeselberg. "SIP security requirements from 3G wireless 1503 networks", draft-kroeselberg-sip-3g-security-req-00.txt. Work In 1504 Progress, IETF, January 2001. 1506 32. D. Harkins, D. Carrel: "The Internet Key Exchange (IKE)", RFC 1507 2409, November 1998. 1509 33. Srinivas, Chan, Sengodan, Costa-Requena: "Mapping of Basic and 1510 Digest Authentication to DIAMETER AAA Messages", draft-srinivas- 1511 aaa-basic-digest-00.txt, Work in progress, July 2001. 1513 34. B. Sterman: "Digest Authentication in SIP using RADIUS", draft- 1514 sterman-sip-radius-00.txt, Work in progress, February 2001. 1516 35. P.R. Calhoun, W. Bulley, A.C. Rubens, J. Haag, G. Zorn: 1517 "Diameter NASREQ Application", draft-ietf-aaa-diameter-nasreq- 1518 07.txt, Work in progress, July 2001. 1520 36. H. Schulzrinne: "Universal Emergency Address for SIP-based 1521 Internet Telephony", draft-schulzrinne-sipping-sos-00.txt, Work in 1522 progress, July 2001. 1524 37. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, 1525 J. Rosenberg, K. Summers, H. Schulzrinne: "SIP Call Flow 1526 Examples", draft-ietf-sip-call-flows-05.txt, Work in progress, 1527 June 2001. 1529 38. A. Johnston, R. Sparks, C. Cunningham, S. Donovan, K. Summers: 1530 "SIP Service Examples", Work in progress, draft-ietf-sip-service- 1531 examples-02.txt, June 2001. 1533 39. R. Shirey: "Internet Security Glossary", RFC 2828, May 2000. 1535 Full Copyright Statement 1537 "Copyright (C) The Internet Society (2000). All Rights Reserved. 1538 This document and translations of it may be copied and furnished to 1539 others, and derivative works that comment on or otherwise explain it 1540 or assist in its implementation may be prepared, copied, published 1541 and distributed, in whole or in part, without restriction of any 1542 kind, provided that the above copyright notice and this paragraph 1543 are included on all such copies and derivative works. However, this 1544 document itself may not be modified in any way, such as by removing 1545 the copyright notice or references to the Internet Society or other 1546 Internet organizations, except as needed for the purpose of 1547 developing Internet standards in which case the procedures for 1548 copyrights defined in the Internet Standards process must be 1549 followed, or as required to translate it into languages other than 1550 English. The limited permissions granted above are perpetual and 1551 will not be revoked by the Internet Society or its successors or 1552 assigns. This document and the information contained herein is 1553 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1555 Network Working Group Expiration 04/30/02 29 1556 3GPP requirements on SIP October 2001 1558 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1559 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1563 Network Working Group Expiration 04/30/02 30