CoovaAAA RADIUS Requirements

RADIUS requirements for using the CoovaAAA service are as follows.

RADIUS Attributes

Here are some basic requirements and recommendation for RADIUS attributes for user (and device) authentication and session accounting.

User Authentication

`User-Name`	The username being authenticated.
`Calling-Station-Id`	MAC address of the client device. Always required.
`Called-Station-Id`	MAC address of access point. Required if no suitable MAC address in `NAS-Identifier`.
`NAS-Identifier`	Either an identifier (name) or MAC address. Required with AP MAC address if no `Called-Station-Id`.
`Acct-Session-Id`	Not required, but recommended and must remain consistent in accounting.
	See below for authentication protocol specific attributes.

User Session Accounting

	All requirements for authentication apply for accounting.
`Acct-Status-Type`	Accounting status types include `Start`, `Interim-Update` and `Stop`.
`Acct-Session-Id`	Required and must be consistent throughout session.
`Class`	Not required, but recommended. Must be same as `Class` attribute returned in `Access-Accept`.

Device Authentication

`User-Name`	Username for the administrative account.
`Service-Type`	Required to be `Administrative-User`.
`Called-Station-Id`	Recommended.
`NAS-Identifier`	Either an identifier (name) or MAC address. Recommended.
`Acct-Session-Id`	Not required, but recommended and must remain consistent in accounting.
	See below for authentication protocol specific attributes.

Authentication Protocols

`PAP`	`User-Password`	The simplest authentication method (only recommended for device auth).
`CHAP`	`CHAP-Challenge CHAP-Password`	A challenge and response authentication protocol.
`MSCHAP`	`MS-CHAP-Challenge MS-CHAP-Response`	A Microsoft challenge and response authentication protocol.
`MSCHAPv2`	`MS-CHAP-Challenge MS-CHAP2-Response`	A Microsoft challenge and response authentication protocol (version 2).
`EAP`	`EAP-Message`	EAP authentication methods include PEAP, EAP-TTLS, EAP-MD5, etc.

Session Accounting

`Acct-Input-Octets`	Currently defined to be bytes received by user (see below).
`Acct-Output-Octets`	Currently defined to be bytes sent by user (see below).
`Acct-Input-Gigawords`	The number of times `Acct-Input-Octets` has rolled-over it's 32-bit integer value.
`Acct-Output-Gigawords`	The number of times `Acct-Output-Octets` has rolled-over it's 32-bit integer value.
`Acct-Input-Packets`	Currently defined to be packets received by user (see below).
`Acct-Output-Packets`	Currently defined to be packets sent by user (see below).

The meaning of the Acct-Input- and Acct-Output- attributes can, in fact, be reversed - it is a matter of perspective. See below for Vendor Accounting Practices. This direction is subject to change with the ability to selectively reverse accounting attributes.

Vendor Accounting Practices

Vendor	Perspective	Notes
Bluesocket	Client
ChilliSpot	AC
Cisco	AC
Colubris	Client
CoovaChilli	Client	Reversible with option swapoctets
Gemtek	Client	Reversible with option Reverse Accounting set to enabled
Hostapd	AC ?
HP ProCurve	Client ?
LANCOM	Client ?
Nomadix	Client

Perspectives:

AC: Input is data from the Client to the NAS, and Output is data to the Client from the NAS
Client *: Input is data from the NAS to the Client, and Output is data to the NAS from the Client

Notes:

RFC 2866: The RADIUS Accounting RFC states that Acct-Input-Octets indicates how many octets have been received from the port over the course of this service being provided - Although not very clearly stated, port should be seen from the point of view of the AC/NAS, not the Client (* those with the Client perspective are not RFC compliant).
RFC 4005: The Diameter NAS Application RFC states that Accounting-Input-Octets contains the number of octets received from the user which also (and perhaps more clearly) takes the point of view of the AC/NAS. In some early drafts, there was a mistake where it said this attribute contains the number of octets in IP packets received by the user.
GSM WLAN Roaming Guidelines: This document defines Acct-Input-Octets as the volume of the downstream traffic of the user - not very clear in the meaning, but seems to suggest the Client point of view.
3GPP TS 29.234: This document defines Acct-Input-Octets as "the number of octets sent by the WLAN UE over the course of the session. According to IETF RFC 2866"
IETF Opinions: In the RFC 2866 clarifications thread

Navigation