Subject: [AAA-WG]: Issue 404 - Closing

From: David Mitton <[email-masked]>
Date: Fri, 11 Jul 2003 14:06:03 -0400

Issue 404: NASREQ-11 Issues
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 11, 2003

Section 4.l0

" When used by 802.1X supplicants, the service typically terminates due
to the expiry of the Session-Timeout AVP. The access device may then
reauthenticate the user with a new AA-Request. The RECOMMENDED way
to do this in Diameter is to use the Authorization-Lifetime AVP
rather than the Termination-Action AVP. However, the Termination-
Action AVP MAY be used when copied from a RADIUS Access-Accept to a
Diameter AA-Answer by a Translation Agent."

This contradicts Section 2.2, which says that the Authorization-Lifetime
AVP SHOULD NOT be used with RADIUS clients. The only alternative is to
use Session-Timeout and Termination-Action, but that doesn't do the job,
since the meaning has been changed. This leaves a Diameter server
incapable of communicating that it would like a RADIUS client to
re-authenticate at a given interval. The suggested fix is to change
the meaning of Termination-Action so that it is compatible with RADIUS.

DJM: - change Termination-Action, so that it does not require the
resetting Session-ID and sending STR.  more consistent with RADIUS
	- Rework Auth-Lifetime description so it offers	gwy solutions
     - Add to RADIUS interactions section, what to do with A-L AVP

---
9.1.something...

" - The Diameter Origin-Host and Origin-Realm AVPs MUST be created
and added using the information from the NAS-Identifier
attribute, and/or the FQDN corresponding to the NAS-IP-Address
attribute. The AAA protocol specified in the identity would be
set to "RADIUS"."

I think that the FQDN corresponding to the NAS-IP-Address is preferred,
if available.

DJM: Okay, done.

9.1.1

" - The Origin-Host AVP's value is inserted in the NAS-Identifier
attribute."

How about also supporting translation of Origin-Host AVP to
NAS-IP-Address or NAS-IPv6-Adddress?

DJM: This is a server response.  The NAS id information is not
present in the RADIUS message.   I have reworked this section to make it
clearer.  The information must either be saved at request time or
derived from context.

9.5.2

" The Diameter AVP will consist of the following fields;
Diameter Flags: V=1, M=0, P=0
Diameter Vendor code = RADIUS VSA Vendor code
Diameter AVP code = RADIUS VSA Vendor type code
Diameter AVP length = length of AVP (header + data + padding)
Diameter Data = RADIUS VSA vendor data

If the RADIUS receiving code knows of vendor specific fields
interpretations for the specific vendor, it may employ them to parse
an extended AVP code or data length, Otherwise the recommended
standard fields will be used.

Nested Multiple vendor data fields MUST be expanded into multiple
Diameter AVPs."

Forwarding a RADIUS Vendor-Specific AVP as non-mandatory
could be dangerous in some circumstances, such as when a
proprietary filter or key attribute is included. I'd suggest
setting M=1 by default.

DJM: Hmmm... this is a toughie.  I agree with your intent, but I think
in practice some RADIUS services are used to sending a scattershot VSA
list that covers all of their configured vendors.  They know the
equipment will ignore the unrecognized attributes.  Funk's SBR takes a
slightly more sophisticated approach in that it will filter VSAs in
the response profile from in the Access Response message if it knows the
NAS vendor type (by configuration).
This would be a good filter option for a gateway.
Well maybe if we default mandatory, but allow local modification?

13.1

DJM: I'm sure there are a number of drafts to update in this section.  A
couple documents have gone to RFC now too.  I will do this as a last pass 
before the next submission.

Additional comments

I believe that it would be useful to talk about translation of unsolicited 
disconnect
or change of filters messages to their RADIUS equivalents, defined in
[DynAuth].

DJM:  DynAuth support is optional.  Should be treated like
server-initiated AAR, with RE-Auth=X
	- RADIUS message (per Chiba) translated	or processed as above
     - Response translated