Secure Zero Touch Provisioning

Secure Zero Touch Provisioning (SZTP), also referred to as secure ZTP is an implementation of RFC 8572, using the Ownership Voucher format from RFC 8366.

The SR Linux implementation of SZTP partially follows RFC 8572 and does not yet implement the full standard.

With SZTP, the operator bootstraps a network device without staging an initial configuration on the device before it joins the network. The deployment must still include DHCP, bootstrap servers, and ownership artifacts in the network. See SZTP process.

The primary function of the secure ZTP process is to securely bootstrap the node, providing it with the necessary information to boot into an operational state. This includes the initial artifacts to establish a mutual trust relationship between the node and the bootstrap server. After the node boots, it discovers the bootstrap server IP address, communicates with the server, and authenticates both the server and itself. The boot image is fetched via download-uri, and its integrity is verified using an image-verification hash. After verification, the device installs the image and applies the initial configuration information to ensure a secure bootstrapping process.

SR Linux uses different bootstrapping methods to obtain the required TLS certificates, trust anchors, and redirect information to connect securely to the server and download all the information required to boot in an operational mode.

SZTP builds trust into the onboarding workflow, validating the network devices and provisioning servers, making it suitable for both trusted and untrusted deployment scenarios.

Supported platforms

SZTP is supported on the following platforms:

  • 7220 IXR-H5
  • 7220 IXR-H6-64
  • 7250 IXR-X4
  • 7250 IXR-X4 OSFP
  • 7250 IXR-X1b
  • 7250 IXR-X3b
  • 7250 IXR-18e
  • 7250 IXR Gen 2c+
  • 7250 IXR Gen 3

SZTP components

Onboarding device

The Nokia router that you want to provision and connect to your network.

DHCP server

The DHCP server supplies the node with the SZTP bootstrap-server location through DHCPv4 option 143 or DHCPv6 option 136, which contains a list of bootstrap-server URIs.

Bootstrap server

The bootstrap server hosts the bootstrapping data, including the OS version and the initial device configuration. The SZTP bootstrap server is a RESTCONF server that communicates with the device over TLS.

The device obtains its bootstrapping information by invoking the get-bootstrapping-data RESTCONF RPC, which is defined in the IETF YANG module ietf-sztp-bootstrap-server (see RFC 8572). The GetBootstrapDataResponse structure contains the bootstrapping data. The SZTP uses the get-bootstrapping-data. It returns the necessary bootstrapping data, the Conveyed information, and, when signed, the Ownership Voucher and Ownership Certificate. The onboarding information contains the boot image (os-name, os-version, download-uri, image-verification hash), an initial configuration, and optional pre-/post-configuration scripts.

The onboarding device uses RPC report-progress to report progress only when the bootstrap server is trusted.

SZTP artifacts

SZTP artifacts are as follows:
  • TPM keys – The IDevID is used for TLS client authentication to the bootstrap server.
  • Redirect information – Data provided to an onboarding device that directs it to an alternative server or endpoint to obtain further configuration or bootstrapping data.
  • Onboarding information – Provides the data required for a device to bootstrap and establish secure connections with other systems.
  • Bootstrapping data – Bootstrapping data enables the CPM to carry out the following tasks:
    • redirect the CPM to a new source of bootstrapping data, such as an optional new bootstrap server
    • transfer device ownership and trust to the customer
    • specify which software image, configuration, and arbitrary scripts to run on the CPM
    The Conveyed Information, Ownership Voucher, and Ownership Certificate comprise the bootstrapping data artifacts that enable the CPM tasks.
  • Conveyed Information – The DHCP server only returns unsigned redirect information, whereas a bootstrap server can return redirection information (optional), onboarding information, and the ownership voucher and ownership certificate. Conveyed information is returned to the CPM as a Cryptographic Message Syntax (CMS) structure, as described in [RFC5652], signed by the customer's CA.
  • Onboarding information – Provides data necessary for a device to bootstrap and establish secure connections with other systems. It includes details about the boot image the device needs to run, an initial configuration it must commit, and the scripts it must execute successfully. Onboarding information is valid only when the CMS structure used to transmit the onboarding information is signed and verified against the customer's CA chain of trust.
  • Ownership Voucher (OV) – To support secure bootstrapping, an OV must be obtained by submitting a request to Nokia Support. The request must include the Pinned Domain Certificate, a trusted digital certificate issued by the customer and provided to Nokia during the OV request, and the order details containing the router serial numbers.
  • Ownership certificate (OC) – The OC represents an X.509 certificate that binds an owner's identity to a public key, allowing a device to validate a signature on the conveyed information artifact. A bootstrap server provides the OC to the device.
  • Pinned Domain Certificate (PDC) – The digital signature on the conveyed information is validated against the PDC, which is contained in the OV.
  • Trust anchor (TA) – A certificate the device uses to validate trust of bootstrap server’s TLS identity.

