RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

["Avi Lior" <avi@bridgewatersystems.com>]

Alan,

See inline. 

> -----Original Message-----
> From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf 
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 2:04 AM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: New Technical Issues RE: WG last call in 
> progress on VLAN/Priority Draft
> 
> "Avi Lior" <avi@bridgewatersystems.com> wrote:
> > I know about policy files and GUIs and XmL and auto code etc...
> 
>   Yes, I didn't mean to presume otherwise.  My point was that 
> we should separate binary code changes from configuration file "code"
> changes.  Binary code changes may be complicated and 
> expensive to deploy.  Configuration file changes can often be 
> done by end users who know little about the protocol or 
> implementation.

But alan, you cant go on the assumption that you will only accept
non-binary "code" changes.

Some attributes -- like the prepaid -- or mobile ip -- EAP --- require
complex algorithms to be executed.  I doubt you can do them via
configuraiton files.  Lets get real here.  What we are talking about is
adding a new Application to the AAA.


> > So whether I end up dealing with the attribute by pressing 
> a few gui 
> > buttons to add another If rule, or I have to insert a new 
> EAP method 
> > or Cryptography procedure do deal with the new attribute 
> --- its all 
> > code change.
> 
>   That statement really masks the fact that some code changes 
> are pretty trivial to do.  Adding new policies based on 
> recently updated dictionary entries is usually pretty 
> trivial.  Adding support for a new authentication algorithm 
> is usually non-trivial.

Exactly.
 
>   Dictionaries allow a much more common set of use-cases for "code"
> changes to be done trivially.  They follow the maxim of 
> "simple things should be simple to do".

Yes. I agree. But my parser in my product is very capable and can handle
more complex attribute structures then the other fellow.  So I can
restate your statement as "complex things should be simle to do"
 
> > In a very simple world yes you can live within the limits of your 
> > dictionaries but in more complex scenarios, you  have to roll some 
> > good old fashion  C compiler.
> 
>   Agreed.  That's why I said the dictionaries catch the 99% 
> common case, not 100% of the situations.

Lets be accurate here.  The dicitionary is about encoding and decoding
and very little about smeantics.

Semantics are handled by clever policy files which use the attribute to
compute some outcome.  The policy files are NOT standard in RADIUS.
Policy files are exectued by Policy Engines (which are NOT covered by
RADIUS).  Policy engines come in many flavours.  Some are simple and
some are complex.  For example, some may provide very simple parsing
capability and some support REGEX capabilities.  Some can execute script
code found in the policy file some can't.  Therefore "How far you can go
with your policy file -- depends on how much you were willing to invest
in your policy engine".

Where the policy engine stops is where you have to start adding code to
you RADIUS server.  In some cases adding code is expesive and in some
cases very simple.  It depends on how much you invested in you RADIUS
design.

The bottom line is this:
We ought not make descision based on how complex or simple it is to
handle an attribute.  That is nuts.

Rather we have to realize that RADIUS needs to support new Applications
with new attributes.  An entity that needs to use those attributes will
have to parse them.  Proxies that don't need to interact with them,
should be able to skip the attribute in the RADIUS packet.  This is done
by having the attributes hide within RADIUS "STRINGS".

Since the Application typically has to parse the attribute, it is not
necessary for the RADIUS dictionary driven code to be able to parse it.
RADIUS dictionaries don't need to parse the EAP-message.  We are all
comfortable with that.  Why are we worried about that now????

It would be nice though to have a standard way to encode complex
attributes.  But given that typically these complex attributes require
code beyond even the most complex policy engine then it is not necessary
to do so.

My original motivation for having a standard for complex attributes was
because people were encoding attribute using name value pairs such as:
in a String     address="24 oberon",phone="    ".  I wanted to stop that
because parsing these strings would slow every RADIUS server out there,
and it was wasting space.

Also I resent somewhat the push now is so much that it ignores what we
did a two years ago.  Based on discussion it was Jari who proposed
encoding RADIUS attributes using Diameter syntax (I seem to recall that
one of you guys were taking credit for that).

I think any other coding scheme is nuts and we should just move on with
diameter encoding.  Unless of course  there is already working code as
in the case of Prepaid.
 
>   Alan DeKok.
> 
> 

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