(RADIATOR) Duplicate detection doesn't use source port

[Hugh Irvine]

Hello Surajh -

Radiator now has an optional "UseExtendedIds" parameter for the  
AuthBy RADIUS clause which will allow Radiator to keep track of a  
much larger number of requests. This is done by using the "Proxy- 
State" attribute to carry a much larger number than can be carried by  
the Identifier field in the radius request header.

Perhaps you could talk to Ericsson about including optional support  
for "Proxy-State"?

You can try turning on "UseExtendedIds" in the AuthBy RADIUS clause  
to see if it makes any difference.

Please let me know what you discover.

regards

Hugh


On 6 Sep 2005, at 16:38, Surajh Surjoo [ MTN - Innovation Centre ]  
wrote:

> We use the Ericsson GGSN J20 towards RADIATOR and find that at  
> times of
> high load we also experience duplicate packets due to the same
> identifier being received in the same second.
>
> The Dupinterval was set to zero and this sorted out our problem,
> temporarily.
>
> We would also have the requirement to accept packets based on source
> address, and source ports and identifiers, in this way greatly  
> improving
> the capacity of RADIATOR.
>
> We now have a problem when proxying accounting requests to the WAP
> gateway. The high load causes the WAP gateway to receive "duplicate"
> packets and the WAP gateway then tends to swap THE msisdn received.  
> This
> makes it impossible to download your MMS messages as the auth then
> fails.
>
> Anyone, experiencing similar problems?
>
> Regards
>
>
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner- 
> radiator at open.com.au] On
> Behalf Of Jonathan Kinred
> Sent: Tuesday, 06 September 2005 6:51 AM
> To: Hugh Irvine
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Duplicate detection doesn't use source port
>
> 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- 
> >identifi
> er}
>
> 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?
>>
>>
>
> --
> 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.
>
>
> NOTE: This e-mail message is subject to the MTN Group disclaimer  
> see http://www.mtn.co.za/disclaimer
>


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.