Re: Issue 111: Accounting

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Here is what RFC 2866 says about the notion of an Accounting Session:

  When a client is configured to use RADIUS Accounting, at the start of
  service delivery it will generate an Accounting Start packet
  describing the type of service being delivered and the user it is
  being delivered to, and will send that to the RADIUS Accounting
  server, which will send back an acknowledgement that the packet has
  been received.  At the end of service delivery the client will
  generate an Accounting Stop packet describing the type of service
  that was delivered and optionally statistics such as elapsed time,
  input and output octets, or input and output packets.  It will send
  that to the RADIUS Accounting server, which will send back an
  acknowledgement that the packet has been received.

As Greg noted, the Service-Type is not being changed here, so that the 
Service is continuing, and sending of additional Start/Stop messages is 
somewhat odd.  Also, do we really want individual RADIUS attributes to 
provide their own definitions of when a new session is started and stopped?  
RADIUS accounting is a separate protocol from RADIUS authentication, and 
runs on a separate port.  Authentication attributes that affect accounting 
(Class, Acct-Interim-Interval) have to date been general ones.  Terminating 
the Accounting Session in mid-stream could cause issues with RADIUS 
implementations that use the Accounting Records for things like simultaneous 
usage control.

For Tunnel Accounting (RFC 2867) the issue was handled by defining a new 
value for Acct-Status-Type rather than using Start/Stop.  For example:

      1      Start
      2      Stop
      3      Interim-Update
      7      Accounting-On
      8      Accounting-Off
      9-14   Reserved for Tunnel Accounting
     15      Reserved for Failed

Paul Congdon said:

At IETF-64 we reviewed this issue.  There did not seem to be any
objection to having compliance statements in the Annex given that this
Annex is where the context for the statements is developed.  Also, since
a new session is created, as stated in the draft, there is no need to
use INTERM messages.

---------------------------------------------------------------------------------
Issue 111: Accounting
Submitter name: Greg Weber
Submitter email address: gdweber@cisco.com
Date first submitted: August 10, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html
Document: IEEE802-00
Comment type: T
Priority: S
Section: A.3
Rationale/Explanation of issue:

The accounting requirements do not seem to be fully treated
by the draft.  Section A.3 has a MUST requirement related to
accounting.  I would think that MUST requirements should be
treated by the text, not in an appendix.  Why does redirection
require a STOP/START pair?  Can't this information be conveyed
via an INTERIM record for the same session?  If the Service-
Type is not changing, I'd think that an INTERIM would suffice.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>