Subject: [hybi] Multiple connections serialization and proxies

From: Wellington Fernando de Macedo <[email-masked]>
Date: Wed, 21 Apr 2010 15:51:30 -0300

Hi,

A question has been raised in the Mozilla implementation. The spec
states:

1. If the user agent already has a WebSocket connection to the
remote host (IP address) identified by /host/, even if known by
another name, wait until that connection has been established or
for that connection to have failed.

However, when the WS is under proxies, we can't leak the host names to
the DNS server. In this case, what should be done? I think the spec
should clarify this.

Wellington.

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Thu, 22 Apr 2010 15:49:16 -0300

Hi again,

We (Ian, Christian Biesinger and me) have talked about this issue.
We've decided that, when
under proxies, Mozilla's
implementation will serialize the connections using the host names.

Ian, can you update the spec accordingly, please?

Wellington.

Em 21/4/2010 15:51, Wellington Fernando de Macedo escreveu:

Hi,

Wellington.

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Thu, 22 Apr 2010 15:50:18 -0300

Thanks :)

Em 22/4/2010 15:49, Wellington Fernando de Macedo escreveu:

Hi again,

under
proxies, Mozilla's

Wellington.

Hi,

Wellington.

---

From: Christian Biesinger <[email-masked]>
Date: Thu, 22 Apr 2010 21:24:07 +0200

Note that if you want websockets to be similar to HTTP, it should
always use host names instead of IP addresses for connection limits.
At least Firefox uses hostnames for HTTP's limit, I'm not quite sure
on the other browsers.

-christian

On Thu, Apr 22, 2010 at 8:49 PM, Wellington Fernando de Macedo
<[email-masked]> wrote:
> Hi again,
>
> We (Ian, Christian Biesinger and me) have talked about this issue. We've
> decided that, when under proxies, Mozilla's implementation will serialize
> the connections using the host names.
>
> A question has been raised in the Mozilla implementation. The spec states:
>
> However, when the WS is under proxies, we can't leak the host names to the
> DNS server. In this case, what should be done? I think the spec should
> clarify this.
>
> Wellington.
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 23 Apr 2010 06:49:12 +0800

This raises a point that needs to be highlighted, particularly for the BWTP on WS proposal:

If connections are identified purely by the domain name of the host, and re-used based solely on that name, then no other state can be accumulated against that connection.

This includes the sub-protocol details, any state like common headers (BWTP uses channels to isolate this, so it might be OK), and all application-layer state tied to the connection.

The only state that can be established is that that could be considered invariant for the life of the connection and it's many (potential) uses.

For instance,

App A establishes WS connection to example.com with sub-protocol foo.

App B requests WS connection to example.com also, but with sub-protocol bar.  It cannot signal this sub-protocol use to example.com if it re-uses the connection established by App A.

Similarly, if App A establishes state on the connection (for example, using one of the BWTP channel headers), then this state could interfere with state that B attempts to establish:

App A logs in and sets the user name to 'alice'.  App B logs in and sets the user name to 'bob'.  Are requests that follow authorized based on alice's permissions, or bob's?

Keep in mind that applications will assume that this 'connection' is theirs to use.  In many cases, the connection will be dedicated, and will persist, so how will the proverbial 'inexpert' server developer know how to cope with an unexplained error like this?

This is made even worse if an intermediary attempts (legitimately) to multiplex streams...

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Biesinger
> Sent: Friday, 23 April 2010 5:24 AM
> To: Wellington Fernando de Macedo
> Cc: [email-masked]
> Subject: Re: [hybi] Multiple connections serialization and proxies
> 
> We've

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 22 Apr 2010 23:54:48 +0100

> This is made even worse if an intermediary attempts (legitimately) to multiplex streams...

All of that is moot provided the reuse/multiplexing is done properly.

That is, with application-visible properties such as sub-protocol
being per virtual connection, not per real connection.

Inexpert server authors (and client authors) will not negotiate these
features, and won't have to deal with it.

-- Jamie

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 23 Apr 2010 07:04:28 +0800

> All of that is moot provided the reuse/multiplexing is done properly.

Given the absence of a mechanism for doing that, I'd say not.  Sure, in a hypothetical protocol that has the concept of 'virtual connections' or channels or the like, this IS moot.

But I was talking about draft-hixie-thewebsocketprotocol-75.

--Martin

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 23 Apr 2010 00:05:00 +0100

> At least Firefox uses hostnames for HTTP's limit, I'm not quite sure

I agree with this.  This HTTP client behaviour is useful, and
independent WebSocket service providers should not be penalised by
interference with unrelated services just because their hosting
provider decides to share IP addresses among different customers.

That way would put pointless pressure on the IP address space, the
opposite of what is achieved with HTTP by Host now.

