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

[Dave Thaler <[e-mail]>]

Fernando Gont <[e-mail]> wrote:
> > 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)

Yes, that's what I had in mind when writing my review.

> > 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:
[...]
> 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?

I like that approach.

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

Yes that matches what I would say.

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

The word "and" was inserted before "provides context" so -11 reads
like "A, and B and C" instead of "A, B, and C" as in your text above.

[...]
> > 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).
>
> (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.

I think it should be part of section 5 outside of the bulleted list, IF the
bulleted list is the list for implementers only.

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

That approach sounds fine to me. 

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

That depends on whether a non-default Valid Lifetime is configured.
My meta-point is that this paragraph would benefit from a discussion about
the upgrade effects, like we're now discussing here.

[...]
> > 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?

Only in the sense that it's another case.  An implementer or admin might
have configured settings assuming a particular result (e.g., robust to rogue
advertisements of 1 prefix), and after an upgrade those assumptions might
not hold.  Hence this should be pointed out in Security Considerations.

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

Yes, which still means for *atypical cases* there may be a new security consideration.
I'm not arguing against the change, only that it ought to be mentioned for the benefit
of security IT pros, deployers who might use non-default values, etc.

Hope this helps,
Dave