A NETCONF-managed device sits behind NAT and accepts no inbound connections; how does NETCONF call home let a manager reach it, and which roles reverse?
answer
- the device dials out
- only one layer flips
- dedicated listening ports on the manager
- verify the server that called you
- keep the mapping alive
basics
~20 sWith NETCONF call home (RFC 8071) the device opens the TCP connection to the manager, on port 4334 for SSH or 4335 for TLS. Only the TCP role reverses: the device remains the SSH or TLS server and the NETCONF server.
solid answer
~40 sRFC 8071 lets the device, the **NETCONF server**, initiate the TCP connection to the manager, the **NETCONF client**, which listens on TCP **4334** for SSH or **4335** for TLS (4336 is RESTCONF call home). **Only the TCP role reverses**: the device is still the SSH or TLS server and the NETCONF server, so existing host keys, certificates and user authentication keep working. That reaches devices behind NAT, with dynamic addresses, or behind firewalls that forbid inbound management. Because the client did not choose whom to dial, it **must** validate the device's host key or certificate against a pinned value, or a preconfigured issuer plus an identifier it expected, such as a serial number. The device, as initiator, should send keepalives so a long-lived session survives idle timeouts.
go deeper
Recall that call home means the device connects out to its manager, which helps when the device cannot accept inbound connections.
Explain that only the TCP role reverses, name the listening ports for SSH and TLS, and say that the NETCONF session then starts with the usual hello exchange.
Show the security judgement: pinned keys or a manufacturer-specific issuer plus an expected identifier, credentials sent only to the matching device, and keepalives from the device across NAT.
Weigh the operating model: one hardened listener in the data centre against open management ports on every device, and what zero-touch registration needs from manufacturing identities.
## The problem call home solves In ordinary NETCONF the **client**, usually a management system, opens a TCP connection to the **server**, the network device, on port 830 for SSH (RFC 6242) or 6513 for TLS (RFC 7589). That assumes the device is reachable. RFC 8071, **NETCONF Call Home and RESTCONF Call Home**, lists situations where it is not: - the device sits behind a firewall that performs **NAT** for internal addresses; - it gets a **dynamic address** that no mapping service registers; - the firewall allows **no inbound management access** at all; - the device runs with **no open ports**; - it is powered on for the first time and should **register itself** with its manager; - the operator prefers to secure **one open port in the data centre** over an open port on every device. ## Exactly what reverses RFC 8071 keeps every role but one. The single reversal is at the **TCP layer**. | Layer | Client-initiated NETCONF | NETCONF call home | |---|---|---| | TCP | Manager connects, device listens | **Device connects, manager listens** | | SSH or TLS | Device is server, manager is client | Unchanged | | NETCONF | Device is server, manager is client | Unchanged | Keeping the upper roles means existing certificate chains and user authentication are unaffected. The device still presents its host key or certificate, and the manager still authenticates as the user. RFC 8071 notes this departs from RFC 4253, which says the SSH client initiates the connection. ## The steps With the IANA-assigned ports, RFC 8071 Sections 3 and 4 run as follows: 1. The manager **listens** on TCP **4334** (`netconf-ch-ssh`) and/or **4335** (`netconf-ch-tls`); **4336** (`restconf-ch-tls`) is the RESTCONF equivalent. 2. The device **connects** to one of them. 3. On that TCP connection the device starts the **SSH or TLS server** and the manager the **SSH or TLS client**: SSH on 4334, TLS on 4335. 4. The manager **validates** the device's host key or certificate (next section). 5. The manager authenticates to the device, using only credentials it had previously associated with that host key or certificate. 6. The NETCONF session starts as usual: both send `<hello>`, the device's hello carries the session ID, and the same framing rules apply. ## Authenticating a server that called you Normally a client chooses whom to connect to and checks that the server's identity matches. In call home the manager did not choose, so RFC 8071 adds requirements: - The manager **MUST** validate the device's host key or certificate, either by **certificate path validation** to a **preconfigured issuer** or by comparing it with a previously trusted, **pinned** value. - When it uses certificate path validation, it **MUST** also find an **identifier** in the certificate that it expected *before* the connection, such as a serial number. - RFC 8071 advises that the trusted issuer be **unique to the device's manufacturer**, not a third-party authority that signs for many manufacturers, especially when the manager will send a password. Otherwise it could hand that secret to another device that happens to share the expected identifier. - The listener is reachable by anyone, so ordinary **denial-of-service** precautions apply, such as temporarily blocking a source after repeated failed attempts. ## Keeping the connection alive A call-home session usually crosses NAT, whose idle mappings expire. RFC 8071 says the device, as initiator, **SHOULD** test aliveness when a persistent connection is wanted: - over **SSH**, by sending `SSH_MSG_GLOBAL_REQUEST` with a deliberately nonexistent request name and "want reply" set; - over **TLS**, by sending heartbeat requests (RFC 6520), and the manager **MUST** advertise `peer_allowed_to_send` so the device can rely on it. ## Where NETCONF over TLS fits Call home over TLS uses the TLS mapping of **RFC 7589** (it obsoletes RFC 5539). That mapping requires **mutual certificate authentication**: the server must request a client certificate, and identities are verified before the hello. The server derives the NETCONF username from the client certificate through an ordered list of fingerprint-to-name mappings. Framing is the same as over SSH: hellos end with `]]>]]>`, and chunked framing follows when both list `:base:1.1`. ## What call home does not change Once the secure transport is up, nothing above it knows who dialled. The hello exchange, the session ID, the RPCs, locking and `<close-session>` behave exactly as in a client-initiated session; closing the session closes the connection the device opened, and the device's own configuration decides when it calls again.
- Why does RFC 8071 require the manager to know an identifier, such as a serial number, before the connection arrives?Because the manager did not choose the peer. A certificate chaining to a trusted issuer proves only that the issuer certified some device; matching an identifier configured in advance ties the session to the device the manager expects, before it sends credentials.
- Which side sends keepalives in a call-home session, and why that side?The device. RFC 8071 says the initiator SHOULD test aliveness when a persistent connection is wanted: over SSH with a global request naming a nonexistent request and asking for a reply, over TLS with heartbeat requests. Traffic from the inside keeps the NAT mapping and firewall state alive.
saying these in an interview costs you the question
- In call home the device becomes the SSH client and the manager the SSH server.
- Call home works by the device opening port 830 on the manager.
- Because the device dialled in, the manager can trust whatever key it presents.
- Any public certificate authority is a fine trust anchor for call-home devices.
- Call home replaces SSH and TLS with a NETCONF-specific handshake.