[Users] TCP-alias and NAT - one more try to get an answer
Alexander Philipp Lintenhofer
lintenhofer at aon.at
Wed Oct 26 20:57:16 CEST 2005
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
>>
>
>
More information about the Users
mailing list