Re: [hybi] It's time to ship

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau <[e-mail]> wrote:

> Hello Ian,
>
> On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette
> (????????????????????????) wrote:
> > >  - you're using the OPTIONS method. The WG's consensus was voted as
> using
> > >    GET. While technically working, OPTIONS limits some possibilities
> since
> > >    no path is sent to the server.
> > >
> > >
> > I agree it is important to be able to identify between various resources
> on
> > a server. E.g. for our use, we will have multiple different websocket
> > endpoints, and we want our frontend to be able to dispatch to the
> > appropriate backend based on the information in the handshake. That said,
> I
> > think the draft allows for that (Sec-WebSocket-URL), or as pointed out on
> > another thread, it appears OPTIONS does allow for a path component. So, I
> > think we should be able to resolve that point.
>
> Once again,I'm not opposed at all to this point. I'd even say that would it
> not have been accepted as a consensus in the last poll, I'd probably have
> voted for it. It's just that it's a change from what was planned till now
> and participants need to express their opinion on that point.
>
> > >  - your proposal involves AES-128-CTR. As was discussed here, it seems
> > > there
> > >    are still export regulations for certain countries eventhough
> they're
> > >    apparently fading out. It could still be a problem for companies who
> > > want
> > >    to export products to some countries and which never had to put
> crypto
> > > in
> > >    them.
> > >
> >
> > It would be nice to understand if this is actually a hard constraint.
> > AES-128-CTR has the benefit of being well understood, as well as fast, as
> > demonstrated by Maciej in another thread. That said, I don't care
> strongly
> > one way or another here.
>
> One of my issue with it is that despite being fast, it's a lot slower than
> simpler masking. I design software components to be used at the border side
> of infrastructures to dispatch the traffic to multiple servers, and I'm
> very much concerned by the performance limitations. On a machine which has
> normally no issue processing 10 Gbps of HTTP, I could not even process 1
> Gbps
> of WebSocket with large contents. This is much concerning because it
> implies
> that in order to build the stream analysers we've talked about in the past,
> it will become mandatory to install expensive crypto acceleration cards.
> This
> is not logical for a protocol which is supposed to be transferred in clear
> (ws:// as opposed to wss://). Checking for forbidden words, dangerous links
> or forbidden contents on campus sites will be much more expensive due to
> this
> masking algorithm alone.
>
> > >  - several people on the list asked for the ability to be able to
> disable
> > >    the masking in some well-controlled environments (eg:
> server-to-server
> > >    communications). I see no provisions for this.
> > >
> > >
> > There's nothing that would prevent you from writing an extension that
> would
> > disable the masking, from my understanding.
>
> Adam did not seem favorable to that.
>
> > >  - it has not yet been stated whether only the payload or also the
> framing
> > >    should be masked. Your proposal masks both, which means that it
> > > definitely
> > >    blocks any possibility of performing multiplexing later. There does
> not
> > >    appear to have been a consensus in this area yet.
> > >
> > >
> > I'm not sure why this would block the possibility of multiplexing. I
> would
> > agree that would be a problem if it were the case. However, a number of
> the
> > early proposals for multiplexing included something like a stream-id in
> the
> > frame. This could still be present. Though it would be masked, so would
> the
> > length and other things that a meaningful intermediary would care about,
> so
> > assuming the intermediary was capable of un-masking, is this an issue?
>
> Yes, and you got the point : if the ID is masked, how to you know which
> stream it is in order to pick the right unmask key ? At least the stream
> ID will have to be unmasked. If we prepend it before the frame, it means
> a new framing format. Till not it was suggested to have it in the frame.
>
>
So, you're saying that with the XOR masking where the entire content
required to unmask the frame was included in the frame, it would be easier
for an intermediary to thus examine the frame? I agree that it would be
easier, and that in the AES method it would require an intermediary to be
"active" instead of "passive", e.g. terminate the connection at the
intermediary. I personally think that's a good argument towards XOR, but am
personally not heavily invested either way as I think for our uses, we would
be terminating at the "intermediary" anyways.


> > >  - Greg proposed to replace the MORE bit with a FIN bit so that the
> first
> > >    hello frame from the server starts with a high bit set, thus
> ensuring
> > >    that we can break the connection on non-HTTP compliant
> intermediaries
> > >    which would expect a second response after the 101.
> > >
> > >
> > The draft Adam sent out is based on an intermediate version I had checked
> > into SVN, back when it looked like we were gaining speed on CONNECT. I
> > didn't yet get around to flipping MORE/FIN, but I don't have any
> ojbections
> > to this.
>
> OK.
>
> > > Those are just a few notes, it's really not easy to changes :-/
> > >
> >
> > There's a tool on the IETF to diff drafts. I find it quite helpful, that
> > said, a lot of text has changed because I had already started to make
> other
> > requested changes (including trying to resolve the HTTP compliance issue,
> by
> > stating the requirements of the handshake rather than stating send X
> bytes,
> > send Y bytes, ...). This makes the diff a bit harder to interpret, for
> sure.
>
> Ah, OK. Till now I'd only use the automated diffs between incremental
> drafts,
> I did not know that there were other tools.
>
>
http://tools.ietf.org/rfcdiff :)


> Regards,
> Willy
>
>