Re: [6lo] Alissa Cooper's No Objection on draft-ietf-6lo-ap-nd-17: (with COMMENT)

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
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo