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

[Bogdan-Andrei Iancu]

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?

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
>>>
>>
>>
>
>
>