Subject: [AAA-WG]: Issue 408: Another Diameter Credit Control Review

From: Bernard Aboba <[email-masked]>
Date: Wed, 21 May 2003 06:23:03 -0700 (PDT)

Submitter name: Avi Lior
Submitter email address: [email-masked]
Date first submitted: May 9, 2003
Reference: http://www.drizzle.com/~aboba/AAA/lior-comments.txt
Document: CC-00
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
General Comments
Use of Authentication\Authorization messages.

As mentioned before (in various emails) I belive that the correct way
(from a philosophical point and technical point) is to use
authentication and authorization messages. I belive you have received
comments to this effect from other people so I won't bother to repeat
myself or others.

Protocol Efficiency

In many domains where this application will be applicable, the user is
authenticated and authorized to use the service. Part of the
authorization service is to perform Credit or Prepaid authorization. The
problem with the current document is that it *forces* the Credit
Authorization or Prepaid Authorization to be performed after the Service
Authroization. This creates a problem: First, the credit authorization
has to traverse the network again. Since both authorization are done in
the Home network, it seems silly to have to traverse the network again.
Second and more importantly, the delay in having to perform this
operation as a seperate step is not acceptable in many application. This
*must* be addressed to have this document acceptable as a generic
solution. This is not a specific 3GPP solution right?

Types of Credit Control

It would be nice if several applicable scenario be presented. For
example, its not clear whether the intent of this application is to
cover Prepaid Data Services.

How are time and volume based applications handled?

What about roaming considerations?

Applicability in other than 3GPP operating environments

This document is intended as a Standard Track therefore, it should work
in general operating environments. That is, environments other than
3GPP. There are certain concepts here that work well in the 3GPP but not
so well in other environments. For example, the notion that a Credit
Control Client can request the user's account balance, or the cost of a
service is not appropriate in all conditions. This particular problem
was brought up in the past and sadly not addressed in this version. I
have no problem if the authors dont want to address these issues.
However, they should submit the document as an Informational Document,
documenting how 3GPP does things.

Redirect

In many instances in the text the action to take when a user resources
are no longer available is to terminate the session. That is one
possible action, the other possible action is to restrict access (or
direct the user) to a portal where they can recharge their account
etc...

Detailed review comments are available below:

http://www.drizzle.com/~aboba/AAA/lior-comments.txt

---

From: <[email-masked]>
Date: Thu, 22 May 2003 11:36:43 +0300

Hi Avri,

> comments to this effect from other people so I won't bother to repeat

I think we should have a discussion on this point, I'll try to start it
in a seperate mail.
 
> operation as a seperate step is not acceptable in many application. 

I think we can discuss the model of forcing the service authorization.
As there can be many different types of service - network access;
SIP services, VOIP services, etc.; the model should be flexible to
allow staged authorizaiton.

> This *must* be addressed to have this document acceptable as a generic

Currently, 3GPP has taken the lead for this type of application.  We've started
with their requirements.  It might be help for others to outline what there
needs / requirements are, so we can take them into account.

> cover Prepaid Data Services.

We have added this.

> What about roaming considerations?

We will consider these - what are the requirements you are thinking need
to be met.

> Applicability in other than 3GPP operating environments

See above (suggestions & models are helpful)

> in general operating environments. 

Actually, this is not necessarily the case.  There are plenty of existing
proposed standards which define solutions that are very specific uses,
networks & architectures.

> That is, environments other than
> service is not appropriate in all conditions. 

So, in some cases, you are saying, that a Credit Control client may not be
authorized to recieve the user's account - is that correct?  I think that
this functionality useful, but perhaps we need to have a way to deny
the account balance inquiry, correct?

> direct the user) to a portal where they can recharge their account

