(RADIATOR) Duplicate detection doesn't use source port

[Hugh Irvine]

Hello Jonathon -

You will need to make the code changes and then do some testing.

As mentioned, we need to know what Cisco actually does when sending a  
duplicate.

I have a vague recollection that we have been down this path  
previously, but that every radius request sent by the Cisco used a  
different source port which made it impossible to do duplicate  
detection anyway. Please let us know the results of your testing and  
we'll consider your modifications.

regards

Hugh


On 6 Sep 2005, at 14:51, Jonathan Kinred wrote:

> Hi Hugh,
>
> I will see what i can do regarding the information from Cisco.
>
> In the meantime i have found that the number of source ports is  
> only 200, i had previously been informed that it was in the 10's of  
> thousands :). So i think the potential memory usage per NAS would  
> be 200 ports x 255 identifiers x 2 request types x sizeof(RecvTime)  
> which is ok for us.
>
> Saying that, we'd have to hack the Client.pm code to extend the  
> RecentIdentifiers hash to include a source port:
>
> From:
> $self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$code.$p- 
> >identifier}
>
> to:
> $self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$p-> 
> {RecvFromPort}}->{$code.$p->identifier}
> or:
> $self->{RecentIdentifiers}->{$p->{RecvFromAddress}.$p-> 
> {RecvFromPort}}->{$code.$p->identifier}
>
> We're not that keen on tracking this change through radiator  
> versions so ideally we'd like to see an option like  
> DupSourcePortCheck which turns this on.
>
> What do you think?
>
> Jonathan
>
>
> Hugh Irvine wrote:
>
>> Hello Jonathon -
>> If you can find out from Cisco how they indicate that a  
>> particular  request is a duplicate when extended source ports are  
>> turned on, we  will be only too happy to implement their  
>> algorithm. Note that the  RFC does not cover the case of different  
>> source ports for each  request. In the absence of any other  
>> information, setting DupInterval  0 is your only option in the  
>> Radiator configuration file (or  NoIgnoreDuplicates for finer  
>> grained control).
>> regards
>> Hugh
>> On 6 Sep 2005, at 11:43, Jonathan Kinred wrote:
>>
>>> Hi,
>>>
>>> During testing we discovered that the source port of a request  
>>> is  not taken into account for duplicate detection. With the  
>>> default  DupInterval of 2 seconds this means that Radiator will  
>>> start  ignoring packets as dupes when a NAS sends more than ~128  
>>> requests  per second. We are using a Cisco SSG and want to turn  
>>> on extended  source ports, so we're definitely going to run into  
>>> the excessive  memory problem below.
>>>
>>> I'm wondering if there is a more elegant way for Radiator to  
>>> handle  this rather than breaking the RFC and not using the  
>>> source port. I  am thinking along the lines of having requests  
>>> purged from the  RecentIdentifiers hash when they exceed  
>>> DupInterval. It sounds like  an expensive operation but as i see  
>>> it our only option for these  NAS's is to enable  
>>> NoIgnoreDuplicates or live with the 128 per  second limit.
>>>
>>> I'd also like to hear if someone has a better solution using the   
>>> current Radiator versions.
>>>
>>> -- 
>>> Jonathan Kinred
>>> System Administrator
>>> Dot Communications
>>>
>>>
>>> Revision 3.6 (2003-04-14 Significant improvements to wireless  
>>> support)
>>> Client duplicate detection now ignores the source port, due to  
>>> some  clients (notably Cisco APs) using a different port for  
>>> every  request, resulting in excessive memory usage.
>>>
>>> Revision 2.16.2 (21/8/00) Minor fixes
>>> Duplicate checking now takes the client port into account, as   
>>> required by RFC 2865.
>>>
>>> -- 
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>>
>> NB:
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/ 
>> archives/ radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.