[SR-Users] Kamailio as SBC

Ellad Yatsko eyatsko at ngs.ru
Wed Oct 24 21:11:00 CEST 2018 

Hello Alex!

1. First of all I'd like to apologize about my yesterday unwise notice. :-)

2. Regarding your paragraph 2 -> "Via ..." & "Supported: path"?
   And how to make Kamailio to "proxy" REIGISTER to upstream registrar
   (Asterisk - do you know it supports "path"? For a what degree does
   Asterisk follow "the letter of RFCs"?)?

3. Regarding "topoh" I will read, ok. As I remember MY config has something
     modparam("topoh", "mask_ip", "1.1.1.2")
     modparam("topoh", "mask_callid", 0)
   I think I will cope this by myself.. :-)

4. Yes, I know about "htable", I can complete it by myself. I familiar
   with this.

Thank you for your asnwers Alex.

Kind regards,
Ellad

> 23.10.2018 15:27, Alex Balashov пишет:
>> Ellad,
>>
>> The reason for the lukewarm replies is not a failure on the part of the
>> public to understand the detailed content of your request; you don't
>> need to "simplify" it for them by individuating the paragraphs. 
>>
>> The central obstacle is that you don't appear to understand that
>> Kamailio is a SIP proxy at the core. There is a well-defined mechanism
>> by which they relay various kinds of requests to user agents (UAs), and
>> this does not consist of capriciously "rewriting IP/UDP headers".
>>
>> In this sense, the valuable conceptual comprehension from so-called
>> "general words" precedes "eager and spirited implementation", and is the
>> reason why you have been encouraged to consider "general words".
>>
>> Having said that:
>>
>> 1. Kamailio can certainly relay REGISTERs to an upstream registrar;
>>
>> 2. This presents the problem of letting the registrar know that the
>> registrant has to be reached back through Kamailio as an adjacency, and
>> the solution to this is provided by the Path extension:
>>
>> https://tools.ietf.org/html/rfc3327
>>
>> This Path header is added to the REGISTER and serves a similar purpose
>> to the one served by Record-Route in dialog-forming requests; it shunts
>> all subsequent inbound requests to the registrant through Kamailio,
>> which removes the Path header and passes it on.
>>
>> 3. As a proxy, Kamailio will dutifully forward authentication
>> challenges back to the caller, as it will do with any final
>> transaction-disposing reply.
>>
>> 4. Proxies do not hide topology in the manner you propose, whether in
>> the context of forwarding registrations or for any other purpose. The
>> message headers will consist mostly of information populated by the user
>> agent that constructed the message, with a few additional bits of
>> information added by Kamailio to reflects its role in the process. This
>> is mainly in the form of an additional Via hop, a Record-Route, etc.
>>
>> Kamailio has a number of modules which can accomplish this in a somewhat
>> "unorthodox" manner:
>>
>> https://kamailio.org/docs/modules/5.1.x/modules/topoh.html
>> https://kamailio.org/docs/modules/5.1.x/modules/topos.html
>>
>> However, these are used mainly for security-motivated topology
>> concealment relative to third parties. The problems invited by these
>> approaches are certainly not worthwhile for use inside one's own
>> network.
>>
>> 5. A REGISTER flow is not a dialog. The term "dialog" has a very
>> specific meaning articulated in 3261 § 12. 
>>
>> In core SIP, and notwithstanding subscribe/notify or any other
>> extensions, only INVITEs are dialog-forming requests.
>>
>> 6. There is no need for Kamailio to maintain - to "remember" or
>> "memorise" - any state for this flow. It can take part in an entirely
>> stateless way.
>>
>> 7. The 'htable' module, as suggested by others, is the best way to
>> implement any sort of temporary IP banning. Otherwise, log the offending
>> IP via xlog() and have fail2ban deal with it.
>>
>> -- Alex
>>
>> On Tue, Oct 23, 2018 at 12:30:03PM +0300, Ellad Yatsko wrote:
>>
>>> Ok. Let's divide overall task onto several little steps.
>>>
>>> I. How to implement the following:
>>>    - when Kamailio receives REGISTER from user in the Internet
>>>    - Kamailio rewrites IP/UDP headers - it acts with Asterisk on behalf
>>> of User, Asterisk should know just Kamailio IP (add "Via"?)
>>>    - Kamailio remembers [somehow] this dialog (how?) and
>>>    - retransmits REGISTER to Asterisk
>>>    - on receiving Unauthorized Kamailio retransmits it to User - this is
>>> an intermediate step, no action needed
>>>    - User repeats steps on Registration with the Nonce
>>>    - on receiving OK [from Asterisk] for the memorized dialog Kamailio
>>> retransmits OK to User and composes User Location
>>>    - on receiving NOT FOUND, FORBIDDEN, etc Kamailio retransmits SIP
>>> answer to User and after several unsuccessful attempts blocks User IP
>>>    - Fail2Ban completes the rest - inserts new rule
>>> Every time Kamailio retransmit SIP packet to the User from Asterisk it
>>> HIDES topology (IP/UDP headers and all SIP-related Info from SIP
>>> Packets). User should know just about Kamailio as about its counterpart.
>>>
>>> How to track SIP REGISTER related messages inside Kamailio?
>>>
>>> TO: Yu Boot - is it "standalone" implementation? How do you think? :-)
>>>
>>> Kind regards,
>>> Ellad
>>>
>>>
>>> 22.10.2018 20:16, Yu Boot пишет:
>>>> I can help you with cfg, if you 're ready to implement standalone
>>>> softswitch on your Kamailio :)
>>>>
>>>>
>>>> 22.10.2018 17:21, Ellad Yatsko пишет:
>>>>> May you help?.. :-)
>>>>>
>>>>> Kind regards,
>>>>> Ellad
>>>>>
>>>>> 22.10.2018 17:12, Alex Balashov пишет:
>>>>>> I did not say that my article represents a complete answer to every
>>>>>> part
>>>>>> of every one of your questions, at every level of abstraction and
>>>>>> specificity. Just that it might be helpful. :-)
>>>>>>
>>>>>> On Mon, Oct 22, 2018 at 04:40:03PM +0300, Ellad Yatsko wrote:
>>>>>>
>>>>>>> Dear Alex,
>>>>>>>
>>>>>>> your article is just "general words". :-) There is a couple of
>>>>>>> questions:
>>>>>>>
>>>>>>>    - can my "vision" be completed?
>>>>>>>    - how can it be implemented?
>>>>>>>
>>>>>>> The major problem as I see is to modify algorithm so Kamailio will
>>>>>>> not check
>>>>>>> database but will lean on answers of its upstream to generate
>>>>>>> UL. It should not BALANCE, just forward SIP traffic, ANALYZE
>>>>>>> answers of
>>>>>>> Upstream
>>>>>>> SIP-Server, make decision about attacks and PROXY RTP. It should be
>>>>>>> more
>>>>>>> clear
>>>>>>> definition what I would like to achieve.
>>>>>>>
>>>>>>> I could be confused about exact terminology of "Session Border
>>>>>>> Controller".
>>>>>>> But I'd like to implement FRAUD/BruteForce protection of my
>>>>>>> Asterisk using
>>>>>>> Kamailio (in the middle) because I heard it highly effective in the
>>>>>>> point
>>>>>>> of view of heavy loads. Asterisk might not bear a "tons" of SIP
>>>>>>> requests
>>>>>>> (dialogs).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Ellad
>>>>>>>
>>>>>>>
>>>>>>> 22.10.2018 12:07, Alex Balashov пишет:
>>>>>>>> I hate to plug my own articles, but in this case it might help:
>>>>>>>>
>>>>>>>> http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Sent from mobile. Apologies for brevity and errors.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ellad Yatsko <eyatsko at ngs.ru>
>>>>>>>> To: sr-users at lists.kamailio.org
>>>>>>>> Sent: Mon, 22 Oct 2018 3:28 AM
>>>>>>>> Subject: [SR-Users] Kamailio as SBC
>>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> I'd like to implement the following diagram:
>>>>>>>>
>>>>>>>>   Users  -> Internet -> Kamailio -> Asterisk
>>>>>>>>
>>>>>>>> 1. Kamailio has no own users, it just re-writes headers and re-send
>>>>>>>> REGISTER messages to Asterisk where usres are located.
>>>>>>>>
>>>>>>>> 2. Depending on Astersisk's answers Kamailio either form UL (using
>>>>>>>> original IP from the first, original REGISTER from Users) or
>>>>>>>> translates
>>>>>>>> Asterisk's answer back to Users. If it is error (e.g.
>>>>>>>> forbidden/notfound) Kamailio blocks User's IP (for instance using
>>>>>>>> pike
>>>>>>>> module) and Fail2Ban adds affected IP into IPSet's List to block
>>>>>>>> it by
>>>>>>>> IPTables Permanently.
>>>>>>>>
>>>>>>>> 3. INVITEs are translated to Asterisk as to the only Upstream
>>>>>>>> SIP-Server. And again Errors from Asterisk are processed in the
>>>>>>>> same way
>>>>>>>> as Bad REGISTERs. Pike in conjunction with IPSet/IPTables block
>>>>>>>> affected
>>>>>>>> IPs.
>>>>>>>>
>>>>>>>> 4. Astersisk sees all registrations from Internet user as they are
>>>>>>>> directly behind Kamailio. Kamailio rewirtes headers twice: from
>>>>>>>> Users to
>>>>>>>> Asterisk and from Asterisk to Users - this allows to hide topology
>>>>>>>> from
>>>>>>>> users (they deal ONLY with Kamailio) and block non-static IPs on the
>>>>>>>> Asterisk's side.
>>>>>>>>
>>>>>>>> Is this possible?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Ellad Yatsko
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Kamailio (SER) - Users Mailing List
>>>>>>>> sr-users at lists.kamailio.org
>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Kamailio (SER) - Users Mailing List
>>>>>>>> sr-users at lists.kamailio.org
>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>> _______________________________________________
>>>>>>> Kamailio (SER) - Users Mailing List
>>>>>>> sr-users at lists.kamailio.org
>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

More information about the sr-users mailing list