1. Hiroyasu Kimura, Yoshifumi Atarashi, and Hidemitsu Higuchi
84th IETF meeting NETCONF over WebSocket (
Tomoyuki Iijima,
(Hitachi)
Hiroyasu Kimura, Yoshifumi Atarashi, and Hidemitsu Higuchi
(Alaxala Networks)
Hi, I’m Tomoyuki Iijima from Hitachi.
I’m going to talk about the NETCONF over WebSocket.

2. Objective of this I-D
To propose a way of sending NETCONF over WebSocket protocol.
But, we do not intend to make this proposal as mandatory.
First of all, this is the objective of this I-D.
Objective of this I-D is to propose a way of sending NETCONF over WebSocket protocol.
But, we do not intend to make this proposal as mandatory.

3. Changes since the last IETF meeting
As per comments received at the last IETF meeting, we’ve made following changes.
Changed description about NETCONF username.
We propose extracting information about NETCONF username from TLS. WebSocket needs TLS for ensuring security. Thus, using information in TLS is necessary in order to ensure that NETCONF user is the very person who is authenticated by TLS (certificate).
We think, for this purpose, complying with Mr. Badra’s I- D is the best approach since reinventing the wheel is not welcomed.
After the previous meeting, we’ve made following changes.
First, we’ve added description about NETCONF username authentication.
Specifically, we’ve proposed the use of Cookie for NETCONF username at the time of WebSocket opening handshake.
And, we’ve added description that this proposal is not limited to browser-based NMS. If implemented as application-based NMS, this I-D can be used to manage large NW.

4. NETCONF username from TLS
I haven’t implemented all of the Mr. Badra’s algorithms yet . But I’ve confirmed that it’s possible for a NETCONF server supporting WebSocket to get TLS Certificate during TLS handshake by, for example, using HTTP server’s API, or seeing SSL_context through SSL_socket.
NETCONF server example.
public class NetconfWebSocketServlet extends WebSocketServlet{
@Override
void doGet(HttpServletRequest req, HttpServletResponse res){
X509Certificate[ ] certificates = (X509Certificate[ ])req.getAttribute(“…X509Certificate”);
// NETCONF server can see client’s TLS certificate sent during TLS handshake here. }
public WebSocket doWebSocketConnect(HttpServletRequest req, String protocol){
// NETCONF server can see messages sent over WebSocket here.
As I mentioned before, we propose the use of Cookie for NETCONF username.
The advantage of Cookie is “ease of use.”
To set Cookie field at NETCONF client, following API is used.
And to get Cookie field at NETCONF server, there’re APIs provided by WebSocket server implementations.
To realize this, “Cookie Name” of something like “netconf_username” should be defined.
And “Cookie Value” should be set by NETCONF client as “foo,” for example.
And, above data should be sent at the time of WebSocket opening handshake from NETCONF client. And above data should be used for NETCONF username authentication at NETCONF server.

5. NETCONF message NETCONF Client WS Client WS Server NETCONF Server
Load html file
TLS handshake
NETCONF
username
GET
(HTTP server)
Start WebSocket (API)
GET
upgrade: WebSocket
protocol: NETCONF
HTTP/
upgrade: WebSocket
protocol: NETCONF
WebSocket
handshake
<hello>
The sequence of exchanging NETCONF messages becomes as follows.
At the time of WebSocket handshake, name of subprotocol and NETCONF username have to be sent.
When netconf username is authenticated, WebSocket connection is established.
After WebSocket connection is established, NETCONF messages are exchanged.
After NETCONF session is established by <hello> exchange and session ID allocation, NETCONF notifications are sent from NETCONF server.
<hello>
NETCONF
messages
on a
single session
<create-subscription>
<notification>

6. Conclusions
We proposed a way of sending NETCONF over WebSocket protocol.
We proposed extracting NETCONF username from TLS, that is complying with Mr. Badra’s algorithms.
Does WG have interests?
If YES, should this I-D move forward as an Experimental I-D?
In conclusion, we proposed a way of sending NETCONF over WebSocket protocol.
And, we proposed a usage of Cookie for NETCONF username authentication.
Does WG have interests?
If YES, should this I-D move forward as an Experimental I-D?
That’s it for our presentation.