: Internetworking 2003: Call for Participation

: Interim updates for Diameter Nasreq

Folks,
	I have posted an interim update to Diameter Nasreq at the URL below.

http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-12a.txt

This version deals with many of the issues raised in issues #402, 403, & 404.
I will also post detailed responses in seperate messages.

http://www.drizzle.com/~aboba/AAA/issues.html

There are still some pending issues to be resolved.  I will address them 
soon, but I wanted to get some of the progress and discussion visible.

Thanks,

Dave.

: RE: Issue 404: NASREQ-11 Issues

Responses embedded starting with DJM:

----
Issue 404: NASREQ-11 Issues
Submitter name: Bernard Aboba
Submitter email address: aboba <at> internaut.com
Date first submitted: March 11, 2003
Reference:
Document: NASREQ-11
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1

" This document describes Diameter applications that are used for AAA
in the Network Access Server (NAS) environment."

Doesn't the document just describe a single
application? Suggested change:

"This document describes the Diameter NAS application,
which, when combined...."

DJM: the word "application" was being overloaded between a Diameter
protocol extention, and a computer application program.  I've rewritten
to be more qualitative.

Section 1.2

"1.2. Advertising Application Support

Diameter nodes conforming to this specification MAY advertise support
by including the value of one (1) in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands [Base]."

Isn't advertisement mandatory? Shouldn't the MAY be a MUST?

DJM: done - why did no one see this before?

Section 2

" Unlike the RADIUS protocol [RADIUS], the Diameter protocol does not
require authentication information to be contained in a request from
the client. Therefore, it is possible to send a request for
authorization only. The type of service depends upon the Auth-
Request-Type AVP. This difference MAY cause operational issues in
environments that need RADIUS interoperability, and it MAY be
necessary that protocol conversion gateways add authentication
information when transmitting to a RADIUS server."

The RADIUS protocol doesn't require authentication information to be
included in a Call-Check, so this isn't accurate. The use of a
capital MAY is inappropriate. Adding authentication information in
a gateway seems questionable security-wise.

Rewrite to:

"The Diameter protocol allows authorization-only requests
depending on the Auth-Request-Type AVP, where no authentication
information is contained in a request from the client. This
capability goes beyond the Call Check capabilities described
in Section 5.6 of [RADIUS] in that no access decision is
requested. As a result, service cannot be started as a result
of a response to an authorization-only request without
introducing a significant security vulnerability.

Since no equivalent capability exists in RADIUS, authorization-only
requests from a NAS implementing Diameter may not be easily
translated to an equivalent RADIUS message by a Diameter/RADIUS
gateway. For example, where a Diameter authorization-only request
cannot be translated to a RADIUS Call Check, it would be necessary
for the Diameter/RADIUS gateway to add authentication information
to the RADIUS Access Request. On receiving the Access-Reply, the
Diameter/RADIUS gateway would need to discard the access decision
(Accept/Reject). It is not clear that these translations can be
accomplished without adding significant security vulnerabilities."

DJM: text incorporated

Section 2.2

"A Diameter server
informs the NAS of the maximum time allowed before re-authentication
or re-authorization via the Authorization-Lifetime AVP [Base]. Note,
however, that the Authorization-Lifetime AVP SHOULD NOT be used if
the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS-
Identifier AVP since this would mean that the NAS is using RADIUS
which does not support server-initiated re-authentication or re-
authorization."

The 2nd sentence is correct, but it doesn't follow from the first.
The issue is not that the Diameter server informs the NAS of the
maximum time allowed; after all, this is what RADIUS does. The issue
is the ability to handle a server-initiated re-authentication or
re-authorization. This paragraph confuses the two issues. Rewrite to:

"A Diameter server
informs the NAS of the maximum time allowed before re-authentication
or re-authorization via the Authorization-Lifetime AVP [Base].
A NAS MUST re-authenticate and/or re-authorize after the period provided
by the Authorization-Lifetime AVP. Furthermore, it is possible for
Diameter servers to issue an unsolicited re-authentication and/or
re-authorization requests (e.g. Re-Auth-Request (RAR) message) to
the NAS. Upon receipt of such a message, the NAS issues a request
to re-authenticate and/or re-authorize the client."

