Subject: Re: [6lo] RESEND: Reveiw of draft-ietf-6lo-privacy-considerations-00

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Jul 2016 01:22:11 +0000

I'm working on updating this now...

Kerry Lynn wrote:
> To begin finalizing the Security Considerations section of draft-ietf-6lo-
> 6lobac, i thought it would be useful to re-read and offer my review of
> draft-ietf-6lo-privacy-considerations-00.

Thanks for the feedback!

> First, some general comments:
>
> - I find the document clear and understandable, as per Dave's usual.
>
> - As this document pertains to constrained devices, I think some of the
> concerns expressed in other fora (e.g. leaking link-local address in
> email headers) don't apply here.

Yes they do.  Just because a device is resource constrained doesn't mean it can't
leak link-local addresses.   In fact we have plenty of evidence that leaking
link-local addresses can easily happen by accident (or programmer neglect),
in any number of Internet protocols (DNS, SIP, SMTP, etc.)

> - I think it would be helpful to clearly divide the document according to
> threats posed by off-link vs on-link adversaries.  In the off-link case,
> we are dealing only with routable addresses and information that is
> at L3 or higher.  This class of threats applies to all hosts, including 6lo.
> Using a random 60+ bit IID (per prefix?) will mitigate all threats
> discussed in draft-ietf-6man-ipv6-address-generation-privacy except
> correlation of activity over time.

Ok, will see what I can do.

> In the on-link case, are we only concerned with threats that apply to
> (wireless) data links that are susceptible to eavesdropping, or must we
> also be concerned with intruders in the wiring closet?

If the link is a multi-access link, and one of the devices can be
compromised, then it can potentially be used to eavesdrop on communication
between two other entities on the link.  So it's not wired vs wireless
so much as point-to-point vs multi-access.

> In any event, this
> class of threats would seem to exclude address scanning (which is trivial
> if an attacker has access to the local link traffic).

