Subject: [AAA-WG]: separated authorization and accounting servers? (resend, sorry if you get this twice...)

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Apr 2001 11:43:51 +0300

Hello,

We've been trying to figure out if the current
version of the Diameter specs allow accounting
and other traffic to be directed to different
servers. Traditionally, we've had this feature
in RADIUS. It might even be conceivable that there
be uses of accounting where there is no authentication
or authorization at all on a node that gives a service.

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.

Do we allow two proxies to be configured for a client
node, one for the authentication and authorization, and
the second one for accounting?

And whatever we say, why are we saying so?

Jari

---

From: "John Alayari" <[email-masked]>
Date: Wed, 18 Apr 2001 09:12:28 -0700

Jari,
I totally agree. The base spec should allow separation of
Authentication/Authorization from Accounting on both client and server side.
And section 13.1 should be reworded to support this. Let me give an example
that shows why we need that:

In the following example, client 1 is the session controller (e.g. SIP
server) and
the client 2 is bearer of data. Please note that, there may be multiple
nodes acting as client for the same session. Server 1 does the
authorization/and authentication function and server 2 does the accounting
only.

The authorization-server directed model here mean that the accounting
policies(accounting records timeliness, etc.) in server 1 are transferred to
client 2 in step 4. and that is communicated to server 2 in step 5.

            ------                   ------
1)Orig Msg |Client|  2)Access Req.  |Server|
 --------->|  1   |---------------->|  1   |
           |      |<----------------|      |
            ------   3)Access Resp.   ------
              |
              | 4) Access/Auth-indication
              |
              V
            ------                   ------
6)Data     |Client| 5)Acct Req.     |Server|
<--------->|  2   |---------------->|  2   |
           |      |<----------------|      |
            ------  6)Acct Resp.     ------

John.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Jari Arkko
Sent: Wednesday, April 18, 2001 1:44 AM
To: [email-masked]
Subject: [AAA-WG]: separated authorization and accounting servers?
(resend, sorry if you get this twice...)

Hello,

Jari

---

From: "David Mitton" <[email-masked]>
Date: Thu, 19 Apr 2001 10:18:37 -0400

Yes,
   you can devise all sorts of scenarios where separated Accounting and 
Authentication make sense.  Some people do it RADIUS.

However,
         Accounting messages are essential to session state keeping 
Authorization servers, and since we have not added any Session Terminate 
Report messages, I think Accounting should be Mandatory back to the Auth 
servers.

If you want to split off the stream at a proxy, or devise NASes that copy 
the stream to multiple targets, that's fine with me.

I'm also really having trouble digesting your example in real terms.
The splitting of functions between your client 1 and 2 seems rather 
awkward.  How many systems are keeping session state?  Whom actually 
implements the session service?

         Dave.

At 4/18/01 12:12 PM -0400, John Alayari wrote:

>From: [email-masked] 
>[<mailto:[email-masked]>mailto:[email-masked]]On Behalf
>Of Jari Arkko

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    [email-masked]

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 24 Apr 2001 16:14:42 -0700 (PDT)

> or authorization at all on a node that gives a service.

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...

> 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.

> 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.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 24 Apr 2001 16:26:31 -0700 (PDT)

> Report messages, I think Accounting should be Mandatory back to the Auth 

Huh? The base protocol defines the STR message, which does just that. I really
want to avoid re-using accounting messages to maintain state information.

PatC

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Apr 2001 00:04:59 +0300

> 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,
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.

> messages. Is this not clear in the draft? If not, it certainly needs to be

Well, consider the case of some random node using Diameter accounting to
produce accounting data for e.g. statistics purposes. Can we do that?

> It used to be possible, and is in RADIUS, but no longer in -02 due to the

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.

Jari

---

From: "David Mitton" <[email-masked]>
Date: Wed, 25 Apr 2001 17:25:57 -0400

>want to avoid re-using accounting messages to maintain state information.

You're right.
Hmm... somehow I'm confused.  I'll go off and sort out my confusionination.

I do agree with a separate point Jari makes in a later message, there will 
be people that will want to implement Accounting for accounting's sake, 
independent of the Auth/Auth stream.   Perhaps we need to call out that as 
a different "application".

Dave.

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 26 Apr 2001 06:53:22 -0700 (PDT)

> It isn't clear to me why the extension id or the RFC structure makes a 

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.

> a network server is configured with the address of the main AA server, plus

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 :(

> 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.

> next node is a proxy shouldn't make a difference.

see above.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 26 Apr 2001 06:55:46 -0700 (PDT)

> a different "application".

Why does this sound like I'll be spliting the base back into two documents...
:(

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 26 Apr 2001 11:49:52 -0700 (PDT)

> Patrice Calhoun [mailto:[email-masked]] writes:
> 
> Changing the format of the documents doesn't solve the problem.

When accounting was separate, it had its own extension. When an accounting
message was en-route towards the home domain, a specific accounting server
could advertise itself in the home network, and we could guarantee that all
accounting messages would be sent to that particular server.

As it stands right now, accounting messages would be sent to *any* server in
the home domain, unless the proxies were (manually) configured for a specific
Accounting server, which is how RADIUS works today.

Perhaps this is enough.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 26 Apr 2001 11:41:49 -0700