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

I’ve been agitating for a combined form. My thanks to Eliot for continuing the conversation. Below I provide some details from the current BRSKI draft to flesh out the conversation and then present an argument for my position.

On Apr 23, 2017, at 5:23 AM, Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>> wrote:

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

Given that the .well-known concept is already well defined the approach taken in the BRSKI draft (s2.3) is to include only the “manufacturer” authority:
https://example.com

From here the relying party can use the .well-known constructs to access any variety of manufacturer services which I expect to include
https://example.com/.well-known/brksi
https://example.com/.well-known/mud
etc

This minimizes the information stored within the certificate itself. A single extension indicating the “manufacturer services authority”. Building a full URL to these services is done using the .well-known method.

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"<https://mud.example.com/Frobmaster3000.json>,
     "anima", "v1", "https://masa.example.com/masa-service"<https://masa.example.com/masa-service>
   ]
}

Using a .well-known to query a host about which possible interfaces are available has precedent. For an alternative example also see,
https://tools.ietf.org/html/rfc6415
"The client obtains the host-meta document for a given host by sending

        an HTTP [RFC2616<https://tools.ietf.org/html/rfc2616>] or an HTTPS [RFC2818<https://tools.ietf.org/html/rfc2818>] GET request to the host for
        the "/.well-known/host-meta” path […]”

I see this as an optional redirection that MUD or BRSKI or future protocols might define but don’t see it as a necessary part of the manufacturing certificate extension definition. I’d think we could stop at an extension to provide the root authority to form .well-known URLs. Simpler, smaller, and just as flexible.

As a side note using this approach imposes a difficulty on MUD: the model and serial number information need to be carried elsewhere and normatively defined - MUD can no longer depend on a distinct URL for each class of device. So while I see this as an improvement for IETF as a whole it is problematic for MUD itself and I appreciate the willingness of the MUD authors to discuss it.

- max

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

_______________________________________________
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima