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

[Jan Janak]

On Tue, Jul 5, 2011 at 12:42, Iñaki Baz Castillo <ibc at aliax.net> wrote:
> 2011/7/5 Jan Janak <jan at ryngle.com>:
>> But why would anyone want to use this in the Route header? By using
>> sips instead of sip;transport=tls in a Route header the proxy server
>> is enforcing that it is to be contacted securely during the dialog,
>> even if the original request (that established the dialog) may not
>> have been subject to such a restriction. In other words request path
>> that was fine for the INVITE is no longer fine for the re-INVITE or
>> BYE.
>
> Hi Jan, the Route header will be removed by each proxy in the path, so
> there is no restriction for in-dialog requests. Example:
>
>
> A                     P1                    P2                        B
>
> -----INV TLS----->
>
>                         ----- INV UDP ---->
>                                RR: sips:P1;tcp
>
>                                                    ----- INV UDP ---->
>                                                          RR: sip:P2;udp
>                                                          RR: sips:P1;tcp
>
>
> The 200 arriving to A would contain:
>
>  SIP/2.0 200 OK
>  Record-Route: sip:P2;transport=udp
>  Record-Route: sips:P1;transport=tcp
>  Contact: sip:B;transport=udp
>
>
> So A would generate an ACK as follows:
>
>  ACK sip:B;transport=udp SIP/2.0
>  Route: sips:P1;transport=tcp
>  Route: sip:P2;transport=udp
>
> then A would route the ACK to P1 using TLS (as topmost Route has sips).
>
>
> P1 would remove the topmost Route (loose-routing) so the ACK would become:
>
>  ACK sip:B;transport=udp SIP/2.0
>  Route: sip:P2;transport=udp
>
> then P1 would route the ACK to P2 using UDP (as topmost Route is sip with udp).
>
>
> And so on.
>
>
> So a sips scheme in a Route header is just hop-by-hop information, and
> not end-to-end.

So what is the difference then? How is a Route header with sips scheme
different from a Route header with the transport=tls parameter? Is the
proxy server supposed to treat Route headers with sips differently
than Route headers with sip;transport=tls?

> However a sips schema in a request URI mandates all the path to be
> secure, but that is not the case of a sips in a Record-Route header.
>
>
>
>> Also, what is the real difference between using sip;transport=tls and
>> sips in Route headers? In both cases the server sending the request
>> will fail to deliver it if it cannot contact the downstream server
>> over TLS. Or is it supposed to fallback to UDP when the parameter is
>> used and reject the request when sips is used?
>
> RFC 3261 deprecates the usage of transport=tls in section 26.2.2 SIPS
> URI Scheme:
>
>      Note that in the SIPS URI scheme, transport is independent of TLS,
>      and thus "sips:alice at atlanta.com;transport=tcp" and
>      "sips:alice at atlanta.com;transport=sctp" are both valid (although
>      note that UDP is not a valid transport for SIPS).  The use of
>      "transport=tls" has consequently been deprecated, partly because
>      it was specific to a single hop of the request.  This is a change
>      since RFC 2543.

Yeah, I understand this paragraph. I think the motivation for this was
to make sips independent of the particular transport mechanism (tls).

But my original question was related to the Route/Record-Route header.
There the proxy records the particular transport mechanism that was
used when the dialog was being established. So if the INVITE was
received over TLS, it would contain ;transport=tls in the Route
header.

You mentioned that the Route header should rather contain sips scheme
if the scheme of the Request-URI was sips. And I don't understand why.
Maybe you're right, but I don't see what difference that would make at
the moment.

> But anyway, in other thread in sip-implementors I got the conclussion
> that RFC 3261 deprecates sips schema with transport=tls, but says
> nothing about sip schema with transport=tls (in fact, "tls" is still a
> valid transport according to the BNF grammar). So, I don't say that
> current sip-router behavior is wrong, but I think it would be more
> "ellegant" if it would use sips URI and ;transport=tcp.

Elegant is a subjective and it hardly justifies such change, we need
more hard evidence supporting such change.

> NOTE: In fact, some existing clients (as the widely extended PJSIP)
> would fail if the Record-Route contains sips+transport=tcp as I've
> reported today:
>  http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-July/013102.html
>
> This is because PJSIP does not understand at all the meaning of a sips
> schema (ugly in a so widely deployed SIP stack).

One can hardly blame them, I don't understand sips either ;-).

-Jan

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