Subject: RE: Subtypes (again) and other ideas
From: Avi Lior <[email-masked]>
To: 'Nakhjiri Madjid-MNAKHJI1' <[email-masked]>, Avi Lior <[email-masked]>, 'Victor Gamov' <[email-masked]>, [email-masked]
Date: Thu, 29 Jan 2004 17:30:09 -0500

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Tuesday, January 27, 2004 3:32 PM
> To: 'Avi Lior'; 'Victor Gamov'; [email-masked]
> Subject: RE: Subtypes (again) and other ideas
> 
> 
> Hi Avi,
> 
> I am not sure, if I understand the problem you are raising 
> below. Are you saying that a sub attribute out of for 
> instance WLAN attribute (which is treated as a vendor 
> specific) needs security, then that piece of data cannot be a 
> subattribute anymore? If true, although I agree that is a 
> problem, but isn't that already a 
> problem for vendor specific attributes?

It is. 

> The suggested idea seems to be the best way to handle all the 
> new applications that are popping up with the limited 
> attribute space. Furthermore, this approach won't tie the 
> hand of application designers to have to map all their data 
> into existing attributes.

But don't forget my other reason. Not using application space allows us to
reuse attributes.

I think that there is a better approach to handling the limited attribute
space for RADIUS.  I already posted an internet draft for that.  See
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-lior-radius-attribut
e-type-extension-00.txt 

> Regards,
> Madjid
> 
> >
> I have some issues with the above scheme:
> 
> You want to introduce application spaces by allowing us to 
> group attributes for a given application into a single 
> attribute.  There is a problem with this approach.
> 
> If one of these attributes for example had to password 
> protected then this would break base radius processing.  We 
> would have to promote the attribute such that it appears as a 
> base radius attribute breaking the scheme you propose.
> 
> Secondly, we should strive to reuse attributes as much as 
> possible.  Note I don't mean overload attributes but when an 
> attribute is symmatically the same for two applications it 
> should be reused.
> 
>  
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 27 Jan 2004 20:34:01 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Victor Gamov'" <[email-masked]>, [email-masked]
Subject: RE: Subtypes (again) and other ideas
Date: Tue, 27 Jan 2004 14:31:48 -0600

Hi Avi,

I am not sure, if I understand the problem you are raising below.
Are you saying that a sub attribute out of for instance WLAN attribute
(which is treated as a vendor specific) needs security, then that piece
of data cannot be a subattribute anymore?
If true, although I agree that is a problem, but isn't that already a 
problem for vendor specific attributes?
The suggested idea seems to be the best way to handle all the new applications
that are popping up with the limited attribute space.
Furthermore, this approach won't tie the hand of application designers
to have to map all their data into existing attributes.

Regards,
Madjid

>
I have some issues with the above scheme:

You want to introduce application spaces by allowing us to group attributes
for a given application into a single attribute.  There is a problem with
this approach.

If one of these attributes for example had to password protected then this
would break base radius processing.  We would have to promote the attribute
such that it appears as a base radius attribute breaking the scheme you
propose.

Secondly, we should strive to reuse attributes as much as possible.  Note I
don't mean overload attributes but when an attribute is symmatically the
same for two applications it should be reused.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 14 Jan 2004 21:59:54 +0000
From: Avi Lior <[email-masked]>
To: 'Victor Gamov' <[email-masked]>, [email-masked]
Subject: RE: Subtypes (again) and other ideas
Date: Wed, 14 Jan 2004 16:59:05 -0500

Hi Victor,

See my comments below:

> We can standardize that (for example) attribute 241 must be used for 
> WLAN, 242 for LAN, 243 for SIP and so on.  The format of such 
> attributes 
>   like Vendor-Specific (26) attribute.
> Madjid write about idea like this and Diameter specification describe 
> something like this (but I still not familar with it).
> 
> Or another way is to use some attribute (241 for example) to carry 
> service-specific information (based on Service-Type attribute) like 
> Vendor-Specific attribute format:
>
> Service-Specific ::= 241 Length Service-Type String
> String ::= Type Length Value ...
> 
> Service-Type value in Service-Type attribute and in Service-specific 
> attribute must be equal. If not server/client may (must?) ignore this 
> this attribute (or whole packet?)
> 
> And then use 242 (for example) to carry application-specific 
> information 
> such as "Prepaid" or others; 243 to carry tunnel-specific information 
> (based on Tunnel-Type attribute) and so on.
> 
> Many of this attributes will have similar names but different 
> purpose. 
> For example, Filter-* attributes for WLAN and LAN (different 
> services) 
> may define filter for different layers.
> 
> All info used in many services or applications may be TLV or 
> grouped in 
> new attribute with same logic.
> 
> We don't introduce new packet format.
> We don't introduce new packet type.
> We don't change dictionary format. Only extend it with new TLV 
> attributes and new Service-Specific (SERVICEATTR) attributes. 
> We don't introduce subtypes. Only new attribute and attribute logic 
> similar Vendor-Specific attribute but potentially with more checks.

I have some issues with the above scheme:

You want to introduce application spaces by allowing us to group attributes
for a given application into a single attribute.  There is a problem with
this approach.

If one of these attributes for example had to password protected then this
would break base radius processing.  We would have to promote the attribute
such that it appears as a base radius attribute breaking the scheme you
propose.

Secondly, we should strive to reuse attributes as much as possible.  Note I
don't mean overload attributes but when an attribute is symmatically the
same for two applications it should be reused.

> 2. Large packets
> All current packets type has one format and maximum allowable 
> length is 
> 4096 (why 4096 not? min UDP packet size?). But we still have 
> unassigned 
> packet code.  So we can standardize new packets type 
> (Authorization-BIG-response) that will be carry authorization 
> information and have attribute Length size more than one 
> octet. And we can add new attribute used in Access-Request 
> packet which will be 
> tell NAS to send Authorization-BIG-Request with same parameters as in 
> Access-Request to get authorization info from AAA-server.

Do you have any evidence that we need to increase the packet size.

> 3. Roaming and QoS
> When we talk about roaming access we must have in mind that 
> AAA-protocols used to deliver info to NAS only.
> The User-Profile paradigm must be used to store information about QoS 
> and other parameters based on NAS-IP-Address and Service-Type 
> (and some 
> other attributes from Access-Request packet).  So if NAS 
> cann't support 
>   requested QoS it can refuse user or requsted service for 
> example. Or 
> allow service with pure QoS. But this behaivor must be based on 
> providers agreement only not to AAA logic.  And we can write BCP to 
> illustrate this situations.
> 
> 
> All this ideas are backward compatible and not so difficult 
> for programming.
> 
> Any suggestions?
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Jan 2004 16:22:46 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Subtypes (again) and other ideas 
Date: Tue, 13 Jan 2004 11:23:44 -0500
Message-Id: <[email-masked]>

Victor Gamov <[email-masked]> wrote:
> First of all: sorry for my English. I hope that you will be understand me.

  You're doing fine.

> 1. Subtypes.
> We have some unassigned attribute types in RFC-2865 and others. On other 
> hand we need to support many service or even application specific 
> attributes. So I think that we can use unassigned types to do it.
> 
> We can standardize that (for example) attribute 241 must be used for 
> WLAN, 242 for LAN, 243 for SIP and so on.  The format of such attributes 
>   like Vendor-Specific (26) attribute.

  I think that's a reasonable idea.  The extra attributes should
really be hidden from the main RADIUS attribute space.

  On a functional level, much of the data required for WLAN, etc. may
be treated as an opaque protocol, transported inside of RADIUS.  In
that case, a design similar to EAP-Message packaging EAP packets would
be useful.

  Where a protocol like EAP doesn't already exist, and where the
encapsulated data is specific to RADIUS, it just makes sense to put
them into TLV's, like other RADIUS attributes.

> We don't introduce new packet format.
> We don't introduce new packet type.
> We don't change dictionary format. Only extend it with new TLV 
> attributes and new Service-Specific (SERVICEATTR) attributes.
> We don't introduce subtypes. Only new attribute and attribute logic 
> similar Vendor-Specific attribute but potentially with more checks.

  I agree.

> 2. Large packets
> All current packets type has one format and maximum allowable length is 
> 4096 (why 4096 not? min UDP packet size?). But we still have unassigned 
> packet code.  So we can standardize new packets type 
> (Authorization-BIG-response) 

  Are there compelling reasons for these large packets?

  In this case, I'm inclined to agree with the charter restrictions.
Large RADIUS packets generally mean your system is designed
inefficiently.

> 3. Roaming and QoS

  I have fewer opinions here.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Jan 2004 11:29:48 +0000
Date: Tue, 13 Jan 2004 14:29:01 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Subtypes (again) and other ideas

Hi gentlemens!

First of all: sorry for my English. I hope that you will be understand me.

I just finished to read this list about last three mounts. I find many 
interesting threads and many ideas in it.  But questions still more.

Following my IMHO about some this questions.

1. Subtypes.
We have some unassigned attribute types in RFC-2865 and others. On other 
hand we need to support many service or even application specific 
attributes. So I think that we can use unassigned types to do it.

We can standardize that (for example) attribute 241 must be used for 
WLAN, 242 for LAN, 243 for SIP and so on.  The format of such attributes 
  like Vendor-Specific (26) attribute.

Madjid write about idea like this and Diameter specification describe 
something like this (but I still not familar with it).

Or another way is to use some attribute (241 for example) to carry 
service-specific information (based on Service-Type attribute) like 
Vendor-Specific attribute format:

Service-Specific ::= 241 Length Service-Type String
String ::= Type Length Value ...

Service-Type value in Service-Type attribute and in Service-specific 
attribute must be equal. If not server/client may (must?) ignore this 
this attribute (or whole packet?)

And then use 242 (for example) to carry application-specific information 
such as "Prepaid" or others; 243 to carry tunnel-specific information 
(based on Tunnel-Type attribute) and so on.

Many of this attributes will have similar names but different purpose. 
For example, Filter-* attributes for WLAN and LAN (different services) 
may define filter for different layers.

All info used in many services or applications may be TLV or grouped in 
new attribute with same logic.

We don't introduce new packet format.
We don't introduce new packet type.
We don't change dictionary format. Only extend it with new TLV 
attributes and new Service-Specific (SERVICEATTR) attributes.
We don't introduce subtypes. Only new attribute and attribute logic 
similar Vendor-Specific attribute but potentially with more checks.

2. Large packets
All current packets type has one format and maximum allowable length is 
4096 (why 4096 not? min UDP packet size?). But we still have unassigned 
packet code.  So we can standardize new packets type 
(Authorization-BIG-response) that will be carry authorization 
information and have attribute Length size more than one octet.
And we can add new attribute used in Access-Request packet which will be 
tell NAS to send Authorization-BIG-Request with same parameters as in 
Access-Request to get authorization info from AAA-server.

We introduce new packet type
We introduce new packet format
But both for RADIUS server and client supported new specification. All 
older server/client will be silently discard such packets.

3. Roaming and QoS
When we talk about roaming access we must have in mind that 
AAA-protocols used to deliver info to NAS only.
The User-Profile paradigm must be used to store information about QoS 
and other parameters based on NAS-IP-Address and Service-Type (and some 
other attributes from Access-Request packet).  So if NAS cann't support 
  requested QoS it can refuse user or requsted service for example. Or 
allow service with pure QoS. But this behaivor must be based on 
providers agreement only not to AAA logic.  And we can write BCP to 
illustrate this situations.

All this ideas are backward compatible and not so difficult for programming.

Any suggestions?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 10 Jan 2004 16:56:01 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked]
Subject: Charter issues 
Date: Sat, 10 Jan 2004 11:55:24 -0500

We need to make progress here.

We use terms like subtypes, RADIUS attributes are flat etc... 

But I don't think we have any definitions for these.

I asked the chairs to provide a definition for subtypes etc.... And I have
received no definitions.

If the chairs are saying the Attributes of type String that contains other
attributes are subtypes, and that these are prohibited, then I have a huge
issue with that.

Many of the existing RADIUS attributes meet this criteria.  And David if
that is your definition of subtypes then you are wrong in saying that RADIUS
attributes are flat.

To the chairs, please provide defintions / justification for the terms you
use in the proposed charter.  Otherwise please remove these restrictions.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: January 9, 2004 3:47 PM
> To: Mike Bean; [email-masked]
> Subject: RE: Potential work items 
> 
> 
> Mike Bean writes...
> 
> > We have code in our RADIUS server that parses many 
> structured RADIUS 
> > attribute types, some RFC, most VSA.
> 
> VSAs are fine... for what VSAs were intended for.  I have 
> worked on RADIUS Servers that parsed VSAs, too.  
> 
> > I understand that this group does not want to add new 
> attribute types
> to
> > the RADIUS standard; however, since 3GPP2 standards have 
> been adopted
> and
> > require RADIUS support for sub-type values, it may be 
> helpful to write
> an
> > informational RFC that describes the use of sub-types in a RADIUS 
> > attribute.
> 
> IMHO, it is unfortunate if 3GPP2 has standardized use of 
> RADIUS attributes that substantially "bend" the well-accepted 
> RADIUS architecture.  Having done so, the debate is over how 
> to "promote" these VSAs into some form of standards or 
> multi-vendor status.  Like it or not, the standard RADIUS 
> attribute space is "flat".
> 
> > Perhaps IS-835 and IS-878 can be changed to flatten these sub-type 
> > attributes into separate attributes.
> 
> That would probably be my preference, but I haven't seen the 
> documents you reference.
> 
> > My concern is it may be too late...
> 
> Too late because the implementers have shipped product and 
> don't want to go back and re-implement, in an effort to move 
> into an IETF standards-based arena?  I've heard the argument 
> that the closure of the IETF RADIUS WG created an "open 
> season" for other SDOs to revise the RADIUS architecture, but 
> I just don't buy it.
> 
> > ...providing additional information on how sub-type attributes are
> used
> > can only help developers.
> 
> Help developers to continue to "make the same mistakes"?  
> Sorry for what might be perceived as a cheap shot, but IMHO 
> use of sub-types in non-VSA attributes is a mistake. 
> 
> > I suspect most vendors supporting 3GPP2 in their
> > RADIUS server have already written code to support at least the
> display of
> > sub-type attributes.  My two cents.
> 
> I suppose you are correct.  Is this a case of the de-facto 
> standard forcing the hand of the de-jure standard development?
> 
> Thanks for your contribution to the discussion.  I don't know 
> how this will come out, but having more concrete data helps.
> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Jan 2004 22:19:35 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Mike Bean <[email-masked]>,  [email-masked]
Subject: RE: Potential work items 
Date: Fri, 9 Jan 2004 17:19:00 -0500 

Just to be clear...In the subtype discussions that I was involved with and
in the current I-Ds that use them, Nobody requires changes to the
Dictionary.

Nobody is introducing a new type.

