RE: Consensus Call on RADEXT WG re-charter

["Glen Zorn" <glenzorn@comcast.net>]

Stefan Winter <mailto:stefan.winter@restena.lu> scribbled on Tuesday,
April 15, 2008 1:07 PM:

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

I don't know how we got started down this path of arguing about the
complexity of building protocol gateways; my point is that if the only
way for two protocols to interoperate is through a gateway, those
protocols _are not_ compatible except in the most trivial of senses,
like ATM & Ethernet or IPv4 & v6 or RADIUS and RadSec.  Therefore, stop
claiming backward compatibility if for no other reason that it's
embarrassing to associated with such a nonsensical claim.

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



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