Re: It's all in the timing...

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Wed, Aug 10, 2005 at 06:11:45PM -0400, Alan DeKok wrote:

> "Nelson, David" <dnelson@enterasys.com> wrote:
> > I have a general concern, or meta-issue, to raise regarding the WGLC of
> > draft-ietf-radext-ieee802-00.txt.  The VLAN, Priority and Filtering
> > Attributes draft proposes new RADIUS attributes of base data type String
> > (Octet String) that are, in fact, multi-field structures a.k.a. complex
> > data types.
> 
>   Like ARAP-Features, Login-LAT-Group, Framed-Appletalk-Link,
> Framed-Appletalk-Zone ...
> 
> > My frustration is that I don't see a good solution.  The Design
> > Guidelines for RADIUS Attributes must be given time to mature and obtain
> > consensus.  It does not seem reasonable to delay the VLAN, Priority and
> > Filtering Attributes draft until the design guidelines are ready.  I
> > guess the best I can hope for is that work on the design guidelines
> > progresses rapidly, and that any substantial disconnects between the
> > design guidelines and the VLAN, Priority and Filtering Attributes draft
> > can be reconciled before it goes out for IETF Last Call.
> 
>   Sure.
> 
>   I also have no objection to publishing the VLAN... draft without the
> benefit of the final Design Guidelines draft.  There are already
> complex data types in RADIUS attributes, so adding a few more
> shouldn't be a serious problem.

Seconded. I would also like to reiterate my plea for layering. 

Let's keep RADIUS to deal with big endian numeric and variable length
octet strings (possibly interpreted as UTF-8 if they need to be
displayed), and keep it at that.

Interpretation of values, applying boundaries and so forth should always
be done on a higher layer.

I thing we should not try and invent an ASN.1 for RADIUS or another
RFC2869 (creating a data structure by tying attributes together using a
tag, where the syntax of the pair (tag-value or just value) is dependent
of the value(!) of the potential tag (> 0x1f means no tag). Hackish
seems a nice word for that solution).

Let's keep the attribute field in the basic protocol a simple transport
for simple ordinals and octet strings, and build on that to do the rest.

The day that RADIUS requires some form of a DTD so that the protocol can
do part of the application's work of verifying the syntax of its own
input is the day that I quit my RADIUS work. If an application refuses
to check its own input syntax /at all cost/, have it use XML, not
RADIUS.

All types are /not/ created equal. Complex types belong on a higher
layer. It should be possible to parse a RADIUS packet using a simple
dictionary containing only name, number and 4 types, before passing it
onwards to an application, whether that's done through a database,
XML-RPC, SOAP, BEEP, HTTP GET, or whatever.

Of course, a recommendation for a field separator and escape method may
be useful if application developers are really incapable of coming up
with anything to use. I'd suggest something light weight, like HTTP's
request URIs (field1&field2&ben%26jerry).  If an application wants
fields to carry names, they can be encoded as var=value&var=value, again
as in HTTP.

I favour independent, simple layers and the KISS principle, especially
in security protocols.

If a proposal is being done to merely prevent another tagged attribute
invention for allowing simple sets, then I suggest either creating a
container attribute type that is to be parsed as the RADIUS attribute
field (ie. allowing it to contain a list of A/V pairs), or the HTTP
request URI approach given above. But, please, keep it /simple/ and stay
away from application specific types below the application.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

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