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

[Olle E. Johansson]

5 jul 2011 kl. 20.01 skrev Martin Hoffmann:

> Juha Heinanen wrote:
>> Martin Hoffmann writes:
>> 
>>> I think the upshot of it all is that there is no more transport=tls. If
>>> you want TLS, you have to do use the sips scheme with transport=tcp; if
>>> you want DTLS, you do sips with transport=udp.
>> 
>> i don't agree with the above.
> 
> If I understand things correctly, the above is the intent of the
> standardization body in charge of SIP.
> 
>> for example, no matter which transport a
>> request arrives to a proxy, the next hop proxy may be only reachable
>> over tls, in which case i would use ;transport=tls.
> 
> Well, you shouldn't. You should use transport=tcp, because that is the
> transport protocol you are using. That you want this encrypted is
> indicated by the sips scheme of your SIP URI. Also, if you next hop is
> only reachable via TLS and, yet the transport parameter and schema
> indicate unencrypted TCP, what stops you from using the TLS connection
> you have?
> 
> Only the opposite is a problem because you would degenerate the
> security status of your transmission and that is prohibited by the sips
> scheme.

I disagree. SIPS and SIP with "transport=tls" are two different things.
RFC 3261 deprecated "transport=tls" but it is widely agreed on SIPit testings that we have no other way to handle some situations.

Quoting RFC 5630:

      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.

   The "tls" parameter has not been eliminated from the ABNF in
   [RFC3261], Section 25, since the parameter needs to remain in the
   ABNF for backward compatibility in order for parsers to be able to
   process the parameter correctly.  The transport=tls parameter has
   never been defined in an RFC, but only in some of the Internet drafts
   between [RFC2543] and [RFC3261].

   This specification does not make use of the transport=tls parameter.

   The reinstatement of the transport=tls parameter, or an alternative
   mechanism for indicating the use of the TLS on a single hop in a URI,
   is outside the scope of this specification.

   For Via header fields, the following transport protocols are defined
   in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-
   SCTP".

So "transport=tls" is still in need of clarification...

/O