Depends on the link-layer protocol.  Some link layers (e.g., ones
that don't support multicast/broadcast) don't use ND and so address scanning
may still be an issue.

> - If address scanning is eliminated as a concern (as in cases where it
> cannot be prevented), then arguments about "enough entropy" do not
> apply and locally assigned short addresses have their rightful place in
> forming link-local IIDs.  The side effect of this is to enable maximally
> efficient RFC 6282 compression for link-local traffic.

I think you're still assuming that link-local addresses can never leak
via higher layer protocols, whereas we know they can.  So link-local addresses
are still an issue for the off-link case.  Even though an attacker can't
use them to communicate with the constrained device, they can still result
in privacy vulnerabilities.

> - Concerns about correlation over time may not apply to certain classes
> of devices (fixed servers) or applications (e.g. building automation, where
> associating link-layer address with location is a feature, not a bug).  In
> some cases, it may simply be impractical to change link-layer address
> on a frequent basis (e.g. it is common in the case of MS/TP nodes to set
> the L2 address via DIP switches).

Right, in cases like fixed services that might even be resolvable via
DNS or some other mechanism, public addresses are used and privacy of such
addresses is not an issue.  However, the point is that that IETF should not
design protocols that can ONLY support such cases.  (The draft is a bit
softer than saying that though, it just says that your Privacy Considerations
section needs to have a discussion of the issues, and then the IETF community
and the IESG can decide whether there is IETF consensus on it.)

> - It has been suggested that ND might be eliminated in some cases to
> further increase bandwidth efficiency.  (For example, in cases where a
> locally-assigned short identifier has been assigned at L2 and is then
> used to form an IID, ND is redundant.)

Well there's multiple parts of "ND".   The NUD part is still relevant in
all cases.  The Address Resolution part can be eliminated in some cases
(and indeed it's up to each link-layer protocol to say how Address Resolution
is done, which defaults to normal ND if you say nothing).

> AFAIK, there hasn't been any
> discussion about how to tell the difference between L2-derived and
> "random" IIDs.  We might identify L2-derived IIDs as those containing
> the 0xFFFE pattern in the middle, or not having the 0xFFFE pattern but
> having the U/L bit = 0 in the IID.  This would exclude these patterns from
> valid privacy IIDs and result in a maximum entropy of ~63 bits.

One cannot positively tell the difference simply by looking at an address.
One needs additional information to say for sure, because ultimately it's
up to each link (or maybe even finer granularity).  But for things like
address-to-string conversion ("pretty-printing") purposes, some implementations
(like Windows) do have a random generation algorithm that avoids colliding
with the patterns you mention, and do result in a max entropy of ~63 bits.
So far I don't see any reason the draft needs to discuss this point though.

> Now on to specifics:
>
> - In section 2, I think the analysis pertains to the lifetime of a given
> link so the wording "average lifetime of a device" should instead be
> "average lifetime of a link".

Right, will fix (it's correct in the equation at top of page 4 but then
the text below it wasn't consistent with it).

> It is worth noting that CoAP servers do not have a "stealth mode".
> According to [RFC7252] a CoAP server MUST respond to an empty
> Confirmable message with a Reset message.

It's not worth noting because the same could be said for TCP or HTTP
or ICMP.  The "stealth mode" is a property of a host firewall in front of
it but on the same device.  Section 5 of RFC 7288 (which the draft
references) already contains a discussion of this point, and just uses
TCP and ICMP as examples, and that text equally applies to COAP.

> - In section 3, MS/TP has 7 or 64 bits (since L2 addresses must be in
> the range 0 - 127).

Thanks, will fix.

> - Section 3.1 seems to alternately switch between discussing link-layer
> addresses and IIDs formed from those addresses.  Perhaps consistent
> use of "link identifier" and "interface identifier" would help disambiguate
> the meaning.

Ok, will see what I can do.

> EUI-64 and EUI-48 are well-defined terms (trademarked in fact, and
> this should be noted in the document).

Why should it be noted?  Can you point me to a 6man RFC (since many
6man RFCs mention EUI-64 and EUI-48) that notes that the term is
trademarked?  Is there an RFC style guide directive on such matters?

> An EUI-64 may have 40, 36, or
> 28 bits of entropy, while an EUI-48 may have 24, 20, or 12 bits, none
> of which meet the standard of "at least 46 bits".

When the OUI is unknown, the lack of such knowledge provides a few
more bits of entropy since the attacker has to at least try any well-known
OUI's and do a search within each one.  For example, if there's 64+
possible OUI's in use, that's around 6 more bits of entropy.   An off-link
attacker cannot, without additional information, know what the link type is
and so has to try OUIs without being able to narrow it down to OUI's for that
link type.

> I'm not sure it's
> accurate to use "randomized IEEE identifiers", unless this refers to
> locally-assigned MAC addresses with the U/L bit = 1, in which case we
> might want to reference an appropriate IEEE 802 or ISO standard.

Random MAC addresses was the intent, but "MAC" as a term only applies
to specific link types.  Maybe "randomized link-layer addresses" is a
better term, so I'll use that.

> - In Section 4, first bullet, it should be enough to indicate that privacy
> IIDs are RECOMMENDED for routable addresses.  (Is there a case
> where a privacy IID is less than ~63 bits of entropy?)

Such a recommendation may be too strong for some cases (it would indeed
be sufficient, but not necessary).  For example, if the link lifetime is
usually <1 second, then privacy IIDs might be overkill.  The point of
the first bullet is to say that an IP-over-Foo doc should contain such
a discussion.  However, perhaps your point is that it could say that
using privacy addresses is one easy way to meet the requirement.

That is, I don't believe there is 6lo WG consensus for stating that
privacy IIDs are RECOMMENDED for routable addresses.

> This section
> should also discuss options for providing privacy IIDs via DHCPv6
> (M=1 in RA).

I have no problem adding such a reference.  The point is to say what
privacy considerations need to be addressed in a doc, rather than
details of *how* to address them, in order to leave maximum freedom.
But providing examples as informative references as you suggest is
a good thing.

> Second bullet - as I've indicated above, there's no such thing as a
> "random" EUI-64 or EUI-48.  We can probably use "randomized MAC
> addresses".  I need to go back and re-read [RFC7136] to see if it makes
> sense to specify U/L bit in this context.

Agreed, will use "randomized link-layer addresses".

> Third bullet - this advice should not apply to link-local IIDs.  Any
> attacker wishing to find "hits" just needs to fire up a sniffer.

Disagree as noted above.  It applies due to off-link leakage.
(And the IP-over-Foo layer should not make assumptions about
what upper-layer protocols do.)  The risk might be smaller, and hence
it might apply "less", but it still applies.

> Fourth bullet - this advice should not apply to link-local IIDs for devices
> or applications where correlation of activities over time is not a concern.

Same answer.   The risk might be smaller and hence it might apply "less",
but it still applies.

Again the main point of this draft is not to say what one MUST or MUST NOT do
(or rather *how* one MUST or MUST NOT solve some privacy issue),
but rather what issues need to be addressed in a doc, and some recommendations
("shoulds") on good ways to address them.   So the fact that there's still a risk
means there's still a need for text to address them or convincingly (to the IETF
community and to the IESG) explain why some issue doesn't apply to a particular
IP-over-foo mechanism.

Thanks again for the review,
Dave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Jul 2016 01:22:07 +0000

Ok, I just posted an update in which I tried to take Kerry's feedback into account.

Some notes below about what I did, but see the diffs for details.

> From: Dave Thaler
> Sent: Tuesday, July 5, 2016 6:22 PM
> To: [email-masked]; Kerry Lynn <[email-masked]>
> Subject: RE: [6lo] RESEND: Reveiw of draft-ietf-6lo-privacy-considerations-00
> 
> I'm working on updating this now.
> 
> Kerry Lynn wrote:
> > To begin finalizing the Security Considerations section of
> > draft-ietf-6lo- 6lobac, i thought it would be useful to re-read and
> > offer my review of draft-ietf-6lo-privacy-considerations-00.
> 
> Thanks for the feedback!
> 
> > - As this document pertains to constrained devices, I think some of
> > the concerns expressed in other fora (e.g. leaking link-local address
> > in email headers) don't apply here.
> 
> Yes they do.  Just because a device is resource constrained doesn't mean it
> can't leak link-local addresses.   In fact we have plenty of evidence that
> leaking link-local addresses can easily happen by accident (or programmer
> neglect), in any number of Internet protocols (DNS, SIP, SMTP, etc.)

I did make changes in a number of places, especially any discussion around
address scans, to make the discussion specific to routable addresses.
I put in some text to state my points as well, but the primary focus of
address scan text (and thus the larger number of entropy bits) is for
routable addresses, which I hope is clear in the text now.

> > - I think it would be helpful to clearly divide the document according
> > to threats posed by off-link vs on-link adversaries.  In the off-link
> > case, we are dealing only with routable addresses and information that
> > is at L3 or higher.  This class of threats applies to all hosts, including 6lo.

I made textual changes, but not organizational changes (table of contents
remains the same) since some points do not clearly delineate that way.
So hopefully it's clear enough in each paragraph now.

> > (wireless) data links that are susceptible to eavesdropping, or must
> > we also be concerned with intruders in the wiring closet?
> 
> If the link is a multi-access link, and one of the devices can be compromised,
> then it can potentially be used to eavesdrop on communication between two
> other entities on the link.  So it's not wired vs wireless so much as point-to-
> point vs multi-access.

I added a minor point about NBMA but the main focus in the text is, I hope,
consistent with I think what your main point is.

> > In any event, this
> > class of threats would seem to exclude address scanning (which is
> > trivial if an attacker has access to the local link traffic).
> 
> Depends on the link-layer protocol.  Some link layers (e.g., ones that don't
> support multicast/broadcast) don't use ND and so address scanning may still
> be an issue.
> 
> > apply and locally assigned short addresses have their rightful place
> > in forming link-local IIDs.  The side effect of this is to enable
> > maximally efficient RFC 6282 compression for link-local traffic.
> 
> I think you're still assuming that link-local addresses can never leak via higher
> layer protocols, whereas we know they can.  So link-local addresses are still
> an issue for the off-link case.  Even though an attacker can't use them to
> communicate with the constrained device, they can still result in privacy
> vulnerabilities.

As noted earlier, I updated the text so that address scans and the larger
amount of entropy being mainly for routable addresses.

> 
> > - Concerns about correlation over time may not apply to certain
> > classes of devices (fixed servers) or applications (e.g. building
> > automation, where associating link-layer address with location is a
> > feature, not a bug).  In some cases, it may simply be impractical to
> > change link-layer address on a frequent basis (e.g. it is common in
> > the case of MS/TP nodes to set the L2 address via DIP switches).
> 
> Right, in cases like fixed services that might even be resolvable via DNS or
> some other mechanism, public addresses are used and privacy of such
> design protocols that can ONLY support such cases.  (The draft is a bit softer
> than saying that though, it just says that your Privacy Considerations section
> needs to have a discussion of the issues, and then the IETF community and
> the IESG can decide whether there is IETF consensus on it.)
> 
> Well there's multiple parts of "ND".   The NUD part is still relevant in all
> cases.  The Address Resolution part can be eliminated in some cases (and
> indeed it's up to each link-layer protocol to say how Address Resolution is
> done, which defaults to normal ND if you say nothing).
> 
> > having the U/L bit = 0 in the IID.  This would exclude these patterns
> > from valid privacy IIDs and result in a maximum entropy of ~63 bits.
> 
> One needs additional information to say for sure, because ultimately it's up
> to each link (or maybe even finer granularity).  But for things like address-to-
> string conversion ("pretty-printing") purposes, some implementations (like
> Windows) do have a random generation algorithm that avoids colliding with
> the patterns you mention, and do result in a max entropy of ~63 bits.
> > - In section 2, I think the analysis pertains to the lifetime of a
> > given link so the wording "average lifetime of a device" should
> > instead be "average lifetime of a link".
> 
> Right, will fix (it's correct in the equation at top of page 4 but then the text
> below it wasn't consistent with it).

Done.

> It's not worth noting because the same could be said for TCP or HTTP or
> ICMP.  The "stealth mode" is a property of a host firewall in front of it but on
> the same device.  Section 5 of RFC 7288 (which the draft
> references) already contains a discussion of this point, and just uses TCP and
> ICMP as examples, and that text equally applies to COAP.

Updated text to discuss firewalls and reword to make it clearer that it's
about dropping unsolicited inbound traffic before it ever reaches
the TCP/ICMP/COAP/whatever layer, and also mentioned network firewalls
in front of the subnet, that have the same effect.

> > - In section 3, MS/TP has 7 or 64 bits (since L2 addresses must be in

Fixed.

> 
> > - Section 3.1 seems to alternately switch between discussing
> > link-layer addresses and IIDs formed from those addresses.  Perhaps
> > consistent use of "link identifier" and "interface identifier" would
> > help disambiguate the meaning.
> 

Changed.

> Why should it be noted?  Can you point me to a 6man RFC (since many 6man
> RFCs mention EUI-64 and EUI-48) that notes that the term is trademarked?  Is
> there an RFC style guide directive on such matters?
> 
> When the OUI is unknown, the lack of such knowledge provides a few more
> bits of entropy since the attacker has to at least try any well-known OUI's and
> do a search within each one.  For example, if there's 64+ possible OUI's in
> use, that's around 6 more bits of entropy.   An off-link attacker cannot,
> without additional information, know what the link type is and so has to try
> OUIs without being able to narrow it down to OUI's for that link type.

I also reduced the number of occurrences of the "46 bits" number, since that's
just an example for links that can last 8 years or more.  (Many 6lo links last
for far less time than that, so we shouldn't over-index on the number 46,
it's just an example.   The key point is to derive the number from the max
expected link lifetime.)

> Random MAC addresses was the intent, but "MAC" as a term only applies to
> specific link types.  Maybe "randomized link-layer addresses" is a better
> term, so I'll use that.

Done

> 
> > - In Section 4, first bullet, it should be enough to indicate that
> > privacy IIDs are RECOMMENDED for routable addresses.  (Is there a case
> be sufficient, but not necessary).  For example, if the link lifetime is usually
> <1 second, then privacy IIDs might be overkill.  The point of the first bullet is
> to say that an IP-over-Foo doc should contain such a discussion.  However,
> perhaps your point is that it could say that using privacy addresses is one easy
> way to meet the requirement.
> 
> That is, I don't believe there is 6lo WG consensus for stating that privacy IIDs
> are RECOMMENDED for routable addresses.
> 
> > This section
> I have no problem adding such a reference.  The point is to say what privacy
> considerations need to be addressed in a doc, rather than details of *how*
> to address them, in order to leave maximum freedom.
> But providing examples as informative references as you suggest is a good
> thing.

I checked and there is no reference (RFC or draft) as far as anyone I asked knows.
So I didn't mention DHCPv6 in this document, I left it for 6man documents
to discuss since it's not specific to 6lo.

> > addresses".  I need to go back and re-read [RFC7136] to see if it
> > makes sense to specify U/L bit in this context.
> 

Done

> (And the IP-over-Foo layer should not make assumptions about what upper-
> layer protocols do.)  The risk might be smaller, and hence it might apply
> "less", but it still applies.
> 
> > Fourth bullet - this advice should not apply to link-local IIDs for
> > devices or applications where correlation of activities over time is not a
> concern.
> 
> Same answer.   The risk might be smaller and hence it might apply "less", but
> it still applies.

Also the whole section is under the heading of "recommendations" not
"requirements", so they're already implied SHOULD's rather than MUST's
in that sense.   But either way, the security/privacy text in a draft should address
the issue, whatever the answer is.

> 
> Again the main point of this draft is not to say what one MUST or MUST NOT
> do (or rather *how* one MUST or MUST NOT solve some privacy issue), but
> rather what issues need to be addressed in a doc, and some
> recommendations
> means there's still a need for text to address them or convincingly (to the
> IETF community and to the IESG) explain why some issue doesn't apply to a
> particular IP-over-foo mechanism.
>

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 7 Jul 2016 13:35:20 -0400

Hi Dave,

Thanks for your edits.  I'm currently on holiday with only a mobile phone
(which works only when the wind blows right) so I'll give comments when
i get back to civilization on Tues.  Hopefully we can have some group
discussion in 6lo if time permits.

Regards, Kerry

On Wed, Jul 6, 2016 at 9:22 PM, Dave Thaler <[email-masked]> wrote:

> compromised,
> via higher
> DNS or
> softer
> all
> TCP and
> usually
> privacy

---

From: Dave Thaler <[email-masked]>
Date: Fri, 15 Jul 2016 18:21:55 +0000

> > But providing examples as informative references as you suggest is a
> > good thing.
> 
> So I didn't mention DHCPv6 in this document, I left it for 6man documents to
> discuss since it's not specific to 6lo.

I've now found https://tools.ietf.org/html/rfc7824#section-4.1
which explains why at least today DHCPv6 is not used for temporary addresses.
Based on that discussion, I'm thinking it's best to keep it out of this doc, but
let me know if others disagree (and if so, what text you would suggest after
reading that short section).

I will ask this during my slot in 6lo.

Dave