Hi Christan, Thanks for your response and apologies for the slow follow up. See inline.
Mališa On Mon, Mar 26, 2018 at 10:42 AM Christian M. Amsüss <[email protected]> wrote: > Hello Mališa, > > On Fri, Mar 23, 2018 at 10:12:16AM +0000, Mališa Vučinić wrote: > > I am tempted to say that this does not prevent us from updating the > client > > endpoint (but not the token) based on implicit knowledge at JRC. Do you > > agree? > > observation is fundamentally a hop-to-hop thing (terminated at proxies); > both the token and the observation counter are scoped to those hops, and > while a minimal proxy may get away with passing them on unmodified, I > doubt that that can be used to form a stable mechanism. > > The topic of a delegated observe has been brought up before[1] (with a > focus on nomadic devices), and was not followed up to after initial > comments. If minimal-security were to do observations that hops off a > proxy observation to a direct one, it'd need a specification similar to > that (with its holes filled) to let that observation hop off smoothly. > > (Whether the observation is FETCH or GET is immaterial here, and in this > setting it's a good approximation to say that the difference is that the > FETCH allows binary data with a mime type to be part of the request, > which would in a GET need to be squished into a query string). > > > As I understand, even richardson-6tisch-minimal-rekey needs to transport > that modelled data, so at any rate I can suggest two alternatives to a > hopping observation: > > * Don't observe through the proxy, but establish an observation after > the address has been assigned. > This incurs cost of two additional packages, but is conceptually > simple and straightforward. > Yep, so two messages to join and two additional messages for the first rekey to happen. > > * Establish a dynlink (formerly bindings) to make the JRC PUT (or PATCH) > the node. > This would take two additional messages as well (the former pledge > requesting a dynlink once it knows its final address, plus its > response). This is the less common but more versatile approach to > observation. > An advantage over plain observation is that it might be possible to > establish this link in another way than explicitly requesting it (eg. > piggy-backing an "and when you've managed, please keep me posted on /X > relative to whatever address I might have then", or by the JRC knowing > from somewhere else that such a binding is to be established) > What would be the advantage of establishing a dynlink over specifying in the minimal-security draft that once the pledge joins, it needs to expose a /j resource that the JRC may use to update the keying material? This would essentially be a static link specified in the draft. Do you see any pitfall with that? 6tisch-minimal-rekey sounds like it is a valid expectation that the > nodes will use CoMI; if that is the case and this approach is followed, > the PUT/PATCHing that would be the result of a dynlink cold probably be > set up implicitly. > I don't think we have the consensus on the use of CoMI in minimal-security. We considered it for future work, but at this point I would refrain from pulling in new specifications.. > > Best regards > Christian > > [1]: > https://mailarchive.ietf.org/arch/msg/core/-emsRTJmyyFHlrNwbJkqGfXQaYw > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