See Issue 405 for additional discussion on this.

DJM: text incorporated

Section 3.1

" It is possible for a single session to be authorized first, then
followed by an authentication request."

It would help to provide an example of when this would be desirable.
Unfortunately, I can't think of any.

<DJM: Call-Check on dial-in trunking systems.  The line signalling tells
the switch a call is incoming, and the call is accepted and directed to
a line unit (Pre-Megaco).  When the protocol is established, then we can
authenticate.  Failure will abort the connection.

The ABNF for AAR includes support for RADIUS attributes not allowable in
an Access-Request, including Session-Timeout, Idle-Timeout, and Class.
To avoid problems in translation, I'd avoid including these AVPs in the
ABNF.

DJM: Excellent catch!  I need to keep working on my AVP spreadsheet.

The AAR ABNF also does not include the Proxy-State AVP, which is allowed
in a RADIUS Access Request. This is because the Proxy-Info AVP takes its
place, no?
DJM: Correct.

Section 3.2

The Proxy-State attribute is not listed in the ABNF for AA-Answer. I assume
it is not supported because Proxy-Info AVP takes its place.
DJM: Correct
	It doesn't seem that the ABNF breaks out the contents of AVP groups.

Section 4

" AVPs new to Diameter have code values 256 and greater. A Diameter
message that includes one of these AVPs MAY cause interoperability
issues should the request traverse a AAA node that only supports the
RADIUS protocol. However, the Diameter protocol should not be
hampered from future developments due to the existing installed base."

The MAY doesn't need to be capitalized here. Also, backward compatibility
is achievable as described in Issue 405. Rewrite to:

" AVPs new to Diameter have code values 256 and greater. Diameter
messages including one or more of these AVPs may cause interoperability
problems should the request traverse a AAA node that only supports
RADIUS. "

DJM: Jari had similar comment.  Already re-worked.

RADIUS compatibility is further addressed in Issue 405.

Section 4.5

" The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and
allows the NAS to send in the request, the ASCII string of the phone
number that the user called, using Dialed Number Identification
(DNIS) or a similar technology. Note that this may be different from
the phone number the call comes in on. It SHOULD only be present in"

The Called-Station-Id can also contain a MAC address, as in
draft-congdon-radius-8021x-23.txt. To cover this and other cases I
would change this to:

"The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and
allows the NAS to send in the request, the ASCII string describing the layer 2
address that the user contacted to. For dialup access, this can
be a phone number, obtained using Dialed Number Identification
(DNIS) or a similar technology. Note that this may be different
from the phone number the call comes in on. For use with IEEE 802
access, the Called-Station-Id MAY contain a MAC address,
formatted as described in [Congdon]."

DJM: text incorporated

4.6

" The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and
allows the NAS to send in the request the the ASCII string of the
phone number that the call came from, using Automatic Number
Identification (ANI) or a similar technology. It SHOULD only be
present in authentication and/or authorization requests.

If the Auth-Request-Type AVP is set to authorization-only and the
User-Name AVP is absent, the Diameter Server MAY perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the ANI.
"

Change to:

"The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and
allows the NAS to send in the request the the ASCII string describing
the layer 2 address that the user connected from. For dialup access, this
is the phone number that the call came from, using Automatic Number
Identification (ANI) or a similar technology. For use with IEEE 802
access, the Calling-Station-Id AVP MAY contain a MAC address,
formated as described in [Congdon]. It SHOULD only be
present in authentication and/or authorization requests.

If the Auth-Request-Type AVP is set to authorization-only and the
User-Name AVP is absent, the Diameter Server MAY perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the layer 2
address (ANI, MAC Address, etc.)"

DJM: Text incorporated.

4.7

As described, the Connect-Info attribute is only useful for dialup.

Change:

" The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
in the AA-Request message, and indicates the nature of the user's
connection. The connection speed SHOULD be included at the beginning
of the first Connect-Info AVP in the message. If the transmit and
receive connection speeds differ, they may both be included in the
first AVP with the transmit speed first (the speed the NAS modem
transmits at), a slash (/), the receive speed, then optionally other
information.

For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
"

To:

