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

Dave Thaler <dthaler@microsoft.com> Wed, 06 July 2016 01:22 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BCB12D182 for <6lo@ietfa.amsl.com>; Tue, 5 Jul 2016 18:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.021
X-Spam-Level:
X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 bO1KGQe8QPsg for <6lo@ietfa.amsl.com>; Tue, 5 Jul 2016 18:22:13 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0137.outbound.protection.outlook.com [104.47.34.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BB612B025 for <6lo@ietf.org>; Tue, 5 Jul 2016 18:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aq43M2MvlvhfqLlGT6zdd7MTmiHGoQKx3mTGP/+VB8Y=; b=PHVW7Y1MRVvgDjmQUqm8Ibr+yqjr3ICsEOd1YtRyiv65GJPSoza/dvKlfCbwP990S6tKGohfwY8Aj3Vmo7e/cKLJ8Cg5ASFrUWV1I1fuBrOClsgMF2iZY607M5lQYqWNWxShWv218k9rtaDbfOQ9dpwGMzNy/YHwaZOlVEDfIG4=
Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Wed, 6 Jul 2016 01:22:11 +0000
Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0534.015; Wed, 6 Jul 2016 01:22:11 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "6lo@ietf.org" <6lo@ietf.org>, Kerry Lynn <kerlyn@ieee.org>
Thread-Topic: RE: [6lo] RESEND: Reveiw of draft-ietf-6lo-privacy-considerations-00
Thread-Index: AdHXI6KQvHrJgkbFSuihW6hkeciJmQ==
Date: Wed, 06 Jul 2016 01:22:11 +0000
Message-ID: <DM2PR0301MB0717E12C81B148B725353679A33A0@DM2PR0301MB0717.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2001:4898:80e8:f::470]
x-ms-office365-filtering-correlation-id: ce394675-6d71-478d-6e23-08d3a53bf493
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0717; 6:ogI1jbAyXAgBTR8wNgzLKsmKoy0zHcif9e/ZpRCycH2KLn8b2TXZomFS0WhA9U9nkqmm7bg3YHT23EvBXm2ycvtYNuZQmVIWGPtz23VBwsrM+0QDyEYmKnpQ6VGOTPRm/cTpYvubzZ2Kljb9XjxJQV5EOkx8s2c4I5XCOc/AfN80WJNVkg6Er/V2LaVyUXOEq+cKOx3RdX24Pl+W+oSVE94DFug5pPnGwYR6MWJeQJwwXytJ+belPgjo/wCprcldomkgdhn/0lDuGsAoZy0Q4X2BUz1gSuRXtaJAN8skVsvOilbAAh068CScJ2t75EoscJJBnTcjCAN64keheATr+A==; 5:OQL3vDSQAWyeNtkVCWmKQsybBHI9UCPwZemPfAzceRnQg/A2V+VFvfOivETxnb7kzMbNH8gNRwl5kxyNsOuOVPwe1vT7elvNkib+febe6eGdpOZWdBh7CqbHqGk7SdYiw4sejo+bH/eZE1/Ge9tUxw==; 24:gYrW8vJvjydydyIXKZ/lXQASsfm0WiXwzDAMOBKCZYn+r02t93LMztwdY/8LuYquWK5A22IRPG0bmLeV+AX7Re51nLaHDAs04aPgZu/3zSY=; 7:T3b1HA5zdyw2n0AeJ3obW+3w13+EionBAUvva9VeSasFRsQtwlAMTXjJo9MyG6Yb9Q2lQ3/dQh4a0ONYeQO7YX/2ydX7AzmckBXxJzCU3yrcECVvuqM2QSa60iPJPJOn0SAtDNV5LW51/mvhCAwKwaNO0NMDOovi6byA9r1BVq21f+ucjEn1++dldru8bYVg28Hb+Glmg2j8/2PHKS3JTo5sEs7K01GfviS7J0O6vQ7pH/7sdDXlZSS1CPqX15if
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0717;
x-microsoft-antispam-prvs: <DM2PR0301MB07174B20157A63405A9A3F53A33A0@DM2PR0301MB0717.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(192374486261705)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0717; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0717;
x-forefront-prvs: 0995196AA2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(43784003)(24454002)(51914003)(189002)(199003)(101416001)(68736007)(3660700001)(106356001)(2906002)(105586002)(81156014)(9686002)(19625215002)(122556002)(81166006)(2900100001)(790700001)(7846002)(7736002)(6116002)(102836003)(5002640100001)(8936002)(586003)(5003600100003)(19300405004)(15975445007)(77096005)(3280700002)(2501003)(74316002)(7696003)(8676002)(33656002)(189998001)(54356999)(86362001)(10090500001)(50986999)(11100500001)(107886002)(97736004)(19580395003)(5001770100001)(76576001)(87936001)(99286002)(5005710100001)(8990500004)(230783001)(10290500002)(16236675004)(10400500002)(92566002)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0717; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0717E12C81B148B725353679A33A0DM2PR0301MB0717_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2016 01:22:11.2686 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0717
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/TQY9M7EBxrPkl3Ww9a1d96eqCNU>
Subject: Re: [6lo] RESEND: Reveiw of draft-ietf-6lo-privacy-considerations-00
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
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, 06 Jul 2016 01:22:17 -0000

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

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

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

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

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

> - In section 3, MS/TP has 7 or 64 bits (since L2 addresses must be in
> the range 0 - 127).

Thanks, will fix.

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

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

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

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

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

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