Re: [Netconf] draft-ietf-netconf-zerotouch-21 feedback

[Tarko Tikan <[e-mail]>]

hey,

> This draft does not enable putting an "owner CA trust anchor" on a device
> from manufacturing.  Section 5.1 describes devices possessing a list of
> trust anchor certs for *well-known* bootstrap servers and issuers of
> ownership vouchers.  By well-known, we mean something along the lines
> of a MASA (manufacturer assured signing authority), not a deployment-
> specific trust anchor for a specific owner.

OK, fair enough. I'm not sure how this will work out in L3VPN/private 
management scenarios where internet access might not be available.

> Insecure zero touch bootstrapping mechanisms have been available for some
> time.  What's new with this work is that it is secured.  There cannot be
> an insecure mode, as that would then enable a degradation-attack, whereby
> the attacker blocks the device from reaching secured resources, causing
> the device to ultimately land on an insecure resource the attacker controls.

I fully agree with the security part. But I find this draft interesting 
because it might finally be something that is actually usable in 
production in multivendor environment. While insecure ZTP 
implementations exist today, they are not really usable unless you have 
the strict serial-number to the devicetype to the customer mapping.

> SZTP is usable in real life today, but there is the expectation that, for
> devices with multiple interfaces, that a specific port would always be
> used, at least within that owner's organization.  This works pretty well,
> but there are cases where optional hardware (i.e., an LTE modem) might
> be attached, which can introduce variability in the initial configuration
> that should be pushed to the device.  This draft addresses this (kind of)
> via the "hw-model" input parameter and name-mangling (e.g., srx250-lte).
> This is a little bit hacky, but trying to come up with something better
> was more complicated than I wanted to get into at this time.  Vendor-
> specific input parameters can be used now, if needed.
> 
> You started this saying that the device may have multiple ZTP capable
> interfaces and it's not known which interface might be used during
> installation.  It's important to note that SZTP-itself doesn't care
> which interface is used to get the bootstrapping data (it can even
> be read off a removable storage device).  What matters is what
> interface(s) the initial config needs to configure, which may not
> necessarily be the same as the interface used for the SZTP call.
> My claim is that this is fairly predictable within a deployment,
> such that canned responses work great.  Can you provide a more
> concrete example where this doesn't work?

Agree about the ZTP interface part and in most cases, the interface 
thats being used for ZTP bootstrapping, is the interface thats needs to 
be used towards the SP network.

Concrete example where you cannot predict the interface is device with 
1G copper and 1G SFP interface. Either can be used based on customer 
location:

- customer colocated at the AN site = use copper

- customer connected to AN via fiber = use SFP

-- 
tarko