[6lo] Review of draft-ietf-6lo-privacy-considerations-00
Kerry Lynn <kerlyn@ieee.org> Wed, 04 November 2015 01:39 UTC
Return-Path: <kerlyn2001@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EAB1A8903 for <6lo@ietfa.amsl.com>; Tue, 3 Nov 2015 17:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level:
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJkeRajXlgmI for <6lo@ietfa.amsl.com>; Tue, 3 Nov 2015 17:39:41 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7751A88D9 for <6lo@ietf.org>; Tue, 3 Nov 2015 17:39:41 -0800 (PST)
Received: by lbbwb3 with SMTP id wb3so5296377lbb.1 for <6lo@ietf.org>; Tue, 03 Nov 2015 17:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=B7ZuaRUARNh+BdeXgC2Jgwrk6ENDkM9s5sMhc5KkZE4=; b=ch9sdffnF1pWkI9SCs+hsTzRMbzDsBGkPwjo1tbU0knFs0bQ2APa/n8btj/RmVWjK2 tnAspO0mg4Pro9Y4tghGIFUbCwz/+tuD1pVrf2bx1zFCmHGCCWEDnpwRtXFQBMIApTOa GZ4YOeqApfSE89eJEQpS/cv+HifdGQJsOYm7np/Xy4uPp12+cxmV7KKjWybIkkFoDl2g +nDl4oFjf2eZf3GOUR9RDjp8nw531ChrEZMhJfg0kvDoIaIB4icu+iEhXm13CA0ah1bC nK+WH/LYLWKTWe1LMcbU4d/XsDks196suuRPIahLxSdTCpRwaoDo/3NaYfTBf2NPHn47 Kz9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee_org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=B7ZuaRUARNh+BdeXgC2Jgwrk6ENDkM9s5sMhc5KkZE4=; b=yF5+rnwK+5BV8qJOl4WIis+IRZwGprxa9Wvj2dtfJgnQBBU7+O5eRYmJb5CUzIE96L 5SJH0t099+/PRNyiA68svbEEN5Psg8RCeYWg6/1F42pJFGzsTL9iVH+KhFALKtleFHm9 I53XTiYCZPjCLz4yB8G6HA8gBV/nsgJFfLf82eTA7r/71Gv4JkQFmG7vak8bSTeqnlcP dzFwQ5FgcN7xd4IZqDmyu3rNsndUDK4BkryU2HEJ/l7FCZuAYslClVo0qPKDC9AFi8f/ xs5YzXvjsor7Gk+VtJuI3Is0SzUBDOBhFks8FjhTkELLw3T6qP09mBIYBHFEsiX+ICFx QiPw==
MIME-Version: 1.0
X-Received: by 10.112.159.2 with SMTP id wy2mr14706914lbb.102.1446601179235; Tue, 03 Nov 2015 17:39:39 -0800 (PST)
Sender: kerlyn2001@gmail.com
Received: by 10.25.165.195 with HTTP; Tue, 3 Nov 2015 17:39:39 -0800 (PST)
Date: Tue, 03 Nov 2015 20:39:39 -0500
X-Google-Sender-Auth: 5QhEw7MrT6AB-QrdsVEj6UxWNvU
Message-ID: <CABOxzu3rCprewfRmBkj1MoE34dF03m9NKs1-=PRiwhnijh+81g@mail.gmail.com>
From: Kerry Lynn <kerlyn@ieee.org>
To: "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c240d06b91060523ad15fb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6lo/KJ2We-Xi1AJf_qI3Rg8_eK7mIsc>
Subject: [6lo] Review of draft-ietf-6lo-privacy-considerations-00
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 01:39:43 -0000
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 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