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

From: "Glen Zorn" <[email-masked]>
Date: Fri, 2 Jul 2004 11:25:59 -0700

Description of issue: No advertisement of service type in CER/CEA 
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 2 July 2004
Document: cca
Comment type: T
Priority: S 
Section: 1.3
Rationale/Explanation of issue: The Service-Identifier AVP is not included in the CER/CEA messages.
Lengthy description of problem:
Section 4.1, para. 6 states "it is the combination of support of the Diameter Credit Control Application and the service defined in the Service-Identifier AVP, which defines interoperability between any given credit control client and server."  However, inclusion of the Session-Identifier AVP in the CER/CEA exchange is not mandated.  This could lead to a situation where peers have successfully negotiated application support, but cannot interoperate. 

Requested change: 
Change section 1.3 from

   Diameter nodes conforming to this specification MUST advertise 
   support by including the value of 4 in the Auth-Application-Id of the 
   Capabilities-Exchange-Request and Capabilities-Exchange-Answer 
   command [DIAMBASE].  

to

   Diameter nodes conforming to this specification MUST advertise 
   support by including one or more Session-Identifier AVPs (corresponding to the supported 
   services) and setting the value of 4 in the Auth-Application-Id of the 
   Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE].  

Add Section 10.3:

10.3 Capabilities-Exchange-Request/Answer AVP Table 
    
   This section defines AVPs that are specific to Diameter Credit  
   Control Application and MUST be included in the Diameter 
   Capabilities-Exchange-Request/Answer (CER/CEA) message [DIAMBASE].  
        
   The Capabilities-Exchange-Request/Answer commands MUST include the 
   following additional AVPs: 
    
                                      +---------------+   
                                      | Command Code  |  
                                      |-------+-------+   
        Attribute Name                |  CER  |  CEA  |   
        ------------------------------+-------+-------+   
        Service-Identifier            |  1+   |  1+   | 
        ------------------------------+-------+-------+ 

~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

---

From: <[email-masked]>
Date: Wed, 7 Jul 2004 10:22:08 +0300

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

When the AAA server authorizes a user to access a service it has knowledge
a) of the user and b) of the service. The DCC server may be configured
in an appropriate DB as part of the subscriber/service data.

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

Same as above. Note that in the sect 5.2.2 model the Service-Id can be
included in the AA-request.

Marco

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Tue, 13 Jul 2004 09:45:08 +0200

Hi Glen,

seems that we haven't reached consensus on this this far.
I agree that inclusion of the Service-Id in the CER/CEA messages as you propose below would enhance interoperability - in fact when studying the RFC 3588 it's quite similar to Supported-Vendor-Id AVP. But since CER/CEA messages cannot be proxied this mechanism alone does not necessarily guarantee that an upstream agent would not get a service-id it does not know about, right? So, the inclusion of Service-Id in CER/CEA does add value in configurations where there is a direct connection between the client and the server. If people think that this kind of restriction with relays/proxies is acceptable then it's ok for me (actually RFC3588 has already similar restrictions).

But still don't know how the Service-id would help in routing: The RFC 3588 defines that the routing table entry consists of realm name and application identifier. If an RFC 3588 compliant peer receives a CER with a Service-id it will not do anything with that information from routing point of view. We have used this as our basis this far and relied on other routing mechanisms as Marco explained in earlier mails. I.e. in CER/CEA we negotiate the application-id only, and when the user is authenticated/authorized the AA server assigns the credit control server based on the user and the requested service (or the DCC server address is configured in the DCC client). The DCC server address is used as destination host/realm and the DCC messages are routed using the mechanisms in RFC3588. So, the case where a DCC server receives an unknown service-id should not really happen.

BR,
Leena 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Glen Zorn
Sent: 7. heinäkuuta 2004 0:37
To: [email-masked]
Cc: [email-masked]
Subject: RE: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt

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

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

>> 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 guess I'll just take your word for it & drop the matter.

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

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.

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

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.

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

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?

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

> Hope this clarify

Apparently dense,

~gwz