That said, there is a case for a finite but higher connecting-state
concurrency limit per IP, to resist connection-setup DOS attacks where
a wildcard DNS is used by the attacker.  If implemented, this should
probably coordinated with HTTP somehow, not a WebSocket-only feature.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 23 Apr 2010 00:09:57 +0100

> Given the absence of a mechanism for doing that, I'd say not.  Sure, in a hypothetical protocol that has the concept of 'virtual connections' or channels or the like, this IS moot.

You did specifically say it will be a problem when something reuses a
connection or when a proxy multiplexes.  Clearly -if- those things are
ever done, then just do them properly.

Did I misunderstand and you meant something else?

> But I was talking about draft-hixie-thewebsocketprotocol-75.

No, you referred to concerns about connections being reused by two
different apps, and about proxies multiplexing - neither of which
appear in that document.

Either that or it's been radically changed since I read an earlier
version

-- Jamie

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 23 Apr 2010 07:18:53 +0800

> ever done, then just do them properly.

There is currently no mechanism described that would allow either party (browser or server) to identify virtual connections.

Thus, there is no way to do this "properly".
 
> different apps, and about proxies multiplexing - neither of which

I was talking about the concrete proposals that exist (even if Greg's isn't on the ietf servers yet), and I'm sorry if there was an implication to the contrary.

To be honest, all this theoretical discussion, while occasionally a pleasant distraction, doesn't contribute much to progress.  I'd really like to see some concrete proposals.
 
> Either that or it's been radically changed since I read an earlier

No, it hasn't.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 23 Apr 2010 01:18:58 +0100

> Thus, there is no way to do this "properly".

Correct, there is no mechanism, but also no need for one since reuse
and multiplexing don't occur.  If they're added, a virtual connection
mechanism will be at the same time.

> I was talking about the concrete proposals that exist (even if
> Greg's isn't on the ietf servers yet), and I'm sorry if there was an
> implication to the contrary.

Ok.  The various proposals include, (perhaps implicitly at this
stage), mechanisms for handling your concerns about credentials and
subprotocols from different applications on the same connection.

Those concerns are one of the reasons why transport and application
protocol negotiations should be independent.

It's still an important thing to get right in those proposals so
thanks for bringing it up.

-- Jamie

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 23 Apr 2010 08:58:34 +0800

> mechanism will be at the same time.

I think that I misread the referenced section.

Just re-read it.

So, the only protection against multi-connection-DOS from the one client is to request that the client not have more than one connection attempt in progress at a time.

This only works if the client doesn't get rejected straight away, otherwise, the round trip time is the only limiting factor, which isn't that great.

Some (security considerations) advice on what a server might do to take advantage of the client-side requirement would be good.

--Martin

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 23 Apr 2010 09:48:02 +0200

Martin,

You are correct in noting that the DOS protection is simply to
serialized connections.

However, one of the prime victims of this would be any application
that needs multiple "connections"  to/from the server.  We've seen from
the SPDY analysis that RTT is on the critical path for rendering
webpages, so *IF* multiple websocket connections are to be encouraged,
then this serialization could potentially be a significant latency
on some applications.

My preference would be to enable the use of a single connection
with multiplexing - so that multiple "connections" would not need to
suffer the cost of any RTT for TCP, TLS etc. and would certainly
not need to be serialized with other "connections" establishment.

As you and Jamie have pointed out, this would need to be done
properly, by which I mean:
 + no imposition on minimal implmentations of websocket.
 + equal semantics to dedicated connection websocket.
 + transparent to websocket API users.

cheers

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 23 Apr 2010 11:37:15 +0100

Thomson, Martin wrote:
> So, the only protection against multi-connection-DOS from the one
> client is to request that the client not have more than one
> connection attempt in progress at a time.
> 
> This only works if the client doesn't get rejected straight away,
> otherwise, the round trip time is the only limiting factor, which
> isn't that great.

It's intended to limit the number of connections in progress at the
server, rather than limit the rate at which they occur, I guess.
They are two different dimensions of DOS: memory vs. bandwidth.

Once the number is limited, the bandwidth can be limited by
the server itself slowing down responses when it see repeated
requests from the same client IP.

Unfortunately it can't distinguish different clients from the same IP
- so clients can DOS other clients if the server does this, which is
also a problem.

Therefore clients should identify themselves somehow.  (Clients could
cheat, but cheating clients won't obey the anti-DOS requirements
anyway.)

Another aspect of client-side DOS protection is at what point is the
"connection" considered "established", to permit more?  It should be
later rather than earlier in the negotiation process, to prevent DOS
against server-side negotiation resources especially TLS.  But as Greg
says, the initial number allowed without further permission should be
greater than 1.

I favour the server being able to send back a number saying how many
more connections are permitted now.  Negotiated flow control, rather
than spec'd fixed values (except the first).  There could still be a
default, for simple implementations.

-- Jamie