Re: Iotdir telechat review of draft-ietf-6man-rfc4941bis-11

[Fernando Gont <[e-mail]>]

Hello, Dave,

Thanks a lot for your feedback! In-line...

On 20/10/20 17:59, Dave Thaler via Datatracker wrote:
> Reviewer: Dave Thaler
> Review result: Ready with Issues
> 
> 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. 

Good grief!

How about moving "on unencrypted packets" to the first bullet, as:

    o  The payload contents of unencrypted packets on the wire

?

(but see below)



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

How reverting this text as:

OLD:
---- cut here ----
    Note that an attacker, who is on path, may be able to perform
    significant correlation on unencrypted packets based on

    o  The payload contents of the packets on the wire

    o  The characteristics of the packets such as packet size and timing

    Use of temporary addresses will not prevent such payload-based
    correlation, which can only be addressed by widespread deployment of
    encryption as discussed in [RFC7624].  Nor will it prevent an on-link
    observer (e.g. the node's default router) to track all the node's
    addresses.
---- cut here ----

NEW:
---- cut here ----
    Note that an attacker, who is on path, may be able to perform
    significant correlation based on

    o  The payload contents of the packets on the wire

    o  The characteristics of the packets such as packet size and timing

    Use of temporary addresses will not prevent such payload-based
    correlation.
---- cut here ----


(Tweaking our text to elaborate what encryption may or may not mitigate 
would seem to introduce complexity for what's a mostly orthogonal topic)

Thoughts?



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

This might have been my fault (English as second-language here). This is 
how I would have written the text:

    This section discusses the problem in more detail, provides context
    for evaluating the significance of the concerns in specific
    environments, and makes comparisons with existing practices.

(not sure what you meant about the "addition of 'and'", though).



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

Will do.



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

(me thinking out loud) Probably because it's not a change to the actual 
protocol (i.e., those are not necessarily changes "an implementer of RFC 
4941 should be aware of"). Please do let us know if you think this 
should be added to the bulleted list in Section 5, though.



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

Ok.

I guess one might apply this:

OLD:

    This section summarizes the changes in this document relative to RFC
    4941 that an implementer of RFC 4941 should be aware of.


NEW:

    This section summarizes the substantive changes in this document
    relative to RFC 4941.


Then, regarding the item you've raised above, one might add a bullet 
like this one:

   o The discussion about the security and privacy implications of
     different address generation mechanisms has been replaced with
     references to recent work in this area ([RFC7707], [RFC7721], and
     [RFC7217]).

Thoughts?



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

For all practical scenarios, this will actually be the other way around: 
Since this document reduces the Valid Lifetime, then, for the case where 
the local network employs say, one GUA prefix and one ULA prefix, nodes 
would end up using 4 concurrent temporary addresses, as opposed to the 
14 temporary addresses they might end up employing with RFC4941.




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

Will fix this (thanks!).



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

Is this any different from RFC4941 or even with SLAAC itself?

Namely:

* As noted above, for all typical cases nodes will end up employing 
fewer temporary addresses than with RFC4941.

* An attacker can always advertise multiple PIOs, or both SLAAC PIOs 
plus RAs with M set (such that nodes configure addresses with both SLAAC 
and DHCPv6). Ultimately, it's up to the node to enforce a limit on the 
maximum number of configured addresses.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492