NETCONF Working Group T. Iijima Internet-Draft Hitachi, Ltd. Intended status: Experimental H. Kimura Expires: January 14, 2013 Y. Atarashi H. Higuchi Alaxala Networks Corp. Jul 13, 2012 NETCONF over WebSocket draft-iijima-netconf-websocket-ps-03 Abstract This memo proposes a way of transporting NETCONF over WebSocket protocol. Web-based systems are increasing with the advancement of Web technologies and emergence of cloud computing. Management systems that support browser-based interface are also getting common. It's natural to expect network devices to have browser-based managemaent interface. Currently, however, few network management protocols support being transported over HTTP. NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743]. But, it falls short of fulfilling NETCONF specification in that it can't provide NETCONF notification[RFC5277] because of HTTP's lack of bi-directional capabilty. At present, WebSocket protocol, the update of HTTP with bi-directional capability, is available[RFC6455]. 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 January 14, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Iijima, et al. Expires January 14, 2013 [Page 1] Internet-Draft NETCONF over WebSocket Jul 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Concerns about Using HTTP and WebSocket . . . . . . . . . . . 6 5. Handling of NETCONF username . . . . . . . . . . . . . . . . . 7 6. Transporting NETCONF Messages over WebSocket Protocol . . . . 8 6.1. Message Sequence . . . . . . . . . . . . . . . . . . . . . 8 6.2. WebSocket Message from NETCONF Client at WebSocket Handshake . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. WebSocket Message from NETCONF Server at WebSocket Handshake . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. NETCONF Message at NETCONF Client over WebSocket Connection . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. NETCONF Message at NETCONF Server over WebSocket Connection . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Iijima, et al. Expires January 14, 2013 [Page 2] Internet-Draft NETCONF over WebSocket Jul 2012 1. Introduction Web-based systems are increasing due to the advancement of Web technologies and emergence of cloud computing. Management systems that support browser-based interface are also getting common. It's natural to expect network devices to have browser-based management interface. Currently, however, few network management protocols support being transported over HTTP. NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743]. But, it falls short of fulfilling NETCONF specification in that it can't provide NETCONF notification [RFC5277] because of HTTP's lack of bi-directional capability. At present, WebSocket protocol, the update of HTTP with bi-directional capability, is available[RFC6455]. This memo describes the way NETCONF is sent over WebSocket protocol. This memo does not intend to make WebSocket protocol as a mandatory transport mapping for NETCONF. NETCONF specifies that it is mandatory to be sent over SSH [RFC6241]. But [RFC6241] also specifies in 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 [RFC6241], '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 January 14, 2013 [Page 3] Internet-Draft NETCONF over WebSocket Jul 2012 2. Problem Statement Figure 1 is an architecture of NETCONF extracted from [RFC6241]. As of now, there's few protocols that is used to manage network devices through Web-based management system according to the NETCONF specification. Although SOAP/HTTP/TLS is defined to be one of the transport protocols for NETCONF, it falls short of realizing notification mechanism since HTTP lacks bi-directional capability. 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, however, WebSocket protocol is available. It is based on HTTP and has a bi-directional capability. Some implementations are available already. Jetty[Jetty], Kaazing[Kaazing] and so on are available as WebSocket servers. And, Web-browsers like Chrome[Chrome] and FireFox[FireFox] work as WebSocket clients. Moreover, there are WebSocket client libraries, which help develop install-based applications on top of WebSocket. By using WebSocket as an underlying protocol for NETCONF, it's possible to realize Web-based management systems that support not only NETCONF configuration but also NETCONF notification. Iijima, et al. Expires January 14, 2013 [Page 4] Internet-Draft NETCONF over WebSocket Jul 2012 3. Use Case There are cases in which browser-based management systems use XML over HTTP to manage network devices. XML has high compatibility with Web-based management systems in that XML messages are manipulated easily on Web browsers by using JavaScript DOM API. If NETCONF, instead of proprietary XML, and its data models are used for above cases, it's possible to manage various network devices in the same manner through browser-based management systems. But, as described in the previous section, NETCONF is rarely used in browser-based management systems today. Since WebSocket provides standardized JavaScript-based API[WebSocket API] for Web browsers, development of browser-based NETCONF client that can exchange messages over WebSocket is easily possible. An html file written with WebSocket API to send and receive NETCONF messages works as a browser-based NETCONF client. Browser-based network management systems don't require installation on computers. There is a case when people want to manage network devices from any computers. In such a case, browser-based management systems are effective since it doesn't require installlation process. People can manage network devices even from tablet computers. Furthermore, there are other activities to use HTTP for managing devices other than network. For example, DMTF (Distributed Management Task Force), has standarded REST-based CIMI (Cloud Infrastructure Management Interface)[DMTF] to control computers. REST-based API can be manipulated by JavaScript language at Web browsers. And, SNIA (Storage Networking Industry Association) has standardized CDMI (Cloud Data Management Interface)[CDMI] to control storage devices. This can also be manipulated by JavaScript language at Web browsers. Having an option to control network devices through Web browsers will help operators to manage various devices from the same environment. Iijima, et al. Expires January 14, 2013 [Page 5] Internet-Draft NETCONF over WebSocket Jul 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 using HTTP for transporting NETCONF/SOAP. 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 WebSocket handshake, should be specified as 'no-cache.' And, WebSocket itself has several security concerns. But, it incorporates its own security mechanisms such as origin header and masking, as stated in the Security Considerations section of [RFC6455]. In any case, TLS is necessary for ensuring authentication and confidentiality, when WebSocket is used for transporting NETCONF. Iijima, et al. Expires January 14, 2013 [Page 6] Internet-Draft NETCONF over WebSocket Jul 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 extracted from TLS authentication data. At present, [I-D.badra-netconf-rfc5539bis] is proposing the way of extracting NETCONF username from TLS authentication data, and basing on this algorithm is the efficient approach. NETCONF server which uses TLS can get TLS Certificate from SSL Socket before WebSocket opening handshake starts, and can extract NETCONF username from the Certificate. Iijima, et al. Expires January 14, 2013 [Page 7] Internet-Draft NETCONF over WebSocket Jul 2012 6. Transporting NETCONF Messages over WebSocket Protocol This section specifies the way of transporting NETCONF messages between a NETCONF client and a NETCONF server when WebSocket protocol is used for underlying protocol for NETCONF. 6.1. Message Sequence Overall message sequence is depicted in Figure 2. This sequence is depicting the case in which NETCONF client runs on a Web-browser. But it must be noted that there is also a case in which NETCONF client runs as an install-based application if NETCONF client is developed with WebSocket client library. +---------------------------+ +-------------------------+ | Network Management System | | Network Device | | | | (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 January 14, 2013 [Page 8] Internet-Draft NETCONF over WebSocket Jul 2012 | \ |----------------->| | |Invoke onopen = function() { }| | |<----------| | | | | | | |(NETCONF) | | |---------->| | | | |----------------->| | | | |---------->| | | | | | | |<----------| | |<-----------------| | |<----------| | | |(NETCONF)| | |---------->| | | | |----------------->| | | | |---------->| | | | | | | |<----------| | |<-----------------| | |<----------| | | .... | | (NETCONF)| | | |<----------| | |<-----------------| | |<----------| | | | | | | Figure 2: Message Sequence First of all, a browser initiates loading of an html file, which imports the code of NETCONF client. This initiates the TLS handshake before the loading of the html file. At the time of TLS handshake, NETCONF server can extract NETCONF username from Certificate or PSK according to the algorighm 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 an NETCONF client and it initiates WebSocket opening handshake. When NETCONF server receives a WebSocket connection request, it notifies NETCONF 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 Iijima, et al. Expires January 14, 2013 [Page 9] Internet-Draft NETCONF over WebSocket Jul 2012 client. Then, NETCONF messages are exchanged. After NETCONF message of request is approved by the NETCONF server, NETCONF messages are sent from 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 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. If necessary, any TCP port numbers other than above can be used by specifying at both NETCONF client and server. 6.2. WebSocket Message from NETCONF Client at WebSocket Handshake WebSocket opening handshake is necessary for the establishment of an WebSocket connection, to be used for NETCONF message exchange. 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: 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 Iijima, et al. Expires January 14, 2013 [Page 10] Internet-Draft NETCONF over WebSocket Jul 2012 specification of subprotocol is made by using WebSocket API in the html file of the NETCONF client as depicted in Figure 4. var wssURL = "wss://" + host; wss = new WebSocket(wssURL, "netconf"); Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake 6.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 are some implementations as mentioned in section 2. Thus, it's possible to develop NETCONF server by using the implementations' libraries. Most of the fields in Figure 5 are generated automatically by WebSocket server. The only field that the NETCONF server needs to specify is 'Sec-WebSocket-Protocol' field. The NETCONF server has to specify ithe field as 'netconf,' for example, in order to let the NETCONF client know that the WebSocket server in the network device accepts NETCONF messages. 6.4. NETCONF Message at NETCONF Client over WebSocket Connection NETCONF message exchange between NETCONF client and NETCONF server starts after an WebSocket connection is established. messages are exchanged, first, to establish a NETCONF session and to allocate 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. In addition, messages like are sent asynchronously Iijima, et al. Expires January 14, 2013 [Page 11] Internet-Draft NETCONF over WebSocket Jul 2012 from NETCONF server to NETCONF client for NETCONF 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 established. // rpc message of can be sent here // by send() method. wss.send("message to send"); .... }; wss.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. wss.send("message to send"); ... } }; Figure 6: WebSocket API in NETCONF Client for Sending Messages As shown in Figure 6, NETCONF messages sent from NETCONF client is sent by using WebSocket API of "wss.send()." And, NETCONF messages received at NETCONF client is received 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 messages created by JavaScript DOM API according to the data typed into network management system. It must be noted that in the case of transporting NETCONF over WebSocket, parts need to Iijima, et al. Expires January 14, 2013 [Page 12] Internet-Draft NETCONF over WebSocket Jul 2012 be created by NETCONF client, unlike the case of transporting NETCONF over SOAP/HTTPS, in which parts are produced in SOAP layer. 6.5. NETCONF Message at NETCONF Server over WebSocket Connection The way of sending and receiving NETCONF message at NETCONF server is proprietary. Unlike the WebSocket client, there's no standardized API for WebSocket server. But, there are some WebSocket server implementations as mentioned in section 2. By using libraries of those implementations, developers can develop NETCONF server on top of those implementations. Iijima, et al. Expires January 14, 2013 [Page 13] Internet-Draft NETCONF over WebSocket Jul 2012 7. Security Considerations 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. 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, security has to be provided in the form of NETCONF over WebSocket over TLS (WSS). Iijima, et al. Expires January 14, 2013 [Page 14] Internet-Draft NETCONF over WebSocket Jul 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 January 14, 2013 [Page 15] Internet-Draft NETCONF over WebSocket Jul 2012 9. Acknowledgements This document was written using the xml2rfc tool described in [RFC2629]. Iijima, et al. Expires January 14, 2013 [Page 16] Internet-Draft NETCONF over WebSocket Jul 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. [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 [CDMI] "SNIA's CDMI". [Chrome] "Chrome". [DMTF] "CLOUD | DMTF". [FireFox] "FireFox". [Jetty] "Jetty WebServer". Iijima, et al. Expires January 14, 2013 [Page 17] Internet-Draft NETCONF over WebSocket Jul 2012 [Kaazing] "Kaazing". [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Iijima, et al. Expires January 14, 2013 [Page 18] Internet-Draft NETCONF over WebSocket Jul 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 January 14, 2013 [Page 19]