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

[Kerry Lynn <[e-mail]>]

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 = 0 in the IID.  This would exclude these patterns from
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