Robust Authentication Proxying

[Alan DeKok]

  I think there's a fundamental disconnect here.  I'm trying to explain
that RADIUS is an imperfect protocol.  You're trying to find ways of
configuring FreeRADIUS to be work around those imperfections.

  My suggestions are:

 1) realize that RADIUS is imperfect.  If a home server fails, there
will *always* be a request that is lost, rejected, timed out, etc.  The
client WILL fail authentication and disconnect the user when this
happens.  This is how RADIUS works.

  2) proxy fail-over DOES work in the server.  Maybe not exactly the way
you want... but I recall asking you for specific suggestions as to how
to make it better, and getting... not much.

  3) If you want to try source code mods, go to src/main/event.c.  Look
in the function no_response_to_proxied_request().  Find the line:

	post_proxy_fail_handler(request);

  Delete it.  Re-compile && re-install radiusd.  Then try the fail over
tests again.  It SHOULD cause fail-over to backup home servers for one
request.  Do NOT configure the "do_not_respond" policy.  Try setting
"response_window = 5" and "zombie_period = 5".

  4) Try setting the home server pool type to "load-balance" (again, as
I have suggested).  It WILL still fail over from one server to another.
 But the "load-balance" portion will spread the load MUCH more evenly
across all home servers, and there will be FEWER failed requests when a
home server dies.

  I hope those suggestions will be followed.  They are your best hope
for resolving this issue.

  And now for a detailed response to the rest of your comments.

> Yes, if the NAS sends another separate request with a different ID, it
> will be proxied to a different home server, but that does not help the
> poor guy who had the hard luck of his request hitting the bad home
> server.  He will get an error message.  He will have to retry or call
> support or whatever.

  The suggestions above will help.  The code changes MAY help.

  If you want the users to always get a response, ensure that there are
never any failures in your system.  No amount of poking FreeRADIUS will
fix the problem that home servers go down.

> Yes, a subsequent, different request will go
> to a different home server, but, again, I want to use the proxy to
> provide smarter resiliency across a pool of servers.

  So... use "load-balance", as I suggested.  That can provide a slightly
better response in some situations.

> I guess I do not see those as negatives.  That is exactly what I want to
> happen.  RADIUS network traffic is tiny.  The system load created by
> sending multiple requests to a home server or a bunch of home servers is
> minimal. I am not seeing how you are adding any more load when instead,
> the proxy sends back an Access-Reject, which, in the best case scenario,
> will result in the end-client re-authenticating, generating yet another
> request.

  You will be sending packets to TWO home servers, rather than one.
This might be fine in your situation.  It is definitely not fine in
other situations.

  FreeRADIUS is designed to work in a wide variety of environments.
This means that it might NOT work exactly the way you demand.  The
solution is simple: you have source code.  Fix it.  If we add a fix that
will make *your* situation work, it is likely to break *other* peoples
networks.

  We can't take that risk.

> Your argument that the RADIUS server cannot handle a retry does not hold
> water to me, 

  That isn't what I said.  That's part of the disconnect in communication.

> Okay, AT BEST you get 3-6 different home servers in a 30-second period. 
> Right now, AT BEST I get 1.  Which method is more resilient?  Which
> method results in no false rejections being returned to the NAS?  

  Which method is working in 100,000 deployments?

  You should note that I asked you for *specific* suggestions for a
better algorithm.  Your response was "I want it to fail over sooner".
That is unhelpful.

  If you are so set on demanding something better, then offer *concrete*
suggestions for how to fix it.  Look at the code.  It's available,
commented, and reasonably clean.

  Come up with a *better* method, and we'll implement it.  The current
repetition of "it's bad and I want it to work differently" isn't useful.

>  I have my NASes configured to retry for
> up to 60 seconds, once every 2 seconds.  They will retry 30 times.  It
> is more important to me that authentication requests succeed, even if
> they succeed slowly.  It sounds to me like freeradius is making
> assumptions about how NASes should work, and as a result, reducing the
> flexibility it provides.

  That's what "max_request_time" is for.  If your NAS is retransmitting
for 60 seconds, set "max_request_time" to 60 or 62 seconds.

>>  If you want the proxy to fail over, send it more than ONE request at a
>> time (like a normal proxying system), and do NOT configure the "do not
>> respond" policy.
> 
> So my NAS now has to send two separate requests for the same
> authentication, and pick the one that does not come back with an
> Access-Reject?

  That is not what I meant.  You seemed to be claiming that it NEVER
failed over.  I pointed out that it does fail over, and gave an example
of when  and how it fails over.

> Again, I am not arguing that the proxy will not fail over.

  Well... that wasn't at all clear from your messages.

> To a NAS, there is a big difference between a timeout and a reject.  If
> it does not get a response, a NAS will typically handle the client
> differently than if it gets an explicit rejection.

  Huh?  How?  Will it accept the user?  Will it let them in?  Will it
give them some "minimal" service, even if they weren't authenticated?

  That violates all RADIUS specifications, best practices, and network
security guidelines I'm aware of.

>  Right now, a timeout
> event from the home server results in an explicit rejection (unless I
> configure it not to send that reject).  It IS possible to get the number
> down to zero, because I have used RADIUS software that does it.  The
> only time it should ever be non-zero is if all home servers that can
> possibly be tried in a given window (which might not be all of them, but
> is most likely going to be more than one of them) fail to respond.  Like
> I said, I am trying to migrate to freeradius for some other features.  I
> have used two other proprietary RADIUS server software packages that
> implement this behavior.

  Well... offer *specific* suggestions for changes to FreeRADIUS that
will help implement this.  Try the suggested patches, and see if they help.

> I also understand that Accept-Challenge can complicate the proxying, but
> that is solvable as well with standard state tracking.

  That I disagree with.  EAP makes re-routing proxied Access-Challenges
pretty much impossible. (Except in certain rare situation)

> I know that networks are imperfect.  The answer to that imperfection is
> to retry, not to give up.  When you tell a NAS that the request has been
> rejected when, in fact, it has not, you are not effectively retrying. 
> You are saying, "Do not retry.  You actually got this failed result."

  No.  That's *your* NAS behavior.  Most NASes authenticate end users,
who will hit the "connect network" button again when something fails.

  This is another cause of the miscommunication.  It seems that your
NASes behave *very* differently from standard RADIUS NASes.  They treat
timeouts as "re-try authentication".

  But.. if they behave that way, why did they time out in the first
place?  Why not just set the timeouts to infinity?  That way
authentication will *never* fail.

> But look, I have gone through the code.  Ivan's right, that there is no
> way to get the behavior I want in freeradius without either a module
> (not sure if this is even possible to accomplish via a module because
> proxying is not handled via a module ) or by hacking the code to change
> how proxy no-responses are handled.  It just frustrates me that you
> challenge the value of this.

  Nonsense.  I asked *specifically* for suggestions as to a better
algorithm.  I'm refusing to implement a vague and poorly defined
suggestion.  That shouldn't be a surprise.

  Come up with a well-defined algorithm that's better than the current
one, and we'll implement it.

>  For people like me who use freeradius not
> to serve dial gear but to serve as robust authentication platforms for
> on-network services, where sending a false rejection to a client is an
> SLA issue, having a proxy that can robustly and transparently handle
> transient network failures is very valuable.  With that, we do not have
> to reprogram or replace NAS software (some of which we cannot control)
> to handle those kinds of transient network failures for us.

  I understand that.  Please also understand that it doesn't help to say
"make it better... I don't know HOW, but you guys need to make it better".

  We can't implement magic.  We CAN implement concrete suggestions.

  Alan DeKok.