I'm in the process of pushing back some major changes to v3. It involves removing the 253-byte limit on the internal representation for attributes (i.e. VALUE_PAIRs). The changes were much less than I thought. They took only a day or so once I decided which approach to take. They also required "talloc", which explains why the change wasn't done up until now. The server can now support RFC 6929 "extended" attributes, without any pre-defined limitation on length. i.e. 4K certificates, etc. I'm in the process of sweeping through the code, and removing the rest of the length limitations. e.g. EAP-Message encoding / decoding, etc. As a bonus, the server can now represent *255* character DHCP options, which it couldn't do before. Arran and I are working on true support for nested TLVs. At that point, turning FreeRADIUS into a Diameter server isn't that hard. :) Alan DeKok.
hi, just wondering what happends when our FR 3 server with all this goodness and local configuration with massive attributes goes and sends such stuff to a pre 3.0 server or some other RADIUS server? alan
A.L.M.Buxey@lboro.ac.uk wrote:
just wondering what happends when our FR 3 server with all this goodness and local configuration with massive attributes goes and sends such stuff to a pre 3.0 server or some other RADIUS server?
Nothing. RFC 6929 *allows* for longer attributes. But since no one uses them, there's no issue. And the format is designed to be transparent to legacy servers. They just pass the attributes without looking at them. RFC 6929 also has text about how to do RADIUS properly. i.e. issues like the IAS nonsense with Operator-Name are now expressly forbidden. Alan DeKok.
On 6 May 2013, at 18:07, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
just wondering what happends when our FR 3 server with all this goodness and local configuration with massive attributes goes and sends such stuff to a pre 3.0 server or some other RADIUS server?
Nothing.
RFC 6929 *allows* for longer attributes. But since no one uses them, there's no issue. And the format is designed to be transparent to legacy servers. They just pass the attributes without looking at them.
RFC 6929 also has text about how to do RADIUS properly. i.e. issues like the IAS nonsense with Operator-Name are now expressly forbidden.
And for other attributes they'll be truncated at 253 bytes at encode time. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 06.05.2013 15:29, Alan DeKok wrote:
I'm in the process of pushing back some major changes to v3. It involves removing the 253-byte limit on the internal representation for attributes (i.e. VALUE_PAIRs).
Very nice! We have a use case where we need to get some blob from the database which is used by another (custom) module. Right now we are ok with the 253 byte limit, but it will not suffice forever. I even thought about splitting it into separate Attributes, which is ugly, so I'm glad this won't be necessary. Regards Jakob
Jakob Hirsch wrote:
Very nice! We have a use case where we need to get some blob from the database which is used by another (custom) module. Right now we are ok with the 253 byte limit, but it will not suffice forever. I even thought about splitting it into separate Attributes, which is ugly, so I'm glad this won't be necessary.
Yeah. It's just a "nice to have" feature. It doesn't affect day-to-day RADIUS attributes. But it makes the server much more forgiving. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Jakob Hirsch