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

Tom Herbert <tom@herbertland.com> Mon, 02 October 2017 16:27 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 C8A12133059 for <ideas@ietfa.amsl.com>; Mon, 2 Oct 2017 09:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 TD9uLEJtuotT for <ideas@ietfa.amsl.com>; Mon, 2 Oct 2017 09:27:34 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 F306813234B for <ideas@ietf.org>; Mon, 2 Oct 2017 09:27:33 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id u67so5764039qkg.6 for <ideas@ietf.org>; Mon, 02 Oct 2017 09:27:33 -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=9ZCIHbIaACpkWFxcEUoJeyeq0ToeClXv/MXwaUXNXVc=; b=1nhCv3AnwHQy4P9a0Tqiw9brIM7Y8/7EBldy6uUJUIxT5bcd7hd7bm3hx4KSH6pH7c l/fau63PrDIVQ5qQR3H6bY03nyj5j+90rdZ1JKydIjWiboEwuqAj3GoOZQA5XI9WXixb 8yonq6gwSI+p2U629cTx5kyh+bDg1BHh8loKIVV0Rw3DOCHc/zcG4t+5+6nOkraBAnan zkCWfUNxCxhYMZLYV7j1qUeM3VI4MxRN0Y5Pnkc/ltWQQTXKpfrT54PlpBA0puGmD1OA FweQJW/El7TthB/X3usWaGinJQsxJ9CyrPVb9fxM6JIz+fRysCMwVJNOu3EHsJocsWwF Joww==
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=9ZCIHbIaACpkWFxcEUoJeyeq0ToeClXv/MXwaUXNXVc=; b=odglVUQP6j9rrBDGLX74+dwUc9+AAKxnKij3ydHJcaGvbE7cuXATxONWKACPgBwcwy oeVrxy6wZIP6cb/i2IDFTyNrg0zhdbC/elpTku13CiH7dZQocpx0KP5s/0AmbJ2EO9+q /qgTnNdkPNQPQV9lPXFNqoyldY3w5at1b5cQGZ3EWMfnooosZkTw4u0t940kkYvjgP7u sdWrVAe5bfKpDKlm9tHg8xi3q8OO1DssnH+npy1vE4yRvpvMWtkpjIdQYy/DzUCmcTY9 P5GDwNTqwbiO4xFzIgaKgyAj2nFlOYcba0fIPV3ZJP6q5MZLmZCP78N3vzhn1y8wP09Y bOAw==
X-Gm-Message-State: AMCzsaW9/yNpQzH9rYPxuly4ca56f5R63Ap3q28pdRJmtozZTTqnSCUl 6/L3G6xozy9SNXf7UHnxiWtuJhkmzyPegE3B2Q4AUA==
X-Google-Smtp-Source: AOwi7QCZcmcWRnfI2cls0aDU6iaKH8Y3JTGMdO43vRLHL2/YHDo0im1TioC+wRLujBIzARYg4l+mKde1w1JqJsm2O30=
X-Received: by 10.55.155.86 with SMTP id d83mr8935841qke.311.1506961652975; Mon, 02 Oct 2017 09:27:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.144 with HTTP; Mon, 2 Oct 2017 09:27:32 -0700 (PDT)
In-Reply-To: <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com>
References: <e476f817-580b-9083-48bb-72de1745f1c1@huitema.net> <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 02 Oct 2017 09:27:32 -0700
Message-ID: <CALx6S35GKkW1GzSDA2qPx9SJWUfGE23SC4gct3H7eg=EUixgCA@mail.gmail.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Cc: Christian Huitema <huitema@huitema.net>, The IESG <iesg@ietf.org>, "ideas@ietf.org" <ideas@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05d9980417e2055a92da2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/ObMr_1r0-BgIhgv22-R2QemAQSQ>
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:27:36 -0000

On Mon, Oct 2, 2017 at 9:18 AM, Templin, Fred L <Fred.L.Templin@boeing.com>
wrote:

> Hi Christian,
>
>
>
> For applications like civil aviation Air Traffic Management (ATM), we have
>
> a case where it is desirable for Air Traffic Control (ATC) to be able to
> track
>
> the mobile nodes (airplanes).
>
>
>
> We want for ATC to be able to track airplanes wherever they happen to
>
> be worldwide and connected over whatever available data links (satellite,
>
> cellular, WiMAX, VHF, etc.). The mobile nodes also benefit from being
>
> globally addressable at all times, since they are willing participants in
> the
>
> global ATM service.
>
>
>
> So, we see ID/Loc architectures as a useful tool for supporting this
>
> safety-of-flight critical ATM service. Should it be noted that there are
>
> use cases where mobile node tracking is indeed desirable?
>
>
>
If the good guys are able to track mobile devices based on plain text
address, doesn't that mean the bad guys will be able to do that also? Seems
a little bit scary prospect to me in the context of aviation...

Tom

Thanks - Fred
>
>
>
> *From:* Ideas [mailto:ideas-bounces@ietf.org] *On Behalf Of *Christian
> Huitema
> *Sent:* Monday, October 02, 2017 8:56 AM
> *To:* The IESG <iesg@ietf.org>; ideas@ietf.org
> *Subject:* [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks
> (ideas)
>
>
>
> 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.
>
>
>
> 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
>
>