Subject: [sipcore] Proposal for a new SIP transport (WebSocket)

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 14:29:42 +0200

Hi all,
A draft describing a mechanism for usage of WebSocket protocol as a
new transport between SIP entities was submitted to rtcweb WG on 13
Sep 2011. However the discussions on that list seemed to conclude that
the draft was interesting but outside the scope of rtcweb. Since the
draft describes a new transport for SIP it makes more sense to propose
it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether
the proposed draft could fit well in this WG.
There are some aspects of the draft that will be addressed in a new
revision (as mandating Outbound support given the nature of the
WebSocket protocol). The first revision of the draft can be found at:
http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/
--------------------------------Abstract
  This document specifies a WebSocket subprotocol for a new transport
in SIP (Session Initiation Protocol).  The WebSocket protocol enables
two-way realtime communication between clients (typically web-based
applications) and servers.  The main goal of this specification is to
integrate the SIP protocol within web
applications.------------------------------

This new SIP transport could fit well within a RTCweb architecture
(since RTCweb does not mandate the in-the-wire protocol nor the format
of the messages exchanged between RTCweb clients and servers). This is
just an use case, a future revision of the draft could incorporate
more use cases.

A presentation of the proposed specification (including a video with
running code) can be found at:

http://sip-on-the-web.aliax.net/
-------------------------------Introduction
  The aim of this presentation is to show the SIP protocol working
within a web browser and interoperating with any SIP network.
  After some slides describing the used technology there is a
signaling flowchart and a video showing a real
implementation.-------------------------------

Please let us know whether this draft would fit well in SIPCORE or may
be we would do better by proposing it in DISPATCH.
Thanks a lot.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 14:42:40 +0200

Hi, let me resend the the mail since I had a problem with my text editor:

--------------------------------
Abstract

  applications.
------------------------------

This new SIP transport could fit well within a RTCweb architecture
(since RTCweb does not mandate the in-the-wire protocol nor the format
of the messages exchanged between RTCweb clients and servers). This is
just a use case, a future revision of the draft could incorporate more
use cases.

-------------------------------
Introduction

  After some slides describing the used technology there is a
  signaling flowchart and a video showing a real implementation.
-------------------------------

Thanks a lot.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 14:59:09 +0000

I think this is a really good idea and provides benefits even for SIP clients which are not Javascript-based or in the browser - i.e., it's a useful transport even for native SIP client applications. 

Is there time in the SIPCORE WG meeting slot in Taipei to have this draft presented?

Also, I think SIPCORE is the right WG.

-hadriel

I think SIPCORE is the right place for this.

On Oct 28, 2011, at 8:42 AM, Iñaki Baz Castillo wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 17:12:01 +0200

> I think this is a really good idea and provides benefits even for SIP clients which are not Javascript-based or in the browser - i.e., it's a useful transport even for native SIP client application…

Indeed I expect that WebSocket will be widely used by native
applications in smartphones.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 11:57:01 -0400

> Is there time in the SIPCORE WG meeting slot in Taipei to have this draft presented?

Generally we want to condition meeting discussion on prior list 
discussion. So get busy discussing on the list.

> Also, I think SIPCORE is the right WG.

Me too. AFAIK a final decision hasn't been made of which WG, but I'm ok 
with discussing it on sipcore for now.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 30 Oct 2011 15:51:09 +0200

On 10/28/11 6:12 PM, Iñaki Baz Castillo wrote:
> 2011/10/28 Hadriel Kaplan<[email-masked]>:
I concur, it is a great idea.

> applications in smartphones.
I am sure WebSocket is and it will become even more a success (but I am 
biased here...)

/Sal

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 17:07:45 +0000

On Oct 28, 2011, at 11:57 AM, Paul Kyzivat wrote:

> Generally we want to condition meeting discussion on prior list discussion. So get busy discussing on the list.

OK, well I had directly emailed Iñaki some comments on the draft.  Some of them were nits around terminology, and re-writing the daft to be more centered around Websocket being another transport type for SIP, rather than as a Javascript-app.

At a high-layer, I can't see anything preventing this from being another transport type.  There're some things to decide once you get into the bits/bytes/details, but I don't think any of them are insurmountable.

But one question is if it should be a complete/first-class transport type like TCP, UDP, and SCTP - i.e., just another transport that could even be used between proxies.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 18:21:49 +0100

> But one question is if it should be a complete/first-class transport type like TCP, UDP, and SCTP - i.e., just another transport that could even be used between proxies.

Well, honestly I see no use case for using WebSocket transport between
SIP proxies/servers. WebSocket is clearly a transport for web browsers
and also for client applications. There is no advantage in using
WebSocket between other SIP nodes.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 13:51:31 -0400

