Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt

From: <[email-masked]>
Date: Tue, 6 Jul 2004 17:42:53 +0300

> OK, but how is this problem solved by _not_ including the 
> Service-Identifier in the CER/CEA?  It seems like what you 
> are saying is that CCA just won't work through relays... 

Actually I was thinking to your proposal....
I think the DCC should just work fine with relays too.

> I think that the existing capabilities exchange mechanism is 
> sufficient, if used properly.  This mechanism seems to me 
> (please correct me if I'm wrong -- I can't find any rationale 
> in the I-D, but maybe I just missed it) to be just a way to 
> avoid having to get a new app ID from IANA, but that seems a 
> poor reason to break Diameter.

Hmm...'break Diameter' it seems a bit to strong statement.
The application is always the DCC, no reason to define new app ID.
The rational for the service-id is explained in section 4.1

clip

  'The Diameter Credit Control Application defines the framework for 
   credit control; it provides generic credit control mechanisms 
   supporting multiple service applications. The Credit Control 
   Application, therefore, does not define AVPs that could be used as 
   input in the rating process. Listing the possible services that could 
   use this Diameter application is seen as out of scope for this 
   generic mechanism as well.' 

Because we couldn't define all the possible rating inputs for all the
possible services (i.e. the attributes to qualify the service and
determine its price), the service-id was introduced as primary
'rating root' so that the server knows immediately whether the
requested service can be rated before to perform very expensive
operations such as invoking the rating process and eventually reject 
the request.

> I still don't see how this really helps much.  For example, 
> suppose that the only route from an access point to a set of 
> n>1 servers (all of which support CCA, but only 1 of which 
> supports the correct service) is through a relay.  It doesn't 
> seem to matter how many CER/CEA exchanges take place between 
> the client and the relay, unless the relay happens by chance 
> to send the CCR to the right server the protocol will fail.  
> Put another way, in the pathological case the relay might 
> _never_ select the right server.

The DCC rely on two different models, assuming your access point 
perform service specific authentication/authorization with a AAA server:

1- The AAA server returns in the AA-answer the FQDN of the credit-control
   server(s) that support this service. The DCC-client will contact then the
   server to perform credit authorization.
2- If the model defined in sect. 5.2.2 is used, the AAA server advertises support
   for the DCC. The relay sends the request to this AAA server, which then select
   the appropriate CC-server on the basis of its knowledge of the user and
   requested service. Communication with the CC-Server continues via the AAA
   server.

Hope this clarify
Marco

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 6 Jul 2004 14:37:26 -0700

[email-masked] <mailto:[email-masked]> writes:

Just for my own edification, since I'm obviously missing something...

>> Service-Identifier in the CER/CEA?  It seems like what you are saying 
>> is that CCA just won't work through relays...
> 

I guess I'll just take your word for it & drop the matter.

>> sufficient, if used properly.  This mechanism seems to me (please 
>> correct me if I'm wrong -- I can't find any rationale in the I-D, but 
>> maybe I just missed it) to be just a way to avoid having to get a new 
>> app ID from IANA, but that seems a poor reason to break Diameter.
> 

OK.  My assertion was based on the belief that a DCC message could be routed correctly (from a Diameter POV) and still arrive at a peer that could not understand it.  Is that not the case?  

> The application is always the DCC, no reason to define new app ID.

OK.  So I guess that you are saying that any DCC message can be routed to any DCC server and it will be understood?  I didn't get that from the I-D.

>    input in the rating process. Listing the possible services that
>    could use this Diameter application is seen as out of scope for
>    this generic mechanism as well.'

Hmm.  Maybe I'm right after all, then...it's quite confusing.  My claim would be that what is actually specified in the document is an application framework, not an application (again, in the RFC 3588 sense of the term); your quote seems to justify this claim.

> determine its price), the service-id was introduced as primary 'rating 
> root' so that the server knows immediately whether the requested 
> service can be rated before to perform very expensive operations such 
> as invoking the rating process and eventually reject
> the request.     
> 
>> I still don't see how this really helps much.  For example, suppose 
>> that the only route from an access point to a set of
>> supports the correct service) is through a relay.  It doesn't seem to 
>> matter how many CER/CEA exchanges take place between the client and 
>> the relay, unless the relay happens by chance to send the CCR to the 
>> right server the protocol will fail. Put another way, in the 
>> pathological case the relay might _never_ select the right server.
> 
> 1- The AAA server returns in the AA-answer the FQDN of the
>    credit-control server(s) that support this service.

OK.  How does the AAA server know which of the (possibly many) DCC-servers supports this particular service, since the Service-Identifier in not included in the CER/CEA messages?  Is it a configured parameter?

>    The DCC-client
>    will contact then the server to perform credit authorization.
> 2- If the model defined in sect. 5.2.2 is used, the AAA server
>    advertises support for the DCC. The relay sends the request to
>    this AAA server, which then select the appropriate CC-server on
>    the basis of its knowledge of the user and requested service.
>    Communication with the CC-Server continues via the AAA server.

Again, it's not really clear to me how the AAA server knows which is the appropriate CC-server.

> Marco

Apparently dense,

~gwz

"They that can give up essential liberty to obtain a little temporary safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." 
-- Voltaire