This is potentially doable.  How do you envision such functionality to
be handled?  Would it configurable based upon the service provider?  
This functionality, though, could be very tricky to get right.  For example,
you could imaging a scenario where you are using a pre-paid account to
view streaming content via a 3rd party.  If your account runs out, the
stream should be stopped as the 3rd party has no way to be paid for the
rest of the content.  The user, of course, could add credits to his/her
account and re-attach to the streaming server where they left off.

This, however, seems very service specific.  My gut feeling is that
all we should do here is have a way to notify the user when the user
is low on credit and terminate when the user runs out.  If services
want to add more functionality, it is probably best handled at 
the service level.

br
John

---

From: <[email-masked]>
Date: Thu, 22 May 2003 13:45:58 +0300

Hi Avi,

> comments to this effect from other people so I won't bother to repeat

So, it depends upon what functionality you are looking at.  On one hand,
you are authorizing a service.  On the other hand, you are debiting /
crediting someone's account.  I think this is the rub.  It is feasible
to use authorization, but you still have to perform some accounting.

Bernard made this comment:

 It seems cleaner to me to use a conventional authentication
 request/response sequence to inform the Diameter server of
 the requested service, and have the Diameter server do the
 service rating, and check the user's credit allocation.
 The Diameter server can then return the allocated resource
 usage prior to re-authorization. When the Diameter client
 has expended the allocated resources it will send a
 re-authorization request (actually you probably want
 it to send one sooner in case there are delays). The
 Diameter server can then check the user's credit
 limit and the service rating again and allocate more
 resources, or deny the request and force the user off.

I think that this may be an interesting way to provide the functionality,
so we are looking into how we could integrate it into the current document.

One note about 3GPP.  3GPP already has specified a way to do this kind
of prepaid service with Diameter (which is partly the basis for the CCA
draft).  I think a good solution to the problem would be to create 
the Diameter application that would support both the 3GPP architecture
and a more generic architecture.  We are trying to clean-up a lot
of text in the current document in order to accomplish this.

John

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 22 May 2003 13:10:21 -0700

Hi,

  For those willing to look at PowerPoint vs. ASCII art sequence diagrams,
on slide #4 I have a diagram of the interaction model for credit control at:

  http://www.circumference.org/circumference.ppt

  The AAA server is labled "IPDR Prepay", but it also shows the other 
likely relevant elements in the flow of information which include a
balance manager and a rating system.

  Note that there is a distinction between debiting the account and
reserving the account.

  Just like when you register at a hotel, they authorize and reserve some
monies against your credit card, they don't actually charge you until 
you check out; the prepay scenario is the same.

  Also diagrammed is the "InterimAccounting" which is a somewhat hybrid
operation because the service element is both indicating that some
service was delivered (accounting) and that there is a desire to reserve
more balance (authorization).

Regards,

  Jeff Meyer

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, May 22, 2003 6:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [AAA-WG]: Issue 408: Another Diameter Credit Control Review

> Are you suggesting something like this:
>
> NAS		AAA Server
> -------auth req----->
>                        a) check user credit
>                        b) if OK, deduct amount (if approriate)
> <------auth  ans ---	  and reply

a) but not b). The auth req/ans sequence does not demonstrate that the
service event has actually occurred -- that is what accounting messages do.
So while you can check user credit (and place limits on session-time and
other
resources) via the answer it is probably not appropriate to credit/debit
at that time. This can wait until the accounting messages are sent.

> some time goes by
>
> -----re-auth req----->
>                        a) check user credit
>                        b) if OK, deduct amount (if approriate)
> <----re-auth  ans ---	  and reply

In this figure, I'm not clear whether we're talking about
re-authentication or re-authorization. I hope it's the latter.  What we
need in the first authentication answer is AVPs which give the time
(or other resources) until session re-authorization (NOT
re-authentication).  The RADIUS Session-Time attribute isn't appropriate for
this, since it forces re-authentication when Termination-Action=1 (RADIUS).
So you need to define new AVPs, I think.

