NETCONF Working Group T. Iijima Internet-Draft Hitachi, Ltd. Intended status: Experimental H. Kimura Expires: April 20, 2013 Y. Atarashi H. Higuchi Alaxala Networks Corp. Oct 17, 2012 NETCONF over WebSocket draft-iijima-netconf-websocket-ps-04 Abstract This memo proposes a way of transporting NETCONF over WebSocket protocol. Web-related technologies are advancing and number of Web- based systems are increasing. Management systems that adopt Web- related technologies or that have browser-based management interface are getting common. It is natural to expect that there is a standard network operation and management protocol to be used over HTTP. Currently, however, there are few efforts in this area. Although NETCONF[RFC6241] once defined itself to be sent over SOAP/ HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of bi-directional capability, such efforts aren't successful enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. But now, WebSocket protocol, the update of HTTP equipped with bi-directional capability, is available[RFC6455]. This memo describes how NETCONF should be treated 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 20, 2013. Copyright Notice Iijima, et al. Expires April 20, 2013 [Page 1] Internet-Draft NETCONF over WebSocket Oct 2012 Copyright (c) 2012 IETF Trust and the persons identified as the 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 Using HTTP and WebSocket . . . . . . . . . . . 7 5. Handling of NETCONF Username . . . . . . . . . . . . . . . . . 8 6. Transporting NETCONF Messages over WebSocket Protocol . . . . 9 6.1. Message Sequence . . . . . . . . . . . . . . . . . . . . . 9 6.2. WebSocket Message at Handshake from NETCONF Client . . . . 11 6.3. WebSocket Message at Handshake from NETCONF Server . . . . 12 6.4. NETCONF Message over WebSocket at NETCONF Client . . . . . 12 6.5. NETCONF Message over WebSocket at NETCONF Server . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Iijima, et al. Expires April 20, 2013 [Page 2] Internet-Draft NETCONF over WebSocket Oct 2012 1. Introduction Web-related technologies are advancing and number of Web-based systems are increasing. Management systems that adopt Web-related technologies or have browser-based management interface are getting common. It is natural to expect that there is a standard network operation and management protocol to be sent over HTTP. Currently, however, there are few efforts in this area and, in most cases, management interface to be used over HTTP are proprietary. Although NETCONF[RFC6241] once defined itself to be sent over SOAP/ HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of bi-directional capability, such efforts didn't succeed well enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. But now, WebSocket protocol, the update of HTTP equipped with bi-directional capability, is available[RFC6455]. This memo describes how NETCONF should be exchanged over WebSocket protocol. This memo does not intend to make WebSocket as a mandatory transport protocol for NETCONF. NETCONF specifies that it is mandatory to be sent over SSH[RFC6241]. But [RFC6241] also specifies in its section 2 that "the NETCONF protocol can be layered on any transport protocol that provides the required set of functionality." According to the specification, those required set of functionality are "Connection- Oriented Operation" and "Authentication, Integrity, and Confidentiality." WebSocket protocol meets those requirements. It is 'connection-oriented.' And, as written in the section 10.5 of [RFC6455], 'authentication' is ensured by mechanisms available to a generic HTTP server, such as cookies, HTTP Authentication, or TLS. Moreover, as written in the section 10.6 of [RFC6455], 'integrity and confidentiality' are ensured by running WebSocket protocol over TLS. For these reasons, WebSocket protocol coupled with TLS meets the requirements of transport protocol for NETCONF. Iijima, et al. Expires April 20, 2013 [Page 3] Internet-Draft NETCONF over WebSocket Oct 2012 2. Problem Statement Web-related technologies, such as JavaScript and JSON(JavaScript Orient Notation), are widely used. And number of Web-based systems, such as those provided for IaaS (Infrastructure as a Service), are increasing. There are systems that are providing management interface in a form of REST API(Application Programming Interface). It is natural to expect that there is a standard network operation and management protocol to be sent over HTTP. Currently, however, there are few efforts in this area. And, in most of the cases, management interface are proprietary. NETCONF[RFC6241] once defined itself to be sent over SOAP/ HTTPS[RFC4743], as drawn in Figure 1. But, supposedly due to unfamiliarity to SOAP or lack of bi-directional capability, such efforts haven't been successful enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. 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 As of now, however, WebSocket protocol is available[RFC6455]. It is based on HTTP, which is familiar to all. And, it has a bi- directional capability. Thus, by using WebSocket protocol, it's possible to realize NETCONF that is used over HTTP with ease and that supports notification mechanism specified in [RFC5277]. Iijima, et al. Expires April 20, 2013 [Page 4] Internet-Draft NETCONF over WebSocket Oct 2012 Some WebSocket implementations already exist today. As examples of WebSocket server implementation, Jetty[Jetty], Kaazing[Kaazing], and the like are available. And, as examples of WebSocket client implementation, Jetty[Jetty] is available. Moreover, as examples of Web-browsers that can work as WebSocket client, Chrome[Chrome], and FireFox[FireFox] and the like are available. WebSocket server and client implementations mentioned above are providing libraries. And WebSocket protocol itself also defines API[WebSocket API] to be used on Web-browsers. Thus, by using those libraries and APIs, developers can develop NETCONF server, install- based NETCONF client, and browser-based NETCONF client with ease that use WebSocket for transporting NETCONF. Iijima, et al. Expires April 20, 2013 [Page 5] Internet-Draft NETCONF over WebSocket Oct 2012 3. Use Case XML, which NETCONF uses for message encoding, has high compatibility with HTTP in that XML are easily manipulated on Web-browsers by JavaScript DOM (Document Object Model) API. Hence, there are cases in which XML is used over HTTP to manage network devices. But as far as those XML are proprietary, the way of managing network devices and items to manage are different from network device to network device. If NETCONF, instead of proprietary XML, and its data models are used for above cases, it will provide a way of managing various network devices in a same manner. Browser-based network management systems don't require installation on computers. For this reason, some operators prefer browser-based network management systems. This trend might accelerate in the age of tablet computers. In this respect, it is rational for NETCONF to have an option to be used through browser-based network management system. Operators will be able to manage network devices from any computers without installation. Iijima, et al. Expires April 20, 2013 [Page 6] Internet-Draft NETCONF over WebSocket Oct 2012 4. Concerns about Using HTTP and WebSocket There are some drawbacks inherent in HTTP as mentioned in the section 2.4 of [RFC4743], which describes the way of transporting NETCONF over SOAP/HTTPS. But, for these drawbacks, the same section makes suggestions. 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 fields of 'Cache-Control' and 'Pragma' in HTTP header, which is sent before or during WebSocket opening handshake, SHOULD be specified as 'no- cache.' WebSocket has had several security concerns. But it incorporated its own security mechanisms such as origin header and masking, as stated in the Security Considerations section of [RFC6455]. In any case, using TLS is necessary for ensuring authentication and confidentiality, when WebSocket is used for transporting NETCONF. Iijima, et al. Expires April 20, 2013 [Page 7] Internet-Draft NETCONF over WebSocket Oct 2012 5. Handling of NETCONF Username NETCONF[RFC6241] mandates underlying transport protocol to carry NETCONF username and to provide it to NETCONF server. In the case of transporting NETCONF over WebSocket, this memo proposes that NETCONF username SHOULD be carried and provided in compliance with NETCONF over TLS[I-D.badra-netconf-rfc5539bis]. In the case of transporting NETCONF over WebSocket, TLS is necessary for the user authentication. In order to ensure that NETCONF access control is done consistently with TLS authentication, NETCONF username SHOULD be matched with TLS authentication data. At present, [I-D.badra-netconf-rfc5539bis] is proposing ways of extracting NETCONF username from TLS authentication data. Being compliant with these approaches is the most efficient. At least, it is confirmed that NETCONF server using WebSocket/TLS for underlying protocol can see TLS Certificate at the time of TLS handshake and can extract NETCONF username from the Certificate. Iijima, et al. Expires April 20, 2013 [Page 8] Internet-Draft NETCONF over WebSocket Oct 2012 6. Transporting NETCONF Messages over WebSocket Protocol This section specifies how NETCONF messages are exchanged between NETCONF client and server over WebSocket protocol. 6.1. Message Sequence Simplified overall message sequence is depicted in Figure 2. This sequence is depicting the case in which NETCONF client runs on a Web- browser. However, it must be noted that there is also a case in which NETCONF client runs as an install-based software developed with WebSocket client library. +---------------------------+ +---------------------------+ | Network Management System | | Network Device | | | | (e.g. 192.168.1.1) | | +---------++-----------+ | | +-----------++---------+ | | | NETCONF || WebSocket | | | | WebSocket || NETCONF | | | | Client || (HTTP) | | | | (HTTP) || Server | | | | || Client | | | | Server || | | | +---------++-----------+ | | +-----------++---------+ | +------|-----------|--------+ +--------|-----------|------+ | | | | |Load *.html| | | |---------->| Hello(TLS) | | | / |------------------->| | | | | Server Certificate | | | TLS |<-------------------| | | handshake | Client Certificate | | | | |------------------->|NETCONF username | | | Finished(TLS) |---------->| | \ |<-------------------| | | | | | | | GET(HTTP) | | | |------------------->| | | | 200 OK(HTTP) | | | |<-------------------| | |<----------| | | .... |Call WebSocket() API | | |---------->| | | | |Connection: Upgrade | | | / |------------------->| | | WebSocket |Connection: Upgrade | | | opening |<-------------------| | | handshake | ACK(TCP) | | | \ |------------------->| | Iijima, et al. Expires April 20, 2013 [Page 9] Internet-Draft NETCONF over WebSocket Oct 2012 |Invoke onopen = function() { } | | |<----------| | | | | | | |(NETCONF) | | |---------->| | | | |------------------->| | | | |---------->| | | | | | | |<----------| | |<-------------------| | |<----------| | | .... |(NETCONF) | | |---------->| | | | |------------------->| | | | |---------->| | | | | | | |<----------| | |<-------------------| | |<----------| | | .... | | (NETCONF)| | | |<----------| | |<-------------------| | |<----------| | | | | | | Figure 2: Message Sequence First of all, a browser starts loading of an html file, which imports the code of NETCONF client, over TLS. This invokes TLS handshake. At the time of TLS handshake, NETCONF server can extract NETCONF username from Certificate according to the algorithm described in [I-D.badra-netconf-rfc5539bis]. After TLS handshake is complete, the html file is loaded onto the browser. The loaded html file works as NETCONF client and it initiates WebSocket opening handshake. When NETCONF server receives a WebSocket connection request, it notifies the client of whether WebSocket handshake has succeeded. After WebSocket connection is established, NETCONF client starts sending NETCONF messages over the connection. NETCONF messages are exchanged between NETCONF client and server, at first, so that a NETCONF session is established and a NETCONF session ID is allocated by NETCONF server to the NETCONF client. Then, NETCONF messages are exchanged. After NETCONF Iijima, et al. Expires April 20, 2013 [Page 10] Internet-Draft NETCONF over WebSocket Oct 2012 message of request is approved by the NETCONF server, NETCONF messages are sent from NETCONF server asynchronously. 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 NETCONF notification mechanism[RFC5277], subscription status is lost when WebSocket server shuts down. Thus, it is necessary to redo WebSocket opening handshake, NETCONF session establishment, and NETCONF notification subscription after WebSocket server reboots. Without any indications, TCP port numbers of 443 is automatically used for transporting NETCONF messages over WebSocket over TLS. When port number other than 443 needs to be used, the number SHOULD be specified at both NETCONF client and server respectively. 6.2. WebSocket Message at Handshake from NETCONF Client WebSocket opening handshake is necessary for the establishment of an WebSocket connection, which is used for NETCONF message exchange. The WebSocket handshake is initiated by a 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: 192.168.1.1 C: Upgrade: websocket C: Connection: Upgrade C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== C: Origin: http://192.168.1.1 C: Sec-WebSocket-Protocol: netconf C: Sec-WebSocket-Version: 13 Figure 3: WebSocket Message from NETCONF Client Most of the fileds in Figure 3 are generated automatically by WebSocket client. The only field that the NETCONF client needs to specify is 'Sec-WebSocket-Protocol' field, so-called subprotocol field. The NETCONF client has to specify the field as 'netconf,' for example, so that the NETCONF server understands that messages sent over this connection is directed towards NETCONF server. Aforementioned establishment of the WebSocket connection and specification of subprotocol is made by using WebSocket API in the Iijima, et al. Expires April 20, 2013 [Page 11] Internet-Draft NETCONF over WebSocket Oct 2012 html file of the NETCONF client as depicted in Figure 4. var wssURL = "wss://" + location.host; var wss = new WebSocket(wssURL, "netconf"); Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake 6.3. WebSocket Message at Handshake from NETCONF Server Figure 5 is an example of WebSocket message sent from the NETCONF server to the 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 Most of the fields in Figure 5 are generated automatically by WebSocket server, too. The only field that the NETCONF server needs to specify is 'Sec-WebSocket-Protocol' field. The NETCONF server has to specify the field as 'netconf,' for example, in order to let the NETCONF client know that the WebSocket server in the network device accepts NETCONF messages. Unlike the WebSocket client, there's no standardized WebSocket API for WebSocket server. But, there are some WebSocket server implementations as mentioned in section 2. Thus, it's possible to develop a part of WebSocket opening handshake at NETCONF server with ease by using libraries provided by those implementations. 6.4. NETCONF Message over WebSocket at NETCONF Client NETCONF message exchange between NETCONF client and server starts after an WebSocket connection is established. messages are exchanged, first, for the establishment of a NETCONF session and allocation of NETCONF session ID. Then, messages like are sent from NETCONF client to NETCONF server for NETCONF configurations. And messages like are sent from NETCONF client to NETCONF server for subscription of NETCONF notification. Moreover, messages like are sent asynchronously from NETCONF server to NETCONF client for NETCONF Iijima, et al. Expires April 20, 2013 [Page 12] Internet-Draft NETCONF over WebSocket Oct 2012 notification. During this data transfer period, both NETCONF configuration messages and NETCONF notification messages are encapsulated as a payload of WebSocket protocol according to the Data Framing specified in the section 5.2 of WebSocket protocol[RFC6455]. This encapsulation is made by WebSocket layer. Sending and receiving of NETCONF messages at NETCONF client is made by using WebSocket API. The example is illustrated in Figure 6. wss.onopen = function() { // WebSocket connection has been established. // Thus, NETCONF can be sent here // by send() method. wss.send("message to send"); .... }; wss.onmessage = function (evt) { // NETCONF message has arrived. // Thus, NETCONF message can be parsed here by DOM APIs. var parser = new DOMParser(); var dom = parser.parseFromString(evt.data, "text/xml"); .... if(dom.documentElement.nodeName == "hello"){ // The NETCONF message turned out to be // NETCONF . // Subsequent NETCONF message can be sent here // by send() method. wss.send("message to send"); ... } }; Figure 6: WebSocket API in NETCONF Client for Sending Messages As shown in Figure 6, NETCONF messages are sent from NETCONF client by using WebSocket API of "wss.send()." And, NETCONF messages are received at NETCONF client by using WebSocket API of "wss.onmessage()." The contents of NETCONF messages exchanged through above API might be either a hand-written XML messages typed into network management system or XML messages created by JavaScript DOM API according to the data set on the network management system. It must be noted that in the case of transporting NETCONF over WebSocket, parts need to Iijima, et al. Expires April 20, 2013 [Page 13] Internet-Draft NETCONF over WebSocket Oct 2012 be created by NETCONF client, unlike the case of transporting NETCONF over SOAP/HTTPS, in which parts are generated in SOAP layer. 6.5. NETCONF Message over WebSocket at NETCONF Server Unlike the WebSocket client, the way of sending and receiving NETCONF message at NETCONF server is proprietary since there's no standardized API for WebSocket server. But, there are some WebSocket server implementations as mentioned in section 2. Thus, it's possible to develop NETCONF server with ease by using libraries provided by those implementations. Iijima, et al. Expires April 20, 2013 [Page 14] Internet-Draft NETCONF over WebSocket Oct 2012 7. Security Considerations It is necessary to use TLS (Transport Layer Security) in order to ensure Transport-level security, such as authentication of users and encryption of data transfer. That is, NETCONF has to be sent in the form of NETCONF over WebSocket over TLS (WSS). In addition, the security considerations of NETCONF protocol[RFC6241], NETCONF Notification mechanism[RFC5277], and WebSocket protocol[RFC6455] are applicable to this document. Implementers or users SHOULD take these considerations into account. Iijima, et al. Expires April 20, 2013 [Page 15] Internet-Draft NETCONF over WebSocket Oct 2012 8. IANA Considerations As written in section 11.5 of WebSokcet protocol[RFC6455], NETCONF's Subprotocol Common Name, to be exchanged in 'Sec-WebSocket-Protocol' field at WebSocket opening handshake, coupled with Identifier and Definition need to be registered with the WebSocket Subprotocol Name Registry. Iijima, et al. Expires April 20, 2013 [Page 16] Internet-Draft NETCONF over WebSocket Oct 2012 9. Acknowledgements This document was written using the xml2rfc tool described in [RFC2629]. Iijima, et al. Expires April 20, 2013 [Page 17] Internet-Draft NETCONF over WebSocket Oct 2012 10. References 10.1. Normative References [I-D.badra-netconf-rfc5539bis] Badra, M., "NETCONF Over Transport Layer Security (TLS)", draft-badra-netconf-rfc5539bis-02 (work in progress), April 2012. [I-D.ietf-netconf-rfc4743-rfc4744-to-historic] Wijnen, B., "RFC4743 and RFC4744 to Historic status", draft-ietf-netconf-rfc4743-rfc4744-to-historic-00 (work in progress), September 2012. [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. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [WebSocket API] "The WebSocket API". 10.2. Informative References [Chrome] "Chrome". [FireFox] "FireFox". [Jetty] "Jetty WebServer". [Kaazing] "Kaazing". Iijima, et al. Expires April 20, 2013 [Page 18] Internet-Draft NETCONF over WebSocket Oct 2012 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Iijima, et al. Expires April 20, 2013 [Page 19] Internet-Draft NETCONF over WebSocket Oct 2012 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.net 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 20, 2013 [Page 20]