idnits 2.17.1
draft-ietf-sipping-3gpp-r5-requirements-00.txt:
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:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2]), 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
-- 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 11, 2002) is 7868 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)
== Missing Reference: '36' is mentioned on line 1195, but not defined
== Unused Reference: '14' is defined on line 1513, but no explicit
reference was found in the text
== Unused Reference: '21' is defined on line 1541, but no explicit
reference was found in the text
== Unused Reference: '33' is defined on line 1585, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 2246 (ref.
'3') (Obsoleted by RFC 4346)
-- Obsolete informational reference (is this intentional?): RFC 2396 (ref.
'4') (Obsoleted by RFC 3986)
-- Obsolete informational reference (is this intentional?): RFC 2401 (ref.
'5') (Obsoleted by RFC 4301)
-- Obsolete informational reference (is this intentional?): RFC 2409 (ref.
'6') (Obsoleted by RFC 4306)
-- Obsolete informational reference (is this intentional?): RFC 2486 (ref.
'7') (Obsoleted by RFC 4282)
-- Obsolete informational reference (is this intentional?): RFC 2828 (ref.
'8') (Obsoleted by RFC 4949)
-- Obsolete informational reference (is this intentional?): RFC 2833 (ref.
'9') (Obsoleted by RFC 4733, RFC 4734)
-- Obsolete informational reference (is this intentional?): RFC 2916 (ref.
'10') (Obsoleted by RFC 3761)
-- Obsolete informational reference (is this intentional?): RFC 3265 (ref.
'13') (Obsoleted by RFC 6665)
-- Obsolete informational reference (is this intentional?): RFC 3266 (ref.
'14') (Obsoleted by RFC 4566)
== Outdated reference: A later version (-28) exists of
draft-ietf-dhc-dhcpv6-26
== Outdated reference: A later version (-01) exists of
draft-ietf-sip-dhcpv6-00
== Outdated reference: A later version (-02) exists of
draft-ietf-sipping-basic-call-flows-01
== Outdated reference: A later version (-02) exists of
draft-ietf-sipping-pstn-call-flows-00
== Outdated reference: A later version (-15) exists of
draft-ietf-sipping-service-examples-02
== Outdated reference: A later version (-07) exists of
draft-ietf-sip-refer-06
== Outdated reference: A later version (-05) exists of
draft-ietf-sip-replaces-02
Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING Working Group M. Garcia-Martin
3 Internet-Draft Ericsson
4 Expires: April 11, 2003 October 11, 2002
6 3rd-Generation Partnership Project (3GPP) Release 5 requirements on
7 the Session Initiation Protocol (SIP)
8 draft-ietf-sipping-3gpp-r5-requirements-00.txt
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at http://
26 www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on April 11, 2003.
33 Copyright Notice
35 Copyright (C) The Internet Society (2002). All Rights Reserved.
37 Abstract
39 The 3rd Generation Partnership Project (3GPP) has selected SIP [2]as
40 the session establishment protocol for the 3GPP IP Multimedia Core
41 Network Subsystem (IMS). IMS is part of the Release 5 of the 3GPP
42 specifications. Although SIP is a protocol that fulfills most of the
43 requirements to establish a session in an IP network, SIP has never
44 been evaluated against the specific 3GPP requirements for operation
45 in a cellular network. In this document we express the requirements
46 identified by 3GPP to support SIP for the Release 5 of the 3GPP IMS
47 in cellular networks.
49 Table of Contents
51 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
53 3. Overview of the 3GPP IMS . . . . . . . . . . . . . . . . . 5
54 4. 3GPP Requirements on SIP . . . . . . . . . . . . . . . . . 8
55 4.1 General requirements . . . . . . . . . . . . . . . . . . . 8
56 4.1.1 Efficient use of the radio interface . . . . . . . . . . . 8
57 4.1.2 Minimum session setup time . . . . . . . . . . . . . . . . 8
58 4.1.3 Minimum support required in the terminal . . . . . . . . . 8
59 4.1.4 Roaming and non-roaming . . . . . . . . . . . . . . . . . 8
60 4.1.5 Terminal mobility management . . . . . . . . . . . . . . . 8
61 4.1.6 IP version 6 . . . . . . . . . . . . . . . . . . . . . . . 9
62 4.2 SIP outbound proxy . . . . . . . . . . . . . . . . . . . . 9
63 4.2.1 SIP outbound proxy . . . . . . . . . . . . . . . . . . . . 9
64 4.2.2 Discovery of the SIP outbound proxy . . . . . . . . . . . 9
65 4.3 Registration . . . . . . . . . . . . . . . . . . . . . . . 9
66 4.3.1 Registration required . . . . . . . . . . . . . . . . . . 10
67 4.3.2 Location of the SIP Registrar . . . . . . . . . . . . . . 10
68 4.3.3 Efficient registration . . . . . . . . . . . . . . . . . . 10
69 4.3.4 Registration for roaming and non-roaming cases . . . . . . 10
70 4.3.5 Visited domain name . . . . . . . . . . . . . . . . . . . 10
71 4.3.6 De-registration . . . . . . . . . . . . . . . . . . . . . 11
72 4.4 SIP Compression . . . . . . . . . . . . . . . . . . . . . 12
73 4.4.1 Compression algorithm independency . . . . . . . . . . . . 12
74 4.4.2 Extensibility of the SIP compression . . . . . . . . . . . 12
75 4.4.3 Minimal impact of SIP compression on the network . . . . . 12
76 4.4.4 Optionality of SIP compression . . . . . . . . . . . . . . 13
77 4.5 QoS requirements related to SIP . . . . . . . . . . . . . 13
78 4.5.1 Independence between QoS signaling and SIP . . . . . . . . 13
79 4.5.2 Coordination between SIP and QoS/Resource allocation . . . 13
80 4.6 Prevention of theft of service . . . . . . . . . . . . . . 14
81 4.7 Radio resource authorization . . . . . . . . . . . . . . . 14
82 4.8 Prevention of malicious usage . . . . . . . . . . . . . . 14
83 4.9 Prevention of denial of service . . . . . . . . . . . . . 15
84 4.10 Identification of users . . . . . . . . . . . . . . . . . 15
85 4.10.1 Private user identity . . . . . . . . . . . . . . . . . . 15
86 4.10.2 Public user identities . . . . . . . . . . . . . . . . . . 15
87 4.10.3 Delivery of the dialed public user ID . . . . . . . . . . 17
88 4.11 Identifiers used for routing . . . . . . . . . . . . . . . 17
89 4.12 Hiding requirements . . . . . . . . . . . . . . . . . . . 17
90 4.12.1 Hiding of the network structure . . . . . . . . . . . . . 17
91 4.12.2 Hiding of IP addresses . . . . . . . . . . . . . . . . . . 17
92 4.12.3 SIP hiding proxy . . . . . . . . . . . . . . . . . . . . . 18
93 4.13 Cell-ID . . . . . . . . . . . . . . . . . . . . . . . . . 18
94 4.13.1 Cell-ID in signaling from the UA to the visited and home
95 networks . . . . . . . . . . . . . . . . . . . . . . . . . 18
96 4.13.2 Format of the cell-ID . . . . . . . . . . . . . . . . . . 18
97 4.14 Release of sessions . . . . . . . . . . . . . . . . . . . 18
98 4.14.1 Ungraceful session release . . . . . . . . . . . . . . . . 19
99 4.14.2 Graceful session release . . . . . . . . . . . . . . . . . 19
100 4.15 Routing of SIP messages . . . . . . . . . . . . . . . . . 19
101 4.15.1 SIP outbound proxy . . . . . . . . . . . . . . . . . . . . 20
102 4.15.2 SIP serving proxy in the home network . . . . . . . . . . 20
103 4.15.3 INVITE might follow a different path than REGISTER . . . . 20
104 4.15.4 SIP inbound proxy . . . . . . . . . . . . . . . . . . . . 20
105 4.15.5 Distribution of the Source Routing set of proxies . . . . 20
106 4.16 Emergency sessions . . . . . . . . . . . . . . . . . . . . 21
107 4.17 Identities used for session establishment . . . . . . . . 21
108 4.17.1 Remote Party Identification presentation . . . . . . . . . 21
109 4.17.2 Remote Party Identification privacy . . . . . . . . . . . 21
110 4.17.3 Remote Party Identification blocking . . . . . . . . . . . 21
111 4.17.4 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 22
112 4.17.5 Anonymous session establishment . . . . . . . . . . . . . 22
113 4.18 Charging . . . . . . . . . . . . . . . . . . . . . . . . . 22
114 4.18.1 Support of both prepaid and postpaid models . . . . . . . 22
115 4.18.2 Charging correlation levels . . . . . . . . . . . . . . . 23
116 4.18.3 Charging correlation principles . . . . . . . . . . . . . 23
117 4.18.4 Collection of Session Detailed Information . . . . . . . . 24
118 4.19 General support of additional capabilities . . . . . . . . 24
119 4.19.1 Additional capabilities . . . . . . . . . . . . . . . . . 24
120 4.19.2 DTMF signaling . . . . . . . . . . . . . . . . . . . . . . 24
121 4.19.3 Early Media . . . . . . . . . . . . . . . . . . . . . . . 25
122 4.20 Exchange of session description . . . . . . . . . . . . . 25
123 4.21 Prohibition of certain SDP parameters . . . . . . . . . . 25
124 4.21.1 Prohibition of codecs . . . . . . . . . . . . . . . . . . 25
125 4.21.2 Prohibition of media types . . . . . . . . . . . . . . . . 26
126 4.22 Network initiated re-authentication . . . . . . . . . . . 26
127 4.23 Security model . . . . . . . . . . . . . . . . . . . . . . 26
128 4.24 Access Domain Security . . . . . . . . . . . . . . . . . . 27
129 4.24.1 General requirements . . . . . . . . . . . . . . . . . . . 27
130 4.24.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 29
131 4.24.3 Message Protection . . . . . . . . . . . . . . . . . . . . 29
132 4.24.4 Negotiation of mechanisms . . . . . . . . . . . . . . . . 30
133 4.24.5 Verification of messages . . . . . . . . . . . . . . . . . 31
134 4.25 Network Domain Security . . . . . . . . . . . . . . . . . 31
135 5. Security considerations . . . . . . . . . . . . . . . . . 32
136 6. IANA considerations . . . . . . . . . . . . . . . . . . . 32
137 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . 32
138 Normative References . . . . . . . . . . . . . . . . . . . 32
139 Informational References . . . . . . . . . . . . . . . . . 33
140 Author's Address . . . . . . . . . . . . . . . . . . . . . 35
141 Full Copyright Statement . . . . . . . . . . . . . . . . . 36
143 1. Conventions
145 This document does not specify any protocol of any kind. Therefore,
146 the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
147 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
148 "OPTIONAL" in this document, as described in RFC-2119 [1], does not
149 apply.
151 2. Introduction
153 3GPP has selected SIP [2]as the protocol to establish and tear down
154 multimedia sessions in the IP Multimedia Subsystem (IMS). A
155 description of the IMS can be found in 3GPP Technical Specification
156 23.228 [31]. A comprehensive set of session flows can be found in
157 3GPP Technical Specification 24.228 [32].
159 This document is an effort to define the requirements applicable to
160 the usage of the SIP protocol suite in cellular networks, and
161 particularly in the 3GPP IMS, and in particular, to the Release 5 of
162 the 3GPP specifications. Further releases of the 3GPP specifications
163 may contain additional requirements to SIP. This document focuses on
164 the requirements identified for the 3GPP Release 5 IMS.
166 The rest of this document is structured as follows:
168 o Section 3 offers an overview of the 3GPP IMS. Readers who are not
169 familiar with it should carefully read this section.
171 o Section 4 contains the 3GPP requirements to SIP. Requirements are
172 grouped by categories. Some requirements include a statement on
173 possible solutions that would be able to fulfill the requirement.
174 Note also that, as a particular requirement might be fulfilled by
175 different solutions, not all the solutions might have an impact on
176 SIP.
178 3. Overview of the 3GPP IMS
180 This section gives the reader an overview of the 3GPP IM CN Subsystem
181 (IMS). It is not intended to be comprehensive. But it provides
182 enough information to understand the basis of the 3GPP IMS. Readers
183 are encouraged to find a more detailed description in the 3GPP
184 Technical Specifications 23.060 [30], 23.228 [31] and 24.228 [32].
186 For a particular cellular device, the 3GPP IMS network is further
187 decomposed in a home network and a visited network.
189 An IMS subscriber belongs to his or her home network. Services are
190 triggered and may be executed in the home network. One or more SIP
191 servers are deployed in the SIP home network to support the IP
192 Multimedia Subsystem. Among those SIP servers, there is a SIP
193 serving proxy, which is also acting as a SIP registrar.
194 Authentication/Authorization servers may be part of the home network
195 as well. Users are authenticated in the home network.
197 A SIP outbound proxy is provided to support the UA. The SIP outbound
198 proxy is typically located in the visited network, although it may
199 located in the home network as well. The SIP outbound proxy
200 maintains security associations between itself and the terminals, and
201 interworks with the resource management in the packet network.
203 The SIP outbound proxy is assigned after the mobile device has
204 connected to the access network. Once this proxy is assigned, it
205 does not change while the mobile remains connected to the access
206 network. Thus the mobile can move freely within the access network
207 without SIP outbound proxy reassignment.
209 The home network may support also one or more SIP edge proxies.
210 These nodes may act as the first entry point for SIP signaling to the
211 home network and may decide (with the help of location servers) which
212 SIP registrar server to assign to a particular user. Typically the
213 address of the home network SIP edge proxy is configured in DNS in
214 the form of a DNS NAPTR and SRV records for SIP.
216 Additionally, home and visited networks may deploy, if required, a
217 SIP hiding proxy. The main purpose of the SIP hiding proxy is to
218 hide the network configuration.
220 The 3GPP IM CN Subsystem is designed to be access independent.
221 Access is granted from 3GPP cellular terminals or from other
222 terminals that use other accesses out of the scope of 3GPP.
224 3GPP cellular IP Multimedia terminals use the existing General Packet
225 Radio Service (GPRS) [30] as a transport network for IP datagrams.
226 The terminals first connect to the GPRS network to get an IPv6
227 prefix. In order to do this, the terminals must perform a (GPRS)
228 Attach procedure followed by a (GPRS) PDP Context Activation
229 procedure. These GPRS procedures are required to be completed before
230 any IP Multimedia session can be established.
232 As a result of the above-mentioned GPRS procedures, the terminal has
233 built an IPv6 address. The IPv6 address belongs to the same network
234 address space as the SIP outbound proxy. The address does not change
235 as the mobile terminal moves while still attached to the same network
236 address space.
238 If the terminal moves from a GPRS access to another GPRS access, the
239 above-mentioned GPRS procedures needs to start from the beginning to
240 allocate an IPv6 address to the terminal.
242 Figure 1 shows an overview of the 3GPP architecture for IM CN
243 Subsystem.
245 +-------------+ +----------------+ +----------------+
246 | | | | | +------+ |
247 | | | | | | SIP | |
248 | | | | | |server| |
249 | | | | | | +------+ |
250 +-|+ | | | | | / |
251 | | | | | +------+ | | +------+ |
252 | | | | | | SIP | | | | SIP | |
253 | | ---|-------------|--|----|server|----|---|-|server| |
254 +--+ | | | +------+ | | +------+ |
255 | | | | | |
256 SIP | GPRS access | | Visited Network| | Home Network |
257 dev. +-------------+ +----------------+ +----------------+
259 Figure 1: Overview of the 3GPP IMS architecture
261 Another possible future configuration is depicted in Figure 2. In
262 that case, a general-purpose computer (e.g., a laptop computer) is
263 connected to a GPRS terminal. The computer hosts the Multimedia
264 application (comprising SIP, SDP, RTP, etc.). The GPRS terminal
265 handles the radio access and the GPRS connectivity. Note that, for
266 the sake of clarity, in this example the home network has not been
267 depicted in the figure.
269 +-------------+ +----------------+
270 +-------+ | | | | |
271 | | +-|+ | | | |
272 | | | | | | | +------+ |
273 +-------+ | | | | | | SIP | |
274 / / --------| | ---|-------------|-------|server|------
275 /-------/ +--+ | | | +------+ |
276 | | | |
277 SIP GPRS | GPRS access | | Visited Network|
278 client terminal +-------------+ +----------------+
280 Figure 2: A computer connected to a GPRS terminal
282 Services are typically executed in an application server. The
283 interface between the SIP server and the application server is based
284 on SIP. However, certain operators may want to reuse the existing
285 technology, and therefore, they may need to interoperate SIP with
286 protocols like CAMEL/Intelligent-Network or Open services
287 Architecture (OSA).
289 4. 3GPP Requirements on SIP
291 4.1 General requirements
293 This section does not specify any particular requirement to SIP.
294 However, it includes a list of general requirements that must be
295 considered when developing solutions to particular requirements.
297 4.1.1 Efficient use of the radio interface
299 The radio interface is a scarce resource. As such, the exchange of
300 signaling messages between the mobile terminal and the network should
301 be minimized. All the mechanisms developed should make an efficient
302 use of the radio interface.
304 See also the related requirements in Section 4.4
306 4.1.2 Minimum session setup time
308 All the procedures and mechanisms should have a minimum impact on the
309 session setup time as perceived by the user. When there is a choice
310 between performing tasks at session establishment and in transactions
311 prior to session establishment, then the tasks should be performed
312 prior to session establishment.
314 See also the related requirements in Section 4.4
316 4.1.3 Minimum support required in the terminal
318 As terminals could be rather small devices, memory requirements,
319 power consumption, processing power, etc. should be kept to a
320 minimum. Mandating support for additional protocols in the terminal
321 must meet this requirement.
323 4.1.4 Roaming and non-roaming
325 All the requirements must be met for both roaming and non-roaming
326 scenarios. There should not be a significant change in the signaling
327 procedures between roaming and non-roaming scenarios.
329 4.1.5 Terminal mobility management
331 As terminal mobility is managed by the access network, there is no
332 need to support terminal mobility management in SIP.
334 4.1.6 IP version 6
336 3GPP IMS is solely designed to use IP version 6. As a consequence,
337 all protocols must support IPv6 addesses.
339 4.2 SIP outbound proxy
341 4.2.1 SIP outbound proxy
343 A SIP outbound proxy is provided to support both roaming and non-
344 roaming scenarios. The SIP outbound proxy may be located either in
345 the home network or in the visited network.
347 4.2.2 Discovery of the SIP outbound proxy
349 There must be a general mechanism so that the mobile device (UA)
350 learns the SIP outbound proxy address.
352 The Internet Draft DHCPv6 option for SIP servers [22] seems to
353 fulfill the requirement.
355 In addition to the above expressed requirement, the 3GPP access
356 network may provide the SIP outbound proxy address during access
357 network bearer establishment. This is considered a less general
358 mechanism though.
360 4.3 Registration
362 The home network must maintain one or more SIP registrars. The SIP
363 registrar authenticates the user and registers the IP address where
364 the user can be located.
366 Once the terminal is switched on, the mobile device UA reads its
367 configuration data. This data may be stored in a SIM card or any
368 other memory device. The configuration data contains an
369 identification of the home network. The device finds the SIP
370 registrar address from the home network domain name. The terminal
371 sends the registration through the SIP outbound proxy.
373 In order to support the search of the registrar, the home network
374 contains one or more SIP servers that may be configured in DNS with
375 the NAPTR/SRV record of SIP. These are the home network edge
376 proxies. Their mission is to serve as a first point of contact in
377 the home network, and decide (with the help of location servers)
378 which SIP registrar server to assign to a particular user.
380 The procedures specified in RFC 3263 [11] applied to a REGISTER
381 message seems to be sufficient to meet this requirement.
383 4.3.1 Registration required
385 A user must register to the IMS before he/she can receive any
386 invitation to any sessions. In addition, it is desirable for the
387 user to register before initiating any sessions. The rationale
388 behind this is that:
390 1. The SIP serving proxy in the home network needs to know when the
391 user is available and from which terminal, in order to route
392 received SIP requests for sessions and services.
394 2. The user can be pre-authenticated early, so that authentication
395 does not contribute to post-dial delay. The procedure should not
396 have a penalty on the session setup time (see also the
397 requirement stated in Section 4.1.2).
399 3. The user is assigned a particular serving proxy. The serving
400 proxy downloads the service profile for that user to trigger
401 services.
403 Therefore, 3GPP has mandated the mobile device UA to register before
404 the mobile device UA initiates any session.
406 4.3.2 Location of the SIP Registrar
408 4.3.3 Efficient registration
410 Due to the scarce radio interface resource, a single registration
411 must be sufficient to insure that the mobile UA is reachable from
412 both the home and visited networks.
414 A single REGISTER message, addressed to the registrar, may traverse
415 the SIP outbound proxy. This can install, if needed, soft
416 registration states in the SIP outbound proxy.
418 4.3.4 Registration for roaming and non-roaming cases
420 Independently of whether the UA is roaming or not, it is desirable
421 for the registration procedure to be the same.
423 4.3.5 Visited domain name
425 The home network must be able to validate the existence of a roaming
426 agreement between the home and the visited network. The home network
427 needs to validate that the user is allowed to roam to such a visited
428 network. Therefore, there must be a mechanism so that the visited
429 network identity is known at registration time at the home network.
431 It is acceptable to represent the visited network identity either as
432 a visited network domain name or as a string.
434 4.3.6 De-registration
436 4.3.6.1 De-registration of users
438 There must be a procedure for a user to de-register from the network.
439 This procedure may be used, e.g., when the user deactivates the
440 terminal.
442 We believe that a REGISTER with an expiration timer of 0 will meet
443 the requirement.
445 4.3.6.2 Network initiated de-registration or re-registration
447 There are a number of situations where the network needs to de-
448 register or trigger a re-registration of a previously registered UA.
449 Examples of usage are described in Section 4.3.6.3, Section 4.3.6.4
450 and Section 4.3.6.5.
452 This implies a need for a notification mechanism whereby the UA can
453 be notified of the de-registration, or a request for re-registration.
455 We believe this requirement is met by the SIP-specific event
456 notification [13] and a registration event package [16].
458 4.3.6.3 Network initiated de-registration, network maintenance
460 There might be cases when the SIP serving proxy has to shutdown,
461 e.g., due to maintenance operation. Although this situation is not
462 likely to happen in everyday situations, still it is desirable to
463 have a mechanism to inform the UA that his current registration is
464 being cancelled. The UA may initiate another registration process,
465 that will lead to the selection of a new SIP serving proxy.
467 4.3.6.4 Network initiated de-registration, network/traffic determined
469 The system must support a mechanism to avoid inconsistent information
470 storage and remove any redundant registration information. This case
471 will occur when a subscriber roams to a different network without a
472 prior de-registration. This case occurs in normal mobility
473 procedures when the user roams from one access network to another
474 one, or when imposing new service conditions to roamers.
476 4.3.6.5 Network initiated de-registration, administrative
478 For different reasons (e.g., subscription termination, stolen
479 terminal, etc.) a home network administrative function may determine
480 a need to clear a user's SIP registration. It is desirable to have a
481 mechanism whereby the SIP serving proxy can inform the UA that his
482 registration is being cancelled.
484 There must be a procedure for a the SIP serving proxy to de-register
485 users. The de-registration information must be available at all the
486 proxies that keep registration state and the UA.
488 We believe that a procedure based on SIP-specific event notification
489 [13] and a registration event package [16].
491 4.4 SIP Compression
493 The radio interface is a scarce resource and typically, the available
494 bandwidth over the radio interface is limited. These two factors
495 seem to limit the transport of possibly large SIP messages over the
496 air interface. Particularly, the session setup time might be
497 extended, due to the time needed to transport SIP messages over a
498 limited bandwidth channel.
500 On the other hand, the number and size of certain SIP header values,
501 such as Via or Record-Route, seems to not be limited. A mobile
502 device UA may present limitations in the available memory to store
503 this kind of information.
505 Therefore, there must be a mechanism to efficiently transport SIP
506 signaling packets over the radio interface, by compressing the SIP
507 messages between the mobile device UA and the SIP outbound proxy, and
508 between the SIP outbound proxy and the mobile device UA. Note that
509 compression of IP and transport layer protocol headers that carry
510 these SIP messages is also a requirement, although we believe that
511 does not have an impact on SIP.
513 4.4.1 Compression algorithm independency
515 The chosen solution(s) must be able to allow the operation under
516 several different compression algorithms.
518 4.4.2 Extensibility of the SIP compression
520 The chosen solution(s) must be extensible to facilitate the
521 incorporation of new and improved compression algorithms in a
522 backward compatible way, as they become available.
524 4.4.3 Minimal impact of SIP compression on the network
526 Application specific compression must minimize impacts on existing
527 3GPP access networks (such as base stations transceivers). On the
528 other hand, the compression mechanism should be independent of the
529 access, e.g., the compression must be defined between the mobile
530 device UA and the outbound SIP proxy.
532 4.4.4 Optionality of SIP compression
534 It must be possible to leave the usage of compression for SIP
535 signaling optional. To facilitate mobile terminal roaming between
536 networks which are using compression, the mobile terminal should
537 always support ability to compress SIP signaling. If compression is
538 not supported, communication may continue without compression,
539 depending on the local policy of the visited network.
541 4.4.4.1 Compression reliability
543 The compression mechanism should be reliable and be able to recover
544 automatically from errors generated during the decompression.
546 4.5 QoS requirements related to SIP
548 4.5.1 Independence between QoS signaling and SIP
550 The selection of QoS signaling and resource allocation schemes must
551 be independent of the selected session control protocols. This
552 allows for independent evolution of QoS control and SIP.
554 4.5.2 Coordination between SIP and QoS/Resource allocation
556 4.5.2.1 Allocation before alerting
558 In establishing a SIP session, it must be possible for an application
559 to request that the resources needed for bearer establishment are
560 successfully allocated before the destination user is alerted. Note,
561 however, that it must be also possible for an SIP application in a
562 terminal to alert the user before the radio resources are established
563 (e.g., if the user wants to participate in the media negotiation).
565 We believe this requirement is met by Integration of Resource
566 Management and SIP [17].
568 4.5.2.2 Destination user participates in the bearer negotiation
570 In establishing a SIP session, it must be possible for a terminating
571 application to allow the destination user to participate in
572 determining which bearers shall be established. Although it must be
573 possible to establish the SIP session without user intervention.
575 We believe this requirement is met by the standard SDP negotiation
576 described in SIP [2] and the SDP offer/answer model [12] and the
577 extensions described in Integration of Resource Management and SIP
578 [17].
580 4.5.2.3 Successful bearer establishment
582 Successful bearer establishment must include the completion of any
583 required end-to-end QoS signaling, negotiation and resource
584 allocation.
586 We believe this requirement is met by the procedures described in the
587 Integration of Resource Management and SIP [17] .
589 4.6 Prevention of theft of service
591 Users are typically allocated QoS resources. There is an admission
592 control mechanism that prevents users to exceeds the limits
593 negotiated with the network. The network must prevent unauthorized
594 users to make usage of non-authorized resources. For instance, the
595 network must provide mechanism to prevent a user to use the resources
596 allocated to a second user, and for which this second user may be
597 paying.
599 We believe this requirement may be met by the procedures described in
600 the Private SIP extensions for Media Authorization [18].
602 4.7 Radio resource authorization
604 As radio resources are very valuable the network must be able to
605 manage these in a controlled manner. The network must be able to
606 identify who is using these resources and be able to authorize their
607 usage. For example, a mobile device terminal could execute an
608 unlimited and uncontrolled resorce reservation procedure if the
609 network does not supervise the usage of radio resources.
611 We believe this requirement is met by the procedures described in the
612 Private SIP extensions for Media Authorization [18]..
614 4.8 Prevention of malicious usage
616 The 3GPP IMS must prevent mobile devices for making a malicious usage
617 of the network. For instance, a malicious UA could not follow the
618 Record-Route procedures, so that subsequent request bypass proxies
619 which recorded route.
621 4.9 Prevention of denial of service
623 The risk of a proxy to receive a denial of service attack shall be
624 minimized. For instance, a malicious mobile device could learn a SIP
625 proxy IP address and port number (e.g., in a Record-Route header
626 value) and establish an attack to that proxy.
628 4.10 Identification of users
630 4.10.1 Private user identity
632 In order to use the 3GPP IMS, a user is assigned a private user
633 identity. The home network operator assigns the private user
634 identity, which is used to uniquely identify the user from a network
635 perspective. The private user identity is used, for example, for
636 authentication, authorization, administration, and possibly
637 accounting purposes. Note that the private user identity is not used
638 for routing of SIP messages.
640 The private user identity is a unique global identity defined by the
641 Home Network Operator. The identity takes the form of a Network
642 Access Identifier (NAI) as defined in RFC 2486 [7].
644 The end user does not have access to the private user identity.
645 Typically the identity is stored in a Subscriber Identity Module
646 card.
648 The private user identity is permanently allocated to a user (it is
649 not a dynamic identity), and is valid for the duration of the user's
650 business subscription with the home network.
652 4.10.1.1 Private user ID in registrations
654 The mobile UA must deliver the private user identity to the SIP
655 outbound proxy and the registrar at registration time.
657 The private user identity is used as the basis for authentication
658 during registration of the mobile user. The term authentication is
659 used in this document with the same meaning as it is defined in RFC
660 2828 [8].
662 We believe that this requirement is met by populating the username
663 field of the Authorization: header value of the REGISTER request with
664 the private user identity.
666 4.10.2 Public user identities
668 In order to use the 3GPP IMS, a user is assigned one or more public
669 user identities. The user will make use of the public user identity/
670 identities when requesting communication to other users. For
671 example, the public user identity might be included on a business
672 card.
674 Different public user identities may be grouped into a user profile.
675 A user may have different profiles, each one containing different
676 public user identities. A public user identity can be part of a
677 single user profile.
679 The user may need to register one or more public user identities
680 prior to receiving communications addressed to that public user
681 identity.
683 We believe this requirement is met by populating the From: and To:
684 header values of a REGISTER message with the public user identity.
686 4.10.2.1 Format of the public user identities
688 The public user identity/identities must take the form of a SIP URI
689 (as defined in RFC 3261 [2] and RFC 2396 [4]) or the form of a E.164
690 [37]number.
692 We believe this requirement is met by using SIP URLs and telephone
693 numbers represented in SIP URLs as described in SIP [3]. In
694 addition, tel: URLs as specified in [13] can be used to fulfill the
695 requirement.
697 4.10.2.2 Registration of public user IDs
699 It must be possible to register globally (i.e., through one single UA
700 request) a user that has more than one public identity that belongs
701 to the same user profile, via a mechanism within the IMS. In this
702 case, the user will be registered with all the public identities
703 associated to a user profile.
705 We believe this requirement may be accomplished by external
706 procedures. For example, the user's profile may contain a list of
707 alias identities that the registrar considers active if the primary
708 identity is registered. The user may get informed of the
709 automatically registered public user IDs by subscribing to its own
710 registration state.
712 4.10.2.3 Authentication of the public user ID
714 Public user identities are not authenticated by the 3GPP IMS.
715 However the network authorizes that the public user identity is
716 associated to the registered private user identity.
718 There is a list of public user identities that are associated with
719 each private user ID within the IMS. IMS will reject attempts to use
720 other public identities with this private user ID.
722 4.10.3 Delivery of the dialed public user ID
724 Typically a UA will be registered under a set of different public
725 user IDs. As such, sessions destined to the user can be placed to
726 any of the registered public user IDs. The serving proxy,
727 application server(s) in the termination network may apply certain
728 filtering rules or services based on the public user ID contained in
729 the Request-URI. The UA may also apply certain filtering rules or
730 services based on the called public user ID.
732 As such, it must be possible, for all sessions, to deliver the dialed
733 public user ID to the terminating entities, such as the serving
734 proxy, application servers and the terminating UA.
736 4.11 Identifiers used for routing
738 Routing of SIP signaling within IMS must use SIP URLs as defined in
739 SIP [2]. E.164 [37] format public user identities must not be used
740 for routing within IMS, and session requests based upon E.164 format
741 public user identities will require conversion into SIP URI format
742 for internal IMS usage.
744 We believe that this requirement is achieved by translating E.164
745 numbers into SIP URIs. A database, such as ENUM [10] might do the
746 job.
748 4.12 Hiding requirements
750 Although the requirements included in this section are not optional,
751 the hiding feature is an optional to use through configuration. This
752 means that a network operator can, at his desire, switch the hiding
753 functionality on or off.
755 4.12.1 Hiding of the network structure
757 A network operator need not be required to reveal the internal
758 network structure to another network (in Via, Route, or other
759 headers) that may contain indication of the number of SIP proxies,
760 domain name of the SIP proxies, capabilities of the SIP proxies or
761 capacity of the network.
763 4.12.2 Hiding of IP addresses
765 A network need not be required to expose the explicit IP addresses of
766 the nodes within the network (excluding firewalls and border
767 gateways).
769 4.12.3 SIP hiding proxy
771 In order to support the hiding requirements, a SIP hiding proxy may
772 be included in the SIP signaling path. Such additional proxy may be
773 used to shield the internal structure of a network from other
774 networks.
776 4.13 Cell-ID
778 The identity of the cell through which the 3GPP UA is accessing the
779 IMS (Cell-ID) may be used by the home network to provide localized
780 services or information on the location of the terminal during an
781 emergency call (when emergency calls are handled in IMS, see also the
782 requirement stated in Section 4.16).
784 4.13.1 Cell-ID in signaling from the UA to the visited and home networks
786 Assuming that the Cell-ID is obtained by the UA by other mechanisms
787 outside the scope or beyond SIP, the Cell-ID must be transported at
788 least in the following procedures:
790 o Registration
792 o Session Establishment (Mobile Originated)
794 o Session Establishment (Mobile Terminated)
796 o Session Release
798 The Cell-ID is private information and only of interest in the UA
799 home network. Therefore, the Cell-ID should be removed prior to
800 sending the SIP signaling beyond the originating home network.
802 4.13.2 Format of the cell-ID
804 The cell-ID must be sent in any of the formats described in the 3GPP
805 Technical Specification 23.003 [29].
807 4.14 Release of sessions
809 In addition to the normal mechanisms to release a SIP session (e.g.,
810 BYE), two cases are considered in this section. The ungraceful
811 release of the session (e.g., the terminal moves to an out-of-
812 coverage zone) and the graceful session release ordered by the
813 network (e.g., pre-paid caller runs out of credit).
815 We believe this requirement is met by a SIP entity acting as a so-
816 called transparent back-to-back User Agent.
818 4.14.1 Ungraceful session release
820 If an ungraceful session termination occurs (e.g., flat battery or
821 mobile leaves coverage), when a call stateful SIP proxy server (such
822 as the SIP serving proxy at home) is involved in a session, memory
823 leaks and eventually server failure can occur due to hanging state
824 machines. To ensure stable server operation and carrier grade
825 service, a mechanism to handle the ungraceful session termination
826 issue must be provided. We assume that there is a mechanism by which
827 the SIP outbound proxy is notified, by a mechanism external to SIP,
828 of the ungraceful session termination. This allows transforming the
829 ungraceful session release into a graceful session release ordered by
830 the network (see next section). For example, the SIP outbound proxy,
831 upon reception of the notification of loss of mobile radio coverage,
832 could send a BYE request on behalf of the terminal, although this BYE
833 cannot be authenticated.
835 4.14.2 Graceful session release
837 There must be a mechanism so that an entity in the network may order
838 the release of resources to other entities. This may be used, e.g.,
839 in pre-paid calls when the user runs out of credit.
841 This release must not involve any request to the UA to send out a
842 release request (BYE), as the UA might not follow this request. The
843 receiving entity needs the guarantee that resources are released when
844 requested by the ordering entity.
846 The following objectives must be met:
848 o Accurately report the termination to the charging subsystem.
850 o Release the associated network resources: bearer resources and
851 signaling resources.
853 o Notify other parties to the session, if any, of the session
854 termination.
856 Where feasible, this mechanism should be at the SIP protocol level in
857 order to guarantee access independence for the system.
859 4.15 Routing of SIP messages
860 4.15.1 SIP outbound proxy
862 The 3GPP architecture includes a SIP outbound proxy which is
863 typically located in the visited network (although it may be located
864 in the home network). This outbound proxy provides local services
865 such as compression of SIP messages or security functions. In
866 addition, the outbound proxy may interact with the media reservation
867 mechanism to provide authentication and authorization support for
868 media reservation.
870 All mobile terminal originated session setup attempts must transit
871 the outbound proxy, so that the services provided by the outbound
872 proxy can be delivered to the mobile terminal.
874 4.15.2 SIP serving proxy in the home network
876 The serving proxy in the home network allows triggering of user
877 customized services that are typically executed in an application
878 server.
880 All mobile terminal originated session setup attempts must transit
881 the serving proxy in the home network, so that the proxy can properly
882 trigger the SIP services allocated to the user(e.g., speed dial
883 substitution). This implies a requirement for some sort of source-
884 routing mechanism to assure these proxies are transited correctly.
886 4.15.3 INVITE might follow a different path than REGISTER
888 The path taken by an INVITE request need not be restricted to the
889 specific path taken by a mobile terminal originated REGISTER request,
890 e.g., the INVITE may traverse just the SIP outbound proxy and the SIP
891 serving proxy, without passing through any other proxies. However,
892 the path taken by the INVITE may follow the same path taken by the
893 REGISTER .
895 4.15.4 SIP inbound proxy
897 The visited network may apply certain services and policies to
898 incoming sessions (such as establishment of security services or
899 interaction with the media reservation mechanism). Therefore, the
900 visited network may contain a SIP inbound proxy for terminating
901 sessions. In general, the SIP inbound proxy and the SIP outbound
902 proxy are the same SIP proxy.
904 4.15.5 Distribution of the Source Routing set of proxies
906 Section 4.15.2 and Section 4.15.4 assume that a source routing
907 mechanism is used to effect traversal of the required SIP proxies
908 during session setup.
910 There must be some means of dynamically informing the node which adds
911 the source routing set of proxies that the INVITE has to traverse
912 (e.g., the outbound proxy or serving proxy) of what that set of
913 proxies should be.
915 The hiding requirements expressed in Section 4.12 also apply to the
916 said set of proxies.
918 4.16 Emergency sessions
920 3GPP networks already contain alternative procedures to deliver
921 emergency sessions. The Release 5 of the 3GPP specifications does
922 not add any requirement with respect SIP emergency sessions.
924 4.17 Identities used for session establishment
926 4.17.1 Remote Party Identification presentation
928 It must be possible to present to the caller the identity of the
929 party to which he/she may dial back to return a call.
931 We believe this requirement is met by the procedures described in
932 draft-ietf-sip-asserted-identity [19].
934 4.17.2 Remote Party Identification privacy
936 In addition to the previous requirement, the called party must be
937 able to request that his/her identity not be revealed to the caller.
939 We believe this requirement is met by the procedures described in
940 draft-ietf-sip-privacy-general [20].
942 4.17.3 Remote Party Identification blocking
944 Regulatory agencies, as well as subscribers, may require the ability
945 of a caller to block the display of their caller identification.
946 This function may be performed by the destination subscriber's SIP
947 serving proxy. In this way, the destination subscriber is still able
948 to do a session-return, session-trace, transfer, or any other
949 supplementary service.
951 Therefore, it must be possible that the caller requests to block the
952 display of his/her identity at the callee's display.
954 We believe this requirement is met by the procedures described in
955 draft-ietf-sip-privacy-general [20].
957 4.17.4 Anonymity
959 Procedures are required for an anonymous session establishment.
960 However, sessions are not intended to be anonymous to the originating
961 or terminating network operators.
963 We believe this requirement is met by the procedures described in
964 draft-ietf-sip-privacy-general [20] and draft-ietf-sip-asserted-
965 identity [19].
967 4.17.5 Anonymous session establishment
969 If the caller requests the session to be anonymous, the UAC must not
970 reveal any identity information to the UAS.
972 If the caller requests the session to be anonymous, the terminating
973 network must not reveal any identity or signaling routing information
974 to the destination endpoint. The terminating network should
975 distinguish at least two cases, first if the caller intended the
976 session to be anonymous, and second if the caller's identity was
977 deleted by a transit network.
979 We believe this requirement is met by the procedures described in
980 draft-ietf-sip-privacy-general [20] and draft-ietf-sip-asserted-
981 identity [19].
983 4.18 Charging
985 The 3GPP charging implications are described in the 3GPP Technical
986 Specification 32.225 [34].
988 4.18.1 Support of both prepaid and postpaid models
990 Operators may choose to offer prepaid and/or postpaid services. The
991 prepaid model is accomplished with the support of the on-line
992 charging model. The postpaid model is accomplished by the support of
993 the off-line charging model.
995 On-line charging is the process where charging information can
996 affect, in real-time, the service rendered to the user, such as
997 request for a graceful release of an existing session. On-line
998 charging interacts with the SIP signaling.
1000 Off-line charging is the process where charging information does not
1001 affect, in real-time, the service rendered to the user.
1003 4.18.2 Charging correlation levels
1005 The following levels of correlation for IMS charging are considered:
1007 o Correlation within a session. A session may comprise a number of
1008 media components. It must be possible to correlate the charging
1009 data of the different media components belonging to a session.
1011 o Correlation at media component level. For a session comprising
1012 several media types (such as audio and video), charging data is
1013 generated for each media type and needs to be correlated between
1014 network elements. For this, a media identifier shall be unique
1015 and shall clearly identify to which media type of a session this
1016 charging information belongs to. This component identifier is not
1017 exchanged between network elements and is based on the ordering of
1018 media flows in the SDP. This ordering is the same as the one used
1019 in the binding information passed to the GPRS network.
1021 4.18.3 Charging correlation principles
1023 To support the correlation of charging information, the following
1024 principles apply to both offline and online charging:
1026 o The correlation of charging information for an IMS session is
1027 based on the use of IMS Charging Identifiers (ICID).
1029 o The first IMS network entity within the SIP signaling path is
1030 responsible for assigning an ICID. This ICID shall then be passed
1031 along the whole session path in an end-to-end manner. However,
1032 this shall not preclude further elements (other SIP proxies) along
1033 the session path generating additional identifiers to be passed
1034 along.
1036 o The ICID is passed to all IMS network entities in the session
1037 signaling path. This is performed using SIP signaling.
1039 o The addresses of the charging functions are passed by the serving
1040 SIP proxy to all IMS network entities in the session signaling
1041 path. This is to provide a common destination for all the
1042 charging records generated by each IMS network entity with the
1043 same ICID.
1045 o For the charging correlation between the GPRS network and the IMS,
1046 one or more GPRS Charging IDs, which identify the PDP contexts of
1047 the session, are passed from the GPRS network to the IMS.
1049 o The GPRS Charging IDs are passed by the outbound SIP proxy to the
1050 serving SIP proxy and the Application Servers using SIP signaling.
1051 They are not transferred from one home IMS (e.g., caller's home)
1052 to another home IMS (e.g., callee's home).
1054 o Inter Operator Identifiers (IOI) are shared betweenthe caller's
1055 home IMS and the callee's home IMS to provide identifiers of the
1056 home originating and home terminating networks.
1058 4.18.4 Collection of Session Detailed Information
1060 The SIP serving proxy or another SIP server in the home network must
1061 be able to log details of all sessions, such as the duration, source,
1062 and destination of a session, to provide to the charging subsystem.
1064 4.19 General support of additional capabilities
1066 4.19.1 Additional capabilities
1068 3GPP is interested on applying and using additional services, like
1069 those described in SIP Call Control - Transfer [23], SIP Basic Call
1070 Flow Examples [24], SIP PSTN Call Flows [25] and SIP service examples
1071 [26]. Although 3GPP is not going to standardize additional services,
1072 3GPP may make sure that the capabilities that enable those services
1073 are granted in the network.
1075 As such we believe that the SIP REFER method [27] and the Replaces
1076 header [28] constitute a complement to be used as an enabler in order
1077 to meet the above requirement.
1079 4.19.2 DTMF signaling
1081 Support for voice calls must provide a similar level of service to
1082 the existing circuit based voice service. This includes the ability
1083 to utilize DTMF signaling e.g., for control of interactive voice
1084 response systems such as ticket sales lines, timetable information
1085 etc.
1087 The transport of DTMF tones from the mobile terminal to target
1088 systems that may be in the PSTN, or to SIP based solutions (i.e., no
1089 PSTN connection) must be supported.
1091 The transport of DTMF signals may be required for the whole call,
1092 just for the first part, or from some later point in the call, i.e.,
1093 the start time and duration of such signaling is unpredictable.
1095 We believe that the mechanisms specified in RFC 2833 [9] meet the
1096 requirement without impacting SIP.
1098 4.19.3 Early Media
1100 As mobile terminals will frequently interoperate with the PSTN,
1101 support for early media is required.
1103 4.20 Exchange of session description
1105 Typically a session description protocol like SDP is used in SIP to
1106 describe the media streams and codecs needed to establish the
1107 session. SIP uses an offer/answer model of the session description,
1108 as described in RFC 3264 [12] where one of the parties offers his
1109 session description and the other answers to that offer.
1111 In the 3GPP IMS, the mobile terminals might have restrictions with
1112 the memory, DSP capacity, etc. As such, it is required a mechanism
1113 by which the Session Description negotiation may conclude with one
1114 out of many codecs per media stream. Both UAC and UAS must know,
1115 prior to any media is sent or received, which codec is used for each
1116 media stream.
1118 In the 3GPP IMS, an efficient use of the network and radio resources
1119 is an important requirement. As such, the network should know in
1120 advance which codecs is used for a particular media stream. The
1121 network access control may use this information to grant access to
1122 the network and control the resource utilization.
1124 Additionally, it is required that the party who pays for the resource
1125 utilization has the opportunity to decide the codecs to use, once
1126 both end parties are aware of the capabilities supported at the
1127 remote UA.
1129 Therefore, it is required a mechanism by which both UAC and UAS have
1130 the ability to negotiate and trim down the number of codecs used per
1131 media stream, so that at the end of the negotiation there can be a
1132 reduced set of agreed codecs per media stream.
1134 We believe that the mechanism specified in RFC 3264 [12] meet the
1135 requirement.
1137 4.21 Prohibition of certain SDP parameters
1139 4.21.1 Prohibition of codecs
1141 The SIP outbound proxy may contain local policy rules with respect
1142 the codecs allowed in the network. For instance, certain networks
1143 may disallow high bandwidth consuming audio codecs. There has to be
1144 a mechanism whereby the SIP outbound proxy can reject a session
1145 establishment attempt when a codec is prohibited in the network due
1146 to local policy.
1148 4.21.2 Prohibition of media types
1150 Certain user's subscription may include restrictions to use certain
1151 media types. For instance, a user may not be allowed to establish a
1152 video session. The SIP serving proxy in the home network downloads
1153 the user profile, which contains the rules of this kind of
1154 restrictions.
1156 As the establishment of sessions traverse the SIP serving proxy in
1157 the home network, this proxy can prohibit an attempt to establish a
1158 session that includes a non-allowed media type for the user.
1159 Therefore, there has to be a mechanism whereby the SIP serving proxy
1160 can reject a session establishment attempt when the session includes
1161 a forbidden media type.
1163 4.22 Network initiated re-authentication
1165 Network operators need to authenticate users to ensure that they are
1166 charged appropriately for the services they use. The re-
1167 authentication done when the user initiates a message will not
1168 suffice for this purpose, as described below.
1170 If the duration of the authentication period is set to a relatively
1171 low value to ensure that the user cannot incur a high amount of
1172 charges between two authentications, it may create a lot of
1173 unnecessary authentications of users which have remained largely
1174 inactive, and therefore utilize unnecessary air interface resources.
1176 If the duration of the authentication period is set to a relatively
1177 high value to avoid these unnecessary authentications the risk is
1178 then that some users may incur high charges between authentications.
1180 A user's authentication is automatically invalidated when a certain
1181 threshold for charges (or number, or duration of sessions) is reached
1182 without giving the user a chance to re-authenticate, even if a valid
1183 registration exists. This would not provide an adequate level of
1184 service.
1186 Consequently it must be possible for the network to initiate a re-
1187 authentication process at any time. The triggers must be set within
1188 the network and may include charging thresholds, number of events,
1189 session duration etc.
1191 4.23 Security model
1193 Section 4.23, Section 4.24 and Section 4.25 have been based on the
1194 3GPP Technical Specifications 33.203 [35], 23.228 [31] and 33.210
1195 [36].
1197 The scope for security of the 3GPP IMS is securing the SIP signaling
1198 between the various SIP entities. Protecting the end-to-end media
1199 streams may be a future extension but is not considered in the
1200 Release 5 version of the IMS specifications.
1202 Each operator providing IMS services acts as its own domain of trust,
1203 and shares a long-term security association with its subscribers
1204 (e.g., pre-shared keys). Operators may enter into roaming agreements
1205 with other operators, in which case a certain level of trust exists
1206 between their respective domains.
1208 SIP user agents must authenticate to their home network before the
1209 use of IMS resources is authorized. In the Release 5 of the 3GPP IMS
1210 specifications, authentication is performed during registration and
1211 re-registrations.
1213 Portions of the SIP signaling must be protected hop-by-hop. Looking
1214 at Figure 1 in Section 3, we can distinguish two distinct zones where
1215 the required security is unique:
1217 o Access Domain: Between the SIP user device and the visited
1218 network.
1220 o Network Domain: Between the visited and the home networks, or
1221 inside the home network.
1223 Characteristics needed in the Access Domain are quite different from
1224 those of the Network Domain because the terminal's requirements on
1225 mobility, computation restriction, battery limit, bandwidth
1226 conservation and radio interface. SIP entities in the access domain
1227 should be able to maintain security contexts with a large group of
1228 users in parallel. Furthermore, Access Domain provides user specific
1229 security associations while Network Domain provides security
1230 associations between network nodes. Therefore the weight of
1231 protocols and algorithms and the compliance of them with compression
1232 mechanisms are very important to Access Domain Security. It is
1233 therefore required that the security solutions must allow different
1234 mechanisms in these two domains.
1236 4.24 Access Domain Security
1238 4.24.1 General requirements
1239 4.24.1.1 Scalability and Efficiency
1241 3GPP IMS is characterized by a large subscriber base of up to a
1242 billion users, all of which must be treated in a secure manner.
1244 The security solutions must allow global roaming among a large number
1245 of administrative domains.
1247 4.24.1.2 Bandwidth and Roundtrips
1249 The wireless interface in 3GPP terminals is an expensive resource
1250 both in terms of power consumption and maximum utilization of scarce
1251 spectrum. Furthermore, cellular networks have typically long round-
1252 trip time delays, which must be taken in account in the design of the
1253 security solutions.
1255 Any security mechanism that involves 3GPP terminals should not
1256 unnecessarily increase the bandwidth needs.
1258 All security mechanisms that involve 3GPP terminals should minimize
1259 the number of necessary extra roundtrips. In particular, during
1260 normal call signaling there should not be any additional security
1261 related messages.
1263 For example, once an IPsec security association or a TLS connection
1264 is established, no additional round trips are required during session
1265 setup. However, the requirement of minimizing the number of round
1266 trips is hard to satisfy with IKE or TLS. It seems that IKE [6] adds
1267 a number of roundtrips, particularly if run together with legacy
1268 authentication extensions developed in the IPSRA WG. TLS [3] uses
1269 fewer roundtrips, but on the other hand doesn't support UDP.
1271 4.24.1.3 Computation
1273 It must be possible for mobile device terminals to provide security
1274 without requiring public key cryptography and/or certificates. 3GPP
1275 IMS may, however, include optional security schemes that employ these
1276 techniques.
1278 Current HTTP authentication methods use only symmetric cryptography
1279 as required here. Lower-layer mechanisms (ex: IKE, TLS) require
1280 implementation of public-key cryptography and/or Diffie-Helman. If
1281 these lower-layer mechanisms were used, the mobile terminal would
1282 authenticate and negotiate session keys with the visited network
1283 using only symmetric methods.
1285 4.24.1.4 Independence of the transport protocol
1287 The selected security mechanism should work with any transport
1288 protocol allowed by SIP (e.g., TCP, UDP).
1290 4.24.2 Authentication
1292 Authentication, as used in this context, means entity authentication
1293 that enables two entities to verify the identity of the respective
1294 peer.
1296 4.24.2.1 Authentication method
1298 A strong, mutual authentication must be provided.
1300 The authentication method must be able to work when there are zero or
1301 more SIP proxies in the SIP path between the authenticator and the
1302 authenticated user.
1304 It must be possible to support extensible authentication methods.
1305 Therefore authentication using an extensible authentication framework
1306 is strongly recommended.
1308 Authentication methods based on the secure storage of long-term keys
1309 used for authentication and the secure execution of authentication
1310 algorithms must be supported.
1312 The SIP client's credentials must not be transferred as plain text.
1314 3GPP intends to reuse UMTS AKA [15]. UMTS AKA applies a symmetric
1315 cryptographic scheme, provides mutual authentication, and is
1316 typically implemented on a so-called SIM card that provides secure
1317 storage on the user's side.
1319 Additional requirements related to message protection that apply to
1320 the authentication method are stated in Section 4.24.3.
1322 4.24.3 Message Protection
1324 4.24.3.1 Message Protection Mechanisms
1326 SIP entities (typically a SIP client and a SIP proxy) must be able to
1327 communicate using integrity and replay protection. By integrity, we
1328 mean the ability for receiver of a message to verify that the message
1329 has not been modified in transit. SIP entities should be able to
1330 communicate confidentially. In 3GPP IMS, these protection modes must
1331 be based on initial authentication. Integrity protection and
1332 confidentiality must be possible using symmetric cryptographic keys.
1334 It must be possible to handle also error conditions in a satisfactory
1335 manner as to allow recovery (see also Section 4.3.6.3 and Section
1336 4.14).
1338 It must be possible to provide this protection between two adjacent
1339 SIP entities. In future network scenarios it may also be necessary
1340 to provide this protection through proxies, though the 3GPP Release 5
1341 IMS does not require this.
1343 The security mechanism must be able to protect a complete SIP
1344 message.
1346 If header compression/removal or SIP compression is applied to SIP
1347 messages, it must be compatible with message protection.
1349 4.24.3.2 Delegation
1351 3GPP IMS implements distributed security functions responsible for
1352 authentication and message protection.
1354 It must be possible to perform an initial authentication based on
1355 long-term authentication credentials, followed by subsequent
1356 protected signaling that uses short-term authentication credentials,
1357 such as session keys created during initial authentication. The used
1358 authentication mechanism is able to provide such session keys. It
1359 must be possible to apply subsequent message protection as soon as
1360 possible, even during the initial authentication period.
1362 Initial authentication is performed between the SIP UA and the
1363 authenticating SIP serving proxy in the home network. However, the
1364 authentication mechanism must not require access to the long-term
1365 authentication credentials in these nodes. In the home network, the
1366 authenticating SIP serving proxy must support interaction with a
1367 dedicated authentication server in order to accomplish the
1368 authentication task. At the client side a secured (tamper-resistant)
1369 device storing the long-term credentials of the user must perform the
1370 authentication.
1372 Additionally, the SIP serving proxy that performed the initial
1373 authentication must be able to securely delegate subsequent SIP
1374 signaling protection (e.g., session keys for integrity or encryption)
1375 to an authorized SIP proxy further downstream. The tamper-resistant
1376 device at the client side must be able to securely delegate the
1377 session keys to the SIP user agent.
1379 4.24.4 Negotiation of mechanisms
1381 A method must be provided to securely negotiate the security
1382 mechanisms to be used in the access domain.
1384 This method must at least support the negotiation of different
1385 security mechanisms providing integrity protection and encryption,
1386 algorithms used within these mechanisms and additional parameters
1387 they require to be exchanged.
1389 The negotiation mechanism must protect against attackers who do not
1390 have access to authentication credentials. In particular, the
1391 negotiation mechanism must be able to detect a possible man-in-the-
1392 middle attacker who could influence the negotiation result such that
1393 services with weaker or no security are negotiated.
1395 A negotiation mechanism is generally required in all secure protocols
1396 to decide which security services to use and when they should be
1397 started. This security mechanism serves algorithm and protocol
1398 development as well as interoperability. Often, the negotiation is
1399 handled within a security service. For example, the HTTP
1400 authentication scheme includes a selection mechanism for choosing
1401 among appropriate algorithms. Note that when referring to
1402 negotiation we mean just the negotiation, not all functions in
1403 protocols like IKE. For instance, we expect the session key
1404 generation is to be a part of the initial authentication.
1406 SIP entities must be able to use the same security mode parameters to
1407 protect several SIP sessions without re-negotiation. For example,
1408 security mode parameters may be assumed to be valid within the
1409 lifetime of a registration. Note that it is necessary to amortize
1410 the cost of security association setup and parameter negotiation over
1411 several INVITEs.
1413 4.24.5 Verification of messages
1415 4.24.5.1 Verification at the SIP outbound proxy
1417 The SIP outbound proxy must be able to guarantee the message origin
1418 and verify that the message has not been changed (e.g., it is
1419 integrity protected).
1421 4.24.5.2 Verification at the SIP serving proxy
1423 The serving SIP proxy needs to receive an indication if the outbound
1424 proxy was able to verify the message origin and, in the case of a
1425 REGISTER request, whether it was integrity protected or not.
1427 4.25 Network Domain Security
1429 Message authentication, key agreement, integrity and replay
1430 protection, and confidentiality must be provided for communications
1431 between SIP network entities such as proxy servers.
1433 Network domain security mechanisms must be scalable up to a large
1434 number of network elements.
1436 3GPP intends to make it mandatory to have the protection discussed
1437 above at least between two operators, and optional within an
1438 operator's own network. Security gateways exist between operator's
1439 networks.
1441 We believe the above requirements to be fulfilled by applying
1442 security mechanisms as specified in the current IP Security standards
1443 specified in RFC 2401 [5].
1445 5. Security considerations
1447 This document does not define a protocol, but still presents some
1448 security requirements to protocols. The main security requirements
1449 are stated in Section 4.23, Section 4.24 and Section 4.25.
1450 Additional security-related issues are discussed under Section 4.6,
1451 Section 4.7, Section 4.8, Section 4.9, Section 4.12 and Section 4.10.
1453 6. IANA considerations
1455 This document introduces no new IANA considerations.
1457 7. Contributors
1459 The following people contributed to this document:
1461 Duncan Mills (Vodafone), Gabor Bajko (Nokia), Georg Mayer (Siemens),
1462 Francois-Xerome Derome (Alcatel), Hugh Shieh (AWS), Andrew Allen
1463 (dynamicsoft), Sunil Chotai (mmO2), Keith Drage (Lucent), Jayshree
1464 Bharatia (Nortel), Kevan Hobbis (Huthison 3G UK), Dean Willis
1465 (dynamicsoft), Krisztian Kiss (Nokia), Vesa Torvinen (Ericsson), Jari
1466 Arkko (Ericsson), Sonia Garapaty (Nortel).
1468 Normative References
1470 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1471 Levels", BCP 14, RFC 2119, March 1997.
1473 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1474 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
1475 Session Initiation Protocol", RFC 3261, June 2002.
1477 Informational References
1479 [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
1480 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1481 1999.
1483 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1484 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1485 1998.
1487 [5] Kent, S. and R. Atkinson, "Security Architecture for the
1488 Internet Protocol", RFC 2401, November 1998.
1490 [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
1491 RFC 2409, November 1998.
1493 [7] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
1494 2486, January 1999.
1496 [8] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
1498 [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
1499 Telephony Tones and Telephony Signals", RFC 2833, May 2000.
1501 [10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
1502 2000.
1504 [11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
1505 (SIP): Locating SIP Servers", RFC 3263, June 2002.
1507 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1508 Session Description Protocol (SDP)", RFC 3264, June 2002.
1510 [13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
1511 Notification", RFC 3265, June 2002.
1513 [14] Olson, S., Camarillo, G. and A. Roach, "Support for IPv6 in
1514 Session Description Protocol (SDP)", RFC 3266, June 2002.
1516 [15] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
1517 Protocol (HTTP) Digest Authentication Using Authentication and
1518 Key Agreement (AKA)", RFC 3310, September 2002.
1520 [16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
1521 Package for Registrations", draft-rosenberg-sip-reg-00 (work in
1522 progress), May 2002.
1524 [17] Rosenberg, J., Camarillo, G. and F. Andreasen, "Integration of
1525 Resource Management and SIP", draft-ietf-sip-manyfolks-
1526 resource-07 (work in progress), April 2002.
1528 [18] Evans, D., Marshall, W. and F. Andreasen, "SIP Extensions for
1529 Media Authorization", draft-ietf-sip-call-auth-06 (work in
1530 progress), May 2002.
1532 [19] Watson, M., Peterson, J. and C. Jennings, "Private Extensions
1533 to the Session Initiation Protocol (SIP) for Asserted Identity
1534 within Trusted Networks", draft-ietf-sip-asserted-identity-02
1535 (work in progress), August 2002.
1537 [20] Peterson, J., "A Privacy Mechanism for the Session Initiation
1538 Protocol (SIP)", draft-ietf-sip-privacy-general-01 (work in
1539 progress), June 2002.
1541 [21] Droms, R., Perkins, C., Bound, J., Volz, B., Carney, M. and T.
1542 Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
1543 draft-ietf-dhc-dhcpv6-26 (work in progress), June 2002.
1545 [22] Volz, B. and H. Schulzrinne, "DHCPv6 Options for SIP Servers",
1546 draft-ietf-sip-dhcpv6-00 (work in progress), April 2002.
1548 [23] Sparks, R., "SIP Call Control - Transfer", draft-ietf-sip-cc-
1549 transfer-05 (work in progress), May 2002.
1551 [24] Johnston, A., "Session Initiation Protocol Basic Call Flow
1552 Examples", draft-ietf-sipping-basic-call-flows-01 (work in
1553 progress), October 2002.
1555 [25] Johnston, A., "Session Initiation Protocol PSTN Call Flows",
1556 draft-ietf-sipping-pstn-call-flows-00 (work in progress),
1557 August 2002.
1559 [26] Johnston, A., "SIP Service Examples", draft-ietf-sipping-
1560 service-examples-02 (work in progress), July 2002.
1562 [27] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-06
1563 (work in progress), July 2002.
1565 [28] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation
1566 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-02
1567 (work in progress), May 2002.
1569 [29] 3GPP, "TS 23.003 Numbering, addressing and identification
1570 (Release 5)", September 2002, .
1573 [30] 3GPP, "TS 23.060:General Packet Radio Service (GRPS); Service
1574 Description; Stage 2", September 2002, .
1577 [31] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) -
1578 Release 5", September 2002, .
1581 [32] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia call
1582 control based on SIP and SDP", September 2002, .
1585 [33] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) -
1586 Release 5", September 2002, .
1589 [34] 3GPP, "TS 32.225: Telecommunication Management; Charging
1590 Management; Charging Data Description for IP Multimedia
1591 Subsystem; (Release 5)", September 2002, .
1594 [35] 3GPP, "TS 32.203: 3G Security; Access security for IP based
1595 services; (Release 5)", September 2002, .
1598 [37] ITU-T, "Recommendation E.164 (05/97): The international public
1599 telecommunication numbering plan", May 1997, .
1603 Author's Address
1605 Miguel A. Garcia Martin
1606 Ericsson
1607 Hirsalantie 11
1608 Jorvas FIN-02420
1609 Finland
1611 EMail: miguel.a.garcia@ericsson.com
1613 Full Copyright Statement
1615 Copyright (C) The Internet Society (2002). All Rights Reserved.
1617 This document and translations of it may be copied and furnished to
1618 others, and derivative works that comment on or otherwise explain it
1619 or assist in its implementation may be prepared, copied, published
1620 and distributed, in whole or in part, without restriction of any
1621 kind, provided that the above copyright notice and this paragraph are
1622 included on all such copies and derivative works. However, this
1623 document itself may not be modified in any way, such as by removing
1624 the copyright notice or references to the Internet Society or other
1625 Internet organizations, except as needed for the purpose of
1626 developing Internet standards in which case the procedures for
1627 copyrights defined in the Internet Standards process must be
1628 followed, or as required to translate it into languages other than
1629 English.
1631 The limited permissions granted above are perpetual and will not be
1632 revoked by the Internet Society or its successors or assigns.
1634 This document and the information contained herein is provided on an
1635 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1636 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1637 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1638 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1639 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1641 Acknowledgement
1643 Funding for the RFC Editor function is currently provided by the
1644 Internet Society.