Hello, It seems that since version 3.2.6, Freeradius always sends the Message-Authenticator AVP, as discussed in the thread below (I did search the conference, but did not find anything more relevant). I have upgraded the freeradius version on the server this weekend, and I have number of customer complaints whose obsolete BRASes fail to process replies containing the M-A AVP. Hence, I would need to selectively remove them from the replies - I tried to do it via the update-reply in the post-auth section of the configuration update reply { Message-Authenticator !* ANY } , but examining the packets via radsniff, the replies still do contain the M-A AVP. Could you please kindly advise on how to best remove the M-A attribute via the server configuration? Thank you very much in advance. -- Regards, Daniel Ryšlink Dne 19-Sep-24 v 13:27 Alan DeKok napsal(a):
On Sep 19, 2024, at 4:21 AM, Bjørn Mork via Freeradius-Users<freeradius-users@lists.freeradius.org> wrote:
Unsurprisingly, many router vendors are still trying to implement the BlastRADIUS recommendations in their RADIUS clients. With "interesting" effects as a result. Vendors are "special". There was one I found which would discard packets which contained Message-Authenticator.
Why? "It's unexpected". <sigh>
I got a complaint yesterday that vendor A now requires M-A in the Accept-Accept, or the session is rejected. I guess that's good. We were running 3.2.2 on the servers in question. An upgrade was obviously long overdue in any case, so I upgraded to 3.2.6. And everything was fine. For several minutes.
Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work! :(
How are we supposed to handle real world vendors like that? It would be nice to have some fine grained M-A enable/disable knobs. E.g. by client or account (virtual internal attribute?). By client will not work well for proxied requests, so that's probably not sufficient. Vendors should just fix their products. It's not hard. Message-Authenticator has been defined for 20+ years. It's not rocket surgery.
Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter). Arg.
I _really_ don't want to add more configuration flags to work around broken vendor equipment. That kind of nonsense tends to hang around for decades, because vendors go "well, there's a flag to work around it, so we don't have to fix our products!"
I'll see if there's a good solution, but I suspect not. If vendors could ship products which aren't garbage, that would be great...
Alan DeKok.
- List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html