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