[Users] TCP-alias and NAT - one more try to get an answer

Klaus Darilion klaus.mailinglists at pernau.at
Thu Oct 27 13:30:37 CEST 2005


Bogdan-Andrei Iancu wrote:
> Hi Alexander,
> 
> sound like a solid reason. It means that the solution will be to allow 
> fix_nated_contact() for TCP based protos.
> any other suggestions?

I think it should be fine to allow fix_nated_contact() also for TCP/TLS 
(to have correct alias mapping)

regards
klaus

> 
> regards,
> bogdan
> 
> Alexander Philipp Lintenhofer wrote:
> 
>> Hi Bogdan,
>>
>> This is the answer, Andrei gave me:
>> "....ser aliases only the ports, it never adds an alias for an IP 
>> (security risk)....."
>>
>> I think, he means TCP-hijacking in the case of a modificated/malformed 
>> via-header.
>>
>> regards,
>> Philipp
>>
>>> Hi Alexander,
>>>
>>> indeed, it seams you have case. Even if the draft says that the alias 
>>> tuple must include the VIA ip:port, currently the IP is considered as 
>>> received IP. Why? not sure (is Andrei's work), but I can speculate on 
>>> the overhead introduce in getting the address from via and convert it 
>>> to IP (via may contain DNS name which should be resolved!).
>>>
>>> If we go ahead on this road, right, you need a way to set the NAT IP 
>>> in the contact -> use fix_nated_contact() which does not support TCP 
>>> :D.  I do not like this approach because the alias is a mixture 
>>> between the NAT IP and the inside port :/
>>>
>>> If we go as the draft says, and use via ip:port we have to face the 
>>> need of performing DNS lookup only to generate the alias ....this is 
>>> even uglier and more dangerous. and also we will end having private 
>>> IPs in RURIs and in aliases..which is a little bit tricky - a private 
>>> IP is not unique ;).
>>>
>>> so, I would say the best way is the first one....and to allow 
>>> fix_nated_contact() also for TCP/TLS.........
>>>
>>> regards,
>>> bogdan
>>>
>>>
>>>
>>> Alexander Ph. Lintenhofer wrote:
>>>
>>>> Hi All,
>>>>
>>>> I just wanted to ask you once again about the TCP-alias riddle. I 
>>>> found out, that there is a problem with the combination of 
>>>> fix_nated_contact(), force_tcp_alias() and NAT:
>>>>
>>>> Imagine following situation:
>>>>
>>>> Alice behind NAT: socket 172.16.0.6:2421
>>>> Nat-Box translates this to 192.168.0.13:6007
>>>>
>>>> The Outbound-Proxy of Alice is 192.168.0.1
>>>>
>>>> Bob is registered with 192.168.1.1
>>>>
>>>> 1.)
>>>> Her INVITE:
>>>> ====================================================================
>>>> INVITE sip:bob at 192.168.1.1:2331;transport=tcp;line=wxqurd1s SIP/2.0
>>>> [...]
>>>> Via: SIP/2.0/TCP 172.16.0.6:2421;received=192.168.0.13;
>>>>                branch=z9hG4bK-wm9jcstcboys;rport=6007
>>>> From: "Alice" <sip:alice at atlanta.com>;tag=sufzmxi0us
>>>> To: "Bob" <sip:bob at biloxi.com>;tag=c9550czwtn
>>>> [...]
>>>> Contact: <sip:alice at 172.16.0.6:2421;transport=tcp;line=fyyuh6tl>
>>>> [...]
>>>> ====================================================================
>>>>
>>>> 2.)
>>>> fix_nated_contact() doesn't work with TCP (look at nathelper.c).
>>>> force_tcp_alias() now creates following tuple as TCP-alias: 
>>>> 192.168.0.13:6007 to 192.168.0.13:2421
>>>>
>>>> Reason:
>>>> The TCP-alias is not built solely from the Via-header as suggested 
>>>> in the draft. The portnumber is taken from the Via-header and the 
>>>> IP-address is taken from the source of the incoming datagram. I read 
>>>> it in the sourcecode and assured it by contacting Andrei!
>>>>
>>>> 3.)
>>>> So as a result of the notfixed Contact-header of Alice's INVITE the 
>>>> BYE of Bob is addressed to 172.16.0.6:2421. But no TCP-alias exists 
>>>> for this socket :-(
>>>>
>>>> 4.)
>>>> I made following test by rewriting the Contact-header....
>>>> ====================================================================
>>>> if (method=="INVITE")
>>>> {
>>>>   replace("Contact: <sip:alice at 172.16.0.6:2421;transport=tcp;",
>>>>           "Contact: <sip:alice at 192.168.0.13:2421;transport=tcp;");
>>>> }
>>>> ====================================================================
>>>> ...with success. Now TCP-alias works as you can see on my 
>>>> Ethereal-trace below!
>>>> Compare the destination port of the packet to the destination port 
>>>> of the RURI!
>>>> ====================================================================
>>>> [...]
>>>> Transmission Control Protocol, Src Port: 5060 (5060), Dst Port: 6007 
>>>> (6007), ...
>>>> Session Initiation Protocol
>>>> Request-Line: BYE 
>>>> sip:alice at 192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0
>>>> Message Header
>>>> [...]
>>>> From: "Bob" <sip:bob at biloxi.com>;tag=kcsveifugd
>>>> To: "Alice" <sip:alice at atlanta.com>;tag=ricaq5cy15
>>>> Contact: <sip:bob at 192.168.1.1:2331;transport=tcp;line=wxqurd1s>
>>>> [...]
>>>> ====================================================================
>>>>
>>>> Another solution:
>>>> Comment the lines in nathelper.c which force the return in case of 
>>>> TCP or TLS. Now all works well!
>>>>
>>>> But why??????????????
>>>>
>>>> regards,
>>>> Philipp
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>
>>
>>
> 
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 
> 





More information about the sr-users mailing list