[SR-Users] NAPTR, SRV and sips vs. transport=tls

[Iñaki Baz Castillo]

2012/12/1 Andreas Granig <agranig at sipwise.com>:
> Hi,
>
> Hope to get some guidance here over the usage of "sips" and "sip plus
> transport=tls" when following RFC3263.
>
> The RFC3263 says that a NATPR record could return something like this
> for a query like "host -t NAPTR example.com":
>
>    ;          order pref flags service      regexp  replacement
>       IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.
>       IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com
>       IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.
>
> This means that the client should use sips if possible when contacting
> example.com.

The client yes, but a proxy not. This is, if the proxy is forwarding a
request with RURI "sip:alice at domain.com" and NAPTR returns a SIPS+D2T
(along others) the proxy could choose to send the request via TLS but
must not modify the RURI scheme.

Anyhow, I strongly discourage the usage of sips schema. It was a
"dream" of the IETF. Nobody uses it, nobody can use it and it provides
nothing (since an intermediary proxy could decide not to honor the
requested security and forward the request via UDP/TCP). Some months
ago I discussed this subject in sipcore WG and the conclusion is that
nobody wants sips usage.



> A lot of clients and servers are sending
> "sip:user at example.com;transport=tls" in request URIs and Contact headers
> and Record-Route headers, and you can check with
> uri_param("transport","tls") which transport socket to use. This is
> pretty useful as you can determine hop-by-hop whether or not to use TLS.

> This approach has been obsoleted by RFC3261 though, and there doesn't
> seem to be a mechanism in RFC3263 to indicate "use schema sip, but use
> transport=tls".

transport=tls has NEVER been real, no one RFC mentions it.



> On encounter of a NAPTR record like the one above, how does kamailio
> act? Does it set a "sips" schema for the next hop?

As said before, the proxy could choose TLS for forwarding the request
(so would add a top Via with "TLS" transport) but should not modify
the URI scheme.



> And what's the general take on this "sips" schema? As far as I
> understand RFC3261, it means that if a client sends a request to a
> sips-URI, the request is sent to the domain via TLS, and from there "the
> request is sent securely to the callee, but with security mechanisms
> that depend on the policy of the domain of the callee." (RFC3261,
> Chapter 4). What does this really mean in practice?

When a client sends a request with SIPS in the RURI, the responses
must have SIPS in all the Record-Route and Contact. And the same for
incoming requests in the same dialog. Otherwise the client should
terminate the dialog.


> Are you allowed to
> rewrite the schema to "sip" and pass it on for example via UDP to the
> callee if the callee didn't indicate transport=tls (deprecated anyways)
> or "sips:" in the Contact of the registration? Or should you keep "sips"
> as schema, but still send it via UDP, because you know based on local
> policy or based on client registration that the next hop is not
> supporting TLS?

In this case the proxy should not attempt to forward the request and,
instead, reject it with 416"Unsupported URI Scheme".


> How would widespread clients react when getting a call
> to a "sips" URI, especially if they receive it via UDP?

Good cuestion but IMHO there is no good response. They could reply
normally but the UAC may later terminate the dialog when it realizes
that the Contact URI in the response has no SIPS schema (since SIPS is
not valid in UDP).


As said before, the easiest way to live with this is by never using
SIPS as it provides nothing and adds lot of undocumented issues. Also
note that it's valid for a client (or a proxy) to send a request via a
TLS connection and still setting a Contact URI with transport=tcp.
This would be hard for receiving incoming requests but for that
Outbound (RFC 5626) does exist (the proxy would route the requests
over the connection initiated by the client, regardless it is TCP or
TLS and regardless the URI schema in the Contact URI).


Regards.




-- 
Iñaki Baz Castillo
<ibc at aliax.net>