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

[Olle E. Johansson]

2 sep 2009 kl. 10.16 skrev Klaus Darilion:

>
>
> 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.
>
Well, I would not say this is about security, but it will make it work  
better. It's on my list.
Thanks for the feedback!

/O