RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter

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

Stefan Winter <mailto:stefan.winter@restena.lu> scribbled on Friday,
April 25, 2008 7:20 PM:

> Hi,
> 
>> One thing that's wrong is that it ignores the limitations on the
>> RADIUS PDU that exist primarily (or solely) because of the UDP
>> transport.  One example: the maximum length of 4096 octets for a
>> Radius packet was chosen (IIRC) based upon the maximum size of a
>> _UDP_ frame that could be reliably transmitted w/o fragmentation _in
>> the access networks of the day_.  It doesn't seem to be very smart
>> to go to all the trouble of defining RADIUSoTCP while leaving this
>> kind of unnecessary, UDP-specific limitation in place.
> 
> You are perfectly right in condemning the number 4096. It was
> a limitation which was pretty much arbitrary. When using TCP,
> one wouldn't be forced to keep it if using the TCP transport _only_,
> from end to end. 
> 
> But giving up on this limitation would completely ruin
> translation back to RADIUS-as-in-2865. Which is a common use
> for existing RADIUS deployments where the NAS speaks RADIUS
> only. And from what I gathered in this discussion so far it is
> seen as being of paramount importance that this translation works.
> 
> I think I remember a discussion a while back about what to do
> with Diameter Accepts above 4096 Bytes, and how to build a
> translation agent that is able to turn this into RADIUS. IIRC,
> the outcome was that it isn't possible at all, and that an
> Accept which is too large has to be translated into a Reject.

"Impossible" is such an interesting word, especially when applied to
software ;-).  It's certainly _technically_ possible to do this with a
slight modification of the RADIUS protocol; what seems to be
_politically_ impossible is making the slight change.

> (the discussion took place when talking about NAS-Filter-Rule
> and the issue "Diameter-RADIUS gateway behavior not completely
> specified" in general) 
> 
> I definitely want to steer clear of this. Unfortunately, the
> only way of doing so is to stay with 4096. Maybe an option
> would be: if a deployment scenario can be *sure* to be free of
> plain RADIUS elements everywhere, it MAY use larger payloads.

That seems a bit Draconian: al that is necessary (without the minor
change mentioned above) is that RadSec gateways never forward an illegal
RADIUS packet to a RADIUS client or server (it's really very useful to
treat the two as distinct protocols).

...



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