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

[Alexander Ph. Lintenhofer]

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