Re: Subtypes (again) and other ideas

[Victor Gamov <vit@lipetsk.ru>]

Avi Lior wrote:
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] 
> > Sent: Tuesday, January 27, 2004 3:32 PM
> > To: 'Avi Lior'; 'Victor Gamov'; radiusext@ops.ietf.org
> > 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. 

Hi gentlemen!

I'm really sorry, that I was absent for a long time

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

I red this pecifications and now I have new ideas about our problem.

1. I think that we need to use VSA with Vendor-Id=0 (standard RADIUS) to 
extend standard RADIUS attributes space.  It's very possible that 
current attribute space will be exceed in future.

2. New attribute type from still unassigned attribute space with 
following format to extend Service-specific attributes:

 0                   1                   2                   3
+---------------------------------------------------------------+
|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+-------------------------------+
|   Type (241)  |    Length     |        Service-Type           |
+---------------+---------------+-------------------------------+
|    Service-Type (cont)        |  String...
+---------------+---------------+---------------+---------------+

Type 241 for Service-Specific

Length >= 7

Service-Type = value of Service-Type attribute.
(We need to propose new Service-Type values for different services 
(Wi-Fi, LAN, PPPoE etc))

String may be in following format:

+---------------+---------------+---------------+---------------+
|          Extended-Type        |       ID      |Extended-Length|
+---------------+---------------+---------------+---------------+
|   Extended-Value...
+---------------+---------------+---------------+---------------+

Extended-Type -- type of service-specific attribute

ID -- random value from 0 to 255 to identify different service-specific 
attributes with equal Extended-Type in one packet

Extended-Length >= 5

Extended-Value -- Service-Type and Extended-Type specific value

Attributes with equal Service-Type, Extended-Type and ID MUST be 
concatenated. This allows Extended-Value longer than 245 bytes

3. When different applications need to share some attribute we can add 
it in RADIUS VSA (with Vendor-ID 0) attribute space after some 
discussions.  So item 1 is very useful for this.


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