[Serusers] avpops and ip based auth

[Greger V. Teigre]

I haven't really looked into the pike code, so you're loosing me. I just 
wanted to launch the idea.
What about the other approach, using usrloc? ;-)
g-)

Iqbal wrote:
> Hi
>
> Tks...I think the pike idea looks interesting, since it already has
> the cache mechanism built in, and as you said instead of blocking we
> would be allowing, in fact if I was to increase the density
> parameters to unlimited or something like that, there would never be
> a block ( I know this is a crude hack, but would help to test I
> guess). That way all IP would get cached, and hence not blocked, but
> by default allowed. the ru|n |pike_check_req(), it will always be
> positive, since we wont really hit the cache (oh in the code is there
> a max to the size of the cache, just to prevent some kind oof
> overflow), and if positive, then bypass the rest of the auth systems,
> by setting some flag. And of course increase the sampling time, if
> the IP do not change often,
> And then also increase remove_latency to keep the IP address in cache.
>
> thoughts ?
>
> Iqbal
>
> Greger V. Teigre wrote:
>
>> Iqbal,
>> Sorry for being slow, I have been travelling.
>>
>> I think what you are trying to do is sort of the pike module
>> upside-down ;-)
>> You primarily purpose is to reduce the authentication requirements on
>> INVITEs.  Now, if you use mysql as subscriber DB, the auth in itself
>> is not really that bad, it's a DB read.  It scales pretty well.
>> So, to accomplish your goal and in order to reduce the number of DB
>> hits, you need to find a way to avoid DB lookups alltogether.  avpops
>> will not do, it is probably not more efficient than an auth (probably
>> less because it is more generic).  Thus, you need to make a reverse
>> pike module where the IPs are cached using a hash.  Dependent on the
>> number of IPs you want to store, there will be added SER memory
>> requirements.  Also, you will need a way to expire the IP from the
>> auth DB.
>>
>>    BUT: Maybe you could use a new usrloc table for this?  NOTE: There
>> is (at least) one catch that prevents the following from working (see
>> further down):
>> For an unauthorized INVITE (see check below), first challenge the
>> user and authenticate, then on auth success, make sure that Contact
>> has a public IP (which you probably do anyway). You will have the
>> correct IP address in Contact. Then just save("ip_auth")
>>
>> INVITE check:
>> You can then check if the IP is registered by changing the ruri to
>> the IP address of the Contact and use if(registered("ip_auth")) to
>> check if the IP is registered. Then do revert_uri();
>>
>> Catch:
>> The username will prevent the registered("ip_auth") call from
>> working, it will not match.  However, if you could change the
>> username part of the Contact in the INVITE to "noone" or something
>> static before saving and restore it before forwarding, you will get
>> a usrloc table with: noone at a1.b1.c1.d1
>> noone at a2.b2.c.2.d2
>> ...
>>
>> You must then change username part of ruri to none before the call to
>> registered().
>>
>> I don't know how to do that without any code.  Anybody?!
>>
>> Mini-catch: You need to enable domain for usrloc, so if you use only
>> username, you have a problem.
>>
>> Mini-catch 2: I have not tried using save on an INVITE. I don't know
>> how much error checking is done.
>>
>> Hack? Oh yeah. But you reuse the memory cache of the usrloc and get
>> no DB hits...
>>
>> g-)
>>
>> PS! If you tried, it would be interesting to hear the results...
>>
>> Iqbal wrote:
>>
>>> Hi
>>>
>>> I am using trusted mainly for inbound routes from my gateway to ser
>>> for inbound calling via pstn numbers mapped to IP phones. (I do
>>> think that trusted module/pacth bound to gateways listed in lcr
>>> could be a good idea).
>>> Now what I am looking for is to take several devices/gateways and
>>> have them hit ser but ignore all auth i.e no user/pass combos, but
>>> just detect IP's. I think I can get them to all have external IP
>>> adds, which would remove the problems of private IP's being used by
>>> other devices.
>>> My main problem is resource usage in all the scenarios, minimum DB
>>> hits is obviously best, lets assume the gateway will initiate 10000
>>> calls
>>> (just to have alarge number :-)), and lets say all these calls are
>>> of 10 secs each, if I had to auth each call every time that would
>>> be a pain, however if I could auth once, and from there on in ,
>>> just let all calls pass, and re-check the auth every so often (lets
>>> say once per hour) then thats fine.
>>>
>>> In terms of billing it would be per gateway, but I would need to
>>> break down per call, which shouldnt be hard since they would all
>>> have diff destinations I guess.
>>>
>>> trying to find the best scenario for a one time auth system with
>>> miminal db lookups in it.
>>>
>>> iqbal
>>>
>>> Greger V. Teigre wrote:
>>>
>>>> I would say that as allow_trusted uses a cached (and I believe
>>>> hashed) list of IP addresses to match against, it is better suited
>>>> for non-(or low) dynamic data like trusted peers etc. avpops is
>>>> better suited for subscriber specific operations (as avpops will do
>>>> the DB every time) and thus larger number of IPs and dynamic data.
>>>>    Are you thinking about storing the IPs with avp_db_store for
>>>> each register and then just allow any IP you have stored?  This
>>>> would save you some DB cycles probably (and some SIP messages) as
>>>> you only do one lookup and no digest challenge for INVITEs.  You
>>>> would then allow anybody behind a given NAT and again IP-based
>>>> auth on UDP is not really secure.
>>>>    And of course, you would probably need a way to expire the IPs?!
>>>>
>>>> Or have I misunderstood completely? What are you trying to achieve?
>>>> g-)
>>>>
>>>> Iqbal wrote:
>>>>
>>>>> allow_trusted I already use, just wanted to know which is better,
>>>>> or is it just personal preference here. If either is used and
>>>>> looking by the acc table billing could still be pulled even
>>>>> thought no username/password..any inputs here.
>>>>>
>>>>> Iqbal
>>>>>
>>>>> On 6/23/2005, "Greger V. Teigre" <greger at teigre.com> wrote:
>>>>>
>>>>>> Have you looked at allow_trusted() in (I believe) the domain
>>>>>> module. In fact, when I come to think of it, maybe the functions
>>>>>> are undocumented. I'm on GPRS right now, but I'll check when I
>>>>>>    get back over the weekend. You populate the trusted table and
>>>>>> use allow_trusted() before auth of INVITE's (and probably assume
>>>>>> that you don't get REGISTERs). There is also a FIFO command to
>>>>>> reload the trusted table. I guess it's feasible to use REGISTER
>>>>>> to store a new IP after a successful auth and then use IP for
>>>>>>    INVITE's. Ref. an earlier discussion, using IP for UDP is not
>>>>>> really good security-wise, you should use TCP.
>>>>>> g-)
>>>>>>
>>>>>> Iqbal wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> If I use avpops for IP based auth, and drop the normal
>>>>>>> username/password combo aside from spoofing what is the downside
>>>>>>> if any. Also if I do IP based auth, can I auth once, and be done
>>>>>>> with it, or is it auth once per call, I guess its once per call,
>>>>>>> if so is there any way to bypass auth completely for a
>>>>>>> particular IP address, again I am assuming no, since the IP
>>>>>>> will still need to be checked for each request.
>>>>>>> Iqbal
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Serusers mailing list
>>>>>>> serusers at lists.iptel.org
>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>
>>>>>>
>>>>
>>>>
>>>> .
>>>
>>
>>
>> .