Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-ap-nd-14: (with COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo