Acct-Authentic in Accounting-On and Accounting-Off forms of Accounting-Request. Valid?

[Arran Cudbard-Bell]

> On May 21, 2015, at 11:53 AM, Nick Lowe <nick.lowe at gmail.com> wrote:
> 
> Hi Alan,
> 
> A BSS is always unique on a per-VAP basis, so that's
> per-SSID-per-radio-per-physical-AP.
> 
> Does the RADIUS spec prohibit accounting on a per-BSS basis, which is
> the basis of how all APs offer service to clients/stations (STAs)?

No, but it also doesn't provide for it.


> RFC 3580 does specify that Access-Requests will be scoped to a
> per-BSSID/per-SSID basis via the Called-Station-Id, so why not
> implement the same behaviour for accounting?

Because RFC 3580 doesn't say Accounting-Requets will be?

RFC 3580's comments are likely about the scope of authentication.
i.e. The RADIUS server should perform autz based on the user and the
BSSID.

RFC 2866 says:

5.1.  Acct-Status-Type


   Description

      This attribute indicates whether this Accounting-Request marks the
      beginning of the user service (Start) or the end (Stop).

      It MAY be used by the client to mark the start of accounting (for
      example, upon booting) by specifying Accounting-On and to mark the
      end of accounting (for example, just before a scheduled reboot) by
      specifying Accounting-Off.

   A summary of the Acct-Status-Type attribute format is shown below.
   The fields are transmitted from left to right.

A client is a RADIUS client, not a service.

> In the Aerohive model, there are no central controllers - each AP is a
> RADIUS client.

Yes, it's lovely.

> Without the Called-Station-Id, there is no specificity to an
> Accounting-On or Accounting-Off and they become a blunt instrument,
> and actually rather useless/meaningless.

No, they're still extremely useful just not for your particular use case.
If BSSIDs go up/down the AP should send stop messages for the active
sessions. If it's not, that's an issue, and that should be fixed.

Accounting-On/Off packets have traditionally been a last resort thing,
where the system is about to restart, or went down in a non-clean fashion.

> It doesn't match how APs
> actually operate so things should change.

Start attending IETF meetings then.

> Yes, it has not been traditionally done.
> 
> The RADIUS accounting spec was written long before wireless NASes
> existed, but I actually think that it would make sense for all
> wireless vendors to align to this model - scoping to the BSS with the
> Called-Station-Id and sending Accounting-On and Accounting-Off on a
> per-BSS basis (which means sent on a physical AP basis, even where
> it's actually transmitted by a central controller).
> 
> This already happens for Access-Request packets, and
> Accounting-Request packets with Start, Interim-Update and Stop with
> most vendors in this space via the Called-Station-Id.

It would be useful. But it's pushing the burden of complexity onto the
RADIUS server. I think explicit stops are better for normal operation
than bulk session closes using Accounting-Off.

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150521/1b21ee6e/attachment-0001.sig>