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

[Dave Thaler <[e-mail]>]

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: [e-mail]; Kerry Lynn <[e-mail]>
> 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!
> 
> > 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 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.
> > 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.

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.

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

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

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

Done.

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

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
> > the range 0 - 127).
> 
> Thanks, will fix.

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.
> 
> Ok, will see what I can do.

Changed.

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

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

Done

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

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.

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

Done

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

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