" The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
in the AA-Request or ACR STOP message. When sent in the
Access-Request it indicates the nature of the user's
connection. The connection speed SHOULD be included at the beginning
of the first Connect-Info AVP in the message. If the transmit and
receive connection speeds differ, they may both be included in the
first AVP with the transmit speed first (the speed the NAS
transmits at), a slash (/), the receive speed, then optionally other
information. Examples:

"28800 V42BIS/LAPM", "52000/31200 V90" or "11 Mbps 802.11b"

If sent in the ACR STOP, this attribute may be used to
summarize statistics relating to session quality. For example,
in IEEE 802.11, the Connect-Info attribute may contain information
on the number of link layer retransmissions. The exact format of
this attribute is implementation specific."

DJM: Text incorporated

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: Open - need to work on this.

Section 6.1

" The Service-Type AVP (AVP Code 6) is of type Enumerated and contains
the type of service the user has requested, or the type of service to
be provided. One such AVP MAY be present in an authentication and/or
authorization request or response. A NAS is not required to implement
all of these service types, and MUST treat unknown or unsupported
Service-Types as though a response with a Result-Code other than
Diameter-SUCCESS had been received instead."

Is this the same as saying that the authentication failed?

DJM: yes.  I didn't write this, but that's the intent.
Do we want to specify a failure code? say DIAMETER_INVALID_AVP_VALUE

Note also that Service-Types 15 and 16 have recently been defined by IEEE 
802.11f.
Should these be included in the list?
DJM: Shhh!  I'm ignoring them.	The lists are informational!

Section 8

"If Authentication and Authorization occur in seperate transactions, the
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD."

This assumes that service is begun once the authorization response is received,
correct? Also "seperate" is misspelled.
DJM: Yes, and got that.

I think you need to add Connect-Info to the list of Accounting AVPs.
DJM: Another good catch.

Section 9

Why does this section include a table with NAS-Identifier,
NAS-IP-Address, NAS-IPv6-Address, etc.? This looks like it
belonged somewhere else and ended up here by mistake.

DJM: they are discussed below.  I have moved the table down the
section.

" Note that this section uses the two terms; AVP and attribute in a
consise manner. The former is used to signify a Diameter AVP, while
the latter is used to signify a RADIUS attribute."

Do you mean "consistent manner"?

DJM: All of the above.  It's both concise (ahh! spello) and consistent.
    But really we are just being pickier than normal about the
    differences.  I've changed this to:

    Note that this section uses the two terms; "AVP" and "attribute" in a
    concise and specific manner. The former is used to signify a Diameter
    AVP, while the latter is used to signify a RADIUS attribute.

Section 9.1

"Therefore, a
RADIUS/Diameter Translation Agent SHOULD NOT assume to track session
state information."

I think you mean "SHOULD NOT be assumed", no?
DJM: Sentence improved.

" - If a Message-Authenticator attribute is present, it MUST be
checked and discarded. The gateway system SHOULD generate and
include a Message-Authenticator in return responses to this
system."

I think you mean that it is checked, and if valid, then it is not included
within the Diameter message; if invalid, then the packet is silently 
discarded.

DJM: well I meant something like that.	The nouns and objects are now
better qualified.

" - 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, but this preference policy? needs to be reviewed across the
section for consistency.  - Open Issue, needs a walk through

" - If the RADIUS message contains an address attribute, (e.g.
Framed-IP-Address, Login-IP-Host, Login-IPv6-Host, NAS-IP-
Address, NAS-IPv6-Address) it MUST be converted to the
appropriate Diameter AVP and Address type."

Didn't we dump the idea of address type?
DJM: Well, yes and no.  We dumped my Diameter-Nasreq conversion
proposal of RADIUS types, which removed potential overhead, and that's
what this item was inserted for, I must have missed it. But the Diameter
Base still has typed addresses (but not used for these AVPs). And RADIUS
has the "ipaddr" IPv4 data type and separate attributes. In practice, I
don't know if the two will actually meet anywhere. The list of
attributes given does not apply any more and I have removed it and
generalized the text.

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: need to walk through this whole NAS/Host address scheme and get
it straight.

9.4

"If this is not possible, an attribute error should be
returned."

Not sure which protocol this is referring to. RADIUS doesn't support
error messages, and Diameter doesn't have attribute (only AVPs).

