Hi, > This is what you said: "...a RadSec to RADIUS gateway involves > terminating TCP, TLS, and forwarding the contents to RADIUS. If this > isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't > doing HTTP." A Diameter to RADIUS gateway involves terminating TCP (or > SCTP), TLS, and forwarding the contents to RADIUS. With the devil being in the detail: With RadSec to RADIUS, the incoming packet is already a RADIUS packet as soon as it is decoded from the TLS tunnel. There is no translation of the content. With Diameter to RADIUS, non-trivial translations need to be done, some of which can't even be done at all right now (Accepts >4096 bytes payload, AVPs with >253 bytes). We have yet to see a Diameter translation agent that can do bijective translations from one to another and back again (which I personally see as the holy grail of compatibility). I doubt we will ever. With RadSec to RADIUS, this is a triviality. Greetings, Stefan Winter > If you really think > that this is different from your HTTPS->HTTP example, perhaps it's > because you are conveniently ignoring the fact that HTTP is only defined > over TCP. However, one could just as easily argue that HTTP != HTTPS, > given the need for different port numbers... > > >> I don't think that I said anything about good or evil :-), but you > >> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & > >> that's not a problem. The problem would arise if someone claimed > >> that it was because, 'Well, you can build a gateway'. > > > > The protocols being transported on IPv4 can also be > > transported on IPv6. > > I really don't know how that is relevant. Dropping down a layer or 2, > the same protocols can be carried by both Ethernet & ATM. Are you going > to claim that they are somehow compatible (backward, forward or > upside-down)? > > > Similarly, UDP transport + RADIUS application > > protocol is... RADIUS. TCP transport + RADIUS application protocol > > is... RADIUS. > > I know that you have read RFC 2865 (probably more often than I), so you > know that there is no such thing as a standard "RADIUS application > protocol", defined w/o regard for the underlying transport. > > > The only way to call RadSec something other than RADIUS is > > if you say that FTP over IPv6 is not FTP. After all, FTP was > > for IPv4, > > I can't find any mention of IPv4 in RFC 959; it does mention TCP, > however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP > interoperate? These questions seem much more to the point, I think. > > > and IPv6 is a new-fangled transport... so FTP over > > IPv6 is not FTP... it's "magic". > > One more time: the version of IP being used is transparent & therefore > irrelevant to FTP. UDP transport is forever enshrined in RFC 2865, > however; maybe that's a bad thing, but it's true nonetheless. > > > 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/> > > -- > 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/> -- 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.