[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        F. Dressler
Internet-Draft                                                  G. Carle
Expires: January 9, 2005                         University of Tuebingen
                                                                  C. Fan
                                                              C. Kappler
                                                           H. Tschofenig
                                                              Siemens AG
                                                           July 11, 2004

              NSLP for Accounting Configuration Signaling

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 9, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   Monitoring, metering and accounting of packets are increasingly
   important functionality that needs to be provided in the Internet.
   This document proposes the definition of a new NSIS NSLP which allows
   the dynamic configuration of accounting entities on the data path.  A
   problem statement, scenarios for a QoS monitoring and a charging

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 1]

Internet-Draft              Accounting NSLP                    July 2004

   application, and requirements presented.  Finally, the usage of NSIS
   for this purpose is motivated.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4

   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1   Charging . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2   QoS Monitoring . . . . . . . . . . . . . . . . . . . . . .  7
     4.3   Configuration information common to both scenarios . . . .  8

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1   General requirements . . . . . . . . . . . . . . . . . . .  9
       5.1.1   Extensibility  . . . . . . . . . . . . . . . . . . . .  9
       5.1.2   Scalability  . . . . . . . . . . . . . . . . . . . . .  9
       5.1.3   Interoperability . . . . . . . . . . . . . . . . . . .  9
       5.1.4   Security . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2   Flexible accounting model  . . . . . . . . . . . . . . . . 10
     5.3   Distinguishing flows . . . . . . . . . . . . . . . . . . . 10
     5.4   Flexible data collection . . . . . . . . . . . . . . . . . 10
     5.5   Location of accounting entities  . . . . . . . . . . . . . 11
     5.6   Location of the collector  . . . . . . . . . . . . . . . . 11
     5.7   Configuration protocol . . . . . . . . . . . . . . . . . . 11
       5.7.1   Configuration of accounting entities . . . . . . . . . 11
       5.7.2   Selection of accounting entities . . . . . . . . . . . 11
       5.7.3   Accounting Configuration State installation and
               removal  . . . . . . . . . . . . . . . . . . . . . . . 11
       5.7.4   Initiation and maintenance of accounting tasks . . . . 11
       5.7.5   Collection of information on available accounting
               entities . . . . . . . . . . . . . . . . . . . . . . . 12
     5.8   Accounting across domains  . . . . . . . . . . . . . . . . 12

   6.  Applicability of NSIS  . . . . . . . . . . . . . . . . . . . . 12

   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 13

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 14
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 14

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16

       Intellectual Property and Copyright Statements . . . . . . . . 18

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 2]

Internet-Draft              Accounting NSLP                    July 2004

1.  Introduction

   Monitoring, metering and accounting of packets is an important
   functionality in many networks today.  Several working groups have
   described mechanisms to collect and report usage data for resource
   consumption in a network by a particular entity.  For example, the
   IPFIX WG defines a protocol to collect such data.  RADIUS (see
   [RFC2865], [RFC2866] and
   [I-D.draft-lior-radius-prepaid-extensions-03]) and DIAMETER (see
   [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols which
   provide information about consumed resources via accounting records.
   The Meter MIB [RFC2720] is a MIB for collecting flow information.
   However, it is also necessary to configure and coordinate the
   entities doing the accounting.  In more complex network topologies
   and architectures these entities are not only located at the edges of
   a network.  Instead, these accounting entities are distributed along
   the data path.  While it is possible to configure these entities with
   protocols such as RADIUS or DIAMETER (or SNMP for the Meter MIB), it
   is also cumbersome.

   This draft introduces a new NSLP the Accounting NSLP for
   configuration and coordination of accounting entities in a
   path-coupled fashion.

   This draft is organized as follows: We give a problem description in
   Section 3, and then illustrate it with a number of scenarios in
   Section 4.  Subsequently, we list a few requirements in Section 5.
   Finally, we discuss the suitability of NSIS for the configuration of
   accounting entities in Section 6.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   Furthermore, this document uses the following terms:

   Accounting Data

      Accounting data describe utilized resources concerning a
      particular flow or service for a later charging process.  Examples
      for such data are packet counter, timers, and information
      describing the end user or system.

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 3]

Internet-Draft              Accounting NSLP                    July 2004

   Accounting Record

      An accounting record represents aggregated and/or correlated
      accounting data.

   Monitoring Probe

      A monitoring probe is an entity that examines the data flow in
      order to gather accounting data.  This accounting data is exported
      to an accounting entity.

   Accounting entity

      An accounting entity produces accounting data describing the
      resource utilization of a particular flow or service.  Typically,
      this information is collected from accociated monitoring probes.


      A collector receives accounting data from one or multiple
      accounting entities.  This accounting data is aggregated,
      correlated, and stored in form of accounting records.

3.  Problem Statement

   There is a need in industry and the Internet research community to
   collect and export information on data flows.  We call such
   information accounting records.  Accounting records are useful in
   mediation systems, accounting systems, and network management systems
   to facilitate services such as Internet research, measurement,
   accounting, billing, QoS monitoring, intrusion detection, and traffic
   profiling/engineering.  In recognition of the need for such
   accounting the IPFIX WG was founded.

   While the purpose for collecting accounting records in each case is
   different, the basic architecture of such accounting systems is
   usually identical, cf.  Figure 1.  Measurement data is collected by a
   monitoring probe, and from there transported to an accounting entity.
   The accounting entity produces accounting data from the measurement
   data or additional data such as session information.  Monitoring
   probe and accounting entity may be collocated, and one accounting
   entity may control several monitoring probes; in any event the
   monitoring probe is controlled by an accounting entity.  The
   accounting entity transmits its accounting data to the actual
   collector.  The collector correlates accounting data relating to the
   same event from different accounting entities and produces an
   accounting record.  There may be more than one collector depending on

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 4]