DJM: Yes, It can only be a Diameter AVP error.	The flow in this
situation is Diameter to RADIUS.  Changed to:	"a Result-Code of
DIAMETER_INVALID_AVP_LENGTH should be returned."

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

"[AAATrans] B. Aboba, J. Wood. "Authentication, Authorization and
Accounting (AAA) Transport Profile", draft-ietf-aaa-
transport-08, IETF work in progress, April 2002"

Latest version is -12.
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: Groan...  Open for now.

Re: : RE: Issue 404: NASREQ-11 Issues

David Mitton wrote:

> 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: Groan...  Open for now.

Isn't DynAUth an Internet-Draft? How stable is it, and how appropriate
would it be for us to document in an RFC how convert to draft protocol?

I do see this as important, actually. But I'm wondering if we should
publish this one separately. Or is it very easy? If it can be done
easily, maybe we should do it now. Otherwise, it might make more
sense to produce a different document, a companion to DynAuth, that
would explain it.

--Jari

Re: : RE: Issue 404: NASREQ-11 Issues

> Isn't DynAUth an Internet-Draft? How stable is it, and how appropriate
> would it be for us to document in an RFC how convert to draft protocol?

As I understand it draft-chiba-radius-dynamic-authorization-18.txt has
incorporated all IESG comments and is awaiting final approval for
publication. So it is stable. However, the conversion between RADIUS and
Diameter is tricky as described below. My concern is that we
might have to fix NASREQ or draft-chiba to make conversation possible, and
if we don't think this through now, there will be a "gotcha" that would
make it hard/impossible.

> I do see this as important, actually. But I'm wondering if we should
> publish this one separately. Or is it very easy?

I believe that it's important for deployment of Diameter. draft-chiba is
already in widespread use and given the number of NASes that support
RADIUS, if Diameter/RADIUS translation is not possible then Diameter will
be undeployable wherever draft-chiba is used.

Here are the issues that arise:

a. Diameter NAS talking to a RADIUS server via a Diameter/RADIUS gateway.
The gateway copies the identification attributes from the CoA or
Disconnect Request into a Diameter disconnect or reauthorization request.
NASREQ should support the same identification attributes as draft-chiba to
make this easy -- we need an ABNF for disconnect or reauthorization
requests in NASREQ to make this clear. The Diameter NAS then sends a re-
authorization or termination request. I'd suggest that the termination
request be translated to a Disconnect-ACK in RADIUS, with the Diameter
gateway providing a response in Diameter. The re-authorization request
should be translated to a CoA-ACK in RADIUS, with the authorization change
attributes being inserted into the re-authorization response.

The other alternative is to try to translate the Diameter re-authorization
request into something like a RADIUS "call check" -- but I think that
within draft-chiba it is necessary to receive a CoA-NAK or ACK as a
response, not just a "call check" Request.

b. RADIUS NAS talking to a Diameter server via a Diameter/RADIUS gateway.
Here the Diameter server sends a CoA or disconnect request. The gateway
translates a Diameter disconnect request into a RADIUS Disconnect-Request
by using the same identification attributes in both. The gateway then
receives a Disconnect-ACK from the RADIUS NAS and translates this to a
Diameter disconnect request; the Diameter server responds with a
disconnect response and the gateway throws this away (doesn't need to be
translated).

A Diameter CoA request is somewhat trickier, because it only contains
identification attributes. I think the gateway needs to reply with a
Diameter re-authorization request, without sending any packet to the
RADIUS NAS. After receiving the Diameter re-authorization response, the
gateway can issue a CoA-Request to the RADIUS NAS by copying both the
identification and authorization attributes into the CoA-Request. The
gateway then receives a CoA-ACK or CoA-NAK and discards this because it
isn't translatable. This is a bit of a problem because the Diameter server
will believe that its request was honored while it may not have been.

Translation between Diameter and RADIUS is made considerably simpler if
We were to support an (optional) sequence more akin to Diameter in draft-chiba.
For example, a Request with a Service-Type of "Reauthorization" would be
interpretted purely as a identification of a session that needs to be
re-authorized, or disconnected. The RADIUS NAS would then respond with
a NAK to acknowledge receipt, including an Error-Cause attribute
saying "In progress", and would then send an Access-Request.

