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

[Andreas Granig]

Hi Juha,

My impression is that transport=tls is something like a widely used
consensus on how to securely communicate in SIP. However, is there a way
how support for that is communicated towards a client, like SIPS+D2T was
supposed to be the way to indicate "sips" support in NAPTR?

I'm using TLS for some months now with a couple of clients, and I'm
starting to wonder why we're all still using a mechanism deprecated in
RFC3261, whereas we're usually quite sensitive to shortcomings and
mistakes in RFC3261 and are not shy cranking out new SIP related RFCs
like there's no tomorrow...

It didn't bother me much until today where I realized there is no way to
properly indicate to a client that my server supports TLS. Or is there?

Andreas


On 12/01/2012 12:29 AM, Juha Heinanen wrote:
> Andreas Granig writes:
> 
>> 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".
> 
> when rfc3261 was specified, the whole sips thing was put there at the
> last minute.  no-one had any practical experience of it.  i guess the
> requirement to have something like https came from ietf area directors.
> the result is a useless mess.
> 
>> 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?
> 
> in that case, the proxy has to drop the request unless the last hop is
> "secure", i.e., uses a vpn, barb wire, or something.
> 
>> 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?
> 
> you cannot use sips with udp transport.
> 
> -- juha
> 
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121201/9cf28fe6/attachment.pgp>