Subject: [AAA-WG]: How to use Diameter Accounting

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Wed, 3 Oct 2001 11:53:16 +0200

Submitter name: Harri Hakala
Submitter email address: [email-masked]
Date first submitted: 10.10.2001
Reference: 
Document: Base (draft-ietf-aaa-diameter-08-alpha01)
Comment type: T/E
Priority: 1 
Section: 2.3 and 8
Rationale/Explanation of issue: 

According to the section 8.0 Diameter can provide two different type of services to applications.
The first involves authentication and authorization, and can optionally make use of accounting.
The second only makes use of accounting.

There are certain applications, which needs only send the accounting information and
do not need the support of authentication and authorization.
 
The Accounting commands from the Diameter base protocol suits very well for this purpose.

In section 2.3 Diameter Protocol Extensibility it is described the ways how 
the Diameter protocols can be extended.
Section 2.3.2 defines that when no existing AVP can be used appropriately to communicate some
service-specific information, a new AVP should be created.
By using the accounting commands and service-specific AVPs would be the perfect solutions
for the applications which only want to send the accounting information.

But it is not possible to use the Accounting commands with service specific AVPs without
creating a new application, because the accounting is not an application by itself
(no Application identifier defined).

This means that there is always need to create a new application before it is possible to use
the Diameter accounting commands.
Anyhow it is said in section 2.3.3 that the creation of a new application should be view as a
last resort.
In the same chapter it is also defined that the new Diameter application MUST define at least one 
Command Code.
Does this mean that if a new application is created it still can use Commands from the base protocol without
creating a new Commands ? 

Does this restrict the possibility to use Diameter protocol only for accounting purposes ?

Requested change: 
Proposal 

Even if the Accounting is part of the Base protocol it should be possible to use only the accounting part of
Diameter without creating each time a new application.

Application Id for accounting used for capabilities exchange.

Best regards.........Harri Hakala

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Oct 2001 13:06:21 +0300

Yes. At present we allow the use of Diameter also only
for accounting. But then the mandatory Application
Id, and the rules governing the creation of new
applications make some restrictions anyway.
The end result is that folks who want to use
accounting features in Diameter are forced to
create new dummy applications, and if the application
creation rules are followed, also invent dummy
messages -- all for stating some new AVPs that
should be sent.

What can we do? Weaken the restrictions on adding
new applications?

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Oct 2001 08:35:08 -0700 (PDT)

> messages -- all for stating some new AVPs that

I would suggest that Diameter accounting should be usable as a general
service without requiring creation of dummy appliations. All that should
be required is new AVPs. 

> What can we do? Weaken the restrictions on adding
How about assigning accounting its own application ID?

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Oct 2001 09:30:11 -0700

> service without requiring creation of dummy appliations. All that should

right because the folks wanting to use Accounting for another purpose really
need to define the contents of the accounting messages. Actually, section 9.3
of the base spec details this.

how else can folks get interoperability?

> How about assigning accounting its own application ID?

This is the way it used to work.... then Glen argued to bundle it into the
base spec, and remove the separate appl-id, and we created the acct-appl-id.

Is reversing on a WG decision we made over 8 months ago really the right thing
to do here?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Oct 2001 09:31:50 -0700

Perhaps the more appropriate fix is to state that new applications do not have
to include a command code if they are used for accounting only.

The goal was to eliminate the possibility of folks submitting hundreds of
applications containing simple AVPs to extend an existing command.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Oct 2001 09:40:01 -0700 (PDT)

> how else can folks get interoperability?

So how do we accomplish this?

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 3 Oct 2001 09:50:54 -0700

Harri Hakala (LMF) [mailto:[email-masked]] writes:

...

> (no Application identifier defined).

I'm confused: first you say that "There are certain applications, which
needs only send the
accounting information and do not need the support of authentication and
authorization." but then youcomplain about having to create a new Diameter
application identifying the application.  I don't understand.

> Does this mean that if a new application is created it still can
> use Commands from the base protocol without
> Even if the Accounting is part of the Base protocol it should be
> possible to use only the accounting part of

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Oct 2001 09:37:28 -0700

> So how do we accomplish this? 

