Hi Max,
On 4/24/17 5:52 PM, Max Pritikin (pritikin) wrote: > > 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 <l...@cisco.com >> <mailto:l...@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. One challenge here is that we need model information present, and you may need it as well to route to the correct BRSKI service (presuming there is more than one for manufacturer example.com). And so we would need to add at least the model back, or otherwise reflect the model in the authority section. I'm not a big fan of requiring that because it requires unnecessary interactions with DNS administration. >> 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"; >> ] >> } > 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. But more complex, requiring a query as opposed to a straight retrieval, thus requiring additional work on the back end. > > > 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. At the moment, more manufacturers are coming back to me to say that we should just leave these as separate and distinct mechanisms. I think that's the simplest approach. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