I really don't see what the all the fuss is about.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Friday, January 09, 2004 3:47 PM
> To: Mike Bean; [email-masked]
> Subject: RE: Potential work items 
> 
> 
> Mike Bean writes...
> 
> > We have code in our RADIUS server that parses many 
> structured RADIUS 
> > attribute types, some RFC, most VSA.
> 
> VSAs are fine... for what VSAs were intended for.  I have 
> worked on RADIUS Servers that parsed VSAs, too.  
> 
> > I understand that this group does not want to add new 
> attribute types
> to
> > the RADIUS standard; however, since 3GPP2 standards have 
> been adopted
> and
> > require RADIUS support for sub-type values, it may be 
> helpful to write
> an
> > informational RFC that describes the use of sub-types in a RADIUS 
> > attribute.
> 
> IMHO, it is unfortunate if 3GPP2 has standardized use of 
> RADIUS attributes that substantially "bend" the well-accepted 
> RADIUS architecture.  Having done so, the debate is over how 
> to "promote" these VSAs into some form of standards or 
> multi-vendor status.  Like it or not, the standard RADIUS 
> attribute space is "flat".
> 
> > Perhaps IS-835 and IS-878 can be changed to flatten these sub-type 
> > attributes into separate attributes.
> 
> That would probably be my preference, but I haven't seen the 
> documents you reference.
> 
> > My concern is it may be too late...
> 
> Too late because the implementers have shipped product and 
> don't want to go back and re-implement, in an effort to move 
> into an IETF standards-based arena?  I've heard the argument 
> that the closure of the IETF RADIUS WG created an "open 
> season" for other SDOs to revise the RADIUS architecture, but 
> I just don't buy it.
> 
> > ...providing additional information on how sub-type attributes are
> used
> > can only help developers.
> 
> Help developers to continue to "make the same mistakes"?  
> Sorry for what might be perceived as a cheap shot, but IMHO 
> use of sub-types in non-VSA attributes is a mistake. 
> 
> > I suspect most vendors supporting 3GPP2 in their
> > RADIUS server have already written code to support at least the
> display of
> > sub-type attributes.  My two cents.
> 
> I suppose you are correct.  Is this a case of the de-facto 
> standard forcing the hand of the de-jure standard development?
> 
> Thanks for your contribution to the discussion.  I don't know 
> how this will come out, but having more concrete data helps.
> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Jan 2004 20:48:18 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items 
Date: Fri, 9 Jan 2004 15:46:42 -0500
From: "Nelson, David" <[email-masked]>
To: "Mike Bean" <[email-masked]>, <[email-masked]>

Mike Bean writes...

> We have code in our RADIUS server that parses many structured RADIUS
> attribute types, some RFC, most VSA.

VSAs are fine... for what VSAs were intended for.  I have worked on
RADIUS Servers that parsed VSAs, too. =20

> I understand that this group does not want to add new attribute types
to
> the RADIUS standard; however, since 3GPP2 standards have been adopted
and
> require RADIUS support for sub-type values, it may be helpful to write
an
> informational RFC that describes the use of sub-types in a RADIUS
> attribute.

IMHO, it is unfortunate if 3GPP2 has standardized use of RADIUS
attributes that substantially "bend" the well-accepted RADIUS
architecture.  Having done so, the debate is over how to "promote" these
VSAs into some form of standards or multi-vendor status.  Like it or
not, the standard RADIUS attribute space is "flat".

> Perhaps IS-835 and IS-878 can be changed to flatten these sub-type
> attributes into separate attributes.

That would probably be my preference, but I haven't seen the documents
you reference.

> My concern is it may be too late...

Too late because the implementers have shipped product and don't want to
go back and re-implement, in an effort to move into an IETF
standards-based arena?  I've heard the argument that the closure of the
IETF RADIUS WG created an "open season" for other SDOs to revise the
RADIUS architecture, but I just don't buy it.

> ...providing additional information on how sub-type attributes are
used
> can only help developers.

Help developers to continue to "make the same mistakes"?  Sorry for what
might be perceived as a cheap shot, but IMHO use of sub-types in non-VSA
attributes is a mistake.=20

> I suspect most vendors supporting 3GPP2 in their
> RADIUS server have already written code to support at least the
display of
> sub-type attributes.  My two cents.

I suppose you are correct.  Is this a case of the de-facto standard
forcing the hand of the de-jure standard development?

Thanks for your contribution to the discussion.  I don't know how this
will come out, but having more concrete data helps.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Jan 2004 20:11:26 +0000
From: "Mike Bean" <[email-masked]>
To: <[email-masked]>
Subject: Re: Potential work items 
Date: Fri, 9 Jan 2004 12:10:11 -0800

We have code in our RADIUS server that parses many structured RADIUS
attribute types, some RFC, most VSA.  Usually this parsing is done so that
we can make a decision based on the data contained in the sub-fields or so
that internals of the value type can be read easily in logs or output files.
Unless an attribute is protected by some security association between two
RADIUS servers, the values can be marked as string in the RADIUS dictionary
and be passed through a RADIUS proxy server as "opaque" values.  If the
attribute is encrypted based on the shared secret between a RADIUS client
and server, then hopefully the attribute is encrypted using the method used
for tunnel-password so proxy servers can re-encrypt.  The assumption is most
RADIUS servers can mark an attribute as type tunnel-password in their
dictionary.  We had to add special support to proxy Cisco-AVPairs containing
session keys because of a non-standard encryption scheme.

I understand that this group does not want to add new attribute types to the
RADIUS standard; however, since 3GPP2 standards have been adopted and
require RADIUS support for sub-type values, it may be helpful to write an
informational RFC that describes the use of sub-types in a RADIUS attribute.
Sure most of these attributes are for accounting and only a billing server
needs to understand them; however, they are still carried in RADIUS packets.
Perhaps IS-835 and IS-878 can be changed to flatten these sub-type
attributes into separate attributes.  My concern is it may be too late and
providing additional information on how sub-type attributes are used can
only help developers.  I suspect most vendors supporting 3GPP2 in their
RADIUS server have already written code to support at least the display of
sub-type attributes.  My two cents.

Here an example of a sub-type definition from our XML based dictionary:

<attribute name="3GPP2-PrePaid-Acct-Quota" vendor="3GPP2" code="90"
type="cdma-group">
  <subattribute name="Quota-ID" code="1" type="integer" />
  <subattribute name="Volume-Quota" code="2" type="integer" />
  <subattribute name="Volume-Quota-Overflow" code="3" type="short" />
  <subattribute name="Volume-Threshold" code="4" type="integer" />
  <subattribute name="Volume-Threshold-Overflow" code="5" type="short" />
  <subattribute name="Duration-Quota" code="6" type="integer" />
  <subattribute name="Duration-Quota-Overflow" code="7" type="short" />
  <subattribute name="Update-Reason" code="8" type="short-enumeration">
    <value name="Pre-initialization" code="1" />
    <value name="Initial-Request" code="2" />
    <value name="Threshold-Reached" code="3" />
    <value name="Quota-Reached" code="4" />
    <value name="Remote-Forced-Disconnect" code="5" />
    <value name="Client-Service-Termination" code="6" />
    <value name="Main-Service-Instance-Released" code="7" />
    <value name="Service-Instance-Not-Established" code="8" />
  </subattribute>
  <subattribute name="Volume-Used-ATS" code="9" type="integer" />
  <subattribute name="Volume-Used-ATS-Overflow" code="10" type="short" />
  <subattribute name="Tariff-Switch-Interval" code="11" type="integer" />
  <subattribute name="PrePaid-Server-Address" code="12" type="ip-address" />
</attribute>

Mike Bean
NavisRadius Product Group
Lucent Technologies

----- Original Message ----- 
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 08, 2004 11:09 AM
Subject: RE: Potential work items

Avi Lior writes...

> Great!!! I was saying that all along.  Prepaid is exactly that so is
the
> Sterman draft.
> Both of these are add on applications.  They both need specialized
code in
> the RADIUS server to perform their Authentication/Authorization.

My ears prick up when you say "code in the RADIUS server".  If you mean
a separate application (or service) running on the same host as the
RADIUS Server application, and communicating tot eh RADIUS Server via
some API, then fine.

If you mean that the code is integral to the RADIUS Server application
and the parser code that understands RADIUS attributes also needs to
understand the "opaque" messages, then maybe not so fine.

If the "opaque" message format is not documented as part of, or an
extension to, RADIUS or Diameter, then it follows the EAP precedent.

-- Dave

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Jan 2004 15:17:26 +0000
To: [email-masked]
Subject: HTTP Digest in EAP? 
Date: Fri, 09 Jan 2004 16:16:26 +0100
From: [email-masked] (Wolfgang Beck)

While looking to reduce the amount of attribute numbers for
draft-sterman, I stumbled over EAP request / response type 38
'EAP-HTTP Digest', registered by O. Tavakoli of funk.com. I did
not find any draft or other specification of this EAP type. Does
anybody on the list know about it?

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 20:40:08 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 15:39:45 -0500 

> Clearly.  I guess what's in question is whether those RFCs, 
> defining the message format and application behavior for 
> Prepaid Accounting Services, are a potential work item for 
> RADEXT (or AAAEXT).  Prepaid is not RADIUS...

Sip (sterman) is not RADIUS its RADIUS extension as well.
All the other documents are expressing extension to Dial Up hence RADIUS
extension.

All those other Diameter applications are extending the base diameter and
hence Diameter Extensions.
 
> -- Dave
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 20:10:24 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 15:08:51 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> We still need to document the opaque messages though in the RFCs.
This is
> akin to Diameter Applications.

Hmmm...  Somehow I feel that the Diameter Applications are tied more
intimately to the Diameter Architecture than I had in mind for the
prepaid application.  The Diameter documents are separated the way they
are mostly for readability.  Diameter is still Diameter...

> For the base RADIUS server (the parsing engine etc) the string is
Opaque=20
> but we need to document its contents so that we have interoperability.

Clearly.  I guess what's in question is whether those RFCs, defining the
message format and application behavior for Prepaid Accounting Services,
are a potential work item for RADEXT (or AAAEXT).  Prepaid is not
RADIUS...

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 20:06:26 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Thu, 8 Jan 2004 15:06:07 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:32 AM
To: Roy, Radhika R, ALABS; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QoS attributes

Hi Radhika,

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

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

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

OK.
=20
> From AAA server point of view, the QoS attributes MUST be=20
> generic enough, like authentication/authorization, to satisfy=20
> all the needs for all types (e.g., application, transport) of=20
> calls (e.g., SIP, IPSec/TLS). This is our challenge in=20
> 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. =20
We may use SIP to initiate the call & codecs, however my operator may=20
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=20
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=20
bandwidth might be 128k while yours might be 2M. =20

John

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 19:59:21 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 14:58:50 -0500 

We are getting converged here....

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, January 08, 2004 2:10 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Potential work items 
> 
> 
> Avi Lior writes...
> 
> > Great!!! I was saying that all along.  Prepaid is exactly that so is
> the
> > Sterman draft.
> > Both of these are add on applications.  They both need specialized
> code in
> > the RADIUS server to perform their Authentication/Authorization.
> 
> My ears prick up when you say "code in the RADIUS server".  
> If you mean a separate application (or service) running on 
> the same host as the RADIUS Server application, and 
> communicating tot eh RADIUS Server via some API, then fine.
> 
> If you mean that the code is integral to the RADIUS Server 
> application and the parser code that understands RADIUS 
> attributes also needs to understand the "opaque" messages, 
> then maybe not so fine.  

So we are in total agreement.  We do not want to break  the parser code of
RADIUS!!!

The intent of my draft and that of the sterman draft is to pass the a string
attribute to some plugin code for futher processing.  That code would know
what to do with the string.

> If the "opaque" message format is not documented as part of, 
> or an extension to, RADIUS or Diameter, then it follows the 
> EAP precedent.

We still need to document the opaque messages though in the RFCs.  This is
akin to Diameter Applications.  For the base RADIUS server (the parsing
engine etc) the string is Opaque but we need to document its contents so
that we have interoperability.

> -- Dave
> 
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 19:10:55 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 14:09:58 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Great!!! I was saying that all along.  Prepaid is exactly that so is
the
> Sterman draft.
> Both of these are add on applications.  They both need specialized
code in
> the RADIUS server to perform their Authentication/Authorization.

My ears prick up when you say "code in the RADIUS server".  If you mean
a separate application (or service) running on the same host as the
RADIUS Server application, and communicating tot eh RADIUS Server via
some API, then fine.

If you mean that the code is integral to the RADIUS Server application
and the parser code that understands RADIUS attributes also needs to
understand the "opaque" messages, then maybe not so fine. =20

If the "opaque" message format is not documented as part of, or an
extension to, RADIUS or Diameter, then it follows the EAP precedent.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 19:04:15 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, Alan DeKok <[email-masked]>,  [email-masked]
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 14:03:48 -0500 

> I think Alan DeKok hit the nail on the head.  External "bolt 
> on" or "plug in" applications should that need to use RADIUS 
> as a form of opaque message transport should do it the way EAP does.
> 
> -- Dave

Great!!! I was saying that all along.  Prepaid is exactly that so is the
Sterman draft.
Both of these are add on applications.  They both need specialized code in
the RADIUS server to perform their Authentication/Authorization.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 19:02:10 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 14:00:48 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> RADIUS already provides for only two character contexts: Text and
String.
>=20
> Introducing another will break Dictionaries right?

I was thinking of the definition of the Login-LAT-Service, as an
example.  This does not introduce a new data type.  The description
additionally restricts the existing data type, although admittedly not
in a strong "type checking" formal syntax fashion. =20

>From RFC 2865:

String

      The String field is one or more octets, and contains the identity
      of the LAT service to use.  The LAT Architecture allows this
      string to contain $ (dollar), - (hyphen), . (period), _
      (underscore), numerics, upper and lower case alphabetics, and the
      ISO Latin-1 character set extension [11].  All LAT string
      comparisons are case insensitive.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 18:51:16 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Alan DeKok <[email-masked]>,  [email-masked]
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 13:50:48 -0500 

> Well, without actually introducing a new data type, you're 
> allowed to sub-specify the allowable character set for string 
> types in the textual descriptions of attributes.

RADIUS already provides for only two character contexts: Text and String.

Introducing another will break Dictionaries right?

> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 18:44:01 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 13:43:31 -0500 

EAP-Message as a String is totally consistant with the definition as per
RFC-2865

Here is the definition of String from RFC-2865:

      In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646
      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      RADIUS implementers using C are cautioned not to use strcpy() when
      handling strings.

      The format of the value field is one of five data types.  Note
      that type "text" is a subset of type "string".

      text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, January 08, 2004 1:33 PM
> To: [email-masked]
> Subject: Re: Potential work items 
> 
> 
> "Nelson, David" <[email-masked]> wrote:
> > If you consider the EAP-Message attribute a String, I guess so.  :-)
> 
>   I've always seen this as a problem in the RFC's.  
> Attributes like CHAP-Challenge, or EAP-Message should not be 
> "string" attributes, in the same way that User-Password is a 
> "string" attribute.  In the RADIUS server I'm working on, 
> we're using type "octets", which means "undistinguished 
> data", versus "printable string".
> 
>   But that's a side topic.  We're not supposed to be defining 
> new data types, so I won't discuss it any more.
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 18:42:11 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 13:41:11 -0500
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok writes...

>   I've always seen this as a problem in the RFC's.  Attributes like
> CHAP-Challenge, or EAP-Message should not be "string" attributes, in
> the same way that User-Password is a "string" attribute.  In the
> RADIUS server I'm working on, we're using type "octets", which means
> "undistinguished data", versus "printable string".

Well, without actually introducing a new data type, you're allowed to
sub-specify the allowable character set for string types in the textual
descriptions of attributes.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 08 Jan 2004 18:32:07 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Potential work items 
Date: Thu, 08 Jan 2004 13:33:23 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> If you consider the EAP-Message attribute a String, I guess so.  :-)

  I've always seen this as a problem in the RFC's.  Attributes like
CHAP-Challenge, or EAP-Message should not be "string" attributes, in
the same way that User-Password is a "string" attribute.  In the
RADIUS server I'm working on, we're using type "octets", which means
"undistinguished data", versus "printable string".

  But that's a side topic.  We're not supposed to be defining new data
types, so I won't discuss it any more.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 18:30:07 +0000
From: "Ed Van Horne" <[email-masked]>
To: "'Roy, Radhika R, ALABS'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: QoS attributes
Date: Thu, 8 Jan 2004 10:29:38 -0800
Organization: Cisco Systems

"COPS for policies of authentication, authorization, and accounting..."

Perhaps I took this out of context. Thanks for the clarification, it is
exactly what I understood to be the relationship between AAA and COPS.

Regards,
Ed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Roy, Radhika R, ALABS
Sent: Thursday, January 08, 2004 6:41 AM
To: Ed Van Horne; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Ed:

Where did you see that COPS is being proposed to be used as an
authentication/authorization mechanisms? No one is saying this.

COPS and AAA are dealing with two different things. The implications of
John and my agreement are as follows:

1. AAA is used for authentication and authorization of all resources
including QoS.

2. COPS is used as a policy distribution protocol including QoS.

It would be interesting to see how COPS and AAA are used to complement
each other. We can write BCP drafts showing their use cases because I
believe that we do need any extensions in protocols to do so (e.g., you
have shown one way of doing it).

Hope this clarifies the things.

br,
Radhika

-----Original Message-----
From: Ed Van Horne [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:22 PM
To: Roy, Radhika R, ALABS; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

I am not quite clear on how COPS is used as an authentication mechanism.
It seems to me that AAA is primarily about authentication (with
attributes, such as QoS, authorizing use of features by the session as a
whole) and COPS is about authorizing the features for the session on the
various network element that implement them. It is true that COPS needs
a way to determine the identity of the authorizer, but this would be the
'identity' of the AAA server, not the individual user.

Maybe that is what John meant, but it was not entirely clear to me.

Regards,
Ed

Ed Van Horne 
Building Broadband Solutions Unit - San Diego 
Cisco Systems 
10935 Vista Sorrento Parkway 
San Diego, CA 92130 
858.526.1152 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Roy, Radhika R, ALABS
Sent: Wednesday, January 07, 2004 12:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Hi, John:

I agree with you completely.

Now, it provides a clear direction how we should proceed with QoS
attributes in AAA (RADIUS/DIAMETER).

More importantly, this shows how both AAA (RADIUS/DIAMETER) and COPS
complement each other.

br,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:23 AM
To: Roy, Radhika R, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Radhika,

> I think that COPS is a policy protocol, and policies related to QOS 
> can also be used for distribution and enforcements. Similar may also 
> be the case for security and accounting.

Agreed.
 
> However, DIAMETER/RADIUS is also used for authentication, 
> authorization, and accounting (AAA).

Agreed.
 
> Here are the interesting points:
> 
> 1. COPS for policies of authentication, authorization, and accounting 
> including QOS.

OK.
 
> 2. DIAMETER/RADIUS for offering actual services for authentication, 
> authorization, and accounting including QoS.

This I am not so sure of.  I've always thought that Diameter / 
RADIUS can be used to authorize QoS services.  For example, if I've
subscribed to a service with Real-time QoS, Diameter could be used to
authorize my use of such a service.  If I request a service that I am
not allowed to, then the authorization would fail.

> In item 2, I am lacking clear wordings here.
> 
> The question is this: Can we not develop standards complementing both 
> COPS and DIAMETER/RADIUS as they are also a part of IETF standard 
> protocols?

Taking a systematic view, I would think that AAA protocols can do the
authorization & accounting side of any QoS-aware services. COPS can be
used inside of the network to transport QoS policies to the enforcement
points, to ensure that QoS parameters are not exceded. 

John

--
to unsubscribe send a message to [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 18:14:52 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items
Date: Thu, 8 Jan 2004 13:13:23 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I still plan for submit a draft that describes enhanced authorization
attributes for NAS management, to cover non-CLI management protocols and
more granular levels of management access control.  This will require a
small number of new attributes and/or new enumerated values for existing
attributes.

No new commands or new data types are required.  No use of sub-types or
change to the attribute format is required.

Interest was expressed at the BOF at IETF 58 in seeing this as a WG work
item.

Regards,
=20
Dave
=20
David B. Nelson
Wireless & AAA Architect, Office of the CTO
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330 =20
E-mail: [email-masked]
=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2004 11:50 AM
> To: [email-masked]
> Subject: Potential work items
>=20
> In order to update the potential charter, it would be helpful if we
could
> get a list of potential work items that:
>=20
> a. Don't require new RADIUS commands.
> b. Don't require changes to the RADIUS dictionary (e.g. no
>    sub-types).
> c. Don't require changes to the RADIUS attribute format.
> d. Need to be handled as a WG work item.
> e. Are likely to be widely deployed, if specified.
>=20
> If you have a proposed work item that meets these requirements, please
> post info to the list.
>=20
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 18:02:29 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 13:01:06 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>, <[email-masked]>

Avi writes...

> If I remember correctly, the Home RADIUS server has to interpret the
> attibutes.
>=20
> A proxy server will never have to look at these attributes.  The Home
> Radius server will have a specific application running on it to=20
> interpret the attributes and act on them.  Therefore, since proxy=20
> servers don't have to parse the attributes and the home radius will=20
> have a custom application on it; doesn't it make sense to still allow
> these attributes to be packed (somehow) in a String?

If you consider the EAP-Message attribute a String, I guess so.  :-)

I think Alan DeKok hit the nail on the head.  External "bolt on" or
"plug in" applications should that need to use RADIUS as a form of
opaque message transport should do it the way EAP does.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 17:50:06 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Potential work items 
Date: Thu, 8 Jan 2004 12:49:32 -0500 

If I remember correctly, the Home RADIUS server has to interpret the
attibutes.

A proxy server will never have to look at these attributes.  The Home Radius
server will have a specific application running on it to interpret the
attributes and act on them.  Therefore, since proxy servers don't have to
parse the attributes and the home radius will have a custom application on
it; doesn't it make sense to still allow these attributes to be packed
(somehow) in a String?  

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, January 08, 2004 11:14 AM
> To: [email-masked]
> Subject: Re: Potential work items 
> 
> 
> [email-masked] (Wolfgang Beck) wrote:
> > > b. Don't require changes to the RADIUS dictionary (e.g. no 
> > > sub-types).
> > This is ugly. I expect that 20 - 40 attributes are to be expected 
> > (extensions to RfC 2595 are constantly added). As this data doesn't 
> > need to be interpreted by the RADIUS server, I don't see a 
> reason why 
> > sub-attributes are bad here.
> 
>   If the data isn't interpreted by the RADIUS server, then it 
> may be packed into a list of one attribute, like EAP-Message.
> 
>   i.e. using RADIUS to transport opaque data for "foo" should 
> be solved by creating a "packed-foo-message" attribute, and 
> not a RADIUS attribute for every field in "foo".
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 08 Jan 2004 16:13:19 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Potential work items 
Date: Thu, 08 Jan 2004 11:14:03 -0500
Message-Id: <[email-masked]>

[email-masked] (Wolfgang Beck) wrote:
> > b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
> This is ugly. I expect that 20 - 40 attributes are to be expected (extensions
> to RfC 2595 are constantly added). As this data doesn't need to be
> interpreted by the RADIUS server, I don't see a reason why
> sub-attributes are bad here.

  If the data isn't interpreted by the RADIUS server, then it may be
packed into a list of one attribute, like EAP-Message.

  i.e. using RADIUS to transport opaque data for "foo" should be
solved by creating a "packed-foo-message" attribute, and not a RADIUS
attribute for every field in "foo".

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 14:41:32 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Thu, 8 Jan 2004 09:40:57 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: "Ed Van Horne" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Ed:

Where did you see that COPS is being proposed to be used as an
authentication/authorization mechanisms? No one is saying this.

COPS and AAA are dealing with two different things. The implications of
John and my agreement are as follows:

1. AAA is used for authentication and authorization of all resources
including QoS.

2. COPS is used as a policy distribution protocol including QoS.

It would be interesting to see how COPS and AAA are used to complement
each other. We can write BCP drafts showing their use cases because I
believe that we do need any extensions in protocols to do so (e.g., you
have shown one way of doing it).

Hope this clarifies the things.

br,
Radhika

-----Original Message-----
From: Ed Van Horne [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:22 PM
To: Roy, Radhika R, ALABS; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

I am not quite clear on how COPS is used as an authentication mechanism.
It seems to me that AAA is primarily about authentication (with
attributes, such as QoS, authorizing use of features by the session as a
whole) and COPS is about authorizing the features for the session on the
various network element that implement them. It is true that COPS needs
a way to determine the identity of the authorizer, but this would be the
'identity' of the AAA server, not the individual user.

Maybe that is what John meant, but it was not entirely clear to me.

Regards,
Ed

Ed Van Horne=20
Building Broadband Solutions Unit - San Diego=20
Cisco Systems=20
10935 Vista Sorrento Parkway=20
San Diego, CA 92130=20
858.526.1152=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Roy, Radhika R, ALABS
Sent: Wednesday, January 07, 2004 12:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Hi, John:

I agree with you completely.

Now, it provides a clear direction how we should proceed with QoS
attributes in AAA (RADIUS/DIAMETER).

More importantly, this shows how both AAA (RADIUS/DIAMETER) and COPS
complement each other.

br,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:23 AM
To: Roy, Radhika R, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Radhika,

> I think that COPS is a policy protocol, and policies related
> to QOS can also be used for distribution and enforcements.=20
> Similar may also be the case for security and accounting.

Agreed.
=20
> However, DIAMETER/RADIUS is also used for authentication,
> authorization, and accounting (AAA).

Agreed.
=20
> Here are the interesting points:
>=20
> 1. COPS for policies of authentication, authorization, and
> accounting including QOS.

OK.
=20
> 2. DIAMETER/RADIUS for offering actual services for
> authentication, authorization, and accounting including QoS.

This I am not so sure of.  I've always thought that Diameter /=20
RADIUS can be used to authorize QoS services.  For example, if I've
subscribed to a service with Real-time QoS, Diameter could be used to
authorize my use of such a service.  If I request a service that I am
not allowed to, then the authorization would fail.

> In item 2, I am lacking clear wordings here.
>=20
> The question is this: Can we not develop standards
> complementing both COPS and DIAMETER/RADIUS as they are also=20
> a part of IETF standard protocols?

Taking a systematic view, I would think that AAA protocols can do the
authorization & accounting side of any QoS-aware services. COPS can be
used inside of the network to transport QoS policies to the enforcement
points, to ensure that QoS parameters are not exceded.=20

John

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Jan 2004 12:43:02 +0000
To: [email-masked]
Subject: Re: Potential work items
Date: Thu, 08 Jan 2004 13:37:45 +0100
From: [email-masked] (Wolfgang Beck)

1.
I am proposing HTTP Digest RADIUS (aka sterman draft) as WG work item:
> a. Don't require new RADIUS commands.
ok.

> b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
the current draft needs 11 attributes. Sub-types are not required but
would make sense as 10 of the attributes will be mostly used
together. 

> c. Don't require changes to the RADIUS attribute format.
ok.

> d. Need to be handled as a WG work item.
SIPPING would prefer if RADIUSEXT would do this work.

> e. Are likely to be widely deployed, if specified.
There seems to be a demand: the current sterman-draft is widely
implemented, Dean Willis reported that other proprietary mechanisms exist.
HTTP Digest is by now the only SIP security mechanism that is implemented
in commercial products. ISPs with an existing RADIUS infrastructure that
want go into the SIP business need a solution for that.

2.
SIP accounting (based on draft-schulzrinne-sipping-radius-accounting-00.txt):
> a. Don't require new RADIUS commands.
ok.

> b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
ok. Around 10  - 15 attributes will be required.

> c. Don't require changes to the RADIUS attribute format.
ok.

> d. Need to be handled as a WG work item.
see above 
> e. Are likely to be widely deployed, if specified.
By now, most SIP vendors define their own set of RADIUS attributes. If
there was a standard, it's likely they will comply to it.

3.
Media accounting:
Information about media streams must be associated with SIP- H323- RTSP-
etc. users for accounting purposes. RfC 2959 hints how to structure
this information.

> a. Don't require new RADIUS commands.
ok.

> b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
This is ugly. I expect that 20 - 40 attributes are to be expected (extensions
to RfC 2595 are constantly added). As this data doesn't need to be
interpreted by the RADIUS server, I don't see a reason why
sub-attributes are bad here.

> c. Don't require changes to the RADIUS attribute format.
ok.

> d. Need to be handled as a WG work item.
Media accounting is not only interesting for SIP. All WGs using RTP
can benefit from this work. AVT would be the only other group where
this would fit in. 

> e. Are likely to be widely deployed, if specified.
see above 

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 23:22:58 +0000
From: "Ed Van Horne" <[email-masked]>
To: "'Roy, Radhika R, ALABS'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: QoS attributes
Date: Wed, 7 Jan 2004 15:22:21 -0800
Organization: Cisco Systems

I am not quite clear on how COPS is used as an authentication mechanism.
It seems to me that AAA is primarily about authentication (with
attributes, such as QoS, authorizing use of features by the session as a
whole) and COPS is about authorizing the features for the session on the
various network element that implement them. It is true that COPS needs
a way to determine the identity of the authorizer, but this would be the
'identity' of the AAA server, not the individual user.

Maybe that is what John meant, but it was not entirely clear to me.

Regards,
Ed

Ed Van Horne 
Building Broadband Solutions Unit - San Diego 
Cisco Systems 
10935 Vista Sorrento Parkway 
San Diego, CA 92130 
858.526.1152 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Roy, Radhika R, ALABS
Sent: Wednesday, January 07, 2004 12:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Hi, John:

I agree with you completely.

Now, it provides a clear direction how we should proceed with QoS
attributes in AAA (RADIUS/DIAMETER).

More importantly, this shows how both AAA (RADIUS/DIAMETER) and COPS
complement each other.

br,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:23 AM
To: Roy, Radhika R, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Radhika,

> I think that COPS is a policy protocol, and policies related
> to QOS can also be used for distribution and enforcements. 
> Similar may also be the case for security and accounting.

Agreed.
 
> However, DIAMETER/RADIUS is also used for authentication,
> authorization, and accounting (AAA).

Agreed.
 
> Here are the interesting points:
> 
> 1. COPS for policies of authentication, authorization, and
> accounting including QOS.

OK.
 
> 2. DIAMETER/RADIUS for offering actual services for
> authentication, authorization, and accounting including QoS.

This I am not so sure of.  I've always thought that Diameter / 
RADIUS can be used to authorize QoS services.  For example, if I've
subscribed to a service with Real-time QoS, Diameter could be used to
authorize my use of such a service.  If I request a service that I am
not allowed to, then the authorization would fail.

> In item 2, I am lacking clear wordings here.
> 
> The question is this: Can we not develop standards
> complementing both COPS and DIAMETER/RADIUS as they are also 
> a part of IETF standard protocols?

Taking a systematic view, I would think that AAA protocols can do the
authorization & accounting side of any QoS-aware services. COPS can be
used inside of the network to transport QoS policies to the enforcement
points, to ensure that QoS parameters are not exceded. 

John

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 20:47:22 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 7 Jan 2004 15:46:35 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi, John:

I agree with you completely.

Now, it provides a clear direction how we should proceed with QoS =
attributes in AAA (RADIUS/DIAMETER).

More importantly, this shows how both AAA (RADIUS/DIAMETER) and COPS =
complement each other.

br,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:23 AM
To: Roy, Radhika R, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Radhika,

> I think that COPS is a policy protocol, and policies related=20
> to QOS can also be used for distribution and enforcements.=20
> Similar may also be the case for security and accounting.

Agreed.
=20
> However, DIAMETER/RADIUS is also used for authentication,=20
> authorization, and accounting (AAA).

Agreed.
=20
> Here are the interesting points:=20
>=20
> 1. COPS for policies of authentication, authorization, and=20
> accounting including QOS.

OK.
=20
> 2. DIAMETER/RADIUS for offering actual services for=20
> authentication, authorization, and accounting including QoS.

This I am not so sure of.  I've always thought that Diameter /=20
RADIUS can be used to authorize QoS services.  For example, if
I've subscribed to a service with Real-time QoS, Diameter could
be used to authorize my use of such a service.  If I request
a service that I am not allowed to, then the authorization would fail.

> In item 2, I am lacking clear wordings here.
>=20
> The question is this: Can we not develop standards=20
> complementing both COPS and DIAMETER/RADIUS as they are also=20
> a part of IETF standard protocols?

Taking a systematic view, I would think that AAA protocols can
do the authorization & accounting side of any QoS-aware services.
COPS can be used inside of the network to transport QoS
policies to the enforcement points, to ensure that QoS parameters
are not exceded.=20

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 18:13:46 +0000
content-class: urn:content-classes:message
Subject: RE: Potential work items
Date: Wed, 7 Jan 2004 10:13:13 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>

Hi Bernard,
On LAN attributes, we are collaborating our efforts with Paul/Chuck as=20
the two drafts overlap to some extent.  Moving forward, we will have
location
information attributes in a separate draft, and may have to do the same
thing for=20
some of other attributes based on the urgency and logic.  There are also

a few additional attributes that will be added to the list based on the=20
requirements from 3GPP2 and GSMA. =20

As it was suggested on the mailing list, some of these attributes will
be presented
as generic AAA attributes (i.e., will provide both RADIUS and Diameter
syntax).

Paul/chuck and I also talked about a RADIUS information guidelines for
WLAN --
that basically would describe the required attributes, interpretation of
some=20
of existing attributes, and what RADIUS RFCs must be supported.  We do
not have=20
a draft on this yet, but it is a potential work item.

BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, January 07, 2004 8:50 AM
> To: [email-masked]
> Subject: Potential work items
>=20
>=20
> In order to update the potential charter, it would be helpful=20
> if we could
> get a list of potential work items that:
>=20
> a. Don't require new RADIUS commands.
> b. Don't require changes to the RADIUS dictionary (e.g. no
>    sub-types).
> c. Don't require changes to the RADIUS attribute format.
> d. Need to be handled as a WG work item.
> e. Are likely to be widely deployed, if specified.
>=20
> If you have a proposed work item that meets these requirements, please
> post info to the list.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 16:34:22 +0000
Date: Wed, 7 Jan 2004 08:49:33 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Potential work items