Internet-Draft              Accounting NSLP                    July 2004

   the actual tasks.

                             | Collector       |
                             | +-------------+ |
                             | | Acc. Record | |
                             | +-------------+ |
                                   ^ ^ ^ ^
                            ****    *   *    ****
                       ****       *       *       ****
                  ****          *           *          ****
             ****             *               *             ****
       +-----------+    +-----------+    +-----------+    +-----------+
       |    +-----+|    |    +-----+|    |    +-----+|    |    +-----+|
   ===>| AE | Acc.||===>| AE | Acc.||===>| AE | Acc.||===>| AE | Acc.||===>
       |    | Data||    |    | Data||    |    | Data||    |    | Data||
       |    +-----+|    |    +-----+|    |    +-----+|    |    +-----+|
       +-----------+    |           |    +-----------+    +-----------+
          ^    ^        |           |          ^
          *    *        |           |          *
       +----+ +----+    |           |       +-----+
   --->| MP | | MP |--->| MP        |------>| MP  |----------------------->
       +----+ +----+    +-----------+       +-----+

       |AE| = Accounting   === = Acc. Configuration   --- = Data Flow
       +--+   Entity             Signaling Messages

       |MP| = Monitoring   *** = other
       +--+   Probe              Signaling Messages

              Figure 1: Schematic Accounting Architecture

   In this context two problems need to be solved, such as
   o  measurement data needs to be transported from the monitoring
      probes to the accounting entities.  Accounting data needs to be
      transported from the accounting entities to the collector.
      [I-D.ietf-ipfix-protocol] is a protocol suitable for this task.
   o  The accounting entities need to be configured and coordinated.
      This document suggests the usage of NSIS for this purpose.

   In a flexible environment, it must be possible to dynamically
   configure and coordinate accounting entities rather than hardwiring
   them.  Configuration and coordination includes e.g.  what entities do
   the accounting for a particular flow or session, providing triggers

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 5]

Internet-Draft              Accounting NSLP                    July 2004

   to start or stop accounting, distribution of identifiers for the
   collector, flows or user, and so forth.  The IPFIX WG has identified
   the needs for such configurations but has defined the work currently
   as "out of the scope" [I-D.ietf-ipfix-reqs].  RADIUS and DIAMETER
   allow for configuration of single accounting entities.  Nevertheless
   configuration and coordination of distributed accounting entities is
   not supported.  Since accounting entities usually are found along the
   path of the data they are accounting, a path-coupled signaling
   protocol for distributing such information seems useful.  In Section
   4 we discuss in more detail two possible applications for
   configuration of accounting entities, namely QoS monitoring and

4.  Scenarios

   This section describes two scenarios for the usage of the Accounting
   NSLP: Charging and QoS monitoring

