Re: [Netconf] WG LC for zerotouch

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> Hi Martin,
> 
> Again, trimming down to just open threads.
> 
> >> >> > o  Section 7.2
> >> >> >
> >> >> >  Adding custom query parameters like this breaks the normal YANG
> >> >> >  contract.  If I understand this correctly, the instance data tree
> >> >> >  presented to the client is supposed to change based on these query
> >> >> >  parameters.
> >> >> 
> >> >> Correct.  The idea is that the response could vary based on the input
> >> >> query params.  Of course, in case there was any doubt, the response 
> >> >> would always conform to same YANG schema.
> >> >
> >> >See below.
> >> >
> >> >> >  If you really need to have that functionality, it would better to
> >> >> >  model the device-specific data as an action; input would be the
> >> >> >  os-name, os-version etc, and output would be the
> >> >> >  zerotouch-information and voucher etc.
> >> >> 
> >> >> I thought of this as well, but didn't do anything about it as my 
> >> >> last message to the list said that we'd add "query parameters"
> >> >> and I wanted to follow through on that statement.
> >> >> 
> >> >> But what is the issue?  Is it primarily that using query params 
> >> >> on GET should be limited to returning different representations
> >> >> of a resource, and this use seems to be returning different 
> >> >> resources altogether?
> >> >
> >> > Yes, this is my concern.  A normal RESTCONF / YANG server has *one*
> >> > single instance of the operational state, and it just provides an API
> >> > to this data.  It can be filtered and pruned based on access rights,
> >> > but not modified from the outside based on query parameters.
> >> 
> >> I agree, it seems more proper.  Okay, let's make this change.  No
> >> objections from the WG, right?  As a heads-up for those following
> >> along, this change doesn't affect the essence of the solution, but
> >> the diff will appear somewhat big...
> >> 
> >> 
> >> >> FWIW, if we were to do this, we might also consider moving the 
> >> >> 'serial-number' field from the URL to an input field
> >> >
> >> > Hmm, did you mean 'unique-id'?
> >> 
> >> Yes. But what about the idea, moving 'unique-id' from the URL path
> >> to an input param?  Or, even more dramatically, we could remove 
> >> 'unique-id' altogether, relying instead on the RESTCONF username
> >> extracted from the DevID certificate?
> >
> > See below.
> >
> >> If relying on the extracted username, note that none of the 
> >> 'cert-to-name' identities defined in RFC 7407, which is also
> >> used in draft-ietf-netconf-restconf-client-server, would work.
> >> The 'common-name' identity is closest, but what is really needed
> >> is a combination of a 'serialNumber' attribute and an optional
> >> 'hardwareModuleName' attribute (not all DevID certs define it).
> >
> > Ok.  I've tried to find a spec for the DevID, but couldn't find a
> > public version.
> 
> Here's the part you're looking for:
> 
> 
>   7.2.8 subject
>   The DevID subject field shall uniquely identify the device 
>   associated with the particular DevID credential within the
>   issuer’s domain of significance. The formatting of this field
>   shall contain a unique X.500 Distinguished Name (DN). This
>   may include the unique device serial number assigned by the
>   manufacturer or any other suitable unique DN value that the
>   issuer prefers. In the case of a third-party CA or a standards
>   certification agency, this can contain the manufacturer’s
>   identity information.  The subject field’s DN encoding should
>   include the “serialNumber” attribute with the device’s unique
>   serial number.
> 
>   7.2.9 subjectAltName
>   The non-critical DevID subjectAltName extension may supplement
>   the subject field identity information as specified in RFC 5280
>   by containing a hardwareModuleName as specified in RFC 4108.
> 
> 
> 
> >> I suppose that this is an issue for the afore-mentioned restconf
> >> client/server draft more so than this one though.  Still, since
> >> we're talking about it, assuming we did this, would that draft
> >> add said identities, or would a 7407bis be better?
> >
> > I think that such an identitiy could be defined in this draft.  Isn't
> > such an identity quite specific to this use case?
> 
> okay, but in which module? - it just needs to be a module imported
> wherever ietf-x509-cert-to-name is used (ietf-netconf-server and 
> ietf-restconf-server) but not any module defined in this draft.
> So maybe yet another module is needed in this draft: ietf-more-
> x509-cert-to-name-identities? - naming suggestions welcomed! ;)

