Re: [Sip] Using TLS in the first hop - Bug in RFC 5630

[Iñaki Baz Castillo <[e-mail]>]

2011/9/16 Horvath, Ernst <[e-mail]>:
> Well, I read RFC 3261 differently. 8.1.2 says:
>
>   Otherwise, the procedures are applied to the first Route header field
>   value in the request (if one exists), or to the request's Request-URI
>   if there is no Route header field present.  These procedures yield an
>   ordered set of address, port, and transports to attempt.  Independent
>   of which URI is used as input to the procedures of [4], if the
>   Request-URI specifies a SIPS resource, the UAC MUST follow the
>   procedures of [4] as if the input URI were a SIPS URI.
>
> This behaviour overrides the transport indicated in the Route header if
> the Request-URI is SIPS. And it applies to mid-dialog requests as well.
> BTW, RFC 5630 has some text on your original point:
>
> 5.1.1.2.  SIPS in a Dialog
>
>   If the Request-URI in a request that initiates a dialog is a SIP URI,
>   then the UAC needs to be careful about what to use in the Contact
>   header field (in case Record-Route is not used for this hop).  If the
>   Contact header field was a SIPS URI, it would mean that the UAS would
>   only accept mid-dialog requests that are sent over secure transport
>   on each hop.  Since the Request-URI in this case is a SIP URI, it is
>   quite possible that the UA sending a request to that URI might not be
>   able to send requests to SIPS URIs.  If the top Route header field
>   does not contain a SIPS URI, the UAC MUST use a SIP URI in the
>   Contact header field, even if the request is sent over a secure
>   transport (e.g., the first hop could be re-using a TLS connection to
>   the proxy as would be the case with [RFC5626]).

Hi, this definitely tells me that SIPS and TLS is impossible, but just
in the case of full TLS in the whole path.

I insist on the bug I've reported for RFC 5630: If the client sets a
SIP Contact URI and sends the request using TLS, then it would receive
incoming in-dialog requests via UDP or TCP, but not TLS. This does not
make sense as the caller could use just SIP over TLS, and in case of
NAT this would never work as the proxy/server could never send a TCP
or UDP request to the client.

So IMHO SIPS and TLS is broken and it can only work when the full path
is secure (which is unfeasible in most of the environments). This
needs a rework, or maybe Olle is right and we should use
;transport=tls (with SIP schema), ;transport=tls-sctp and so on.

-- 
Iñaki Baz Castillo
<[e-mail]>