In order to update the potential charter, it would be helpful if we could
get a list of potential work items that:

a. Don't require new RADIUS commands.
b. Don't require changes to the RADIUS dictionary (e.g. no
   sub-types).
c. Don't require changes to the RADIUS attribute format.
d. Need to be handled as a WG work item.
e. Are likely to be widely deployed, if specified.

If you have a proposed work item that meets these requirements, please
post info to the list.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 16:27:01 +0000
Date: Wed, 7 Jan 2004 08:41:42 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: RE: QoS attributes

> > A couple of other possible alternatives would include:
> >
> >    2. Client---(RSVP)---PEP---(Diameter)---Local AAA---(Diameter)---Home AAA
> >
> > and:
> >
> >    3. Client---(RSVP)---PEP---(COPS)---Local PDP---(COPS+)---Home PDP

This is a great discussion.

HOWEVER, I would point out that it is really a discussion that needs to
occur elsewhere (perhaps in NSIS?), since it relates to the AAA
requirements for QoS.  Neither AAA WG nor RADEXT BOF is the place for that
kind of requirements discussion -- it needs to occur in a forum where the
subject matter experts reside.

Here on the RADEXT BOF mailing list, what we are trying to do is nail down
a potential charter.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 12:07:23 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 7 Jan 2004 14:05:33 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Jari,

> > Taking a systematic view, I would think that AAA protocols can
> > do the authorization & accounting side of any QoS-aware services.
> > COPS can be used inside of the network to transport QoS
> > policies to the enforcement points, to ensure that QoS parameters
> > are not exceded.=20
>=20
> We have a couple of fixed things in the architecture, namely:
>=20
>    o  The client, obviously.
>=20
>    o  The Policy Enforcement Point (PEP). If the link of
>       whose bandwidth is being controlled terminates on
>       a node, that's where you _have_ to do to the
>       enforcement.
>=20
>    o  The home network. This is the ultimate decision point
>       regarding the authority to request some QoS. (Of course,
>       in many cases the decision is delegated to others "offer him
>       the best service you can, our roaming contract price
>       is in any case fixed".)
>=20
>    o  The protocols between the client and the PEP. For instance,
>       it could be some yet-to-be-defined 802.11k bandwidth allocation
>       scheme on the link, RSVP, PPP multilink negotiation, or=20
> 	  whatever.
>       No one is proposing to replace these protocols with either COPS
>       or AAA.

Agreed.  However, for the last bullet: protocols between the client and =
the PEP,
a reasonable assumption could be that certain services have hard-coded =
QoS,
so the client doesn't have to signal anything more than just initiating =
services.
For example, SIP video call assumes certain a QoS profile, and if the =
request
for the service is successful, it means the QoS profile is fufilled.

> Then we have some other things which are not so fixed, such as
> the protocols between the PEP and the home network.
>=20
> I think this model helps us understand the issues better. For =
instance,
> when we say "AAA is not a QoS signaling protocol", do we really mean
> that AAA should not be used the client and the PEP, do we mean that
> it should not be uesd between the PEP and the home network, or what?
>=20
> I think you John are suggesting an architecture like this:
>=20
>    1. Client---(RSVP)---PEP---(COPS)---Local AAA---(Diameter)---Home =
AAA

Well, there are many ways to skin a cat, the above was just one way to =
do it.

> A couple of other possible alternatives would include:
>=20
>    2. Client---(RSVP)---PEP---(Diameter)---Local =
AAA---(Diameter)---Home AAA
>=20
> and:
>=20
>    3. Client---(RSVP)---PEP---(COPS)---Local PDP---(COPS+)---Home PDP

These are other ways.  My feeling is that some of these will be =
determinted
by the service provider.  If you replace PEP with NAS (they could be the
same box) then using something like Diameter is very reasonable.
=20
> What are the tradeoffs involved in these different architectures?
> Here are some tradeoffs that I was able to identify: number 3 appears
> to require some extensions of COPS, such as a DIAMETER/RADIUS -like
> roaming & routing scheme. Numbers 2 or 3 would be simpler than number =
1,
> because just one protocol is needed instead of two.

Agreed - I just wanted to use as many protocols as possible ;)
=20
> Also, who is binding the authentication of the user into the various
> QoS requests that happen elsewhere in the network? How? Or do we =
expect
> users to authenticate to every router that the send an RSVP request =
to?
> I'm hoping someone has answers to these questions already...

This is something that we are looking at in NSIS.  NSIS is planning on =
using
an RSVP-like mechanism for QoS signaling (& middlebox traversal).  Not =
all
routers are RSVP / NSIS aware, but hopfully things like NASes & PEPs =
will
be.  My guess is that the user will signaling to something like a NAS on
the datapath, the NAS checks the users credentials & possibly signals to
the AAA server to ensure authorzation, etc.

br,
John

PS - I think we are getting a little bit into the weeds on this topic. I =
don't
think RADext will architect a complete solution on this topic.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 11:53:39 +0000
Date: Wed, 07 Jan 2004 13:52:06 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: QoS attributes

Hi John,

>>The question is this: Can we not develop standards 
>>complementing both COPS and DIAMETER/RADIUS as they are also 
>>a part of IETF standard protocols?
> 
> 
> Taking a systematic view, I would think that AAA protocols can
> do the authorization & accounting side of any QoS-aware services.
> COPS can be used inside of the network to transport QoS
> policies to the enforcement points, to ensure that QoS parameters
> are not exceded. 

We have a couple of fixed things in the architecture, namely:

   o  The client, obviously.

   o  The Policy Enforcement Point (PEP). If the link of
      whose bandwidth is being controlled terminates on
      a node, that's where you _have_ to do to the
      enforcement.

   o  The home network. This is the ultimate decision point
      regarding the authority to request some QoS. (Of course,
      in many cases the decision is delegated to others "offer him
      the best service you can, our roaming contract price
      is in any case fixed".)

   o  The protocols between the client and the PEP. For instance,
      it could be some yet-to-be-defined 802.11k bandwidth allocation
      scheme on the link, RSVP, PPP multilink negotiation, or whatever.
      No one is proposing to replace these protocols with either COPS
      or AAA.

Then we have some other things which are not so fixed, such as
the protocols between the PEP and the home network.

I think this model helps us understand the issues better. For instance,
when we say "AAA is not a QoS signaling protocol", do we really mean
that AAA should not be used the client and the PEP, do we mean that
it should not be uesd between the PEP and the home network, or what?

I think you John are suggesting an architecture like this:

   1. Client---(RSVP)---PEP---(COPS)---Local AAA---(Diameter)---Home AAA

A couple of other possible alternatives would include:

   2. Client---(RSVP)---PEP---(Diameter)---Local AAA---(Diameter)---Home AAA

and:

   3. Client---(RSVP)---PEP---(COPS)---Local PDP---(COPS+)---Home PDP

What are the tradeoffs involved in these different architectures?
Here are some tradeoffs that I was able to identify: number 3 appears
to require some extensions of COPS, such as a DIAMETER/RADIUS -like
roaming & routing scheme. Numbers 2 or 3 would be simpler than number 1,
because just one protocol is needed instead of two.

Also, who is binding the authentication of the user into the various
QoS requests that happen elsewhere in the network? How? Or do we expect
users to authenticate to every router that the send an RSVP request to?
I'm hoping someone has answers to these questions already...

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 11:32:27 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 7 Jan 2004 13:32:07 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Radhika,

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

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

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

OK.
=20
> From AAA server point of view, the QoS attributes MUST be=20
> generic enough, like authentication/authorization, to satisfy=20
> all the needs for all types (e.g., application, transport) of=20
> calls (e.g., SIP, IPSec/TLS). This is our challenge in=20
> 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. =20
We may use SIP to initiate the call & codecs, however my operator may=20
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=20
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=20
bandwidth might be 128k while yours might be 2M. =20

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 11:23:54 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 7 Jan 2004 13:23:09 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Radhika,

> I think that COPS is a policy protocol, and policies related=20
> to QOS can also be used for distribution and enforcements.=20
> Similar may also be the case for security and accounting.

Agreed.
=20
> However, DIAMETER/RADIUS is also used for authentication,=20
> authorization, and accounting (AAA).

Agreed.
=20
> Here are the interesting points:=20
>=20
> 1. COPS for policies of authentication, authorization, and=20
> accounting including QOS.

OK.
=20
> 2. DIAMETER/RADIUS for offering actual services for=20
> authentication, authorization, and accounting including QoS.

This I am not so sure of.  I've always thought that Diameter /=20
RADIUS can be used to authorize QoS services.  For example, if
I've subscribed to a service with Real-time QoS, Diameter could
be used to authorize my use of such a service.  If I request
a service that I am not allowed to, then the authorization would fail.

> In item 2, I am lacking clear wordings here.
>=20
> The question is this: Can we not develop standards=20
> complementing both COPS and DIAMETER/RADIUS as they are also=20
> a part of IETF standard protocols?

Taking a systematic view, I would think that AAA protocols can
do the authorization & accounting side of any QoS-aware services.
COPS can be used inside of the network to transport QoS
policies to the enforcement points, to ensure that QoS parameters
are not exceded.=20

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Jan 2004 07:54:03 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 7 Jan 2004 09:50:34 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Avi, Pasi,

> I agree with this in general.
>=20
> I don't think the intent was to have RADIUS do the signaling.

This is part of my confusion - I haven't seen a crisp statement
about how QoS & AAA are related.

If you think of it as bandwidth limiting, or more aptly authorization
for certain bandwidth, then I'm OK with that.

John

> > Hi,
> >=20
> > I think at least some people are intending to use the=20
> > bandwidth RADIUS attributes for configuring some sort of=20
> > "bandwidth limiting" mechanism in a WLAN access point. This=20
> > is very different=20
> > from QoS signalling for, e.g., reserving bandwidth along the route=20
> > to some destination.
> >=20
> > I agree with John in that using AAA protocols for QoS=20
> > signalling is not a good idea; however, using them to provide=20
> > parameters for some "bandwidth limiting" mechanism seems very=20
> > appropriate.=20
> >=20
> > Diameter even provides an AVP data format (QoSFilterRule) for=20
> > exactly this purpose. It seems that this AVP data format is=20
> > not yet used by any AVP type, though. It is quite complex, so=20
> > perhaps something like a simple "maximum uplink/downlink bandwidth"=20
> > attribute would be sufficient for many purposes.
> >=20
> > BTW, it seems the actual text describing the "dscp" and=20
> > "metering" options is missing from RFC 3588. The latest draft=20
> > that still explains their parameters seems to be -09,=20
> > available from:=20
> > http://www.watersprings.org/pub/id/draft-ietf-aaa-diameter-09.txt
> >=20
> > Best regards,
> > Pasi
> >=20
> > > -----Original Message-----
> > > From: [email-masked] On Behalf Of ext Avi Lior
> > > Sent: Monday, January 05, 2004 6:18 PM
> > > To: Loughney John (Nokia-NRC/Helsinki); [email-masked];=20
> > > [email-masked]; [email-masked]
> > > Cc: Avi Lior; [email-masked]
> > > Subject: RE: QoS attributes
> > >=20
> > >=20
> > > Good question John,
> > >=20
> > > Well what do you call Bandwidth attributes and transporting=20
> > them? We=20
> > > are certainly talking about tranpsorting Bandwidth=20
> parameters in a=20
> > > RADIUS message.  It certainly makes sense to me to include=20
> > Bandwidth=20
> > > attributes as part of the authorization of a given service.
> > >=20
> > > Is Bandwidth part of QoS?  I think it is.
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Sunday, January 04, 2004 3:52 AM
> > > > To: [email-masked]; [email-masked];=20
> > [email-masked]
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: RE: QoS attributes
> > > >=20
> > > >=20
> > > > Roy, Avi,
> > > >=20
> > > > I am getting quite confused by this discussion.  Could=20
> I ask what
> > > > we are actually discussing?  RADIUS/Diameter are not=20
> > > > signaling protocols, they are AAA protocols.  RADIUS/Diameter=20
> > > > should not transport QoS information.  My expectation is that=20
> > > > they would be involved in authorization for QoS for some=20
> > > > services, but doing more would seem to be out of scope for=20
> > > > AAA protocols.
> > > >=20
> > > > Am I missing something?
> > > >=20
> > > > John
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 06 Jan 2004 20:36:23 +0000
From: Avi Lior <[email-masked]>
To: 'nagi reddy jonnala' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: 'Kuntal Chowdhury' <[email-masked]>, 'Parviz Yegani' <[email-masked]>, "'Lila Madour (QA/EMC)'" <[email-masked]>
Subject: RE: Comments/questions on Prepaid-draft-02
Date: Tue, 6 Jan 2004 15:35:42 -0500 

Nagi,

Thanx very much for the questions/comments/concerns.  I have answered most
of your questions, hopefully well ;-) --  ( I owe you answers for the first
two)

> Here are the comments/questions on prepaid-draft-02.
> 
> 1) I'm not really convinced with the way *Service Element" 
> work? How can an element sits in between access device and a 
> Prepaid server *disconnect* a session on the access device? I 
> can unserstand it can meter the things but can not disconnect 
> sessions.
> 
> You can argue that Service element asks/updates the quotas. 
> How do you handle the re-authorizations that are supposed to 
> be initiated by access devices.
> 
> Can you explain little further of its significance and how it works?
> 
> 
> 2) Doesn't PP draft *standardize* the servic keys? I would 
> assume that it is really important for interoperation.
> 
> 3) Always, Termination-Action MUST be set to Radius-Request to
>    make sure that access device will ask for another quota rather than
>    disconnecting the session (it is the case if Termination-Action
>    = default).

Not neccesarily.  We don't need to rely on Termination-Action in Prepaid.
The NAS would request additional quota when the threshold has been reached.
The NAS would request additional quota when the quota runs out.
Both of these actions are independent of the setting of Termination-Action.

> 4) Section 4.2 talks about sending User-Password attribute 
> while sending
> 
> the message from HAAA to Prepaid server for more security.
> 
> I disagree with this. What are we doing here? Are we making 
> PP server another authentication server?

What we say in the draft is this:

For added security, the HAAA MAY also set the User-Password(2) attribute 
to the password used between the HAAA and the PrePaid server. 

Note it is NOT the user's password and therefore the PPS is not an
authentication service. It is a password that can be configured between the
Home AAA and the Prepaid Server.  The thought was that it COULD be used to
enhance security.  We can remove this if it adds no value.

> 5) Sections 4.2.1 and  4.4, Ascend-data-filter was mentioned 
> separately.
> 
>      I guess we can remove this.

