idnits 2.17.1 draft-dressler-nsis-accounting-nslp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 780. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 796), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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.) ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2004) is 7226 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) == Unused Reference: 'RFC2629' is defined on line 641, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-03 == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-03 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-02 -- No information found for draft-courturier-nsis-measure - is the name correct? == Outdated reference: A later version (-06) exists of draft-ietf-aaa-diameter-cc-05 == Outdated reference: A later version (-22) exists of draft-lior-radius-prepaid-extensions-03 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Dressler 2 Internet-Draft G. Carle 3 Expires: January 9, 2005 University of Tuebingen 4 C. Fan 5 C. Kappler 6 H. Tschofenig 7 Siemens AG 8 July 11, 2004 10 NSLP for Accounting Configuration Signaling 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 Monitoring, metering and accounting of packets are increasingly 45 important functionality that needs to be provided in the Internet. 46 This document proposes the definition of a new NSIS NSLP which allows 47 the dynamic configuration of accounting entities on the data path. A 48 problem statement, scenarios for a QoS monitoring and a charging 49 application, and requirements presented. Finally, the usage of NSIS 50 for this purpose is motivated. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1 Charging . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2 QoS Monitoring . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3 Configuration information common to both scenarios . . . . 8 65 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.1 General requirements . . . . . . . . . . . . . . . . . . . 9 67 5.1.1 Extensibility . . . . . . . . . . . . . . . . . . . . 9 68 5.1.2 Scalability . . . . . . . . . . . . . . . . . . . . . 9 69 5.1.3 Interoperability . . . . . . . . . . . . . . . . . . . 9 70 5.1.4 Security . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.2 Flexible accounting model . . . . . . . . . . . . . . . . 10 72 5.3 Distinguishing flows . . . . . . . . . . . . . . . . . . . 10 73 5.4 Flexible data collection . . . . . . . . . . . . . . . . . 10 74 5.5 Location of accounting entities . . . . . . . . . . . . . 11 75 5.6 Location of the collector . . . . . . . . . . . . . . . . 11 76 5.7 Configuration protocol . . . . . . . . . . . . . . . . . . 11 77 5.7.1 Configuration of accounting entities . . . . . . . . . 11 78 5.7.2 Selection of accounting entities . . . . . . . . . . . 11 79 5.7.3 Accounting Configuration State installation and 80 removal . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.7.4 Initiation and maintenance of accounting tasks . . . . 11 82 5.7.5 Collection of information on available accounting 83 entities . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.8 Accounting across domains . . . . . . . . . . . . . . . . 12 86 6. Applicability of NSIS . . . . . . . . . . . . . . . . . . . . 12 88 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 92 8.2 Informative References . . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 96 Intellectual Property and Copyright Statements . . . . . . . . 18 98 1. Introduction 100 Monitoring, metering and accounting of packets is an important 101 functionality in many networks today. Several working groups have 102 described mechanisms to collect and report usage data for resource 103 consumption in a network by a particular entity. For example, the 104 IPFIX WG defines a protocol to collect such data. RADIUS (see 105 [RFC2865], [RFC2866] and 106 [I-D.draft-lior-radius-prepaid-extensions-03]) and DIAMETER (see 107 [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols which 108 provide information about consumed resources via accounting records. 109 The Meter MIB [RFC2720] is a MIB for collecting flow information. 110 However, it is also necessary to configure and coordinate the 111 entities doing the accounting. In more complex network topologies 112 and architectures these entities are not only located at the edges of 113 a network. Instead, these accounting entities are distributed along 114 the data path. While it is possible to configure these entities with 115 protocols such as RADIUS or DIAMETER (or SNMP for the Meter MIB), it 116 is also cumbersome. 118 This draft introduces a new NSLP the Accounting NSLP for 119 configuration and coordination of accounting entities in a 120 path-coupled fashion. 122 This draft is organized as follows: We give a problem description in 123 Section 3, and then illustrate it with a number of scenarios in 124 Section 4. Subsequently, we list a few requirements in Section 5. 125 Finally, we discuss the suitability of NSIS for the configuration of 126 accounting entities in Section 6. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 Furthermore, this document uses the following terms: 136 Accounting Data 138 Accounting data describe utilized resources concerning a 139 particular flow or service for a later charging process. Examples 140 for such data are packet counter, timers, and information 141 describing the end user or system. 143 Accounting Record 145 An accounting record represents aggregated and/or correlated 146 accounting data. 148 Monitoring Probe 150 A monitoring probe is an entity that examines the data flow in 151 order to gather accounting data. This accounting data is exported 152 to an accounting entity. 154 Accounting entity 156 An accounting entity produces accounting data describing the 157 resource utilization of a particular flow or service. Typically, 158 this information is collected from accociated monitoring probes. 160 Collector 162 A collector receives accounting data from one or multiple 163 accounting entities. This accounting data is aggregated, 164 correlated, and stored in form of accounting records. 166 3. Problem Statement 168 There is a need in industry and the Internet research community to 169 collect and export information on data flows. We call such 170 information accounting records. Accounting records are useful in 171 mediation systems, accounting systems, and network management systems 172 to facilitate services such as Internet research, measurement, 173 accounting, billing, QoS monitoring, intrusion detection, and traffic 174 profiling/engineering. In recognition of the need for such 175 accounting the IPFIX WG was founded. 177 While the purpose for collecting accounting records in each case is 178 different, the basic architecture of such accounting systems is 179 usually identical, cf. Figure 1. Measurement data is collected by a 180 monitoring probe, and from there transported to an accounting entity. 181 The accounting entity produces accounting data from the measurement 182 data or additional data such as session information. Monitoring 183 probe and accounting entity may be collocated, and one accounting 184 entity may control several monitoring probes; in any event the 185 monitoring probe is controlled by an accounting entity. The 186 accounting entity transmits its accounting data to the actual 187 collector. The collector correlates accounting data relating to the 188 same event from different accounting entities and produces an 189 accounting record. There may be more than one collector depending on 190 the actual tasks. 192 +-----------------+ 193 | Collector | 194 | +-------------+ | 195 | | Acc. Record | | 196 | +-------------+ | 197 +-----------------+ 198 ^ ^ ^ ^ 199 **** * * **** 200 **** * * **** 201 **** * * **** 202 **** * * **** 203 +-----------+ +-----------+ +-----------+ +-----------+ 204 | +-----+| | +-----+| | +-----+| | +-----+| 205 ===>| AE | Acc.||===>| AE | Acc.||===>| AE | Acc.||===>| AE | Acc.||===> 206 | | Data|| | | Data|| | | Data|| | | Data|| 207 | +-----+| | +-----+| | +-----+| | +-----+| 208 +-----------+ | | +-----------+ +-----------+ 209 ^ ^ | | ^ 210 * * | | * 211 +----+ +----+ | | +-----+ 212 --->| MP | | MP |--->| MP |------>| MP |-----------------------> 213 +----+ +----+ +-----------+ +-----+ 215 +--+ 216 |AE| = Accounting === = Acc. Configuration --- = Data Flow 217 +--+ Entity Signaling Messages 219 +--+ 220 |MP| = Monitoring *** = other 221 +--+ Probe Signaling Messages 223 Figure 1: Schematic Accounting Architecture 225 In this context two problems need to be solved, such as 226 o measurement data needs to be transported from the monitoring 227 probes to the accounting entities. Accounting data needs to be 228 transported from the accounting entities to the collector. 229 [I-D.ietf-ipfix-protocol] is a protocol suitable for this task. 230 o The accounting entities need to be configured and coordinated. 231 This document suggests the usage of NSIS for this purpose. 233 In a flexible environment, it must be possible to dynamically 234 configure and coordinate accounting entities rather than hardwiring 235 them. Configuration and coordination includes e.g. what entities do 236 the accounting for a particular flow or session, providing triggers 237 to start or stop accounting, distribution of identifiers for the 238 collector, flows or user, and so forth. The IPFIX WG has identified 239 the needs for such configurations but has defined the work currently 240 as "out of the scope" [I-D.ietf-ipfix-reqs]. RADIUS and DIAMETER 241 allow for configuration of single accounting entities. Nevertheless 242 configuration and coordination of distributed accounting entities is 243 not supported. Since accounting entities usually are found along the 244 path of the data they are accounting, a path-coupled signaling 245 protocol for distributing such information seems useful. In Section 246 4 we discuss in more detail two possible applications for 247 configuration of accounting entities, namely QoS monitoring and 248 charging. 250 4. Scenarios 252 This section describes two scenarios for the usage of the Accounting 253 NSLP: Charging and QoS monitoring 255 4.1 Charging 257 While flexible usage-based charging today is mainly a problem in 258 mobile telecommunication networks such as 3GPP, it is expected to 259 also play an important role in other networks in the future. 261 As a prerequisite to charging, accounting entities along the data 262 path independently need to collect accounting data for the same 263 session. For example, when streaming a video from an application 264 server to a WLAN user, accounting may be performed independently by 265 the application server, the WLAN access point and ingress nodes of 266 several transit networks. When a handover occurs yet other, 267 initially unforeseen, accounting entities become involved. Yet, the 268 user would like to be presented a single bill in the end. Even more 269 difficult, the user may wish to know the total costs in advance. 270 This implies accounting data collected (or estimated) by the 271 different accounting entities needs to be correlated and aggregated 272 in order to avoid the user pays duplicate fees. Accounting entities 273 need to know to what collector they must send their accounting data. 274 A further problem of data correlation is the identification of 275 related records by the collector. 277 Existing accounting concepts are based on static configuration of 278 accounting entities [Ref 3GPP?]. Currently there exists no mechanism 279 to provide dynamic discovery of accounting entities with a unique 280 correlation identifier related to one service. 282 Figure 2 shows an example where a data receiver expects data from a 283 data sender via two routers Router 1 and Router 2. The 284 administrative domain (referred as Accounting Domain) is responsible 285 for configuring accounting functionality at Router 1, Router 2 and at 286 the application server (i.e., data sender). 288 +------------------------------------------+ 289 Data Receiver | Router 1 Router 2 Data Sender | 290 +-----------+ | +----+ +----+ +-----------+ | 291 |Application|<-----| |<-----| |<-----|Application| | 292 | +--+ | | |+--+| |+--+| | +--+ | | 293 | |AE| | | ||AE||<====>||AE||<====>| |AE| | | 294 | +--+ | | |+--+| |+--+| | +--+ | | 295 +-----------+ | +----+ +----+ +-----------+ | 296 | Accounting Domain | 297 +------------------------------------------+ 299 +--+ 300 |AE| = Accounting === = Signaling --- = Data Flow 301 +--+ Entity Messages 303 Figure 2: Signaling to configure accounting for later charging 305 Different configuration needs arise for different use cases. In the 306 case that a pure content charging scheme should be applied later, 307 only the content accessed is relevant for later charging. For this 308 case, only the AE at the Data Sender should be configured to register 309 the content accessed. All other AEs should be instructed to do 310 nothing since their accounting data will be discarded anyway. 312 In other cases, the situation can be different. For the case where a 313 mixed content and access charging should be applied, possibly due to 314 the need to account the expensive wireless access between the 315 receiver and Router 1, not only the content accessed but also the 316 data volume are relevant for later charging. For this case, the AE 317 at the Data Sender should be configured to register the content 318 accessed. And, the AE at R1 should be configured to register data 319 volume. All other AEs should do nothing. 321 4.2 QoS Monitoring 323 When a network can provide QoS to its users it is important to be 324 able to monitor whether the QoS provided matches the QoS initially 325 negotiated in the according service level agreement. Such monitoring 326 can be performed by monitoring probes and related accounting entities 327 on the data path. One possibility is installing and configuring 328 these probes once-and-for-all. It would, however, be more convenient 329 to be able to invoke the monitoring service on demand. Furthermore, 330 one may want to configure the accounting entities depending on the 331 current monitoring needs. 333 +-----------------------------------------------------------+ 334 | | 335 | Administrative Domain A | 336 | | 337 | Ingress Node A probe 1 probe 2 Egress Node B | 338 | +-----------+ +----+ +----+ +-----------+ | 339 | | |=====>| |=====>| |=====>| | | 340 | | | | | | | | | | 341 ---->| AE |----->| AE |----->| AE |----->| AE |----> 342 | | | | | | | | | | 343 | +-----------+ +----+ +----+ +-----------+ | 344 | | 345 +-----------------------------------------------------------+ 347 +--+ 348 |AE| = Accounting === = Signaling --- = Data Flow 349 +--+ Entity Messages 351 Figure 3: Signaling to configure accounting for QoS monitoring 353 For example, network domain A negotiates a SLA with a neighboring 354 domain, guaranteeing a particular QoS for all packets entering at 355 ingress node A and leaving at egress node B. When the QoS guarantees 356 are configured, e.g. with the QoS NSLP, one node on the data path, 357 e.g. the ingress node, initiates the configuration of accounting 358 entities on the data path. Accounting data is used for monitoring 359 whether the QoS negotiated in the SLA corresponds to the QoS 360 delivered. For example, the transmission delay of flows can be 361 measured at several places and the total delay across the domain can 362 then be determined. The collected information is of interest for 363 both domain A and the neighboring domain. 365 4.3 Configuration information common to both scenarios 367 The configuration of accounting entities described in Section 4.1 and 368 Section 4.2 would include, among other things, the distribution of 369 the following information: 370 o which accounting entries have to register usage data 371 o what type of data to collect (e.g. count packets, measure delay 372 etc.) 373 o data related to what flows to collect 374 o which usage data need to be transferred from accounting entities 375 to a collector (i.e., flow identifier) 376 o the identity of the collector to which usage data is to be 377 delivered 378 o a correlation ID which allows the collector to correlate the flow 379 data arriving from different accounting entities 381 o description of the trigger when to start and stop accounting 383 5. Requirements 385 This section describes the requirements for an efficient signaling of 386 configuration parameters to accounting entities. We assume an 387 existing protocol to transport the collection of accounting data 388 (a) between the monitoring probe and the accounting entity and 389 (b) between the accounting entity and a collector. 391 The IPFIX protocol [I-D.ietf-ipfix-protocol] has all the required 392 capabilities to fulfill the functionality required by (a). We also 393 assume that the monitoring probes and the accounting entities may be 394 collocated. 396 5.1 General requirements 398 5.1.1 Extensibility 400 The NSLP accounting specification should be extensible to future 401 technologies. This includes the extensibility of the configuration 402 of the accounting entities. 404 Extensibility is also required concerning the data model. This 405 relates to the parameter exchange between the accounting entities and 406 the interface between the accounting entities and the monitoring 407 probes and the collector, respectively. 409 5.1.2 Scalability 411 Multiple accounting entities may be included in the overall 412 accounting task. Also, they can be geographically widespread. The 413 configuration process must be able to efficiently support hundreds of 414 accounting entities and to address them individually. 416 5.1.3 Interoperability 418 A number of accounting solutions may be defined in future in the 419 IETF. Additionally, accounting solutions are specified by other 420 organizations, e.g. the 3GPP. The accounting NSLP should bridge 421 between these solutions. The communication between the Internet 422 accounting and monitoring and other accounting entities may be 423 organized using proxy or agent based systems. 425 5.1.4 Security 427 Besides the discussion of the security considerations at the end of 428 this document, it should be clarified that the process of configuring 429 an Internet-wide accounting system is a very sensitive task. 430 Therefore, arrangements should be taken to secure this process. It 431 has to be noticed that this configuration step can pass domain 432 borders as well as technology borders. 434 5.2 Flexible accounting model 436 The accounting NSLP should support a flexible accounting model. 437 Depending on the accounting scenario, different information must be 438 exchanged between the accounting entities. For example, if the 439 accounting is used for charging purposes, pricing information might 440 be required at each accounting entity in order to verify account 441 balances etc. Therefore, the accounting model should be separated 442 from the configuration process and the associated protocols. 444 5.3 Distinguishing flows 446 A primary capability of the accounting function is the identification 447 of data packets belonging to different applications or users. The 448 configuration of the accounting entities should take this parameter 449 into account. During the service life-time, statistics describing 450 the resource consumptions of this service are gathered and exported 451 to a collector. The accounting configuration should be flexible to 452 allow the description of multiple services and associated flows 453 (scalability). 455 Flows belonging to one application - the accounting configuration 456 should allow the aggregation of accounting information for streams 457 belonging to a particular application, e.g. a multimedia 458 transmission with associated data transfers (web pages). 460 Flows belonging to one user - the accounting configuration should 461 allow the aggregation of accounting data for all streams belonging to 462 an individual user regardless of the used applications. 464 5.4 Flexible data collection 466 After the gathering of accounting data, it has to be transferred to a 467 collector. We propose to employ the IPFIX protocol 468 [I-D.ietf-ipfix-protocol] for this task. The IPFIX information model 469 [I-D.ietf-ipfix-info] is very flexible for such application. 471 Depending on the accounting scenario, a single collector can be 472 responsible for collecting and processing all accounting information. 473 Nevertheless, there are scenarios where multiple collectors have to 474 be employed. 476 5.5 Location of accounting entities 478 The accounting entities are located on the data path, i.e., on the 479 path of the data that should be accounted. The configuration of 480 accounting entities can be initiated anywhere on this path. It is an 481 open problem how the initiator and receiver of the accounting 482 configuration signaling are determined. 484 Accounting entities can be located anywhere along the data path, 485 e.g., only in a subset of the path, or only at start and end point 486 etc. 488 5.6 Location of the collector 490 The collector MAY be located on the data path. In this case, the 491 collector SHOULD use the accounting NSLP to inform all involved 492 accounting entities about its location. 494 The collector MAY be shifted during the accounting process. The 495 handover process is not part of this document. The identification of 496 the new collector SHOULD be done using the same mechanisms as for the 497 first identification. 499 5.7 Configuration protocol 501 5.7.1 Configuration of accounting entities 503 The protocol MUST be able to configure accounting entities, e.g. to 504 control which information needs to be collected and which entities 505 are allocated which task. 507 Protocol messages need to be interpreted only by accounting entities. 509 5.7.2 Selection of accounting entities 511 The protocol should provide functionality to select accounting 512 entities that that become part of an accounting process by specifying 513 e.g. their type or total number. 515 5.7.3 Accounting Configuration State installation and removal 517 The protocol MUST be able to install accounting state and also to 518 remove it. Furthermore, accounting state SHOULD be soft state in 519 order to cope with rerouting and device failure. 521 5.7.4 Initiation and maintenance of accounting tasks 523 The protocol MUST be able to transport a trigger to start and stop of 524 collection of accounting data, a correlation identifier that allows 525 the collector to correlate accounting data received from different 526 accounting entities, and a trigger to send off accounting data to the 527 collector. 529 The triggering source of the initiation is out of scope of this 530 document. 532 The protocol MUST be able to react to rerouting of the packets that 533 are to be accounted. This may imply including new accounting 534 entities and removing some. 536 5.7.5 Collection of information on available accounting entities 538 The protocol SHOULD be able to collect information on accounting 539 entities and their capabilities without actually installing any 540 state. 542 5.8 Accounting across domains 544 Accounting configuration MUST be possible across administrative 545 domains. There are challenging security aspects in this goal. 547 6. Applicability of NSIS 549 According to the NSIS framework [I-D.ietf-nsis-fw], the NSIS protocol 550 suite can support various signaling applications that need to install 551 or manipulate state in NSIS-aware network nodes (NEs) along the path 552 of a data flow. Thereby, not every network node has to be NSIS 553 aware. The signaling protocol messages however do not need to run 554 all the way between the data flow endpoints. Rather, the NSIS 555 initiating NE and the NSIS receiving NE can be located anywhere along 556 the data path. The NSIS protocol suite has two layers. The lower 557 transport layer, NTLP, is responsible for transporting NSIS messages 558 and is used by all NSIS signaling application. The NSIS signaling 559 applications are located in the upper layer and are called NSLPs. 560 Examples of NSLPs that are currently being specified are QoS NSLP 561 [I-D.ietf-nsis-qos-nslp] for signaling QoS reservations and the NAT / 562 Firewall NSLP [I-D.ietf-nsis-nat-nslp] for configuring Network 563 Address Translaters and firewalls along the data path. 565 The problem of signaling to configure accounting entities seems to be 566 well suited to be solved with a novel NSIS signaling application, the 567 Accounting NSLP. A similar idea was first reported in 568 [I-D.courturier-nsis-sqm]. The Accounting NSLP needs to be able to 569 install, modify and remove accounting configuration related state. 570 As illustrated in previous sections, accounting entities - which are 571 to become Accounting NSLP Entities - are naturally located on the 572 data path where accounting has to be performed. Furthermore, 573 signaling for accounting configuration needs the flexibility provided 574 by NSIS to commence and end on arbitrary accounting entities. Any 575 accounting entity on the data path has to be able to initiate 576 accounting configuration signaling. The selection of signaling 577 initiator and receiver depends on the configuration and on the 578 specific application environment. An Accounting NSLP, similar to QoS 579 NSLP, would be agnostic of the actual configuration information it 580 carries. Hence it can be used for any accounting application, such 581 as QoS monitoring and charging. In fact, it currently seems that 582 some of the QoS NSLP message structure (RESERVE (i.e. CONFIGURE), 583 RESPONSE, QUERY and NOTIFY) could be reused. 585 Possible interworking between the Accounting NSLP and the QoS NSLP 586 needs to be investigated. In some cases it seems to make sense that 587 a reservation of resources via the QoS NSLP would trigger the 588 configuration and initiation of accounting for usage of these 589 resources. Furthermore, accounting can be terminated as soon as the 590 QoS reservation is torn down. 592 7. Security considerations 594 The process of configuring entities to start and stop accounting and 595 to transmit collected resource records to a third party introduces 596 security challenges. 598 First, the application domain needs to be considered. If a malicous 599 user is capable of stop accounting of requested services then fraud 600 is possible. It must not be possible to configure accounting 601 entities in such a way that other users are charged for the usage of 602 a service which they have not used. 604 Second, interworking between multiple domains causes authorization 605 problems. For example, network domain A might want to collect 606 resource records in network domain B to offer the user with a more 607 consistent bill covering both the price of the network resource 608 consumption and the application usage. A high degree of trust is 609 required to allow other domains to configure accounting entities and 610 to collect the resource usage of particular users. In any case it 611 needs to be prevented that arbitrary resource records associated with 612 users are collected by other domains. It has to be noted that the 613 process of charging involves other states than only the collection of 614 usage records. 616 Third, it must be avoided that a denial of service attack is mounted 617 on either Collectors or Accounting Entities. Accounting Entities can 618 be subject to DoS attacks if a large number of resource have to be 619 collected or 'unlimited' per-flow states are created. Collectors can 620 be subject to DoS attacks if they are flooded with accounting 621 records. 623 The introduced mechanisms allow a number of entities to configure 624 accounting entities. This might introduce some weaknesses compared 625 to a centralized approach where a single entity (or a few selected 626 entities) are authorized to perform this action. The authorization 627 configuration of a decentralized approach is more difficult to secure 628 since a single malicious entity is able to start/stop/modify the 629 process of accounting record collection within a single domain or 630 even beyond this domain. 632 8. References 634 8.1 Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", March 1997. 639 8.2 Informative References 641 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 642 June 1999. 644 [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 645 October 1999. 647 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 648 "Remote Authentication Dial In User Service (RADIUS)", RFC 649 2865, June 2000. 651 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 653 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 654 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 656 [I-D.ietf-ipfix-protocol] 657 Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX 658 Protocol Specifications", draft-ietf-ipfix-protocol-03 659 (work in progress), January 2004. 661 [I-D.ietf-ipfix-info] 662 Calato, P., Meyer, J. and J. Quittek, "Information Model 663 for IP Flow Information Export", draft-ietf-ipfix-info-03 664 (work in progress), February 2004. 666 [I-D.ietf-ipfix-reqs] 667 Quittek, J., Zseby, T., Claise, B. and S. Zander, 668 "Requirements for IP Flow Information Export", 669 draft-ietf-ipfix-reqs-16 (work in progress), June 2004. 671 [I-D.ietf-nsis-qos-nslp] 672 Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP 673 for Quality-of-Service signaling", 674 draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004. 676 [I-D.ietf-nsis-fw] 677 Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J. 678 and S. Van den Bosch, "Next Steps in Signaling: 679 Framework", draft-ietf-nsis-fw-05 (work in progress), 680 October 2003. 682 [I-D.ietf-nsis-nat-nslp] 683 Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, 684 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 685 draft-ietf-nsis-nslp-natfw-02 (work in progress), May 686 2004. 688 [I-D.courturier-nsis-sqm] 689 Courturier, A., "Signaling for QoS Measurement", 690 draft-courturier-nsis-measure-00 (work in progress), May 691 2003. 693 [I-D.ietf-aaa-diameter-cc] 694 Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. 695 Hakala, "Diameter Credit-control Application", 696 draft-ietf-aaa-diameter-cc-05 (work in progress), May 697 2004. 699 [I-D.draft-lior-radius-prepaid-extensions-03] 700 Lior, A., Yegani, P., Chowdhury, K., Madour, L. and Y. Li, 701 "PrePaid Extensions to Remote Authentication Dial-In User 702 Service (RADIUS)", draft-lior-radius-prepaid-extensions-03 703 (work in progress), February 2004. 705 [TS32.240] 706 3GPP, "Charging Architecture and Principles", 3GPP 707 Technical Specification TS32.240, December 2003. 709 Authors' Addresses 711 Falko Dressler 712 University of Tuebingen 713 Wilhelm-Schickard-Institute for Computer Science 714 Auf der Morgenstelle 10C 715 Tuebingen 71076 716 Germany 718 Phone: +49 7071 29-70522 719 EMail: dressler@informatik.uni-tuebingen.de 720 URI: http://net.informatik.uni-tuebingen.de/ 722 Georg Carle 723 University of Tuebingen 724 Wilhelm-Schickard-Institute for Computer Science 725 Auf der Morgenstelle 10C 726 Tuebingen 71076 727 Germany 729 Phone: +49 7071 29-70505 730 EMail: carle@informatik.uni-tuebingen.de 731 URI: http://net.informatik.uni-tuebingen.de/ 733 Changpeng Fan 734 Siemens AG 735 Siemensdamm 62 736 Berlin 13627 737 Germany 739 Phone: +49 30 386-36361 740 EMail: changpeng.fan@siemens.com 742 Cornelia Kappler 743 Siemens AG 744 Siemensdamm 62 745 Berlin 13627 746 Germany 748 Phone: +49 30 386-32894 749 EMail: cornelia.kappler@siemens.com 750 Hannes Tschofenig 751 Siemens AG 752 Otto-Hahn-Ring 6 753 Munich, Bayern 81739 754 Germany 756 EMail: Hannes.Tschofenig@siemens.com 758 Intellectual Property Statement 760 The IETF takes no position regarding the validity or scope of any 761 Intellectual Property Rights or other rights that might be claimed to 762 pertain to the implementation or use of the technology described in 763 this document or the extent to which any license under such rights 764 might or might not be available; nor does it represent that it has 765 made any independent effort to identify any such rights. Information 766 on the procedures with respect to rights in RFC documents can be 767 found in BCP 78 and BCP 79. 769 Copies of IPR disclosures made to the IETF Secretariat and any 770 assurances of licenses to be made available, or the result of an 771 attempt made to obtain a general license or permission for the use of 772 such proprietary rights by implementers or users of this 773 specification can be obtained from the IETF on-line IPR repository at 774 http://www.ietf.org/ipr. 776 The IETF invites any interested party to bring to its attention any 777 copyrights, patents or patent applications, or other proprietary 778 rights that may cover technology that may be required to implement 779 this standard. Please address the information to the IETF at 780 ietf-ipr@ietf.org. 782 Disclaimer of Validity 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 787 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 788 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 789 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Copyright Statement 794 Copyright (C) The Internet Society (2004). This document is subject 795 to the rights, licenses and restrictions contained in BCP 78, and 796 except as set forth therein, the authors retain all their rights. 798 Acknowledgment 800 Funding for the RFC Editor function is currently provided by the 801 Internet Society.