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

From: <[email-masked]>
Date: Mon, 5 Jul 2004 14:21:05 +0300

Hi Glen,

actually the WG last call ended a while ago, the draft has already been
review by the IESG (as you may have noticed from my previous email).
As you know changes are not allowed at this stage, unless explicitly
requested by the IESG or major bugs are discovered.

We have discussed among authors a year ago the possibility of using CER/CEA 
as you propose. While including the Service-Identifier AVP in
CER/CEA *may* work in case of direct connection to the server, it won't help
if e.g. relay agents were present in between client and server.
All the client would know from an immediate peer that advertises it self as a
relay agent is that any message can be sent over there. Because the base
protocol is working solely on the basis of the Application-Identifier, even
though the server would advertise Service-Ids to the relay agent, the relay
agent would still deliver CCR messages to the server regardless the
service-id. The other problem of including the Service-Id in CER/CEA is that 
one can have negotiate application-ids in one CER command, and therefore there 
is a risk that the receiver can't be sure to which application the Service-Id 
is related to, in case several applications would adopt the same mechanism in 
the future. We finally thought that if we introduce a mechanism, this must work in
all the possible AAA network topologies and scenarios, we then discarded the CER/CEA
and we ended up to the end-to-end discovery documented in the DCC draft.

I think it would be more appropriate to enhance the capability exchange
possibly in a next version of the base protocol rather than in the DCC, since 
many other applications may benefit from it.

For the time being I think what we have is enough. At the first CCR sent
to the server, the server will reject the request if the service indicated
in the Service-Identifier AVP is not supported. The Result-code in CCA is 
set to DIAMETER_RATING_FAILED and the Failed AVP includes the Service-Id AVP.
The client MUST NOT send such similar request in the future (typically until a
new CER/CEA is performed). As I say this is already covered in the draft, 
however, since we are updating the draft (IESG review) we can make it even 
more explicit in the new 4.1.2/4.1.4 sub-sect., for instance

4.1.2 Application Support 
    
   Since the Application-Id of the Diameter Credit Control Application does 
   not uniquely identify the service being monitored, an additional mechanism 
   is needed. The service application MUST be identified using the Service-
   Identifier AVP at command level. A server receiving a request for a 
   service application it does not support will reject the request as defined 
   in sub-section 4.1.4.; the client will not send such similar request
   in the future. This is effectively an end-to-end discovery of the
   service application the credit control server is supporting.
   The Service-Identifier AVP MUST be a unique identifier for a given service 
   as defined in section 8.28.  
    
   Thus, the combination of the Diameter Credit Control Application-Id and 
   the Service-Identifier AVP in the Credit-Control-Request command uniquely 
   defines the service within the context of the Diameter Credit Control, and 
   hence provides interoperability between Diameter credit control clients 
   and server. 
    
   With this mechanism it is possible to cover additional service specific 
   requirements as needed in other documents. However, introducing new credit 
   control mechanisms to the framework defined in this specification, require 
   definition of a new version of the Diameter Credit Control Application and 
   corresponding Application Identifier.

4.1.4 Handling of Unsupported/Incorrect Rating Input  
    
   Diameter credit control implementations are required to support the 
   Mandatory rating AVPs defined in service specific documentation of the 
   services they support according to the 'M' bit rules in [DIAMBASE].  
        
   In case a rating input required for the rating process is incorrect in the 
   Credit control request, or the credit control server does not support the 
   requested service (identified by the Service-Idntifier AVP at command 
   level), the Credit control answer MUST contain error code 
   DIAMETER_RATING_FAILED. A CCR message with this error MUST contain one or 
   more Failed-AVP AVPs containing the missing and/or unsupported AVPs that 
   caused the failure. A Diameter credit control client receiving error code 
   DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar 
   requests in the future (typically until a new capability exchange
   negotiation is performed according [DIAMBASE]).

Regards
Marco

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Glen Zorn
> Sent: 02 July, 2004 21:26
> To: [email-masked]
> Subject: [AAA-WG]: Issue with draft-ietf-aaa-diameter-cc-05.txt
> 
> 
> 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: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Jul 2004 11:04:02 -0700

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

> Hi Glen,
> 
> actually the WG last call ended a while ago, the draft has already
> been review by the IESG (as you may have noticed from my previous
> email). As you know changes are not allowed at this stage, unless
> explicitly requested by the IESG or major bugs are discovered. 

Sorry, I'll wait for IETF Last Call, then.
  
> 
> We have discussed among authors a year ago the possibility of using
> CER/CEA as you propose. While including the Service-Identifier AVP in
> CER/CEA *may* work in case of direct connection to the server, it
> won't help if e.g. relay agents were present in between client and
> server. All the client would know from an immediate peer that
> advertises it self as a relay agent is that any message can be sent
> over there. Because the base protocol is working solely on the basis
> of the Application-Identifier, even though the server would advertise
> Service-Ids to the relay agent, the relay agent would still deliver
> CCR messages to the server regardless the service-id. The other
> problem of including the Service-Id in CER/CEA is that one can have
> negotiate application-ids in one CER command, and therefore there is
> a risk that the receiver can't be sure to which application the
> Service-Id is related to, in case several applications would adopt
> the same mechanism in the future. We finally thought that if we
> introduce a mechanism, this must work in all the possible AAA network
> topologies and scenarios, we then discarded the CER/CEA and we ended
> up to the end-to-end discovery documented in the DCC draft.          
> 
> I think it would be more appropriate to enhance the capability
> exchange possibly in a next version of the base protocol rather than
> in the DCC, since many other applications may benefit from it. 
> 
> For the time being I think what we have is enough. At the first CCR
> sent to the server, the server will reject the request if the service
> indicated in the Service-Identifier AVP is not supported. The
> Result-code in CCA is set to DIAMETER_RATING_FAILED and the Failed
> AVP includes the Service-Id AVP. The client MUST NOT send such
> similar request in the future (typically until a new CER/CEA is
> performed). As I say this is already covered in the draft, however,
> since we are updating the draft (IESG review) we can make it even
>    Since the Application-Id of the Diameter Credit Control
>    Application does not uniquely identify the service being
>    monitored, an additional mechanism is needed. The service
>    application MUST be identified using the Service- Identifier AVP
>    at command level. A server receiving a request for a service
>    application it does not support will reject the request as defined
>    in sub-section 4.1.4.; the client will not send such similar
>    request in the future. This is effectively an end-to-end discovery
>    of the service application the credit control server is
>    supporting. The Service-Identifier AVP MUST be a unique identifier
> for a given service as defined in section 8.28. 
> 
>    Thus, the combination of the Diameter Credit Control
>    Application-Id and the Service-Identifier AVP in the
>    Credit-Control-Request command uniquely defines the service within
>    the context of the Diameter Credit Control, and hence provides
>    interoperability between Diameter credit control clients and
> server. 
> 
>    With this mechanism it is possible to cover additional service
>    specific requirements as needed in other documents. However,
>    introducing new credit control mechanisms to the framework defined
>    in this specification, require definition of a new version of the
>    Diameter Credit Control Application and corresponding Application
> Identifier. 
> 
>    Mandatory rating AVPs defined in service specific documentation of
>    the services they support according to the 'M' bit rules in
> [DIAMBASE]. 
> 
>    In case a rating input required for the rating process is
>    incorrect in the Credit control request, or the credit control
>    server does not support the requested service (identified by the
>    Service-Idntifier AVP at command level), the Credit control answer
>    MUST contain error code DIAMETER_RATING_FAILED. A CCR message with
>    this error MUST contain one or more Failed-AVP AVPs containing the
>    missing and/or unsupported AVPs that caused the failure. A
>    Diameter credit control client receiving error code
>    DIAMETER_RATING_FAILED in answer to a request MUST NOT send such
>    similar requests in the future (typically until a new capability
> exchange negotiation is performed according [DIAMBASE]). 
> 
> Regards
> Marco
> 
>> Submitter name: Glen Zorn Submitter email address: [email-masked]
>>    Capabilities-Exchange-Request/Answer (CER/CEA) message [DIAMBASE].
>> 
>>    The Capabilities-Exchange-Request/Answer commands MUST include
>> the    following additional AVPs: 
>> 
>>                                       +---------------+
>>                                       | Command Code  |
>>                                       |-------+-------+
>> punished unless they kill in large numbers and to the sound of
>> trumpets." 
>> -- Voltaire

Hope this helps,

~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: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Jul 2004 19:35:15 -0700

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

> CCR messages to the server regardless the service-id. 

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

> The other

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.

> performed). 

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.

> As I say this is already covered in the draft, however,

Hope this helps,

~gwz