We are currently investigating the addition of a new RADIUS attribute to
allow us to do Redirects. This is needed for WLAN and other applications.

So we will remove the mention of Ascend Filter.

> 6) Section 4.4, Mid-Session Operation - doesn't consider if 
> there are Broker AAAs in between. For example, You may need 
> to add IP addresses of PP servers to the Access-Requests.

There should be no impact on Broker AAAs in any phase (start of session,
mid-session and end of session).  Broker AAAs will forward the
Access-Requests to the home network based on the user-name attribute.  The
AAA in the home network will then forward the Access Request to the
appropriate PPS by looking in the PPAQ attribute which contains the IP
Address of the serving PP Servers and optionaly delegates.

The design intent is to have no impact on Broker AAA servers.

> 7) Section 4.4, Mid-Session operation:
> 
> Isn't it possible that the operator wants to update his 
> services and wants to notify the access points.

Not sure I follow your question here.  Please clarify.
> 
> 8) Section 4.5.1. says "Each AAA MUST route the Disconnect 
> Request packet. How the routing decision is made is an 
> implementation detail. "
> 
> Can you explain how can a Disconnect message initiated by PP 
> server will reach the Access Device?  I mean what are the 
> attributes involved to make the packet reach its destination 
> through the proxies.

There is a good discussion of this in RFC-3576. 

> 
> 9) what does a PP server do if it receives Disconnect-NAK?
> Does it keep billing?

It would have to stop billing.  You always err on the side of the
subscriber. However, remember that all of these things are covered by
roaming agreements.  So I suppose the event would be recorded and the issue
would be taken up by the operators.

Also note that the revenue loss would be limited to the Quota.  One reason
for a having a quota is to limit liability (in this case revenue loss) when
things go wrong.

> 10) Section 4.5.1
> 
> "Once the Disconnect Request packet reaches AAA that is in the same
>    network as the serving Access Device, if the Access Device supports
>    Disconnect-Request (as per [RFC3576]), it sends the 
> message directly
>    to the Access Device; otherwise it uses other mechanisms such as
>    SNMP or Telnet to command the Access Device to terminate the
>    session."
> 
>   - How does a AAA server know that if the access point supports
>      Disconnect (or) CoA messages?  Is this also out of scope? :)

I think you mean the Visited AAA.  The Visited AAA (which is co-located with
the access point) would be configured to indicate whether the devices
support particular messages.

How the VAAA is configured is out of scope.

> 
>   - How does Telnet/SNMP work in this scenario. Can you 
> further explain?

Some NAS devices out there support the ability to terminate sessions by
either telnet or SNMP.  If we know its telnet then we can start a telnet
session to terminate a session (this is highly vendor specific)  If the
device is not reachable by telnet (for whatever reason - but one common one
is that it is in another adminstrative network) then we would expect that
the Visited network accept a Disconnect message and it would then disconnect
the session using Telnet, SNMP or whatever it has available to disconnect
the session.

> 11) Should there be a threshold value always ( with 
> Volume/Time quota).
>       Is it possible that an access device choose not to implement
>       this attribute?

I don't think that we would mandate the Threshold value.  However, there is
a timing issue.  What happens between the time that the counter
(time/volume) has expired and the time where we get more quota?  Is service
disruptted?
Note this is the same issue that exists today with Terminate-Action.  What
happens to the Service when the user is being re-authenticated.

> 12) Section 5.3.
> 
> "Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
>    Length: length of VolumeQuotaOverflow attribute (= 4 octets)
>    VolumeQuotaOverflow (VQO):
> 
>       The optional VolumeQuotaOverflow Sub-Type is used to 
> indicate how
>       many times the VolumeQuota counter has wrapped around 2^32 over
>       the course of the service being provided. "
> 
> Is this present in access-request (or) access-accept? Its 
> worth mentioning who sends to whom.

We will clarify.

> 
> Regards
> Nagi.
> 
> PS: Can you tell us what does it take to flatten the 
> attributes. Roughly, how many new attributes are needed? I 
> believe it is really important to debate this topic to make progress.
> 

Lets say we would need 10 attributes.  But as you can see I think this
argument is not relevant.

First the intent is that the subtypes are only used by the two end points.
The prepaid attributes are used by two applications to communicate with each
other.  The two applications are the Prepaid Client which runs on the NAS
and the Prepaid Server which runs in the home AAA.  Broker AAA need not look
inside those attributes.

Second, there is more then enough examples of current attributes in RADIUS
and Diameter that contain more then one piece of information encoded in a
String Attribute.  So I really don't see an issue.

I think the concern is that we don't invent a new RADIUS attribute type
called "SUBTYPE" and I totally agree with that because that would "break"
RADIUS in the sense that Proxy RADIUS servers would have to understand this
new type.  We are not doing that at all.  The attributes that we define are
strings.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Jan 2004 23:08:25 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Mon, 5 Jan 2004 18:06:50 -0500 

I agree with this in general.

I don't think the intent was to have RADIUS do the signaling.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, January 05, 2004 5:52 PM
> To: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> 
> Hi,
> 
> I think at least some people are intending to use the 
> bandwidth RADIUS attributes for configuring some sort of 
> "bandwidth limiting" mechanism in a WLAN access point. This 
> is very different 
> from QoS signalling for, e.g., reserving bandwidth along the route 
> to some destination.
> 
> I agree with John in that using AAA protocols for QoS 
> signalling is not a good idea; however, using them to provide 
> parameters for some "bandwidth limiting" mechanism seems very 
> appropriate. 
> 
> Diameter even provides an AVP data format (QoSFilterRule) for 
> exactly this purpose. It seems that this AVP data format is 
> not yet used by any AVP type, though. It is quite complex, so 
> perhaps something like a simple "maximum uplink/downlink bandwidth" 
> attribute would be sufficient for many purposes.
> 
> BTW, it seems the actual text describing the "dscp" and 
> "metering" options is missing from RFC 3588. The latest draft 
> that still explains their parameters seems to be -09, 
> available from: 
> http://www.watersprings.org/pub/id/draft-ietf-aaa-diameter-09.txt
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: [email-masked] On Behalf Of ext Avi Lior
> > Sent: Monday, January 05, 2004 6:18 PM
> > To: Loughney John (Nokia-NRC/Helsinki); [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: Avi Lior; [email-masked]
> > Subject: RE: QoS attributes
> > 
> > 
> > Good question John,
> > 
> > Well what do you call Bandwidth attributes and transporting 
> them? We 
> > are certainly talking about tranpsorting Bandwidth parameters in a 
> > RADIUS message.  It certainly makes sense to me to include 
> Bandwidth 
> > attributes as part of the authorization of a given service.
> > 
> > Is Bandwidth part of QoS?  I think it is.
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Sunday, January 04, 2004 3:52 AM
> > > To: [email-masked]; [email-masked]; 
> [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: QoS attributes
> > > 
> > > 
> > > Roy, Avi,
> > > 
> > > I am getting quite confused by this discussion.  Could I ask what
> > > we are actually discussing?  RADIUS/Diameter are not 
> > > signaling protocols, they are AAA protocols.  RADIUS/Diameter 
> > > should not transport QoS information.  My expectation is that 
> > > they would be involved in authorization for QoS for some 
> > > services, but doing more would seem to be out of scope for 
> > > AAA protocols.
> > > 
> > > Am I missing something?
> > > 
> > > John
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Jan 2004 22:54:02 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 6 Jan 2004 00:52:01 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,

I think at least some people are intending to use the bandwidth
RADIUS attributes for configuring some sort of "bandwidth
limiting" mechanism in a WLAN access point. This is very different=20
from QoS signalling for, e.g., reserving bandwidth along the route=20
to some destination.

I agree with John in that using AAA protocols for QoS signalling
is not a good idea; however, using them to provide parameters
for some "bandwidth limiting" mechanism seems very appropriate.=20

Diameter even provides an AVP data format (QoSFilterRule) for=20
exactly this purpose. It seems that this AVP data format is=20
not yet used by any AVP type, though. It is quite complex, so=20
perhaps something like a simple "maximum uplink/downlink bandwidth"=20
attribute would be sufficient for many purposes.

BTW, it seems the actual text describing the "dscp" and "metering"
options is missing from RFC 3588. The latest draft that still
explains their parameters seems to be -09, available from:
http://www.watersprings.org/pub/id/draft-ietf-aaa-diameter-09.txt

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] On Behalf Of ext Avi Lior
> Sent: Monday, January 05, 2004 6:18 PM
> To: Loughney John (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Cc: Avi Lior; [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
> Good question John,
>=20
> Well what do you call Bandwidth attributes and transporting them?
> We are certainly talking about tranpsorting Bandwidth parameters in
> a RADIUS message.  It certainly makes sense to me to include
> Bandwidth attributes as part of the authorization of a given
> service.
>=20
> Is Bandwidth part of QoS?  I think it is.
>=20
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]=20
> > Sent: Sunday, January 04, 2004 3:52 AM
> > To: [email-masked]; [email-masked]; =
[email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: QoS attributes
> >=20
> >=20
> > Roy, Avi,
> >=20
> > I am getting quite confused by this discussion.  Could I ask what=20
> > we are actually discussing?  RADIUS/Diameter are not=20
> > signaling protocols, they are AAA protocols.  RADIUS/Diameter=20
> > should not transport QoS information.  My expectation is that=20
> > they would be involved in authorization for QoS for some=20
> > services, but doing more would seem to be out of scope for=20
> > AAA protocols.
> >=20
> > Am I missing something?
> >=20
> > John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Jan 2004 16:18:16 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked], [email-masked]
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Mon, 5 Jan 2004 11:17:56 -0500 

Good question John,

Well what do you call Bandwidth attributes and transporting them?  We are
certainly talking about tranpsorting Bandwidth parameters in a RADIUS
message.  It certainly makes sense to me to include Bandwidth attributes as
part of the authorization of a given service.  

Is Bandwidth part of QoS?  I think it is.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, January 04, 2004 3:52 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Roy, Avi,
> 
> I am getting quite confused by this discussion.  Could I ask what 
> we are actually discussing?  RADIUS/Diameter are not 
> signaling protocols, they are AAA protocols.  RADIUS/Diameter 
> should not transport QoS information.  My expectation is that 
> they would be involved in authorization for QoS for some 
> services, but doing more would seem to be out of scope for 
> AAA protocols.
> 
> Am I missing something?
> 
> John
> 
> > -----Original Message-----
> > From: ext Roy, Radhika R, ALABS [mailto:[email-masked]]
> > Sent: 03 January, 2004 16:34
> > To: [email-masked]; Nakhjiri Madjid-MNAKHJI1
> > Cc: Avi Lior; Loughney John (Nokia-NRC/Helsinki);
> > [email-masked]
> > Subject: RE: QoS attributes
> > 
> > 
> > Let us take a single node/server situation where there is 
> only one AAA 
> > server.
> > 
> > Now, the situation is this: Let a SIP call comes with SDP
> > information of
> > audio, video, and data where QoS needs to be supported for 
> > each kind of
> > media.
> > 
> > How do you want to represent QoS attributes for each kind of media?
> > 
> > Even if you represent QoS attributes for each media, what 
> does the AAA 
> > server do with all those QoS attributes? How do go from 
> there to deal 
> > with those attributes? (Please note that it is a single node/server 
> > situation, not AAA node/server to node/server 
> communications as it can 
> > be seen in the case of roaming.)
> > 
> > Radhika R. Roy
> > [email-masked]
> > 
> > -----Original Message-----
> > From: Jari Arkko [mailto:[email-masked]]
> > Sent: Saturday, January 03, 2004 4:05 AM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: 'Avi Lior'; [email-masked]; [email-masked]
> > Subject: Re: QoS attributes
> > 
> > 
> > Nakhjiri Madjid-MNAKHJI1 wrote:
> > 
> > > Maybe I am missing your point as well, but again, the grouping  
> > > comes into my mind: Can you group the parameters into a 
> generic QoS 
> > > attribute, with subtypes (or AVPs) that the AAA server or 
> at least 
> > > the AAA intermediaries don't have to understand in details? They 
> > > just know it is a QoS related info they are passing along or 
> > > receiving?
> > > 
> > > At the moment I am going to through Diameter base RFC, trying to 
> > > understand how Diameter does this! I found the grouped 
> AVP values, 
> > > but I am not clear if all the original AVPs must be understood by 
> > > the Diameter nodes? Anybody cares for a hint :)
> > 
> > Intermediate nodes may not need to understand the AVPs. 
> (Grouping has 
> > nothing to do with that, its just a representation.)
> > 
> > For the transport of this information to be meaningful, 
> however, the 
> > end nodes have to *do* something with the information. It 
> may not be 
> > necessary that they understand the attributes, but on the 
> server side 
> > you have to at least
> > 
> > - Determine whether the NAS/client/service nodes are capable
> >    and willing to provide the requested QoS. Alternatively, you
> >    just provide the information on a do-it-if-you-can basis.
> >    In Diameter, you would probably set the 'M' (Mandatory) bit
> >    in the former case and reset it in the latter.
> > - Determine what QoS this particular sesssion should get, on
> >    a policy basis. This could be e.g. a configuration on a user
> >    database, but it could also be something more complicated.
> > 
> > On the NAS side you have to at least
> > 
> > - Parse the AVPs that you have been given, if the 'M' bit is
> >    on.
> > - Force the effect requested by the AVPs, for instance by
> >    setting the max bandwidth parameter on the interface, talking
> >    to an access point about the priority it gives to this
> >    particular session, or something like that.
> > 
> > In conclusion the 'M' bit functionality in Diameter allows you a 
> > limited form of control how the QoS instructions are to be 
> processed. 
> > Given that current nodes do not support the kind of QoS attributes 
> > this BOF is looking at, its likely that most usage would have to be 
> > M=0, at least for a while. However, for the QoS attribute 
> > functionality to be useful, the end nodes have to 
> "understand" them in 
> > some manner. We have the protocol means to carry the information in 
> > AAA without requiring too much of that, but just carrying 
> them in AAA 
> > is not enough for the effects. I think one big question 
> here is that 
> > if link layer or SDO specific QoS attributes become available,
> > what is the likelihood of the server attributes matching
> > those understood by the NAS in a roaming setting.
> > 
> > --Jari
> > 
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Jan 2004 16:10:56 +0000
From: Avi Lior <[email-masked]>
To: "'CONGDON,PAUL (HP-Roseville,ex1)'" <[email-masked]>,  'Henning Schulzrinne' <[email-masked]>, Richard Perlman <[email-masked]>
Cc: Avi Lior <[email-masked]>,  "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>,  [email-masked]
Subject: RE: Encoding of Location-Id and Location-Name in	draft-black-radi us-lanedge-00.txt
Date: Mon, 5 Jan 2004 11:10:01 -0500 

I don't think there is much to optimize here. You have to do a character by
character examination to extract the information you want.

Let me be clear about something.  I am not really concerned about the
performance hit in parsing this particular attribute.  My concern is that
protocol designers will continue to use this style of encoding and then we
would have a performance problem.  Using X.500 style of encoding is very
alluring for many reasons.  What about XML encoding?  That is even more
alluring.  When will we have to deal with that?

I would like to adopt the following heuristic (we can refine this):  If the
item in question is defined elsewhere then we adopt its encoding scheme.
Otherwise, if it is just for the consumption of AAA we adopt an encoding
scheme that is most efficient for RADIUS.

We also have to be very vigilant that the contents of the strings are
specified tightly!!!

On the other hand, I get the feeling that resistance is futile ;-)

Avi.
  
