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

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

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 <[e-mail]> On Behalf Of Mirja Kühlewind (IETF)
> Sent: vendredi 31 janvier 2020 16:49
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]; The IESG
> <[e-mail]>; Shwetha Bhandari (shwethab) <[e-mail]>;
> [e-mail]
> Subject: 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)
> <[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
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo