[sr-dev] why new tcp connection?

[Olle E. Johansson]

6 nov 2009 kl. 14.54 skrev Klaus Darilion:

>
>
> Iñaki Baz Castillo schrieb:
>> El Viernes, 6 de Noviembre de 2009, Klaus Darilion escribió:
>>> Hi Juha!
>>>
>>> Personally I do not like the alias approach. IIRC correctly there  
>>> were
>>> some security issues with aliases (at least some time ago) and ser  
>>> does
>>> hand aliases a little bit different then described by IETF to  
>>> avoid this
>>> issues.
>> Could I know about those security issues? (just a brief description).
>
> I do not remember anymore in detail, but I think by spoofing aliases  
> (and the proxy accepts the spoofed alias) it could be possible to  
> intercept SIP messages which are targeted to another user/client  
> behind the same NAT.
>
>>> To solve the situation there are 2 other solutions:
>>>  1. in client
>>>  2. in server
>>>
>>> 1. client:
>>> The client learns the public socket during REGISTER (Via received 
>>> +rport
>>> in response) and changes its contact in REGISTER
>> What about if the server doesn't challenge the client? XDD
>
> No problem - at least for xlite. It does:
> 1. REGISTER with local socket
> 2. 407
> 3. REGISTER with local socket
> 4. 200 ok (learn public socket)
> 5. deREGISTER local socket
> 6. 200 ok
> 7. REGISTER with public socket
> 8. 200 ok
>
> I do not know how pjsip handles this (if it is smarter :-)
>
>>> and INVITE messages to
>>> the new one learned. This is for example what xlite and pjsip  
>>> does. This
>>> approach does not work if the client does not register - if it only
>>> sends INVITE then there is no learned socket available in the  
>>> initial
>>> INVITE.
>> If the client doesn't register then it cannot receive responses  
>> anyway.
>
> e.g. call-setup would work, but BYE from callee would fail.
>
>> However, the fact is that during a TCP dialog there "should" exist  
>> *two* TCP connections (assuming binding port = 5060):
>> a) UA:random_port - Proxy:5060
>> b) Proxy:random_port - UA:5060
>
> that's the broken idea of RFC 3261. In fact that will never work due  
> to NAT/FW. The un-standardized approaches are described above and  
> work well. The standardized approach would be sip-outbound, which  
> gives the same result than the un-standardized approach.

SIP-outbound for when NAT is involved and connection-reuse drafts  
(that Andrei referred to earlier) for when there's no NAT, like  
between two sip proxys on the public Internet or a local network.

And in addition, there's a lot of work done for TCP/TLS that makes it  
even more complicated. If you opened a connection to a proxy for berlin.example.com 
  and approved the server certificate and then realize that you're  
about to set up a new connection to the same proxy, but now for stockholm.example.com 
  - you're not allowed to reuse the first connection.

/O