Subject: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests

From: Brett Tate <[email-masked]>
Date: Thu, 14 May 2015 13:04:01 -0400

Hi,

Concerning RFC 7118, "wss" was not defined as a transport for SIP-URI.  If
dialog setup with "transport=ws" as a SIP-URI parameter within Contact or
Record-Route entry when the connection is actually secured using wss (such
as within RFC 7118 section 8.2 example), should wss continue to be used?
Based upon RFC 7118 section 8.2 example (such as ACK sent over wss), I
assume yes; however I didn't notice anything within RFC 7118 discussing
the topic.

Thanks,
Brett

P.S. Trying here since no reply received on sip-implementors.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 18 May 2015 17:52:38 +0200

> assume yes; however I didn't notice anything within RFC 7118 discussing

Hi, my opinion (based on so many old threads about secure SIP
transport, "tls" and "wss") is that this is not a specific issue in
RFC 7118, but in the whole "secure SIP design". The only way to
mandate a secure SIP full path is by using the sips schema, but sips
is just broken.

I'm pretty sure that the same issue reported here about "wss" also
applies to "tls". RFC 7118 does not attempt to make any change on this
subject.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Brett Tate <[email-masked]>
Date: Tue, 19 May 2015 09:36:53 -0400

Hi,

Thanks for the response.  Reply is inline.

> > Concerning RFC 7118, "wss" was not defined as a transport
> > for SIP-URI.  If dialog setup with "transport=ws" as a
> > SIP-URI parameter within Contact or Record-Route entry
> > when the connection is actually secured using wss (such
> > as within RFC 7118 section 8.2 example), should wss
> > continue to be used?  Based upon RFC 7118 section 8.2
> > example (such as ACK sent over wss), I assume yes; however
> > I didn't notice anything within RFC 7118 discussing the
> > topic.

Based upon recent discussion on sip-implementors, it sounds like errata
should be opened against the RFC 7118 section 8.2 example.  I haven't
noticed anything within RFC 7118 (or RFC 5626) which would allow Alice to
send ACK (for 2xx) using wss when the Record-Route entry indicated
transport=ws.

The errata would be to 1) fix the example, 2) add normative text to allow it
to be compliant, or 3) mention using a "local policy" to determine the
transport (which appears to comply with RFC 3261).

The following section 5.5 snippet potentially indicates why the example
doesn't rely upon NAPTR/SRV to continue to use wss.

"At the time this document was written, DNS NAPTR/Service Record
(SRV) queries could not be performed by commonly available
WebSocket client stacks (in JavaScript engines and web browsers)."

> Hi, my opinion (based on so many old threads about secure
> SIP transport, "tls" and "wss") is that this is not a
> specific issue in RFC 7118, but in the whole "secure SIP
> design". The only way to mandate a secure SIP full path is
> by using the sips schema, but sips is just broken.
>
> I'm pretty sure that the same issue reported here about
> "wss" also applies to "tls". RFC 7118 does not attempt to
> make any change on this subject.

I'm not sure that I understand the response.  RFC 5630 discusses the
transport=tls deprecation; I assume transport=wss was not added for similar
reasons.  Based upon the following thread, sips support doesn't appear to be
very common.  If not using sips, the RFC 7118 section 8.2 example would need
to supply a Record-Route entry which relies upon NAPTR/SRV usage to select
wss.

http://www.ietf.org/mail-archive/web/sipcore/current/msg06562.html

Thanks,
Brett

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 19 May 2015 15:48:09 +0200

> send ACK (for 2xx) using wss when the Record-Route entry indicated

http://tools.ietf.org/html/rfc5630#section-3.1.3

(note that RFC 5630 updates RFC 3261)

----------------
   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

   Using SIP over TLS is very simple.  A UA opens a TLS connection and
   uses SIP URIs instead of SIPS URIs for all the header fields in a SIP
   message (From, To, Request-URI, Contact header field, Route, etc.).
   When TLS is used, the Via header field indicates TLS.
----------------

So the client just needs to follow same criteria for the ACK (same
criteria it decided for sending the initial INVITE).

> The errata would be to 1) fix the example,

How? The example is valid according to RFC 5630 section 3.1.3 above.
One may suggest that the Record-Route added by the proxy should have
sips schema rather than sip, but that would be incorrect as sips means
"sips all the path".

> 2) add normative text to allow it

IMHO there is something to fix or properly document, but again: not an
issue in RFC 7118. The very same scenario would apply if you take
example 8.2 in RFC 7118 and replace "ws" with "tcp" and "WSS" with
"TLS".

It is the SIP secure transport mechanism what is broken.

> or 3) mention using a "local policy" to determine the

I expect that is already stated by RFC 5630 section 3.1.3. In any
case, I think that should be specified in that RFC..

> WebSocket client stacks (in JavaScript engines and web browsers)."

Neither RFC 5630 section 3.1.3 relies on DNS NAPTR/SRV records.

> reasons.

Yes.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Brett Tate <[email-masked]>
Date: Tue, 19 May 2015 14:38:07 -0400

Hi,

Thanks for the response; reply is inline.

> > Based upon recent discussion on sip-implementors, it sounds like
> > errata should be opened against the RFC 7118 section 8.2 example.  I
> > haven't noticed anything within RFC 7118 (or RFC 5626) which would
> > allow Alice to send ACK (for 2xx) using wss when the Record-Route
> > entry indicated transport=ws.
>
> So the client just needs to follow same criteria for the
> ACK (same criteria it decided for sending the initial INVITE).

AFAIK, that quote doesn't mean to disregard the RFC 3263 rules concerning
transport selection.

For instance concerning mid-dialog requests, I don't think that snippet
indicates that it is appropriate to attempt TLS when the Record-Route
SIP-URI contains port and transport TCP.  However, a local policy could
cause such behavior.

> How?

It looks like removing port 443 works; however it relies upon using SRV.

I actually like the example as it is.  I'm just not sure I'd be able to
defend the behavior since I think RFC 3263 indicates that it should cause
transport "ws" (instead of "wss") to be used.

> IMHO there is something to fix or properly document, but
> again: not an issue in RFC 7118. The very same scenario
> would apply if you take example 8.2 in
> RFC 7118 and replace "ws" with "tcp" and "WSS" with "TLS".

AFAIK, the mentioned replacement has the same issue.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 21 May 2015 16:26:15 +0200

> transport "ws" (instead of "wss") to be used.

Right, but as said in my other email, note that this is about an
Outbound connection which is supposed to remain open and reused for
all future requests. The problem is that, if the client follows RFC
5630 section 3.1.3 to send the initial INVITE there is no way for the
proxy to "let" the client reuse the same connection for in-dialog
requests, which breaks RFC 5626 somehow.

> AFAIK, the mentioned replacement has the same issue.

That's why I still think that the issue should not be placed at RFC
7118, but I may be wrong.

-- 
Iñaki Baz Castillo
<[email-masked]>