[Serusers] avpops and ip based auth

[Greger V. Teigre]

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

Sorry about that. I'm sure the pike idea wasn't any more  thought through 
;-) In fact, the usrloc approach might reduce the coding requirements.

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

Yes, there are really quite a few things you wouldn't need.

> 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

Right, seems feasible.  If you are to hack the module, may I suggest that 
you create a new module and just base it on pike? I will be happy to allow 
it into the experimental directory ;-)
g-)


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