Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6lobac-06: (with DISCUSS and COMMENT)
Kerry Lynn <kerlyn@ieee.org> Mon, 27 February 2017 22:53 UTC
Return-Path: <kerlyn2001@gmail.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 D2C59129459; Mon, 27 Feb 2017 14:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.418
X-Spam-Level:
X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PtJKWvsUWV6u; Mon, 27 Feb 2017 14:53:40 -0800 (PST)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 BAC7612944F; Mon, 27 Feb 2017 14:53:40 -0800 (PST)
Received: by mail-ot0-x235.google.com with SMTP id x10so62129843otb.1; Mon, 27 Feb 2017 14:53:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bIg/kPEbjG9Ry69WjQqwc1E0Wr7Dq06JmblcbQh27ww=; b=cfINvipwTYCwBxvHBcEmnBS2R9gVggawrz+Y0OZtqvflnx+BS30U8UxV+Z9RmyZ+d3 CSPBL0Lck9QIM398SHfy+vaShAhET1r0ljkqgdNTu1wXBVopkRHfW5BoXMspBZKDNqf3 RumMDiaQBGuh7GABN6Hw6TvOdw94MszvQ5ehlMT23/0a69SbTd+4liJZnfxfy4echTB5 vC7STU9Mng6XszZ/2jLbRZlONBcgVjzq+OadO1oRCcYfeD+reJemq3MHGbhsFeJS7eKs a8cmgb5EzQ6avOOGir18Fu62AxrshOPp2sdbPbs6U2WuI1UFuUb6h7J4dKGBCmKLdhwZ qdYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bIg/kPEbjG9Ry69WjQqwc1E0Wr7Dq06JmblcbQh27ww=; b=R3r8A7MT9/tRKVFeydMY0SpNlk9yzuJtSRMN7WaK3vhDxXQ1D+Jd2RDrjiWGkWZISg T19Fr7Gnej+bUSmwKo1bcedJlYU0JGS35U+U4f7Di2IXQfIC0o3OYjOKo1FOnxxhJt9s f4Rab62Ve3FCDztQyqq3bi00c1oQi4NnnAZrWHt4a5J/b7xpS17+49hvfhaqa7tgw40W /3ew3fM8ty/NwM/YllqiH8BxCkAODYJoTGpcJ79tmyWnoqUKEkkDUnuYTt67MkSShuP8 YQYQxW+J7h+EQYbfwUOKday0SZ+iYteQ36ebgvf+WaeKgkORHkd6HTZnsW4SVKNgtd3q jitg==
X-Gm-Message-State: AMke39n1w4FM3XTRb8PrU8Pbj+1xQEel10eqxRkqEG0cN6+mS0c1NuEO1+xHbVil1TWsBz+o/ORAhKkGtLV5DA==
X-Received: by 10.157.33.181 with SMTP id s50mr10895555otb.15.1488236020043; Mon, 27 Feb 2017 14:53:40 -0800 (PST)
MIME-Version: 1.0
Sender: kerlyn2001@gmail.com
Received: by 10.182.217.38 with HTTP; Mon, 27 Feb 2017 14:53:39 -0800 (PST)
In-Reply-To: <148052358314.2961.7757929872750287025.idtracker@ietfa.amsl.com>
References: <148052358314.2961.7757929872750287025.idtracker@ietfa.amsl.com>
From: Kerry Lynn <kerlyn@ieee.org>
Date: Mon, 27 Feb 2017 17:53:39 -0500
X-Google-Sender-Auth: 9gzOvni5VyfB69OtzRtjmwRec3I
Message-ID: <CABOxzu0WU21H-xEUF9WHO2ZFmuYriU9Eft8cyPkrn8yEvfh3WQ@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary="001a1147f2c851156f05498af3b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/1r3bXtJgBz-kiG3tca8O8wsWZjY>
Cc: 6lo-chairs@ietf.org, "6lo@ietf.org" <6lo@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-6lo-6lobac@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>
Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6lobac-06: (with DISCUSS and COMMENT)
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: Mon, 27 Feb 2017 22:53:43 -0000
Hi Alissa, Thanks for your review. Sorry it has taken to long to get back to you. Comments inline... On Wed, Nov 30, 2016 at 11:33 AM, Alissa Cooper <alissa@cooperw.in> wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-6lo-6lobac-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 12 says: > > "For this reason, it is RECOMMENDED that a different (but stable) IID be > generated for each globally scoped address in use according to, for > example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]." > > I have a couple of questions about this recommendation that should be > easy to clear up. First, do you really mean "different" IID? EUI-64 > identifiers are different from each other, but embedding one in an IID > still leaves you susceptible to address scanning attacks. Maybe what is > meant here is "semantically opaque" or "with maximum supportable entropy" > or something along those lines? > > <kel> I've added text that distinguishes between "MAC-address-derived" and "semantically opaque" IIDs. The first is formed from the dynamically assigned 8-bit MS/TP node address and is recommended for link-local traffic (which is likely the only type of traffic for many deployments). "Semantically opaque" IIDs having 64 bits of entropy are strongly recommended for forming globally scoped addresses. Section 12 recommends a different such IID for each routable address in use. </kel? > Second, what is meant by the word "stable" here? The mechanisms cited > offer a variety of different "stability" spans -- DHCP lease lifetime, > temporary address lifetime, lifetime of connection to a link, etc. So > it's not clear what is actually being recommended or if the cited > mechanisms all provide the desired property. > > <kel> Section 12 now references RFC 8065, which distinguishes between "stable" and "temporary" addresses - the former typically employed by servers and the latter by clients. Section 12 recommends the latter be changed "frequently" but doesn't go into details (implying you should read RFC 8065 for guidance). The point of changing global addresses frequently is to mitigate address scanning attacks. The analysis in RFC 8065 Section 2 could have been presented as (number of trials to 0.5 probability of a "hit") X (time per trial). The number of trials to 0.5 probability of a hit can be modeled as between an urn without replacement (in the case of a stable address) to an urn with replacement (in the limit, where the address changes with each new connection). </kel> > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I mostly understand why Sections 6 and 12 are specified as they are but > there are a couple of points of departure from > draft-ietf-6lo-privacy-considerations and draft-ietf-6man-default-iids > that I'd like to discuss. > > (1) draft-ietf-6man-default-iids says that the choice of address > generation mechanism should be configurable when a mechanism is specified > to embed a link layer address in an IID. Is there a reason that doesn't > apply here? The document doesn't say anything about it for the link-local > case. > > <kel> I have been trying to follow RFC 8064, but not too successfully. I'm under the impression that it only applies to situations where the guidance is that a link-layer derived IID is used in a globally scoped address? 6LoBAC strongly recommends the use of semantically opaque IIDs for such addresses. </kel> > (2) draft-ietf-6lo-privacy-considerations says: > > "Specifications should make sure that an IPv6 address can change > over long periods of time. For example, the interface identifier > might change each time a device connects to the network (if > connections are short), or might change each day (if connections > can be long). This is necessary to mitigate correlation over > time." > > This document doesn't seem to provide any guidance about supporting the > ability to change an IPv6 address within the life span of a long-lived > attachment to the same physical network. Some of the mechanisms cited in > Section 12 provide this and some do not. I appreciate that correlation of > activities over time isn't perceived to be a huge threat here, but aren't > there cases where being able to change an address despite remaining > attached to the same physical network would be desirable? That seems > worth some guidance for nodes that want to support it. > > <kel> The guidance is that "temporary" globally scoped addresses should change frequently. An issue arises with MAC-address-derived IIDs used to form link-local addresses. It is quite typical that the address of an MS/TP device is selected by DIP switches and then the device is placed e.g. in the ceiling for an extended period (ideally years). For this to present a correlation of activities over time risk, the link-local address would a) have to leak offlink, and b) be correlated with a temporary globally scoped address that is changing frequently. Does this scenario pose a serious concern? If so, I think the best guidance that can be offered is to not let link-local addresses leak. This is unlikely in the first place, as MS/TP devices are usually quite constrained and all the bytes in flash are accounted for (thermostats don't typically send email). </kel> Thanks again, Kerry
- [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6… Alissa Cooper
- Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6… Kerry Lynn