From: Warren Kumari <war...@kumari.net> Sent: 06 April 2020 16:07 On Mon, Apr 6, 2020 at 6:36 AM tom petch <ie...@btconnect.com> wrote: > > Warren > > Where I think I get confused with this is its context. Abstract talks of > travelling to a datacentre and elsewhere there are references to a POP, both > of which to me have a flavour of a well-staffed high in technical expertise > locations where this sort of work is little needed. I think more of > enterprise, where an organisation may have two well equipped data centres and > dozens or hundreds of locations with little or no support staff where this > issue is paramount. I think that this is more a question of language than of > changing the technical details but it does keep jarring with me. In the same > vein, the references to routers jars with me since while that may be an issue > in an operator POP, I see the need to configure other kinds of servers as > more pressing. > > The other more technical issue is TFTP which yes, I expect will be widely > used but which, IMHO, is only ever used over a LAN and so, short of VLAN, > which indeed some enterprise do use, implies that the device and config > server are on the same LAN, ie in the same building or at least campus. > Again, it is a question of context, is it assumed that device and server are > proximal?
It is often surprising to me just how much one's experiences and situations influence one's assumptions and outlook - it seems that I may have assumed that others have the same experiences / didn't explain the context well. It is quite common that operators want to install a peering router / switch at a location where they have no employees - common examples of this are IXP / POP / data-center / anywhere where they peer with others (e.g Ashburn Equinix). While there are (often) technical people at the location, they are either employed by the datacenter operator (e.g Equinix, AMS-IX), or by one's "competitors" - this means that you really don't want to hand them a copy of your config file and ask them to stick it on the device. Operators generally order a circuit from inside their network to the location, and then order a device to be shipped there... and then have to dispatch a person to stick the initial config on the device. Traditional (unencrypted) autoboot doesn't solve this, because $whoever could just plug their laptop into the newly installed circuit, perform the autoboot routine, and have a copy of the config. Another very common case is for an ISP (think Verizon, or Telus) to deliver a circuit to a customer - they have a contractor which delivers the fiber, and then roll a truck to have someone physically plug in a PE / CPE router and install the initial config. Again, they don't really want to hand the config to the user, and also cannot use the current autoboot solutions for the same reason - the customer could just plug their own device / laptop into the newly installed circuit, autoboot and grab the config / join the IGP / whatever. These are the specific use-case that this is intending to solve - many / almost all network devices already support some sort of autoboot where they DHCP (or similar) and then fetch (TFTP is a very common mechanism[0], but by no means the only one) an **unencrypted** config file -- all that this document does is say "keep doing that, but download an encrypted config instead". It intentionally is kept simple - vendors already have their own autoboot functionality and this is a simple patch to that. Vendors also already have a way to put per-device state (such as a serial number, licence, and often crypto goop in a TPM, etc) - in some cases all they will need to do is publish the public key, indexed by the serial number (a number of vendors have said that this will be trivial). The document is intentionally kept flexible because so much of this builds on vendor proprietary solutions; and so instead of saying "Step 1: Do X. Step 2: Do Y, ... Step N: Do N", it describes the concept, and leaves it to the (more than capable) vendors to figure out how to implement it in their system. This also is only aimed at network devices - other types of servers may be more pressing, but this document tries not to boil the ocean - it simply says "instead of grabbing an unencrypted config, grab an encrypted one, decrypt it and done!" Hopefully this better sets the scene / explains the context and use case? I'm not sure if there is a concise way to explain this in the draft... <tp> Warren, thanks for that., I sort of guessed the first but not the second. For the second, do you get TFTP over a newly laid fibre? I was thinking not based on what I have seen but if you do then that is fine.. Scenarios I have encountered do not fit either of these two e.g. upgrades to a remote enterprise office with lots of staff but no technical expertise or the installation of a single device that must be secure (e.g. Hole in the Wall) but that is ok, it is just that I do not quite see the draft excluding them, I think that it is possible to write an introduction that limits the scope along the lines you sketch out. Do you have any other scenario? Tom Petch W [0]: I'm using in the document because it is the archetype, and familiar to the intended audience... > > I would like to see these two points nailed down more after which I could > propose some refinement to the language. > > Tom Petch > > ________________________________________ > From: OPSAWG <opsawg-boun...@ietf.org> on behalf of internet-dra...@ietf.org > <internet-dra...@ietf.org> > Sent: 03 April 2020 21:40 > To: i-d-annou...@ietf.org > Cc: opsawg@ietf.org > Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-sdi-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > WG of the IETF. > > Title : Secure Device Install > Authors : Warren Kumari > Colin Doyle > Filename : draft-ietf-opsawg-sdi-06.txt > Pages : 18 > Date : 2020-04-03 > > Abstract: > Deploying a new network device often requires that an employee > physically travel to a datacenter to perform the initial install and > configuration, even in shared datacenters with "smart-hands" type > support. In many cases, this could be avoided if there were a > standard, secure way to initially provision the devices. > > This document extends existing auto-install / Zero-Touch Provisioning > mechanisms to make the process more secure. > > [ Ed note: Text inside square brackets ([]) is additional background > information, answers to frequently asked questions, general musings, > etc. They will be removed before publication. This document is > being collaborated on in Github at: https://github.com/wkumari/draft- > wkumari-opsawg-sdi. The most recent version of the document, open > issues, etc should all be available here. The authors (gratefully) > accept pull requests. ] > > [ Ed note: This document introduces concepts and serves as the basic > for discussion - because of this, it is conversational, and would > need to be firmed up before being published ] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-sdi-06 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sdi-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-sdi-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg