[OpenSIPS-Users] force_tcp_alias default behavior seems wrong – should not use port from Via-header

[Jonas Borjesson]

Hi,

Sorry, I thought I did buy no, the request-uri will NOT be
"sip:public_ip:5061", if it was it would not find the correct
connection since it is not stored under that key. Due to
"fix_nated_contact", as part of the REGISTER flow, the Contact of that
REGISTER will now be "sip:public_ip:public_port" and as such, when the
call comes back to opensips, that is what the request uri will be.
Hence, the fix_nated_contact and force_tcp_alias are now doing the
exact same thing, which makes sense. I.e., they are changing "things"
to match that of the actual connection and not like today where
fix_nated_contact will match the incoming connection but
force_tcp_alias will not (because it grabs the port from the
Via-header instead of the actual port of the connection - also compare
with rport usage, which does the correct thing).

Also, if you keep the force_tcp_alias as is, every client behind the
same NAT would be broken because only the very first client that
established the connection would ever be able to receive a call
(assuming they port the same port in their Via-header). Even if you
then tried to fix things by using fix_nated_contact then no clients
would work since none of them would have a stored connection under the
"fixed" contact and as such, all attempts to connect to those clients
would fail (of course, UDP would work but then again force_tcp_alias
is obviously not used for UDP). At the end of the day, this is kind of
a poor-mans version of SIP outbound (rfc5626) I guess...

/Jonas


