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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]>;tag=sufzmxi0us
To: "Bob" <sip:[EMAIL PROTECTED]>;tag=c9550czwtn
[...]
Contact: <sip:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:2421;transport=tcp;",
"Contact: <sip:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:2421;transport=tcp;line=fyyuh6tl SIP/2.0
Message Header
[...]
From: "Bob" <sip:[EMAIL PROTECTED]>;tag=kcsveifugd
To: "Alice" <sip:[EMAIL PROTECTED]>;tag=ricaq5cy15
Contact: <sip:[EMAIL PROTECTED]: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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
