NETCONF Call Home and RESTCONF Call Home
Extracted elements (20)
Call home is restricted to NETCONF and RESTCONF because those protocols require mutual identity verification, unlike base SSH and TLS which do not mandate programmatic verification of the other party. Allowing SSH/TLS server-initiated connections without application-layer identity checks would open new vulnerabilities.
Call home reverses only the TCP layer roles: the NETCONF/RESTCONF server initiates the TCP connection, but retains its SSH/TLS server role and NETCONF/RESTCONF server role. This preserves existing certificate chains and user authentication mechanisms so deployed management infrastructure can support call home without changes.
RESTCONF Call Home only supports TLS transport (not SSH), consistent with the RESTCONF protocol itself. NETCONF Call Home supports both SSH and TLS. Only the TCP initiator role is reversed; all other client/server roles (SSH/TLS layer, NETCONF/RESTCONF layer) remain the same as in client-initiated connections.
After server host key or certificate validation, the client MUST only use credentials that it had previously associated with the server's presented host key or certificate when performing client authentication.
If a certificate is sent by the server, the server MUST also send all intermediate certificates leading up to a well-known and trusted issuer, as defined for SSH in RFC 6187 Section 2.1 and for TLS in RFC 5246 Section 7.4.2.
If a persistent connection is desired, the NETCONF/RESTCONF server SHOULD actively test connection aliveness using keep-alives: HeartbeatRequest messages (RFC 6520) for TLS connections, or SSH_MSG_GLOBAL_REQUEST with a nonexistent request name and 'want reply' set to 1 for SSH connections.
If certificate path validation is used, the client MUST ensure the presented certificate has a valid chain of trust to a preconfigured issuer certificate, and that the certificate encodes an identifier (per RFC 6125) that the client was aware of before the connection attempt.
If transport-level client authentication is required and the client fails to authenticate itself within a time period defined by local policy, the server MUST close the connection.
The NETCONF/RESTCONF client MUST support accepting TCP connections on the IANA-assigned call home ports (4334, 4335, 4336), but MAY be configured to listen on a different port.
The NETCONF/RESTCONF client MUST validate the server's presented host key or certificate, either by certificate path validation or by comparing to a previously trusted/pinned value. If a certificate is presented with revocation-checking information, the client SHOULD check revocation status; if revoked, the client MUST immediately close the connection.
The NETCONF/RESTCONF server MUST support connecting to one of the IANA-assigned call home ports, but MAY be configured to connect to a different port. Port 4334 is used for NETCONF over SSH, 4335 for NETCONF over TLS, and 4336 for RESTCONF over TLS.
When using TLS, the NETCONF/RESTCONF client MUST advertise the 'peer_allowed_to_send' heartbeat extension (RFC 6520) so that servers can depend on it for keep-alives during call home connections.
The call home sequence is: (1) the NETCONF/RESTCONF server initiates a TCP connection to the client; (2) the client initiates an SSH or TLS session to the server over that TCP connection; (3) the client initiates a NETCONF or RESTCONF session to the server over the SSH/TLS session.
Three IANA-assigned TCP ports define call home variants: port 4334 (netconf-ch-ssh) for NETCONF Call Home over SSH, port 4335 (netconf-ch-tls) for NETCONF Call Home over TLS, and port 4336 (restconf-ch-tls) for RESTCONF Call Home over TLS.
This document registers three TCP port numbers in the IANA 'User Ports' range: 4334 (netconf-ch-ssh), 4335 (netconf-ch-tls), and 4336 (restconf-ch-tls), as the default ports for NETCONF Call Home and RESTCONF Call Home.
An attacker can launch a DoS attack on the call home client by triggering computationally expensive operations (e.g., TLS 1.3 KeyShare asymmetric operations) before being rejected. Mitigations such as temporarily blacklisting source addresses after repeated failed login attempts are recommended.
Internet-facing call home hosts are subject to fingerprinting via scanning tools (e.g., zmap). SSH/TLS clients may be less robust than servers to resulting attacks, so implementers MUST provide software update mechanisms to fix vulnerabilities in a timely fashion.
The TCP role reversal (SSH/TLS server initiating the TCP connection) is incongruous with RFC 4253 and RFC 6125, which assume client-initiated connections. The mitigations are mandatory server authentication via certificate path validation or pinning, and requiring the client to match an identifier in the certificate to a preconfigured expected identifier.
When using RESTCONF Call Home, special care is required with HTTP authentication schemes that convey shared secrets (Basic, Digest). Implementers and deployments should review the Security Considerations for any HTTP client authentication scheme used.
When using X.509 certificates, the preconfigured issuer certificate used for path validation SHOULD be unique to the server's manufacturer and not belong to a third-party CA that could issue certificates for multiple manufacturers, to prevent credential leakage to a rogue server with a matching identity (e.g., same serial number).