I've just committed patches that enable TCP transport in the server. It was previously off by default. The code is a lot cleaner than the previous attempt, and (not surprisingly), smaller and easier to understand. It should provide all of the functionality of 2.1.7, plus TCP transport for high load systems. If anyone has spare cycles to check the usual edge cases, that would help a lot. Alan DeKok.
Hi,
It should provide all of the functionality of 2.1.7, plus TCP
regarding this - a new feature of 2.1.7 related to the DF bit for the UDP packets. I believe that the change meant that the do not fragment bit was changed to be set - was any regard to this being default, rather than configurable, given - I suspect several people might fall foul of this issue when they try throwing 1500 byte EAP packets across their WAN....... alan
Alan Buxey wrote:
regarding this - a new feature of 2.1.7 related to the DF bit for the UDP packets. I believe that the change meant that the do not fragment bit was changed to be set - was any regard to this being default, rather than configurable,
Most systems destroy fragmented UDP packets. Setting the DF bit won't change that.
given - I suspect several people might fall foul of this issue when they try throwing 1500 byte EAP packets across their WAN.......
Yup. If there are complaints, we can make it configurable. Alan DeKok.
Hi,
regarding this - a new feature of 2.1.7 related to the DF bit for the UDP packets. I believe that the change meant that the do not fragment bit was changed to be set -
No, it *unsets* the bit. Linux sets it by default, and in effect, can cause large packets to be discarded if MTU decreases on the link somewhere. Unsetting it gives at least a good chance that routers *can* fragment the large packet if need be. Unless your routers are broken of course.
was any regard to this being default, rather than configurable, given - I suspect several people might fall foul of this issue when they try throwing 1500 byte EAP packets across their WAN.......
It is meant to help these people :-) Stefan
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi,
No, it *unsets* the bit. Linux sets it by default, and in effect, can cause large packets to be discarded if MTU decreases on the link somewhere. Unsetting it gives at least a good chance that routers *can* fragment the large packet if need be. Unless your routers are broken of course.
ah cool - so its the right way around. so long as their iptables etc isnt set to drop fragmented UDP (which is common - and default on a Solaris box IIRC) alan
Stefan Winter <stefan.winter@restena.lu> wrote:
regarding this - a new feature of 2.1.7 related to the DF bit for the UDP packets. I believe that the change meant that the do not fragment bit was changed to be set -
No, it *unsets* the bit. Linux sets it by default, and in effect, can cause large packets to be discarded if MTU decreases on the link somewhere. Unsetting it gives at least a good chance that routers *can* fragment the large packet if need be. Unless your routers are broken of course.
Tell me if I am being stupid, but why don't we just crank down the MTU for IPv4 traffic to 576 (for IPv6 this should not be necessary IIRC as userspace should be informed if the packet is too large...but them with DF it should too for IPv4, right?)? The only time I have seen any MTU related problems is with our useless Cisco WLC 4400 that sulks if it receives any packets larger than 1300 bytes... Fragments on networks should always be avoided, I understand crypto packed traffic (EAP and isakmp for example) can end up knocking out fragmented traffic but surely there is no harm in trying to persuade them not to be formed. Is there something about EAP that prevents payloads being spread across several EAP-Messages? Apologies for not munching the RFC's, but they do not exactly make for light bedtime reading :) Cheers -- Alexander Clouter .sigmonster says: He is the best of men who dislikes power. -- Mohammed
Alexander Clouter wrote:
Stefan Winter <stefan.winter@restena.lu> wrote: Tell me if I am being stupid, but why don't we just crank down the MTU for IPv4 traffic to 576
NFS performance on local links will become horrible. File copies on local links will become horrible.
Is there something about EAP that prevents payloads being spread across several EAP-Messages? Apologies for not munching the RFC's, but they do not exactly make for light bedtime reading :)
Certificates. They can be many kilobytes long, and most ethernet can only handle 1.5K packets. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
Stefan Winter <stefan.winter@restena.lu> wrote: Tell me if I am being stupid, but why don't we just crank down the MTU for IPv4 traffic to 576
NFS performance on local links will become horrible. File copies on local links will become horrible.
Well, I understand that, but I am guessing not everyone runs an NFS server or client on their FreeRADIUS boxen...
Is there something about EAP that prevents payloads being spread across several EAP-Messages? Apologies for not munching the RFC's, but they do not exactly make for light bedtime reading :)
Certificates. They can be many kilobytes long, and most ethernet can only handle 1.5K packets.
Should have made clearer that I asking "payload being spread across several packets" rather than "why do EAP packets need to be large". Nevermind. -- Alexander Clouter .sigmonster says: I'm a fuschia bowling ball somewhere in Brittany
Hi,
Should have made clearer that I asking "payload being spread across several packets" rather than "why do EAP packets need to be large".
You can control the amount of EAP Bytes to be transferred in one RADIUS message from server to client (eap_fragment_size). Setting it lower will avoid fragmentation on most scenarios. But not deterministically: an itnermediate proxy may add more attributes to its liking, so your packet can still grow beyond the local frag size limit at that point. The second uneasy scenario: if you use EAP-TLS, the *client* will send (potentially large) certificates itself. As the server operator, you have no control over supplicant EAP fragment size settings. In that case, the packet coming back from the client may need to be fragmented anyway. There's no real way to circumvent that (unless you have full control over the client side), which as a corollary means: make sure your infrastructure can handle fragments properly to be prepared. Unsetting DF is one part, having sane firewalls that treat fragmented packets in a dignified manner is another one. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 2009-09-24, at 4:10 PM, Alan DeKok wrote:
It should provide all of the functionality of 2.1.7, plus TCP transport for high load systems. If anyone has spare cycles to check the usual edge cases, that would help a lot.
mmm too bad Juniper doesn't support Radius over TCP. We have a couple of very high load NASes and it would definitely help to provide reliable auth/acct. actually...is there any NAS that support this yet? -Gabe
Gabriel Blanchard wrote:
mmm too bad Juniper doesn't support Radius over TCP. We have a couple of very high load NASes and it would definitely help to provide reliable auth/acct.
actually...is there any NAS that support this yet?
No. The only pieces of software that allow TCP transport are: Radiator (only TLS over TCP. I don't think that bare TCP is allowed) RadSecProxy (the same) FreeRADIUS It's not really recommended for NASes to use TCP, *unless* they have high loads. See RFC 3539 for details. What is "high load"? 100pps? 1000 pps? Alan DeKok.
On 2009-09-24, at 4:37 PM, Alan DeKok wrote:
It's not really recommended for NASes to use TCP, *unless* they have high loads. See RFC 3539 for details.
Yes I believe I've read about that already, maybe I'll have another look.
What is "high load"? 100pps? 1000 pps?
Sounds about right actually. Averages out at 100pps (we use Interim updates) and it can peak around 1000pps. Most of that load comes from users leaving their home routers on with an invalid username and/or password and hammering our NASes at about 3-4 attempts per second per user. Juniper (not sure about Cisco) has a fix to limit these kinds of "attacks" but it doesn't always work and due to the nature of our network we can't always find exactly who the user is. -Gabe
Hi,
No. The only pieces of software that allow TCP transport are:
Radiator (only TLS over TCP. I don't think that bare TCP is allowed)
Radiaotr can do, I think: Don't use the keyword "RequireTLS" in your ServerRADSEC clause. But I'm not in the office right now, and can't fact-check myself.
RadSecProxy (the same)
It can be configured to be built with TCP only in the latest version. Stefan
FreeRADIUS
It's not really recommended for NASes to use TCP, *unless* they have high loads. See RFC 3539 for details.
What is "high load"? 100pps? 1000 pps?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (5)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
Gabriel Blanchard -
Stefan Winter