Via header interpretation with rport parameter being set

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Via header interpretation with rport parameter being set

Thomas Gelf
Hi All,

I stumbled over an intersting issue I'd like to share and to ask
feedback for. Grandstream phones offer an option called "use symmetric
RFC 3581 routing". If that option is enabled and STUN detection was
successful, it's REGISTER packets show a perfectly correct Contact
header and a Via header using it's private IP address and port.

IMO RFC 3581 is not clear about whether in such situations a client
shall nonetheless replace it's Via ip:port pair with what he has
learned by doing STUN. Please correct me if this assumption is wrong,
I'll open a ticket at Grandstream and forget about this.

Said so, I'd like to raise a few questions:

* is there something like a has_rport() function in OpenSIPS?
* would a new test checking whether Contact differs from the socket
  where the UAC's packet came from make sense?
* More and more clients are adding the rport parameter, and while most
  of them are setting Via as learned by STUN, this must not be always
  true. At least I didn't find anything in RFC 3581 stating so. Even if
  I definitively would never ever suggest using Grandstream as a refe-
  rence implementation, the fact that they are doing as told above
  means that different interpretations could definitively be possible
  here. As told before, I could be wrong here!
* Contact is as correct as possible in most cases, however just checking
  for private IPs doesn't suffice (for the very same reason there are
  multiple checks for Via headers), but one should also NOT consider the
  client being behind NAT just because Contact and client socket differ.

Instead of explaining wide and long the meaning of this, I'll show you
an example of how my "best-nat-check-ever"-config should look like,
assuming there was a client_nat_test("8") meaning that Contact differs
from client socket:

if (client_nat_test("8"))
{
    # Contact doesn't match client socket, apply all checks regardless
    # of rport being set or not:
    if (client_nat_test("7")) {
        setbflag(BF_NAT);
        AVP_RECEIVED = $source_uri;
    }
} else {
    # Contact is correct. If either rport is set or Via is also correct,
    # we have no NAT issue.
    if (! $(hdr(Via)[0]) =~ ";rport" && client_nat_test("6"))
    {
        setbflag(BF_NAT);
        AVP_RECEIVED = $source_uri;
    }
}

I'm pretty curious about your opinions!

Best regards,
Thomas Gelf

--
 mail: [hidden email]
  web: http://thomas.gelf.net/


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Via header interpretation with rport parameter being set

Iñaki Baz Castillo
2009/9/14 Thomas Gelf <[hidden email]>:

> Hi All,
>
> I stumbled over an intersting issue I'd like to share and to ask
> feedback for. Grandstream phones offer an option called "use symmetric
> RFC 3581 routing". If that option is enabled and STUN detection was
> successful, it's REGISTER packets show a perfectly correct Contact
> header and a Via header using it's private IP address and port.
>
> IMO RFC 3581 is not clear about whether in such situations a client
> shall nonetheless replace it's Via ip:port pair with what he has
> learned by doing STUN. Please correct me if this assumption is wrong,
> I'll open a ticket at Grandstream and forget about this.

It doesn't matter if a client sets Via with the private or public
(STUN) address. When a proxy or server receives a request it must
inspect the Via header sent-field value (the IP and port).
If the IP doesn't match the real source IP, then the proxy/server adds
";received=REAL_SOURCE_IP so responses would be sent to REAL_SOURCE_IP
and original port in Via sent-field value. This doesn't solve NAT
since the port used is still the original (private) port. So "rport"
makes sense here:
If the client adds an empty ;rport parameter, it means that it uses
symmetric SIP so the server adds to the Via header:
- ;received=REAL_SOURCE_IP
- ;rport=REAL_SOURCE_PORT
and the proxy/server sends replies to REAL_SOURCE_IP:REAL_SOURCE_PORT
(so "fixes" NAT).

In conclusion: a client doing STUN is not required to change its Via
sent-by header as adding ";rport" gets the same effect.

Of course, all the above is just for UDP. In TCP it makes no sense as
the first attempt is to send the replies using the existing TCP
connection.



> Said so, I'd like to raise a few questions:
>
> * is there something like a has_rport() function in OpenSIPS?

I don't know why you need it.


> * would a new test checking whether Contact differs from the socket
>  where the UAC's packet came from make sense?

Be carefull since it wouldn't work for TCP clients (the listening port
could be 5060 while each request uses a random source port different
than 5060).



> * More and more clients are adding the rport parameter, and while most
>  of them are setting Via as learned by STUN, this must not be always
>  true. At least I didn't find anything in RFC 3581 stating so. Even if
>  I definitively would never ever suggest using Grandstream as a refe-
>  rence implementation, the fact that they are doing as told above
>  means that different interpretations could definitively be possible
>  here. As told before, I could be wrong here!

As I explained above, it doesn't matter (or it shouldn't). The server
should inspect the "Contact" header rather than Via to detect NAT.