4.1  Charging

   While flexible usage-based charging today is mainly a problem in
   mobile telecommunication networks such as 3GPP, it is expected to
   also play an important role in other networks in the future.

   As a prerequisite to charging, accounting entities along the data
   path independently need to collect accounting data for the same
   session.  For example, when streaming a video from an application
   server to a WLAN user, accounting may be performed independently by
   the application server, the WLAN access point and ingress nodes of
   several transit networks.  When a handover occurs yet other,
   initially unforeseen, accounting entities become involved.  Yet, the
   user would like to be presented a single bill in the end.  Even more
   difficult, the user may wish to know the total costs in advance.
   This implies accounting data collected (or estimated) by the
   different accounting entities needs to be correlated and aggregated
   in order to avoid the user pays duplicate fees.  Accounting entities
   need to know to what collector they must send their accounting data.
   A further problem of data correlation is the identification of
   related records by the collector.

   Existing accounting concepts are based on static configuration of
   accounting entities [Ref 3GPP?].  Currently there exists no mechanism
   to provide dynamic discovery of accounting entities with a unique
   correlation identifier related to one service.

   Figure 2 shows an example where a data receiver expects data from a
   data sender via two routers Router 1 and Router 2.  The
   administrative domain (referred as Accounting Domain) is responsible

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 6]

Internet-Draft              Accounting NSLP                    July 2004

   for configuring accounting functionality at Router 1, Router 2 and at
   the application server (i.e., data sender).

   Data Receiver   | Router 1    Router 2      Data Sender    |
   +-----------+   |  +----+      +----+      +-----------+   |
   |Application|<-----|    |<-----|    |<-----|Application|   |
   |   +--+    |   |  |+--+|      |+--+|      |   +--+    |   |
   |   |AE|    |   |  ||AE||<====>||AE||<====>|   |AE|    |   |
   |   +--+    |   |  |+--+|      |+--+|      |   +--+    |   |
   +-----------+   |  +----+      +----+      +-----------+   |
                   |            Accounting Domain             |

       |AE| = Accounting   === = Signaling    --- = Data Flow
       +--+   Entity             Messages

     Figure 2: Signaling to configure accounting for later charging

   Different configuration needs arise for different use cases.  In the
   case that a pure content charging scheme should be applied later,
   only the content accessed is relevant for later charging.  For this
   case, only the AE at the Data Sender should be configured to register
   the content accessed.  All other AEs should be instructed to do
   nothing since their accounting data will be discarded anyway.

   In other cases, the situation can be different.  For the case where a
   mixed content and access charging should be applied, possibly due to
   the need to account the expensive wireless access between the
   receiver and Router 1, not only the content accessed but also the
   data volume are relevant for later charging.  For this case, the AE
   at the Data Sender should be configured to register the content
   accessed.  And, the AE at R1 should be configured to register data
   volume.  All other AEs should do nothing.

4.2  QoS Monitoring

   When a network can provide QoS to its users it is important to be
   able to monitor whether the QoS provided matches the QoS initially
   negotiated in the according service level agreement.  Such monitoring
   can be performed by monitoring probes and related accounting entities
   on the data path.  One possibility is installing and configuring
   these probes once-and-for-all.  It would, however, be more convenient
   to be able to invoke the monitoring service on demand.  Furthermore,
   one may want to configure the accounting entities depending on the
   current monitoring needs.

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 7]

Internet-Draft              Accounting NSLP                    July 2004

       |                                                           |
       |                 Administrative Domain A                   |
       |                                                           |
       |  Ingress Node A    probe 1     probe 2      Egress Node B |
       | +-----------+      +----+      +----+      +-----------+  |
       | |           |=====>|    |=====>|    |=====>|           |  |
       | |           |      |    |      |    |      |           |  |
    ---->|   AE      |----->| AE |----->| AE |----->|    AE     |---->
       | |           |      |    |      |    |      |           |  |
       | +-----------+      +----+      +----+      +-----------+  |
       |                                                           |

       |AE| = Accounting   === = Signaling    --- = Data Flow
       +--+   Entity             Messages

     Figure 3: Signaling to configure accounting for QoS monitoring

   For example, network domain A negotiates a SLA with a neighboring
   domain, guaranteeing a particular QoS for all packets entering at
   ingress node A and leaving at egress node B.  When the QoS guarantees
   are configured, e.g.  with the QoS NSLP, one node on the data path,
   e.g.  the ingress node, initiates the configuration of accounting
   entities on the data path.  Accounting data is used for monitoring
   whether the QoS negotiated in the SLA corresponds to the QoS
   delivered.  For example, the transmission delay of flows can be
   measured at several places and the total delay across the domain can
   then be determined.  The collected information is of interest for
   both domain A and the neighboring domain.

