NETCONF Working Group T. Iijima Internet-Draft Hitachi, Ltd. Intended status: Experimental H. Kimura Expires: April 23, 2012 Y. Atarashi H. Higuchi Alaxala Networks Corp. Oct 21, 2011 NETCONF over WebSocket draft-iijima-netconf-websocket-ps-01 Abstract This memo proposes transporting NETCONF over WebSocket protocol[I-D.ietf-hybi-thewebsocketprotocol]. The use of HTTP and Web-based applications are increasing with the emergence of advanced drawing technologies and cloud computing. IT management systems supporting browser-based interface are getting common. It's natural for network management systems to support Web-based interface. Currently, however, few network management protocols support the transportation over HTTP. Although NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743], it was excluded from the options of realizing notification mechanism[RFC5277] since HTTP lacks bi- directional capabilty. At present, WebSocket protocol, the update of HTTP with bi-directional capability, is available. This memo describes the way NETCONF is sent over WebSocket protocol. 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 21, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Iijima, et al. Expires April 21, 2012 [Page 1] Internet-Draft NETCONF over WebSocket Oct 2011 document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Concerns about HTTP and WebSocket . . . . . . . . . . . . . . 7 5. Messages of NETCONF over WebSocket . . . . . . . . . . . . . . 8 5.1. Message Sequence . . . . . . . . . . . . . . . . . . . . . 8 5.2. WebSocket Message from NETCONF Client at WebSocket Handshake . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. WebSocket Message from NETCONF Server at WebSocket Handshake . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. NETCONF Message over WebSocket Connection . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Iijima, et al. Expires April 21, 2012 [Page 2] Internet-Draft NETCONF over WebSocket Oct 2011 1. Introduction The use of HTTP and Web-based applications are increasing in contrast with install-based applications with the emergence of advanced drawing technologies and cloud computing. IT management systems supporting browser-based interface to control IT resources are getting common. It's natural for network management systems to support Web-based interface. Currently, however, few network management protocols support transportation over HTTP. Although NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743], it was excluded from the options of realizing notification mechanism[RFC5277] since HTTP lacks bi-directional capabilty. At present, WebSocket protocol, the update of HTTP with bi-directional capability, is available[I-D.ietf-hybi-thewebsocketprotocol]. This memo describes the way NETCONF is sent over WebSocket protocol. This memo does not intend to standardize NETCONF over WebSocket as a mandatory transport mapping of NETCONF. NETCONF over SSH is defined to be mandatory in RFC6241[RFC6241]. But section 2 of RFC6241 also specifies that "the NETCONF protocol can be layered on any transport protocol that provides the required set of functionality." According to the description of those requirements, "Connection-Oriented Operation" and "Authentication, Integrity, and Confidentiality" are the required set of functionality. WebSocket protocol meets those requirements. It is connection-oriented. And, authentication, integrity, and confidentiality are ensured by technologies such as masking of payload and sending over TLS. Thus, WebSocket can become one of the optional protocols to transport NETCONF. Iijima, et al. Expires April 21, 2012 [Page 3] Internet-Draft NETCONF over WebSocket Oct 2011 2. Problem Statement Figure 1 is an architecture of NETCONF extracted from RFC6241[RFC6241]. So far there's few ways to easily provide browser- based network management system using NETCONF. Even though SOAP/ HTTP/TLS is defined as one of the transport protocols for NETCONF, it can not provide notification mechanism since HTTP lacks bi- directional capability. AJAX and Comet technologies are often used to outwardly provide HTTP with bi-directinal capability by way of polling or keeping a long session at the application level. But, those technologies tend to consume large amount of bandwidth and memories. There are cases where such technologies can not be accomodated into network devices due to their lack of resources (memory, processor). Layer Example +-------------+ +-----------------+ +----------------+ (4) | Content | | Configuration | | Notification | | | | data | | data | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------+ | (3) | Operations | | | | | | | | | +-------------+ +-----------------+ | | | | +-------------+ +-----------------+ +----------------+ (2) | Messages | | , | | | | | | | | | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------------------------------+ (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | | Transport | | | +-------------+ +-----------------------------------------+ Figure 1: NETCONF Protocol Layers At present, WebSocket protocol is being standardized. It is based on HTTP and has a bi-directional capability. Although standardization is still ongoing in IETF, there are already some implementations. Jetty[Jetty], Kaazing[Kaazing], and Apache/pywebsocket are available as WebSocket servers. And, Chrome[Chrome] and FireFox[FireFox] are available as browsers to run WebSocket clients. By using WebSocket as an underlying protocol for NETCONF, NETCONF client in a network management system become browser-based. And, realtime event Iijima, et al. Expires April 21, 2012 [Page 4] Internet-Draft NETCONF over WebSocket Oct 2011 notification is possible. This is beneficial for a network management system that provides failure detection function. Iijima, et al. Expires April 21, 2012 [Page 5] Internet-Draft NETCONF over WebSocket Oct 2011 3. Use Case Some vendors are providing network management systems that put XML messages directly onto HTTP. In some cases, API is provided in a style of XML, and operators write XML messages by hands and send those messages through network management system. It's not scalable, but one of the advantages of this style is that it does not require much programming. However, as far as the parts of XML is proprietary, those network management systems can manage limited number of network devices. NETCONF and its data models can be used for this purpose. And, WebSocket is defining JavaScript API[WebSocket API], which is supported by current Web browsers. By using WebSocket API to exchange NETCONF messages, NETCONF client becomes browser-based. Browser-based network management systems don't require installation in computers. Thus, they can be provided without much care about the platform on which network management systems run. For this reason, they can be used even by tablet computers, which will be deployed widely in a cloud computing age. In addition, there are various APIs to control computer and storage resources, which are also intended to be used by Web browser. DMTF (Distributed Management Task Force), for example, is standardizing REST-based API in CMWG (Cloud Management Working Group) for controlling computer and storage resources[DMTF]. REST-based API is easily manipulated by JavaScript language. And, SNIA (Storage Networking Industry Association) defines CDMI (Cloud Data Management Interface), a cloud strage API[CDMI]. This is also manipulated by JavaScript language. By using WebSocket API for NETCONF notification and combining these APIs, it's possible to develop management systems that can control IT resources according to situations in networks. Iijima, et al. Expires April 21, 2012 [Page 6] Internet-Draft NETCONF over WebSocket Oct 2011 4. Concerns about HTTP and WebSocket HTTP and WebSocket, on the other hand, have several concerns to pay attention to. As Security Considerations section of [I-D.ietf-hybi-thewebsocketprotocol] mentions, HTTP and WebSocket have quite a few risks of being attacked for its wide usage. But, as stated in the same section of [I-D.ietf-hybi-thewebsocketprotocol], WebSocket incorporates its own security mechanisms such as challenge- response exchange and payload masking. In addition, TLS is used when strong care needs to be paid on information transported over WebSocket protocol. Section 2.4 of RFC 4743[RFC4743] also mentions some drawbacks inherent in HTTP. But the section makes suggestion offsetting those drawbacks. Those suggestions are effective when WebSocket is used for transporting NETCONF. That is, intermediate proxies should not be used since it may close idle connections. And, the field of 'Cache-Control' and 'Pragma' in HTTP header sent before and during WebSocket handshake should be specified as 'no-cache,' as in the case of transporting NETCONF over SOAP/HTTPS. Iijima, et al. Expires April 21, 2012 [Page 7] Internet-Draft NETCONF over WebSocket Oct 2011 5. Messages of NETCONF over WebSocket This section specifies the messages exchanged between an NETCONF client and an NETCONF server when WebSocket protocol is used for transporting NETCONF. 5.1. Message Sequence Overall message sequence is depicted in Figure 2. Iijima, et al. Expires April 21, 2012 [Page 8] Internet-Draft NETCONF over WebSocket Oct 2011 +---------------------------+ +-------------------------+ | Network Management System | | Network device | | +---------++-----------+ | |+-----------++---------+ | | | NETCONF || WebSocket | | || WebSocket || NETCONF | | | | client || (HTTP) | | || (HTTP) || server | | | | || client | | || server || | | | +---------++-----------+ | |+-----------++---------+ | +------|-----------|--------+ +------|-----------|------+ |Load *.html| | | |---------->| HTTP:GET | | | |----------------->| | | | HTTP:200 OK | | | |<-----------------| | |<----------| | | .... |API:new WebSocket() | | |---------->| HTTP:Upgrade | | | |----------------->| | | | HTTP:Upgrade | WebSocket | | |<-----------------| opening | | | TCP:ACK | handshake | | |----------------->| | |API:onopen = function() { } | | |<----------| | | |NETCONF: | | |---------->| | | | |----------------->| | | | |---------->| | | | | | | |<----------| | |<-----------------| | |<----------| | | |NETCONF: | | |---------->| | | | |----------------->| | | | |---------->| | | | | | | |<----------| | |<-----------------| | |<----------| | | .... | | NETCONF:| | | |<----------| | |<-----------------| | |<----------| | | | | | | Iijima, et al. Expires April 21, 2012 [Page 9] Internet-Draft NETCONF over WebSocket Oct 2011 Figure 2: Message Sequence When a browser loads an html file which imports the code of NETCONF client using WebSocket API, it initiates WebSocket opening handshake. After NETCONF client is notified of the success of WebSocket handshake, it starts sending NETCONF messages. NETCONF messages are exchanged, after an NETCONF session is established and an NETCONF session ID is allocated by the NETCONF server to the NETCONF client. NETCONF messages are sent from NETCONF server, after an NETCONF session ID is allocated and subscription request is approved by the NETCONF server. When WebSocket server shuts down, NETCONF session as well as WebSocket connection is killed. Since NETCONF notification subscription is associated with NETCONF session ID as written in section 3.5 of [RFC5277], status of subscription is lost when WebSocket server shuts down. Thus, WebSocket opening handshake, NETCONF session establishment, and NETCONF notification subscription need to be made again after WebSocket server reboots. TCP port numbers of 80 and 443 can be used for transporting NETCONF messages over WebSocket and for transporting NETCONF messages over WebSocket over TLS, respectively. In this case, indication of TCP port numbers in NETCONF client is unnecessary. When any TCP port numbers other than official HTTP and HTTPS numbers are assigned for this purpose, indication of port numbers in NETCONF client as well as NETCONF server is necessary. And, setting about firewall should be opened for these port numbers. 5.2. WebSocket Message from NETCONF Client at WebSocket Handshake WebSocket opening handshake is necessary before an NETCONF client establishes an NETCONF session. The WebSocket handshake is initiated by the NETCONF client. Figure 3 is an example of WebSocket message sent from the NETCONF client at the time of WebSocket handshake. C: GET /netconf HTTP/1.1 C: Host: netconfdevice C: Upgrade: websocket C: Connection: Upgrade C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== C: Origin: http://example.com C: Sec-WebSocket-Protocol: netconf C: Sec-WebSocket-Version: 13 Figure 3: WebSocket Message from NETCONF Client Iijima, et al. Expires April 21, 2012 [Page 10] Internet-Draft NETCONF over WebSocket Oct 2011 As written in Figure 3, GET instead of POST is specified in the WebSocket header. Fields of 'Upgrade' and 'Connection' are specified as 'websocket' and 'Upgrade' respectively, so that an HTTP server running in the NETCONF server understands that it needs to work as an WebSocket server. Challenge-response mechanism encoded in base64 is included in the 'Sec-WebSocket-Key' field. And, Origin field needs to be validated by the WebSocket server. But, these are generated automatically by WebSocket client. The field that the NETCONF client needs to specify is that of 'Sec-WebSocket-Protocol,' so-called subprotocol field. The NETCONF client has to specify it, for example, as 'netconf,' so that the WebSocket server understands that it needs to hand over messages sent over this connection to the NETCONF server. Aforementioned establishment of the WebSocket connection and specification of subprotocol is made by using WebSocket API as depicted in Figure 4 in the NETCONF clients. var wsURL = "ws://" + host; ws = new WebSocket(wsURL, "netconf"); Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake 5.3. WebSocket Message from NETCONF Server at WebSocket Handshake Figure 5 is an example of WebSocket message sent from an NETCONF server to an NETCONF client at the time of WebSocket handshake. S: HTTP/1.1 101 Switching Protocols S: Upgrade: websocket S: Connection: Upgrade S: Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= S: Sec-WebSocket-Protocol: netconf Figure 5: WebSocket Message from NETCONF Server Unlike the WebSocket client, there's no standardized WebSocket API for WebSocket server. Although the way of implementing WebSocket server is proprietary, there's some implementations as mentioned in section 2. NETCONF server can be develped on top of those implementations by using their libraries. As written in Figure 5, when HTTP server inside network device can run as WebSocket server, the number of 101 has to be returned to Iijima, et al. Expires April 21, 2012 [Page 11] Internet-Draft NETCONF over WebSocket Oct 2011 WebSocket client. Fields of 'Upgrade' and 'Connection' are specified as 'websocket' and 'Upgrade' respectively, in order to let the NETCONF client know that an HTTP server in network device can run as WebSocket server. In this case too, above fields need to be generated by WebSocket server. The field that the NETCONF server needs to specify is that of 'Sec-WebSocket-Protocol.' The NETCONF server has to specify its name of the subprotocol, for example, as 'netconf,' in order to let the NETCONF client know that the WebSocket server in the network device accepts NETCONF messages. 5.4. NETCONF Message over WebSocket Connection After an WebSocket connection is established, an NETCONF client and an NETCONF server start exchanging NETCONF messages. Exchanges of messages between NETCONF client and NETCONF server start from this timing. After an NETCONF session is established and a session ID is allocated to NETCONF client, messages containing for NETCONF configurations and messages like for NETCONF notification should be sent from the NETCONF client to the NETCONF server. And messages like should be sent from the NETCONF server to the NETCONF client asynchronously. During this data transfer period, so called HTTP headers coupled with GET, 404 and so on are unnecessary. NETCONF configuration messages as well as NETCONF notification messages are encapsulated as a payload of WebSocket protocol according to the Data Framing specified in the section 5.2 of [I-D.ietf-hybi-thewebsocketprotocol]. And above encapusulated data are exchanged over TCP without the use of HTTP. Sending of NETCONF message from NETCONF client is made by using WebSocket API as depicted in Figure 6. Iijima, et al. Expires April 21, 2012 [Page 12] Internet-Draft NETCONF over WebSocket Oct 2011 ws.onopen = function() { // WebSocket connection has established. // rpc message of can be sent here // by send() method. ws.send("message to send"); .... }; ws.onmessage = function (evt) { // NETCONF message has arrived. // NETCONF message can be parsed by DOM APIs. var received_msg = evt.data; var parser = new DOMParser(); var dom = parser.parseFromString(evt.data, "text/xml"); if(dom.documentElement.nodeName == "hello"){ // rpc reply message of has arrived. // Subsequent NETCONF message can be sent here // by send() method. ws.send("message to send"); ... } }; Figure 6: WebSocket API in NETCONF Client for Sending Messages As shown in Figure 6, NETCONF messages are sent from WebSocket API. The NETCONF message to send through WebSocket API can be a hand- written message typed in from browser-based NMS. Or it might be created by JavaScript DOM API according to the data typed in from browser-based NMS. Unlike the case of NETCONF over SOAP over HTTPS, which provides API to manipulate NETCONF , parts of as well as contents need to be manipulated by NETCONF client. NETCONF messages are also received by WebSocket API. These messages are analyzed by JavaScript DOM API. In contrast, the way of sending NETCONF message from NETCONF server is proprietary. Unlike the WebSocket client, there's no standardized WebSocket API for WebSocket server. Although the way of implementing WebSocket server is proprietary, there's some implementations as mentioned in section 2. NETCONF server can be developed on top of those implementations by using their libraries. By using send method of those libraries, it's possible to send NETCONF notification message asynchronously from NETCONF server to NETCONF clients. Iijima, et al. Expires April 21, 2012 [Page 13] Internet-Draft NETCONF over WebSocket Oct 2011 6. Security Considerations The security considerations of [RFC6241], [RFC5277], and [I-D.ietf-hybi-thewebsocketprotocol] are applicable to this document. Implementers or users should take these considerations into account. Transport-level security, such as authentication of users and encryption of data transfer, has to be ensured by TLS (Transport Layer Security). That is, security has to be provided in the form of NETCONF over WebSocket over TLS (WSS). Iijima, et al. Expires April 21, 2012 [Page 14] Internet-Draft NETCONF over WebSocket Oct 2011 7. IANA Considerations As written in section 11.5 of [I-D.ietf-hybi-thewebsocketprotocol], registration of NETCONF's Identifier, to be exchanged at WebSocket opening handshake, and Common Name with WebSocket Subprotocol Name Registry is necessary. Iijima, et al. Expires April 21, 2012 [Page 15] Internet-Draft NETCONF over WebSocket Oct 2011 8. Acknowledgements This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]. Iijima, et al. Expires April 21, 2012 [Page 16] Internet-Draft NETCONF over WebSocket Oct 2011 9. References 9.1. Normative References [I-D.ietf-hybi-thewebsocketprotocol] Fette, I. and A. Melnikov, "The WebSocket protocol", draft-ietf-hybi-thewebsocketprotocol-17 (work in progress), September 2011. [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [WebSocket API] "The WebSocket API". 9.2. Informative References [CDMI] "SNIA's CDMI". [Chrome] "Chrome". [DMTF] "CLOUD | DMTF". [FireFox] "FireFox". [I-D.moffitt-xmpp-over-websocket] Moffitt, J. and E. Cestari, "An XMPP Sub-protocol for WebSocket", draft-moffitt-xmpp-over-websocket-00 (work in progress), December 2010. [Jetty] "Jetty WebServer". Iijima, et al. Expires April 21, 2012 [Page 17] Internet-Draft NETCONF over WebSocket Oct 2011 [Kaazing] "Kaazing". [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Iijima, et al. Expires April 21, 2012 [Page 18] Internet-Draft NETCONF over WebSocket Oct 2011 Authors' Addresses Tomoyuki Iijima Hitachi, Ltd. 292 Yoshida-cho, Totsuka-ku Yokohama, Kanagawa 244-0817 Japan Phone: +81-45-860-2156 Email: tomoyuki.iijima.fg@hitachi.com Hiroyasu Kimura Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: h-kimura@alaxala.com Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Hidemitsu Higuchi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: hidemitsu.higuchi@alaxala.com Iijima, et al. Expires April 21, 2012 [Page 19]