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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Thu Oct 27 18:09:09 CEST 2005


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 ?

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