Assuming that this is done, on re-authorization the user credit is checked
again, and new time/resources can be allocated to the session.  Note that
it is also possible to initiate re-authorization from the Diameter/RADIUS
server side, via dynamic authorization messages.  Thus, the server can
check the declining user credit via the interim accounting messages and
decide to change the allocated resources/time at any point.

---

From: Avi Lior <[email-masked]>
Date: Thu, 22 May 2003 18:39:49 -0400

Hi John,

I am on vacation so I can't get to the email as often as I would like ;-)

Note that 3GPP2 or is in the process of defining a prepaid solution using
radius -- see IS-835C Chapter 6 ( I can get it you if you can't).  I also
have an IETF I-D that I will update to line up the 3GPP2 solution.  So you
guys are not the only or the first to do this.(this is to address a comment
in a previous email)

It would be very good if you can, at least in a prepaid scenario, allocate
an initial quota during the authentiction/authorization phase.  This will
address the latency issue I brought up.

Second, use re-authorization messages to re-allocate quotas.  This would
line up with RADIUS nicely when you have to interoperate.  And we will have
to interoperate! In 3GPP2 for example and in the all RADIUS WLAN world.  

In the RADIUS world Accounting messages are just not usable for this type of
interaction.  Its not a philosophical point (although it does stem from the
fact that accounting message in both RADIUS and DIAMETER are meant to report
or record an event that happened and not to be used for controlling a
session).  In RADIUS accounting messages can be stored by intermediaries and
forwarded at a later time.

More comments inline.....

> From: [email-masked] [mailto:[email-masked]] 
> Sent: May 22, 2003 6:46 AM
> To: [email-masked]; [email-masked]
> So, it depends upon what functionality you are looking at.  
> On one hand, you are authorizing a service.  On the other 
> hand, you are debiting / crediting someone's account.  I 
> think this is the rub.  It is feasible to use authorization, 
> but you still have to perform some accounting.

You are really not doing accounting.  And certainly you are not doing
accouting in the RADIUS/DIAMETER context which view accounting as a
recording function and not something you act on.

What your application is doing is debiting and crediting a resource (a users
account) we debit and credit resources all the time in RADIUS and DIAMETER.
For example, when a user logs on we increment a counter, and when he logs
off we decriment a counter.  This way we can enforce how many concurrent
logins a user can have.  This is an accounting function right? But you would
never do it using accounting records.  So just because you are debiting and
crediting money from a user's account that doesn't necessarily make it
accounting in the RADIUS/DIAMETER context.

> service rating, and check the user's credit allocation.  The 
> Diameter server can then return the allocated resource  usage 
> prior to re-authorization. When the Diameter client  has 
> expended the allocated resources it will send a  
> re-authorization request (actually you probably want  it to 
> send one sooner in case there are delays). The  Diameter 
> server can then check the user's credit  limit and the 
> service rating again and allocate more  resources, or deny 
> the request and force the user off.
> 
> I think that this may be an interesting way to provide the 
> functionality, so we are looking into how we could integrate 
> it into the current document.
> 
> One note about 3GPP.  3GPP already has specified a way to do 
> this kind of prepaid service with Diameter (which is partly 
> the basis for the CCA draft).  I think a good solution to the 
> problem would be to create 
> the Diameter application that would support both the 3GPP 
> architecture and a more generic architecture.  We are trying 
> to clean-up a lot of text in the current document in order to 
> accomplish this.

I look forward to see the next draft.
 
> John
Looking to offer a managed WLAN Service? Download our market report, completed by Telechoice Market Analyst group, to learn more. <a href="http://www.bridgewatersystems.com/learnmore">http://www.bridgewatersystems.com/learnmore</a>

---

From: Avi Lior <[email-masked]>
Date: Thu, 22 May 2003 18:55:58 -0400

I have some issues with these scenarios at least from a Prepaid context. See
inline.

> Sent: May 22, 2003 9:08 AM
> a) but not b). The auth req/ans sequence does not demonstrate 
> that the service event has actually occurred -- that is what 
> accounting messages do. So while you can check user credit 
> (and place limits on session-time and other
> resources) via the answer it is probably not appropriate to 
> credit/debit at that time. This can wait until the accounting 
> messages are sent.