> * Contact is as correct as possible in most cases, however just checking
>  for private IPs doesn't suffice (for the very same reason there are
 >  multiple checks for Via headers), but one should also NOT consider the
>  client being behind NAT just because Contact and client socket differ.

If a client uses symmetric SIP (as most of them do), and uses UDP,
then NAT is detected by comparing the real source IP:port with the
value of the Contact header.
In case of TCP, just the real source IP should be compared against the
Contact IP.




--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Via header interpretation with rport parameter being set

Thomas Gelf
Iñaki Baz Castillo wrote:
> In conclusion: a client doing STUN is not required to change its Via
> sent-by header as adding ";rport" gets the same effect.

That's what I wanted to point out ;-)

> Of course, all the above is just for UDP. In TCP it makes no sense as
> the first attempt is to send the replies using the existing TCP
> connection.

Fortunately I do not yet need to care about TCP :-p

> If a client uses symmetric SIP (as most of them do), and uses UDP,
> then NAT is detected by comparing the real source IP:port with the
> value of the Contact header.

And that's exactly what I'm missing. As of

http://www.opensips.org/html/docs/modules/devel/nat_traversal.html#id228455

there is no such test in OpenSIPS nat_traversal module. As you correctly
pointed out, the whole rport-handling voodoo is not even needed - I'm
already calling force_rport() for each request. I thought it might be
even more elegant to care about what the client states - but you're
absolutely right, that's a waste of ressources.

As no test comparing the real source IP:port with the value in the
Contact header is available, test 2 and 4 are still being used. However,
they are either useless or could lead to wrong assumption (as in the
example I mentioned).

So, to the long and the short of it, let's come back to my essential
question (probably hidden between too much text in my former post):

* would a new test checking whether Contact differs from the socket
  where the UAC's packet came from make sense?

To pick up Iñaki's addition: it should obviously be used for UDP only.

Cheers,
Thomas

--
 mail: [hidden email]
  web: http://thomas.gelf.net/


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Via header interpretation with rport parameter being set

Iñaki Baz Castillo
2009/9/14 Thomas Gelf <[hidden email]>:
>> If a client uses symmetric SIP (as most of them do), and uses UDP,
>> then NAT is detected by comparing the real source IP:port with the
>> value of the Contact header.
>
> And that's exactly what I'm missing. As of
>
> http://www.opensips.org/html/docs/modules/devel/nat_traversal.html#id228455

Yes, I also miss it. In fact I use test function of nathelper module.


> there is no such test in OpenSIPS nat_traversal module. As you correctly
> pointed out, the whole rport-handling voodoo is not even needed - I'm
> already calling force_rport() for each request. I thought it might be
> even more elegant to care about what the client states - but you're
> absolutely right, that's a waste of ressources.

Note that if a client behind NAT doesn't use symmetric SIP, it will
NEVER receive replies (since it requires to receive replies in other
port, which is impossible from outside the router).


> As no test comparing the real source IP:port with the value in the
> Contact header is available, test 2 and 4 are still being used. However,
> they are either useless or could lead to wrong assumption (as in the
> example I mentioned).

You are right.


> So, to the long and the short of it, let's come back to my essential
> question (probably hidden between too much text in my former post):
>
> * would a new test checking whether Contact differs from the socket
>  where the UAC's packet came from make sense?

Sure! :)

Please report it in the tracker explaining what we have talked about
and I will give feedback to the report :)



--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Via header interpretation with rport parameter being set

Thomas Gelf
Iñaki Baz Castillo wrote:
> Note that if a client behind NAT doesn't use symmetric SIP, it will
> NEVER receive replies (since it requires to receive replies in other
> port, which is impossible from outside the router).

Are there clients using asymmetric SIP still to be found out there in
the wild?

> Please report it in the tracker explaining what we have talked about
> and I will give feedback to the report :)

Great! I have to leave for an hour or so, will immediately do so once
back.

--
 mail: [hidden email]
  web: http://thomas.gelf.net/


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Via header interpretation with rport parameter being set

Iñaki Baz Castillo
2009/9/14 Thomas Gelf <[hidden email]>:
> Iñaki Baz Castillo wrote:
>> Note that if a client behind NAT doesn't use symmetric SIP, it will
>> NEVER receive replies (since it requires to receive replies in other
>> port, which is impossible from outside the router).
>
> Are there clients using asymmetric SIP still to be found out there in
> the wild?

There are still some gateways doing it :(




--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Via header interpretation with rport parameter being set

Thomas Gelf
Iñaki Baz Castillo wrote:
> 2009/9/14 Thomas Gelf <[hidden email]>:
>> Iñaki Baz Castillo wrote:
>>> Please report it in the tracker explaining what we have talked about
>>> and I will give feedback to the report  :)

Done!

>> Are there clients using asymmetric SIP still to be found out there in
>> the wild?
> There are still some gateways doing it :(

Any names?

Cheers,
Thomas

--
 mail: [hidden email]
  web: http://thomas.gelf.net/


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users