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

[Tarko Tikan <[e-mail]>]

hey,

>> I might be mistaken but currently it looks like secure bootstrap is not
>> possible without properly precustomized devices. If hw-model, os-name
>> etc. are not sent in get-bootstrapping-data in untrusted mode it becomes
>> impossible to generate correct configuration for the device.
> 
> I'm curious what you mean by the first sentence.  Looking to the 2nd
> sentence for clues, be aware that those three input parameters are
> optional and only needed in select cases.  When get-bootstrapping-data is
> sent to an untrusted bootstrap server, the primary input is the device's
> authentication credentials (e.g., TLS-level client certificate) with
> which the bootstrap server can use to return signed data.  Please take
> a look at Appendix A (Promoting a Connection from Untrusted to Trusted).

Well I'm worried about the implications of the trust model. Getting the 
owner CA trust anchor onto the devices from factory would be as 
complicated as todays ZTP. Getting ownership vouchers from the 
manufacturer is better but from practical perspective it would be best 
if there would be insecure mode where device blindly trusts whatever is 
served by bootstrapping server.

>> 2) Currently used ZTP interface information should be sent in
>> get-bootstrapping-data. Minimally ifName and vlan ID (for the scenarios
>> where ZTP DHCP client sends out DHCP discovery on all 4k vlan IDs).
>>
>> This is required for devices that might have multiple ZTP capable
>> interfaces (router with DSL and SFP interface for example) and it's not
>> known which interface might be used during installation. Without this
>> information it again becomes impossible to generate correct
>> configuration for the device.
> 
> I see.  One or more additional input parameters would be needed to
> address this.  Do you think a single parameter "interface" (the name
> of the ZTP interface used) would suffice, or perhaps a generic "opaque"
> parameter for a vendor-specific text format would be more flexible?
> Currently, if needed, vendors could define a vendor-specific parameters
> but, of course, that could affect interoperability - as not all bootstrap
> servers will handle the additional input the same way.

The first concern is ZTP in general so it'll do even if it is vendor 
specific. But such things tend to be forgotten by vendors and if the 
interface parameter is optional then we might end up in the same 
situation as today - ZTP exists on paper but unusable in real life 
unless you can directly map device serial number to intended role.

It would be tempting to make it a single parameter filled with ifName of 
relevant interface. But that would be problematic in cases where device 
sends DHCP discoveries with all possible VLAN IDs while the subinterface 
for that VLAN might not exist. So when interface parameter is filled 
with ge-0/0/0 for example but vlan 123 is in use, the parameter should 
say ge-0/0/0.123.

>> 3) zerotouch/enabled? MUST be restored to "true" when device is
>> reset to factory config using a push-button or CLI command. There
>> have been negative examples where even factory default customization
>> is wiped clean during the push-button factory reset.
> 
> True, and it is the intention of the draft to enable devices to be
> "reset" in the field, thereby returning them to their initial states,
> as described in Section 5.   Perhaps the draft isn't saying this
> clearly enough?  Please let us know which section you were looking
> at when thinking this.

I was reading 5.1 when I thought about that. I mentioned this because I 
have seen situations where devices will end up in some limbo state after 
factory reset even when they were ZTP capable from the factory. IMHO if 
someone claims they support draft-ietf-netconf-zerotouch then their 
devices MUST return to zerotouch/enabled?=true in every factory reset 
situation imaginable.

-- 
tarko