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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Fri, 31 Jan 2020 02:42:43 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6lo-ap-nd-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

----------------------------------------------------------------------
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!

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?)

3) Nit sec 4.4: s/it an be found/it can be found/

4) Sce 6: Use of normative language: s/The node may use a same Crypto-ID/The
node MAY use a same Crypto-ID/

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)?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 14:03:20 +0000

Hello Mirja:

Many thanks for your review : )

> 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.

> 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

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

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Fri, 31 Jan 2020 16:48:35 +0100

Hi Pascal,

This all looks good to me.

Thanks,
Mirja

> Am 31.01.2020 um 15:04 schrieb Pascal Thubert (pthubert) <[email-masked]>:
> 
> Hello Mirja:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 16:01:22 +0000

Great! 

Published as 15. You may want to recheck the changes I made based on your review here:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-15

Again, many thanks, Mirja.

Pascal

> -----Original Message-----
> From: 6lo <[email-masked]> On Behalf Of Mirja Kühlewind (IETF)
> Sent: vendredi 31 janvier 2020 16:49
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG
> <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>;
> [email-masked]
> Subject: Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-ap-nd-14:
> (with COMMENT)
> 
> Hi Pascal,
> 
> >> 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 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?)
> >
> >> 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.