Subject: Re: [AAA-WG]: comment on diameter credit control

From: Kuntal Chowdhury <[email-masked]>
Date: Thu, 03 Apr 2003 18:28:37 -0600

Harri Hakala (LMF) wrote:
> Kuntal Chowdhury wrote:
> 
> 
>>OK, then what the credit control server is doing? Most likely 
>>it looks at the 
>>account balance of the user and then it allocates a portion 
>>of the balance (unit 
>>if you will) to the service element for the user's session. 
>>If the account 
>>balance is "nil" then the credit control server has to reject 
>>the request from 
>>the service element. The action of the credit control server 
>>i.e. checking 
>>account balance + allocating portion of balance if available 
>>is what I call 
>>"authorization" of the service. I think "authorization" of 
>>the service needs to 
>>involve the credit control server. There is no point in 
>>authorizing a user for a 
>>service that he/she cannot use because the account balance 
>>for that service is 
>>nil or too low.
> 
> 
> The draft just proposes that the authorization should be done in two phases.
> First the service element shall transfer user authentication and service specific 
> authorization information to the AA server to know whether the end user is allowed
> to access to the service, i.e. to validate that the user has a subscription for the
> service, right category, etc. The way how the authentication and authorization will 
> be performed and the application specific authentication and authorization messages 
> that can be used are out of scope of the draft. The messages defined in other Diameter 
> applications or other authentication and authorization protocols can be used. 
> Note that the AA-applications are not impacted and you don't need to update these
> protocols due to the credit control application. So the existing service specific 
> authentication and authorization protocols do not need to carry any credit control 
> specific parameters, e.g. rating input parameters, granted units, etc. 
> 

What you are talking about is service authorization w/o an account balance 
verification. This should be OK for a non-prepaid user who does not require a 
credit check. When the AAA server receives the authorization request from a 
service element it can determine whether the user has a prepaid account for that 
particular service (or may be prepaid account in general for all services) by 
looking at the user's AAA profile. If yes, the AAA server should authorize the 
request based on the remaining balance left in the user's prepaid account. If 
the credit control server is collocated with the AAA server, then it becomes a 
simple query. If the credit control server is located outside the AAA server, 
then the AAA server can use the same auth messages that you propose that the 
service element uses to talk to the credit control server. I think this is a 
much cleaner and quicker way to authorize a user's request. By doing service 
authorization and account balance check in one shot reduces the possibility of 
delay in service initiation which may be critical factor for real-time services.

> If all is in order, then the service element can start to use the credit control application. 
> In other words the service element shall initiate 'credit control authorization' towards the
> credit control server by using ACR/ACA messages containing the credit control AVPs to do tasks
> which you describe above (and described in the chapter 3.1).
> 

As I mentioned above, this type of mandatory two step process to authorize every 
service request increases the service setup time.

> In summary, the draft suggests that the 'authorization' should be done in two phases; first the 
> AA server validates whether the user is allowed access to the service, secondly the credit 
> control server checks the user's account for coverage for the requested service event (and 
> allocates the initial quota). It also defines that both 'authorization' phases can be done by 
> using separate protocols and these applications do not need to have interdependences.
> 

I am suggesting to allow one step process as well.

-Kuntal

---

From: Kuntal Chowdhury <[email-masked]>
Date: Thu, 03 Apr 2003 18:45:44 -0600

Harri Hakala (LMF) wrote:
> Kuntal Chowdhury wrote:
> 
> 
>>IMHO, the simple examples of service elements are P-CSCF, MMS-C, 
>>AGW/GGSN/PDSN/HA. I don't think these network elements should 
>>care about price 
>>of a service. In a roaming situation, the home network most 
>>likely will not be 
>>happy to share it's price-per-service details with the 
>>visited network's service 
>>element.
>>
>>........ 
>>
>>I don't think it's a good idea to let the service 
>>elements/nodes to meddle with 
>>price of a service. I don't think carrier's will like to 
>>distribute this info 
>>across network elements. Price is something that the 
>>carrier's like to deal 
>>directly with the end-user. The end-user can 
>>discover/negotiate price of a 
>>service through application (https://, phone call) etc. 
>>rather than intermediate 
>>nodes being involved. I hope we can converge on this issue.
> 
> 
> The purpose is that the credit control application is a general purpose real-time
> accounting protocol for various applications & services, so there will be various 
> types of service elements in different kind of systems as well. Some of these network 
> elements may provide support of sending cost estimation to the end user.
> 

If these service elements are wholly owned by the provider of the said service 
(the same owner of the credit control server) then I can see your point. However 
there is no guarantee that will be the case. It is totally upto the service 
provider's policy to distribute price info freely to any service element or not.

> Some systems have requirements to provide at the beginning of a chargeable event an indication
> to the charged party of the charges to be levied for the event.
> There are also services (advice of charge kind of) that provides the user with information
> about the applicable charging rate or cost estimation at session establishment or when 
> cost of the service change during the session. We thought that the credit control application
> should also provide the capabilities to support these kind of services. The way how the service
> node then forwards this information to the end user is not scope of the draft. 
> 

I am not worried about what transport the service element will use to send this 
price info to the user. The thing I am not sure about is what makes the credit 
control server so sure that it can reveal the actual price of a service it is 
providing to the service elements which may be owned by a competitor. I believe 
the charge for a service should be negotiated a priori between the user and the 
credit control service provider. When you buy a prepaid account it tells you the 
price of the specific service. What you suggest is a close network where the 
service element and the credit control server are in cahoots with each other 
which may not be the case at all times.

> But of course we can discuss whether this support is really needed.
> 

Thanks for your consideration.

-Kuntal

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Fri, 4 Apr 2003 06:56:05 +0200

Hi Kuntal,

The drawback will be that you need to update all authentication and
authorization protocols to carry rating input parameters and credit
control parameters. Because the service element does not necessarily
know if the user is postpaid or prepaid, all authentication and 
authorization requests then need to carry these parameters.

Very often the credit control server is located outside the AAA server,
so the AAA server needs to establish the credit control session between
AAA server and the credit control server. When there is need for interim
request (session based credit control), the AAA server then acts as 
credit control proxy between the service element and the credit control
server Do we want that the AAA server start to be acting as the credit 
control proxy ?

Regards............Harri

> -----Original Message-----
> From: Kuntal Chowdhury [mailto:[email-masked]]
> Sent: 4. huhtikuuta 2003 3:29
> To: Harri Hakala (LMF)
> Cc: [email-masked]; [email-masked]; [email-masked];
> Leena Mattila (LMF)
> Subject: Re: [AAA-WG]: comment on diameter credit control
> 
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 4 Apr 2003 13:06:57 +0300

Hi all,

> Q1. What is a "home environment"? I guess it should be home network.

I'm editing the document right now, and will use the term 'home domain'
as this is consistant with the Diameter Base draft.

John

---

From: <[email-masked]>
Date: Fri, 4 Apr 2003 13:12:55 +0300

Hi all,
	
> server Do we want that the AAA server start to be acting as the credit 

I worry about this as well.  This gets very close to third party involvement,
which greatly increases various sercurity risks, etc.  I'd prefer to keep
a simple solution.  

A far simpler solution, would be that a user has multiple identities for
charging purposes, and uses those directly.  This would not be something
we need to specify, then, here.

br,
John

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Fri, 4 Apr 2003 13:55:16 +0200

> which may not be the case at all times.

We thought that there must be trust relationship between the credit control server and
credit control client, otherwise it is high risk to allocate quotas (and price information
as well) to an untrust client.

We have assumption (section 3) that the service element is located in the same administrative 
domain in which the end user's credit control server is located. It might be still possible that the
service element in the visited domain can offer services to the end user, but in that case a 
commercial agreement must exist between these parties. 

Regards........Harri

> Sent: 4. huhtikuuta 2003 3:46
> To: Harri Hakala (LMF)

---

From: <[email-masked]>
Date: Fri, 4 Apr 2003 17:14:44 +0300

> domain in which the end user's credit control server is 
> located. It might be still possible that the

That's exact, trusted relationship must exist.

Moreover if the user is using services in her home network the service
element (Application server) is located in the same administrative
domain, thus the price of the service is not delivered to a
service element of a competitor. Of course the IP packets conveying
the price to the end user will travel through an access device located
in the visited network, but I would assume in this kind of use cases
(e.g. user requesting the price of a service or requesting top-up
of the account) the proper end-to-end security mechanism such as
IPSec or TLS are used.

In case of services offered by the visited network I would assume
that price enquiry is not certainly directed to the home network of
the user, which cannot know the price of the service offered by
visited domain.

Regards
Marco

> From: ext Harri Hakala (LMF) [mailto:[email-masked]]
> Sent: 04 April, 2003 14:55
> To: 'Kuntal Chowdhury'
> Cc: [email-masked]; Loughney John (NRC/Helsinki); Stura Marco
> (NET/Helsinki); Leena Mattila (LMF)
> Subject: RE: [AAA-WG]: comment on diameter credit control
> 
> 
> Kuntal Chowdhury wrote:
> domain in which the end user's credit control server is 
> located. It might be still possible that the