headers
Jari Arkko | 11 May 2003 09:35
Picon
Picon

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
Permalink | Reply |
headers
Bernard Aboba | 11 May 2003 17:42

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.
Permalink | Reply |
headers
Jari Arkko | 11 May 2003 20:00
Picon
Picon

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
Permalink | Reply |
headers
Bernard Aboba | 11 May 2003 20:15

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.
Permalink | Reply |
headers
Bernard Aboba | 11 May 2003 14:57

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
(Continue reading)

Permalink | Reply |
headers
Jari Arkko | 11 May 2003 19:55
Picon
Picon

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.
(Continue reading)

Permalink | Reply |

Gmane