[Serusers] avpops and ip based auth

[Iqbal]

well I havent looked into usrloc :-) and i got lost, especially since 
you warned there it might not work.

I havent looked at pike, just the way it works, and your idea of 
reversing pike so that instead if giving a failure if too many in cache, 
I could just check to see if in cache, and then allow. i.e use pike for 
its caching ability as opposed to other stuff. The other params setting 
would be just so that it never really blocked...which its supposed to 
do, so i will just set them to a maximum.

the only problem I have then is that it would cache ALL ip addresses, 
how would I then limit it to only cache and check the IP's I want.

I was thinking of another kludge

if ip=a.b.c.d || ip = e.f.g.h { pike; setflag=2} that way only those get 
cached

then pike_check instead of any auth later on, so no db hits

iqbal





Greger V. Teigre wrote:

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