[OPSAWG] dealing with multiple manufacturer services with a single certificate extension

[Eliot Lear <[e-mail]>]

Hi everyone,

Just a quick update on this document.  I am preparing for the next
version of the draft.  There is one major change contemplated that is
not yet addressed.

I received feedback from the IETF Chicago meeting regarding how best to
structure URLs in manufacturer certificates.  There are currently two
planned, one for MUD and one for ANIMA/BRSKI.  The question is whether
these should be combined. 

I had said in Chicago that I would ask various manufacturers about
whether additional complexity on the backend is worth saving the bytes
in the certificate.  There was, as you might imagine, a mixed response. 
A number of manufacturers answered, “No, and in fact we want to do our
own certificate extensions”.  Others simply answered “No, the code
requirements for ANIMA will probably make the cert extension a
relatively minimal matter”.  And some manufacturers, said, “yes, every
byte counts.”  I am proceeding in a way that accommodates the 3rd group
for now, but I seek discussion.

If we combine the URLs the way it would work is that there would be a
service endpoint along the lines of the following:

  * https://example.com/.well-known/mfg/modelname

At that point, we would need to deference, introducing some additional
complexity somewhere in the system.  We should be mindful of the
following issue:

 1. Versioning should be supported OUTSIDE of the referenced service. 
    The more that is done, the more freedom the referenced service has
    the ability to change.
 2. Versioning of services should not be done in lock step.  That is, if
    we keep the versioning information in the URL, that means that when
    the MUD version is bumped, so too would the ANIMA version.  It is
    possible to keep a registry that would indicate URL versioning and
    then map to all the different versions of whatever is referenced,
    but that seems ridiculously complex.
 3. The resolution mechanism to services should be independent of how
    the URL is gotten by the various {MUD/ANIMA/...} controllers.  And
    thus, if a MUD controller receives the URL via LLDP or DHCP, the
    same processing should occur as if it was received via a
    certificate.  This simplifies code paths, and will hence reduce risk
    of bugs.  It will also follow the principle of least astonishment.

It seems to me the simplest way to handle this sort of thing is to
create a table that MUD/ANIMA controllers simply download when they see
the URL.  It might look something like this:

{
   "mfg-services" : [ 
     "mud", "v1", "https://mud.example.com/Frobmaster3000.json",
     "anima", "v1", "https://masa.example.com/masa-service"
   ]
}

This sort of change would be required in both the ANIMA and MUD
services, but could then be used for any other manufacturer-based
service.  Is this what people want?  For MUD, this amounts to a simple
additional file retrieval.  For ANIMA, the same.  Then one simply
dereferences the table.  Most importantly, all implementations need to
be prepared to handle the case where a particular service is NOT listed
(this might seem like a big duh, but I figured I'd mention it).

Comments?

Eliot