RE: AW: [NSIS] Re: authorizing query messages

David,

Just a question: Do we need to enhance
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-09.txt
to include QSPEC if you we decide to use DIAMETER to perform the
authorization for users' resources?

Thanks,

An
-----Original Message-----
From: David R Oran [mailto:oran@cisco.com]
Sent: Monday, October 10, 2005 10:52 AM
To: Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;
nsis@ietf.org
Subject: Re: AW: [NSIS] Re: authorizing query messages

Do you think it makes sense to have the authorization response to the  
query return a QSPEC with the user's authorized resources so that can  
be returned along with the available resources (or alternatively used  
by the NSLP to reduce the reported available resources to only the  
amount authorized?

On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote:

> hi jukka,
>
> thanks for your feedback. here is a proposal how to handle  
> authorization
> for the query message:
>
> the query message triggers a QAR with the authentication info but
> without any QoS-Resources.
> it might be necessary to indicate (somewhere) that this is only a  
> query
> without the need to enable accounting and charging.
>
> as such, the response in the QAA is also limited to the result rather
> than returning information like avps like CC-Time,Cost,
> QoS-Resources,Authz-time).
>
> here is the figure:
>
>    End-Host         Network Element             Entity
>   requesting QoS      ( Diameter              ( Diameter
>                        QoS Client)             QoS Server)
>       |                   |                         |
>       +---QoS-Query------>|                         |
>       |                   +- - - - - QAR - - - - - >|
>       |                   |(QoS-Resources=NULL,     |
>       |                   |   QoS-Auth-Data,User-ID)|
>       |                   |                +--------+--------------+
>       |                   |                |  Authorize request    |
>       |                   |                |  Keep no session data |
>       |                   |                |                       |
>       |                   |                +--------+--------------+
>       |                   |< - - - - QAA - - - - - -+
>       |                   |(Result-Code)            |
>       |                   |                         |
>       |           +-------+---------+
>       |           |Proceeed with    |
>       |           |QoS signaling    |
>       |           |exchange         |
>       |           +-------+---------+
>       |                   |
>       |                   +----------QoS-Reserve--------------->
>       |                   |
>       |                   |<---------QoS-Response---------------
>       |<--QoS-Response----+
>
>
> ciao
> hannes
>
>
>
>> Hi,
>>
>> I would expect that in certain networks, not everybody may query the
>> network of available resources. Thus, there could be need to
>> include an
>> auhtorization token, or ask from a Diameter server whether the node
>> sending the query is allowed to do that.
>>
>> Cheers,
>> Jukka
>>
>>
>> On Thu, 6 Oct 2005, Hannes Tschofenig wrote:
>>
>>
>>
>>> hi all,
>>>
>>> as part of our work on the diameter-qos application and the
>>>
>>>
>> radius-qos draft
>>
>>
>>> we came across the aspect of authorizing individual types
>>>
>>>
>> of actions taken by
>>
>>
>>> the qos signaling protocol. from discussions in the past i
>>>
>>>
>> remember that
>>
>>
>>> people wanted to authorize query messages as well. when we
>>>
>>>
>> come to the
>>
>>
>>> concrete details we are not quite sure what it actually
>>>
>>>
>> means. what would be
>>
>>
>>> the authorization decision regarding the query message
>>>
>>>
>> people have in mind?
>>
>>
>>>
>>> ciao
>>> hannes
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
>>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
>

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis