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

[Klaus Darilion]

Bogdan-Andrei Iancu wrote:
> ok.....
> 
> so fixing this bug it means just removing a line.....does somebody has 
> any objection is I fix it now on the last 100 meters :D ?

Is anybody out there using TCP and relays on the "not working feature" 
of fix_nated_contact?

If not, I vote for changing it. Then it will work for the only person 
who uses it ;-)

klaus

> 
> regards,
> bogdan
> 
> Alexander Ph. Lintenhofer wrote:
> 
>> .... and it is not really a big deal to implement it :-)
>>
>> regards,
>> Philipp
>>
>>> 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
>>>>>>
>>>>>>
> 
>