[sr-dev] TLS: Sip-Routers adds a Record-Route with "sip" scheme rather than "sips"

Martin Hoffmann martin.hoffmann at telio.ch
Wed Jul 6 10:23:33 CEST 2011


Olle E. Johansson wrote:
> 6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
>
> > It's like in HTTP world:
> > 
> > - http:// means HTTP over TCP.
> > - https:// means HTTP over TLS over TCP.
> > 
> > Since HTTP just works over TCP, there is no reason for a ;transport
> > param. But SIP protocol can work over different transport layers (TLS
> > is not a transport layer).
> > 
> You can not compare sips with https. Sorry.
> 
> https puts a requirement for TLS all the way.
> 
> SIPS: in RFC3261 did not.

RFC 3261, section 4:

| A call made to a SIPS URI guarantees that secure, encrypted transport
| (namely TLS) is used to carry all SIP messages from the caller to the
| domain of the callee.  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.

> It's simply a request, a proposal. Now if you don't want to change the
> properties of the original request, but still require your
> infrastructure to use TLS for the next hop you do not want to change
> to a SIPS: uri, which will put a new requirement for the rest of the
> signalling. You want to add an attribute like ";transport=tls".

Why? We are talking about the URI in the (Record-) Route header here,
which _only_ indicates how to get to the next hop. If you put a SIPS URI
in there, this has no consequence whatsoever for the complete path.

> Yes, SIPS: is really messy and hard to understand.

I'd argue it's completely broken like so many things in SIP. IETF went
out to publish a document to fix it. After much argueing, this became
RFC 5630 and people are confused as ever.

> How would you guys
> handle a Contact: with SIPS: ?

In a dialog or in a registration?

> Can you reuse a connection like
> outbound? I guess not, since you have to verify the endpoint
> certificate.

If you reuse a connection you'd have done that already earlier. Most
likely, the client opened the conneciton to you in the first place.

One final word: What Iñaki and me are argueing here is what the standards
say. What we probably don't agree on is what this means in practice. For
me as someone who regularly has to bring different SIP implementations
together, it means pretty much nothing. You'd never find SIPS URIs in
the wild but plenty of transport=tls. (Or well, not really, nobody is
using TLS in practice anyways.)

Regards,
Martin



More information about the sr-dev mailing list