Subject: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05]

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Fri, 28 Mar 2014 15:42:27 +0000

Hello,

We have implemented the NETCONF over TLS and the Call Home mechanism as
described in the document [draft-ietf-netconf-rfc5539bis-05]. We used netopeer
[1] as our NETCONF server, and ncclient [2] as our NETCONF client.

[1] https://code.google.com/p/netopeer
[2] http://cnds.eecs.jacobs-university.de/software/ncclient

What works:

  - ncclient can now interact with netopeer over TLS 6513.
  - ncclient can listen on TCP XXXX (IANA TLS port). A call-home from netopeer
    reverses the roles, and a NETCONF client-server session is established.

Here are some implementation notes:

- tested interaction over TLS v1.0 [python 2.x does not support TLS v1.1/v1.2,
  TODO: need to port ncclient to python v3.4]
- used stunnel v5.0 as a proxy to handle TLS interaction on the server-side
  stunnel was patched to provide information for mapping cert to username.
- strict mutual authentication using stunnel [validate peer certificate
  against a trusted CA chain and check if cert is locally installed]
- interaction works over both v4 and v6.

Here is a list of issues that popped up while implementing
[draft-ietf-netconf-rfc5539bis-05].

Issue #1
--------

- How to handle ssh host key verification when multiple hosts are behind a
  NAT? - This is probably implementation specific. It depends how an SSH
client stores hosts keys. We thought to share this issue along anyway.

Issue #2
--------

- How to handle TLS certificate hostname verification when multiple hosts are
  behind a NAT? - Similar to #1. The NMS should have some kind of pre-defined
knowledge, that the hostname is correct (expected for the certificate). Maybe
this can be mentioned more explicitely in the NETCONF over TLS text.

Issue #3
--------

- What shall be the strictness of the TLS certificate mutual verification?
  a) validate the peer certificate against a trusted CA chain.
  b) validate using a) and check if peer certificate is locally installed.

  - We think it should be configurable, but it is _not_ covered by
    [ietf-netconf-server] data model. Should it be there?

Issue #4
--------

- Do we need to document NETCONF client-side configuration for NETCONF call
  home? - This is connected with #3 - do we need to configure how the client
should verify the server certificates? Or is validation of the certificates
completely out of scope (for both, server and client)?

Issue #5
--------

- [Section 2.6]: "Implementations of the protocol specified in this document
  MAY implement any TLS cipher suite that provides mutual authentication
  [RFC5246].  However, implementations MUST support TLS 1.2 [RFC5246] and are
  REQUIRED to support the mandatory-to-implement cipher suite, which is
  TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to future
  versions of TLS; in which case, the mandatory-to- implement cipher suite for
  the implemented version MUST be supported."

  - The CIPHER suites for TLS v1.2 are mandated by [RFC 5246: Section 9]. Do
    we need to mention them in this document?  We think we don't. Mandatory
    ciphers are specified by TLS specification and will probably change in
    future versions of TLS.

Issue #6
--------

- [Section 2.4]: "Implementations MAY optionally support TLS certificate-based
  authentication [RFC5246]."

  a) Does the MAY hint towards allowing PSK-based TLS support?
  b) We searched a bit on PSK-based TLS support in open-source projects:
    - openssl supports PSK, also available in s_server
    - stunnel does not support PSK, likely patchable.
    - python does not support PSK (neither Python 2 nor Python 3)

Issue #7
--------

- [Section 2.4.1]: "the NETCONF client MUST check its understanding of the
  NETCONF server hostname against the server's identity" [...] "If the NETCONF
  client has external information as to the expected identity of the NETCONF
  server, the hostname check MAY be omitted."

  a) MAY vs MUST

Issue #8
--------

- [Section 2.3]: "The NETCONF server MUST NOT process any NETCONF messages
  received after the <close-session> operation."

  This is mandated by NETCONF protocol specification. Would it be better to
  just refer to RFC 6241?

Issue #9
--------

- [Section 2.1.1]: Client to Server
- [Section 2.1.2]: Server to Client

  The client and server reverse roles during a NETCONF CALL HOME. Would it be
better to explicitly prefix "NETCONF" in the section titles?

Best Regards,
Radek and Vaibhav