RE: Subtypes (again) and other ideas

[Avi Lior <avi@bridgewatersystems.com>]

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

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