draft-ietf-opsawg-sdi-09.txt   draft-ietf-opsawg-sdi-10.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational C. Doyle Intended status: Informational C. Doyle
Expires: November 8, 2020 Juniper Networks Expires: November 12, 2020 Juniper Networks
May 7, 2020 May 11, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-09 draft-ietf-opsawg-sdi-10
Abstract Abstract
Deploying a new network device in a location where the operator has Deploying a new network device in a location where the operator has
no staff of its own often requires that an employee physically travel no staff of its own often requires that an employee physically travel
to the location to perform the initial install and configuration, to the location to perform the initial install and configuration,
even in shared datacenters with "smart-hands" type support. In many even in shared datacenters with "smart-hands" type support. In many
cases, this could be avoided if there were a secure way to initially cases, this could be avoided if there were a secure way to initially
provision the device. provision the device.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2020. This Internet-Draft will expire on November 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14
Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15 Appendix B. Demo / proof of concept . . . . . . . . . . . . . . 15
B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16 B.1. Step 1: Generating the certificate. . . . . . . . . . . . 16
B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16 B.1.1. Step 1.1: Generate the private key. . . . . . . . . . 16
B.1.2. Step 1.2: Generate the certificate signing request. . 16 B.1.2. Step 1.2: Generate the certificate signing request. . 16
B.1.3. Step 1.3: Generate the (self signed) certificate B.1.3. Step 1.3: Generate the (self signed) certificate
itself. . . . . . . . . . . . . . . . . . . . . . . . 16 itself. . . . . . . . . . . . . . . . . . . . . . . . 16
B.2. Step 2: Generating the encrypted config. . . . . . . . . 16 B.2. Step 2: Generating the encrypted config. . . . . . . . . 17
B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17 B.2.1. Step 2.1: Fetch the certificate. . . . . . . . . . . 17
B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 17 B.2.2. Step 2.2: Encrypt the config file. . . . . . . . . . 17
B.2.3. Step 2.3: Copy config to the config server. . . . . . 17 B.2.3. Step 2.3: Copy config to the config server. . . . . . 17
B.3. Step 3: Decrypting and using the config. . . . . . . . . 17 B.3. Step 3: Decrypting and using the config. . . . . . . . . 17
B.3.1. Step 3.1: Fetch encrypted config file from config B.3.1. Step 3.1: Fetch encrypted config file from config
server. . . . . . . . . . . . . . . . . . . . . . . . 17 server. . . . . . . . . . . . . . . . . . . . . . . . 17
B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 17 B.3.2. Step 3.2: Decrypt and use the config. . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In a growing, global network, significant amounts of time and money In a growing, global network, significant amounts of time and money
are spent deploying new devices and "forklift" upgrading existing are spent deploying new devices and "forklift" upgrading existing
devices. In many cases, these devices are in shared datacenters (for devices. In many cases, these devices are in shared datacenters (for
example, Internet Exchange Points (IXP) or "carrier neutral example, Internet Exchange Points (IXP) or "carrier neutral
datacenters"), which have staff on hand that can be contracted to datacenters"), which have staff on hand that can be contracted to
perform tasks including physical installs, device reboots, loading perform tasks including physical installs, device reboots, loading
skipping to change at page 5, line 29 skipping to change at page 5, line 29
instead be HTTP, FTP, etc. ] instead be HTTP, FTP, etc. ]
2.1. Example Scenario 2.1. Example Scenario
Operator_A needs another peering router, and so they order another Operator_A needs another peering router, and so they order another
router from Vendor_B, to be drop-shipped to the Point of Presence router from Vendor_B, to be drop-shipped to the Point of Presence
(POP) / datacenter. Vendor_B begins assembling the new device, and (POP) / datacenter. Vendor_B begins assembling the new device, and
tells Operator_A what the new device's serial number will be tells Operator_A what the new device's serial number will be
(SN:17894321). When Vendor_B first installs the firmware on the (SN:17894321). When Vendor_B first installs the firmware on the
device and boots it, the device generates a public-private keypair, device and boots it, the device generates a public-private keypair,
and Acme publishes the public key on their keyserver (in a public key and Vendor_B publishes the public key on their keyserver (in a public
certificate, for ease of use). key certificate, for ease of use).
While the device is being shipped, Operator_A generates the initial While the device is being shipped, Operator_A generates the initial
device configuration, fetches the certificate from Vendor_B device configuration, fetches the certificate from Vendor_B
keyservers by providing the serial number of the new device. keyservers by providing the serial number of the new device.
Operator_A then encrypts the device configuration and puts this Operator_A then encrypts the device configuration and puts this
encrypted config on a (local) TFTP server. encrypted config on a (local) TFTP server.
When the device arrives at the POP, it gets installed in Operator_A' When the device arrives at the POP, it gets installed in Operator_A'
rack, and cabled as instructed. The new device powers up and rack, and cabled as instructed. The new device powers up and
discovers that it has not yet been configured. It enters its discovers that it has not yet been configured. It enters its
skipping to change at page 6, line 18 skipping to change at page 6, line 18
3. Vendor Role / Requirements 3. Vendor Role / Requirements
This section describes the vendors roles and responsibilities and This section describes the vendors roles and responsibilities and
provides an overview of what the device needs to do. provides an overview of what the device needs to do.
3.1. Device key generation 3.1. Device key generation
Each devices requires a public-private key keypair, and for the Each devices requires a public-private key keypair, and for the
public part to be published and retrievable by the operator. The public part to be published and retrievable by the operator. The
cryptograthic algorithm and key lenghts to be used are out of the cryptograthic algorithm and key lengths to be used are out of the
scope of this document. This section illustrates one method, but, as scope of this document. This section illustrates one method, but, as
with much of this document the exact mechanism may vary by vendor. with much of this document the exact mechanism may vary by vendor.
EST [RFC7030]and [I-D.gutmann-scep] are methods which vendors may EST [RFC7030]and [I-D.gutmann-scep] are methods which vendors may
want to consider. want to consider.
During the manufacturing stage, when the device is initially powered During the manufacturing stage, when the device is initially powered
on, it will generate a public-private keypair. It will send its on, it will generate a public-private keypair. It will send its
unique device identifier and the public key to the vendor's unique device identifier and the public key to the vendor's
Certificate Publication Server to be published. The vendor's Certificate Publication Server to be published. The vendor's
Certificate Publication Server should only accept certificates from Certificate Publication Server should only accept certificates from
skipping to change at page 14, line 19 skipping to change at page 14, line 19
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
From -08 to -08 From -09 to -10
o Typos - "lenghts" => "lengths", missed a reference to Acme.
From -08 to -09
o Addressed Mirja's IETF LC comments. o Addressed Mirja's IETF LC comments.
From -04 to -08 From -04 to -08
o Please see GitHub commit log (I forgot to put them in here :-P ) o Please see GitHub commit log (I forgot to put them in here :-P )
From -03 to -04 From -03 to -04
o Addressed Joe's WGLC comments. This involved changing the "just o Addressed Joe's WGLC comments. This involved changing the "just
 End of changes. 8 change blocks. 
10 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/