idnits 2.17.1 draft-ietf-hybi-websocket-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-17) exists of draft-ietf-hybi-thewebsocketprotocol-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HYBI Working Group G. Montenegro, Ed. 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational March 14, 2011 5 Expires: September 15, 2011 7 HyBi WebSocket Requirements and Features 8 draft-ietf-hybi-websocket-requirements-02 10 Abstract 12 This document states the requirements of the WebSocket Protocol. The 13 goal of the document is to provide a stable base for protocol design 14 and related discussion. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 15, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 53 3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4 54 3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 6 55 3.2. WebSocket Server Requirements . . . . . . . . . . . . . . . 6 56 3.3. WebSocket Proxies Requirements . . . . . . . . . . . . . . 6 57 3.4. WebSocket Security Requirements . . . . . . . . . . . . . . 7 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Appendix A. Change Log (to be removed by RFC Editor before 65 publication) . . . . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 HTTP [RFC2616] is a client/server protocol, where the HTTP servers 71 store the data and provide it when it is requested by clients. When 72 used to retrieve data from an HTTP server, the client sends HTTP 73 requests to the server, and the server returns the requested data in 74 HTTP responses. So the client has to poll the server continuously in 75 order to receive new data. 77 Recently, techniques that enable bidirectional communication over 78 HTTP have become more pervasive. Those techniques reduce the need to 79 poll continuously the server thanks to the usage of HTTP hanging 80 requests and multiple connections between the client and the server 81 [I-D.ietf-hybi-design-space]. 83 The goal of HyBi is to provide an efficient and clean two-way 84 communication channel between client and server. 86 The communication channel will: 88 o Allow each side to, independently from the other, send data when 89 it is willing and ready to do so. 91 o Rely on a single TCP connection for traffic in both directions. 93 o Reduce the high overhead produced by HTTP headers in each request/ 94 response. 96 The goal of this work is to provide the set of requirements for the 97 WebSocket Protocol. 99 In the following sections we list and analyse the requirements from 100 the perspective of clients and servers. 102 2. Terminology 104 This document uses the following HyBi-related terms: 106 connection: A transport layer virtual circuit established between a 107 client and a server for the purpose of communication. 109 frame: The basic unit of WebSocket communication, consisting of a 110 structured sequence of octets matching the syntax defined in the 111 actual protocol and transmitted on the established communication 112 channel. 114 message: user message: a block of related data with identified 115 boundaries. A message may comprise multiple frames. 117 origin server: The server on which a given resource resides or is to 118 be created. 120 WebSocket handshake: The process (and associated capability 121 negotiation) that sets up the WebSocket communication channel. 123 WebSocket communication channel: After the WebSocket handshake is 124 complete, the resultant bi-directional communication path between 125 client and server over the transport (e.g., TCP, or SSL over TCP). 127 WebSocket sub-protocol: The negotiated sub-protocol for use on a 128 WebSocket communication channel that dictates framing, encoding, 129 etc. 131 2.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 3. WebSocket Requirements 139 The following requirements for the WebSocket Protocol have been 140 identified both in the HyBi wg input document 141 [I-D.ietf-hybi-thewebsocketprotocol] and in the HyBi mailing list 142 dicussion. 144 REQ. 1: The WebSocket Protocol MUST run directly on top of the 145 transport protocol (over which the communication was running up to 146 and including the WebSocket handshake). The transport protocol is 147 limited to TCP. 149 REQ. 2: The WebSocket Protocol MUST be able to handle (send and 150 receive) messages on the transport protocol (over which the 151 communication was running up to and including the WebSocket 152 handshake). 154 Reason: transfer data as message obviates the need for the receiver 155 to parse/handle partial content. 157 REQ. 3: The protocol MUST support the ability to fragment a message 158 into frames of a given length. 160 REQ. 4: It MUST be possible to send a message when the total size is 161 either unknown or exceeds a fixed buffer size. 163 Reason: This will allow dynamic messages to be constructed and sent 164 without the need to buffer the entire message. 166 REQ. 5: Textual data MUST be encoded as UTF-8. 168 REQ. 6: The protocol MUST support and clearly distinguish between 169 textual and binary data types (e.g. binary) via a common framing 170 with explicit length indication. 172 REQ. 7: The WebSocket protocol MUST allow HTTP and WebSocket 173 connections to be served from the same port. Consideration MUST 174 be given: 176 * to provide WebSocket services via modules that plug in to 177 existing web infrastructure. 179 * to making it possible and practical to implement standalone 180 implementations of the protocol without requiring a fully 181 conforming HTTP implementation. 183 Reason: Some server developers would like to integrate WebSocket 184 support into existing HTTP servers. In addition, the default HTTP 185 and HTTPS ports are ofter favoured for traffic that has to go through 186 a firewall, so service providers will likely want to be able to use 187 WebSocket over ports 80 and 443, even when running a Web server on 188 the same host. However there could be scenarios where it is not 189 opportune or possible to setup a proxy on the same HTTP server. 191 REQ. 8: If using an HTTP Upgrade exchange in the WebSocket 192 handshake, the protocol MUST be HTTP compatible up to and 193 including the Upgrade exchange. 195 REQ. 9: The protocol SHOULD make it possible and practical to reuse 196 existing HTTP components where appropriate. 198 Reason: Reusing existing well-debugged software decreases the number 199 of implementation errors as well as the possibility to introduce 200 security holes, and increases development speed, especially when the 201 WebSocket server is implemented as modules that plug in to existing 202 popular Web servers. 204 3.1. WebSocket Client Requirements 206 REQ. 10: The WebSocket Client MUST be able to set up a communication 207 channel with a WebSocket Server using a well-defined handshake. 209 REQ. 11: The WebSocket Protocol MUST provide for graceful close of 210 an active WebSocket connection on request from the user 211 Application. 213 Reason: a clean shutdown signals that the other endpoint has 214 definitely received all the messages sent prior to the close, so 215 there is no protocol uncertainty about what has been processed and 216 what can be retried on another connection. 218 REQ. 12: WebSocket Protocol MUST also allow ungraceful close, either 219 on request from the user application or as a result of a detected 220 error condition. 222 REQ. 13: The WebSocket Client MUST be able to request the server, 223 during the handshake, to use a specific WebSocket sub-protocol. 225 REQ. 14: The WebSocket Client MUST have the ability to send and 226 clearly distinguish between arbitrary text or binary content to 227 the server on the established communication channel. 229 3.2. WebSocket Server Requirements 231 REQ. 15: The WebSocket Server that accepts to set up a communication 232 channel with a WebSocket Client MUST use a well-defined handshake. 234 REQ. 16: The WebSocket Server MUST have the ability to send and 235 clearly distinguish between arbitrary text or binary content to 236 the client on the established communication channel. 238 3.3. WebSocket Proxies Requirements 240 Todo 242 REQ. 17: The WebSocket protocol MUST work over existing proxies to 243 the same extent as HTTP or HTTPS already does. 245 Reason: This is in line with Req on HTTP compliance. 247 3.4. WebSocket Security Requirements 249 REQ. 18: The WebSocket Protocol MUST use the Origin-based security 250 model commonly used by Web browsers to restrict which Web pages 251 can contact a WebSocket sever when the WebSocket protocol is used 252 from a Web page. 254 REQ. 19: When used directly (not from a Web page), the WebSocket 255 Protocol MUST use a security model equivalent to that of direct 256 HTTP or HTTPS usage. 258 REQ. 20: WebSocket should be designed to be robust against cross- 259 protocol attacks. The protocol design should consider and 260 mitigate the risk presented by WebSocket clients to existing 261 servers (including HTTP servers). It should also consider and 262 mitigate the risk to WebSocket servers presented by clients for 263 other protocols (including HTTP). 265 Reason: As the WebSocket protocol is expected to be often used in 266 browsers, a careful design is necessary to mitigate the chances for 267 hostile JavaScript to use WebSocket for a cross-protocol attack 268 against vanilla HTTP resources or non-HTTP servers. More the design 269 should prevent the possibility for cross-site XMLHttpRequest (using 270 CORS or XDomainRequest) to be used for a cross-protocol attack 271 against WebSocket resources, potentially violating integrity (though 272 not confidentiality). 274 Subsequent discussion in the working group has determined consensus 275 on the use of masking as one of the mechanisms to mitigate this 276 concern. 278 4. Security Considerations 280 5. IANA Considerations 282 This requirements document does not mandate any immediate IANA 283 actions. However, such IANA considerations may arise from future 284 HyBi specification documents which try to meet the requirements given 285 here. 287 6. Acknowledgments 289 The initial requirements were created by Salvatore Loreto. Thanks to 290 Greg Wilkins and Maciej Stachowiak for fulfilling previous editing 291 duties. 293 7. References 295 7.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 301 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 302 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 304 [I-D.ietf-hybi-thewebsocketprotocol] 305 Fette, I., "The WebSocket protocol", 306 draft-ietf-hybi-thewebsocketprotocol-06 (work in 307 progress), February 2011. 309 7.2. Informative References 311 [I-D.ietf-hybi-design-space] 312 Moffitt, J., Loreto, S., Saint-Andre, P., and S. Salsano, 313 "Design Space for Bidirectional Protocols", 314 draft-ietf-hybi-design-space-00 (work in progress), 315 June 2010. 317 Appendix A. Change Log (to be removed by RFC Editor before publication) 319 From version -01 to version -02: 321 o In Req. 1, clarified that the transport protocol is TCP. 323 o Explicit mention of masking as one of the mechanisms to use in 324 order to mitigate cross-protocol attacks. 326 o Moved Requirements Language to terminology section. 328 o Got rid of MUST in intro. 330 From version -00 to version -01: 332 o Modified definition of a Message to reflect recent consensus that 333 it may comprise multiple frames. 335 o Added definitions for WebSocket handshake, WebSocket communication 336 channel and WebSocket sub-protocol. 338 o Updated references to official IETF documents, moved "design- 339 space" to informational. 341 o Added a new requirement to support the ability to fragment a 342 message into frames of a given length 344 o Reworded Req 5 to reflect recent consensus on "binary+data" as 345 well as common framing with explicit length indication 347 o Reworded Req 7 to reflect recent consensus (declared in 348 Maastricht) on "HTTP compliance" 350 o Reworded Req 12 and 13 into a single Req on the client being able 351 to send text or binary content. Elided mention of "discrete 352 blocks" as the structure of messages is captured elsewhere. 354 o Reworded Req 15 and 16 into a single Req on the server being able 355 to send text or binary content. Elided mention of "discrete 356 blocks" as the structure of messages is captured elsewhere. 358 o Added a requirement in the proxies requirements section along the 359 lines of the HTTP compliance requirement, per consensus declared 360 in Maastricht. 362 o Modified security requirement when used from outside a browser to 363 avoid wording in terms of a security model equivalent to that of 364 browser-based usage. 366 o Various editorial changes. 368 Author's Address 370 Gabriel Montenegro (editor) 371 Microsoft Corporation 372 One Microsoft Way 373 Redmond 98052 374 USA 376 Email: gabriel.montenegro@microsoft.com