Some comments wrt AAA and content peering

["Mark Day" <markday@cisco.com>]

On behalf of the design team, I asked Randy Bush to find us a contact who
was familiar with AAA and able to offer comments about the relationship of
that work to what we are trying to do with accounting for peering. Bernard
Aboba was kind enough to volunteer for that role, for which we are very
grateful. Below are his comments on the subject.  Given the widespread
interest in the accounting issues apparent at the Oct. 3 meeting, I thought
that these deserved a wider audience.

--Mark

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Monday, October 23, 2000 9:59 PM
To: Mark Day
Subject: RE: AAA contact for contact peering design team?


In general, the most important thing to think about when
designing an accounting mechanism is the degree of security
and reliability required. This is largely dependent on
whether real money is changing hands as a result of the
data within an accounting exchange.

http://www.ietf.org/internet-drafts/draft-ietf-aaa-acct-06.txt
distinguishes between "archival" quality accounting, which
may be required by financial and legal regulations where the
accounting exchange affects financial statements, and other
types of accounting, which are used for less mission
critical functions, such as capacity planning, but actually
do not have impact on financial statements.

In terms of the models discussed in the draft, I believe
that the following is true:

The Flat Rate Accounting model need not necessarily conform to
archival standards, because the bill doesn't depend on usage.
This means that you have considerable flexiblity in defining
how it is done. Basically almost anything, including a tin
can and string can be made to work.

Other accounting models (Metered, Prepay event, and
Prepay metered) result in money changing hands. In some
cases, the amounts are likely to be substantial. In this
case, you will probably need to meet archival accounting
standards.

Another distinction is between Prepay and non-prepay methods.
I am assuming that in Prepay methods (prepay event and
Prepay metered) that you will need to check the account balance
prior to authorization. In the case of prepay event,
the service requested determines the fee and therefore the
account balance can be checked as part of the authorization
procedure. Of course this implies that an error message
exists to indicate "account balance insufficient".

In the case of prepay metered, you don't know how much
resource will be consumed, so the best you can do is
return a "session limit" parameter indicating the maximum
amount of resource that can be consumed. In practice, it
probably makes sense not to return the full balance, but
some smaller amount, to enable periodic re-authorization.

The metered accounting model can be made to work without
any special effort since there is no interaction between
authorization and accounting. Flat rate is the easiest
of all.

With respect to the accounting record formats, there are
some things to think about. XML is certainly very popular,
but if you are going to have huge volumes of data, then
you may need to think about efficiency. In the US, accounting
data is typically archived for 7 years, which means that
there will be CD-ROMs or tapes sitting in a warehouse
somewhere. The square footage used will affected by
the compactness of your accounting format. For this
reason, it might be worth considering a more compact
(but readable) accounting record, or alternatively,
compressing the XML. See RFC 2924 for a discussion of
the issues.

In terms of DIAMETER, here are some thoughts:

a. DIAMETER accounting is being designed to supply both
transport and application layer acknowledgments. This
should make it robust against a number of the faults
described in draft-ietf-aaa-acct-06.txt. This makes
it superior to RADIUS (though not necessarily to other
mechanisms like SMTP) in terms of reliability.

b. DIAMETER accounting currently suffers from "response
bloating" a la SNMP, but as described in
draft-ietf-aaa-issues-00.txt there is a discussion
about fixing this.

b. DIAMETER can in principle transport accounting records
of any format as well as AVP-based binary records. So using
DIAMETER wouldn't force you to use a particular accounting
record format.

c. DIAMETER supports various mechanisms for securing accounting
transfers, including hop-by-hop and end-to-end mechanisms of
various strengths. I'm curious about what security you feel
you need in your application. For example, would the
Kerberos mechanism proposed by Kaushik Narayan
(kaushik@cisco.com) work for you or do you need something
stronger, such as CMS?

d. We are currently having a debate within AAA as to whether
DIAMETER should support application-layer batching or only
transport-layer. The argument seems to come down to efficiencies
in signing of batches via heavweight methods such as PKI. Do
you care about this?

e. In my opinion, DIAMETER may be more appropriate for your
accounting problem than for the authentication and authorization
aspects. If you are in a situation where you need to
authentication/authorize a huge number of requests from
the same user, then re-usable tickets are a big win. This
would lead one to a solution based on GSS-API.

I'm working on draft on GSS-API security for SIP/HTTP which
may be of interest. As soon as the draft transitions from
a series of semi-incoherent scriblings to something more
readable, I can provide a copy to you for review.