Subject: RE: [AAA-WG]: Issue 405: RADIUS compatibility

From: <[email-masked]>
Date: Thu, 13 Mar 2003 06:44:48 +0200

I support this.

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 12 March, 2003 22:16
> To: [email-masked]
> Subject: [AAA-WG]: Issue 405: RADIUS compatibility
> 
> 
> Issue 405: RADIUS compatibility
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: March 11, 2003
> Reference:
> Document: NASREQ-11
> Comment type: Technical
> Priority: S
> Section: 9
> Rationale/Explanation of issue:
> As noted in Section 2.2, it is possible for a Diameter server to
> know that it is talking to a RADIUS client. This is indicated
> by an AAR message containing a NAS-IP-Address, NAS-IPv6-Address
> or NAS-Identifier AVP.
> 
> Given this, the Diameter can restrict itself to use of RADIUS
> compatible attributes and commands. I would suggest that a 
> discussion of
> this
> issue be included in a separate sub-section of Section 9:
> 
> "9.X.X RADIUS compatibility mode
> 
> Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs
> are not used by Diameter clients within AAR messages, the presence
> of these attribute indicates that the Request was originated
> by a RADIUS client and subsequently translated.
> 
> A Diameter server receiving such a message SHOULD restrict itself
> to use of AVPs within the range 0-255, so as to ensure RADIUS
> backward compatibility. In addition, a Diameter server SHOULD NOT
> by default attempt server-initiated re-authentication or 
> re-authorization
> for a session known to have been initiated by a RADIUS client.
> 
> In addition, the Authorization-Lifetime AVP SHOULD
> NOT be included in an AA-Answer message relating to such a session;
> instead the equivalent RADIUS attributes (e.g. Session-Timeout and
> Termination-Action) SHOULD be used instead. Within Diameter these
> attributes have the same meaning as within RADIUS."
> 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Mar 2003 21:38:58 -0800 (PST)

It also occurred to me that it would be worthwhile to talk about the case
where a Diameter NAS is talking to a RADIUS server. Here the dynamic is a
bit different, because the Diameter NAS may not know it is talking to a
RADIUS server, and the RADIUS server may not know it is talking to a
Diameter NAS.

However, the first time that the Diameter NAS includes an attribute >255,
or uses a Diameter-only capability, it will presumably get back an error
message from the Diameter/RADIUS gateway saying "RADIUS compatiblity mode
required." At that point, the Diameter NAS should limit its dialect to
RADIUS compatibility mode.

Given that the RADIUS/Diameter gateway is a NASREQ function, I expected to
find some discussion of gateway error messages in the document, but in
searching through it, there is really no discussion of the Error-Message
AVP usage within this application.

It is not entirely clear to me that the DIAMETER_AVP_UNSUPPORTED or
DIAMETER_AVP_NOT_ALLOWED messages are appropriate for a case where an AVP
is >255 and therefore cannot be translated. Perhaps we need a
DIAMETER_AVP_UNTRANSLATABLE error message?

Similarly, DIAMETER_COMMAND_UNSUPPORTED doesn't seem like the right error
message for the case where a command can't be translated (e.g. unsolicited
Diameter disconnect reaching a gateway that doesn't support [DynAuth]).
Perhaps a DIAMETER_COMMAND_UNTRANSLATABLE is needed?

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2003 14:45:05 +0200

> RADIUS compatibility mode.

Sounds good.

> DIAMETER_AVP_UNTRANSLATABLE error message?

Yes. Can we add one in the NASREQ document, or should it have
been in the base?

> Perhaps a DIAMETER_COMMAND_UNTRANSLATABLE is needed?

I'd use that, yes.

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Mar 2003 04:18:32 -0800 (PST)

> Yes. Can we add one in the NASREQ document, or should it have

It's unique to a RADIUS/Diameter gateway, which I gather is something that
is part of the NAS application and its decendants (EAP too, I guess). So
one could make an argument that it is not needed for *all* Diameter
applications and so needn't be part of Base.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Mar 2003 04:42:03 -0800 (PST)

OK. Here is my revised text, taking the error messages into account:

Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs
are not used by Diameter clients within AAR messages, the presence
of these attributes indicates that the Request was originated
by a RADIUS client and subsequently translated.

backward compatibility.

attributes have the same meaning as within RADIUS.

When a Diameter/RADIUS gateway
encounters an untranslatable AVP, it will
return a DIAMETER_AVP_UNTRANSLATABLE value in the
Error-Message AVP. A Diameter NAS encountering
this error SHOULD restrict itself to use of AVPs
with the range 0-255 so as to ensure RADIUS backward
compatibility.

Similarly, when a Diameter/RADIUS
gateway encounters an untranslatable command, it will
return a DIAMETER_COMMAND_UNTRANSLATABLE value in
the Error-Message AVP. A Diameter NAS encountering
this error SHOULD restrict use of the offending
command, so as to ensure RADIUS backward compatibility.

Since RADIUS does not support server-initiated re-authentication
and implementations may not support server-initiated re-authorization
[DynAuth], a Diameter server SHOULD NOT attempt server-initiated
re-authentication for a session known to be initiated by a RADIUS
client. A Diameter server MAY attempt server-initiated re-authorization
or session termination for a session known to be initiated by a
RADIUS client. However, it will typically receive a
DIAMETER_COMMAND_UNTRANSLATABLE error message in response.
A Diameter server encountering this error SHOULD NOT continue
to attempt server-initiated re-authorization or session-termination
for that NAS. "

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2003 23:46:05 +0200

Ok. And we need a section defining the new error codes.

Jari