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

[Alexander Philipp Lintenhofer]

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