4.3  Configuration information common to both scenarios

   The configuration of accounting entities described in Section 4.1 and
   Section 4.2 would include, among other things, the distribution of
   the following information:
   o  which accounting entries have to register usage data
   o  what type of data to collect (e.g.  count packets, measure delay
   o  data related to what flows to collect
   o  which usage data need to be transferred from accounting entities
      to a collector (i.e., flow identifier)
   o  the identity of the collector to which usage data is to be
   o  a correlation ID which allows the collector to correlate the flow
      data arriving from different accounting entities

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 8]

Internet-Draft              Accounting NSLP                    July 2004

   o  description of the trigger when to start and stop accounting

5.  Requirements

   This section describes the requirements for an efficient signaling of
   configuration parameters to accounting entities.  We assume an
   existing protocol to transport the collection of accounting data
      (a) between the monitoring probe and the accounting entity and
      (b) between the accounting entity and a collector.

   The IPFIX protocol [I-D.ietf-ipfix-protocol] has all the required
   capabilities to fulfill the functionality required by (a).  We also
   assume that the monitoring probes and the accounting entities may be

5.1  General requirements

5.1.1  Extensibility

   The NSLP accounting specification should be extensible to future
   technologies.  This includes the extensibility of the configuration
   of the accounting entities.

   Extensibility is also required concerning the data model.  This
   relates to the parameter exchange between the accounting entities and
   the interface between the accounting entities and the monitoring
   probes and the collector, respectively.

5.1.2  Scalability

   Multiple accounting entities may be included in the overall
   accounting task.  Also, they can be geographically widespread.  The
   configuration process must be able to efficiently support hundreds of
   accounting entities and to address them individually.

5.1.3  Interoperability

   A number of accounting solutions may be defined in future in the
   IETF.  Additionally, accounting solutions are specified by other
   organizations, e.g.  the 3GPP.  The accounting NSLP should bridge
   between these solutions.  The communication between the Internet
   accounting and monitoring and other accounting entities may be
   organized using proxy or agent based systems.

5.1.4  Security

   Besides the discussion of the security considerations at the end of
   this document, it should be clarified that the process of configuring

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 9]

Internet-Draft              Accounting NSLP                    July 2004

   an Internet-wide accounting system is a very sensitive task.
   Therefore, arrangements should be taken to secure this process.  It
   has to be noticed that this configuration step can pass domain
   borders as well as technology borders.

5.2  Flexible accounting model

   The accounting NSLP should support a flexible accounting model.
   Depending on the accounting scenario, different information must be
   exchanged between the accounting entities.  For example, if the
   accounting is used for charging purposes, pricing information might
   be required at each accounting entity in order to verify account
   balances etc.  Therefore, the accounting model should be separated
   from the configuration process and the associated protocols.

5.3  Distinguishing flows

   A primary capability of the accounting function is the identification
   of data packets belonging to different applications or users.  The
   configuration of the accounting entities should take this parameter
   into account.  During the service life-time, statistics describing
   the resource consumptions of this service are gathered and exported
   to a collector.  The accounting configuration should be flexible to
   allow the description of multiple services and associated flows

   Flows belonging to one application - the accounting configuration
   should allow the aggregation of accounting information for streams
   belonging to a particular application, e.g.  a multimedia
   transmission with associated data transfers (web pages).

   Flows belonging to one user - the accounting configuration should
   allow the aggregation of accounting data for all streams belonging to
   an individual user regardless of the used applications.

5.4  Flexible data collection

   After the gathering of accounting data, it has to be transferred to a
   collector.  We propose to employ the IPFIX protocol
   [I-D.ietf-ipfix-protocol] for this task.  The IPFIX information model
   [I-D.ietf-ipfix-info] is very flexible for such application.

   Depending on the accounting scenario, a single collector can be
   responsible for collecting and processing all accounting information.
   Nevertheless, there are scenarios where multiple collectors have to
   be employed.

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 10]

Internet-Draft              Accounting NSLP                    July 2004

5.5  Location of accounting entities

   The accounting entities are located on the data path, i.e., on the
   path of the data that should be accounted.  The configuration of
   accounting entities can be initiated anywhere on this path.  It is an
   open problem how the initiator and receiver of the accounting
   configuration signaling are determined.

   Accounting entities can be located anywhere along the data path,
   e.g., only in a subset of the path, or only at start and end point

