draft-ietf-opsawg-sdi-06.txt   draft-ietf-opsawg-sdi-07.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: October 5, 2020 Juniper Networks Expires: October 9, 2020 Juniper Networks
April 03, 2020 April 07, 2020
Secure Device Install Secure Device Install
draft-ietf-opsawg-sdi-06 draft-ietf-opsawg-sdi-07
Abstract Abstract
Deploying a new network device often requires that an employee Deploying a new network device in a location where the operator has
physically travel to a datacenter to perform the initial install and no staff of its own often requires that an employee physically travel
configuration, even in shared datacenters with "smart-hands" type to the location to perform the initial install and configuration,
support. In many cases, this could be avoided if there were a even in shared datacenters with "smart-hands" type support. In many
standard, secure way to initially provision the devices. cases, this could be avoided if there were a secure way to initially
provision the device.
This document extends existing auto-install / Zero-Touch Provisioning This document extends existing auto-install / Zero-Touch Provisioning
mechanisms to make the process more secure. mechanisms to make the process more secure.
[ Ed note: Text inside square brackets ([]) is additional background [ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings, information, answers to frequently asked questions, general musings,
etc. They will be removed before publication. This document is etc. They will be removed before publication. This document is
being collaborated on in Github at: https://github.com/wkumari/draft- being collaborated on in Github at: https://github.com/wkumari/draft-
wkumari-opsawg-sdi. The most recent version of the document, open wkumari-opsawg-sdi. The most recent version of the document, open
issues, etc should all be available here. The authors (gratefully) issues, etc should all be available here. The authors (gratefully)
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 October 5, 2020. This Internet-Draft will expire on October 9, 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 3, line 16 skipping to change at page 3, line 16
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. . . . . . . . . 17
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 simply deploying new devices and "forklift" upgrading are spent deploying new devices and "forklift" upgrading existing
existing devices. In many cases, these devices are in shared devices. In many cases, these devices are in shared datacenters (for
datacenters (for example, Internet Exchange Points (IXP) or "carrier example, Internet Exchange Points (IXP) or "carrier neutral
neutral datacenters"), which have staff on hand that can be datacenters"), which have staff on hand that can be contracted to
contracted to perform tasks including physical installs, device perform tasks including physical installs, device reboots, loading
reboots, loading initial configurations, etc. There are also a initial configurations, etc. There are also a number of (often
number of (often vendor proprietary) protocols to perform initial vendor proprietary) protocols to perform initial device installs and
device installs and configurations - for example, many network configurations - for example, many network devices will attempt to
devices will attempt to use DHCP [RFC2131]to get an IP address and use DHCP [RFC2131]to get an IP address and configuration server, and
configuration server, and then fetch and install a configuration when then fetch and install a configuration when they are first powered
they are first powered on. on.
Network device configurations contain a significant amount of The configurations of network devices contain a significant amount of
security related and / or proprietary information (for example, security related and / or proprietary information (for example,
RADIUS [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets). RADIUS [RFC2865] or TACACS+ [I-D.ietf-opsawg-tacacs] secrets).
Exposing these to a third party to load onto a new device (or using Exposing these to a third party to load onto a new device (or using
an auto-install techniques which fetch an unencrypted config file via an auto-install techniques which fetch an unencrypted config file via
something like TFTP [RFC1350]) is simply not acceptable to many TFTP [RFC1350]) or something similar, is an unacceptable security
operators, and so they have to send employees to remote locations to risk for many operators, and so they send employees to remote
perform the initial configuration work. As well as having a locations to perform the initial configuration work; this costs, time
significant monetary cost, it also takes significantly longer to and money.
install devices and is generally inefficient.
There are some workarounds to this, such as asking the vendor to pre- There are some workarounds to this, such as asking the vendor to pre-
configure the devices before shipping it; asking the smart-hands to configure the devices before shipping it; asking the smart-hands to
install a terminal server; providing a minimal, unsecured install a terminal server; providing a minimal, unsecured
configuration and using that to bootstrap to a complete configuration and using that to bootstrap to a complete
configuration, etc; but these are often clumsy and have security configuration, etc; but these are often clumsy and have security
issues - for example, in the terminal server case, the console port issues - for example, in the terminal server case, the console port
connection could be easily snooped. connection could be easily snooped.
This document layers security onto existing auto-install solutions to This document layers security onto existing auto-install solutions to
provide a secure method to initially configure new devices. It is provide a secure method to initially configure new devices. It is
optimized for simplicity, both for the implementor and the operator; optimized for simplicity, both for the implementor and the operator;
it is explicitly not intended to be an "all singing, all dancing" it is explicitly not intended to be an "all singing, all dancing"
fully featured system for managing installed / deployed devices, nor fully featured system for managing installed / deployed devices, nor
is it intended to solve all use-cases - rather it is a simple is it intended to solve all use-cases - rather it is a simple
targeted solution to solve a common operational issue. Solutions targeted solution to solve a common operational issue where the
such as Secure Zero Touch Provisioning (SZTP)" [RFC8572], network device has been delivered, fibre laid (as appropriate) but
there is no trusted member of the operator's staff to perform the
initial configuration.
Solutions such as Secure Zero Touch Provisioning (SZTP)" [RFC8572],
[I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more [I-D.ietf-anima-bootstrapping-keyinfra] and similar are much more
fully featured, but also more complex to implement and / or are not fully featured, but also more complex to implement and / or are not
widely deployed yet. widely deployed yet.
This solution is specifically designed to be a simple method on top This solution is specifically designed to be a simple method on top
of exiting device functionality. If devices do not support this new of exiting device functionality. If devices do not support this new
method, they can continue to use the existing functionality. In method, they can continue to use the existing functionality. In
addition, operators can choose to use this to protect their addition, operators can choose to use this to protect their
configuration information, or can continue to use the existing configuration information, or can continue to use the existing
functionality. functionality.
skipping to change at page 12, line 31 skipping to change at page 12, line 31
Over" situation. Over" situation.
Even when using a secure bootstrapping mechanism, security conscious Even when using a secure bootstrapping mechanism, security conscious
operators may wish to bootstrapping devices with a minimal / less operators may wish to bootstrapping devices with a minimal / less
sensitive config, and then replace this with a more complete one sensitive config, and then replace this with a more complete one
after install. after install.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank everyone who contributed, including Benoit The authors wish to thank everyone who contributed, including Benoit
Claise, Francis Dupont, Tom Petch, Sam Ribeiro, Michael Richardson, Claise, Francis Dupont, Sam Ribeiro, Michael Richardson, Sean Turner
Sean Turner and Kent Watsen. Joe Clarke also provided significant and Kent Watsen. Joe Clarke also provided significant comments and
comments and review. review, and Tom Petch provided significant editorial contributions to
better describe the use cases, and clarify the scope.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 9 change blocks. 
31 lines changed or deleted 36 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/