Hi, > If you go by the assumption, as reality pretty much dictates, that > RADIUS is not divorced from specific transport binding, then you should > be very cautious to avoid creating a heck of a lot of confusion > downstream from where we sit. For the last umpteen years RADIUS has been > RADIUS. True we have caused all sorts of havoc with attributes, but that > hasn't killed basic interoperability between RADIUS clients and servers. > This new effort would kill that basic interoperability. Therefore you > need to make very clear that the result of this work will NOT be > interoperable with the massive world-wide deployment of RADIUS clients. Well, if an implementation would do RadSec exclusively, and NOT listen on UDP/1812 as well, then yes, RADIUS clients would not be able to communicate with that implementation. Reality however is that all the implementations so far can do both, UDP/1812 and RadSec on TCP/2083, and are able to translate between both. Such implementations *are* interoperable with existing RADIUS clients. Since this is a (sane) behaviour by all implementations so far, it might be wise to add an according note to the RadSec I-D that: if interoperability with standard RADIUS clients is required, the implementation also has to listen on UDP/1812 (I used to think that goes without saying, but it certainly doesn't hurt to put that sentence in there). I wouldn't want to mandate this for all implementations as a MUST though, since I can easily imagine proxy interconnections in a backend that have no business with NASes, and for such deployments it would just be an unnecessary burden to mandate listening in UDP/1812. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Attachment:
signature.asc
Description: This is a digitally signed message part.