RE: RADIUS V2

[Avi Lior <avi@bridgewatersystems.com>]

Bernard,

See comments below:

> As has been pointed out on this list, there are currently 
> quite a few "gotchas" in RADIUS/Diameter gateway operation.  
> For example, VSAs with "sub-attributes" are translated to 
> individual Diameter Vendor-Specific AVPs, rather than "Grouped" AVPs.

When you say "sub-attributes"  how are you defining sub-attributes?
As you know there was confusion surrounding this term.  I think it would be
helpful to use percise language here.
 
> It seems to me that Jari's proposal will improve the fidelity 
> of translation significantly, and make it quite a bit easier 
> to define attributes for both RADIUS and Diameter 
> simultaneously.  It also may allow for reuse of AVP 
> definitions in RFC 3588, NASREQ, Diameter EAP, etc., saving 
> considerable work (and text) in RADEXT WG documents.

I don't disagree with this.  But note that this is clearly a new RADIUS type
of attribute.  It will break existing code and specifically it will impact
what I call "base radius" that is, Policy Engines and Dictionary Parsers
etc. 

> Given the potential benefits, the proposal is definitely 
> worth serious examination.

I agree.  It would seem that one would consider this work if one had long
term prospects for RADIUS.  Since we are clearly "breaking RADIUS" what else
should we be looking at?

How about RADIUS reliability? Introduce a hearbeat mechanism and improve
accounting. Clearly a more pressing issue.

How about longer attribute lengths? -- as described before there is a need
for this and we see more evidence as we build more secure networks.



Avi

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