On Mon, Sep 28, 2015 at 4:14 AM, Bogdan-Andrei Iancu
<bogdan at opensips.org> wrote:
> Hi Jonas,
>
> One question (which remained unanswered): when the call comes back to
> opensips (from main server to Alice, let's say), what it the the RURI? Is
> "sip:public_ip:5061" (as per contact in REGISTER) ? If you use
> fix_nated_contact() at REGISTER time, does the RURI in INVITE changes to
> "sip:public_ip:NAT_port" ?
>
> I'm asking as the the whole aliasing mechanism is not network level only,
> but it is tightly linked to the SIP level too, to how the SIP entities do
> map over the TCP connections.
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 24.09.2015 17:52, Jonas Borjesson wrote:
>>
>> Hi,
>>
>> The exact details is as follows:
>>
>> The client will establish a TLS connection, which is terminated by
>> opensips. The client will then send an OPTIONS and from the 200
>> response will learn about its external, to opensips, IP and port
>> through the received and rport from the Via-header. It will then issue
>> a REGISTER using the same connection and populate that REGISTER with
>> the information it learned from the OPTIONS. I agree that this is not
>> really per any spec but in general, this is really the very same as
>> issuing an initial REGISTER (which it will get wrong), examine the Via
>> in that response and re-register with the correct Contact based off of
>> that info. Now, this particular client has currently two issues, which
>> I'm having them fix:
>>
>> 1. They “forgot” to use the rport value in the Via from the response
>> to the OPTIONS as the port in their Contact of the REGISTER. Hence,
>> they essentially will register with Contact: <public_ip>:5061 but this
>> can be easily fixed by opensips fix_nated_contact and, I'm arguing, is
>> a separate issue from connection management.
>>
>> 2. The client doesn't end up using the rport in the new Via, which
>> then effectively becomes 5061 and that is in fact how I found this
>> issue. In general though, I think the Via in this case actually
>> shouldn't be the external facing IP and port but rather the actual
>> private ip and port of where the connection is “attached” to on
>> Alice's client since because of “symmetric response routing” this is
>> not an issue (the use of rport etc) and in general, you can't really
>> trust the information in there anyway (which is why we have received
>> and rport in the first place).
>>
>> However, even though the client has some issues I think that the
>> connection management of opensips is a separate problem but of course,
>> if the Client gets the Contact wrong, and it isn't being fixed by
>> opensips through e.g. fix_nated_contact then the “key” used to lookup
>> the connection for any future requests going to that client will of
>> course be wrong and the request will fail. Anyway, I believe that
>> since we are dealing with connections, the key for that connection
>> must be calculated off of the information representing that
>> connection, which a layer 7 protocol, such as SIP, does not. Hence,
>> they key should be local IP + local port + remote IP + remote port +
>> transport and this is irrespective of what it says in the SIP message
>> itself. Based on that philosophy, I changed the force_tcp_alias to
>> grab the port from the packet instead (port=msg->rcv.src_port) and
>> that will correctly store the connection under the correct key, which
>> then truly represents that connection and this will address the issue.
>> Again though, the Contact of the REGISTER must of course match that
>> but at least now, all connections will be stored correctly in the
>> internal map of opensips.
>>
>> Does that make sense?
>>
>> /Jonas
>>
>>
>> On Thu, Sep 24, 2015 at 12:51 AM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org> wrote:
>>>
>>> Hi Jonas,
>>>
>>> A quick question first about the Contact hdr used by Alice and Bob
>>> devices
>>> during registration. From your explanation, I understand that STUN
>>> correctly
>>> discover the IP address of the NAT, but you haven't mentioned anything on
>>> the port. So, I guess the contact populated in the Register is a mixing
>>> of
>>> the public NAT address and the port of the local box. Is this correct ?
>>>
>>> I'm asking, as before exploring the issue about the "force_tcp_alias"
>>> (which, I agree, has some problems), I want to understand how the
>>> end-user
>>> (bob or alice) are to be addressed on the OpenSIPS proxy - like INVITE to
>>> sip:bob at NAT_IP:local_port ?
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>>> On 24.09.2015 03:34, Jonas Borjesson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have the following problem (sorry for somewhat long explanation,
>>>> want to get it right on the first try :-):
>>>>
>>>> * Alice is behind a NAT and registers with whatever.com and has
>>>> through STUN figured out her public ip, which will go into the Contact
>>>> of the REGISTER.
>>>> * Bob is behind the same NAT as Alice and registers with whatever.com
>>>> and has through STUN figured out his public ip, which will go into the
>>>> Contact of the REGISTER.
>>>> * Carol is another user that calls bob at whatever.com.
>>>> * opensips is acting as a pure transaction stateful proxy for all SIP
>>>> traffic (including REGISTER so I'm not using opensips as a registrar)
>>>> * opensips config is using force_tcp_alias() so that the connection
>>>> can be re-used at a later point.
>>>> * Alice's and Bob's clients are sending keep-alive traffic (double
>>>> crlf) to keep the connection up.
>>>>
>>>> In the above scenario, because of the way force_tcp_alias works, Bob
>>>> will NOT get the call but rather Alice for the following reason:
>>>>
>>>> When Alice's client registers and the force_tcp_alias is executed, a
>>>> mapping between Alice's public ip + the port found in the top-most
>>>> Via-header and her incoming TCP/TLS connection will be created. When
>>>> Bob registers, which he does after Alice, he too will create mapping
>>>> between his connection and the public_ip + port in Via. Of course,
>>>> since Alice and Bob are behind the same NAT they will have the same
>>>> IP, hence “half” the key is shared between Alice & Bob at all times.
>>>> If Alice & Bob also puts the same port as each other in the top-most
>>>> Via-header, they now share the exact same key for the connection
>>>> whereby opensips will complain with the following message:
>>>> “tcpconn_add_alias: possible port hijack attempt”. Hence, when Carol
>>>> later on calls Bob, which then will be “resolved” to
>>>> bob at public_ip:some_port (by a location aware proxy behind opensips)
>>>> and subsequently proxied to Bob via the opensips node, it will find a
>>>> live connection and re-use that, which ends up at Alice.
>>>>
>>>> So, looking at the code (action.c):
>>>>
>>>> case FORCE_TCP_ALIAS_T:
>>>>       …
>>>>       if (a->elem[0].type==NOSUBTYPE) {
>>>>           port=msg->via1->port;
>>>>       ...
>>>>
>>>> which clearly grabs the port out of the Via. By doing this there is a
>>>> chance that clients will happen to have the same local port and you
>>>> will run into the scenario above. Even worse, for those clients that
>>>> do not set the port on the Via to the actual port of the connection
>>>> (which clients do) they will end up with the default for the
>>>> transport, which in my case was 5061 for TLS. Malicious users behind
>>>> the same corporate NAT could take advantage of this by setting up many
>>>> connections to effectively “steal” other peoples phone calls, granted,
>>>> they may have to setup several thousands of connections to be sure so
>>>> perhaps not practical.
>>>>
>>>> So, suggested solutions:
>>>>
>>>> Suggestion 1: I do not see any value with using the port from the via
>>>> but rather always use the port from the src packet itself since that
>>>> is what you really want anyway. That will avoid everything above.
>>>>
>>>> Suggestion 2: Allow for script variables to force_tcp_alias so you
>>>> could pass whatever you want, which in my case always would be the
>>>> source port of the incoming packet. Currently, the config-file grammar
>>>> only allows for number but could be easily extended to allow for other
>>>> types as well.
>>>>
>>>> Both solutions are fairly trivial where solution 1 seems to be the
>>>> correct default behavior but solution 2 has the most flexibility and
>>>> also wouldn't mess with any existing deployments in the wild, even
>>>> though I'm guessing they suffer from the same problem as described but
>>>> may not have been discovered yet.
>>>>
>>>> Comments/thoughts? If people agree, I will issue a pull request
>>>> against latest 1.11. Also, the behavior is the same for at least
>>>> versions 1.8 and 1.11. I am assuming it’s also the same for all
>>>> versions in between as well, and possibly earlier versions but I
>>>> haven't checked.
>>>>
>>>> Thanks,
>>>>
>>>> /Jonas
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>