> -----Original Message-----
> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:[email-masked]] 
> Sent: Saturday, January 03, 2004 6:46 PM
> To: 'Henning Schulzrinne'; Richard Perlman
> Cc: 'Avi Lior'; BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL 
> (HP-Roseville,ex1); [email-masked]
> Subject: RE: Encoding of Location-Id and Location-Name in 
> draft-black-radi us-lanedge-00.txt
> 
> 
> 
> The origin of the current Location-ID string comes from X.500 
> formats. Surely there is optimized code that can parse this...
> 
> Paul
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Saturday, January 03, 2004 12:48 PM
> > To: Richard Perlman
> > Cc: 'Avi Lior'; BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL 
> > (HP-Roseville,ex1); [email-masked]
> > Subject: Re: Encoding of Location-Id and Location-Name in 
> > draft-black-radius-lanedge-00.txt
> > 
> > 
> > On a related note, there is a proposal in the GEOPRIV WG on encoding
> > civil (city/street) locations in DHCP; see 
> > draft-schulzrinne-geopriv-dhcp-civil-01.txt
> > 
> > It would be really nice if there was some commonality across
> > these formats.
> > 
> > On 12/29/2003 12:50 PM, Richard Perlman wrote:
> > 
> > > Avi:
> > > 
> > > I am not sure that the parsing of a string is all that much more
> > > difficult. Given an arbitrarily large base of locations, 
> you would 
> > > probably search a hashed list anyways, and strings are a 
> lot easier 
> > > for people to manage in some table or file rather than 
> > having to add
> > > value assignments to a dictionary.
> > > 
> > > Richard
> > > 
> > > On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)"
> > > <[email-masked]>
> > > wrote:
> > > 
> > > 
> > >>Hi Avi,
> > >>
> > >>The encoding of Location-ID is identical to that proposed
> > by the Wi-Fi
> > >>Alliance in it's WISPr document in section 5.2 for their
> > "Location-ID"
> > >>attribute.  I'm not sure where that encoding originated, 
> so I'm not
> > >>sure if there are other applications which make use of it or not.
> > >>
> > >>There have been discussions regarding making attributes such as
> > >>Location-ID into a common (not vendor-specific) attribute.  
> > Since it
> > >>may be used widely, whichever encoding format is preferable (the
> > >>current WISPr or else TLV) should be chosen.  Perhaps there 
> > are others
> > >>who have knowledge of why and how the WISPr Location-ID format was
> > >>chosen, and could add their input here.
> > >>
> > >>/chuck
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Avi Lior [mailto:[email-masked]]
> > >>Sent: Monday, December 22, 2003 2:03 PM
> > >>To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK
> > (HP-Roseville,ex1);
> > >>[email-masked]
> > >>Subject: Encoding of Location-Id and Location-Name in
> > >>draft-black-radius-l anedge-00.txt
> > >>
> > >>
> > >>Hi Paul, Chuck
> > >>
> > >>I have an issue with Location-ID and Location-Name.
> > >>
> > >>Since these attribute may appear in an Access-Request message, I
> > >>assume that they would be used by RADIUS in evaluating policy.  
> > >>Therefore I would not want these encoded as a string the 
> > way you have
> > >>it.  I would rather see a more efficient encoding scheme, one that
> > >>would make it faster for RADIUS to parse.
> > >>
> > >>In discussions on this list I proposed to use a single
> > attribute that
> > >>is of type string (the same as yours) that would encode the
> > >>information using TLV. Both of these schemes provide for 
> > extensibility
> > >>and optionality.  But the TLV approach as an advantage that it is
> > >>easier to parse for RADIUS ( we don't want to slow RADIUS 
> > down), and
> > >>is more compact.  The encoding approach in your document is human
> > >>readable.
> > >>
> > >>IMO the string encoding you propose would be okay if it
> > already has an
> > >>application that expects this type of encoding.
> > >>
> > >>--
> > >>to unsubscribe send a message to
> > [email-masked] 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
> > [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 05 Jan 2004 05:43:02 +0000
content-class: urn:content-classes:message
Subject: RE: Authorization for AAA and RADIUS work items
Date: Mon, 5 Jan 2004 07:42:18 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi all,

> I agree that AAA/RADIUS/DIAMETER server MUST not signal QoS.
>=20
> It is also clear that authentication is also NOT directly related to
> QoS.
>=20
> However, you have agreed that "accounting" has implications on QoS.
>=20
> I also believe that "authorization" may/will also have=20
> implications QoS as John also mentioned.

I think that QoS can be thought of as a service, which a user may
need to be authorized for. This can be related to accounting, in a
way, for example, if a person's service subscription supports the
service or not. =20
=20
> So, we have bounded the problems how far we should go for
> standardization of QoS attributes for the AAA/RADIUS/DIAMETER server.
>=20
> So, is it possible to provide clear guidance what we should do in
> addressing the QoS attributes?

I think that is something that needs more discussion.  I would like to
see some sort of basic 'requirements' layed out for QoS.  Nothing
in great detail, but a good overview of what one expects from QoS/
AAA interaction.=20

br,
John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 23:10:57 +0000
content-class: urn:content-classes:message
Subject: RE: SIP AAA and QoS Attributes
Date: Sun, 4 Jan 2004 18:10:33 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: "Wolfgang Beck" <[email-masked]>, <[email-masked]>

Wolfgang:

I did NOT say for "authentication" of SIP QoS attributes or parameters.

What I said is as follows:

SIP resources (may including QoS) "MAY" need to be authorized for the
user who has been "authenticated."=20

For example, a user may not be authorized for using video, if it is long
distance call. If even one is authorized to use video, the user may not
be authorized to use "bandwidth" more than 128 kbps, etc., etc.

Similarly, the accounting/billing may also be dependent on the above.

However, it is a fair question: Where do we capture all those things for
"authorization" and "accounting/billing" information of all those
resources/QoS attributes? Should we deal in AAA/RADIUS/DIAMETER or some
other standards?

Radhika

PS: I am aware about the works of the SIP session policy works (URL of
the slides that you have provided).

-----Original Message-----
From: Wolfgang Beck [mailto:[email-masked]]
Sent: Sunday, January 04, 2004 5:49 PM
To: [email-masked]
Subject: RE: SIP AAA and QoS Attributes

Radhika,

You wrote:
> > - SIP UASs (eg. SIP Proxies, PSTN Gateways, Application Servers) use
> > SIP specific RADIUS (or DIAMETER) attributes to do AAA for SIP
specific
> > services (I am working on an updated version of the sterman draft
which
> > should be available at the beginning of february).
> >=20
> [RRR] Good. Will it also include QoS abstraction/attributes for each
> media (audio, video, data) that will be a part of the SDP messages
> in SIP?
Are you thinking of a SIP session policy framework like the one
described in
http://www.softarmor.com/sipping/meets/ietf58/slides/pres-hilt-session-p
olicy.ppt ?
This work is in a very early stage.

I don't quite understand why you would need to authenticate QoS
parameters
in a SIP system. This is up to your resource reservation protocol of
choice (which can, of course, be part of a device which uses SIP for
call signalling).

Given the absence of public networks providing dynamic resource
reservation, I'd give media accounting priority over QoS
authentication.

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 22:49:09 +0000
To: [email-masked]
Subject: RE: SIP AAA and QoS Attributes
Date: Sun, 04 Jan 2004 23:48:34 +0100
From: [email-masked] (Wolfgang Beck)

Radhika,

You wrote:
> > - SIP UASs (eg. SIP Proxies, PSTN Gateways, Application Servers) use
> > SIP specific RADIUS (or DIAMETER) attributes to do AAA for SIP specific
> > services (I am working on an updated version of the sterman draft which
> > should be available at the beginning of february).
> > 
> [RRR] Good. Will it also include QoS abstraction/attributes for each
> media (audio, video, data) that will be a part of the SDP messages
> in SIP?
Are you thinking of a SIP session policy framework like the one
described in
http://www.softarmor.com/sipping/meets/ietf58/slides/pres-hilt-session-policy.ppt ?
This work is in a very early stage.

I don't quite understand why you would need to authenticate QoS parameters
in a SIP system. This is up to your resource reservation protocol of
choice (which can, of course, be part of a device which uses SIP for
call signalling).

Given the absence of public networks providing dynamic resource
reservation, I'd give media accounting priority over QoS
authentication.

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 20:24:50 +0000
content-class: urn:content-classes:message
Subject: RE: SIP AAA and QoS Attributes
Date: Sun, 4 Jan 2004 15:24:27 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: "Wolfgang Beck" <[email-masked]>, <[email-masked]>

Inline [RRR]

Thanks to Wolfgang for sending this message - Radhika

-----Original Message-----
From: Wolfgang Beck [mailto:[email-masked]]
Sent: Sunday, January 04, 2004 2:43 PM
To: [email-masked]
Subject: SIP AAA and QoS Attributes

- SIP UASs (eg. SIP Proxies, PSTN Gateways, Application Servers) use
SIP specific RADIUS (or DIAMETER) attributes to do AAA for SIP specific
services (I am working on an updated version of the sterman draft which
should be available at the beginning of february).

[RRR] Good. Will it also include QoS abstraction/attributes for each
media (audio, video, data) that will be a part of the SDP messages in
SIP?

- RSVP / NSIS etc. routers or other intermediaries involved with
resource
reservation use their own RADIUS (or DIAMETER) attributes. I am really
astonished that there isn't more activity in this area. Who would invest
into a public bandwidth reservation architecture without being able to
charge for it?

[RRR] That is exactly right. Each should use its own way of dealing with
RADIUS/DIAMETER where needed. That is why, I have been directing the
discussion along the same line when QoS attributes are being discussed.
In fact, in this way, RADIUS/DIAMETER may act as glue for various
services/layers.

- Media Accounting is a bit different from QoS acounting. QoS accounting
says: 'A has reserved a flow of x kb/s for 120 seconds', while Media
Accounting says: 'A has sent x packets and received y packets. The
session
duration was z seconds, the average roundtrip delay was p, the average
jitter buffer length was q, there were r seconds with errors etc'. Media
Accounting is necessary if there is no resource reservation available.

[RRR] We can revisit this when we will have more handle on QoS
attributes for billing/accounting, when needed.

SIP and resource reservation should be kept separate. The SIP WG still
fights bravely against any attempts to make SIP a resource reservation
protocol.

[RRR] Absolutely, you are right. For example, RFCs like 3312 provides
indication when resources reservation in SIP should be started and
completed before sending other signaling messages (e.g., reserve
resources before sending the 180 ringing response). However, RFC 3312
never says how resources reservation needs to be done or what kinds of
QoS signaling mechanisms need to be used for resources reservation.

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 19:44:18 +0000
To: [email-masked]
Subject: SIP AAA and QoS Attributes
Date: Sun, 04 Jan 2004 20:42:55 +0100
From: [email-masked] (Wolfgang Beck)

- SIP UASs (eg. SIP Proxies, PSTN Gateways, Application Servers) use
SIP specific RADIUS (or DIAMETER) attributes to do AAA for SIP specific
services (I am working on an updated version of the sterman draft which
should be available at the beginning of february).

- RSVP / NSIS etc. routers or other intermediaries involved with resource
reservation use their own RADIUS (or DIAMETER) attributes. I am really
astonished that there isn't more activity in this area. Who would invest
into a public bandwidth reservation architecture without being able to
charge for it?

- Media Accounting is a bit different from QoS acounting. QoS accounting
says: 'A has reserved a flow of x kb/s for 120 seconds', while Media
Accounting says: 'A has sent x packets and received y packets. The session
duration was z seconds, the average roundtrip delay was p, the average
jitter buffer length was q, there were r seconds with errors etc'. Media
Accounting is necessary if there is no resource reservation available.

SIP and resource reservation should be kept separate. The SIP WG still
fights bravely against any attempts to make SIP a resource reservation
protocol.

--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 18:29:21 +0000
content-class: urn:content-classes:message
Subject: RE: Authorization for AAA and RADIUS work items
Date: Sun, 4 Jan 2004 13:28:47 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi, Bernard:

I agree that AAA/RADIUS/DIAMETER server MUST not signal QoS.

It is also clear that authentication is also NOT directly related to
QoS.

However, you have agreed that "accounting" has implications on QoS.

I also believe that "authorization" may/will also have implications QoS
as John also mentioned.

So, we have bounded the problems how far we should go for
standardization of QoS attributes for the AAA/RADIUS/DIAMETER server.

So, is it possible to provide clear guidance what we should do in
addressing the QoS attributes?

Radhika

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Sunday, January 04, 2004 12:44 PM
To: [email-masked]
Subject: Authorization for AAA and RADIUS work items

In order to make sure that AAA-related WGs stay in sync with other WGs
and
SDOs, there is a requirement that AAA-related work items be authorized
by
a requirements document.

Here are some of the AAA requirements documents that have been approved
for publication as RFCs:

draft-ietf-sipping-aaa-req-04.txt
RFC 3141
RFC 2989
RFC 2977
RFC 2881
RFC 2477

Nowhere in these documents is there any mention of AAA requirements for
signaled QoS.

In the NSIS requirements document (draft-ietf-nsis-req-09.txt) there is
a
requirement 5.9.4 that mentions AAA:

"The NSIS SHOULD be developed with respect to be able to collect
usage records from one or more network elements. "

However this seems to only relate to accounting, not authentication and
authorized of signaled QoS.

It would therefore appear to me that use of AAA for signaled QoS has not
been authorized by a requirements document, and therefore cannot become
a
RADEXT (or even AAA) WG work item.

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 17:28:49 +0000
Date: Sun, 4 Jan 2004 09:44:04 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Authorization for AAA and RADIUS work items

In order to make sure that AAA-related WGs stay in sync with other WGs and
SDOs, there is a requirement that AAA-related work items be authorized by
a requirements document.

Here are some of the AAA requirements documents that have been approved
for publication as RFCs:

draft-ietf-sipping-aaa-req-04.txt
RFC 3141
RFC 2989
RFC 2977
RFC 2881
RFC 2477

Nowhere in these documents is there any mention of AAA requirements for
signaled QoS.

In the NSIS requirements document (draft-ietf-nsis-req-09.txt) there is a
requirement 5.9.4 that mentions AAA:

"The NSIS SHOULD be developed with respect to be able to collect
usage records from one or more network elements. "

However this seems to only relate to accounting, not authentication and
authorized of signaled QoS.

It would therefore appear to me that use of AAA for signaled QoS has not
been authorized by a requirements document, and therefore cannot become a
RADEXT (or even AAA) WG work item.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 16:14:31 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Sun, 4 Jan 2004 11:14:10 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: "Roy, Radhika R, ALABS" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi, John and all:

John has made a very important point: AAA server ONLY =
"authenticate/authorize" of the QoS resources for the user for a given =
call.

It means that AAA does NOT anyway "guarantee" whether those QoS =
resources are available on end-to-end basis.

The only problem that we need to solve is this: Like authentication, we =
need to create a COMMON standards for QoS attributes that can be used =
for all types of calls.

I appreciate John for clarifications of the most important point that we =
have been looking for.

Radhika

-----Original Message-----
From: Roy, Radhika R, ALABS=20
Sent: Sunday, January 04, 2004 11:04 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QoS attributes

John:

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.

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 .

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.

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.

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

Hope that others will also add to this.

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 04, 2004 3:52 AM
To: Roy, Radhika R, ALABS; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QoS attributes

Roy, Avi,

I am getting quite confused by this discussion.  Could I ask what=20
we are actually discussing?  RADIUS/Diameter are not signaling
protocols, they are AAA protocols.  RADIUS/Diameter should not
transport QoS information.  My expectation is that they
would be involved in authorization for QoS for some services,
but doing more would seem to be out of scope for AAA protocols.

Am I missing something?

John

> -----Original Message-----
> From: ext Roy, Radhika R, ALABS [mailto:[email-masked]]
> Sent: 03 January, 2004 16:34
> To: [email-masked]; Nakhjiri Madjid-MNAKHJI1
> Cc: Avi Lior; Loughney John (Nokia-NRC/Helsinki);=20
> [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
> Let us take a single node/server situation where there is only one AAA
> server.
>=20
> Now, the situation is this: Let a SIP call comes with SDP=20
> information of
> audio, video, and data where QoS needs to be supported for=20
> each kind of
> media.
>=20
> How do you want to represent QoS attributes for each kind of media?
>=20
> Even if you represent QoS attributes for each media, what does the AAA
> server do with all those QoS attributes? How do go from there to deal
> with those attributes? (Please note that it is a single node/server
> situation, not AAA node/server to node/server communications as it can
> be seen in the case of roaming.)
>=20
> Radhika R. Roy
> [email-masked]
>=20
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Saturday, January 03, 2004 4:05 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Avi Lior'; [email-masked]; [email-masked]
> Subject: Re: QoS attributes
>=20
>=20
> Nakhjiri Madjid-MNAKHJI1 wrote:
>=20
> > Maybe I am missing your point as well, but again, the grouping
> >  comes into my mind: Can you group the parameters
> > into a generic QoS attribute, with subtypes (or AVPs) that the AAA
> > server or at least the AAA intermediaries don't have to understand
> > in details? They just know it is a QoS related info they are passing
> > along or receiving?
> >=20
> > At the moment I am going to through Diameter base RFC,
> > trying to understand how Diameter does this!
> > I found the grouped AVP values, but I am not clear if all the
> > original AVPs must be understood by the Diameter nodes?
> > Anybody cares for a hint :)
>=20
> Intermediate nodes may not need to understand the AVPs. (Grouping
> has nothing to do with that, its just a representation.)
>=20
> For the transport of this information to be meaningful, however,
> the end nodes have to *do* something with the information. It
> may not be necessary that they understand the attributes, but
> on the server side you have to at least
>=20
> - Determine whether the NAS/client/service nodes are capable
>    and willing to provide the requested QoS. Alternatively, you
>    just provide the information on a do-it-if-you-can basis.
>    In Diameter, you would probably set the 'M' (Mandatory) bit
>    in the former case and reset it in the latter.
> - Determine what QoS this particular sesssion should get, on
>    a policy basis. This could be e.g. a configuration on a user
>    database, but it could also be something more complicated.
>=20
> On the NAS side you have to at least
>=20
> - Parse the AVPs that you have been given, if the 'M' bit is
>    on.
> - Force the effect requested by the AVPs, for instance by
>    setting the max bandwidth parameter on the interface, talking
>    to an access point about the priority it gives to this
>    particular session, or something like that.
>=20
> In conclusion the 'M' bit functionality in Diameter allows
> you a limited form of control how the QoS instructions are to
> be processed. Given that current nodes do not support the
> kind of QoS attributes this BOF is looking at, its likely that
> most usage would have to be M=3D0, at least for a while. However,
> for the QoS attribute functionality to be useful, the end
> nodes have to "understand" them in some manner. We have the
> protocol means to carry the information in AAA without requiring
> too much of that, but just carrying them in AAA is not enough
> for the effects. I think one big question here is that if
> link layer or SDO specific QoS attributes become available,
> what is the likelihood of the server attributes matching
> those understood by the NAS in a roaming setting.
>=20
> --Jari
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 16:04:15 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Sun, 4 Jan 2004 11:03:41 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

John:

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.

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 .

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.

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.

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

Hope that others will also add to this.

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, January 04, 2004 3:52 AM
To: Roy, Radhika R, ALABS; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QoS attributes

Roy, Avi,

I am getting quite confused by this discussion.  Could I ask what=20
we are actually discussing?  RADIUS/Diameter are not signaling
protocols, they are AAA protocols.  RADIUS/Diameter should not
transport QoS information.  My expectation is that they
would be involved in authorization for QoS for some services,
but doing more would seem to be out of scope for AAA protocols.

Am I missing something?

John

> -----Original Message-----
> From: ext Roy, Radhika R, ALABS [mailto:[email-masked]]
> Sent: 03 January, 2004 16:34
> To: [email-masked]; Nakhjiri Madjid-MNAKHJI1
> Cc: Avi Lior; Loughney John (Nokia-NRC/Helsinki);=20
> [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
> Let us take a single node/server situation where there is only one AAA
> server.
>=20
> Now, the situation is this: Let a SIP call comes with SDP=20
> information of
> audio, video, and data where QoS needs to be supported for=20
> each kind of
> media.
>=20
> How do you want to represent QoS attributes for each kind of media?
>=20
> Even if you represent QoS attributes for each media, what does the AAA
> server do with all those QoS attributes? How do go from there to deal
> with those attributes? (Please note that it is a single node/server
> situation, not AAA node/server to node/server communications as it can
> be seen in the case of roaming.)
>=20
> Radhika R. Roy
> [email-masked]
>=20
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Saturday, January 03, 2004 4:05 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Avi Lior'; [email-masked]; [email-masked]
> Subject: Re: QoS attributes
>=20
>=20
> Nakhjiri Madjid-MNAKHJI1 wrote:
>=20
> > Maybe I am missing your point as well, but again, the grouping
> >  comes into my mind: Can you group the parameters
> > into a generic QoS attribute, with subtypes (or AVPs) that the AAA
> > server or at least the AAA intermediaries don't have to understand
> > in details? They just know it is a QoS related info they are passing
> > along or receiving?
> >=20
> > At the moment I am going to through Diameter base RFC,
> > trying to understand how Diameter does this!
> > I found the grouped AVP values, but I am not clear if all the
> > original AVPs must be understood by the Diameter nodes?
> > Anybody cares for a hint :)
>=20
> Intermediate nodes may not need to understand the AVPs. (Grouping
> has nothing to do with that, its just a representation.)
>=20
> For the transport of this information to be meaningful, however,
> the end nodes have to *do* something with the information. It
> may not be necessary that they understand the attributes, but
> on the server side you have to at least
>=20
> - Determine whether the NAS/client/service nodes are capable
>    and willing to provide the requested QoS. Alternatively, you
>    just provide the information on a do-it-if-you-can basis.
>    In Diameter, you would probably set the 'M' (Mandatory) bit
>    in the former case and reset it in the latter.
> - Determine what QoS this particular sesssion should get, on
>    a policy basis. This could be e.g. a configuration on a user
>    database, but it could also be something more complicated.
>=20
> On the NAS side you have to at least
>=20
> - Parse the AVPs that you have been given, if the 'M' bit is
>    on.
> - Force the effect requested by the AVPs, for instance by
>    setting the max bandwidth parameter on the interface, talking
>    to an access point about the priority it gives to this
>    particular session, or something like that.
>=20
> In conclusion the 'M' bit functionality in Diameter allows
> you a limited form of control how the QoS instructions are to
> be processed. Given that current nodes do not support the
> kind of QoS attributes this BOF is looking at, its likely that
> most usage would have to be M=3D0, at least for a while. However,
> for the QoS attribute functionality to be useful, the end
> nodes have to "understand" them in some manner. We have the
> protocol means to carry the information in AAA without requiring
> too much of that, but just carrying them in AAA is not enough
> for the effects. I think one big question here is that if
> link layer or SDO specific QoS attributes become available,
> what is the likelihood of the server attributes matching
> those understood by the NAS in a roaming setting.
>=20
> --Jari
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Jan 2004 08:52:46 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Sun, 4 Jan 2004 10:52:12 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Roy, Avi,

I am getting quite confused by this discussion.  Could I ask what=20
we are actually discussing?  RADIUS/Diameter are not signaling
protocols, they are AAA protocols.  RADIUS/Diameter should not
transport QoS information.  My expectation is that they
would be involved in authorization for QoS for some services,
but doing more would seem to be out of scope for AAA protocols.

Am I missing something?

John

> -----Original Message-----
> From: ext Roy, Radhika R, ALABS [mailto:[email-masked]]
> Sent: 03 January, 2004 16:34
> To: [email-masked]; Nakhjiri Madjid-MNAKHJI1
> Cc: Avi Lior; Loughney John (Nokia-NRC/Helsinki);=20
> [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
> Let us take a single node/server situation where there is only one AAA
> server.
>=20
> Now, the situation is this: Let a SIP call comes with SDP=20
> information of
> audio, video, and data where QoS needs to be supported for=20
> each kind of
> media.
>=20
> How do you want to represent QoS attributes for each kind of media?
>=20
> Even if you represent QoS attributes for each media, what does the AAA
> server do with all those QoS attributes? How do go from there to deal
> with those attributes? (Please note that it is a single node/server
> situation, not AAA node/server to node/server communications as it can
> be seen in the case of roaming.)
>=20
> Radhika R. Roy
> [email-masked]
>=20
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Saturday, January 03, 2004 4:05 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Avi Lior'; [email-masked]; [email-masked]
> Subject: Re: QoS attributes
>=20
>=20
> Nakhjiri Madjid-MNAKHJI1 wrote:
>=20
> > Maybe I am missing your point as well, but again, the grouping
> >  comes into my mind: Can you group the parameters
> > into a generic QoS attribute, with subtypes (or AVPs) that the AAA
> > server or at least the AAA intermediaries don't have to understand
> > in details? They just know it is a QoS related info they are passing
> > along or receiving?
> >=20
> > At the moment I am going to through Diameter base RFC,
> > trying to understand how Diameter does this!
> > I found the grouped AVP values, but I am not clear if all the
> > original AVPs must be understood by the Diameter nodes?
> > Anybody cares for a hint :)
>=20
> Intermediate nodes may not need to understand the AVPs. (Grouping
> has nothing to do with that, its just a representation.)
>=20
> For the transport of this information to be meaningful, however,
> the end nodes have to *do* something with the information. It
> may not be necessary that they understand the attributes, but
> on the server side you have to at least
>=20
> - Determine whether the NAS/client/service nodes are capable
>    and willing to provide the requested QoS. Alternatively, you
>    just provide the information on a do-it-if-you-can basis.
>    In Diameter, you would probably set the 'M' (Mandatory) bit
>    in the former case and reset it in the latter.
> - Determine what QoS this particular sesssion should get, on
>    a policy basis. This could be e.g. a configuration on a user
>    database, but it could also be something more complicated.
>=20
> On the NAS side you have to at least
>=20
> - Parse the AVPs that you have been given, if the 'M' bit is
>    on.
> - Force the effect requested by the AVPs, for instance by
>    setting the max bandwidth parameter on the interface, talking
>    to an access point about the priority it gives to this
>    particular session, or something like that.
>=20
> In conclusion the 'M' bit functionality in Diameter allows
> you a limited form of control how the QoS instructions are to
> be processed. Given that current nodes do not support the
> kind of QoS attributes this BOF is looking at, its likely that
> most usage would have to be M=3D0, at least for a while. However,
> for the QoS attribute functionality to be useful, the end
> nodes have to "understand" them in some manner. We have the
> protocol means to carry the information in AAA without requiring
> too much of that, but just carrying them in AAA is not enough
> for the effects. I think one big question here is that if
> link layer or SDO specific QoS attributes become available,
> what is the likelihood of the server attributes matching
> those understood by the NAS in a roaming setting.
>=20
> --Jari
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Jan 2004 23:46:36 +0000
From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
To: 'Henning Schulzrinne' <[email-masked]>, Richard Perlman <[email-masked]>
Cc: 'Avi Lior' <[email-masked]>, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>, "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, [email-masked]
Subject: RE: Encoding of Location-Id and Location-Name in	draft-black-radi us-lanedge-00.txt
Date: Sat, 3 Jan 2004 18:46:03 -0500 

The origin of the current Location-ID string comes from X.500 formats.
Surely there is optimized code that can parse this...

Paul

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Saturday, January 03, 2004 12:48 PM
> To: Richard Perlman
> Cc: 'Avi Lior'; BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL 
> (HP-Roseville,ex1); [email-masked]
> Subject: Re: Encoding of Location-Id and Location-Name in 
> draft-black-radius-lanedge-00.txt
> 
> 
> On a related note, there is a proposal in the GEOPRIV WG on encoding 
> civil (city/street) locations in DHCP; see 
> draft-schulzrinne-geopriv-dhcp-civil-01.txt
> 
> It would be really nice if there was some commonality across 
> these formats.
> 
> On 12/29/2003 12:50 PM, Richard Perlman wrote:
> 
> > Avi:
> > 
> > I am not sure that the parsing of a string is all that much more 
> > difficult. Given an arbitrarily large base of locations, you would 
> > probably search a hashed list anyways, and strings are a lot easier 
> > for people to manage in some table or file rather than 
> having to add 
> > value assignments to a dictionary.
> > 
> > Richard
> > 
> > On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" 
> > <[email-masked]>
> > wrote:
> > 
> > 
> >>Hi Avi,
> >>
> >>The encoding of Location-ID is identical to that proposed 
> by the Wi-Fi 
> >>Alliance in it's WISPr document in section 5.2 for their 
> "Location-ID" 
> >>attribute.  I'm not sure where that encoding originated, so I'm not 
> >>sure if there are other applications which make use of it or not.
> >>
> >>There have been discussions regarding making attributes such as 
> >>Location-ID into a common (not vendor-specific) attribute.  
> Since it 
> >>may be used widely, whichever encoding format is preferable (the 
> >>current WISPr or else TLV) should be chosen.  Perhaps there 
> are others 
> >>who have knowledge of why and how the WISPr Location-ID format was 
> >>chosen, and could add their input here.
> >>
> >>/chuck
> >>
> >>
> >>-----Original Message-----
> >>From: Avi Lior [mailto:[email-masked]]
> >>Sent: Monday, December 22, 2003 2:03 PM
> >>To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK 
> (HP-Roseville,ex1); 
> >>[email-masked]
> >>Subject: Encoding of Location-Id and Location-Name in 
> >>draft-black-radius-l anedge-00.txt
> >>
> >>
> >>Hi Paul, Chuck
> >>
> >>I have an issue with Location-ID and Location-Name.
> >>
> >>Since these attribute may appear in an Access-Request message, I 
> >>assume that they would be used by RADIUS in evaluating policy.  
> >>Therefore I would not want these encoded as a string the 
> way you have 
> >>it.  I would rather see a more efficient encoding scheme, one that 
> >>would make it faster for RADIUS to parse.
> >>
> >>In discussions on this list I proposed to use a single 
> attribute that 
> >>is of type string (the same as yours) that would encode the 
> >>information using TLV. Both of these schemes provide for 
> extensibility 
> >>and optionality.  But the TLV approach as an advantage that it is 
> >>easier to parse for RADIUS ( we don't want to slow RADIUS 
> down), and 
> >>is more compact.  The encoding approach in your document is human 
> >>readable.
> >>
> >>IMO the string encoding you propose would be okay if it 
> already has an 
> >>application that expects this type of encoding.
> >>
> >>--
> >>to unsubscribe send a message to 
> [email-masked] 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 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Jan 2004 20:48:56 +0000
Date: Sat, 03 Jan 2004 15:48:14 -0500
From: Henning Schulzrinne <[email-masked]>
To: Richard Perlman <[email-masked]>
CC: "'Avi Lior'" <[email-masked]>, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>, "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, [email-masked]
Subject: Re: Encoding of Location-Id and Location-Name in	draft-black-radius-lanedge-00.txt

On a related note, there is a proposal in the GEOPRIV WG on encoding 
civil (city/street) locations in DHCP; see 
draft-schulzrinne-geopriv-dhcp-civil-01.txt

It would be really nice if there was some commonality across these formats.

On 12/29/2003 12:50 PM, Richard Perlman wrote:

> Avi:
> 
> I am not sure that the parsing of a string is all that much more difficult.
> Given an arbitrarily large base of locations, you would probably search a
> hashed list anyways, and strings are a lot easier for people to manage in
> some table or file rather than having to add value assignments to a
> dictionary.
> 
> Richard
> 
> On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
> wrote:
> 
> 
>>Hi Avi,
>>
>>The encoding of Location-ID is identical to that proposed by the Wi-Fi
>>Alliance in it's WISPr document in section 5.2 for their "Location-ID"
>>attribute.  I'm not sure where that encoding originated, so I'm not sure if
>>there are other applications which make use of it or not.
>>
>>There have been discussions regarding making attributes such as Location-ID
>>into a common (not vendor-specific) attribute.  Since it may be used widely,
>>whichever encoding format is preferable (the current WISPr or else TLV)
>>should be chosen.  Perhaps there are others who have knowledge of why and
>>how the WISPr Location-ID format was chosen, and could add their input here.
>>
>>/chuck
>>
>>
>>-----Original Message-----
>>From: Avi Lior [mailto:[email-masked]]
>>Sent: Monday, December 22, 2003 2:03 PM
>>To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1);
>>[email-masked]
>>Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l
>>anedge-00.txt
>>
>>
>>Hi Paul, Chuck
>>
>>I have an issue with Location-ID and Location-Name.
>>
>>Since these attribute may appear in an Access-Request message, I assume that
>>they would be used by RADIUS in evaluating policy.  Therefore I would not
>>want these encoded as a string the way you have it.  I would rather see a
>>more efficient encoding scheme, one that would make it faster for RADIUS to
>>parse.
>>
>>In discussions on this list I proposed to use a single attribute that is of
>>type string (the same as yours) that would encode the information using TLV.
>>Both of these schemes provide for extensibility and optionality.  But the
>>TLV approach as an advantage that it is easier to parse for RADIUS ( we
>>don't want to slow RADIUS down), and is more compact.  The encoding approach
>>in your document is human readable.
>>
>>IMO the string encoding you propose would be okay if it already has an
>>application that expects this type of encoding.
>>
>>--
>>to unsubscribe send a message to [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Jan 2004 17:37:42 +0000
Date: Sat, 3 Jan 2004 09:53:01 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Diameter QoSFilterRule AVP

> How do you want to represent QoS attributes for each kind of media?

Diameter has the QoSFilterRule AVP, defined in RFC 3588, Section 4.3.  Has
anyone analyzed the capabilities that are supported there?  Here's what
RFC 3588 says about it:

QoSFilterRule filters MUST follow the format:

   action dir proto from src to dst [options]

   action
                tag    - Mark packet with a specific DSCP
                         [DIFFSERV].  The DSCP option MUST be
                         included.
                meter  - Meter traffic.  The metering options
                         MUST be included.

   dir      The format is as described under IPFilterRule.

   proto    The format is as described under IPFilterRule.

   src and dst  The format is as described under IPFilterRule.

   options:
            frag    Match if the packet is a fragment and this is not
                    the first fragment of the datagram.  frag may not
                    be used in conjunction with either tcpflags or
                    TCP/UDP port specifications.

            ipoptions spec
                    Match if the IP header contains the comma
                    separated list of options specified in spec.  The
                    supported IP options are:

                    ssrr (strict source route), lsrr (loose source
                    route), rr (record packet route) and ts
                    (timestamp).  The absence of a particular option
                    may be denoted with a '!'.

            tcpoptions spec
                    Match if the TCP header contains the comma
                    separated list of options specified in spec.  The
                    supported TCP options are:

                    mss (maximum segment size), window (tcp window
                    advertisement), sack (selective ack), ts (rfc1323
                    timestamp) and cc (rfc1644 t/tcp connection
                    count).  The absence of a particular option may
                    be denoted with a '!'.

            established
                    TCP packets only.  Match packets that have the RST
                    or ACK bits set.

            setup   TCP packets only.  Match packets that have the SYN
                    bit set but no ACK bit.

            tcpflags spec
                    TCP packets only.  Match if the TCP header
                    contains the comma separated list of flags
                    specified in spec.  The supported TCP flags are:

                    fin, syn, rst, psh, ack and urg.  The absence of a
                    particular flag may be denoted with a '!'.  A rule
                    that contains a tcpflags specification can never
                    match a fragmented packet that has a non-zero
                    offset.  See the frag option for details on
                    matching fragmented packets.

            icmptypes types
                    ICMP packets only.  Match if the ICMP type is in
                    the list types.  The list may be specified as any
                    combination of ranges or individual types
                    separated by commas.  Both the numeric values and
                    the symbolic values listed below can be used.  The
                    supported ICMP types are:

                    echo reply (0), destination unreachable (3),
                    source quench (4), redirect (5), echo request
                    (8), router advertisement (9), router
                    solicitation (10), time-to-live exceeded (11), IP
                    header bad (12), timestamp request (13),
                    timestamp reply (14), information request (15),
                    information reply (16), address mask request (17)
                    and address mask reply (18).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Jan 2004 15:13:50 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Sat, 3 Jan 2004 09:34:29 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: <[email-masked]>, "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Cc: "Avi Lior" <[email-masked]>, <[email-masked]>, <[email-masked]>

Let us take a single node/server situation where there is only one AAA
server.

Now, the situation is this: Let a SIP call comes with SDP information of
audio, video, and data where QoS needs to be supported for each kind of
media.

How do you want to represent QoS attributes for each kind of media?

Even if you represent QoS attributes for each media, what does the AAA
server do with all those QoS attributes? How do go from there to deal
with those attributes? (Please note that it is a single node/server
situation, not AAA node/server to node/server communications as it can
be seen in the case of roaming.)

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Saturday, January 03, 2004 4:05 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Avi Lior'; [email-masked]; [email-masked]
Subject: Re: QoS attributes

Nakhjiri Madjid-MNAKHJI1 wrote:

> Maybe I am missing your point as well, but again, the grouping
>  comes into my mind: Can you group the parameters
> into a generic QoS attribute, with subtypes (or AVPs) that the AAA
> server or at least the AAA intermediaries don't have to understand
> in details? They just know it is a QoS related info they are passing
> along or receiving?
>=20
> At the moment I am going to through Diameter base RFC,
> trying to understand how Diameter does this!
> I found the grouped AVP values, but I am not clear if all the
> original AVPs must be understood by the Diameter nodes?
> Anybody cares for a hint :)

Intermediate nodes may not need to understand the AVPs. (Grouping
has nothing to do with that, its just a representation.)

For the transport of this information to be meaningful, however,
the end nodes have to *do* something with the information. It
may not be necessary that they understand the attributes, but
on the server side you have to at least

- Determine whether the NAS/client/service nodes are capable
   and willing to provide the requested QoS. Alternatively, you
   just provide the information on a do-it-if-you-can basis.
   In Diameter, you would probably set the 'M' (Mandatory) bit
   in the former case and reset it in the latter.
- Determine what QoS this particular sesssion should get, on
   a policy basis. This could be e.g. a configuration on a user
   database, but it could also be something more complicated.

On the NAS side you have to at least

- Parse the AVPs that you have been given, if the 'M' bit is
   on.
- Force the effect requested by the AVPs, for instance by
   setting the max bandwidth parameter on the interface, talking
   to an access point about the priority it gives to this
   particular session, or something like that.

In conclusion the 'M' bit functionality in Diameter allows
you a limited form of control how the QoS instructions are to
be processed. Given that current nodes do not support the
kind of QoS attributes this BOF is looking at, its likely that
most usage would have to be M=3D0, at least for a while. However,
for the QoS attribute functionality to be useful, the end
nodes have to "understand" them in some manner. We have the
protocol means to carry the information in AAA without requiring
too much of that, but just carrying them in AAA is not enough
for the effects. I think one big question here is that if
link layer or SDO specific QoS attributes become available,
what is the likelihood of the server attributes matching
those understood by the NAS in a roaming setting.

--Jari

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Jan 2004 09:06:47 +0000
Date: Sat, 03 Jan 2004 11:04:58 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: 'Avi Lior' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: QoS attributes

Nakhjiri Madjid-MNAKHJI1 wrote:

> Maybe I am missing your point as well, but again, the grouping
>  comes into my mind: Can you group the parameters
> into a generic QoS attribute, with subtypes (or AVPs) that the AAA
> server or at least the AAA intermediaries don't have to understand
> in details? They just know it is a QoS related info they are passing
> along or receiving?
> 
> At the moment I am going to through Diameter base RFC,
> trying to understand how Diameter does this!
> I found the grouped AVP values, but I am not clear if all the
> original AVPs must be understood by the Diameter nodes?
> Anybody cares for a hint :)

