[sr-dev] Playing with TCP and TLS

[Olle E. Johansson]

29 okt 2012 kl. 10:52 skrev Klaus Darilion <klaus.mailinglists at pernau.at>:

> 
> 
> On 26.10.2012 22:03, Olle E. Johansson wrote:
>> 
>> 26 okt 2012 kl. 21:08 skrev Klaus Darilion
>> <klaus.mailinglists at pernau.at>:
>> 
>>> Am 26.10.2012 14:08, schrieb Olle E. Johansson:
>>>> 25 okt 2012 kl. 19:05 skrev Klaus Darilion
>>>> <klaus.mailinglists at pernau.at>:
>>>> 
>>>>> Kamailio uses the next hop target (probably the URI in the Path
>>>>> header) and searches for open TCP connections to this target. I
>>>>> guess the Path header contains the private IP address of the
>>>>> outbound proxy, thus it does not match the open TCP connection.
>>>>> If there is not outboundproxy, the solution is simple: as
>>>>> always use fix_nated_register() on REGISTER. Then, after
>>>>> lookup() the proxy will search for a TCP connection to the
>>>>> "received" IP:port and find and uses the existing connection.
>>>> Thinking about TLS - how do we match there?
>>> 
>>> AFAIK there is no difference to TLS. If there is a TLS connection
>>> whose remote address matches the next hop, it will be used.
>> 
>> That's bad. We need to check the domains in the certificate before
>> re-using it. If they showed NO client cert, we should open a new
>> one. If they showed a client, we should verify.
> 
> Not necessarily. Usually SIP clients are behind NAT (not servers) and thus we need NAT traversal for these clients and these clients usually do not have a client certificate.
> 
> For servers, we usually want to have separate TLS connections for each direction. In your "untypical" scenario the NAT traversal should be fixed on the client side and then you could use 2 separate TLS connections.
Will that happen with Kamailio today? Won't the TCP matching make us reuse the existing connection?

> 
>> Will the on-send route give me the possibility or is it triggered
>> before kamailio selects a tcp connection? I'm a bit unclear of the
>> exact situation where the on-send route is called.
> 
> [on-send] is just before the message is sent. AFAIK it is executed before the message is handled over to the transport layer - thus I think TLS paramters of the new connection are not available.
Agree. Just wanted to check.
> 
> Generally, domain verification against the certificate name is broken. For example if you have to reopen a TLS connection for an in-dialog request, there is no proper URI (RURI, next hop Route URI) to compare against the certificate.
no, which is why we don't want IP addresses in the record-route headers for TLS.

/O
> 
> regards
> Klaus
>> 
>> /O
>>