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

[Kerry Lynn <[e-mail]>]

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

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