Hi Pascal, This all looks good to me.
Thanks, Mirja > Am 31.01.2020 um 15:04 schrieb Pascal Thubert (pthubert) <[email protected]>: > > Hello Mirja: > > Many thanks for your review : ) > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> A couple of small comments: >> >> 1) Sec 2.2: If actually all terms from all the RFC listed in section 2.2 are >> used, >> all the reference would need to be normative. Maybe double-check this! > > I went through that with Eric's review and some refs moved back and forth > before I finally published 14. > > I found that from that list the generic LLN discussion and the legacy IPv6 ND > are not necessary to understand and implement this specification. The needed > normative references are the 6LoWPAN ND and RFC 3971, and crypto references. > I think we are OK now. > > >> 2) Sec 3: I would have expected that section 3 says something about backward >> compatibility (what if not all nodes in a network are updated?) and gives a >> strong recommend to use this scheme (or even obsolete the old one?) > > Right. What about adding: > " > Section 5.3 of [RFC8505] introduces the ROVR as a generic object that > is designed for backward compatibility with the capability to > introduce new computation methods in the future. Section 7.3 > discusses collisions when heterogeneous methods to compute the ROVR > field coexist inside a same network. > > [RFC8505] was designed in preparation for this specification, which > is the RECOMMENDED method for building a ROVR field. > > " > >> 3) Nit sec 4.4: s/it an be found/it can be found/ > > Fixed > >> 4) Sce 6: Use of normative language: s/The node may use a same Crypto- >> ID/The node MAY use a same Crypto-ID/ > > done > > >> 5) Security Consideration Section: Is there a new risk/possible attack >> because >> computational complexity of the proposed scheme is higher than the one in >> RFC8505? Could that be used as an attack against a central node? Would it be >> necessary to rate limit requests somehow? Or is there already a rate limit >> (that should be mentioned here)? > > Actually the challenge is distributed at the edge of the network. That's a > limit if the scheme that a compromised 6LR may admit an attacker. > What about adding a section as follows in the security section: > " > > 7.6. Compromised 6LR > > This specification distributes the challenge and its validation at > the edge of the network, between the 6LN and its 6LR. The central > 6LBR is offloaded, which avoids DOS attacks targeted at that central > entity. This also saves back and forth exchanges across a > potentially large and constrained network. > > The downside is that the 6LBR needs to trust the 6LR for performing > the checking adequately, and the communication between the 6LR and > the 6LBR must be protected to avoid tempering with the result of the > test. > > If a 6LR is compromised, it may pretend that it owns any address and > defeat the protection. It may also admit any rogue and let it take > ownership of any address in the network, provided that the 6LR knows > the ROVR field used by the real owner of the address. > " > > Again, many thanks Mirja. Please let me know if the above looks OK and I'll > publish. > > All the best, > > Pascal > >> >> >> _______________________________________________ >> 6lo mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
