Questions about handling of RFC 3576 Service-type Authorize-only

[Joe Urbasik <joe.urbasik@siemens.com>]

Hello,

I am looking at implementing a server for the protocol in RFC 3576, and I
have a few questions regarding the "Authorize-only" Service-type.

I have looked through the archives for this list, and have also browsed RFC
2865 and 4005, in trying to find answers.

RFC 3576 requires a conforming implementation to respond to a DM or CoA
request with Service-type Authoize-only with a NAK to the Initial Request,
followed by a RADIUS Access-request. I understand from the description in
RFC 3576 that this Access-request is meant to trigger a "reauthorization".

I am trying to understand this part of the protocol, in the case where the
Initial request is generated from a Radius server, as opposed to a
Radius/Diameter gateway.

I have these two general questions:

1a. What is the usage scenario for this feature, from a network management
perspective ?

I know the RFC says that "This enables a usage model akin to that supported
in Diameter, thus easing translation between the two protocols". but I am
not so familiar with Diameter, and I do not understand what the need is for
this feature - is this strictly for forward compatibility with Diameter ?

1b. What is the usage scenario, with radius servers ? (This may be the same 
question from another perspective, but in case it isn't) :

From the point of view of someone wanting to enhance a radius server, what
is the need or attraction for implementing/issuing the "Authorize-only"
requests within this protocol ?

2. The RFC states that the Radius Access-request is to be sent by the
RFC3576 Server. Implicit in this is that the RFC3576 server will get a
response - is it expected to act on that response message ? 

Can the sending of the Access Request be performed by a different server
process, or must the Request come from the same process (or port) that
received the initial Authorize-only request, and that issued the NAK ? In
other words, is the Radius Server maintaining some sort of state between the
two messages ?


I also have 2 specific technical questions

1. I have assumed that the values for the Attributes are to be taken from
RFC 2865, yet in that RFC, "Service-type" has defined the value
"Authenticate-only", not "Authorize-only"

2. Regarding permitted attributes, the paragraph at the top of page 13 says:

   Where a Service-Type Attribute with value "Authorize Only" is
   included within a CoA-Request or Disconnect-Request, attributes
   representing an authorization change MUST NOT be included; only
   identification attributes are permitted.  If attributes other than
   NAS or session identification attributes are included in such a CoA-
   Request, implementations MUST send a CoA-NAK;

My interpretation of this statement is that only the (3) "NAS identification
attributes" and (12) "Session identification attributes", as listed at the 
start of section 3, MAY be in the message. However that interpretation 
excludes Service-type (trivial) and State (less trivial - see [Note 7] ).

Have I misinterpreted the paragraph, or are those actually the exceptions ?


Thank you in advance, for any help that you are able to offer. 


Joe Urbasik
Senior Software Developer 

Chantry Networks.
Ph: 905-567-6900 x6484
Fax:905-567-0099

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>