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

Hi Pascal,

This all looks good to me.

Thanks,
Mirja

> Am 31.01.2020 um 15:04 schrieb Pascal Thubert (pthubert) <pthubert@cisco.com>:
> 
> 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
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo