Subject: [AAA-WG]: Issue 349: Accounting Response Bloat

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 May 2002 15:23:31 -0700 (PDT)

Issue 349: Accounting Response Bloat
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 22, 2002
Reference: 
Document: Base
Comment type: T
Priority: S
Section: 9.7.2
Rationale/Explanation of issue:

Early on, Accounting Response bloating was identified as an 
issue in Diameter. For example, this is cited in
Section 3.5 of draft-ietf-aaa-issues-05.txt, which
refers to "SNMP-style" response bloat within Diameter. 
The problem is having the AVPs included in the Accounting-Request
echo'd in the Accounting-Answer, greatly increasing the size
of the ACA message. 

Section 9.7.2 of Base states:

"The Accounting-Answer command contains the same Session-Id and 
MAY contains the same Accounting Description and Usage AVPs 
that were sent in the Accounting-Request command."

This is inappropriate. The only reason that the usage AVPs should
be included in the Accounting-Answer is if the NAS specifically
requests this, such as by including the CMS-Data AVP.

---

From: <[email-masked]>
Date: Wed, 29 May 2002 10:13:51 +0300

Hi Bernard,

Change is made, issue can be considered closed.

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 29 May, 2002 09:00
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]
> Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat
> 
> 
> > Do you propose to strike the 2nd part of the text entirely 
> (that is OK for me) or
> > modifying it to be something like:
> > 
> > 	The Accounting-Answer command contains the same Session-Id and 
> > 	includes the the usage AVPs only if the NSA specifically 
> > 	requests that they be included, such as by including the CMS-
> > 	DATA AVP.
> 
> This text would work for me. 
> 
>

---

From: <[email-masked]>
Date: Thu, 30 May 2002 09:45:58 +0300

Hi all,

In summary, my original 'NSA' will be included.  I think that
should solve it.

John

> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 30 May, 2002 01:09
> To: Johan Johansson
> Cc: Loughney John (NRC/Helsinki); [email-masked]; William Bulley;
> [email-masked]
> Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat
> 
> 
> Johan Johansson wrote:
> 
> > I'm have a shady understanding of how CMS works at best, so 
> please bear 
> > with me if I'm completely off target. If you are using CMS, 
> wouldn't the 
> > simple fact that the ACR checked out at the accounting 
> server by itself 
> > mean that it was transfered correctly and the ACA with a 
> > DIAMETER_SUCCESS Result-Code be the receipt that it did?
> 
> 
> Yes, though for the purposes of non-repudiation a "plaintext" 
> ACA SUCCESS
> will not be helpful. That is, I send you something encrypted with your
> PK and signed by my PK. You will be able to conclusively show that I
> wrote the message. But I will not be able to show that you received
> it.
> 
> Adding CMS on the ACA SUCCESS helps a bit, because now I can show
> you received something for session ID X. However, I still can't
> prove you received exactly those values that I sent you, because
> I could be lying later and claiming that I used the session ID
> with some other AVP values.
> 
> Finally, adding either the usage AVPs, or a hash of them in the
> ACA SUCCESS, protected by CMS, will help me to show that you
> actually did receive the AVPs in question.
> 
> Whether we need this function is another debate.
> 
> Jari
> 
>

---

From: <[email-masked]>
Date: Thu, 30 May 2002 10:59:17 +0300

Hi Jari,

Sounds good, I will add the text.

john

> Sent: 30 May, 2002 10:55
> Cc: [email-masked]; [email-masked]; [email-masked]
> [email-masked] wrote:
> 
> 
> > I prefer the 1+1 approach.  What would you see as the 
> clarifying text needed.
> > 
> > Is this sufficient?
> > 
> > 	DATA AVP.  This this rule takes precedence over the regular 
> > 	P/ENCR rules.
> 
> 
> =>
> 
> includes the usage AVPs only if CMS is in use when sending this
> command. Note that the inclusion of the usage AVPs when CMS is
> not being used leads to unnecessarily large answer messages,
> 
> and can not be used as a server's proof of the receipt of these
> 
> AVPs in an end-to-end fashion.
> 
> (Then, later, when we want to fix the bloat problem also with
> CMS, we can add a new AVP that the NAS can include in the request
> for the hash, and the server can send it back signed. So I don't
> think we will lose this functionality for ever if we go for 1+1.)
> 
> Jari
> 
>