Subtypes (again) and other ideas

[Victor Gamov <vit@lipetsk.ru>]

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