By following my recommendation (in the other e-mail to this thread). Allow for
folks to create accounting related applications that do not define new command
codes, but only AVPs. 

That would require a change to section 2.3

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Oct 2001 09:38:45 -0700

> application identifying the application.  I don't understand.

Actually, that's an interesting point. It is possible to just create a
Diameter spec that defines new AVPs to be included in the Accounting
messages, and then you are done.

sometimes the solution is so simple it's hard to see. Thanks Glen!

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Oct 2001 09:44:17 -0700 (PDT)

> to include a command code if they are used for accounting only.

That makes sense to me. After all, the Accounting Server typically only
writes the AVPs to disk anyway. So it need not necessarily understand the
semantics of the AVPs. 

> applications containing simple AVPs to extend an existing command.

All that should be needed is to define the AVPs. No new command code
should be required.

> > for the applications which only want to send the accounting information.

Yes, this is very important.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 3 Oct 2001 09:53:52 -0700

> > messages -- all for stating some new AVPs that

I agree that this is silly.  As I recall, though, the restrictions are
intentional and arise from a fear of extensible protocols.  Of course,
hamstringing Diameter extensibility virtually guarantees that we (or some
other set of folks) will go through this same exercise again in a few
years...

> > What can we do? Weaken the restrictions on adding

Good idea.  In fact, I would be in favor of removing all arbitrary
restrictions (other than IANA registration and documentation) on the
creation of new applications.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Oct 2001 09:41:42 -0700

> creation of new applications.
What would IESG folks say about this one?

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Oct 2001 09:49:12 -0700 (PDT)

> sometimes the solution is so simple it's hard to see. Thanks Glen!

Yes, it would seem that this is the most straightforward way to handle
it. That is after all how it works in RADIUS. 

Can we get some text inserted that will make this crystal clear? This
keeps coming up again and again -- and used as a justification for
creating new protocols.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Oct 2001 09:53:12 -0700 (PDT)

> other set of folks) will go through this same exercise again in a few

Months, not years. If Diameter can't be used as a general accounting
facility, then there are at least two other WGs ready to define their own
accounting protocols. This makes no sense. 

I'm not sure why anyone should be afraid of extending the Accounting
functionality. There are no interoperability issues -- an Accounting
Server that just writes AVPs to disk can do this with arbitrary AVPs.

---

From: Jacques Caron <[email-masked]>
Date: Wed, 03 Oct 2001 19:09:54 +0200

Hi,

What about a server that would _require_ some specific AVPs for the 
application (in the general sense, not the Diameter sense) it handles?

Say, in a roaming environment, a server that would want to have billing 
information... I guess you could always send back an error saying that AVPs 
are missing, but it's probably better to know beforehand (at capabilities 
exchange time)?

Jacques.

>Server that just writes AVPs to disk can do this with arbitrary AVPs.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: David Mitton <[email-masked]>
Date: Wed, 03 Oct 2001 13:30:00 -0400

At 10/3/2001 07:09 PM +0200, Jacques Caron wrote:

>information... I guess you could always send back an error saying that 
>AVPs are missing, but it's probably better to know beforehand (at 
>capabilities exchange time)?
>
>Jacques.

ummm... my mind explodes contemplating a scalable protocol that would have 
someone withhold information, unless someone downstream says "pretty 
please", so you can have more round trips...

Either the access server has the information to support the service and 
always forwards it, or the downstream server did not authorize the correct 
service.

sorry for being terse, but you could argue this in many angles, but it 
comes down to provisioning AND IMPLEMENTING the correct service to start 
with,  NOT negotiating up on the fly.

The real work is detailing these "required" AVPs.  And getting them 
provided  as a matter of course.

Dave.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Oct 2001 10:25:51 -0700

will do this as part of the recent issue that was filed for acct purposes.

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 3 Oct 2001 21:30:53 +0300

> sometimes the solution is so simple it's hard to see. Thanks Glen!

Not so fast! This isn't *just* a problem with the arbitrary rules on
creating new apps. Acct-Application-Id is a mandatory AVP on
accounting messages, and you need to put in a value. So, what
value to put in? Ok, let's assume we loosen the rules on making
new accounting apps, perhaps by introducing a new section
between 2.3.2 and 2.3.3. Anybody can add these and allocate
an application id, and define new AVPs. (New cmds are still
harder to get.) So: the first conclusion is that we do need an acct
app value*. But that's fine.

