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

[Klaus Darilion]

On 01.12.2012 00:25, Andreas Granig wrote:
> 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.
>
> Concluding from that, I suppose it should perform an SRV lookup "host -t
> SRV _sips._tcp.example.com", and the result would be:
>
>     ;;          Priority Weight Port   Target
>         IN SRV  0        1      5061   server1.example.com
>         IN SRV  0        2      5061   server2.example.com
>
> What I'm curious about is how requests towards one of these servers
> should look like, and how they are being handled by kamailio.

(Disclaimer: non normative - this is how I understand SIP and how I 
would use it)

The request URI should look like the one which the user enters. E.g. if 
user enters "sip:12345 at example.com" then the request URI should be 
"sip:12345 at example.com" - regardless of the transport protocol chosen by 
the transport layer.

Thus, if NAPTR records tell you to use SIP over TLS, then use SIP over 
TLS but do not change the request URI.

The contact header could be any transport - but of course it makes sense 
if the client uses the same transport protocol as used for sending the 
request (which is usually the same used for registration).

When a user enters "sips:12345 at example.com", then of course a secure 
transport must be used, which basically means that TLS will be used. 
Nevertheless the request URI is still "sips:12345 at example.com" without 
any transport identifier.

The request URI only contains a transport parameter if the user entered 
one (e.g. to force its client to use a certain transport), or if the 
call forwarding logic in the proxy requires a certain transport. In this 
case, NAPTR lookups will be skipped (as transport is already defined).

In case if a SIPS URI entered by the user, the contact URI must be SIPS 
too. In a proxy it usually does not makes sense to manually change a 
request URI from SIP to SIPS - but there may be certain scenarios where 
things may get complex, e.g. the Sipwise "SIP Provider" setup:


Client1 <---TLS/TCP/UDP ----> Proxy <---UDP--> sems/b2bua
                           /
Client2 <---TLS/TCP/UDP --

As long as SIP URIs are used, there is no problem in converting from TLS 
to UDP. If client 1 uses a SIPS URI to call client 2, then may be 
problems: From standard point of view it should be fine to convert TLS 
to UDP, as the transport is secured by other means (in this case a local 
hop via loopback interface). The question is how the SIP client will 
react, when receiving SIP requests for SIPs URIs, but the contact 
contains a SIP URI. A workaround of course would be to change sems's 
contact to "sips:...;transport=tls" in the proxy, but still use UDP 
between proxy and sems.


> 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".

RFC3263 does not enforce the format of the URI. It just tells you to use 
TLS/TCP/UDP - as said above, the RURI should not be changed due to NAPTR 
lookups.

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

Hopefully not. The RURI should not be changed.

> 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? 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? How would widespread clients react when getting a call
> to a "sips" URI, especially if they receive it via UDP?

Yes, there are lots of open issues and sips itself is broken by design 
as it enforces encryption between all hops, but there is no way to 
control or enforce that encryption is really used between all hops.

So, I personally would mandate to drop the SIPS schema completely, as it 
can not guarantee secure transport on all hops. The only hop where a 
client can enforce a secure transport is the first hop - and this can be 
done also with the SIPS schema.

regards
Klaus