idnits 2.17.00 (12 Aug 2021) /tmp/idnits24831/draft-alfano-aaa-qosreq-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 2003) is 6792 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 section? '1' on line 684 looks like a reference -- Missing reference section? '2' on line 687 looks like a reference -- Missing reference section? '3' on line 691 looks like a reference -- Missing reference section? '4' on line 696 looks like a reference -- Missing reference section? '5' on line 699 looks like a reference -- Missing reference section? '6' on line 701 looks like a reference -- Missing reference section? '7' on line 704 looks like a reference -- Missing reference section? '8' on line 708 looks like a reference -- Missing reference section? '9' on line 712 looks like a reference -- Missing reference section? '11' on line 719 looks like a reference -- Missing reference section? '13' on line 730 looks like a reference -- Missing reference section? '14' on line 734 looks like a reference -- Missing reference section? '15' on line 738 looks like a reference -- Missing reference section? '16' on line 742 looks like a reference -- Missing reference section? '17' on line 746 looks like a reference -- Missing reference section? '12' on line 726 looks like a reference -- Missing reference section? '10' on line 715 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Authentication, Authorization and Accounting Frank M. Alfano 3 Internet Draft Peter J. McCann 4 Document: draft-alfano-aaa-qosreq-01.txt Tom Towle 5 Expires: April 2004 Richard Ejzak 6 Lucent Technologies 7 Hannes Tschofenig 8 Siemens 9 October 2003 11 Requirements for a QoS AAA Protocol 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes requirements for a protocol that would 35 perform Authentication, Authorization, and Accounting for Quality-of- 36 Service reservations. Such a protocol would be used by entities to 37 authenticate a user's reservation request, to ensure that the 38 reservation is authorized and to provide accounting functionality. 40 The requirements covered in this document primarily address the 41 communication of AAA protocols and not the QoS signaling protocols, 42 although they have to provide some degree of interworking. Therefore, 43 we list a minimal set of requirements on supported QoS signaling 44 protocols. 46 Requirements for a QoS AAA Protocol October 2003 48 Table of Contents 50 1. Introduction...................................................2 51 1.1 QoS Signaling..............................................3 52 1.2 Architecture...............................................3 53 2. Keywords.......................................................5 54 3. Terminology....................................................5 55 4. Generic Requirements on a QoS Signaling Protocol...............7 56 4.1 User Authentication/Authorization..........................7 57 4.2 Support for different authorization scenarios..............7 58 4.3 Providing Authorization Information........................7 59 4.4 Reauthorization............................................8 60 4.5 Integrity and Replay Protection............................8 61 4.6 Confidentiality Protection.................................8 62 5. Generic Requirements on a QoS AAA Protocol.....................9 63 5.1 Inter-domain Support.......................................9 64 5.2 Identity-based Routing.....................................9 65 6. Requirements for QoS Authentication............................9 66 6.1 Flexible Authentication Support............................9 67 7. Requirements for QoS Authorization............................10 68 7.1 Making an Authorization Decision..........................10 69 7.2 Triggering an Authorization Process.......................10 70 7.3 Associating QoS Reservations and Application State........10 71 7.4 Dynamic Authorization.....................................11 72 7.5 Bearer Gating.............................................11 73 8. Requirements for QoS Accounting...............................11 74 8.1 Accounting Records........................................11 75 8.2 Accounting Rules..........................................11 76 8.3 Sending Accounting Records................................12 77 8.4 Failure Notification......................................12 78 8.5 Accounting Correlation....................................12 79 9. Interaction with other AAA Applications.......................12 80 10. Use Scenario.................................................13 81 10.1 Bearer Gating............................................14 82 10.2 Loss of Connectivity.....................................14 83 11. Security Considerations......................................14 84 12. References...................................................15 85 13. Author's Addresses...........................................16 87 1. Introduction 89 To meet the quality-of-service needs of applications such as voice- 90 over-IP, it will often be necessary to explicitly request resources 91 from the network. This will allow the network to identify packets 92 belonging to such application flows and ensure that bandwidth, delay, 93 and error rate requirements are met. By performing admission control 94 Requirements for a QoS AAA Protocol October 2003 96 on individual flows, the network can avoid congestion and the 97 resulting high packet drop rates. 99 1.1 QoS Signaling 101 A variety of protocols can be used to signal QoS information and to 102 make a reservation, such as RSVP, NSIS, SIP/SDP or link-layer 103 specific mechanisms. 105 RSVP [2] is the existing IETF-defined QoS signaling protocol. The 106 Next Steps in Signaling (NSIS) working group [3] is currently 107 developing a general signaling model based on two-layer architecture. 109 In the meantime, deployments such as 3rd generation cellular networks 110 are defining their own reservation procedures: these include link- 111 layer specific means, such as the PDP Context Activation procedures 112 of 3GPP [4,5] or the service instance establishment procedures of 113 3GPP2 [6]. This list can easily be extended. 115 In other areas QoS signaling mechanisms are often tightly coupled to 116 the application signaling. In the 3GPP/3GPP2 IP Multimedia Core 117 Network subsystems the Session Initiation Protocol (SIP) [7] and 118 Session Description Protocol (SDP) [8] are essentially being used to 119 request resource reservations from the network. Special purpose 120 protocols are used for communication between the SIP servers and 121 network elements. 123 1.2 Architecture 125 This draft describes requirements on a AAA protocol for QoS 126 reservations stemming from the new (primarily wireless) network 127 deployments in light of recent efforts to revisit QoS signaling 128 within the IETF. The goal is to meet these requirements of network 129 operators while at the same time supporting a variety of QoS 130 signaling protocols and avoiding the need for monolithic, vertically 131 integrated applications (such as e.g., a SIP proxy server in every 132 router). A high-level picture of the resulting architecture is shown 133 in Figure 1. 135 Requirements for a QoS AAA Protocol October 2003 137 +-------------+ 138 | Resource | 139 | Authorizing | 140 | Entity | 141 +-----+-------+ 142 | 143 | 144 /-\----+-----/\ 145 //// \\\\ 146 || || 147 | AAA Cloud | 148 || || 149 \\\\ //// 150 \-------+-----/ 151 | 152 +-------------+ +---+--+ 153 | Entity | Application | | 154 | Requesting |<<=================+ NE +==========>> 155 | Resource | Flow | | 156 +-------------+ +------+ 157 Figure 1: Architecture 159 Figure 1 depicts an entity requesting a resource, a network element 160 (NE) through which application flows need to pass (i.e., an entity 161 which enforces the QoS reservation), a cloud of AAA servers and an 162 entity authorizing the QoS request. In many cases, the authentication 163 terminates at the user's home network where a database containing 164 subscriber records is located. This is often the entity that executes 165 the authorization decision. Finally, there might be an interaction 166 with an application signaling protocol. 168 Note that the entity authorizing the QoS reservation request might be 169 a AAA server, an application server or another entity. These entities 170 are collectively referred as the "Resource Authorizing Entity" in 171 Figure 1. 173 The term "AAA Cloud" is used to refer to the network of AAA proxies 174 and brokers. Furthermore, there might be more than one network 175 element that needs to interact with the AAA infrastructure although 176 Figure 1 depicts only one for clarity. Similarly, a given user might 177 support different authentication methods; he might have more than one 178 home network; or, he might use different means of authorization. 180 The remainder of this document is organized as follows: 182 Section 3 defines some terms that are used in subsequent discussion. 184 Requirements for a QoS AAA Protocol October 2003 186 Section 4 describes some generic requirements for a QoS signaling 187 protocol. 188 Section 5 gives generic requirements for a QoS AAA protocol. 189 Section 6 gives requirements specific to Authentication. 190 Section 7 gives requirements specific to Authorization. 191 Section 8 gives requirements specific to Accounting. 192 Section 9 discusses the relationship of a QoS AAA protocol to other 193 AAA applications. 194 Section 10 gives an example use scenario. 195 Finally, Section 11 outlines some security considerations. 197 2. Keywords 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in RFC-2119 [9]. 203 3. Terminology 205 Accounting Rules 206 An accounting rule is a collection of data that identifies one 207 or more IP flows and provides related information. An accounting 208 rule defines the accounting treatment such as on-line (i.e., 209 pre-paid) or off-line accounting. The data may also identify, 210 for example, volume or time based accounting, rating 211 information, termination actions for on-line accounting (e.g., 212 drop or re-route packets), record correlation identifiers, etc. 214 Application Server 215 An application server is a network entity that exchanges 216 signaling messages with an application endpoint. It may be a 217 source of authorization for QoS-enhanced application flows. For 218 example, a SIP server is one kind of application server. 220 Application Endpoint 221 An application endpoint is an entity in an end user device that 222 exchanges signaling messages with application servers or 223 directly with other application endpoints. Based on the result 224 of this signaling, the endpoint will make a request for QoS from 225 the network. For example, a SIP User Agent is one kind of 226 application endpoint. 228 Authorizing Entity 229 The authorizing entity is that entity responsible for 230 authorizing QoS requests for a particular application flow. 231 This may be a AAA server (with a subscriber database) or an 232 application server or some other entity. 234 Requirements for a QoS AAA Protocol October 2003 236 Network Element 237 A network element is a network entity such as an IP router on 238 the path between two endpoints, through which IP packets 239 belonging to application flows pass. Typically only a small 240 subset of the network elements along a path communicates with 241 the AAA infrastructure for the purpose of QoS authorization. In 242 a typical service provider scenario, the first-hop router will 243 be required to play this role. A motivation of this 244 architectural simplification is referred to as the New Jersey 245 Turnpike Model and is described in detail in Section 4 of [11]. 246 Network elements are responsible for enforcing the result of the 247 authorization process. 249 Subscriber Database 250 A Subscriber Database holds information related to network users 251 such as information about their subscribed service. A user 252 might, for example, have a subscription for a 'gold' service 253 that authorizes him for higher QoS parameters than 'normal' 254 users. 256 Termination Actions 257 On-line accounting allows the on-line accounting authorization 258 entity to terminate flows in real time. A termination action 259 defines the action to be taken by the network element for the 260 case where a flow has been terminated. For example flow packets 261 might be dropped, might be redirected, or might be allowed to 262 continue but not be counted. 264 QoS signaling protocol 265 A protocol used to carry QoS information between two end points 266 and intercepted by entities along the path. The QoS signaling 267 protocols discussed in this context follow the data path (i.e., 268 they are path-coupled). 270 QoS AAA protocol 271 The QoS AAA protocol runs between a network element (acting as a 272 AAA client) and the resource authorizing entity (acting as a AAA 273 server). For example, upon receipt of a QoS request from the 274 resource requesting entity, the network element might copy 275 authentication credentials and QoS flow information into a AAA 276 message which is forwarded to the resource authorizing entity, 277 possibly via one or more proxy AAA servers. The authorizing 278 entity returns an authorization decision (yes/no) for the flow, 279 and accounting data would be sent to the authorizing entity 280 while the flow is active. 282 Requirements for a QoS AAA Protocol October 2003 284 4. Generic Requirements on a QoS Signaling Protocol 286 While the details of a particular QoS signaling protocol are outside 287 the scope of this document, we do list here some generic requirements 288 that any QoS signaling protocol must meet in order to act as a front 289 end for a QoS AAA protocol. 291 4.1 Identification of Resource Authorizing Entity 293 The QoS signaling protocol MUST carry information sufficient to 294 identify the resource authorizing entity. Note that the network 295 element and the resource authorizing entity will often be in 296 different administrative domains. 298 4.2 User Authentication/Authorization 300 The QoS signaling protocol MUST carry information to allow the 301 authorizing entity to compute the authorization decision. In most 302 cases this information will allow the authorizing entity to 303 authenticate the user. Note that authentication is not necessarily 304 required since authorization can also be accomplished for an 305 anonymous user. 307 Section 5.7.1 of [13] points to these requirements for the NSIS area. 308 RSVP extended the admission control procedure by adding user 309 authentication as described in [14]. Additional authorization 310 capability has been added with the help of authorization tokens as 311 described in [15] and [16]. 313 It is important to provide cryptographic authentication or to protect 314 the authorization information (e.g., tokens) appropriately to counter 315 identity spoofing and attacks against the authorization information 316 (e.g., replay attacks). These attacks might lead to fraud as 317 described in [17]. 319 4.3 Support for different authorization scenarios 321 [11] and [12] describe a two and a three party approach for computing 322 the authorization decision. The QoS signaling protocol SHOULD support 323 these general authorization scenarios. This wide range of 324 authorization scenarios is required to make the QoS AAA protocol 325 applicable in all deployment environments. 327 4.4 Providing Authorization Information 329 The QoS signaling protocol MUST carry sufficient information between 330 the authorizing entity and the enforcing entity (and vice versa) to 331 compute an authorization decision and to execute it. 333 Requirements for a QoS AAA Protocol October 2003 335 This information might include flow identification, QoS objects for 336 determining the authorization (in the direction to the authorizing 337 entity) as well as for provisioning (in the direction from the 338 authorizing entity to the enforcing entity) and price information. 339 Flow information can be used for determining the authorization 340 decision in those case where it meaningful. 342 In many cases it MUST be possible to determine the price of the QoS 343 reservation and to communicate the price to the user (or at least to 344 provide sufficient information to allow the user to compute the 345 price). As described in [11] one or both end-points may need to know 346 the price information. 348 4.5 Reauthorization 350 The QoS signaling protocol MUST allow the network to trigger a 351 reauthorization procedure at any time to support periodic and event 352 triggered authorization. 354 4.6 Integrity and Replay Protection 356 The QoS signaling protocol MUST be integrity and replay protected. 358 To support this requirement each signaling message would, for 359 example, carry a keyed message digest to ensure that only valid 360 requests are granted by the network. This is especially important 361 when a user is being held responsible for charges associated with a 362 QoS session. Prior to providing integrity and replay protection it 363 is necessary to dynamically establish session keys. This is 364 particularly important in a mobile environment as described in 365 Section 7 of [11]. 367 Integrity and replay protection is required for NSIS as described in 368 [17] (see Section 4.2 and 4.3 of [17]). 370 4.7 Confidentiality Protection 372 The QoS signaling protocol MUST provide confidentiality protection in 373 those cases where authorization information is vulnerable to replay 374 attacks. As an example, single-use authorization tokens may rely on 375 the use of a secure channel. An adversary who is able to eavesdrop 376 authorization tokens might be able to reuse them. They only provide a 377 proof of possession and do not serve the purpose of cryptographic 378 authentication where a liveness guarantee has to be provided by the 379 parties executing the protocol. 381 Requirements for a QoS AAA Protocol October 2003 383 5. Generic Requirements on a QoS AAA Protocol 385 In this section we list some high-level requirements that must be met 386 by a QoS AAA protocol. 388 5.1 Inter-domain Support 390 The QoS AAA protocol MUST support inter-domain operation. In 391 particular, users may roam outside their home network, leading to a 392 situation where the network element and authorizing entity are in 393 different administrative domains. This implies the existence of a 394 roaming agreement between the two networks. In general, one or both 395 end-points involved in a communication may be roaming, meaning that 396 the network elements along the data path may belong to multiple 397 administrative domains, none of which are the home domain of either 398 end-point. 400 5.2 Identity-based Routing 402 The QoS AAA protocol MUST route AAA requests to the authorizing 403 entity based on the identity information given in the QoS signaling 404 protocol. 406 6. Requirements for QoS Authentication 408 In this section we list some QoS AAA requirements specific to 409 authentication and authorization. 411 6.1 Flexible Authentication Support 413 The QoS AAA protocol MUST support verification of authentication 414 information present in QoS signaling messages. The QoS AAA protocol 415 MUST support a variety of different authentication protocols. 416 Different QoS architectures are likely to have a different security 417 infrastructure with different requirements. 419 The PacketCable architecture, for example, heavily utilizes Kerberos 420 whereas the 3GPP architecture makes use of the UMTS AKA algorithm. 422 Requirements for a QoS AAA Protocol October 2003 424 7. Requirements for QoS Authorization 426 In this section we list some QoS AAA requirements specific to 427 authorization. 429 7.1 Making an Authorization Decision 431 The QoS AAA protocol MUST exchange sufficient information between the 432 authorizing entity and the enforcing entity (and vice versa) to 433 compute an authorization decision and to execute this decision. 435 This information might include flow identification, QoS objects for 436 determining the authorization as well as for provisioning and price 437 information. 439 The flow identification provided to the QoS AAA protocol MUST allow 440 flow information to be under-specified ("wild carded"). This might be 441 the case for aggregates and when endpoints are unknown at the time of 442 initial resource authorization. 444 7.2 Triggering an Authorization Process 446 The QoS AAA protocol MUST allow periodic and event triggered 447 execution of the authorization process. 449 The trigger for re-authorization might be originated at the enforcing 450 entity or even at the authorizing entity. In any case it should be 451 possible to carry information with the QoS AAA protocol to allow the 452 enforcing or some other trusted entity to determine when to trigger 453 authorization. For example, a time-based trigger, a volume-based 454 trigger or even triggers based on consumed financial resources might 455 lead to a reauthorization procedure. 457 7.3 Associating QoS Reservations and Application State 459 The QoS AAA protocol MUST carry information sufficient for an 460 application server to identify the appropriate application session. 461 This allows an application session to be associated with a particular 462 QoS reservation. 464 Note that if flow information is sufficient to identify an 465 application session then no separate identifier is required. Although 466 this is not true for NSIS other QoS signaling protocols use different 467 identifiers. 469 Requirements for a QoS AAA Protocol October 2003 471 7.4 Dynamic Authorization 473 The QoS AAA protocol MUST support dynamic authorization; that is, it 474 MUST be possible to push updates towards the network element(s) from 475 authorizing entities. 477 This requirement would support runtime application state transitions 478 or even a change in the subscriberÆs profile that would lead to a 479 different authorization state for a specific QoS reservation. 481 7.5 Bearer Gating 483 The QoS AAA protocol MUST allow the authorizing entity to gate 484 authorized application flows. 486 Even though a user might received an authorization for a given flow, 487 some applications may want to toggle the flow on or off based on 488 application state transitions. This control is called bearer gating. 489 Unlike revocation functionality, gating leaves state information 490 about the QoS reservation in place and it is only temporarily 491 suspended. 493 8. Requirements for QoS Accounting 495 In this section we list some QoS AAA requirements specific to 496 accounting. 498 8.1 Accounting Records 500 The QoS AAA protocol MUST define QoS accounting records containing 501 duration or volume (byte count) usage information, or both duration 502 and volume usage information. The records MUST also contain a 503 description of the QoS attributes (e.g., bandwidth, delay, loss rate) 504 that were supported for the flow. 506 8.2 Accounting Rules 508 The QoS AAA protocol MUST allow the authorizing entity to transfer 509 accounting rules that are applicable to specific flows. These rules 510 would define the on-line ("pre-paid") versus off-line ("post-paid") 511 nature of the accounting as well as convey other associated 512 parameters such as record identifiers, rating information, usage 513 quota, on-line termination actions, etc. 515 The QoS AAA protocol MUST allow for accounting rules to be provided 516 at authorization time as well as to be pushed later as dynamic 517 updates. 519 Requirements for a QoS AAA Protocol October 2003 521 8.3 Sending Accounting Records 523 The network element MUST send accounting records for a particular 524 application flow to the authorizing entity for that flow or to 525 another entity identified by the authorizing entity. 527 8.4 Failure Notification 529 The QoS AAA protocol MUST allow the network element to report 530 failures to the authorizing entity. These failures (such as loss of 531 connectivity due to movement of a mobile node or other reasons for 532 packet loss) primarily address problems in the data path and do not 533 cover problems with the QoS AAA protocol. 535 8.5 Accounting Correlation 537 The QoS AAA protocol MUST support the exchange of sufficient 538 information to allow for correlation between accounting records 539 generated by the network elements and accounting records generated by 540 an application server. 542 For example, an application server might create and pass an 543 accounting correlation identifier to the network element. This 544 correlation identifier would then be stored for inclusion in 545 subsequent accounting records. This would allow the home network to 546 link the accounting information of the network element with those of 547 the application server. 549 9. Interaction with other AAA Applications 551 It is likely that an endpoint attached to a first-hop network element 552 was authenticated and authorized for basic, best-effort Internet 553 access prior to requesting any special QoS from the network. If the 554 subscriber database for basic network access is the same as the one 555 containing a QoS subscription, it may be expeditious to define some 556 interactions between the AAA protocol used for basic access (e.g., 557 NASREQ [10]) and the one outlined here for QoS. For example, it may 558 be useful to return some QoS-related attributes to the first-hop 559 network element at the time the endpoint is granted basic, best- 560 effort access. This would allow for some future QoS requests to be 561 granted based on the cached profile, rather than requiring a round- 562 trip to the home subscriber database. This gives rise to the 563 following requirement: 565 The QoS AAA protocol MUST define a QoS profile that can be re-used in 566 other AAA applications. 568 Still, it must be possible to execute the QoS AAA protocol 569 independently of other AAA protocols applications. 571 Requirements for a QoS AAA Protocol October 2003 573 Also, it may be useful to allow application servers to push QoS 574 authorization information to a network element prior to any explicit 575 request from the endpoint. This could support application endpoints 576 that do not support an explicit QoS signaling mechanism. In this 577 case, the authorization may be pushed via the home AAA server, which 578 presumably knows to which NAS the endpoint is currently attached. 579 Alternatively, the QoS AAA protocol may define some sort of 580 redirection facility that would allow application servers to send AAA 581 messages directly to selected network elements such as a NAS. This 582 operation could be considered a special case of dynamic authorization 583 where no explicit request for QoS was made prior to the 584 authorization: 586 The QoS AAA protocol MUST support dynamic authorization initiated by 587 the authorizing entity. 589 10. Scenarios 591 This section provides a few example scenarios: 593 An application in a mobile node wants to open a video session with a 594 video server. The mobile node and the video server negotiate the 595 resources to be used for the session and for which the application 596 will be financially responsible. When resource negotiation has 597 completed, the video server stores the resource information and 598 assigns a session identifier to the information that can be used as 599 the primary key for later information queries. This identifier has 600 to be known to both parties - the mobile node and the video server. 602 The mobile node starts to use a QoS signaling protocol. The signaling 603 message will hit a network element (most likely the first hop router) 604 in the visited network. The video server and the network element will 605 verify that the mobile node has not requested more resources than 606 what were negotiated and for which the application has agreed to be 607 financially responsible. To link the application protocol session 608 with this particular resource request, the mobile node passes the 609 session identifier received from the video server to the network 610 element via the QoS signaling protocol. The network element makes a 611 request to the video server (or some other centralized node) as 612 identified in the session identifier. The video server passes the 613 relevant QoS state information to the network element in an answer 614 message, associating the origin host information from the request 615 with the state information stored by the video server. (This can 616 then be used later for pushing information to the network element.) 617 All accounting messages from a network entity include an accounting 618 correlation id. 620 Requirements for a QoS AAA Protocol October 2003 622 10.1 Bearer Gating 624 The video server can control the flow of packets on the network 625 element by sending packet flow gating information in the answer 626 message delivered for resource authorization. If the flow of packets 627 is not immediately enabled, some event at the video server will 628 trigger the server to enable the flow. The video server sends a 629 request containing flow gating information to the network element to 630 allow the flow of packets. The network element returns the state of 631 the packet flow in the response message to the video server. 633 10.2 Loss of Connectivity 635 The network element determines connectivity to the end host has been 636 lost. The video server needs this information in order to take 637 corrective action, charge appropriately, and/or release resources 638 associated with the session. The network element informs the video 639 server of the loss of connectivity in a request message containing 640 state information of the network element. The video server 641 acknowledges the request in an answer message. The video server may 642 then issue a session abort request message to other network 643 functional entities. 645 11. Security Considerations 647 The QoS AAA protocol whose requirements are given in this draft 648 assumes that a trust relationship exists between the authorizing 649 entity and the network element. This trust relationship does not need 650 to be pre-existing at the protocol startup but could also be 651 dynamically established. The relationship may be direct or it may be 652 indirect via a AAA cloud consisting of brokers and proxies. Each 653 link in this chain of relationships MUST be secured to prevent 654 spoofed authorizations. 656 This relationship implies that the bearer element should grant 657 service based on the decision of the authorizing entity, presumably 658 because the used resources will be paid for. The establishment of a 659 trust relationship between the involved networks therefore also 660 implies the setup of a financial settlement. 662 The authentication outlined in Section 6 MUST be cryptographically 663 strong and protected against replay and other attacks. Various 664 threats against a QoS signaling protocol (and on the AAA 665 infrastructure) are described in [17]. 667 Once QoS resources have been authorized, it may be possible for an 668 unauthorized party to subvert them for its own use. Steps MUST be 669 taken to prevent an adversary from injecting or spoofing data 670 packets, which could then receive preferred treatment (i.e., steal 671 Requirements for a QoS AAA Protocol October 2003 673 other user's QoS resources). Although beyond the scope of this 674 document cryptographic protection of the data traffic should be 675 considered either at the network or at the link layer. 677 Among other things, Section 9 implies to off-load some authorization 678 decisions from the user's home network to the visted network. Making 679 the user's profile available to entities outside the home network 680 might raise some privacy concerns. 682 12. Reference 684 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 685 BCP 9, RFC 2026, October 1996. 687 [2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 688 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 689 Specification", RFC 2205, September 1997. 691 [3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and 692 Van den Bosch, S., "Next Steps in Signaling: Framework", 693 Internet Draft, Internet Engineering Task Force, September 694 2003. Work in progress. 696 [4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling 697 Flows", April 2003. 699 [5] 3GPP TS 29.207, "Policy control over Go interface", March 2003. 701 [6] 3GPP2 C.S0017-0 (also TIA IS-707-A), "Data Service Options for 702 Spread Spectrum Systems." 704 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 705 Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP: 706 Session Initiation Protocol", RFC 3261, June 2002. 708 [8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session 709 Description Protocol", Internet Draft, Internet Engineering 710 Task Force, September 2003. Work In Progress. 712 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 713 Levels", BCP 14, RFC 2119, March 1997. 715 [10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter 716 Network Access Server Application", Internet Draft, Internet 717 Engineering Task Force, October, 2003. Work In Progress. 719 [11] H. Tschofenig, M. Buechli, S. Van den Bosch and H. Schulzrinne: 720 "NSIS Authentication, Authorization and Accounting Issues", 721 Requirements for a QoS AAA Protocol October 2003 723 Internet Draft, Internet Engineering Task Force, March 2003. 724 Work in progress. 726 [12] H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne and 727 T. Chen: "QoS NSLP Authorization Issues", Internet Draft, 728 Internet Engineering Task Force, June 2003. Work in progress. 730 [13] M. Brunner: "Requirements for QoS signaling protocols", 731 Internet Draft, Internet Engineering Task Force, August 2003. 732 Work in progress. 734 [14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 735 Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 736 3182, October, 2001. 738 [15] L. Hamer, B. Gage, and H. Shieh: "Framework for session set-up 739 with media authorization," RFC 3521, Internet Engineering Task 740 Force, April 2003. 742 [16] L. Hamer, B. Gage, B. Kosinski, and H. Shieh: "Session 743 Authorization Policy Element", RFC 3520, Internet Engineering 744 Task Force, April 2003. 746 [17] Tschofenig, H. and D. Kroeselberg: "Security Threats for NSIS", 747 Internet Draft, Internet Engineering Task Force, June 2003. 749 13. Author's Addresses 751 Frank M. Alfano 752 Lucent Technologies 753 Rm 9C-226L 754 1960 Lucent Lane 755 Naperville, IL 60563 756 Phone: +1 630 979 7209 757 Email: falfano@lucent.com 759 Peter J. McCann 760 Lucent Technologies 761 Rm 9C-226R 762 1960 Lucent Lane 763 Naperville, IL 60563 764 Phone: +1 630 713 9359 765 Email: mccap@lucent.com 766 Requirements for a QoS AAA Protocol October 2003 768 Thomas T. Towle 769 Lucent Technologies 770 Rm 9C-229 771 1960 Lucent Lane 772 Naperville, IL 60563 773 Phone: +1 630 979 7303 774 Email: ttowle@lucent.com 776 Richard Ejzak 777 Lucent Technologies 778 Rm 7H-245 779 1960 Lucent Lane 780 Naperville, IL 60563 781 Phone: +1 630 979 7036 782 Email: ejzak@lucent.com 784 Hannes Tschofenig 785 Siemens AG 786 Otto-Hahn-Ring 6 787 81739 Munich 788 Germany 789 EMail: Hannes.Tschofenig@siemens.com 791 Intellectual Property Statement 793 At the time of submission the authors are not aware of any 794 intellectual property rights that pertain to the implementation or 795 use of the technology described in this document. However, this does 796 not preclude the possibility that Lucent Technologies, Inc. or other 797 entities may have such rights. The patent licensing policy of Lucent 798 Technologies, Inc. is on file with the IETF Secretariat. 800 The IETF takes no position regarding the validity or scope of any 801 intellectual property or other rights that might be claimed to 802 pertain to the implementation or use of the technology described in 803 this document or the extent to which any license under such rights 804 might or might not be available; neither does it represent that it 805 has made any effort to identify any such rights. Information on the 806 IETF's procedures with respect to rights in standards-track and 807 standards-related documentation can be found in BCP-11. Copies of 808 claims of rights made available for publication and any assurances of 809 licenses to be made available, or the result of an attempt made to 810 obtain a general license or permission for the use of such 811 proprietary rights by implementers or users of this specification can 812 be obtained from the IETF Secretariat. 814 Requirements for a QoS AAA Protocol October 2003 816 The IETF invites any interested party to bring to its attention any 817 copyrights, patents or patent applications, or other proprietary 818 rights that may cover technology that may be required to practice 819 this standard. Please address the information to the IETF Executive 820 Director. 822 Full Copyright Statement 824 Copyright (C) The Internet Society (2003). All Rights Reserved. This 825 document and translations of it may be copied and furnished to 826 others, and derivative works that comment on or otherwise explain it 827 or assist in its implementation may be prepared, copied, published 828 and distributed, in whole or in part, without restriction of any 829 kind, provided that the above copyright notice and this paragraph are 830 included on all such copies and derivative works. However, this 831 document itself may not be modified in any way, such as by removing 832 the copyright notice or references to the Internet Society or other 833 Internet organizations, except as needed for the purpose of 834 developing Internet standards in which case the procedures for 835 copyrights defined in the Internet Standards process must be 836 followed, or as required to translate it into languages other than 837 English. 839 The limited permissions granted above are perpetual and will not be 840 revoked by the Internet Society or its successors or assigns. 842 This document and the information contained herein is provided on an 843 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 844 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 845 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 846 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 847 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.