RE: QoS attributes

["Roy, Radhika R, ALABS" <rrroy@att.com>]

Hi, John:

Here, I also agree with you.

With respect to the use of IPSec/TLS in SIP, what happens is this:

1. IPSec/TLS channels are opened before sending any SIP messages and it is assumed that the user is authenticated. At this point, no one is sure whether it is a SIP call or any other call. Of  course, SIP service level authorization cannot be done at this level, as you have indicated.

2. Then SIP calls are made over the IPSec/TLS channels. Now, re-authentication of the user may not be needed for every SIP signaling message. In this case, a security association is needed between the IPSec/TLS layer and SIP/VoIP layer. The key is this: If the same AAA server is used, this server can do the security association faithfully without re-authentication. I guess this the beauty of AAA server.

3. Item 2 solves one of the most important problems. For example, the call setup time for the SIP/layer reduces drastically. There are other advantages, and we will talk about those as well.

I have those things in my mind when I referred to IPsec/TLS.

br,
Radhika

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Wednesday, January 07, 2004 6:32 AM
To: Roy, Radhika R, ALABS; jari.arkko@piuha.net;
Madjid.Nakhjiri@motorola.com
Cc: avi@bridgewatersystems.com; radiusext@ops.ietf.org
Subject: RE: QoS attributes


Hi Radhika,

> As long as authentication, authorization, and accounting for 
> any services (e.g., VoIP services/SIP, QoS services, any 
> other resources) of a given call are concerned, it is in the 
> domain of the AAA protocol.

Agreed.
 
> However, services or calls are usually reside in the 
> application layer, and we should restrict ourselves to remain 
> in that layer as per standards. In the same token, calls 
> (e.g., opening of a transport channel) can be in the 
> transport layer (e.g., IPSec, TLS) as well .

Well, one can think of an AAA server used as a subscriber 
database.  The AAA server needs to check if a user is
authorized for a particular server.
 
> Now, there are some dependency. For example, if 
> authentication/authorization services are provided for the 
> SIP/VoIP services, it means it should also deal with QoS 
> resources in the SIP layer if the AAA server wants to do 
> something specific to QoS (e.g., use of specific codecs or 
> applications - this ,in turn, will lead to detail QoS 
> parameters for each media) of that SIP call.
> 
> If the authentication is provided for a user for the 
> transport layer (e.g., IPSec, TLS) only, we can deal with the 
> IP/Transport layer QOS resources (e.g., RSVP, DiffServe) 
> authorization. If we stop here for the Transport layer call, 
> as I understand from your email, I think that we are OK.

I don't think that IPSec or TLS can do service level authorization,
so wrt QoS, I don't think IPSec or TLS is enough.

> If a SIP user is authentication, it will also mean how to 
> authorize the use of resources like codecs (e.g., audio, 
> video) and applications (e.g., white board, data sharing). If 
> we stop here for the SIP call, as I understand from your 
> email, I think that we are OK.

OK.
 
> From AAA server point of view, the QoS attributes MUST be 
> generic enough, like authentication/authorization, to satisfy 
> all the needs for all types (e.g., application, transport) of 
> calls (e.g., SIP, IPSec/TLS). This is our challenge in 
> creating the common QoS attributes standard for the AAA server.

Agreed.

To add.  Suppose I want to have a video call to you, using SIP.
I have a 3G mobile phone & you are using a laptop with WLAN.  
We may use SIP to initiate the call & codecs, however my operator may 
want to use some sort of AAA protocol (RADIUS / Diameter) to see if
I am allowed to use such a service and your ISP may want to 
check to see that you are allowed to use a certain amount of
bandwidth.  COPS may be used interally within the operator/ISP
network for traffic management, etc.  Use of preconditions with
SIP may ensure that we have sufficient QoS service for the call.
However, one thing is missing, there is no end-to-end mechanism
to ensure we are using similar QoS settings for the call.   My 
bandwidth might be 128k while yours might be 2M.  

John


--
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/>

--
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/>