(RADIATOR) Duplicate detection doesn't use source port

Tue Sep 6 03:08:24 CDT 2005

Hi Hugh
I am forwarding the description onto our WAP gateway team to check if
they support it on their side.

Can you send me an example of how to add this to an authby radius
clause?

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Tuesday, 06 September 2005 9:23 AM
To: Surajh Surjoo [ MTN - Innovation Centre ]
Cc: Jonathan Kinred; radiator at open.com.au
Subject: Re: (RADIATOR) Duplicate detection doesn't use source port

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.

NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/disclaimer

--
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.