Subject: [hybi] Connection Strategy

From: John Fallows <[email-masked]>
Date: Mon, 4 May 2009 13:21:25 -0700

Folks,

As promised, this "Connection Strategy" thread is the first of our
focused IETF discussions outlined previously.

o Connection strategy (now)
o Proxy traversal strategy (next)
o Wire protocol (after that)

The overall goal for this thread is to define a connection strategy
that can be used by future browsers for full-duplex, bidirectional
communication, while integrating with the browser security model.
This connection strategy discussion does not cover any details of the
specific bytes on the wire after the connection has been established,
and is therefore post-connection protocol agnostic.  Hopefully, the
connection strategy would be sufficiently general-purpose to apply
beyond the browser usecase as well.

I plan to present a discussion of the requirements for the connection
strategy, my understanding of the available alternatives and a logical
conclusion based on the preceding analysis.

The browser security model defines the trust boundary between
different code served by different "origin" servers.  The origin
concept is defined by HTML5 [1] as follows:

"The origin of a resource and the effective script origin of a
resource are both either opaque identifiers or tuples consisting of a
scheme component, a host component, a port component, and optionally
extra data."

The Cross-Origin Resource Sharing specification [2] relaxes the
same-origin request constraint by defining an opt-in cross-origin
communication strategy that uses the "Origin" HTTP header.

The rationale for relaxing the same-origin request constraint for HTTP
resources applies equally well to bidirectional communication, which
seems well-matched by an HTTP-based "Origin" header connection
strategy.

There are a number of different bidirectional communication connection
strategies available, such as:
  o crossdomain.xml + separate raw TCP connection
  o HTTP Upgrade in-band to raw TCP
  o Multiple HTTP requests representing independent upstream and downstream
  o Multiple HTTP requests representing overlapping upstream and
downstream (BOSH)

Are there other connection strategies worth considering here?

Note: Using a non-HTTP protocol such as XMPP or BEEP to establish
communication is not a separate connection strategy as it would fall
under crossdomain.xml with separate TCP connection.

In-band upgrade from HTTP to raw TCP (remember discussion of specific
protocol bytes sent over TCP comes later) has some
potentially-significant security benefits over separate control and
data channels such as crossdomain.xml.  The concept of domain is
equivalent to origin but without the port, which can introduce an
attack vector for virtual hosting environments where different users
may have control over different ports.  In this case, the trust model
assumed by the plug-in runtime does not match the trust model enforced
at the server.  In-band upgrade from HTTP using "Origin" header forces
these trust models to match scheme, host and port.

When an in-band HTTP Upgrade is successful, the server responds with a
101 Switching Protocols status code, as specified by RFC2616, section
10.1.2.

"The server understands and is willing to comply with the client's
request, via the Upgrade message header field (section 14.42), for a
change in the application protocol being used on this connection. The
server will switch protocols to those defined by the response's
Upgrade header field immediately after the empty line which terminates
the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so.
For example, switching to a newer version of HTTP is advantageous over
older versions, and switching to a real-time, synchronous protocol
might be advantageous when delivering resources that use such
features."

Using multiple different HTTP requests to provide full-duplex
bidirectional communication is a necessary compromise for today's
browser implementations, and is still subject to the HTTP 2 connection
limit recommended by RFC2616, section 8.1.4 Practical Considerations
[3].  A single post-connection TCP stream makes more efficient use of
the network, and gives us the most flexibility in designing the wire
protocol framing for future browser implementations, and seems to be
more general purpose for use by non-browser clients.

In conclusion, an HTTP Upgrade with Origin header strategy seems to do
a good job of balancing the requirements.

Looking forward to a fun and productive discussion.

Kind Regards,
John Fallows

[1] http://dev.w3.org/html5/spec/Overview.html#origin
[2] http://www.w3.org/TR/access-control/
[3] http://www.ietf.org/rfc/rfc2616.txt

--
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 05 May 2009 13:51:41 +1000

John,

I don't mean to be disruptive to your good attempt to
bring some order to the wide ranging discussions here....

but...

I've relabelled this phase "Message Strategy", because
I don't think we can assume that connections are the
starting point of this discussion.

The references that you cite discuss origins and cross domain
as they apply to individual resources - not connections.
HTTP allows resources from different origins to
be transported over the same connection (proxies).

With HTTP, every client to server message semantically
has it's own URL, and thus it's own origin/domain.

With WebSocket, there is only a single origin/domain
that is associated with an entire connection.

I don't we should assume either model and should have
a discussion about which of these (or other models)
we prefer.  Indeed some may advocate streaming rather
than messaging.

It is a later transport discussion when we can discuss
how messages might relate to connections etc.

-------------

For my contribution to messaging strategy:

I advocate messaging over streaming because streamed
data is essentially small messages at the quantum of bytes
or bits.     The arguments for streaming and against messaging
are essentially transport discussions about the efficiency of
appropriate framing.  So let's defer that discussion (and if
we have lots of 1 bytes messages, then the framing can be
designed to match that).

I advocate messaging over connection based abstraction
because making connections a non-transport
issue can be very limiting.

For example, assuming a single origin per connection limits
multiplexing and it would not be possible to offload bidirectional
SSL to dedicated hardware that terminated all the SSL connections
and forwarded messages to the server over fewer connections.

Another example is a mashup page that contains javascript
from multiple origins, but all of them wish to establish
bidirectional communications with the same cross domain.
If we assume connection semantics, then multiple connections
will be required to the same server just to convey the
multiple origins involved.

I'm not opposed to specific transports being developed
that do allow origin and domain to be assumed for all
messages on a connection (and thus not have to send them),
but that is a transport efficiency issue and not something
that should be part of the central design of the communications
paradygm.

I agree with John that the definition of Origin should
be adopted from his [1] reference.  This implies that
each message has an associated URL.

I think the cross domain access control referred to in
[2] should also be closely followed where appropriate -
although some of it is very request/response oriented.

This needs to be extended to unrequested messages
that are sent.  So for example, if every message
from sent from a server has an associated set
of allowed origins, then the user-agent can ensure
that the message is not delivered to code from
a non allowed origin.

While it could be a non-trivial expense to have
the list allowable list of origins with every
message -  I see this as a transport concern to
potentially find efficient way (perhaps by
association with  a connection) to optimize this.

So semantically, it is the message that has
the allowed origins - but it may be that those
are transported by association with a connection
or they may be transported with per message
meta data.

cheers

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