Introduction to Accounting

Management
RFC 2975
SIPPING
IETF 53
Minneapolis, MN
Thursday March 21, 2002

What is Accounting Management?

The field of Accounting Management is
concerned with the collection of resource
consumption data for the purposes of
capacity and trend analysis, cost
allocation, auditing, and billing.

Uses for Accounting Data

Trend analysis and capacity planning.
Goal: forecast of future usage
High reliability typically not required, moderate packet loss can be tolerated

Billing
Non-usage sensitive billing
Does not require usage information
In theory all accounting data can be lost without affecting the billing process.

Usage-sensitive billing
Packet loss = Revenue loss
Billing process may need to conform to financial reporting and legal requirements
An archival accounting approach may be needed.

Auditing
The act of verifying the correctness of a procedure; commonly relies on accounting data
To permit a credible audit, the auditing data collection process must be at least as
reliable as the entity being audited.

Cost allocation
Cost allocation models often have profound behavioral and financial impacts.
Due to financial and legal requirements, archival accounting practices are frequently
required in this application.

What is Archival Accounting?

In archival accounting, the goal is to collect all
accounting data, to reconstruct missing entries
as best as possible in the event of data loss, and
to archive data for a mandated time period.
It is "usual and customary" for these systems to
be engineered to be very robust against
accounting data loss.
This is not just a good idea. Legal or
financial requirements frequently mandate
archival accounting practices, and may often
dictate that data be kept confidential, regardless
of whether it is to be used for billing purposes or
not.

Tools for Robust Accounting

Non-volatile storage
Without non-volatile storage, event-driven systems will lose data once
the transmission timeout has been exceeded, and batching designs
will experience data loss once the internal memory used for
accounting data storage has been exceeded.

Interim accounting
Useful only when insufficient non-volatile storage available on the
client
Increases accounting traffic; interim interval must be set w/care
A well designed accounting system will not require interim records to
transit the wire

Reliable transport
Implies that the receiving transport layer has taken responsibility for
delivering the data to the application, but no guarantees!

Application-layer acknowledgement
Tells you that the accounting server has taken responsibility for the
data (e.g. written to stable storage)

Failover support

Tools for Secure Accounting

Authentication
Is the data being sent to the intended destination?

Integrity Protection
Has the data been tampered with?

Replay Protection
Has the data been replayed?

Confidentiality
Can the data be obtained by an eavesdropper?

Transmission versus object security

May need to provide the above services even when
there are proxies in the path

Issues with RADIUS Accounting (RFC 2866)

Undefined retransmission behavior (UDP)
It is recommended that the client continue attempting to send the
Accounting-Request packet until it receives an acknowledgement,
using some form of backoff.

Undefined failover behavior

Application layer ACK maybe
Accounting-Response packet implies that the Accounting-Request
has been received and recorded successfully.

Undefined proxy behavior

Extreme care should be used when implementing a proxy server
that takes responsibility for retransmissions so that its
retransmission policy is robust and scalable.

No error messages
If the RADIUS accounting server is unable to successfully record
the accounting packet it MUST NOT send an AccountingResponse acknowledgment to the client.
Cant say disk failed or Im busy
Result: the client will retry instead of failing over

Security Issues
Transport security
Each accounting packet is authenticated and
integrity protected with the RADIUS shared
secret
Authenticator vulnerable to offline dictionary attack
Dont choose a weak password!

No confidentiality
Replay protection is a feature of accounting
post-processing, not the wire protocol
Fixes: run over IPsec (RFC 3162)

Object security
No protection against untrusted proxies

RADIUS Accounting Request

0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Code|Identifier|Length|
+++++++++++++++++++++++++++++++++
||
|Authenticator|
||
||
+++++++++++++++++++++++++++++++++
|Attributes...
+++++++++++++

The NAS and RADIUS accounting server share a secret. The

Request Authenticator field in Accounting-Request packets
contains a one-way MD5 hash calculated over a stream of
octets consisting of the Code + Identifier + Length + 16 zero
octets + request attributes + shared secret (where + indicates
concatenation). The 16 octet MD5 hash value is stored in the
Authenticator field of the Accounting-Request packet.
Notice anything interesting about this?

RADIUS Accounting Attributes

1-39
40
41
42
43
44
45
46
47
48
49
50
51
55

(refer to RADIUS document [2])

Acct-Status-Type
Acct-Delay-Time
Acct-Input-Octets
Acct-Output-Octets
Acct-Session-Id
Acct-Authentic
Acct-Session-Time
Acct-Input-Packets
Acct-Output-Packets
Acct-Terminate-Cause
Acct-Multi-Session-Id
Acct-Link-Count
Event-Timestamp

Replay Protection
Accounting request authenticator is not a nonce, as in
RADIUS authentication!
Only source of liveness in the Accounting packet is the
Acct-Session-Id and Event-Timestamp attributes
Identifier is only a single octet, can wrap
Acct-Session-Id MUST be included in Accounting Request, not
required to be temporally unique
Event-Timestamp attribute is optional (RFC 2869)

The RADIUS server can detect a duplicate request if it

has the same client source IP address and source UDP
port and Identifier within a short span of time.
Unless source UDP port is changed every 256 packets, server
will accept a replay once the Identifier wraps
Post-processing check for duplicate Acct-Session-Id to detect
replay
Accounting server needs to timestamp the packets

RFC 2975 Evaluation

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Usage
|
Intra-domain
| Inter-domain
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capacity
| SNMPv3 &
| SNMPv3 &<*
|
| Planning
| RADIUS #%@
|
|
|
| TACACS+ @
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-usage
| SNMPv3 &
| SNMPv3 &<*
|
| Sensitive
| RADIUS #%@
|
|
| Billing
| TACACS+ @
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Usage
|
|
|
| Sensitive
|
|
|
| Billing,
| SNMPv3 &>$
| SNMPv3 &<>*$
|
| Cost
| TACACS+ &$@
|
|
| Allocation &
|
|
|
| Auditing
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time
|
|
|
| Sensitive
| SNMPv3 &>$
| No existing
|
| Billing,
|
| protocol
|
| fraud
|
|
|
| detection,
|
|
|
| roaming
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
#
*
%
&
$
@
<
>

=
=
=
=
=
=
=
=

lacks confidentiality support

lacks data object security
limited robustness against packet loss
lacks application layer acknowledgment (e.g. SNMP InformRequest)
requires non-volatile storage
lacks batching support
lacks certificate support (KSM, work in progress)
lacks support for large packet sizes (TCP transport mapping experimental)

Alternatives
SNMP
The most popular accounting method
Supports polling model
Bulk retrieval best handled over TCP
Issues explained in RFC 2975

Support for application layer ACK

SNMP Responses to get, get-next, or get-bulk requests return
the requested data, or an error code indicating the nature of
the error encountered.
A noError SNMP Response to a SET command indicates
that the request assignments were made by the application.
SNMP SETs are atomic.
Notifications do not use acknowledgements to indicate that
data has been processed. The Inform notification returns an
acknowledgement of receipt, but not of processing, by
design.

Push model not feasible due to response bloating

Security with SNMPv3

Alternatives, contd
Diameter
Runs over reliable transport
Failover support
Interim accounting
Application layer ACK, error messages
No response bloating
Push or Pull model
Secured via IPsec or TLS
Deployable with untrusted proxies via CMS

Some Closing Thoughts

Its one thing to be confused. Its another
thing to be confused about money.
My boss, referring to an accounting issue,
1994

The use of RADIUS accounting [for

usage based billing] could be considered
negligent.
Mike ODell, former O&M Area Director

Feedback?