[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Taskforce                                 N. Wilson
Internet-Draft                                              RealVNC Ltd.
Intended status: Informational                          October 07, 2013
Expires: April 10, 2014

Use of the WebSocket Protocol as a Transport for the Remote Framebuffer


   The Remote Framebuffer protocol (RFB) enables clients to connect to
   and control remote graphical resources.  This document describes a
   transport for RFB using the WebSocket protocol, and defines a
   corresponding WebSocket subprotocol, enabling an RFB server to offer
   resources to clients with WebSocket connectivity, such as web-

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 10, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Wilson                   Expires April 10, 2014                 [Page 1]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Overview of the WebSocket Protocol as a stream transport    3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Interaction with the WebSocket Protocol . . . . . . . . . . .   4
     3.1.  The "Sec-WebSocket-Protocol" header . . . . . . . . . . .   4
     3.2.  Close Frames  . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Data Frames . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Versioning Considerations . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Registration of the RFB WebSocket Subprotocol . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  Origin checking . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Data authentication and integrity . . . . . . . . . . . .   8
     6.3.  Creating a Safe JavaScript Environment  . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

1.1.  Background

   _This section is non-normative._

   The WebSocket Protocol [RFC6455] provides a reliable, full-duplex,
   message-oriented transport.  The opening handshake is formatted as an
   HTTP request and response, enabling access to resources through
   intermediaries obeying HTTP semantics, such as proxies.  This enables
   resources served over a WebSocket-based transport to be accessible to
   all web user-agents.

   In addition, although untrusted websites cannot be given a mechanism
   to make arbitrary TCP connections, web-browsers are able to offer web

Wilson                   Expires April 10, 2014                 [Page 2]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

   resources such as JavaScript scripts the ability to make arbitrary
   connections using the WebSocket protocol.  The initial HTTP-formatted
   handshake is performed by the user agent rather than the untrusted
   web resource, and it conveys origin context, unlike a TCP handshake.
   The web-browser is therefore able to allow pages to open WebSocket
   connections, without opening up remote access to servers on the local
   network, because WebSocket servers are able to check the origin
   passed by the browser.

   Therefore, offering RFB resources over a WebSocket-based transport
   opens access to a variety of applications such as web pages, which
   are unable to use the TCP transport described in The RFB Protocol

   The purpose of defining a WebSocket subprotocol is firstly to give
   endpoints a clear way to indicate how the RFB stream is mapped to
   WebSocket frames, ensuring compatible transport of the stream by
   using an agreed mapping.  Secondly, using a WebSocket subprotocol
   enables multiple services to run at once on a single server.
   Services which run over TCP/IP commonly use a port number allocated
   for each service to enable multiple listening services on one
   machine, but the behaviour of HTTP proxies makes it likely that
   WebSocket servers will commonly be run only on ports 80 and 443.  The
   WebSocket subprotocol mechanism is analogous to the port number
   system of IP addressing, but uses a short string naturally associated
   with the service for identification, rather than an allocated number.

1.2.  Overview of the WebSocket Protocol as a stream transport

   _This section is non-normative._

   The RFB Protocol [RFC6143], section 7 explains that the protocol may
   operate over any reliable stream- or message-oriented transport, but
   only describes the RFB protocol as a stream of octets.  This gives a
   clear mapping for the TCP/IP transport, but for message-oriented
   transport layers, the encapsulation of the RFB octet-stream must be

   In this document, the WebSocket subprotocol for RFB is defined to
   place no importance on the message boundaries of the WebSocket layer.
   Instead, WebSocket messages are concatenated to form an octet stream
   in each direction.

   This is firstly because some RFB messages may be large, such as those
   containing pixel data, and it may be a significant burden to some
   client to require these to be processed as a single message.  The
   WebSocket API [WSAPI] requires clients to buffer the fragments of the
   WebSocket message until the entire message has been received.

Wilson                   Expires April 10, 2014                 [Page 3]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

   Although the RFB server and any WebSocket-aware proxy can fragment
   the message as it chooses, a client application such as a mobile web-
   browser would have to consume several megabytes of memory to satisfy
   the requirements of the WebSocket API, if an RFB FramebufferUpdate
   message could not be split across multiple WebSocket messages.

   Secondly, it is advantageous to RFB servers to be able to wrap the
   RFB stream in WebSocket messages flexibly.  As well as being a
   convenience to implementors of RFB servers, it also enables WebSocket
   connectivity to be added to legacy software using a proxy.  Without
   requiring knowledge the protocol, a generic proxy may be used which
   concatenates WebSocket messages received from the WebSocket client to
   send over TCP to the RFB server, and reads bytes from the RFB server
   and sends them to the client via WebSocket messages.

2.  Definitions

   RFB client, server, endpoint:  As defined in The RFB Protocol
      [RFC6143], section 1.  An RFB endpoint is an RFB client or server.

   WebSocket client, server, endpoint:  As described in The WebSocket
      Protocol [RFC6455], section 1.2.

   RFB WebSocket subprotocol:  The WebSocket subprotocol (described in
      [RFC6455] section 1.9) which acts as a transport for the RFB
      Protocol, as described in this document.

   RFB WebSocket client, server, endpoint:  An RFB client, server, or
      endpoint respectively which is also a WebSocket client, server, or
      endpoint and uses the RFB WebSocket subprotocol as the RFB

3.  Interaction with the WebSocket Protocol

   The WebSocket Protocol contains a number of features not present in
   TCP.  These are discussed here in turn, and their interpretation by
   RFB entities conforming to the RFB WebSocket subprotocol.

3.1.  The "Sec-WebSocket-Protocol" header

   The WebSocket Protocol [RFC6455] section 4, "Opening Handshake",
   describes the use of the "Sec-WebSocket-Protocol" header to indicate
   negotiation of a WebSocket subprotocol.  The requirements of this
   section as described by the key words "MUST", "SHOULD", and so on,
   are not superseded by use of the RFB WebSocket subprotocol.  A
   WebSocket client aware of the RFB WebSocket subprotocol may choose to
   request the subprotocol by including the token "rfb" in the "Sec-
   WebSocket-Protocol" header in its request.  A WebSocket server aware

Wilson                   Expires April 10, 2014                 [Page 4]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

   of the RFB WebSocket subprotocol may choose to respond to such a
   request by including a "Sec-WebSocket-Protocol" header in its
   response containing the token "rfb".

   The interpretation of any data following the opening WebSocket
   handshake is determined by the subprotocol in effect, if any.  If the
   RFB WebSocket subprotocol was not requested by the client or was not
   selected by the server, then this document does not place any
   interpretation on the subsequent data.  In particular, if a client
   requests any subprotocol but the server not include it in its
   response, the client cannot assume any particular meaning for the
   data that follows.  This is because WebSocket servers may ignore
   requests for any unknown subprotocols and proceed, and in practice
   are expected to do so.  If the WebSocket client requires use of a
   particular subprotocol, it is its responsibility to close the
   connection if use of the subprotocol was not successfully negotiated.

   The RFB WebSocket subprotocol does not place any restrictions on use
   of the subprotocol alongside WebSocket extensions.  The effect of any
   such extensions is outside the scope of this document.

3.2.  Close Frames

   When the RFB WebSocket subprotocol is in use, the status code and
   reason of any WebSocket Close frames relate only to the WebSocket
   transport, not the RFB stream using the transport.  The WebSocket
   connection will normally be closed by a status code 1000 ("Normal
   Closure") or 1001 ("Going Away").  Any status code or reason sent by
   the WebSocket client or server SHOULD NOT convey RFB-specific
   information.  No status codes in the private use range 4000-4999 are
   defined by this subprotocol.  No mapping is provided between
   WebSocket Close frame status codes and the strings used in RFB Close

   Any RFB-specific close data MAY be conveyed using an appropriate RFB
   message.  For example, in the case of an RFB authentication failure,
   the close condition may be conveyed using an RFB SecurityResult
   message as appropriate, after which the WebSocket connection may be
   closed using a Close frame status code indicating success.  As long
   as there were no errors in the transport, the WebSocket Close frame
   does not use a status code indicating failure, even though the RFB
   connection failed to be established, because the RFB error was
   conveyed as application data over the WebSocket transport.

   The meaning of any status codes used in Close frames MUST refer to
   the state of the WebSocket protocol, for status codes defined in the
   WebSocket Protocol and any subsequent versions, or other status codes
   registered by the IANA in the Close Code Number Registry.  For

Wilson                   Expires April 10, 2014                 [Page 5]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

   example, the status code 1002 ("Protocol Error") describes errors in
   the WebSocket protocol and not an error in the RFB stream carried by
   the transport.

3.3.  Data Frames

   The RFB octet-stream is transported using Data frames with opcode 0x2
   (Binary).  When the RFB WebSocket subprotocol is in use and no
   WebSocket extensions are in use, WebSocket clients MUST send RFB data
   using Binary messages.

   RFB WebSocket subprotocol does not specify any multiplexing of
   connections or interleaving of data with other streams.  Where no
   WebSocket extensions are in use, RFB WebSocket clients MUST use
   Binary messages exclusively for RFB data, such that the octets from
   the ordered stream of Binary WebSocket messages when truncated
   conform with the description given in the RFB Protocol [RFC6143].

   The frame boundaries do not have to be aligned in any way with the
   RFB stream.  RFB WebSocket endpoints, when receiving messages, MUST
   NOT vary their behaviour based on the framing of the RFB stream using
   WebSocket messages.  It is suggested that RFB WebSocket endpoints
   avoid sending empty messages, and that endpoints impose a suitable
   limit on the size of the messages they send to avoid placing
   unnecessary load on clients.

   The interpretation of Text messages (with opcode 0x1) is unspecified.
   RFB WebSocket endpoints SHOULD NOT send Text messages, but if a
   WebSocket extension is in use which uses these messages they may be
   sent.  An RFB WebSocket client receiving such a message SHOULD fail
   the WebSocket connection (as defined in section 7.1.7 of [RFC6455])
   except where any method has been used to negotiate a meaning for
   these messages.

4.  Versioning Considerations

   The RFB WebSocket subprotocol is identified by the token "rfb".  This
   token contains no version component, since the RFB protocol is
   already versioned in its initial handshake.  The definition of this
   subprotocol makes no reference to the specific format of messages in
   RFB 3.8, so is applicable to subsequent versions of the RFB protocol.

5.  IANA Considerations

   RFC Editor Note: Please set the RFC number assigned for this document
   in the sub-sections below and remove this note.

Wilson                   Expires April 10, 2014                 [Page 6]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

5.1.  Registration of the RFB WebSocket Subprotocol

   This specification describes a WebSocket subprotocol registered in
   the WebSocket Subprotocol Name Registry defined in [RFC6455], section
   11.5.  This registration supersedes the prior registration for "rfb"
   referencing [RFC6143].

   Subprotocol Identifier:  "rfb"

   Subprotocol Common Name:  RFB

   Subprotocol Definition:  RFC??? (this document)

6.  Security Considerations

6.1.  Origin checking

   Using the WebSocket protocol as a transport presents fresh
   challenges, since the connections can be created by untrusted
   resources which originate outside the local subnetwork and have
   traversed any firewalls in place.  This differs from TCP connections.
   For example, an RFB server accessible over TCP on the local
   subnetwork may be configured on the assumption that connections
   originate inside the trusted subnet, and this assumption may be
   enforced using a firewall.  To make a connection, any client has to
   have already gained access to the subnet.

   This is not the case for a RFB server accepting connections over the
   WebSocket protocol.  The WebSocket protocol is specifically designed
   so that it is safe to allow untrusted resources to make connections,
   on the assumption that WebSocket servers carefully enforce any
   applicable restrictions on the origin of content.  In the TCP
   example, the RFB server does not need to enforce the restriction that
   connections originate inside the subnet, is this is implemented by
   the firewall.  However, a web-browser running on a machine in the
   subnet may open up WebSocket connection based on scripts loaded from
   any source at all on a web page, originating outside the subnet.  The
   web-browser is only able to allow the script to do this on the basis
   that the Origin header it sends conveys enough information for the
   WebSocket server to apply any policies and decide if the connection
   is to be accepted.

   Therefore, any WebSocket server implementers must carefully consider
   the implications of opening up access to resources via the WebSocket
   Protocol.  Any WebSocket server must act as its own firewall, since
   it receives essentially unfiltered connections from the public
   Internet.  In the case of an RFB server which is accessible over TCP
   as well as the RFB WebSocket subprotocol, the TCP connection may be

Wilson                   Expires April 10, 2014                 [Page 7]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

   hidden behind a firewall or NAT or for any other reason may be not
   publicly accessible on the Internet.  In this case, the origin
   restrictions in place for the TCP connections should be also enforced
   by the WebSocket server implementation, or else clearly documented in
   such a way that administrators of the software do not misunderstand
   the scope of who can connect in to the server.

   Unless all WebSocket software that runs in a LAN environment is
   implemented to enforce these restrictions, web-browser vendors may
   not be able to justify permitting untrusted web resources
   (JavaScript) to make WebSocket connections.

6.2.  Data authentication and integrity

   Where applicable, the Secure WebSocket Protocol (using the WebSocket
   Protocol over TLS [RFC5246]) may be used.  However, it is not
   practicable in all circumstances to provision many dynamically-run
   RFB servers on a LAN with a certificate which browsers can verify, so
   implementors may choose to use an unencrypted WebSocket connection,
   but authenticate the server at the application level using an
   encrypting RFB Security Type, verifying the peer using identities
   known to the RFB client rather than the browser.

   Therefore, use of TLS is encouraged alongside other mechanisms
   including secure RFB Security Types.  It is strongly recommended that
   one of these two mechanisms is used to provide authentication of the
   server, and integrity and confidentiality of RFB data.

6.3.  Creating a Safe JavaScript Environment

   Many of the RFB clients using WebSockets are likely to be implemented
   in JavaScript and executed by web-browsers.  In this case,
   implementors must be aware of the difficulties of executing
   JavaScript in a safe context.  Banners and other resources loaded
   alongside the page may substitute functions into top-level objects
   and subvert the security of the connection or skim passwords.  When
   implementing any application which prompts for a user's password or
   sends and receives data which may be sensitive, the application must
   be loaded from a safe context, such as a web page served over HTTPS,
   and which loads no untrusted external resources.  Certain operations
   required for encryption, such as secure random number generation, may
   require browser support such as the Web Cryptography API [WCAPI].

Wilson                   Expires April 10, 2014                 [Page 8]

Internet-Draft        The RFB WebSocket Subprotocol         October 2013

7.  Acknowledgements

   Thanks to Pierre Garnero of Visteon for feedback during drafting.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6143]  Richardson, T. and J. Levine, "The Remote Framebuffer
              Protocol", RFC 6143, March 2011.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

8.2.  Informative References

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [WCAPI]    Dahl, D., Ed. and R. Sleevi, Ed., "Web Cryptography API,
              W3C Working Draft", June 2013.

   [WSAPI]    Hickson, I., Ed., "The WebSocket API", April 2013.

Author's Address

   Nicholas Wilson
   RealVNC Ltd.
   Betjeman House, 104 Hills Road
   Cambridge  CB2 1LQ

   Phone: +44 1223 310411
   Email: ncw@realvnc.com

Wilson                   Expires April 10, 2014                 [Page 9]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/