Intermediate nodes may not need to understand the AVPs. (Grouping
has nothing to do with that, its just a representation.)

For the transport of this information to be meaningful, however,
the end nodes have to *do* something with the information. It
may not be necessary that they understand the attributes, but
on the server side you have to at least

- Determine whether the NAS/client/service nodes are capable
   and willing to provide the requested QoS. Alternatively, you
   just provide the information on a do-it-if-you-can basis.
   In Diameter, you would probably set the 'M' (Mandatory) bit
   in the former case and reset it in the latter.
- Determine what QoS this particular sesssion should get, on
   a policy basis. This could be e.g. a configuration on a user
   database, but it could also be something more complicated.

On the NAS side you have to at least

- Parse the AVPs that you have been given, if the 'M' bit is
   on.
- Force the effect requested by the AVPs, for instance by
   setting the max bandwidth parameter on the interface, talking
   to an access point about the priority it gives to this
   particular session, or something like that.

In conclusion the 'M' bit functionality in Diameter allows
you a limited form of control how the QoS instructions are to
be processed. Given that current nodes do not support the
kind of QoS attributes this BOF is looking at, its likely that
most usage would have to be M=0, at least for a while. However,
for the QoS attribute functionality to be useful, the end
nodes have to "understand" them in some manner. We have the
protocol means to carry the information in AAA without requiring
too much of that, but just carrying them in AAA is not enough
for the effects. I think one big question here is that if
link layer or SDO specific QoS attributes become available,
what is the likelihood of the server attributes matching
those understood by the NAS in a roaming setting.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 02 Jan 2004 17:44:36 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: QoS attributes
Date: Fri, 2 Jan 2004 11:44:01 -0600 

