RE: : RFC 4005 AUTH48 Review

Bernard,

> As I read the above recommendation, it boils down to the following:
> 
> a. Go ahead with Dave's separate document on translation of RFC 2865
> non-conformant VSAs.
> 
> b. Add text to NASREQ restricting the length of AVPs 1-255 OR add
> a header flag for use by RADIUS/Diameter gateways.
> 
> c. Consider an alternative Diameter/RADIUS interoperability mechanism,
> such as encapsulation.
> 
> IMHO, recommendations a and b are worth considering.  I would like to hear
> the opinion of WG participants on these items.
> 
> Item c is a more difficult issue.  Here are some thoughts.
> 
> From the very beginning RADIUS/Diameter compatibility has been one of the
> most difficult problems that Diameter has had to tackle.  The original
> Diameter proposals, based on UDP, were designed to tackle this problem by
> extending the RADIUS packet format in a backward compatible way.  However,
> because of IESG feedback, Diameter moved to reliable transport, and as a
> result, the "gateway" approach described in NASREQ was taken.
> 
> Having operated email "gateways", it has become painfully obvious to me
> that translating one protocol to another, particularly when that
> translation does not have perfect fidelity is not a viable long term
> solution.
> 
> As a result, I am sympathetic to Glen's point of view -- the gateway
> described in NASREQ is at best a temporary solution.  Given the continued
> evolution of RADIUS, it is very difficult to convince myself that it will
> remain viable for the medium term, let alone long enough to allow for
> large scale "Diameter only" networks to arise.
> 
> However, at the same time it is hard to argue that the NASREQ document
> should be held up pending development of a more viable approach to
> RADIUS/Diameter interoperability.
> 
> Therefore my recommendation is that only items a) and b) should be
> considered blocking for the publication of RFC 4005, and that c) be
> pursued in a separate document on RADIUS/Diameter interoperability.

I agree on this; this is what I understood was the game plan for a longtime;
that NASREQ could handle very general gatewaying issues, but not solve
everything.

I also think that we should go forward with point c. The implications for
this are that a simple "Use NASREQ to interwork with Diameter" will be
insufficient for on-going work in RADext; so that specific new RADIUS extensions
should have a short dicussion on how to interwork with Diameter.

thanks,
John