On Mon, Nov 05, 2018 at 09:16:54AM +0700, Michael Richardson wrote: > > Benjamin Kaduk <ka...@mit.edu> wrote: > >> John Mattsson <john.matts...@ericsson.com> wrote: > of negotiation is > >> still needed. The current plan for the next version > is to introduce > >> cipher suites and to let the cipher suite with value 0 > indicate that > >> algorithms have been negotiated out-of-band. > >> > >> I agree with the idea that some common default should be very easy to > >> refer to, but I don't like the idea that the gateway has to remember > >> what the out-of-band "default" is on a per-device basis. I would say > >> that we need at least 0/1, so that we can say that it's the current vs > >> the "new" default. > >> > >> If you consider the case where the sensor is on very low bandwidth > >> connection (I would say LoRaWAN, but I am not well qualified in that > >> space). The sensor gets visited every two or three years by a > >> technician (if only to make sure that the sensor is still where it is > >> supposed to be). While there new firmware updates are applied, and as > >> a result the algorithm defaults are updated. During the cycle, some > >> devices are updated and some are still old. > > > Are you proposing that the management of the 0/1-to-algorithm mapping > > be managed on a per-deployment basis or by the IETF? > > I think that the existing proposal was that 0 means "negotiated out-of-band", > which implies that it's a per-deployment basis. > > I'm proposing that instead of having 0 mean "some local default", > I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other > local default 1", which lets the default be updated without a flag day.
That feels like a potentially awkward provisioning problem. I guess the idea is that any given node is only going to do 1 or 0 and not both? Maybe that helps. Thanks, Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
