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

From: Dave Thaler via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 13:59:56 -0700

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 18:44:13 -0300

Hello, Dave,

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

On 20/10/20 17:59, Dave Thaler via Datatracker wrote:
> 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"

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?

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

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

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?

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

> for consistency with the other IPv6 RFCs.

Will fix this (thanks!).

> consume more host resources (e.g., drain battery).  > For regular hosts

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Dave Thaler <[email-masked]>
Date: Wed, 21 Oct 2020 00:15:47 +0000

Fernando Gont <[email-masked]> 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!
>

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

> > clause only applies to the first bullet.  Either the change should be 
> > reverted, or else it should be moved into the first bullet.
> > 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.
>
[...]
> (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:
>

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

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

That approach sounds fine to me. 

> > paragraph should be augmented to point out that simply upgrading an 
> > RFC 4941-compliant node to an implementation of this draft can 

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.

[...]
> > a separate IID per prefix, additional security considerations are 
> > needed since there is now a way to conduct new attacks that were not 
> > consume more host resources (e.g., drain battery).  > For regular 
> > hosts "large enough" might mean enough to generate 8 or 16 IIDs total 

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 02:36:03 -0300

On 20/10/20 21:15, Dave Thaler wrote:
[....]
>> (Tweaking our text to elaborate what encryption may or may not mitigate would seem to introduce complexity for what's a mostly orthogonal topic)

Will do. Thanks!

> Yes that matches what I would say.

Great. Will do. Thanks!

> That approach sounds fine to me.

Okay. Unless there are any other comments on this topic from other 
folks, I'll apply the suggested change. Thanks!

> the upgrade effects, like we're now discussing here.

Fair enough. Would it be okay to address this in the Security 
Considerations Section, as opposed to Section 4?

> not hold.  Hence this should be pointed out in Security Considerations.

Fair enough.

How about adding this (please feel free to suggest tweaks if necessary):

---- cut here ----
This document introduces a change from RFC4941, in that temporary 
addresses configured for different SLAAC prefixes are required to employ 
interface identifiers that are statistically different. This will 
typically require nodes to join one solicited-node multicast group per 
each temporary address.  An attacker could forge Router Advertisement 
messages containing Prefix Information Options (PIOs) advertising 
multiple different prefixes, such that victim nodes configure temporary 
addresses for each of such prefixes, thus leading nodes to join multiple 
multicast groups. If the number of multicast groups is large enough, a 
node may need to resort setting the network interface card to 
promiscuous mode. This would cause the node to process more packets than 
strictly necessary, and might have a negative impact on battery-life, 
and on system performance in general.

A number of considerations should be made regarding this possible attack 
vector:

  o Nodes that employ stable addresses [RFC7217] will usually configure
    one stable address for each SLAAC prefix, where addresses for
    different prefixes employ statistically-different interface
    identifiers. Thus, an attacker could essentially trigger the same
    issue without relying on the configuration of temporary addresses. If
    anything, the mechanism specified in this document would increase the
    number of multicast groups that must be joined on a per-SLAAC-prefix
    basis, but need not increase the overall number of multicast groups a
    node must join.

  o When compared to RFC4941, this document reduces the default Valid
    Lifetime of temporary addresses (TEMP_VALID_LIFETIME from Section
    3.8) to 2 days, Thus, nodes implementing this document and employing
    the default parameters from Section 3.8 will employ at most two
    concurrent temporary addresses per SLAAC prefix, resulting in a major
    reduction on the number of concurrent temporary addresses per SLAAC
    prefix. Thus, in typical network scenarios where two or three SLAAC
    network prefixes are employed, implementations of this document will
    require hosts to join fewer multicast groups, than RFC4941
    implementations.

Implementations concerned with the maximum number of multicast groups 
that would be required to join as a result of configured addresses, or 
the overall number of configured addresses, should consider enforcing 
implementation-specific limits on e.g. the maximum number of configured 
addresses, the maximum number of SLAAC prefixes that are employed for 
auto-configuration, the maximum number of configured addresses, and/or 
the maximum ratio for TEMP_VALID_LIFETIME/TEMP_PREFERRED_LIFETIME (that 
ultimately controls the number of concurrent temporary addresses per 
SLAAC prefix). Many of these configuration limits are readily available 
in SLAAC and RFC4941 implementations. We note that these configurable 
limits are meant to prevent pathological behaviors (as opposed to simply 
limiting the usage of IPv6 addresses), since IPv6 implementations are 
expected to leverage the usage of multiple addresses [RFC7934].

We note that many other attack vectors exist against SLAAC host 
implementations, most of which have a much higher impact. As a result, 
when SLAAC-based attacks are a concern, network administrators should 
consider deploying mitigations such as RA-guard [RFC6105] [RFC7113] and 
DHCPv6-Shield [RFC7610].
---- cut here ----

To be honest, I'm a bit skeptical about whether the issue we have 
discussed warrants this amount of text --- although one might argue that 
the last two paragraphs discuss general considerations and mitigations.

Thoughts?

Thanks!

Cheers,

---

From: Dave Thaler <[email-masked]>
Date: Wed, 21 Oct 2020 21:59:14 +0000

> Considerations Section, as opposed to Section 4?

My opinion is that this point is different from security considerations
(which is a separate point), it's more "upgrade considerations" since the
point here is that simply upgrading might cause a battery drain if you
have things configured in a particular way.  No attacker is involved.
Security considerations are for things that are about attacks or mitigations.

> node may need to resort setting the network interface card to

If you use this text then 
s/resort setting/resort to setting/
 
>    basis, but need not increase the overall number of multicast groups a

s/need not/may nor may not, depending on the configuration,/

>    the default parameters from Section 3.8 will employ at most two

s/will emply/will by default employ/

But it also occurs to me that an "upgrade considerations" text in
section 4 or elsewhere might also need to mention that if applications
were built assuming that connections stay up for a week, such
applications might break on an upgrade, unless the valid lifetime
is explicitly configured to be a non-default value.  (This is not
a security consideration, it's an app compat consideration.)

> the last two paragraphs discuss general considerations and mitigations.

I agree it's more text than I expected and I'd be happier with a much smaller
amount of text if a briefer version were written.

Dave

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 20:35:41 -0300

> Security considerations are for things that are about attacks or mitigations.

Oops! Looks like I misunderstood you. -- I thought you were portraying 
this issue as a security issue (rather than an upgrade issue). So let me 
proposed the following text instead:

---- cut here ----
RFC4941 employed a randomized temporary Interface Identifier for 
generating temporary addresses, such that a set of temporary addresses 
configured at a given time (for multiple SLAAC prefixes) would employ 
the same Interface Identifier.  Sharing the same IID among multiple 
address allowed host to join only one solicited-node multicast group 
pero temporary address set.

This revision requires that temporary addresses configured for different 
SLAAC prefixes employ interface identifiers that are statistically 
different from each other. This means that when a network employs 
multiple prefixes, each temporary address of the set will result in a 
different solicited-node multicast address, and thus the number of 
multicast groups that a host should join becomes a function of the 
number of SLAAC prefixes employed for generating temporary addresses).

Thus, a network that employs multiple prefixes may require hosts to join 
more multicast groups than in the RFC4941 case. If the number of 
multicast groups is large enough, a node may need to resort to setting 
the network interface card to promiscuous mode. This would cause the 
node to process more packets than strictly necessary, and might have a 
negative impact on battery-life, and on system performance in general.

We note that since this document reduces the default TEMP_VALID_LIFETIME 
from 7 days (in [RFC4941]) to 2 days, the number of concurrent temporary 
addresses per SLAAC prefix will be smaller than for RFC4941 
implementations, and thus the number of multicast groups for a network 
that employs, say, between 1 and threee prefixes will be similar than 
for RFC4941 implementations.

Implementations concerned with the maximum number of multicast groups 
that would be required to join as a result of configured addresses, or 
the overall number of configured addresses, should consider enforcing 
implementation-specific limits on e.g. the maximum number of configured 
addresses, the maximum number of SLAAC prefixes that are employed for 
auto-configuration, and/or the maximum ratio for 
TEMP_VALID_LIFETIME/TEMP_PREFERRED_LIFETIME (that ultimately controls 
the number of concurrent temporary addresses per SLAAC prefix). Many of 
these configuration limits are readily available in SLAAC and RFC4941 
implementations. We note that these configurable limits are meant to 
prevent pathological behaviors (as opposed to simply limiting the usage 
of IPv6 addresses), since IPv6 implementations are expected to leverage 
the usage of multiple addresses [RFC7934].
---- cut here ----

?

BTW, should this be incorporated into Section 4, or elsewhere?

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 20:38:15 -0300

[....]
> a security consideration, it's an app compat consideration.)

May/should applications really rely on a host configuration parameter 
they don't really control?

i.e., if they may assume a specific value, and would otherwise break, 
then there's not much of a real option in configuring the aforementioned 
parameters.

Thanks,