Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)

Tom Herbert <tom@herbertland.com> Mon, 02 October 2017 16:24 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA191344C6 for <ideas@ietfa.amsl.com>; Mon, 2 Oct 2017 09:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 6IgiVsRu4_Fl for <ideas@ietfa.amsl.com>; Mon, 2 Oct 2017 09:24:10 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 69996133059 for <ideas@ietf.org>; Mon, 2 Oct 2017 09:24:07 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id o187so3503338qke.7 for <ideas@ietf.org>; Mon, 02 Oct 2017 09:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RyvHn80zrC48HW0g89XOT9whotKHx+oaRUKL49jos38=; b=1X7cwsraihzCOEO63MESLHczhw53ijFFzTvoX9ozohBc+A4CZNRsYdxN296a5IEIvs RVwlkyh3pJA44LjsRsY3eat2aEKfMNtToYLp6vpAlpWr6nQUurA5r/PPYgBhtefNFEdp wONg0a8H6OQVP1RftETke/hQ7Q6/hu4jbgPkqQf32XPHcndDKZ3g5ptEDYbSbtv3GVPc rarWyqs8Ic1bPi2U/3UdXpOnDOfdUnDfQTanTtg6pp+5eSGQzW0w7pzcPGiCwUHtAqjM /jir5ab8/3GSmHIImai5znnMA2yHQqHv0no936hscWONKbbtAvT+OmP6EQQ2WZEeeSTh DLKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RyvHn80zrC48HW0g89XOT9whotKHx+oaRUKL49jos38=; b=t9RrjSEzYPjDB9IAExTe6MjY0BurOjYVx84fB0EMJnxpvHJiBlXPc03nWYk7qTvsWy c1eOGekJ60X+rlRTZWPRFLFJffBoXc2569Vk/p0rVgX4Ky0YBsTegYWbIy9BeHi9fYFn inVikjt2LROOEKhxVPRG9q/NQvEXFBh+gaoFB2IGX6jLOWbXiVQ/mAopMqtH+KyiwL5D FCdpL6TBV1HEnskK7Hctb7l91ycaPC5a1xS91gx6WM24LjOw8bonnossghF1/MnwUM1L lxE3l1wq+RiM1Pxvoy5FfKkeNqfshgZc+VUvblCIJtvSQ8MkPODC0fzooIAkQCCRMYOR 8Mwg==
X-Gm-Message-State: AMCzsaWRfN7glOsZc4x1hjfx6sF3n58qLTDqhJlaMJoIfO+nnnVOJ8VM r75tOzsgy1iQJ9TjjCE+08PDIDKzaAIpNG93anY3TA==
X-Google-Smtp-Source: AOwi7QC0Z+VYFkUiwQXSnMQYDq2K+QNzwUX74YHeN6P8nrh5SM0lbRaHAHhD3/YFmSL5hS7Ctm22SnwuyOy6cvYy4B4=
X-Received: by 10.55.130.129 with SMTP id e123mr15237121qkd.295.1506961446432; Mon, 02 Oct 2017 09:24:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.144 with HTTP; Mon, 2 Oct 2017 09:24:05 -0700 (PDT)
In-Reply-To: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net>
References: <e476f817-580b-9083-48bb-72de1745f1c1@huitema.net> <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 2 Oct 2017 09:24:05 -0700
Message-ID: <CALx6S36AUemAxhh82QCY5Zm-vG3PwTOAq2_Drt__-hf8uQyyyg@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: The IESG <iesg@ietf.org>, ideas@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0727dab49011055a92cd78"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/aJkE0xUn-5uhTO1NqH2palxi7CQ>
Subject: Re: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2017 16:24:12 -0000

On Mon, Oct 2, 2017 at 8:55 AM, Christian Huitema <huitema@huitema.net>
wrote:

> I just realized that I forget to copy this message to the IESG and IDEAS
> mailing lists. Sorry.
>
> -------- Forwarded Message --------
> Subject: Fwd: Re: WG Review: IDentity Enabled Networks (ideas)
> Date: Sun, 1 Oct 2017 17:06:46 -0700
> From: Christian Huitema <huitema@huitema.net> <huitema@huitema.net>
> To: IETF Discussion Mailing List <ietf@ietf.org> <ietf@ietf.org>
>
> On 9/29/2017 9:13 AM, The IESG wrote:
>
> > A new IETF WG has been proposed in the Routing Area. The IESG has not made
> > any determination yet. The following draft charter was submitted, and is
> > provided for informational purposes only. Please send your comments to the
> > IESG mailing list (iesg@ietf.org) by 2017-10-09.
> ...
> >
> > Network solutions based on the concept of Identifier-Locator separation are
> > increasingly considered to support mobility, overlay networking for
> > virtualization and multi-homing across heterogeneous access networks.
>
> The problem there is that the same properties that facilitate routing
> also facilitate tracking.
>
> Consider a mobile node that switches from a Wi-Fi network to a cellular
> network. In the current state of the art, there is no relation between
> the Wi-Fi address and the cellular address. Intermediaries cannot
> observe the traffic and deduce that two different flows of IP packets
> originate from the same node. In contrast, with an ID/Loc architecture,
> the two flows are associated with the same identifier, which can then be
> used to track the movements of the device.
>
> Similarly, consider a node that connects several times to the same
> network, and each time uses IPv6 temporary addresses. The web servers
> that it contact cannot use the IP addresses to correlate different
> connections that happened at different times. This would change if the
> identifier in an ID/LOC architecture remained constant.
>
> I don't think the idea is that identifiers in ID/LOC are intended to be
constant. To the contrary, an end host should be able to use an arbitrary
identifiers to create IP addresses to achieve the exact same effect of IPv6
temporary addresses (from the application point of view the mechanism is
identical). There should be no systematic means within the network to
correlate that two packets with different source addresses are from the
same node.

There is one caveat, not so much specific to ID/LOC, but how host IPv6
address assigned is being done. It is common to assign a /64 IPv6 address
to UE. A stated benefit in security is that this makes address scanning
difficult (i.e. an attacker scanning over a 2^64 space is difficult). The
downside of this that address obfuscation for device tracking is only
effective in the upper 64 bits which means the available address space for
untrackable device addresses is much smaller. I believe that the upshot is
that more bits should be assigned to device prefix to achieve security.
This was discussed in 6man list, but is also relevant to ID/LOC.

Tom

Multipath TCP and planned multipath extensions of QUIC are example of
> transport protocol that allow transport connections to use multiple
> network paths simultaneously. In both cases, there s significant work
> going on to ensure that intermediaries cannot easily associate the
> traffic on the multiple paths with a single connection. If the
> multi-homing function was delegated to an ID/LOC system, intermediaries
> could potentially observe the identifiers and associate these connections.
>
> In short, careless applications of the ID/LOC architecture could easily
> result in serious privacy issues. The proposed charter does include a
> brief statement about privacy:
>
> > - Analysis of the concepts of identity-identifier split and dynamic
> > identifier changes, including their implications on anonymity and privacy.
> > Explicitly, the framework must define privacy requirements and how potential
> > extensions/solutions should meet them.
>
> This is a good start, but the whole concept of "unique identifiers" is
> scary, and I would like to see this expanded. For example, I would like
> to see an explicit reference to a baseline, e.g. assuring no privacy
> downgrade compared to IPv6 temporary addresses, or assuring that hosts
> that elect to not be tracked when roaming across networks will not be. I
> also know that there have been discussions of hiding identifiers from
> intermediaries, and i would like to see that as an explicit goal of the
> proposed WG.
>
> --
> Christian Huitema
>
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
>