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. (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. But honestly, I'd prefer to keep it as simple and error-proof (as in: configuration errors) as possible and forbid larger payloads outright. Greetings, Stefan Winter P.S.: 4096 was the max "_in the access networks of the day_"? Anyone have a clue what that network was? Token Ring? -- 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.