Telechat Review of draft-ietf-6man-rfc4941bis-11
review-ietf-6man-rfc4941bis-11-iotdir-telechat-thaler-2020-10-20-00

Request Review of draft-ietf-6man-rfc4941bis
Requested rev. no specific revision (document currently at 12)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2020-10-20
Requested 2020-10-11
Requested by Éric Vyncke
Authors Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves
Draft last updated 2020-10-20
Completed reviews Secdir Last Call review of -12 by Christopher Wood
Genart Last Call review of -10 by Russ Housley (diff)
Iotdir Telechat review of -11 by Dave Thaler (diff)
Comments
This document was just scheduled for telechat so not too many days to review it but it is a -bis document, so, it should not be that long. 
As this document can have an impact on NDP, and as NDP implementation in IoT can be 'tricky', I would really appreciate to have an IoT-focused review.
Thank you in advance for a review before the telechat (20th of October would be perfect) as it will greatly assist me for my own IESG review.
Regards
-éric
Assignment Reviewer Dave Thaler 
State Completed
Review review-ietf-6man-rfc4941bis-11-iotdir-telechat-thaler-2020-10-20
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/N-POR074xGAgFPjvg_rTBfubivc
Reviewed rev. 11 (document currently at 12)
Review result Ready with Issues
Review completed: 2020-10-20

Review
review-ietf-6man-rfc4941bis-11-iotdir-telechat-thaler-2020-10-20

I reviewed the diffs between RFC 4941 and draft-ietf-6man-rfc4941bis-11
and have the following comments.

Section 1.2:
The change from RFC 4941 to add "on unencrypted packets" in
the paragraph starting "Note that an attacker, who is on path,
may be able to perform significant correlation" is incorrect.
That's because the 2nd bullet (about packet size and timing)
can still apply to encrypted packets.  Instead the "unencrypted"
clause only applies to the first bullet.  Either the change should
be reverted, or else it should be moved into the first bullet.
Similarly the text added to the end of 1.2 has the same problem.
Deployment of encryption will not prevent correlation based on
timing, and it will only prevent correlation based on packet size
if padding is used to make packets all the same size.  Simply
encrypting does not solve this.

Section 2:
Grammatically, the addition of "and" is unnecessary and arguably
poor grammar.  I would hope the RFC editor would revert it if you
didn't. Instead, Oxford comma fans will want to insert a comma
before "and makes comparisons".

Section 5:
The change from "MUST NOT" to "SHOULD NOT" is in point 7 of section
3.4 (Generating Temporary Addresses) is, I would argue, a significant
change that needs to be mentioned in section 5.

Also, significant text from RFC 4941 (sections 2.2 and 2.3) was removed
in the update and replaced with one sentence referencing RFCs 7721,
7707, and 7217.  That's fine but I wonder why it isn't mentioned
in section 5 (Significant Changes from RFC 4941).  Unlike what the
section title implies, the text of section 5 only contains the
subset of significant changes "that an implementer should be aware of".
I'd suggest also mentioning significant changes that other readers
may want to know, since implementers are not the only audience for
this doc (deployers, security analysts, application developers,
and even end users may benefit from reading this document).

Section 4:
With the change to use a separate IID per prefix, I believe the 2nd
paragraph should be augmented to point out that simply upgrading
an RFC 4941-compliant node to an implementation of this draft can
exacerbate the problem mentioned in this paragraph.

Also, "neighbour" should be "neighbor" twice in that paragraph,
for consistency with the other IPv6 RFCs.

Section 9:
RFC 4941 reused the same IID for multiple prefixes, with the rationale
explained in point 4 of section 3 of the RFCs.  With the change to use
a separate IID per prefix, additional security considerations are needed
since there is now a way to conduct new attacks that were not
present before.  Namely, by sending a large enough number of prefixes
one can force the host into multicast promiscuous mode and thereby
consume more host resources (e.g., drain battery).  For regular hosts
"large enough" might mean enough to generate 8 or 16 IIDs total
(link-local + stable + temporary total), but for some smaller devices
such as IoT devices, a much smaller number of prefixes (potentially
just one more) might be needed to result in such an effect.