You can debit the users account when the next Prepaid Authorization message
comes in.  So that when the NAS askes for more resources using the
authorization message you can commit the previously allocated amount at that
time.  This way you don't need accounting messages.  One thing is that you
want to generate an Authorize only message when the session ends (similar to
account stop message).

This is what 3GPP2 is doing for prepaid.

> re-authentication or re-authorization. I hope it's the 
> latter.  What we need in the first authentication answer is 
> AVPs which give the time (or other resources) until session 
> re-authorization (NOT re-authentication).  The RADIUS 
> Session-Time attribute isn't appropriate for this, since it 
> forces re-authentication when Termination-Action=1 (RADIUS). 

The AVP mentioned above is the PPAQ AVP used in 3GPP2.

> Assuming that this is done, on re-authorization the user 
> credit is checked again, and new time/resources can be 
> allocated to the session.  Note that it is also possible to 
> initiate re-authorization from the Diameter/RADIUS server 
> side, via dynamic authorization messages.  Thus, the server 
> can check the declining user credit via the interim 
> accounting messages and decide to change the allocated 
> resources/time at any point.

I just want to make sure that accounting messages are not needed for these
applications at all.  If they are available in real-time they can help in
tracking a sessions progress.  If they are not available in real-time they
can be used for post checking (consolidating accounts) and error recovery.
You can do everything using Auth and Authz messages.
Looking to offer a managed WLAN Service? Download our market report, completed by Telechoice Market Analyst group, to learn more. <a href="http://www.bridgewatersystems.com/learnmore">http://www.bridgewatersystems.com/learnmore</a>

---

From: <[email-masked]>
Date: Fri, 23 May 2003 10:38:41 +0300

Hi Avi,

> guys are not the only or the first to do this.(this is to address a comment

I never suggest that 3GPP was the only one doing this, they already do have
a 3GPP standard using Diameter completed.  That was more my point.
 
> address the latency issue I brought up.

As I understand, this is what the current 3GPP2 spec proposes.

> to interoperate! In 3GPP2 for example and in the all RADIUS 

Well, perhaps I should re-read the proposed 3GPP2 spec, but I was under
the assumption that after the initial quota is met, accounting messages
are used to report the used quota and request an additional quota.  I'll
try to dig around and find the spec ...

> forwarded at a later time.

Of course, we are defining a Diameter application, not a RADIUS application.
We should consider how to interwork with RADIUS for certain scenarios, but
I guess I have not seen a requirement that everything done in Diameter
MUST be equally usuable with RADIUS.

John

---

From: Avi Lior <[email-masked]>
Date: Fri, 23 May 2003 13:08:50 -0400

John,

> Well, perhaps I should re-read the proposed 3GPP2 spec, but I 
> was under the assumption that after the initial quota is met, 
> accounting messages are used to report the used quota and 
> request an additional quota.  I'll try to dig around and find 
> the spec ...

Regarding 3GPP2: during V&V we changed prepaid to work with Access Request
messages.  On-line Accounting is not used anymore.  This will make it easier
to work with other RADIUS scenarios such as WLAN.
 
> Of course, we are defining a Diameter application, not a 
> RADIUS application. We should consider how to interwork with 
> RADIUS for certain scenarios, but I guess I have not seen a 
> requirement that everything done in Diameter MUST be equally 
> usuable with RADIUS.

I will leave the "MUST" to the AAA-WG.  But IMHO, RADIUS is not going to die
any day soon so we SHOULD make sure that Diameter interopperates with
RADIUS.  For example, recently CHIBA went a "major" change to make sure that
it would interoperate with DIAMETER deployments.

Avi