5.6  Location of the collector

   The collector MAY be located on the data path.  In this case, the
   collector SHOULD use the accounting NSLP to inform all involved
   accounting entities about its location.

   The collector MAY be shifted during the accounting process.  The
   handover process is not part of this document.  The identification of
   the new collector SHOULD be done using the same mechanisms as for the
   first identification.

5.7  Configuration protocol

5.7.1  Configuration of accounting entities

   The protocol MUST be able to configure accounting entities, e.g.  to
   control which information needs to be collected and which entities
   are allocated which task.

   Protocol messages need to be interpreted only by accounting entities.

5.7.2  Selection of accounting entities

   The protocol should provide functionality to select accounting
   entities that that become part of an accounting process by specifying
   e.g.  their type or total number.

5.7.3  Accounting Configuration State installation and removal

   The protocol MUST be able to install accounting state and also to
   remove it.  Furthermore, accounting state SHOULD be soft state in
   order to cope with rerouting and device failure.

5.7.4  Initiation and maintenance of accounting tasks

   The protocol MUST be able to transport a trigger to start and stop of

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 11]

Internet-Draft              Accounting NSLP                    July 2004

   collection of accounting data, a correlation identifier that allows
   the collector to correlate accounting data received from different
   accounting entities, and a trigger to send off accounting data to the

   The triggering source of the initiation is out of scope of this

   The protocol MUST be able to react to rerouting of the packets that
   are to be accounted.  This may imply including new accounting
   entities and removing some.

5.7.5  Collection of information on available accounting entities

   The protocol SHOULD be able to collect information on accounting
   entities and their capabilities without actually installing any

5.8  Accounting across domains

   Accounting configuration MUST be possible across administrative
   domains.  There are challenging security aspects in this goal.

6.  Applicability of NSIS

   According to the NSIS framework [I-D.ietf-nsis-fw], the NSIS protocol
   suite can support various signaling applications that need to install
   or manipulate state in NSIS-aware network nodes (NEs) along the path
   of a data flow.  Thereby, not every network node has to be NSIS
   aware.  The signaling protocol messages however do not need to run
   all the way between the data flow endpoints.  Rather, the NSIS
   initiating NE and the NSIS receiving NE can be located anywhere along
   the data path.  The NSIS protocol suite has two layers.  The lower
   transport layer, NTLP, is responsible for transporting NSIS messages
   and is used by all NSIS signaling application.  The NSIS signaling
   applications are located in the upper layer and are called NSLPs.
   Examples of NSLPs that are currently being specified are QoS NSLP
   [I-D.ietf-nsis-qos-nslp] for signaling QoS reservations and the NAT /
   Firewall NSLP [I-D.ietf-nsis-nat-nslp] for configuring Network
   Address Translaters and firewalls along the data path.

   The problem of signaling to configure accounting entities seems to be
   well suited to be solved with a novel NSIS signaling application, the
   Accounting NSLP.  A similar idea was first reported in
   [I-D.courturier-nsis-sqm].  The Accounting NSLP needs to be able to
   install, modify and remove accounting configuration related state.
   As illustrated in previous sections, accounting entities - which are
   to become Accounting NSLP Entities - are naturally located on the

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 12]

Internet-Draft              Accounting NSLP                    July 2004

   data path where accounting has to be performed.  Furthermore,
   signaling for accounting configuration needs the flexibility provided
   by NSIS to commence and end on arbitrary accounting entities.  Any
   accounting entity on the data path has to be able to initiate
   accounting configuration signaling.  The selection of signaling
   initiator and receiver depends on the configuration and on the
   specific application environment.  An Accounting NSLP, similar to QoS
   NSLP, would be agnostic of the actual configuration information it
   carries.  Hence it can be used for any accounting application, such
   as QoS monitoring and charging.  In fact, it currently seems that
   some of the QoS NSLP message structure (RESERVE (i.e.  CONFIGURE),
   RESPONSE, QUERY and NOTIFY) could be reused.

   Possible interworking between the Accounting NSLP and the QoS NSLP
   needs to be investigated.  In some cases it seems to make sense that
   a reservation of resources via the QoS NSLP would trigger the
   configuration and initiation of accounting for usage of these
   resources.  Furthermore, accounting can be terminated as soon as the
   QoS reservation is torn down.

