Subject: Re: [hybi] -09: handshake

From: Alexey Melnikov <[email-masked]>
Date: Fri, 08 Jul 2011 17:02:08 +0100

Peter Saint-Andre wrote:

>Here are some comments on Section 5, again mostly editorial...
>
>Section 5.1 uses the terms "/resource name/" whereas Section 3 uses the
>term "resource-name".
>
I will try to clarify.

>Section 5.1 talks about a "/secure/ flag" but that term is not used in
>Section 3. Perhaps modify the latter to say:
>
>   The URI is called "secure" (and it said that "the secure flag is
>   set") if the scheme component matches "wss" case-insensitively.
>
>Change "may" to "MAY" in this sentence...
>
Changed.

>   Clients running in controlled environments, e.g. browsers on mobile
>   handsets tied to specific carriers, may offload the management of the
>   connection to another agent on the network.
>
>It's not clear to me what we mean by "another agent". Is this, for
>example, separate software that runs on the same handset as the
>WebSocket, an application provided by the handset manufacturer or
>service provider that the handset client interacts with via an API, some
>kind of third-party service, or any of the above?
>  
>
All of the above. I am not convinced that that needs clarifying, I think 
the text is clear as is.

>There are a few confusing phrases and long sentences here:
>
>       If the client cannot determine the IP address of the remote host
>       (for example because all communication is being done through a
>       proxy server that performs DNS queries itself), then the client
>       MUST assume for the purposes of this step that each host name
>       refers to a distinct remote host, and should instead limit the
>       total number of simultaneous connections that are not established
>       to a reasonably low number (e.g., in a Web browser, simultaneous
>       pending connections to a.example.com and b.example.com would be
>       allowed, but if thirty connections are requested, that may not be
>       allowed.  The limit should consider the number of tabs the user
>       has open.
>
>I suggest:
>
>       If the client cannot determine the IP address of the remote host
>       (for example because all communication is being done through a
>       proxy server that performs DNS queries itself), then the client
>       MUST assume for the purposes of this step that each host name
>       refers to a distinct remote host.  Instead, the client SHOULD
>       limit the total number of simultaneous pending connections to a
>       reasonably low number (e.g., the client might allow simultaneous
>       pending connections to a.example.com and b.example.com, but
>       might not allow thirty simultaneous pending connections to
>       various hosts).  In a Web browser context, the client SHOULD
>       consider the number of tabs the user has open in setting a limit
>       to the number of simultaneous pending connections.
>  
>
I've used the following variation of your text, which I think is more 
correct:

          If the client cannot determine the IP address of the remote host
          (for example because all communication is being done through a 
proxy
          server that performs DNS queries itself), then the client MUST
          assume for the purposes of this step that each host name 
refers to a
          distinct remote host, and instead the client SHOULD limit the 
total number of
          simultaneous pending connections to a reasonably
          low number (e.g., the client might allow simultaneous pending 
connections
          to a.example.com and b.example.com, but if thirty simultaneous 
connections
          to a single host are requested, that may not be allowed).
          In a Web browser context, the client SHOULD consider the 
number of tabs the user
          has open in setting a limit to the number of simultaneous 
pending connections.

>I have one nit and one concern with this text:
>
>       NOTE: This makes it harder for a script to perform a denial of
>       service attack by just opening a large number of WebSocket
>       connections to a remote host.  A server can further reduce the
>       load on itself when attacked by making use of this by pausing
>       before closing the connection, as that will reduce the rate at
>       which the client reconnects.
>
>Nit: change "by making use of this by pausing before closing the
>connection" to "by pausing before closing the connection".
>
>Concern: this specification says nothing about the reconnection logic.
>  
>
While your suggestion might be a good idea, I would like to hear more 
feedback from the WG.

>You might adapt some of the text from Section 3.3 of RFC 6120:
>
>###
>
>3.3.  Reconnection
>
>   It can happen that an XMPP server goes offline unexpectedly while
>   servicing TCP connections from connected clients and remote servers.
>   Because the number of such connections can be quite large, the
>   reconnection algorithm employed by entities that seek to reconnect
>   can have a significant impact on software performance and network
>   congestion.  If an entity chooses to reconnect, it:
>
>   o  SHOULD set the number of seconds that expire before reconnecting
>      to an unpredictable number between 0 and 60 (this helps to ensure
>      that not all entities attempt to reconnect at exactly the same
>      number of seconds after being disconnected).
>
>   o  SHOULD back off increasingly on the time between subsequent
>      reconnection attempts (e.g., in accordance with "truncated binary
>      exponential backoff" as described in [ETHERNET]) if the first
>      reconnection attempt does not succeed.
>
>###
>
>A question about this text:
>
>       Servers
>       can refuse to accept connections from hosts with an excessive
>       number of existing connections
>
>Do we mean "hosts" here or instead "clients" or "IP addresses"?
>  
>
I've changed "hosts" to "host/IP addresses" (I assume the former comes 
from some reverse DNS lookup). I don't think "client" is going to be 
useful, because in a general case the server can't tell if it is talking 
to the same client or not. (Hmm, unless the client is using the same TLS 
certificate or something like this.)

But anyway, this text is informative and I think leaving it as is or 
adding "IP addresses" is good enough.

>   3.  _Proxy Usage_: If the client is configured to use a proxy when
>       using the WebSocket protocol to connect to host /host/ and/or
>       port /port/, then the client SHOULD connect to that proxy and ask
>       it to open a TCP connection to the host given by /host/ and the
>       port given by /port/.
>
>Do we really mean "and/or"? I don't think you can connect to just a port. :)
>  
>
Changed.

>s/SOCKS/SOCKS5 [RFC1928]/
>
>s/[RFC3548]/[RFC4648]/
>
Updated.

>Please also specify which flavor of base64 (Section 4 or Section 5 of
>RFC 4648) and specify whether padding bits are included at the end of
>the block.
>
>It looks as if [I-D.ietf-websec-origin] is a normative reference, since
>we're taking the ABNF for the "Sec-WebSocket-Origin" from that spec.
>
Agreed.

>I don't think that should hold up publication of the WebSocket spec, but
>if you're worried about that then please provide reviews of the same
>origin spec on the WebSec list. :)
>
>https://www.ietf.org/mailman/listinfo/websec
>
>   10.  The request MAY include a header with the name "Sec-WebSocket-
>        Protocol".  If present, this value indicates the subprotocol(s)
>        the client wishes to speak, ordered by preference.
>
>Please specify that the subprotocols are provided in a comma-separated
>list. (And again in Section 5.2.1.)
>
>   Once the client's opening handshake has been sent, the client MUST
>   wait for a response from the server before sending any further data.
>
>I don't see anywhere a definition of the server's behavior (e.g., it
>MUST close the WebSocket if the client tries to send data before the
>server sends a response).
>
I don't think mandating that is a good idea. The client might pipeline 
its data in anticipation of successful outcome of the handshake. That 
was discussed on the mailing list.

>In Section 5.2.2...
>
>   At this point, the server may begin
>   sending (and receiving) data.
>
>I think at this point both parties (client and server) are allowed to
>send data, right?
>
Yes, but in general case the client doesn't know that until it reads the 
response to the handshake. So I suggest no change is needed.