Finally, the current text in 2.5 dictates that "Relay" app can only be used
by relay nodes. Well... what about "plain accounting" diameter servers
that don't care if they record Foo or Bar service? Shouldn't they be allowed
to advertise "Relay" in Acct-Application-Id as well?

So in conclusion, how about the following:

1. Introduce a new section between 2.3.2 and 2.3.3 that tells
    you how you can make new applications for accounting
2. Allow the allocation of apps ids for these.
3. Modify 2.5 for allowing Relay for Acct-Application-Id also for
    Diameter servers.

Jari
*) Alternative solution: use "Relay", or "Accounting". Not sure
I like these. It would be useful to indicate what service generated
the acct records.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Oct 2001 09:48:58 +0200

> Is reversing on a WG decision we made over 8 months ago really the right
> thing to do here?

what is the technically right thing to do?

randy

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 4 Oct 2001 03:01:01 -0700

Jari Arkko [mailto:[email-masked]] writes:

> app value*.

What do you mean by "acct app value"?  Do you mean a "generic" value for
accounting?  If so, I disagree...

> But that's fine.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Oct 2001 13:14:57 +0300

>accounting?  If so, I disagree...

Given that Acct-Application-Id AVP is mandatory in accounting
messages, we need *some* value for that. This we can propably
agree on, or?

Then it is another question what the value should be. My
preference is at the moment that user groups should be able
to create new apps, and allocate new values that they use
here. This seems to match your desire, or?

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 4 Oct 2001 03:26:09 -0700

> here. This seems to match your desire, or?

Yes, exactly.  I wanted to clarify, since our preferences don't seem to
match Harri's (see his last message)...

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Oct 2001 13:36:39 +0300

>match Harri's (see his last message)...

Harri said he wanted to eliminate the "need to create a new dummy
application". This could mean the dummy new messages, the renaming
of the acct messages app specific ones, the allocation of an app
id, or some combination of these. I tried to reach Harri but couldn't
find him at the moment. But I thought that he didn't mind allocating
new application identities, particularly when he said OK to my
proposal that suggested this as one part of the solution. So, we just
might all agree, but I'll let Harri confirm...

Jari

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 5 Oct 2001 21:46:44 -0700

> here. This seems to match your desire, or?

This seems to be the best way forward.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 5 Oct 2001 21:48:20 -0700

> what is the technically right thing to do?

six of one, half a dozen of another.

I think there is a better fix than reverting to prehistoric ages. I've
proposed it, and other folks tend to agree with it.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 5 Oct 2001 21:51:10 -0700

> proposed it, and other folks tend to agree with it.

I can't even understand my own response. Folks tend to agree with 
allowing for application ids to be allocated for accounting purposes
without requiring a new command code. Some new text was sent out that
folks appear to like.

I think that's the better fix.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 7 Oct 2001 07:37:21 -0700

> 2. Allow the allocation of apps ids for these.

ok so far.

> 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for

what does this fix have anything to do with this issue? This is a much larger
change that can have many other side effects. What is the purpose for this
request?

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 7 Oct 2001 19:25:02 +0300

> change that can have many other side effects. What is the purpose for this

Well... yes. I admit this isn't directly the issue at hand. I just went through the situation,
and saw that in order to build a general-purpose account-record-saving device,
it would have to announce a particular application. This change would only be
relevant for the accounting servers, as clients obviously have to be application
aware.

This isn't a major issue for me, we could propably manage well with the
first two parts of the proposed solution. Even if you had a general purpose
account-record-saving device, you could still easily configure it with the
app ids.

On the other hand, I don't at present see the 'many other side effects'. Did
you have any specific fears about them?

Jari

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 7 Oct 2001 11:50:33 -0700

> you have any specific fears about them?

well, the issue here is one would then advertise for *all* accounting
applications, instead of individually. One may receive more than it asked
for :(

The protocol can already advertise the acct apps it supports, without any
changes to the spec.

PatC