SZTP process

  1. Ensure the device has a Nokia CA-signed IDevID certificate in the TPM on each control card.
  2. Ensure the Nokia OV trust anchor is available on the CPM so the device can validate it.
  3. Obtain an OV by submitting a request to Nokia Support. The request must include the PDC, a trusted digital certificate issued by the customer and provided to Nokia during the OV request, along with the order details containing the router serial numbers. See SZTP components for information about the OV and other SZTP artifacts.
  4. Ensure that the DHCP server and the SZTP (RESTCONF) bootstrap server are configured in the network.
  1. The CPM initializes the secure bootstrapping process, as defined in the SZTP process (RFC 8572).
  2. The CPM verifies the digital signature of the acquired bootstrapping data. The CPM starts by validating the signature of the CMS structure of the OV against the Nokia trust anchor stored on the CPM. If the signature is valid, the contents of the OV can be trusted.
  3. The CPM extracts the PDC from the validated OV and verifies that the Ownership Certificate's (OC) chain of trust leads to that PDC. After transferring trust to the customer, the CPM uses the OC to validate the onboarding information within the conveyed-information structure.
  4. Note: The CPM must only use the onboarding information when digital signatures are verified.
    After the trust is established, the CPM uses the onboarding data to upgrade or download the software, apply the base configuration, and execute any scripts referenced in the onboarding information.

SZTP implementation guidelines

This topic describes rules and limitations that apply to the Nokia SR Linux SZTP implementation.

The implementation partially follows RFC 8572 and does not implement the full standard. See Secure Zero Touch Provisioning and SZTP process for an overview.

The workflows and behaviors in this topic reflect SZTP qualification for Release 26.7. Where a behavior changed in a later release, the release is stated.

Conveyed-information format

RFC 8572 allows the following three values for the inner eContentType of signed conveyed information:

  • The device supports id-ct-sztpConveyedInfoJSON from Release 26.10.1, t (OID 1.2.840.113549.1.9.16.1.43).
  • The device does not support id-ct-sztpConveyedInfoXML (OID 1.2.840.113549.1.9.16.1.42).
  • The device supports id-data (OID 1.2.840.113549.1.7.1) in all releases.
  • The device does not accept encrypted conveyed information for redirect or onboarding.

Nokia implementation behavior during SZTP

The following redirect bootstrapping limitations apply:

  • When a device receives the conveyed information with redirect information, it accepts the trust anchor only if the signature can be verified. This means the message from the bootstrap server must be conveyed information, along with the OV and OC.

  • The device must first validate the OV and OC signature to trust the redirect information and the TA of the next bootstrap server. In a dual-mode workflow, the first pass must use signed redirect information that includes the OV, PDC, and OC. The device does not support a first pass with unsigned redirect information that omits those artifacts, even when the second pass sends signed or unsigned onboarding information.

  • The redirect information can list only one bootstrap server (server, port, and TA). The device does not support multiple bootstrap servers in the redirect server list in this release.

Onboarding information handling

The following onboarding guidelines apply:

  • Only HTTP or HTTPS URIs are supported for the download URI in onboarding information, The device supports FQDN resolution for the download URI.
  • For configuration-handling, the device supports only the replace option. If the server sends the merge option, the device stops SZTP bootstrapping for that server and tries the next server or method. The device logs an error when it receives the merge option and, if the server is trusted, sends a bootstrap-error progress report.

Initial configuration and management ACL

If the configuration from the SZTP server applies CPM management filter ACLs, allow the TCP ports that the device used for SZTP when the bootstrap server did not use port 443. Allow these ports for IPv4 and IPv6.

After the device applies the configuration, management may switch to srbase-mgmt. Without the correct ACL entries, post-configuration progress reports may drop and the bootstrap may then fail.

Affected progress report types include config-complete, post-script-initiated, post-script-complete, post-script-warning, post-script-error, bootstrap-error, and bootstrap-complete.

The following example whitelists TCP source ports 8090 through 8099 for a laboratory SZTP server. Adjust the port range and entry numbers for your deployment.

CPM management filter entries for non-default SZTP ports

entry 900 {
    description SZTP-TEST-cpm-whitelist
    match {
        ipv4 {
            protocol tcp
        }
        transport {
            source-port {
                range {
                    start 8090
                    end 8099
                }
            }
        }
    }
    action {
        accept {
        }
    }
}
entry 900 {
    description SZTP-TEST-cpm-whitelist
    match {
        ipv6 {
            next-header tcp
        }
        transport {
            source-port {
                range {
                    start 8090
                    end 8099
                }
            }
        }
    }
    action {
        accept {
        }
    }
}

Dual CPM chassis installation

The following guidelines apply to chassis with two CPMs:

  • Install both CPMs before starting SZTP. SZTP can run with one CPM installed, but the device may not send a final bootstrap-complete progress report. The software does not require two CPMs for SZTP to start.
  • Program the TPM on both CPMs with IDevID certificates. Both CPMs must have factory-installed IDevID certificates. If the device cannot validate the standby CPM, it does not send the final bootstrap-complete report.