Introduction to Accounting ManagementRFC 2975SIPPINGIETF 53Minneapolis, MNThursday 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 DataTrend analysis and capacity planning.Goal: forecast of future usageHigh reliability typically not required, moderate packet loss can be toleratedBillingNon-usage sensitive billingDoes not require usage informationIn theory all accounting data can be lost without affecting the billing process.Usage-sensitive billingPacket loss = Revenue lossBilling process may need to conform to financial reporting and legal requirementsAn archival accounting approach may be needed.AuditingThe act of verifying the correctness of a procedure; commonly relies on accounting dataTo permit a credible audit, the auditing data collection process must be at least as reliable as the entity being audited. Cost allocationCost 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 AccountingNon-volatile storageWithout 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 accountingUseful only when insufficient non-volatile storage available on the clientIncreases accounting traffic; interim interval must be set w/careA well designed accounting system will not require interim records to transit the wireReliable transportImplies that the receiving transport layer has taken responsibility for delivering the data to the application, but no guarantees!Application-layer acknowledgementTells you that the accounting server has taken responsibility for the data (e.g. written to stable storage)Failover support

Tools for Secure AccountingAuthenticationIs the data being sent to the intended destination?Integrity ProtectionHas the data been tampered with?Replay ProtectionHas the data been replayed?ConfidentialityCan the data be obtained by an eavesdropper?Transmission versus object securityMay 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 maybeAccounting-Response packet implies that the Accounting-Request has been received and recorded successfully.Undefined proxy behaviorExtreme 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 messagesIf the RADIUS accounting server is unable to successfully record the accounting packet it MUST NOT send an Accounting-Response acknowledgment to the client.Cant say disk failed or Im busyResult: the client will retry instead of failing over

Security IssuesTransport securityEach accounting packet is authenticated and integrity protected with the RADIUS shared secretAuthenticator vulnerable to offline dictionary attackDont choose a weak password!No confidentialityReplay protection is a feature of accounting post-processing, not the wire protocolFixes: run over IPsec (RFC 3162)Object securityNo protection against untrusted proxies

RADIUS Accounting Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Attributes1-39 (refer to RADIUS document [2])40 Acct-Status-Type41 Acct-Delay-Time42 Acct-Input-Octets43 Acct-Output-Octets44 Acct-Session-Id45 Acct-Authentic46 Acct-Session-Time47 Acct-Input-Packets48 Acct-Output-Packets49 Acct-Terminate-Cause50 Acct-Multi-Session-Id51 Acct-Link-Count55 Event-Timestamp

Replay ProtectionAccounting 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 attributesIdentifier is only a single octet, can wrapAcct-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 wrapsPost-processing check for duplicate Acct-Session-Id to detect replayAccounting server needs to timestamp the packets

RFC 2975 Evaluation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage | Intra-domain | Inter-domain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capacity | SNMPv3 & | 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)

AlternativesSNMPThe most popular accounting methodSupports polling model Bulk retrieval best handled over TCPIssues explained in RFC 2975Support for application layer ACKSNMP 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 bloatingSecurity with SNMPv3

Alternatives, contdDiameterRuns over reliable transportFailover supportInterim accountingApplication layer ACK, error messagesNo response bloatingPush or Pull modelSecured via IPsec or TLSDeployable with untrusted proxies via CMS

Some Closing ThoughtsIts 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?