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

Alexander Ph. Lintenhofer lintenhofer at aon.at
Thu Oct 27 19:48:55 CEST 2005


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





More information about the sr-users mailing list