One document matched: draft-calhoun-diameter-accounting-01.txt
Differences from draft-calhoun-diameter-accounting-00.txt
INTERNET DRAFT Jari Arkko
Category: Standards Track Oy LM Ericsson Ab
Title: draft-calhoun-diameter-accounting-01.txt Pat R. Calhoun
Date: October 1999 Sun Microsystems, Inc.
Pankaj Patel
Convergys Corporation
Glen Zorn
Microsoft Corporation
DIAMETER Accounting Extension
Status of this Memo
This document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@ipass.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
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:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
The DIAMETER protocol provides Authentication and Authorization for
dial-up PPP clients [2] and for Mobile-IP [3]. The ROAMOPS WG has
been working on an accounting data format, called Accounting Data
Interchange Format (ADIF) [10], as a method to transfer accounting
Arkko et al. expires April 2000 [Page 1]
INTERNET DRAFT October 1999
information over a wide variety of transports. This document describes
how ADIF can be securely transmitted over the DIAMETER protocol.
Table of Contents
1.0 Introduction
1.1 Copyright Statement
1.2 Requirements language
1.3 Changes in version 01
2.0 Command Codes
2.1 Accounting-Request
2.2 Accounting-Answer
2.3 Accounting-Poll-Ind
3.0 DIAMETER AVPs
3.1 Accounting-Record-Type
3.2 ADIF-Record
3.3 Accounting-Confirmation
3.4 Session-Token
3.5 Accounting-Interim-Interval
3.6 Accounting-Delivery-Max-Batch
3.7 Accounting-Delivery-Max-Delay
3.8 Accounting-Record-Number
4.0 Protocol overview
4.1 Authorization-Server Directed Model
4.2 Protocol Messages
4.3 Fault Resilience
4.4 Session Records
4.5 Accounting in brokering environments
5.0 IANA Considerations
6.0 Acknowledgments
7.0 References
8.0 Authors' Addresses
9.0 Full Copyright Statement
1.0 Introduction
The DIAMETER protocol provides Authentication and Authorization for
dial-up PPP clients [2] and for Mobile-IP [3]. The ROAMOPS WG has
been working on an accounting data format, called Accounting Data
Interchange Format (ADIF) [10], as a method to transfer accounting
information over a wide variety of transports. This document
describes how ADIF can be securely transmitted over the DIAMETER
protocol.
This document describes how Accounting Records can be transmitted
within the DIAMETER protocol in a secure fashion, even when the
Arkko et al. expires April 2000 [Page 2]
INTERNET DRAFT October 1999
messages must traverse DIAMETER proxies [1, 9]. This extension allows
for both real-time and batched accounting transfers.
This document introduces AVPs that are very similar to some found in
the base [1] and the end-to-end security extension [9]. However,
since this extension requires that the AVPs in question must have
bits set which are not currently permitted in both the stated drafts,
a new version of the AVP has been defined here. However, a future
version of this document may make use of the original AVPs once the
[1] and [9] have been corrected. If there is interest in this
extension, the impact of changing [1] and [9] must be carefully
evaluated.
The Extension number for this draft is five (5). This value is used
in the Extension-Id Attribute value Pair (AVP) as defined in [7].
1.1 Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
1.2 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [6].
1.3 Changes in version 01
This document contains several minor editor changes found during the
DIAMETER Document Reading Party in addition to the following:
- Removed the Accounting-Session-Id in favor for the Session-Id as
described in the base protocol.
- Removed the Accounting-Digital-Signature in favor for the
Digital-Signature described in the secure proxy extension.
- Renamed the Accounting-Certificate to Session-Token.
- Removed the Accounting-Session-Id from the Session-Token
- Removed the Session-Record accounting type.
- Added the Accounting-Poll-Ind Command Code.
Arkko et al. expires April 2000 [Page 3]
INTERNET DRAFT October 1999
- Added the Accounting-Delivery-Max-Batch and Accounting-
Delivery-Max-Delay AVPs.
- Added the Accounting-Record-Number, which is a way to identify
an accounting record.
2.0 Command Codes
This section will define the Commands [1] for DIAMETER
implementations supporting the Mobile IP extension.
Command Name Command Code
-----------------------------------
Accounting-Request ???
Accounting-Answer ???
Accounting-Poll-Ind ???
2.1 Accounting-Request
Description
The Accounting-Request command is sent by a DIAMETER node in order
to exchange accounting information with a peer. The Accounting
information is contained within an ADIF record, as described in
[10].
The Accounting-request command MAY contain accounting information
for more than a single session, which allows it to send batched
accounting information. When the batch mode is used, the session-
Id AVP [1] MUST be present and the Digital-Signature AVP [6] MAY
be present, and MUST have a tag of the same value as the ADIF-
Record AVP.
The Accounting-Request message MAY contain the Accounting-
Confirmation AVP, with the corresponding Digital-Signature AVP
signed by the user's home AAA server, when the request is being
issued to a broker that allows direct communication (see section
4.5).
Message Format
<Accounting-Request> ::= <DIAMETER Header>
<Accounting-Request Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
(<Session-Id AVP> &&
Arkko et al. expires April 2000 [Page 4]
INTERNET DRAFT October 1999
<Accounting-Record-Type> &&
<Accounting-Record-Number> &&
<User-Name AVP> &&
[<Accounting-Confirmation AVP> &&
<Digital-Signature AVP>] &&
<ADIF-Record AVP> &&
<Digital-Signature AVP>)
<Timestamp AVP>
<Nonce AVP>
{<Integrity-Check-Value AVP> ||
<Digital-Signature AVP> }
The length of the DIAMETER Command AVP must be 12 when the Command
Code is set to ??? (Accounting-Request).
2.2 Accounting-Answer
Description
The Accounting-Answer command is used to acknowledge an
Accounting-Request command. The Accounting-Answer command contains
the same Session-Id AVP that was sent in the Accounting-Request
command, and the MD5 hash in Accounting-Confirmation AVP forms a
confirmation that the right accounting record was accepted. This
can be signed using the Digital-Signature AVP for end-to-end
message integrity and possible non-repudiation.
Only the target DIAMETER Server, known as the home DIAMETER
Server, SHOULD respond with the Accounting-Answer command.
If the Accounting-Request command contained more than one ADIF-
Record AVP, the Accounting-Answer SHOULD contain the same number
of ADIF-Record AVPs. However, it is possible for the DIAMETER
Server to acknowledge each ADIF-Record in a separate response.
This allows the sender of the ADIF-Records to send a batch of
records, whose final destination are different.
Message Format
<Accounting-Answer> ::= <DIAMETER Header>
<Accounting-Answer Command AVP>
<Result-Code AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
(<Session-Id AVP> &&
<Accounting-Record-Number> &&
<Result-Code AVP> &&
Arkko et al. expires April 2000 [Page 5]
INTERNET DRAFT October 1999
<Accounting-Confirmation AVP> &&
<Digital-Signature AVP>)
<Timestamp AVP>
<Nonce AVP>
{<Integrity-Check-Value AVP> ||
<Digital-Signature AVP> }
The length of the DIAMETER Command AVP must be 12 when the Command
Code is set to ??? (Accounting-Answer).
2.3 Accounting-Poll-Ind
Description
The Accounting-Poll-Ind command is sent by a DIAMETER Server in
order to force the Client to send current accounting data. This
data MUST include not yet sent accounting records from completed
sessions, as well as INTERIM_RECORD records from all ongoing
sessions.
The Client MUST use Accounting-Request command to send the
accounting data.
The use of Accounting-Poll-Ind is useful in situations where a
DIAMETER Server comes up after an unscheduled downtime, and wishes
to synchronize with the Client(s) sooner than at the end of the
next INTERIM_RECORD or at the end of a session. Accounting-Order
SHOULD NOT be used in a roaming situation due to the excessive
polling through the roaming network.
Warning: The use of the Accounting-Poll-Ind message is discouraged
in roaming networks, since it is unfeasible for a server to
attempt to poll all of it's roaming partner's DIAMETER Clients.
Message Format
<Accounting-Poll-Ind> ::= <DIAMETER Header>
<Accounting-Poll-Ind Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Nonce AVP>
{<Integrity-Check-Value AVP> ||
<Digital-Signature AVP> }
The length of the DIAMETER Command AVP must be 12 when the Command
Arkko et al. expires April 2000 [Page 6]
INTERNET DRAFT October 1999
Code is set to ??? (Accounting-Poll-Ind).
3.0 DIAMETER AVPs
This section will define the mandatory AVPs which MUST be supported
by all DIAMETER implementations supporting this extension. The
following AVPs are defined in this document:
Attribute Name Attribute Code Definition in Section
-------------------------------------------------------------------
Accounting-Record-Type ??? 3.1
ADIF-Record ??? 3.2
Accounting-Confirmation ??? 3.3
Session-Token ??? 3.4
Accounting-Interim-Interval ??? 3.5
Accounting-Delivery-Max-Batch ??? 3.6
Accounting-Delivery-Max-Delay ??? 3.7
Accounting-Record-Number ??? 3.8
3.1 Accounting-Record-Type
Description
The Accounting-Record-Type AVP contains the type of record that
can be found in the ADIF-Record AVP.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Flags
The 'M' bit MUST be set. The 'T' bit MAY be set if more than
one Accounting record is being sent in an Accounting-Request
message. The 'P' bit MAY be set if end to end message
integrity is required, but may not be necessary if the
Digital-Signature is used. The 'H', 'E', 'V' bits MUST NOT be
set.
Integer32
The Integer32 field contains the record type that can be found
Arkko et al. expires April 2000 [Page 7]
INTERNET DRAFT October 1999
in the ADIF-Record AVP. The following values are currently
defined:
EVENT_RECORD 1
An Accounting Event Record is used to indicate a service
of indivisible nature has occurred. This record contains
all information relevant to the service, and is the only
record of the service.
START_RECORD 2
An Accounting Start, Interim, and Stop Records are used
to indicate that a service of a measurable length has
been given. An Accounting Start Record is used to
initiate an accounting session, and contains accounting
information that is relevant to the initiation of the
session.
INTERIM_RECORD 3
An Interim Accounting Record contains cumulative
accounting information for an existing Accounting
session. Interim Accounting Records SHOULD be sent
everytime a re-authentication or re-authorization occurs.
STOP_RECORD 4
An Accounting Stop Record is sent to terminate an
accounting session and contains cumulative accounting
information relevant to the existing session.
The selection of whether to use INTERIM_RECORD records is
directed by the Accounting-Interim-Interval AVP.
3.2 ADIF-Record
Description
This attribute contains an ADIF record, as defined in [10].
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Arkko et al. expires April 2000 [Page 8]
INTERNET DRAFT October 1999
AVP Flags
The 'M' bit MUST be set. The 'T' bit MAY be set if more than
one Accounting record is being sent in an Accounting-Request
message. The 'P' bit MAY be set if end to end message
integrity is required, but may not be necessary if the
Digital-Signature is used. The 'H', 'E', 'V' bits MUST NOT be
set.
Data
The Data field contains an ADIF payload as defined in [10].
3.3 Accounting-Confirmation
Description
This AVP contains an MD5 hash of a previous ADIF-Record, and is
used to confirm receipt of the ADIF-Record. When signed via the
Digital-Signature, this AVP provides the sender of the
Accounting-Request with proof that the receiver accepted the
Accounting record.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Flags
The 'M' bit MUST be set. The 'T' bit MAY be set if more than
one Accounting record is being sent in an Accounting-Request
message. The 'P' bit MAY be set if end to end message
integrity is required, but may not be necessary if the
Digital-Signature is used. The 'H', 'E', 'V' bits MUST NOT be
set.
Data
The Data field contains an MD5 hash of the ADIF-Record AVP
being confirmed.
3.4 Session-Token
Description
Arkko et al. expires April 2000 [Page 9]
INTERNET DRAFT October 1999
The Session-Token AVP is created by the home DIAMETER server as a
result of a successful Authentication and/or Authorization. This
"token" is used in the subsequent Accounting-Request messages as a
proof that the user was in fact authorized for the service. The
document [7] and section 4.1 provides further information on this
AVP.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Session-Id | Length of User-Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Digital-Signature | Digital-Signature Transform |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Id... | User-Name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digital-Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Flags
The 'M' bit MUST be set. The 'T' bit MAY be set if more than
one Accounting record is being sent in an Accounting-Request
message. The 'P' bit MAY be set if end to end message
integrity is required, but may not be necessary if the
Accounting-Digital-Signature is used. The 'H', 'E', 'V' bits
MUST NOT be set.
Length of Session-Id
This 16 bit field contains the length of the Session-Id field
found in this AVP.
Length of User-Name
This 16 bit field contains the length of the User-Name field
found in this AVP.
Length of Digital-Signature
This 16 bit field contains the length of the Digital-Signature
field found in this AVP.
Digital-Signature Transform
Arkko et al. expires April 2000 [Page 10]
INTERNET DRAFT October 1999
This 16 bit field contains the transform used to generate the
Digital-Signature field, as defined in the Digital-Signature
AVP in [9].
Session-Lifetime
This 32 bit field contains the number of seconds that the
session has been autorized for. This field MUST be the same as
the value of the Session-Timeout AVP [1].
TimeStamp
This 32 bit field contains a timestamp representing when this
AVP was created. The format of this field is identical to the
Timestamp AVP defined in [1].
Session-Id
This variable length field contains the Session-Id, and MUST be
identical to the value found in the Session-Id AVP [1].
User-Name
This variable length field contains the User-Name and MUST be
identical to the value of the User-Name AVP [1].
Digital-Signature
This variable length field contains a signature of the AVP's
data, not including the AVP header and is generated using the
transform specified in the Digital-Signature-Transform field.
3.5 Accounting-Interim-Interval
Description
The Accounting-Interim-Interval AVP is sent from the DIAMETER
authenticating/authorizing server to the DIAMETER Client. The
Client uses information in the AVP to decide how and when to
produce accounting records. With different values in this AVP,
service sessions can result in one, two, or two+N accounting
records, based on the needs of the home-organization.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Arkko et al. expires April 2000 [Page 11]
INTERNET DRAFT October 1999
AVP Flags
As defined in the DIAMETER Base Protocol.
Integer32
The following accounting record production behaviour is
directed by the inclusion of this AVP:
1. The omission of the Accounting-Interim-Interval AVP or
its inclusion with Value field set to 0 means that
EVENT_RECORD, START_RECORD, and STOP_RECORD are produced, as
appropriate for the service.
2. The inclusion of the AVP with Value field set to a non-
zero value means that INTERIM_RECORD records MUST be
produced between the START_RECORD and STOP_RECORD records.
The Value field of this AVP is the nominal interval between
these records in seconds. The Client MUST produce the first
INTERIM_RECORD record roughly at the time when this nominal
interval has elapsed from the START_RECORD, the next one
again as the interval has elapsed once more, and so on until
the session ends and a STOP_RECORD record is produced.
The Client MUST ensure that the interim record production
times are randomized so that large accounting message storms
are not created either among records or around a common
service start time.
3.6 Accounting-Delivery-Max-Batch
Description
This attribute is sent to a device as a response to an
authorization request. It controls how accounting data is
transferred to the accounting server. The attribute sets the
requirements in terms of number of locally collected records
before accounting data transfer SHOULD begin. The DIAMETER Client
MAY deliver the data earlier due to satisfying requirements set by
Accounting- Delivery-Max-Delay, device reboot, lack of memory, or
explicit configuration. The DIAMETER Client MUST begin the
transfer in the given limits unless prevented from doing so by
network partitions, client or server failures, network congestion,
or client overload.
AVP Format
Arkko et al. expires April 2000 [Page 12]
INTERNET DRAFT October 1999
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Flags
As defined in the DIAMETER Base Protocol.
Integer32
The Integer32 field contains the number of accounting records
that may be stored locally at the DIAMETER Client before data
transfer SHOULD begin. Refer to section 4.1 for information on
how a record is placed on a particular batch, and how different
maximum batch and delay attributes may be given to different
sessions.
3.7 Accounting-Delivery-Max-Delay
Description
This attribute is sent to a device as a response to an
authorization request. It controls how accounting data is
transferred to the accounting server. The attribute sets the
requirements in terms of maximum delay before accounting data
transfer SHOULD begin. The DIAMETER Client MAY deliver the data
earlier due to satisfying requirements set by Accounting-
Delivery-Max-Batch, device reboot, lack of memory, or explicit
configuration. The DIAMETER Client MUST begin the transfer in the
given limits unless prevented from doing so by network partitions,
client or server failures, network congestion, or client overload.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Flags
As defined in the DIAMETER Base Protocol.
Arkko et al. expires April 2000 [Page 13]
INTERNET DRAFT October 1999
Integer32
The Integer32 field contains the number of seconds that may
elapse before accounting data transfer SHOULD begin from the
DIAMETER Client. Refer to section 4.1 for information on how a
record is placed on a particular batch, and how different
maximum batch and delay attributes may be given to different
sessions.
3.8 Accounting-Record-Number
Description
The Accounting-Record-Number AVP identifies this record within one
session. As Session-Id AVPs are globally unique, the combination
of Session-Id and Accounting-Record- Number AVPs is also globally
unique, and can be used in matching accounting records with
confirmations.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Header (AVP Code = ???)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Flags
As defined in the DIAMETER Base Protocol.
Integer32
This number uniquely identifies the record within a session. An
easy way to produce unique numbers is to set the value to 0 for
records of type EVENT_RECORD and START_RECORD, and set the
value to 1 for the first INTERIM_RECORD, 2 for the second, and
so on until the value for STOP_RECORD is one more than for the
last INTERIM_RECORD.
4.0 Protocol overview
This accounting protocol is based on an authorization-server directed
model with capabilities for both efficient batch and fast real-time
delivery of accounting information. Several fault resilience methods
[11] have been built in to the protocol in order minimize loss of
accounting data in various fault situations and under different
Arkko et al. expires April 2000 [Page 14]
INTERNET DRAFT October 1999
assumptions about the capabilities of the used devices.
4.1 Authorization-Server Directed Model
The authorization-server directed model means that at authorization
time, the device generating the accounting data gets information from
the authorization server regarding the way accounting data shall be
forwarded. This information includes a certificate to prove that the
session truly was authorized, as well as accounting record timeliness
requirements.
When the user's home DIAMETER Server successfully authenticates
and/or authorizes a session, it generates the Session-Token AVP that
is returned in the response. The document [7] describes a possible
format for the AVP, which is also described in section 3.6.
As discussed in [11], batch transfer of accounting data is more CPU-
and bandwidth efficient than real-time transfer. However, there are
many applications where real-time transfer is a requirement for at
least some of the accounting records. These applications include
roaming, where most (local) accounting records can be transferred in
batch mode, but roaming (visiting) accounting records should be
transferred fast due to the needs of credit limit checks and fraud
detection. For these reasons this accounting protocol defines both
batch and real-time transfer modes, and allows their use
simultaneously. The authorization server (chain) directs the
selection of proper transfer strategy, based on its knowledge of the
user and relationships of roaming partnerships. The server (or
proxies in between) use the Accounting-Delivery-Max-Batch,
Accounting-Delivery-Max-Delay, and Accounting-Interim-Interval AVPs
to control the operation of the DIAMETER Client. The first two
attributes set the requirements in terms of number of records and
maximum delay before accounting data transfer for this session SHOULD
begin. The DIAMETER Client MAY deliver the data earlier due to a
full batch of records, device reboot, lack of memory, or explicit
configuration. The DIAMETER Client MUST begin the transfer in the
given limits unless prevented from doing so by network partitions,
client or server failures, network congestion, or client overload.
The Accounting-Interim-Interval AVP, when present, instructs the
DIAMETER Client to produce accounting records continuously even
during a session.
Typically, the authorization server uses a few batching/real-time
classes, such as the local users whose data might be transferred once
in an hour and the roaming users whose data would be transferred
immediately. Each Accounting-Delivery-Max-Batch / Accounting-
Arkko et al. expires April 2000 [Page 15]
INTERNET DRAFT October 1999
Delivery-Max-Delay AVP pair with different values forms one pool of
accounting data in the DIAMETER Client. That is, a new record is
placed to same pool as the previous one if the authorization server
returned same values for both AVPs and the pool has not been emptied
in between.
4.2 Protocol Messages
The DIAMETER Client generating the accounting data will use the
Accounting-Request message to send one or more accounting records to
the DIAMETER Server. The Server MUST reply with the Accounting-Answer
message with appropriate confirmations.
It is possible that a DIAMETER Proxy breaks up a batch of accounting
records and sends them towards different DIAMETER Home Servers. In
this case it is possible that a separate Accounting-Answer message
contain the response for each block. Therefore, a Client MUST be
prepared to handle this scenario.
Upon receipt of an Accounting-Request, a home DIAMETER Server MUST
generate a response. The response includes the Result-Code, which MAY
contain an error if the ADIF-Record, or some other AVP, is not
acceptable. Furthermore, an Accounting-Confirmation MUST be returned.
The Accounting-Confirmation is an MD5 hash of the ADIF-Record data
which is being confirmed.
Each DIAMETER Accounting protocol message MAY be compressed using
IPComp in order to reduce the used network bandwidth. DIAMETER peers
MUST use a negotiation mechanisms such as ISAKMP/IKE in order to
ensure that both peers are able to handle IPComp. Note that it
usually makes sense to compress only Accounting-Request messages with
possibly lengthy ADIF data, not Accounting-Answer messages.
4.3 Fault Resilience
DIAMETER Base protocol mechanisms are used to overcome small message
loss and network faults of temporary nature.
DIAMETER Clients MUST implement the use of alternate servers to guard
against server failures and certain network failures. DIAMETER
Servers or related off-line processing systems MUST detect duplicate
accounting records caused by the sending of same record to several
servers and duplication of messages in transit. This detection MUST
be based on the inspection of Accounting-Record-Id and Host-IP-
Address AVP pairs.
Arkko et al. expires April 2000 [Page 16]
INTERNET DRAFT October 1999
DIAMETER Clients MAY have non-volatile memory for the safe storage of
accounting records over reboots or extended network failures, network
partitions, and server failures. If such memory is available the
Client SHOULD store new accounting records there as soon as the
records are created and until a positive acknowledgement of their
reception from the DIAMETER Server has been received. Upon a reboot,
the Client MUST starting sending the records in the non-volatile
memory to the accounting server with appropriate modifications in
termination cause, session length, and other relevant information in
the records.
A further extension of this protocol may include AVPs to control how
many accounting records may at most be stored in the DIAMETER Client
without committing them to the non-volatile memory or transferring
them to the DIAMETER Server.
The Client SHOULD NOT remove the accounting data from any of its
memory areas before the correct Accounting-Answer has been received.
The Client MAY remove oldest, undelivered or yet unacknowledged
accounting data if it runs out of resources such as memory. It is an
implementation dependent matter for the client to accept new sessions
under this condition.
4.4 Session Records
In all accounting records the Session-Id AVP, ADIF-Record AVP, and
User-Name AVPs MUST be present. If only one accounting record is
present in the message, the whole message may be protected using the
Digital-Signature, as defined in [9].
However, if the accounting records are being in sent in batch mode,
the sender can create several "blocks" of accounting records by
making use of the AVP Tag field (bit 'T' [1]). Each block is
individually signed, unless all blocks are destined for the same home
DIAMETER Server.
Different types of session records are sent depending on the actual
type of accounted service and the authorization server's directions
for interim accounting. If the accounted service is of an indivisible
nature, then the Accounting-Record-Type AVP MUST be present and set
to the value EVENT_RECORD. This can be used to account for services
such as "send an e-mail to this wireless terminal".
If the accounted service is of a measurable length, then the AVP MUST
use the values START_RECORD, STOP_RECORD, and possibly,
INTERIM_RECORD. If the authorization server has directed interim
accounting to be on but with no specified interim interval, two
Arkko et al. expires April 2000 [Page 17]
INTERNET DRAFT October 1999
accounting records MUST be generated for each service of type
session. When the initial Accounting-Request is sent for a given
session is sent, the Accounting-Record-Type AVP MUST be set to the
value START_RECORD. When the last Accounting-Request is sent, the
value MUST be STOP_RECORD.
If a specified interim interval exists, the DIAMETER Client MUST
produce additional records between the START_RECORD and STOP_RECORD,
marked INTERIM_RECORD. The production of these records is directed
both by Accounting-Interim-Interval as well as any re-authentication
or -authorization of the session. If a batch size of greater than 1
has been specified by the authorization server, then the DIAMETER
Client MUST ensure that new interim records overwrite previous
interim records for the same session and batch as this reduces the
amount of memory required to store the records. In effect, this means
that interim records are delivered at least as often as dictated by
Accounting-Delivery-Max-Delay.
4.5 Accounting in brokering environments
The DIAMETER base protocol describes brokers that provide redirect
services, by allowing AAA servers within a roaming consortium to
directly communicate in a secure fashion. However, since brokers can
also provide settlement services, it needs to be aware of the
accounting information exchange. Historically, the thought was to
have the broker "proxy" the accounting records from the local to the
home network.
A new model has been defined that allows the local AAA server to
issue the Accounting-Request message to the home AAA server, which
includes the ADIF-Record AVP with the corresponding Digital-Signature
AVP. The home server generates the Accounting-Confirmation AVP and
the Digital-Signature AVP, which is returned in the Accounting-Answer
message. The local AAA server then forwards both the ADIF-Record and
the Accounting-Confirmation AVPs with both Digital-Signature AVPs to
the broker in an Accounting-Request message. The broker replies by
issuing an Accounting-Answer message that includes its own
Accounting-Confirmation and Digital-Signature AVPs.
This new model eliminates the need for application end-to-end
security, by allowing the peers to communicate directly, and reduces
the latency that would otherwise be added through the proxy process.
5.0 IANA Considerations
The numbers for the Command Code AVPs (section 2) is taken from the
Arkko et al. expires April 2000 [Page 18]
INTERNET DRAFT October 1999
numbering space defined for Command Codes in [1]. The numbers for the
various AVPs defined in section 3 were taken from the AVP numbering
space defined in [1]. The numbering for the AVP and Command Codes
MUST NOT conflict with values specified in [1] and other DIAMETER
related Internet Drafts.
This document introduces the Accounting-Record-Type AVP, which may
contain pre-defined values. This document defines the values 1-3.
All remaining values are available for assignment via IETF Consensus
[8].
6.0 Acknowledgments
The authors would like to thank Nenad Trifunovic, Tony Johansson and
Pankaj Patel for their participation in the Document Reading Party.
Thanks to the various people that have contributed to accounting
related requirements at the IETF's AAA Working Group and other
related WGs.
7.0 References
[1] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-08.txt, Work in Progress,
August 1999.
[2] P. R. Calhoun, "DIAMETER Authentication Extension",
draft-calhoun-diameter-auth-06.txt, Work in Progress,
August 1999.
[3] P. R. Calhoun, C. Perkins, "DIAMETER Mobile IP Extension",
draft-calhoun-diameter-mobileip-02.txt, Work in Progress,
August 1999.
[4] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)." RFC 2138,
April 1997.
[5] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997.
[6] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming",
draft-ietf-roamops-fraud-limit-00.txt, May 1999.
[8] Narten, Alvestrand,"Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998
[9] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions",
draft-calhoun-diameter-proxy-02.txt, Work in Progress,
August 1999.
[10] B. Aboba, D. Lidyard, "The Accounting Data Interchange
Format (ADIF)", draft-ietf-roamops-actng-05.txt,
Arkko et al. expires April 2000 [Page 19]
INTERNET DRAFT October 1999
Work in Progress, November 1998.
[11] B. Aboba, J. Arkko. Introduction to Accounting Management.
draft-aboba-acct-01.txt. Work in progress, June 1999.
8.0 Authors' Addresses
Questions about this memo can be directed to:
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
Phone: +358 40 5079256
E-Mail: Jari.Arkko@ericsson.com
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Pankaj Patel
Convergys Corporation
4600 Montgomery Road
Cincinnati, OH 45212
USA
Phone: 1-513-723-2018
E-Mail: pankaj.patel@convergys.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: 1-425-703-1559
Arkko et al. expires April 2000 [Page 20]
INTERNET DRAFT October 1999
E-Mail: gwz@acm.org
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this docu- ment itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Inter- net organizations, except as needed
for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English. The limited permis- sions granted
above are perpetual and will not be revoked by the Internet
Society or its successors or assigns. This document and the
information contained herein is provided on an "AS IS" basis and
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Arkko et al. expires April 2000 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 14:42:04 |