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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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
Hello Phillipp,
the problem exposed by you here is somehow similar to the topic discussed on devel@openser.org in the mail thread "Processing REGISTER requests".
Mainly is how to attach a resource to a contact address and identify it properly (in this case is the tcp connection). Since we have all over NATs, we cannot rely on the contact address. The latest version of openser stores in the usrloc database the associated NAT ip and port along with contact address. This is not enough when you have multiple levels of NATs (e.g., two different networks with same private IPs being visible from outside behind same nat - this gets a conflict when same user has phones in both networks).
It is clear that in your case you have to keep the tcp connection open for the whole call. The problem is how to identify the connection from the contact address. We have to address this soon and find the proper solution for this case as well as for usrloc.
Cheers, Daniel
On 10/26/05 12:51, 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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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?
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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.... 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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@atlanta.com;tag=sufzmxi0us To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn [...] Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: <sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 Message Header [...] From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 Contact: sip:bob@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
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@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@atlanta.com;tag=sufzmxi0us > To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn > [...] > Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", "Contact: sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 > Message Header > [...] > From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd > To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 > Contact: sip:bob@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
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@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@atlanta.com;tag=sufzmxi0us >> To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn >> [...] >> Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", > "Contact: sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 >> Message Header >> [...] >> From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd >> To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 >> Contact: sip:bob@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 > > >
Hi Alexander,
I removed the protocol restrictions. Once more it was proved that for TCP/TLS there are still dark zones which have evaded us so far :) Let's be cautious!! ;)
thanks for the help in troubleshooting
regards, bogdan
Alexander Ph. Lintenhofer wrote:
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@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@atlanta.com;tag=sufzmxi0us >>> To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn >>> [...] >>> Contact: sip:alice@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@172.16.0.6:2421;transport=tcp;", >> "Contact: >>> sip:alice@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@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 >>> Message Header >>> [...] >>> From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd >>> To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 >>> Contact: sip:bob@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 >> >> >> >>
-
Alexander Ph. Lintenhofer -
Alexander Philipp Lintenhofer
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Klaus Darilion