(RADIATOR) Duplicate detection doesn't use source port
Hugh Irvine
hugh at open.com.au
Tue Sep 6 04:22:39 CDT 2005
Hello Surajh -
Here is an example:
<AuthBy RADIUS>
.....
UseExtendedIds
.....
</AuthBy>
See section 6.30.19 in the Radiator 3.13 reference manual ("doc/
ref.html").
BTW - the latest version is Radiator 3.13 (plus patches).
regards
Hugh
On 6 Sep 2005, at 18:08, Surajh Surjoo [ MTN - Innovation Centre ]
wrote:
> 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.
>
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.
More information about the radiator
mailing list