idnits 2.17.00 (12 Aug 2021) /tmp/idnits60366/draft-tschofenig-nsis-aaa-issues-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 22 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 576 has weird spacing: '...itiated reser...' == Line 629 has weird spacing: '...rvation with ...' == Line 665 has weird spacing: '...itiated reser...' -- 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 (5 February 2003) is 7044 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 1013 looks like a reference -- Missing reference section? '2' on line 1017 looks like a reference -- Missing reference section? '3' on line 1024 looks like a reference -- Missing reference section? '4' on line 1028 looks like a reference -- Missing reference section? '5' on line 1032 looks like a reference -- Missing reference section? '6' on line 1035 looks like a reference -- Missing reference section? '7' on line 1039 looks like a reference -- Missing reference section? '8' on line 1044 looks like a reference -- Missing reference section? '9' on line 1049 looks like a reference -- Missing reference section? '10' on line 1052 looks like a reference -- Missing reference section? '11' on line 1057 looks like a reference -- Missing reference section? '12' on line 1061 looks like a reference -- Missing reference section? '13' on line 1065 looks like a reference -- Missing reference section? '14' on line 1068 looks like a reference -- Missing reference section? '15' on line 1073 looks like a reference -- Missing reference section? '16' on line 1077 looks like a reference -- Missing reference section? '17' on line 1080 looks like a reference -- Missing reference section? '18' on line 1085 looks like a reference -- Missing reference section? '19' on line 1089 looks like a reference -- Missing reference section? '20' on line 1092 looks like a reference -- Missing reference section? '21' on line 1097 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force NSIS 3 Internet Draft H. Tschofenig,M. Buechli 4 S. Van den Bosch, H. Schulzrinne 5 Siemens/Alcatel/Alcatel/Columbia 6 draft-tschofenig-nsis-aaa-issues-00.txt 7 5 February 2003 8 Expires: August 2003 10 NSIS Authentication, Authorization and Accounting Issues 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also 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 material 24 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 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the implications of authentication, 35 authorization and accounting for an NSIS QoS signaling protocol. We try 36 to show that authorization and charging are very important for the 37 internal machinery of a signaling protocol and for the security and 38 trust model behind it. This document only addresses charging aspects for 39 unicast data traffic. 41 1 Introduction 43 When RSVP [1] was designed a few assumptions had to be made. These 44 assumptions are, however, not described in too much detail. Especially 45 with regard to accounting and charging a number of white spots have been 46 left open which make it difficult for providers to create a solution 47 without considerable effort. This document tries to highlight some of 48 these issues and explain why NSIS should consider them during the design 49 phase. This document does not try to introduce a new charging or 50 accounting infrastructure and does not aim to provide a literature 51 review of pricing mechanisms or mathematic models. Instead an abstract 52 view on authentication, authorization and charging is provided as far as 53 relevant for NSIS and to QoS signaling in particular. 55 2 Terminology 57 Accounting terminology used in this document tries to be consistent with 58 [2]. NSIS terminology is taken from [3]. The term Policy Decision Point 59 (PDP) refers to the logical entity defined in [4]. 61 Reverse charging denotes charging for the receiver of the data traffic 62 in contrast to charging for the data traffic transmitter (i.e. sender). 64 3 The Relationship between Authorization and Accounting 66 RSVP is currently only deployed in fairly closed environment such as 67 enterprise networks. In such an environment authorization usually means 68 role based access control based on some group membership or special 69 rights to use a service. Users are typically not charged directly for 70 their generated QoS traffic nor for QoS reservations. If the signaling 71 messages (and thereby the QoS reservation) travel beyond the 72 administrative domain then the enterprise network is charged and not the 73 individual end user directly. 75 With mobility and telecommunication networks today authorization can (or 76 should) be seen in an abstract form as "Is one of the signaling 77 participants able to pay for the reservation?". This abstraction is 78 supported by the fact that reservations require some form of penalty in 79 order not reserve too many resources. 81 It might therefore be correct to say that authorization is strongly 82 interrelated to the availability of funds/credits and therefore with 83 charging. Some service provider might use some additionally information 84 based on the subscriber profile/information stored data to assist in the 85 authorization process. 87 4 The two Accounting/Trust Models 89 4.1 New Jersey Turnpike Model 91 On the New Jersey Turnpike, motorists pick up a ticket at the toll booth 92 when entering the highway. At the highway exit the ticket is presented 93 and payment is made at the toll booth for the distance driven. An 94 abstract form of this model is given in Figure 1 where security is 95 provided in a peer-to-peer or network-to-network fashion since the 96 accounting and charging model is also accomplished in the same fashion. 98 +--------------------+ +--------------------+ +--------------------+ 99 | Network | | Network | | Network | 100 | X | | Y | | Z | 101 | | | | | | 102 | -----------> -----------> | 103 | | | | | | 104 | | | | | | 105 +--------^-----------+ +--------------------+ +---------+----------+ 106 | . 107 | . 108 | v 109 +--+---+ Data Data +--+---+ 110 | Node | ====================================> | Node | 111 | A | Sender Receiver | B | 112 +------+ +------+ 114 Legend: 116 ----> Peering relationship which allows neighboring networks/entities 117 to charge each other for the QoS reservation and data traffic 119 ====> Data flow 121 ..... Communication to the end host 123 Figure 1: New Jersey Turnpike Model 125 The model shown in Figure 1 uses peer-to-peer relationships between 126 different administrative domains as a basis for accounting and charging. 127 Based on the peering relationship a chain-of-trust is established. There 128 are several issues which come in mind when considering this type of 129 model: 131 · Since accounting and charging requires some protocol interaction 132 with the end host it is reasonable to assume that a QoS signaling 133 protocol is not the first protocol executed between an end host 134 and the attached network. Typically some network access protocols 135 are executed which establish a relationship between the user and 136 his home network (subscription-based scenario). A more detailed 137 description of this environment is given in Section 6. Using this 138 assumption a relationship between the visited/access network (the 139 network where the end host is currently attached) and the user's 140 home network for the purpose of charging is already established. 141 Hence generating additional accounting records for QoS 142 reservations and QoS data traffic does not require a major 143 change. 145 · The price for a QoS reservation needs to be determined somehow 146 and communicated to the charged entity and to the network where 147 the charged entity is attached. The description of this model 148 assumes that the data sender is charged. Section 6 addresses the 149 issue of charging for either one of the two end points. 151 Section A describes two mechanisms for price distribution: in- 152 band (or probing) and out-off band price distribution protocols 154 · This architecture seems to be simple enough to allow a scalable 155 solution (ignoring reverse charging, multicast issues and the 156 problem of determining the cost for a reservation along the 157 entire path). 159 · Depending on the signaling protocol and the price distribution 160 protocol (especially in case of an in-band protocol) it might be 161 possible that a malicious node is able to cause harm by modifying 162 signaling messages in such a way that the end point is charged 163 more than intended. (TBD: This issue needs to be elaborated in 164 more details.) 166 Charging for the data sender applied to this model simplifies security 167 handling by demanding only peer-to-peer security protection. Node A 168 would perform authentication and key establishment. The established 169 security association (together with the session key) would allow the 170 user to protect QoS signaling messages. The identity used during the 171 authentication and key establishment phase would be used by Network X 172 (see Figure 1) to perform the so-called policy-based admission control 173 procedure. In our context this user identifier would be used to 174 establish the necessary infrastructure to provide authorization and 175 charging. Signaling messages later exchanged between the different 176 networks are then also subject to authentication and authorization. The 177 authenticated entity thereby is, however, the neighboring network and 178 not the end host. 180 The New Jersey Turnpike model is attracting because of its simplicity. 181 In [5] S. Schenker et. al. discussed various accounting implications and 182 introduced the edge pricing model. The edge pricing model is very 183 similar to this model with the exception that mobility and the security 184 implications itself are not addressed. 186 4.2 New Jersey Parkway Model 188 On the New Jersey Parkway highway, drivers have to deposit 20 or 25 189 cents every few miles, with toll booths in the middle of the road in 190 addition to entrance or exit ramps. (With electronic toll tags, each 191 such toll is deducted individually.) 193 +--------------------+ +--------------------+ +--------------------+ 194 | Network | | Network | | Network | 195 | X | | Y | | Z | 196 | | | | | | 197 | | | | | | 198 | | | | | | 199 | | | | | | 200 +-------^ -----------+ +----------^---------+ +-----^---+----------+ 201 | | | . 202 |+-------------------------+ | . 203 ||+-------------------------------------------+ . 204 ||| . 205 +-+++--+ Data Data +--+---+ 206 | Node | ====================================> | Node | 207 | A | Sender Receiver | B | 208 +------+ +------+ 210 Legend: 212 ----> Direct authorization and charging relationship 214 ====> Data flow 216 ..... Communication to the end host 218 Figure 2: New Jersey Parkway Model 220 In this model one of the NSIS end points (initiator or responder) is 221 charged directly by the traversed domains along the path. In other 222 words, each network charges the end point only for the incurred costs in 223 its own network. Each network maintains only local pricing information. 224 Figure 2 shows this model in case that the data sender is charged. 226 The following list gives some issues caused by the selection of this 227 model: 229 · Since the end point probably does not have agreements with all 230 traversed networks there is a need for a trusted third party for 231 authentication, authorization and financial settlement. Such a 232 trusted third party might be a clearing house. 234 · Authentication and authorization of reservation requests needs to 235 be done on a per-reservation request basis. As a possible 236 solution, the signaling messages might carry authorization tokens 237 from the charged entity which can be verified at the intermediate 238 domains. Each network might have to contact the clearing house. A 239 route change might therefore require a new authentication and 240 authorization of the end point for the purpose of charging. 242 · There are, however, some concerns related to scalability and 243 deployment. If the NSIS initiator is located in the end host (and 244 the NSIS initiator is charged) then the number of end points may 245 be too large to handle by a clearing house. Therefore, some kind 246 of proxy in the access network which interacts with the clearing 247 house on behalf of several end points may be required. Another 248 approach is to use a distributed clearing house. If this model is 249 deployed on an Internet-wide scale then there is a need for 250 multiple clearinghouses that need to communicate with each other. 251 This introduces additional complexity. 253 · A route change might require a new end-to-middle 254 authentication/authorization for the purpose of charging. Hence a 255 route change might not be handled locally anymore. This has an 256 impact on the local repair mechanism. In the New Jersey Turnpike 257 model a route change in the middle of the network does not 258 require any interaction with nodes other than the involved ones. 259 The New Jersey Parkway model is different since it might require 260 an interaction with the end points and thereby destroying the 261 local repair mechanism. 263 · To reduce state maintenance, processing and signaling message 264 exchanges in the core network some sort of aggregation (see [6], 265 [7], [8] ) is used. Aggregation thereby causes per-flow end-to- 266 end signaling messages to be hidden in the core network and a 267 separate signaling message exchange to be used. Because the New 268 Jersey Parkway model might require some interaction with an 269 individual end host aggregation in the traditional sense might be 270 much more difficult to deploy. 272 5 What should be charged? 274 In the above-description we assumed that data sender is simply charged 275 for something. There are, however, some more fine-grained charging 276 considerations which might affect the complexity of the interaction. In 277 Section 6 the question is consider which entity to charge. Closely 278 related is therefore what a user can be charged for: 280 Signaling messages: Although it is possible to charge signaling 281 message originators for generated messages it is currently 282 rarely used. In some cases such a behavior denial of service 283 attacks could be prevented or the misuse of end-to-end 284 signaling messages as a subliminal channel. 286 QoS reservations: Charging on the reservations implies charging on 287 reserved resources regardless whether they are used or not. 289 Transmitted data traffic: Charging based on transmitted data 290 traffic is based on the amount of bytes/packets that have been 291 send by the data source. This type of charging will constrain 292 the traffic volume of the data source but not the duration or 293 amount of the reservation. Therefore, this type of charing can 294 only be applied for QoS classes that allow for overbooking of 295 resources (i.e. resources are not provisioned with regard to 296 their specified peak rate). 298 Application cost: Finally there are costs associated to the usage 299 of a particular service such as a video service. This cost 300 might already include the cost of the above-mentioned costs 301 for more end user transparency. Costs for applications are 302 outside the scope of NSIS. 304 6 Who should be charged? 306 Which entity is charged is one of the most important set of components 307 for a AAA framework. To provide the required functionality the following 308 issues need to be addressed: 310 · Negotiation which entity is charged for which part of the costs 312 · Price Distribution 314 · Authorization of a reservation 316 · QoS Signaling 318 These individual steps might be combined and merged with the QoS 319 signaling messages. As an example, in RSVP the signaling messages PATH 320 or RESV might be used to piggyback information related to price 321 distribution and charging. Whether this is possible depends on the 322 flexibility of the signaling protocol, the number of round-trips 323 executed by the signaling protocol and the semantic of the messages. 325 Subsequently the above-described issues are discussed in more detailed: 327 Negotiation which entity is charged: 329 First the end points need to negotiate/determine which end 330 point will be charged for what part of the total cost. Once it 331 has been decided the networks along the path (Parkway model) 332 or the access networks have to be informed about this decision 333 since they finally need to know where to get the money from. 334 In existing telecommunication networks it is not only possible 335 to provide this negotiation capability at the beginning of the 336 session but also during an establish session or even 337 afterwards. The term session in this context refers to a 338 telephone call. Because of the stateless principle we assume 339 that there is no such session concept and hence it is fair to 340 say that the negotiation is done first (but with the option to 341 be changed at any time). 343 In this context it is interesting to mention that ST-II [9] 344 provides an object to indicate which entity to charge for the 345 reservation. Such object is not included in the base RSVP 346 RFCs. We believe that such information should belong to a QoS 347 signaling protocol since it delivers the necessary information 348 to the networks in order to setup the accounting and charging 349 procedures. 351 In the literature (for example in [5], in [10] and in [11]) an 352 additional degree of control has been introduced by allowing 353 the sender and the receiver to share their costs according to 354 a fractional part. Furthermore it is possible the the two 355 parties share different types of costs (see Section 5). Hence 356 it would be possible to charge the sender for the QoS 357 reservation but to charge the receiver for application 358 specific costs. It is needless to say that this adds 359 additional complexity. 361 Price Distribution: 363 Aspects of price distribution are discussed in Section A but a 364 summary of the most important issues is given in this section. 365 Two problems arise when determining the price of the 366 reservation. First, the price cannot be immediately referred 367 from the IP address. Second, the asymmetry of routes at router 368 and AS level (see [12]) and the possibility of asymmetric 369 costs for a single link in the uplink or downlink direction 370 requires that the direction is considered. 372 The process of price determination, price distribution and 373 authorization/charging is likely to be periodic since the 374 duration of the reservation is unknown. The soft-state 375 principle used in NSIS requires periodic refresh messages to 376 keep a reservation in place. Hence there is a question whether 377 the price determination, price distribution and 378 authorization/charging mechanism should be closely tight to 379 this refresh interval. There is clearly a tradeoff between 380 performance (computational and bandwidth requirements) and 381 accuracy/efficiency. If price determination, price 382 distribution and authorization/charging mechanism is bound to 383 the refresh interval and the refresh messages are transmitted 384 at a very high rate then substance overhead might be caused. 386 From a user perspective it seems to be important that cost 387 transparency is provided and that the end host has the ability 388 to determine the cost of a reservation and has the ability to 389 perform cost control. 391 Authorization of a reservation: 393 Whenever authorization is discussed in this context then the 394 ability to provide assurance for charging is meant. This is, 395 however, only of interest where an end host is participating 396 in the signaling message exchange and depending on the chosen 397 model which part of the signaling path is considered. For 398 intra-domain traffic (traffic within an administrative domain) 399 authorization is much simpler: An incoming signaling message 400 hitting a router within the domain is authenticated and 401 verification is required to ensure that the message is 402 transmitted from a known router within the same domain. This 403 assumes that the borders are properly protected and discard 404 unprotected signaling message from other domains. 406 Authorization for a QoS reservation from an end host to the 407 attached network requires some guarantee that a particular 408 entity can be charged for the cost of the reservation. The 409 charged entity is likely to be one of the end hosts. The 410 establishment of the necessary infrastructure is either based 411 on a per-session communication (e.g. micro-macro payment 412 protocols, authorization tokens) or more traditionally as part 413 of the network access procedure (e.g. AAA communication). 414 Depending on the model (NJ Turnpike or NJ Parkway model) and 415 on the choice for charging of the data sender or the data 416 receiver per-session established authorization setup might be 417 required. From a performance perspective the per-session based 418 approach is less favorable. 420 QoS Signaling: 422 Finally there is the question how the above-described steps 423 should be most efficiently combined with the behaviour of a 424 QoS signaling protocol. 426 Principally either the data sender or the data receiver can be charged 427 for a QoS reservation. Since signaling protocols are typically 428 characterised as either sender- or receiver-initiated, an answer has to 429 be provided which approach allows a better integration with various 430 charging strategies. Unfortunately, it is not possible to consider only 431 charging for the data sender since charging for the data receiver is 432 often used in todays telecommunication networks (e.g. 800# numbers, 433 collect calls). 435 In this version of the document we mainly focus on the simpler NJ 436 Turnpike model. Future versions will extend the descriptions to the NJ 437 Parkway model. 439 To simplify representation the AAA infrastructure is not shown in Figure 440 3, 4, 5 and in 6. Hence to get a complete picture the reader has to take 441 the AAA infrastructure into account. This might involve interaction with 442 local AAA servers, interaction with a Credit Control Server for the 443 purpose of real-time cost and credit control as described in [13] or 444 home AAA servers in case of mobility as depicted in Section 7. 446 6.1 Sender initiated reservations with charging for the data sender 448 This model is the simplest in relationship with the NJ Turnpike model 449 since the data sender S which triggers the reservation is also charged. 450 The necessary charging infrastructure is likely to be established as 451 part of network access authentication and the interaction with a AAA 452 infrastructure. When AS 1 receives a QoS reservation request which asks 453 for the establishment of a QoS reservation then an authorization check 454 can immediately be executed. Authorization might not only be based on 455 credit availablility but also on some information stored with the 456 subscriber's contract such as contract type or some form of policy which 457 might also be distributed as part of the initial network access 458 procedures or on-demand accessible via the AAA infrastructure. The 459 subscriber's contract is a business relationship between the user and 460 his home provider. 462 To provide cost control for the data sender it is likely that additional 463 communication between AS 1 and the initiator S is necessary to 464 distribute the necessary information. The initiator S might want to know 465 the price for the QoS reservation in advance before issuing a QoS 466 reservation message (RESV message in Figure 3 based on the RSVP 467 terminology). Hence for in-band price distribution a separate roundtrip 468 is required. For out-of-band price determination such a roundtrip can be 469 omitted but some tariff or price information has to be communicated 470 between the sender S and the access network (AS1 in our case) - if not 471 already known for some other reason. 473 For in-band price distribution each network (or even each router) along 474 the path accumulates cost and AS 1 charges S for the total amount. Based 475 on the existing peering relationship between neighboring networks each 476 provider charges its neighboring provider. This procedure might be 477 comparable with the postal service where a customer gives a letter to a 478 post post office and delegates responsibility to perform the required 479 shipping. The post office might itself delegate the responsibility to 480 other companies to transport the letter to its final destination. The 481 sender pays for the total amount for the shipment at the post office 482 which knows the total cost for the entire delivery. Each participating 483 party receives the monetary amount negotiated with its "peer" based on 484 the previously agreed price. A similar description is provided in [14]. 486 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 487 |AS 1|----->|AS 2|----->|AS 3|----->|AS 4|----->|AS 5| 488 +----+ +----+ +----+ +----+ +----+ 489 ^ |RESV 490 |RESV v 491 +----+ +----+ 492 | S | | R | 493 +----+ +----+ 494 Data Traffic 495 ================================================> 496 Charging (S -> AS1 -> AS2 -> AS3 -> AS4 -> AS5) 497 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 499 Legend: 501 ----> Signaling message 502 ====> Data flow 503 ~~~~> Charging direction 505 Figure 3: Sender-initiated reservation with charging for the data sender 507 6.2 Sender initiated reservation with charging for the data receiver 508 Charging for the data receiver is more complex in comparison to charging 509 for the data sender. The reason is not due to the QoS signaling 510 machinery - such as sender- or receiver-initiated reservations but 511 caused by the complicated charging relationships. The following 512 description tries to describe the problem in more detail which is 513 depicted in Figure 4: 515 When AS 1 receives the RESV signaling message from S which indicates 516 that R is charged for the price of the QoS reservation then AS 1 needs 517 some assurance that the entity R is willing to pay for the indicated 518 reservation. Hence a plain identifier containing the identity of R is 519 insufficient to provide enough assurance. 521 Hence the sender needs to possess some from of authorization token which 522 allows AS 1 to establish the necessary association to a party which is 523 able to provide the financial settlement. Following the idea of such an 524 authorization token the subsequently described interaction is necessary. 526 An authorization token previously send from R to S and then transmitted 527 to AS 1 might allow AS 1 to establish the necessary infrastructure 528 (possibly to a trusted third party or to R's home network) to execute a 529 real-time credit check and to be able to charge R via this 530 infrastructure by AS 1 for a given QoS reservation. Then the QoS 531 reservation is done in the same way as a sender-initiated reservation 532 with charging for a data sender. The total cost for the session cannot 533 be fully determined during the reservation setup because the duration of 534 a call and other factors are unknown at the beginning. Hence periodic 535 communication is necessary between AS 1 and a trusted third party or R's 536 home network. R needs to be given a mechanism to allow the QoS 537 reservation and therefore the costs to be restricted without always 538 transmitting authorization tokens to the data sender for periodic re- 539 authentication and re-authorization procedures. 541 Note that the sender S communicate the name of the data senders access 542 network (in this case AS 1) to the receiver R. This allows the data 543 receiver R to request an authorization token for a specific network with 544 the indicated QoS parameters to include some additional restrictions in 545 the token. 547 It is not very likely that the data receiver R provides direct payment 548 to S before triggering a QoS reservation. Such an infrastructure is not 549 likely to be available. 551 6.3 Receiver initiated reservation with charging for the data receiver 553 The properties of the sender initiated reservation with charging for the 554 data receiver described-above are similar to those of a receiver 555 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 556 |AS 1|----->|AS 2|----->|AS 3|----->|AS 4|----->|AS 5| 557 +----+ +----+ +----+ +----+ +----+ 558 ^ |RESV 559 |RESV v 560 +----+ +----+ 561 | S | | R | 562 +----+ +----+ 563 Data Traffic 564 ================================================> 565 Payment (R -> AS1 or R -> S) 566 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 567 Charging ([S ->] AS1 -> AS2 -> AS3 -> AS4 -> AS5) 568 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 570 Legend: 572 ----> Signaling message 573 ====> Data flow 574 ~~~~> Charging direction 576 Figure 4: Sender-initiated reservation with charging for the data 577 receiver 579 initiated reservation. 581 When AS 1 receives a PATH signaling message then S has to indicate that 582 R is willing to pay for the QoS reservation. Unfortunately the PATH 583 message (with the semantics defined within RSVP) cannot be used to 584 determine the price of a reservation since the receiver is allowed to 585 change the QoS parameters. Hence the computed price might only serve to 586 compute the upper-bound and would therefore only serve R as a hint. AS 5 587 cannot use an out-of-band price distribution mechanism because of 588 asymmetric routes. Hence price distribution can only be probing based 589 (in-band). 591 Finally after a successful reservation the receiver R (or some party 592 associated with R) has to provide a financial settlement with AS 1 to 593 transfer the desired QoS costs. 595 A major question is therefore whether it is possible for R to provide 596 financial settlement with AS5 although the reservation price is 597 determined from S to R (data flow direction). 599 AS 1 therefore has to determine the price for the reservation and 600 communicate the accumulated price along the path to AS 5 and to R. 602 TBD: Is it possible for R establish a financial settlement with AS5 to 603 provide peer-to-peer charging in the reverse direction(R -> AS 5 -> AS 4 604 -> AS 3 -> AS 2 -> AS 1) although authorization for the RESV message 605 would be required at AS 1? 607 +----+ PATH +----+ PATH +----+ PATH +----+ PATH +----+ 608 |AS1 |.....>|AS2 |.....>|AS3 |.....>|AS4 |.....>|AS5 | 609 | |<-----| |<-----| |<-----| |<-----| | 610 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 611 ^ | . ^RESV 612 PATH. v RESV PATH v | 613 +----+ +----+ 614 | S | | R | 615 +----+ +----+ 616 Data Traffic 617 ================================================> 618 Charging (R -> AS1 or R -> S) 619 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 620 Charging ([S ->] AS1 -> AS2 -> AS3 -> AS4 -> AS5) 621 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 623 Legend: 625 ----> Signaling message 626 ====> Data flow 627 ~~~~> Charging direction 629 Figure 5: Receiver-initiated reservation with charging for the data 630 receiver 632 6.4 Receiver initiated reservation with charging for the data sender 634 When the sender S transmits a PATH message neither S nor AS 1 are able 635 to determine the cost for the reservation solely based on the semantic 636 of the PATH message. The PATH message is forwarded towards the data 637 receiver. R then finally decides about the reservation and its 638 parameters but S is charged for the reservation. 640 It seems to be difficult for the sender S to restrict the QoS parameters 641 selected by the receiver R when transmitting the RESV message. It would 642 therefore be better if either a double roundtrip is used or if the 643 semantics of the PATH message is changed. 645 +----+ PATH +----+ PATH +----+ PATH +----+ PATH +----+ 646 |AS1 |.....>|AS2 |.....>|AS3 |.....>|AS4 |.....>|AS5 | 647 | |<-----| |<-----| |<-----| |<-----| | 648 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 649 ^ | . ^RESV 650 PATH. v RESV PATH v | 651 +----+ +----+ 652 | S | | R | 653 +----+ +----+ 654 Data Traffic 655 ================================================> 656 Charging (S -> AS1 -> AS2 -> AS3 -> AS4 -> AS5) 657 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 659 Legend: 661 ----> Signaling message 662 ====> Data flow 663 ~~~~> Charging direction 665 Figure 6: Receiver-initiated reservation with charging for the data 666 sender 668 6.5 NJ Parkway Model Example 670 The following example shows the implications for a sender initiated 671 reservations with charging for the data sender based on the NJ Parkway 672 model. 674 The sender needs some mechanisms to provide information to all 675 intermediate domains which request independent charging from the data 676 sender (i.e. from S). This mechanism can be provided by the following 677 procedures: 679 · Information carried within the NSIS protocol (e.g. OSP tokens) 680 which immediately allow the intermediate domain to contact some 681 trusted third party (such as a clearing house). 683 · The possibility for an intermediate network to request 684 authentication / authorization from the data sender S via NSIS. 685 Such a mechanism might therefore be similar to SIP. 687 · An out-of-band mechanism which is triggered by intermediate 688 networks to request authentication and authorization from 689 intermediate networks. 691 In-band price distribution (or probing) is difficult to use since the 692 data sender is not aware of the QoS reservation costs along the entire 693 path (without a previous query). Out-of-band price distribution might 694 provide this functionality but a separate interaction with each domain 695 to the end host is required. When transmitting some sort of 696 authorization tokens it might be useful for the data sender S to have 697 information about the QoS reservation costs of all individual 698 intermediate domains along the path. 700 7 Implication of Mobility 702 This section addresses some of the implications of mobility. Starting 703 with a simple model at the beginning which allows limited mobility in 704 the same administrative domain some basic observations are made. 705 Extending the basic model to support to mobility to support mobility 706 where both users are registered at the same home network but roam to 707 different access networks (different from the home network). Finally 708 even this restriction is abolished. 710 7.1 Simple model without mobility 712 In Figure 7 two nodes are attached to a single administrative domain 713 either in a non-mobile environment (traditional enterprise network) or 714 with limited mobility in this network. No roaming agreements are 715 necessary and even authentication during network access might be 716 simplified due to a larger degree of freedom for selecting the proper 717 security infrastructure (for example Kerberos everywhere). To provide 718 authorization of a QoS reservation request role based access control 719 might be used since momentary authorization might not be applicable in 720 an enterprise network. Instead users or groups with specific rights 721 might be allowed to trigger QoS reservations. In this case it might not 722 even be necessary to communicate information who is charged for which 723 information to the network elements. Inter-domain communication for QoS 724 signaling messages and for AAA communication is not required. 726 +------------------------------------------------------------------+ 727 | | 728 | +------+ Network | 729 | -+ AAA/ +-- X | 730 | --- | PDP | ---- | 731 | --- +------+ ----- | 732 | --- ----- | 733 | --- ---- | 734 | ----- --- | 735 | +---+----+ +---+----+ | 736 | | Router | | Router | | 737 +------| 1 |--------------------------------------| n |--+ 738 +---+----+ +---+----+ 739 | | 740 +--+---+ +--+---+ 741 | Node | | Node | 742 | A | | B | 743 +------+ +------+ 745 Figure 7: Simple model without mobility 747 7.2 Split between access and home network(s) 749 With Figure 8 the basic environment described in Figure 7 is extended by 750 allowing end hosts to roam to networks (denoted as access network) 751 beyond their home networks. As part of the network access authentication 752 the end host is authenticated to its home network involving entities 753 (such as the local AAA server in the access network). AAA inter-domain 754 communication is required. The QoS signaling messages stay within the 755 same access network which is different than the home network. 756 Additionally the user might be registered at different home networks. 757 These networks primarily serve the purpose of providing a guarantee that 758 the indicated user requesting resources (and network access) is able to 759 pay. This functionality can be provided by a traditional 760 telecommunication network, by a credit card company or by something 761 similar. 763 In comparison to the previous model it is likely that role-based access 764 control is not sufficient for the purpose of QoS reservation request 765 authorization. Hence it might be necessary for the end hosts to decide 766 which entity (user A at node A or user B at node B) has to be charged 767 for which resource (QoS reservation, QoS data traffic, etc.). The access 768 network then collects accounting records and transmits bills to the 769 indicated home network of the authenticated user. Since the QoS 770 signaling messages travel only within a single administrative domain it 771 is not necessary to address issues raised in Section 4. 773 +----------------------+ +----------------------+ 774 | +------+ | | +------+ | 775 | | AAA | Home | | | AAA | Home | 776 | | | Network | | | | Network | 777 | +--+---+ (User A)| | +--+---+ (User B)| 778 | | | | | | 779 | | | | | | 780 +----+-----------------+ +----+-----------------+ 781 | | 782 +---------------------------+-----------------+ 783 | 784 +--------------------------------+-----------------------------------+ 785 | +--+---+ Access Network | 786 | | AAA/ | | 787 | | PDP | | 788 | +--+---+ | 789 | +---------------------+-----------------------+ | 790 | | | | 791 | +---+----+ +---+----+ | 792 | | Router | | Router | | 793 +------| x |------------------------------------| y |------+ 794 +---+----+ +---+----+ 795 | | 796 +--+---+ +--+---+ 797 | Node | | Node | 798 | A | | B | 799 +------+ +------+ 801 Figure 8: Split between access and home network(s) 803 7.3 Global mobility 805 As an extension of the previous model global mobility is considered 806 where users are subscribed at different home networks and they roam in 807 different networks. The networks between the two access networks (X and 808 Y), which are traversed by the QoS signaling message, are omitted. This 809 scenario addresses issues discussed in Section 4 and 6. Note that the 810 AAA Broker is not necessarily required if the two home networks (of user 811 A and B) share a business and trust relationship (and consequently a 812 security association). 814 +----------+ 815 | AAA | 816 +-----------------------+ Broker +----------+ 817 | +----------+ | 818 +----+-----------------+ +----+-----------------+ 819 | +--+---+ | | +--+---+ | 820 | | AAA | Home | | | AAA | Home | 821 | | | Network | | | | Network | 822 | +--+---+ (User A)| | +--+---+ (User B)| 823 | | | | | | 824 | +----+ | | +----+ | 825 | | | | | | 826 +---------+------------+ +---------+------------+ 827 | | 828 +---------+------------+ +---------+------------+ 829 | | | | | | 830 | +--+---+ | | +--+---+ | 831 | | AAA/ | | | | AAA/ | | 832 | | PDP | | | | PDP | | 833 | +---+--+ | | +---+--+ | 834 | | | | | | 835 | Access Network X | | Access Network Y | 836 | | | | | | 837 | +---+----+ | | +---+----+ | 838 | | Router | | | | Router | | 839 +------| x |------+ +------| y |------+ 840 +---+----+ +---+----+ 841 | | 842 +--+---+ +--+---+ 843 | Node | | Node | 844 | A | | B | 845 +------+ +------+ 847 Figure 9: Global mobility 849 8 Security Considerations 851 This document describes the implications of two accounting and charging 852 models (i.e. the New Jersey Turnpike and the New Jersey Parkway model) 853 for NSIS QoS signaling. As excepted, there are implications for the 854 security architecture. The New Jersey Turnpike model is based on the 855 peer-to-peer security and the chain-of-trust. This model, although often 856 criticised, serves as the basis for RSVP and some of its mechanisms such 857 as local repair and the aggregation mechanism. The second model, the New 858 Jersey Parkway model, relaxes the assumption of the first model. The 859 introduced end-to-middle authentication adds additional complexity. 861 This document does not discuss concrete security mechanisms for both 862 models, instead the implications are presented at an abstract level. 863 Hence it is not useful to give detailed security requirements and 864 threats. 866 Based on the topics discussed in this draft the NSIS working group 867 should decide on which model QoS signaling should be based. Additionally 868 it is necessary to discuss sender- and receiver-initiated signaling and 869 finally the impacts of price distribution need to be addressed. 871 9 Open Issues 873 · Non-repudiation is a security property where one party is later 874 unable to deny the execution of a specific action. For QoS 875 signaling this might be a desirable property. When added to a 876 signaling protocol this property, unfortunately, is not for free. 877 Hence it is an open question whether real-world applications and 878 architectures demand this property. 880 10 Acknowledgements 882 Place you name here. 884 A Price Distribution 886 How much an entity is charged for individual parts of a QoS reservation 887 (see Section 5) is mainly a matter of business/marketing decisions and 888 will not be discussed in this document and is outside the scope of NSIS. 889 The task of determining the price is called pricing. Unfortunately the 890 price of a QoS reservation cannot easily determined based on the 891 structure of the IP address unlike with E.164 phone numbers. Depending 892 on the chosen price distribution mechanism implications for an NSIS 893 signaling protocol exist. 895 Principally, two ways of price distributions can be identified: 897 Out-of-band price distribution: Using this approach the inter- 898 domain prices for certain destinations a distributed by 899 mechanisms executed separate from a NSIS in-path signaling 900 protocol. In case of out-of-band price distribution it is 901 required that the price is determined based on destination AS 902 and the ASes along the path to this network. If the price for 903 one or more networks along this path then some additional 904 signaling is required. The main assumption of this scheme is 905 that the information obtained by the BGP-based sink tree 906 mechanism provides a good approximation to the path 907 subsequently taken by the later data packets. 909 In-band probing: The signaling messages enable some functions to 910 query the costs along the path to determine the costs between 911 the source and the destination. To discover the networks along 912 the path is fairly simple if a signaling protocol used used 913 (in-band probing). As a disadvantage a signaling protocol 914 needs to carry new objects and additional processing is 915 required at each network along the path. Hence it is required 916 that each network understands and processes these objects. 918 In the past a number of price distribution protocols have been proposed 919 which have a strong relationship to the signaling machinery, since they 920 share common properties: 922 · The determined price depends on the route between source network 923 and destination network. Protocols which allow their objects to 924 be embedded into the signaling protocol (in-band probing) are 925 able to more accurately determine the path and therefore the 926 associated costs. 928 · Some flexibility and extensibility is required to allow 929 autonomous systems to determine the price for a QoS reservation 930 independently of other domains. 932 · Signaling price information between various networks suffers from 933 the same signaling protocol requires (such as scalability, "in- 934 path" discovery, etc.) as QoS signaling protocols. To tackle 935 scalability similar mechanisms for aggregation are therefore 936 considered such as those used in [7]. 938 · Unfortunately none of the proposals cares about the issues 939 described in Section 4 introduced by the two different models. 941 In [11] an in-band probing approach is presented which allows price 942 information to be communicated. The pricing object is updated along the 943 path to reflect costs. The idea of the Simple RSVP protocol [15] also 944 seems to follow a similar strategy. 946 RNAP [10] is a proposal which allows both in-band probing and out-of- 947 band price distribution. The out-of-band price distribution mechanism is 948 modeled according to the same principles as BGRP's aggregation and 949 protocol mechanism [7]. The aggregation mechanism of BGRP is inspired by 950 BGP [16]. A very similar idea was chosen by the Border Pricing Protocol 951 (BPP) [17], which uses the same aggregation mechanism but only allows 952 out-of-band price distribution. 954 The Tariff Distribution Protocol (TDP) [18] is an attempt to define 955 message formats (using XML, HTML, plain text or even in a binary format 956 e.g. JAVA classes) and attributes for exchanging tariff information 957 either in an in-band (for example with RSVP) or out-of-band fashion. 958 Instead of exchanging price information in [18] tariff are communicated. 959 The term tariff is thereby defined as: "A tariff is a set of rules for 960 calculating the charge advices for session of one service" (see Section 961 2 of[18]). The difference between charge and charge advice is also 962 described in Section 2 of [18]. Unlike in other proposals aggregation is 963 not considered. 965 In the Billing Information Protocol (BIP) [19] only attributes used to 966 deliver price information are described (in BNF notation). The current 967 specification mainly addresses SIP as a transport mechanism but can be 968 used for other protocols as well. 970 Related to the work described above is the Open Settlement Protocol [20] 971 which is mainly focused on charging and not on price distribution. Hence 972 it should be seen as complementary to the above schemes which could be 973 used to support the New Jersey Parkway Model described in Section 4. 975 The work in the Internet Open Trading Protocol (IOTP) working group (see 976 [21] for the IOTP Version 1.0 specification) aims to map real world 977 transactions to the internet and is as such a superset of the 978 functionality described in this document. 980 B Authors' Addresses 982 Sven Van den Bosch 983 Alcatel 984 Francis Wellesplein 1 985 B-2018 986 Antwerpen 987 Phone: 32-3-240-8103 988 EMail: sven.van_den_bosch@alcatel.be 990 Maarten Büchli 991 Alcatel 992 Francis Wellesplein 1 993 B-2018 994 Antwerpen 995 EMail: maarten.buchli@alcatel.be 996 Henning Schulzrinne 997 Dept. of Computer Science 998 Columbia University 999 1214 Amsterdam Avenue 1000 New York, NY 10027 1001 USA 1002 EMail: schulzrinne@cs.columbia.edu 1004 Hannes Tschofenig 1005 Siemens AG 1006 Otto-Hahn-Ring 6 1007 81739 Munich 1008 Germany 1009 EMail: Hannes.Tschofenig@siemens.com 1011 C Bibliography 1013 [1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1014 "Resource ReSerVation protocol (RSVP) -- version 1 functional 1015 specification," RFC 2205, Internet Engineering Task Force, Sept. 1997. 1017 [2] B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, G. 1018 Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. 1019 Beadles, P. Walsh, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. 1020 Jacobs, B. Lim, B. Hirschman, R. Hsu, Y. Xu, E. Campbell, S. Baba, and 1021 E. Jaques, "Criteria for evaluating AAA protocols for network access," 1022 RFC 2989, Internet Engineering Task Force, Nov. 2000. 1024 [3] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. V. den 1025 Bosch, "Next steps in signaling: Framework," Internet Draft, Internet 1026 Engineering Task Force, 2002. Work in progress. 1028 [4] R. Yavatkar, D. Pendarakis, and R. Guerin, "A framework for policy- 1029 based admission control," RFC 2753, Internet Engineering Task Force, 1030 Jan. 2000. 1032 [5] S. Shenker, D. Clark, D. Estrin, and S. Herzog, "Pricing in computer 1033 networks: Reshaping the research agenda," in Proc. of TPRC 1995 , 1995. 1035 [6] F. Baker, C. Iturralde, F. L. Faucheur, and B. Davie, "Aggregation 1036 of RSVP for IPv4 and IPv6 reservations," RFC 3175, Internet Engineering 1037 Task Force, Sept. 2001. 1039 [7] P. Pan, E. Hahne, and H. Schulzrinne, "Bgrp: Sink-tree-based 1040 aggregation for inter-domain reservations," in Journal of Communications 1041 and Networks, Vol. 2, No. 2, pp. 157-167, http://www.cs.columbia.edu/ 1042 pingpan/papers/bgrp.pdf , 2000. 1044 [8] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. 1045 Braden, B. Davie, J. Wroclawski, and E. Felstaine, "A framework for 1046 integrated services operation over diffserv networks," RFC 2998, 1047 Internet Engineering Task Force, Nov. 2000. 1049 [9] C. Topolcic, "Experimental internet stream protocol: Version 2 (ST- 1050 II)," RFC 1190, Internet Engineering Task Force, Oct. 1990. 1052 [10] X. Wang and H. Schulzrinne, "Rnap: A resource negotiation and 1053 pricing protocol," in International Workshop on Network and Operating 1054 Systems Support for Digital Audio and Video (NOSSDAV'99), pages 77--93, 1055 Basking Ridge, New Jersey 1057 [11] M. Karsten, J. Schmitt, and R. Steinmetz, "An embedded charging 1058 approach for rsvp," in International Workshop on Quality of Service '98, 1059 Napa, California, USA , May 1998. 1061 [12] L. Amini and H. Schulzrinne, "Observations from router-level 1062 internet traces," in DIMACS Workshop on Internet and WWW Measurement, 1063 Mapping and Modeling, (Piscataway, New Jersey) , Feb. 2002. 1065 [13] H. Hakala et al. , "Diameter credit control application," Internet 1066 Draft, Internet Engineering Task Force, June 2002. Work in progress. 1068 [14] J. Gerke, H. Ritter, J. Schiller, and K. Wehrle, "Elements of an 1069 open framework for pricing in the future internet," in Proceedings of 1070 the Conference on Quality of future Internet Services (QofIS 2000), 1071 pages 300--311, Berlin 1073 [15] K. Fujikawa and Y. Goto, "Simple resource ReSerVation protocol 1074 (SRSVP)," Internet Draft, Internet Engineering Task Force, Feb. 2000. 1075 Work in progress. 1077 [16] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)," RFC 1078 1771, Internet Engineering Task Force, Mar. 1995. 1080 [17] V. Oberle, H. Ritter, and K. Wehrle, "Bpp: A protocol for 1081 exchanging pricing information between autonomous systems," in 1082 Proceedings of HPSR 2001 (IEEE Workshop on High-Performance Switching 1083 and Routing), Dallas (USA) , May 2001. 1085 [18] O. Heckmann et al. , "Tariff distribution protocol (TDP)," 1086 Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in 1087 progress. 1089 [19] R. Prasanna, "Bip: Billing information protocol," Internet Draft, 1090 Internet Engineering Task Force, 2002. Work in progress. 1092 [20] E. T. S. Institute, "Telecommunications and internet protocol 1093 harmonization over networks (tiphon); open settlement protocol (osp) for 1094 inter- domain pricing, authorization, and usage exchange, technical 1095 specification 101 321. version 2.1.0." 1097 [21] D. Burdett, "Internet open trading protocol - IOTP version 1.0," 1098 RFC 2801, Internet Engineering Task Force, Apr. 2000.