Subject: [AAA-WG]: [Issue] Missing ABNFs in NASREQ?

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2004 14:42:03 -0800 (PST)

In reading the NASREQ draft and Diameter Base again, I've
concluded that NASREQ is missing a section or two detailing the ABNFs for
use of NASREQ with several commands defined in Diameter Base:

Session-Termination-Request/Answer
Re-Auth-Request/Answer

While the ABNF of these commands is defined in Diameter Base, there is no
provision for inclusion of AVPs defined in NASREQ within these commands,
because the AVPs are defined in NASREQ, not Diameter Base.

Nevertheless, use of NASREQ AVPs in these commands seems useful/likely,
but NASREQ doesn't describe what is legal and what isn't.

For example, it might be reasonable to specify which session to terminate
or re-authorize based on the Calling-Station-Id.

I *think* that this involves merely allowing additional of optional AVPs
to the commands, so that use of a different applicationID or command isn't
required.

---

From: David Mitton <[email-masked]>
Date: Thu, 08 Jan 2004 18:00:08 -0500

>to the commands, so that use of a different applicationID or command isn't

hmmm... then we'll have to find a section to put that in too...
Suggestion: add 3.3, 3.4, etc...

Accounting is a somewhat similar case.  It uses Base messages, and 
therefore does not have an ABNF, but it does have it's own AVP section 8 
and occurrence tables in section 10.2.

Diameter messages "traditionally" have four types of specs: a message ABNF, 
a table of related AVPs with their codes, types, and flags, the AVP 
descriptions themselves, and a table of message-to-AVPs allowed occurrences.

We seem to have problems when functions overlap and usage of messages and 
AVPs are normatively described elsewhere.

Dave.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Jan 2004 09:45:20 +0200

> to the commands, so that use of a different applicationID or command isn't

Lets talk more in depth about the kind of situations that would warrant
the use of additional AVPs. The base does allow the use of additional
AVPs in these contexts, but I'm searching for the specific reason to
include NASREQ AVPs.

I'm not sure the Calling-Station-Id case is a good example. The STR
and RAR commands have been designed to affect a given, existing session
which is identified via the Session-ID AVP. How would the inclusion
of Calling-Station-Id change that? Or are you proposing that Session-ID
be optional, and you'd be re-authentication all sessions that come from
a given MAC address?

What about other AVPs? Some authz related AVP? But it seems unnecessary
in termination, and for re-auth the base says:

    A successful RAA message MUST be followed by an application-specific
    authentication and/or authorization message.

which would imply that the usual NASREQ commands could carry the authz
attributes.

What about information about the current status of the session, say
byte counts? But if those are needed, presumably they would be carried
in accounting commands.

Any other examples?

--Jari