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

[Kerry Lynn <[e-mail]>]

Correction below...

On Tue, Nov 3, 2015 at 8:39 PM, Kerry Lynn <[e-mail]> wrote:

> Greetings,
>
> 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.
>
> 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.
>
> - 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.
>
> 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?  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).
>
> - 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.
>
> - 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).
>
> - 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.)  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 = 1 in the IID.  This would exclude these patterns from
>

This ^^^ should read "having the U/L bit = 0 in the IID."

>

> valid privacy IIDs and result in a maximum entropy of ~63 bits.
>
>
> 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".
>
> 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.
>
> - In section 3, MS/TP has 7 or 64 bits (since L2 addresses must be in
> the range 0 - 127).
>
> - 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.
>
> EUI-64 and EUI-48 are well-defined terms (trademarked in fact, and
> this should be noted in the document).  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".  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.
>
> - 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?)  This section
> should also discuss options for providing privacy IIDs via DHCPv6
> (M=1 in RA).
>
> 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.
>
> Third bullet - this advice should not apply to link-local IIDs.  Any
> attacker
> wishing to find "hits" just needs to fire up a sniffer.
>
> 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.
>
> HTH, Kerry
>