[asterisk-dev] Pinetree :: For Asterisk SIP trunks behind a SIP proxy

Klaus Darilion klaus.mailinglists at pernau.at
Wed Sep 2 03:16:38 CDT 2009



Olle E. Johansson schrieb:
> 1 sep 2009 kl. 16.22 skrev Klaus Darilion:
> 
>>
>> Olle E. Johansson schrieb:
>>> Hackers!
>>>
>>> In the middle of the debate about peer matching, I'm adding another
>>> recipe to the pot: Peer matching behind a SIP proxy.
>>>
>>> Many of us implement asterisk behind SIP proxys for load balancing or
>>> failover or both. That means that all messages to Asterisk is sent by
>>> the proxy and all peer matching on IP/port fails. Asterisk simply
>>> doesn't know how to separate the devices behind the proxy.
>>>
>>> With my new code, you can add a rule to the SIP proxy [peer] section,
>>> saying "don't match me, match who sent to me". The way Asterisk does
>>> that, is by reading the second VIA header. This is the device that
>>> sent the message to Asterisk - another proxy or an endpoint. You can
>>> also be very strict and say "match last via" - which always will be
>>> the other endpoint.
>> Hope this uses "received" and "rport" param, as Via is easily  
>> spoofable
> 
> Well, it's always a matter of who you trust, right. I did not choose  
> that approach, but it's an interesting addition.
> Anything is spoofable, so you want authentication at ingress point to  
> check who's spoofing what :-)

But it is common behavior of SIP proxies to not validate the IP:port in 
the Via header because if it differs from source IP:port the "received" 
and "rport" headers will be added - and also must be used for response 
routing.

Thus, an element "behind" the SIP proxy should always use the 
received:rport address as the other one can be spoofed or ist just wrong 
anyway (e.g. several clients behind NAT with
   Via: SIP/2.0/UDP 192.168.0.2:5060;branch=3442;received=..;rport=..
will cause confusion anyway)

Please as received and rport (if available) to make this feature secure.

regards
Klaus



More information about the asterisk-dev mailing list