Avi,

Maybe I am missing your point as well, but again, the grouping
 comes into my mind: Can you group the parameters
into a generic QoS attribute, with subtypes (or AVPs) that the AAA
server or at least the AAA intermediaries don't have to understand
in details? They just know it is a QoS related info they are passing
along or receiving?

At the moment I am going to through Diameter base RFC,
trying to understand how Diameter does this!
I found the grouped AVP values, but I am not clear if all the
original AVPs must be understood by the Diameter nodes?
Anybody cares for a hint :)

Thanks,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Avi Lior
Sent: Friday, January 02, 2004 10:39 AM
To: [email-masked]; Avi Lior; [email-masked]
Subject: RE: QoS attributes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, December 28, 2003 6:35 AM
> To: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi Avi,
> 
> > There are two problems with this approach is certain conditions:
> > 
> > Dealing with a QoS Class Id only only addresses static arrangements 
> > where both parties agree apriori on the contents of that are 
> > represented by a particular instance of the QoS Class Id.  This is 
> > useful but its not the only model.
> 
> > In some cases the QoS maybe more dynamic, we therefore need the 
> > flexibility to transfer the QoS Class Id and/or QoS parameters.
> 
> Agreed, however the more dynamic model is something that is 
> probably beyond RADext to standardize.

I don't particularly want to standerdize all QoS models.  But we are
starting to see QoS related work coming into RADIUS and Diameter from the
following areas:  WLAN, 3GPP2 (Go/Gq) interfaces and probably 3GPP.

The SDO will want to transport their QoS attributes in AAA (we don't know
what these are).  Learning from past experiences they will use VSAs which is
fine but it will cause interoperability issues down the road.  So the
question is can we be more proactive and accommodate the various QoS models
here?

Or as a minimum provide a framework or guidelines as to how deal with the
various QoS models and then have one or more RFCs for each QoS model thereby
achieving interoperability.

> > Something that I understand is Bandwidth.  Two parties can agree on 
> > how to bill for bandwidth without having to agree on 
> descrete bundles 
> > of bandwidth. We bill bandwidth on bits/second.
> 
> So, why are we not discussing Bandwidth?  If I understand, 
> you want to support a bandwidth attribute.  If so, I think 
> that a more comprehensive proposal would be good, one which 
> discusses the trade-offs, etc.  QoS is probably a swamp if we 
> start at supporting multiple attributes.

Bandwidth is just one of the attributes. Bandwidth is being discussed now.
And other QoS attributes would come to light shortly.
 
> > Also I am very surprised about the resistance to do this.  If we 
> > justify doing Credit Control over AAA why is this a problem?
> 
> I don't see the comparison, actually.  The Credit Control is 
> trying to standardized a token based approach for doing AAA 
> authorization. It is not standardizing (or at least trying to 
> carefully work
> with) billing models, etc.  

I agree with you and that is why I raised the question.  When I brought up
QoS, I did not intend for RADEXT to define new QoS attributes but rather to
show how existing QoS parameter would be transported within AAA messages.
Whatever the QoS attributes are.

I think the disconnect is that you are thinking I want to define (new) QoS
attributes and/or (new) QoS models.  I don't want to do this at all.

Avi.

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 02 Jan 2004 16:56:07 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Fri, 2 Jan 2004 11:55:49 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi, Avi, John, and all:

It is good that QOS attributes need to be addressed.

The question is: What would be the attributes for QoS t consider by the
AAA server?

Let us consider a call scenario. SIP INVITE message contains SDP where
audio, video, and data (application) need to be supported. Like security
(authentication), an AAA (RADIUS/DIAMETER) needs to do something.

Step 1: Each media will have their QoS attributes. What are those?

However, unlike security (authentication), the QoS attributes are
"end-to-end" specific. That is, the information that is available within
the AAA server is NOT sufficient to take the decision.

Step 2: Now, the question is this: Even if the QoS attributes are known,
what decision that an AAA server needs to take? How do we solve this
puzzle of an "end-to-end" attribute (e.g., bandwidth or delay) with the
AAA server? Does the AAA server need to take the help of other entities?
If so, what are those and how?

Let us focus on the above points: Step 2 (First) and Step 1 (Second).

Have a Happy New Year!

Best regards,

Radhika R. Roy
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 02 Jan 2004 16:39:12 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Fri, 2 Jan 2004 11:38:31 -0500 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, December 28, 2003 6:35 AM
> To: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi Avi,
> 
> > There are two problems with this approach is certain conditions:
> > 
> > Dealing with a QoS Class Id only only addresses static arrangements 
> > where both parties agree apriori on the contents of that are 
> > represented by a particular instance of the QoS Class Id.  This is 
> > useful but its not the only model.
> 
> > In some cases the QoS maybe more dynamic, we therefore need the 
> > flexibility to transfer the QoS Class Id and/or QoS parameters.
> 
> Agreed, however the more dynamic model is something that is 
> probably beyond RADext to standardize.

I don't particularly want to standerdize all QoS models.  But we are
starting to see QoS related work coming into RADIUS and Diameter from the
following areas:  WLAN, 3GPP2 (Go/Gq) interfaces and probably 3GPP.

The SDO will want to transport their QoS attributes in AAA (we don't know
what these are).  Learning from past experiences they will use VSAs which is
fine but it will cause interoperability issues down the road.  So the
question is can we be more proactive and accommodate the various QoS models
here?

Or as a minimum provide a framework or guidelines as to how deal with the
various QoS models and then have one or more RFCs for each QoS model thereby
achieving interoperability.

> > Something that I understand is Bandwidth.  Two parties can agree on 
> > how to bill for bandwidth without having to agree on 
> descrete bundles 
> > of bandwidth. We bill bandwidth on bits/second.
> 
> So, why are we not discussing Bandwidth?  If I understand, 
> you want to support a bandwidth attribute.  If so, I think 
> that a more comprehensive proposal would be good, one which 
> discusses the trade-offs, etc.  QoS is probably a swamp if we 
> start at supporting multiple attributes.

Bandwidth is just one of the attributes. Bandwidth is being discussed now.
And other QoS attributes would come to light shortly.
 
> > Also I am very surprised about the resistance to do this.  If we 
> > justify doing Credit Control over AAA why is this a problem?
> 
> I don't see the comparison, actually.  The Credit Control is 
> trying to standardized a token based approach for doing AAA 
> authorization. It is not standardizing (or at least trying to 
> carefully work
> with) billing models, etc.  

I agree with you and that is why I raised the question.  When I brought up
QoS, I did not intend for RADEXT to define new QoS attributes but rather to
show how existing QoS parameter would be transported within AAA messages.
Whatever the QoS attributes are.

I think the disconnect is that you are thinking I want to define (new) QoS
attributes and/or (new) QoS models.  I don't want to do this at all.

Avi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>