2011/7/5 I?aki Baz Castillo <ibc at aliax.net>:
> So, it's clear that PJSIP should use TLS if the topmost Route header
> of the locally generated request (i.e. ACK for 200) contains a "sips:"
> schema. Then the topmost Route URI transport could be "tcp" or could
> not exist (if it's "tls" then it's a bit ugly and depretated, so also
> use TLS as well).
>
> This is, a topmost Route with sips schema requires sending the request
> to the first hop using TLS, always.
I've been discussing this topic in kamailio maillist. My conclusion is
the following:
After re-checking RFC 2543, RFC 3261 and RFC 5630:
- In RFC 2543 "sips" schema does not exist, neither ";transport=tls".
The only it says is that a request can be sent via TLS by setting
"TLS" as Via transport:
RFC 2543 - 13.1.4 Hop-by-Hop Encryption
SIP requests and responses MAY also be protected by security
mechanisms at the transport or network layer. No particular mechanism
is defined or recommended here. Two possibilities are IPSEC [34] or
TLS [35].
- In RFC 3261 "sips" schema is defined and mandates SIP over TLS over
TCP (as neither SCTP over TLS or DTLS were defined in 2002, but leaves
the door open for using new secure mechanism when schema is "sips").
- RFC 3261 shows *NO* example of ";transport=tls", not al all, and it
clearly states that "sips" must be used.
- RFC 3261 just talks about "tls" in ;transport param in the BNF section:
transport-param = "transport=" ( "udp" / "tcp" / "sctp" / "tls"
/ other-transport )
and this is because (as RFC 5630 explains):
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].
- And RFC 3261 says:
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.
but in RFC 2543 there is no mention AT ALL to ";transport=tls",
neither "tls" is mentioned as a valid value for the URI transport
param. In fact, BNF in RFC 2543 says:
transport-param = "transport=" ( "udp" | "tcp" )
So after "re-reading" all the specifications (RFC 2543, RFC 3261 and
RFC 5630) it's fully CLEAR for me that using ;transport=tls is
*incorrect*. It seems that such value has been used in some drafts
between RFC 2543 and RFC 3261 (without including them!!). But since
RFC 3261 (which is what we use) there is no ;transport=tls at all. So
implementations should leave using it (because they are using
something that does not exist).
And of course, it's not good that a SIP implementation (as PJSIP)
understands something that it's not defined (as ;transport=tls) but
fails to understand the standard mechanism ("sips" schema with no
;transport or with ;transport=tcp).
Could you please consider it?
Regards.
--
I?aki Baz Castillo
<ibc at aliax.net>
