idnits 2.17.1 draft-calhoun-sip-aaa-reqs-04.txt: -(648): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(651): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(654): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(745): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(748): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(751): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(755): 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 8 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As stated in section 2.1, it is a requirement that a user MUST not be tied to a specific SIP server. This is necessary for many reasons, including scaling and to minimize deployment issues when SIP servers are added to the network to relieve traffic load. In this document, the SIP server that has been either statically or dynamically assigned to serve a particular user is called the Serving SIP Proxy in the home network. This document assumes that the Serving SIP Proxy is always assigned in the home network of the user. -- 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: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 645, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 654, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 657, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 660, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2486 (ref. '6') (Obsoleted by RFC 4282) == Outdated reference: A later version (-01) exists of draft-schulzrinne-sin-00 ** Obsolete normative reference: RFC 1409 (ref. '8') (Obsoleted by RFC 1416) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Henrik Basilier 3 Category: Informational Ericsson, Inc. 4 Title: draft-calhoun-sip-aaa-reqs-04.txt Pat R. Calhoun 5 Date: March 2002 Black Storm Networks 6 Matt Holdrege 7 ipVerse 8 Tony Johansson 9 Ericsson, Inc. 10 James Kempf 11 Sun Microsystems, Inc. 12 Jaakko Rajaniemi 13 Nokia Networks 15 AAA Requirements for IP Telephony/Multimedia 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 This document is an individual contribution for consideration by the 39 SIP Working Group of the Internet Engineering Task Force. Comments 40 should be submitted to the diameter@diameter.org mailing list. 42 Distribution of this memo is unlimited. 44 Copyright (C) The Internet Society 2001. All Rights Reserved. 46 Abstract 48 The AAA Working Group has been defining requirements for Network 49 Access in Inter-Domain (roaming) networks, including requirements 50 from the Mobile IP and NASREQ Working Groups. Some of these 51 requirements were input from work done in the 3rd Generation wireless 52 SDOs. These same SDO's have a need to tie their IP Intelligent 53 Servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their 54 AAA infrastructure. 56 This Internet Draft describes requirements from 3rd Generation 57 wireless SDOs, discusses an architecture that satisfies those 58 requirements and deduces requirements for detailed definition of SIP- 59 AAA interworking. Furthermore, the Draft is intended to stimulate 60 discussions within the SIPPING Working Group, in order to come up 61 with a set of requirements that could then be used to begin 62 informative protocol design (meaning a new application extension to 63 Diameter) in the AAA Working Group. 65 Table of Contents 67 1.0 Introduction 68 1.1 Requirements language 69 1.2 Abbreviations 70 2.0 Network Architecture 71 2.1 Prerequisites for the 3G SDOs 72 2.2 Registration 73 2.3 Invitation 74 2.3.1 Invitation terminating in the mobile node 75 2.3.2 Invitation originating from the mobile node 76 2.3.3 Session accounting 77 3.0 Requirements 78 4.0 Security Considerations 79 5.0 References 80 6.0 Acknowledgements 81 7.0 Authors' Addresses 82 8.0 Full Copyright Statement 84 1.0 Introduction 86 The AAA Working Group has been defining requirements for Network 87 Access in Inter-Domain (roaming) networks, including requirements 88 from the Mobile IP and NASREQ Working Groups. Some of these 89 requirements were input from work done in the 3rd Generation wireless 90 SDOs. These same SDO's have a need to tie their IP intelligent 91 servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their 92 AAA infrastructure. 94 This Internet Draft describes requirements from 3rd Generation 95 wireless SDOs, discusses an architecture that satisfies those 96 requirements and deduces requirements for detailed definition of SIP- 97 AAA interworking. Furthermore, the Draft is intended to stimulate 98 discussions within the SIPPING Working Group, in order to come up 99 with a set of requirements that could then be used to begin 100 informative protocol design (meaning a new application extension to 101 Diameter) in the AAA Working Group. 103 1.1 Requirements language 105 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 106 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 107 described in [3]. 109 1.2 Abbreviations 111 3GPP: Third Generation Partnership Project 113 3GPP2: Third Generation Partnership Project 2 115 AAA: Authentication, Authorization and Accounting 117 DNS: Domain Name Server 119 DSI: Dynamic Subscriber Information database 121 SDO: Standard Development Organization 123 SIP: Session Initiation Protocol 125 2.0 Network Architecture 127 This section describes details of a scalable network architecture 128 based on SIP using a backend AAA infrastructure for use in 3G and 129 possibly other wired and wireless networks. We will detail how the 130 registration procedure will occur. We will also investigate how a SIP 131 invitation will proceed. 133 The authors wish to state that much of this work is still in progress 134 in various other groups including the SIP WG and 3G SDOs, and is 135 subject to change. The ideas described in this document do not 136 represent a final agreement in any working group or SDOs, but does 137 include ideas from well established positions in the related groups. 138 This document will be updated when further SIP, AAA, and 3G 139 requirements are received. 141 This document is also intended as an informal method for IETF SIP 142 experts to feed in their expertise into the 3G standardization 143 efforts through comments on this Internet Draft. 145 Although the next generation wireless networks (3G) are a driving 146 force towards the integration of SIP and AAA, it is desirable that 147 the architecture proposed be similar, if not identical, to the 148 wireline architecture. 150 2.1 Prerequisites for the 3G SDOs 152 The usage of SIP and Diameter within 3GPP and 3GPP2 is or is expected 153 to be specified in the respective SDOs, which set some prerequisites 154 on the interworking between the 3G SDOs SIP architecture and the AAA 155 infrastructure. There is a separate discussion about the way 3GPP 156 and 3GPP2 defines the usage of SIP. This document focuses only on SIP 157 - AAA related issues. 159 The following requirements are identified due to the perceived need 160 of evolving existing telecommunications infrastructure rather than 161 build new independent ones as well as the need to solve problems 162 identified with existing systems: 164 1. It is required that the home network always maintain the 165 control of sessions and services because service mobility can 166 be easier realized. 168 2. Scalability of the architecture is required. This will 169 minimize deployment issues when SIP servers are added to the 170 network to relieve traffic load. 172 3. The distributed architecture of the 3G network shall be hidden 173 from the user. Thus a user must not be tied to a particular SIP 174 server. 176 4. Performance considerations: the operational architecture of 177 hosts that serve many users shall be kept as simple as 178 possible. Resource consuming operations shall be dedicated to 179 servers that can implement load sharing. 181 5. Necessity of SIP-AAA interworking: A 3GPP or 3GPP2 operator 182 requires its SIP servers to have access through AAA to 183 subscriber information so that they can request authorization 184 and authentication information before granting access to the 185 user to the multimedia services he or she may have subscribed 186 to. An operator may therefore want the possibility to restrict 187 the usage of SIP servers to authorized users only. Accounting 188 may be used to gather usage data of SIP servers for a specific 189 user. 191 6. Multiple access networks may exist: authorization based on the 192 authorization from the access network does not guarantee access 193 rights for SIP services. 195 2.2 Registration 197 In this section, we will provide an example of a user registering his 198 device. The scenario described is one where the user is roaming in a 199 visited network, typically owned and operated by a different service 200 provider. This is however seen as a superset of the scenario where 201 the user is in his home network, which is therefore not explicitly 202 described. 204 As stated in section 2.1, it is a requirement that a user MUST not be 205 tied to a specific SIP server. This is necessary for many reasons, 206 including scaling and to minimize deployment issues when SIP servers 207 are added to the network to relieve traffic load. In this document, 208 the SIP server that has been either statically or dynamically 209 assigned to serve a particular user is called the Serving SIP Proxy 210 in the home network. This document assumes that the Serving SIP Proxy 211 is always assigned in the home network of the user. 213 One other important consequence from the requirements in section 2.1 214 is the ability to have a Home entry SIP Proxy, acting as a SIP proxy. 215 The Home entry SIP Proxy will access a Dynamic Subscriber Information 216 (DSI) database through the AAAH in order to identify the Serving SIP 217 Proxy in the home network serving the particular user. This Home 218 entry SIP Proxy MAY be used both for incoming SIP Sessions (SIP 219 INVITEs originating in another network) as well as messages 220 originating from roaming mobiles (accessing functions in their home 221 network from a different domain/provider) if there was a desire to 222 hide the network configuration. If there was no desire to hide the 223 network configuration the SIP INVITEs MAY be originated directly to 224 the Serving SIP Proxy in the home network. 226 Furthermore, a Outbound SIP Proxy in the Visited network MAY be 227 present. The Outbound SIP Proxy is the first point of contact in the 228 visited network for a multimedia user. The Outbound SIP Proxy behaves 229 like a Proxy (as defined in [1] or subsequent versions), i.e. it 230 accepts requests and processes them internally or forwards them on to 231 the Home entry SIP Proxy, possibly after translation. 233 There could be several methods for a mobile node to find its Home 234 entry SIP Proxy / Outbound SIP Proxy or for any other node to find 235 the Home entry SIP Proxy Contact of a user. Although the exact 236 methods to use is outside the scope of this document, we have assumed 237 the use of Domain Name Service (DNS) throughout this document. 239 Home Network 240 +--------+ +----------+ 241 +------->|xyz.com |<----->| xyz.com | 242 | | AAAH |<--+ | DSI | 243 | +--| server +-+ | | Database | 244 | | +--------+ | | +----------+ 245 | | | | 246 6.AAA|7.AAA| 4.AAA| |3.AAA 247 Req| Rsp| Rsp| | Req 248 | v v | 249 +--+--------+ 5. SIP +---+---------+ 250 |Serving SIP| Reg.| Home | 251 | Proxy in |<-------+ entry | 252 | the home | | SIP | 253 | network +------->| Proxy | 254 +-----------+8.200 OK+--+----------+ 255 | ^ 256 | | 257 9.200 OK| | 2. SIP REGISTER 258 v | 259 +-------+--------+ 260 | (optional) | 261 Visited Network | Outbound | 262 | SIP | 263 | Proxy | 264 +--+-------------+ 265 | ^ 266 10.200 OK | | 1. SIP REGISTER 267 v | 268 +-------+-+ 269 | SIP | 270 | Client | bob@xyz.com 271 +---------+ 272 Figure 1: SIP Registration 274 In the event an Outbound SIP Proxy is present, a SIP client issues 275 its SIP REGISTER method to the Outbound SIP Proxy within the visited 276 network, otherwise the message is sent directly to the Home entry SIP 277 Proxy. When present, the Outbound SIP Proxy forwards the SIP REGISTER 278 to a Home entry SIP Proxy in the home network of the user. When the 279 Home entry SIP Proxy receives SIP REGISTER method from the SIP client 280 or the Outbound SIP Proxy, the Home entry SIP Proxy will issue a AAA 281 message to the Home AAA Server (AAAH). The AAA message includes the 282 SIP Client's identity, relevant parameters from the SIP message, and 283 other authorization and service specific information. The AAAH MAY 284 use the information to authenticate the SIP client, and to determine 285 whether it authorizes the client to access the service. 287 The AAAH MAY decide that a challenge-response procedure is 288 appropriate, and instruct the SIP proxy to send back a 401 289 (Unauthorized) response. The AAAH would generate the challenge in the 290 response message that is sent back in to the SIP client, which would 291 then have to re-register. 293 If access is granted, the AAAH must verify whether a static Serving 294 SIP Proxy in the home network was configured for the client or if one 295 was selected by the Home entry SIP Proxy. If an Serving SIP Proxy in 296 the home network has not been selected, the AAAH MAY dynamically 297 assign an Serving SIP Proxy in the home network to the SIP client, 298 who will act as the client's server for the duration of the 299 authorization period (determined by the AAAH) or the Home entry SIP 300 Proxy MAY select a Serving SIP Proxy in the home network for the user 301 (selection based on information obtained from the AAA server). 303 If the AAAH determines that the SIP client does not have a security 304 association with the assigned server, it MAY create a dynamic 305 security association between the nodes, by distributing session keys 306 to be used in all subsequent SIP messages. This is similar to the 307 method described in [4]. 309 Dynamic establishment of security associations by the AAAH is 310 typically useful in scenarios where the entities do not have pre- 311 established trust, and trust is mandatory in all SIP messages. It 312 should be equally possible for the AAAH to return the relevant 313 certificates to the entities, which could then establish a direct 314 security association, via an out-of-band key management protocol, 315 such as the Internet Key Exchange [8]. 317 When the Home entry SIP Proxy has obtained a successful reply from 318 the AAAH the Home entry SIP Proxy will forward SIP REGISTER method to 319 the selected Serving SIP Proxy in the home network. 321 At this point the Serving SIP Proxy in the home network MAY pull 322 security information (e.g. Session keys) and other necessary 323 information (e.g. Service Profile) from the AAAH. If the Home entry 324 SIP Proxy has selected the Serving SIP Proxy in the home network for 325 the user, the Serving SIP Proxy in the home network MAY also request 326 to the AAAH that it updates the DSI database to include the identity 327 of the Serving SIP Proxy. 329 If the AAAH has authenticated the client the Serving SIP Proxy in the 330 home network will then responds back to the Home entry SIP Proxy with 331 a 200 OK message, which is proxied back all the way to the user. 333 If the authentication of the SIP client is instead handled by the 334 Serving SIP Proxy in the home network, the Serving SIP Proxy in the 335 home network MAY decide that a challenge-response procedure is 336 appropriate, and MAY issue a 401 (Unauthorized) response, including 337 the challenge. The SIP client would calculate the answer to the 338 challenge and would have to re-register and if granted, then the 339 Serving SIP Proxy in the home network will send back a 200 OK 340 message. 342 The AAAH MAY push security information (e.g Session keys) along with 343 other necessary information (e.g Service profile) to the assigned 344 Serving SIP Proxy in the home network. This sequence is not 345 illustrated in any of the figures. 347 A successful SIP registration MAY result in the generation of an 348 accounting record by the client's Serving SIP Proxy in the home 349 network. The accounting record MAY include such information as the 350 user's identity, the location of the registration, date and time, 351 etc. 353 Once the AAAH has sent the successful authorization message to the 354 Serving SIP Proxy in the home network, it MAY update its DSI 355 database. The database contains the identity of the SIP client, and 356 the Serving SIP Proxy in the home network. This database MAY be used 357 by other SIP servers within the local administrative domain to 358 identify a SIP client's assigned SIP server. 360 Additionally, under certain circumstances (e.g., subscription 361 termination, lost terminal, etc.), a home network administrative 362 function may determine a need to clear a user's SIP registration and 363 the assignment of the Serving SIP Proxy in the home network. This 364 function initiates the de-registration procedure and may reside in 365 various elements depending on the exact reason for initiating the de- 366 registration. One such home network element is the AAAH. Also an 367 administrative function external to the AAAH may trigger the AAAH to 368 initiate the de-registration procedure. 370 2.3 Invitation 372 In this section, we will look at the details of a SIP INVITE message, 373 how a session is setup, and how accounting takes place for the 374 session. It is assumed that there will be some kind of security 375 association between SIP servers. This may be established either via 376 the AAA infrastructure or in some other way to allow SIP sessions to 377 be established from SIP servers / proxies that are not members of the 378 AAA infrastructure on behalf of other users. 380 2.3.1 Invitation terminating in the mobile node 381 Home Network 382 +--------+ +----------+ +----------+ 383 |xyz.com | | xyz.com | | Naming | 384 | AAAH |<-->| DSI | | Server | 385 +->| server | | Database | | (e.g.DNS)| 386 | +--------+ +----------+ +----------+ 387 | ^ ^ 388 | AAA | | 389 | | | xyz.com? 390 v V v 391 +-----------+ INVITE+-----------+ INVITE +-----------+ 392 |Serving SIP|<------+ Home |<-------+ abc.com | 393 |Proxy in | | entry | | | 394 |the home +------>| SIP |------->| SIP | 395 |network |200 OK | Proxy |200 OK | Server | 396 +-------+---+ +-----------+ +---+-------+ 397 ^ | | ^ 398 200 OK| | 200 OK| | 399 | | SIP | | SIP 400 | | INVITE | | INVITE 401 | v v | 402 +--+------+ +---------+ 403 | SIP | | SIP | 404 | Client | | Client | 405 +---------+ +---------+ 406 bob@xyz.com joe@abc.com 408 Figure 2: Mobile Node terminated SIP Session Initiation 410 Figure 2 provides an example scenario of a user that wishes to 411 establish a SIP session with bob@xyz.com. 413 The SIP client of joe@abc.com issues the INVITE message to its local 414 SIP Server (abc.com SIP Server). 416 If the Serving SIP Proxy in the home network of bob@xyz.com is not 417 known, the SIP Server SHOULD attempt to resolve the Home entry SIP 418 Proxy within the home network, perhaps using a mechanism such as DNS. 419 The INVITE method is forwarded to the Home entry SIP Proxy. Upon 420 receipt of the SIP INVITE, the Home entry SIP Proxy MAY send an 421 authorization request to the AAAH, in order to determine whether the 422 session can be established and to find out which of the Serving SIP 423 Proxy in the home network is assigned to the SIP Client. At that 424 point, the Home entry SIP Proxy will forward the request directly to 425 the Serving SIP Proxy in the home network (Figure 2). 427 Upon receipt of the SIP INVITE method, the Serving SIP Proxy in the 428 home network MAY send an authorization request to the AAAH, in order 429 to determine whether the session can be established. The 430 authorization check by the AAAH MAY include other policy decisions, 431 such as time of day, origination point of the session, etc. A 432 successful response from the AAAH will result in the forwarding of 433 the SIP INVITE method to the SIP Client. A response that includes an 434 error would cause the Serving SIP Proxy in the home network to return 435 an error back to the initiating SIP Server. 437 2.3.2 Invitation originating from the mobile node 439 Home Network 440 +----------+ +-------+ +----------+ 441 | xyz.com | |xyz.com| | Naming | 442 DSI |<->| AAAH | | Server | 443 | Database | | server| | (e.g.DNS)| 444 +----------+ +-------+ +----------+ 445 ^ ^ ^ 446 | | | 447 +-----------+ | |abc.com? 448 | | | 449 v v v 450 +-----------+INVITE +-----------+INVITE +-----------+ 451 | Home +------->|Serving SIP+------>| abc.com | 452 | entry | | Proxy in | | | 453 | SIP |<-------+ the home |<------+ SIP | 454 | Proxy |200 OK | network |200 OK | Server | 455 +---+-------+ +-----------+ +------+----+ 456 | ^ ^ | 457 | | 200 OK| |SIP 458 200 OK| |SIP | |INVITE 459 | |INVITE | | 460 v | | v 461 +------+--+ +-+-------+ 462 | SIP | | SIP | 463 | Client | | Client | 464 +---------+ +---------+ 465 bob@xyz.com joe@abc.com 467 Figure 3: Mobile node initiated SIP Session Initiation 469 Figure 3 provides an example of a user, bob@xyz.com, that wishes to 470 establish a SIP session with joe@abc.com. 472 The SIP Client of bob@xyz.com sends the SIP INVITE, either to his 473 Home entry SIP Proxy, or directly to the Serving SIP Proxy in the 474 home network, if this is known. If the Home entry SIP Proxy receives 475 the SIP INVITE, it will after a location lookup in the DSI database, 476 proxy it to the Serving SIP Proxy in the home network. 478 Upon receipt of the SIP INVITE method, the Serving SIP Proxy in the 479 home network MAY send an authorization request to the AAAH, in order 480 to determine whether the session can be established. The 481 authorization check by the AAAH MAY include other policy decisions, 482 such as time of day, origination point of the session, etc. A 483 successful response from the AAAH will result in the forwarding of 484 the SIP INVITE method to the SIP Client. A response that includes an 485 error would cause the Serving SIP Proxy in the home network to return 486 an error back to the initiating SIP Client. 488 The authorization MAY be performed in the Serving SIP Proxy in the 489 home network if the AAAH has provided the required information to the 490 Serving SIP Proxy in the home network in the registration. 492 The Serving SIP Proxy in the home network will, after this, use 493 ordinary SIP proxying mechanisms to proxy the SIP INVITE to the SIP 494 server serving joe@abc.com, which will proxy the message to the SIP 495 Client of joe@abc.com. SIP 200 OK messages traverse back along the 496 same path. 498 2.3.3 Session accounting 500 During the SIP session establishment, the SIP server MAY initiate an 501 accounting session towards the Accounting server in the home or 502 visited network. SIP servers MAY generate several accounting records 503 during the SIP session. At the end of the SIP session, a final 504 accounting record should be issued that includes a summary of the SIP 505 session. 507 The accounting records should include accounting information that is 508 necessary for billing and inter-network settlement purpose. 509 Accounting information such as user identities (called and calling 510 party Ids), SIP call Id, used media types, request-URI, QoS 511 parameters (requested/negotiated quality of service), accounting 512 correlation Id, and SIP session duration should be recorded. 514 Any change during the SIP session that MAY affect the charge of SIP 515 session (e.g. change of media type, additional service requested, 516 call redirection) should be reflected in an accounting record. For 517 example during session forwarding, the initial calling party (A) MAY 518 incur the charges from A to B while the forwarding party MAY incur 519 charges due to the 'forwarded' session. Also, if the called party 520 requests additional media components with regard to the initial 521 request from calling party then the called party MAY be charged for 522 these additional components. 524 Parameters for accounting generation SHOULD be configurable in the 525 SIP servers, or alternatively, the AAA server MAY indicate interim 526 accounting information to the SIP server, which advises the SIP 527 server when to generate the interim accounting records and if a 528 cumulative or non-cumulative accounting model MUST be used. It 529 should be noted that the traditional telco world currently makes use 530 of, and prefers, non-cumulative accounting information. 532 If SIP extensions (e.g. instant messaging, presence service) are 533 used, some of the request or response messages in these extensions 534 MAY trigger generation of accounting information. For example, a SIP 535 SUBSCRIBE MAY trigger generation of a one-time event accounting 536 record, session based instant messaging MAY trigger generation of 537 accounting session and SIP INFO methods MAY trigger generation of an 538 interim accounting message. 540 Accounting data related to bearer payload (e.g. number of transmitted 541 packets, used bandwidth) is assumed to be handled by other mechanisms 542 than SIP and is not included in these requirements. However a unique 543 accounting correlation Id MAY exist, which correlates the SIP session 544 with specific bearer(s)in the access network. If the unique 545 correlation Id exist, it MUST be included in all accounting records 546 to be able to correlate the accounting information from SIP session 547 to used bearer in the access network. 549 3.0 Requirements 551 From the previous section, we can extract the following requirements 552 for SIP-AAA interworking: 554 1. A basic requirement for Service Providers is to be able to 555 integrate different networks for more efficient operations. 556 IETF AAA efforts support this idea by striving for a single AAA 557 architecture and protocol set. Whether access is supported by 558 PPP, Mobile-IP, MEGACO or SIP, a common architecture and 559 protocol set SHOULD be used. 561 2. The AAAH MAY authenticate a user based on the corresponding 562 SIP REGISTER method. 564 3. The AAAH MAY authenticate a user session (the end result of a 565 successful SIP INVITE method), implementing whatever policy it 566 wishes, such as taking into account time of day, distance, etc. 568 4. The AAA infrastructure MUST be able to distribute (push or 569 pull) subscriber/service/security profiles to the relevant SIP 570 servers, based on policies 572 5. The AAAH MUST be able to update the entry for the assigned SIP 573 server for the user performing SIP registration. 575 6. The AAAH MUST be able to provide the assigned server of the 576 user to the SIP entities requesting it. 578 7. The AAAH MUST be able to initiate de-registration of the user. 580 8. The AAA infrastructure or the Home entry SIP Proxy MUST be 581 able to allocate a SIP server for a subscriber at registration 582 time, based on policies, load distribution etc. 584 9. The scheme supported for the authentication between the SIP 585 servers and the AAA infrastructure MUST be flexible enough to 586 accommodate current authentication mechanisms, e.g. using 587 Subscriber Identity Module (SIM) card, and possible future 588 authentication mechanisms. 590 10. Ability for SIP Servers to provide the duration of a session, 591 the parties involved, and other relevant information to the 592 visited and home AAA servers as accounting information. 594 11. The AAA accounting messages MUST separate the "session 595 duration time" information from those generated via additional 596 services (e.g. 3-way calling, etc.) 598 12. There MUST be support for accounting transfers where the 599 information contained in the accounting data has a direct 600 bearing on the establishment, progression and termination of a 601 session. 603 13. There MUST be support for accounting transfers where the 604 information contained in the accounting data does NOT have a 605 direct bearing on the establishment, progression and 606 termination of a session. 608 14. SIP servers MUST be able to provide relevant accounting 609 information for billing and inter-network settlement purpose to 610 home and visited AAA servers. Both one time event accounting 611 records and session based (START, INTERIM, STOP records) 612 accounting MUST be supported. 614 15. Any change during the SIP session that affects the charge of 615 SIP session MUST be reflected in accounting messages. 617 16. The AAA accounting protocol MUST support accounting per media 618 component (e.g. voice, video). The AAA accounting Protocol 619 MUST enable different parties to be charged per media 620 component. 622 17. Both cumulative and non-cumulative accounting model MUST be 623 supported. 625 18. Parameters for accounting generation must either be 626 configurable in the SIP servers or communicated by the AAA 627 servers. 629 19. If possible the accounting for SIP session MUST be correlated 630 to the bearer in the access network. 632 4.0 Security Considerations 634 It+ is assumed that integrating AAA and IP Telephony/Multimedia will 635 not introduce any new security risks. Therefore, the AAA data MUST be 636 secured and obscured when transiting the network, the endpoints MUST 637 be authenticated before data is sent, and the endpoints MAY be 638 authorized to access certain types of AAA data. 640 5.0 References 642 [1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Ses� 643 sion Initiation Protocol". RFC 2543, March 1999. 645 [2] Aboba et al, "Network Access AAA Evaluation Criteria". RFC 2989, 646 November 2000. 648 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev� 649 els", BCP 14, RFC 2119, March 1997. 651 [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho� 652 rization, and Accounting Requirements". RFC 2977, October 2000. 654 [5] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Pro� 655 tocol, Version 2", RFC 2165, June 1999. 657 [6] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 658 1999. 660 [7] H. Schulzrinne, L. Slutsman, I. Faynberg, H. Lu, "Interworking 661 between SIP and INAP". draft-schulzrinne-sin-00.txt, IETF Work in 662 Progress, July 2000. 664 [8] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC 1409, 665 November 1998. 667 6.0 Acknowledgements 669 The authors would like to thank the participants of the 3GPP and 670 3GPP2 working groups for their valuable feedback, and to Harri Hakala 671 for very useful proposed text. 673 7.0 Authors' Addresses 675 Questions about this memo can be directed to: 677 Henrik Basilier 678 Ericsson Inc. 679 2100 Shattuck Ave. 680 Berkeley, Califonia, 94704 681 USA 683 Phone: +1 858-361-4314 684 Fax: +1 510-666-3999 685 E-mail: henrik.basilier@ericsson.com 687 Pat R. Calhoun 688 Black Storm Networks 689 250 Cambridge Avenue 690 Suite 200 691 Palo Alto, California, 94306 692 USA 694 Phone: +1 650-617-2932 695 Fax: +1 720-293-7501 696 E-mail: pcalhoun@diameter.org 698 Matt Holdrege 699 ipVerse 700 223 Ximeno Ave. 701 Long Beach, CA 90803 702 U.S.A. 704 E-mail: matt@ipverse.com 705 Tony Johansson 706 Ericsson Inc. 707 2100 Shattuck Ave. 708 Berkeley, Califonia, 94704 709 USA 711 Phone: +1 510-305-6108 712 Fax: +1 510-666-3999 713 E-mail: tony.johansson@ericsson.com 715 James Kempf 716 Network and Security Research Center, Sun Laboratories 717 Sun Microsystems, Inc. 718 15 Network Circle 719 Menlo Park, California, 94025 720 USA 722 Phone: +1 650-786-5890 723 Fax: +1 650-786-6445 724 E-mail: james.kempf@eng.sun.com 726 Jaakko Rajaniemi 727 Nokia Networks 728 P.O. Box 301 729 00045 Nokia Group 730 Finland 732 Phone: +358 50 3391387 733 Fax: +358 9 51130163 734 E-mail: jaakko.rajaniemi@nokia.com 736 8.0 Full Copyright Statement 738 Copyright (C) The Internet Society (2001). All Rights Reserved. 740 This document and translations of it may be copied and furnished to 741 others, and derivative works that comment on or otherwise explain it 742 or assist in its implementation may be prepared, copied, published 743 and distributed, in whole or in part, without restriction of any 744 kind, provided that the above copyright notice and this paragraph are 745 included on all such copies and derivative works. However, this docu� 746 ment itself may not be modified in any way, such as by removing the 747 copyright notice or references to the Internet Society or other 748 Internet organizations, except as needed for the purpose of develop� 749 ing Internet standards in which case the procedures for copyrights 750 defined in the Internet Standards process must be followed, or as 751 required to translate it into languages other than English. The lim� 752 ited permissions granted above are perpetual and will not be revoked 753 by the Internet Society or its successors or assigns. This document 754 and the information contained herein is provided on an "AS IS" basis 755 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS� 756 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 757 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 758 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 759 FITNESS FOR A PARTICULAR PURPOSE.