Subject: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...?

From: Bruce Atherton <[email-masked]>
Date: Wed, 05 Jan 2011 10:31:12 -0800

On 22/12/2010 9:25 AM, Pat McManus @Mozilla wrote:
> With that in mind I want to ask everyone if they think an approach based
> on Get+Upgrade containing mandatory client->server XOR masking meets the
> bar of an acceptable and good web sockets protocol.

I've never understood the asymmetry of this poll. I'm not seeking to 
block forward progress here, but perhaps someone could explain it to me.

The reason I'm confused is that, as a bidirectional protocol, it seems 
perfectly reasonable to use Websockets for peer to peer communications. 
If I have two nodes in a cluster and they are communicating with 
Websockets, which is the client and which is the server? If the one that 
opens the connection is the client, does that mean that if, in the 
future, applications are developed where servers initiate Websocket 
connections to browsers, then they will be the client and the browser 
will be the server? What does that do to the security guarantees you are 
looking for?

Perhaps the intention is that Websockets are never used for peer to peer 
connections, or that we fake a client in that situation. But it seems a 
lot of complication, and what is the gain? That servers have their load 
reduced? They still have to unmask all those incoming messages, and as I 
showed in the web portal usecase, the server may be a Websocket client 
for far more connections than it is a server. Yes, you get sendfile() 
from server to client as a result. But if, instead, the server had a way 
of optionally turning off masking in a frame when needed (there I go 
again) then you could get that in cases where it mattered.

Again, I'm not looking to hold anything up here. I think that the 
language of the straw poll should be adopted and put into the draft (so 
if it matters, here is a +1). There is far too much resistance here to 
letting things into the spec IMHO. It should be much easier to get 
changes in, even if they are later reversed. But at the same time, I 
hope that this poll does not rule out further discussion on what 
"mandatory" and "client->server" means.

> * It accomplishes this at reasonable cost
>    + masking is unidirectional and favors the server end. I've worked on
> servers in the past and right now I'm working on a browser and I really
> do believe that is the right trade off. A browser is much more
> interested in latency than in overall load scaling, while a server has
> real concerns about the latter. making sendfile() useless to the browser
> is no big deal - it doesn't help with latency when compared to IP time
> scales and the client is less likely to have the kind of data that would
> be zero copied anyhow.

---

From: John Tamplin <[email-masked]>
Date: Wed, 5 Jan 2011 13:35:25 -0500

On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton <[email-masked]> wrote:

> perfectly reasonable to use Websockets for peer to peer communications. If I
> have two nodes in a cluster and they are communicating with Websockets,
> which is the client and which is the server? If the one that opens the
> connection is the client, does that mean that if, in the future,
> applications are developed where servers initiate Websocket connections to
> browsers, then they will be the client and the browser will be the server?
> What does that do to the security guarantees you are looking for?

> connections, or that we fake a client in that situation. But it seems a lot
> of complication, and what is the gain? That servers have their load reduced?
> They still have to unmask all those incoming messages, and as I showed in
> the web portal usecase, the server may be a Websocket client for far more
> connections than it is a server. Yes, you get sendfile() from server to
> client as a result. But if, instead, the server had a way of optionally
> turning off masking in a frame when needed (there I go again) then you could
> get that in cases where it mattered.
>
> Again, I'm not looking to hold anything up here. I think that the language
> of the straw poll should be adopted and put into the draft (so if it
> matters, here is a +1). There is far too much resistance here to letting
> things into the spec IMHO. It should be much easier to get changes in, even
> if they are later reversed. But at the same time, I hope that this poll does
> not rule out further discussion on what "mandatory" and "client->server"
> means.
>

AFAIK, there has been no discussion of allowing a server to initiate a
connection to the client.  In many cases, it isn't even possible to do so,
and it isn't clear security administrators would want every browser on their
network essentially becoming a server.  If you control both ends, then why
do you need WebSocket at all, rather than just using TCP directly?

In any case, it seems allowing such usage is beyond the current scope.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Jerod Venema <[email-masked]>
Date: Wed, 5 Jan 2011 13:48:40 -0500

On Wed, Jan 5, 2011 at 1:35 PM, John Tamplin <[email-masked]> wrote:

> On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton <[email-masked]>wrote:
>

Long time reader, first time posting...hi everyone :)

I can see plenty of valid use cases for peer-to-peer WebSockets. One in
particular that's come up for me recently is video streaming (for, say, live
video conferencing) directly in a browser. It'd be great to be able to use
peer-to-peer communication under this scenario - reduce lag, overhead, etc.

> In any case, it seems allowing such usage is beyond the current scope.

Whether or not it's in scope is a different question, but there are clearly
use-cases for it.

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

-- 
Jerod Venema
Frozen Mountain Software
http://www.frozenmountain.com/
(w) 919-300-5141
(c) 919-368-5105

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jan 2011 10:54:30 -0800

This is a related, but different problem. See:
http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00

-Ekr

On Wed, Jan 5, 2011 at 10:48 AM, Jerod Venema <
[email-masked]> wrote:

>>> language of the straw poll should be adopted and put into the draft (so if
>>> it matters, here is a +1). There is far too much resistance here to letting

---

From: Scott Ferguson <[email-masked]>
Date: Wed, 05 Jan 2011 11:03:49 -0800

John Tamplin wrote:
> On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton <[email-masked] 
> <mailto:[email-masked]>> wrote:

> If you control both ends, then why do you need WebSocket at all, 
> rather than just using TCP directly?

Because many messaging protocols need a framing layer and a standard 
basic framing protocol is a useful thing. Instead of every application 
rolling its own framing protocol (and API and network layer), people 
writing their messaging protocol can concentrate on the messages and 
leave the network stuff and framing to a common library.