[As individual]

Iñaki,

Thanks for submitting this. Its a good start. I saw a few things that 
need some investigation:

Section 6:

The requirement to use sips for the contact uri if the connection to the 
server is secure via wss will force all other hops to be secured too. So 
the server can only connect to another client that has established a wss 
connection with a sips contact, or to another sip server via a sips URI. 
This ought to be spelled out. (Its violated in an example.)

The constructed contact address is not globally reachable - it can only 
be reached through the server. And there mention of gruus, which is a 
solution to that problem. How to address this needs further discussion.

Section 7:

When the server is trying to route requests, how can it determine which 
addresses correspond to a particular websocket? This is a form of 
connection reuse, which has been addressed by RFC 5626 (outbound) and 
RFC 5923. Note that there was much effort to make 5923 define connection 
reuse over TCP, but no safe way was found and it was abandoned.)

There needs to be a careful analysis of the security aspects of reusing 
the connection for outbound requests. And then it will likely result in 
updating RFC 5630 (sip-sips) and RFC 3261 regarding sips.

Section 9.2:

Shows sending to a sips URI using UDP, which isn't permitted.

I may have more comments later, but that's all for now.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 19:08:09 +0100

2011/10/31 Paul Kyzivat <[email-masked]>:
> Iñaki,
>
> Thanks for submitting this. Its a good start. I saw a few things that need
> some investigation:
>
> Section 6:
>
> server is secure via wss will force all other hops to be secured too. So the
> server can only connect to another client that has established a wss

First of all let me say that I plan to remove "sips" schema from the
draft (given the ammount of issues with "sips" mechanism).

However, the remote peer (using SIP over UDP so "sip" scheme) never
contacts a SIP node speaking "sips", but "sip". The proxy adds two
Record-Route, the the UDP peer always contacts the URI in the
Record-Route with "sip" schema and UDP protocol.

> The constructed contact address is not globally reachable - it can only be
> reached through the server. And there mention of gruus, which is a solution
> to that problem. How to address this needs further discussion.

Indeed, for a new revision of the draft I plan to make Outbound
mandatory for WebSocket clients so there is no need for "discovering
the local IP address".

I also have to add a modification to RFC 3261:

When a proxy/server receives a request via WebSocket transport, it MAY
choose not to add the ";received" param in the top Via. This is
because WebSocket is supposed to use already existing infrastructure
in which there can be certain number of HTTP or TCP load balancers
between the client and HTTP/WebSocket server, so the server would
write into ;received the IP of the load balancer in front of it. This
would reveal the client the internal HTTP/TCP topology of the server
which could be insecure.

So adding ;received to Via would be a local policy decision.

> addresses correspond to a particular websocket?

As said above, Outbound should be mandatory for WebSocket client and
their outbound proxies (Outbound EDGE proxies). Of course, there could
be no outbound proxy but a single proxy/registrar (in this case it
must also implement Outbound).

So for determining which addresses correspond to a particular
websocket the proxy MUST perform RFC 5626 procedures (by inspecting
the token flow in the Route header).

My current implementation does it and works perfectly. The same as for
TCP/TLS/UDP clients.

> This is a form of connection
> reuse, which has been addressed by RFC 5626 (outbound) and RFC 5923. Note
> that there was much effort to make 5923 define connection reuse over TCP,
> but no safe way was found and it was abandoned.)

If I'm not wrong, we are done with Outbound.

> There needs to be a careful analysis of the security aspects of reusing the
> connection for outbound requests. And then it will likely result in updating
> RFC 5630 (sip-sips) and RFC 3261 regarding sips.

But using Outbound is enough, am I right? This is, I've coded a strict
implementation of Outbound in my proxy speaking WebSocket and I'm not
aware of security concerns.

> Shows sending to a sips URI using UDP, which isn't permitted.

But the top Route is "sip", so the destination of the request is a
"sip" URI rather than "sips". Is it still invalid? I need
clarification on this.

> I may have more comments later, but that's all for now.

Really thanks a lot for your comments. I will address of all them in a
new revision of the draft.

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 19:01:29 +0000

> WebSocket between other SIP nodes.

I'm not sure I see one either, but I think I can manufacture possible use-cases:
1) Since websocket has an HTTP layer to create the "transport" for the application/SIP layer, you can use the HTTP digest/challenge mechanism as a transport-layer authentication scheme.  For example, a proxy/B2BUA generating a new websocket connection to another proxy can be challenged in HTTP - without confusion as to whom the challenge is for, as is sometimes the case when the challenge is in a SIP response.  I.e., it would be a single-hop proxy-proxy digest/challenge mechanism.  Mutual-TLS obviates the need for that generally, but mutual-TLS isn't always available/practical.

