Subject: [AAA-WG]: Mobile IP accounting

From: Johan Johansson <[email-masked]>
Date: Wed, 30 Jan 2002 17:15:20 +0100

I am somewhat confused about how to do MIP accounting. The only 
description of accounting beyond avp definitions that I can find in the 
mip draft is a few statements about Accounting-Multi-Session-Id and the 
figure reproduced below for your convenience:

           ACR, Session-Id = foo         ACR, Session-Id = bar
       Accounting-Multi-Session-Id = a   Accounting-Multi-Session-Id = a
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           ACA, Session-Id = foo       ACA, Session-Id = bar

            Figure 4: Accounting messages w/ Mobile IP Application

This seems to imply that only *the* accounting server receives any 
accounting information, which in this particular case also happens to be 
the AAAH. Let us examine the following network:

FA in realm abc.com
AAAH in realm isp.com
HA in realm def.com

Does this mean that only isp.com will receive accounting messages and 
that abc.com and def.com never interchange information at all and if 
they want to store accounting information for comparison we say "sure, 
go ahead" but we don't care how and we provide no support for it?

j

---

From: Johan Johansson <[email-masked]>
Date: Wed, 30 Jan 2002 17:32:45 +0100

Am I furthermore correct in assuming that the initial ACR has the realm 
from the users' nai but no destination host and that subsequent ACRs 
have the destination host of the initial ACA?

Johan Johansson wrote:

> description of accounting beyond avp definitions that I can find in 
> the mip draft is a few statements about Accounting-Multi-Session-Id 
> and the figure reproduced below for your convenience:
>
> accounting information, which in this particular case also happens to 
> be the AAAH. Let us examine the following network:
>
> FA in realm abc.com
> AAAH in realm isp.com
> HA in realm def.com
>

---

From: Mark Eklund <[email-masked]>
Date: Thu, 31 Jan 2002 09:36:53 -0500

Johan,

 >        Accounting-Multi-Session-Id = a   Accounting-Multi-Session-Id = a

I had always assummed that the FA accounting records were the property
of the foreign domain and the HA accounting records were property of
the home domain.  Figure 4 disagrees with my assumptions.  Given your
argument above, I would say that Figure 4 is wrong.

-mark

---

From: Tony Johansson <[email-masked]>
Date: Thu, 31 Jan 2002 11:58:44 -0800

Johan and Mark,

> argument above, I would say that Figure 4 is wrong.

Well, I thought that we have agree that ACR's MUST be sent to the Home AAA
server, see text below from Base section 9.2

"9.2  Protocol Messages

   A Diameter node that receives a successful authentication and/or
   authorization messages from the Home AAA Server, MUST collect
   accounting information for the session. The Accounting-Request
   message is used to transmit the accounting information to the Home
   AAA server, which MUST reply with the Accounting-Answer message to
   confirm reception.  The Accounting-Answer message includes the
   Result-Code AVP, which MAY indicate that an error......"

However, there is of course nothing that prevents the foreign domain to collect
a copy of the accounting data. Regarding the fact that we only talk about
real-time accounting, I really don't see anything wrong with what we have in
the spec today.

---

From: Johan Johansson <[email-masked]>
Date: Fri, 01 Feb 2002 01:40:00 +0000

>real-time accounting, I really don't see anything wrong with what we have in
I am not necessarily claiming that something is wrong. What I am trying 
to do is understand the assumptions made when accounting was specified. 
My present understanding is that accounting is merely a log of what 
happens and not a control channel in the sense that you will never get 
an ACA with the result code DIAMETER_INSUFFICIENT_FUNDS. It would be the 
job of the authorization server to take such a decision.

Another assumption is that the AAAH and the HA is operated by the same 
organization, at least in the case where the HA is not in the foreign 
realm. Maybe a small company deem it affordable to buy a couple of 
agents but is unwilling to invest in a home server and the support 
necessary to administer the users and keep it running and therefore buys 
this service from an isp? In this scenario it hardly makes sense to send 
accounting data to someone who is not participating in the actual 
traffic. Then again accounting could be routed separately from the 
authorization/authentication traffic. Maybe this is a scenario that we 
are not even trying to cover?

The drafts never explain the purpose of sending accounting data both 
from the home and foreign realm to the home server. Forcing the foreign 
agent to send signed accounting data could be useful for nonrepudiation 
I guess and the home agent's accounting data could be used for online or 
offline verification that the data is reasonable. Is this the purpose?

As you say, there is nothing that stops the foreign realm from storing a 
copy of the accounting data in case they want to send a bill. There is a 
certain logic in not specifying the means for doing so since it is after 
all within the same organization. But why do we then specify how the 
home organization is to transport its data within its network?

j