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

[Bogdan-Andrei Iancu]

Hi Alexander,

I removed the protocol restrictions.
Once more it was proved that for TCP/TLS there are still dark zones 
which have evaded us so far :) Let's be cautious!! ;)

thanks for the help in  troubleshooting

regards,
bogdan

Alexander Ph. Lintenhofer wrote:

> >If not, I vote for changing it. Then it will work for the only person 
> who uses it
> ...maybe there will be a little more people in the future using TLS 
> (therefore TCP) and sitting behind NAT.....
>
> Nevertheless thank you for this great work, OpenSER-Team!
>
> regards,
> Philipp
>
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>>
>>
>>
>
>