Introduction to Accounting Management

1. Introduction to Accounting Management RFC 2975 SIPPING IETF 53 Minneapolis, MN Thursday March 21, 2002

3. 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.

4. 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.

5. 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.

6. 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

7. 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

8. 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 Accounting-Response acknowledgment to the client.” • Can’t say “disk failed” or “I’m busy” • Result: the client will retry instead of failing over

9. Security Issues • Transport security • Each accounting packet is authenticated and integrity protected with the RADIUS shared secret • Authenticator vulnerable to offline dictionary attack • Don’t 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

10. 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?

11. RADIUS Accounting Attributes • 1-39 (refer to RADIUS document [2]) • 40 Acct-Status-Type • 41 Acct-Delay-Time • 42 Acct-Input-Octets • 43 Acct-Output-Octets • 44 Acct-Session-Id • 45 Acct-Authentic • 46 Acct-Session-Time • 47 Acct-Input-Packets • 48 Acct-Output-Packets • 49 Acct-Terminate-Cause • 50 Acct-Multi-Session-Id • 51 Acct-Link-Count • 55 Event-Timestamp

12. 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

13. 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)

14. 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

15. Alternatives, cont’d • 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

16. Some Closing Thoughts • “It’s one thing to be confused. It’s 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 O’Dell, former O&M Area Director

17. Feedback?