Subject: Re: (radius) Accounting-On question

From: "Claudio Lapidus" <[email-masked]>
Date: Sat, 25 May 2002 13:16:10 -0300

Hello Victor,

>Assuming that RADIUS client sends Accounting-On/Off, suppose Accounting-On
>does not reach the server...
>
>a) Should Accounting-On be re-transmitted? (probably "yes"),

Always according to local policies regarding retransmissions. Some clients 
let you define multiple target servers, adjust the max time allowed before a 
sent packet is declared unacknowledged, if that timeout remains constant for 
succesive retransmissions or if it is going to increase for each attempt, if 
multiple servers are to be tried in a "failover" or "round-robin" mode, etc.

>b) Should the client not send Start/Stop messages until Accounting-On is
>acknowledged?

I don't see why. Radius protocol is stateless in nature. It is designed to 
make each message independent of any other, and this is the way to properly 
implement it. If a certain message wasn't acknowledged, the client may elect 
to take some extra steps to attempt its delivery, but this is unrelated to 
what to do with new events that merit new mesages to generate and transmit, 
I think.

>c) If the answer to (b) is "yes", then should no service be allowed on the
>NAS until Accounting-On is acknowledged? Alternatively, if the service is
>allowed (or if RADIUS client is not a physical NAS and the concept of
>"service" is something entirely different), then what should RADIUS client
>do with sessions that are starting before Accounting-On is acknowledged?
>Queue  up the Accounting Start/Stops?

There are different postures here. Depending on the nature of the service 
being provided (and how critical you consider its accounting), some 
implementations allow you to not actually start user's service until the NAS 
gets an acknowledge _for an Accounting Start message_. Of course, this is 
rather restrictive from a service point of view, but it guarantees that no 
service is delivered without proper accounting. Other implementations tend 
to prioritize service delivery as their main function and leave tha acct 
funcionality as an accesory one. However, I cannot remember any client being 
so restrictive with regard to an Acct-On or Acct-Off message.

>
>My assumption is that Accounting-On is most useful when RADIUS server
>manages some resources, such as IP pools, based on the session state. Thus
>when Accounting-On is received, the server can clean up all sessions in
>progress from that client.

That's exactly the way it works for most servers, yes.

However, if after RADIUS client restarts an
>Accounting-Start reaches the server before Accounting-On, it is likely that
>the server will loose state synchronization with the client and will free
>resources still in use.

As in the previous case, when the server receives an acct-start message it 
allocates a resource to the client. Then, when it receives tha acct-on, it 
releases it. Wasn't it supposed to behave that way? How could the server 
tell an out-of-sequence message from a correctly sequenced one? I think this 
is a very special and stretched case, not often found in common remote 
access scenarios, where Radius has its main application.

Probably the main point here is the old discussion that tries to state if an 
Accounting-Response message is to be considered as a transport layer ACK or 
as an application layer one: when a server sends an Acct-Response is it 
saying to the client "I have received your message" or "I have received your 
message and made sure that the application layer has taken care of it"? You 
may want to consult RFC2975 for a very insightful explanation of the point.

Going back to your question "c)", I would like to remind you that Radius was 
designed with the specific goal of centralize AAA information for remote 
access service. If you want to use its syntaxis and message structure to 
manage "some entirely different concept of service", certainly you can try, 
but you may well end up with a very specialized implementation that doesn't 
easily interoperates with any other implementation out there, unless they're 
already "service-aware", and here I say "service" in the restricted way you 
put it. I think that you'll have to pay very close attention to what the 
semantics implies in each of these cases.

regards,
cl.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.