Hmm.  Maybe a new document with just a new version of
ietf-x509-cert-to-name is most appropriate?  (I.e., not a complete
7407bis)  Or even update ietf-x509-cert-to-name in this document...

> > >> >  I suggest you shorten the lines of the examples even more, so that
> > >> >  the examples are properly indented in the draft (they are currently
> > >> >  outdented)
> > >> 
> > >> It's hard to make the lines much shorter with the URN being so long.
> > >> Options are 1) don't indent just the xmlns line or 2) move from two-
> > >> space indent to single-space indent.  Do you have a preference?
> > >
> > > In the second example you use (1).  You can also use "\", which you
> > > are also already using.
> > 
> > So I do, albeit only in the HTTP-header parts, not the HTTP-body parts.
> > 
> > FWIW, my build-script inserts source files in situ as directed by
> > processing instructions. I can modify the build-script to do the 
> > auto-'\' insertion logic on some column-boundary, but it may need
> > a complimentary update on the extraction tools.  Do we need some 
> > sort of standard around this?
> > 
> > I'm aware that here you're only talking about examples, which 
> > currently are not extracted via tools, but the same auto-'\' 
> > insertion logic could also help with the YANG modules, as they
> > could become unwieldy too...though I suppose liberal use of 
> > groupings could always be employed to keep line-lengths in
> > check.  Okay, but still, a YANG Doctors discussion at IETF 99
> > suggested introducing the ability to auto-extract and validate
> > examples in drafts too, to automate as much of the YD review
> > process as possible, so still I think there may be a need for
> > a '\' standard of some sort here.  Thoughts?
> 
> This is still open.

I don't have a good solution to this... It is often possible to format
the XML so that it is legal, but then it might look odd, e.g.:

                <tag
                >long line here......</tag>

> >> >> > o  Section 9
> >> >> >
> >> >> >  Should you also mention that /device list should be protected by
> >> >> >  nacm rules?
> >> >> 
> >> >> Yes, indeed, I left out the standard security template for the bootstrap
> >> >> server YANG module.  Will add.
> >> >> 
> >> >> 
> >> >> >  If the RESTCONF user name is the device's unique-id, then a single
> >> >> >  NACM rule can be used:
> >> >> >
> >> >> >       <rule>
> >> >> >         <name>allow-device</name>
> >> >> >         <path xmlns:ztbs="urn:ietf:params:xml:ns:yang:\ietf-zerotouch-bootstrap-server">
> >> >> >           /ztbs:device[ztbs:unique-id=$USER]
> >> >> >         </path>
> >> >> >         <access-operations>read</access-operations>
> >> >> >         <action>permit</action>
> >> >> >       </rule>
> >> >> 
> >> >> Yes, but would you expect this to appear in the draft?  Typically,
> >> >> the specific NACM rule syntax is left as an exercise to the reader...
> >> >
> >> > In order to do this, the "username" must be the same as the
> >> > "unique-id".  This requires the client cert to be constructed
> >> > properly.
> >> 
> >> Agreed.  In this case, the client cert is a DevID cert, and  802.1AR 
> >> governs its construction.  Not too many options there.  Of course, 
> >> the mapping of said cert to username is being discussed above wrt the
> >> cert-to-name mapping logic... 
> >> 
> >> 
> >> >> Since the NACM rule is not obvious, and due to the cert implications,
> >> >> I think it would be very helpful with an appendix that describes how
> >> >> this can be set up.
> >> 
> >> I think that this will depend on if we go with an action or a top-level 
> >> RPC. If an action, then NACM may have a place and an example may help.
> >> But, if using a top-level RPC, then it seems that the server has no 
> >> option but to auth the DevID cert and provide a RESTCONF username-specific
> >> response - NACM can't constrain it any further, right?
> > 
> > Correct.
> 
> Well, maybe not entirely correct.  It looks like NACM rules can 
> constrain RPCs using the "rpc-name" rule type.

