Trusted ZTP - First Version of HLD

[thovikeerthi]

HLD proposal for Trusted Zero Touch Provisioning (tZTP)

Introduction for Reviewers

What this HLD proposes.
A factory-fresh SONiC switch today learns where to fetch its configuration from DHCP (option 67), downloads ztp.json over HTTP/TFTP, and applies it.
Every trust decision in that flow is implicit: the switch trusts the DHCP server because it answered first, the URL because DHCP said so, and the payload because it downloaded cleanly. It cannot tell an operator's provisioning server from an attacker's, cannot prove to the server which switch it is, and cannot verify that the configuration is the one the operator actually authored.

Trusted ZTP (tZTP) closes those gaps by implementing a solution which builds over a open-source/3rd party RFC 8572 Secure Zero Touch Provisioning solution-agent.

Three ideas carry the design:

• Identity is a certificate, not an address. Each switch holds a per-unit X.509 certificate with its serial number in the Subject/SAN and presents it as the TLS client certificate. The bootstrap server extracts that serial and uses it to look up the switch's onboarding profile. (Appendix A.)
• The payload is signed independently of the transport.
• Ownership is provable without prior contact.

Two trust models follow from this: trusted-server (the operator's CA is pre-installed, so the server is validated before any data is accepted) and voucher-anchored (only the manufacturer's anchor is present, so the server is validated after connecting, via the voucher). The second is what makes blind drop-ship deployment possible; Appendices D and E walk each end to end.

What actually changes in SONiC.
Deliberately little. tZTP adds only a trust front-end — it authenticates the server, the device, the ownership chain, and the payload signature — and then hands a validated payload to the existing, unmodified ztp-engine.py and its plugins.

Changes are confined to sonic-ztp (new modules ahead of the existing engine), sonic-buildimage, sonic-yang-models, sonic-utilities (CLI) and sonic-mgmt (tests). No changes to SWSS, orchagent, syncd, SAI, or the ASIC — no SAI API impact. The RFC 8572 client itself is a reused open-source component, isolated behind a single adapter so it can be replaced without touching anything else.

Backward compatibility is requirement #1, not an afterthought. The feature is off by default (trusted_mode=false). A three-state mode model — off / transition / enforced — lets operators stage a rollout.
In enforced mode, legacy option-67 discovery is refused so downgrade attacks are blocked, and any failed trust check applies nothing at all — no image, no configuration, no script.

Scope. Phase 1 (this document) delivers the full protocol and trust chain with a file-based device identity, so it runs on whitebox hardware - developmental. Phase 2 (follow-up HLD) moves the key into a TPM 2.0 with IEEE 802.1AR IDevID/LDevID and EST enrollment - deployment ready; the onboarding logic is identical, only the key's storage location changes. Securing the NOS image download during ONIE install, and the bootstrap server implementation itself, are out of scope.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.