accounting

term

networkinggovernance & risksecurity

The third A in AAA: recording what an authenticated party actually did, for billing, capacity or evidence.

It is the one most often configured last and needed most under pressure, because authentication and authorisation answer questions about the present while accounting is the only one that answers questions about the past. In carrier networks it exists to produce an invoice; in enterprise networks it exists so that someone can say which account issued which command on which device, which is exactly the question asked after an outage or an intrusion and exactly the record nobody enabled. RFC 2866 gives RADIUS accounting its shape: Accounting-Request packets on UDP 1813 with an Acct-Status-Type of Start (1), Stop (2) or Interim-Update (3), plus Accounting-On (7) and Accounting-Off (8) when a NAS boots or shuts down, carrying Acct-Session-Id, the input and output octet and packet counters, Acct-Session-Time and Acct-Terminate-Cause, each acknowledged by an Accounting-Response and retried with backoff until it is. RFC 8907 gives TACACS+ its accounting exchange with START, STOP and WATCHDOG flags, which on a router means every command an administrator ran. Syslog (RFC 5424) and a device's own configuration change log carry the rest, and NIST's control catalogue says what a record must establish: what happened, when, where, from what source, with what outcome, and the identity of who was involved.

Accounting is the part of AAA that produces a record, and the record is the point: authentication decides who may enter and authorisation decides what they may do, but only accounting can say afterwards what was done, by which account, on which device, and when. Carriers built it to bill, which is why the RADIUS attributes count octets; enterprises need it for the question that follows every outage and every intrusion, and discover on the day whether it was ever switched on. The protocols that carry it are the same ones that carry authentication, each with an accounting side of its own.

RADIUS accounting is RFC 2866, published in June 2000 by Rigney as an Informational companion to RFC 2865. The network access server sends Accounting-Request packets (code 4) to UDP port 1813 and expects an Accounting-Response (code 5) for each; the RFC recommends that "the client continue attempting to send the Accounting-Request packet until it receives an acknowledgement, using some form of backoff", which is why accounting survives a brief server outage and why a long one produces a flood of delayed records when the server returns. The Acct-Status-Type attribute says what kind of record it is: 1 Start when a session begins, 2 Stop when it ends, 3 Interim-Update at intervals during it, 7 Accounting-On and 8 Accounting-Off when the NAS itself starts or stops serving, with further values for tunnels and 15 for a failed attempt. The attributes carry the measurements: Acct-Session-Id to tie Start, updates and Stop together, Acct-Input-Octets and Acct-Output-Octets, Acct-Input-Packets and Acct-Output-Packets, Acct-Session-Time in seconds, Acct-Terminate-Cause for why it ended, Acct-Delay-Time for how long the record waited, Acct-Multi-Session-Id to link related sessions and Acct-Authentic to say who authenticated it. The Class attribute the server placed in the Access-Accept comes back unmodified, so a tag the policy engine attached at login is on every record. The Request Authenticator of an accounting packet is an MD5 over the packet with sixteen zero octets in the authenticator's place and the shared secret appended, which lets the server detect a record from a client that does not know the secret, and nothing more; the whole record is otherwise in clear text, as everything in RADIUS is without RadSec.

TACACS+ accounting, in RFC 8907 of September 2020, is the third of the protocol's three packet types, 0x03, and its records are about administrators rather than subscribers. The accounting request carries flags, START (0x02) for the beginning of a task, STOP (0x04) for its end and WATCHDOG (0x08) to report that a long task is still in progress, and because TACACS+ authorises commands one by one, a router configured for command accounting sends a record for each command an administrator executes, with the username, the device, the command line and the time. That stream, kept on a server, is the answer to who changed what; it exists only for devices where it was enabled and only for the period the server retained.

The device's own logs are the complement. Syslog, in RFC 5424 of March 2009, defines a message of a header, structured data and free text, with a priority computed as facility times eight plus severity, severities from 0 Emergency to 7 Debug, facilities 4 and 10 reserved for security and authorization messages and 16 to 23 for local use, and a timestamp derived from RFC 3339; the document specifies the message and leaves transport to others, UDP in RFC 5426 and TLS in RFC 5425, which every implementation must support. Cisco's Configuration Change Notification and Logging feature shows what a device can record on its own: it "allows the tracking of configuration changes entered on a per-session and per-user basis by implementing an archive function" and "saves configuration logs that track each configuration command that is applied, who applied the command, the parser return code (PRC) for the command, and the time the command was applied", with options to hide passwords in the log and to send each entry to syslog. Configuration backup tools close the loop by storing every device's configuration in a version-controlled repository and showing the difference between one day and the next; Oxidized, which describes itself as a network device configuration backup tool and a RANCID replacement, supports over 130 operating system types and writes to git, so that the diff between two commits is the change, even when the command accounting that would have named the author was never enabled.

What a record must contain is written down. NIST's control catalogue, SP 800-53, requires in AU-3 that audit records establish "what type of event occurred", "when the event occurred", "where the event occurred", the "source of the event", the "outcome of the event" and the "identity of any individuals, subjects, or objects/entities associated with the event"; AU-2 asks an organisation to "provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents"; AC-6(9) says simply "log the execution of privileged functions", because, in its discussion, the misuse of privileged functions by insiders or by attackers holding compromised accounts is "a serious and ongoing concern". Read together, those controls are the specification for an enterprise's accounting: RADIUS Start and Stop for every network session, TACACS+ command records for every administrative session, syslog with synchronised clocks from every device, and configuration history that shows what the commands did. The article on who did what and when assembles them into one design, and the regulations that demand it, from SOX to PCI DSS, have entries of their own.

Also known as: aaa, aaa accounting, radius accounting, command accounting, session accounting, who did what and when

← All glossary entries