idnits 2.17.1 draft-tschofenig-nsis-aaa-issues-01.txt: -(141): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(357): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(971): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(981): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 24 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 25 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 26 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 627 has weird spacing: '...itiated reser...' == Line 670 has weird spacing: '...rvation with ...' == Line 708 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 (3 March 2003) is 7724 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 1063 looks like a reference -- Missing reference section? '2' on line 1067 looks like a reference -- Missing reference section? '3' on line 1074 looks like a reference -- Missing reference section? '4' on line 1078 looks like a reference -- Missing reference section? '5' on line 1082 looks like a reference -- Missing reference section? '6' on line 1086 looks like a reference -- Missing reference section? '7' on line 1088 looks like a reference -- Missing reference section? '8' on line 1091 looks like a reference -- Missing reference section? '9' on line 1095 looks like a reference -- Missing reference section? '10' on line 1100 looks like a reference -- Missing reference section? '11' on line 1105 looks like a reference -- Missing reference section? '12' on line 1108 looks like a reference -- Missing reference section? '13' on line 1113 looks like a reference -- Missing reference section? '14' on line 1117 looks like a reference -- Missing reference section? '15' on line 1121 looks like a reference -- Missing reference section? '16' on line 1124 looks like a reference -- Missing reference section? '17' on line 1129 looks like a reference -- Missing reference section? '18' on line 1133 looks like a reference -- Missing reference section? '19' on line 1136 looks like a reference -- Missing reference section? '20' on line 1141 looks like a reference -- Missing reference section? '21' on line 1145 looks like a reference -- Missing reference section? '22' on line 1148 looks like a reference -- Missing reference section? '23' on line 1153 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 25 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-01.txt 7 3 March 2003 8 Expires: September 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. With regard 45 to authorization and charging a few issues still need to be resolved to 46 make it easier for network providers to create a more performant 47 solution. This document tries to highlight some of these issues and 48 explain why NSIS should consider them during the design phase. This 49 document does not try to introduce a new charging or accounting 50 infrastructure and does not aim to provide a literature review of 51 pricing mechanisms or mathematical models. Instead, an abstract view on 52 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 Charging: The determination of the charge units to be assigned to 62 the service utilization (i.e. the usage of chargeable related 63 elements) [5]. 65 Authentication: Entity authentication is the process whereby one 66 party is assured (thorough acquisition of corroborative 67 evidence) of the identity of a second party involved in a 68 protocol, and that the second has actually participated (i.e., 69 is active at, or immediately prior to, the time the evidence 70 is acquired) [6]. Entity authentication is a special type of 71 authentication. In this document the term authentication 72 refers to entity authentication in nearly all cases. 74 Authorization: The act of determining if a particular right, such 75 as access to some resource, can be granted to the presenter of 76 a particular credential [2]. 78 Accounting: The act of collecting information on resource usage for 79 the purpose of trend analysis, auditing, billing, or cost 80 allocation [2]. 82 Domain: Refers to one or more networks under control of a single 83 administrative entity. 85 Chain-of-Trust: Assume a security association between node A and 86 node B and another one between node B and node C. In case node 87 A sends a message to node C it assumes that B acts in the 88 intended manner to securely forward the message to C. This 89 principle of security provides overall security which is as 90 good as the weakest link in the chain. 92 Financial settlement: The process of authentication and 93 authorization between participating entities to establish the 94 necessary infrastructure which provides the service provider 95 with the necessary assurance that a service requestor can be 96 charged. In this document two types of financial settlements 97 are used: per-session and per-channel. 99 Reverse charging denotes charging the receiver of the data traffic in 100 contrast to charging the data sender. 102 3 The Relationship between Authorization and Accounting 104 RSVP is currently only deployed in closed environments such as 105 enterprise networks. In such an environment authorization usually means 106 role-based access control based on group membership or special rights to 107 use a service. Users are typically not charged directly for their 108 generated QoS traffic nor for QoS reservations. If the signaling 109 messages (and thereby the QoS reservation) travel beyond the 110 administrative domain, then the enterprise network is charged and not 111 the individual end user directly. 113 With mobility and telecommunication networks today authorization can (or 114 should) be seen in an abstract form as "Is one of the signaling 115 participants able to pay for the reservation?". This abstraction is 116 supported by the fact that QoS reservations require some form of penalty 117 for not reserving too many resources. 119 Authorization is strongly related to the availability of funds/credits 120 and therefore with charging. Some service provider might use some 121 additional information based on the subscriber profile stored data to 122 assist in the authorization process. 124 4 The Two Trust Models 126 4.1 New Jersey Turnpike Model 128 On the New Jersey Turnpike, motorists pick up a ticket at a toll booth 129 when entering the highway. At the highway exit the ticket is presented 130 and payment is made at the toll booth for the distance driven. An 131 abstract form of this model is given in Figure 1 where security is 132 provided in a peer-to-peer or network-to-network fashion since the 133 accounting and charging model is also accomplished in the same fashion. 135 The model shown in Figure 1 uses peer-to-peer relationships between 136 different administrative domains as a basis for accounting and charging. 137 Based on the peering relationship a chain-of-trust is established. There 138 are several issues which come to mind when considering this type of 139 model: 141 � Since accounting and charging requires some protocol interaction 142 with the end host, it is reasonable to assume that a QoS 144 +--------------------+ +--------------------+ +--------------------+ 145 | Network | | Network | | Network | 146 | X | | Y | | Z | 147 | | | | | | 148 | -----------> -----------> | 149 | | | | | | 150 | | | | | | 151 +--------^-----------+ +--------------------+ +---------+----------+ 152 | . 153 | . 154 | v 155 +--+---+ Data Data +--+---+ 156 | Node | ====================================> | Node | 157 | A | Sender Receiver | B | 158 +------+ +------+ 160 Legend: 162 ----> Peering relationship which allows neighboring networks/entities 163 to charge each other for the QoS reservation and data traffic 165 ====> Data flow 167 ..... Communication to the end host 169 Figure 1: New Jersey Turnpike Model 171 signaling protocol is not the first protocol executed between an 172 end host and the attached network. Typically, some network access 173 protocols are executed which establish a relationship between the 174 user and his home network (subscription-based scenario). A more 175 detailed description of this environment is given in Section 6. 176 Network access procedures which include authentication and 177 authorization establish the necessary financial settlement 178 between the access network and some other entity. For traditional 179 subscription based environments this other entity is the user's 180 home network. In case of alternative means of access the user's 181 home network is replaced by credit card companies or other 182 entities which establish the necessary financial settlement. 183 Generating additional accounting records for QoS reservations and 184 QoS data traffic does not require a major change for the existing 185 accounting infrastructure. We refer to this as a per-channel 186 financial establishment which provides much better performance 187 characteristics as the per-session financial settlement 188 procedures. Per-session financial settlement cannot be completely 189 avoided since it is required for reverse charging. 191 � The price for a QoS reservation needs to be determined somehow 192 and communicated to the charged entity and to the network where 193 the charged entity is attached. The description of this model 194 assumes that the data sender is charged. Section 6 addresses the 195 issue of charging either one of the two end points. 197 Appendix A describes two mechanisms for price distribution: in- 198 band (or probing) and out-off band price distribution protocols 200 � This architecture seems to be simple enough to allow a scalable 201 solution (ignoring reverse charging, multicast issues and price 202 distribution). 204 � Depending on the signaling protocol and the price distribution 205 protocol (especially in case of an in-band protocol) it might be 206 possible that a malicious node is able to cause harm by modifying 207 signaling messages in such a way that the end point is charged 208 more than intended. (TBD: This issue needs to be elaborated in 209 more detail.) 211 Charging the data sender applied to this model simplifies security 212 handling by demanding only peer-to-peer security protection. Node A 213 would perform authentication and key establishment. The established 214 security association (together with the session key) would allow the 215 user to protect QoS signaling messages. The identity used during the 216 authentication and key establishment phase would be used by Network X 217 (see Figure 1) to perform the so-called policy-based admission control 218 procedure. In our context this user identifier would be used to 219 establish the necessary infrastructure to provide authorization and 220 charging. Signaling messages later exchanged between the different 221 networks are then also subject to authentication and authorization. The 222 authenticated entity thereby is, however, the neighboring network and 223 not the end host. 225 The New Jersey Turnpike model is attracting because of its simplicity. 226 S. Schenker et. al. [7] discuss various accounting implications and 227 introduced the edge pricing model. The edge pricing model shows 228 similarity to the model described in this section with the exception 229 that mobility and the security implications itself are not addressed. 231 4.2 New Jersey Parkway Model 233 On the New Jersey Parkway highway, drivers have to deposit 20 or 25 234 cents every few miles, with toll booths in the middle of the road in 235 addition to entrance or exit ramps. (With electronic toll tags, each 236 such toll is deducted individually.) 238 +--------------------+ +--------------------+ +--------------------+ 239 | Network | | Network | | Network | 240 | X | | Y | | Z | 241 | | | | | | 242 | | | | | | 243 | | | | | | 244 | | | | | | 245 +-------^ -----------+ +----------^---------+ +-----^---+----------+ 246 | | | . 247 |+-------------------------+ | . 248 ||+-------------------------------------------+ . 249 ||| . 250 +-+++--+ Data Data +--+---+ 251 | Node | ====================================> | Node | 252 | A | Sender Receiver | B | 253 +------+ +------+ 255 Legend: 257 ----> Direct authorization and charging relationship 259 ====> Data flow 261 ..... Communication to the end host 263 Figure 2: New Jersey Parkway Model 265 In this model one of the NSIS end points (initiator or responder) is 266 charged directly by all traversed domains along the path. In other 267 words, each network charges the end point only for the incurred costs in 268 its own network. Each network maintains only local pricing information. 269 Figure 2 shows this model when the data sender is charged. 271 Below are some issues of this model: 273 � Since the end point probably does not have agreements with all 274 traversed networks there is a need for a trusted third party for 275 authentication, authorization and financial settlement. Such a 276 trusted third party might be a clearing house. 278 � Authentication and authorization of reservation requests needs to 279 be done on a per-reservation request basis. The authorizing 280 entity needs to provide a per-session financial settlement with 281 the intermediate domains. A route change might therefore trigger 282 an authorization process which requires interaction by the 283 authorizing entity. 285 � There are, however, some concerns related to scalability and 286 deployment. If the NSIS initiator is located in the end host (and 287 the NSIS initiator is charged), then the number of end points may 288 be too large to handle by a clearing house. Therefore, some kind 289 of proxy in the access network which interacts with the clearing 290 house on behalf of several end points may be required. Another 291 approach is to use a distributed clearing house. If this model is 292 deployed on an Internet-wide scale, there is a need for multiple 293 clearinghouses that need to communicate with each other. This 294 introduces additional complexity. 296 � A route change might require a new end-to-middle 297 authentication/authorization for the purpose of charging. Hence a 298 route change might not be handled locally anymore. This has an 299 impact on the local repair mechanism. In the New Jersey Turnpike 300 model a route change in the middle of the network does not 301 require any interaction with nodes other than the involved ones. 302 The New Jersey Parkway model is different since it might require 303 an interaction with the end points and thereby destroying the 304 local repair mechanism. 306 � To reduce state maintenance, processing and signaling message 307 exchanges in the core network some sort of aggregation (see [8], 308 [9], [10] ) is used. Aggregation causes per-flow end-to-end 309 signaling messages to be hidden in the core network and a 310 separate signaling message exchange to be used. Because the New 311 Jersey Parkway model might require some interaction with an 312 individual end host aggregation might be much more difficult to 313 deploy. 315 � Per-session financial settlement is necessary and serves as a 316 basis for the protocol interaction. 318 5 What Should Be Charged? 320 In the description above, we assumed that data sender is simply charged 321 for something. There are, however, some more fine-grained charging 322 considerations which affect the complexity of the interaction. In 323 Section 6, we consider which entity to charge. Closely related is what a 324 user is charged for: 326 Signaling messages: Although it is possible to charge signaling 327 message originators for generated messages it is currently 328 rarely used. In some cases charging for signaling can prevent 329 denial of service attacks or the misuse of end-to-end 330 signaling messages as a covert channel. 332 QoS reservations: Charging for resource reservations implies 333 charging for reserved resources regardless of whether they are 334 used or not. 336 Transmitted data traffic: Charging based on transmitted data 337 traffic is based on the amount of bytes or packets that have 338 been sent by the data source. This type of charging will 339 constrain the traffic volume of the data source but not the 340 duration or amount of the reservation. Therefore, this type of 341 charging can only be applied for QoS classes that allow for 342 overbooking of resources (i.e., resources are not provisioned 343 with regard to their specified peak rate). 345 Application cost: Finally, there are costs associated to the usage 346 of a particular service such as a conferencing or video 347 streaming. This cost might already include the cost of the 348 above-mentioned costs for more end user transparency. Costs 349 for applications are outside the scope of NSIS. 351 6 Who Should Be Charged? 353 Which entity is charged is one of the most important questions for an 354 AAA framework. To provide the required functionality the following 355 issues need to be addressed: 357 � Negotiation which entity is charged for which part of the costs; 359 � Price distribution; 361 � Authorization of a reservation; 363 � QoS signaling; 365 These individual steps might be combined and merged with the QoS 366 signaling messages. As an example, in RSVP the signaling messages PATH 367 or RESV might be used to piggyback information related to price 368 distribution and charging. Whether this is possible depends on the 369 flexibility of the signaling protocol, the number of round-trips 370 executed by the signaling protocol and the semantic of the messages. 372 Subsequently the above-described issues are discussed in more detailed: 374 Negotiation which entity is charged: 376 First the end points need to negotiate or determine which 377 entity will be charged for what part of the total cost. Once 378 it has been decided the networks along the path (Parkway 379 model) or the access networks have to be informed about this 380 decision since they finally need to know where to get the 381 money from. In existing telecommunication networks it is not 382 only possible to provide this negotiation capability at the 383 beginning of the session but also during an established 384 session or even afterwards. Because of the stateless principle 385 we assume that there is no such session concept and hence it 386 is fair to say that the negotiation is done first (but with 387 the option to be changed at any time). 389 In this context it is interesting to mention that ST-II [11] 390 provides an object to indicate which entity to charge for the 391 reservation. Such object is not included in the base RSVP 392 RFCs. We believe that such information should belong to a QoS 393 signaling protocol since it delivers the necessary information 394 to the networks in order to setup the accounting and charging 395 procedures. 397 In the literature (for example in [7], in [12] and in [13]), 398 an additional degree of control has been introduced by 399 allowing the sender and the receiver to divide the cost 400 between them. Furthermore, it is possible the the two parties 401 share different types of costs (see Section 5). Hence it would 402 be possible to charge the sender for the QoS reservation but 403 to charge the receiver for application-specific costs. 404 Needless to say, this adds complexity. 406 Price distribution: 408 Aspects of price distribution are discussed in Appendix A, but 409 a summary of the most important issues is given in this 410 section. Two problems arise when determining the price of the 411 reservation. First, the price cannot be immediately inferred 412 from the destination IP address. Second, the asymmetry of 413 routes at router and AS level (see [14]) and the possibility 414 of asymmetric costs for a single link in the uplink or 415 downlink direction requires that the direction is considered. 417 The process of price determination, price distribution and 418 authorization is likely to be periodic since the duration of 419 the QoS reservation is unknown at the beginning of the 420 signaling message exchange. The soft-state principle used in 421 NSIS requires periodic refresh messages to keep a reservation 422 in place. Hence, there is a question whether the price 423 determination, price distribution and authorization mechanism 424 should be closely tied to this refresh interval. There is 425 clearly a tradeoff between performance (computational and 426 bandwidth requirements) and efficiency. If price 427 determination, price distribution and authorization mechanism 428 is bound to the refresh interval and the refresh messages are 429 transmitted at a very high rate, then substantial overhead 430 might be caused. 432 From a user perspective, it is important that cost 433 transparency is provided and that the end host has the ability 434 to determine the cost of a reservation and has the ability to 435 perform cost control. 437 Authorization of a reservation: 439 Whenever authorization is discussed in this context then the 440 ability to provide assurance for charging is meant. This is, 441 however, only of interest where an end host is participating 442 in the signaling message exchange and depending on the chosen 443 model which part of the signaling path is considered. For 444 intra-domain traffic (traffic within an administrative domain) 445 authorization is much simpler: An incoming signaling message 446 hitting a router within the domain is authenticated and 447 verification is required to ensure that the message is 448 transmitted from a known router within the same domain. This 449 assumes that the borders are properly protected and discard 450 unprotected signaling message from other domains. 452 The establishment of the necessary infrastructure is either 453 based on a per-session communication (e.g., micro-macro 454 payment protocols, authorization tokens) or more traditionally 455 as part of the network access procedure (e.g., AAA 456 communication). Depending on the model (NJ Turnpike or NJ 457 Parkway model) and on the choice for charging of the data 458 sender or the data receiver per-session established 459 authorization setup might be required. From a performance 460 perspective, the per-session based approach is less favorable. 462 QoS signaling: 464 Finally. there is the question how the above-described steps 465 should be most efficiently combined with the behaviour of a 466 QoS signaling protocol. 468 Principally either the data sender or the data receiver can be charged 469 for a QoS reservation. Since signaling protocols are typically 470 characterised as either sender- or receiver-initiated, an answer has to 471 be provided which approach allows a better integration with various 472 charging strategies. Unfortunately, it is not possible to consider only 473 charging for the data sender since charging for the data receiver is 474 often used in todays telecommunication networks (e.g., 800 numbers, 475 collect calls). In this version of the document we mainly focus on the 476 simpler NJ Turnpike model. Future versions will extend the descriptions 477 to the NJ Parkway model. 479 To simplify representation the AAA infrastructure is not shown in Figure 480 3, 4, 5 and in 6. Hence to get a complete picture the reader has to take 481 the AAA infrastructure into account. This might involve interaction with 482 local AAA servers, interaction with a Credit Control Server for the 483 purpose of real-time cost and credit control as described in [15] or 484 home AAA servers in case of mobility as depicted in Section 7. 486 6.1 Sender initiated reservations with charging for the data sender 488 This model is the simplest in relationship with the NJ Turnpike model 489 since the data sender S which triggers the reservation is also charged. 490 The necessary charging infrastructure is likely to be established as 491 part of network access authentication and the interaction with a AAA 492 infrastructure. When AS 1 receives a QoS reservation request which asks 493 for the establishment of a QoS reservation then an authorization check 494 can immediately be executed. Authorization might not only be based on 495 credit availablility but also on some information stored with the 496 subscriber's contract such as contract type or some form of policy which 497 might also be distributed as part of the initial network access 498 procedures or on-demand accessible via the AAA infrastructure. The 499 subscriber's contract is a business relationship between the user and 500 his home provider. 502 To provide cost control for the data sender it is likely that additional 503 communication between AS 1 and the initiator S is necessary to 504 distribute the necessary information. The initiator S might want to know 505 the price for the QoS reservation in advance before issuing a QoS 506 reservation message (RESV message in Figure 3 based on the RSVP 507 terminology). Hence for in-band price distribution a separate roundtrip 508 is required. For out-of-band price determination such a roundtrip can be 509 omitted but some tariff or price information has to be communicated 510 between the sender S and the access network (AS1 in our case) - if not 511 already known for some other reason. 513 For in-band price distribution each network (or even each router) along 514 the path accumulates cost and AS 1 charges S for the total amount. Based 515 on the existing peering relationship between neighboring networks each 516 provider charges its neighboring provider. This procedure might be 517 comparable with the postal service where a customer gives a letter to a 518 post post office and delegates responsibility to perform the required 519 shipping. The post office might itself delegate the responsibility to 520 other companies to transport the letter to its final destination. The 521 sender pays for the total amount for the shipment at the post office 522 which knows the total cost for the entire delivery. Each participating 523 party receives the monetary amount negotiated with its "peer" based on 524 the previously agreed price. A similar description is provided in [16]. 526 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 527 |AS 1|----->|AS 2|----->|AS 3|----->|AS 4|----->|AS 5| 528 +----+ +----+ +----+ +----+ +----+ 529 ^ |RESV 530 |RESV v 531 +----+ +----+ 532 | S | | R | 533 +----+ +----+ 534 Data Traffic 535 ================================================> 536 Charging (S -> AS1 -> AS2 -> AS3 -> AS4 -> AS5) 537 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 539 Legend: 541 ----> Signaling message 542 ====> Data flow 543 ~~~~> Charging direction 545 Figure 3: Sender-initiated reservation with charging for the data sender 547 6.2 Sender initiated reservation with charging for the data receiver 549 Charging for the data receiver is more complex in comparison to charging 550 for the data sender. The reason is not due to the QoS signaling 551 machinery - such as sender- or receiver-initiated reservations but 552 caused by the complicated charging relationships. The following 553 description tries to describe the problem in more detail which is 554 depicted in Figure 4: 556 When AS 1 receives the RESV signaling message from S which indicates 557 that R is charged for the price of the QoS reservation then AS 1 needs 558 some assurance that the entity R is willing to pay for the indicated 559 reservation. Hence a plain identifier containing the identity of R is 560 insufficient to provide enough assurance. 562 Hence the sender needs to possess some from of authorization token which 563 allows AS 1 to establish the necessary association to a party which is 564 able to provide the financial settlement. Following the idea of such an 565 authorization token the subsequently described interaction is necessary. 567 An authorization token previously send from R to S and then transmitted 568 to AS 1 might allow AS 1 to establish the necessary infrastructure 569 (possibly to a trusted third party or to R's home network) to execute a 570 real-time credit check and to be able to charge R via this 571 infrastructure by AS 1 for a given QoS reservation. Then the QoS 572 reservation is done in the same way as a sender-initiated reservation 573 with charging for a data sender. The total cost for the session cannot 574 be fully determined during the reservation setup because the duration of 575 a call and other factors are unknown at the beginning. Hence periodic 576 communication is necessary between AS 1 and a trusted third party or R's 577 home network. R needs to be given a mechanism to allow the QoS 578 reservation and therefore the costs to be restricted without always 579 transmitting authorization tokens to the data sender for periodic re- 580 authentication and re-authorization procedures. 582 Note that the sender S communicate the name of the data senders access 583 network (in this case AS 1) to the receiver R. This allows the data 584 receiver R to request an authorization token for a specific network with 585 the indicated QoS parameters to include some additional restrictions in 586 the token. 588 It is not very likely that the data receiver R provides direct payment 589 to S before triggering a QoS reservation. Such an infrastructure is not 590 likely to be available. 592 6.3 Receiver initiated reservation with charging for the data receiver 594 The properties of the sender initiated reservation with charging for the 595 data receiver described-above are similar to those of a receiver 596 initiated reservation. 598 When AS 1 receives a PATH signaling message then S has to indicate that 599 R is willing to pay for the QoS reservation. Unfortunately the PATH 600 message (with the semantics defined within RSVP) cannot be used to 601 determine the price of a reservation since the receiver is allowed to 602 change the QoS parameters. Hence the computed price might only serve to 603 compute the upper-bound and would therefore only serve R as a hint. AS 5 604 cannot use an out-of-band price distribution mechanism because of 605 asymmetric routes. Hence price distribution can only be probing based 606 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 607 |AS 1|----->|AS 2|----->|AS 3|----->|AS 4|----->|AS 5| 608 +----+ +----+ +----+ +----+ +----+ 609 ^ |RESV 610 |RESV v 611 +----+ +----+ 612 | S | | R | 613 +----+ +----+ 614 Data Traffic 615 ================================================> 616 Payment (R -> AS1 or R -> S) 617 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 618 Charging ([S ->] AS1 -> AS2 -> AS3 -> AS4 -> AS5) 619 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 621 Legend: 623 ----> Signaling message 624 ====> Data flow 625 ~~~~> Charging direction 627 Figure 4: Sender-initiated reservation with charging for the data 628 receiver 630 (in-band). 632 Finally after a successful reservation the receiver R (or some party 633 associated with R) has to provide a financial settlement with AS 1 to 634 transfer the desired QoS costs. 636 A major question is therefore whether it is possible for R to provide 637 financial settlement with AS5 although the reservation price is 638 determined from S to R (data flow direction). 640 AS 1 therefore has to determine the price for the reservation and 641 communicate the accumulated price along the path to AS 5 and to R. 643 TBD: Is it possible for R establish a financial settlement with AS5 to 644 provide peer-to-peer charging in the reverse direction(R -> AS 5 -> AS 4 645 -> AS 3 -> AS 2 -> AS 1) although authorization for the RESV message 646 would be required at AS 1? 647 +----+ PATH +----+ PATH +----+ PATH +----+ PATH +----+ 648 |AS1 |.....>|AS2 |.....>|AS3 |.....>|AS4 |.....>|AS5 | 649 | |<-----| |<-----| |<-----| |<-----| | 650 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 651 ^ | . ^RESV 652 PATH. v RESV PATH v | 653 +----+ +----+ 654 | S | | R | 655 +----+ +----+ 656 Data Traffic 657 ================================================> 658 Charging (R -> AS1 or R -> S) 659 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 660 Charging ([S ->] AS1 -> AS2 -> AS3 -> AS4 -> AS5) 661 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 663 Legend: 665 ----> Signaling message with RSVP RESV semantic 666 ....> Signaling message with RSVP PATH semantic 667 ====> Data flow 668 ~~~~> Charging direction 670 Figure 5: Receiver-initiated reservation with charging for the data 671 receiver 673 6.4 Receiver initiated reservation with charging for the data sender 675 When the sender S transmits a PATH message neither S nor AS 1 are able 676 to determine the cost for the reservation solely based on the semantic 677 of the PATH message. The PATH message is forwarded towards the data 678 receiver. R then finally decides about the reservation and its 679 parameters but S is charged for the reservation. 681 It seems to be difficult for the sender S to restrict the QoS parameters 682 selected by the receiver R when transmitting the RESV message. It would 683 therefore be better if either a double roundtrip is used or if the 684 semantics of the PATH message is changed. 686 6.5 NJ Parkway Model Example 687 +----+ PATH +----+ PATH +----+ PATH +----+ PATH +----+ 688 |AS1 |.....>|AS2 |.....>|AS3 |.....>|AS4 |.....>|AS5 | 689 | |<-----| |<-----| |<-----| |<-----| | 690 +----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+ 691 ^ | . ^RESV 692 PATH. v RESV PATH v | 693 +----+ +----+ 694 | S | | R | 695 +----+ +----+ 696 Data Traffic 697 ================================================> 698 Charging (S -> AS1 -> AS2 -> AS3 -> AS4 -> AS5) 699 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 701 Legend: 703 ----> Signaling message with RSVP RESV semantic 704 ....> Signaling message with RSVP PATH semantic 705 ====> Data flow 706 ~~~~> Charging direction 708 Figure 6: Receiver-initiated reservation with charging for the data 709 sender 711 The following example shows the implications for a sender initiated 712 reservations with charging for the data sender based on the NJ Parkway 713 model. 715 The sender needs some mechanisms to provide information to all 716 intermediate domains which request independent charging from the data 717 sender (i.e. from S). This mechanism can be provided by the following 718 procedures: 720 � Information carried within the NSIS protocol (e.g. OSP tokens) 721 which immediately allow the intermediate domain to contact some 722 trusted third party (such as a clearing house). 724 � The possibility for an intermediate network to request 725 authentication / authorization from the data sender S via NSIS. 726 Such a mechanism might therefore be similar to SIP. 728 � An out-of-band mechanism which is triggered by intermediate 729 networks to request authentication and authorization from 730 intermediate networks. 732 In-band price distribution (or probing) is difficult to use since the 733 data sender is not aware of the QoS reservation costs along the entire 734 path (without a previous query). Out-of-band price distribution might 735 provide this functionality but a separate interaction with each domain 736 to the end host is required. When transmitting some sort of 737 authorization tokens it might be useful for the data sender S to have 738 information about the QoS reservation costs of all individual 739 intermediate domains along the path. 741 7 Implication of Mobility 743 This section addresses some of the implications of mobility. Starting 744 with a simple model at the beginning which allows limited mobility in 745 the same administrative domain some basic observations are made. 746 Extending the basic model to support to mobility to support mobility 747 where both users are registered at the same home network but roam to 748 different access networks (different from the home network). Finally 749 even this restriction is abolished. 751 7.1 Simple model without mobility 753 In Figure 7 two nodes are attached to a single administrative domain 754 either in a non-mobile environment (traditional enterprise network) or 755 with limited mobility in this network. No roaming agreements are 756 necessary and even authentication during network access might be 757 simplified due to a larger degree of freedom for selecting the proper 758 security infrastructure (for example Kerberos everywhere). To provide 759 authorization of a QoS reservation request role based access control 760 might be used since momentary authorization might not be applicable in 761 an enterprise network. Instead users or groups with specific rights 762 might be allowed to trigger QoS reservations. In this case it might not 763 even be necessary to communicate information who is charged for which 764 information to the network elements. Inter-domain communication for QoS 765 signaling messages and for AAA communication is not required. 767 7.2 Split between access and home network(s) 769 With Figure 8 the basic environment described in Figure 7 is extended by 770 allowing end hosts to roam to networks (denoted as access network) 771 beyond their home networks. As part of the network access authentication 772 the end host is authenticated to its home network involving entities 773 (such as the local AAA server in the access network). AAA inter-domain 774 communication is required. The QoS signaling messages stay within the 775 +------------------------------------------------------------------+ 776 | | 777 | +------+ Network | 778 | -+ AAA/ +-- X | 779 | --- | PDP | ---- | 780 | --- +------+ ----- | 781 | --- ----- | 782 | --- ---- | 783 | ----- --- | 784 | +---+----+ +---+----+ | 785 | | Router | | Router | | 786 +------| 1 |--------------------------------------| n |--+ 787 +---+----+ +---+----+ 788 | | 789 +--+---+ +--+---+ 790 | Node | | Node | 791 | A | | B | 792 +------+ +------+ 794 Figure 7: Simple model without mobility 796 same access network which is different than the home network. 797 Additionally the user might be registered at different home networks. 798 These networks primarily serve the purpose of providing a guarantee that 799 the indicated user requesting resources (and network access) is able to 800 pay. This functionality can be provided by a traditional 801 telecommunication network, by a credit card company or by something 802 similar. 804 In comparison to the previous model it is likely that role-based access 805 control is not sufficient for the purpose of QoS reservation request 806 authorization. Hence it might be necessary for the end hosts to decide 807 which entity (user A at node A or user B at node B) has to be charged 808 for which resource (QoS reservation, QoS data traffic, etc.). The access 809 network then collects accounting records and transmits bills to the 810 indicated home network of the authenticated user. Since the QoS 811 signaling messages travel only within a single administrative domain it 812 is not necessary to address issues raised in Section 4. 814 7.3 Global mobility 815 +----------------------+ +----------------------+ 816 | +------+ | | +------+ | 817 | | AAA | Home | | | AAA | Home | 818 | | | Network | | | | Network | 819 | +--+---+ (User A)| | +--+---+ (User B)| 820 | | | | | | 821 | | | | | | 822 +----+-----------------+ +----+-----------------+ 823 | | 824 +---------------------------+-----------------+ 825 | 826 +--------------------------------+-----------------------------------+ 827 | +--+---+ Access Network | 828 | | AAA/ | | 829 | | PDP | | 830 | +--+---+ | 831 | +---------------------+-----------------------+ | 832 | | | | 833 | +---+----+ +---+----+ | 834 | | Router | | Router | | 835 +------| x |------------------------------------| y |------+ 836 +---+----+ +---+----+ 837 | | 838 +--+---+ +--+---+ 839 | Node | | Node | 840 | A | | B | 841 +------+ +------+ 843 Figure 8: Split between access and home network(s) 845 As an extension of the previous model global mobility is considered 846 where users are subscribed at different home networks and they roam in 847 different networks. The networks between the two access networks (X and 848 Y), which are traversed by the QoS signaling message, are omitted. This 849 scenario addresses issues discussed in Section 4 and 6. Note that the 850 AAA Broker is not necessarily required if the two home networks (of user 851 A and B) share a business and trust relationship (and consequently a 852 security association). 854 8 Security Considerations 855 +----------+ 856 | AAA | 857 +-----------------------+ Broker +----------+ 858 | +----------+ | 859 +----+-----------------+ +----+-----------------+ 860 | +--+---+ | | +--+---+ | 861 | | AAA | Home | | | AAA | Home | 862 | | | Network | | | | Network | 863 | +--+---+ (User A)| | +--+---+ (User B)| 864 | | | | | | 865 | +----+ | | +----+ | 866 | | | | | | 867 +---------+------------+ +---------+------------+ 868 | | 869 +---------+------------+ +---------+------------+ 870 | | | | | | 871 | +--+---+ | | +--+---+ | 872 | | AAA/ | | | | AAA/ | | 873 | | PDP | | | | PDP | | 874 | +---+--+ | | +---+--+ | 875 | | | | | | 876 | Access Network X | | Access Network Y | 877 | | | | | | 878 | +---+----+ | | +---+----+ | 879 | | Router | | | | Router | | 880 +------| x |------+ +------| y |------+ 881 +---+----+ +---+----+ 882 | | 883 +--+---+ +--+---+ 884 | Node | | Node | 885 | A | | B | 886 +------+ +------+ 888 Figure 9: Global mobility 890 This document describes the implications of two accounting and charging 891 models (i.e. the New Jersey Turnpike and the New Jersey Parkway model) 892 for NSIS QoS signaling. As excepted, there are implications for the 893 security architecture. The New Jersey Turnpike model is based on the 894 peer-to-peer security and the chain-of-trust. This model, although often 895 criticised, serves as the basis for RSVP and some of its mechanisms such 896 as local repair and the aggregation mechanism. The second model, the New 897 Jersey Parkway model, relaxes the assumption of the first model. The 898 introduced end-to-middle authentication adds additional complexity. 900 This document does not discuss concrete security mechanisms for both 901 models, instead the implications are presented at an abstract level. 902 Hence it is not useful to give detailed security requirements and 903 threats. 905 Based on the topics discussed in this draft the NSIS working group 906 should decide on which model QoS signaling should be based. Additionally 907 it is necessary to discuss sender- and receiver-initiated signaling and 908 finally the impacts of price distribution need to be addressed. 910 As a special type of authorization per-session and per-channel financial 911 settlement procedures are introduced. 913 9 Open Issues 915 � Non-repudiation is a security property where one party is later 916 unable to deny the execution of a specific action. For QoS 917 signaling this might be a desirable property. When added to a 918 signaling protocol this property, unfortunately, is not for free. 919 Hence it is an open question whether real-world applications and 920 architectures demand this property. This issue will be addressed 921 in a more solution oriented description. 923 � For intra-domain mobility it is necessary to provide context 924 transfer for the purpose of re-authentiation and authorization. 925 This version of the document does not describe proposal for fast 926 and efficient re-authorization during intra-domain mobility 927 procedures. 929 10 Acknowledgements 931 We would like to thank Tianwei Chen for his comments to the draft. 933 A Price Distribution 935 How much an entity is charged for individual parts of a QoS reservation 936 (see Section 5) is mainly a matter of business/marketing decisions and 937 will not be discussed in this document and is outside the scope of NSIS. 938 The task of determining the price is called pricing. Unfortunately the 939 price of a QoS reservation cannot easily determined based on the 940 structure of the IP address unlike with E.164 phone numbers. Depending 941 on the chosen price distribution mechanism implications for an NSIS 942 signaling protocol exist. 944 Principally, two ways of price distributions can be identified: 946 Out-of-band price distribution: Using this approach the inter- 947 domain prices for certain destinations a distributed by 948 mechanisms executed separate from a NSIS in-path signaling 949 protocol. In case of out-of-band price distribution it is 950 required that the price is determined based on destination AS 951 and the ASes along the path to this network. If the price for 952 one or more networks along this path then some additional 953 signaling is required. The main assumption of this scheme is 954 that the information obtained by the BGP-based sink tree 955 mechanism provides a good approximation to the path 956 subsequently taken by the later data packets. 958 In-band probing: The signaling messages enable some functions to 959 query the costs along the path to determine the costs between 960 the source and the destination. To discover the networks along 961 the path is fairly simple if a signaling protocol used used 962 (in-band probing). As a disadvantage a signaling protocol 963 needs to carry new objects and additional processing is 964 required at each network along the path. Hence it is required 965 that each network understands and processes these objects. 967 In the past a number of price distribution protocols have been proposed 968 which have a strong relationship to the signaling machinery, since they 969 share common properties: 971 � The determined price depends on the route between source network 972 and destination network. Protocols which allow their objects to 973 be embedded into the signaling protocol (in-band probing) are 974 able to more accurately determine the path and therefore the 975 associated costs. 977 � Some flexibility and extensibility is required to allow 978 autonomous systems to determine the price for a QoS reservation 979 independently of other domains. 981 � Signaling price information between various networks suffers from 982 the same signaling protocol requires (such as scalability, "in- 983 path" discovery, etc.) as QoS signaling protocols. To tackle 984 scalability similar mechanisms for aggregation are therefore 985 considered such as those used in [9]. 987 � Unfortunately none of the proposals cares about the issues 988 described in Section 4 introduced by the two different models. 990 In [13] an in-band probing approach is presented which allows price 991 information to be communicated. The pricing object is updated along the 992 path to reflect costs. The idea of the Simple RSVP protocol [17] also 993 seems to follow a similar strategy. 995 RNAP [12] is a proposal which allows both in-band probing and out-of- 996 band price distribution. The out-of-band price distribution mechanism is 997 modeled according to the same principles as BGRP's aggregation and 998 protocol mechanism [9]. The aggregation mechanism of BGRP is inspired by 999 BGP [18]. A very similar idea was chosen by the Border Pricing Protocol 1000 (BPP) [19], which uses the same aggregation mechanism but only allows 1001 out-of-band price distribution. 1003 The Tariff Distribution Protocol (TDP) [20] is an attempt to define 1004 message formats (using XML, HTML, plain text or even in a binary format 1005 e.g. JAVA classes) and attributes for exchanging tariff information 1006 either in an in-band (for example with RSVP) or out-of-band fashion. 1007 Instead of exchanging price information in [20] tariff are communicated. 1008 The term tariff is thereby defined as: "A tariff is a set of rules for 1009 calculating the charge advices for session of one service" (see Section 1010 2 of[20]). The difference between charge and charge advice is also 1011 described in Section 2 of [20]. Unlike in other proposals aggregation is 1012 not considered. 1014 In the Billing Information Protocol (BIP) [21] only attributes used to 1015 deliver price information are described (in BNF notation). The current 1016 specification mainly addresses SIP as a transport mechanism but can be 1017 used for other protocols as well. 1019 Related to the work described above is the Open Settlement Protocol [22] 1020 which is mainly focused on charging and not on price distribution. Hence 1021 it should be seen as complementary to the above schemes which could be 1022 used to support the New Jersey Parkway Model described in Section 4. 1024 The work in the Internet Open Trading Protocol (IOTP) working group (see 1025 [23] for the IOTP Version 1.0 specification) aims to map real world 1026 transactions to the internet and is as such a superset of the 1027 functionality described in this document. 1029 B Authors' Addresses 1031 Sven Van den Bosch 1032 Alcatel 1033 Francis Wellesplein 1 1034 B-2018 1035 Antwerpen 1036 Phone: 32-3-240-8103 1037 EMail: sven.van_den_bosch@alcatel.be 1039 Maarten B�chli 1040 Alcatel 1041 Francis Wellesplein 1 1042 B-2018 1043 Antwerpen 1044 EMail: maarten.buchli@alcatel.be 1046 Henning Schulzrinne 1047 Dept. of Computer Science 1048 Columbia University 1049 1214 Amsterdam Avenue 1050 New York, NY 10027 1051 USA 1052 EMail: schulzrinne@cs.columbia.edu 1054 Hannes Tschofenig 1055 Siemens AG 1056 Otto-Hahn-Ring 6 1057 81739 Munich 1058 Germany 1059 EMail: Hannes.Tschofenig@siemens.com 1061 C Bibliography 1063 [1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1064 "Resource ReSerVation protocol (RSVP) -- version 1 functional 1065 specification," RFC 2205, Internet Engineering Task Force, Sept. 1997. 1067 [2] B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, G. 1068 Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. 1069 Beadles, P. Walsh, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. 1070 Jacobs, B. Lim, B. Hirschman, R. Hsu, Y. Xu, E. Campbell, S. Baba, and 1071 E. Jaques, "Criteria for evaluating AAA protocols for network access," 1072 RFC 2989, Internet Engineering Task Force, Nov. 2000. 1074 [3] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. V. den 1075 Bosch, "Next steps in signaling: Framework," Internet Draft, Internet 1076 Engineering Task Force, 2002. Work in progress. 1078 [4] R. Yavatkar, D. Pendarakis, and R. Guerin, "A framework for policy- 1079 based admission control," RFC 2753, Internet Engineering Task Force, 1080 Jan. 2000. 1082 [5] "European telecommunications standards institute (etsi), internet 1083 protocol (ip) based networks; parameters and mechanisms for charging 1084 technical report 101 734 version 1.1.1," 1999. 1086 [6] 1997. 1088 [7] S. Shenker, D. Clark, D. Estrin, and S. Herzog, "Pricing in computer 1089 networks: Reshaping the research agenda," in Proc. of TPRC 1995 , 1995. 1091 [8] F. Baker, C. Iturralde, F. L. Faucheur, and B. Davie, "Aggregation 1092 of RSVP for IPv4 and IPv6 reservations," RFC 3175, Internet Engineering 1093 Task Force, Sept. 2001. 1095 [9] P. Pan, E. Hahne, and H. Schulzrinne, "Bgrp: Sink-tree-based 1096 aggregation for inter-domain reservations," in Journal of Communications 1097 and Networks, Vol. 2, No. 2, pp. 157-167, http://www.cs.columbia.edu/ 1098 pingpan/papers/bgrp.pdf , 2000. 1100 [10] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. 1101 Braden, B. Davie, J. Wroclawski, and E. Felstaine, "A framework for 1102 integrated services operation over diffserv networks," RFC 2998, 1103 Internet Engineering Task Force, Nov. 2000. 1105 [11] C. Topolcic, "Experimental internet stream protocol: Version 2 (ST- 1106 II)," RFC 1190, Internet Engineering Task Force, Oct. 1990. 1108 [12] X. Wang and H. Schulzrinne, "Rnap: A resource negotiation and 1109 pricing protocol," in International Workshop on Network and Operating 1110 Systems Support for Digital Audio and Video (NOSSDAV'99), pages 77--93, 1111 Basking Ridge, New Jersey 1113 [13] M. Karsten, J. Schmitt, and R. Steinmetz, "An embedded charging 1114 approach for rsvp," in International Workshop on Quality of Service '98, 1115 Napa, California, USA , May 1998. 1117 [14] L. Amini and H. Schulzrinne, "Observations from router-level 1118 internet traces," in DIMACS Workshop on Internet and WWW Measurement, 1119 Mapping and Modeling, (Piscataway, New Jersey) , Feb. 2002. 1121 [15] H. Hakala et al. , "Diameter credit control application," Internet 1122 Draft, Internet Engineering Task Force, June 2002. Work in progress. 1124 [16] J. Gerke, H. Ritter, J. Schiller, and K. Wehrle, "Elements of an 1125 open framework for pricing in the future internet," in Proceedings of 1126 the Conference on Quality of future Internet Services (QofIS 2000), 1127 pages 300--311, Berlin , 2000. 1129 [17] K. Fujikawa and Y. Goto, "Simple resource ReSerVation protocol 1130 (SRSVP)," Internet Draft, Internet Engineering Task Force, Feb. 2000. 1131 Work in progress. 1133 [18] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)," RFC 1134 1771, Internet Engineering Task Force, Mar. 1995. 1136 [19] V. Oberle, H. Ritter, and K. Wehrle, "Bpp: A protocol for 1137 exchanging pricing information between autonomous systems," in 1138 Proceedings of HPSR 2001 (IEEE Workshop on High-Performance Switching 1139 and Routing), Dallas (USA) , May 2001. 1141 [20] O. Heckmann et al. , "Tariff distribution protocol (TDP)," 1142 Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in 1143 progress. 1145 [21] R. Prasanna, "Bip: Billing information protocol," Internet Draft, 1146 Internet Engineering Task Force, 2002. Work in progress. 1148 [22] E. T. S. Institute, "Telecommunications and internet protocol 1149 harmonization over networks (tiphon); open settlement protocol (osp) for 1150 inter- domain pricing, authorization, and usage exchange, technical 1151 specification 101 321. version 2.1.0." 1153 [23] D. Burdett, "Internet open trading protocol - IOTP version 1.0," 1154 RFC 2801, Internet Engineering Task Force, Apr. 2000.