Subject: RE: [AAA-WG]: separated authorization and accounting servers?

From: "Victor Manuel Avila Gonzalez (ECE)" <[email-masked]>
Date: Thu, 26 Apr 2001 16:18:08 +0200

See below

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: jueves 26 de abril de 2001 15:53
To: Jari Arkko
Cc: Patrice Calhoun; Jari Arkko; [email-masked]
Subject: Re: [AAA-WG]: separated authorization and accounting servers?

> 
> 
> Patrice Calhoun wrote:
> 
> > It used to when Accounting was a separate extension, but although I fought
> > hard to keep it an extension, WG comments was that Accounting MUST be in the
> > base protocol.
> > 
> > So, this is no longer possible, other than by manual configuration.
> > 
> > Unless we re-introduce the extension-Id for accounting in the base...
> 
> It isn't clear to me why the extension id or the RFC structure makes a 
> difference,

If an extension id is assigned to accounting, then it is part of the
capabilities exchange. Servers can specify that they wish to receive
accounting packets, while others do not. This can force accounting to go to
particular servers.

> but manual configuration is still possible? I think this covers the need 
> we had,
> a network server is configured with the address of the main AA server, plus
> the accounting server.

yes, manual configuration is still possible, but I would have thought we'd be
able to do better than RADIUS. I still think that making it part of the
exchange it the right way to go, but the base doesn't have an extension
identifier :(

> 
> > 
> >> But can we do this? We haven't figured out if the
> >> specifications say anything about this. Section 13.1
> >> talks about authorization server directed model, but
> >> I would classify the "direction" as optional information.
> >> Section 13.2 says servers that receive a succesfull
> >> authentication response must collect accounting information.
> >> But must they send it too? And can there be other nodes
> >> that would not perform authentication/authorization but
> >> who still produce accounting information (e.g. for
> >> trend analysis purposes)? Section 11 talks about user
> >> sessions and their life-cycle. But it doesn't seem to
> >> state anything about this issue in particular.
> > 
> > 
> > Not sure that I follow you here. Only the access device generates accounting
> > messages. Is this not clear in the draft? If not, it certainly needs to be
> > fixed.
> 
> Well, consider the case of some random node using Diameter accounting to
> produce accounting data for e.g. statistics purposes. Can we do that?

sure. Accounting does not have to following authorization. However, a policy
on a server MAY require that authorization be successful prior to accepting
accounting records for a particular extension.

___________________________________________________________________________
	Then, what does it mean the sentence in section 13.1??

"This accounting protocol is based on an authorization-server directed model"

	And how to understand the session state machine in section 11.1 where the action to move the state idle to pending ( I understand that this should be the first step when initiating a dialogue ) is  " send serv. specific auth req" ????

____________________________________________________________________________

> 
> > 
> >> Do we allow two proxies to be configured for a client
> >> node, one for the authentication and authorization, and
> >> the second one for accounting?
> > 
> > 
> > It used to be possible, and is in RADIUS, but no longer in -02 due to the
> > changes I noted above.
> 
> Now I lost you! Again, I'm not sure why the extension id makes a difference
> here. Yet you seemed to say first that by manual configuration this is 
> possible.
> Either the manual config is possible or not, but I don't think the fact 
> that the
> next node is a proxy shouldn't make a difference.

see above.

PatC