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

[AbdurRashidSangi <[e-mail]>]

Dear all,

Suppose if a particular use case requires more frequently the arbitrary use of randomly generated IIDs then enormous amount of DAD cycle would be created.

Although, MAC driven IIDs (RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4338, RFC4391, RFC5121 and RFC5072) needs less or no amount of DAD but in practice such IID generation is discouraged "draft-ietf-6man-default-iids-09 AND I-D.ietf-6man-ipv6-address-generation-privacy" as the privacy concerns (Network activity correlation, Location tracking, Address scanning and Device-specific vulnerability exploitation) still persist. More preferred approach is to use RFC7217 for same purpose. 

Unlike for DAD the 6LBR, providing the status (= 1) and needs the LN to regenerate an IID which ultimately require another DAD cycle, 6LBR (according to RFC7217) suggest a unique IID for LNs using its own (6LBR) secret key?

Wouldn't it be a better approach?

Cheers,
Rashid Sangi.

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