proxy question

[adrian.p.smith at bt.com]

That sparked off quite a debate!

Thanks everyone.

Adrian


-----Original Message-----
From: freeradius-users-bounces+adrian.p.smith=bt.com at lists.freeradius.org [mailto:freeradius-users-bounces+adrian.p.smith=bt.com at lists.freeradius.org] On Behalf Of Arran Cudbard-Bell
Sent: 07 February 2014 11:58
To: FreeRadius users mailing list
Subject: Re: proxy question


On 6 Feb 2014, at 18:55, Alan DeKok <aland at deployingradius.com> wrote:

> Arran Cudbard-Bell wrote:
>> Hm, ok I was wrong, it does always forward retries, it's only when 
>> the request is waiting to be processed or being processed by a worker 
>> that it ignores the retransmissions.
> 
>  Yes.  That was the subject of some debate in the IETF RADIUS working 
> group.  The proxy acts as a "pass through" device for retransmits.

I guess that's the root of the fragment reassembly debate.

>  But if the server is still working on the reqeust, the answer is 
> *unknown*.  So it can't proxy it, it can't respond, and it can't do 
> anything other than ignore the retransmit.

Yes.

>> Doesn't seem that's entirely sensible, or consistent, but ok...
> 
>  It's really the only choice.
> 
>  The server could do re-transmits itself.  It did that in version 1.
> But the code was complicated and fragile.   And the other people in the
> RADIUS WG though doing that would break things in the network.

I was more thinking about it in terms of the server imposing a cap on the retransmit rate.

I've had NAS go crazy and repeatedly spam the server with Auth and Acct requests, and it'd be nice to stop that craziness from accidentally DoSing the proxy chain.

>> But the status checks themselves will be retried.
> 
>  Because FreeRADIUS originated the packet, and is acting like a client.
> Clients do retransmits...

Sure. I was just clarifying Buxey's response. It was unclear whether the OP was asking whether retransmits of Access-Requests were performed when status-server checks were enabled, or whether the status-server messages were retransmitted.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org> FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2