Robust Authentication Proxying

[Alan DeKok]

Philip Molter wrote:
> I did try that.  It did not do what I was attempting to do.

  Hmm... "it didn't work".

>  I am trying
> to patch with the algorithm I describe further on down.  Freeradius can
> offer a robust transparent internal failover OR the existing failure
> handling.  It is not an either/or scenario.

  As I said, I'm open to suggestions.

> I am not sure how you ever got the impression that the home server pool
> type has been set to anything but "load-balance".  It has been set to
> "load-balance" since the very beginning.

  I've been reading your messages.  It has *not* been clear that the
pool type was set to "load-balance".

> One way of accomplishing this (an algorithm as you have requested) is to
> realize that when the NAS does not get back a response, it will (if
> configured) retransmit the original request.  When the proxy does not
> get back a response from the home server it chose (after whatever length
> of time), it can fail out the home server, not send any response back to
> the NAS, forget that it ever saw the original request from the NAS, and
> when the NAS retransmits its request, the proxy will see it as a new
> original request, choose a new home server (the previous one has been
> failed out), and then hopefully the proxy will get a response from this
> new home server that it will pass back to the NAS.

  That's a good idea, but not really possible as-is.

> This requires relatively quick fail out of home servers, something which
> can already be configured.  It requires that the tracking hash of the
> original request packet and proxy be cleared.

  I'm not so sure.  For one, deleting the original tracking has is not
an option.  It's also not necessary.

  See the existing code for how requests can fail-over from one home
server to another *without* a problem.  The code already supports this.

>  Both of these can be
> enabled via an option, probably at the pool level, so that it does not
> change the behavior for existing configs, but adds this capability for
> people who want this kind of transparent failover.  However, I think the
> cleanest way to implement is to add a new Response-Packet-Type of
> (suggestion) 'Proxy-Clear-Response' that is treated like the above for
> proxied requests and is treated as 'Do-Not-Respond' if not used within
> the a post-proxy failure handler.

  I'm not sure that's necessary.

> Does that seem like a method that can work.  Again, not to replace
> anything but to supplement it?

  It's an *additional* method, rather than a *better* method.  It
requires additional code, additional state machine checks, and as
such... I'm biased against it.  It's just too much like a site-specific
hack for it to be integrated into the main distribution.

  Adding a *better* method is the preferred approach.  It's OK to change
existing behavior, so long as it's for the better.

> Many NASes can use an internal user cache as a backup to a
> non-responding or slowly-responding RADIUS server.  If the proxy returns
> a an actual Access-Reject, the NAS accepts that and says the request is
> invalid.  If the proxy returns nothing, the NAS can say, "Well, my
> RADIUS server is down, but I have this record for the same user/pass in
> my cache and previously, it received an Access-Accept.  Let me accept
> this request."  That does not break any RADIUS specifications I know of,

  Nonsense.  NASes that cache authentication credentials are
*completely* outside of the RADIUS specification.  It's like adding a
jet engine to a car.  There's no law *preventing* it, so it must be
legal, right?

> I hope my description above of the proxy forgetting the original request
> when it fails out a home server is an example of a different algorithm. 

  It's simple, and it can't work.  Re-processing duplicate packets from
scratch is simply not an option.

  Please explain *why* the suggested patch I had doesn't work.  What
does it do?  How does it behave differently than what you expect?

> Please tell me if the example I gave above is a good HOW.  I am trying
> to come up with a code-based solution today, but I am not nearly as
> familiar with the code as you probably are.

  The code can be safely ignored.  The algorithm depends on only a few
pieces of information:

	proxy
	home server
	various timeouts
	NAS retransmits

  If you can describe an algorithm based on that information, it can be
implemented.

  Alan DeKok.