Using the NETCONF Configuration Protocol over Secure SHell (SSH)
obsoleted by
- rfc-6242 — Using the NETCONF Protocol over Secure Shell (SSH)
Extracted elements (21)
NETCONF servers are required to default to TCP port 830 to allow NETCONF traffic to be easily identified and filtered by firewalls; the trade-off is that this also makes it more easily identified by attackers.
Running NETCONF as an SSH subsystem (rather than a shell command) avoids the need to recognize shell prompts or skip extraneous shell start-up messages, simplifying client implementation. SSHv2 subsystem support is required since SSHv1 does not include it.
The ]]>]]> framing sequence was chosen because it cannot legally appear in XML, allowing it to unambiguously delimit messages and enable resynchronization after XML syntax or parsing errors.
NETCONF over SSH requires SSH version 2 (SSHv2); subsystem support used to invoke the 'netconf' subsystem is a feature of SSHv2 and is not available in SSHv1.
Implementations MUST skip over extraneous messages from user start-up scripts by searching for an 'xml' start directive, which MUST be followed by a <hello> element in the 'NETCONF' namespace.
NETCONF servers MUST default to providing access to the 'netconf' SSH subsystem only when the SSH session is established using the IANA-assigned TCP port 830.
Servers SHOULD be configurable to allow access to the netconf SSH subsystem over other ports beyond the default port 830.
The agent MUST NOT process any RPC commands received on the current session after the <close-session> command.
The document containing the <hello> element MUST be the first XML document that the client sends after the NETCONF session is established.
The identity of the client MUST also be verified and authenticated by the server according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is exchanged.
The identity of the server MUST be verified and authenticated by the client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the server.
The server MUST indicate its capabilities by sending an XML document containing a <hello> element as soon as the NETCONF session is established.
The special character sequence ]]>]]> MUST be sent by both the client and the server after each XML document in the NETCONF exchange to delimit message boundaries.
After capabilities exchange, the manager sends complete XML documents containing <rpc> elements and the agent responds with complete XML documents containing <rpc-reply> elements, each terminated by ]]>]]>.
NETCONF is invoked as an SSH subsystem named 'netconf' within an SSH session of type 'session', using the ssh-connection service after successful ssh-userauth authentication.
Session termination is accomplished via the <close-session> operation; the agent processes it in order, responds with <ok>, and then closes the SSH session channel.
The <hello> element exchange establishes the capabilities of both client and server at session start; the server sends first, and the client's <hello> must be its first XML document. The <hello> contains a <capabilities> list and the server includes a <session-id>.
IANA assigned TCP port 830 as the default port for NETCONF over SSH sessions, and assigned 'netconf' as an SSH Service Name as defined in RFC 4250.
Configuring NETCONF to operate on non-default ports without corresponding firewall changes may unintentionally expose the netconf SSH subsystem to nodes outside administrative boundaries.
NETCONF accesses and modifies configuration and state data, which may include sensitive information such as usernames or security keys; access must be limited to authorized users and systems, and NETCONF should only be used over channels providing strong encryption.
Each XML document in the NETCONF/SSH exchange is terminated by the framing sequence ]]>]]>, which cannot legally appear in an XML document and thus serves as an unambiguous end-of-message delimiter.