7.  Security considerations

   The process of configuring entities to start and stop accounting and
   to transmit collected resource records to a third party introduces
   security challenges.

   First, the application domain needs to be considered.  If a malicous
   user is capable of stop accounting of requested services then fraud
   is possible.  It must not be possible to configure accounting
   entities in such a way that other users are charged for the usage of
   a service which they have not used.

   Second, interworking between multiple domains causes authorization
   problems.  For example, network domain A might want to collect
   resource records in network domain B to offer the user with a more
   consistent bill covering both the price of the network resource
   consumption and the application usage.  A high degree of trust is
   required to allow other domains to configure accounting entities and
   to collect the resource usage of particular users.  In any case it
   needs to be prevented that arbitrary resource records associated with
   users are collected by other domains.  It has to be noted that the
   process of charging involves other states than only the collection of
   usage records.

   Third, it must be avoided that a denial of service attack is mounted
   on either Collectors or Accounting Entities.  Accounting Entities can
   be subject to DoS attacks if a large number of resource have to be
   collected or 'unlimited' per-flow states are created.  Collectors can

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 13]

Internet-Draft              Accounting NSLP                    July 2004

   be subject to DoS attacks if they are flooded with accounting

   The introduced mechanisms allow a number of entities to configure
   accounting entities.  This might introduce some weaknesses compared
   to a centralized approach where a single entity (or a few selected
   entities) are authorized to perform this action.  The authorization
   configuration of a decentralized approach is more difficult to secure
   since a single malicious entity is able to start/stop/modify the
   process of accounting record collection within a single domain or
   even beyond this domain.

8.  References

8.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

8.2  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2720]  Brownlee, N., "Traffic Flow Measurement: Meter MIB",
              October 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

              Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX
              Protocol Specifications", draft-ietf-ipfix-protocol-03
              (work in progress), January 2004.

              Calato, P., Meyer, J. and J. Quittek, "Information Model
              for IP Flow Information Export", draft-ietf-ipfix-info-03
              (work in progress), February 2004.

              Quittek, J., Zseby, T., Claise, B. and S. Zander,

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 14]

Internet-Draft              Accounting NSLP                    July 2004

              "Requirements for IP Flow Information Export",
              draft-ietf-ipfix-reqs-16 (work in progress), June 2004.

              Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP
              for Quality-of-Service signaling",
              draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004.

              Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.
              and S. Van den Bosch, "Next Steps in Signaling:
              Framework", draft-ietf-nsis-fw-05 (work in progress),
              October 2003.

              Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun,
              "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
              draft-ietf-nsis-nslp-natfw-02 (work in progress), May

              Courturier, A., "Signaling for QoS Measurement",
              draft-courturier-nsis-measure-00 (work in progress), May

              Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.
              Hakala, "Diameter Credit-control Application",
              draft-ietf-aaa-diameter-cc-05 (work in progress), May

              Lior, A., Yegani, P., Chowdhury, K., Madour, L. and Y. Li,
              "PrePaid Extensions to Remote Authentication Dial-In User
              Service (RADIUS)", draft-lior-radius-prepaid-extensions-03
              (work in progress), February 2004.

              3GPP, "Charging Architecture and Principles", 3GPP
              Technical Specification TS32.240, December 2003.

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 15]

Internet-Draft              Accounting NSLP                    July 2004

Authors' Addresses

   Falko Dressler
   University of Tuebingen
   Wilhelm-Schickard-Institute for Computer Science
   Auf der Morgenstelle 10C
   Tuebingen  71076

   Phone: +49 7071 29-70522
   EMail: dressler@informatik.uni-tuebingen.de
   URI:   http://net.informatik.uni-tuebingen.de/

   Georg Carle
   University of Tuebingen
   Wilhelm-Schickard-Institute for Computer Science
   Auf der Morgenstelle 10C
   Tuebingen  71076

   Phone: +49 7071 29-70505
   EMail: carle@informatik.uni-tuebingen.de
   URI:   http://net.informatik.uni-tuebingen.de/

   Changpeng Fan
   Siemens AG
   Siemensdamm 62
   Berlin  13627

   Phone: +49 30 386-36361
   EMail: changpeng.fan@siemens.com

   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin  13627

   Phone: +49 30 386-32894
   EMail: cornelia.kappler@siemens.com

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 16]

Internet-Draft              Accounting NSLP                    July 2004

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739

   EMail: Hannes.Tschofenig@siemens.com

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 17]

Internet-Draft              Accounting NSLP                    July 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Dressler, et al.    draft-dressler-nsis-accounting-nslp-00.txt    [Page 18]

Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/