2) Since websocket can cross even restrictive firewalls, you could use a piece of proxy-ish software on your laptop like SER or Asterix or SipXecs or whatever.  I have no idea why you'd want to run those from behind a restrictive firewall, or why you couldn't configure the firewall to let you do it, instead of using websocket; but if you needed to, you could use websocket.

But yeah those aren't very compelling.  I'm ok with making it a client-specific thing, similar to (and probably based on) Sip-Outbound.  I just think we need to decide, one way or the other.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 20:15:42 +0100

> 1) Since websocket has an HTTP layer to create the "transport" for the application/SIP layer, you can use the HTTP digest/challenge mechanism as a transport-layer authentication scheme.  For exampl…

Unfortunately authentication in WebSocket is not defined at transport
layer (or at HTTP layer during the initial HTTP handshake). So
regardless it uses HTTP for the handshake, the client will not react
if it receives a HTTP 401/407 response. In fact, the WebSocket JS API
does not include functions or callbacks for handling ah HTTP response
other than 101.

In the other side, a WebSocket HTTP handshake can contain a Cookie
header (like in normal HTTP). This is supposed to be used as
authentication/authorization (assuming that the web browser previously
navigated a web page with same domain and got a Cookie).

Any other kind of authentication must be done at application level (so
within the custom WebSocket Subprotocol implemented on top of the
WebSocket transport).

Given this, I don't want to enter on how to authenticate a WebSocket
connection. In fact, my implementation does not ask for authentication
to the WebSocket client. Instead, it checks a HTTP GET query param
(imagine it as a "license key") and when a SIP request arrives via
WebSocket, the proxy routes it to the main proxy which asks for
authentication (401/407) as usual. So I don't ask for authentication
in my WebSocket capable SIP proxy. Of course, this is up to the
developer/admin, and therefore I think it's better not to mention it
in the draft.

> 2) Since websocket can cross even restrictive firewalls, you could use a piece of proxy-ish software on your laptop like SER or Asterix or SipXecs or whatever.  I have no idea why you'd want to run…

Huh... that's really freak :)

> But yeah those aren't very compelling.  I'm ok with making it a client-specific thing, similar to (and probably based on) Sip-Outbound.  I just think we need to decide, one way or the other.

IMHO the draft should be focused on WebSocket clients (web browsers or
other client applications), but there is no problem at all in leaving
the door open in the draft for those who want to use WebSocket between
other SIP entities.

Regards.

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 31 Oct 2011 15:37:15 -0400

> From: Iñaki Baz Castillo [[email-masked]]  
> 

It sounds like WebSocket paths are effectively a variant of the
connection between the UA and the Edge Proxy in SIP Outbound (RFC
5626), and what they need is a "flow token" (defined by the edge
proxy), not a new Via transport value (standardized).

> From: Hadriel Kaplan [[email-masked]]  
> 
> 2) Since websocket can cross even restrictive firewalls, you could use
> a piece of proxy-ish software on your laptop like SER or Asterix or
> SipXecs or whatever.  I have no idea why you'd want to run those from
> behind a restrictive firewall, or why you couldn't configure the
> firewall to let you do it, instead of using websocket; but if you
> needed to, you could use websocket.

Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP
packets in HTTP requests/responses as a way to get through restrictive
firewalls?

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 19:44:03 +0000

On Oct 31, 2011, at 3:15 PM, Iñaki Baz Castillo wrote:

> if it receives a HTTP 401/407 response.

draft-ietf-hybi-thewebsocketprotocol-17, section 4.1:
   1.  If the status code received from the server is not 101, the
       client handles the response per HTTP [RFC2616] procedures, in
       particular the client might perform authentication if it receives
       401 status code, the server might redirect the client using a 3xx
       status code (but clients are not required to follow them), etc.

section 4.2.2:
   2.  The server can perform additional client authentication, for
       example by returning a 401 status code with the corresponding
       WWW-Authenticate header field as described in [RFC2616].

Do those not mean what I thought they meant?

> In fact, the WebSocket JS API

But I'm not talking about what a Web browser might expose to a Javascript API - I'm talking about websocket as a SIP transport layer.  

Obviously we'll want to enable using websockets from a bowser's Javascript too - but I'm only talking about a use-case of proxy-to-proxy above, which doesn't care about browser-specific uses.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 20:48:33 +0100

> proxy), not a new Via transport value (standardized).

I agree, and that's the reason for which I plan to mandate Outbound in
the draft.

> not a new Via transport value (standardized).

This is a new SIP transport, so IMHO a new Via transport value is required.

Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 19:50:35 +0000

> packets in HTTP requests/responses as a way to get through restrictive

Yup, and I was seriously debating whether to send an email to the IETF-discuss malling list suggesting draft-ietf-hybi-thewebsocketprotocol-17 should actually either officially update or deprecate RFC 3093, when the draft was put for IETF Last Call not long ago.  But I thought doing so might backfire on me someday so I chickened out. :(

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 20:51:18 +0100

> Do those not mean what I thought they meant?

Yes, you are right. However I invite you to test a WebSocket
connection from the latest Chrome or Firefox (which implement the last
version of websocket draft-17) against a WebSocket server that returns
a 401 :)

> Obviously we'll want to enable using websockets from a bowser's Javascript too - but I'm only talking about a use-case of proxy-to-proxy above, which doesn't care about browser-specific uses.

Sure. I agree. So that could added to the draft as a possible
authentication mechanism.

Thanks.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 15:52:52 -0400

Iñaki,

On 10/31/11 2:08 PM, Iñaki Baz Castillo wrote:
> 2011/10/31 Paul Kyzivat<[email-masked]>:
>> Iñaki,
>>

Well, if you remove the use of sips, then all issues related to use of 
sips will go away. :-)

But I got the impression that you wanted use of wss to force use of a 
secured connection e2e. sips is the only thing we have that comes close 
to providing that.

> Record-Route with "sip" schema and UDP protocol.

The intent of sips is that every hop, e2e, is sips over tls.
Double R-R doesn't eliminate that requirement.

> mandatory for WebSocket clients so there is no need for "discovering

OK. If your intent is to require use of outbound then that answers a 
lot. Then we will have to ensure that it all integrates with outbound.

> So adding ;received to Via would be a local policy decision.

This seems like a real hack. If there is a problem to deal with here I 
hope it can be abstracted.

> the token flow in the Route header).

Again, clarifying that use of outbound is intended answers many questions.

> If I'm not wrong, we are done with Outbound.

Its an RFC, if that is what you mean.
I wasn't suggesting it wasn't.
Clearly you needed some form of connection reuse here - either outbound 
or 5923. I was saying that 5923 doesn't work for you. I was guessing you 
were intending outbound, and now that is clear.

> aware of security concerns.

Again, use of outbound resolves much.

> "sip" URI rather than "sips". Is it still invalid? I need

See above.

> new revision of the draft.

You are welcome.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 20:54:31 +0100

> Yup, and I was seriously debating whether to send an email to the IETF-discuss malling list suggesting draft-ietf-hybi-thewebsocketprotocol-17 should actually either officially update or deprecate…

Note that WebSocket is more than just a IP tunnel opened with HTTP. It
enforces the way in which data is transferred between client and
server by mandating frame masking from client to server, it also
defines a message boundadry protocol on top of TCP and a WebSocket
subprotocol negotiation during the initial handshake.

This is needed in order to avoid that a malicius JavaScript sends raw
binary/text data over a TCP connection (imagine you visit a web page
and the JS code open a TCP connection with a SMTP server and sends
SPAM) :)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 1 Nov 2011 04:57:26 +0100

2011/10/31 Paul Kyzivat <[email-masked]>:
> Well, if you remove the use of sips, then all issues related to use of sips
> will go away. :-)
>
> secured connection e2e. sips is the only thing we have that comes close to
> providing that.

Ok. So I will leave "sips" schema which in the context of WebSocket
transport requires WebSocket over TLS ("wss" schema in the WebSocket
URI connection of the client).

However, nobody prevents a WS client to establish a WSS connection but
use "sip" schema on top of it (as RFC 5630 section-3.1.3 states).

> Double R-R doesn't eliminate that requirement.

Ok. IMHO "sips" is just impossible to work since a proxy adding a
"sips" schema must use a domain in the Record-Route, and such domain
could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the
pach for in-dialog requests and that's critical when Outbound is being
used. However this is another history out of the scope here.

> OK. If your intent is to require use of outbound then that answers a lot.
> Then we will have to ensure that it all integrates with outbound.

Sure :)

> This seems like a real hack. If there is a problem to deal with here I hope
> it can be abstracted.

Let's assume that:

- A SIP Websocket client is a real client (not a proxy or server).
- The spec will require Outbound so ;received and ;rport is 100%
useless (even more when the server cannot try the IP in
;received/;rport for sending a response in case the connection is
closed since a WebSocket client does not listen for incoming
connections).

So IMHO it's clear that ;received is useless in SIP over WebSocket,
and it can reveal server internal infrastructure to the client. So,
what can we do here? IMHO the SIP WebSocket server/proxy should be
able not to set the ;received param given the above rationale.

Thanks a lot.

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