This makes case a) simpler because presumably the RADIUS server would use
this sequence when talking to a Diameter NAS. Case b) is also simpler
because the Diameter messages now are more easily translated to RADIUS
equivalents.

> If it can be done easily, maybe we should do it now.

It can be done easily *if* we make the above change to draft-chiba.

> Otherwise, it might make more
> sense to produce a different document, a companion to DynAuth, that
> would explain it.

If we issue DynAuth now with no changes, translation could prove
impractical for the reasons cited above. I don't believe that this is
something we can put off.

Re: : RE: Issue 404: NASREQ-11 Issues

> Isn't DynAUth an Internet-Draft? How stable is it, and how appropriate
> would it be for us to document in an RFC how convert to draft protocol?

I've gone through draft-chiba and identified modifications required to
enable translation by a Diameter/RADIUS gateway.  This requires addition
of a Service-Type with value "Authorize Only" to both Disconnect/CoA
messages as well as to a RADIUS Access-Request.  A version of the draft
with the potential changes included is available for inspection here:

http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-19.txt

If people think these potential changes represent a useful addition, I can
update draft-chiba to include them.

Re: : RE: Issue 404: NASREQ-11 Issues

Bernard Aboba wrote:

> I believe that it's important for deployment of Diameter. draft-chiba is
> already in widespread use and given the number of NASes that support
> RADIUS, if Diameter/RADIUS translation is not possible then Diameter will
> be undeployable wherever draft-chiba is used.

Ok, I'm now convinced we need to do it.

> Translation between Diameter and RADIUS is made considerably simpler if
> We were to support an (optional) sequence more akin to Diameter in draft-chiba.
> For example, a Request with a Service-Type of "Reauthorization" would be
> interpretted purely as a identification of a session that needs to be
> re-authorized, or disconnected. The RADIUS NAS would then respond with
> a NAK to acknowledge receipt, including an Error-Cause attribute
> saying "In progress", and would then send an Access-Request.
> 
> This makes case a) simpler because presumably the RADIUS server would use
> this sequence when talking to a Diameter NAS. Case b) is also simpler
> because the Diameter messages now are more easily translated to RADIUS
> equivalents.
> 
> 
>>If it can be done easily, maybe we should do it now.
> 
> 
> It can be done easily *if* we make the above change to draft-chiba.

We need to talk to the authors of draft-chiba to see if the
change is feasible in their opinion.

--Jari

Re: : RE: Issue 404: NASREQ-11 Issues

Bernard Aboba wrote:

> I've gone through draft-chiba and identified modifications required to
> enable translation by a Diameter/RADIUS gateway.  This requires addition
> of a Service-Type with value "Authorize Only" to both Disconnect/CoA
> messages as well as to a RADIUS Access-Request.  A version of the draft
> with the potential changes included is available for inspection here:
> 
> http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-19.txt
> 
> If people think these potential changes represent a useful addition, I can
> update draft-chiba to include them.

Great! I didn't realize it was so easy for you to talk to the
authors of draft-chiba 

I haven't looked at the modifications yet, but I recall that you
said it has been deployed, will there be problems because of this
change?

--Jari

Re: : RE: Issue 404: NASREQ-11 Issues

> I haven't looked at the modifications yet, but I recall that you
> said it has been deployed, will there be problems because of this
> change?

The changes have to be optional. But presumably an operator who really
needs Diameter compatibility will demand support from their NAS vendor.
My understsanding is that 3GPP2 is looking at requiring draft-chiba, and
if they want to be able to transition to Diameter at some future point,
then I think that implementing the (optional) changes is a good idea.

RE: : RE: Issue 404: NASREQ-11 Issues

Bernard,

> I've gone through draft-chiba and identified modifications required to
> enable translation by a Diameter/RADIUS gateway.  This requires addition
> of a Service-Type with value "Authorize Only" to both Disconnect/CoA
> messages as well as to a RADIUS Access-Request.  A version of the draft
> with the potential changes included is available for inspection here:
> 
> http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-19.txt
> 
> If people think these potential changes represent a useful 
> addition, I can update draft-chiba to include them.

I think that this would be useful, I support updating the draft to 
support it.

John