< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/