Re: Some comments wrt AAA and content peering

[Stephen Thomas <stephen.thomas@transnexus.com>]

Curious minds are wondering about a related (but, perhaps, ultimately 
orthogonal) question. Does the group have any feelings, opinions, etc. on 
the use of Secure Sockets Layer (SSL) or TLS? I ask because I suspect it's 
a technology that many in this market will be familiar with, just by the 
nature of the problem space. What got me wondering was that SSL can 
definitely provide authentication and, with suitably defined policies, 
authorization. In some ways DIAMETER tackles those same problems. If 
everyone thinks they're going to be supporting SSL anyway, maybe it would 
be beneficial to look at ways to re-use that for some of the security and 
AAA issues. That approach would seem to agree with Bernard's comment that 
DIAMETER may be most appropriate for the accounting piece alone. (But there 
are standards other than DIAMETER for doing accounting using SSL; they're 
not IETF standards, however.)

Although I won't speak for the AAA folks and why they chose not to use 
SSL/TLS (or IPSEC, for that matter), some of the frequent concerns raised 
against SSL are its complexity and memory footprint, and the fact that it 
really requires a PKI. (Note: I personally reject the oft-repeated argument 
that no widely deployed PKI exists today. There's a heck of a lot of 
PKI-secured commerce going on every day on the Web. Some people might not 
like the de facto ecommerce PKI, but it certainly exists and, with millions 
of users every day, it's large.)

Stephen


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

____________________________________________________________________
Stephen Thomas                                       +1 404 872 4887
TransNexus, Chief Technical Officer    stephen.thomas@transnexus.com