Hello Alissa Many thanks for your review !
I committed the proposed changes as -18 so you can review them in the final version, but we can certainly adapt and do more, see https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18 . Note that the commit also adds text to answer a DISCUSS by Benjamin. Please see below for the discussion: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 4.4: > > "If it is > not present, it can be found in an abstract table that was created by > a previous message and indexed by the hash." > > Reading the document top to bottom, I was confused about what this was > referencing when I first came across it. Given that this is explained later, a > forward section reference might help. Probably a lack of clarity in the first sentence of that section. Added "as hash" in: " As opposed to the RSA Signature Option (RSAO) defined in section 5.2. of SEND [RFC3971], the NDPSO does not have a key hash field. Instead, the leftmost 128 bits of the ROVR field in the EARO are used as hash to retrieve the CIPO that contains the key material used for signature verification, left-padded if needed. " I shared that impression when rereading but moving the sentence you quote up right below the above would have cut another logical chain and created the same problem. ------------------- > Section 7: > > I think somewhere in here there should be a brief discussion about how use of > this specification could facilitate correlation attacks by providing an > identifier > that allows traffic from multiple source addresses to be tied back to the same > node via the Crypto-ID. That is, if a node intends to use multiple addresses > to > defend against the 6LR or being able to correlate traffic originating with > each > address, it should not use the mechanism specified in this document. (I'm > assuming this is a corner case for these kinds of deployments but it's worth > saying anyway. Also, if there is some other cross-address identifier that the > 6LR > always has anyway, this isn't actually a > problem.) I believe I see your point, and there's more to it: If you look at the definition of the Modifier in section 4.3, this is explicitly why we introduced it. See also the thread with Benjamin about selecting the right size for that information. " Modifier: 8-bit unsigned integer. Set to an arbitrary value by the creator of the Crypto-ID. The role of the modifier is to enable the formation of multiple Crypto-IDs from a same key pair, which reduces the traceability and thus improves the privacy of a constrained node that could not maintain many key-pairs. " Proposal is to add: " 7.7. Correlating Registrations The ROVR field in the EARO introduced in [RFC8505] extends the EUI-64 field of the ARO defined in [RFC6775]. One of the drawbacks of using an EUI-64 as ROVR is that an attacker that is aware of the registrations can correlate traffic for a same 6LN across multiple addresses. Section 3 of [RFC8505] indicates that the ROVR and the address being registered are decoupled. A 6LN may use a same ROVR for multiple registrations or a different ROVR per registration, and the IID must not derive from the ROVR. In theory different 6LNs could use a same ROVR as long as they do not attempt to register the same address. The Modifier used in the computation of the Crypto-ID enables a 6LN to build different Crypto-IDs for different addresses with a same keypair. Using that facility improves the privacy of the 6LN as the expense of storage in the 6LR, which will need to store multiple CIPOs that contain the same private key. Note that if the attacker is the 6LR, then the Modifier alone does not provide a protection, and the 6LN would need to use different keys and MAC addresses in an attempt to obfuscate its multiple ownership. " > > Section 8.3: > > Are there protocol-specific reasons why "IESG Approval" is a valid > registration > policy for this registry? Specification Required on its own seems appropriate > to > me. > See also the discussion with IANA and Benjamin. The idea is that if someone wants to add a curve or a hash function, but following the method in this draft. Do we really need an RFC or is the IANA registry the reference? The idea is that the IESG should be able to determine that the new curve provides benefits without the need for an RFC. Do we have it wrong? Again, many thanks for your time and your review! 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