Yes, but NACM cannot control access based on input parameters, which
is what would be needed in this case.

> But, in this case,
> an NACM group containing a list of users that matched exactly each 
> device would have to be maintained, which isn't quite a nice as
> using the $USER variable.
> 
> 
> 
> >>> (note: this seems
> >>> more secure to me - I like it)
> >>
> >> Hmm, I think it is less clear.  With an explicit list and actions, you
> >> can use NACM to do the access control.  With top-level RPCs, the
> >> implementation of the RPC has to do the access control.
> 
> Right, but it wouldn't be "access control" so much as something akin
> to a 404.  When establishing the RC connection, the server must first
> auth the client's cert (at the TLS-level) that, in the case of an 
> IDevID cert, most like maps to checking to see if it has a chain of
> trust to the vendor's CA cert.  Then cert-maps is used to extract a
> username; in the IDevID case, it is most likely some combo of the 
> serialNumber and hardwareModuleName attributes.  This username is 
> fed into the RPC handling logic which will do some internal lookup
> and either find a match (and return data) or not (and return an error).
> No need for NACM in this flow is there?
> 
>  
> > Also, a list of devices is more transparent - I mean, this list must
> > somehow exist anyway, but with top-level RPCs it will be hidden.
> 
> A list of devices needs to exist in the database, and the NBI, but
> not the SBI, right?

The bootstrap server has one RC interface.  If it used for NB or SB
access doesn't really matter.  I was thinking that the list of devices
might be useful also for a "NB" client.

> > Maybe implementations want to add additional objects to this list, for
> > monitoring or something.
> 
> Unsure.  The point of the SBI is that the device only receives a 
> device-specific response, no other objects are ever included, right?

Sure; again I was thinking of objects for other clients.

> But maybe you mean some implementations will want to modify the format
> of the device-specific response, which I agree is possible, but that
> doesn't impact if we use an RPC versus an action.  Do you agree?

Right.

> >> >> > o  Other comment
> >> >> >
> >> >> >  Is it assumed that there will be a vendor-specific YANG module to
> >> >> >  enable the zero-touch process?  Did you consider an
> >> >> >  ietf-zerotouch-device module for this purpose?  Such a configuration
> >> >> >  must be carefully designed to allow for a "merge" configuration file
> >> >> >  to actually disable the zero touch process.
> >> >> 
> >> >> It is assumed to be vendor-specific currently.  I have not thought to
> >> >> define a ietf-zerotouch-device module as of yet that, presumably, would
> >> >> contain a boolean or an enum (but not a p-container) for enabling the
> >> >> service.  Do you think we should add such a module to the draft, or just
> >> >> put a note somewhere about it?
> >> >
> >> > I don't have a strong opinion, but if there's not a standard module
> >> > for this, the text should mention that it is assumed that vendors
> >> > define this themselves.   Hmm, I think I would prefer a standard
> >> > module; it would make the solution more complete.
> >> 
> >> We can add a module, but maybe it should be called something like
> >> ietf-zerotouch-bootstrap-client, to mirror the ietf-zerotouch-
> >> bootstrap-server module? - though this may be a mismatch as the
> >> former regards a southbound protocol and the latter regards a
> >> configuration model...
> >> 
> >> Maybe we can discuss what would be in this model.  I'm not sure if
> >> I'm oversimplifying it, but I think the module might be just a single
> >> config true leaf called something like "enabled".   There might also
> >> be some config false leafs for the stuff mentioned in section 5.1, 
> >> though it doing so is not so important since the bootstrapping only
> >> occurs once (not ongoing management).  So a module would primarily
> >> be for the "enabled" leaf.  Anything else?  Still think it's worth it?
> >
> > I'm not sure.  It does seem odd to write that we expect vendors to
> > provide this single leaf in a proprietary module, but maybe it is ok.
> 
> Okay, I'll add a ietf-zerotouch-device module.  It doesn't hurt.  
> Vendors can use it or not.  If nothing else, at least they can
> reference it for their native model.


/martin