It's basic layered software design.

(Server to browser is a whole different issue that is well beyond the 
scope of WebSockets, besides being a security nightmare.)

-- Scott

> ------------------------------------------------------------------------
>

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 05 Jan 2011 11:49:24 -0800

On 05/01/2011 10:35 AM, John Tamplin wrote:
> connection to the client.

Ok, forget about server to browser. Sorry I mentioned it, since it 
complicates the question about peer to peer.

> In any case, it seems allowing such usage is beyond the current scope.

It is fine if people want to declare that Websockets is a client/server 
protocol only. Like Scott, I would prefer to be able to reuse a 
Websockets library in peer to peer applications and have it take care of 
a bunch of details so I don't have to reinvent the wheel. But if you 
guys want to declare that Websockets is client/server only, then  fine. 
I'll just have to find another bidirectional protocol to use.

But I think a decision should be made whether to allow for peer to peer 
in the design because it has an effect on how this asymmetrical 
communication should be done.

---

From: John Tamplin <[email-masked]>
Date: Wed, 5 Jan 2011 15:07:54 -0500

On Wed, Jan 5, 2011 at 2:49 PM, Bruce Atherton <[email-masked]> wrote:

> protocol only. Like Scott, I would prefer to be able to reuse a Websockets
> library in peer to peer applications and have it take care of a bunch of
> details so I don't have to reinvent the wheel. But if you guys want to
> declare that Websockets is client/server only, then  fine. I'll just have to
> find another bidirectional protocol to use.
>
> But I think a decision should be made whether to allow for peer to peer in
> the design because it has an effect on how this asymmetrical communication
> should be done.
>

Since much of the contentious things about WebSockets comes about precisely
because of its requirements of being used by browsers running untrusted code
and reusing existing HTTP infrastructure, it seems unlikely you would want
to use all of WebSockets for something that did not have those requirements.
 If you want to re-use the framing, that is fine, and you can simply say
that you use the unmasked framing for both sides of your application.

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 05 Jan 2011 16:26:31 -0800

On 05/01/2011 12:07 PM, John Tamplin wrote:
>
> Since much of the contentious things about WebSockets comes about 
> precisely because of its requirements of being used by browsers 
> running untrusted code and reusing existing HTTP infrastructure, it 
> seems unlikely you would want to use all of WebSockets for something 
> that did not have those requirements.  If you want to re-use the 
> framing, that is fine, and you can simply say that you use the 
> unmasked framing for both sides of your application.

Unfortunately, as I said before, that is fine if you control your 
infrastructure. But not all of us are deploying in environments that are 
set up by design to allow the free exchange of protobufs. A bastardized 
version of Websockets will not pass through any intermediaries that 
unmask and remask, and will fill the error logs of any that peek into 
the frames to do things like analytics or logging or filtering.

It sounds like there is a laser focus of scope for the hybi working 
group on just the interactions between browser and server, and that any 
other usecase need not apply. If that is the case, I will stop bringing 
up considerations of other situations such as standalone clients, the 
server being the client to another server, or two peers communicating 
with Websockets, since they all appear to be out of scope for the WG.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Jan 2011 10:43:39 +0100

On 6 January 2011 01:26, Bruce Atherton <[email-masked]> wrote:
> It sounds like there is a laser focus of scope for the hybi working group on
> just the interactions between browser and server, and that any other usecase
> need not apply. If that is the case, I will stop bringing up considerations
> of other situations such as standalone clients, the server being the client
> to another server, or two peers communicating with Websockets, since they
> all appear to be out of scope for the WG.

Bruce,

a difficulty of this working group is that we were never able to even
agree on a requirement document as the various constituencies
suspected each other of steering the requirements towards their own
use-cases. Hence it is difficult to really say what is in scope or out
of scope.

But I for one certainly appreciate you raising cases that push the
boundaries of this WG's scope, as good design results from
consideration of edge cases.

My own work with cometd certainly already has peer to peer usage, we
have a sub-project called the Oort cloud that links up cometd servers
into a cluster.  Currently this uses our long polling transport, but
once we implement WS support in our java client, then WS would be a
much better choice.

We also have many examples in the cometd project of standalone (non
browser) clients being written - in phones and on desktop
applications.  Again most of these would benefit from a WS transport.

Neither of these use-cases run potentially hostile 3rd party code (as
browsers do), so are at much less risk from injection of HTTP-like
content.

While I dubious about the actual level of threat posed by vulnerable
intermediaries, I fully support the browser vendors interest in
avoiding the issue and believe that mandatory masking is a good
solution for the browsers.   I just don't understand why that means
that masking must be made mandatory for all other use cases.  If
browsers don't want the ability to switch it off - then don't write
your code so that it can be switched off.

regards

---

From: Brodie Thiesfield <[email-masked]>
Date: Fri, 7 Jan 2011 00:24:47 +1000

Opera already support peer to peer HTTP (or peer-proxy-peer) via
Unite. I would think that it is a small logical step for them to
implement peer to peer websocket as well.
http://unite.opera.com/develop/faq/

Peer to peer websocket would enable a whole range of interesting
applications, and I don't think that it is that far fetched that it
cannot be imagined in the future.

Regards,
Brodie

---

From: Toni Ruottu <[email-masked]>
Date: Thu, 6 Jan 2011 19:39:13 +0200

Greetings.

I work for the University of Helsinki. We have drafted an API for
embedding WebSocket servers in web pages, and implemented the draft in
a Firefox extension. See http://browsersocket.org/ for details.

  --Toni