From nobody Mon Oct 2 08:56:02 2017 Return-Path: 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 7123313234B for ; Mon, 2 Oct 2017 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 SNffnxxJP-Kh for ; Mon, 2 Oct 2017 08:55:52 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788FF13304A for ; Mon, 2 Oct 2017 08:55:51 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dz34N-0005Nx-UQ for ideas@ietf.org; Mon, 02 Oct 2017 17:55:49 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dz34G-00087g-Ph for ideas@ietf.org; Mon, 02 Oct 2017 11:55:45 -0400 Received: (qmail 4188 invoked from network); 2 Oct 2017 15:55:37 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.117]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Oct 2017 15:55:37 -0000 References: To: The IESG , ideas@ietf.org From: Christian Huitema X-Forwarded-Message-Id: Message-ID: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> Date: Mon, 2 Oct 2017 08:55:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C0223FBA6D252892D234B2EF" Content-Language: en-US X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5uRpdYmWlxtC1fWHyapxk6IXv9krsgRhBn0ayn6qsUc7p7He3a39gjg/ 9oOEoAajC61PdOWeIW8R8TgUu5HhPnKfiMbvyB9bt0CmI37AboPsTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKeAoqWDmtF8nD2nEDT705fpjj0HlFDoqoWF20+xKQ35+nd/nGlMBQ0xDQkm A/S/XlviXj3T4KI9X3Edk1VAD/raxm0eXjh1Edf5/6lW85Glx+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYjmJKJXZ+nOfVIFw1j15M+NioHoPZGa4M+gVoRbXuj eYr/hP0Jmw5F96Fkk2ajdfYHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFGJcKcttgBZ1L66iO4uqDysibYT4C2qF2lnc18bVJn66J awn+Wnh2kh0k8ZYL6YOzHQk0IjYSNEQ5rGiBTcWNKzwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTgV2UgQ4fjGXvUpBoNqBFuFjI1dRH6f16eQCtvwPkeoznDkScy96NTyJk9BjUcSB1l1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 15:55:53 -0000 This is a multi-part message in MIME format. --------------C0223FBA6D252892D234B2EF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 To: IETF Discussion Mailing List 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 --------------C0223FBA6D252892D234B2EF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

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>
To: IETF Discussion Mailing List <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
--------------C0223FBA6D252892D234B2EF-- From nobody Mon Oct 2 09:18:46 2017 Return-Path: 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 47400133059; Mon, 2 Oct 2017 09:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Foz7uQ2yo_Yl; Mon, 2 Oct 2017 09:18:38 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05451326FE; Mon, 2 Oct 2017 09:18:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v92GIXx7039117; Mon, 2 Oct 2017 09:18:37 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v92GIPdU039010 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 2 Oct 2017 09:18:25 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Oct 2017 09:18:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 2 Oct 2017 09:18:25 -0700 From: "Templin, Fred L" To: Christian Huitema , The IESG , "ideas@ietf.org" Thread-Topic: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTO5b1XXR8U7Y2UkCpxQHITCbUoqLQumHA Date: Mon, 2 Oct 2017 16:18:25 +0000 Message-ID: <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> In-Reply-To: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_45e8993a73ef4bb9b3914f32c4609823XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:18:41 -0000 --_000_45e8993a73ef4bb9b3914f32c4609823XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuLA0KDQpGb3IgYXBwbGljYXRpb25zIGxpa2UgY2l2aWwgYXZpYXRpb24gQWly IFRyYWZmaWMgTWFuYWdlbWVudCAoQVRNKSwgd2UgaGF2ZQ0KYSBjYXNlIHdoZXJlIGl0IGlzIGRl c2lyYWJsZSBmb3IgQWlyIFRyYWZmaWMgQ29udHJvbCAoQVRDKSB0byBiZSBhYmxlIHRvIHRyYWNr DQp0aGUgbW9iaWxlIG5vZGVzIChhaXJwbGFuZXMpLg0KDQpXZSB3YW50IGZvciBBVEMgdG8gYmUg YWJsZSB0byB0cmFjayBhaXJwbGFuZXMgd2hlcmV2ZXIgdGhleSBoYXBwZW4gdG8NCmJlIHdvcmxk d2lkZSBhbmQgY29ubmVjdGVkIG92ZXIgd2hhdGV2ZXIgYXZhaWxhYmxlIGRhdGEgbGlua3MgKHNh dGVsbGl0ZSwNCmNlbGx1bGFyLCBXaU1BWCwgVkhGLCBldGMuKS4gVGhlIG1vYmlsZSBub2RlcyBh bHNvIGJlbmVmaXQgZnJvbSBiZWluZw0KZ2xvYmFsbHkgYWRkcmVzc2FibGUgYXQgYWxsIHRpbWVz LCBzaW5jZSB0aGV5IGFyZSB3aWxsaW5nIHBhcnRpY2lwYW50cyBpbiB0aGUNCmdsb2JhbCBBVE0g c2VydmljZS4NCg0KU28sIHdlIHNlZSBJRC9Mb2MgYXJjaGl0ZWN0dXJlcyBhcyBhIHVzZWZ1bCB0 b29sIGZvciBzdXBwb3J0aW5nIHRoaXMNCnNhZmV0eS1vZi1mbGlnaHQgY3JpdGljYWwgQVRNIHNl cnZpY2UuIFNob3VsZCBpdCBiZSBub3RlZCB0aGF0IHRoZXJlIGFyZQ0KdXNlIGNhc2VzIHdoZXJl IG1vYmlsZSBub2RlIHRyYWNraW5nIGlzIGluZGVlZCBkZXNpcmFibGU/DQoNClRoYW5rcyAtIEZy ZWQNCg0KRnJvbTogSWRlYXMgW21haWx0bzppZGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMiwgMjAxNyA4 OjU2IEFNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBpZGVhc0BpZXRmLm9yZw0KU3Vi amVjdDogW0lkZWFzXSBGd2Q6IEZ3ZDogUmU6IFdHIFJldmlldzogSURlbnRpdHkgRW5hYmxlZCBO ZXR3b3JrcyAoaWRlYXMpDQoNCg0KSSBqdXN0IHJlYWxpemVkIHRoYXQgSSBmb3JnZXQgdG8gY29w eSB0aGlzIG1lc3NhZ2UgdG8gdGhlIElFU0cgYW5kIElERUFTIG1haWxpbmcgbGlzdHMuIFNvcnJ5 Lg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDoNCg0KRndk OiBSZTogV0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5ldHdvcmtzIChpZGVhcykNCg0KRGF0 ZToNCg0KU3VuLCAxIE9jdCAyMDE3IDE3OjA2OjQ2IC0wNzAwDQoNCkZyb206DQoNCkNocmlzdGlh biBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5l dD4NCg0KVG86DQoNCklFVEYgRGlzY3Vzc2lvbiBNYWlsaW5nIExpc3QgPGlldGZAaWV0Zi5vcmc+ PG1haWx0bzppZXRmQGlldGYub3JnPg0KDQoNCg0KT24gOS8yOS8yMDE3IDk6MTMgQU0sIFRoZSBJ RVNHIHdyb3RlOg0KDQoNCg0KPiBBIG5ldyBJRVRGIFdHIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRo ZSBSb3V0aW5nIEFyZWEuIFRoZSBJRVNHIGhhcyBub3QgbWFkZQ0KDQo+IGFueSBkZXRlcm1pbmF0 aW9uIHlldC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcyBzdWJtaXR0ZWQsIGFuZCBp cw0KDQo+IHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlDQoNCj4gSUVTRyBtYWlsaW5nIGxpc3QgKGllc2dAaWV0 Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+KSBieSAyMDE3LTEwLTA5Lg0KDQouLi4NCg0KPg0K DQo+IE5ldHdvcmsgc29sdXRpb25zIGJhc2VkIG9uIHRoZSBjb25jZXB0IG9mIElkZW50aWZpZXIt TG9jYXRvciBzZXBhcmF0aW9uIGFyZQ0KDQo+IGluY3JlYXNpbmdseSBjb25zaWRlcmVkIHRvIHN1 cHBvcnQgbW9iaWxpdHksIG92ZXJsYXkgbmV0d29ya2luZyBmb3INCg0KPiB2aXJ0dWFsaXphdGlv biBhbmQgbXVsdGktaG9taW5nIGFjcm9zcyBoZXRlcm9nZW5lb3VzIGFjY2VzcyBuZXR3b3Jrcy4N Cg0KDQoNClRoZSBwcm9ibGVtIHRoZXJlIGlzIHRoYXQgdGhlIHNhbWUgcHJvcGVydGllcyB0aGF0 IGZhY2lsaXRhdGUgcm91dGluZw0KDQphbHNvIGZhY2lsaXRhdGUgdHJhY2tpbmcuDQoNCg0KDQpD b25zaWRlciBhIG1vYmlsZSBub2RlIHRoYXQgc3dpdGNoZXMgZnJvbSBhIFdpLUZpIG5ldHdvcmsg dG8gYSBjZWxsdWxhcg0KDQpuZXR3b3JrLiBJbiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgYXJ0 LCB0aGVyZSBpcyBubyByZWxhdGlvbiBiZXR3ZWVuDQoNCnRoZSBXaS1GaSBhZGRyZXNzIGFuZCB0 aGUgY2VsbHVsYXIgYWRkcmVzcy4gSW50ZXJtZWRpYXJpZXMgY2Fubm90DQoNCm9ic2VydmUgdGhl IHRyYWZmaWMgYW5kIGRlZHVjZSB0aGF0IHR3byBkaWZmZXJlbnQgZmxvd3Mgb2YgSVAgcGFja2V0 cw0KDQpvcmlnaW5hdGUgZnJvbSB0aGUgc2FtZSBub2RlLiBJbiBjb250cmFzdCwgd2l0aCBhbiBJ RC9Mb2MgYXJjaGl0ZWN0dXJlLA0KDQp0aGUgdHdvIGZsb3dzIGFyZSBhc3NvY2lhdGVkIHdpdGgg dGhlIHNhbWUgaWRlbnRpZmllciwgd2hpY2ggY2FuIHRoZW4gYmUNCg0KdXNlZCB0byB0cmFjayB0 aGUgbW92ZW1lbnRzIG9mIHRoZSBkZXZpY2UuDQoNCg0KDQpTaW1pbGFybHksIGNvbnNpZGVyIGEg bm9kZSB0aGF0IGNvbm5lY3RzIHNldmVyYWwgdGltZXMgdG8gdGhlIHNhbWUNCg0KbmV0d29yaywg YW5kIGVhY2ggdGltZSB1c2VzIElQdjYgdGVtcG9yYXJ5IGFkZHJlc3Nlcy4gVGhlIHdlYiBzZXJ2 ZXJzDQoNCnRoYXQgaXQgY29udGFjdCBjYW5ub3QgdXNlIHRoZSBJUCBhZGRyZXNzZXMgdG8gY29y cmVsYXRlIGRpZmZlcmVudA0KDQpjb25uZWN0aW9ucyB0aGF0IGhhcHBlbmVkIGF0IGRpZmZlcmVu dCB0aW1lcy4gVGhpcyB3b3VsZCBjaGFuZ2UgaWYgdGhlDQoNCmlkZW50aWZpZXIgaW4gYW4gSUQv TE9DIGFyY2hpdGVjdHVyZSByZW1haW5lZCBjb25zdGFudC4NCg0KDQoNCk11bHRpcGF0aCBUQ1Ag YW5kIHBsYW5uZWQgbXVsdGlwYXRoIGV4dGVuc2lvbnMgb2YgUVVJQyBhcmUgZXhhbXBsZSBvZg0K DQp0cmFuc3BvcnQgcHJvdG9jb2wgdGhhdCBhbGxvdyB0cmFuc3BvcnQgY29ubmVjdGlvbnMgdG8g dXNlIG11bHRpcGxlDQoNCm5ldHdvcmsgcGF0aHMgc2ltdWx0YW5lb3VzbHkuIEluIGJvdGggY2Fz ZXMsIHRoZXJlIHMgc2lnbmlmaWNhbnQgd29yaw0KDQpnb2luZyBvbiB0byBlbnN1cmUgdGhhdCBp bnRlcm1lZGlhcmllcyBjYW5ub3QgZWFzaWx5IGFzc29jaWF0ZSB0aGUNCg0KdHJhZmZpYyBvbiB0 aGUgbXVsdGlwbGUgcGF0aHMgd2l0aCBhIHNpbmdsZSBjb25uZWN0aW9uLiBJZiB0aGUNCg0KbXVs dGktaG9taW5nIGZ1bmN0aW9uIHdhcyBkZWxlZ2F0ZWQgdG8gYW4gSUQvTE9DIHN5c3RlbSwgaW50 ZXJtZWRpYXJpZXMNCg0KY291bGQgcG90ZW50aWFsbHkgb2JzZXJ2ZSB0aGUgaWRlbnRpZmllcnMg YW5kIGFzc29jaWF0ZSB0aGVzZSBjb25uZWN0aW9ucy4NCg0KDQoNCkluIHNob3J0LCBjYXJlbGVz cyBhcHBsaWNhdGlvbnMgb2YgdGhlIElEL0xPQyBhcmNoaXRlY3R1cmUgY291bGQgZWFzaWx5DQoN CnJlc3VsdCBpbiBzZXJpb3VzIHByaXZhY3kgaXNzdWVzLiBUaGUgcHJvcG9zZWQgY2hhcnRlciBk b2VzIGluY2x1ZGUgYQ0KDQpicmllZiBzdGF0ZW1lbnQgYWJvdXQgcHJpdmFjeToNCg0KDQoNCj4g LSBBbmFseXNpcyBvZiB0aGUgY29uY2VwdHMgb2YgaWRlbnRpdHktaWRlbnRpZmllciBzcGxpdCBh bmQgZHluYW1pYw0KDQo+IGlkZW50aWZpZXIgY2hhbmdlcywgaW5jbHVkaW5nIHRoZWlyIGltcGxp Y2F0aW9ucyBvbiBhbm9ueW1pdHkgYW5kIHByaXZhY3kuDQoNCj4gRXhwbGljaXRseSwgdGhlIGZy YW1ld29yayBtdXN0IGRlZmluZSBwcml2YWN5IHJlcXVpcmVtZW50cyBhbmQgaG93IHBvdGVudGlh bA0KDQo+IGV4dGVuc2lvbnMvc29sdXRpb25zIHNob3VsZCBtZWV0IHRoZW0uDQoNCg0KDQpUaGlz IGlzIGEgZ29vZCBzdGFydCwgYnV0IHRoZSB3aG9sZSBjb25jZXB0IG9mICJ1bmlxdWUgaWRlbnRp ZmllcnMiIGlzDQoNCnNjYXJ5LCBhbmQgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIGV4cGFuZGVk LiBGb3IgZXhhbXBsZSwgSSB3b3VsZCBsaWtlDQoNCnRvIHNlZSBhbiBleHBsaWNpdCByZWZlcmVu Y2UgdG8gYSBiYXNlbGluZSwgZS5nLiBhc3N1cmluZyBubyBwcml2YWN5DQoNCmRvd25ncmFkZSBj b21wYXJlZCB0byBJUHY2IHRlbXBvcmFyeSBhZGRyZXNzZXMsIG9yIGFzc3VyaW5nIHRoYXQgaG9z dHMNCg0KdGhhdCBlbGVjdCB0byBub3QgYmUgdHJhY2tlZCB3aGVuIHJvYW1pbmcgYWNyb3NzIG5l dHdvcmtzIHdpbGwgbm90IGJlLiBJDQoNCmFsc28ga25vdyB0aGF0IHRoZXJlIGhhdmUgYmVlbiBk aXNjdXNzaW9ucyBvZiBoaWRpbmcgaWRlbnRpZmllcnMgZnJvbQ0KDQppbnRlcm1lZGlhcmllcywg YW5kIGkgd291bGQgbGlrZSB0byBzZWUgdGhhdCBhcyBhbiBleHBsaWNpdCBnb2FsIG9mIHRoZQ0K DQpwcm9wb3NlZCBXRy4NCg0KDQoNCi0tDQoNCkNocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQoNCg== --_000_45e8993a73ef4bb9b3914f32c4609823XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQ2hyaXN0aWFuLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIGFwcGxpY2F0aW9u cyBsaWtlIGNpdmlsIGF2aWF0aW9uIEFpciBUcmFmZmljIE1hbmFnZW1lbnQgKEFUTSksIHdlIGhh dmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+YSBjYXNlIHdoZXJlIGl0IGlzIGRlc2lyYWJsZSBmb3IgQWly IFRyYWZmaWMgQ29udHJvbCAoQVRDKSB0byBiZSBhYmxlIHRvIHRyYWNrPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPnRoZSBtb2JpbGUgbm9kZXMgKGFpcnBsYW5lcykuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5XZSB3YW50IGZvciBBVEMgdG8gYmUgYWJsZSB0byB0cmFjayBh aXJwbGFuZXMgd2hlcmV2ZXIgdGhleSBoYXBwZW4gdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YmUgd29y bGR3aWRlIGFuZCBjb25uZWN0ZWQgb3ZlciB3aGF0ZXZlciBhdmFpbGFibGUgZGF0YSBsaW5rcyAo c2F0ZWxsaXRlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jZWxsdWxhciwgV2lNQVgsIFZIRiwgZXRjLiku IFRoZSBtb2JpbGUgbm9kZXMgYWxzbyBiZW5lZml0IGZyb20gYmVpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Z2xvYmFsbHkgYWRkcmVzc2FibGUgYXQgYWxsIHRpbWVzLCBzaW5jZSB0aGV5IGFyZSB3aWxs aW5nIHBhcnRpY2lwYW50cyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Z2xvYmFsIEFUTSBzZXJ2 aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28sIHdlIHNl ZSBJRC9Mb2MgYXJjaGl0ZWN0dXJlcyBhcyBhIHVzZWZ1bCB0b29sIGZvciBzdXBwb3J0aW5nIHRo aXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+c2FmZXR5LW9mLWZsaWdodCBjcml0aWNhbCBBVE0gc2Vydmlj ZS4gU2hvdWxkIGl0IGJlIG5vdGVkIHRoYXQgdGhlcmUgYXJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnVz ZSBjYXNlcyB3aGVyZSBtb2JpbGUgbm9kZSB0cmFja2luZyBpcyBpbmRlZWQgZGVzaXJhYmxlPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBJZGVhcyBbbWFpbHRv OmlkZWFzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGlhbiBI dWl0ZW1hPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAwMiwgMjAxNyA4OjU2IEFN PGJyPg0KPGI+VG86PC9iPiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGlkZWFzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJZGVhc10gRndkOiBGd2Q6IFJlOiBXRyBSZXZp ZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFzKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPkkganVzdCByZWFsaXplZCB0aGF0IEkgZm9yZ2V0IHRvIGNvcHkgdGhpcyBtZXNz YWdlIHRvIHRoZSBJRVNHIGFuZCBJREVBUyBtYWlsaW5nIGxpc3RzLiBTb3JyeS48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLS0tLSBGb3J3YXJk ZWQgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBp biAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5TdWJqZWN0OiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Gd2Q6IFJlOiBXRyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFz KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPG86 cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VuLCAxIE9jdCAyMDE3IDE3OjA2OjQ2IC0wNzAw PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpw PjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaHJpc3RpYW4gSHVpdGVtYSA8YSBocmVmPSJtYWls dG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+Jmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+VG86IDxvOnA+PC9v OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklFVEYgRGlzY3Vzc2lvbiBNYWlsaW5nIExpc3QgPGEgaHJl Zj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPg0KJmx0O2lldGZAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cHJlPk9uIDkvMjkvMjAxNyA5OjEzIEFNLCBUaGUgSUVTRyB3cm90ZTo8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IEEgbmV3IElF VEYgV0cgaGFzIGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJvdXRpbmcgQXJlYS4gVGhlIElFU0cgaGFz IG5vdCBtYWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBhbnkgZGV0ZXJtaW5hdGlvbiB5 ZXQuIFRoZSBmb2xsb3dpbmcgZHJhZnQgY2hhcnRlciB3YXMgc3VibWl0dGVkLCBhbmQgaXM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBv c2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlPG86cD48L286cD48L3By ZT4NCjxwcmU+Jmd0OyBJRVNHIG1haWxpbmcgbGlzdCAoPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0 Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+KSBieSAyMDE3LTEwLTA5LjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPi4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT4mZ3Q7IE5ldHdvcmsgc29sdXRpb25zIGJhc2VkIG9uIHRoZSBjb25jZXB0IG9m IElkZW50aWZpZXItTG9jYXRvciBzZXBhcmF0aW9uIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZndDsgaW5jcmVhc2luZ2x5IGNvbnNpZGVyZWQgdG8gc3VwcG9ydCBtb2JpbGl0eSwgb3Zlcmxh eSBuZXR3b3JraW5nIGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgdmlydHVhbGl6YXRp b24gYW5kIG11bHRpLWhvbWluZyBhY3Jvc3MgaGV0ZXJvZ2VuZW91cyBhY2Nlc3MgbmV0d29ya3Mu PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhl IHByb2JsZW0gdGhlcmUgaXMgdGhhdCB0aGUgc2FtZSBwcm9wZXJ0aWVzIHRoYXQgZmFjaWxpdGF0 ZSByb3V0aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+YWxzbyBmYWNpbGl0YXRlIHRyYWNraW5n LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNv bnNpZGVyIGEgbW9iaWxlIG5vZGUgdGhhdCBzd2l0Y2hlcyBmcm9tIGEgV2ktRmkgbmV0d29yayB0 byBhIGNlbGx1bGFyPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0d29yay4gSW4gdGhlIGN1cnJl bnQgc3RhdGUgb2YgdGhlIGFydCwgdGhlcmUgaXMgbm8gcmVsYXRpb24gYmV0d2VlbjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnRoZSBXaS1GaSBhZGRyZXNzIGFuZCB0aGUgY2VsbHVsYXIgYWRkcmVz cy4gSW50ZXJtZWRpYXJpZXMgY2Fubm90PG86cD48L286cD48L3ByZT4NCjxwcmU+b2JzZXJ2ZSB0 aGUgdHJhZmZpYyBhbmQgZGVkdWNlIHRoYXQgdHdvIGRpZmZlcmVudCBmbG93cyBvZiBJUCBwYWNr ZXRzPG86cD48L286cD48L3ByZT4NCjxwcmU+b3JpZ2luYXRlIGZyb20gdGhlIHNhbWUgbm9kZS4g SW4gY29udHJhc3QsIHdpdGggYW4gSUQvTG9jIGFyY2hpdGVjdHVyZSw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT50aGUgdHdvIGZsb3dzIGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgaWRlbnRp Zmllciwgd2hpY2ggY2FuIHRoZW4gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51c2VkIHRvIHRy YWNrIHRoZSBtb3ZlbWVudHMgb2YgdGhlIGRldmljZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5TaW1pbGFybHksIGNvbnNpZGVyIGEgbm9kZSB0 aGF0IGNvbm5lY3RzIHNldmVyYWwgdGltZXMgdG8gdGhlIHNhbWU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5uZXR3b3JrLCBhbmQgZWFjaCB0aW1lIHVzZXMgSVB2NiB0ZW1wb3JhcnkgYWRkcmVzc2Vz LiBUaGUgd2ViIHNlcnZlcnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGF0IGl0IGNvbnRhY3Qg Y2Fubm90IHVzZSB0aGUgSVAgYWRkcmVzc2VzIHRvIGNvcnJlbGF0ZSBkaWZmZXJlbnQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5jb25uZWN0aW9ucyB0aGF0IGhhcHBlbmVkIGF0IGRpZmZlcmVudCB0 aW1lcy4gVGhpcyB3b3VsZCBjaGFuZ2UgaWYgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+aWRl bnRpZmllciBpbiBhbiBJRC9MT0MgYXJjaGl0ZWN0dXJlIHJlbWFpbmVkIGNvbnN0YW50LjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk11bHRpcGF0 aCBUQ1AgYW5kIHBsYW5uZWQgbXVsdGlwYXRoIGV4dGVuc2lvbnMgb2YgUVVJQyBhcmUgZXhhbXBs ZSBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IGFsbG93 IHRyYW5zcG9ydCBjb25uZWN0aW9ucyB0byB1c2UgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5uZXR3b3JrIHBhdGhzIHNpbXVsdGFuZW91c2x5LiBJbiBib3RoIGNhc2VzLCB0aGVyZSBz IHNpZ25pZmljYW50IHdvcms8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5nb2luZyBvbiB0byBlbnN1 cmUgdGhhdCBpbnRlcm1lZGlhcmllcyBjYW5ub3QgZWFzaWx5IGFzc29jaWF0ZSB0aGU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT50cmFmZmljIG9uIHRoZSBtdWx0aXBsZSBwYXRocyB3aXRoIGEgc2lu Z2xlIGNvbm5lY3Rpb24uIElmIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm11bHRpLWhvbWlu ZyBmdW5jdGlvbiB3YXMgZGVsZWdhdGVkIHRvIGFuIElEL0xPQyBzeXN0ZW0sIGludGVybWVkaWFy aWVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Y291bGQgcG90ZW50aWFsbHkgb2JzZXJ2ZSB0aGUg aWRlbnRpZmllcnMgYW5kIGFzc29jaWF0ZSB0aGVzZSBjb25uZWN0aW9ucy48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBzaG9ydCwgY2FyZWxl c3MgYXBwbGljYXRpb25zIG9mIHRoZSBJRC9MT0MgYXJjaGl0ZWN0dXJlIGNvdWxkIGVhc2lseTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlc3VsdCBpbiBzZXJpb3VzIHByaXZhY3kgaXNzdWVzLiBU aGUgcHJvcG9zZWQgY2hhcnRlciBkb2VzIGluY2x1ZGUgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmJyaWVmIHN0YXRlbWVudCBhYm91dCBwcml2YWN5OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgLSBBbmFseXNpcyBvZiB0aGUgY29uY2Vw dHMgb2YgaWRlbnRpdHktaWRlbnRpZmllciBzcGxpdCBhbmQgZHluYW1pYzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZndDsgaWRlbnRpZmllciBjaGFuZ2VzLCBpbmNsdWRpbmcgdGhlaXIgaW1wbGlj YXRpb25zIG9uIGFub255bWl0eSBhbmQgcHJpdmFjeS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m Z3Q7IEV4cGxpY2l0bHksIHRoZSBmcmFtZXdvcmsgbXVzdCBkZWZpbmUgcHJpdmFjeSByZXF1aXJl bWVudHMgYW5kIGhvdyBwb3RlbnRpYWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IGV4dGVu c2lvbnMvc29sdXRpb25zIHNob3VsZCBtZWV0IHRoZW0uPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBpcyBhIGdvb2Qgc3RhcnQsIGJ1dCB0 aGUgd2hvbGUgY29uY2VwdCBvZiAmcXVvdDt1bmlxdWUgaWRlbnRpZmllcnMmcXVvdDsgaXM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5zY2FyeSwgYW5kIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBl eHBhbmRlZC4gRm9yIGV4YW1wbGUsIEkgd291bGQgbGlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PnRvIHNlZSBhbiBleHBsaWNpdCByZWZlcmVuY2UgdG8gYSBiYXNlbGluZSwgZS5nLiBhc3N1cmlu ZyBubyBwcml2YWN5PG86cD48L286cD48L3ByZT4NCjxwcmU+ZG93bmdyYWRlIGNvbXBhcmVkIHRv IElQdjYgdGVtcG9yYXJ5IGFkZHJlc3Nlcywgb3IgYXNzdXJpbmcgdGhhdCBob3N0czxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnRoYXQgZWxlY3QgdG8gbm90IGJlIHRyYWNrZWQgd2hlbiByb2FtaW5n IGFjcm9zcyBuZXR3b3JrcyB3aWxsIG5vdCBiZS4gSTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFs c28ga25vdyB0aGF0IHRoZXJlIGhhdmUgYmVlbiBkaXNjdXNzaW9ucyBvZiBoaWRpbmcgaWRlbnRp ZmllcnMgZnJvbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmludGVybWVkaWFyaWVzLCBhbmQgaSB3 b3VsZCBsaWtlIHRvIHNlZSB0aGF0IGFzIGFuIGV4cGxpY2l0IGdvYWwgb2YgdGhlPG86cD48L286 cD48L3ByZT4NCjxwcmU+cHJvcG9zZWQgV0cuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hyaXN0 aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_45e8993a73ef4bb9b3914f32c4609823XCH150608nwnosboeingcom_-- From nobody Mon Oct 2 09:23:56 2017 Return-Path: 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 D22301326FE; Mon, 2 Oct 2017 09:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 X1gBrKpINJ7d; Mon, 2 Oct 2017 09:23:48 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 4D6FE13234B; Mon, 2 Oct 2017 09:23:48 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id y29so3137705pff.0; Mon, 02 Oct 2017 09:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V/Y+w1aHVKP8ZGf1mc6A4Q1FboUk9Rj/vKA4JLckq4k=; b=kVs2FQ7o+WMoBMlNF2AfcZnGJ0zhTLSK/PnJOksxHX8hA1UNQZj/zSBHyglT9sG/X0 90w2mdsugC0YtSNNMHBQNcQrgqPeeUZ6IlzZvNoc3C1eLWMe1s6s52B2oG5/5UzAzQBL 7VkoKJmDXkCtw7TqQ0WQ4QJt9T4IJzjHNTLUlpImGFT3fGN1oyZhl9+8VbzfDMa/E60u 5E/Zvi1XHSbB6XSIPUcEbVjlwuhW45GP2BxPAfA1jFc88Oe4BN3iuoq6nXgvERJKOyQ2 bKPLGROjpUyzyhuzDyWjPGthl863WUnO7hJRpf7BlCN0vBAsjdZ2YgXq6meGFP2GYi4D HB4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V/Y+w1aHVKP8ZGf1mc6A4Q1FboUk9Rj/vKA4JLckq4k=; b=jI6r8BtanFhqglMew1sh5Q4KyfE7r1Ni1vMNNGBB0sIvC8NJYKRCtXSJCxOEHZulL1 QmOfaYE+/Z3OBFKOwFtev5/Tttiarzz8VhAGJ02xKs0UHu90PaL5WhdX2P3fYjdlEv8W ps8HTYKT4t+izpykx1G3ykAA8Uuzpt+mT9dCINVgOZmSkvUlDlKMxsauZ1oEOq2u7X8Z oJdoCymNIVdU+RtFyalQ675EM3kJft8+yputcycNbVxze5neDS2d60rSwaWVeuktXkEa 09MisF6Gn+JbmtZlAe4LTLxoeMj75M7KruJyYZpDbY+36tdjwsaZ1icTCOCWxm6QK9CT dUAw== X-Gm-Message-State: AHPjjUikmqEeuwwqF4KzjGgqhBsTgBpZpcfFBd55xvD446H9pUCGuAoq lSfPMpu1sSmfmcBbmk18x2c= X-Google-Smtp-Source: AOwi7QA3hIQBhypG4iXQxNKwmVb9TyU5VFOVXQZx9otisdjft85O3lS6YVvQsluR0HH5KkmCbFLoHQ== X-Received: by 10.159.218.75 with SMTP id x11mr14249052plv.92.1506961427671; Mon, 02 Oct 2017 09:23:47 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id z8sm17523411pgs.41.2017.10.02.09.23.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 09:23:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dino Farinacci In-Reply-To: <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> Date: Mon, 2 Oct 2017 09:23:54 -0700 Cc: Christian Huitema , The IESG , "ideas@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:23:50 -0000 > 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? Note Christian, in LISP you can have ephemeral and crypto EIDs. See = draft-ietf-lisp-eid-anonymity-00 and draft-farinacci-lisp-ecdsa-auth-00, = respectively, for details. Dino From nobody Mon Oct 2 09:24:16 2017 Return-Path: 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 ; 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 ; 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 ; Mon, 2 Oct 2017 09:24:07 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o187so3503338qke.7 for ; 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: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> From: Tom Herbert Date: Mon, 2 Oct 2017 09:24:05 -0700 Message-ID: To: Christian Huitema Cc: The IESG , ideas@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0727dab49011055a92cd78" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:24:12 -0000 --94eb2c0727dab49011055a92cd78 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 2, 2017 at 8:55 AM, Christian Huitema 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 > To: IETF Discussion Mailing List > > 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 > > --94eb2c0727dab49011055a92cd78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 2, 2017 at 8:55 AM, Christian Huitema <= ;huitema@huitema.n= et> wrote:
=20 =20 =20

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 <h= uitema@huitema.net>
To: IETF Discussion Mailing List = <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<=
/span>) by 2017-10-09.
...
>
> Network solutions based on the concept of Identifier-Locator separatio=
n 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 iden= tifiers 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 a= chieve the exact same effect of IPv6 temporary addresses (from the applicat= ion point of view the mechanism is identical). There should be no systemati= c means within the network to correlate that two packets with different sou= rce addresses are from the same node.=C2=A0

There = is one caveat, not so much specific to ID/LOC, but how host IPv6 address as= signed is being done. It is common to assign a /64 IPv6 address to UE. A st= ated 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 thi= s that address obfuscation for device tracking is only effective in the upp= er 64 bits which means the available address space for untrackable device a= ddresses is much smaller. I believe that the upshot is that more bits shoul= d be assigned to device prefix to achieve security. This was discussed in 6= man 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 priv= acy. > Explicitly, the framework must define privacy requirements and how pot= ential > extensions/solutions should meet them. This is a good start, but the whole concept of "unique identifiers&quo= t; 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. --=20 Christian Huitema

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


--94eb2c0727dab49011055a92cd78-- From nobody Mon Oct 2 09:27:37 2017 Return-Path: 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 ; 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 ; 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 ; Mon, 2 Oct 2017 09:27:33 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id u67so5764039qkg.6 for ; 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: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> From: Tom Herbert Date: Mon, 2 Oct 2017 09:27:32 -0700 Message-ID: To: "Templin, Fred L" Cc: Christian Huitema , The IESG , "ideas@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05d9980417e2055a92da2b" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:27:36 -0000 --94eb2c05d9980417e2055a92da2b Content-Type: text/plain; charset="UTF-8" On Mon, Oct 2, 2017 at 9:18 AM, Templin, Fred L 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 ; 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 > > *To: * > > IETF Discussion Mailing List > > > > 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 > > --94eb2c05d9980417e2055a92da2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 2, 2017 at 9:18 AM, Templin, Fred L <<= a href=3D"mailto:Fred.L.Templin@boeing.com" target=3D"_blank">Fred.L.Templi= n@boeing.com> wrote:

Hi Christian,

=C2=A0

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

=C2=A0

We want for ATC to be able to track a= irplanes wherever they happen to

be worldwide and connected over whate= ver available data links (satellite,

cellular, WiMAX, VHF, etc.). The mobi= le nodes also benefit from being

globally addressable at all times, si= nce they are willing participants in the

global ATM service.

=C2=A0

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?

=C2=A0

<= /blockquote>
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 aviati= on...

Tom

Thanks - Fred

=C2=A0

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)

=C2=A0

I just realized that I forget to copy this message to the IESG and IDEAS= mailing lists. Sorry.


-------- Forwarded Message --------

Subjec= t:

Fwd: Re: WG Review: IDentity Enabled Networks (ideas= )

Date: =

Sun, 1 Oct 2017 17:06:46 -0700

From: =

Christian Huitema <huitema@huitema.net>

To:

IETF Discussion Mailing List <ietf@ietf.org>

=C2=A0<= /p> 

On 9/29/2017 9:13 AM, The IESG wrote:
=C2=A0
> 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 commen=
ts to the
> IESG mailing list (iesg@ietf.org) by 2017-10-09.
...
>=C2=A0
> Network solutions based on the concept of Identifier-Locator sepa=
ration are
> increasingly considered to support mobility, overlay networking f=
or
> virtualization and multi-homing across heterogeneous access netwo=
rks.
=C2=A0
The problem there is that the same properties that facilitate routing<=
u>
also facilitate tracking.
=C2=A0
Consider a mobile node that switches from a Wi-Fi network to a cellula=
r
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<=
u>
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.
=C2=A0
Similarly, consider a node that connects several times to the same<=
/u>
network, and each time uses IPv6 temporary addresses. The web servers<=
u>
that it contact cannot use the IP addresses to correlate different<=
/u>
connections that happened at different times. This would change if the=

identifier in an ID/LOC architecture remained constant.<=
/pre>

=C2=A0


Multipath TCP and planned multipath extensions of QUIC are example of<=
u>


transport protocol that allow transport connections to use multiple=



network paths simultaneously. In both cases, there s significant work<=
u>


going on to ensure that intermediaries cannot easily associate the<=
/u>


traffic on the multiple paths with a single connection. If the<=
u>


multi-homing function was delegated to an ID/LOC system, intermediarie=
s


could potentially observe the identifiers and associate these connecti=
ons.


=C2=A0


In short, careless applications of the ID/LOC architecture could easil=
y


result in serious privacy issues. The proposed charter does include a<=
u>


brief statement about privacy:


=C2=A0


> - Analysis of the concepts of identity-identifier split and dynam=
ic


> identifier changes, including their implications on anonymity and=
 privacy.


> Explicitly, the framework must define privacy requirements and ho=
w potential


> extensions/solutions should meet them.


=C2=A0


This is a good start, but the whole concept of "unique identifier=
s" is


scary, and I would like to see this expanded. For example, I would lik=
e


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<=
u>


intermediaries, and i would like to see that as an explicit goal of th=
e


proposed WG.


=C2=A0


-- 


Christian Huitema


=C2=A0


=C2=A0

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


--94eb2c05d9980417e2055a92da2b-- From nobody Mon Oct 2 09:30:52 2017 Return-Path: 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 551D91344C6; Mon, 2 Oct 2017 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dkmkXT8oljkB; Mon, 2 Oct 2017 09:30:44 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F20113234B; Mon, 2 Oct 2017 09:30:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v92GUhFf041659; Mon, 2 Oct 2017 09:30:44 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v92GUeuT041615 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 2 Oct 2017 09:30:40 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Oct 2017 09:30:40 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 2 Oct 2017 09:30:40 -0700 From: "Templin, Fred L" To: Tom Herbert CC: Christian Huitema , The IESG , "ideas@ietf.org" Thread-Topic: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTO5b1XXR8U7Y2UkCpxQHITCbUoqLQumHAgAB6ewD//4r3YA== Date: Mon, 2 Oct 2017 16:30:40 +0000 Message-ID: <3a9cf74ba67d4222b1c543d8bfccfe20@XCH15-06-08.nw.nos.boeing.com> References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_3a9cf74ba67d4222b1c543d8bfccfe20XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:30:46 -0000 --_000_3a9cf74ba67d4222b1c543d8bfccfe20XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tLA0KDQo+SWYgdGhlIGdvb2QgZ3V5cyBhcmUgYWJsZSB0byB0cmFjayBtb2JpbGUgZGV2 aWNlcyBiYXNlZCBvbiBwbGFpbiB0ZXh0IGFkZHJlc3MsIGRvZXNuJ3QgdGhhdA0KPiBtZWFuIHRo ZSBiYWQgZ3V5cyB3aWxsIGJlIGFibGUgdG8gZG8gdGhhdCBhbHNvPyBTZWVtcyBhIGxpdHRsZSBi aXQgc2NhcnkgcHJvc3BlY3QgdG8gbWUgaW4NCj4gdGhlIGNvbnRleHQgb2YgYXZpYXRpb24uLi4N Cg0KVGhlcmUgYXJlIG5vIGJhZCBndXlzIGluIHRoaXMgbmV0d29yay4gVGhlIHVuZGVybGF5IG5l dHdvcmsgaXMgc2VjdXJlZCBhZ2FpbnN0DQp1bmF1dGhvcml6ZWQgYWNjZXNzLg0KDQpUaGFua3Mg LSBGcmVkDQoNCg0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29t XQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAyLCAyMDE3IDk6MjggQU0NClRvOiBUZW1wbGluLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogQ2hyaXN0aWFuIEh1aXRlbWEg PGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGlkZWFzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW0lkZWFzXSBGd2Q6IEZ3ZDogUmU6IFdHIFJldmlldzogSURl bnRpdHkgRW5hYmxlZCBOZXR3b3JrcyAoaWRlYXMpDQoNCg0KDQpPbiBNb24sIE9jdCAyLCAyMDE3 IGF0IDk6MTggQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxt YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGkgQ2hyaXN0aWFuLA0K DQpGb3IgYXBwbGljYXRpb25zIGxpa2UgY2l2aWwgYXZpYXRpb24gQWlyIFRyYWZmaWMgTWFuYWdl bWVudCAoQVRNKSwgd2UgaGF2ZQ0KYSBjYXNlIHdoZXJlIGl0IGlzIGRlc2lyYWJsZSBmb3IgQWly IFRyYWZmaWMgQ29udHJvbCAoQVRDKSB0byBiZSBhYmxlIHRvIHRyYWNrDQp0aGUgbW9iaWxlIG5v ZGVzIChhaXJwbGFuZXMpLg0KDQpXZSB3YW50IGZvciBBVEMgdG8gYmUgYWJsZSB0byB0cmFjayBh aXJwbGFuZXMgd2hlcmV2ZXIgdGhleSBoYXBwZW4gdG8NCmJlIHdvcmxkd2lkZSBhbmQgY29ubmVj dGVkIG92ZXIgd2hhdGV2ZXIgYXZhaWxhYmxlIGRhdGEgbGlua3MgKHNhdGVsbGl0ZSwNCmNlbGx1 bGFyLCBXaU1BWCwgVkhGLCBldGMuKS4gVGhlIG1vYmlsZSBub2RlcyBhbHNvIGJlbmVmaXQgZnJv bSBiZWluZw0KZ2xvYmFsbHkgYWRkcmVzc2FibGUgYXQgYWxsIHRpbWVzLCBzaW5jZSB0aGV5IGFy ZSB3aWxsaW5nIHBhcnRpY2lwYW50cyBpbiB0aGUNCmdsb2JhbCBBVE0gc2VydmljZS4NCg0KU28s IHdlIHNlZSBJRC9Mb2MgYXJjaGl0ZWN0dXJlcyBhcyBhIHVzZWZ1bCB0b29sIGZvciBzdXBwb3J0 aW5nIHRoaXMNCnNhZmV0eS1vZi1mbGlnaHQgY3JpdGljYWwgQVRNIHNlcnZpY2UuIFNob3VsZCBp dCBiZSBub3RlZCB0aGF0IHRoZXJlIGFyZQ0KdXNlIGNhc2VzIHdoZXJlIG1vYmlsZSBub2RlIHRy YWNraW5nIGlzIGluZGVlZCBkZXNpcmFibGU/DQoNCklmIHRoZSBnb29kIGd1eXMgYXJlIGFibGUg dG8gdHJhY2sgbW9iaWxlIGRldmljZXMgYmFzZWQgb24gcGxhaW4gdGV4dCBhZGRyZXNzLCBkb2Vz bid0IHRoYXQgbWVhbiB0aGUgYmFkIGd1eXMgd2lsbCBiZSBhYmxlIHRvIGRvIHRoYXQgYWxzbz8g U2VlbXMgYSBsaXR0bGUgYml0IHNjYXJ5IHByb3NwZWN0IHRvIG1lIGluIHRoZSBjb250ZXh0IG9m IGF2aWF0aW9uLi4uDQoNClRvbQ0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IElkZWFzIFttYWls dG86aWRlYXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRlYXMtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAy LCAyMDE3IDg6NTYgQU0NClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0Bp ZXRmLm9yZz4+OyBpZGVhc0BpZXRmLm9yZzxtYWlsdG86aWRlYXNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbSWRlYXNdIEZ3ZDogRndkOiBSZTogV0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5ldHdv cmtzIChpZGVhcykNCg0KDQpJIGp1c3QgcmVhbGl6ZWQgdGhhdCBJIGZvcmdldCB0byBjb3B5IHRo aXMgbWVzc2FnZSB0byB0aGUgSUVTRyBhbmQgSURFQVMgbWFpbGluZyBsaXN0cy4gU29ycnkuDQoN Ci0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpGd2Q6IFJl OiBXRyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFzKQ0KDQpEYXRlOg0K DQpTdW4sIDEgT2N0IDIwMTcgMTc6MDY6NDYgLTA3MDANCg0KRnJvbToNCg0KQ2hyaXN0aWFuIEh1 aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pg0K DQpUbzoNCg0KSUVURiBEaXNjdXNzaW9uIE1haWxpbmcgTGlzdCA8aWV0ZkBpZXRmLm9yZz48bWFp bHRvOmlldGZAaWV0Zi5vcmc+DQoNCg0KDQpPbiA5LzI5LzIwMTcgOToxMyBBTSwgVGhlIElFU0cg d3JvdGU6DQoNCg0KDQo+IEEgbmV3IElFVEYgV0cgaGFzIGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJv dXRpbmcgQXJlYS4gVGhlIElFU0cgaGFzIG5vdCBtYWRlDQoNCj4gYW55IGRldGVybWluYXRpb24g eWV0LiBUaGUgZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5kIGlzDQoN Cj4gcHJvdmlkZWQgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25seS4gUGxlYXNlIHNlbmQg eW91ciBjb21tZW50cyB0byB0aGUNCg0KPiBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9y ZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4pIGJ5IDIwMTctMTAtMDkuDQoNCi4uLg0KDQo+DQoNCj4g TmV0d29yayBzb2x1dGlvbnMgYmFzZWQgb24gdGhlIGNvbmNlcHQgb2YgSWRlbnRpZmllci1Mb2Nh dG9yIHNlcGFyYXRpb24gYXJlDQoNCj4gaW5jcmVhc2luZ2x5IGNvbnNpZGVyZWQgdG8gc3VwcG9y dCBtb2JpbGl0eSwgb3ZlcmxheSBuZXR3b3JraW5nIGZvcg0KDQo+IHZpcnR1YWxpemF0aW9uIGFu ZCBtdWx0aS1ob21pbmcgYWNyb3NzIGhldGVyb2dlbmVvdXMgYWNjZXNzIG5ldHdvcmtzLg0KDQoN Cg0KVGhlIHByb2JsZW0gdGhlcmUgaXMgdGhhdCB0aGUgc2FtZSBwcm9wZXJ0aWVzIHRoYXQgZmFj aWxpdGF0ZSByb3V0aW5nDQoNCmFsc28gZmFjaWxpdGF0ZSB0cmFja2luZy4NCg0KDQoNCkNvbnNp ZGVyIGEgbW9iaWxlIG5vZGUgdGhhdCBzd2l0Y2hlcyBmcm9tIGEgV2ktRmkgbmV0d29yayB0byBh IGNlbGx1bGFyDQoNCm5ldHdvcmsuIEluIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBhcnQsIHRo ZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4NCg0KdGhlIFdpLUZpIGFkZHJlc3MgYW5kIHRoZSBj ZWxsdWxhciBhZGRyZXNzLiBJbnRlcm1lZGlhcmllcyBjYW5ub3QNCg0Kb2JzZXJ2ZSB0aGUgdHJh ZmZpYyBhbmQgZGVkdWNlIHRoYXQgdHdvIGRpZmZlcmVudCBmbG93cyBvZiBJUCBwYWNrZXRzDQoN Cm9yaWdpbmF0ZSBmcm9tIHRoZSBzYW1lIG5vZGUuIEluIGNvbnRyYXN0LCB3aXRoIGFuIElEL0xv YyBhcmNoaXRlY3R1cmUsDQoNCnRoZSB0d28gZmxvd3MgYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUg c2FtZSBpZGVudGlmaWVyLCB3aGljaCBjYW4gdGhlbiBiZQ0KDQp1c2VkIHRvIHRyYWNrIHRoZSBt b3ZlbWVudHMgb2YgdGhlIGRldmljZS4NCg0KDQoNClNpbWlsYXJseSwgY29uc2lkZXIgYSBub2Rl IHRoYXQgY29ubmVjdHMgc2V2ZXJhbCB0aW1lcyB0byB0aGUgc2FtZQ0KDQpuZXR3b3JrLCBhbmQg ZWFjaCB0aW1lIHVzZXMgSVB2NiB0ZW1wb3JhcnkgYWRkcmVzc2VzLiBUaGUgd2ViIHNlcnZlcnMN Cg0KdGhhdCBpdCBjb250YWN0IGNhbm5vdCB1c2UgdGhlIElQIGFkZHJlc3NlcyB0byBjb3JyZWxh dGUgZGlmZmVyZW50DQoNCmNvbm5lY3Rpb25zIHRoYXQgaGFwcGVuZWQgYXQgZGlmZmVyZW50IHRp bWVzLiBUaGlzIHdvdWxkIGNoYW5nZSBpZiB0aGUNCg0KaWRlbnRpZmllciBpbiBhbiBJRC9MT0Mg YXJjaGl0ZWN0dXJlIHJlbWFpbmVkIGNvbnN0YW50Lg0KDQoNCg0KTXVsdGlwYXRoIFRDUCBhbmQg cGxhbm5lZCBtdWx0aXBhdGggZXh0ZW5zaW9ucyBvZiBRVUlDIGFyZSBleGFtcGxlIG9mDQoNCnRy YW5zcG9ydCBwcm90b2NvbCB0aGF0IGFsbG93IHRyYW5zcG9ydCBjb25uZWN0aW9ucyB0byB1c2Ug bXVsdGlwbGUNCg0KbmV0d29yayBwYXRocyBzaW11bHRhbmVvdXNseS4gSW4gYm90aCBjYXNlcywg dGhlcmUgcyBzaWduaWZpY2FudCB3b3JrDQoNCmdvaW5nIG9uIHRvIGVuc3VyZSB0aGF0IGludGVy bWVkaWFyaWVzIGNhbm5vdCBlYXNpbHkgYXNzb2NpYXRlIHRoZQ0KDQp0cmFmZmljIG9uIHRoZSBt dWx0aXBsZSBwYXRocyB3aXRoIGEgc2luZ2xlIGNvbm5lY3Rpb24uIElmIHRoZQ0KDQptdWx0aS1o b21pbmcgZnVuY3Rpb24gd2FzIGRlbGVnYXRlZCB0byBhbiBJRC9MT0Mgc3lzdGVtLCBpbnRlcm1l ZGlhcmllcw0KDQpjb3VsZCBwb3RlbnRpYWxseSBvYnNlcnZlIHRoZSBpZGVudGlmaWVycyBhbmQg YXNzb2NpYXRlIHRoZXNlIGNvbm5lY3Rpb25zLg0KDQoNCg0KSW4gc2hvcnQsIGNhcmVsZXNzIGFw cGxpY2F0aW9ucyBvZiB0aGUgSUQvTE9DIGFyY2hpdGVjdHVyZSBjb3VsZCBlYXNpbHkNCg0KcmVz dWx0IGluIHNlcmlvdXMgcHJpdmFjeSBpc3N1ZXMuIFRoZSBwcm9wb3NlZCBjaGFydGVyIGRvZXMg aW5jbHVkZSBhDQoNCmJyaWVmIHN0YXRlbWVudCBhYm91dCBwcml2YWN5Og0KDQoNCg0KPiAtIEFu YWx5c2lzIG9mIHRoZSBjb25jZXB0cyBvZiBpZGVudGl0eS1pZGVudGlmaWVyIHNwbGl0IGFuZCBk eW5hbWljDQoNCj4gaWRlbnRpZmllciBjaGFuZ2VzLCBpbmNsdWRpbmcgdGhlaXIgaW1wbGljYXRp b25zIG9uIGFub255bWl0eSBhbmQgcHJpdmFjeS4NCg0KPiBFeHBsaWNpdGx5LCB0aGUgZnJhbWV3 b3JrIG11c3QgZGVmaW5lIHByaXZhY3kgcmVxdWlyZW1lbnRzIGFuZCBob3cgcG90ZW50aWFsDQoN Cj4gZXh0ZW5zaW9ucy9zb2x1dGlvbnMgc2hvdWxkIG1lZXQgdGhlbS4NCg0KDQoNClRoaXMgaXMg YSBnb29kIHN0YXJ0LCBidXQgdGhlIHdob2xlIGNvbmNlcHQgb2YgInVuaXF1ZSBpZGVudGlmaWVy cyIgaXMNCg0Kc2NhcnksIGFuZCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgZXhwYW5kZWQuIEZv ciBleGFtcGxlLCBJIHdvdWxkIGxpa2UNCg0KdG8gc2VlIGFuIGV4cGxpY2l0IHJlZmVyZW5jZSB0 byBhIGJhc2VsaW5lLCBlLmcuIGFzc3VyaW5nIG5vIHByaXZhY3kNCg0KZG93bmdyYWRlIGNvbXBh cmVkIHRvIElQdjYgdGVtcG9yYXJ5IGFkZHJlc3Nlcywgb3IgYXNzdXJpbmcgdGhhdCBob3N0cw0K DQp0aGF0IGVsZWN0IHRvIG5vdCBiZSB0cmFja2VkIHdoZW4gcm9hbWluZyBhY3Jvc3MgbmV0d29y a3Mgd2lsbCBub3QgYmUuIEkNCg0KYWxzbyBrbm93IHRoYXQgdGhlcmUgaGF2ZSBiZWVuIGRpc2N1 c3Npb25zIG9mIGhpZGluZyBpZGVudGlmaWVycyBmcm9tDQoNCmludGVybWVkaWFyaWVzLCBhbmQg aSB3b3VsZCBsaWtlIHRvIHNlZSB0aGF0IGFzIGFuIGV4cGxpY2l0IGdvYWwgb2YgdGhlDQoNCnBy b3Bvc2VkIFdHLg0KDQoNCg0KLS0NCg0KQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRlYXMgbWFpbGlu ZyBsaXN0DQpJZGVhc0BpZXRmLm9yZzxtYWlsdG86SWRlYXNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkZWFzDQoNCg== --_000_3a9cf74ba67d4222b1c543d8bfccfe20XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcyMjQwMTc0Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjM1MjkxMjA4IC0x MTU4MzYzNjQ4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt c3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUb20sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPklmIHRoZSBnb29kIGd1eXMgYXJl IGFibGUgdG8gdHJhY2sgbW9iaWxlIGRldmljZXMgYmFzZWQgb24gcGxhaW4gdGV4dCBhZGRyZXNz LCBkb2Vzbid0IHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg bWVhbiB0aGUgYmFkIGd1eXMgd2lsbCBiZSBhYmxlIHRvIGRvIHRoYXQgYWxzbz8gU2VlbXMgYSBs aXR0bGUgYml0IHNjYXJ5IHByb3NwZWN0IHRvIG1lIGluPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IHRoZSBjb250ZXh0IG9mIGF2aWF0aW9uLi4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBubyBiYWQgZ3V5cyBpbiB0aGlzIG5ldHdvcmsuIFRoZSB1 bmRlcmxheSBuZXR3b3JrIGlzIHNlY3VyZWQgYWdhaW5zdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dW5hdXRob3JpemVkIGFjY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRvbSBIZXJiZXJ0 IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IE9jdG9iZXIgMDIsIDIwMTcgOToyOCBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBM ICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0 aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVz Z0BpZXRmLm9yZyZndDs7IGlkZWFzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb SWRlYXNdIEZ3ZDogRndkOiBSZTogV0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5ldHdvcmtz IChpZGVhcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9u LCBPY3QgMiwgMjAxNyBhdCA5OjE4IEFNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1h aWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGkgQ2hyaXN0aWFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkZvciBhcHBsaWNhdGlvbnMgbGlrZSBjaXZpbCBhdmlhdGlvbiBB aXIgVHJhZmZpYyBNYW5hZ2VtZW50IChBVE0pLCB3ZSBoYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ YSBjYXNlIHdoZXJlIGl0IGlzIGRlc2lyYWJsZSBmb3IgQWlyIFRyYWZmaWMgQ29udHJvbCAoQVRD KSB0byBiZSBhYmxlIHRvIHRyYWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIG1vYmlsZSBub2Rl cyAoYWlycGxhbmVzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5XZSB3YW50IGZvciBBVEMgdG8gYmUgYWJsZSB0byB0cmFjayBhaXJwbGFuZXMgd2hlcmV2 ZXIgdGhleSBoYXBwZW4gdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5iZSB3b3JsZHdpZGUgYW5kIGNv bm5lY3RlZCBvdmVyIHdoYXRldmVyIGF2YWlsYWJsZSBkYXRhIGxpbmtzIChzYXRlbGxpdGUsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Y2VsbHVsYXIsIFdpTUFYLCBWSEYsIGV0Yy4pLiBUaGUgbW9iaWxl IG5vZGVzIGFsc28gYmVuZWZpdCBmcm9tIGJlaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Z2xvYmFs bHkgYWRkcmVzc2FibGUgYXQgYWxsIHRpbWVzLCBzaW5jZSB0aGV5IGFyZSB3aWxsaW5nIHBhcnRp Y2lwYW50cyBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5nbG9iYWwgQVRNIHNlcnZpY2UuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28sIHdlIHNlZSBJ RC9Mb2MgYXJjaGl0ZWN0dXJlcyBhcyBhIHVzZWZ1bCB0b29sIGZvciBzdXBwb3J0aW5nIHRoaXM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5zYWZldHktb2YtZmxpZ2h0IGNyaXRpY2FsIEFUTSBzZXJ2aWNl LiBTaG91bGQgaXQgYmUgbm90ZWQgdGhhdCB0aGVyZSBhcmU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj51 c2UgY2FzZXMgd2hlcmUgbW9iaWxlIG5vZGUgdHJhY2tpbmcgaXMgaW5kZWVkIGRlc2lyYWJsZT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRo ZSBnb29kIGd1eXMgYXJlIGFibGUgdG8gdHJhY2sgbW9iaWxlIGRldmljZXMgYmFzZWQgb24gcGxh aW4gdGV4dCBhZGRyZXNzLCBkb2Vzbid0IHRoYXQgbWVhbiB0aGUgYmFkIGd1eXMgd2lsbCBiZSBh YmxlIHRvIGRvIHRoYXQgYWxzbz8gU2VlbXMgYSBsaXR0bGUgYml0IHNjYXJ5IHByb3NwZWN0IHRv IG1lIGluIHRoZSBjb250ZXh0IG9mIGF2aWF0aW9uLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g SWRlYXMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWRlYXMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmlkZWFzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5DaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIg MDIsIDIwMTcgODo1NiBBTTxicj4NCjxiPlRvOjwvYj4gVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1h aWx0bzppZXNnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7 Ow0KPGEgaHJlZj0ibWFpbHRvOmlkZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRlYXNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJZGVhc10gRndkOiBGd2Q6IFJlOiBX RyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFzKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5JIGp1c3QgcmVhbGl6ZWQgdGhhdCBJIGZv cmdldCB0byBjb3B5IHRoaXMgbWVzc2FnZSB0byB0aGUgSUVTRyBhbmQgSURFQVMgbWFpbGluZyBs aXN0cy4gU29ycnkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnI+DQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwv cD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9 IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnJpZ2h0Ij4NCjxiPlN1YmplY3Q6IDwvYj48 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RndkOiBSZTogV0cgUmV2aWV3OiBJRGVudGl0eSBF bmFibGVkIE5ldHdvcmtzIChpZGVhcyk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy Pg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmln aHQiPg0KPGI+RGF0ZTogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk ZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdW4sIDEgT2N0 IDIwMTcgMTc6MDY6NDYgLTA3MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0K PHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246cmlnaHQi Pg0KPGI+RnJvbTogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJpc3RpYW4gSHVp dGVtYQ0KPGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiIHRhcmdldD0iX2JsYW5r Ij4mbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBp biAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnJpZ2h0Ij4NCjxiPlRvOiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklF VEYgRGlzY3Vzc2lvbiBNYWlsaW5nIExpc3QNCjxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2lldGZAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cHJlPk9uIDkvMjkvMjAxNyA5OjEzIEFNLCBUaGUgSUVTRyB3 cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mZ3Q7IEEgbmV3IElFVEYgV0cgaGFzIGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJvdXRpbmcgQXJl YS4gVGhlIElFU0cgaGFzIG5vdCBtYWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBhbnkg ZGV0ZXJtaW5hdGlvbiB5ZXQuIFRoZSBmb2xsb3dpbmcgZHJhZnQgY2hhcnRlciB3YXMgc3VibWl0 dGVkLCBhbmQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IHByb3ZpZGVkIGZvciBpbmZv cm1hdGlvbmFsIHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBJRVNHIG1haWxpbmcgbGlzdCAoPGEgaHJlZj0i bWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3JnPC9hPikg YnkgMjAxNy0xMC0wOS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4uLi48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBOZXR3b3JrIHNv bHV0aW9ucyBiYXNlZCBvbiB0aGUgY29uY2VwdCBvZiBJZGVudGlmaWVyLUxvY2F0b3Igc2VwYXJh dGlvbiBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IGluY3JlYXNpbmdseSBjb25zaWRl cmVkIHRvIHN1cHBvcnQgbW9iaWxpdHksIG92ZXJsYXkgbmV0d29ya2luZyBmb3I8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mZ3Q7IHZpcnR1YWxpemF0aW9uIGFuZCBtdWx0aS1ob21pbmcgYWNyb3Nz IGhldGVyb2dlbmVvdXMgYWNjZXNzIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBwcm9ibGVtIHRoZXJlIGlzIHRoYXQgdGhl IHNhbWUgcHJvcGVydGllcyB0aGF0IGZhY2lsaXRhdGUgcm91dGluZzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPmFsc28gZmFjaWxpdGF0ZSB0cmFja2luZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Db25zaWRlciBhIG1vYmlsZSBub2RlIHRoYXQg c3dpdGNoZXMgZnJvbSBhIFdpLUZpIG5ldHdvcmsgdG8gYSBjZWxsdWxhcjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPm5ldHdvcmsuIEluIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBhcnQsIHRoZXJl IGlzIG5vIHJlbGF0aW9uIGJldHdlZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgV2ktRmkg YWRkcmVzcyBhbmQgdGhlIGNlbGx1bGFyIGFkZHJlc3MuIEludGVybWVkaWFyaWVzIGNhbm5vdDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9ic2VydmUgdGhlIHRyYWZmaWMgYW5kIGRlZHVjZSB0aGF0 IHR3byBkaWZmZXJlbnQgZmxvd3Mgb2YgSVAgcGFja2V0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pm9yaWdpbmF0ZSBmcm9tIHRoZSBzYW1lIG5vZGUuIEluIGNvbnRyYXN0LCB3aXRoIGFuIElEL0xv YyBhcmNoaXRlY3R1cmUsPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIHR3byBmbG93cyBhcmUg YXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIGlkZW50aWZpZXIsIHdoaWNoIGNhbiB0aGVuIGJlPG86 cD48L286cD48L3ByZT4NCjxwcmU+dXNlZCB0byB0cmFjayB0aGUgbW92ZW1lbnRzIG9mIHRoZSBk ZXZpY2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+U2ltaWxhcmx5LCBjb25zaWRlciBhIG5vZGUgdGhhdCBjb25uZWN0cyBzZXZlcmFsIHRpbWVz IHRvIHRoZSBzYW1lPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0d29yaywgYW5kIGVhY2ggdGlt ZSB1c2VzIElQdjYgdGVtcG9yYXJ5IGFkZHJlc3Nlcy4gVGhlIHdlYiBzZXJ2ZXJzPG86cD48L286 cD48L3ByZT4NCjxwcmU+dGhhdCBpdCBjb250YWN0IGNhbm5vdCB1c2UgdGhlIElQIGFkZHJlc3Nl cyB0byBjb3JyZWxhdGUgZGlmZmVyZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Y29ubmVjdGlv bnMgdGhhdCBoYXBwZW5lZCBhdCBkaWZmZXJlbnQgdGltZXMuIFRoaXMgd291bGQgY2hhbmdlIGlm IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50aWZpZXIgaW4gYW4gSUQvTE9DIGFyY2hp dGVjdHVyZSByZW1haW5lZCBjb25zdGFudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NdWx0aXBhdGggVENQIGFuZCBwbGFubmVkIG11bHRpcGF0 aCBleHRlbnNpb25zIG9mIFFVSUMgYXJlIGV4YW1wbGUgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT50cmFuc3BvcnQgcHJvdG9jb2wgdGhhdCBhbGxvdyB0cmFuc3BvcnQgY29ubmVjdGlvbnMgdG8g dXNlIG11bHRpcGxlPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0d29yayBwYXRocyBzaW11bHRh bmVvdXNseS4gSW4gYm90aCBjYXNlcywgdGhlcmUgcyBzaWduaWZpY2FudCB3b3JrPG86cD48L286 cD48L3ByZT4NCjxwcmU+Z29pbmcgb24gdG8gZW5zdXJlIHRoYXQgaW50ZXJtZWRpYXJpZXMgY2Fu bm90IGVhc2lseSBhc3NvY2lhdGUgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+dHJhZmZpYyBv biB0aGUgbXVsdGlwbGUgcGF0aHMgd2l0aCBhIHNpbmdsZSBjb25uZWN0aW9uLiBJZiB0aGU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5tdWx0aS1ob21pbmcgZnVuY3Rpb24gd2FzIGRlbGVnYXRlZCB0 byBhbiBJRC9MT0Mgc3lzdGVtLCBpbnRlcm1lZGlhcmllczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmNvdWxkIHBvdGVudGlhbGx5IG9ic2VydmUgdGhlIGlkZW50aWZpZXJzIGFuZCBhc3NvY2lhdGUg dGhlc2UgY29ubmVjdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+SW4gc2hvcnQsIGNhcmVsZXNzIGFwcGxpY2F0aW9ucyBvZiB0aGUgSUQv TE9DIGFyY2hpdGVjdHVyZSBjb3VsZCBlYXNpbHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXN1 bHQgaW4gc2VyaW91cyBwcml2YWN5IGlzc3Vlcy4gVGhlIHByb3Bvc2VkIGNoYXJ0ZXIgZG9lcyBp bmNsdWRlIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5icmllZiBzdGF0ZW1lbnQgYWJvdXQgcHJp dmFjeTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mZ3Q7IC0gQW5hbHlzaXMgb2YgdGhlIGNvbmNlcHRzIG9mIGlkZW50aXR5LWlkZW50aWZpZXIg c3BsaXQgYW5kIGR5bmFtaWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IGlkZW50aWZpZXIg Y2hhbmdlcywgaW5jbHVkaW5nIHRoZWlyIGltcGxpY2F0aW9ucyBvbiBhbm9ueW1pdHkgYW5kIHBy aXZhY3kuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBFeHBsaWNpdGx5LCB0aGUgZnJhbWV3 b3JrIG11c3QgZGVmaW5lIHByaXZhY3kgcmVxdWlyZW1lbnRzIGFuZCBob3cgcG90ZW50aWFsPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBleHRlbnNpb25zL3NvbHV0aW9ucyBzaG91bGQgbWVl dCB0aGVtLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoaXMgaXMgYSBnb29kIHN0YXJ0LCBidXQgdGhlIHdob2xlIGNvbmNlcHQgb2YgJnF1b3Q7 dW5pcXVlIGlkZW50aWZpZXJzJnF1b3Q7IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+c2Nhcnks IGFuZCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgZXhwYW5kZWQuIEZvciBleGFtcGxlLCBJIHdv dWxkIGxpa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50byBzZWUgYW4gZXhwbGljaXQgcmVmZXJl bmNlIHRvIGEgYmFzZWxpbmUsIGUuZy4gYXNzdXJpbmcgbm8gcHJpdmFjeTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmRvd25ncmFkZSBjb21wYXJlZCB0byBJUHY2IHRlbXBvcmFyeSBhZGRyZXNzZXMs IG9yIGFzc3VyaW5nIHRoYXQgaG9zdHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGF0IGVsZWN0 IHRvIG5vdCBiZSB0cmFja2VkIHdoZW4gcm9hbWluZyBhY3Jvc3MgbmV0d29ya3Mgd2lsbCBub3Qg YmUuIEk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbHNvIGtub3cgdGhhdCB0aGVyZSBoYXZlIGJl ZW4gZGlzY3Vzc2lvbnMgb2YgaGlkaW5nIGlkZW50aWZpZXJzIGZyb208bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5pbnRlcm1lZGlhcmllcywgYW5kIGkgd291bGQgbGlrZSB0byBzZWUgdGhhdCBhcyBh biBleHBsaWNpdCBnb2FsIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb3Bvc2VkIFdH LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0t IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNocmlzdGlhbiBIdWl0ZW1hPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZGVhcyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRlYXNAaWV0Zi5vcmciPklkZWFzQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRlYXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkZWFzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3a9cf74ba67d4222b1c543d8bfccfe20XCH150608nwnosboeingcom_-- From nobody Mon Oct 2 09:46:34 2017 Return-Path: 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 DCA67132D41 for ; Mon, 2 Oct 2017 09:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 L9PEL8YZElK8 for ; Mon, 2 Oct 2017 09:46:32 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C717A120720 for ; Mon, 2 Oct 2017 09:46:31 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1dz3rQ-00056G-4S for ideas@ietf.org; Mon, 02 Oct 2017 18:46:29 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dz3r6-0005fB-OO for ideas@ietf.org; Mon, 02 Oct 2017 12:46:27 -0400 Received: (qmail 4397 invoked from network); 2 Oct 2017 16:46:04 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.117]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Oct 2017 16:46:04 -0000 To: Dino Farinacci , "Templin, Fred L" Cc: The IESG , "ideas@ietf.org" References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> From: Christian Huitema Message-ID: Date: Mon, 2 Oct 2017 09:46:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.29) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tC5u20H4jDeqOqKhKMa17wXv9krsgRhBn0ayn6qsUc7p7He3a39gjg/ 9oOEoAajC61PdOWeIW8R8TgUu5HhPnLXsZ/zvZCpyHRns5FgvqdnTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKeAoqWDmtF8nD2nEDT705fpjj0HlFDoqoWF20+xKQ35+nd/nGlMBQ0xDQkm A/S/XlviXj3T4KI9X3Edk1VAD/raxm0eXjh1Edf5/6lW85Glx+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYjmJKJXZ+nOfVIFw1j15M+NioHoPZGa4M+gVoRbXuj edLPh3AwRDSwUY58cvL01UgHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGF8N2IrsxSJSJSZLlKTS85vMibYT4C2qF2lnc18bVJn66J awn+Wnh2kh0k8ZYL6YOznrQCcLg4qwXcikLD+MiFBTwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTxD0lugE85NC8TRxNzgAe9FjI1dRH6f16eQCtvwPkeoy/RHCd+AU+DSNrWD2KXtAdl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:46:33 -0000 On 10/2/2017 9:23 AM, Dino Farinacci wrote: >> 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 a= re >> use cases where mobile node tracking is indeed desirable? > Note Christian, in LISP you can have ephemeral and crypto EIDs. See dra= ft-ietf-lisp-eid-anonymity-00 and draft-farinacci-lisp-ecdsa-auth-00, res= pectively, for details. > Dino, I am well aware that we (well, you) *can* engineer ID/LOC networks to have good privacy properties. But I am also aware that if this is not an explicit goal in the charter, we may very well end up with architectures that have pretty bad properties. For example, most ID/LOC architectures rely on a database that provides the up-to-date LOC for an ID. In my bad dreams, I could see the database extended to provide other properties of the ID, such as subscriber ID. Similarly, there was a proposal some time ago to have a unique IPv6 identifier for every EU citizen; that bad idea was quashed, but we could easily see something like that resurface as on unique ID per user. That's why I would like to see the proposed charter to be crystal clear about privacy requirements, rather than just say that we will think about it. --=20 Christian Huitema From nobody Mon Oct 2 09:49:49 2017 Return-Path: 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 0A54B132396 for ; Mon, 2 Oct 2017 09:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 UinmSDHylStr for ; Mon, 2 Oct 2017 09:49:47 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CC3120720 for ; Mon, 2 Oct 2017 09:49:46 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dz3uI-00026w-Rq for ideas@ietf.org; Mon, 02 Oct 2017 18:49:35 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dz3u2-0003NP-Aj for ideas@ietf.org; Mon, 02 Oct 2017 12:49:10 -0400 Received: (qmail 1740 invoked from network); 2 Oct 2017 16:48:30 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.117]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Oct 2017 16:48:29 -0000 To: "Templin, Fred L" , Tom Herbert Cc: The IESG , "ideas@ietf.org" References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> <3a9cf74ba67d4222b1c543d8bfccfe20@XCH15-06-08.nw.nos.boeing.com> From: Christian Huitema Message-ID: Date: Mon, 2 Oct 2017 09:48:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3a9cf74ba67d4222b1c543d8bfccfe20@XCH15-06-08.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------02DD9E115AC82A4349A1B272" Content-Language: en-US X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nnRH5OCGIekfan419MO3gcXv9krsgRhBn0ayn6qsUc7p7He3a39gjg/ 9oOEoAajC61PdOWeIW8R8TgUu5HhPnLUSYGqqhr6VpiMkB5EEtKpTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKeLTZrohEYNqXHUJBt/zvJojj0HlFDoqoWF20+xKQ35+qr5V2ZbZ4HnGWDW DCGQER28QWdnB3wN1Us5flF/yXto+m6tTHY+01PY0Fa/G3bd5Npo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c3u+aEdm3+zO5teKLXRbOgM+rOrdJaBYvX2Vr0DqPfo IkQ9v4Phn+YN6RP23kGBELrCNsbRg//mN0jF8dSqZiN4x6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5rXFXkQEnTC9rKm30SFEfAwT 3HfqasSOvpJDggeXzOMEFplgxXXijguesMtH2okR9lz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBnVLUE5wQMuDWRk3qAUSk9R3h1vgDbEdmhrg3iVBpdRa29tyIytZRvp0Gut3t97wmGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:49:48 -0000 This is a multi-part message in MIME format. --------------02DD9E115AC82A4349A1B272 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/2/2017 9:30 AM, Templin, Fred L wrote: > >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... > >   > > There are no bad guys in this network. The underlay network is secured > against > > unauthorized access. > Fred, that's the kind of statements that really give me pause. "Let's do something dangerous on my network because it is well isolated and secure." I am pretty sure that the gentle folks at Equifax were thinking along similar lines. -- Christian Huitema --------------02DD9E115AC82A4349A1B272 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/2/2017 9:30 AM, Templin, Fred L wrote:

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

 

There are no bad guys in this network. The underlay network is secured against

unauthorized access.


Fred, that's the kind of statements that really give me pause. "Let's do something dangerous on my network because it is well isolated and secure." I am pretty sure that the gentle folks at Equifax were thinking along similar lines.

-- 
Christian Huitema
--------------02DD9E115AC82A4349A1B272-- From nobody Mon Oct 2 09:55:26 2017 Return-Path: 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 DAE7D132D41; Mon, 2 Oct 2017 09:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 i2FNviIMXLEz; Mon, 2 Oct 2017 09:55:17 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C0212421A; Mon, 2 Oct 2017 09:55:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v92GtBBs020164; Mon, 2 Oct 2017 09:55:12 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v92GtA0q020130 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 2 Oct 2017 09:55:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Oct 2017 09:55:09 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 2 Oct 2017 09:55:10 -0700 From: "Templin, Fred L" To: Christian Huitema , Tom Herbert CC: The IESG , "ideas@ietf.org" Thread-Topic: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTO5b1XXR8U7Y2UkCpxQHITCbUoqLQumHAgAB6ewD//4r3YIAAeuGA//+LOjA= Date: Mon, 2 Oct 2017 16:55:09 +0000 Message-ID: References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> <3a9cf74ba67d4222b1c543d8bfccfe20@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_c849f4452b574931a6010784711a2b26XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:55:20 -0000 --_000_c849f4452b574931a6010784711a2b26XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuLA0KDQo+RnJlZCwgdGhhdCdzIHRoZSBraW5kIG9mIHN0YXRlbWVudHMgdGhh dCByZWFsbHkgZ2l2ZSBtZSBwYXVzZS4gIkxldCdzIGRvIHNvbWV0aGluZyBkYW5nZXJvdXMNCj4g b24gbXkgbmV0d29yayBiZWNhdXNlIGl0IGlzIHdlbGwgaXNvbGF0ZWQgYW5kIHNlY3VyZS4iIEkg YW0gcHJldHR5IHN1cmUgdGhhdCB0aGUgZ2VudGxlIGZvbGtzIGF0DQo+IEVxdWlmYXggd2VyZSB0 aGlua2luZyBhbG9uZyBzaW1pbGFyIGxpbmVzLg0KDQpVbmRlcnN0b29kLCBidXQgZm9yIHRoZSBB ZXJvbmF1dGljYWwgVGVsZWNvbW11bmljYXRpb25zIE5ldHdvcmsgKEFUTikgaXQgcmVhbGx5DQpp cyBzZWN1cmVkIGF0IHRoZSBsb3dlciBsYXllcnMgYW5kIGhhcyB0byBiZSB0aGF0IHdheS4gVGhl cmUgYXJlIG5vIGNvbm5lY3Rpb25zIHRvIHRoZQ0Kb3BlbiBJbnRlcm5ldCwgYW5kIHRoZXJlIGNh biBiZSBubyBvcHBvcnR1bml0eSBmb3Igcm9ndWUgQVRDcyB0byBjb21lIGluIGFuZCBzdGFydA0K Z2l2aW5nIG9yZGVycyB0byBhaXJwbGFuZXMuIFRoaXMgaXMgdHJ1ZSB3aGV0aGVyL25vdCB0aGVy ZSBpcyBhIExvYy9JRCBzcGxpdCBhcmNoaXRlY3R1cmUNCmluIHBsYWNlLg0KDQpUaGFua3MgLSBG cmVkDQoNCkZyb206IENocmlzdGlhbiBIdWl0ZW1hIFttYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5l dF0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMiwgMjAxNyA5OjQ4IEFNDQpUbzogVGVtcGxpbiwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgVG9tIEhlcmJlcnQgPHRvbUBoZXJi ZXJ0bGFuZC5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBpZGVhc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtJZGVhc10gRndkOiBGd2Q6IFJlOiBXRyBSZXZpZXc6IElEZW50aXR5 IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFzKQ0KDQoNCk9uIDEwLzIvMjAxNyA5OjMwIEFNLCBUZW1w bGluLCBGcmVkIEwgd3JvdGU6DQo+SWYgdGhlIGdvb2QgZ3V5cyBhcmUgYWJsZSB0byB0cmFjayBt b2JpbGUgZGV2aWNlcyBiYXNlZCBvbiBwbGFpbiB0ZXh0IGFkZHJlc3MsIGRvZXNuJ3QgdGhhdA0K PiBtZWFuIHRoZSBiYWQgZ3V5cyB3aWxsIGJlIGFibGUgdG8gZG8gdGhhdCBhbHNvPyBTZWVtcyBh IGxpdHRsZSBiaXQgc2NhcnkgcHJvc3BlY3QgdG8gbWUgaW4NCj4gdGhlIGNvbnRleHQgb2YgYXZp YXRpb24uLi4NCg0KVGhlcmUgYXJlIG5vIGJhZCBndXlzIGluIHRoaXMgbmV0d29yay4gVGhlIHVu ZGVybGF5IG5ldHdvcmsgaXMgc2VjdXJlZCBhZ2FpbnN0DQp1bmF1dGhvcml6ZWQgYWNjZXNzLg0K DQpGcmVkLCB0aGF0J3MgdGhlIGtpbmQgb2Ygc3RhdGVtZW50cyB0aGF0IHJlYWxseSBnaXZlIG1l IHBhdXNlLiAiTGV0J3MgZG8gc29tZXRoaW5nIGRhbmdlcm91cyBvbiBteSBuZXR3b3JrIGJlY2F1 c2UgaXQgaXMgd2VsbCBpc29sYXRlZCBhbmQgc2VjdXJlLiIgSSBhbSBwcmV0dHkgc3VyZSB0aGF0 IHRoZSBnZW50bGUgZm9sa3MgYXQgRXF1aWZheCB3ZXJlIHRoaW5raW5nIGFsb25nIHNpbWlsYXIg bGluZXMuDQoNCg0KDQotLQ0KDQpDaHJpc3RpYW4gSHVpdGVtYQ0K --_000_c849f4452b574931a6010784711a2b26XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBDaHJp c3RpYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDtGcmVkLCB0aGF0J3MgdGhlIGtpbmQgb2Ygc3RhdGVtZW50 cyB0aGF0IHJlYWxseSBnaXZlIG1lIHBhdXNlLiAmcXVvdDtMZXQncyBkbyBzb21ldGhpbmcgZGFu Z2Vyb3VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IG9uIG15IG5l dHdvcmsgYmVjYXVzZSBpdCBpcyB3ZWxsIGlzb2xhdGVkIGFuZCBzZWN1cmUuJnF1b3Q7IEkgYW0g cHJldHR5IHN1cmUgdGhhdCB0aGUgZ2VudGxlIGZvbGtzIGF0PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEVxdWlmYXggd2VyZSB0aGlua2luZyBhbG9uZyBzaW1pbGFy IGxpbmVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmRlcnN0b29kLCBidXQgZm9yIHRoZSBB ZXJvbmF1dGljYWwgVGVsZWNvbW11bmljYXRpb25zIE5ldHdvcmsgKEFUTikgaXQgcmVhbGx5PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyBzZWN1cmVkIGF0IHRoZSBsb3dl ciBsYXllcnMgYW5kIGhhcyB0byBiZSB0aGF0IHdheS4gVGhlcmUgYXJlIG5vIGNvbm5lY3Rpb25z IHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3BlbiBJbnRlcm5l dCwgYW5kIHRoZXJlIGNhbiBiZSBubyBvcHBvcnR1bml0eSBmb3Igcm9ndWUgQVRDcyB0byBjb21l IGluIGFuZCBzdGFydDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z2l2aW5n IG9yZGVycyB0byBhaXJwbGFuZXMuIFRoaXMgaXMgdHJ1ZSB3aGV0aGVyL25vdCB0aGVyZSBpcyBh IExvYy9JRCBzcGxpdCBhcmNoaXRlY3R1cmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmluIHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgLSBGcmVkPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQ2hyaXN0aWFuIEh1aXRlbWEgW21h aWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0 b2JlciAwMiwgMjAxNyA5OjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0 O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7OyBUb20gSGVyYmVydCAmbHQ7dG9tQGhlcmJl cnRsYW5kLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3Jn Jmd0OzsgaWRlYXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZGVhc10gRndk OiBGd2Q6IFJlOiBXRyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFzKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPk9uIDEwLzIvMjAxNyA5OjMwIEFNLCBUZW1wbGlu LCBGcmVkIEwgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SWYgdGhlIGdvb2QgZ3V5 cyBhcmUgYWJsZSB0byB0cmFjayBtb2JpbGUgZGV2aWNlcyBiYXNlZCBvbiBwbGFpbiB0ZXh0IGFk ZHJlc3MsIGRvZXNuJ3QgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mZ3Q7IG1lYW4gdGhlIGJhZCBndXlzIHdpbGwgYmUgYWJsZSB0byBkbyB0aGF0IGFsc28/IFNl ZW1zIGEgbGl0dGxlIGJpdCBzY2FyeSBwcm9zcGVjdCB0byBtZSBpbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IHRoZSBjb250ZXh0IG9mIGF2aWF0aW9uLi4uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZSBhcmUgbm8gYmFkIGd1eXMgaW4gdGhpcyBu ZXR3b3JrLiBUaGUgdW5kZXJsYXkgbmV0d29yayBpcyBzZWN1cmVkIGFnYWluc3Q8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dW5hdXRob3JpemVkIGFjY2Vzcy48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkZyZWQs IHRoYXQncyB0aGUga2luZCBvZiBzdGF0ZW1lbnRzIHRoYXQgcmVhbGx5IGdpdmUgbWUgcGF1c2Uu ICZxdW90O0xldCdzIGRvIHNvbWV0aGluZyBkYW5nZXJvdXMgb24gbXkgbmV0d29yayBiZWNhdXNl IGl0IGlzIHdlbGwgaXNvbGF0ZWQgYW5kIHNlY3VyZS4mcXVvdDsgSSBhbSBwcmV0dHkgc3VyZSB0 aGF0IHRoZSBnZW50bGUgZm9sa3MgYXQgRXF1aWZheCB3ZXJlIHRoaW5raW5nIGFsb25nIHNpbWls YXIgbGluZXMuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkNocmlzdGlhbiBIdWl0ZW1hPG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c849f4452b574931a6010784711a2b26XCH150608nwnosboeingcom_-- From nobody Mon Oct 2 10:04:24 2017 Return-Path: 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 72B30133039 for ; Mon, 2 Oct 2017 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 t1Riu3Z7pfXx for ; Mon, 2 Oct 2017 10:04:22 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 251B3132F65 for ; Mon, 2 Oct 2017 10:04:22 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 47so8076972qts.10 for ; Mon, 02 Oct 2017 10:04:22 -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=F6+8k8IYOjRLvnXvac8aUOTba2EW1JhhEDf33i9YFEU=; b=B4++LWX9SNgoFLmiXlWP51PsnTQP+8eZ9f7+aicf1sSdZh9UCpDmESl/aFhfBJ5lam QVSH4mXcYpAl2SNCpiPa6l+4DYoKNkZgInlH6vBsQdSNTu07HMDlweipz+Y2YI4hXdX7 MCIJ6xl4WSCWigM5siK/i4/qL6+0SIHheIIIyIUgcaJNwLJP2Ix7hLB14kQQyxleq5FM Pv5YiNTgViEdGFVQr8MDzYez400ZzSV+l78QWJoqNFhmQPSDklLGeeIgUM1sjqdmgpOQ LPcazw+ReZC22XDJDNua8XPLbOJy8OJE80RkDjTvQ1c+F/HfWFxFAMGDDi0UjGB7bia7 JnAw== 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=F6+8k8IYOjRLvnXvac8aUOTba2EW1JhhEDf33i9YFEU=; b=O62Y+O9Vxp0Asdi30WbKdYxck3uCD27SUB+/lHtU2zc7JeIPkZsMugwfv+wSzSfy3z Ah+IPmuoGhQZby0+MHntN9prglwspUs1fkpkgxEmv6wu/Z0mHnd0uP7kcl4U/3uPErFV LQyYzKt+rZ5by38GrtjBEieITqHso9hAeMfI6kr9Ser3nbD41kF4IzU/j9f06uOgM6+2 0MGy1RfWT85rGVJ+hPICTPP8PiZKla8YuvEfwzE+wGIVbtqPSddXHO0O75DS1/gKFUbN pcXpPKzy4jv118HEp17q73ycj4jaFdVReHC1MpWMUcv5pnBRo8NUGmnpRgc4ast7gWEZ FdCw== X-Gm-Message-State: AMCzsaWzXVOvEXQl15yT9F7US+4mAOlpXTjgWyv0h9goo7dfbQUa7DGN y5gyMBhPiS0S0uciBmHiUOqrr9/KZA2CWkTFxFhm8w== X-Google-Smtp-Source: AOwi7QC7LPBMrFbD3mr3tqiIZ/WxmDxk7ZzAeqpvmm12IhWYGCaZEGgnyi7RmPMSXORtHjZA1hBSM47TMU4Lqbicci4= X-Received: by 10.200.36.164 with SMTP id s33mr6388100qts.108.1506963860750; Mon, 02 Oct 2017 10:04:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Mon, 2 Oct 2017 10:04:20 -0700 (PDT) In-Reply-To: References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> <3a9cf74ba67d4222b1c543d8bfccfe20@XCH15-06-08.nw.nos.boeing.com> From: Tom Herbert Date: Mon, 2 Oct 2017 10:04:20 -0700 Message-ID: To: "Templin, Fred L" Cc: Christian Huitema , The IESG , "ideas@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 17:04:23 -0000 On Mon, Oct 2, 2017 at 9:55 AM, Templin, Fred L wrote: > Hi Christian, > > > >>Fred, that's the kind of statements that really give me pause. "Let's do >> something dangerous > >> on my network because it is well isolated and secure." I am pretty sure >> that the gentle folks at > >> Equifax were thinking along similar lines. > > > > Understood, but for the Aeronautical Telecommunications Network (ATN) it > really > > is secured at the lower layers and has to be that way. There are no > connections to the > > open Internet, and there can be no opportunity for rogue ATCs to come in and > start > > giving orders to airplanes. This is true whether/not there is a Loc/ID split > architecture > Fred, That may be true for your use case, but we can never define IETF protocols on the basis that something at a lower layer will secure them. Tom From nobody Mon Oct 2 10:09:02 2017 Return-Path: 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 DAA7A133052; Mon, 2 Oct 2017 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9r1iHaRTQqXu; Mon, 2 Oct 2017 10:08:55 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750D8133039; Mon, 2 Oct 2017 10:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v92H8sVb062315; Mon, 2 Oct 2017 10:08:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v92H8lMt061866 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 2 Oct 2017 10:08:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Oct 2017 10:08:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 2 Oct 2017 10:08:47 -0700 From: "Templin, Fred L" To: Tom Herbert CC: Christian Huitema , The IESG , "ideas@ietf.org" Thread-Topic: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTO5b1XXR8U7Y2UkCpxQHITCbUoqLQumHAgAB6ewD//4r3YIAAeuGA//+LOjCAAHk2AP//ixKA Date: Mon, 2 Oct 2017 17:08:46 +0000 Message-ID: <9215a0fba5bf4a8dabf85ed457237ae2@XCH15-06-08.nw.nos.boeing.com> References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> <3a9cf74ba67d4222b1c543d8bfccfe20@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 17:08:57 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVy IDAyLCAyMDE3IDEwOjA0IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+DQo+IENjOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5l dD47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgaWRlYXNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtJZGVhc10gRndkOiBGd2Q6IFJlOiBXRyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0 d29ya3MgKGlkZWFzKQ0KPiANCj4gT24gTW9uLCBPY3QgMiwgMjAxNyBhdCA5OjU1IEFNLCBUZW1w bGluLCBGcmVkIEwNCj4gPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+IEhp IENocmlzdGlhbiwNCj4gPg0KPiA+DQo+ID4NCj4gPj5GcmVkLCB0aGF0J3MgdGhlIGtpbmQgb2Yg c3RhdGVtZW50cyB0aGF0IHJlYWxseSBnaXZlIG1lIHBhdXNlLiAiTGV0J3MgZG8NCj4gPj4gc29t ZXRoaW5nIGRhbmdlcm91cw0KPiA+DQo+ID4+IG9uIG15IG5ldHdvcmsgYmVjYXVzZSBpdCBpcyB3 ZWxsIGlzb2xhdGVkIGFuZCBzZWN1cmUuIiBJIGFtIHByZXR0eSBzdXJlDQo+ID4+IHRoYXQgdGhl IGdlbnRsZSBmb2xrcyBhdA0KPiA+DQo+ID4+IEVxdWlmYXggd2VyZSB0aGlua2luZyBhbG9uZyBz aW1pbGFyIGxpbmVzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFVuZGVyc3Rvb2QsIGJ1dCBmb3IgdGhl IEFlcm9uYXV0aWNhbCBUZWxlY29tbXVuaWNhdGlvbnMgTmV0d29yayAoQVROKSBpdA0KPiA+IHJl YWxseQ0KPiA+DQo+ID4gaXMgc2VjdXJlZCBhdCB0aGUgbG93ZXIgbGF5ZXJzIGFuZCBoYXMgdG8g YmUgdGhhdCB3YXkuIFRoZXJlIGFyZSBubw0KPiA+IGNvbm5lY3Rpb25zIHRvIHRoZQ0KPiA+DQo+ ID4gb3BlbiBJbnRlcm5ldCwgYW5kIHRoZXJlIGNhbiBiZSBubyBvcHBvcnR1bml0eSBmb3Igcm9n dWUgQVRDcyB0byBjb21lIGluIGFuZA0KPiA+IHN0YXJ0DQo+ID4NCj4gPiBnaXZpbmcgb3JkZXJz IHRvIGFpcnBsYW5lcy4gVGhpcyBpcyB0cnVlIHdoZXRoZXIvbm90IHRoZXJlIGlzIGEgTG9jL0lE IHNwbGl0DQo+ID4gYXJjaGl0ZWN0dXJlDQo+ID4NCj4gRnJlZCwNCj4gDQo+IFRoYXQgbWF5IGJl IHRydWUgZm9yIHlvdXIgdXNlIGNhc2UsIGJ1dCB3ZSBjYW4gbmV2ZXIgZGVmaW5lIElFVEYNCj4g cHJvdG9jb2xzIG9uIHRoZSBiYXNpcyB0aGF0IHNvbWV0aGluZyBhdCBhIGxvd2VyIGxheWVyIHdp bGwgc2VjdXJlDQo+IHRoZW0uDQoNCklQdjYgTmVpZ2hib3IgRGlzY292ZXJ5IFtSRkM0ODYxXSBp cyBhIHByb21pbmVudCBleGFtcGxlIG9mIGFuDQpJRVRGIHByb3RvY29sIHRoYXQgcmVsaWVzIG9u IGxvd2VyIGxheWVyIHNlY3VyaXR5Lg0KDQpUaGFua3MgLSBGcmVkDQoNCj4gVG9tDQoNCg== From nobody Mon Oct 2 14:08:54 2017 Return-Path: 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 B764913336A; Mon, 2 Oct 2017 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xCmrITdbXMyS; Mon, 2 Oct 2017 14:08:45 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EA7132125; Mon, 2 Oct 2017 14:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3A0DD62202; Mon, 2 Oct 2017 17:08:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j8J6kunntsQb; Mon, 2 Oct 2017 17:08:33 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id AC6BD62201; Mon, 2 Oct 2017 17:08:32 -0400 (EDT) To: Christian Huitema , The IESG , ideas@ietf.org References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> From: Robert Moskowitz Message-ID: Date: Mon, 2 Oct 2017 17:08:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> Content-Type: multipart/alternative; boundary="------------9C5086BB7819EB06DCC4FE03" Content-Language: en-US Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 21:08:48 -0000 This is a multi-part message in MIME format. --------------9C5086BB7819EB06DCC4FE03 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/02/2017 11:55 AM, Christian Huitema 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 > To: IETF Discussion Mailing List > > > > 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. I have been thinking about this, Christian, and I have a proposal for HIP that I will be starting on shortly that will cripple this tracking while not interfering with mobility. In short, there is a chain of SPIs used. The endpoints know the chain, and no one else. This IS a problem with NAT traversal, but what is NOT a problem with NAT traversal? But as you indicated, we need to think more about privacy, as hard as that is... > > 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 --------------9C5086BB7819EB06DCC4FE03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/02/2017 11:55 AM, Christian Huitema 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>
To: IETF Discussion Mailing List <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.

I have been thinking about this, Christian, and I have a proposal for HIP that I will be starting on shortly that will cripple this tracking while not interfering with mobility.  In short, there is a chain of SPIs used.  The endpoints know the chain, and no one else.  This IS a problem with NAT traversal, but what is NOT a problem with NAT traversal?

But as you indicated, we need to think more about privacy, as hard as that is...


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

--------------9C5086BB7819EB06DCC4FE03-- From nobody Mon Oct 2 17:30:41 2017 Return-Path: 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 A164E126CB6; Mon, 2 Oct 2017 17:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 WSIPpnhDE5jc; Mon, 2 Oct 2017 17:30:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0DB134904; Mon, 2 Oct 2017 17:30:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWS31906; Tue, 03 Oct 2017 00:30:28 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Oct 2017 01:30:26 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Mon, 2 Oct 2017 17:30:13 -0700 From: Uma Chunduri To: Christian Huitema , The IESG , "ideas@ietf.org" Thread-Topic: [Ideas] Fwd: Fwd: Re: WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTO5b3sMS7wpFzqkenmQiiy1KNcqLRQ67w Date: Tue, 3 Oct 2017 00:30:12 +0000 Message-ID: <25B4902B1192E84696414485F572685401A859E1@SJCEML701-CHM.china.huawei.com> References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> In-Reply-To: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.137] Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F572685401A859E1SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59D2DA25.00D8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5ab36991a3cc495e53dfaa818919d83b Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 00:30:35 -0000 --_000_25B4902B1192E84696414485F572685401A859E1SJCEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuLA0KDQpJbi1MaW5lIFtVbWFdOg0KDQotLQ0KVW1hIEMuDQoNCkZyb206IElk ZWFzIFttYWlsdG86aWRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlh biBIdWl0ZW1hDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMDIsIDIwMTcgODo1NiBBTQ0KVG86IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgaWRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFtJZGVhc10g RndkOiBGd2Q6IFJlOiBXRyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFz KQ0KDQoNCkkganVzdCByZWFsaXplZCB0aGF0IEkgZm9yZ2V0IHRvIGNvcHkgdGhpcyBtZXNzYWdl IHRvIHRoZSBJRVNHIGFuZCBJREVBUyBtYWlsaW5nIGxpc3RzLiBTb3JyeS4NCg0KLS0tLS0tLS0g Rm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCkZ3ZDogUmU6IFdHIFJldmll dzogSURlbnRpdHkgRW5hYmxlZCBOZXR3b3JrcyAoaWRlYXMpDQoNCkRhdGU6DQoNClN1biwgMSBP Y3QgMjAxNyAxNzowNjo0NiAtMDcwMA0KDQpGcm9tOg0KDQpDaHJpc3RpYW4gSHVpdGVtYSA8aHVp dGVtYUBodWl0ZW1hLm5ldD48bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+DQoNClRvOg0KDQpJ RVRGIERpc2N1c3Npb24gTWFpbGluZyBMaXN0IDxpZXRmQGlldGYub3JnPjxtYWlsdG86aWV0ZkBp ZXRmLm9yZz4NCg0KDQoNCk9uIDkvMjkvMjAxNyA5OjEzIEFNLCBUaGUgSUVTRyB3cm90ZToNCg0K DQoNCj4gQSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgUm91dGluZyBBcmVh LiBUaGUgSUVTRyBoYXMgbm90IG1hZGUNCg0KPiBhbnkgZGV0ZXJtaW5hdGlvbiB5ZXQuIFRoZSBm b2xsb3dpbmcgZHJhZnQgY2hhcnRlciB3YXMgc3VibWl0dGVkLCBhbmQgaXMNCg0KPiBwcm92aWRl ZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIHRvIHRoZQ0KDQo+IElFU0cgbWFpbGluZyBsaXN0IChpZXNnQGlldGYub3JnPG1haWx0bzpp ZXNnQGlldGYub3JnPikgYnkgMjAxNy0xMC0wOS4NCg0KLi4uDQoNCj4NCg0KPiBOZXR3b3JrIHNv bHV0aW9ucyBiYXNlZCBvbiB0aGUgY29uY2VwdCBvZiBJZGVudGlmaWVyLUxvY2F0b3Igc2VwYXJh dGlvbiBhcmUNCg0KPiBpbmNyZWFzaW5nbHkgY29uc2lkZXJlZCB0byBzdXBwb3J0IG1vYmlsaXR5 LCBvdmVybGF5IG5ldHdvcmtpbmcgZm9yDQoNCj4gdmlydHVhbGl6YXRpb24gYW5kIG11bHRpLWhv bWluZyBhY3Jvc3MgaGV0ZXJvZ2VuZW91cyBhY2Nlc3MgbmV0d29ya3MuDQoNCg0KDQpUaGUgcHJv YmxlbSB0aGVyZSBpcyB0aGF0IHRoZSBzYW1lIHByb3BlcnRpZXMgdGhhdCBmYWNpbGl0YXRlIHJv dXRpbmcNCg0KYWxzbyBmYWNpbGl0YXRlIHRyYWNraW5nLg0KDQoNCg0KQ29uc2lkZXIgYSBtb2Jp bGUgbm9kZSB0aGF0IHN3aXRjaGVzIGZyb20gYSBXaS1GaSBuZXR3b3JrIHRvIGEgY2VsbHVsYXIN Cg0KbmV0d29yay4gSW4gdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFydCwgdGhlcmUgaXMgbm8g cmVsYXRpb24gYmV0d2Vlbg0KDQp0aGUgV2ktRmkgYWRkcmVzcyBhbmQgdGhlIGNlbGx1bGFyIGFk ZHJlc3MuIEludGVybWVkaWFyaWVzIGNhbm5vdA0KDQpvYnNlcnZlIHRoZSB0cmFmZmljIGFuZCBk ZWR1Y2UgdGhhdCB0d28gZGlmZmVyZW50IGZsb3dzIG9mIElQIHBhY2tldHMNCg0Kb3JpZ2luYXRl IGZyb20gdGhlIHNhbWUgbm9kZS4gSW4gY29udHJhc3QsIHdpdGggYW4gSUQvTG9jIGFyY2hpdGVj dHVyZSwNCg0KdGhlIHR3byBmbG93cyBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIGlkZW50 aWZpZXIsIHdoaWNoIGNhbiB0aGVuIGJlDQoNCnVzZWQgdG8gdHJhY2sgdGhlIG1vdmVtZW50cyBv ZiB0aGUgZGV2aWNlLg0KDQoNCg0KU2ltaWxhcmx5LCBjb25zaWRlciBhIG5vZGUgdGhhdCBjb25u ZWN0cyBzZXZlcmFsIHRpbWVzIHRvIHRoZSBzYW1lDQoNCm5ldHdvcmssIGFuZCBlYWNoIHRpbWUg dXNlcyBJUHY2IHRlbXBvcmFyeSBhZGRyZXNzZXMuIFRoZSB3ZWIgc2VydmVycw0KDQp0aGF0IGl0 IGNvbnRhY3QgY2Fubm90IHVzZSB0aGUgSVAgYWRkcmVzc2VzIHRvIGNvcnJlbGF0ZSBkaWZmZXJl bnQNCg0KY29ubmVjdGlvbnMgdGhhdCBoYXBwZW5lZCBhdCBkaWZmZXJlbnQgdGltZXMuIFRoaXMg d291bGQgY2hhbmdlIGlmIHRoZQ0KDQppZGVudGlmaWVyIGluIGFuIElEL0xPQyBhcmNoaXRlY3R1 cmUgcmVtYWluZWQgY29uc3RhbnQuDQoNCg0KDQpNdWx0aXBhdGggVENQIGFuZCBwbGFubmVkIG11 bHRpcGF0aCBleHRlbnNpb25zIG9mIFFVSUMgYXJlIGV4YW1wbGUgb2YNCg0KdHJhbnNwb3J0IHBy b3RvY29sIHRoYXQgYWxsb3cgdHJhbnNwb3J0IGNvbm5lY3Rpb25zIHRvIHVzZSBtdWx0aXBsZQ0K DQpuZXR3b3JrIHBhdGhzIHNpbXVsdGFuZW91c2x5LiBJbiBib3RoIGNhc2VzLCB0aGVyZSBzIHNp Z25pZmljYW50IHdvcmsNCg0KZ29pbmcgb24gdG8gZW5zdXJlIHRoYXQgaW50ZXJtZWRpYXJpZXMg Y2Fubm90IGVhc2lseSBhc3NvY2lhdGUgdGhlDQoNCnRyYWZmaWMgb24gdGhlIG11bHRpcGxlIHBh dGhzIHdpdGggYSBzaW5nbGUgY29ubmVjdGlvbi4NCg0KDQoNCltVbWFdOiBNb2JpbGl0eSB0cmFj a2luZyBhcyB5b3UgZXhwbGFpbmVkIGNvdWxkIGJlIGltcG9ydGFudCBhbmQgc2hvdWxkIGJlIGNv bnNpZGVyZWQgaW4gdGhlIHRocmVhdCBhbmFseXNpcy4NCg0KICAgICAgICAgICAgICAgVGhhbmtz IGZvciBwb2ludGluZyB0aGUgZWZmb3J0cyBpbiBNUFRDUC9RVUlDIHRvIG1pdGlnYXRlIHRoaXMu DQoNCiBJZiB0aGUNCg0KbXVsdGktaG9taW5nIGZ1bmN0aW9uIHdhcyBkZWxlZ2F0ZWQgdG8gYW4g SUQvTE9DIHN5c3RlbSwgaW50ZXJtZWRpYXJpZXMNCg0KY291bGQgcG90ZW50aWFsbHkgb2JzZXJ2 ZSB0aGUgaWRlbnRpZmllcnMgYW5kIGFzc29jaWF0ZSB0aGVzZSBjb25uZWN0aW9ucy4NCg0KDQoN CltVbWFdOiBUcnVlLCBidXQgSSB3b3VsZCBub3RlIHRoaXMgaXMgcmVzcGVjdGl2ZSBkYXRhIHBs YW5lIHByb3RvY29sICBtZWNoYW5pc20gdGhhdCBzaG91bGQgYWRkcmVzcyB0aGlzIGlzIGluLWxp bmUgd2l0aCBSb2JlcnTigJlzIHJlc3BvbnNlIChzb3VuZHMgbGlrZSB2ZXJ5IGdvb2QgcHJvcG9z YWwgdG8gc3RhcnQgd2l0aCkgLi4NCg0KDQoNCg0KDQpJbiBzaG9ydCwgY2FyZWxlc3MgYXBwbGlj YXRpb25zIG9mIHRoZSBJRC9MT0MgYXJjaGl0ZWN0dXJlIGNvdWxkIGVhc2lseQ0KDQpyZXN1bHQg aW4gc2VyaW91cyBwcml2YWN5IGlzc3Vlcy4gVGhlIHByb3Bvc2VkIGNoYXJ0ZXIgZG9lcyBpbmNs dWRlIGENCg0KYnJpZWYgc3RhdGVtZW50IGFib3V0IHByaXZhY3k6DQoNCg0KDQo+IC0gQW5hbHlz aXMgb2YgdGhlIGNvbmNlcHRzIG9mIGlkZW50aXR5LWlkZW50aWZpZXIgc3BsaXQgYW5kIGR5bmFt aWMNCg0KPiBpZGVudGlmaWVyIGNoYW5nZXMsIGluY2x1ZGluZyB0aGVpciBpbXBsaWNhdGlvbnMg b24gYW5vbnltaXR5IGFuZCBwcml2YWN5Lg0KDQo+IEV4cGxpY2l0bHksIHRoZSBmcmFtZXdvcmsg bXVzdCBkZWZpbmUgcHJpdmFjeSByZXF1aXJlbWVudHMgYW5kIGhvdyBwb3RlbnRpYWwNCg0KPiBl eHRlbnNpb25zL3NvbHV0aW9ucyBzaG91bGQgbWVldCB0aGVtLg0KDQoNCg0KVGhpcyBpcyBhIGdv b2Qgc3RhcnQsIGJ1dCB0aGUgd2hvbGUgY29uY2VwdCBvZiAidW5pcXVlIGlkZW50aWZpZXJzIiBp cw0KDQpzY2FyeSwgYW5kIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBleHBhbmRlZC4gRm9yIGV4 YW1wbGUsIEkgd291bGQgbGlrZQ0KDQp0byBzZWUgYW4gZXhwbGljaXQgcmVmZXJlbmNlIHRvIGEg YmFzZWxpbmUsIGUuZy4gYXNzdXJpbmcgbm8gcHJpdmFjeQ0KDQpkb3duZ3JhZGUgY29tcGFyZWQg dG8gSVB2NiB0ZW1wb3JhcnkgYWRkcmVzc2VzLCBvciBhc3N1cmluZyB0aGF0IGhvc3RzDQoNCnRo YXQgZWxlY3QgdG8gbm90IGJlIHRyYWNrZWQgd2hlbiByb2FtaW5nIGFjcm9zcyBuZXR3b3JrcyB3 aWxsIG5vdCBiZS4NCg0KDQoNCiBJDQoNCmFsc28ga25vdyB0aGF0IHRoZXJlIGhhdmUgYmVlbiBk aXNjdXNzaW9ucyBvZiBoaWRpbmcgaWRlbnRpZmllcnMgZnJvbQ0KDQppbnRlcm1lZGlhcmllcywg YW5kIGkgd291bGQgbGlrZSB0byBzZWUgdGhhdCBhcyBhbiBleHBsaWNpdCBnb2FsIG9mIHRoZQ0K DQpwcm9wb3NlZCBXRy4NCg0KDQoNCltVbWFdOiBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIGNhbiBi ZSBnb2FsIG9mIElERUFTLCB3aGljaCBtb3N0bHkgdGFsa3MgYWJvdXQgY29udHJvbCBwbGFuZSBh c3BlY3RzLg0KDQoNCg0KLS0NCg0KQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQoNCg0K --_000_25B4902B1192E84696414485F572685401A859E1SJCEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkJydXNoIFNjcmlwdCBNVCI7DQoJcGFub3NlLTE6MyA2IDggMiA0IDQg NiA3IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJGcmVlc3R5bGUgU2NyaXB0IjsN CglwYW5vc2UtMTozIDggNCAyIDMgMiA1IDExIDQgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBDaHJpc3RpYW4sPG86cD48L286cD48L3NwYW4+ PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4tTGluZSBbVW1hXTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtGcmVlc3R5bGUgU2NyaXB0JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5VbWEgQy48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QnJ1c2ggU2NyaXB0IE1U JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSWRlYXMg W21haWx0bzppZGVhcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJp c3RpYW4gSHVpdGVtYTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMDIsIDIwMTcg ODo1NiBBTTxicj4NCjxiPlRvOjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBp ZGVhc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbSWRlYXNdIEZ3ZDogRndkOiBSZTog V0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5ldHdvcmtzIChpZGVhcyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cD5JIGp1c3QgcmVhbGl6ZWQgdGhhdCBJIGZvcmdldCB0byBjb3B5IHRo aXMgbWVzc2FnZSB0byB0aGUgSUVTRyBhbmQgSURFQVMgbWFpbGluZyBsaXN0cy4gU29ycnkuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS0tLS0g Rm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0gPG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0i MCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0 IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+U3ViamVjdDogPG86cD48L286cD48L2I+PC9w Pg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RndkOiBSZTogV0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5ldHdvcmtz IChpZGVhcyk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0i IiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkRh dGU6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1biwgMSBPY3QgMjAxNyAxNzowNjo0 NiAtMDcwMDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIi IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RnJv bTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0aWFuIEh1aXRlbWEgPGEgaHJl Zj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiPiZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0 OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlRvOiA8 bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JRVRGIERpc2N1c3Npb24gTWFpbGluZyBMaXN0 IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj4NCiZsdDtpZXRmQGlldGYub3JnJmd0Ozwv YT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHByZT5PbiA5LzI5LzIwMTcgOToxMyBBTSwgVGhlIElFU0cgd3JvdGU6PG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmd0OyBB IG5ldyBJRVRGIFdHIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBSb3V0aW5nIEFyZWEuIFRoZSBJ RVNHIGhhcyBub3QgbWFkZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgYW55IGRldGVybWlu YXRpb24geWV0LiBUaGUgZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5k IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25h bCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZndDsgSUVTRyBtYWlsaW5nIGxpc3QgKDxhIGhyZWY9Im1haWx0bzpp ZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPikgYnkgMjAxNy0xMC0wOS48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4uLi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+Jmd0OyBOZXR3b3JrIHNvbHV0aW9ucyBiYXNlZCBvbiB0aGUgY29u Y2VwdCBvZiBJZGVudGlmaWVyLUxvY2F0b3Igc2VwYXJhdGlvbiBhcmU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mZ3Q7IGluY3JlYXNpbmdseSBjb25zaWRlcmVkIHRvIHN1cHBvcnQgbW9iaWxpdHks IG92ZXJsYXkgbmV0d29ya2luZyBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IHZpcnR1 YWxpemF0aW9uIGFuZCBtdWx0aS1ob21pbmcgYWNyb3NzIGhldGVyb2dlbmVvdXMgYWNjZXNzIG5l dHdvcmtzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPlRoZSBwcm9ibGVtIHRoZXJlIGlzIHRoYXQgdGhlIHNhbWUgcHJvcGVydGllcyB0aGF0IGZh Y2lsaXRhdGUgcm91dGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFsc28gZmFjaWxpdGF0ZSB0 cmFja2luZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT5Db25zaWRlciBhIG1vYmlsZSBub2RlIHRoYXQgc3dpdGNoZXMgZnJvbSBhIFdpLUZpIG5l dHdvcmsgdG8gYSBjZWxsdWxhcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5ldHdvcmsuIEluIHRo ZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBhcnQsIHRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgV2ktRmkgYWRkcmVzcyBhbmQgdGhlIGNlbGx1bGFy IGFkZHJlc3MuIEludGVybWVkaWFyaWVzIGNhbm5vdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9i c2VydmUgdGhlIHRyYWZmaWMgYW5kIGRlZHVjZSB0aGF0IHR3byBkaWZmZXJlbnQgZmxvd3Mgb2Yg SVAgcGFja2V0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9yaWdpbmF0ZSBmcm9tIHRoZSBzYW1l IG5vZGUuIEluIGNvbnRyYXN0LCB3aXRoIGFuIElEL0xvYyBhcmNoaXRlY3R1cmUsPG86cD48L286 cD48L3ByZT4NCjxwcmU+dGhlIHR3byBmbG93cyBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1l IGlkZW50aWZpZXIsIHdoaWNoIGNhbiB0aGVuIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+dXNl ZCB0byB0cmFjayB0aGUgbW92ZW1lbnRzIG9mIHRoZSBkZXZpY2UuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2ltaWxhcmx5LCBjb25zaWRlciBh IG5vZGUgdGhhdCBjb25uZWN0cyBzZXZlcmFsIHRpbWVzIHRvIHRoZSBzYW1lPG86cD48L286cD48 L3ByZT4NCjxwcmU+bmV0d29yaywgYW5kIGVhY2ggdGltZSB1c2VzIElQdjYgdGVtcG9yYXJ5IGFk ZHJlc3Nlcy4gVGhlIHdlYiBzZXJ2ZXJzPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhhdCBpdCBj b250YWN0IGNhbm5vdCB1c2UgdGhlIElQIGFkZHJlc3NlcyB0byBjb3JyZWxhdGUgZGlmZmVyZW50 PG86cD48L286cD48L3ByZT4NCjxwcmU+Y29ubmVjdGlvbnMgdGhhdCBoYXBwZW5lZCBhdCBkaWZm ZXJlbnQgdGltZXMuIFRoaXMgd291bGQgY2hhbmdlIGlmIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPmlkZW50aWZpZXIgaW4gYW4gSUQvTE9DIGFyY2hpdGVjdHVyZSByZW1haW5lZCBjb25zdGFu dC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5N dWx0aXBhdGggVENQIGFuZCBwbGFubmVkIG11bHRpcGF0aCBleHRlbnNpb25zIG9mIFFVSUMgYXJl IGV4YW1wbGUgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50cmFuc3BvcnQgcHJvdG9jb2wgdGhh dCBhbGxvdyB0cmFuc3BvcnQgY29ubmVjdGlvbnMgdG8gdXNlIG11bHRpcGxlPG86cD48L286cD48 L3ByZT4NCjxwcmU+bmV0d29yayBwYXRocyBzaW11bHRhbmVvdXNseS4gSW4gYm90aCBjYXNlcywg dGhlcmUgcyBzaWduaWZpY2FudCB3b3JrPG86cD48L286cD48L3ByZT4NCjxwcmU+Z29pbmcgb24g dG8gZW5zdXJlIHRoYXQgaW50ZXJtZWRpYXJpZXMgY2Fubm90IGVhc2lseSBhc3NvY2lhdGUgdGhl PG86cD48L286cD48L3ByZT4NCjxwcmU+dHJhZmZpYyBvbiB0aGUgbXVsdGlwbGUgcGF0aHMgd2l0 aCBhIHNpbmdsZSBjb25uZWN0aW9uLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+W1VtYV06IE1vYmlsaXR5IHRyYWNraW5nIGFzIHlvdSBleHBsYWluZWQgY291bGQg YmUgaW1wb3J0YW50IGFuZCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbiB0aGUgdGhyZWF0IGFuYWx5 c2lzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBmb3IgcG9pbnRpbmcg dGhlIGVmZm9ydHMgaW4gTVBUQ1AvUVVJQyB0byBtaXRpZ2F0ZSB0aGlzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT4gSWYgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+bXVsdGktaG9t aW5nIGZ1bmN0aW9uIHdhcyBkZWxlZ2F0ZWQgdG8gYW4gSUQvTE9DIHN5c3RlbSwgaW50ZXJtZWRp YXJpZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb3VsZCBwb3RlbnRpYWxseSBvYnNlcnZlIHRo ZSBpZGVudGlmaWVycyBhbmQgYXNzb2NpYXRlIHRoZXNlIGNvbm5lY3Rpb25zLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltV bWFdOiBUcnVlLCBidXQgSSB3b3VsZCBub3RlIHRoaXMgaXMgcmVzcGVjdGl2ZSBkYXRhIHBsYW5l IHByb3RvY29sICZuYnNwO21lY2hhbmlzbSB0aGF0IHNob3VsZCBhZGRyZXNzIHRoaXMgaXMgaW4t bGluZSB3aXRoIFJvYmVydOKAmXMgcmVzcG9uc2UgKHNvdW5kcyBsaWtlIHZlcnkgZ29vZCBwcm9w b3NhbCB0byBzdGFydCB3aXRoKSAuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5JbiBzaG9ydCwgY2FyZWxlc3MgYXBwbGljYXRpb25zIG9mIHRoZSBJRC9MT0MgYXJj aGl0ZWN0dXJlIGNvdWxkIGVhc2lseTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlc3VsdCBpbiBz ZXJpb3VzIHByaXZhY3kgaXNzdWVzLiBUaGUgcHJvcG9zZWQgY2hhcnRlciBkb2VzIGluY2x1ZGUg YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmJyaWVmIHN0YXRlbWVudCBhYm91dCBwcml2YWN5Ojxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsg LSBBbmFseXNpcyBvZiB0aGUgY29uY2VwdHMgb2YgaWRlbnRpdHktaWRlbnRpZmllciBzcGxpdCBh bmQgZHluYW1pYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgaWRlbnRpZmllciBjaGFuZ2Vz LCBpbmNsdWRpbmcgdGhlaXIgaW1wbGljYXRpb25zIG9uIGFub255bWl0eSBhbmQgcHJpdmFjeS48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IEV4cGxpY2l0bHksIHRoZSBmcmFtZXdvcmsgbXVz dCBkZWZpbmUgcHJpdmFjeSByZXF1aXJlbWVudHMgYW5kIGhvdyBwb3RlbnRpYWw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mZ3Q7IGV4dGVuc2lvbnMvc29sdXRpb25zIHNob3VsZCBtZWV0IHRoZW0u PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhp cyBpcyBhIGdvb2Qgc3RhcnQsIGJ1dCB0aGUgd2hvbGUgY29uY2VwdCBvZiAmcXVvdDt1bmlxdWUg aWRlbnRpZmllcnMmcXVvdDsgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zY2FyeSwgYW5kIEkg d291bGQgbGlrZSB0byBzZWUgdGhpcyBleHBhbmRlZC4gRm9yIGV4YW1wbGUsIEkgd291bGQgbGlr ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRvIHNlZSBhbiBleHBsaWNpdCByZWZlcmVuY2UgdG8g YSBiYXNlbGluZSwgZS5nLiBhc3N1cmluZyBubyBwcml2YWN5PG86cD48L286cD48L3ByZT4NCjxw cmU+ZG93bmdyYWRlIGNvbXBhcmVkIHRvIElQdjYgdGVtcG9yYXJ5IGFkZHJlc3Nlcywgb3IgYXNz dXJpbmcgdGhhdCBob3N0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgZWxlY3QgdG8gbm90 IGJlIHRyYWNrZWQgd2hlbiByb2FtaW5nIGFjcm9zcyBuZXR3b3JrcyB3aWxsIG5vdCBiZS48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+IEk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbHNvIGtub3cgdGhhdCB0aGVyZSBo YXZlIGJlZW4gZGlzY3Vzc2lvbnMgb2YgaGlkaW5nIGlkZW50aWZpZXJzIGZyb208bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5pbnRlcm1lZGlhcmllcywgYW5kIGkgd291bGQgbGlrZSB0byBzZWUgdGhh dCBhcyBhbiBleHBsaWNpdCBnb2FsIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb3Bv c2VkIFdHLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPltVbWFdOiBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIGNhbiBiZSBnb2Fs IG9mIElERUFTLCB3aGljaCBtb3N0bHkgdGFsa3MgYWJvdXQgY29udHJvbCBwbGFuZSBhc3BlY3Rz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_25B4902B1192E84696414485F572685401A859E1SJCEML701CHMchi_-- From nobody Tue Oct 3 05:43:33 2017 Return-Path: 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 4122D134CCB; Tue, 3 Oct 2017 05:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hIvQgqD8YXld; Tue, 3 Oct 2017 05:43:28 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE641344D1; Tue, 3 Oct 2017 05:43:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 021F96219A; Tue, 3 Oct 2017 08:43:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9DtmrccqejbN; Tue, 3 Oct 2017 08:43:16 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 942426216F; Tue, 3 Oct 2017 08:43:14 -0400 (EDT) To: Uma Chunduri , Christian Huitema , The IESG , "ideas@ietf.org" References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <25B4902B1192E84696414485F572685401A859E1@SJCEML701-CHM.china.huawei.com> From: Robert Moskowitz Message-ID: <2b2104cf-b9d8-3cbe-c198-298d6596d2d2@htt-consult.com> Date: Tue, 3 Oct 2017 08:43:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F572685401A859E1@SJCEML701-CHM.china.huawei.com> Content-Type: multipart/alternative; boundary="------------E54625CD2FB2C6508D3D4735" Content-Language: en-US Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 12:43:31 -0000 This is a multi-part message in MIME format. --------------E54625CD2FB2C6508D3D4735 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/02/2017 08:30 PM, Uma Chunduri wrote: > > Hi Christian, > > In-Line [Uma]: > > -- > > Uma C. > > *From:*Ideas [mailto:ideas-bounces@ietf.org] *On Behalf Of *Christian > Huitema > *Sent:* Monday, October 02, 2017 8:56 AM > *To:* The IESG ; 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 > > *To: * > > > > IETF Discussion Mailing List > > 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. > [Uma]: Mobility tracking as you explained could be important and > should be considered in the threat analysis. > Thanks for pointing the efforts in MPTCP/QUIC to > mitigate this. > If the > multi-homing function was delegated to an ID/LOC system, intermediaries > could potentially observe the identifiers and associate these connections. > [Uma]: True, but I would note this is respective data plane protocol > mechanism that should address this is in-line with Robert’s response > (sounds like very good proposal to start with) .. > 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. > [Uma]: I am not sure how this can be goal of IDEAS, which mostly talks > about control plane aspects. This is really hard. One party has to have its identity in the clear to start the control plane, otherwise you have this great DOS attack. We went through this discussion in the early days of HIP. This is why the Responder's HIT is in the clear; the Initiator's can be hidden. Well the HI can. But once you have state between the peers, much can be done. With HIP I have to change the HIT derivation to allow for a chain of HITs off the HI that Eve cannot connect. But this raises challenges for NAT traversal... I can do this for HIP; I don't know, yet, how to make this general for IDEAS. Bob --------------E54625CD2FB2C6508D3D4735 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/02/2017 08:30 PM, Uma Chunduri wrote:

Hi Christian,

 

In-Line [Uma]:

 

--

Uma C.

 

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>

To:

IETF Discussion Mailing List <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.
 
[Uma]: Mobility tracking as you explained could be important and should be considered in the threat analysis.
               Thanks for pointing the efforts in MPTCP/QUIC to mitigate this.
 If the
multi-homing function was delegated to an ID/LOC system, intermediaries
could potentially observe the identifiers and associate these connections.
 
[Uma]: True, but I would note this is respective data plane protocol  mechanism that should address this is in-line with Robert’s response (sounds like very good proposal to start with) ..
                
 
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.
 
[Uma]: I am not sure how this can be goal of IDEAS, which mostly talks about control plane aspects.

This is really hard.  One party has to have its identity in the clear to start the control plane, otherwise you have this great DOS attack.  We went through this discussion in the early days of HIP.  This is why the Responder's HIT is in the clear; the Initiator's can be hidden.  Well the HI can.

But once you have state between the peers, much can be done.  With HIP I have to change the HIT derivation to allow for a chain of HITs off the HI that Eve cannot connect.  But this raises challenges for NAT traversal...

I can do this for HIP; I don't know, yet, how to make this general for IDEAS.

Bob

--------------E54625CD2FB2C6508D3D4735-- From nobody Wed Oct 4 07:57:33 2017 Return-Path: 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 0728B132C2A; Wed, 4 Oct 2017 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 HjjoWzQfnEG3; Wed, 4 Oct 2017 07:57:23 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 D4957132697; Wed, 4 Oct 2017 07:57:22 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id q4so2373985oic.7; Wed, 04 Oct 2017 07:57:22 -0700 (PDT) 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=bb7WMcqoVqRyzvWeR9USiXxED/AidAjwpfp8Jn/D4aY=; b=qOYfnKK5O0Nx1eK0dYR1qVQCVlEchGb2fLULjMXyobjXm9EBXoaMTPqCVfED/5mSXu EC1XUJspIJj7RBP4O90o+dOS98wimhCwK2LoT4Yv8GXCp+Acp3EB8h1Q5A2vrbJyvbuf sLS26iQLUA1EHfg+ITlSRUJNmyk1vu0sIYPPVDbZvdbcSYvz+DjMqUw+lZJc8vkvryUt uM4a6n/zct3E9bv6dny3W4klTWFIW0mRTk2NJL5BZwo4eliukHZIA2lmNVPDJ3N9EAQw 55g4dQyfVkoG9ssglFjv0rn8UzZTQcYjf9I5lwEAVGOEzN4ckC7lryRjCYu7lrmpbsLG RHtA== 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=bb7WMcqoVqRyzvWeR9USiXxED/AidAjwpfp8Jn/D4aY=; b=DZbD0zA3oY1ZuWDIUf4rjt1TJ6MXTnzCYQoonBpKDrT69LDG9eXbnIC0eI7otF/Enm Ffeu0R0ULrjOfAjc8q1UROx0RMReh713+iVG5wu/SUbgY93mMZyx5yeFLiLp9GyaHhTe iVEL1kgtmsQNxz46wulbiBnz4CLvcOF1QsEOu5MkDT8IQ5wjthk9OUK136wmklM2AahY tteBheXFYVGG/cD9qNW51RzK038mycHiafnSLt8vOz+4uDOHpbGs3cRe9d3R+QuaR4+v FELxwwYdOnWgSi2KjtV1pnK/aQDvSefwhFuTipAIV2QF/DuJmW2pEyKNq0JHtPxYuYuR TNLw== X-Gm-Message-State: AMCzsaVs8KU6nKocWKWwR29O5DHrZROSRloM+a1T3Pn9PqBJMXRhL9kK SXcrGvSbsOaiBiQqiMNpq7txoDOetevS05tMKAzHkg== X-Google-Smtp-Source: AOwi7QDoG4DiO1RtqK+v397pdArzemaY10bDU5yqGmCQKO0zt+poJsadpZD3mCEi6Vb+x6Hfgg1qOHdVSz4uEzY1zfQ= X-Received: by 10.157.13.67 with SMTP id 61mr5831192oti.162.1507129042023; Wed, 04 Oct 2017 07:57:22 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Wed, 4 Oct 2017 07:57:21 -0700 (PDT) In-Reply-To: <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> From: Phillip Hallam-Baker Date: Wed, 4 Oct 2017 10:57:21 -0400 X-Google-Sender-Auth: tr83UhDZWHj_DOo4e062dVXgp_c Message-ID: To: Stephen Farrell Cc: IETF-Discussion , ideas@ietf.org Content-Type: multipart/alternative; boundary="001a113711b02e4200055ab9d338" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 14:57:25 -0000 --001a113711b02e4200055ab9d338 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell wrote: > > As currently described, I oppose creation of this working > group on the basis that it enables and seemingly encourages > embedding identifiers for humans as addresses. Doing so > would have significant privacy downsides, would enable > new methods for censorship and discrimination, and could > be very hard to mitigate should one wish to help protect > people's privacy, as I think is current IETF policy. > > If the work precluded the use of any identifiers that > strongly map to humans then I'd be ok with it being done > as it'd then only be a waste of resources. But I don't > know how that could be enforced so I think it'd be better > to just not do this work at all. > > S. =E2=80=8B+1 I know how to restrict the work to 'meaningless' identifiers, require that the identifiers be the output of a cryptographic algorithm. =E2=80=8BNow strictly speaking, this only limits scope to identifiers that = are indexical as opposed to rendering them meaningless but I think that was the sense of it. N=C3=B6th proposed a trichotemy of identifiers as follows * Identity, the signifier is the signified (e.g. data: URI) * Indexical, the signifier is related to the signified by a systematic relationship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.) * Names, the signifier is the related to the signified by a purely conventional relationship, (e.g. example.com to its owner) There is a big difference between attempting to manage indexical signifiers and names. Especially when the people trying to do so refuse to read any of the literature on semiotics. Names are problematic because the only way that a conventional relationship can be implemented is through some sort of registration infrastructure and we already have one of those and the industry that manages it has a marketcap in the tens of billions. Identifiers do lead to tractable solutions. But, this proposal looks a bit unfocused for IRTF consideration, an IETF WG? Really? I wrote this for the ename workshop and I think it shows that some of the goals stated can be solved: http://www.prismproof.org/Documents/draft-hallambaker-sin.html But this is what my names look like: alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz https://mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com/ They are both legal addresses fully compliant with the DNS etc specs. The first won't resolve on the regular DNS, the second does but the embedded security properties will only be enforced if the resolver understands the mm-- prefix. I can use these names to achieve content based routing of both static and dynamic data. In the first case, the identifier is the fingerprint of the content itself, in the second, the identifier is the fingerprint of a key signing the content. --001a113711b02e4200055ab9d338 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:

As currently described, I oppose creation of this working
group on the basis that it enables and seemingly encourages
embedding identifiers for humans as addresses. Doing so
would have significant privacy downsides, would enable
new methods for censorship and discrimination, and could
be very hard to mitigate should one wish to help protect
people's privacy, as I think is current IETF policy.

If the work precluded the use of any identifiers that
strongly map to humans then I'd be ok with it being done
as it'd then only be a waste of resources. But I don't
know how that could be enforced so I think it'd be better
to just not do this work at all.

S.

=E2=80=8B+1

I know how to restrict the work to 'meaningless' identif= iers, require that the identifiers be the output of a cryptographic algorit= hm.

<= div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8BNow strictly= speaking, this only limits scope to identifiers that are indexical as oppo= sed to rendering them meaningless but I think that was the sense of it.


N=C3=B6th= =C2=A0proposed a trichotemy of identifiers as follows

* Identity, the signifier is the si= gnified (e.g. data: URI)

= * Indexical, the signifier is related to the signified by a systematic rela= tionship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.)

* Names, =C2=A0the signifier is the rel= ated to the signified by a purely conventional relationship, (e.g. example.com to its owner)


There is a big difference between attempting to manage= indexical signifiers and names. Especially when the people trying to do so= refuse to read any of the literature on semiotics.

Names are problematic because the only way that = a conventional relationship can be implemented is through some sort of regi= stration infrastructure and we already have one of those and the industry t= hat manages it has a marketcap in the tens of billions.

Identifiers do lead to tractable solutions. = But, this proposal looks a bit unfocused for IRTF consideration, an IETF WG= ? Really?

<= /div>

I wrote this for the enam= e workshop and I think it shows that some of the goals stated can be solved= :
http://www.prismproof.org/Documents/dra= ft-hallambaker-sin.html

But this is what my names look like:

alice@example.com.mm--mb2gk-6duf= 5-ygyyl-jny5e-rwshz
https://mb2gk-6duf5-ygyyl-jny5e-rwshz.exampl= e.com/
<= /span>

They are both lega= l addresses fully compliant with the DNS etc specs. The first won't res= olve on the regular DNS, the second does but the embedded security properti= es will only be enforced if the resolver understands the mm-- prefix.
=


I can use these names to achieve content= based routing of both static and dynamic data. In the first case, the iden= tifier is the fingerprint of the content itself, in the second, the identif= ier is the fingerprint of a key signing the content.
--001a113711b02e4200055ab9d338-- From nobody Wed Oct 4 09:17:50 2017 Return-Path: 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 CC9381326F6 for ; Wed, 4 Oct 2017 09:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 2riHRNz79ylO for ; Wed, 4 Oct 2017 09:17:40 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 1EE15126D0C for ; Wed, 4 Oct 2017 09:17:40 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id r64so11738416qkc.1 for ; Wed, 04 Oct 2017 09:17:39 -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:content-transfer-encoding; bh=JCoFWHe6tWZtmgqtr6OIHam0XGxpdFgFeDvhbxYqI7s=; b=c9BCyT6RQLZIH/YIFeFNhIO2fA+sqDcvkMW5+9uv9FILqY/cXoWRLx5pIn1ptWLyRo weq6vvI6FJTHwklRtY7M1sUiP32NvGBep0lGRj9TvA9bOohXIHNaXJQnnmgtT09F8o1R GcP79+YsWMe4tmSNHg7qY6lqE6rgN1BxmnnxwOhyqNnMSvANFf8dyo7izwJs37xj8iXu /Gqln7bH/3SQ81xaRxjym02fhLQvrtqFlo0yWAbTmehISaM8jrxeQzd4bI41IxmOQqge tPrQF8O6HnOkUYuiUZnX4FShA4/ZXVImDpP8kUeGFJ5vjakrmF00Imm//82JU+/V/se/ 8W5A== 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:content-transfer-encoding; bh=JCoFWHe6tWZtmgqtr6OIHam0XGxpdFgFeDvhbxYqI7s=; b=ulT4H5zmdLYyaQHOVqa9pQd/XnLDWZpBJ78FPcRwKjIS7mH/aUk8v3Bk3x5IvRB3CH XYclVfnD/FdvSzh0F28jY/zLOiCVaUSE33EROkcSawVbNoMkGkDM/VOiMkDhjx84gIVX rxeB+DuVRKVnn/xExXSUwCNn/tsa/YIUR7jhpvJTveFjzTeqRFy84X/zabknhpO6RZaD x7tX2iaqcQq0S/7PY1SYr2QT33q9SFO/nqSEYM0ZYh7rXb2Er4a+N1aAJjkXBOoxThch Xe/E9mEhg5G/flxkGeuSAgKpg3whLyZbg2UpmSNbVKZB6kUrlZLpkof/7tzXbCooS81P 6aFw== X-Gm-Message-State: AMCzsaXmIcsw9VmIYt58k4OTVNYZR9Ghz568VoE9zDuXI2eag8Y+ftZv ARpBOuEW2JHpN3QwTrl47L8gAcHFb3ZQwOTSNkmpqnVC X-Google-Smtp-Source: AOwi7QA3NMQVB7dgmH2TaC+ZNKkWvUzyj7+4dWPx+CN23HU4KRlz59xBb2l6zr3rjDrQMBYh3z8QHfslYwtlg9+foPc= X-Received: by 10.55.109.131 with SMTP id i125mr24464257qkc.17.1507133859037; Wed, 04 Oct 2017 09:17:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 09:17:38 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> From: Tom Herbert Date: Wed, 4 Oct 2017 09:17:38 -0700 Message-ID: To: Phillip Hallam-Baker Cc: Stephen Farrell , ideas@ietf.org, IETF-Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 16:17:43 -0000 On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker wrote: > On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell > wrote: >> >> >> As currently described, I oppose creation of this working >> group on the basis that it enables and seemingly encourages >> embedding identifiers for humans as addresses. Doing so >> would have significant privacy downsides, would enable >> new methods for censorship and discrimination, and could >> be very hard to mitigate should one wish to help protect >> people's privacy, as I think is current IETF policy. >> >> If the work precluded the use of any identifiers that >> strongly map to humans then I'd be ok with it being done >> as it'd then only be a waste of resources. But I don't >> know how that could be enforced so I think it'd be better >> to just not do this work at all. >> >> S. > > > +1 > > I know how to restrict the work to 'meaningless' identifiers, require tha= t > the identifiers be the output of a cryptographic algorithm. > > Now strictly speaking, this only limits scope to identifiers that are > indexical as opposed to rendering them meaningless but I think that was t= he > sense of it. > > > N=C3=B6th proposed a trichotemy of identifiers as follows > > * Identity, the signifier is the signified (e.g. data: URI) > > * Indexical, the signifier is related to the signified by a systematic > relationship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.) > > * Names, the signifier is the related to the signified by a purely > conventional relationship, (e.g. example.com to its owner) > > > There is a big difference between attempting to manage indexical signifie= rs > and names. Especially when the people trying to do so refuse to read any = of > the literature on semiotics. > > Names are problematic because the only way that a conventional relationsh= ip > can be implemented is through some sort of registration infrastructure an= d > we already have one of those and the industry that manages it has a > marketcap in the tens of billions. > > Identifiers do lead to tractable solutions. But, this proposal looks a bi= t > unfocused for IRTF consideration, an IETF WG? Really? > Identifiers are equivalent to addresses in that they indicate a node in the network for the purposes of end to end communications. The only difference between identifiers and addresses is that identifiers are not topological. Virtual addresses in network virtualization are also identifiers. So the security properties are the same when considering privacy. For instance, if applications use temporary addresses for privacy, it would have equivalent properties using temporary identifiers. In fact from the application POV this would be transparent. It could get a pool of apparently random addresses to choose from as source of communication, it shouldn't know or even care if the addresses are identifiers. Identity is a completely separate concept from identifiers. Is not required in any of the identifier/locator protocols and AFAIK none of them even mention the term. There is no association of an identity of user behind and identifier any more than there is an association of identity behind IP address. The fact that the words "identifier" and "identity" share a common prefix is an unfortunate happenstance :-). Tom From nobody Wed Oct 4 09:34:56 2017 Return-Path: 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 69CCA13430D; Wed, 4 Oct 2017 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wbDeFHxQCQwt; Wed, 4 Oct 2017 09:34:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185B313422B; Wed, 4 Oct 2017 09:34:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EC68BE2F; Wed, 4 Oct 2017 17:34:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK2JXrI6b8Pz; Wed, 4 Oct 2017 17:34:43 +0100 (IST) Received: from [127.0.0.1] (unknown [109.125.18.168]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 213F9BE24; Wed, 4 Oct 2017 17:34:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507134883; bh=0yVzGYDz/5tCmZwcdjkqWw6Ofv5t1sQDEtQqbpK7/Ws=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=xTyTL0HREOEFSk0cyl5nCFw2PqcyV/mWptY6V1EFtncPHO9ZOgn6MPbuWoFzBfxNi o3QXWoD5jzjRXL5gxyowRoFtmkAy9ovvJioDRlWtjuO5nm1L3ke9Wj6S8NsrW6tkam jqrgJ5albIoRv1blVjGn/xQfnxceUZk5QRt8VfZs= X-Priority: 3 To: tom@herbertland.com Cc: ideas@ietf.org,ietf@ietf.org,phill@hallambaker.com From: stephen.farrell@cs.tcd.ie In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 4 Oct 2017 16:34:41 +0000 Message-ID: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> MIME-Version: 1.0 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 16:34:49 -0000 DQoNCk9uIFdlZG5lc2RheSwgNCBPY3RvYmVyIDIwMTcsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPiBP biBXZWQsIE9jdCA0LCAyMDE3IGF0IDc6NTcgQU0sIFBoaWxsaXAgSGFsbGFtLUJha2VyDQo+IDxw aGlsbEBoYWxsYW1iYWtlci5jb20+IHdyb3RlOg0KPiA+IE9uIEZyaSwgU2VwIDI5LCAyMDE3IGF0 IDI6MzEgUE0sIFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4NCj4g PiB3cm90ZToNCj4gPj4NCj4gPj4NCj4gPj4gQXMgY3VycmVudGx5IGRlc2NyaWJlZCwgSSBvcHBv c2UgY3JlYXRpb24gb2YgdGhpcyB3b3JraW5nDQo+ID4+IGdyb3VwIG9uIHRoZSBiYXNpcyB0aGF0 IGl0IGVuYWJsZXMgYW5kIHNlZW1pbmdseSBlbmNvdXJhZ2VzDQo+ID4+IGVtYmVkZGluZyBpZGVu dGlmaWVycyBmb3IgaHVtYW5zIGFzIGFkZHJlc3Nlcy4gRG9pbmcgc28NCj4gPj4gd291bGQgaGF2 ZSBzaWduaWZpY2FudCBwcml2YWN5IGRvd25zaWRlcywgd291bGQgZW5hYmxlDQo+ID4+IG5ldyBt ZXRob2RzIGZvciBjZW5zb3JzaGlwIGFuZCBkaXNjcmltaW5hdGlvbiwgYW5kIGNvdWxkDQo+ID4+ IGJlIHZlcnkgaGFyZCB0byBtaXRpZ2F0ZSBzaG91bGQgb25lIHdpc2ggdG8gaGVscCBwcm90ZWN0 DQo+ID4+IHBlb3BsZSdzIHByaXZhY3ksIGFzIEkgdGhpbmsgaXMgY3VycmVudCBJRVRGIHBvbGlj eS4NCj4gPj4NCj4gPj4gSWYgdGhlIHdvcmsgcHJlY2x1ZGVkIHRoZSB1c2Ugb2YgYW55IGlkZW50 aWZpZXJzIHRoYXQNCj4gPj4gc3Ryb25nbHkgbWFwIHRvIGh1bWFucyB0aGVuIEknZCBiZSBvayB3 aXRoIGl0IGJlaW5nIGRvbmUNCj4gPj4gYXMgaXQnZCB0aGVuIG9ubHkgYmUgYSB3YXN0ZSBvZiBy ZXNvdXJjZXMuIEJ1dCBJIGRvbid0DQo+ID4+IGtub3cgaG93IHRoYXQgY291bGQgYmUgZW5mb3Jj ZWQgc28gSSB0aGluayBpdCdkIGJlIGJldHRlcg0KPiA+PiB0byBqdXN0IG5vdCBkbyB0aGlzIHdv cmsgYXQgYWxsLg0KPiA+Pg0KPiA+PiBTLg0KPiA+DQo+ID4NCj4gPiArMQ0KPiA+DQo+ID4gSSBr bm93IGhvdyB0byByZXN0cmljdCB0aGUgd29yayB0byAnbWVhbmluZ2xlc3MnIGlkZW50aWZpZXJz LCByZXF1aXJlIHRoYXQNCj4gPiB0aGUgaWRlbnRpZmllcnMgYmUgdGhlIG91dHB1dCBvZiBhIGNy eXB0b2dyYXBoaWMgYWxnb3JpdGhtLg0KPiA+DQo+ID4gTm93IHN0cmljdGx5IHNwZWFraW5nLCB0 aGlzIG9ubHkgbGltaXRzIHNjb3BlIHRvIGlkZW50aWZpZXJzIHRoYXQgYXJlDQo+ID4gaW5kZXhp Y2FsIGFzIG9wcG9zZWQgdG8gcmVuZGVyaW5nIHRoZW0gbWVhbmluZ2xlc3MgYnV0IEkgdGhpbmsg dGhhdCB3YXMgdGhlDQo+ID4gc2Vuc2Ugb2YgaXQuDQo+ID4NCj4gPg0KPiA+IE7DtnRoIHByb3Bv c2VkIGEgdHJpY2hvdGVteSBvZiBpZGVudGlmaWVycyBhcyBmb2xsb3dzDQo+ID4NCj4gPiAqIElk ZW50aXR5LCB0aGUgc2lnbmlmaWVyIGlzIHRoZSBzaWduaWZpZWQgKGUuZy4gZGF0YTogVVJJKQ0K PiA+DQo+ID4gKiBJbmRleGljYWwsIHRoZSBzaWduaWZpZXIgaXMgcmVsYXRlZCB0byB0aGUgc2ln bmlmaWVkIGJ5IGEgc3lzdGVtYXRpYw0KPiA+IHJlbGF0aW9uc2hpcCwgKGUuZy4gbmkgVVJJcywg U0hBMjU2RGF0YSksIFBHUCBmaW5nZXJwcmludHMgZXRjLikNCj4gPg0KPiA+ICogTmFtZXMsICB0 aGUgc2lnbmlmaWVyIGlzIHRoZSByZWxhdGVkIHRvIHRoZSBzaWduaWZpZWQgYnkgYSBwdXJlbHkN Cj4gPiBjb252ZW50aW9uYWwgcmVsYXRpb25zaGlwLCAoZS5nLiBleGFtcGxlLmNvbSB0byBpdHMg b3duZXIpDQo+ID4NCj4gPg0KPiA+IFRoZXJlIGlzIGEgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBh dHRlbXB0aW5nIHRvIG1hbmFnZSBpbmRleGljYWwgc2lnbmlmaWVycw0KPiA+IGFuZCBuYW1lcy4g RXNwZWNpYWxseSB3aGVuIHRoZSBwZW9wbGUgdHJ5aW5nIHRvIGRvIHNvIHJlZnVzZSB0byByZWFk IGFueSBvZg0KPiA+IHRoZSBsaXRlcmF0dXJlIG9uIHNlbWlvdGljcy4NCj4gPg0KPiA+IE5hbWVz IGFyZSBwcm9ibGVtYXRpYyBiZWNhdXNlIHRoZSBvbmx5IHdheSB0aGF0IGEgY29udmVudGlvbmFs IHJlbGF0aW9uc2hpcA0KPiA+IGNhbiBiZSBpbXBsZW1lbnRlZCBpcyB0aHJvdWdoIHNvbWUgc29y dCBvZiByZWdpc3RyYXRpb24gaW5mcmFzdHJ1Y3R1cmUgYW5kDQo+ID4gd2UgYWxyZWFkeSBoYXZl IG9uZSBvZiB0aG9zZSBhbmQgdGhlIGluZHVzdHJ5IHRoYXQgbWFuYWdlcyBpdCBoYXMgYQ0KPiA+ IG1hcmtldGNhcCBpbiB0aGUgdGVucyBvZiBiaWxsaW9ucy4NCj4gPg0KPiA+IElkZW50aWZpZXJz IGRvIGxlYWQgdG8gdHJhY3RhYmxlIHNvbHV0aW9ucy4gQnV0LCB0aGlzIHByb3Bvc2FsIGxvb2tz IGEgYml0DQo+ID4gdW5mb2N1c2VkIGZvciBJUlRGIGNvbnNpZGVyYXRpb24sIGFuIElFVEYgV0c/ IFJlYWxseT8NCj4gPg0KPiBJZGVudGlmaWVycyBhcmUgZXF1aXZhbGVudCB0byBhZGRyZXNzZXMg aW4gdGhhdCB0aGV5IGluZGljYXRlIGEgbm9kZQ0KPiBpbiB0aGUgbmV0d29yayBmb3IgdGhlIHB1 cnBvc2VzIG9mIGVuZCB0byBlbmQgY29tbXVuaWNhdGlvbnMuIFRoZSBvbmx5DQo+IGRpZmZlcmVu Y2UgYmV0d2VlbiBpZGVudGlmaWVycyBhbmQgYWRkcmVzc2VzIGlzIHRoYXQgaWRlbnRpZmllcnMg YXJlDQo+IG5vdCB0b3BvbG9naWNhbC4gVmlydHVhbCBhZGRyZXNzZXMgaW4gbmV0d29yayB2aXJ0 dWFsaXphdGlvbiBhcmUgYWxzbw0KPiBpZGVudGlmaWVycy4gU28gdGhlIHNlY3VyaXR5IHByb3Bl cnRpZXMgYXJlIHRoZSBzYW1lIHdoZW4gY29uc2lkZXJpbmcNCj4gcHJpdmFjeS4gRm9yIGluc3Rh bmNlLCBpZiBhcHBsaWNhdGlvbnMgdXNlIHRlbXBvcmFyeSBhZGRyZXNzZXMgZm9yDQo+IHByaXZh Y3ksIGl0IHdvdWxkIGhhdmUgZXF1aXZhbGVudCBwcm9wZXJ0aWVzIHVzaW5nIHRlbXBvcmFyeQ0K PiBpZGVudGlmaWVycy4gSW4gZmFjdCBmcm9tIHRoZSBhcHBsaWNhdGlvbiBQT1YgdGhpcyB3b3Vs ZCBiZQ0KPiB0cmFuc3BhcmVudC4gSXQgY291bGQgZ2V0IGEgcG9vbCBvZiBhcHBhcmVudGx5IHJh bmRvbSBhZGRyZXNzZXMgdG8NCj4gY2hvb3NlIGZyb20gYXMgc291cmNlIG9mIGNvbW11bmljYXRp b24sIGl0IHNob3VsZG4ndCBrbm93IG9yIGV2ZW4gY2FyZQ0KPiBpZiB0aGUgYWRkcmVzc2VzIGFy ZSBpZGVudGlmaWVycy4NCj4gDQo+IElkZW50aXR5IGlzIGEgY29tcGxldGVseSBzZXBhcmF0ZSBj b25jZXB0IGZyb20gaWRlbnRpZmllcnMuIElzIG5vdA0KPiByZXF1aXJlZCBpbiBhbnkgb2YgdGhl IGlkZW50aWZpZXIvbG9jYXRvciBwcm90b2NvbHMgYW5kIEFGQUlLIG5vbmUgb2YNCj4gdGhlbSBl dmVuIG1lbnRpb24gdGhlIHRlcm0uIFRoZXJlIGlzIG5vIGFzc29jaWF0aW9uIG9mIGFuIGlkZW50 aXR5IG9mDQo+IHVzZXIgYmVoaW5kIGFuZCBpZGVudGlmaWVyIGFueSBtb3JlIHRoYW4gdGhlcmUg aXMgYW4gYXNzb2NpYXRpb24gb2YNCj4gaWRlbnRpdHkgYmVoaW5kIElQIGFkZHJlc3MuIFRoZSBm YWN0IHRoYXQgdGhlIHdvcmRzICJpZGVudGlmaWVyIiBhbmQNCj4gImlkZW50aXR5IiBzaGFyZSBh IGNvbW1vbiBwcmVmaXggaXMgYW4gdW5mb3J0dW5hdGUgaGFwcGVuc3RhbmNlIDotKS4NCg0KDQpZ ZXMuIEJ1dCBkb2Vzbid0IHRoYXQgbWVhbiBlaXRoZXIgdGhlIG5hbWUgb2YgdGhpcyBlZmZvcnQg aXMgd2lsZGx5IG1pc2xlYWRpbmcgb3IgZWxzZSB0aGUgZWZmb3J0IGlzIGh1Z2VseSBwcm9ibGVt YXRpYyBmcm9tIGEgcHJpdmFjeSBQT1Y/IEVpdGhlciB3YXksIGlzdG0gdGhpcyBvdWdodCBub3Qg cHJvY2VlZC4NCg0KUy4NCg0KPiANCj4gVG9tDQo+ From nobody Wed Oct 4 09:58:05 2017 Return-Path: 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 4C84F1342FC; Wed, 4 Oct 2017 09:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EFVchTOteAvV; Wed, 4 Oct 2017 09:58:02 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB4F13422B; Wed, 4 Oct 2017 09:58:02 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dzmzh-0002rj-EF; Wed, 04 Oct 2017 12:58:01 -0400 Date: Wed, 04 Oct 2017 12:57:55 -0400 From: John C Klensin To: ietf@ietf.org cc: ideas@ietf.org Message-ID: <94E38EAAADE89B4B40A79530@PSB> In-Reply-To: <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 16:58:04 -0000 IESG, A comment somewhat orthogonal to whether this WG should be chartered (I see the need, or at least the desire, but suspect the current charter is badly structured to accomplish it). It may be that, with LISP (another IMO unfortunate name) and HIP already out there, we are already obligated to do something like this. However, I strongly urge that, if the charter is accepted in principle, you move away from from acronyms that are likely to create far more confusion than the desire for demonstrating cleverness or cuteness can possibly be worth. "ideas" itself is an example. It may be an an acronym that was cleverly matched to the WG name (or vice versa) but it is also a word that implies an entirely different meaning, one that is fairly misleading relative to the intended WG's topic and more suited, if it is suitable at all for a WG name, for something exploring or brainstorming a much broader range of topics. An "ideas@ietf.org" mailing list is particularly obnoxious in that regard. If people really are trying to show off how clever they can be with acronyms, how about taking the LISP precedent and figuring out words that would match some other programming language names? For example, those who oppose this might like COBOL or, more neutrally, SLIP (although that, of course, describes another piece of networking protocol (see RFC 1055)). Or someone who dislikes this might advocate calling it The Ultimate Routing Key Evolutionary Ysmmer group. You get the idea -- if we want the IETF to be seen as a mature and responsible body, we really don't need to go there. "GRIDS" is as bad or worse, because "Grid" refers to a well-known networking technology about which the IETF Stream has published RFCs (See, e.g., RFC 6272). Our job is supposed to be trying to make the Internet better. It seems to me that creating confusion by side-effect of the terminology we use does not advance that goal. best, john On 29/09/17 17:13, 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. > > IDentity Enabled Networks (ideas) >... > 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. Identifier-locator separation > protocols require infrastructure that allows nodes to > discover the network topological location(s) of its peer(s) > for packet delivery. A common infrastructure and protocol > could be used by identifier/locator protocols as well as > network virtualization. However, additional infrastructure > and new protocol extensions are needed to address new > requirements that go well beyond the traditional discovery > service and mapping of identifier-to-location for packet > delivery. Identifier-locator protocols are also useful for > additional services involving dynamic association of a name > to a set of network addresses - these include dynamic > multicast, cloud service anycast and context-aware IoT > queries. > > The IDEAS WG is chartered to produce a framework document > that defines the expected behavior of a mapping system across > the multiple existing use cases. The framework will aim at a > homogeneous behavior across use cases, and it will call out > specific trade-offs that may be considered in the development > of solutions. We refer to the framework providing the set of > services as Generic Identity Services (GRIDS). >... From nobody Wed Oct 4 10:07:21 2017 Return-Path: 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 360401342FC for ; Wed, 4 Oct 2017 10:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 NbqAHswJiMzM for ; Wed, 4 Oct 2017 10:07:13 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 605B013422B for ; Wed, 4 Oct 2017 10:07:13 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id a43so14577754qta.0 for ; Wed, 04 Oct 2017 10:07:13 -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:content-transfer-encoding; bh=qBfTepalzz5r4Xoc5udfew+r8ONZvBuvAUGWQaA4OF4=; b=HXr3BtTlH9VFX30pDN8CMgPScsZAmeAblPaDCkXzbJSa7VXMhXU1fSEpfhUmMFGOs+ 0q4gYV++bawcIXjte5v8Xnq7VSA1nlZIdeTMzVJGZU4n3fKrlS5NPuEfRsk07jWmkvdE vyR9eFCrlaTQc8Rkm9mfSnoPOXbiT+uS90O1lvEsthSy8PNHIXT+c2U4ToHAdVcpMlID wdYVqbWXV+x9ez1/F7edcTVSQEL1miPwdbWxV4X5zvBD23BELyMZtIZVaZcAzXpsHFWK +Ry0Xo40N4CFWT/BZu2ir/Fy9Kold6L5MspKBActKgMsfbCexCtrVw/oiSoP1Lv5n7tK lVpw== 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:content-transfer-encoding; bh=qBfTepalzz5r4Xoc5udfew+r8ONZvBuvAUGWQaA4OF4=; b=MR2PJ5HhoU4Fw78kDSpzt1Js7pOiVc5lpNyKgr9QdLlqJ1w8j2FsvaYsE5R4Mx18KF dxqLgavS7utEFCRWX6j74hfQ4xrFidNFnn+x0iw389XjvipcIVw4CWcYhhHsj3yVc1o+ 7D4F/Feys9Cc1A0i18vJ7fgQGgz4W/zoktraQeWYxz7fgB/irpJGPLt/MvhJsZQ19Byd 5/TdfP/jymSpMFrjdNLvs2KhP/OpJ5fjcO63XuQGIJxvAD5JbXw0pQa0ANqLCyMyKph0 pyH5QppIqK5acxPgD1ZbARUIwgfSTWuA4o+/uPxba196mrE0d9G3ffjmT0JJKwydXc2X 8dhg== X-Gm-Message-State: AMCzsaVMfun++SXhM4YGBjCmqbkZH9j8a860XPncuNMkWqEkFZ1aTQXe 6sq7BDm56T0Iz82ah2J7O3h/ev0WjsETFykt4GZcxA== X-Google-Smtp-Source: AOwi7QCDrJUz3Va4cxYW1t6CiVJf3uMVizWZqnZtSR94xFJ9FfTH2cvzLMNLeuSOVTUF67fex1TAW032UJdYDmMxDpY= X-Received: by 10.200.35.247 with SMTP id r52mr30777788qtr.275.1507136832363; Wed, 04 Oct 2017 10:07:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 10:07:11 -0700 (PDT) In-Reply-To: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> From: Tom Herbert Date: Wed, 4 Oct 2017 10:07:11 -0700 Message-ID: To: Stephen Farrell Cc: ideas@ietf.org, IETF-Discussion , Phillip Hallam-Baker Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 17:07:19 -0000 On Wed, Oct 4, 2017 at 9:34 AM, wrote: > > > On Wednesday, 4 October 2017, Tom Herbert wrote: >> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker >> wrote: >> > On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell >> > wrote: >> >> >> >> >> >> As currently described, I oppose creation of this working >> >> group on the basis that it enables and seemingly encourages >> >> embedding identifiers for humans as addresses. Doing so >> >> would have significant privacy downsides, would enable >> >> new methods for censorship and discrimination, and could >> >> be very hard to mitigate should one wish to help protect >> >> people's privacy, as I think is current IETF policy. >> >> >> >> If the work precluded the use of any identifiers that >> >> strongly map to humans then I'd be ok with it being done >> >> as it'd then only be a waste of resources. But I don't >> >> know how that could be enforced so I think it'd be better >> >> to just not do this work at all. >> >> >> >> S. >> > >> > >> > +1 >> > >> > I know how to restrict the work to 'meaningless' identifiers, require = that >> > the identifiers be the output of a cryptographic algorithm. >> > >> > Now strictly speaking, this only limits scope to identifiers that are >> > indexical as opposed to rendering them meaningless but I think that wa= s the >> > sense of it. >> > >> > >> > N=C3=B6th proposed a trichotemy of identifiers as follows >> > >> > * Identity, the signifier is the signified (e.g. data: URI) >> > >> > * Indexical, the signifier is related to the signified by a systematic >> > relationship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.) >> > >> > * Names, the signifier is the related to the signified by a purely >> > conventional relationship, (e.g. example.com to its owner) >> > >> > >> > There is a big difference between attempting to manage indexical signi= fiers >> > and names. Especially when the people trying to do so refuse to read a= ny of >> > the literature on semiotics. >> > >> > Names are problematic because the only way that a conventional relatio= nship >> > can be implemented is through some sort of registration infrastructure= and >> > we already have one of those and the industry that manages it has a >> > marketcap in the tens of billions. >> > >> > Identifiers do lead to tractable solutions. But, this proposal looks a= bit >> > unfocused for IRTF consideration, an IETF WG? Really? >> > >> Identifiers are equivalent to addresses in that they indicate a node >> in the network for the purposes of end to end communications. The only >> difference between identifiers and addresses is that identifiers are >> not topological. Virtual addresses in network virtualization are also >> identifiers. So the security properties are the same when considering >> privacy. For instance, if applications use temporary addresses for >> privacy, it would have equivalent properties using temporary >> identifiers. In fact from the application POV this would be >> transparent. It could get a pool of apparently random addresses to >> choose from as source of communication, it shouldn't know or even care >> if the addresses are identifiers. >> >> Identity is a completely separate concept from identifiers. Is not >> required in any of the identifier/locator protocols and AFAIK none of >> them even mention the term. There is no association of an identity of >> user behind and identifier any more than there is an association of >> identity behind IP address. The fact that the words "identifier" and >> "identity" share a common prefix is an unfortunate happenstance :-). > > > Yes. But doesn't that mean either the name of this effort is wildly misle= ading or else the effort is hugely problematic from a privacy POV? Either w= ay, istm this ought not proceed. > Stephen, There are two distinct efforts represented in IDEAS. One is a developing a common identifier/locator mapping system and the other is identity management. IMO the first is much more tangible and it's clear this is needed given the emergence of id/loc use in data center, mobile networks, as well as network virtualization. The identity effort is less clear in terms of feasibility, privacy, and benefits-- there might be something there, but honestly it looks much more like a research project to me at this point. Tom From nobody Wed Oct 4 11:48:15 2017 Return-Path: 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 5DBD4133055; Wed, 4 Oct 2017 11:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nxWoPZ4WGi-z; Wed, 4 Oct 2017 11:48:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64EC133023; Wed, 4 Oct 2017 11:48:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX33583; Wed, 04 Oct 2017 18:48:08 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 19:48:07 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 11:48:03 -0700 From: Alexander Clemm To: "stephen.farrell@cs.tcd.ie" , "tom@herbertland.com" CC: "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HtvaRdsDDgEqucGYSnlXKNaLMpUwAgAefuYCAABZuAIAABMSA//+mfxA= Date: Wed, 4 Oct 2017 18:48:03 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> In-Reply-To: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59D52CE9.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:48:14 -0000 VGhlcmUgd2VyZSBhIGNvdXBsZSBvZiB0aGluZ3MgcmFpc2VkIGluIHRoZSBvdmVyYWxsIHRocmVh ZCB0aGF0IEkganVzdCB3YW50ZWQgdG8gcXVpY2tseSByZXNwb25kIHRvOg0KDQpDbGVhcmx5IHBy aXZhY3kgaXMgYW4gaW1wb3J0YW50IGlzc3VlIGFuZCBjb25jZXJuLiAgVGhlIGN1cnJlbnQgY2hh cnRlciBwcm9wb3NhbCBpbmNsdWRlcyBhIHJlcXVpcmVtZW50IGZvciBhIGRldGFpbGVkIGFuYWx5 c2lzIG9mIHRoaXMgYXNwZWN0LiAgSWYgdGhpcyBhc3BlY3QgbmVlZHMgdG8gYmUgZXhwYW5kZWQs IHN1cmUsIGxldCdzIGRvIHRoaXMuICANCg0KRXZlcnlvbmUgc2VlbXMgdG8gYmUganVtcGluZyB1 cCBhbmQgZG93biByZWdhcmRpbmcgdGhlIHVzZSBvZiB0aGUgdGVybSBvZiAiaWRlbnRpdHkiIGFz IGlmIGEgZm9yZWdvbmUgY29uY2x1c2lvbiB0aGF0IHRoaXMgaXMgYSBzeW5vbnltIGZvciAicHJp dmFjeSBpbnZhc2lvbiIuICAgSG93ZXZlcjoNCi0gIklkZW50aXR5IiBkb2VzIG5vdCBpbXBseSAi cGVyc29uYWwgaWRlbnRpdHkiLiAgUmVhbGx5LCB0aGlzIGlzIGFuIGlkZW50aWZpZXIgc2NoZW1l IGZvciBlbmRwb2ludHMuICAgUGVyaGFwcyBldmVuICJpZGVudGl0eSIgaXMgYSBtaXNub21lci4g IElmIHlvdSB3aWxsLCBpZGVudGl0eSBhcyBjb25jZWl2ZWQgaW4gdGhlIGNvbnRleHQgb2YgSURF QVMgaXMgYSBzZWNvbmQgbGV2ZWwgb2YgaWRlbnRpZmllciB0aGF0IGRvZXMgbm90IGhhdmUgdG8g YmUgZXhwb3NlZCBvdmVyIHRoZSBkYXRhIHBsYW5lDQotIEJlY2F1c2Ugb2YgdGhpcywgaXQgbWF5 IHJlc3VsdCBpbiBncmVhdGVyIHByaXZhY3kgdGhhbiBleGlzdGluZyBzY2hlbWVzLCBub3QgbGVz cy4gIEl0IGVuYWJsZXMgeW91LCBmb3IgZXhhbXBsZSwgdG8gb2JmdXNjYXRlIGVuZHBvaW50cyB0 byBvdXRzaWRlIG9ic2VydmVycyBhcyB5b3Ugd291bGRuJ3QgbmVlZCB0byB1c2UgcGVyc29uYWwg dW5pcXVlIGxvbmctbGl2ZWQgaWRlbnRpZmllcnMsIHF1aXRlIHRoZSBjb250cmFyeS4gIA0KIC0g VGhlcmUgaXMgYWxzbyBhIHNlY3VyaXR5IGRpbWVuc2lvbiBoZXJlLiBJZiBJIGFtIHZpY3RpbSBv ZiBhIHBoaXNoaW5nIGF0dGFjayBiZWNhdXNlIG15IG5ldHdvcmsgaW5mb3JtYXRpb24gKGxpa2Ug dG9kYXkpIGlzIGV4cG9zZWQgdG8gYm90bmV0cywgcGhpc2hlcnMgZXRjIHdobyBjYW4gaGlkZSBm cm9tIG1lIChidXQgbm90IEkgZnJvbSB0aGVtKSBhbmQgcmVtYWluIGFub255bW91cyBvciBpbXBl cnNvbmF0ZSBsZWdpdGltYXRlIHVzZXJzLCBJIGRvIGNvbnNpZGVyIHRoaXMgYSB2ZXJ5IHNlcmlv dXMgdGhyZWF0IGFsc28gdG8gbXkgcHJpdmFjeS4gIEhvdyBjYW4gSUVURiBjb3VudGVyYWN0IHN1 Y2ggdGhyZWF0cz8gIEkgdGhpbmsgdGhhdCBJREVBUywgaWYgZG9uZSByaWdodCwgY2FuIHByb3Zp ZGUgYSBjb250cmlidXRpb24gaGVyZS4gIA0KDQpPbmUgYXNwZWN0IHRoYXQgaGFzIGJlZW4gbWlz c2luZyBmcm9tIHRoZSBkaXNjdXNzaW9uIGlzIHRoZSBxdWVzdGlvbiB3aGV0aGVyIHRoZXJlIGlz IGEgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGUgbmV0d29yayBwcm92aWRlciB3aG8gcHJvdmlkZXMg R1JJRFMgc2VydmljZXMgYW5kIGFuIG91dHNpZGUgYXR0YWNrZXIgLyBvYnNlcnZlci4gIEkgdGhp bmsgdGhpcyBkaXN0aW5jdGlvbiBpcyBpbXBvcnRhbnQuICBUaGUgd2F5IEkgc2VlIGl0LCBpZiBk b25lIHJpZ2h0IChzdXJlLCBiaWcgImlmIiwgYW5kIHJlcXVpcmluZyBkZXRhaWxlZCBhbmFseXNp cyksIElERUFTIGFzIEkgd291bGQgZW52aXNpb24gaXQgY2FuIGNvbnRyaWJ1dGUgZ3JlYXRseSB0 byBwcm92aWRlIGdyZWF0ZXIgc2VjdXJpdHkgYW5kIHByaXZhY3kgZnJvbSBvdXRzaWRlIGF0dGFj a2Vycy4gIEF0IHRoZSBzYW1lIHRpbWUsIGFzIGl0IGlzIGN1cnJlbnRseSBlbnZpc2lvbmVkLCB0 aGVyZSBjbGVhcmx5IGlzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGJldHdlZW4gYW4gZW50aXR5IGFu ZCB0aGUgcHJvdmlkZXIgb2YgIml0cyIgR1JJRFMgc2VydmljZXMuICBUaGUgbWFwcGluZyBkYXRh YmFzZSB3aWxsIGhhdmUgaW5mb3JtYXRpb24gYWJvdXQgbG9jYXRvci1pZGVudGlmaWVyIGFuZCBp ZGVudGlmaWVyLWlkZW50aWZpZXIgbWFwcGluZ3MsIHNvIEdSSURTIHdpbGwga25vdyB3aGljaCBp ZGVudGlmaWVycyBpdHMgZW5kcG9pbnRzIGFyZSB1c2luZy4gIENsZWFybHksIGlmIHRoaXMgdHJ1 c3QgaXMgYWJ1c2VkIGJlY2F1c2UgdGhlIHByb3ZpZGVyIGNhbm5vdCBiZSB0cnVzdGVkLCBpZiB5 b3UgYXJlIGNvbmNlcm5lZCB0aGF0IGl0IHNlbGxzIHlvdXIgZW5kcG9pbnTigJlzIGluZm9ybWF0 aW9uIHRvIHRoZSBtb2Igb3IgYSBzdXBwcmVzc2l2ZSBnb3Zlcm5tZW50LCB0aGVyZSBpcyBhbiBp c3N1ZS4gIEhvd2V2ZXIsIHdoZW4gY29uY2VybmVkIGFib3V0IHRoaXMgc2NlbmFyaW8sIGl0IHNl ZW1zIHRvIG1lIG9uZSB3b3VsZCBoYXZlIGVxdWFsIHJlYXNvbiB0byBlLmcuIG5vdCB0cnVzdCB5 b3VyIG1vYmlsZSBzZXJ2aWNlIHByb3ZpZGVyIGVpdGhlciwgd2hvIGNhbiB0cmFjayB5b3UsIGtu b3dzIHlvdXIgbG9jYXRpb24sIGFuZCBoYXMgeW91ciBjdXN0b21lciBkYXRhLiAgDQoNCi0tLSBB bGV4DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZGVhcyBbbWFp bHRvOmlkZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNCwgMjAxNyA5OjM1IEFN DQo+IFRvOiB0b21AaGVyYmVydGxhbmQuY29tDQo+IENjOiBpZGVhc0BpZXRmLm9yZzsgcGhpbGxA aGFsbGFtYmFrZXIuY29tOyBpZXRmQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWRlYXNdIFdH IFJldmlldzogSURlbnRpdHkgRW5hYmxlZCBOZXR3b3JrcyAoaWRlYXMpDQo+IA0KPiANCj4gDQo+ IE9uIFdlZG5lc2RheSwgNCBPY3RvYmVyIDIwMTcsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPiA+IE9u IFdlZCwgT2N0IDQsIDIwMTcgYXQgNzo1NyBBTSwgUGhpbGxpcCBIYWxsYW0tQmFrZXINCj4gPiA8 cGhpbGxAaGFsbGFtYmFrZXIuY29tPiB3cm90ZToNCj4gPiA+IE9uIEZyaSwgU2VwIDI5LCAyMDE3 IGF0IDI6MzEgUE0sIFN0ZXBoZW4gRmFycmVsbA0KPiA+ID4gPHN0ZXBoZW4uZmFycmVsbEBjcy50 Y2QuaWU+DQo+ID4gPiB3cm90ZToNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gQXMgY3VycmVudGx5 IGRlc2NyaWJlZCwgSSBvcHBvc2UgY3JlYXRpb24gb2YgdGhpcyB3b3JraW5nIGdyb3VwIG9uDQo+ ID4gPj4gdGhlIGJhc2lzIHRoYXQgaXQgZW5hYmxlcyBhbmQgc2VlbWluZ2x5IGVuY291cmFnZXMg ZW1iZWRkaW5nDQo+ID4gPj4gaWRlbnRpZmllcnMgZm9yIGh1bWFucyBhcyBhZGRyZXNzZXMuIERv aW5nIHNvIHdvdWxkIGhhdmUNCj4gPiA+PiBzaWduaWZpY2FudCBwcml2YWN5IGRvd25zaWRlcywg d291bGQgZW5hYmxlIG5ldyBtZXRob2RzIGZvcg0KPiA+ID4+IGNlbnNvcnNoaXAgYW5kIGRpc2Ny aW1pbmF0aW9uLCBhbmQgY291bGQgYmUgdmVyeSBoYXJkIHRvIG1pdGlnYXRlDQo+ID4gPj4gc2hv dWxkIG9uZSB3aXNoIHRvIGhlbHAgcHJvdGVjdCBwZW9wbGUncyBwcml2YWN5LCBhcyBJIHRoaW5r IGlzDQo+ID4gPj4gY3VycmVudCBJRVRGIHBvbGljeS4NCj4gPiA+Pg0KPiA+ID4+IElmIHRoZSB3 b3JrIHByZWNsdWRlZCB0aGUgdXNlIG9mIGFueSBpZGVudGlmaWVycyB0aGF0IHN0cm9uZ2x5IG1h cA0KPiA+ID4+IHRvIGh1bWFucyB0aGVuIEknZCBiZSBvayB3aXRoIGl0IGJlaW5nIGRvbmUgYXMg aXQnZCB0aGVuIG9ubHkgYmUgYQ0KPiA+ID4+IHdhc3RlIG9mIHJlc291cmNlcy4gQnV0IEkgZG9u J3Qga25vdyBob3cgdGhhdCBjb3VsZCBiZSBlbmZvcmNlZCBzbw0KPiA+ID4+IEkgdGhpbmsgaXQn ZCBiZSBiZXR0ZXIgdG8ganVzdCBub3QgZG8gdGhpcyB3b3JrIGF0IGFsbC4NCj4gPiA+Pg0KPiA+ ID4+IFMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ICsxDQo+ID4gPg0KPiA+ID4gSSBrbm93IGhvdyB0 byByZXN0cmljdCB0aGUgd29yayB0byAnbWVhbmluZ2xlc3MnIGlkZW50aWZpZXJzLA0KPiA+ID4g cmVxdWlyZSB0aGF0IHRoZSBpZGVudGlmaWVycyBiZSB0aGUgb3V0cHV0IG9mIGEgY3J5cHRvZ3Jh cGhpYyBhbGdvcml0aG0uDQo+ID4gPg0KPiA+ID4gTm93IHN0cmljdGx5IHNwZWFraW5nLCB0aGlz IG9ubHkgbGltaXRzIHNjb3BlIHRvIGlkZW50aWZpZXJzIHRoYXQNCj4gPiA+IGFyZSBpbmRleGlj YWwgYXMgb3Bwb3NlZCB0byByZW5kZXJpbmcgdGhlbSBtZWFuaW5nbGVzcyBidXQgSSB0aGluaw0K PiA+ID4gdGhhdCB3YXMgdGhlIHNlbnNlIG9mIGl0Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBOw7Z0 aCBwcm9wb3NlZCBhIHRyaWNob3RlbXkgb2YgaWRlbnRpZmllcnMgYXMgZm9sbG93cw0KPiA+ID4N Cj4gPiA+ICogSWRlbnRpdHksIHRoZSBzaWduaWZpZXIgaXMgdGhlIHNpZ25pZmllZCAoZS5nLiBk YXRhOiBVUkkpDQo+ID4gPg0KPiA+ID4gKiBJbmRleGljYWwsIHRoZSBzaWduaWZpZXIgaXMgcmVs YXRlZCB0byB0aGUgc2lnbmlmaWVkIGJ5IGENCj4gPiA+IHN5c3RlbWF0aWMgcmVsYXRpb25zaGlw LCAoZS5nLiBuaSBVUklzLCBTSEEyNTZEYXRhKSwgUEdQDQo+ID4gPiBmaW5nZXJwcmludHMgZXRj LikNCj4gPiA+DQo+ID4gPiAqIE5hbWVzLCAgdGhlIHNpZ25pZmllciBpcyB0aGUgcmVsYXRlZCB0 byB0aGUgc2lnbmlmaWVkIGJ5IGEgcHVyZWx5DQo+ID4gPiBjb252ZW50aW9uYWwgcmVsYXRpb25z aGlwLCAoZS5nLiBleGFtcGxlLmNvbSB0byBpdHMgb3duZXIpDQo+ID4gPg0KPiA+ID4NCj4gPiA+ IFRoZXJlIGlzIGEgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBhdHRlbXB0aW5nIHRvIG1hbmFnZSBp bmRleGljYWwNCj4gPiA+IHNpZ25pZmllcnMgYW5kIG5hbWVzLiBFc3BlY2lhbGx5IHdoZW4gdGhl IHBlb3BsZSB0cnlpbmcgdG8gZG8gc28NCj4gPiA+IHJlZnVzZSB0byByZWFkIGFueSBvZiB0aGUg bGl0ZXJhdHVyZSBvbiBzZW1pb3RpY3MuDQo+ID4gPg0KPiA+ID4gTmFtZXMgYXJlIHByb2JsZW1h dGljIGJlY2F1c2UgdGhlIG9ubHkgd2F5IHRoYXQgYSBjb252ZW50aW9uYWwNCj4gPiA+IHJlbGF0 aW9uc2hpcCBjYW4gYmUgaW1wbGVtZW50ZWQgaXMgdGhyb3VnaCBzb21lIHNvcnQgb2YgcmVnaXN0 cmF0aW9uDQo+ID4gPiBpbmZyYXN0cnVjdHVyZSBhbmQgd2UgYWxyZWFkeSBoYXZlIG9uZSBvZiB0 aG9zZSBhbmQgdGhlIGluZHVzdHJ5DQo+ID4gPiB0aGF0IG1hbmFnZXMgaXQgaGFzIGEgbWFya2V0 Y2FwIGluIHRoZSB0ZW5zIG9mIGJpbGxpb25zLg0KPiA+ID4NCj4gPiA+IElkZW50aWZpZXJzIGRv IGxlYWQgdG8gdHJhY3RhYmxlIHNvbHV0aW9ucy4gQnV0LCB0aGlzIHByb3Bvc2FsIGxvb2tzDQo+ ID4gPiBhIGJpdCB1bmZvY3VzZWQgZm9yIElSVEYgY29uc2lkZXJhdGlvbiwgYW4gSUVURiBXRz8g UmVhbGx5Pw0KPiA+ID4NCj4gPiBJZGVudGlmaWVycyBhcmUgZXF1aXZhbGVudCB0byBhZGRyZXNz ZXMgaW4gdGhhdCB0aGV5IGluZGljYXRlIGEgbm9kZQ0KPiA+IGluIHRoZSBuZXR3b3JrIGZvciB0 aGUgcHVycG9zZXMgb2YgZW5kIHRvIGVuZCBjb21tdW5pY2F0aW9ucy4gVGhlIG9ubHkNCj4gPiBk aWZmZXJlbmNlIGJldHdlZW4gaWRlbnRpZmllcnMgYW5kIGFkZHJlc3NlcyBpcyB0aGF0IGlkZW50 aWZpZXJzIGFyZQ0KPiA+IG5vdCB0b3BvbG9naWNhbC4gVmlydHVhbCBhZGRyZXNzZXMgaW4gbmV0 d29yayB2aXJ0dWFsaXphdGlvbiBhcmUgYWxzbw0KPiA+IGlkZW50aWZpZXJzLiBTbyB0aGUgc2Vj dXJpdHkgcHJvcGVydGllcyBhcmUgdGhlIHNhbWUgd2hlbiBjb25zaWRlcmluZw0KPiA+IHByaXZh Y3kuIEZvciBpbnN0YW5jZSwgaWYgYXBwbGljYXRpb25zIHVzZSB0ZW1wb3JhcnkgYWRkcmVzc2Vz IGZvcg0KPiA+IHByaXZhY3ksIGl0IHdvdWxkIGhhdmUgZXF1aXZhbGVudCBwcm9wZXJ0aWVzIHVz aW5nIHRlbXBvcmFyeQ0KPiA+IGlkZW50aWZpZXJzLiBJbiBmYWN0IGZyb20gdGhlIGFwcGxpY2F0 aW9uIFBPViB0aGlzIHdvdWxkIGJlDQo+ID4gdHJhbnNwYXJlbnQuIEl0IGNvdWxkIGdldCBhIHBv b2wgb2YgYXBwYXJlbnRseSByYW5kb20gYWRkcmVzc2VzIHRvDQo+ID4gY2hvb3NlIGZyb20gYXMg c291cmNlIG9mIGNvbW11bmljYXRpb24sIGl0IHNob3VsZG4ndCBrbm93IG9yIGV2ZW4gY2FyZQ0K PiA+IGlmIHRoZSBhZGRyZXNzZXMgYXJlIGlkZW50aWZpZXJzLg0KPiA+DQo+ID4gSWRlbnRpdHkg aXMgYSBjb21wbGV0ZWx5IHNlcGFyYXRlIGNvbmNlcHQgZnJvbSBpZGVudGlmaWVycy4gSXMgbm90 DQo+ID4gcmVxdWlyZWQgaW4gYW55IG9mIHRoZSBpZGVudGlmaWVyL2xvY2F0b3IgcHJvdG9jb2xz IGFuZCBBRkFJSyBub25lIG9mDQo+ID4gdGhlbSBldmVuIG1lbnRpb24gdGhlIHRlcm0uIFRoZXJl IGlzIG5vIGFzc29jaWF0aW9uIG9mIGFuIGlkZW50aXR5IG9mDQo+ID4gdXNlciBiZWhpbmQgYW5k IGlkZW50aWZpZXIgYW55IG1vcmUgdGhhbiB0aGVyZSBpcyBhbiBhc3NvY2lhdGlvbiBvZg0KPiA+ IGlkZW50aXR5IGJlaGluZCBJUCBhZGRyZXNzLiBUaGUgZmFjdCB0aGF0IHRoZSB3b3JkcyAiaWRl bnRpZmllciIgYW5kDQo+ID4gImlkZW50aXR5IiBzaGFyZSBhIGNvbW1vbiBwcmVmaXggaXMgYW4g dW5mb3J0dW5hdGUgaGFwcGVuc3RhbmNlIDotKS4NCj4gDQo+IA0KPiBZZXMuIEJ1dCBkb2Vzbid0 IHRoYXQgbWVhbiBlaXRoZXIgdGhlIG5hbWUgb2YgdGhpcyBlZmZvcnQgaXMgd2lsZGx5IG1pc2xl YWRpbmcNCj4gb3IgZWxzZSB0aGUgZWZmb3J0IGlzIGh1Z2VseSBwcm9ibGVtYXRpYyBmcm9tIGEg cHJpdmFjeSBQT1Y/IEVpdGhlciB3YXksIGlzdG0NCj4gdGhpcyBvdWdodCBub3QgcHJvY2VlZC4N Cj4gDQo+IFMuDQo+IA0KPiA+DQo+ID4gVG9tDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRlYXMgbWFpbGluZyBsaXN0DQo+IElkZWFz QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRlYXMN Cg== From nobody Wed Oct 4 12:13:28 2017 Return-Path: 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 4246C13305E; Wed, 4 Oct 2017 12:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 9LJ0YM2ygj5C; Wed, 4 Oct 2017 12:13:21 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF7F133039; Wed, 4 Oct 2017 12:13:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.42,478,1500966000"; d="asc'?scan'208";a="219509958" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 04 Oct 2017 11:43:24 -0700 Received: from VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Oct 2017 12:13:20 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Wed, 4 Oct 2017 12:13:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVFYSR7xAVa5XB9Q6WmKNAVjjgQErn80X124UByTaic=; b=BFwLIwgrFylBPM+NeO3padAsR+EpUdZc2tbaXU9yhOOwermjiIOER7PFb/TGBOxF7bR8fG84V1T64mgtyAc4IklG8DjpbkqYBmCV4t28Yk/D8ahIIa7VZcvD9roRT4h++DuoXtCeffUkjzkAAfFzj8zpZLxkUoEdsI6uTaXQajQ= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 4 Oct 2017 19:13:19 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0077.018; Wed, 4 Oct 2017 19:13:19 +0000 From: "Eggert, Lars" To: Stephen Farrell CC: "ietf@ietf.org" , "ideas@ietf.org" Thread-Topic: WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT35v3hyWdVoV0KqrqLEQ0bs66LML/QAgAfnOQA= Date: Wed, 4 Oct 2017 19:13:18 +0000 Message-ID: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> In-Reply-To: <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [50.206.82.160] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:D/JWnGGx9CFYYL5+dZNGqoN7KO3c1q5wrGQ91w157or5iEmXhea1pAUdNVqWrekdbm77T9GFSInJcVSgmkcdYfsI654Rs85cWEUePJwyrQAXxZg23Yl3cJe/2X03VdX57NURZdYCFtLKae8gX8pCwaP6zqZWEeiVDzC2aUMBPiVMAgaj8jpc8GaOLc2NQDHjy5cpvFAAgy42dyTqdri1/iyHQncaJS4NPQoFZbyBSp+ewwq9Ca8NYGceuIq6idDzplNPyyXwOnG5ghqPhnZ951lFokU87xDwAB634ti104r57r2/jvqfCyGs/g3a2N6IDXvQDqHzpP0gpFotvxl+bw==; 5:SBrHgl6WikL1dtIKTaP7m1yJq4S1yhqtD9kdifXUBqKc/Zj5PMMdGEtY0bTusM9jK42vAYoBxh+9jyXnIjUriF6YAkI9yYhjKUAZlOQMfTr9wH/w6onLLVlkY/bc1Dokq3LfTPmGJ+r9dxi8Cs8qOA==; 24:hIUkO3r3YIiO6eUKgiqLhHyfxBPxq05+YcH5aNY27lMfYN5+4dNqAY6ZfTlKFlT5vASdy8QnjTKerVKE/OtI+IoAURQRUSgWPPEHqEafYaI=; 7:0X3PPG5fTd2bJKQiZeVsqtoJiaIl53WSu66k2yvPwfuQw42Kzai0K8a85daI+3fG1LjoaszEjtfGjEarfCpNrRJqG2iRlCIFKZwdPIqzrjU7yTBeH8TbxmU1nJ4XOB9XYW63LgJEe575aTuVDGLzUycEmhJzJlydpgZPPDpqiaJgS2awCl+sCj3qHKmuixbY+F8A66RyGPWCPG6wqjG8kCywWpbdAa1iQ1Vvl2sgp+I= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ea7cb18b-1bc0-4711-da8d-08d50b5bf913 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-exchange-antispam-report-test: UriScan:(32856632585715); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1763; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(24454002)(377424004)(189002)(81156014)(6512007)(66066001)(3660700001)(3280700002)(2900100001)(68736007)(8676002)(81166006)(101416001)(6246003)(97736004)(99286003)(86362001)(2950100002)(14454004)(53936002)(106356001)(4001150100001)(6916009)(105586002)(57306001)(54906003)(36756003)(50226002)(6436002)(8936002)(4326008)(3846002)(5660300001)(305945005)(316002)(6116002)(77096006)(2906002)(478600001)(25786009)(53546010)(189998001)(50986999)(6506006)(6486002)(76176999)(99936001)(83716003)(33656002)(229853002)(7736002)(102836003)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_3734A9B8-62A1-488F-A55A-C928BD4C2588"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2017 19:13:18.8894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 19:13:22 -0000 --Apple-Mail=_3734A9B8-62A1-488F-A55A-C928BD4C2588 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2017-9-29, at 11:31, Stephen Farrell wrote: > As currently described, I oppose creation of this working > group +1, for the reasons below Lars > on the basis that it enables and seemingly encourages > embedding identifiers for humans as addresses. Doing so > would have significant privacy downsides, would enable > new methods for censorship and discrimination, and could > be very hard to mitigate should one wish to help protect > people's privacy, as I think is current IETF policy. > > If the work precluded the use of any identifiers that > strongly map to humans then I'd be ok with it being done > as it'd then only be a waste of resources. But I don't > know how that could be enforced so I think it'd be better > to just not do this work at all. --Apple-Mail=_3734A9B8-62A1-488F-A55A-C928BD4C2588 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlnVMswACgkQVLXDCb9w wVeOoA/+MOzcrbj7hUvm8Ji/lGzIzz48sKQMddZDXuUWCuca84ls6iKeMBdJz7a+ RxWZcgCzg89m/vjeAwt+DYWsu275DX2qQmFLlv/3dryLFgk0kzgyoLvXXC+ecWxk GZh6TwWDQmcB55Dy/3QwRUpilYFmmnzI7l1T8jxJgbKqKHox3sDC7aIW2qqUWZDx e8mrOfNllcd8TnLyfRc3N+4fe19CN0xVjZaUZOULWAzKQjhFCtkP18aNCKaG5DpJ lIspY7PiyhCzdv/NOZivtZIeasmoHA9WtnkCR3PIVZibWrLGfGBR8tMozvpySJEv 1c/NNsTUanGLeUYB0s/QsG1MjIVAkjUZwJqsU3dmwfkQcWvFUehD5oos6f55uTT0 peW/BWBYPcptFLYEQwXLswE5N/PhuMHXsOagCpa8JJzHR2tPiLSmkID9Uy5FrrYa VyTeIUnbt8ZLnWOD5caA/Qm6jcd+guhVfVn2DRqCq7nX7KU7fP4EmUDFih+aHXE7 H2I3ja2W8PLunu8MMaVHZMqsHuVRo1wa1fWT98TSG/oNwmY4/4RP0tTp304esSa6 SfcJeJjPd2LI/EM5H3JDpXBvBXVjkcTSWnA6mq1UeX+hKVq4niKHsl4vxQ+E/oki usDnarGWDJgLW9aDDCS/ywFSpYoJzfUZPThfDvACudBKLfLt6Cs= =DAtT -----END PGP SIGNATURE----- --Apple-Mail=_3734A9B8-62A1-488F-A55A-C928BD4C2588-- From nobody Wed Oct 4 12:45:22 2017 Return-Path: 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 EBDE2133079; Wed, 4 Oct 2017 12:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 XY58GwL1JpQf; Wed, 4 Oct 2017 12:45:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A0313217D; Wed, 4 Oct 2017 12:45:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0AEF8BE2F; Wed, 4 Oct 2017 20:45:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMj-Wzpg8jHY; Wed, 4 Oct 2017 20:45:11 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24DE7BE2E; Wed, 4 Oct 2017 20:45:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507146311; bh=0GWYeuypDiGHZqOtImTVXK/NlgN4jWZGJu6hf8lDANc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DJZzVxDGvV4xcvAqAZj7utxZWzxhb0h0mljGPurHh4BwGHCqXrEPgo0mHllQRxyFU nGUwNqs7SWQ/TmvzTPTJLeLFUL5ZO72Kssy7Lb0339AxRqt4uBYKyfFc6d5vQouW5j 6QSgaFQFHiQaNGuYlwvMq0kMaExh+6TfBNGPo7QQ= To: Alexander Clemm , "tom@herbertland.com" Cc: "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Oct 2017 20:45:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v0BQdUTJLccqWNdr3ATS5EGonPhvqqMqr" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 19:45:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v0BQdUTJLccqWNdr3ATS5EGonPhvqqMqr Content-Type: multipart/mixed; boundary="uA5hAacJl4TG0NMxIo3cShACnVtQSmVfS"; protected-headers="v1" From: Stephen Farrell To: Alexander Clemm , "tom@herbertland.com" Cc: "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" Message-ID: Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> --uA5hAacJl4TG0NMxIo3cShACnVtQSmVfS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, TL;DR - I am now even more convinced that this ought not go ahead. (Sorry;-) On 04/10/17 19:48, Alexander Clemm wrote: > There were a couple of things raised in the overall thread that I > just wanted to quickly respond to: >=20 > Clearly privacy is an important issue and concern. The current > charter proposal includes a requirement for a detailed analysis of > this aspect. If this aspect needs to be expanded, sure, let's do > this. TBH, I don't think that'd help, for me at least. I don't see any way in which such permanent strings representing identity can be defined to be usable as claimed and not be perniciously privacy invasive. So some promises to ponder the problem in charter text wouldn't do it for me. (And tbh, I've seen that can kicked down that road before, so I'm skeptical of such promises in general.) > Everyone seems to be jumping up and down regarding the use of the > term of "identity" as if a foregone conclusion that this is a synonym > for "privacy invasion". However: - "Identity" does not imply > "personal identity". Really, this is an identifier scheme for > endpoints. =20 Sorry, what I assume is the relevant draft [1] says the "identity" (denoted "IDy") is a "Unique and Permanent Identity" and that "Networks may treat traffic differently depending on the IDy of source or destination" and also seems to envisage a large logical database of everyone's IDy's: "Identity also allows to have metadata associated it to be applied, regardless of which IDf is used to refer it." (Where IDf is the identifier that'll later be mapped to a locator via, I assume, HIP or LISP or similar.) I think it's entirely correct to jump up and down about the privacy consequences of the above. (Not to mention the potential censorship and discriminatory aspects.) [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-0= 1 > Perhaps even "identity" is a misnomer. =20 Well, it was presumably your choice (where your =3D=3D some set of the proponents). If that's a mistake, then it seems a fairly fatal one - to get the name wrong for an effort all about mapping names to identifiers;-) > If you will, > identity as conceived in the context of IDEAS is a second level of > identifier that does not have to be exposed over the data plane - > Because of this, it may result in greater privacy than existing > schemes, not less.=20 I see that argument in [1] but I'm not buying it tbh. To get that level of protection from such an indirection, one would have to have something like Tor hidden services and perhaps one would have to *not* standardise the mapping from human meaningful identifiers to those used as IDf, and esp. not the reverse mapping. Defining that reverse mapping cannot but be privacy invasive afaics. (There could maybe be ways to define how an already hashed human meaningful identifier could then be further hashed to become an IDy but I don't really see the point of that at all, other than to just standardise something for the fun of the process.) > It enables you, for example, to obfuscate > endpoints to outside observers as you wouldn't need to use personal > unique long-lived identifiers, quite the contrary. - There is also a > security dimension here. If I am victim of a phishing attack because > my network information (like today) is exposed to botnets,=20 (Nit: that says nothing about being a victim of, only of being a target of, an attempted attack. Speaking of victims also tends not to lead to more objective analysis, so I think it's better to not go there unless it's relevant, which I don't think is the case here, because...) I don't understand what network information you mean. If you mean email addresses, and are proposing that the email ecosystem change to use some IDf or LOC values, that doesn't seem at all realistic to me. If you don't mean email addresses then I don't see how any lower layer change will affect attempted phishes. The routing area is probably also the entirely wrong venue for any real anti-phishing effort. That really wasn't a good example;-) > phishers > etc who can hide from me (but not I from them) and remain anonymous > or impersonate legitimate users, I do consider this a very serious > threat also to my privacy. How can IETF counteract such threats? I > think that IDEAS, if done right, can provide a contribution here. I don't see that at all. Unless I'm mistaken that seems like wishful thinking to me. >=20 > One aspect that has been missing from the discussion is the question > whether there is a distinction between the network provider who > provides GRIDS services and an outside attacker / observer. I think > this distinction is important. The way I see it, if done right > (sure, big "if", and requiring detailed analysis), IDEAS as I would > envision it can contribute greatly to provide greater security and > privacy from outside attackers. At the same time, as it is currently > envisioned, there clearly is a trust relationship between an entity > and the provider of "its" GRIDS services. The mapping database will > have information about locator-identifier and identifier-identifier > mappings, so GRIDS will know which identifiers its endpoints are > using. Clearly, if this trust is abused because the provider cannot > be trusted, if you are concerned that it sells your endpoint=C3=A2=E2=82= =AC=E2=84=A2s > information to the mob or a suppressive government, there is an > issue. However, when concerned about this scenario, it seems to me > one would have equal reason to e.g. not trust your mobile service > provider either, who can track you, knows your location, and has your > customer data. ISTM that introducing that GRIDS thing makes matters worse and not better, because, as you yourself say, it is clear that whoever has access to the GRIDS information would be better able to track people compared to now. I would prefer to see fewer long lived identifiers in networking and not more, and this proposal introduces more long lived identifiers (erroneously calling those identities). Regardless of what one thinks of them, given that things like HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit adding this extra layer of indirection with a privacy invasive "Unique and Permanent" identifier which seems to be the only non-overlapping part of this work - in fact I only see downsides. Cheers, S. >=20 > --- Alex >=20 >=20 >> -----Original Message----- From: Ideas >> [mailto:ideas-bounces@ietf.org] On Behalf Of=20 >> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 9:35 >> AM To: tom@herbertland.com Cc: ideas@ietf.org; >> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG >> Review: IDentity Enabled Networks (ideas) >>=20 >>=20 >>=20 >> On Wednesday, 4 October 2017, Tom Herbert wrote: >>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker=20 >>> wrote: >>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell=20 >>>> wrote: >>>>>=20 >>>>>=20 >>>>> As currently described, I oppose creation of this working >>>>> group on the basis that it enables and seemingly encourages >>>>> embedding identifiers for humans as addresses. Doing so would >>>>> have significant privacy downsides, would enable new methods >>>>> for censorship and discrimination, and could be very hard to >>>>> mitigate should one wish to help protect people's privacy, as >>>>> I think is current IETF policy. >>>>>=20 >>>>> If the work precluded the use of any identifiers that >>>>> strongly map to humans then I'd be ok with it being done as >>>>> it'd then only be a waste of resources. But I don't know how >>>>> that could be enforced so I think it'd be better to just not >>>>> do this work at all. >>>>>=20 >>>>> S. >>>>=20 >>>>=20 >>>> +1 >>>>=20 >>>> I know how to restrict the work to 'meaningless' identifiers,=20 >>>> require that the identifiers be the output of a cryptographic >>>> algorithm. >>>>=20 >>>> Now strictly speaking, this only limits scope to identifiers >>>> that are indexical as opposed to rendering them meaningless but >>>> I think that was the sense of it. >>>>=20 >>>>=20 >>>> N=C3=83=C2=B6th proposed a trichotemy of identifiers as follows >>>>=20 >>>> * Identity, the signifier is the signified (e.g. data: URI) >>>>=20 >>>> * Indexical, the signifier is related to the signified by a=20 >>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP=20 >>>> fingerprints etc.) >>>>=20 >>>> * Names, the signifier is the related to the signified by a >>>> purely conventional relationship, (e.g. example.com to its >>>> owner) >>>>=20 >>>>=20 >>>> There is a big difference between attempting to manage >>>> indexical signifiers and names. Especially when the people >>>> trying to do so refuse to read any of the literature on >>>> semiotics. >>>>=20 >>>> Names are problematic because the only way that a conventional=20 >>>> relationship can be implemented is through some sort of >>>> registration infrastructure and we already have one of those >>>> and the industry that manages it has a marketcap in the tens of >>>> billions. >>>>=20 >>>> Identifiers do lead to tractable solutions. But, this proposal >>>> looks a bit unfocused for IRTF consideration, an IETF WG? >>>> Really? >>>>=20 >>> Identifiers are equivalent to addresses in that they indicate a >>> node in the network for the purposes of end to end >>> communications. The only difference between identifiers and >>> addresses is that identifiers are not topological. Virtual >>> addresses in network virtualization are also identifiers. So the >>> security properties are the same when considering privacy. For >>> instance, if applications use temporary addresses for privacy, it >>> would have equivalent properties using temporary identifiers. In >>> fact from the application POV this would be transparent. It could >>> get a pool of apparently random addresses to choose from as >>> source of communication, it shouldn't know or even care if the >>> addresses are identifiers. >>>=20 >>> Identity is a completely separate concept from identifiers. Is >>> not required in any of the identifier/locator protocols and AFAIK >>> none of them even mention the term. There is no association of an >>> identity of user behind and identifier any more than there is an >>> association of identity behind IP address. The fact that the >>> words "identifier" and "identity" share a common prefix is an >>> unfortunate happenstance :-). >>=20 >>=20 >> Yes. But doesn't that mean either the name of this effort is wildly >> misleading or else the effort is hugely problematic from a privacy >> POV? Either way, istm this ought not proceed. >>=20 >> S. >>=20 >>>=20 >>> Tom >>>=20 >> _______________________________________________ Ideas mailing list=20 >> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas --uA5hAacJl4TG0NMxIo3cShACnVtQSmVfS-- --v0BQdUTJLccqWNdr3ATS5EGonPhvqqMqr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ1TpGAAoJEC88hzaAX42ijdAH/jvkGUvFzPAdm33HGTeeXJSC viHPHxFfnjQckv7V/PK+Y2YA4PZNBRwU7Ehv1jozBpQuXy6Z0Zx6dFZDJ9pr6SsZ 5SB6j25EiHwmGrdFyvgYHRskWuzrbmWah4GxUffonQRDNz9x6zIpWDjN2fHaYl1t rD684vkkZr/Hu0guvjXOXUZeGjE3w88qmR57HYAnPoTg7xZUZ0SJvbfipsMBmRqE kCiyhX9zSUmyTSWMl7gAq5PM9S3/B9D8/M6fJyQ/gJ5T+lx/Yh3z+uCsHbX3eqkn PqvEeqeinTE3Zups/DI2yUqCSjsSQW5gVZyMpYuIB+uDcn5/Gkba7nfVVQLn4nY= =tIcK -----END PGP SIGNATURE----- --v0BQdUTJLccqWNdr3ATS5EGonPhvqqMqr-- From nobody Wed Oct 4 13:35:48 2017 Return-Path: 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 BB6BA134485; Wed, 4 Oct 2017 13:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 IqpKFs-IV6FP; Wed, 4 Oct 2017 13:35:36 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 C628C126B6D; Wed, 4 Oct 2017 13:35:36 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id m18so1012328pgd.13; Wed, 04 Oct 2017 13:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=duMlAHVY0QH7MwJPo6caLf3gIUMG/9ck8nPM3IUlXzU=; b=P+yX20UU9M2iXgPq5b6FhVULqsUbikGhTuRv9FugqBUPsf5QrIlbrCEmm4jzQ+fWUF yJBSz4qwXRb6jc25dCnq4lz86UI0cQ9BXsaQCEtlwxk8BOvOp0tKTLtUVBrd175rSf5q p7RI3HyVpoNX73jfvAuKnW0mX6fSJ1nE/1Nt07+SpW+HWCvgoT7UertUBIHBOqlGDnoB s/Wn79hm7yuc+xc+HJ2xL4x54U3PTR79egZKUdDq8RLc9aQqRuQQl0T88axhyjir2nA9 G9SIbOV7H8oPR7JoxUY2eCYQuXKNB9TFG/a/pHPi6QaV4WmHncGhfguD8myYmEOevQjk QU+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=duMlAHVY0QH7MwJPo6caLf3gIUMG/9ck8nPM3IUlXzU=; b=D0fybi3T4SknSKJV7IcyPrsIB8oQU48qdB8kknw5ONlPR8r+i1xb1iI+QOVHC6slaA RzJpkpVjAJWeN5HD5pxfYoaJtKgoh52xmx/82WZIIv7RahHQ/2dWk7gjsnnhg6Oe26oy K9OUWc4JWqptNfFkd/gAOcFpsXPZ/5mRJbzWXrGYoDpn1o6pmFlU/ldhwmA8OAOflbtb BtLvRY3QyuFqiiRIjxHpv7qG220KTiF9deSvZhqf9hNq/9wwcUfpW2n2YNyXMYtM3MG+ XrF13dI6B0E5GFaU+TdtlKL/kr1pHmunZOWKiMPkMOGGGypwa4iuBlGubq2+ujFvrIFg 4Uxg== X-Gm-Message-State: AMCzsaUBvzv19usJvkZ1ZdSw/rLh3mzKQGaqAwKrZUNUStbtHa9ZRHTJ 8ioWIbdnYTXSQ3Kj3dC2axg= X-Google-Smtp-Source: AOwi7QBGpqNZZN6eqpIaKgVB4nZwtc6GccODtJfssKdRN5MvOXJeDWfdVBTTVbfSSOysIQE9FG7H8w== X-Received: by 10.99.103.68 with SMTP id b65mr11100095pgc.271.1507149336286; Wed, 04 Oct 2017 13:35:36 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id g68sm25709075pfb.120.2017.10.04.13.35.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 13:35:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dino Farinacci In-Reply-To: Date: Wed, 4 Oct 2017 13:35:32 -0700 Cc: Alexander Clemm , Tom Herbert , "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" , "lisp@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 20:35:40 -0000 Adding lisp@ietf.org to cc list. How about creating a working group that solely focuses on deployment of = a mapping system and does not specify how and where identifiers are = allocated? I have made suggestions before that such a working group should be in = the ops area. Some examples include and are not limited to v6ops, dnsop, = and mboned. Cheers, Dino > On Oct 4, 2017, at 12:45 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > TL;DR - I am now even more convinced that this ought not > go ahead. (Sorry;-) >=20 > On 04/10/17 19:48, Alexander Clemm wrote: >> There were a couple of things raised in the overall thread that I >> just wanted to quickly respond to: >>=20 >> Clearly privacy is an important issue and concern. The current >> charter proposal includes a requirement for a detailed analysis of >> this aspect. If this aspect needs to be expanded, sure, let's do >> this. >=20 > TBH, I don't think that'd help, for me at least. I don't > see any way in which such permanent strings representing > identity can be defined to be usable as claimed and not > be perniciously privacy invasive. So some promises to > ponder the problem in charter text wouldn't do it for > me. (And tbh, I've seen that can kicked down that road > before, so I'm skeptical of such promises in general.) >=20 >> Everyone seems to be jumping up and down regarding the use of the >> term of "identity" as if a foregone conclusion that this is a synonym >> for "privacy invasion". However: - "Identity" does not imply >> "personal identity". Really, this is an identifier scheme for >> endpoints. =20 >=20 > Sorry, what I assume is the relevant draft [1] says the "identity" > (denoted "IDy") is a "Unique and Permanent Identity" and that > "Networks may treat traffic differently depending on the IDy of > source or destination" and also seems to envisage a large logical > database of everyone's IDy's: "Identity also allows to have metadata > associated it to be applied, regardless of which IDf is used to > refer it." (Where IDf is the identifier that'll later be mapped > to a locator via, I assume, HIP or LISP or similar.) >=20 > I think it's entirely correct to jump up and down about the > privacy consequences of the above. (Not to mention the potential > censorship and discriminatory aspects.) >=20 > [1] = https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01 >=20 >> Perhaps even "identity" is a misnomer. =20 >=20 > Well, it was presumably your choice (where your =3D=3D some set of > the proponents). If that's a mistake, then it seems a fairly > fatal one - to get the name wrong for an effort all about mapping > names to identifiers;-) >=20 >> If you will, >> identity as conceived in the context of IDEAS is a second level of >> identifier that does not have to be exposed over the data plane - >> Because of this, it may result in greater privacy than existing >> schemes, not less.=20 >=20 > I see that argument in [1] but I'm not buying it tbh. To get > that level of protection from such an indirection, one would > have to have something like Tor hidden services and perhaps > one would have to *not* standardise the mapping from human > meaningful identifiers to those used as IDf, and esp. not the > reverse mapping. Defining that reverse mapping cannot but be > privacy invasive afaics. (There could maybe be ways to define > how an already hashed human meaningful identifier could then > be further hashed to become an IDy but I don't really see the > point of that at all, other than to just standardise something > for the fun of the process.) >=20 >> It enables you, for example, to obfuscate >> endpoints to outside observers as you wouldn't need to use personal >> unique long-lived identifiers, quite the contrary. - There is also a >> security dimension here. If I am victim of a phishing attack because >> my network information (like today) is exposed to botnets,=20 >=20 > (Nit: that says nothing about being a victim of, only of being > a target of, an attempted attack. Speaking of victims also > tends not to lead to more objective analysis, so I think it's > better to not go there unless it's relevant, which I don't > think is the case here, because...) >=20 > I don't understand what network information you mean. If you > mean email addresses, and are proposing that the email ecosystem > change to use some IDf or LOC values, that doesn't seem at all > realistic to me. If you don't mean email addresses then I don't > see how any lower layer change will affect attempted phishes. > The routing area is probably also the entirely wrong venue for > any real anti-phishing effort. >=20 > That really wasn't a good example;-) >=20 >> phishers >> etc who can hide from me (but not I from them) and remain anonymous >> or impersonate legitimate users, I do consider this a very serious >> threat also to my privacy. How can IETF counteract such threats? I >> think that IDEAS, if done right, can provide a contribution here. >=20 > I don't see that at all. Unless I'm mistaken that seems like > wishful thinking to me. >=20 >>=20 >> One aspect that has been missing from the discussion is the question >> whether there is a distinction between the network provider who >> provides GRIDS services and an outside attacker / observer. I think >> this distinction is important. The way I see it, if done right >> (sure, big "if", and requiring detailed analysis), IDEAS as I would >> envision it can contribute greatly to provide greater security and >> privacy from outside attackers. At the same time, as it is currently >> envisioned, there clearly is a trust relationship between an entity >> and the provider of "its" GRIDS services. The mapping database will >> have information about locator-identifier and identifier-identifier >> mappings, so GRIDS will know which identifiers its endpoints are >> using. Clearly, if this trust is abused because the provider cannot >> be trusted, if you are concerned that it sells your endpoint=C3=A2=E2=82= =AC=E2=84=A2s >> information to the mob or a suppressive government, there is an >> issue. However, when concerned about this scenario, it seems to me >> one would have equal reason to e.g. not trust your mobile service >> provider either, who can track you, knows your location, and has your >> customer data. >=20 > ISTM that introducing that GRIDS thing makes matters worse and not > better, because, as you yourself say, it is clear that whoever has > access to the GRIDS information would be better able to track people > compared to now. >=20 > I would prefer to see fewer long lived identifiers in networking > and not more, and this proposal introduces more long lived identifiers > (erroneously calling those identities). >=20 > Regardless of what one thinks of them, given that things like > HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit > adding this extra layer of indirection with a privacy invasive > "Unique and Permanent" identifier which seems to be the only > non-overlapping part of this work - in fact I only see downsides. >=20 > Cheers, > S. >=20 >=20 >>=20 >> --- Alex >>=20 >>=20 >>> -----Original Message----- From: Ideas >>> [mailto:ideas-bounces@ietf.org] On Behalf Of=20 >>> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 9:35 >>> AM To: tom@herbertland.com Cc: ideas@ietf.org; >>> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG >>> Review: IDentity Enabled Networks (ideas) >>>=20 >>>=20 >>>=20 >>> On Wednesday, 4 October 2017, Tom Herbert wrote: >>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker=20 >>>> wrote: >>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell=20 >>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>> As currently described, I oppose creation of this working >>>>>> group on the basis that it enables and seemingly encourages >>>>>> embedding identifiers for humans as addresses. Doing so would >>>>>> have significant privacy downsides, would enable new methods >>>>>> for censorship and discrimination, and could be very hard to >>>>>> mitigate should one wish to help protect people's privacy, as >>>>>> I think is current IETF policy. >>>>>>=20 >>>>>> If the work precluded the use of any identifiers that >>>>>> strongly map to humans then I'd be ok with it being done as >>>>>> it'd then only be a waste of resources. But I don't know how >>>>>> that could be enforced so I think it'd be better to just not >>>>>> do this work at all. >>>>>>=20 >>>>>> S. >>>>>=20 >>>>>=20 >>>>> +1 >>>>>=20 >>>>> I know how to restrict the work to 'meaningless' identifiers,=20 >>>>> require that the identifiers be the output of a cryptographic >>>>> algorithm. >>>>>=20 >>>>> Now strictly speaking, this only limits scope to identifiers >>>>> that are indexical as opposed to rendering them meaningless but >>>>> I think that was the sense of it. >>>>>=20 >>>>>=20 >>>>> N=C3=83=C2=B6th proposed a trichotemy of identifiers as follows >>>>>=20 >>>>> * Identity, the signifier is the signified (e.g. data: URI) >>>>>=20 >>>>> * Indexical, the signifier is related to the signified by a=20 >>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP=20 >>>>> fingerprints etc.) >>>>>=20 >>>>> * Names, the signifier is the related to the signified by a >>>>> purely conventional relationship, (e.g. example.com to its >>>>> owner) >>>>>=20 >>>>>=20 >>>>> There is a big difference between attempting to manage >>>>> indexical signifiers and names. Especially when the people >>>>> trying to do so refuse to read any of the literature on >>>>> semiotics. >>>>>=20 >>>>> Names are problematic because the only way that a conventional=20 >>>>> relationship can be implemented is through some sort of >>>>> registration infrastructure and we already have one of those >>>>> and the industry that manages it has a marketcap in the tens of >>>>> billions. >>>>>=20 >>>>> Identifiers do lead to tractable solutions. But, this proposal >>>>> looks a bit unfocused for IRTF consideration, an IETF WG? >>>>> Really? >>>>>=20 >>>> Identifiers are equivalent to addresses in that they indicate a >>>> node in the network for the purposes of end to end >>>> communications. The only difference between identifiers and >>>> addresses is that identifiers are not topological. Virtual >>>> addresses in network virtualization are also identifiers. So the >>>> security properties are the same when considering privacy. For >>>> instance, if applications use temporary addresses for privacy, it >>>> would have equivalent properties using temporary identifiers. In >>>> fact from the application POV this would be transparent. It could >>>> get a pool of apparently random addresses to choose from as >>>> source of communication, it shouldn't know or even care if the >>>> addresses are identifiers. >>>>=20 >>>> Identity is a completely separate concept from identifiers. Is >>>> not required in any of the identifier/locator protocols and AFAIK >>>> none of them even mention the term. There is no association of an >>>> identity of user behind and identifier any more than there is an >>>> association of identity behind IP address. The fact that the >>>> words "identifier" and "identity" share a common prefix is an >>>> unfortunate happenstance :-). >>>=20 >>>=20 >>> Yes. But doesn't that mean either the name of this effort is wildly >>> misleading or else the effort is hugely problematic from a privacy >>> POV? Either way, istm this ought not proceed. >>>=20 >>> S. >>>=20 >>>>=20 >>>> Tom >>>>=20 >>> _______________________________________________ Ideas mailing list=20= >>> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas >=20 > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Wed Oct 4 13:46:53 2017 Return-Path: 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 E0A7D1331E7; Wed, 4 Oct 2017 13:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 or1mrK8UQpaT; Wed, 4 Oct 2017 13:46:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC38613307B; Wed, 4 Oct 2017 13:46:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2955BE38; Wed, 4 Oct 2017 21:46:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmRSn4L3IfVf; Wed, 4 Oct 2017 21:46:43 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C94DBDD8; Wed, 4 Oct 2017 21:46:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507150003; bh=ft2nVRVRO+f8oYspfkLGITM7ywm2L7eGJhjgi0ZsoHY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AgjvLMSQTB9jPRKX8f3kpl0kswEOrK8/U8tysRRgyck9bupHUrMTPGIaG0pRat4F4 JXPpphC93sjHDzjZpHB5e87MeySnG8aqaPpr81S0ug6hxxOvwAs3cRbtYrYU2bPy9J QLcVvrGd+2aMZUP+9SCJmCAbr6ryUnUTXIJTDtH4= To: Dino Farinacci Cc: Alexander Clemm , Tom Herbert , "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" , "lisp@ietf.org list" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4846459e-7ce5-a5ce-be8e-5854838dc244@cs.tcd.ie> Date: Wed, 4 Oct 2017 21:46:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Np1AnoqIqJjJGrExM86qutM1wo1WX6F7B" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 20:46:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Np1AnoqIqJjJGrExM86qutM1wo1WX6F7B Content-Type: multipart/mixed; boundary="vLixmrQQpXTB5fmmrNAavgsepHfV29uxF"; protected-headers="v1" From: Stephen Farrell To: Dino Farinacci Cc: Alexander Clemm , Tom Herbert , "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" , "lisp@ietf.org list" Message-ID: <4846459e-7ce5-a5ce-be8e-5854838dc244@cs.tcd.ie> Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> In-Reply-To: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> --vLixmrQQpXTB5fmmrNAavgsepHfV29uxF Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Dino, On 04/10/17 21:35, Dino Farinacci wrote: > Adding lisp@ietf.org to cc list. >=20 > How about creating a working group that solely focuses on deployment > of a mapping system and does not specify how and where identifiers > are allocated? >=20 > I have made suggestions before that such a working group should be in > the ops area. Some examples include and are not limited to v6ops, > dnsop, and mboned. If there's deployment of things like LISP and HIP and folks are interested in discussing/documenting what they've been doing in the ops area then that seems quite reasonable sure. S. >=20 > Cheers, Dino >=20 >> On Oct 4, 2017, at 12:45 PM, Stephen Farrell >> wrote: >>=20 >>=20 >> Hiya, >>=20 >> TL;DR - I am now even more convinced that this ought not go ahead. >> (Sorry;-) >>=20 >> On 04/10/17 19:48, Alexander Clemm wrote: >>> There were a couple of things raised in the overall thread that >>> I just wanted to quickly respond to: >>>=20 >>> Clearly privacy is an important issue and concern. The current=20 >>> charter proposal includes a requirement for a detailed analysis >>> of this aspect. If this aspect needs to be expanded, sure, let's >>> do this. >>=20 >> TBH, I don't think that'd help, for me at least. I don't see any >> way in which such permanent strings representing identity can be >> defined to be usable as claimed and not be perniciously privacy >> invasive. So some promises to ponder the problem in charter text >> wouldn't do it for me. (And tbh, I've seen that can kicked down >> that road before, so I'm skeptical of such promises in general.) >>=20 >>> Everyone seems to be jumping up and down regarding the use of >>> the term of "identity" as if a foregone conclusion that this is a >>> synonym for "privacy invasion". However: - "Identity" does not >>> imply "personal identity". Really, this is an identifier scheme >>> for endpoints. >>=20 >> Sorry, what I assume is the relevant draft [1] says the "identity"=20 >> (denoted "IDy") is a "Unique and Permanent Identity" and that=20 >> "Networks may treat traffic differently depending on the IDy of=20 >> source or destination" and also seems to envisage a large logical=20 >> database of everyone's IDy's: "Identity also allows to have >> metadata associated it to be applied, regardless of which IDf is >> used to refer it." (Where IDf is the identifier that'll later be >> mapped to a locator via, I assume, HIP or LISP or similar.) >>=20 >> I think it's entirely correct to jump up and down about the privacy >> consequences of the above. (Not to mention the potential censorship >> and discriminatory aspects.) >>=20 >> [1] >> https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01 >>=20 >>> Perhaps even "identity" is a misnomer. >>=20 >> Well, it was presumably your choice (where your =3D=3D some set of the= >> proponents). If that's a mistake, then it seems a fairly fatal one >> - to get the name wrong for an effort all about mapping names to >> identifiers;-) >>=20 >>> If you will, identity as conceived in the context of IDEAS is a >>> second level of identifier that does not have to be exposed over >>> the data plane - Because of this, it may result in greater >>> privacy than existing schemes, not less. >>=20 >> I see that argument in [1] but I'm not buying it tbh. To get that >> level of protection from such an indirection, one would have to >> have something like Tor hidden services and perhaps one would have >> to *not* standardise the mapping from human meaningful identifiers >> to those used as IDf, and esp. not the reverse mapping. Defining >> that reverse mapping cannot but be privacy invasive afaics. (There >> could maybe be ways to define how an already hashed human >> meaningful identifier could then be further hashed to become an IDy >> but I don't really see the point of that at all, other than to just >> standardise something for the fun of the process.) >>=20 >>> It enables you, for example, to obfuscate endpoints to outside >>> observers as you wouldn't need to use personal unique long-lived >>> identifiers, quite the contrary. - There is also a security >>> dimension here. If I am victim of a phishing attack because my >>> network information (like today) is exposed to botnets, >>=20 >> (Nit: that says nothing about being a victim of, only of being a >> target of, an attempted attack. Speaking of victims also tends not >> to lead to more objective analysis, so I think it's better to not >> go there unless it's relevant, which I don't think is the case >> here, because...) >>=20 >> I don't understand what network information you mean. If you mean >> email addresses, and are proposing that the email ecosystem change >> to use some IDf or LOC values, that doesn't seem at all realistic >> to me. If you don't mean email addresses then I don't see how any >> lower layer change will affect attempted phishes. The routing area >> is probably also the entirely wrong venue for any real >> anti-phishing effort. >>=20 >> That really wasn't a good example;-) >>=20 >>> phishers etc who can hide from me (but not I from them) and >>> remain anonymous or impersonate legitimate users, I do consider >>> this a very serious threat also to my privacy. How can IETF >>> counteract such threats? I think that IDEAS, if done right, can >>> provide a contribution here. >>=20 >> I don't see that at all. Unless I'm mistaken that seems like=20 >> wishful thinking to me. >>=20 >>>=20 >>> One aspect that has been missing from the discussion is the >>> question whether there is a distinction between the network >>> provider who provides GRIDS services and an outside attacker / >>> observer. I think this distinction is important. The way I see >>> it, if done right (sure, big "if", and requiring detailed >>> analysis), IDEAS as I would envision it can contribute greatly to >>> provide greater security and privacy from outside attackers. At >>> the same time, as it is currently envisioned, there clearly is a >>> trust relationship between an entity and the provider of "its" >>> GRIDS services. The mapping database will have information about >>> locator-identifier and identifier-identifier mappings, so GRIDS >>> will know which identifiers its endpoints are using. Clearly, if >>> this trust is abused because the provider cannot be trusted, if >>> you are concerned that it sells your endpoint=C3=A2=E2=82=AC=E2=84=A2= s information to >>> the mob or a suppressive government, there is an issue. However, >>> when concerned about this scenario, it seems to me one would have >>> equal reason to e.g. not trust your mobile service provider >>> either, who can track you, knows your location, and has your=20 >>> customer data. >>=20 >> ISTM that introducing that GRIDS thing makes matters worse and not=20 >> better, because, as you yourself say, it is clear that whoever has=20 >> access to the GRIDS information would be better able to track >> people compared to now. >>=20 >> I would prefer to see fewer long lived identifiers in networking=20 >> and not more, and this proposal introduces more long lived >> identifiers (erroneously calling those identities). >>=20 >> Regardless of what one thinks of them, given that things like HIP >> and LISP exist, and try tackle the ID/LOC split, I see no benefit=20 >> adding this extra layer of indirection with a privacy invasive=20 >> "Unique and Permanent" identifier which seems to be the only=20 >> non-overlapping part of this work - in fact I only see downsides. >>=20 >> Cheers, S. >>=20 >>=20 >>>=20 >>> --- Alex >>>=20 >>>=20 >>>> -----Original Message----- From: Ideas=20 >>>> [mailto:ideas-bounces@ietf.org] On Behalf Of=20 >>>> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 >>>> 9:35 AM To: tom@herbertland.com Cc: ideas@ietf.org;=20 >>>> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG=20 >>>> Review: IDentity Enabled Networks (ideas) >>>>=20 >>>>=20 >>>>=20 >>>> On Wednesday, 4 October 2017, Tom Herbert wrote: >>>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker=20 >>>>> wrote: >>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell=20 >>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> As currently described, I oppose creation of this >>>>>>> working group on the basis that it enables and seemingly >>>>>>> encourages embedding identifiers for humans as addresses. >>>>>>> Doing so would have significant privacy downsides, would >>>>>>> enable new methods for censorship and discrimination, and >>>>>>> could be very hard to mitigate should one wish to help >>>>>>> protect people's privacy, as I think is current IETF >>>>>>> policy. >>>>>>>=20 >>>>>>> If the work precluded the use of any identifiers that=20 >>>>>>> strongly map to humans then I'd be ok with it being done >>>>>>> as it'd then only be a waste of resources. But I don't >>>>>>> know how that could be enforced so I think it'd be better >>>>>>> to just not do this work at all. >>>>>>>=20 >>>>>>> S. >>>>>>=20 >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> I know how to restrict the work to 'meaningless' >>>>>> identifiers, require that the identifiers be the output of >>>>>> a cryptographic algorithm. >>>>>>=20 >>>>>> Now strictly speaking, this only limits scope to >>>>>> identifiers that are indexical as opposed to rendering them >>>>>> meaningless but I think that was the sense of it. >>>>>>=20 >>>>>>=20 >>>>>> N=C3=83=C2=B6th proposed a trichotemy of identifiers as follows >>>>>>=20 >>>>>> * Identity, the signifier is the signified (e.g. data: >>>>>> URI) >>>>>>=20 >>>>>> * Indexical, the signifier is related to the signified by a >>>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP=20 >>>>>> fingerprints etc.) >>>>>>=20 >>>>>> * Names, the signifier is the related to the signified by >>>>>> a purely conventional relationship, (e.g. example.com to >>>>>> its owner) >>>>>>=20 >>>>>>=20 >>>>>> There is a big difference between attempting to manage=20 >>>>>> indexical signifiers and names. Especially when the people=20 >>>>>> trying to do so refuse to read any of the literature on=20 >>>>>> semiotics. >>>>>>=20 >>>>>> Names are problematic because the only way that a >>>>>> conventional relationship can be implemented is through >>>>>> some sort of registration infrastructure and we already >>>>>> have one of those and the industry that manages it has a >>>>>> marketcap in the tens of billions. >>>>>>=20 >>>>>> Identifiers do lead to tractable solutions. But, this >>>>>> proposal looks a bit unfocused for IRTF consideration, an >>>>>> IETF WG? Really? >>>>>>=20 >>>>> Identifiers are equivalent to addresses in that they indicate >>>>> a node in the network for the purposes of end to end=20 >>>>> communications. The only difference between identifiers and=20 >>>>> addresses is that identifiers are not topological. Virtual=20 >>>>> addresses in network virtualization are also identifiers. So >>>>> the security properties are the same when considering >>>>> privacy. For instance, if applications use temporary >>>>> addresses for privacy, it would have equivalent properties >>>>> using temporary identifiers. In fact from the application POV >>>>> this would be transparent. It could get a pool of apparently >>>>> random addresses to choose from as source of communication, >>>>> it shouldn't know or even care if the addresses are >>>>> identifiers. >>>>>=20 >>>>> Identity is a completely separate concept from identifiers. >>>>> Is not required in any of the identifier/locator protocols >>>>> and AFAIK none of them even mention the term. There is no >>>>> association of an identity of user behind and identifier any >>>>> more than there is an association of identity behind IP >>>>> address. The fact that the words "identifier" and "identity" >>>>> share a common prefix is an unfortunate happenstance :-). >>>>=20 >>>>=20 >>>> Yes. But doesn't that mean either the name of this effort is >>>> wildly misleading or else the effort is hugely problematic from >>>> a privacy POV? Either way, istm this ought not proceed. >>>>=20 >>>> S. >>>>=20 >>>>>=20 >>>>> Tom >>>>>=20 >>>> _______________________________________________ Ideas mailing >>>> list Ideas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ideas >>=20 >> _______________________________________________ Ideas mailing list=20 >> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas >=20 >=20 --vLixmrQQpXTB5fmmrNAavgsepHfV29uxF-- --Np1AnoqIqJjJGrExM86qutM1wo1WX6F7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ1UiyAAoJEC88hzaAX42izTEH/3SWQmhEt148VZFbzlHQvpLS WAq4Uq+0EVRgP9HHPP91P9B1StqZy5HUTyXhU4Q//OKLHIuyJBNjvncCs89ROqI/ KbbjDoP5eohyB4oAv2CyligVZbgaMJZpiqQEVDwRdcCbyhXD64Zq+xMd+T+1zD60 IZiUGx7L+QyM5udzu3XBAcwLTzMCFBKPzS4ecF+P05cp+dP7Zuskh0TXC3GPu5rB 2XpgsnWDnr1sy8Sc5R0UfewuU9u/YKIM+28EuZ7ubK6PU+9oN6x3vQ3q7WrbD9aB HMWVJ+Co2fECL+nuU8oQNuQRCFQa8QB5Rv236Jilvbo+uhTDZblT9wpu7Pu+Gv8= =CLaD -----END PGP SIGNATURE----- --Np1AnoqIqJjJGrExM86qutM1wo1WX6F7B-- From nobody Wed Oct 4 14:26:24 2017 Return-Path: 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 89862132D54; Wed, 4 Oct 2017 14:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pCcqN2E-J5Uj; Wed, 4 Oct 2017 14:26:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349D61344C9; Wed, 4 Oct 2017 14:26:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW05974; Wed, 04 Oct 2017 21:26:17 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 22:26:16 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 14:26:06 -0700 From: Uma Chunduri To: Stephen Farrell , Alexander Clemm , "tom@herbertland.com" CC: "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLMpUwAgAefuYCAABZuAIAABMSAgAAlQ4CAAA/0gP//oBpQ Date: Wed, 4 Oct 2017 21:26:05 +0000 Message-ID: <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.59D551FA.0073, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:26:22 -0000 SGkgU3RlcGhlbiwNCg0KICAgICAgICAgICAgICAgID4gLi4gaW5mb3JtYXRpb24gd291bGQgYmUg YmV0dGVyIGFibGUgdG8gdHJhY2sgcGVvcGxlIGNvbXBhcmVkIHRvIG5vdy4NCg0KVGhpcyBpcyBu b3QgYWJvdXQgcGVvcGxlLi4NCg0KCT5SZWdhcmRsZXNzIG9mIHdoYXQgb25lIHRoaW5rcyBvZiB0 aGVtLCBnaXZlbiB0aGF0IHRoaW5ncyBsaWtlIEhJUCBhbmQgTElTUCBleGlzdCwgYW5kIHRyeSB0 YWNrbGUgdGhlIElEL0xPQyBzcGxpdCwgSSBzZWUgbm8gYmVuZWZpdCBhZGRpbmcgdGhpcyBleHRy YSBsYXllciBvZiBpbmRpcmVjdGlvbiB3aXRoIGEgcHJpdmFjeSBpbnZhc2l2ZSAiVW5pcXVlIGFu ZCBQZXJtYW5lbnQiIGlkZW50aWZpZXINCiAgICAgICAgICAgICAgICA+d2hpY2ggc2VlbXMgdG8g YmUgdGhlIG9ubHkgbm9uLW92ZXJsYXBwaW5nIHBhcnQgb2YgdGhpcyB3b3JrIC0gaW4gZmFjdCBJ IG9ubHkgc2VlIGRvd25zaWRlcy4NCg0KRldJVywNClRoaXMgaXMgYWxzbyB0byBlbmFibGUgc2Vj dXJpdHkgYW5kIGFjY2VzcyByZXN0cmljdGlvbnMgdG8gdGhlIG5ldyBicmVlZCBvZiBkZXZpY2Vz IG9uIHRoZSBuZXR3b3JrIChJb1Qgb3Igb3RoZXIgbW9iaWxpdHkgIG5vZGVzKS4gSnVzdCBiZWNh dXNlIG9mIHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgb24gdGhlIG5ldHdvcmsgd2l0aCBhbiBhZGRy ZXNzIHRoZXkgc2hvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIGJlIGFjY2Vzc2libGUuIA0KQXV0aGVu dGljYXRpb24gd2l0aCBhIHRydXN0ZWQgSWRQIHdvdWxkIGVuYWJsZSBlc3RhYmxpc2hpbmcgdGhl IHR5cGUgb2YgdGhlIHR5cGUgb2YgZGV2aWNlLCB3aGljaCB0aGVuIGFsbG93cyBncm91cCBiYXNl ZCBwb2xpY2llcyB0byBiZSBlbmZvcmNlYWJsZSAoYSBWMlggbm9kZSBjYW4gdGFsayB0byBvbmx5 IHNhbWUga2luZCBvZiBub2RlIG9yIGEgcGFydGljdWxhciBJb1QgY2FuIGJlIGFjY2Vzc2VkIGJ5 IG9ubHkgcGFydGljdWxhciBkZXZpY2UpLiANCkFzIGRpc2N1c3NlZCBlYXJsaWVyIGluIHRoZSBs aXN0IHBlcmhhcHMgaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9hYmZhYi8gY2FuIGJlIGxvb2tl ZCBpbnRvIGJ1aWxkIHRoaXMgZmVkZXJhdGVkIHN5c3RlbSBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRv Y3VtZW50Lg0KSSBhbHNvIHNlZSB5b3UgYXJlIGFyZ3VpbmcodW5mb3J0dW5hdGVseSkgIGFnYWlu c3QgeW91ciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1OCBkb2N1bWVudCwgd2hl cmUgdGhpcyBjYW4gYmUgb25lIG1vcmUgcG90ZW50aWFsIG1pdGlnYXRpb24gdG9vbCB3LnIudCBk ZXZpY2UgYW5vbnltaXR5IChhcGFydCBmcm9tIGVuY3J5cHQgZXZlcnl0aGluZy9UQ1BJTkMgLSB3 aGljaCBzZXJ2ZXMgYSBkaWZmZXJlbnQgYW5kIGltcG9ydGFudCBwdXJwb3NlIGZvciBjb250ZW50 IHByaXZhY3kgdy5yLnQgbW9uaXRvcmluZykuDQoNCkkgZG9uJ3Qgc2VlIGEgZnVsbHkgZnVuY3Rp b25hbCBtYXBwaW5nIHN5c3RlbSB3aXRob3V0IGFueSBhdXRoZW50aWNhdGlvbiBpbnRvIHRoZSBz eXN0ZW0gYnkgdGhlIGRldmljZS9ub2RlIGZvciB0aGUgbWFwcGluZy4gVGhpcyBoYXMgYmVlbiBh bHdheXMgdGhlIGNhc2UgaW4gdGhlIGNlbGx1bGFyIHdvcmxkIGFuZCBpdCBzZWVtcyB3ZSBhcmUg YWxsIG9rYXkgd2l0aCBpdCBhbmQgdG9kYXkgaXQncyA4MCslIG9mIHRoZSB0b3RhbCB0cmFmZmlj Lg0KIEl0IHdvdWxkIGJlIGdyZWF0IGlmIHlvdSBjYW4gc3VnZ2VzdCB3aGljaCBjYW4gbWVldCB0 aGlzIG9iamVjdGl2ZSBpbiBtb3JlIGJhbGFuY2VkIHdheS4uLg0KDQotLQ0KVW1hIEMuDQo= From nobody Wed Oct 4 14:39:19 2017 Return-Path: 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 07C6C1344C9; Wed, 4 Oct 2017 14:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ygyo-knJuwgM; Wed, 4 Oct 2017 14:39:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EE9133073; Wed, 4 Oct 2017 14:39:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX48072; Wed, 04 Oct 2017 21:39:12 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 22:39:11 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 14:39:04 -0700 From: Padmadevi Pillay Esnault To: Tom Herbert , Stephen Farrell CC: "ideas@ietf.org" , Phillip Hallam-Baker , IETF-Discussion Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT3ymgzcYyPwiEG9DUxoovk7IqLMpU0AgAefuICAABZvAIAABMOAgAAJFYD//8wzkA== Date: Wed, 4 Oct 2017 21:39:03 +0000 Message-ID: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.212] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59D55501.0057, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:39:18 -0000 VGhhbmsgeW91IGZvciB2b2ljaW5nIHlvdXIgY29uY2VybnMgDQoib24gdGhlIGJhc2lzIHRoYXQg aXQgZW5hYmxlcyBhbmQgc2VlbWluZ2x5IGVuY291cmFnZXMgZW1iZWRkaW5nICBpZGVudGlmaWVy cyBmb3IgaHVtYW5zIGFzIGFkZHJlc3NlcyINCg0KVGhpcyBpcyBub3QgdGhlIG9iamVjdGl2ZSBv ciBpbiB0aGUgY2hhcnRlciBvZiB0aGlzIHdnIGFzIHlvdSBwb2ludCBvdXQgdGhpcyB3b3VsZCBi ZSBhZ2FpbnN0IHRoZSBwb2xpY3kuDQpQZXJoYXBzIHRoaXMgY2FuIGJlIG1hZGUgY2xlYXJlciBp biB0aGUgY2hhcnRlciAtIHRoaXMgaXMgYWJvdXQgbWFjaGluZXMgYW5kIHByb2Nlc3Nlcy4NCg0K IklmIHRoZSB3b3JrIHByZWNsdWRlZCB0aGUgdXNlIG9mIGFueSBpZGVudGlmaWVycyB0aGF0IHN0 cm9uZ2x5IG1hcCAgdG8gaHVtYW5zIHRoZW4gSSdkIGJlIG9rIHdpdGggaXQgYmVpbmcgZG9uZSBh cyBpdCdkIHRoZW4gb25seSBiZSBhIHdhc3RlIG9mIHJlc291cmNlcy4iDQoNCldlbGwgaXQgcmVh bGx5IGRlcGVuZHMgaW4gd2hpY2ggY29udGV4dCB0aGlzIHdvcmsgaXMgYmVpbmcgdXNlZC4NCkxv b2tpbmcgYXQgc29tZSBvZiB0aGUgcG9zdGluZ3MsIGl0IHNlZW1zIHRoYXQgYWRkaW5nIG1vcmUg Y29udGV4dCBvbiB0aGUgcHJvYmxlbSBzcGFjZSB3b3VsZCBoZWxwIHRvIGJyaW5nIG1vcmUgY2xh cml0eSBvbiB0aGUgY2hhcnRlci4NCg0KUGFkbWEgDQoNCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IElkZWFzIFttYWlsdG86aWRlYXMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEVnZ2VydCwgDQo+ID4gTGFycw0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAwNCwgMjAxNyAxMjoxMyBQTQ0KPiA+IFRvOiBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU+DQo+ID4gQ2M6IGlkZWFzQGlldGYub3JnOyBpZXRmQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUmU6IFtJZGVhc10gV0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5l dHdvcmtzIChpZGVhcykNCj4gPg0KPiA+IE9uIDIwMTctOS0yOSwgYXQgMTE6MzEsIFN0ZXBoZW4g RmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+ID4gPiBBcyBjdXJy ZW50bHkgZGVzY3JpYmVkLCBJIG9wcG9zZSBjcmVhdGlvbiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAN Cj4gPg0KPiA+ICsxLCBmb3IgdGhlIHJlYXNvbnMgYmVsb3cNCj4gPg0KPiA+IExhcnMNCj4gPg0K PiA+ID4gb24gdGhlIGJhc2lzIHRoYXQgaXQgZW5hYmxlcyBhbmQgc2VlbWluZ2x5IGVuY291cmFn ZXMgZW1iZWRkaW5nIA0KPiA+ID4gaWRlbnRpZmllcnMgZm9yIGh1bWFucyBhcyBhZGRyZXNzZXMu IERvaW5nIHNvIHdvdWxkIGhhdmUgDQo+ID4gPiBzaWduaWZpY2FudCBwcml2YWN5IGRvd25zaWRl cywgd291bGQgZW5hYmxlIG5ldyBtZXRob2RzIGZvciANCj4gPiA+IGNlbnNvcnNoaXAgYW5kIGRp c2NyaW1pbmF0aW9uLCBhbmQgY291bGQgYmUgdmVyeSBoYXJkIHRvIG1pdGlnYXRlIA0KPiA+ID4g c2hvdWxkIG9uZSB3aXNoIHRvIGhlbHAgcHJvdGVjdCBwZW9wbGUncyBwcml2YWN5LCBhcyBJIHRo aW5rIGlzIGN1cnJlbnQgSUVURiBwb2xpY3kuDQo+ID4gPg0KPiA+ID4gSWYgdGhlIHdvcmsgcHJl Y2x1ZGVkIHRoZSB1c2Ugb2YgYW55IGlkZW50aWZpZXJzIHRoYXQgc3Ryb25nbHkgbWFwIA0KPiA+ ID4gdG8gaHVtYW5zIHRoZW4gSSdkIGJlIG9rIHdpdGggaXQgYmVpbmcgZG9uZSBhcyBpdCdkIHRo ZW4gb25seSBiZSBhIA0KPiA+ID4gd2FzdGUgb2YgcmVzb3VyY2VzLiBCdXQgSSBkb24ndCBrbm93 IGhvdyB0aGF0IGNvdWxkIGJlIGVuZm9yY2VkIHNvIA0KPiA+ID4gSSB0aGluayBpdCdkIGJlIGJl dHRlciB0byBqdXN0IG5vdCBkbyB0aGlzIHdvcmsgYXQgYWxsLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSWRlYXMgW21haWx0bzppZGVhcy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVG9tIEhlcmJlcnQNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNCwgMjAx NyAxMDowNyBBTQ0KVG86IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZT4NCkNjOiBpZGVhc0BpZXRmLm9yZzsgUGhpbGxpcCBIYWxsYW0tQmFrZXIgPHBoaWxsQGhhbGxh bWJha2VyLmNvbT47IElFVEYtRGlzY3Vzc2lvbiA8aWV0ZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbSWRlYXNdIFdHIFJldmlldzogSURlbnRpdHkgRW5hYmxlZCBOZXR3b3JrcyAoaWRlYXMpDQoN Ck9uIFdlZCwgT2N0IDQsIDIwMTcgYXQgOTozNCBBTSwgIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllPiB3cm90ZToNCj4NCj4NCj4gT24gV2VkbmVzZGF5LCA0IE9jdG9iZXIgMjAxNywgVG9tIEhl cmJlcnQgd3JvdGU6DQo+PiBPbiBXZWQsIE9jdCA0LCAyMDE3IGF0IDc6NTcgQU0sIFBoaWxsaXAg SGFsbGFtLUJha2VyIA0KPj4gPHBoaWxsQGhhbGxhbWJha2VyLmNvbT4gd3JvdGU6DQo+PiA+IE9u IEZyaSwgU2VwIDI5LCAyMDE3IGF0IDI6MzEgUE0sIFN0ZXBoZW4gRmFycmVsbCANCj4+ID4gPHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQo+PiA+IHdyb3RlOg0KPj4gPj4NCj4+ID4+DQo+PiA+ PiBBcyBjdXJyZW50bHkgZGVzY3JpYmVkLCBJIG9wcG9zZSBjcmVhdGlvbiBvZiB0aGlzIHdvcmtp bmcgZ3JvdXAgb24gDQo+PiA+PiB0aGUgYmFzaXMgdGhhdCBpdCBlbmFibGVzIGFuZCBzZWVtaW5n bHkgZW5jb3VyYWdlcyBlbWJlZGRpbmcgDQo+PiA+PiBpZGVudGlmaWVycyBmb3IgaHVtYW5zIGFz IGFkZHJlc3Nlcy4gRG9pbmcgc28gd291bGQgaGF2ZSANCj4+ID4+IHNpZ25pZmljYW50IHByaXZh Y3kgZG93bnNpZGVzLCB3b3VsZCBlbmFibGUgbmV3IG1ldGhvZHMgZm9yIA0KPj4gPj4gY2Vuc29y c2hpcCBhbmQgZGlzY3JpbWluYXRpb24sIGFuZCBjb3VsZCBiZSB2ZXJ5IGhhcmQgdG8gbWl0aWdh dGUgDQo+PiA+PiBzaG91bGQgb25lIHdpc2ggdG8gaGVscCBwcm90ZWN0IHBlb3BsZSdzIHByaXZh Y3ksIGFzIEkgdGhpbmsgaXMgDQo+PiA+PiBjdXJyZW50IElFVEYgcG9saWN5Lg0KPj4gPj4NCj4+ ID4+IElmIHRoZSB3b3JrIHByZWNsdWRlZCB0aGUgdXNlIG9mIGFueSBpZGVudGlmaWVycyB0aGF0 IHN0cm9uZ2x5IG1hcCANCj4+ID4+IHRvIGh1bWFucyB0aGVuIEknZCBiZSBvayB3aXRoIGl0IGJl aW5nIGRvbmUgYXMgaXQnZCB0aGVuIG9ubHkgYmUgYSANCj4+ID4+IHdhc3RlIG9mIHJlc291cmNl cy4gQnV0IEkgZG9uJ3Qga25vdyBob3cgdGhhdCBjb3VsZCBiZSBlbmZvcmNlZCBzbyANCj4+ID4+ IEkgdGhpbmsgaXQnZCBiZSBiZXR0ZXIgdG8ganVzdCBub3QgZG8gdGhpcyB3b3JrIGF0IGFsbC4N Cj4+ID4+DQo+PiA+PiBTLg0KPj4gPg0KPj4gPg0KPj4gPiArMQ0KPj4gPg0KPj4gPiBJIGtub3cg aG93IHRvIHJlc3RyaWN0IHRoZSB3b3JrIHRvICdtZWFuaW5nbGVzcycgaWRlbnRpZmllcnMsIA0K Pj4gPiByZXF1aXJlIHRoYXQgdGhlIGlkZW50aWZpZXJzIGJlIHRoZSBvdXRwdXQgb2YgYSBjcnlw dG9ncmFwaGljIGFsZ29yaXRobS4NCj4+ID4NCj4+ID4gTm93IHN0cmljdGx5IHNwZWFraW5nLCB0 aGlzIG9ubHkgbGltaXRzIHNjb3BlIHRvIGlkZW50aWZpZXJzIHRoYXQgDQo+PiA+IGFyZSBpbmRl eGljYWwgYXMgb3Bwb3NlZCB0byByZW5kZXJpbmcgdGhlbSBtZWFuaW5nbGVzcyBidXQgSSB0aGlu ayANCj4+ID4gdGhhdCB3YXMgdGhlIHNlbnNlIG9mIGl0Lg0KPj4gPg0KPj4gPg0KPj4gPiBOw7Z0 aCBwcm9wb3NlZCBhIHRyaWNob3RlbXkgb2YgaWRlbnRpZmllcnMgYXMgZm9sbG93cw0KPj4gPg0K Pj4gPiAqIElkZW50aXR5LCB0aGUgc2lnbmlmaWVyIGlzIHRoZSBzaWduaWZpZWQgKGUuZy4gZGF0 YTogVVJJKQ0KPj4gPg0KPj4gPiAqIEluZGV4aWNhbCwgdGhlIHNpZ25pZmllciBpcyByZWxhdGVk IHRvIHRoZSBzaWduaWZpZWQgYnkgYSANCj4+ID4gc3lzdGVtYXRpYyByZWxhdGlvbnNoaXAsIChl LmcuIG5pIFVSSXMsIFNIQTI1NkRhdGEpLCBQR1AgDQo+PiA+IGZpbmdlcnByaW50cyBldGMuKQ0K Pj4gPg0KPj4gPiAqIE5hbWVzLCAgdGhlIHNpZ25pZmllciBpcyB0aGUgcmVsYXRlZCB0byB0aGUg c2lnbmlmaWVkIGJ5IGEgcHVyZWx5IA0KPj4gPiBjb252ZW50aW9uYWwgcmVsYXRpb25zaGlwLCAo ZS5nLiBleGFtcGxlLmNvbSB0byBpdHMgb3duZXIpDQo+PiA+DQo+PiA+DQo+PiA+IFRoZXJlIGlz IGEgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBhdHRlbXB0aW5nIHRvIG1hbmFnZSBpbmRleGljYWwg DQo+PiA+IHNpZ25pZmllcnMgYW5kIG5hbWVzLiBFc3BlY2lhbGx5IHdoZW4gdGhlIHBlb3BsZSB0 cnlpbmcgdG8gZG8gc28gDQo+PiA+IHJlZnVzZSB0byByZWFkIGFueSBvZiB0aGUgbGl0ZXJhdHVy ZSBvbiBzZW1pb3RpY3MuDQo+PiA+DQo+PiA+IE5hbWVzIGFyZSBwcm9ibGVtYXRpYyBiZWNhdXNl IHRoZSBvbmx5IHdheSB0aGF0IGEgY29udmVudGlvbmFsIA0KPj4gPiByZWxhdGlvbnNoaXAgY2Fu IGJlIGltcGxlbWVudGVkIGlzIHRocm91Z2ggc29tZSBzb3J0IG9mIA0KPj4gPiByZWdpc3RyYXRp b24gaW5mcmFzdHJ1Y3R1cmUgYW5kIHdlIGFscmVhZHkgaGF2ZSBvbmUgb2YgdGhvc2UgYW5kIA0K Pj4gPiB0aGUgaW5kdXN0cnkgdGhhdCBtYW5hZ2VzIGl0IGhhcyBhIG1hcmtldGNhcCBpbiB0aGUg dGVucyBvZiBiaWxsaW9ucy4NCj4+ID4NCj4+ID4gSWRlbnRpZmllcnMgZG8gbGVhZCB0byB0cmFj dGFibGUgc29sdXRpb25zLiBCdXQsIHRoaXMgcHJvcG9zYWwgDQo+PiA+IGxvb2tzIGEgYml0IHVu Zm9jdXNlZCBmb3IgSVJURiBjb25zaWRlcmF0aW9uLCBhbiBJRVRGIFdHPyBSZWFsbHk/DQo+PiA+ DQo+PiBJZGVudGlmaWVycyBhcmUgZXF1aXZhbGVudCB0byBhZGRyZXNzZXMgaW4gdGhhdCB0aGV5 IGluZGljYXRlIGEgbm9kZSANCj4+IGluIHRoZSBuZXR3b3JrIGZvciB0aGUgcHVycG9zZXMgb2Yg ZW5kIHRvIGVuZCBjb21tdW5pY2F0aW9ucy4gVGhlIA0KPj4gb25seSBkaWZmZXJlbmNlIGJldHdl ZW4gaWRlbnRpZmllcnMgYW5kIGFkZHJlc3NlcyBpcyB0aGF0IGlkZW50aWZpZXJzIA0KPj4gYXJl IG5vdCB0b3BvbG9naWNhbC4gVmlydHVhbCBhZGRyZXNzZXMgaW4gbmV0d29yayB2aXJ0dWFsaXph dGlvbiBhcmUgDQo+PiBhbHNvIGlkZW50aWZpZXJzLiBTbyB0aGUgc2VjdXJpdHkgcHJvcGVydGll cyBhcmUgdGhlIHNhbWUgd2hlbiANCj4+IGNvbnNpZGVyaW5nIHByaXZhY3kuIEZvciBpbnN0YW5j ZSwgaWYgYXBwbGljYXRpb25zIHVzZSB0ZW1wb3JhcnkgDQo+PiBhZGRyZXNzZXMgZm9yIHByaXZh Y3ksIGl0IHdvdWxkIGhhdmUgZXF1aXZhbGVudCBwcm9wZXJ0aWVzIHVzaW5nIA0KPj4gdGVtcG9y YXJ5IGlkZW50aWZpZXJzLiBJbiBmYWN0IGZyb20gdGhlIGFwcGxpY2F0aW9uIFBPViB0aGlzIHdv dWxkIGJlIA0KPj4gdHJhbnNwYXJlbnQuIEl0IGNvdWxkIGdldCBhIHBvb2wgb2YgYXBwYXJlbnRs eSByYW5kb20gYWRkcmVzc2VzIHRvIA0KPj4gY2hvb3NlIGZyb20gYXMgc291cmNlIG9mIGNvbW11 bmljYXRpb24sIGl0IHNob3VsZG4ndCBrbm93IG9yIGV2ZW4gDQo+PiBjYXJlIGlmIHRoZSBhZGRy ZXNzZXMgYXJlIGlkZW50aWZpZXJzLg0KPj4NCj4+IElkZW50aXR5IGlzIGEgY29tcGxldGVseSBz ZXBhcmF0ZSBjb25jZXB0IGZyb20gaWRlbnRpZmllcnMuIElzIG5vdCANCj4+IHJlcXVpcmVkIGlu IGFueSBvZiB0aGUgaWRlbnRpZmllci9sb2NhdG9yIHByb3RvY29scyBhbmQgQUZBSUsgbm9uZSBv ZiANCj4+IHRoZW0gZXZlbiBtZW50aW9uIHRoZSB0ZXJtLiBUaGVyZSBpcyBubyBhc3NvY2lhdGlv biBvZiBhbiBpZGVudGl0eSBvZiANCj4+IHVzZXIgYmVoaW5kIGFuZCBpZGVudGlmaWVyIGFueSBt b3JlIHRoYW4gdGhlcmUgaXMgYW4gYXNzb2NpYXRpb24gb2YgDQo+PiBpZGVudGl0eSBiZWhpbmQg SVAgYWRkcmVzcy4gVGhlIGZhY3QgdGhhdCB0aGUgd29yZHMgImlkZW50aWZpZXIiIGFuZCANCj4+ ICJpZGVudGl0eSIgc2hhcmUgYSBjb21tb24gcHJlZml4IGlzIGFuIHVuZm9ydHVuYXRlIGhhcHBl bnN0YW5jZSA6LSkuDQo+DQo+DQo+IFllcy4gQnV0IGRvZXNuJ3QgdGhhdCBtZWFuIGVpdGhlciB0 aGUgbmFtZSBvZiB0aGlzIGVmZm9ydCBpcyB3aWxkbHkgbWlzbGVhZGluZyBvciBlbHNlIHRoZSBl ZmZvcnQgaXMgaHVnZWx5IHByb2JsZW1hdGljIGZyb20gYSBwcml2YWN5IFBPVj8gRWl0aGVyIHdh eSwgaXN0bSB0aGlzIG91Z2h0IG5vdCBwcm9jZWVkLg0KPg0KU3RlcGhlbiwNCg0KVGhlcmUgYXJl IHR3byBkaXN0aW5jdCBlZmZvcnRzIHJlcHJlc2VudGVkIGluIElERUFTLiBPbmUgaXMgYSBkZXZl bG9waW5nIGEgY29tbW9uIGlkZW50aWZpZXIvbG9jYXRvciBtYXBwaW5nIHN5c3RlbSBhbmQgdGhl IG90aGVyIGlzIGlkZW50aXR5IG1hbmFnZW1lbnQuIElNTyB0aGUgZmlyc3QgaXMgbXVjaCBtb3Jl IHRhbmdpYmxlIGFuZCBpdCdzIGNsZWFyIHRoaXMgaXMgbmVlZGVkIGdpdmVuIHRoZSBlbWVyZ2Vu Y2Ugb2YgaWQvbG9jIHVzZSBpbiBkYXRhIGNlbnRlciwgbW9iaWxlIG5ldHdvcmtzLCBhcyB3ZWxs IGFzIG5ldHdvcmsgdmlydHVhbGl6YXRpb24uIFRoZSBpZGVudGl0eSBlZmZvcnQgaXMgbGVzcyBj bGVhciBpbiB0ZXJtcyBvZiBmZWFzaWJpbGl0eSwgcHJpdmFjeSwgYW5kIGJlbmVmaXRzLS0gdGhl cmUgbWlnaHQgYmUgc29tZXRoaW5nIHRoZXJlLCBidXQgaG9uZXN0bHkgaXQgbG9va3MgbXVjaCBt b3JlIGxpa2UgYSByZXNlYXJjaCBwcm9qZWN0IHRvIG1lIGF0IHRoaXMgcG9pbnQuDQoNClRvbQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRlYXMg bWFpbGluZyBsaXN0DQpJZGVhc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZGVhcw0K From nobody Wed Oct 4 14:41:59 2017 Return-Path: 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 C884B1321A2; Wed, 4 Oct 2017 14:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 iriUvU7EiX4y; Wed, 4 Oct 2017 14:41:50 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9E1344C9; Wed, 4 Oct 2017 14:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D05602D0E1; Thu, 5 Oct 2017 00:41:48 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1fbW5q2eaWE; Thu, 5 Oct 2017 00:41:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 155572CE21; Thu, 5 Oct 2017 00:41:48 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Thu, 5 Oct 2017 00:41:47 +0300 Cc: "ideas@ietf.org" , "ietf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:41:52 -0000 I was a bit surprised to see this come out of the IESG for=20 review, given that we had fairly serious discussions about the problems of the proposed approaches at the BOF, but I see little=20 attention on those issues in the charter. But, to state my opinion about working group being created with this charter, I have comments from two directions. First, from the point of view of =E2=80=9Cdo we need this=E2=80=9D or = =E2=80=9Cdo I need this=E2=80=9D, I=E2=80=99m a =E2=80=9Cmeh=E2=80=9D. If the HIP and LISP folk and = everyone else were screaming for this, and we had enough deployment that we saw the=20 issues that the charter proposes, then sure. Not sure that=E2=80=99s = case. Secondly, I=E2=80=99m have similar concerns to Christian, Lars, Stephen = and others. More specifically, at the BOF the goal seemed to be creation of = infrastructures to manage and track identities, and to bind them to entities that = assigned them. I am not at all sure that=E2=80=99s a desirable direction. And the = charter says little about the assumptions behind the work. To expand a bit on these concerns, the proposed work doesn=E2=80=99t = consider at all the types of identifier operations that work on ephemeral = identities (e.g., HIP, MP-TCP). It would be sad if we created systems that forced us to manage identifiers from some infrastructure when all we needed to do in a particular case was =E2=80=9Cprove that you are the same entity as in the other connection=E2=80=9D, which can be done e2e = and requires no infrastructure, or permanent identifiers. The charter text also mentions =E2=80=9Cidentifier changes=E2=80=9D in = what feels like a special case for what I would think is rather the default. I find concept of firewalls checking identity troublesome. Now, I=E2=80=99m not opposed to creating a working group in the IETF in = this area, and to support various infrastructure needs of say mobility or multihoming or anycast protoocols, but if we do it, we need to do it right. Dino=E2=80=99s suggestion of mapping systems without the = manage/ create aspect might be one potential useful direction. Another way to think about this space is to consider nodes to have autonomy in how they manage and create their identities, when they reveal or do not reveal identities. Then we could ask what helpful tasks might an infrastructure provide on top of that, e.g.,=20 mapping services or forwarding agent type designs. Jari From nobody Wed Oct 4 14:43:29 2017 Return-Path: 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 DF8D81321A2; Wed, 4 Oct 2017 14:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 awFfxag-grrc; Wed, 4 Oct 2017 14:43:19 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6551344D0; Wed, 4 Oct 2017 14:43:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 96CF646DC9A; Wed, 4 Oct 2017 14:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1507153395; bh=7f5eHnEsdetQXGc4DcXO2/OTOLe/b8NbcQmU4CLwSiE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W+VbJtbi6m0SI8oWZ0gFY6iOm6otDw6BGikkMKFLbA8BFGmpyJdDJrtzu/lwSL9X0 6UDTac2ViMZrpi4Ms4SxFfufxHLV4D4JeEfMUGvd+pREZ8j7Tc/KCwPcYXV4bZuiJs 5JtoNpAMYC1552r5Ug36iJhTuKbZ8EXkZmwcGpTE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8C5B746DC44; Wed, 4 Oct 2017 14:43:13 -0700 (PDT) To: Uma Chunduri , Stephen Farrell , Alexander Clemm , "tom@herbertland.com" Cc: "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> From: "Joel M. Halpern" Message-ID: <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> Date: Wed, 4 Oct 2017 17:43:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:43:22 -0000 I see different people providing different descriptions of why this is being proposed. I do not see a clear problem statement. As such, it is not even clear to me that this is "a" working group. Yours, Joel On 10/4/17 5:26 PM, Uma Chunduri wrote: > Hi Stephen, > > > .. information would be better able to track people compared to now. > > This is not about people.. > > >Regardless of what one thinks of them, given that things like HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit adding this extra layer of indirection with a privacy invasive "Unique and Permanent" identifier > >which seems to be the only non-overlapping part of this work - in fact I only see downsides. > > FWIW, > This is also to enable security and access restrictions to the new breed of devices on the network (IoT or other mobility nodes). Just because of the fact that they are on the network with an address they should not be allowed to be accessible. > Authentication with a trusted IdP would enable establishing the type of the type of device, which then allows group based policies to be enforceable (a V2X node can talk to only same kind of node or a particular IoT can be accessed by only particular device). > As discussed earlier in the list perhaps https://tools.ietf.org/wg/abfab/ can be looked into build this federated system in the architecture document. > I also see you are arguing(unfortunately) against your https://tools.ietf.org/html/rfc7258 document, where this can be one more potential mitigation tool w.r.t device anonymity (apart from encrypt everything/TCPINC - which serves a different and important purpose for content privacy w.r.t monitoring). > > I don't see a fully functional mapping system without any authentication into the system by the device/node for the mapping. This has been always the case in the cellular world and it seems we are all okay with it and today it's 80+% of the total traffic. > It would be great if you can suggest which can meet this objective in more balanced way... > > -- > Uma C. > From nobody Wed Oct 4 14:56:51 2017 Return-Path: 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 103D61344BB; Wed, 4 Oct 2017 14:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dA4pQxONFVUd; Wed, 4 Oct 2017 14:56:47 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 364691323B4; Wed, 4 Oct 2017 14:56:47 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id m18so1115589pgd.13; Wed, 04 Oct 2017 14:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/o1mGaaI/C+mzDykgr1H3K1J0TNu50yE9WzF7ha9rlM=; b=lRPKpHt2JTlqTYx+W1UfRtxuH9ECbh5yj24AnINcf+qofdqustwmOHHEYSoaXvj3xS wFhxLSrhq4AdtGHKjI7eY/sq+L0NIBN0IT+o4yIBPdI4kvFcTbgU3aJpo93TS8ovWTnM ToqXmKifuYiH0VCQUzf9jImh8j6VBC18jKRLMGiMZBn+bY7JNR29Ujge70yKjJj6h6Jp 2DON4g78ZizZLPnHDq4PfSTzZl21rQ5yxDEp+ev6j9OBrxbV4sRXlezhxDOv15xkojuP 6IiaOQdGIFGBiBeJhd7gYme7qREg4qRCwyh2B68ltxSKX8UbWwxip4kjExrQ4hGtoF7B yt2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/o1mGaaI/C+mzDykgr1H3K1J0TNu50yE9WzF7ha9rlM=; b=sT4ZAiqXHRQKfcojIkxEdfFxZZhPPRKS9KZqUTjCDvINkRWcWWhFnZxVJ5MWMizN8U ScXXqm299Mj5jqwJ87oQeLxQiK+ZoLZ/ZAVwWRcqK4hnvioZlM92L9qxvVgLqolqvbxP dzCFg7GB5yzp1n51CDPjNMJkR0OysKsBP6fAgOFOfVTNF5uJJgVk6yfL/4o6jfo4QDAT rwjlYxWo4sOzbwDQs2+Mf+TmR02zfMxmHtV34xpDgbCDZQ3WheoJ2ZblL4R6zMTIcLsk /r76iwjnWgJY2miAYIszhBKqyBCNVCEITi4UKgi3elLDK6RhieHT+Ursb7R51QY7S3Vr tFYQ== X-Gm-Message-State: AMCzsaVnwgSe7Gy7otoeAeoPIMk1lSmPG8DleD7TRrh9gRfbX/gepvkl DeZh/M7lhhpwNXJfVUDZZadzsw== X-Google-Smtp-Source: AOwi7QARZLO4ur64GE2PoBEnSh+aN0VqqNPt8wJSNC0ceuKlEeTUjBtBtlzvmiH/yG/ExFjHrS/1Qg== X-Received: by 10.99.52.196 with SMTP id b187mr10877726pga.222.1507154206282; Wed, 04 Oct 2017 14:56:46 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 207sm27070335pfu.0.2017.10.04.14.56.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 14:56:45 -0700 (PDT) To: Dino Farinacci Cc: "ideas@ietf.org" , "ietf@ietf.org" , "lisp@ietf.org list" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> Date: Thu, 5 Oct 2017 10:56:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:56:50 -0000 On 05/10/2017 09:35, Dino Farinacci wrote: > Adding lisp@ietf.org to cc list. >=20 > How about creating a working group that solely focuses on deployment of= a mapping system and does not specify how and where identifiers are allo= cated? That seems reasonable, well defined and relatively uncontentious. The current proposed charter leaves me a bit puzzled. Firstly I agree that the name 'IDEAS' is misleading, and 'GRIDS' tramples on previous wor= k, and 'identity' is a red flag. But if we get past terminology distractions= , where's the meat? All the interesting stuff is relegated to drafts or a wiki, and the output is a 'framework'. The IETF has a very mixed record with 'framework' documents. Brian >=20 > I have made suggestions before that such a working group should be in t= he ops area. Some examples include and are not limited to v6ops, dnsop, a= nd mboned. >=20 > Cheers, > Dino >=20 >> On Oct 4, 2017, at 12:45 PM, Stephen Farrell wrote: >> >> >> Hiya, >> >> TL;DR - I am now even more convinced that this ought not >> go ahead. (Sorry;-) >> >> On 04/10/17 19:48, Alexander Clemm wrote: >>> There were a couple of things raised in the overall thread that I >>> just wanted to quickly respond to: >>> >>> Clearly privacy is an important issue and concern. The current >>> charter proposal includes a requirement for a detailed analysis of >>> this aspect. If this aspect needs to be expanded, sure, let's do >>> this. >> >> TBH, I don't think that'd help, for me at least. I don't >> see any way in which such permanent strings representing >> identity can be defined to be usable as claimed and not >> be perniciously privacy invasive. So some promises to >> ponder the problem in charter text wouldn't do it for >> me. (And tbh, I've seen that can kicked down that road >> before, so I'm skeptical of such promises in general.) >> >>> Everyone seems to be jumping up and down regarding the use of the >>> term of "identity" as if a foregone conclusion that this is a synonym= >>> for "privacy invasion". However: - "Identity" does not imply >>> "personal identity". Really, this is an identifier scheme for >>> endpoints. =20 >> >> Sorry, what I assume is the relevant draft [1] says the "identity" >> (denoted "IDy") is a "Unique and Permanent Identity" and that >> "Networks may treat traffic differently depending on the IDy of >> source or destination" and also seems to envisage a large logical >> database of everyone's IDy's: "Identity also allows to have metadata >> associated it to be applied, regardless of which IDf is used to >> refer it." (Where IDf is the identifier that'll later be mapped >> to a locator via, I assume, HIP or LISP or similar.) >> >> I think it's entirely correct to jump up and down about the >> privacy consequences of the above. (Not to mention the potential >> censorship and discriminatory aspects.) >> >> [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases= -01 >> >>> Perhaps even "identity" is a misnomer. =20 >> >> Well, it was presumably your choice (where your =3D=3D some set of >> the proponents). If that's a mistake, then it seems a fairly >> fatal one - to get the name wrong for an effort all about mapping >> names to identifiers;-) >> >>> If you will, >>> identity as conceived in the context of IDEAS is a second level of >>> identifier that does not have to be exposed over the data plane - >>> Because of this, it may result in greater privacy than existing >>> schemes, not less.=20 >> >> I see that argument in [1] but I'm not buying it tbh. To get >> that level of protection from such an indirection, one would >> have to have something like Tor hidden services and perhaps >> one would have to *not* standardise the mapping from human >> meaningful identifiers to those used as IDf, and esp. not the >> reverse mapping. Defining that reverse mapping cannot but be >> privacy invasive afaics. (There could maybe be ways to define >> how an already hashed human meaningful identifier could then >> be further hashed to become an IDy but I don't really see the >> point of that at all, other than to just standardise something >> for the fun of the process.) >> >>> It enables you, for example, to obfuscate >>> endpoints to outside observers as you wouldn't need to use personal >>> unique long-lived identifiers, quite the contrary. - There is also a >>> security dimension here. If I am victim of a phishing attack because >>> my network information (like today) is exposed to botnets,=20 >> >> (Nit: that says nothing about being a victim of, only of being >> a target of, an attempted attack. Speaking of victims also >> tends not to lead to more objective analysis, so I think it's >> better to not go there unless it's relevant, which I don't >> think is the case here, because...) >> >> I don't understand what network information you mean. If you >> mean email addresses, and are proposing that the email ecosystem >> change to use some IDf or LOC values, that doesn't seem at all >> realistic to me. If you don't mean email addresses then I don't >> see how any lower layer change will affect attempted phishes. >> The routing area is probably also the entirely wrong venue for >> any real anti-phishing effort. >> >> That really wasn't a good example;-) >> >>> phishers >>> etc who can hide from me (but not I from them) and remain anonymous >>> or impersonate legitimate users, I do consider this a very serious >>> threat also to my privacy. How can IETF counteract such threats? I >>> think that IDEAS, if done right, can provide a contribution here. >> >> I don't see that at all. Unless I'm mistaken that seems like >> wishful thinking to me. >> >>> >>> One aspect that has been missing from the discussion is the question >>> whether there is a distinction between the network provider who >>> provides GRIDS services and an outside attacker / observer. I think >>> this distinction is important. The way I see it, if done right >>> (sure, big "if", and requiring detailed analysis), IDEAS as I would >>> envision it can contribute greatly to provide greater security and >>> privacy from outside attackers. At the same time, as it is currently= >>> envisioned, there clearly is a trust relationship between an entity >>> and the provider of "its" GRIDS services. The mapping database will >>> have information about locator-identifier and identifier-identifier >>> mappings, so GRIDS will know which identifiers its endpoints are >>> using. Clearly, if this trust is abused because the provider cannot >>> be trusted, if you are concerned that it sells your endpoint=C3=A2=E2= =82=AC=E2=84=A2s >>> information to the mob or a suppressive government, there is an >>> issue. However, when concerned about this scenario, it seems to me >>> one would have equal reason to e.g. not trust your mobile service >>> provider either, who can track you, knows your location, and has your= >>> customer data. >> >> ISTM that introducing that GRIDS thing makes matters worse and not >> better, because, as you yourself say, it is clear that whoever has >> access to the GRIDS information would be better able to track people >> compared to now. >> >> I would prefer to see fewer long lived identifiers in networking >> and not more, and this proposal introduces more long lived identifiers= >> (erroneously calling those identities). >> >> Regardless of what one thinks of them, given that things like >> HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit >> adding this extra layer of indirection with a privacy invasive >> "Unique and Permanent" identifier which seems to be the only >> non-overlapping part of this work - in fact I only see downsides. >> >> Cheers, >> S. >> >> >>> >>> --- Alex >>> >>> >>>> -----Original Message----- From: Ideas >>>> [mailto:ideas-bounces@ietf.org] On Behalf Of=20 >>>> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 9:35 >>>> AM To: tom@herbertland.com Cc: ideas@ietf.org; >>>> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG >>>> Review: IDentity Enabled Networks (ideas) >>>> >>>> >>>> >>>> On Wednesday, 4 October 2017, Tom Herbert wrote: >>>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker=20 >>>>> wrote: >>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell=20 >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> As currently described, I oppose creation of this working >>>>>>> group on the basis that it enables and seemingly encourages >>>>>>> embedding identifiers for humans as addresses. Doing so would >>>>>>> have significant privacy downsides, would enable new methods >>>>>>> for censorship and discrimination, and could be very hard to >>>>>>> mitigate should one wish to help protect people's privacy, as >>>>>>> I think is current IETF policy. >>>>>>> >>>>>>> If the work precluded the use of any identifiers that >>>>>>> strongly map to humans then I'd be ok with it being done as >>>>>>> it'd then only be a waste of resources. But I don't know how >>>>>>> that could be enforced so I think it'd be better to just not >>>>>>> do this work at all. >>>>>>> >>>>>>> S. >>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> I know how to restrict the work to 'meaningless' identifiers,=20 >>>>>> require that the identifiers be the output of a cryptographic >>>>>> algorithm. >>>>>> >>>>>> Now strictly speaking, this only limits scope to identifiers >>>>>> that are indexical as opposed to rendering them meaningless but >>>>>> I think that was the sense of it. >>>>>> >>>>>> >>>>>> N=C3=83=C2=B6th proposed a trichotemy of identifiers as follows >>>>>> >>>>>> * Identity, the signifier is the signified (e.g. data: URI) >>>>>> >>>>>> * Indexical, the signifier is related to the signified by a=20 >>>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP=20 >>>>>> fingerprints etc.) >>>>>> >>>>>> * Names, the signifier is the related to the signified by a >>>>>> purely conventional relationship, (e.g. example.com to its >>>>>> owner) >>>>>> >>>>>> >>>>>> There is a big difference between attempting to manage >>>>>> indexical signifiers and names. Especially when the people >>>>>> trying to do so refuse to read any of the literature on >>>>>> semiotics. >>>>>> >>>>>> Names are problematic because the only way that a conventional=20 >>>>>> relationship can be implemented is through some sort of >>>>>> registration infrastructure and we already have one of those >>>>>> and the industry that manages it has a marketcap in the tens of >>>>>> billions. >>>>>> >>>>>> Identifiers do lead to tractable solutions. But, this proposal >>>>>> looks a bit unfocused for IRTF consideration, an IETF WG? >>>>>> Really? >>>>>> >>>>> Identifiers are equivalent to addresses in that they indicate a >>>>> node in the network for the purposes of end to end >>>>> communications. The only difference between identifiers and >>>>> addresses is that identifiers are not topological. Virtual >>>>> addresses in network virtualization are also identifiers. So the >>>>> security properties are the same when considering privacy. For >>>>> instance, if applications use temporary addresses for privacy, it >>>>> would have equivalent properties using temporary identifiers. In >>>>> fact from the application POV this would be transparent. It could >>>>> get a pool of apparently random addresses to choose from as >>>>> source of communication, it shouldn't know or even care if the >>>>> addresses are identifiers. >>>>> >>>>> Identity is a completely separate concept from identifiers. Is >>>>> not required in any of the identifier/locator protocols and AFAIK >>>>> none of them even mention the term. There is no association of an >>>>> identity of user behind and identifier any more than there is an >>>>> association of identity behind IP address. The fact that the >>>>> words "identifier" and "identity" share a common prefix is an >>>>> unfortunate happenstance :-). >>>> >>>> >>>> Yes. But doesn't that mean either the name of this effort is wildly >>>> misleading or else the effort is hugely problematic from a privacy >>>> POV? Either way, istm this ought not proceed. >>>> >>>> S. >>>> >>>>> >>>>> Tom >>>>> >>>> _______________________________________________ Ideas mailing list=20 >>>> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas >> >> _______________________________________________ >> Ideas mailing list >> Ideas@ietf.org >> https://www.ietf.org/mailman/listinfo/ideas >=20 > . >=20 From nobody Wed Oct 4 15:12:22 2017 Return-Path: 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 82052132F3F for ; Wed, 4 Oct 2017 15:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3u4oaXEp4JCD for ; Wed, 4 Oct 2017 15:12:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C898132199 for ; Wed, 4 Oct 2017 15:12:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX50663; Wed, 04 Oct 2017 22:12:16 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 23:12:15 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 15:12:10 -0700 From: Uma Chunduri To: "Joel M. Halpern" CC: "ideas@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLMpUwAgAefuYCAABZuAIAABMSAgAAlQ4CAAA/0gP//oBpQgACA4gD//5H9IA== Date: Wed, 4 Oct 2017 22:12:09 +0000 Message-ID: <25B4902B1192E84696414485F572685401A8720E@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> In-Reply-To: <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59D55CC0.00EE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:12:20 -0000 DQoJPkkgc2VlIGRpZmZlcmVudCBwZW9wbGUgcHJvdmlkaW5nIGRpZmZlcmVudCBkZXNjcmlwdGlv bnMgb2Ygd2h5IHRoaXMgaXMgYmVpbmcgcHJvcG9zZWQuDQoJPkkgZG8gbm90IHNlZSBhIGNsZWFy IHByb2JsZW0gc3RhdGVtZW50Lg0KDQpKb2VsLA0KDQpQdXp6bGVkIHdpdGggeW91ciByZXNwb25z ZSENCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhZG1hLWlkZWFzLXByb2Js ZW0tc3RhdGVtZW50LTAzIA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9pZGVhcy9h Ym91dC8NCg0KLS0NClVtYSBDLg0K From nobody Wed Oct 4 15:13:59 2017 Return-Path: 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 76424132199 for ; Wed, 4 Oct 2017 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 spIEaRFQDv2v for ; Wed, 4 Oct 2017 15:13:56 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5EA1320D8 for ; Wed, 4 Oct 2017 15:13:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7A3FA46DC9A; Wed, 4 Oct 2017 15:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1507155236; bh=YG8rKvTXt5zf9wgFQDBSLtGXo8vsLEmrcIuIu8jfkpQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Lwey8KpqTD3qQvcY/Hqq5rlR6kA75cx/E4mfpubcMwJXE6HCw9mREQkHl/dv9xCPF Ym7V7vy5VTDQmACBYOr/fCs17+byqnrq4/bHwsc9B3GbaLEAhCLT3zivKtcZJvtMyT CT8VyLX8FkWD0vpXdEGTBRxuqt1ZEzCEv4r14SLI= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BE2EA467F1B; Wed, 4 Oct 2017 15:13:55 -0700 (PDT) To: Uma Chunduri , "ideas@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> <25B4902B1192E84696414485F572685401A8720E@SJCEML701-CHM.china.huawei.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 4 Oct 2017 18:13:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F572685401A8720E@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:13:57 -0000 Yes, you have a problem statement draft. But there is no clear statement of the problem in the charter. Which means that the working group is not bound by the current draft. And when I ask different people about the proposed work, I get different answers as to the purpose, scope, approach, etc. Yorus, joel On 10/4/17 6:12 PM, Uma Chunduri wrote: > > >I see different people providing different descriptions of why this is being proposed. > >I do not see a clear problem statement. > > Joel, > > Puzzled with your response! > > https://tools.ietf.org/html/draft-padma-ideas-problem-statement-03 > https://datatracker.ietf.org/wg/ideas/about/ > > -- > Uma C. > From nobody Wed Oct 4 15:20:26 2017 Return-Path: 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 3317E1344D8 for ; Wed, 4 Oct 2017 15:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SlA7j-CFk7lN for ; Wed, 4 Oct 2017 15:20:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495EC1344CD for ; Wed, 4 Oct 2017 15:20:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW10302; Wed, 04 Oct 2017 22:20:21 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 23:20:20 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 15:20:11 -0700 From: Uma Chunduri To: "Joel M. Halpern" , "ideas@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLMpUwAgAefuYCAABZuAIAABMSAgAAlQ4CAAA/0gP//oBpQgACA4gD//5H9IIAAdpcA//+K/5A= Date: Wed, 4 Oct 2017 22:20:11 +0000 Message-ID: <25B4902B1192E84696414485F572685401A87227@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> <25B4902B1192E84696414485F572685401A8720E@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59D55EA5.01A3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:20:25 -0000 Sm9lbCwgDQoNCkkgc2VlIHdoYXQgeW91IGFyZSBzYXlpbmcsIGluLWxpbmUgLi4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBq b2VsaGFscGVybi5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA0LCAyMDE3IDM6MTQg UE0NClRvOiBVbWEgQ2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBodWF3ZWkuY29tPjsgaWRlYXNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRlYXNdIFdHIFJldmlldzogSURlbnRpdHkgRW5hYmxlZCBO ZXR3b3JrcyAoaWRlYXMpDQoNClllcywgeW91IGhhdmUgYSBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dC4NCkJ1dCB0aGVyZSBpcyBubyBjbGVhciBzdGF0ZW1lbnQgb2YgdGhlIHByb2JsZW0gaW4gdGhl IGNoYXJ0ZXIuIA0KDQpbVW1hXTogSSBndWVzcywgZ2l2ZW4gdGhlIHZhcmlvdXMgdmVyc2lvbnMg b2YgdGhlIGNoYXJ0ZXIgYW5kIGRpc2N1c3Npb25zIGlmIHRoZXJlIGlzIHNvbWV0aGluZyBtaXNz ZWQgdGhhdCBjYW4gYmUgbG9va2VkIGludG8uDQoNCldoaWNoIG1lYW5zIHRoYXQgdGhlIHdvcmtp bmcgZ3JvdXAgaXMgbm90IGJvdW5kIGJ5IHRoZSBjdXJyZW50IGRyYWZ0Lg0KQW5kIHdoZW4gSSBh c2sgZGlmZmVyZW50IHBlb3BsZSBhYm91dCB0aGUgcHJvcG9zZWQgd29yaywgSSBnZXQgZGlmZmVy ZW50IGFuc3dlcnMgYXMgdG8gdGhlIHB1cnBvc2UsIHNjb3BlLCBhcHByb2FjaCwgZXRjLg0KDQpZ b3J1cywNCmpvZWwNCg0KT24gMTAvNC8xNyA2OjEyIFBNLCBVbWEgQ2h1bmR1cmkgd3JvdGU6DQo+ IA0KPiAJPkkgc2VlIGRpZmZlcmVudCBwZW9wbGUgcHJvdmlkaW5nIGRpZmZlcmVudCBkZXNjcmlw dGlvbnMgb2Ygd2h5IHRoaXMgaXMgYmVpbmcgcHJvcG9zZWQuDQo+IAk+SSBkbyBub3Qgc2VlIGEg Y2xlYXIgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+IA0KPiBKb2VsLA0KPiANCj4gUHV6emxlZCB3aXRo IHlvdXIgcmVzcG9uc2UhDQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cGFkbWEtaWRlYXMtcHJvYmxlbS1zdGF0ZW1lbnQtMDMNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy93Zy9pZGVhcy9hYm91dC8NCj4gDQo+IC0tDQo+IFVtYSBDLg0KPiANCg== From nobody Wed Oct 4 15:26:11 2017 Return-Path: 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 A338B120724 for ; Wed, 4 Oct 2017 15:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 unrL6GA5IKgn for ; Wed, 4 Oct 2017 15:25:57 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 484551320D8 for ; Wed, 4 Oct 2017 15:25:57 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id r25so4862462pgn.4 for ; Wed, 04 Oct 2017 15:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rpOSpOqEcGTTnd4dX/uz26Hbvup/rNsyYosOHB8da3U=; b=tuin0ypN7uFE2+4ukBPnAe1VDtmuwG+XqxyV/fd9bDzTC5Qq66h9aylTsH3FU/ZVGz YtI6RkcxVqMKGn7WDpdTJD+p1nsTYoQrnQIo54hLcx2Nb2Qr6ePt98D/b3tPj/38r3g5 +SsTrJURJOaGXgNef6dFolsOCkrztvu7nQLz9FpSApJ3lYcHujjhzWgiRxA9Xgv3Ae8g lFFIpe2BPbMS6jqIViBUgBe4nzEV/o1DPTeg1C2wliTQK/crBfze16x3Encg36FFDX2u bpb4D1UDncdvUhfJj40hvqKqxLytPgJQT44j7Vbwl821q10UZngowg8zVn2TrjgaDl28 UriQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rpOSpOqEcGTTnd4dX/uz26Hbvup/rNsyYosOHB8da3U=; b=kLsYYQrAzuYjeEdZGsFW8QoR37v4Ev2emo44okjnOfEo27i/74vwgRsOx6P29ZRI+i QYjZ2gBpEXWDqQlm3EMSL+AH5QEb8rulYFhuKDdN+bSxJB4+iiMPF6df+qmPcbNy5IDi ySpBW96nOMrmIDG5tVCJ3CAIeZexX8h0K3Xt5g9H6rsotxC41dKeyYHkR4Rfls5drXEE ZZW+Eq05OM6ejXJo03jg8Bt7CnJ3Vy4HKya8T10ikH5/LmIDkRjJTMaH2lqb3F2Zac1W ZCCsG0Wy0hFejh0R9isd23bRQ7K8nM7/08BHiQHM70czgw5GkiNNgLiefJm2bLNlHIXp Hcyg== X-Gm-Message-State: AHPjjUiEgEadOMdQtTLAXyNi793FOgOLyQJruADMGk8yOdzbwvF55jqY H4TB03m4gM1jgBKIyp4oFYo= X-Google-Smtp-Source: AOwi7QAg4SgfG2o9Dn9dUKf48FYj7oneLJYQnMDZCLiCpdhSvq6RjwbbZN1RgBZY2VnTa3aV1UFCLQ== X-Received: by 10.84.196.131 with SMTP id l3mr20578936pld.195.1507155956912; Wed, 04 Oct 2017 15:25:56 -0700 (PDT) Received: from ?IPv6:2600:380:8659:7cc5:98d5:d34e:95f5:7049? ([2600:380:8659:7cc5:98d5:d34e:95f5:7049]) by smtp.gmail.com with ESMTPSA id l6sm27625639pfc.112.2017.10.04.15.25.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 15:25:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Padma Pillay-Esnault X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 4 Oct 2017 15:25:54 -0700 Cc: Uma Chunduri , "ideas@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7AD02EB3-2E07-406C-94D0-D1628043C34F@gmail.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> <25B4902B1192E84696414485F572685401A8720E@SJCEML701-CHM.china.huawei.com> To: "Joel M. Halpern" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:26:10 -0000 Hi Joel Thanks for your feedback. The charter went through several iterations. With simplification, it seems t= o have lost some clarity. Padma Sent from my iPhone > On Oct 4, 2017, at 15:13, Joel M. Halpern wrote: >=20 > Yes, you have a problem statement draft. > But there is no clear statement of the problem in the charter. Which mean= s that the working group is not bound by the current draft. > And when I ask different people about the proposed work, I get different a= nswers as to the purpose, scope, approach, etc. >=20 > Yorus, > joel >=20 >> On 10/4/17 6:12 PM, Uma Chunduri wrote: >> >I see different people providing different descriptions of why this i= s being proposed. >> >I do not see a clear problem statement. >> Joel, >> Puzzled with your response! >> https://tools.ietf.org/html/draft-padma-ideas-problem-statement-03 >> https://datatracker.ietf.org/wg/ideas/about/ >> -- >> Uma C. >=20 > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Wed Oct 4 15:32:35 2017 Return-Path: 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 037DC1344E4 for ; Wed, 4 Oct 2017 15:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, 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 VYT4eIpx7ra1 for ; Wed, 4 Oct 2017 15:32:16 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 1493B134309 for ; Wed, 4 Oct 2017 15:32:12 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f15so22200428qtf.7 for ; Wed, 04 Oct 2017 15:32:12 -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=GmLRG40ssy7uHv3JcSX13HnbRabUhvyF5sUWe8OuWeg=; b=Iuv2VnReC4DjvosrxUsn/+5pdg16rqTy7lSgYvKY3dAZorlHe36YIPFM4zqk9JIHiA UUfg2dzXJ1+YcEuB1CsvkFWw8FQ4TThg1laYFzFPsvl7ErcjUeBPPxOlRTMDXcT984Kh V5uESodZVcns6cuVh1IozieGV5bFO066QFjCOlPNXl7sATu3UdcgmTvV+fKmoENT5d/j SUTvbmVVW/cBW+L/pytEErxy8E5jt5hCKbsNKATQduiEA4ovVSUSF0qDBeHeRyKr6GHH yBfBj/H/q251J7dir42TY3GCivckao8Qzee5XUuNdMU0wne8P66CBIOtDvRf4vH28XKy 3oxw== 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=GmLRG40ssy7uHv3JcSX13HnbRabUhvyF5sUWe8OuWeg=; b=PbdTgO3yw7R2cQo3EU3W1UELSd3iPN8pw5eiemXROco7tt9PiQcVfKdE4qFD+f8LMS zMkbyKY4APif4s1kwHEWLWVTP920LoIGdt9/7IKeD2v2qpY0RxmBU6yYizM/WSiDWVbh ANgL/fXv2YtghbiOVHhlQcPzfhfo9LyDATYNURVmL4UZLWtWbIsJ8H3aKGmjBvKkOfdY T4U/0Edb3U1KwmCdZ8EFJIHAPy7CdiXSa6cCICiUA/WHajGEvzhjCzvMJD9nw+laNaDs m0M1cXVeMiffSS3NZNM63/M8yrh7Ky9F1jl1OFpU0PVZxQ7y5DLI5aitTdAXYytdAoy9 j/rg== X-Gm-Message-State: AMCzsaWC2gg3gftvq83ltzLBKdvKLjse+vlizNr+Grda0iuTjIU9r088 CfLIBjc+jTQLVba2BGCN0kXvMdUpp9XcfmYl52JkvQ== X-Google-Smtp-Source: AOwi7QB4x7CjBJpLzD44XhKYMoHGJd6AnZQoX8aFIPxP++KSZfv7g5Y8JW8rfmxr0GGBBcOd2umtC5rsyUXZPt3NXVI= X-Received: by 10.200.36.164 with SMTP id s33mr17354343qts.108.1507156331879; Wed, 04 Oct 2017 15:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 15:32:11 -0700 (PDT) Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 15:32:11 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> From: Tom Herbert Date: Wed, 4 Oct 2017 15:32:11 -0700 Message-ID: To: Dino Farinacci Cc: lisp@ietf.org, ietf@ietf.org, Alexander Clemm , Stephen Farrell , "ideas@ietf.org" , "phill@hallambaker.com" Content-Type: multipart/alternative; boundary="001a11404e58c86f30055ac02d4e" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:32:20 -0000 --001a11404e58c86f30055ac02d4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Oct 4, 2017 1:35 PM, "Dino Farinacci" wrote: Adding lisp@ietf.org to cc list. How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated= ? +1 I suggest that could be called idloc (for Identifier-Locator) Tom I have made suggestions before that such a working group should be in the ops area. Some examples include and are not limited to v6ops, dnsop, and mboned. Cheers, Dino > On Oct 4, 2017, at 12:45 PM, Stephen Farrell wrote: > > > Hiya, > > TL;DR - I am now even more convinced that this ought not > go ahead. (Sorry;-) > > On 04/10/17 19:48, Alexander Clemm wrote: >> There were a couple of things raised in the overall thread that I >> just wanted to quickly respond to: >> >> Clearly privacy is an important issue and concern. The current >> charter proposal includes a requirement for a detailed analysis of >> this aspect. If this aspect needs to be expanded, sure, let's do >> this. > > TBH, I don't think that'd help, for me at least. I don't > see any way in which such permanent strings representing > identity can be defined to be usable as claimed and not > be perniciously privacy invasive. So some promises to > ponder the problem in charter text wouldn't do it for > me. (And tbh, I've seen that can kicked down that road > before, so I'm skeptical of such promises in general.) > >> Everyone seems to be jumping up and down regarding the use of the >> term of "identity" as if a foregone conclusion that this is a synonym >> for "privacy invasion". However: - "Identity" does not imply >> "personal identity". Really, this is an identifier scheme for >> endpoints. > > Sorry, what I assume is the relevant draft [1] says the "identity" > (denoted "IDy") is a "Unique and Permanent Identity" and that > "Networks may treat traffic differently depending on the IDy of > source or destination" and also seems to envisage a large logical > database of everyone's IDy's: "Identity also allows to have metadata > associated it to be applied, regardless of which IDf is used to > refer it." (Where IDf is the identifier that'll later be mapped > to a locator via, I assume, HIP or LISP or similar.) > > I think it's entirely correct to jump up and down about the > privacy consequences of the above. (Not to mention the potential > censorship and discriminatory aspects.) > > [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01 > >> Perhaps even "identity" is a misnomer. > > Well, it was presumably your choice (where your =3D=3D some set of > the proponents). If that's a mistake, then it seems a fairly > fatal one - to get the name wrong for an effort all about mapping > names to identifiers;-) > >> If you will, >> identity as conceived in the context of IDEAS is a second level of >> identifier that does not have to be exposed over the data plane - >> Because of this, it may result in greater privacy than existing >> schemes, not less. > > I see that argument in [1] but I'm not buying it tbh. To get > that level of protection from such an indirection, one would > have to have something like Tor hidden services and perhaps > one would have to *not* standardise the mapping from human > meaningful identifiers to those used as IDf, and esp. not the > reverse mapping. Defining that reverse mapping cannot but be > privacy invasive afaics. (There could maybe be ways to define > how an already hashed human meaningful identifier could then > be further hashed to become an IDy but I don't really see the > point of that at all, other than to just standardise something > for the fun of the process.) > >> It enables you, for example, to obfuscate >> endpoints to outside observers as you wouldn't need to use personal >> unique long-lived identifiers, quite the contrary. - There is also a >> security dimension here. If I am victim of a phishing attack because >> my network information (like today) is exposed to botnets, > > (Nit: that says nothing about being a victim of, only of being > a target of, an attempted attack. Speaking of victims also > tends not to lead to more objective analysis, so I think it's > better to not go there unless it's relevant, which I don't > think is the case here, because...) > > I don't understand what network information you mean. If you > mean email addresses, and are proposing that the email ecosystem > change to use some IDf or LOC values, that doesn't seem at all > realistic to me. If you don't mean email addresses then I don't > see how any lower layer change will affect attempted phishes. > The routing area is probably also the entirely wrong venue for > any real anti-phishing effort. > > That really wasn't a good example;-) > >> phishers >> etc who can hide from me (but not I from them) and remain anonymous >> or impersonate legitimate users, I do consider this a very serious >> threat also to my privacy. How can IETF counteract such threats? I >> think that IDEAS, if done right, can provide a contribution here. > > I don't see that at all. Unless I'm mistaken that seems like > wishful thinking to me. > >> >> One aspect that has been missing from the discussion is the question >> whether there is a distinction between the network provider who >> provides GRIDS services and an outside attacker / observer. I think >> this distinction is important. The way I see it, if done right >> (sure, big "if", and requiring detailed analysis), IDEAS as I would >> envision it can contribute greatly to provide greater security and >> privacy from outside attackers. At the same time, as it is currently >> envisioned, there clearly is a trust relationship between an entity >> and the provider of "its" GRIDS services. The mapping database will >> have information about locator-identifier and identifier-identifier >> mappings, so GRIDS will know which identifiers its endpoints are >> using. Clearly, if this trust is abused because the provider cannot >> be trusted, if you are concerned that it sells your endpoint=C3=A2=E2=82= =AC=E2=84=A2s >> information to the mob or a suppressive government, there is an >> issue. However, when concerned about this scenario, it seems to me >> one would have equal reason to e.g. not trust your mobile service >> provider either, who can track you, knows your location, and has your >> customer data. > > ISTM that introducing that GRIDS thing makes matters worse and not > better, because, as you yourself say, it is clear that whoever has > access to the GRIDS information would be better able to track people > compared to now. > > I would prefer to see fewer long lived identifiers in networking > and not more, and this proposal introduces more long lived identifiers > (erroneously calling those identities). > > Regardless of what one thinks of them, given that things like > HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit > adding this extra layer of indirection with a privacy invasive > "Unique and Permanent" identifier which seems to be the only > non-overlapping part of this work - in fact I only see downsides. > > Cheers, > S. > > >> >> --- Alex >> >> >>> -----Original Message----- From: Ideas >>> [mailto:ideas-bounces@ietf.org] On Behalf Of >>> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 9:35 >>> AM To: tom@herbertland.com Cc: ideas@ietf.org; >>> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG >>> Review: IDentity Enabled Networks (ideas) >>> >>> >>> >>> On Wednesday, 4 October 2017, Tom Herbert wrote: >>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker >>>> wrote: >>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell >>>>> wrote: >>>>>> >>>>>> >>>>>> As currently described, I oppose creation of this working >>>>>> group on the basis that it enables and seemingly encourages >>>>>> embedding identifiers for humans as addresses. Doing so would >>>>>> have significant privacy downsides, would enable new methods >>>>>> for censorship and discrimination, and could be very hard to >>>>>> mitigate should one wish to help protect people's privacy, as >>>>>> I think is current IETF policy. >>>>>> >>>>>> If the work precluded the use of any identifiers that >>>>>> strongly map to humans then I'd be ok with it being done as >>>>>> it'd then only be a waste of resources. But I don't know how >>>>>> that could be enforced so I think it'd be better to just not >>>>>> do this work at all. >>>>>> >>>>>> S. >>>>> >>>>> >>>>> +1 >>>>> >>>>> I know how to restrict the work to 'meaningless' identifiers, >>>>> require that the identifiers be the output of a cryptographic >>>>> algorithm. >>>>> >>>>> Now strictly speaking, this only limits scope to identifiers >>>>> that are indexical as opposed to rendering them meaningless but >>>>> I think that was the sense of it. >>>>> >>>>> >>>>> N=C3=83=C2=B6th proposed a trichotemy of identifiers as follows >>>>> >>>>> * Identity, the signifier is the signified (e.g. data: URI) >>>>> >>>>> * Indexical, the signifier is related to the signified by a >>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP >>>>> fingerprints etc.) >>>>> >>>>> * Names, the signifier is the related to the signified by a >>>>> purely conventional relationship, (e.g. example.com to its >>>>> owner) >>>>> >>>>> >>>>> There is a big difference between attempting to manage >>>>> indexical signifiers and names. Especially when the people >>>>> trying to do so refuse to read any of the literature on >>>>> semiotics. >>>>> >>>>> Names are problematic because the only way that a conventional >>>>> relationship can be implemented is through some sort of >>>>> registration infrastructure and we already have one of those >>>>> and the industry that manages it has a marketcap in the tens of >>>>> billions. >>>>> >>>>> Identifiers do lead to tractable solutions. But, this proposal >>>>> looks a bit unfocused for IRTF consideration, an IETF WG? >>>>> Really? >>>>> >>>> Identifiers are equivalent to addresses in that they indicate a >>>> node in the network for the purposes of end to end >>>> communications. The only difference between identifiers and >>>> addresses is that identifiers are not topological. Virtual >>>> addresses in network virtualization are also identifiers. So the >>>> security properties are the same when considering privacy. For >>>> instance, if applications use temporary addresses for privacy, it >>>> would have equivalent properties using temporary identifiers. In >>>> fact from the application POV this would be transparent. It could >>>> get a pool of apparently random addresses to choose from as >>>> source of communication, it shouldn't know or even care if the >>>> addresses are identifiers. >>>> >>>> Identity is a completely separate concept from identifiers. Is >>>> not required in any of the identifier/locator protocols and AFAIK >>>> none of them even mention the term. There is no association of an >>>> identity of user behind and identifier any more than there is an >>>> association of identity behind IP address. The fact that the >>>> words "identifier" and "identity" share a common prefix is an >>>> unfortunate happenstance :-). >>> >>> >>> Yes. But doesn't that mean either the name of this effort is wildly >>> misleading or else the effort is hugely problematic from a privacy >>> POV? Either way, istm this ought not proceed. >>> >>> S. >>> >>>> >>>> Tom >>>> >>> _______________________________________________ Ideas mailing list >>> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas --001a11404e58c86f30055ac02d4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Oct 4, 2017 1:35 PM, "Dino Farinacci" <farinacci@gmail.com> wrote:
Adding lisp@ietf.org to cc list.

How about creating a working group that solely focuses on deployment of a m= apping system and does not specify how and where identifiers are allocated?=


+1

I suggest that could be called idloc = (for Identifier-Locator)

Tom

I have made suggestions before that such a working group should be in the o= ps area. Some examples include and are not limited to v6ops, dnsop, and mbo= ned.

Cheers,
Dino

> On Oct 4, 2017, at 12:45 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> TL;DR - I am now even more convinced that this ought not
> go ahead. (Sorry;-)
>
> On 04/10/17 19:48, Alexander Clemm wrote:
>> There were a couple of things raised in the overall thread that I<= br> >> just wanted to quickly respond to:
>>
>> Clearly privacy is an important issue and concern.=C2=A0 The curre= nt
>> charter proposal includes a requirement for a detailed analysis of=
>> this aspect.=C2=A0 If this aspect needs to be expanded, sure, let&= #39;s do
>> this.
>
> TBH, I don't think that'd help, for me at least. I don't > see any way in which such permanent strings representing
> identity can be defined to be usable as claimed and not
> be perniciously privacy invasive. So some promises to
> ponder the problem in charter text wouldn't do it for
> me. (And tbh, I've seen that can kicked down that road
> before, so I'm skeptical of such promises in general.)
>
>> Everyone seems to be jumping up and down regarding the use of the<= br> >> term of "identity" as if a foregone conclusion that this= is a synonym
>> for "privacy invasion".=C2=A0 =C2=A0However: - "Ide= ntity" does not imply
>> "personal identity".=C2=A0 Really, this is an identifier= scheme for
>> endpoints.
>
> Sorry, what I assume is the relevant draft [1] says the "identity= "
> (denoted "IDy") is a "Unique and Permanent Identity&quo= t; and that
> "Networks may treat traffic differently depending on the IDy of > source or destination" and also seems to envisage a large logical=
> database of everyone's IDy's: "Identity also allows to ha= ve metadata
> associated it to be applied, regardless of which IDf is used to
> refer it." (Where IDf is the identifier that'll later be mapp= ed
> to a locator via, I assume, HIP or LISP or similar.)
>
> I think it's entirely correct to jump up and down about the
> privacy consequences of the above. (Not to mention the potential
> censorship and discriminatory aspects.)
>
>=C2=A0 =C2=A0 =C2=A0[1] https:/= /tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01 >
>> Perhaps even "identity" is a misnomer.
>
> Well, it was presumably your choice (where your =3D=3D some set of
> the proponents). If that's a mistake, then it seems a fairly
> fatal one - to get the name wrong for an effort all about mapping
> names to identifiers;-)
>
>> If you will,
>> identity as conceived in the context of IDEAS is a second level of=
>> identifier that does not have to be exposed over the data plane -<= br> >> Because of this, it may result in greater privacy than existing >> schemes, not less.
>
> I see that argument in [1] but I'm not buying it tbh. To get
> that level of protection from such an indirection, one would
> have to have something like Tor hidden services and perhaps
> one would have to *not* standardise the mapping from human
> meaningful identifiers to those used as IDf, and esp. not the
> reverse mapping. Defining that reverse mapping cannot but be
> privacy invasive afaics. (There could maybe be ways to define
> how an already hashed human meaningful identifier could then
> be further hashed to become an IDy but I don't really see the
> point of that at all, other than to just standardise something
> for the fun of the process.)
>
>> It enables you, for example, to obfuscate
>> endpoints to outside observers as you wouldn't need to use per= sonal
>> unique long-lived identifiers, quite the contrary. - There is also= a
>> security dimension here. If I am victim of a phishing attack becau= se
>> my network information (like today) is exposed to botnets,
>
> (Nit: that says nothing about being a victim of, only of being
> a target of, an attempted attack. Speaking of victims also
> tends not to lead to more objective analysis, so I think it's
> better to not go there unless it's relevant, which I don't
> think is the case here, because...)
>
> I don't understand what network information you mean. If you
> mean email addresses, and are proposing that the email ecosystem
> change to use some IDf or LOC values, that doesn't seem at all
> realistic to me. If you don't mean email addresses then I don'= t
> see how any lower layer change will affect attempted phishes.
> The routing area is probably also the entirely wrong venue for
> any real anti-phishing effort.
>
> That really wasn't a good example;-)
>
>> phishers
>> etc who can hide from me (but not I from them) and remain anonymou= s
>> or impersonate legitimate users, I do consider this a very serious=
>> threat also to my privacy.=C2=A0 How can IETF counteract such thre= ats?=C2=A0 I
>> think that IDEAS, if done right, can provide a contribution here.<= br> >
> I don't see that at all. Unless I'm mistaken that seems like > wishful thinking to me.
>
>>
>> One aspect that has been missing from the discussion is the questi= on
>> whether there is a distinction between the network provider who >> provides GRIDS services and an outside attacker / observer.=C2=A0 = I think
>> this distinction is important.=C2=A0 The way I see it, if done rig= ht
>> (sure, big "if", and requiring detailed analysis), IDEAS= as I would
>> envision it can contribute greatly to provide greater security and=
>> privacy from outside attackers.=C2=A0 At the same time, as it is c= urrently
>> envisioned, there clearly is a trust relationship between an entit= y
>> and the provider of "its" GRIDS services.=C2=A0 The mapp= ing database will
>> have information about locator-identifier and identifier-identifie= r
>> mappings, so GRIDS will know which identifiers its endpoints are >> using.=C2=A0 Clearly, if this trust is abused because the provider= cannot
>> be trusted, if you are concerned that it sells your endpoint=C3=A2= =E2=82=AC=E2=84=A2s
>> information to the mob or a suppressive government, there is an >> issue.=C2=A0 However, when concerned about this scenario, it seems= to me
>> one would have equal reason to e.g. not trust your mobile service<= br> >> provider either, who can track you, knows your location, and has y= our
>> customer data.
>
> ISTM that introducing that GRIDS thing makes matters worse and not
> better, because, as you yourself say, it is clear that whoever has
> access to the GRIDS information would be better able to track people > compared to now.
>
> I would prefer to see fewer long lived identifiers in networking
> and not more, and this proposal introduces more long lived identifiers=
> (erroneously calling those identities).
>
> Regardless of what one thinks of them, given that things like
> HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit<= br> > adding this extra layer of indirection with a privacy invasive
> "Unique and Permanent" identifier which seems to be the only=
> non-overlapping part of this work - in fact I only see downsides.
>
> Cheers,
> S.
>
>
>>
>> --- Alex
>>
>>
>>> -----Original Message----- From: Ideas
>>> [mailto:ideas-bounce= s@ietf.org] On Behalf Of
>>> stephen.farrell@c= s.tcd.ie Sent: Wednesday, October 04, 2017 9:35
>>> AM To: tom@herbertland.= com Cc: ideas@ietf.org;
>>> phill@hallambaker.com= ; ietf@ietf.org Subject: Re: [Idea= s] WG
>>> Review: IDentity Enabled Networks (ideas)
>>>
>>>
>>>
>>> On Wednesday, 4 October 2017, Tom Herbert wrote:
>>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker
>>>> <phill@hallamb= aker.com> wrote:
>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell
>>>>> <steph= en.farrell@cs.tcd.ie> wrote:
>>>>>>
>>>>>>
>>>>>> As currently described, I oppose creation of this = working
>>>>>> group on the basis that it enables and seemingly e= ncourages
>>>>>> embedding identifiers for humans as addresses. Doi= ng so would
>>>>>> have significant privacy downsides, would enable n= ew methods
>>>>>> for censorship and discrimination, and could be ve= ry hard to
>>>>>> mitigate should one wish to help protect people= 9;s privacy, as
>>>>>> I think is current IETF policy.
>>>>>>
>>>>>> If the work precluded the use of any identifiers t= hat
>>>>>> strongly map to humans then I'd be ok with it = being done as
>>>>>> it'd then only be a waste of resources. But I = don't know how
>>>>>> that could be enforced so I think it'd be bett= er to just not
>>>>>> do this work at all.
>>>>>>
>>>>>> S.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> I know how to restrict the work to 'meaningless= 9; identifiers,
>>>>> require that the identifiers be the output of a crypto= graphic
>>>>> algorithm.
>>>>>
>>>>> Now strictly speaking, this only limits scope to ident= ifiers
>>>>> that are indexical as opposed to rendering them meanin= gless but
>>>>> I think that was the sense of it.
>>>>>
>>>>>
>>>>> N=C3=83=C2=B6th proposed a trichotemy of identifiers a= s follows
>>>>>
>>>>> * Identity, the signifier is the signified (e.g. data:= URI)
>>>>>
>>>>> * Indexical, the signifier is related to the signified= by a
>>>>> systematic relationship, (e.g. ni URIs, SHA256Data), P= GP
>>>>> fingerprints etc.)
>>>>>
>>>>> * Names,=C2=A0 the signifier is the related to the sig= nified by a
>>>>> purely conventional relationship, (e.g. example.com to it= s
>>>>> owner)
>>>>>
>>>>>
>>>>> There is a big difference between attempting to manage=
>>>>> indexical signifiers and names. Especially when the pe= ople
>>>>> trying to do so refuse to read any of the literature o= n
>>>>> semiotics.
>>>>>
>>>>> Names are problematic because the only way that a conv= entional
>>>>> relationship can be implemented is through some sort o= f
>>>>> registration infrastructure and we already have one of= those
>>>>> and the industry that manages it has a marketcap in th= e tens of
>>>>> billions.
>>>>>
>>>>> Identifiers do lead to tractable solutions. But, this = proposal
>>>>> looks a bit unfocused for IRTF consideration, an IETF = WG?
>>>>> Really?
>>>>>
>>>> Identifiers are equivalent to addresses in that they indic= ate a
>>>> node in the network for the purposes of end to end
>>>> communications. The only difference between identifiers an= d
>>>> addresses is that identifiers are not topological. Virtual=
>>>> addresses in network virtualization are also identifiers. = So the
>>>> security properties are the same when considering privacy.= For
>>>> instance, if applications use temporary addresses for priv= acy, it
>>>> would have equivalent properties using temporary identifie= rs. In
>>>> fact from the application POV this would be transparent. I= t could
>>>> get a pool of apparently random addresses to choose from a= s
>>>> source of communication, it shouldn't know or even car= e if the
>>>> addresses are identifiers.
>>>>
>>>> Identity is a completely separate concept from identifiers= . Is
>>>> not required in any of the identifier/locator protocols an= d AFAIK
>>>> none of them even mention the term. There is no associatio= n of an
>>>> identity of user behind and identifier any more than there= is an
>>>> association of identity behind IP address. The fact that t= he
>>>> words "identifier" and "identity" shar= e a common prefix is an
>>>> unfortunate happenstance :-).
>>>
>>>
>>> Yes. But doesn't that mean either the name of this effort = is wildly
>>> misleading or else the effort is hugely problematic from a pri= vacy
>>> POV? Either way, istm this ought not proceed.
>>>
>>> S.
>>>
>>>>
>>>> Tom
>>>>
>>> _______________________________________________ Ideas mai= ling list
>>> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas=


--001a11404e58c86f30055ac02d4e-- From nobody Wed Oct 4 15:34:22 2017 Return-Path: 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 785F01344D8; Wed, 4 Oct 2017 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 d-eFzVszV2nz; Wed, 4 Oct 2017 15:34:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502BB1344CD; Wed, 4 Oct 2017 15:34:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW11452; Wed, 04 Oct 2017 22:34:15 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 23:34:14 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 15:34:04 -0700 From: Alexander Clemm To: Stephen Farrell , "tom@herbertland.com" CC: "ideas@ietf.org" , "phill@hallambaker.com" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HtvaRdsDDgEqucGYSnlXKNaLMpUwAgAefuYCAABZuAIAABMSA//+mfxCAAI64gP//oHdg Date: Wed, 4 Oct 2017 22:34:03 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA739C@sjceml521-mbx.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0208.59D561E7.00E9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:34:21 -0000 SGkgU3RlcGhlbiwNCkp1c3QgYSBjb3VwbGUgb2YgcmVzcG9uc2VzIGlubGluZSwgPEFMRVg+ICAo YXQgdGhlIHJpc2sgb2YgbWFraW5nIHlvdXIgb3Bwb3NpdGlvbiBldmVuIHN0cm9uZ2VyOy0pDQot LS0gQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBoZW4g RmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IFNlbnQ6IFdlZG5l c2RheSwgT2N0b2JlciAwNCwgMjAxNyAxMjo0NSBQTQ0KPiBUbzogQWxleGFuZGVyIENsZW1tIDxh bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT47DQo+IHRvbUBoZXJiZXJ0bGFuZC5jb20NCj4gQ2M6 IGlkZWFzQGlldGYub3JnOyBwaGlsbEBoYWxsYW1iYWtlci5jb207IGlldGZAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtJZGVhc10gV0cgUmV2aWV3OiBJRGVudGl0eSBFbmFibGVkIE5ldHdvcmtz IChpZGVhcykNCj4gDQo+IA0KPiBIaXlhLA0KPiANCj4gVEw7RFIgLSBJIGFtIG5vdyBldmVuIG1v cmUgY29udmluY2VkIHRoYXQgdGhpcyBvdWdodCBub3QgZ28gYWhlYWQuIChTb3JyeTstKQ0KPiAN Cj4gT24gMDQvMTAvMTcgMTk6NDgsIEFsZXhhbmRlciBDbGVtbSB3cm90ZToNCj4gPiBUaGVyZSB3 ZXJlIGEgY291cGxlIG9mIHRoaW5ncyByYWlzZWQgaW4gdGhlIG92ZXJhbGwgdGhyZWFkIHRoYXQg SSBqdXN0DQo+ID4gd2FudGVkIHRvIHF1aWNrbHkgcmVzcG9uZCB0bzoNCj4gPg0KPiA+IENsZWFy bHkgcHJpdmFjeSBpcyBhbiBpbXBvcnRhbnQgaXNzdWUgYW5kIGNvbmNlcm4uICBUaGUgY3VycmVu dA0KPiA+IGNoYXJ0ZXIgcHJvcG9zYWwgaW5jbHVkZXMgYSByZXF1aXJlbWVudCBmb3IgYSBkZXRh aWxlZCBhbmFseXNpcyBvZg0KPiA+IHRoaXMgYXNwZWN0LiAgSWYgdGhpcyBhc3BlY3QgbmVlZHMg dG8gYmUgZXhwYW5kZWQsIHN1cmUsIGxldCdzIGRvDQo+ID4gdGhpcy4NCj4gDQo+IFRCSCwgSSBk b24ndCB0aGluayB0aGF0J2QgaGVscCwgZm9yIG1lIGF0IGxlYXN0LiBJIGRvbid0IHNlZSBhbnkg d2F5IGluIHdoaWNoDQo+IHN1Y2ggcGVybWFuZW50IHN0cmluZ3MgcmVwcmVzZW50aW5nIGlkZW50 aXR5IGNhbiBiZSBkZWZpbmVkIHRvIGJlIHVzYWJsZSBhcw0KPiBjbGFpbWVkIGFuZCBub3QgYmUg cGVybmljaW91c2x5IHByaXZhY3kgaW52YXNpdmUuIFNvIHNvbWUgcHJvbWlzZXMgdG8NCj4gcG9u ZGVyIHRoZSBwcm9ibGVtIGluIGNoYXJ0ZXIgdGV4dCB3b3VsZG4ndCBkbyBpdCBmb3IgbWUuIChB bmQgdGJoLCBJJ3ZlIHNlZW4NCj4gdGhhdCBjYW4ga2lja2VkIGRvd24gdGhhdCByb2FkIGJlZm9y ZSwgc28gSSdtIHNrZXB0aWNhbCBvZiBzdWNoIHByb21pc2VzIGluDQo+IGdlbmVyYWwuKQ0KPiAN Cj4gPiBFdmVyeW9uZSBzZWVtcyB0byBiZSBqdW1waW5nIHVwIGFuZCBkb3duIHJlZ2FyZGluZyB0 aGUgdXNlIG9mIHRoZSB0ZXJtDQo+ID4gb2YgImlkZW50aXR5IiBhcyBpZiBhIGZvcmVnb25lIGNv bmNsdXNpb24gdGhhdCB0aGlzIGlzIGEgc3lub255bQ0KPiA+IGZvciAicHJpdmFjeSBpbnZhc2lv biIuICAgSG93ZXZlcjogLSAiSWRlbnRpdHkiIGRvZXMgbm90IGltcGx5DQo+ID4gInBlcnNvbmFs IGlkZW50aXR5Ii4gIFJlYWxseSwgdGhpcyBpcyBhbiBpZGVudGlmaWVyIHNjaGVtZSBmb3INCj4g PiBlbmRwb2ludHMuDQo+IA0KPiBTb3JyeSwgd2hhdCBJIGFzc3VtZSBpcyB0aGUgcmVsZXZhbnQg ZHJhZnQgWzFdIHNheXMgdGhlICJpZGVudGl0eSINCj4gKGRlbm90ZWQgIklEeSIpIGlzIGEgIlVu aXF1ZSBhbmQgUGVybWFuZW50IElkZW50aXR5IiBhbmQgdGhhdCAiTmV0d29ya3MNCj4gbWF5IHRy ZWF0IHRyYWZmaWMgZGlmZmVyZW50bHkgZGVwZW5kaW5nIG9uIHRoZSBJRHkgb2Ygc291cmNlIG9y IGRlc3RpbmF0aW9uIg0KPiBhbmQgYWxzbyBzZWVtcyB0byBlbnZpc2FnZSBhIGxhcmdlIGxvZ2lj YWwgZGF0YWJhc2Ugb2YgZXZlcnlvbmUncyBJRHknczoNCj4gIklkZW50aXR5IGFsc28gYWxsb3dz IHRvIGhhdmUgbWV0YWRhdGEgYXNzb2NpYXRlZCBpdCB0byBiZSBhcHBsaWVkLCByZWdhcmRsZXNz DQo+IG9mIHdoaWNoIElEZiBpcyB1c2VkIHRvIHJlZmVyIGl0LiIgKFdoZXJlIElEZiBpcyB0aGUg aWRlbnRpZmllciB0aGF0J2xsIGxhdGVyIGJlDQo+IG1hcHBlZCB0byBhIGxvY2F0b3IgdmlhLCBJ IGFzc3VtZSwgSElQIG9yIExJU1Agb3Igc2ltaWxhci4pDQoNCjxBTEVYPiBUaGUgaW50ZW50IGlz IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gaG93IHlvdSB3b3VsZCBiZSBpZGVudGlmaWVkIHRocm91 Z2ggYSBwcml2YXRlL3NlY3VyZWQvYXV0aGVudGljYXRlZCBjb250cm9sIHBsYW5lICh3aGljaCBp cyB0aGUgbG9uZ2VyLWxpdmVkICJhbmNob3IiIGlkZW50aWZpZXIpIHZzIG91dCBpbiB0aGUgb3Bl biAoc2hvcnRlci1saXZlZCBpZGVudGlmaWVycyBmb3IgdXNlIG9uIHRoZSBkYXRhIHBsYW5lIHRo YXQgcHJvdmlkZXIgZ3JlYXRlciBhbm9ueW1pemF0aW9uLCBtYWtpbmcgaXQgbW9yZSBkaWZmaWN1 bHQgdG8gdHJhY2sgdXNlcnMgYnkgb3V0c2lkZSBvYnNlcnZlcnMpLiAgVGhlIGFzc3VtcHRpb24g aXMgdGhhdCBhIGRpc3RpbmN0aW9uIGNhbiBiZSBtYWRlIGJldHdlZW4gb3V0c2lkZSAzcmQgcGFy dHkgb2JzZXJ2ZXIgdnMgcHJvdmlkZXIgb2YgdGhlIEdSSURTIHNlcnZpY2VzLiANCg0KSSBndWVz cyBhIGJpZyBwYXJ0IG9mIHRoZSBjb250cm92ZXJzeSBhbmQgeW91ciByZWFjdGlvbiBjb21lcyBm cm9tIHRoZSBzdGF0ZW1lbnQgIk5ldHdvcmtzIG1heSB0cmVhdCB0cmFmZmljIGRpZmZlcmVudGx5 IGRlcGVuZGluZyBvbiBJRHkgb2Ygc291cmNlIG9yIGRlc3RpbmF0aW9uIi4gIEkgY2FuIHNlZSB0 aGF0IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgcmVmcmFtZWQuIFRoZSBpdGVt IG9mIGNvbmNlcm4gaGVyZSBjb25jZXJucyBzY2VuYXJpb3MgbGlrZSB0aGF0IGFzIGEgdXNlciwg SSBtaWdodCB3YW50IHRvIGJlIGFibGUgdG8gZGVmaW5lIGFjY2VzcyBydWxlcyB3aG8gY2FuIGNv bnRhY3QgbWUgbXVjaCBsaWtlIGZyZXF1ZW50bHkgZG9uZSB1c2luZyBmaXJld2FsbCBydWxlcy4g IEZvciBleGFtcGxlLCBubyBXZWJjYW1zL0lvVCBkZXZpY2VzIChwYXJ0IG9mIHRoZSBtZXRhZGF0 YSkgc2hvdWxkIGNvbnRhY3QgbWUuICBSYXRoZXIgdGhhbiBwdXR0aW5nIHRoZSBvbnVzIG9uIG15 IGVuZCBkZXZpY2UgdG8gdHJ5IGFuZCBibG9jayBpbGxlZ2l0aW1hdGUgdHJhZmZpYyBhbmQgZXhw b3NpbmcgbWUgdG8gRG9TIGF0dGFja3Mgb3Igd29yc2UsIEkgbWlnaHQgd2FudCB0byBiZSBhYmxl IHRvIGFydGljdWxhdGUgYSBwb2xpY3kgdG8gdGhhdCBlZmZlY3QgYW5kIGFzayBHUklEUyB0byBu b3QgcHJvdmlkZSBteSBsb2NhdG9yIGluZm9ybWF0aW9uIHRvIGUuZy4gYSBNaXJhaS1jb250cm9s bGVkIFdlYmNhbS4gIE9uZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdvdWxkIHdhbnQgcG9saWNp ZXMgdG8gYmUgYXJ0aWN1bGF0ZWQgdGhhdCByZWZlciB0byBzcGVjaWZpYyBpZGVudGlmaWVycy4g IElmIHdlIHdlcmUgdG8gYWxsb3cgc3VjaCBhIHRoaW5nLCB0aGUgcXVlc3Rpb24gYWJvdXQgaG93 IHRvIG1haW50YWluIHN1Y2ggcnVsZXMgaW1tZWRpYXRlbHkgY29tZXMgdXAgLSBnaXZlbiBpZGVu dGZpZXJzIGFyZSBhbm9ueW1pemVkIGFuZCBmYXN0IGNoYW5naW5nLCB3aGF0IHNlbnNlIHdvdWxk IGl0IG1ha2UgdG8gZXZlbiB0cnkgdG8gYXJ0aWN1bGF0ZSBzdWNoIGEgcnVsZT8gIEhlcmUgaXQg d291bGQgbWFrZSBzZW5zZSB0byBhcnRpY3VsYXRlIGEgcnVsZSBhbG9uZyB0aGUgbGluZXMgb2Yg ImFwcGx5IHRoaXMgcnVsZSB0byB0aGUgZW50aXR5IHRoYXQgdGhlIGlkZW50aWZpZXIgcmVmZXJz IHRvIi4gICANCg0KWW91IGNhbiBkaXNhZ3JlZSB3aXRoIHRoaXMsIGJ1dCB0aGlzIGlzIGp1c3Qg dG8gcHJvdmlkZSBzb21lIGV4cGxhbmF0aW9uIHJlZ2FyZGluZyBiYWNrZ3JvdW5kLiAgSSBkb27i gJl0IHRoaW5rIHRoZXNlIGFyZSBpbGxlZ2l0aW1hdGUgY29uY2VybnMuICBTbywgaG93IGNhbiB3 ZSBmcmFtZSB0aGluZ3MgYWNjb3JkaW5nbHk/ICANCjwvQUxFWD4NCg0KPiANCj4gSSB0aGluayBp dCdzIGVudGlyZWx5IGNvcnJlY3QgdG8ganVtcCB1cCBhbmQgZG93biBhYm91dCB0aGUgcHJpdmFj eQ0KPiBjb25zZXF1ZW5jZXMgb2YgdGhlIGFib3ZlLiAoTm90IHRvIG1lbnRpb24gdGhlIHBvdGVu dGlhbCBjZW5zb3JzaGlwIGFuZA0KPiBkaXNjcmltaW5hdG9yeSBhc3BlY3RzLikNCj4gDQo+ICAg ICAgWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jY20taWRlYXMtaWRlbnRp dHktdXNlLWNhc2VzLTAxDQo+IA0KPiA+IFBlcmhhcHMgZXZlbiAiaWRlbnRpdHkiIGlzIGEgbWlz bm9tZXIuDQo+IA0KPiBXZWxsLCBpdCB3YXMgcHJlc3VtYWJseSB5b3VyIGNob2ljZSAod2hlcmUg eW91ciA9PSBzb21lIHNldCBvZiB0aGUNCj4gcHJvcG9uZW50cykuIElmIHRoYXQncyBhIG1pc3Rh a2UsIHRoZW4gaXQgc2VlbXMgYSBmYWlybHkgZmF0YWwgb25lIC0gdG8gZ2V0IHRoZQ0KPiBuYW1l IHdyb25nIGZvciBhbiBlZmZvcnQgYWxsIGFib3V0IG1hcHBpbmcgbmFtZXMgdG8gaWRlbnRpZmll cnM7LSkNCg0KPEFMRVg+IEFnYWluLCBub3QgaWRlbnRpdHkgaXMgZXhwb3NlZCBvbiB0aGUgZGF0 YSBwbGFuZS4gIFdoYXQgdGVybSB3b3VsZCB5b3Ugc3VnZ2VzdD8gICA8L0FMRVg+IA0KDQo+IA0K PiA+IElmIHlvdSB3aWxsLA0KPiA+IGlkZW50aXR5IGFzIGNvbmNlaXZlZCBpbiB0aGUgY29udGV4 dCBvZiBJREVBUyBpcyBhIHNlY29uZCBsZXZlbCBvZg0KPiA+IGlkZW50aWZpZXIgdGhhdCBkb2Vz IG5vdCBoYXZlIHRvIGJlIGV4cG9zZWQgb3ZlciB0aGUgZGF0YSBwbGFuZSAtDQo+ID4gQmVjYXVz ZSBvZiB0aGlzLCBpdCBtYXkgcmVzdWx0IGluIGdyZWF0ZXIgcHJpdmFjeSB0aGFuIGV4aXN0aW5n DQo+ID4gc2NoZW1lcywgbm90IGxlc3MuDQo+IA0KPiBJIHNlZSB0aGF0IGFyZ3VtZW50IGluIFsx XSBidXQgSSdtIG5vdCBidXlpbmcgaXQgdGJoLiBUbyBnZXQgdGhhdCBsZXZlbCBvZg0KPiBwcm90 ZWN0aW9uIGZyb20gc3VjaCBhbiBpbmRpcmVjdGlvbiwgb25lIHdvdWxkIGhhdmUgdG8gaGF2ZSBz b21ldGhpbmcgbGlrZQ0KPiBUb3IgaGlkZGVuIHNlcnZpY2VzIGFuZCBwZXJoYXBzIG9uZSB3b3Vs ZCBoYXZlIHRvICpub3QqIHN0YW5kYXJkaXNlIHRoZQ0KPiBtYXBwaW5nIGZyb20gaHVtYW4gbWVh bmluZ2Z1bCBpZGVudGlmaWVycyB0byB0aG9zZSB1c2VkIGFzIElEZiwgYW5kIGVzcC4NCj4gbm90 IHRoZSByZXZlcnNlIG1hcHBpbmcuIERlZmluaW5nIHRoYXQgcmV2ZXJzZSBtYXBwaW5nIGNhbm5v dCBidXQgYmUNCj4gcHJpdmFjeSBpbnZhc2l2ZSBhZmFpY3MuIChUaGVyZSBjb3VsZCBtYXliZSBi ZSB3YXlzIHRvIGRlZmluZSBob3cgYW4gYWxyZWFkeQ0KPiBoYXNoZWQgaHVtYW4gbWVhbmluZ2Z1 bCBpZGVudGlmaWVyIGNvdWxkIHRoZW4gYmUgZnVydGhlciBoYXNoZWQgdG8NCj4gYmVjb21lIGFu IElEeSBidXQgSSBkb24ndCByZWFsbHkgc2VlIHRoZSBwb2ludCBvZiB0aGF0IGF0IGFsbCwgb3Ro ZXIgdGhhbiB0byBqdXN0DQo+IHN0YW5kYXJkaXNlIHNvbWV0aGluZyBmb3IgdGhlIGZ1biBvZiB0 aGUgcHJvY2Vzcy4pDQoNCjxBTEVYPiBBcmUgeW91IGFyZ3VpbmcgYWdhaW5zdCB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQgb2YgdGhlIHBhcnRpY3VsYXIgc29sdXRpb24/ICAgDQo8L0FMRVg+DQoNCj4g DQo+ID4gSXQgZW5hYmxlcyB5b3UsIGZvciBleGFtcGxlLCB0byBvYmZ1c2NhdGUgZW5kcG9pbnRz IHRvIG91dHNpZGUNCj4gPiBvYnNlcnZlcnMgYXMgeW91IHdvdWxkbid0IG5lZWQgdG8gdXNlIHBl cnNvbmFsIHVuaXF1ZSBsb25nLWxpdmVkDQo+ID4gaWRlbnRpZmllcnMsIHF1aXRlIHRoZSBjb250 cmFyeS4gLSBUaGVyZSBpcyBhbHNvIGEgc2VjdXJpdHkgZGltZW5zaW9uDQo+ID4gaGVyZS4gSWYg SSBhbSB2aWN0aW0gb2YgYSBwaGlzaGluZyBhdHRhY2sgYmVjYXVzZSBteSBuZXR3b3JrDQo+ID4g aW5mb3JtYXRpb24gKGxpa2UgdG9kYXkpIGlzIGV4cG9zZWQgdG8gYm90bmV0cywNCj4gDQo+IChO aXQ6IHRoYXQgc2F5cyBub3RoaW5nIGFib3V0IGJlaW5nIGEgdmljdGltIG9mLCBvbmx5IG9mIGJl aW5nIGEgdGFyZ2V0IG9mLCBhbg0KPiBhdHRlbXB0ZWQgYXR0YWNrLiBTcGVha2luZyBvZiB2aWN0 aW1zIGFsc28gdGVuZHMgbm90IHRvIGxlYWQgdG8gbW9yZQ0KPiBvYmplY3RpdmUgYW5hbHlzaXMs IHNvIEkgdGhpbmsgaXQncyBiZXR0ZXIgdG8gbm90IGdvIHRoZXJlIHVubGVzcyBpdCdzIHJlbGV2 YW50LA0KPiB3aGljaCBJIGRvbid0IHRoaW5rIGlzIHRoZSBjYXNlIGhlcmUsIGJlY2F1c2UuLi4p DQoNCjxBTEVYPiBJIHdhcyB1c2luZyB0aGUgdGVybSAiSSIgYXMgYSBmaWd1cmUgb2Ygc3BlZWNo LiAgSSBhbSBub3Qgc3BlYWtpbmcgYXMgYSB2aWN0aW0gaGVyZS4gIEFzIGEgdGFyZ2V0LCBzdXJl LiAgICANCjwvQUxFWD4NCg0KPiANCj4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgbmV0d29yayBp bmZvcm1hdGlvbiB5b3UgbWVhbi4gSWYgeW91IG1lYW4gZW1haWwNCj4gYWRkcmVzc2VzLCBhbmQg YXJlIHByb3Bvc2luZyB0aGF0IHRoZSBlbWFpbCBlY29zeXN0ZW0gY2hhbmdlIHRvIHVzZSBzb21l DQo+IElEZiBvciBMT0MgdmFsdWVzLCB0aGF0IGRvZXNuJ3Qgc2VlbSBhdCBhbGwgcmVhbGlzdGlj IHRvIG1lLiBJZiB5b3UgZG9uJ3QgbWVhbg0KPiBlbWFpbCBhZGRyZXNzZXMgdGhlbiBJIGRvbid0 IHNlZSBob3cgYW55IGxvd2VyIGxheWVyIGNoYW5nZSB3aWxsIGFmZmVjdA0KPiBhdHRlbXB0ZWQg cGhpc2hlcy4NCj4gVGhlIHJvdXRpbmcgYXJlYSBpcyBwcm9iYWJseSBhbHNvIHRoZSBlbnRpcmVs eSB3cm9uZyB2ZW51ZSBmb3IgYW55IHJlYWwgYW50aS0NCj4gcGhpc2hpbmcgZWZmb3J0Lg0KPiAN Cj4gVGhhdCByZWFsbHkgd2Fzbid0IGEgZ29vZCBleGFtcGxlOy0pDQoNCjxBTEVYPiBJIGFtIHJl ZmVycmluZyB0byBsb2NhdG9yIGluZm9ybWF0aW9uLiAgVG8gcGhpc2ggbWUsIHNvbWVvbmUgbmVl ZHMgdG8gb2J0YWluIG15IGxvY2F0b3IuIA0KSSBhbSBjb25jZXJuZWQgYWJvdXQgcHJpdmFjeS4g IERvIEkgaGF2ZSBhIHJpZ2h0IHRvIHByaXZhY3kgZm9yIG15IGxvY2F0b3IgaW5mb3JtYXRpb24/ ICANCjwvQUxFWD4NCg0KPiANCj4gPiBwaGlzaGVycw0KPiA+IGV0YyB3aG8gY2FuIGhpZGUgZnJv bSBtZSAoYnV0IG5vdCBJIGZyb20gdGhlbSkgYW5kIHJlbWFpbiBhbm9ueW1vdXMgb3INCj4gPiBp bXBlcnNvbmF0ZSBsZWdpdGltYXRlIHVzZXJzLCBJIGRvIGNvbnNpZGVyIHRoaXMgYSB2ZXJ5IHNl cmlvdXMgdGhyZWF0DQo+ID4gYWxzbyB0byBteSBwcml2YWN5LiAgSG93IGNhbiBJRVRGIGNvdW50 ZXJhY3Qgc3VjaCB0aHJlYXRzPyAgSSB0aGluaw0KPiA+IHRoYXQgSURFQVMsIGlmIGRvbmUgcmln aHQsIGNhbiBwcm92aWRlIGEgY29udHJpYnV0aW9uIGhlcmUuDQo+IA0KPiBJIGRvbid0IHNlZSB0 aGF0IGF0IGFsbC4gVW5sZXNzIEknbSBtaXN0YWtlbiB0aGF0IHNlZW1zIGxpa2Ugd2lzaGZ1bCB0 aGlua2luZyB0bw0KPiBtZS4NCg0KPEFMRVg+IE1heWJlIGl0IGlzIHdpc2hmdWwsIGJ1dCBJIGRv IHRoaW5rIHRoYXQgdGhlc2UgdHJlYXRzIGFyZSByZWFsIGFuZCB0aGF0IGl0IGlzIG5vdCBkaXNo b25vcmFibGUgdG8gdHJ5IHRvIGNvdW50ZXJhY3QgdGhlbS4gIEp1c3QgbGlrZSB0aHJlYXRzIG9u IHByaXZhY3kgKGEgYmlnIGNvbmNlcm4gb24gdGhpcyB0aHJlYWQpIGFyZSByZWFsIGFuZCBuZWVk IHRvIGJlIGNvdW50ZXJhY3RlZDsgSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggdGhpcyBieSB0aGUg d2F5IGJ1dCBkbyBiZWxpZXZlIHdlIGhhdmUgdG8gc3RyaWtlIGEgYmFsYW5jZSB3aXRoIHNlY3Vy aXR5LiAgPC9BTEVYPg0KDQo+IA0KPiA+DQo+ID4gT25lIGFzcGVjdCB0aGF0IGhhcyBiZWVuIG1p c3NpbmcgZnJvbSB0aGUgZGlzY3Vzc2lvbiBpcyB0aGUgcXVlc3Rpb24NCj4gPiB3aGV0aGVyIHRo ZXJlIGlzIGEgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGUgbmV0d29yayBwcm92aWRlciB3aG8NCj4g PiBwcm92aWRlcyBHUklEUyBzZXJ2aWNlcyBhbmQgYW4gb3V0c2lkZSBhdHRhY2tlciAvIG9ic2Vy dmVyLiAgSSB0aGluaw0KPiA+IHRoaXMgZGlzdGluY3Rpb24gaXMgaW1wb3J0YW50LiAgVGhlIHdh eSBJIHNlZSBpdCwgaWYgZG9uZSByaWdodCAoc3VyZSwNCj4gPiBiaWcgImlmIiwgYW5kIHJlcXVp cmluZyBkZXRhaWxlZCBhbmFseXNpcyksIElERUFTIGFzIEkgd291bGQgZW52aXNpb24NCj4gPiBp dCBjYW4gY29udHJpYnV0ZSBncmVhdGx5IHRvIHByb3ZpZGUgZ3JlYXRlciBzZWN1cml0eSBhbmQg cHJpdmFjeSBmcm9tDQo+ID4gb3V0c2lkZSBhdHRhY2tlcnMuICBBdCB0aGUgc2FtZSB0aW1lLCBh cyBpdCBpcyBjdXJyZW50bHkgZW52aXNpb25lZCwNCj4gPiB0aGVyZSBjbGVhcmx5IGlzIGEgdHJ1 c3QgcmVsYXRpb25zaGlwIGJldHdlZW4gYW4gZW50aXR5IGFuZCB0aGUNCj4gPiBwcm92aWRlciBv ZiAiaXRzIiBHUklEUyBzZXJ2aWNlcy4gIFRoZSBtYXBwaW5nIGRhdGFiYXNlIHdpbGwgaGF2ZQ0K PiA+IGluZm9ybWF0aW9uIGFib3V0IGxvY2F0b3ItaWRlbnRpZmllciBhbmQgaWRlbnRpZmllci1p ZGVudGlmaWVyDQo+ID4gbWFwcGluZ3MsIHNvIEdSSURTIHdpbGwga25vdyB3aGljaCBpZGVudGlm aWVycyBpdHMgZW5kcG9pbnRzIGFyZQ0KPiA+IHVzaW5nLiAgQ2xlYXJseSwgaWYgdGhpcyB0cnVz dCBpcyBhYnVzZWQgYmVjYXVzZSB0aGUgcHJvdmlkZXIgY2Fubm90DQo+ID4gYmUgdHJ1c3RlZCwg aWYgeW91IGFyZSBjb25jZXJuZWQgdGhhdCBpdCBzZWxscyB5b3VyIGVuZHBvaW50w6LigqzihKJz DQo+ID4gaW5mb3JtYXRpb24gdG8gdGhlIG1vYiBvciBhIHN1cHByZXNzaXZlIGdvdmVybm1lbnQs IHRoZXJlIGlzIGFuIGlzc3VlLg0KPiA+IEhvd2V2ZXIsIHdoZW4gY29uY2VybmVkIGFib3V0IHRo aXMgc2NlbmFyaW8sIGl0IHNlZW1zIHRvIG1lIG9uZSB3b3VsZA0KPiA+IGhhdmUgZXF1YWwgcmVh c29uIHRvIGUuZy4gbm90IHRydXN0IHlvdXIgbW9iaWxlIHNlcnZpY2UgcHJvdmlkZXINCj4gPiBl aXRoZXIsIHdobyBjYW4gdHJhY2sgeW91LCBrbm93cyB5b3VyIGxvY2F0aW9uLCBhbmQgaGFzIHlv dXIgY3VzdG9tZXINCj4gPiBkYXRhLg0KPiANCj4gSVNUTSB0aGF0IGludHJvZHVjaW5nIHRoYXQg R1JJRFMgdGhpbmcgbWFrZXMgbWF0dGVycyB3b3JzZSBhbmQgbm90IGJldHRlciwNCj4gYmVjYXVz ZSwgYXMgeW91IHlvdXJzZWxmIHNheSwgaXQgaXMgY2xlYXIgdGhhdCB3aG9ldmVyIGhhcyBhY2Nl c3MgdG8gdGhlIEdSSURTDQo+IGluZm9ybWF0aW9uIHdvdWxkIGJlIGJldHRlciBhYmxlIHRvIHRy YWNrIHBlb3BsZSBjb21wYXJlZCB0byBub3cuDQo+IA0KPiBJIHdvdWxkIHByZWZlciB0byBzZWUg ZmV3ZXIgbG9uZyBsaXZlZCBpZGVudGlmaWVycyBpbiBuZXR3b3JraW5nIGFuZCBub3QNCj4gbW9y ZSwgYW5kIHRoaXMgcHJvcG9zYWwgaW50cm9kdWNlcyBtb3JlIGxvbmcgbGl2ZWQgaWRlbnRpZmll cnMgKGVycm9uZW91c2x5DQo+IGNhbGxpbmcgdGhvc2UgaWRlbnRpdGllcykuDQoNCjxBTEVYPiBT ZWUgYWJvdmUuICBJIHJlYWxseSBiZWxpZXZlIHRoaXMgd2lsbCByZXN1bHQgaW4gZmV3ZXIgbG9u Zy1saXZlZCBpZGVudGlmaWVycyB1c2VkIGluIHRoZSBkYXRhIHBsYW5lLiAgVGhhdCB0aGlzIHdv dWxkIHNvbWVob3cgbWFuZGF0ZSBsb25nLWxpdmVkIHBlcnNvbi1pZGVudGlmeWluZyBpZGVudGlm aWVycyBvbiB0aGUgZGF0YSBwbGFuZSBpcyBhIG1pc2NvbmNlcHRpb24uIA0KKGVuZCBvZiBteSBj b21tZW50cykNCjwvQUxFWD4NCg0KPiANCj4gUmVnYXJkbGVzcyBvZiB3aGF0IG9uZSB0aGlua3Mg b2YgdGhlbSwgZ2l2ZW4gdGhhdCB0aGluZ3MgbGlrZSBISVAgYW5kIExJU1ANCj4gZXhpc3QsIGFu ZCB0cnkgdGFja2xlIHRoZSBJRC9MT0Mgc3BsaXQsIEkgc2VlIG5vIGJlbmVmaXQgYWRkaW5nIHRo aXMgZXh0cmEgbGF5ZXINCj4gb2YgaW5kaXJlY3Rpb24gd2l0aCBhIHByaXZhY3kgaW52YXNpdmUg IlVuaXF1ZSBhbmQgUGVybWFuZW50IiBpZGVudGlmaWVyDQo+IHdoaWNoIHNlZW1zIHRvIGJlIHRo ZSBvbmx5IG5vbi1vdmVybGFwcGluZyBwYXJ0IG9mIHRoaXMgd29yayAtIGluIGZhY3QgSSBvbmx5 DQo+IHNlZSBkb3duc2lkZXMuDQo+IA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiANCj4gPg0KPiA+ IC0tLSBBbGV4DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9t OiBJZGVhcw0KPiA+PiBbbWFpbHRvOmlkZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zg0KPiA+PiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIFNlbnQ6IFdlZG5lc2RheSwgT2N0b2Jl ciAwNCwgMjAxNyA5OjM1IEFNDQo+ID4+IFRvOiB0b21AaGVyYmVydGxhbmQuY29tIENjOiBpZGVh c0BpZXRmLm9yZzsgcGhpbGxAaGFsbGFtYmFrZXIuY29tOw0KPiA+PiBpZXRmQGlldGYub3JnIFN1 YmplY3Q6IFJlOiBbSWRlYXNdIFdHDQo+ID4+IFJldmlldzogSURlbnRpdHkgRW5hYmxlZCBOZXR3 b3JrcyAoaWRlYXMpDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIFdlZG5lc2RheSwgNCBPY3Rv YmVyIDIwMTcsIFRvbSBIZXJiZXJ0IHdyb3RlOg0KPiA+Pj4gT24gV2VkLCBPY3QgNCwgMjAxNyBh dCA3OjU3IEFNLCBQaGlsbGlwIEhhbGxhbS1CYWtlcg0KPiA+Pj4gPHBoaWxsQGhhbGxhbWJha2Vy LmNvbT4gd3JvdGU6DQo+ID4+Pj4gT24gRnJpLCBTZXAgMjksIDIwMTcgYXQgMjozMSBQTSwgU3Rl cGhlbiBGYXJyZWxsDQo+ID4+Pj4gPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0K PiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBcyBjdXJyZW50bHkgZGVzY3JpYmVkLCBJIG9wcG9z ZSBjcmVhdGlvbiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgb24NCj4gPj4+Pj4gdGhlIGJhc2lzIHRo YXQgaXQgZW5hYmxlcyBhbmQgc2VlbWluZ2x5IGVuY291cmFnZXMgZW1iZWRkaW5nDQo+ID4+Pj4+ IGlkZW50aWZpZXJzIGZvciBodW1hbnMgYXMgYWRkcmVzc2VzLiBEb2luZyBzbyB3b3VsZCBoYXZl DQo+ID4+Pj4+IHNpZ25pZmljYW50IHByaXZhY3kgZG93bnNpZGVzLCB3b3VsZCBlbmFibGUgbmV3 IG1ldGhvZHMgZm9yDQo+ID4+Pj4+IGNlbnNvcnNoaXAgYW5kIGRpc2NyaW1pbmF0aW9uLCBhbmQg Y291bGQgYmUgdmVyeSBoYXJkIHRvIG1pdGlnYXRlDQo+ID4+Pj4+IHNob3VsZCBvbmUgd2lzaCB0 byBoZWxwIHByb3RlY3QgcGVvcGxlJ3MgcHJpdmFjeSwgYXMgSSB0aGluayBpcw0KPiA+Pj4+PiBj dXJyZW50IElFVEYgcG9saWN5Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiB0aGUgd29yayBwcmVjbHVk ZWQgdGhlIHVzZSBvZiBhbnkgaWRlbnRpZmllcnMgdGhhdCBzdHJvbmdseSBtYXANCj4gPj4+Pj4g dG8gaHVtYW5zIHRoZW4gSSdkIGJlIG9rIHdpdGggaXQgYmVpbmcgZG9uZSBhcyBpdCdkIHRoZW4g b25seSBiZSBhDQo+ID4+Pj4+IHdhc3RlIG9mIHJlc291cmNlcy4gQnV0IEkgZG9uJ3Qga25vdyBo b3cgdGhhdCBjb3VsZCBiZSBlbmZvcmNlZCBzbw0KPiA+Pj4+PiBJIHRoaW5rIGl0J2QgYmUgYmV0 dGVyIHRvIGp1c3Qgbm90IGRvIHRoaXMgd29yayBhdCBhbGwuDQo+ID4+Pj4+DQo+ID4+Pj4+IFMu DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICsxDQo+ID4+Pj4NCj4gPj4+PiBJIGtub3cgaG93IHRv IHJlc3RyaWN0IHRoZSB3b3JrIHRvICdtZWFuaW5nbGVzcycgaWRlbnRpZmllcnMsDQo+ID4+Pj4g cmVxdWlyZSB0aGF0IHRoZSBpZGVudGlmaWVycyBiZSB0aGUgb3V0cHV0IG9mIGEgY3J5cHRvZ3Jh cGhpYw0KPiA+Pj4+IGFsZ29yaXRobS4NCj4gPj4+Pg0KPiA+Pj4+IE5vdyBzdHJpY3RseSBzcGVh a2luZywgdGhpcyBvbmx5IGxpbWl0cyBzY29wZSB0byBpZGVudGlmaWVycyB0aGF0DQo+ID4+Pj4g YXJlIGluZGV4aWNhbCBhcyBvcHBvc2VkIHRvIHJlbmRlcmluZyB0aGVtIG1lYW5pbmdsZXNzIGJ1 dCBJIHRoaW5rDQo+ID4+Pj4gdGhhdCB3YXMgdGhlIHNlbnNlIG9mIGl0Lg0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+PiBOw4PCtnRoIHByb3Bvc2VkIGEgdHJpY2hvdGVteSBvZiBpZGVudGlmaWVycyBh cyBmb2xsb3dzDQo+ID4+Pj4NCj4gPj4+PiAqIElkZW50aXR5LCB0aGUgc2lnbmlmaWVyIGlzIHRo ZSBzaWduaWZpZWQgKGUuZy4gZGF0YTogVVJJKQ0KPiA+Pj4+DQo+ID4+Pj4gKiBJbmRleGljYWws IHRoZSBzaWduaWZpZXIgaXMgcmVsYXRlZCB0byB0aGUgc2lnbmlmaWVkIGJ5IGENCj4gPj4+PiBz eXN0ZW1hdGljIHJlbGF0aW9uc2hpcCwgKGUuZy4gbmkgVVJJcywgU0hBMjU2RGF0YSksIFBHUA0K PiA+Pj4+IGZpbmdlcnByaW50cyBldGMuKQ0KPiA+Pj4+DQo+ID4+Pj4gKiBOYW1lcywgIHRoZSBz aWduaWZpZXIgaXMgdGhlIHJlbGF0ZWQgdG8gdGhlIHNpZ25pZmllZCBieSBhIHB1cmVseQ0KPiA+ Pj4+IGNvbnZlbnRpb25hbCByZWxhdGlvbnNoaXAsIChlLmcuIGV4YW1wbGUuY29tIHRvIGl0cw0K PiA+Pj4+IG93bmVyKQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBUaGVyZSBpcyBhIGJpZyBkaWZm ZXJlbmNlIGJldHdlZW4gYXR0ZW1wdGluZyB0byBtYW5hZ2UgaW5kZXhpY2FsDQo+ID4+Pj4gc2ln bmlmaWVycyBhbmQgbmFtZXMuIEVzcGVjaWFsbHkgd2hlbiB0aGUgcGVvcGxlIHRyeWluZyB0byBk byBzbw0KPiA+Pj4+IHJlZnVzZSB0byByZWFkIGFueSBvZiB0aGUgbGl0ZXJhdHVyZSBvbiBzZW1p b3RpY3MuDQo+ID4+Pj4NCj4gPj4+PiBOYW1lcyBhcmUgcHJvYmxlbWF0aWMgYmVjYXVzZSB0aGUg b25seSB3YXkgdGhhdCBhIGNvbnZlbnRpb25hbA0KPiA+Pj4+IHJlbGF0aW9uc2hpcCBjYW4gYmUg aW1wbGVtZW50ZWQgaXMgdGhyb3VnaCBzb21lIHNvcnQgb2YNCj4gPj4+PiByZWdpc3RyYXRpb24g aW5mcmFzdHJ1Y3R1cmUgYW5kIHdlIGFscmVhZHkgaGF2ZSBvbmUgb2YgdGhvc2UgYW5kDQo+ID4+ Pj4gdGhlIGluZHVzdHJ5IHRoYXQgbWFuYWdlcyBpdCBoYXMgYSBtYXJrZXRjYXAgaW4gdGhlIHRl bnMgb2YNCj4gPj4+PiBiaWxsaW9ucy4NCj4gPj4+Pg0KPiA+Pj4+IElkZW50aWZpZXJzIGRvIGxl YWQgdG8gdHJhY3RhYmxlIHNvbHV0aW9ucy4gQnV0LCB0aGlzIHByb3Bvc2FsDQo+ID4+Pj4gbG9v a3MgYSBiaXQgdW5mb2N1c2VkIGZvciBJUlRGIGNvbnNpZGVyYXRpb24sIGFuIElFVEYgV0c/DQo+ ID4+Pj4gUmVhbGx5Pw0KPiA+Pj4+DQo+ID4+PiBJZGVudGlmaWVycyBhcmUgZXF1aXZhbGVudCB0 byBhZGRyZXNzZXMgaW4gdGhhdCB0aGV5IGluZGljYXRlIGEgbm9kZQ0KPiA+Pj4gaW4gdGhlIG5l dHdvcmsgZm9yIHRoZSBwdXJwb3NlcyBvZiBlbmQgdG8gZW5kIGNvbW11bmljYXRpb25zLiBUaGUN Cj4gPj4+IG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGlkZW50aWZpZXJzIGFuZCBhZGRyZXNzZXMg aXMgdGhhdA0KPiA+Pj4gaWRlbnRpZmllcnMgYXJlIG5vdCB0b3BvbG9naWNhbC4gVmlydHVhbCBh ZGRyZXNzZXMgaW4gbmV0d29yaw0KPiA+Pj4gdmlydHVhbGl6YXRpb24gYXJlIGFsc28gaWRlbnRp ZmllcnMuIFNvIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIGFyZQ0KPiA+Pj4gdGhlIHNhbWUgd2hl biBjb25zaWRlcmluZyBwcml2YWN5LiBGb3IgaW5zdGFuY2UsIGlmIGFwcGxpY2F0aW9ucyB1c2UN Cj4gPj4+IHRlbXBvcmFyeSBhZGRyZXNzZXMgZm9yIHByaXZhY3ksIGl0IHdvdWxkIGhhdmUgZXF1 aXZhbGVudCBwcm9wZXJ0aWVzDQo+ID4+PiB1c2luZyB0ZW1wb3JhcnkgaWRlbnRpZmllcnMuIElu IGZhY3QgZnJvbSB0aGUgYXBwbGljYXRpb24gUE9WIHRoaXMNCj4gPj4+IHdvdWxkIGJlIHRyYW5z cGFyZW50LiBJdCBjb3VsZCBnZXQgYSBwb29sIG9mIGFwcGFyZW50bHkgcmFuZG9tDQo+ID4+PiBh ZGRyZXNzZXMgdG8gY2hvb3NlIGZyb20gYXMgc291cmNlIG9mIGNvbW11bmljYXRpb24sIGl0IHNo b3VsZG4ndA0KPiA+Pj4ga25vdyBvciBldmVuIGNhcmUgaWYgdGhlIGFkZHJlc3NlcyBhcmUgaWRl bnRpZmllcnMuDQo+ID4+Pg0KPiA+Pj4gSWRlbnRpdHkgaXMgYSBjb21wbGV0ZWx5IHNlcGFyYXRl IGNvbmNlcHQgZnJvbSBpZGVudGlmaWVycy4gSXMgbm90DQo+ID4+PiByZXF1aXJlZCBpbiBhbnkg b2YgdGhlIGlkZW50aWZpZXIvbG9jYXRvciBwcm90b2NvbHMgYW5kIEFGQUlLIG5vbmUNCj4gPj4+ IG9mIHRoZW0gZXZlbiBtZW50aW9uIHRoZSB0ZXJtLiBUaGVyZSBpcyBubyBhc3NvY2lhdGlvbiBv ZiBhbg0KPiA+Pj4gaWRlbnRpdHkgb2YgdXNlciBiZWhpbmQgYW5kIGlkZW50aWZpZXIgYW55IG1v cmUgdGhhbiB0aGVyZSBpcyBhbg0KPiA+Pj4gYXNzb2NpYXRpb24gb2YgaWRlbnRpdHkgYmVoaW5k IElQIGFkZHJlc3MuIFRoZSBmYWN0IHRoYXQgdGhlIHdvcmRzDQo+ID4+PiAiaWRlbnRpZmllciIg YW5kICJpZGVudGl0eSIgc2hhcmUgYSBjb21tb24gcHJlZml4IGlzIGFuIHVuZm9ydHVuYXRlDQo+ ID4+PiBoYXBwZW5zdGFuY2UgOi0pLg0KPiA+Pg0KPiA+Pg0KPiA+PiBZZXMuIEJ1dCBkb2Vzbid0 IHRoYXQgbWVhbiBlaXRoZXIgdGhlIG5hbWUgb2YgdGhpcyBlZmZvcnQgaXMgd2lsZGx5DQo+ID4+ IG1pc2xlYWRpbmcgb3IgZWxzZSB0aGUgZWZmb3J0IGlzIGh1Z2VseSBwcm9ibGVtYXRpYyBmcm9t IGEgcHJpdmFjeQ0KPiA+PiBQT1Y/IEVpdGhlciB3YXksIGlzdG0gdGhpcyBvdWdodCBub3QgcHJv Y2VlZC4NCj4gPj4NCj4gPj4gUy4NCj4gPj4NCj4gPj4+DQo+ID4+PiBUb20NCj4gPj4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIElkZWFzDQo+ IG1haWxpbmcgbGlzdA0KPiA+PiBJZGVhc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkZWFzDQoNCg== From nobody Wed Oct 4 15:37:48 2017 Return-Path: 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 66CDE1344D8; Wed, 4 Oct 2017 15:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 KWc71Jy_iBR0; Wed, 4 Oct 2017 15:37:46 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 D0BA4134225; Wed, 4 Oct 2017 15:37:45 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id u130so22006073oib.11; Wed, 04 Oct 2017 15:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yQMeMA3WWlYXnnQhRK1xhSogbbsfN+TG15nM1b6KE5s=; b=DfDE7tJSX42UPIvO9iAKXBUYrnksJHNb+e9H1A0rwZXlBHgMVN6rPn1tL2P8HdgVg/ aY+Wp6KgrnrQG0b15o7RqL1Csfpjq7ICUpIDSWLS6CCtg455OypYpLx2rlDUfJsbft/V K+lMiwpxJlhffzt6LmxkVl7BF7H9IDondcdpcA4dcYN0WVS9cmzLgRLmSG2gVg8KFWI+ mmvFEmB8VhO9oOeNQoWJHg3r+6+UENsDrsmXkTV4bsl6S7Pc/W78SWLFaaGp7jWuw+Eo wmHeRF5SwbSzsI3EKJQ0czeQswcVEZbhJQgBc85x6JSuMMRd1tiwcO1VRF5wyHeKXTFl yYAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yQMeMA3WWlYXnnQhRK1xhSogbbsfN+TG15nM1b6KE5s=; b=Ze7TIZUGkllHDzMTpAsX7pvEGHPzjEyK5DnQH87QY70Z7PygQZ51Kr9LOr4OrX+i8p +T+Hc4NaPh4R2AOT+HjwChsKc2f/HX7mIcretb4zcQ5bA1Ppnr7NJ2AWuTM3ab+5joew B6RAcUbR+Kpz+qC8cVXV4QxnnisvVjiWQSD4QBwmhNNzyVL0TkianxC0CLK8OMIdUX0j 7KqpK9Qh7tDMkBYEzXL3I5MjJLLsuFz+/rYk4l5Ssh6A8EglIPlkKT4XvuyJn7kfpHXV 1WIOEQfD3PrjhOJCryGI83uFw7N7KlZaK8+P3smUCCmM/0yOs5mKeIrcSPMNR48ISv22 ZFYg== X-Gm-Message-State: AMCzsaVfQBT3YvY+7JntILWeJs08hXT2uYtZyn8OpG7T2OqMWrBxXzZL 0/jvnN5/iTcQuknojNYyEFw= X-Google-Smtp-Source: AOwi7QBDFR2jOSE6ssZmZxO08IoNVOvxXm7Y924fnBgtCkFwM8MgmOxp15UFnYePVuk0Ysry5cIztg== X-Received: by 10.202.236.7 with SMTP id k7mr1231226oih.442.1507156665244; Wed, 04 Oct 2017 15:37:45 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-3-96.dsl.pltn13.sbcglobal.net. [108.94.3.96]) by smtp.gmail.com with ESMTPSA id p205sm4480898oib.33.2017.10.04.15.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 15:37:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dino Farinacci In-Reply-To: Date: Wed, 4 Oct 2017 15:37:37 -0700 Cc: lisp@ietf.org, ietf@ietf.org, Alexander Clemm , Stephen Farrell , "ideas@ietf.org" , "phill@hallambaker.com" Content-Transfer-Encoding: quoted-printable Message-Id: <5B46C69B-FF7F-406B-AB53-12AC8BF45E30@gmail.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:37:47 -0000 > I suggest that could be called idloc (for Identifier-Locator) I would suggest ms-ops as in =E2=80=9Cmapping system operation=E2=80=9D. Dino From nobody Wed Oct 4 16:38:05 2017 Return-Path: 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 8B53213336A for ; Wed, 4 Oct 2017 16:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 s0jt8cN_RonC for ; Wed, 4 Oct 2017 16:38:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB9E13337F for ; Wed, 4 Oct 2017 16:37:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX57589; Wed, 04 Oct 2017 23:37:50 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 00:37:49 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 16:37:39 -0700 From: Yingzhen Qu To: Padma Pillay-Esnault , "Joel M. Halpern" CC: "ideas@ietf.org" , Uma Chunduri Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HYgBnClqlD06yfKVGFgC1iaLMpUwAgAefuYCAABZuAIAABMSAgAAlQ4CAAA/0gIAAHDOAgAAEyQCAAAgWgIAAAH4AgAADWgD//5uYcA== Date: Wed, 4 Oct 2017 23:37:38 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810BF1732B@sjceml521-mbx.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <25B4902B1192E84696414485F572685401A871BB@SJCEML701-CHM.china.huawei.com> <501b1f3b-c646-caf5-ec82-87825ce2826b@joelhalpern.com> <25B4902B1192E84696414485F572685401A8720E@SJCEML701-CHM.china.huawei.com> <7AD02EB3-2E07-406C-94D0-D1628043C34F@gmail.com> In-Reply-To: <7AD02EB3-2E07-406C-94D0-D1628043C34F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59D570CE.004B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 23:38:04 -0000 In one version of the charter, it was mentioned that IDEAS would look at ID= y/IDf at network layer and it's a very important assumption. That somehow g= ot lost. If we're looking at identifiers at network layer, the difference between id= entifier and ip address is not that big. For sure there are security and pr= ivacy issues that need to be addressed. IMHO, if there are issues not cover= ed in current charter, and we all agree it is important, we can/should add = it to the charter.=20 Thanks, Yingzhen=20 -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Padma Pillay-Esnau= lt Sent: Wednesday, October 04, 2017 3:26 PM To: Joel M. Halpern Cc: ideas@ietf.org; Uma Chunduri Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) Hi Joel Thanks for your feedback. The charter went through several iterations. With simplification, it seems = to have lost some clarity. Padma Sent from my iPhone > On Oct 4, 2017, at 15:13, Joel M. Halpern wrote: >=20 > Yes, you have a problem statement draft. > But there is no clear statement of the problem in the charter. Which mea= ns that the working group is not bound by the current draft. > And when I ask different people about the proposed work, I get different = answers as to the purpose, scope, approach, etc. >=20 > Yorus, > joel >=20 >> On 10/4/17 6:12 PM, Uma Chunduri wrote: >> >I see different people providing different descriptions of why this = is being proposed. >> >I do not see a clear problem statement. >> Joel, >> Puzzled with your response! >> https://tools.ietf.org/html/draft-padma-ideas-problem-statement-03 >> https://datatracker.ietf.org/wg/ideas/about/ >> -- >> Uma C. >=20 > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Wed Oct 4 16:39:24 2017 Return-Path: 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 A1F2613320B for ; Wed, 4 Oct 2017 16:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 w-_-TfjPAy46 for ; Wed, 4 Oct 2017 16:39:22 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 CD7B313219F for ; Wed, 4 Oct 2017 16:39:21 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id k1so11416267qti.2 for ; Wed, 04 Oct 2017 16:39:21 -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; bh=qFmdFVPFp8aA6+gdpVW0/LZIrGzTxbc42yo/5tzyaUg=; b=VUy64qXi0N/8cu74vl9wL4LRijKqbkEa1c/PbL3ie/VOtrFnMfeE7gepefFEpHH47j N46FMiy4x0K8EOBHsafL7fpprOrh5+79Nlw08YjTMAwcOC6Imt0nyDxt1EJBjrUhvtvi YVN17oXjpfKgNJY+WUzSrfHb+tdbYz3o04LhcQADeDpIuJ3hyp0jjYIGyoWfW8ihVXD8 RwQL/0WgYwpqEQl+aKfteUvFPJESr28nXq90EdIBOqvOcLx/TbffBjD8BMj2zAJNeTSG ccjCCuAOchcC7OJ7XdXHG8IXIYxEYRe7SSKNect+8ckmiCrrpz36kMPdSTzkJ8ymDUCV ZgwQ== 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; bh=qFmdFVPFp8aA6+gdpVW0/LZIrGzTxbc42yo/5tzyaUg=; b=WlCGNLFguyNpJYyTnz952hRV1wP/oPGkGSRiPEkOsKQkCpcd0pixOFt5qajRCi/ihU fYCkuE/bl6EeLVC7o91qt7TW6VYmsDVrFxm3an347aVSx0zrBClQ2/uxe2oM0jmbWcPA THKZ/1Nkpg759E47cLG5i4jmgHba7It1Y8jWW1sfGh5EP5PpxR6Jp8nR+R01/YBqVog9 pELOhn7Lvx5QHfpvsr9tPKvqv1+sn3rxEnYBWd5Iju82m2hMOHr3MvYdOo6mjGq58VRl tBg5tMyuiRllB6uNZAYfCxCdCviumYVBuJjki89tUS4JYyeXFIoNrohHo4kCFnMfhVqL Q5KQ== X-Gm-Message-State: AMCzsaVZZnPuHAjQo31K14Tyw+LawKZWpV0rKJfybI7i9kDI+AlQYkcx ROJAcX5vJsWksJCnIhqOcopg1xzR8l1FZgzeTYlSVg== X-Google-Smtp-Source: AOwi7QALp7ZPoxQva64xbyKSV048ii5gHaxd4xyjYNjkJDjNDyDfi2PYNe4qbwerTcVNQCSimCZctC+6DQDxR0Mv/A0= X-Received: by 10.200.43.140 with SMTP id m12mr31277192qtm.58.1507160360752; Wed, 04 Oct 2017 16:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.235 with HTTP; Wed, 4 Oct 2017 16:39:19 -0700 (PDT) In-Reply-To: <150716015159.6677.15220602314994896246.idtracker@ietfa.amsl.com> References: <150716015159.6677.15220602314994896246.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 4 Oct 2017 16:39:19 -0700 Message-ID: To: ideas@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 23:39:24 -0000 Hello, I've posted a draft to develop a software daemon that could control various mapping systems and identifier/locator protocols. I hope to have same code to make public in near future. Tom ---------- Forwarded message ---------- From: Date: Wed, Oct 4, 2017 at 4:35 PM Subject: New Version Notification for draft-herbert-idlocd-00.txt To: Tom Herbert A new version of I-D, draft-herbert-idlocd-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-idlocd Revision: 00 Title: Identifier-locator control daemon Document date: 2017-10-04 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-herbert-idlocd-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-idlocd/ Htmlized: https://tools.ietf.org/html/draft-herbert-idlocd-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-idlocd-00 Abstract: Identifier-locator protocols rely on a mapping system that is able to map identifiers to locators. Such a mapping system is a type of key/value store. This draft proposes a design and implementation for an Identifier-Locator control daemon (idlocd). The intent is to provide an open source implementation that would be a basis for experimentation, development, and eventual deployment of identifier- locator solutions at large scale. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Oct 4 17:46:51 2017 Return-Path: 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 3D9C8133188; Wed, 4 Oct 2017 17:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DTpNCjOJcAhQ; Wed, 4 Oct 2017 17:46:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CF81344C9; Wed, 4 Oct 2017 17:46:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW22098; Thu, 05 Oct 2017 00:46:28 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 01:46:27 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 17:46:22 -0700 From: Uma Chunduri To: Jari Arkko , "Eggert, Lars" CC: "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRA= Date: Thu, 5 Oct 2017 00:46:21 +0000 Message-ID: <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> In-Reply-To: <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59D580E4.00C1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 00:46:49 -0000 SmFyaSwNCg0KCT4gU2Vjb25kbHksIEnigJltIGhhdmUgc2ltaWxhciBjb25jZXJucyB0byBDaHJp c3RpYW4sIExhcnMsIFN0ZXBoZW4gYW5kIG90aGVycy4NCgk+IE1vcmUgc3BlY2lmaWNhbGx5LCBh dCB0aGUgQk9GIHRoZSBnb2FsIHNlZW1lZCB0byBiZSBjcmVhdGlvbiBvZiBpbmZyYXN0cnVjdHVy ZXMgdG8gbWFuYWdlIGFuZCB0cmFjayBpZGVudGl0aWVzLCBhbmQgdG8gYmluZCB0aGVtIHRvIGVu dGl0aWVzIHRoYXQgYXNzaWduZWQgdGhlbS4gDQogICAgICAgICAgICAgICAgPiBJIGFtIG5vdCBh dCBhbGwgc3VyZSB0aGF04oCZcyBhIGRlc2lyYWJsZSBkaXJlY3Rpb24uIEFuZCB0aGUgY2hhcnRl ciBzYXlzIGxpdHRsZSBhYm91dCB0aGUgYXNzdW1wdGlvbnMgYmVoaW5kIHRoZSB3b3JrLg0KCT5U byBleHBhbmQgYSBiaXQgb24gdGhlc2UgY29uY2VybnMsIHRoZSBwcm9wb3NlZCB3b3JrIGRvZXNu 4oCZdCBjb25zaWRlciBhdCBhbGwgdGhlIHR5cGVzIG9mIGlkZW50aWZpZXIgb3BlcmF0aW9ucyB0 aGF0IHdvcmsgb24gZXBoZW1lcmFsIGlkZW50aXRpZXMgKGUuZy4sIEhJUCwgTVAtVENQKS4gDQog ICAgICAgICAgICAgICAgPkl0IHdvdWxkIGJlIHNhZCBpZiB3ZSBjcmVhdGVkIHN5c3RlbXMgdGhh dCBmb3JjZWQgdXMgdG8gbWFuYWdlIGlkZW50aWZpZXJzIGZyb20gc29tZSBpbmZyYXN0cnVjdHVy ZSB3aGVuIGFsbCB3ZSBuZWVkZWQgdG8gZG8gaW4gYSBwYXJ0aWN1bGFyIGNhc2Ugd2FzIOKAnHBy b3ZlIHRoYXQgeW91IGFyZSANCiAgICAgICAgICAgICAgICA+dGhlIHNhbWUgZW50aXR5IGFzIGlu IHRoZSBvdGhlciBjb25uZWN0aW9u4oCdLCB3aGljaCBjYW4gYmUgZG9uZSBlMmUgYW5kIHJlcXVp cmVzIG5vIGluZnJhc3RydWN0dXJlLCBvciBwZXJtYW5lbnQgaWRlbnRpZmllcnMuDQoNCg0KSSBo b3BlIHlvdSBhZ3JlZSwgd2hlbiB3ZSB0YWxrIGFib3V0IGEgbWFwcGluZyBzeXN0ZW0gLSBpdCdz IGltcG9ydGFudCANCg0KICAgICAtIFdobyBjYW4gdXBkYXRlIHRoZSBtYXBwaW5ncyANCiAgICAg LSBXaG8gY2FuIGFjY2VzcyB0aGUgbWFwcGluZ3MgDQoNCkJvdGggbmVlZHMgQVVUSCBhbmQgaGVu Y2UgYW4gSWRlbnRpdHkgKEVBUCBvciB3aGF0ZXZlciBtZWNoYW5pc20gd2l0aCBhbm9ueW1vdXMg b3IgcHNldWRvbnltb3VzIGFjY2VzcykgJiBwcm92aWRlciA9PT4gZXNzZW50aWFsbHkgYW4gYWNj ZXNzIElELg0KSWYgeW91IGRvbid0IHJlc3RyaWN0IHdobyBjYW4gYWNjZXNzIHRoZSBtYXBwaW5n ICgybmQgcXVlc3Rpb24pIG9uZSB3b3VsZCBnZXQgYSBwcmltaXRpdmUgc3lzdGVtLCBidXQgdGhl IGFiaWxpdHkgdG8gcHJvdmlkZSBzb21lIGNvbnRyb2wgaXMgdXNlZnVsIGZvciBsb3Qgb2Ygc2Nl bmFyaW9zIChpbmNsdWRpbmcgbG90IG9mIElvVC9WZWhpY3VsYXIgbm9kZXMgaGF2aW5nIG1vYmls aXR5IGFuZCBtdWx0aS1hY2Nlc3MpLiANCkluIGFueSBjYXNlLCB5b3Ugc2hvdWxkIHN0aWxsIHJl c3RyaWN0IHdobyBjYW4gdXBkYXRlIHdob3NlIG1hcHBpbmdzLg0KDQpZb3UgbmVlZCB0aGlzICJz dGFuZGFyZGl6ZWQiIHN5c3RlbSB3aXRoIHdlbGwtZGVmaW5lZCBpbnRlcmZhY2VzICBmb3INCiAg IGEuICBsb3Qgb2YgbG9jYWwgSW9UL2VudGVycHJpc2UgZGVwbG95bWVudHMgYW5kIA0KICAgYi4g IGNhbiBiZSAgZXh0ZW5kZWQgdGhyb3VnaCBhIGZlZGVyYXRlZCBzeXN0ZW0gd2hlcmUgb25seSBt YXBwaW5nIG9mIElkZW50aWZpZXJzIGFuZCBsb2NhdGlvbnMgY2FuIGJlIHNoYXJlZCBhbW9uZyBw cm92aWRlcnMgZm9yIGZ1cnRoZXIgcmVhY2hhYmlsaXR5IChjZW50cmFsIHRvIGFueSBtb2JpbGl0 eSBzeXN0ZW0sIHJlZ2FyZGxlc3Mgb2Ygd2hpY2ggSUQvTE9DIHByb3RvY29sKS4NCg0KV2l0aCBy ZWdhcmQgdG8gcHJpdmFjeSBjb25jZXJucyByYWlzZWQsIEkgc3RpbGwgYmVsaWV2ZSB0aGVyZSBh cmUgSUVURiBhcHByb3ZlZCBzb2x1dGlvbnMgbGlrZSBodHRwczovL3Rvb2xzLmlldGYub3JnL3dn L2FiZmFiLyBjYW4gYmUgbGV2ZXJhZ2VkIGhlcmUgdG9vLg0KDQpXaGF0IGRhdGEgcGxhbmUgaWRl bnRpZmllciBpcyBhbm90aGVyIGFzcGVjdCBhbmQgdGhhdCBpcyBnb3Zlcm5lZCBieSBJRC9MT0Mg cHJvdG9jb2xzLg0KDQotLQ0KVW1hIEMuDQoNCg== From nobody Wed Oct 4 18:35:50 2017 Return-Path: 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 806A713450B; Wed, 4 Oct 2017 18:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 zobINrUkZp3k; Wed, 4 Oct 2017 18:35:43 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EC813450A; Wed, 4 Oct 2017 18:35:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id EF46846DC89; Wed, 4 Oct 2017 18:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1507167342; bh=jdWyGcHuI3EbjUIywg90106ex37PzrNpsHQXTrInFR8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TnsePNd+F3AtESpgqTO60GO6Gn8SPq2D0F+xY/Schzqx49tlRTgwI6z2uXhC/BurM VsTMXyxBj0MiTej5muuoVi89IwObfXZGbYWKU8An+UBW7t11a4bZ2LxoCzdvX6+GAD u+WLLcslyTD87/SjgPU7z5gmGChG2laJEqmQPeuo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6D8EC46DC44; Wed, 4 Oct 2017 18:35:40 -0700 (PDT) To: Uma Chunduri , Jari Arkko , "Eggert, Lars" Cc: "ideas@ietf.org" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> From: "Joel M. Halpern" Message-ID: <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> Date: Wed, 4 Oct 2017 21:35:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 01:35:44 -0000 Uma, It simply does not follow that you need an identity in order to be able to update the mapping system. You do need authentication. If you use DNS, then mechanissm such as the authentication used with dynamic DNS suffice. If you use LISP, then the keying associated with the delegation of the identifier works. If you use MobileIP, then you need the authentication with your home register. There is no need for any special Identity. Yours, Joel On 10/4/17 8:46 PM, Uma Chunduri wrote: > Jari, > > > Secondly, I’m have similar concerns to Christian, Lars, Stephen and others. > > More specifically, at the BOF the goal seemed to be creation of infrastructures to manage and track identities, and to bind them to entities that assigned them. > > I am not at all sure that’s a desirable direction. And the charter says little about the assumptions behind the work. > >To expand a bit on these concerns, the proposed work doesn’t consider at all the types of identifier operations that work on ephemeral identities (e.g., HIP, MP-TCP). > >It would be sad if we created systems that forced us to manage identifiers from some infrastructure when all we needed to do in a particular case was “prove that you are > >the same entity as in the other connection”, which can be done e2e and requires no infrastructure, or permanent identifiers. > > > I hope you agree, when we talk about a mapping system - it's important > > - Who can update the mappings > - Who can access the mappings > > Both needs AUTH and hence an Identity (EAP or whatever mechanism with anonymous or pseudonymous access) & provider ==> essentially an access ID. > If you don't restrict who can access the mapping (2nd question) one would get a primitive system, but the ability to provide some control is useful for lot of scenarios (including lot of IoT/Vehicular nodes having mobility and multi-access). > In any case, you should still restrict who can update whose mappings. > > You need this "standardized" system with well-defined interfaces for > a. lot of local IoT/enterprise deployments and > b. can be extended through a federated system where only mapping of Identifiers and locations can be shared among providers for further reachability (central to any mobility system, regardless of which ID/LOC protocol). > > With regard to privacy concerns raised, I still believe there are IETF approved solutions like https://tools.ietf.org/wg/abfab/ can be leveraged here too. > > What data plane identifier is another aspect and that is governed by ID/LOC protocols. > > -- > Uma C. > From nobody Wed Oct 4 18:37:42 2017 Return-Path: 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 7CD4C134510; Wed, 4 Oct 2017 18:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MjbWaAYenBlP; Wed, 4 Oct 2017 18:37:38 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DF213450E; Wed, 4 Oct 2017 18:37:36 -0700 (PDT) X-AuditID: 12074423-80fff70000005865-1e-59d58cdf2bd7 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AD.AC.22629.FDC85D95; Wed, 4 Oct 2017 21:37:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v951bYIt021147; Wed, 4 Oct 2017 21:37:35 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v951bU7E030445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Oct 2017 21:37:33 -0400 Date: Wed, 4 Oct 2017 20:37:30 -0500 From: Benjamin Kaduk To: "Joel M. Halpern" Cc: Uma Chunduri , "ideas@ietf.org" , "ietf@ietf.org" Message-ID: <20171005013730.GC96685@kduck.kaduk.org> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT173fczXSYM9Ra4tDR/cyWzzbOJ/F 4uOpN0wWO+5cZXNg8Wg58pbVY8mSn0we56Z8ZwxgjuKySUnNySxLLdK3S+DK+HVpFlPBQraK 7z9WMTcwPmDpYuTgkBAwkWj/a9fFyMUhJLCYSWLXshNsEM4GRol1j4+wQDhXmCReTW5m7WLk 5GARUJE4f+EHC4jNBmQ3dF9mBrFFBLQl9i/5wARiMwuUS2y/P5MNZIOwgKNE+4IgkDAv0LIN MyZAzXzDJPG75S0TREJQ4uTMJywQvVoSN/69ZALpZRaQllj+jwMkzCngLLF/82uwElEBZYl5 +1axTWAUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmunlZpbopaaUbmIE h7CL8g7Gl33ehxgFOBiVeHgjHl2JFGJNLCuuzD3EKMnBpCTKu6v7aqQQX1J+SmVGYnFGfFFp TmrxIUYJDmYlEd71OUA53pTEyqrUonyYlDQHi5I477agXZFCAumJJanZqakFqUUwWRkODiUJ XmtgrAoJFqWmp1akZeaUIKSZODhBhvMADVcBqeEtLkjMLc5Mh8ifYtTluPHw+h8mIZa8/LxU KXHe5SDXCYAUZZTmwc0BpR6J7P01rxjFgd4S5p0JUsUDTFtwk14BLWECWjKn6QrIkpJEhJRU A2NsRdu7+96bf4XaXjOZ1dJ20K/v5W/LnmVxM39Z8XxLsxFybJULETq0+pO+CkOX+ro9oiHW Va8sZhw0lN90ydPwisZiduPITTF8Z7bJPUpdfXKn9vZa3lk5uspb1p9LMlmpkBWy38vm/+tb K9kONf7qKpu8quHPhwNlV1edCT3l2uSQKVq5Rk+JpTgj0VCLuag4EQCYSOZsGAMAAA== Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 01:37:39 -0000 On Wed, Oct 04, 2017 at 09:35:38PM -0400, Joel M. Halpern wrote: > Uma, > It simply does not follow that you need an identity in order to be > able to update the mapping system. You do need authentication. > If you use DNS, then mechanissm such as the authentication used > with dynamic DNS suffice. > If you use LISP, then the keying associated with the delegation of > the identifier works. > If you use MobileIP, then you need the authentication with your > home register. > > There is no need for any special Identity. My reading of the claim was that authentication is needed in order to change the actual map itself, which does seem like a true statement, in general. Authentication is not necessarily needed just to consume the map. -Ben From nobody Wed Oct 4 18:41:42 2017 Return-Path: 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 9078F13450B; Wed, 4 Oct 2017 18:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 uNvuTgp_DNOh; Wed, 4 Oct 2017 18:41:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3627133071; Wed, 4 Oct 2017 18:40:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DE74846DC89; Wed, 4 Oct 2017 18:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1507167657; bh=PnWUxg7gUSRZeoK0HuoihMezRJs3RAJ+jFYwSBdrUmk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nWnHWTla3kFusWPIWY2vevPFyMf38H/8BOTJimo59K/mNd3Q2MF94g5OfT6WLLl+s vacPmQOW3FAEzBi3h2Obm3oMWaLXDm29f7lGBSwB2p6LlblEi9H2bEt+qah/2kxuXk nYfiAnOjbebb2sdzALv82MZR7ze5iiCsQMoze800= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1049A467F1B; Wed, 4 Oct 2017 18:40:56 -0700 (PDT) To: Benjamin Kaduk Cc: Uma Chunduri , "ideas@ietf.org" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> From: Joel Halpern Direct Message-ID: <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> Date: Wed, 4 Oct 2017 21:40:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171005013730.GC96685@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 01:41:34 -0000 Yes, authentication is necessary to modify the entries. (Whether one should be authenticated before reading varies from case to case.) But authentication does not require a separate identity. Exactly what it requires depends upon how the system is constructed. Uma was arguing that they need an identity. I am arguing that such a thing is counter-productive. Yours, Joel On 10/4/17 9:37 PM, Benjamin Kaduk wrote: > On Wed, Oct 04, 2017 at 09:35:38PM -0400, Joel M. Halpern wrote: >> Uma, >> It simply does not follow that you need an identity in order to be >> able to update the mapping system. You do need authentication. >> If you use DNS, then mechanissm such as the authentication used >> with dynamic DNS suffice. >> If you use LISP, then the keying associated with the delegation of >> the identifier works. >> If you use MobileIP, then you need the authentication with your >> home register. >> >> There is no need for any special Identity. > > My reading of the claim was that authentication is needed in order to > change the actual map itself, which does seem like a true statement, > in general. Authentication is not necessarily needed just to consume > the map. > > -Ben > From nobody Wed Oct 4 18:51:21 2017 Return-Path: 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 94132133071 for ; Wed, 4 Oct 2017 18:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 mVNLEpX_tg57 for ; Wed, 4 Oct 2017 18:50:33 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C4613450B for ; Wed, 4 Oct 2017 18:50:33 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-09v.sys.comcast.net with ESMTP id zvIXdDLBjDIu7zvJ3dSx3S; Thu, 05 Oct 2017 01:50:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1507168233; bh=YHOYS9jBcTwbakNvp6mX4gVlVr1ps+fbQsvBV1nTF/c=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=C7ccIDKO2qPNemjSlxsKhJ5udzUGV9BDBqTWp4eTWwNnHQFbvxWDmh4oUdnR/6dNL cgZGfabEF/TMFzn0Nt5J+RE6inzp9u2VUjEHWvHGMgfEc10BPzxixKb8/6I76xbdfy 3u6FTpxHCl5woP7fC2qTKXjWOfXitrZpUGdmrAGBbkhT5gKzlnLAXb0/nYZIKF4JRZ vE0GO0WL6Sqjn6VVWu4V5h/lLQK/28syMlZiC+kgU6LZ6NbEPUqrdG3c32DMP4CmlL ybbXeX/OPKyqhGn7jWpdLdfd79SynhO0FLJO++aTkXrtt/+xgHmGzfM98pZPAp2aQN X+XK2t/65McjA== Received: from [IPv6:2601:152:4400:b75f::1005] ([IPv6:2601:152:4400:b75f::1005]) by resomta-po-03v.sys.comcast.net with SMTP id zvIzdXHscrmiEzvJ0dWhy2; Thu, 05 Oct 2017 01:50:31 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Mike StJohns X-Mailer: iPad Mail (14G60) In-Reply-To: <94E38EAAADE89B4B40A79530@PSB> Date: Wed, 4 Oct 2017 21:50:29 -0400 Cc: ietf@ietf.org, ideas@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <94E38EAAADE89B4B40A79530@PSB> To: John C Klensin X-CMAE-Envelope: MS4wfBphnr5wtRyflX8BoSvadpry+Vz6D/TYXKDDcYL6Icg6rYaneN9N58nM9hpfzysQFc5QLf8vNJqvDubodnJiDm0VojbIKZae6KkoCCNzi0y3XQE93cAy WiLQStXQTRR/KoBpz3T9Vwydi3YzxAfJZE5NZHVq0xpQOPSrgzlJWu46lcClhRPejNDizoVrgtwsnn3FR0jF8Toneq8SG7i588Aou8DHYbx9g33hxZ7uUcJ9 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 01:50:36 -0000 FYI. IDEAS as an IETF acronym has been taken since about 1989 or so. It st= ood for Internet Design Engineering and Analysis Series which was a fairly s= hort lived document series that preceded the Internet Drafts process. This l= ed to at least one internet routing company noting in its collateral that it= implemented IDEA 9. =20 Mike FWIW. I agree with John about the obnoxiousness of "ideas@ietf.org" as a mai= ling list name. =20 Sent from my iPad > On Oct 4, 2017, at 12:57, John C Klensin wrote: >=20 > However, I strongly urge that, if the charter is accepted in > principle, you move away from from acronyms that are likely to > create far more confusion than the desire for demonstrating > cleverness or cuteness can possibly be worth. "ideas" itself is > an example. It may be an an acronym that was cleverly matched > to the WG name (or vice versa) but it is also a word that > implies an entirely different meaning, one that is fairly > misleading relative to the intended WG's topic and more suited, > if it is suitable at all for a WG name, for something exploring > or brainstorming a much broader range of topics. An > "ideas@ietf.org" mailing list is particularly obnoxious in that > regard. From nobody Wed Oct 4 19:25:43 2017 Return-Path: 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 156FF13450D; Wed, 4 Oct 2017 19:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 P6-8_5UGgjco; Wed, 4 Oct 2017 19:25:34 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 932E513450B; Wed, 4 Oct 2017 19:25:34 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id u130so22592754oib.11; Wed, 04 Oct 2017 19:25:34 -0700 (PDT) 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=1BTVwC+0awDKFH7VmF42ttdRvgITvWP1XFBsK4yY+Hc=; b=iAEPTF12KxGoMu/ZH0biG79jHBA3tvUOc/CnoRGKdfx26ZdAe5383OKD9zuvEG4uzq j3qAU9IkkBhmadPL1+TUdpbp885Mze3VCSQdTmqEKTNiTYNrGdp3gspOPR5w0OGSjHAw +uy+i8jB7zKSCfNUsnjqgwNWsuLFUVIVIzfg3kUrzqHkCu2uBezOo9QGnd7FhqjngSvf XAWVWYxzdQ/GuoMMlSe16SOxwHEO0ggIijcvEj57Y/trvPujv/v26azUzitlkFdcJfAB 1P6KTJy3bluwk8W24OVb84rLQjkYZxR9zBv73TRP/0Z8at8QHfveMLdFBzeLbikuqZTT XOzQ== 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=1BTVwC+0awDKFH7VmF42ttdRvgITvWP1XFBsK4yY+Hc=; b=XF6pYIPye5E6J8PiPRfocJKCp2jY1leUjq/6DH8LzahDe1l0DIx7qSYBVOThBT+zsM YnVcozbkTaxrR0MzYKBuNU7JluuR6Fwz8oJxrnFOyL+6zlsu+wT9TC9zFE4ekF8LpCLC 0bB/YWEzlAuO9Zqo6BPL8JOtOf2WVED3f/2uL3YI3zKCp7Rhu3QZBB/jGado3V8yLrGS lRa9hCL8zyvreXrwqf8MSQCfmH6Ge4vAjPtPDEAvGSj57bvHCOWfWfjZcOUDgYBqXZ4s baLYlMD207P689kzo0UxHfyClk07bTODQwJt97PeD+FT1ORcwrVwV+e/VN2/47ZImmKZ tqBw== X-Gm-Message-State: AMCzsaUPpHiS68ZBcn+CfrTCNUcNEidr6D4R0D7mJkThfQIvhNzdTmC4 jHU9H41cpsqswrCUXRxQNwkca4x5LV5c+nYLk78= X-Google-Smtp-Source: AOwi7QChd4WNd1KmcdmfAH255zWPrnnOVcOzra1UGIZHGCV9JK9ZZQq0JXkE7U2atfvClqqQhJH6tS0rySqpdq5fbV0= X-Received: by 10.202.104.22 with SMTP id d22mr8986849oic.68.1507170334000; Wed, 04 Oct 2017 19:25:34 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Wed, 4 Oct 2017 19:25:33 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <94E38EAAADE89B4B40A79530@PSB> From: Phillip Hallam-Baker Date: Wed, 4 Oct 2017 22:25:33 -0400 X-Google-Sender-Auth: tvz9eyTrA2CxH1Fy_tcV3tNl2NA Message-ID: To: Mike StJohns Cc: John C Klensin , ideas@ietf.org, IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="001a1140f7b85fcdce055ac37062" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 02:25:36 -0000 --001a1140f7b85fcdce055ac37062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 9:50 PM, Mike StJohns wrote: > > FYI. IDEAS as an IETF acronym has been taken since about 1989 or so. It stood for Internet Design Engineering and Analysis Series which was a fairly short lived document series that preceded the Internet Drafts process. This led to at least one internet routing company noting in its collateral that it implemented IDEA 9. > > Mike > > FWIW. I agree with John about the obnoxiousness of "ideas@ietf.org" as a mailing list name. IDEA =E2=80=8B is also the name of the cipher originally used in PGP which might= not be an issue only I seem to recall it was broken with a meet in the middle attack so it is probably tainted. --001a1140f7b85fcdce055ac37062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 4, 2017 at 9:50 PM, Mike StJohns <<= a href=3D"mailto:mstjohns@comcast.net">mstjohns@comcast.net> wrote:<= br>>
> FYI.=C2=A0 IDEAS as an IETF acronym has been taken since ab= out 1989 or so.=C2=A0 It stood for Internet Design Engineering and Analysis= Series which was a fairly short lived document series that preceded the In= ternet Drafts process.=C2=A0 This led to at least one internet routing comp= any noting in its collateral that it implemented IDEA 9.
>
> Mi= ke
>
> FWIW. I agree with John about the obnoxiousness of "= ;ideas@ietf.org" as a mailing li= st name.


IDEA
=E2=80=8B is also the name of the cipher originally used= in PGP which might not be an issue only I seem to recall it was broken wit= h a meet in the middle attack so it is probably tainted.
--001a1140f7b85fcdce055ac37062-- From nobody Wed Oct 4 20:07:44 2017 Return-Path: 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 4F468134520; Wed, 4 Oct 2017 20:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LlYsy16EM4TG; Wed, 4 Oct 2017 20:07:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DCA13451F; Wed, 4 Oct 2017 20:07:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX75364; Thu, 05 Oct 2017 03:07:33 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 04:07:31 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 20:07:26 -0700 From: Uma Chunduri To: "Joel M. Halpern" , Jari Arkko , "Eggert, Lars" CC: "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRCAAI/FAP//oapQ Date: Thu, 5 Oct 2017 03:07:25 +0000 Message-ID: <25B4902B1192E84696414485F572685401A8736F@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> In-Reply-To: <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59D5A1F5.00B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 03:07:37 -0000 SGkgSm9lbCwNCg0KCSAgICA+IEl0IHNpbXBseSBkb2VzIG5vdCBmb2xsb3cgdGhhdCB5b3UgbmVl ZCBhbiBpZGVudGl0eSBpbiBvcmRlciB0byBiZSBhYmxlIHRvIHVwZGF0ZSB0aGUgbWFwcGluZyBz eXN0ZW0uICBZb3UgZG8gbmVlZCBhdXRoZW50aWNhdGlvbi4NCg0KSW5kZWVkLCB0aHguDQogIAkJ DQogIAkgPi4uLi4NCiAgCSAgPlRoZXJlIGlzIG5vIG5lZWQgZm9yIGFueSBzcGVjaWFsIElkZW50 aXR5Lg0KDQpJZiB3ZSBjaG9vc2UsICBhdXRoLiBtZXRob2QgaXMgYXMgcHJpbWl0aXZlIGFzIHVz aW5nIHBhc3N3b3JkcyBlbHNlIHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgbm90IFRydWUuDQoNCi0t DQpVbWEgQy4NCg0K From nobody Wed Oct 4 20:09:22 2017 Return-Path: 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 7A3DB13451F; Wed, 4 Oct 2017 20:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 P2xrCt4hnhMi; Wed, 4 Oct 2017 20:09:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D5813451E; Wed, 4 Oct 2017 20:09:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW35237; Thu, 05 Oct 2017 03:09:15 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 04:09:14 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 20:09:12 -0700 From: Uma Chunduri To: Benjamin Kaduk , "Joel M. Halpern" CC: "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRCAAI/FAIAAAIUA//+iB0A= Date: Thu, 5 Oct 2017 03:09:10 +0000 Message-ID: <25B4902B1192E84696414485F572685401A87383@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> In-Reply-To: <20171005013730.GC96685@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.59D5A25C.0077, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 03:09:20 -0000 Hi Ben, In-line [Uma]: -- Uma C. -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Wednesday, October 04, 2017 6:38 PM To: Joel M. Halpern Cc: ideas@ietf.org; ietf@ietf.org; Uma Chunduri Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) > There is no need for any special Identity. My reading of the claim was that authentication is needed in order to chang= e the actual map itself, which does seem like a true statement, in general.= =20 [Uma]: Yes. AUTH is also needed to update on who all can access that infor= mation. One possibility is It's based on type of the device.=20 Authentication is not necessarily needed just to consume the map. [Uma]: But what is envisioned here is to restrict this consumption based o= n access policy set forth based on type of the device. IoT device type X ca= n only access the mapping of say Y. This needs AUTH for who is asking the m= apping too..=20 -Ben _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Wed Oct 4 20:24:29 2017 Return-Path: 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 565FF134525; Wed, 4 Oct 2017 20:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 e8TG1TEbbQH2; Wed, 4 Oct 2017 20:24:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDFE134521; Wed, 4 Oct 2017 20:24:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW36649; Thu, 05 Oct 2017 03:24:23 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 04:24:22 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 20:24:19 -0700 From: Uma Chunduri To: Joel Halpern Direct , Benjamin Kaduk , Jari Arkko CC: "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRCAAI/FAIAAAIUAgAAA9AD//6NuoA== Date: Thu, 5 Oct 2017 03:24:18 +0000 Message-ID: <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> In-Reply-To: <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0203.59D5A5E7.00E8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 03:24:27 -0000 SGkgSm9lbCwNCg0KDQoJPlllcywgYXV0aGVudGljYXRpb24gaXMgbmVjZXNzYXJ5IHRvIG1vZGlm eSB0aGUgZW50cmllcy4gIChXaGV0aGVyIG9uZSBzaG91bGQgYmUgYXV0aGVudGljYXRlZCBiZWZv cmUgcmVhZGluZyB2YXJpZXMgZnJvbSBjYXNlIHRvIGNhc2UuKQ0KCT5CdXQgYXV0aGVudGljYXRp b24gZG9lcyBub3QgcmVxdWlyZSBhIHNlcGFyYXRlIGlkZW50aXR5LiAgRXhhY3RseSB3aGF0IGl0 IHJlcXVpcmVzIGRlcGVuZHMgdXBvbiBob3cgdGhlIHN5c3RlbSBpcyBjb25zdHJ1Y3RlZC4NCg0K SU1ITywgcHJvdmlkZXIgYmFzZWQgQVVUSCBpcyBuZWVkZWQgaW4gbG90IG9mIGNhc2VzIGlmIHdl IHJlYWxseSB3YW50IHRvIGJ1aWxkIGEgc29saWQgc3lzdGVtIHdoaWNoIGVuYWJsZXMgbW9iaWxp dHkuDQpJIHJlc3BvbmRlZCB0byBKYXJpLCB3aG8gaXMgYSBwaW9uZWVyIGFuZCB3aG8gaGVscGVk IHNwZWMgb3V0IG9uZSBvZiB0aGUgYmVzdCBBVVRIIG1ldGhvZHMgICYgc3lzdGVtcyBzdWNjZXNz ZnVsbHkgZGVwbG95ZWQgZXZlciB3aXRoIGhpcyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNDE4NyANCihidXQgaGUgZGlkIGl0IGZvciBhbm90aGVyIG1vc3Qgc3VjY2Vzc2Z1bCBTRE8s IHdpdGggYWxsIGNvbnN0cnVjdHMgbGlrZSBQc2V1ZG9ueW1zIGFuZCBmYXN0LXJlLWF1dGgtaWRz KSBkaWRuJ3Qgc2VlIHRoZSBuZWVkIGZvciB0aGUgc2FtZSBoZXJlLg0KTWF5IGJlIGFzIHlvdSBp bmRpY2F0ZWQgdGhlcmUgaXMgc29tZXRoaW5nIG1pc3NpbmcgaW4gdGhlIGNoYXJ0ZXIgdGhhdCBk aWRuJ3QgcmVmbGVjdCB0aGUgbmVlZC4gDQoNCi0tDQpVbWEgQy4NCg== From nobody Wed Oct 4 21:40:49 2017 Return-Path: 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 447291321DE; Wed, 4 Oct 2017 21:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 eK78wVRIlVG8; Wed, 4 Oct 2017 21:40:41 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5D11321A0; Wed, 4 Oct 2017 21:40:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7D97446DC89; Wed, 4 Oct 2017 21:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1507178441; bh=mEKNVSyD99hdO8hzz/+1RSMZSaTDG7k8csLGW5FPwEg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TnvT1e/3foGjKvQmIDgrjAnYUKs7YXv4/orWkyAsgk+ENyXkXj/NFKl6UJ+py2tbG k0swm7AmRZgZ2JHKcXEKhw26ogyN9o2IbohZa45AJ+FxjZFp2jiReLPqFOpO4+7Vbh Qw/2EYUE1UYNCfAXfJhsuRliQHXvBaOq9X0DYuso= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B7648467F1B; Wed, 4 Oct 2017 21:40:39 -0700 (PDT) To: Uma Chunduri , Benjamin Kaduk , Jari Arkko Cc: "ideas@ietf.org" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 5 Oct 2017 00:40:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 04:40:43 -0000 You seem to be making some unstated assumptions. If by "Provider" in "Provider based AUTH" you mean the last hop communications service provider, then I would fundamentally disagree with you. The communication service provider has no role in creating or authenticating identifiers. Their job is to provide locators. Now, those service providers may have an authentication relationship, based on some identifiers, in order to provide communications services. But the identifiers for that are completely uncoupled from and unrealted to the identifiers need for an ID / Locator system. Yes, if there is a provider of identifiers (not all systems even require that), then the user of the identifier needs to have an appropriate relationship with the provider of the identifier. And that needs to be related to the authentication needed to update the mapping system. But neither of those require anything other than the identifier and suitable keying. I gave several examples of this in earlier emails to the list. Yours, Joel On 10/4/17 11:24 PM, Uma Chunduri wrote: > Hi Joel, > > > >Yes, authentication is necessary to modify the entries. (Whether one should be authenticated before reading varies from case to case.) > >But authentication does not require a separate identity. Exactly what it requires depends upon how the system is constructed. > > IMHO, provider based AUTH is needed in lot of cases if we really want to build a solid system which enables mobility. > I responded to Jari, who is a pioneer and who helped spec out one of the best AUTH methods & systems successfully deployed ever with his https://tools.ietf.org/html/rfc4187 > (but he did it for another most successful SDO, with all constructs like Pseudonyms and fast-re-auth-ids) didn't see the need for the same here. > May be as you indicated there is something missing in the charter that didn't reflect the need. > > -- > Uma C. > From nobody Wed Oct 4 23:58:53 2017 Return-Path: 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 25B5913454D; Wed, 4 Oct 2017 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Vh07oSpyXT8a; Wed, 4 Oct 2017 23:58:49 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 54876134220; Wed, 4 Oct 2017 23:57:50 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id p46so7678640wrb.0; Wed, 04 Oct 2017 23:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H53I9YjUoFVCaIUoyVLnpcRClC9YU/gGed3DVsFqiOU=; b=cPBTYYSfBmtbXuuwsO+J5T3zv7Wq2OYYZbwyX4YK2UlrYJm+ihT2eYZJlxLO1SgnbY XGiXrE3iIWwGGsPRtBupX2vuwE8kB4KXA5g5e5qp26zatiIAQVMW02eXiO6i1JbkSKs8 7eBRF2WHKTclMbZiSaPXhfvXWj5n/DROwEXyAlq1ssid6fW+lo94UorOVaaLMHupTYCj jW8EyiQ+VfxGBK1EXeUrZUU+SjgpH3J2nXgCbETmhIS6osULgz3KxrCotXSpLNpPvOZx 8sBSd8AtPuJom+wNV2Lpn9qVKsGzB5j3BiTyugp12ZZw5T7ZioSAuTdIF9t809ySsh9i KIag== 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=H53I9YjUoFVCaIUoyVLnpcRClC9YU/gGed3DVsFqiOU=; b=r9jtV0qwcogeOXPyypcp0I1QTkjc6fXgCQRPmPXnY/5j9cO2lPsFpM+e9JG2QjppVj PZsgI9HzyR3Uagp9swoYzDsRsU3mxaZmnSXGmPBnDBgmQkxEq1nb0WLcQbSjcc7T8dxm yVfgkUoGCHI809uSvjx38fsb0kXS/4x9jrSFtxO1rzVjmz80IlZUTT7fp0W/oRCpehrV xJvXk69Q2sCeLfRDuTPjlw6sZtCEuLpd+7isfq2AVa/O4XznKsketnWJAxgXFRPZM4aO j/TBWP3ZBjTLvTgN/b+Kxtp5GefxiN2WL+LoqWQA57YXSUWlZOJMmGyvqIQMX21YfmKc PuvA== X-Gm-Message-State: AHPjjUgHw9B2HAOTa+AfG+UVlQV5/kiB7gmmJN/ghe1g4z6vWBe4wf+k 0h25gjHvbK63P1HUVuC0mYe9tU49ldhCSK8EvRY= X-Google-Smtp-Source: AOwi7QAh3yoI3Qiu04JwRJlXBRW01tFAirbj6wfxUlIaUU+eFRBoyvd0fb9BkyZx3pD8yzT6bua0FvzK/DWjFaueAyU= X-Received: by 10.223.199.15 with SMTP id k15mr22580368wrg.111.1507186668795; Wed, 04 Oct 2017 23:57:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Wed, 4 Oct 2017 23:57:47 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> From: Padma Pillay-Esnault Date: Wed, 4 Oct 2017 23:57:47 -0700 Message-ID: To: "Joel M. Halpern" Cc: Uma Chunduri , Benjamin Kaduk , Jari Arkko , "ideas@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="089e0824490c00fb21055ac73ea5" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 06:58:52 -0000 --089e0824490c00fb21055ac73ea5 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 4, 2017 at 9:40 PM, Joel M. Halpern wrote: > You seem to be making some unstated assumptions. > > If by "Provider" in "Provider based AUTH" you mean the last hop > communications service provider, then I would fundamentally disagree with > you. The communication service provider has no role in creating or > authenticating identifiers. Their job is to provide locators. > There is no disagreement in that the access provider role is to provide locators. > Now, those service providers may have an authentication relationship, > based on some identifiers, in order to provide communications services. Again no disagreement that the access provider have an authentication mechanism. An example would be "A device connects to a wifi, uses some authentication to get a locator." > But the identifiers for that are completely uncoupled from and unrealted > to the identifiers need for an ID / Locator system. > Still in agreement with you here and this is like a and has nothing to do with ID/LOC. I might also add that this is orthogonal to the discussion. The access provider can be provider of identifiers or not it would not have any bearing. At this point, the device has a locator and next step is to update its locator in the mapping system. > Yes, if there is a provider of identifiers (not all systems even require > that), then the user of the identifier needs to have an appropriate > relationship with the provider of the identifier. And that needs to be > related to the authentication needed to update the mapping system. > > (1) The "appropriate relationship with the provider of identifier" or what you call the "user of the identifier" (for clarity - user is NOT a person) is what in this context is called "identity". May be some people would prefer some other term (pseudonym?) but let's stick to this one for the moment. Now regarding who can update the locators? (2) There is agreement that there is a need for the "user of the identifier" (again user is NOT a person) to be authenticated to update the locator of an Identifier. (1) + (2) actually shows de facto a relationship between "user of identifier"(aka identity here) and the "identifier". This is all that what is formalized in this charter as the identity-identifier relationship. > But neither of those require anything other than the identifier and > suitable keying. I gave several examples of this in earlier emails to the > list. > > Here is where we have some difference of opinion ... Well depending on the functionalities, it might be that keying is not sufficient or they may be alternatives to keying. As mentioned in the thread earlier ... there are 2 operations with require some authentication or access-control - update - lookup Access control or "policies" on look up for one may be challenging using keying. Some notions of closed user groups are interesting use cases and it is worthwhile to evaluate other alternatives. Now if we want an open system with no authentication for updates or lookups and no close user group kind of features ... Then, as you said earlier not all system require that and we do not need "user of identifier". Precisely, this is why the identity concept is optional. However it can be useful in some cases such as in enterprise space where IoT devices may need finer access control. Regards Padma > Yours, > Joel > > > On 10/4/17 11:24 PM, Uma Chunduri wrote: > >> Hi Joel, >> >> >> >Yes, authentication is necessary to modify the entries. >> (Whether one should be authenticated before reading varies from case to >> case.) >> >But authentication does not require a separate identity. >> Exactly what it requires depends upon how the system is constructed. >> >> IMHO, provider based AUTH is needed in lot of cases if we really want to >> build a solid system which enables mobility. >> I responded to Jari, who is a pioneer and who helped spec out one of the >> best AUTH methods & systems successfully deployed ever with his >> https://tools.ietf.org/html/rfc4187 >> (but he did it for another most successful SDO, with all constructs like >> Pseudonyms and fast-re-auth-ids) didn't see the need for the same here. >> May be as you indicated there is something missing in the charter that >> didn't reflect the need. >> >> -- >> Uma C. >> >> > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > --089e0824490c00fb21055ac73ea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 4, 2017 at 9:40 PM, Joel M. Halpern <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com= > wrote:
You seem to be making some unsta= ted assumptions.

If by "Provider" in "Provider based AUTH" you mean the = last hop communications service provider, then I would fundamentally disagr= ee with you.=C2=A0 The communication service provider has no role in creati= ng or authenticating identifiers.=C2=A0 Their job is to provide locators.

<Padma> There is no disagreement in that the=C2=A0access=C2=A0provider role is to p= rovide locators.

=C2=A0
Now, those service providers may have an authentication relationship, based= on some identifiers, in order to provide communications services.

<Padma> Again no disagreement that the access provider = have an authentication mechanism. An example would be =C2=A0"A device = connects to a wifi, uses some authentication to get a locator."=
=C2=A0
But the identifiers for that are comp= letely uncoupled from and unrealted to the identifiers need for an ID / Loc= ator system.


<= ;Padma> Still in agreement with you here and this is like a <wifiname,passwd>= and has nothing to do with ID/LOC. I might also add that this is orthogonal to = the discussion. The access provider can be provider of identifiers or not it wo= uld not have any bearing.


At this point, th= e device has a locator and next step is to update its locator in the mappin= g system.



Yes, if there is a provider of identifiers (not all systems even require th= at), then the user of the identifier needs to have an appropriate relations= hip with the provider of the identifier.=C2=A0 And that needs to be related= to the authentication needed to update the mapping system.

<= ;Padma>

(1)= The "appropriate relationship with the provider of identifier" =C2=A0= or what you call the "user of the identifier" (for clarity - user is= NOT a person) is what in this context is called "identity". May be so= me people would prefer some other term (pseudonym?) but let's stick to thi= s one for the moment.

=C2= =A0

Now regarding who can update the locators?

(2) There is agreement that there is a need for the "user of the identifier" (again user is NOT a person) =C2=A0to be authenticated to = update the locator of an Identifier.

=C2= =A0

(1)= + (2) =C2=A0actually shows de facto a relationship between "user of identifier"(aka identity here) =C2=A0and the "identifier".= =C2=A0


This is all that what is formalized in this charter as the identity-identifier r= elationship.

=C2=A0
But neither of those require anything other than the identifier and suitabl= e keying.=C2=A0 I gave several examples of this in earlier emails to the li= st.


<Padma> Here is where we have so= me difference of opinion ...

Well depending on the functionalities, it might be that keying is not sufficient= or they may be alternatives to keying. As mentioned in the thread earlier ... there are 2 operations with require som= e authentication or access-control

- update

- lookup

=C2= =A0

Acc= ess control or "policies" on look up for one may be challenging using= keying. Some notions of closed user groups are interesting use cases and i= t is worthwhile to evaluate other alternatives.

=C2= =A0

Now if we want an open system with no authentication for updates or lookups and= no close user group kind of features ...=C2=A0Then,=C2=A0as you=C2=A0said earlier not all = system require that and we do not need "user of identifier".

Precisely,=C2=A0this is why the identity concept is optional= .=C2=A0
<= br>
Howev= er it can be useful in some cases such as in enterprise space where IoT devices may need finer access control= .=C2=A0

<= div>Regards
Padma =C2=A0
=C2=A0
Yours,
Joel


On 10/4/17 11:24 PM, Uma Chunduri wrote:
Hi Joel,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 >Yes, authentication is necessary to modify = the entries.=C2=A0 (Whether one should be authenticated before reading vari= es from case to case.)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >But authentication does not require a separ= ate identity.=C2=A0 Exactly what it requires depends upon how the system is= constructed.

IMHO, provider based AUTH is needed in lot of cases if we really want to bu= ild a solid system which enables mobility.
I responded to Jari, who is a pioneer and who helped spec out one of the be= st AUTH methods=C2=A0 & systems successfully deployed ever with his https://tools.ietf.org/html/rfc4187
(but he did it for another most successful SDO, with all constructs like Ps= eudonyms and fast-re-auth-ids) didn't see the need for the same here. May be as you indicated there is something missing in the charter that didn= 't reflect the need.

--
Uma C.


_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

--089e0824490c00fb21055ac73ea5-- From nobody Thu Oct 5 00:04:55 2017 Return-Path: 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 4C1B313336A; Thu, 5 Oct 2017 00:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hyuLTyPVHfrw; Thu, 5 Oct 2017 00:04:52 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 6E968132D17; Thu, 5 Oct 2017 00:04:52 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id u138so155603wmu.5; Thu, 05 Oct 2017 00:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Haje3jl2eOptJj0z9ZNzqQRxLx+aJq9cBqD58734Fck=; b=lEE0LjFOeFSnptF8a3OnseulqFPTtWkaUdut9nqdfCmaX8alSxw4WOs9iJShKj8ZS/ N73oOhhO4kqOnbXuaz4hpPRn5SvK4qImXkG3d+VenAm8nMp0HhJvKej8DsyeCO7UOIcU 91xZ9S6sYTkg6Xq5XqYNFsLaFfC8evMiX0X9uVoDAzczFWgn+kdwbNcwcH9Ejq88v6Rm 6mpKJfoPl6msIYccV01s0G7ZjZ7mItc9EVjTjYXjvqFgs75smOmK2mhxozp2SZLspvb2 K1giu7O3L3QdmlLvoqLTMxcbmzYbd22jugy+qkZJzEDRCcVqajLcRXlRAkuffoy3s+e7 N0sA== 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=Haje3jl2eOptJj0z9ZNzqQRxLx+aJq9cBqD58734Fck=; b=GI2IfsnuyIu4tI/2e6+mrJGdUXvAI+bu3mTLktag73ooj2Fwx/XjLX90zvoMJpmpfS w13MnjYWru50ELlxJtslf7IjyHR+wOFMsmKVdB4iyM+OQW+vF/4JKTfWzAaYWmygqAGl 6Fm/Z/DIM6HodfzM3hxTYCGj7l8VdT+pOj97a7FjTM93OwhPn5eVPw2AZzzGY6DVZI5+ /5KZ6qvrBuPly9PuI2nh4T1mJtARv71SHeCyD05Q5yOixEqN32KHpjSqxCM90MqDpH7v npC7NVm2XSf1TW5SIkaVV2qRWpI1JaPknu9nMaRBlTGoENEbka9AanVnMkIh16OnQE1e 6n1g== X-Gm-Message-State: AHPjjUjv0MlqfumdxsGmtitfPem6ot/rRB5OoWN6hIxRzAvg3zU4ZH4K RqhIp7HxRPZZbsnvxnfbXL3GiCDx+Wu70cVdiPU= X-Google-Smtp-Source: AOwi7QCfXUnCsBaeqqfsVm0B62rm5N32j9TKsBXU+U6YveDNLxTN6ZoQGEmh37Qc327AlEVZiNNLnRvIGnrPIDjvojE= X-Received: by 10.28.141.1 with SMTP id p1mr15950371wmd.68.1507187090953; Thu, 05 Oct 2017 00:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Thu, 5 Oct 2017 00:04:50 -0700 (PDT) In-Reply-To: <3c7810cb-8750-416a-d2ef-11b334c0b979@acm.org> References: <3c7810cb-8750-416a-d2ef-11b334c0b979@acm.org> From: Padma Pillay-Esnault Date: Thu, 5 Oct 2017 00:04:50 -0700 Message-ID: To: Erik Nordmark Cc: Christian Huitema , IETF Discussion Mailing List , ideas@ietf.org Content-Type: multipart/alternative; boundary="001a11469d402a9adc055ac7577d" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 07:04:54 -0000 --001a11469d402a9adc055ac7577d Content-Type: text/plain; charset="UTF-8" > I think there is also an aspect of "tracked by whom" which needs to be > considered. > > Perhaps it would be worthwhile to clarify this in the charter. > Today a user is likely to have different concerns about being tracked by > e.g., Facebook or Google when the are logged in the their account then > being track by a 3rd party such as an ISP or nation state. In the same way > an (industrial) IoT device might need to be tracked by the owner of that > device, without it being trackable by a 3rd party. > > There might be an implicit assumption in the IDEAS work that there will be > a globally id->loc database readable by all, the same way we think of the > global DNS. But I think that this would be overly limiting and push us into > a black or white privacy vs. functionality discussion. > > > Elsewhere I see IETF protocols like EVPN which is used to advertise > (factory assigned and permanent) Ethernet MAC addresses in BGP, which is > global. However, the way that protocol is deployed the distribution of the > EVPN routes are constrained (by BGP configuration) to the domain which > should have access to such information. The notion of having a > distribution/lookup/mapping technology which is capable of being global, > i.e., not tied to technology, but where the information sharing is > restricted by policy makes a lot of sense to me. This policy could be some > notion of closed user groups. > > Yes the point was to restrict information to eavesdroppers or share with need to know. > Thus I think we should collectivity look at a combination of approaches > which includes the MP-TCP-like locator agility with its privacy protection > and also cryptographically strong identifiers in IDEAS with privacy > protection designed in from day one. > > Agree > My 2 cents, > Erik > > > --001a11469d402a9adc055ac7577d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
I think there is also an aspect of "tracked by whom" which needs = to be considered.

<Padma> Perhaps it would be worthwhile to clari= fy this in the charter.
=C2=A0
Elsewhere I see IETF protocols like EVPN which is used to advertise (factor= y assigned and permanent) Ethernet MAC addresses in BGP, which is global. H= owever, the way that protocol is deployed the distribution of the EVPN rout= es are constrained (by BGP configuration) to the domain which should have a= ccess to such information. The notion of having a distribution/lookup/mappi= ng technology which is capable of being global, i.e., not tied to technolog= y, but where the information sharing is restricted by policy makes a lot of= sense to me. This policy could be some notion of closed user groups.

<Padma>
Yes the point was to restrict= information to eavesdroppers or share with need to know.=C2=A0
= =C2=A0
Thus I think we should collectivity look at a combination of approaches whi= ch includes the MP-TCP-like locator agility with its privacy protection and= also cryptographically strong identifiers in IDEAS with privacy protection= designed in from day one.

<Padma> Agree
=C2=A0
My 2 cents,
=C2=A0 =C2=A0Erik



--001a11469d402a9adc055ac7577d-- From nobody Thu Oct 5 00:52:16 2017 Return-Path: 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 E421E133070; Thu, 5 Oct 2017 00:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 nlsut0wadQOw; Thu, 5 Oct 2017 00:52:11 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 6116F133018; Thu, 5 Oct 2017 00:51:25 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id q124so408981wmb.0; Thu, 05 Oct 2017 00:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hb7FHgQH7YM+rFbe/PFhiCTPSQOZYdpSSvcxyGsBwR0=; b=SxPRc4Rdi/pQfANSedI/AP/Et5XrBjPpQkr1mH3pJti4UpPaw3QWcvLcHPwScbzLqH yilgDPMZ/xV1W51cfyBziVgIH882BZAWzZENxRRvaDiUN1oCorp+QBOaWjqHPC4KZa+F 858bWe9OV3mV83VZOfZIiBe4IY5c1v/ahBWG0fiuuzQEkNjJvDO6OSDZpoj4hKNIs6sb oXjECAclxFeJug2PiTXlFjY8+eT5KSJhGaapqArSeVXYInjLeW3rz9Dq2y7TXtXprTzk AQhCMagKjnZXbw8smCNVzOdJaUe9kC9Ljm+yFhgRo5XTWrSIhBUGv782/IVJVb4d3YqC Cgdg== 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=Hb7FHgQH7YM+rFbe/PFhiCTPSQOZYdpSSvcxyGsBwR0=; b=kPe1lEOAurFLDmCbFpV4iT1pj1SqVAfICsFQFG793uWpFT55KxjL51Vca4FBuNAd07 hr2pqVNc7R0890bHB40ottdj18ncudqUWJ0w2R0miq/PEJJLoBuEjkEVK22HK32pGeip IO38gPRYwZ898IJTaTJ2aVisaj1ifp1GlJrHCXmzrkM57a/tx6XSPocirdcR3FJHoVku D4XjPbiEpjKaU4l5tmuK5t2AQVyzCeYBSpRW6jnYC6o4aXIp5HKWPfPzmwD+wVgXXwr1 V2qPGmM82BX+AWd3EK9CJ5cXm7yJhwHGi44XUV7sQevWwxS6CZl5gQwJpLHzDqdYwNjU pOhw== X-Gm-Message-State: AHPjjUiKO1kPT2MkLr/KCJ2DdXVUiOgxBAT7AINgPPkN8HohMTU7n/r+ vDdjeU2I7PtS39mUWKxJqflptlEn6jWAmHhLjN8= X-Google-Smtp-Source: AOwi7QAe+LOUcM2BC8Voz/iuxjim/Rv9Bp4UXWsnZfb1hhm9fX6OkM3Xbv9CUkmQbJGqrDqIdbbwL7hNKbZQDhi4exY= X-Received: by 10.28.141.1 with SMTP id p1mr16048532wmd.68.1507189883794; Thu, 05 Oct 2017 00:51:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Thu, 5 Oct 2017 00:51:22 -0700 (PDT) In-Reply-To: <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> From: Padma Pillay-Esnault Date: Thu, 5 Oct 2017 00:51:22 -0700 Message-ID: To: Jari Arkko Cc: "Eggert, Lars" , "ideas@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="001a11469d40a1f98c055ac7fd69" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 07:52:15 -0000 --001a11469d40a1f98c055ac7fd69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 2:41 PM, Jari Arkko wrote: > I was a bit surprised to see this come out of the IESG for > review, given that we had fairly serious discussions about the > problems of the proposed approaches at the BOF, but I see little > attention on those issues in the charter. > > But, to state my opinion about working group being created with this > charter, I have comments from two directions. > > First, from the point of view of =E2=80=9Cdo we need this=E2=80=9D or =E2= =80=9Cdo I need this=E2=80=9D, > I=E2=80=99m a =E2=80=9Cmeh=E2=80=9D. If the HIP and LISP folk and everyon= e else were > screaming for this, and we had enough deployment that we saw the > issues that the charter proposes, then sure. Not sure that=E2=80=99s case= . > > Secondly, I=E2=80=99m have similar concerns to Christian, Lars, Stephen a= nd others. > More specifically, at the BOF the goal seemed to be creation of > infrastructures > to manage and track identities, and to bind them to entities that assigne= d > them. I am not at all sure that=E2=80=99s a desirable direction. And the = charter > says little about the assumptions behind the work. > > The goal was not to manage and track identities but have a means to protect an identifier from misuse and abuse. The "user of an identifier" (disclaimer - user is not a human and in this context aka identity) typically need to authenticate to be able to update the locator in a mapping system. This aspect was just formalized in the charter. Looking at much of the discussions, it is important to make this clarification in the charter. > To expand a bit on these concerns, the proposed work doesn=E2=80=99t cons= ider > at all the types of identifier operations that work on ephemeral identiti= es > (e.g., HIP, MP-TCP). It would be sad if we created systems that > forced us to manage identifiers from some infrastructure when all > we needed to do in a particular case was =E2=80=9Cprove that you are the > same entity as in the other connection=E2=80=9D, which can be done e2e an= d > requires no infrastructure, or permanent identifiers. > > Actually after the discussions in the bof, it was clear that the entities should be allowed to have multiple identifiers and identities. The charter points to life cycle of these and there is no assumption that they cannot be ephemeral. The management of identities here is just formalizing what mapping systems need - an authentication of the "device using the identifier" for the update and look up of the locators. Today we already have identifiers/loc in infrastructure for lookups this is no different. The goal was rather to check if that entity X that is trying to locate entity Y is ok by entity . If not, not to honor the look up - kind of a "do not call" list. > The charter text also mentions =E2=80=9Cidentifier changes=E2=80=9D in wh= at feels > like a special case for what I would think is rather the default. > > no it is default as identifiers are best to be ephemeral for privacy. > I find concept of firewalls checking identity troublesome. > there is no concept of enforcing firewall in the charter. The policy per identifier or identity is based on whether a lookup should be honored or not. Whether local firewalls (as in enterprise domains) are used to prevent and block communication is no different than today's use. > Now, I=E2=80=99m not opposed to creating a working group in the IETF in t= his > area, and to support various infrastructure needs of say mobility or > multihoming or anycast protoocols, but if we do it, we need to do > it right. Dino=E2=80=99s suggestion of mapping systems without the manage= / > create aspect might be one potential useful direction. Another > way to think about this space is to consider nodes to have autonomy > in how they manage and create their identities, when they reveal > or do not reveal identities. Then we could ask what > helpful tasks might an infrastructure provide on top of that, e.g., > mapping services or forwarding agent type designs. > > Agree that we want to do it the right. The notion autonomous nodes having their say on when to reveal their location is a goal for this infra. The "identities" in this context here are never revealed on the wire but only the pseudonyms or identifiers associated. There has been a lot of discussions on the alias and drafts which unfortunately cannot be reflected in a charter. One of the goals is to have better privacy and prevent easy tracking (as with long lived identities) against eavesdroppers or outsiders. Padma Jari > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > --001a11469d40a1f98c055ac7fd69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 4, 2017 at 2:41 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
I was a bit surprised= to see this come out of the IESG for
review, given that we had fairly serious discussions about the
problems of the proposed approaches at the BOF, but I see little
attention on those issues in the charter.

But, to state my opinion about working group being created with this
charter, I have comments from two directions.

First, from the point of view of =E2=80=9Cdo we need this=E2=80=9D or =E2= =80=9Cdo I need this=E2=80=9D,
I=E2=80=99m a =E2=80=9Cmeh=E2=80=9D. If the HIP and LISP folk and everyone = else were
screaming for this, and we had enough deployment that we saw the
issues that the charter proposes, then sure. Not sure that=E2=80=99s case.<= br>
Secondly, I=E2=80=99m have similar concerns to Christian, Lars, Stephen and= others.
More specifically, at the BOF the goal seemed to be creation of infrastruct= ures
to manage and track identities, and to bind them to entities that assigned<= br> them. I am not at all sure that=E2=80=99s a desirable direction. And the ch= arter
says little about the assumptions behind the work.

<Padma>
The goal was not to manage an= d track identities but have a means to protect an identifier from misuse an= d abuse. The "user of an identifier" (disclaimer - user is not a = human and in this context aka identity) typically need to authenticate to b= e able to update the locator in a mapping system. This aspect was just form= alized in the charter.

Looking at much of the disc= ussions, it is important to make this clarification in the charter.
=C2=A0
To expand a bit on these concerns, the proposed work doesn=E2=80=99t consid= er
at all the types of identifier operations that work on ephemeral identities=
(e.g., HIP, MP-TCP). It would be sad if we created systems that
forced us to manage identifiers from some infrastructure when all
we needed to do in a particular case was =E2=80=9Cprove that you are the same entity as in the other connection=E2=80=9D, which can be done e2e and<= br> requires no infrastructure, or permanent identifiers.


I find concept of firewalls checking identity troublesome.
=

<Padma> there is no concept of enforcing firewall= in the charter. The policy per identifier or identity is based on whether = a lookup should be honored or not. Whether local firewalls (as in enterpris= e domains) are used to prevent and block communication is no different than= today's use.


Now, I=E2=80=99m not opposed to creating a working group in the IETF in thi= s
area, and to support various infrastructure needs of say mobility or
multihoming or anycast protoocols, but if we do it, we need to do
it right. Dino=E2=80=99s suggestion of mapping systems without the manage/<= br> create aspect might be one potential useful direction. Another
way to think about this space is to consider nodes to have autonomy
in how they manage and create their identities, when they reveal
or do not reveal identities. Then we could ask what
helpful tasks might an infrastructure provide on top of that, e.g.,
mapping services or forwarding agent type designs.


<Padma>
Agree that we want to do it = the right. The notion autonomous nodes having their say on when to reveal t= heir location is a goal for this infra. The "identities" in this = context here are never revealed on the wire but only the pseudonyms or iden= tifiers associated.

There has been a lot of discus= sions on the alias and drafts which unfortunately cannot be reflected in a = charter.=C2=A0

One of the goals is to have better = privacy and prevent easy tracking (as with long lived identities) against e= avesdroppers or outsiders.

Padma

--001a11469d40a1f98c055ac7fd69-- From nobody Thu Oct 5 09:28:51 2017 Return-Path: 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 CBBFD132F3F; Thu, 5 Oct 2017 09:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 TaI981RKifZs; Thu, 5 Oct 2017 09:28:49 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 DD2C11342DC; Thu, 5 Oct 2017 09:28:25 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id g62so2579357pfk.12; Thu, 05 Oct 2017 09:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GFKysEwiuGShd470p545259mQzwacL/eL+IQEzQZSnk=; b=RqxM7SVujloO+WRjLXDuOg4MWDwOFfCclqdTaF8Z6+3kyJifzG2k5U7tHHJbgZhxRj GYH5j2kspyfOId5u2o8lXs297DnqDJ9iNuUxiQ4Vs8ECWHaMv8LNuHTkllLaw3hgM+N+ zIwU1Z6N2LnUuxns63yCAUq634RexLGRFak7q4XhJXvBLDBG62m7+LQl3UYHaZDNGRDq ehaIe8TfoXmIv7u0Gu6DJ7ZMJLwzbJT+sze5qx5Ky1mv9uFmoQQ/+91ZTr7gi9Zc2PeH SuQWTV9Ixt/6yJjy0LLgITsDMERWvl/UqmEkCG0hu1d/BYmxPC2CnaZEBkuYixf4FJaJ 36mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GFKysEwiuGShd470p545259mQzwacL/eL+IQEzQZSnk=; b=ly1KdjehAsT3lNjBiZqpteIordSHvGvkFYZpG0UWFKr4rsrbUjKAMTG/kGKcWJvBxG OTfOngxbNT5mywBXSQX+4abqHxsxVa1YYGskFmtI65JzcgeHI8AxZ8qmRD6RIVz0uXHC T7cAeJJcXg28o5Nx09mrSuvcf9M3Cun6iVa7mNElYkgcwICIqxXcfJyaNdtDlvPKLMIb Oew2Bc5bsopn+Cm/C+fT1PneYEpRtQ1DyaOn04f4QiFF0O+FkcRSub5fGpgzJONtVnfT baTEjokaH2f7sTDQki4YUgp+15ZJCHmx52oGH+r+A4Yvl8fMgqaRUrmMbV4iuCohd1LO 76FQ== X-Gm-Message-State: AHPjjUg3V8Sq0sDBG6UyzR4r0lpVCyv+Ugl5lrmVp+Q+2liRKwCXVFXM 4H2W0D2eJ27N759dMliQxrp+FqyL X-Google-Smtp-Source: AOwi7QDJucgWIi+3FwaXCjIRafFYelY+XLqBxqIcgxQpOVo19oZayCVa3YRuAwb1QOxoh2mrG2cQxA== X-Received: by 10.99.107.73 with SMTP id g70mr19677855pgc.279.1507220905469; Thu, 05 Oct 2017 09:28:25 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id y7sm30909716pfy.35.2017.10.05.09.28.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 09:28:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dino Farinacci In-Reply-To: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> Date: Thu, 5 Oct 2017 09:28:23 -0700 Cc: The IESG , ideas@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <408B974C-2C4F-497F-9FDE-B9AAD86547B2@gmail.com> References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 16:28:51 -0000 > 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. >=20 > 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. Christian, just to be clear, in LISP, temporary/ephemeral EIDs can be = used for the public case. For a private use case, one uses crypto-EID = authentication to regsiter and to get mappings from the mapping database = (can be used within a closed user-group VPN). And both for the public = and private case, crypto-EIDs can be used so a hash is pretty opaque to = trackers. And there is no reason you cannot use a set of private/public = key pairs and crypto hashes to send packets. So there are solutions to this. And they are implmented and ARE NOT = complicated. Dino From nobody Thu Oct 5 09:31:02 2017 Return-Path: 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 7C0B81331FF; Thu, 5 Oct 2017 09:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 RroEhipbGLSU; Thu, 5 Oct 2017 09:30:52 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 9AEE6132F3F; Thu, 5 Oct 2017 09:30:52 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id b11so8501367pgn.12; Thu, 05 Oct 2017 09:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z8/3nxqFNqwDE0FodKDwFogzOQqyzxa+G9DDbhKP928=; b=Xfrrc9mN/znVegdOo0FmMhD/O8MJ7qV9lmIjMH+gRJ6tbQFfp9M678wmlpu8TmFb6N hS7flgXqEpAFVuOFwRJN1JKiTTwNMtHamror7I1u4tS/NHEG5oH3w3sJGWifw3AG5bmB mB508gUtuo5owY/8871K7x+bpsVxkUTnNv/NKeBzKPYZDUrfAmOQXmZgMF+Vul5JcpBp F3OhznHuerarmX1dTRZcqF67XS0arpGtUcSvwIDcdF3UnNn4Xik+fwrxi9jI+RKx1Qqj 8Lhbz8HHqTblhww6gOz92hRCTuBaCX3C8ByDecyLEHmrDhUfjcdRbU2WR5NoLcQuBD4+ fObg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z8/3nxqFNqwDE0FodKDwFogzOQqyzxa+G9DDbhKP928=; b=QcbEaS1BRWp+932QMTmyXxcJ4rZXM/ij3d8T5q9z/F/wngtUnqIFe6t/q1HLFChEdk jKKansDcT3axUeR8jkDvgGx2X4b/0rqCvOE+iSsf2hrwgyqGOZ1iPQ/rXIlMmTysD1Nu 20vYsdhaq1ljK2I8HcmZA74T0SZ9r+AWSK+7J5KcKj55ruACtEayTG1HfQlXp5v9YO5+ aMHx1sC0eSFFLK0XVd2x1t+awr+VQPeuOlCVDuOpPQu/Ki88pHaPrR/hiZnscS2kYbxr /DdLDxpCOoD4CAHNJz+9jUyU+CCQcXGmAdR+4+ks6qA7HI3cx8+xO8dEuhcbDlL4i/Db J0KQ== X-Gm-Message-State: AMCzsaWfxaXJKBEop6HZ8yNtQqvf0pExQrVd8AcBXxKeERtpygX9Cwu6 qoj7olocHHWNbmjzsK79R78= X-Google-Smtp-Source: AOwi7QB0RI2jeUBiDTmHvgDJc2SpOI1nw3mr6wXiE1+8GxbXThymobsQ6neop5vfeT1hc3PY/5q0Dw== X-Received: by 10.159.252.11 with SMTP id n11mr8717766pls.172.1507221052221; Thu, 05 Oct 2017 09:30:52 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id s81sm36044203pfg.162.2017.10.05.09.30.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 09:30:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dino Farinacci In-Reply-To: Date: Thu, 5 Oct 2017 09:30:50 -0700 Cc: "Templin, Fred L" , "ideas@ietf.org" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <67067a23-bb7f-08e4-3766-8802d8f3121f@huitema.net> <45e8993a73ef4bb9b3914f32c4609823@XCH15-06-08.nw.nos.boeing.com> To: Christian Huitema X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 16:30:55 -0000 > Dino, I am well aware that we (well, you) *can* engineer ID/LOC = networks > to have good privacy properties. But I am also aware that if this is = not > an explicit goal in the charter, we may very well end up with Agree 100%. > architectures that have pretty bad properties. For example, most = ID/LOC > architectures rely on a database that provides the up-to-date LOC for = an > ID. In my bad dreams, I could see the database extended to provide = other > properties of the ID, such as subscriber ID. Similarly, there was a > proposal some time ago to have a unique IPv6 identifier for every EU > citizen; that bad idea was quashed, but we could easily see something > like that resurface as on unique ID per user. That's why I would like = to > see the proposed charter to be crystal clear about privacy = requirements, > rather than just say that we will think about it. Well, your dream is going to come true. There will be an IPv6 EID per = IoT device. ;-) Dino From nobody Thu Oct 5 10:05:31 2017 Return-Path: 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 8B7C51329B5; Thu, 5 Oct 2017 10:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 s7n22yyGJ0-y; Thu, 5 Oct 2017 10:05:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8CB132F3F; Thu, 5 Oct 2017 10:05:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY88741; Thu, 05 Oct 2017 17:05:19 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Oct 2017 18:05:19 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Thu, 5 Oct 2017 10:05:07 -0700 From: Uma Chunduri To: "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko CC: "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRCAAI/FAIAAAIUAgAAA9AD//6NuoIAAjskAgABU/1A= Date: Thu, 5 Oct 2017 17:05:06 +0000 Message-ID: <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59D66650.016D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 17:05:24 -0000 SGkgSm9lbCwNCg0KSW4tbGluZSBbVW1hXToNCg0KDQpCZXN0IFJlZ2FyZHMsDQotLQ0KVW1hIEMu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSANClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNCwg MjAxNyA5OjQxIFBNDQpUbzogVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbT47 IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgSmFyaSBBcmtrbyA8amFyaS5hcmtrb0Bw aXVoYS5uZXQ+DQpDYzogaWRlYXNAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbSWRlYXNdIFdHIFJldmlldzogSURlbnRpdHkgRW5hYmxlZCBOZXR3b3JrcyAoaWRlYXMpDQoN CllvdSBzZWVtIHRvIGJlIG1ha2luZyBzb21lIHVuc3RhdGVkIGFzc3VtcHRpb25zLg0KDQpJZiBi eSAiUHJvdmlkZXIiIGluICJQcm92aWRlciBiYXNlZCBBVVRIIiB5b3UgbWVhbiB0aGUgbGFzdCBo b3AgY29tbXVuaWNhdGlvbnMgc2VydmljZSBwcm92aWRlciwgdGhlbiBJIHdvdWxkIGZ1bmRhbWVu dGFsbHkgZGlzYWdyZWUgd2l0aCB5b3UuIA0KW1VtYV06IEkgbWVhbnQgSWRQIGFuZCBpdCdzIGFu IG9ydGhvZ29uYWwgZGlzY3Vzc2lvbiBpZiBib3RoIHJvbGVzIHBsYXllZCBieSBzYW1lIGVudGl0 eS4uDQogDQogVGhlIGNvbW11bmljYXRpb24gc2VydmljZSBwcm92aWRlciBoYXMgbm8gcm9sZSBp biBjcmVhdGluZyBvciBhdXRoZW50aWNhdGluZyBpZGVudGlmaWVycy4gIFRoZWlyIGpvYiBpcyB0 byBwcm92aWRlIGxvY2F0b3JzLg0KW1VtYV06IEFic29sdXRlbHkuDQoNCk5vdywgdGhvc2Ugc2Vy dmljZSBwcm92aWRlcnMgbWF5IGhhdmUgYW4gYXV0aGVudGljYXRpb24gcmVsYXRpb25zaGlwLCBi YXNlZCBvbiBzb21lIGlkZW50aWZpZXJzLCBpbiBvcmRlciB0byBwcm92aWRlIGNvbW11bmljYXRp b25zIHNlcnZpY2VzLiANCkJ1dCB0aGUgaWRlbnRpZmllcnMgZm9yIHRoYXQgYXJlIGNvbXBsZXRl bHkgdW5jb3VwbGVkIGZyb20gYW5kIHVucmVhbHRlZCB0byB0aGUgaWRlbnRpZmllcnMgbmVlZCBm b3IgYW4gSUQgLyBMb2NhdG9yIHN5c3RlbS4NCg0KWWVzLCBpZiB0aGVyZSBpcyBhIHByb3ZpZGVy IG9mIGlkZW50aWZpZXJzIChub3QgYWxsIHN5c3RlbXMgZXZlbiByZXF1aXJlIHRoYXQpLCANCg0K W1VtYV06ICBZZXMsIG1heSBiZSBub3QgYWxsIHN5c3RlbXMgcmVxdWlyZSB0aGF0LCBlc3BlY2lh bGx5IGlmIHRoaXMgaXMgYSBsb2NhbCBkZXBsb3ltZW50Lg0KDQp0aGVuIHRoZSB1c2VyIG9mIHRo ZSBpZGVudGlmaWVyIG5lZWRzIHRvIGhhdmUgYW4gYXBwcm9wcmlhdGUgcmVsYXRpb25zaGlwIHdp dGggdGhlIHByb3ZpZGVyIG9mIHRoZSBpZGVudGlmaWVyLiAgDQpBbmQgdGhhdCBuZWVkcyB0byBi ZSByZWxhdGVkIHRvIHRoZSBhdXRoZW50aWNhdGlvbiBuZWVkZWQgdG8gdXBkYXRlIHRoZSBtYXBw aW5nIHN5c3RlbS4NCltVbWFdOiBZZXMuDQoNCg0KQnV0IG5laXRoZXIgb2YgdGhvc2UgcmVxdWly ZSBhbnl0aGluZyBvdGhlciB0aGFuIHRoZSBpZGVudGlmaWVyIGFuZCBzdWl0YWJsZSBrZXlpbmcu ICANCltVbWFdOiBJZiBpdCdzIGEgbG9jYWwgc3lzdGVtIHNpbXBsZSBrZXlpbmcgaXMgZW5vdWdo IChpbiB0aGUgZXhwZW5zZSBvZiBrZXkgbWFuYWdlbWVudCBldGMpIGFzIGFsbCBkZXZpY2VzIG1h eSBiZSBtYW5hZ2VkIGJ5IHRoZSBzYW1lIG9yZy4NCg0K From nobody Fri Oct 6 00:49:58 2017 Return-Path: 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 D2611134592; Fri, 6 Oct 2017 00:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 kkKqenogX1x2; Fri, 6 Oct 2017 00:49:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BD4134591; Fri, 6 Oct 2017 00:49:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWY54232; Fri, 06 Oct 2017 07:49:24 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.201.109.53]) by lhreml709-cah.china.huawei.com ([10.201.108.32]) with mapi id 14.03.0301.000; Fri, 6 Oct 2017 08:49:13 +0100 From: Georgios Karagiannis To: Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko CC: "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTr8mvVhpJ8Xk2HRextCZOYFaLUJ9qAgAAzkoCAAA3FAIAAAIUAgAAA8wCAABzkAIAAFVQAgADQAACAAQb2wA== Date: Fri, 6 Oct 2017 07:49:13 +0000 Message-ID: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> In-Reply-To: <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.62.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59D73586.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 07:49:50 -0000 Hi all, Please note that I have looked into the output of the (concluded) IETF ABFA= B WG. In order to answer many questions/concerns that have been raised duri= ng the previous IDEAS discussions, it might be useful to consider the resul= ts of the IETF ABFAB WG. https://datatracker.ietf.org/wg/abfab/documents/ We could incorporate their concepts about identity and how identity can be = established and leveraged in a distributed way able to satisfy trust and pr= ivacy concerns. Best regards, Georgios -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Thursday, October 05, 2017 7:05 PM To: Joel M. Halpern; Benjamin Kaduk; Jari Arkko Cc: ideas@ietf.org; ietf@ietf.org Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) Hi Joel, In-line [Uma]: Best Regards, -- Uma C. -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, October 04, 2017 9:41 PM To: Uma Chunduri ; Benjamin Kaduk ;= Jari Arkko Cc: ideas@ietf.org; ietf@ietf.org Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) You seem to be making some unstated assumptions. If by "Provider" in "Provider based AUTH" you mean the last hop communicati= ons service provider, then I would fundamentally disagree with you.=20 [Uma]: I meant IdP and it's an orthogonal discussion if both roles played b= y same entity.. =20 The communication service provider has no role in creating or authenticati= ng identifiers. Their job is to provide locators. [Uma]: Absolutely. Now, those service providers may have an authentication relationship, based= on some identifiers, in order to provide communications services.=20 But the identifiers for that are completely uncoupled from and unrealted to= the identifiers need for an ID / Locator system. Yes, if there is a provider of identifiers (not all systems even require th= at),=20 [Uma]: Yes, may be not all systems require that, especially if this is a l= ocal deployment. then the user of the identifier needs to have an appropriate relationship w= ith the provider of the identifier. =20 And that needs to be related to the authentication needed to update the map= ping system. [Uma]: Yes. But neither of those require anything other than the identifier and suitabl= e keying. =20 [Uma]: If it's a local system simple keying is enough (in the expense of ke= y management etc) as all devices may be managed by the same org. _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Fri Oct 6 02:32:31 2017 Return-Path: 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 4B36A13487E; Fri, 6 Oct 2017 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 DUbpwdR7dDQq; Fri, 6 Oct 2017 02:32:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91BF13487D; Fri, 6 Oct 2017 02:32:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21922BE24; Fri, 6 Oct 2017 10:32:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxCL7iKHtaAy; Fri, 6 Oct 2017 10:32:18 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49E30BE38; Fri, 6 Oct 2017 10:32:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507282337; bh=8neyMjmPuN9uOo+qlboyaUax4QCoJhr2aLzFQt0AIlY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UtdODxj52eSAN6WdofbX9W4jx0fPfMqKCI4ncBbWHkWwWVAe/dyNhWKQFe6mlAwh7 oiyzGfQcUnZo6m/pfSWnNjzPf9ExLnHKxOOj6cvJe6+B8buh+uQH0vdPK6ecP2QjQq XCUmnoKik8B4aTRFbR/DeXoWSmX5dn5dMisE+hno= To: Georgios Karagiannis , Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko Cc: "ideas@ietf.org" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 6 Oct 2017 10:32:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NoMbXAHSBFaRiUjdEtlIVKM7G4LXg8oIi" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 09:32:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NoMbXAHSBFaRiUjdEtlIVKM7G4LXg8oIi Content-Type: multipart/mixed; boundary="1F9n9qGPLMDBILo4qw5m7JMbCWwOlMEuS"; protected-headers="v1" From: Stephen Farrell To: Georgios Karagiannis , Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko Cc: "ideas@ietf.org" , "ietf@ietf.org" Message-ID: Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> In-Reply-To: --1F9n9qGPLMDBILo4qw5m7JMbCWwOlMEuS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 06/10/17 08:49, Georgios Karagiannis wrote: > Hi all, >=20 > Please note that I have looked into the output of the (concluded) > IETF ABFAB WG. In order to answer many questions/concerns that have > been raised during the previous IDEAS discussions, it might be useful > to consider the results of the IETF ABFAB WG.=20 > https://datatracker.ietf.org/wg/abfab/documents/ >=20 > We could incorporate their concepts about identity and how identity > can be established and leveraged in a distributed way able to satisfy > trust and privacy concerns. I have no clue how GSS-API is even relevant here. abfab was a fine thing for JISC and friends to do to as a way to try broaden the benefit they got from their existing federated authentication setup, in their case involving UK universities. It is not at all clear that that would be even relevant if one wanted to build the kind of all encompassing IdPs envisaged in the ideas charter/draft. The relationships that university account holders have with their own and other academic institutions and with applications running in such environments (that being the point of abfab) don't seem to me to generalise to lower layers in any useful manner. In any case, if this proposal is only now at the point where you're starting to ponder the basic architecture then I'd conclude it's nowhere near ready to charter. (As well as being a bad idea from the privacy POV;-) WGs for such decisions can be a good plan when there's a few known architectural choices on the table, and if different sets of folks need a venue to reach consensus on which road to take - suggesting abfab at this point sounds like floundering around looking for reasons to exist tbh. (Sorry to be blunt and it may not be that, but it appears to be that to me.) S. >=20 > Best regards, Georgios >=20 >=20 > -----Original Message----- From: Ideas > [mailto:ideas-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: > Thursday, October 05, 2017 7:05 PM To: Joel M. Halpern; Benjamin > Kaduk; Jari Arkko Cc: ideas@ietf.org; ietf@ietf.org Subject: Re: > [Ideas] WG Review: IDentity Enabled Networks (ideas) >=20 > Hi Joel, >=20 > In-line [Uma]: >=20 >=20 > Best Regards, -- Uma C. >=20 > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Wednesday, October 04, 2017 9:41 > PM To: Uma Chunduri ; Benjamin Kaduk > ; Jari Arkko Cc: > ideas@ietf.org; ietf@ietf.org Subject: Re: [Ideas] WG Review: > IDentity Enabled Networks (ideas) >=20 > You seem to be making some unstated assumptions. >=20 > If by "Provider" in "Provider based AUTH" you mean the last hop > communications service provider, then I would fundamentally disagree > with you. [Uma]: I meant IdP and it's an orthogonal discussion if > both roles played by same entity.. >=20 > The communication service provider has no role in creating or > authenticating identifiers. Their job is to provide locators. [Uma]: > Absolutely. >=20 > Now, those service providers may have an authentication relationship, > based on some identifiers, in order to provide communications > services. But the identifiers for that are completely uncoupled from > and unrealted to the identifiers need for an ID / Locator system. >=20 > Yes, if there is a provider of identifiers (not all systems even > require that), >=20 > [Uma]: Yes, may be not all systems require that, especially if this > is a local deployment. >=20 > then the user of the identifier needs to have an appropriate > relationship with the provider of the identifier. And that needs to > be related to the authentication needed to update the mapping > system. [Uma]: Yes. >=20 >=20 > But neither of those require anything other than the identifier and > suitable keying. [Uma]: If it's a local system simple keying is > enough (in the expense of key management etc) as all devices may be > managed by the same org. >=20 > _______________________________________________ Ideas mailing list=20 > Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas >=20 >=20 --1F9n9qGPLMDBILo4qw5m7JMbCWwOlMEuS-- --NoMbXAHSBFaRiUjdEtlIVKM7G4LXg8oIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ102gAAoJEC88hzaAX42i2j4H/jaPK8WLAcBI/VttBsv7ZrK8 M0k2jdqe446TeUtqCymyL1xBHEpFKZAh6NYldB129LGq7tbMi7EdPqiQwqSzqn67 oqwieKndadKSJv8/B3csW8TQKwuRGznbI/1/xiaefujQAqgIs2X6bU4vRBn3AHAV H6JLL5WeiaoR+4vOzw/ILlmzplGkE3ApYtQ6A7mXjoSYDFJnxVEdogVBjFEoEXgT 9p4FjP43Pykbq8CCPLCFexp0nypXa18wIZ2sAscrGpQOaVUUjkM2Odg9VHS6aia1 eFXxHPRXgBbIq5FuDkfcPs7A24h936k8EWt0ejdPRMtdPQpCZcUC2f0uLKk2bQM= =CHFD -----END PGP SIGNATURE----- --NoMbXAHSBFaRiUjdEtlIVKM7G4LXg8oIi-- From nobody Fri Oct 6 20:38:16 2017 Return-Path: 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 0AAFA1326FE; Fri, 6 Oct 2017 20:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 P_TXPLeJoI1I; Fri, 6 Oct 2017 20:38:13 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 60D9E132076; Fri, 6 Oct 2017 20:38:13 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 196so4625758wma.1; Fri, 06 Oct 2017 20:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cVepUijScZf8MBa9ggQT3GtQ8LXqimLyLEDbKhXiaSo=; b=i+OX8VoiRCU8Kdwx3T98LxPVcQ8oEJdgPfFyocusDOw+EwLBCPMNMVwxSHZ0kzwKfI tREzP/i8gYbpb38+u38W7GWdQWQ9A9/h2D+2ekXtvV+qFdSA4YasHIkxVzEqdYZw7vMe 7IT9tHzIKFpqs0VMzMRY1hQjqZ09zi+CEqh0rsACwrOC8Os4K27suKf5+sFWfR8FQy++ AlsqAAWe3GTn3VPcF4CXS+b38UOkPVM34BRYKEKpSjkBv9bv8WCRyIWQy0ww8S74a/v1 zBAawh6goceePF73IIMegtx0Mfcw6izVg61+aTfxreFC/eHhAfT2N4lCyvrRyPJqWFzB WLHw== 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=cVepUijScZf8MBa9ggQT3GtQ8LXqimLyLEDbKhXiaSo=; b=caVB208nbQ7TsESC9Ij8lmPI+NAKEo8IMUkogw6VzcJU0P/bPwPZKVuHb9W5s5rIYR IBI5ah5lgeDUMLpVTna0MfzPx2mQ9JKFV8bM8Qd1JQ5KJLcQPoGpJVJGX1BPop4yrfM6 nkAXZUmRBdI2tftAA3ErJXZkskv5UuOATooQlfc9QgZ41suVA0Spj4Ivizz2biz8aBPv REHzZRVzK0+B1jGstzr9rj041sJDx268kSvp7EyDkgbSJzUFb1pGRJOiCMl5sS23QNTT n6ksPCw9zhShh7RxsOpekuI0o9eJGJ1Rw0jd06AWM7aCyCskefx0eBxDb0BY1jrkFB9w 2v1g== X-Gm-Message-State: AMCzsaUIaIciDAp724eYWQ7XbRuT6ZVe5uOgOtZ06Lc3UGtAgB22P5Sf 3VD/9c41pTu1tXTEJqb1DbfntRMsWBsu0pZgTrICtw== X-Google-Smtp-Source: AOwi7QC/x/aumAXn37EdBmWBrn/DLWZ/JI0offx4yaQZw7eohmRlGLi/PLFJYX5PX6xuM2NK28pOaHCq31ILMsFUQwQ= X-Received: by 10.223.186.82 with SMTP id t18mr3901687wrg.19.1507347491906; Fri, 06 Oct 2017 20:38:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Fri, 6 Oct 2017 20:38:10 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> From: Padma Pillay-Esnault Date: Fri, 6 Oct 2017 20:38:10 -0700 Message-ID: To: Stephen Farrell Cc: Georgios Karagiannis , Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko , "ideas@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="089e082452d0ceeaeb055aecaf1c" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 03:38:15 -0000 --089e082452d0ceeaeb055aecaf1c Content-Type: text/plain; charset="UTF-8" On Fri, Oct 6, 2017 at 2:32 AM, Stephen Farrell wrote: > > > It is not at all clear that that would > be even relevant if one wanted to build the kind of all > encompassing IdPs envisaged in the ideas charter/draft. > > What kind of all encompassing IdPs is being referred to above? The charter does not propose to build such an all encompassing system. The charter refers to a mapping system for Id/Loc protocols. The data is routing information. It may have some limited information if useful for routing purposes - such as the list of locators, groupings and so on. Today, routing information of this nature in mapping systems is not hidden. All nodes in ID/Loc protocols typically access this information for encapsulation, translation or forwarding decisions without any restrictions (within their instance/scope). One of the goals is to be able to authenticate and have access-control on the lookups if so desired. This functionality should enhance privacy on revealing locators of nodes. For example, you may want to advertise the location of some of your mobile IoT nodes in a factory on a need to know basis. The solution proposed here is one of them. To address your concerns: no all encompassing system, or humans involved here. Padma --089e082452d0ceeaeb055aecaf1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri, Oct 6, = 2017 at 2:32 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:

<snip>
It is not at all clear that that wou= ld
be even relevant if one wanted to build the kind of all
encompassing IdPs envisaged in the ideas charter/draft.
<snip>=C2= =A0


What kind of all encompassing IdPs is being referre= d to above? The charter does not propose to build such an all encompassing = system.


<= /p>

The charter refers t= o a mapping system for Id/Loc protocols. The data is routing information. I= t may have some limited information if useful for routing purposes - such a= s the list of locators, groupings and so on.=C2=A0=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-right:0in;margin-left:0in;font-size:1= 2pt;font-family:"Times New Roman",serif">

Today, routing information of this natu= re in mapping systems is not hidden. All=C2=A0nodes in ID/Loc protocols typ= ically access this information for encapsulation, translation or forwarding= decisions without any restrictions (within their instance/scope).=C2=A0=


=

One of the goals is to = be able to authenticate and have access-control on the lookups if so desire= d.=C2=A0 This functionality should enhance privacy on revealing locators of= nodes.


For example, you may want t= o advertise the location of some of =C2=A0your mobile IoT nodes in a factor= y on a need to know basis. The solution proposed here is one of them.


To address your concerns: = no all encompassing system, or humans involved here.=C2=A0


Padma=C2=A0

=C2=A0

--089e082452d0ceeaeb055aecaf1c-- From nobody Sat Oct 7 06:22:38 2017 Return-Path: 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 9FBC613487A; Sat, 7 Oct 2017 06:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 hi1OTLOx_6A9; Sat, 7 Oct 2017 06:22:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6231342FD; Sat, 7 Oct 2017 06:22:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E51FBE74; Sat, 7 Oct 2017 14:22:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U84V59fzYZpp; Sat, 7 Oct 2017 14:22:22 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78813BE6F; Sat, 7 Oct 2017 14:22:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507382542; bh=5ARD3zx1nskdq2+wbyNgsly1DMxBCzoP0llHCv4J/0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=4jamDle450rSPifZhml55tqD0uD6WqT2nIcAxu+Og1lXbx0PmV28QJex2ouUey0uT eT48DV7CQKCd0LijVZafpTHXmWrTQlQnqtJGh3ASgEkVMKH4dVl7GPWmzCSotEiuiE d57lwDeZDX9baGEQ5DpZLK+TQf6MPtd+ji69JVBk= To: Padma Pillay-Esnault Cc: Georgios Karagiannis , Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko , "ideas@ietf.org" , "ietf@ietf.org" References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <192c25a4-c841-b828-1cfe-9e9857028b42@cs.tcd.ie> Date: Sat, 7 Oct 2017 14:22:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tVneAxIjaFcQxvJUdSAeLhvlmr2drBLnr" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 13:22:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tVneAxIjaFcQxvJUdSAeLhvlmr2drBLnr Content-Type: multipart/mixed; boundary="j5NaF8XfwDJjktqTTLHgqrPqEpG22uwTj"; protected-headers="v1" From: Stephen Farrell To: Padma Pillay-Esnault Cc: Georgios Karagiannis , Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko , "ideas@ietf.org" , "ietf@ietf.org" Message-ID: <192c25a4-c841-b828-1cfe-9e9857028b42@cs.tcd.ie> Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> In-Reply-To: --j5NaF8XfwDJjktqTTLHgqrPqEpG22uwTj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/10/17 04:38, Padma Pillay-Esnault wrote: > To address your concerns: no all encompassing system, or humans involve= d > here. I'm sorry but my concerns are just not addressed. There are humans involved here - they're the ones carrying the phones and whose presence triggers traffic from other devices. And while "all encompassing" is maybe a little bit overstated, anything considering that there's a widespread need for permanent identifiers (your IDy's) does seem to be aiming in that direction. If this effort is only aiming at some niche within the universe of devices that could have (but hopefully won't have) permanent identifiers known to networking kit, then you've not identified the niche, and so do sorta seem to be aiming for an all-encompasing IdP. S. --j5NaF8XfwDJjktqTTLHgqrPqEpG22uwTj-- --tVneAxIjaFcQxvJUdSAeLhvlmr2drBLnr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ2NUNAAoJEC88hzaAX42iqvAH/2YgEMa7Mizwp98u5yjvyNQc 2ztuVBjcHO4H1JJtVUQ1H/+HKNeuuLQ5DVuROck/761+TyWWbTnVU5Oq1CftKMrs pJzdHxYcgwDMSooMvSrOGQgCCbczz1TDpm8DMxin9XRZvhVTiFJU12MUxouJBxFH f8iZaITKAPKr849YvuDQ6AWNpLu0lttOLhF4PBR094EI9NaAKY7RX2XVrLkL4p28 qoKLulAOzLqp9WV5p0TvU/j57dB+ncg0LfsmksH4trRuXTKstSv6+eNOOnt5fKFH VYe9CGJnpPHo8CyNHAvdGzW0IFZ4Aq5CaA5w6gNsOATN8L18YgdJPcQVHXL5Jlo= =wEiu -----END PGP SIGNATURE----- --tVneAxIjaFcQxvJUdSAeLhvlmr2drBLnr-- From nobody Sat Oct 7 12:58:35 2017 Return-Path: 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 6306C134B58; Sat, 7 Oct 2017 12:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 17Bv51HgzSr3; Sat, 7 Oct 2017 12:58:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11207134B4F; Sat, 7 Oct 2017 12:58:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQB80689; Sat, 07 Oct 2017 19:58:21 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 7 Oct 2017 20:58:20 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Sat, 7 Oct 2017 12:58:12 -0700 From: Uma Chunduri To: Stephen Farrell , Padma Pillay-Esnault CC: Georgios Karagiannis , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko , "ideas@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTPUTpHf/1VBiG/k6j1YoUSQ9obKLUrfeA//+xkRCAAI/FAIAAAIUAgAAA9AD//6NuoIAAjskAgABU/1CAAXIGgIAAHMsAgAEvZgCAAKM4gP//9tQw Date: Sat, 7 Oct 2017 19:58:11 +0000 Message-ID: <25B4902B1192E84696414485F572685401A87B1F@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> <192c25a4-c841-b828-1cfe-9e9857028b42@cs.tcd.ie> In-Reply-To: <192c25a4-c841-b828-1cfe-9e9857028b42@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59D931DE.0013, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 19:58:27 -0000 CT5JZiB0aGlzIGVmZm9ydCBpcyBvbmx5IGFpbWluZyBhdCBzb21lIG5pY2hlIHdpdGhpbiB0aGUg dW5pdmVyc2Ugb2YgZGV2aWNlcyB0aGF0IGNvdWxkIGhhdmUgKGJ1dCBob3BlZnVsbHkgd29uJ3Qg aGF2ZSkgcGVybWFuZW50IGlkZW50aWZpZXJzIGtub3duIHRvIG5ldHdvcmtpbmcga2l0DQoNClF1 aWNrIHJlc3BvbnNlIHJlZ2FyZGluZyB0aGUgdGVybSBwZXJtYW5lbnQgaWRlbnRpZmllcjoNCg0K LSBUaGlzIGlzIG5vdCB0aGVyZSBpbiB0aGUgY2hhcnRlcg0KLSBUaGlzIGlzIG5vIG1vcmUgcGVy bWFuZW50IHRoYW4gYW55ICBpZGVudGl0eSB1c2VkIGZvciBhbnkgQVVUSCBtZXRob2QgdG9kYXkg KElFVEYgZGVmaW5lZCkNCi0gSWYgdGhpcyBpcyB1c2VkIGluIGFueSBvZiB0aGUgZG9jdW1lbnRz IC0gdGhpcyBpcyB0byBkaWZmZXJlbnRpYXRlIGZyb20gdGhlIHRlbXBvcmFyeSBuYXR1cmUgb2Yg dGhlIGFub255bW91cyBpZGVudGlmaWVycyAoZS5nOiBMSVNQIGFub255bW91cyBFSUQpLiBUaGVz ZSBjYW4ndCBiZSB1c2VkIGZvciBBVVRILg0KLSBUaG91Z2ggaXQncyB1cCB0byB0aGUgY29tbXVu aXR5IGRlY2lkZSB3aGljaCBBVVRIIG1ldGhvZCAtIHRoZXJlIHdhcyBhIHByZWNlZGVudCBmb3Ig dGhpcyB0ZXJtIC0gb25lICpleGFtcGxlKiBSRkMgNDE4Ny81NDQ4DQotIHdvdWxkIGJlIGhhcHB5 IHRvIHJlcGxhY2Ugd2l0aCBhbnkgb3RoZXIgdGVybSB3aGljaCBpbmRpY2F0ZXMgdGhlIGludGVu dA0KDQotLQ0KVW1hIEMuDQoNCg0K From nobody Sat Oct 7 15:54:45 2017 Return-Path: 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 BF7F61331D7; Sat, 7 Oct 2017 15:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 V7oZ0rVW0AiD; Sat, 7 Oct 2017 15:54:36 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 1FE66133052; Sat, 7 Oct 2017 15:54:36 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i124so15008087wmf.3; Sat, 07 Oct 2017 15:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6Jx+uVfelVIhefnUgUJCXOyZU728Mlq4rM+j2a0Tu50=; b=k4RJna72vbaX1fjs+g64wbVqtdcIgZWJdlE2+W9NGcTboTeghk55N7fmdVfSk62rnN CFByFaftrWOFmAL7vZeFb1UItC+nAgYGYsVD8Y/Nd1I8JcWdlMFwmtbGqrS8eHisAHMH JLZvP6oyh+I9ELAxp9iO8El8HEwc0+xZXnTd8FgX8Wy+eQmD402mUSk5vP4feQTD8avR njfsvKQ4GVJyeGaqyr4/qUCjjP9HMLLsZPlgMIeDkkYMmPg4QRRL0IzCIL/sdXO3dpUj 4KdCeKK4DKzD56MLy8iPxNx6Xba60/P7J3ep2E2zOTA0tgCukIIo0s8mVr1H3YJ0+r3K rbsw== 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=6Jx+uVfelVIhefnUgUJCXOyZU728Mlq4rM+j2a0Tu50=; b=alBFSa6EZ3w2NoBO/y8YKf2c26Sodbpl7C3nmm8NiUb++bVAzKxiMnmSJ7MExuLuq+ 8IokJFRAYBhWm5xqAcT5NCXTzCFPio6UpgI5nkam1qjLVuHoDsQmAqfKzv6JUhWC0yzL 8b1VoUNkcG41wmyvaYDgA9rjVFsg4D6sDvpAh3RJtqIDXVBUGLAo4Pk8KLTe3DOgXcRe evdAz1UQPh+gjaVjVixAkBOeQoVAIlpB7+T+chs2WVuBqk8ps6mgg2Zhl7HTk/0AmiaF T63TXV8FwjkamiHT/dHtKvwtT7pbsnaziGjc5uEG0AYnltdX/wd8hZ15lYOT1dsgInda ee1w== X-Gm-Message-State: AMCzsaVHiUHV1ru+NhT/LAYym0m4CUkTcoIJaY04PqnTnMB44yEIuNIY iXLycUF5azDZWMBGkr6vv2XMIMhccPrFlt0ZHf7jIA== X-Google-Smtp-Source: AOwi7QAMMSyCv9T517Dv+1zXdysaT5Cf+QVQRjnaqC3AOOC+mYYnZjFdsj2WDt0MBaVQrXdSDtzJ/NtaTGHgFdk1Y/M= X-Received: by 10.28.26.11 with SMTP id a11mr5458689wma.90.1507416874712; Sat, 07 Oct 2017 15:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Sat, 7 Oct 2017 15:54:33 -0700 (PDT) In-Reply-To: <192c25a4-c841-b828-1cfe-9e9857028b42@cs.tcd.ie> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> <192c25a4-c841-b828-1cfe-9e9857028b42@cs.tcd.ie> From: Padma Pillay-Esnault Date: Sat, 7 Oct 2017 15:54:33 -0700 Message-ID: To: Stephen Farrell Cc: Georgios Karagiannis , Uma Chunduri , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko , "ideas@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="001a114cbd9a58832a055afcd7c3" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 22:54:38 -0000 --001a114cbd9a58832a055afcd7c3 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 7, 2017 at 6:22 AM, Stephen Farrell wrote: > > > On 07/10/17 04:38, Padma Pillay-Esnault wrote: > > To address your concerns: no all encompassing system, or humans involved > > here. > > I'm sorry but my concerns are just not addressed. > > There are humans involved here - they're the ones carrying > the phones and whose presence triggers traffic from other > devices.And while "all encompassing" is maybe a little bit overstated, anything considering that there's a widespread > need for permanent identifiers (your IDy's) does seem to be > aiming in that direction. The charter does not mention permanent IDy. However, it is in one of the drafts which AFAIK the authors intend to refresh in a few days to clear up this specific point. I responded earlier to Jari on this specific topic wrt his feedback at the bof. It was discussed on the alias whether IDy are permanent or have a lifecycle. The consensus was that IDys are mutable and have a lifecycle. The charter specifically has this text to reflect this: - Registration and lifecycle management of identities and their associated identifiers. If this effort is only aiming at > some niche within the universe of devices that could have > (but hopefully won't have) permanent identifiers known to > networking kit, then you've not identified the niche, and > so do sorta seem to be aiming for an all-encompasing IdP. > Noted that the scope should be clarified in the charter. To address your concerns: The IDy is not permanent and the scope of the work is not aiming to be all encompassing. The consensus position should be reflected in the next revision to avoid any discrepancies. Propose that we add some text in the charter to reflect the niche/scope of the work. Padma > > S. > > --001a114cbd9a58832a055afcd7c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 7, 2017 at 6:22 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:


On 07/10/17 04:38, Padma Pillay-Esnault wrote:
> To address your concerns: no all encompassing system, or humans involv= ed
> here.

I'm sorry but my concerns are just not addressed.

There are humans involved here - they're the ones carrying
the phones and whose presence triggers traffic from other
devices.And while "all encompassing" is maybe a little bit
overstated, anything considering that there's a widespread
need for permanent identifiers (your IDy's) does seem to be
aiming in that direction.

<Padma>
The charter does not mention permanent IDy.=C2=A0 However, it is in= one of the drafts which AFAIK the authors intend to refresh in a few days = to clear up this specific point.

I responded earli= er to Jari on this specific topic wrt his feedback at the bof. It was discu= ssed on the alias whether IDy are permanent or have a lifecycle.=C2=A0 The = consensus was that IDys are mutable and have a lifecycle. =C2=A0
=
The charter specifically has this text to reflect this:
- Registration and lifecycle management of iden= tities and their associated=C2=A0identifiers.


If t= his effort is only aiming at
some niche within the universe of devices that could have
(but hopefully won't have) permanent identifiers known to
networking kit, then you've not identified the niche, and
so do sorta seem to be aiming for an all-encompasing IdP.
<= div>
Noted that the scope should be clarified in the charter.= =C2=A0

To address your concerns:
The IDy= is not permanent and the scope of the work is not aiming to be all encompa= ssing.
The consensus position should be reflected in the next rev= ision to avoid any discrepancies.

Propose that= we add some text in the charter to reflect the niche/scope of the work.

Padma
=C2=A0
=
S.


--001a114cbd9a58832a055afcd7c3-- From nobody Sat Oct 7 18:38:28 2017 Return-Path: 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 45D1F133078; Sat, 7 Oct 2017 18:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0UKeu3Ebt6VW; Sat, 7 Oct 2017 18:38:25 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 41AB613207A; Sat, 7 Oct 2017 18:38:24 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b189so14575068wmd.4; Sat, 07 Oct 2017 18:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jtpHMdeoDr3UE9Q0O5VI6i73YAK5YSJdwpBL53lZank=; b=dK06z+fYKdXfTEbrkuQldosOf45aXC6we5pqso2jpd+18QPz9Gaofmjr2H6Qiy6dRj Fk6U/ds/CiQO8mk8FCfn++FaRzJ3t27Fh2ELy8KQy87u9C0KwiIsN1tvvEcmdoJ0QSLs Eu0ydyv/L5MoxeHDRela/heGEfA7NxCyvrCUdUHIizcWt2uwbXrluiyQeWiXG/x65XaT 3g259OtJyGoeApqWpbwEID7tGZa/Zk0ISPaXLCk+fSMCy7dYFwW5Af5mc7rvRyQPzjqa ymZp8ko2U0ZkBOzhLJOQF4Ts5ECeBGTkJD/T6Hq2WXFMMSU/RR56YtkjhKAWWgR0uFgQ TIZQ== 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=jtpHMdeoDr3UE9Q0O5VI6i73YAK5YSJdwpBL53lZank=; b=dgloRm5d15lC+VaLQy8tc/8hZ5mjLRAOHdnIi+Gk8wPx083PiE1AgQqGrx0xE3b+hi 3zFb7i/JDhZCMhrUax7+wfuqSsmZBJTvib3Jnx7dVEEToY/AHipwtxIGVPyRXOf8Qv7V BODdfkTLsssJQQr0W/8oAqE+KoJQhRmCLObcr3p0+FEM3QB579i1iuGtSox6gFCLn6O1 gdBQM7MkSE5QQkdh0kaVWH9m92vXKF29hxwYWKNhFXjuGOkNPh6+1OBAHeu3VbeJLYkc 218SK91/4bpQhwspc3tAqrTvZw+r7tfa1VHjWPIt0Kafm7nxR6BlE3oA2lmKcd0Y8Yae jN2g== X-Gm-Message-State: AMCzsaXqt9XDsURhDQlCfo8lgsu7Heb+N4TVUpkUESz4IN/RLwUXiH1C q1g7TU9USWBlCWaLm5CWMxJqe9t/TprFZ8tAyBQbNA== X-Google-Smtp-Source: AOwi7QCf9e5q3RG/40VqV2sI09GrTQb3MpI9DGlXR95ACatB5qozk6fppPpCMm2/wtd4t7v4xsknSoDtcR4o8E741n8= X-Received: by 10.223.186.82 with SMTP id t18mr6062708wrg.19.1507426703323; Sat, 07 Oct 2017 18:38:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Sat, 7 Oct 2017 18:38:22 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> From: Padma Pillay-Esnault Date: Sat, 7 Oct 2017 18:38:22 -0700 Message-ID: To: S Moonesamy Cc: IETF Discussion Mailing List , ideas@ietf.org Content-Type: multipart/alternative; boundary="089e082452d02d3888055aff2150" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 01:38:27 -0000 --089e082452d02d3888055aff2150 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 7, 2017 at 4:43 PM, S Moonesamy wrote: > Hello, > At 09:13 AM 29-09-2017, 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. >> > > I took a quick look at the drafts for the proposed working group and I > came across the following: "An Identity uniquely identifies a Communication > Entity" and "To put it simply, while the IDy of a communicating entity is > obfuscated to outside observers, it is revealed to communicating parties > with a legitimate need to know. Legitimate parties include either end of > entities itself or regulatory authorities or authorized edge nodes > (routers/IDf based firewalls) in the network." > > I assume that the proposed working group will be creating an embedded > identifier so that legitimate parties can track Internet users. I don't > think that it is a good idea. > Not sure if you have been following the discussions the last few days and emails today. The charter which is under review is not trying to create an embedded identifier to track users. The draft in question is being updated and the authors are doing for clarification. Padma > Regards, > S. Moonesamy > --089e082452d02d3888055aff2150 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 7, 2017 at 4:43 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:
Hello,
At 09:13 AM 29-09-2017, The IESG wrote:
A new IETF WG has been proposed in the Routing Area. The IESG has not made<= br> any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the<= br> IESG mailing list (iesg@= ietf.org) by 2017-10-09.

I took a quick look at the drafts for the proposed working group and I came= across the following: "An Identity uniquely identifies a Communicatio= n Entity" and "To put it simply, while the IDy of a communicating= entity is obfuscated to outside observers, it is revealed to communicating= parties with a legitimate need to know.=C2=A0 Legitimate parties include e= ither end of entities itself or regulatory authorities or authorized edge n= odes (routers/IDf based firewalls) in the network."
=C2=A0
I assume that the proposed working group will be creating an embedded ident= ifier so that legitimate parties can track Internet users.=C2=A0 I don'= t think that it is a good idea.

No= t sure if you have been following the discussions the last few days and ema= ils today.=C2=A0 The charter which is under review is not trying to create = an embedded identifier to track users.=C2=A0

The d= raft in question is being updated and the authors are doing for clarificati= on.

Padma
=C2=A0
Regards,
S. Moonesamy

--089e082452d02d3888055aff2150-- From nobody Sun Oct 8 11:02:08 2017 Return-Path: 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 79C7A134880; Sun, 8 Oct 2017 11:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=VC9oCCkz; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=dI+CiB7z 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 Qgpu0q6xPi7T; Sun, 8 Oct 2017 11:02:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B890C133338; Sun, 8 Oct 2017 11:02:00 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.227.87.111]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v98I1kEn003113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Oct 2017 11:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1507485718; x=1507572118; bh=mRTGOIVdoqVp/v4qmRS4+dtbdoXKnuAlIjso7XkUDGo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VC9oCCkzXYq+kYRnXJb3mYGin+ZNafL+5on3Vb+gx6NushR7eY5Mu5+Ze2cc5b/V3 TX8QCpkD/oB7yuidgw/65MM0rIftd+jnv0auzHAQ4AM8b8JWQSbqE8Q/mEQXrPcXFK t421djl/w/deoOYk98TJBEKHhZUgtVcZXoXjeAek= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1507485718; x=1507572118; i=@elandsys.com; bh=mRTGOIVdoqVp/v4qmRS4+dtbdoXKnuAlIjso7XkUDGo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dI+CiB7z0prKrfy7KLZHfCuadFHYQssLTY9PugJMazZRA1ZM3vqFEqpUliZIUQiGw 5HOdR/nRNP3gsYIJ8aFK45/xMBLsFP8ImXCoi0V8kyT+58maA3KwjQPzYFFmKtV7z/ MImAhj0dB7ppWqEasckIUFWCQAKAEud4yk4heRLE= Message-Id: <6.2.5.6.2.20171008102541.11499408@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Oct 2017 10:55:57 -0700 To: Padma Pillay-Esnault , ietf@ietf.org From: S Moonesamy Cc: ideas@ietf.org In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 18:02:01 -0000 Hi Padma, At 06:38 PM 07-10-2017, Padma Pillay-Esnault wrote: >Not sure if you have been following the discussions the last few >days and emails today. The charter which is under review is not >trying to create an embedded identifier to track users. I caught up with the thread about this proposed working group. The (proposed) charter might say that it is not trying to create an embedded identifier to track users. What if that was a side effect of this work? I took a look at the ideas problem statement draft. I can understand that there may be a need for identification. However, it is up to the companies or 501(c)(3) status organizations to make their case for that. Will this proposed working group do any maintenance work on IPv4 technical specifications? Will the output of this proposed working group be used for future work on IPv4 technical specifications? >The draft in question is being updated and the authors are doing for >clarification. Ok. Regards, S. Moonesamy From nobody Sun Oct 8 11:20:34 2017 Return-Path: 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 51A741348C6; Sun, 8 Oct 2017 11:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 rdnkihndamCj; Sun, 8 Oct 2017 11:20:25 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 A40F21348C0; Sun, 8 Oct 2017 11:20:24 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id m72so17381072wmc.1; Sun, 08 Oct 2017 11:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MUOJKYEsNnrKWS7KfjYLhQV0Lr+4SLgZIACKr+8Ov40=; b=H76y7g+M86ai3eV8L9WEMt5JFIK+i/T+EmPo96cZ/aitjq8MjlJfgUBrvZ81V3nWVJ E7AVmDD8ebOxIAMTFVtD1N9TuaAf8YQg2FXPBZOIyrJiZrV5DCHgBEXx70qBdizbiwBI NZvj9eW/LH9qSRM1CuCh9EjIg1MmJWx1otiQIe+QuXszuvA4kbjG/LAeFD8jxp7ecBNZ dKigW0XbrnALy7+pep0aImqzMK+XWDc7dH2jZ9OVkkX6pA43893wipW9ETo3mJAM7myZ woVFUljb+w3kB4n0Oa1yGosbwKiVG5JiemfIFHxdNd85ud6VL+3xDutVKn+6ZNomZxY1 chug== 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=MUOJKYEsNnrKWS7KfjYLhQV0Lr+4SLgZIACKr+8Ov40=; b=iQa00cdPkKve8lxUurZfeF4puFJSfNpz71mEgeVsZzLttUWj74maBs0es11hCqoGHr Qn9PoG2+ewNvB9mNnbn9t9BvmC3HK+2LKB5J04ZgMY75Kw6NcfwIf8/mzAl1sNugpRTH 5wI/WUUTwJULy916yJ9h4BG6mWLtwB2icu6VFcGiSgBTS17ADX7/c+dJhAopa3o7GtTi e++ZG5cXCitSHg4rq35+CxwKdT3b/DM+OiRR/IPCbepVii8ONCUfQX5EtgVDoHuIiKTO ekxa9mg4RPr6iUmNOTd+twIN/844m7YpIc0RMs2Kos72o6URiTY1k47aJuIJU+uT/nKm yb7g== X-Gm-Message-State: AMCzsaXyKpDh4y7t8wjq/EXvGkDuQ6XhJyceDnfvBKhekz6ILQxZkgbw HXcWULop5EWIguhxR4R/HeiEoSrQIrS5OzT7Hm1jOQ== X-Google-Smtp-Source: AOwi7QAOp1613phADUbYRmuSyEm+JV0hPsU9mRGDuzkOxB7WT4jsdhthOxlm1rLNAEjTS7jpePxUhw5+gxWtO236LqU= X-Received: by 10.223.164.206 with SMTP id h14mr6774638wrb.221.1507486823054; Sun, 08 Oct 2017 11:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Sun, 8 Oct 2017 11:20:22 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20171008102541.11499408@elandnews.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> From: Padma Pillay-Esnault Date: Sun, 8 Oct 2017 11:20:22 -0700 Message-ID: To: S Moonesamy Cc: IETF Discussion Mailing List , ideas@ietf.org Content-Type: multipart/alternative; boundary="f403045f16a2978464055b0d200e" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 18:20:27 -0000 --f403045f16a2978464055b0d200e Content-Type: text/plain; charset="UTF-8" On Sun, Oct 8, 2017 at 10:55 AM, S Moonesamy wrote: > Hi Padma, > At 06:38 PM 07-10-2017, Padma Pillay-Esnault wrote: > >> Not sure if you have been following the discussions the last few days and >> emails today. The charter which is under review is not trying to create an >> embedded identifier to track users. >> > > I caught up with the thread about this proposed working group. The > (proposed) charter might say that it is not trying to create an embedded > identifier to track users. What if that was a side effect of this work? > I believe this has already been discussed on the thread. But here it is again, the id.loc protocols are in perspective here and they use ephemeral identifiers, can obsfuscate them or encrypt them as Dino pointed out earlier. There is even text in the charter regarding this. - 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. - Security analysis of the complete system, including authentication, authorization requirements and protection of any metadata. > I took a look at the ideas problem statement draft. I can understand that > there may be a need for identification. However, it is up to the companies > or 501(c)(3) status organizations to make their case for that. ?? Not sure what /how this is in context .... Are we still taking about routing information here? > > Will this proposed working group do any maintenance work on IPv4 technical > specifications? Will the output of this proposed working group be used for > future work on IPv4 technical specifications? > > Can you clarify what you mean here by maintenance work on IPv4 technical specification? Again the context here is a mapping system infrastructure to be used by Id/Loc protocols. Padma > The draft in question is being updated and the authors are doing for >> clarification. >> > > Ok. > > Regards, > S. Moonesamy > --f403045f16a2978464055b0d200e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 8, 2017 at 10:55 AM, S Moonesamy <sm+ietf@elandsys.com<= /a>> wrote:
Hi Padma,<= br> At 06:38 PM 07-10-2017, Padma Pillay-Esnault wrote:
Not sure if you have been following the discussions the last few days and e= mails today.=C2=A0 The charter which is under review is not trying to creat= e an embedded identifier to track users.

 I caught up with the thread about this proposed working group.=C2=A0 The (p= roposed) charter might say that it is not trying to create an embedded iden= tifier to track users.=C2=A0 What if that was a side effect of this work?

I believe this has already been discusse= d on the thread. But here it is again, the id.loc protocols are in perspect= ive here and they use ephemeral identifiers, can obsfuscate them or encrypt= them as Dino pointed out earlier.=C2=A0

There is = even text in the charter regarding this.

- Analysis of the concepts of i= dentity-identifier split and dynamic identifier changes, including their im= plications on anonymity and privacy. Explicitly, the framework must define = privacy requirements and how potential extensions/solutions should meet the= m.

-= Security analysis of the complete system, including authentication, author= ization requirements and protection of any metadata.



I took a look at the ideas problem statement draft.=C2=A0 I can understand = that there may be a need for identification.=C2=A0 However, it is up to the= companies or 501(c)(3) status organizations to make their case for that.

?? Not sure what /how this is in context ...= . Are we still taking about routing information here?
=C2=A0
<= /div>
=C2=A0
Will this proposed working group do any maintenance work on IPv4 technical = specifications?=C2=A0 Will the output of this proposed working group be use= d for future work on IPv4 technical specifications?<= br>
Can you clarify what you mean here by maintena= nce work on IPv4 technical specification? Again the context here is a mappi= ng system infrastructure to be used by Id/Loc protocols.

Padma
=C2=A0
The draft in question is being updated and the authors are doing for clarif= ication.

 Ok.

Regards,
S. Moonesamy=C2=A0

--f403045f16a2978464055b0d200e-- From nobody Sun Oct 8 11:34:36 2017 Return-Path: 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 CF5AE1348E9; Sun, 8 Oct 2017 11:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=AQMGiM3X; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=YMALx5nf 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 f__A4A_ffRqo; Sun, 8 Oct 2017 11:34:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D76741348E8; Sun, 8 Oct 2017 11:34:28 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.227.87.111]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v98IYD8K018137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Oct 2017 11:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1507487665; x=1507574065; bh=VcVuoaB3C2dfRMUyElSMQMZu5vZrzPBiNwm/I2cFkY0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AQMGiM3Xf+z5tkTFU6NsDYCncDGqZU+8G59edUfDX2C2gCXzS/xUrtt/CPaFJTqKw zaT++SxunVo/OOqOfK6H4CLD/XQuHy28vL8doNi5P0qvd7+XnEjUWvDGpo4L1zY9EH h49PCa3w/E0ew+Gg7MsgvySO4axy7uAvPhzModTM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1507487665; x=1507574065; i=@elandsys.com; bh=VcVuoaB3C2dfRMUyElSMQMZu5vZrzPBiNwm/I2cFkY0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YMALx5nfURyP+Er17OIj2t11QYMvYsHaQvJTge4HKv45t0Q4+rBofSq3yXIBbJ3V+ ES+/6Xr1161mE/bpqWVCiOLYYyfkfaeM5IPXM0ycYu4ucBmnn5c7lOZ9pHl2UPBUh5 F5yx6oINnUDDFEf9ogvDbzPf+ztpaoENpWdmSdlE= Message-Id: <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Oct 2017 11:33:14 -0700 To: Padma Pillay-Esnault , ietf@ietf.org From: S Moonesamy Cc: ietf@ietf.org, ideas@ietf.org In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 18:34:30 -0000 Hi Padma, At 11:20 AM 08-10-2017, Padma Pillay-Esnault wrote: >There is even text in the charter regarding this. > >- 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. Why is privacy requirements being redefined? The IAB already has a RFC about that. I have not done a search; there are probably IETF RFCs about that subject. >?? Not sure what /how this is in context .... Are we still taking >about routing information here? No. >Can you clarify what you mean here by maintenance work on IPv4 >technical specification? Again the context here is a mapping system >infrastructure to be used by Id/Loc protocols. There is currently an IETF thread about that [1]. Regards, S. Moonesamy 1. https://www.ietf.org/mail-archive/web/ietf/current/msg104717.html From nobody Sun Oct 8 11:48:06 2017 Return-Path: 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 4421B1321AC for ; Sun, 8 Oct 2017 11:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 PhrCvhPvw4Lf for ; Sun, 8 Oct 2017 11:48:03 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 C4CE51348F3 for ; Sun, 8 Oct 2017 11:47:59 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id z50so34600084qtj.4 for ; Sun, 08 Oct 2017 11:47:59 -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=iF6Auw7hK6bJDxDy4BzW+tYnh9w5T12uaPnJrwBVXIQ=; b=yBZTuy4bChgu7Ml13pRGsJWXCNdzWaUq8TrvUy2R9ZKU+ObV2uqyo8gRngEjxnJmmy 3L0uHrz6+N0TvRQ8tTatgjtCfp0wquYOf9HZRRQfTtdrRf/a+Wq3Lt+qvR91cD3oRMuK bDlXIRSTnbcyUm7PF5AUrCpQ9nr//7z6VXDR2GUWa4+lAff8+qsOVT9DxYkIn+jMF+ky 4PARxqKARRaXJtxIgHYkZpoqtSuas0efsa0pCzlrf+y3FfFdU0LAdElfGLJ1iYDjLqQm V53eVJ1Z1MyrkzYcdAXhMOt8JooA4CE01lrPyNQFLIdhLlwvrsSUHMrttVXryowD6F7t iSuw== 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=iF6Auw7hK6bJDxDy4BzW+tYnh9w5T12uaPnJrwBVXIQ=; b=DJOy2iHZXCFek2lq3s43OG/glB2UwCyKgARjhPKUM/L+DTYTUjNNP7mwG0dkxNsj5l j5BBE8hfcT5ye7jjQHQHtfiP7PA8D41MNF5jIZYT8B9Ea+jkWpQwbwerJlxSt6OR2M/D jUtAQzW0zlngpBc4x48DSk2wNNc55tQsUfkrAQPG4A2bh4h4PilvJi8gUnOSm+CbzMFf SedfuL4eqqL0Au01kQsFYYVIjpun2f8kZ+qj0sedWEg9McukLCp0VqcvZvcSSsLOwZyX jSU3ZnCu1Wfkzzr/1m5TVT5STQ8H9rN8BkXUwpWbgZDWDmDfCishsawVnwP1aOuAKCGz WQow== X-Gm-Message-State: AMCzsaXacNxdWPouDMHmTlQY3TIGehyh+dh1tFIcyS4kRe6WXQsAd7N+ +2AK80Zoou5azCVUEs/VENM4XYtplU7xrk+0UxfkpA== X-Google-Smtp-Source: AOwi7QACLS3ZJGkNSV9d/Og+ZjwbhqkM4nbIKmL0k+cCyBxfwCXaUp2LxfOldar40RF4WBh6r8DQQ2Ons2Maapd1a90= X-Received: by 10.200.43.140 with SMTP id m12mr11715049qtm.58.1507488478754; Sun, 08 Oct 2017 11:47:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Sun, 8 Oct 2017 11:47:57 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> From: Tom Herbert Date: Sun, 8 Oct 2017 11:47:57 -0700 Message-ID: To: Padma Pillay-Esnault Cc: S Moonesamy , ideas@ietf.org, IETF Discussion Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 18:48:05 -0000 On Sun, Oct 8, 2017 at 11:20 AM, Padma Pillay-Esnault wrote: > > > On Sun, Oct 8, 2017 at 10:55 AM, S Moonesamy wrote: >> >> Hi Padma, >> At 06:38 PM 07-10-2017, Padma Pillay-Esnault wrote: >>> >>> Not sure if you have been following the discussions the last few days and >>> emails today. The charter which is under review is not trying to create an >>> embedded identifier to track users. >> >> >> I caught up with the thread about this proposed working group. The >> (proposed) charter might say that it is not trying to create an embedded >> identifier to track users. What if that was a side effect of this work? > > > I believe this has already been discussed on the thread. But here it is > again, the id.loc protocols are in perspective here and they use ephemeral > identifiers, can obsfuscate them or encrypt them as Dino pointed out > earlier. > Padma, I don't think ephemeral identifiers answer the underlying concern here. Hosts can already get multiple addresses to use for obscuring their identity without needing any additional work. I think the concern is more around having a system that provides a potentially public interface that maps identifiers, even ephemeral ones, to an identity. When this is the identity of a end user device, such as a phone, this becomes a system that does maps identifier to user identities. This naturally leads to concerns about how to secure such a system and how to prevent abuse of the information that goes beyond the needs of connectivity. Both the proposed charter and the related drafts are sketchy as to how the system can be secured and who will be authorized to access the system. Tom > There is even text in the charter regarding this. > > - 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. > > - Security analysis of the complete system, including authentication, > authorization requirements and protection of any metadata. > > >> >> I took a look at the ideas problem statement draft. I can understand that >> there may be a need for identification. However, it is up to the companies >> or 501(c)(3) status organizations to make their case for that. > > > ?? Not sure what /how this is in context .... Are we still taking about > routing information here? > >> >> >> >> Will this proposed working group do any maintenance work on IPv4 technical >> specifications? Will the output of this proposed working group be used for >> future work on IPv4 technical specifications? >> > Can you clarify what you mean here by maintenance work on IPv4 technical > specification? Again the context here is a mapping system infrastructure to > be used by Id/Loc protocols. > > Padma > >>> >>> The draft in question is being updated and the authors are doing for >>> clarification. >> >> >> Ok. >> >> Regards, >> S. Moonesamy > > > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > From nobody Sun Oct 8 11:48:24 2017 Return-Path: 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 8C0901348F1; Sun, 8 Oct 2017 11:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 AQoSTBtrQszO; Sun, 8 Oct 2017 11:48:12 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 9E2CA1348F9; Sun, 8 Oct 2017 11:48:11 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m72so17473783wmc.1; Sun, 08 Oct 2017 11:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xu/RdVIXgNJgKMikOTgzsQ0GI6xUvbIK60GqfjleTQI=; b=UP4GderlErdEpHHNc30Z0seJgtEjfdoUyuwQNtnYsw708lsuCHgU77wqn+3Nw9Io9L LZWe12jbqtpaQ9GngVYMj3/RDmkY7BjIEqloaHYNRg8Lw7gUmYXLqvcR/EsHc9KLMaEi pP1+VPq55wwQNC815oCdTiz/bmW+5dvOaFs68OhPkeo8CVtBLYYWCpt1knj1+uwAau6X cBVylWM95ESj/SWFBIThbS6YuC6xIk+MdWTfC21CmTnGmImMN8w6YYuzbGw+2b6LNnIZ 2Ar3vIGrPxBPHara2ULd4rb5gnTpLIisw7SAwLOT8RyDh2lcDYMy0/lqrN8AB0CesZ/N aCsQ== 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=xu/RdVIXgNJgKMikOTgzsQ0GI6xUvbIK60GqfjleTQI=; b=SgjLWmcDYZsNNp4f7DI5E4oh/lWldeKVq4I6GJhjJmpARw1ieapMYiiTT1juYCepD2 YuYq2o8pCkqHTWP8ae5TZfvA6y5Q/HPaRvo7mXAk+d60k3d+WjoWfbl5mcOpPmsjBk39 sYx7XruioNJOfl0NLbYnzi6Lsd5P+z4OKd560NoEoXdsB1EredIhWXZOtfGyFNU9ax9o IQBBYANsjxZG8DwaBXACt8dqh+CYzXwGcIa6n/VVyPTldwbUETXWG8rj2psmQhDSCBPq Xc5TrESnEuTh4Vhu5AjE61k3wXAG4HwQlM3XhlQCzWVVFcvrmcy2FxsegEQFPMufbdft YFoQ== X-Gm-Message-State: AMCzsaUucceuQDYKFXKlMkmGkgypT+sEiZf2qaYhEN+eqFwXHI63KFO3 HnfSk4Vsn4TkjFpkRwl4Z0ysd/C8TNK+JDmWk9g= X-Google-Smtp-Source: AOwi7QBBWZo6YjrIpnxQvZZk7+0Oga/vatK7Ig3DCRMAB4H078GoTIuL3CnXjlzCEVfn4ifdJUN4qU/GYR+oBsowh4Q= X-Received: by 10.28.13.135 with SMTP id 129mr6984679wmn.24.1507488490248; Sun, 08 Oct 2017 11:48:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Sun, 8 Oct 2017 11:48:09 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> From: Padma Pillay-Esnault Date: Sun, 8 Oct 2017 11:48:09 -0700 Message-ID: To: S Moonesamy Cc: IETF Discussion Mailing List , ideas@ietf.org Content-Type: multipart/alternative; boundary="001a11443e74f6dd58055b0d838a" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 18:48:18 -0000 --001a11443e74f6dd58055b0d838a Content-Type: text/plain; charset="UTF-8" On Sun, Oct 8, 2017 at 11:33 AM, S Moonesamy wrote: > Hi Padma, > At 11:20 AM 08-10-2017, Padma Pillay-Esnault wrote: > >> There is even text in the charter regarding this. >> >> - 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. >> > > Why is privacy requirements being redefined? The IAB already has a RFC > about that. I have not done a search; there are probably IETF RFCs about > that subject. It looks like you are referring to general privacy requirements but this is not the scope/context of this work. The charter only refers to the context of the framework requirements. > > ?? Not sure what /how this is in context .... Are we still taking about >> routing information here? >> > > No. this work is in the context of routing information only. > > > Can you clarify what you mean here by maintenance work on IPv4 technical >> specification? Again the context here is a mapping system infrastructure to >> be used by Id/Loc protocols. >> > > There is currently an IETF thread about that [1]. > Regards, > S. Moonesamy > > 1. https://www.ietf.org/mail-archive/web/ietf/current/msg104717.html > No. Padma --001a11443e74f6dd58055b0d838a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Sun, Oct 8, 2017 at 11:33 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
Hi Padma,
At 11:20 AM 08-10-2017, Padma Pillay-Esnault wrote:
There is even text in the charter regarding this.

- Analysis of the concepts of identity-identifier split and dynamic identif= ier changes, including their implications on anonymity and privacy. Explici= tly, the framework must define privacy requirements and how potential exten= sions/solutions should meet them.

 Why is privacy requirements being redefined?=C2=A0 The IAB already has a RF= C about that.=C2=A0 I have not done a search; there are probably IETF RFCs = about that subject.

It looks like you are r= eferring to general privacy requirements but this is not the scope/context = of this work.

The charter only refers to the conte= xt of the framework requirements.



?? Not sure what /how this is in context .... Are we still taking about rou= ting information here?

 No.
=C2=A0
this work is in the context of routin= g information only.


Can you clarify what you mean here by maintenance work on IPv4 technical sp= ecification? Again the context here is a mapping system infrastructure to b= e used by Id/Loc protocols.

 There is currently an IETF thread about that [1].=C2=A0

Regards,
S. Moonesamy

1. https://www.ietf.org/mail-archive/web/ietf/current/msg104717.html


No.

Padma
--001a11443e74f6dd58055b0d838a-- From nobody Sun Oct 8 12:10:26 2017 Return-Path: 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 99C93134918; Sun, 8 Oct 2017 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 2O4suuGRlBb2; Sun, 8 Oct 2017 12:10:19 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 BEE72132924; Sun, 8 Oct 2017 12:10:18 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id q132so18318389wmd.2; Sun, 08 Oct 2017 12:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8LfTE6zkYGGkrI9DZetPLCNOE4QNC3X2xG0dlH+PbB4=; b=nBqYloWJPWeAxAOfvcmWyFQmUaaW0TUGBYUMucLcFchzqO0zf7zO5030R0OuMG3wVV cMS0W8HMD/A2cYZ1cIpVENhvtsU8kxrh4rfbeD+okfTWEeKxByNiuoLkxRYRTtHlDo0+ KdAF1tP0d1t02rH4V5OmlzaBMeJJ2GrmkUqvr4sgtpCrq0iunLYf7jSuEbk33nffdW7c kWHrw/ZiOXbzdCwmmmrsMOEt1VeOg/JbeDDmReAnb5eKgjKOix/IR0WJMlUNsPxqeRvS BkN0UoDVi5/Zs1vBsm0vrAiaQffkLhhGsJv1sBeSW2DHeoTYP9qHN29G7zC8Iv2Atulx u/KA== 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=8LfTE6zkYGGkrI9DZetPLCNOE4QNC3X2xG0dlH+PbB4=; b=aqZWO3CNrjs66xNh7PUPNe6G2nkORh0AVN2wZ7Cvjg1/tYXYTg3Wi5fqjC4PzAJExU xyaC/4L1uogMuEGmTXar3vWEfnb2EovsIEV7BEomp7Y2kpZufK/DvF2hsP2Si+dgcyDB aOqlfnR3BIOVgAmJPZGWEwl2RguCy6GPqiMfpqNvDtKY30d1y0HU8THsJ22EaSyI6LG/ aUOMQMHk29iDApg0W4SOTVmA+V+yeP1glbblDs35WM++m5iJ79oRAMeOT8Pgf2MveDkm YZ5uS8pVUEliJ1AcHlD4o2fM2EEP1tf9ZE5EtPTsquAKp0nzua2TyLbo5wb80EVlk9J8 goCA== X-Gm-Message-State: AMCzsaXw+lrfXQ7WRXbq9P4ytZT1FtBBEgoeyc0uhPr0A8JrcMMvpS/d vNoivWcuIcEqJP/sxRcgBZhQQZcMoKam9HkxCYHDjQ== X-Google-Smtp-Source: AOwi7QD5T/BPtHiKLOAcjDVIMmBDrYb/HbVKVQ7azJU48Tiu9sHdxkn4WS/vtQlrfu/r8BvsP6+Uo54yK1WWkY+t0BY= X-Received: by 10.28.152.5 with SMTP id a5mr6960941wme.131.1507489817180; Sun, 08 Oct 2017 12:10:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.86 with HTTP; Sun, 8 Oct 2017 12:10:16 -0700 (PDT) In-Reply-To: References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> From: Padma Pillay-Esnault Date: Sun, 8 Oct 2017 12:10:16 -0700 Message-ID: To: Tom Herbert Cc: S Moonesamy , ideas@ietf.org, IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="001a114b298c0e3d7a055b0dd391" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 19:10:21 -0000 --001a114b298c0e3d7a055b0dd391 Content-Type: text/plain; charset="UTF-8" Tom I think the concern is more around having a system that provides a > potentially public interface that maps identifiers, even ephemeral > ones, to an identity. When this is the identity of a end user device, > such as a phone, this becomes a system that does maps identifier to > user identities. This naturally leads to concerns about how to secure > such a system and how to prevent abuse of the information that goes > beyond the needs of connectivity. Both the proposed charter and the > related drafts are sketchy as to how the system can be secured and who > will be authorized to access the system. > Let's clarify again 1. IDy is NOT human identities but the "user(temporal) of an (temporal) identifier" who is authorized to update or look up identities. 2. It is not mandatory to authenticate but desirable. 3. In some cases, like in a private or closed when you need to track your devices/planes, do accounting or whatever, you should be able to do this on a need to know basis. Using the cell phone example to tie an end device to a human. Today, doesn't SIM cards tie at some level you as a subscriber to your device and do the accounting? The SIM database is not publicly accessible are they? Thanks Padma > Tom > --001a114b298c0e3d7a055b0dd391 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tom

I think the concern is more around having a system that provides a
potentially public interface that maps identifiers, even ephemeral
ones, to an identity. When this is the identity of a end user device,
such as a phone, this becomes a system that does maps identifier to
user identities. This naturally leads to concerns about how to secure
such a system and how to prevent abuse of the information that goes
beyond the needs of connectivity. Both the proposed charter and the
related drafts are sketchy as to how the system can be secured and who
will be authorized to access the system.


Let's clarify again=C2=A0

1. = IDy is NOT human identities but the "user(temporal) of an (temporal) i= dentifier" who is authorized to update or look up identities.

2. It is not mandatory to authenticate but desirable.=C2= =A0

3. In some cases, like in a private or closed = when you need to track your devices/planes, do accounting or whatever, you = should be able to do this on a need to know basis.

Using the cell phone example to tie an end device to a human. Today, doesn= 't SIM cards tie at some level you as a subscriber to your device and d= o the accounting? The SIM database is not publicly accessible are they?

Thanks
Padma


Tom
--001a114b298c0e3d7a055b0dd391-- From nobody Mon Oct 9 10:15:09 2017 Return-Path: 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 6F88F1344F0; Mon, 9 Oct 2017 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IfUGAkQP8G81; Mon, 9 Oct 2017 10:15:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE20913471B; Mon, 9 Oct 2017 10:14:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXF27456; Mon, 09 Oct 2017 17:14:26 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 18:14:24 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:14:19 -0700 From: Uma Chunduri To: S Moonesamy CC: "ideas@ietf.org" , "ietf@ietf.org" , Padma Pillay-Esnault , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLZOf7KgAESvb+AAHpWAP//jtG5gAF2ZkA= Date: Mon, 9 Oct 2017 17:14:18 +0000 Message-ID: <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> In-Reply-To: <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.247.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59DBAE83.00A0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8 Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:15:03 -0000 Hi, Some reponses in-line [Uma]: ------------ >>- Analysis of the concepts of identity-identifier split and dynamic=20 >>identifier changes, including their implications on anonymity and=20 >>privacy. Explicitly, the framework must define privacy requirements and= =20 >>how potential extensions/solutions should meet them. >Why is privacy requirements being redefined? The IAB already has a RFC a= bout that. I have not done a search; there are probably IETF RFCs about th= at subject. [Uma]: I am not sure what do you mean by "Privacy requirements redefined". = Today in mapping systems LOC information is not private, meaning anybody c= an access this information.=20 This won't work (or fatal w.r.t security) for lot of applica= tions who are seeking to use ID/LOC protocols. AUTH into the system (with mutual authentication, if we can)= can help restrict who can access the LOC information. This also entails LOC updates with encryption. These are essential for ID/LOC protocol deployments (for th= e applications described in IDEAS). Privacy requirements in the charter are mostly around these= items... =20 >>Can you clarify what you mean here by maintenance work on IPv4=20 >>technical specification? Again the context here is a mapping system=20 >>infrastructure to be used by Id/Loc protocols. >There is currently an IETF thread about that [1]. >Regards, >S. Moonesamy >1. https://www.ietf.org/mail-archive/web/ietf/current/msg104717.html=20 [Uma]: What's the relevance of the same here. IDEAS is not seeking to cha= nge any type of LOC information used in ID/LOC protocols... this is governe= d by ID/LOC protocol in use. It could be IPv4 or (mostly) IPv6. IDEAS doesn't alter or won't come into picture outside of I= D/LOC protocol context. -- Uma C. From nobody Mon Oct 9 10:38:07 2017 Return-Path: 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 A1B6813472F for ; Mon, 9 Oct 2017 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 nDF3vRcGQWhr for ; Mon, 9 Oct 2017 10:38:05 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 1653113472B for ; Mon, 9 Oct 2017 10:38:05 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n5so22059682qke.11 for ; Mon, 09 Oct 2017 10:38:05 -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=LSRLfpMSKVmMPxLCpoA4iUGF2AfRjwUK14rOE0ymkC4=; b=h2GoPojjkkVQko4juY7oq75hjHRnN4P2KqDVHQx1Fv6uUmfeo5wUv4QigULgp3mxAr X5noYXPNnOA9UGOztdDRprXEGnqH+5gPUoQMuwULYv1c6bRW7AHAne35fFmURar1SzrH B+fwRZIPtIYiGrVi7M6ko6L0TpvmawE3zrDq+Wv7TSz+QSSEofvMmgjMABWw4pqFTsvq /FMiRh02r5uwH7f9zMbc0bYchPa/CeFSD800W2Ach3so5fSVkSaeQ9nwmixtvGnPiHub 83c74s+5drZSZXkXeWJnlgPmUGdsX4FUji4z4B+X6bo12m1VxSorgcQDIjzLpld6GyjG 3EBw== 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=LSRLfpMSKVmMPxLCpoA4iUGF2AfRjwUK14rOE0ymkC4=; b=IYbd77LL7pSMLVYDNBgD98OA9YO3JuEvTtmB8DB4wlu82wiMLoKsFzgONYlt0/tHFN 3eTFYbkY47At0VnO29/+w0ObF1PbR5qAtOtzxQmr3BHBnAJtk/0wSzJtWuFqLb2yc51N Wd4V+D2pJHJEYkBwCy/gR6fIsJIYqb86V/zx5cryFWLeqPJVsZuLryMmaTwdQwekYOcQ 6K2lknPVLyjN0IReye2Cz9YIKlVbebHRWpACBD1wpV435ZGLyuEgf3dEMWjXOX9QXsOg C9pKUx7/ssWWtBS0ugSU6XwbbG2mMqf9tH9jEOPZgTG8x3bIV/QA6n0w4BcNMCu+XpNk zLpg== X-Gm-Message-State: AMCzsaXXFMWakAHgpAECFOOz8yEmIy8kU13lYOTvKyYr17R15BO/2btz IHYUT3ePNqEtpfl/LOSOziAedZ0wZkRewcodmD7Nxg== X-Google-Smtp-Source: AOwi7QDjgzfWv7FcBl6l+oJJfeJ0psp4KfzjfO3NVtCne1toKNtt/IQ/4k2nLBU+AIfHWLsDsc7lPZl31wql/WJcHWo= X-Received: by 10.55.113.67 with SMTP id m64mr9589376qkc.51.1507570684216; Mon, 09 Oct 2017 10:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Mon, 9 Oct 2017 10:38:03 -0700 (PDT) In-Reply-To: <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> From: Tom Herbert Date: Mon, 9 Oct 2017 10:38:03 -0700 Message-ID: To: Uma Chunduri Cc: S Moonesamy , "ideas@ietf.org" , "ietf@ietf.org" , Padma Pillay-Esnault Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:38:07 -0000 On Mon, Oct 9, 2017 at 10:14 AM, Uma Chunduri wrote: > Hi, > > Some reponses in-line [Uma]: > > ------------ > > >>- 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. > > >Why is privacy requirements being redefined? The IAB already has a RFC about that. I have not done a search; there are probably IETF RFCs about that subject. > > [Uma]: I am not sure what do you mean by "Privacy requirements redefined". Today in mapping systems LOC information is not private, meaning anybody can access this information. I don't believe that is true. There are many examples of deployments that have a private mapping system which is not accessible by just anyone, For instance, in multi tenant virtualization it is imperative that tenants are not able to access the mapping system-- if they were then the whole concept of virtual network isolation starts to breaks done. Mapping systems are already by protected using ACLs, authentication, network isolation, etc. Tom From nobody Mon Oct 9 10:38:55 2017 Return-Path: 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 C45BB134731 for ; Mon, 9 Oct 2017 10:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zp6X2sc9Ac17 for ; Mon, 9 Oct 2017 10:38:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DFF13470B for ; Mon, 9 Oct 2017 10:38:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF12873; Mon, 09 Oct 2017 17:38:50 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 18:38:50 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:38:47 -0700 From: Uma Chunduri To: Tom Herbert , "ideas@ietf.org" Thread-Topic: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt Thread-Index: AQHTPWoK1Z2fXPw0LEeyZ0a8im8qkKLbzLCg Date: Mon, 9 Oct 2017 17:38:47 +0000 Message-ID: <25B4902B1192E84696414485F572685401A87EB2@SJCEML701-CHM.china.huawei.com> References: <150716015159.6677.15220602314994896246.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.247.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59DBB42A.01C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6202a1057af89771528f2f12e17db8ea Archived-At: Subject: Re: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:38:55 -0000 > I've posted a draft to develop a software daemon that could control vario= us mapping systems and identifier/locator protocols. It seems you are contradicting yourself in couple of e-mails posted in IDEA= S. Not sure where you want to standardize the below "idlocd" mapping system. >From Page 9: >5 Security Considerations >Security is very important in identifier-locator mapping protocols. >Any mapping system must be protected from authorized access that >could lead to forged mapping entries or leak other data. ilocd should >therefore run only with admin privileges and software signing should >be used if idlocd were to allow dynamically loadable modules. Any >access to a mapping system should have appropriate security. For an >application to write into a mapping system its credentials must be >verified=20 [Uma]: This is what is being proposed in IDEAS - credential verification A= KA authentication. It doesn't matter if this if the ID is the one used in = data plane directly (EID) or ephemeral one.=20 The moment you authenticate (credential verification in y= our language), this can be construed is tracking the user of the ID, as it= 's been discussed now. Sure, if this is deployed in a secure and local environment= in a DC (for VM mobility), you may not needed. But your draft seems more generically applied to all ID/LOC= protocols from Section 2 (LISP, ILNP, ILA...) >and the network communications for this should be encrypted. [Uma]: Yes. -- Uma C. -----Original Message----- From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Tom Herbert Sent: Wednesday, October 04, 2017 4:39 PM To: ideas@ietf.org Subject: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.= txt Hello, I've posted a draft to develop a software daemon that could control various= mapping systems and identifier/locator protocols. I hope to have same code= to make public in near future. Tom ---------- Forwarded message ---------- From: Date: Wed, Oct 4, 2017 at 4:35 PM Subject: New Version Notification for draft-herbert-idlocd-00.txt To: Tom Herbert A new version of I-D, draft-herbert-idlocd-00.txt has been successfully sub= mitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-idlocd Revision: 00 Title: Identifier-locator control daemon Document date: 2017-10-04 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-herbert-idlocd-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-herbert-idlocd/ Htmlized: https://tools.ietf.org/html/draft-herbert-idlocd-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-idlocd-= 00 Abstract: Identifier-locator protocols rely on a mapping system that is able to map identifiers to locators. Such a mapping system is a type of key/value store. This draft proposes a design and implementation for an Identifier-Locator control daemon (idlocd). The intent is to provide an open source implementation that would be a basis for experimentation, development, and eventual deployment of identifier- locator solutions at large scale. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Ideas mailing list Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas From nobody Mon Oct 9 13:08:43 2017 Return-Path: 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 003E11342FF; Mon, 9 Oct 2017 13:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=tChyrtP4; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=kcJ6vfYi 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 Vx4W1_BGFTQt; Mon, 9 Oct 2017 13:08:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 340971342E5; Mon, 9 Oct 2017 13:08:40 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.227.87.111]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v99K8PH6018694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Oct 2017 13:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1507579716; x=1507666116; bh=pfM2E0pdxcE7NAegb8eaOaRGSV8meY40Lm6dICoobG0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tChyrtP4pZ2HZSjE20fJFKQsD1/m3iyfTG1gTRl8VIfkpp7XEYlQU9BrvDpgMIZdI DFPYj7FZfmSUtU68HjIKVbXxP78G4TG+3RgJfQgooqN9cK1e/rA+3J4GHgH05br/TP s7ZnNzHWCA+5nUxF/F+TkPZOoNvrfXqMstOJdWbQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1507579716; x=1507666116; i=@elandsys.com; bh=pfM2E0pdxcE7NAegb8eaOaRGSV8meY40Lm6dICoobG0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kcJ6vfYiZ9vT4hpcbjwgYpYV0G7GjWgSk1BkpEllytx+gf49K/fzMux6iRbQf/2aB 43heZV5gLGmilAMuV64iTi7a6ngCq4cydL1H8JK/tyrqH4karjXvbeiPa/V3UdKLzY XhBz5iZyZALR3q+EJNQ6lF0i1jK7oQafRsW3evIk= Message-Id: <6.2.5.6.2.20171009124208.0f3a8ed8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Oct 2017 13:08:02 -0700 To: Uma Chunduri From: S Moonesamy Cc: ideas@ietf.org, ietf@ietf.org In-Reply-To: <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.chi na.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 20:08:41 -0000 Hi Uma, At 10:14 AM 09-10-2017, Uma Chunduri wrote: >[Uma]: I am not sure what do you mean by "Privacy requirements >redefined". Today in I was commenting on the text from the proposed charter. There are one or more RFCs which discusses about privacy. >[Uma]: What's the relevance of the same here. IDEAS is not seeking >to change any type of LOC information used in ID/LOC protocols... >this is governed by ID/LOC protocol in use. It could be IPv4 or (mostly) IPv6. > IDEAS doesn't alter or won't come into > picture outside of ID/LOC protocol context. If the IETF were to decide that it will stop doing IPv4 work except for maintenance, should the working group be allowed to add in support for IPv4? Regards, S. Moonesamy From nobody Mon Oct 9 14:15:05 2017 Return-Path: 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 C0BFD134218; Mon, 9 Oct 2017 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JFIK1sQvbTNG; Mon, 9 Oct 2017 14:15:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C74132D51; Mon, 9 Oct 2017 14:15:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF32139; Mon, 09 Oct 2017 21:15:00 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 22:14:59 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 14:14:48 -0700 From: Alexander Clemm To: Tom Herbert , Uma Chunduri CC: "ideas@ietf.org" , Padma Pillay-Esnault , S Moonesamy , "ietf@ietf.org" Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) Thread-Index: AQHTOT4HtvaRdsDDgEqucGYSnlXKNaLZOf32gAESvhGAAHpWAP//jtH5gAHxDwCAAAaigP//wyFw Date: Mon, 9 Oct 2017 21:14:48 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com> References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59DBE6D4.01CD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 21:15:05 -0000 >=20 > I don't believe that is true. There are many examples of deployments that > have a private mapping system which is not accessible by just anyone, For > instance, in multi tenant virtualization it is imperative that tenants ar= e not > able to access the mapping system-- if they were then the whole concept o= f > virtual network isolation starts to breaks done. Mapping systems are alre= ady > by protected using ACLs, authentication, network isolation, etc. >=20 > Tom >=20 I thought one concern raised here wasn't that the information couldn't be s= ecured, but that the owner or operator of the mapping system could collude = with dark forces to turn its information against you, in which case all bet= s are off.=20 Assuming for a moment that we have an operator who does not collude with da= rk forces and does want to secure access to the mapping system and informat= ion, one question concerns how the access is controlled - just to the mappi= ng system as a whole, or at the level of individual records. Is this level= of differentiation provided (which can be important if I want to protect e= .g. my locator information from some, but not all users)?=20 --- Alex From nobody Tue Oct 10 08:55:52 2017 Return-Path: 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 043EA1351C9; Tue, 10 Oct 2017 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2rYNTWoMs_9K; Tue, 10 Oct 2017 08:55:49 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 A52AA135074; Tue, 10 Oct 2017 08:42:53 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id k31so17150207qta.6; Tue, 10 Oct 2017 08:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=VeKJWwehnTYsHzRy5Y/4ZlLFMs21K8O3ZO7hv+dF0xY=; b=PlLgF6uD1428baeyj93yGNT78gt2ObJdqRxz568mVX2TuIc8LkGiOOTCYS0nqst4u7 E071QcoRK4NkVKwexj0c1FJDr2+wqv4AenN4NYMowpPtbY5IRk3C29lkaOCeqK5q0ws6 se5H0XQtEkuxsNRO7/vAj0qv3I/itv8LRPojU/7+/wKQt4gq3nG9d5qnDUPjN1hKqjgZ EzX1uVowVHOGLBScCGXccoBMGGtBwpomiqAwBH53bKt6WxCrnvTjkKJbbEGgANTrPFA+ j1nQh8jLMZbbq56WN8VuN4zq12W8NrvxhV21IbjzCEWizfShdKYx8LZqu76Jjsa+/d7o PRTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=VeKJWwehnTYsHzRy5Y/4ZlLFMs21K8O3ZO7hv+dF0xY=; b=LLJPMz8a2G+61iINl4+8738r1P0sYYNvqCCAEnU48x7RmabRl5io8Y1xhiZWmbQIue U+axRhWxZ2biGvaRth5MjDEsSualNE2fK5500no9oTwANyAhCUC6M9zun0BfX3JEryf2 8HXRnR7nkwuBvqqw0NdKf2WOs/FGRgpPutrJTHRqJGP2gU4SuH19AX1l/E6AKmEguC6w s0Krq2DKPYt0nHG/xFr1W92FKjXp4Z7E/dyXIQaI0VqKPiHcpAVBVVe7MtV+P6Z08V8+ oZVIiBupjNjbRXACvyyVN/dDPFT2MsdjnN9hJiUtKBrU+9XMnDX/wkkbv5TfFile+ds0 bGLw== X-Gm-Message-State: AMCzsaWC81U/2u1YdZMgYruLtJOP5LW63fq+rH2C84cnU7dvQ8FN+0td osXYpA/8lAYh7ipplzuoOSO+Ug== X-Google-Smtp-Source: AOwi7QBH/gidfQYy/QWi+ydbOeHL4hbWn6Y/vjctynSEXFV/b4ro4+HPGEClB0YkuKw5LeYCNhnb+A== X-Received: by 10.37.58.134 with SMTP id h128mr2366291yba.267.1507650172653; Tue, 10 Oct 2017 08:42:52 -0700 (PDT) Received: from [192.168.1.144] (cpe-65-190-24-92.nc.res.rr.com. [65.190.24.92]) by smtp.gmail.com with ESMTPSA id s65sm4758742ywd.15.2017.10.10.08.42.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Oct 2017 08:42:52 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 10 Oct 2017 11:42:50 -0400 From: Alvaro Retana To: "ietf@ietf.org" CC: "ideas@ietf.org" Message-ID: Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas) References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:55:51 -0000 [Apologies for not chiming in before. [*]] I=E2=80=99ve been reading this thread and discussing with others in the IAB/IESG.= Thank you for all the comments and opinions! The concerns about privacy/anonymity and the potential results (tracking, c= ensorship, etc.) are clear. It is a serious topic and I wouldn=E2=80=99t have exp= ected less. I can also see that clarifications about the intention or assur= ances about what the (proposed) WG should produce/focus on haven=E2=80=99t been en= ough to reduce the criticism of both the charter and the existing (individua= l) work. At this point in the process, and without trying to run the WG or rewrite t= he documents on this thread, all I can offer is charter text. My expectatio= n is for the support documents (i.e. the individual drafts that have been wr= itten so far) to be discussed and consensus reached on them =E2=80=93 vs assuming = that they are a foregone conclusion. I think that the number of use cases r= equire that formal discussion anyway. Whatever the result of the chartering= effort is, I hope that interested people will join the mailing list and con= tribute with the same enthusiasm. To me, the widening of the audience has b= een as important as the discussion itself. Right after I send this e-mail I will be opening the ballot [1] for this we= ek=E2=80=99s IESG Telechat discussion of this (proposed) WG. I will be balloting = =E2=80=9CYes=E2=80=9D because I think that the discussion could be taken further in the = context of a WG (hopefully with additional security/privacy expertise). I k= now that the charter text is not perfect, and realize that I may be in the r= ough anyway. Thanks! Alvaro. [1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/ =20 [*] I=E2=80=99m in the process of changing jobs, took a couple of (I would strong= ly argue, well-deserved) days off in between, e-mail went missing, changed e= -mail systems 3 times=E2=80=A6 Definitely not the best timing. :-( =20 From nobody Tue Oct 10 08:59:35 2017 Return-Path: X-Original-To: ideas@ietf.org Delivered-To: ideas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7654F134E61; Tue, 10 Oct 2017 08:59:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: ideas-chairs@ietf.org, ideas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150765116844.13583.13674296294314167759.idtracker@ietfa.amsl.com> Date: Tue, 10 Oct 2017 08:59:28 -0700 Archived-At: Subject: [Ideas] Alvaro Retana's Yes on charter-ietf-ideas-00-06: (with COMMENT) X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:59:28 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-ideas-00-06: Yes 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ideas/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- https://mailarchive.ietf.org/arch/msg/ideas/Rj4P1Qz5_Af5qQ6XONaX-u_kgCU From nobody Tue Oct 10 09:25:14 2017 Return-Path: X-Original-To: ideas@ietf.org Delivered-To: ideas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB99B1345E4; Tue, 10 Oct 2017 09:25:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150765270772.13511.6510075730975367892.idtracker@ietfa.amsl.com> Date: Tue, 10 Oct 2017 09:25:07 -0700 Archived-At: Subject: [Ideas] Kathleen Moriarty's Block on charter-ietf-ideas-00-06: (with BLOCK) X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 16:25:08 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-ideas-00-06: Block 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ideas/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I think there should be another BoF to discuss the privacy aspects and let the community have a chance to voice opinions and fully hash this out. I suspect we'll see appeals (rightfully so) if that does not happen. From nobody Tue Oct 10 12:18:13 2017 Return-Path: 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 07BB21346CB; Tue, 10 Oct 2017 12:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 B3BK7Ot8osGx; Tue, 10 Oct 2017 12:18:08 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22E91346E0; Tue, 10 Oct 2017 12:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A8C43621C2; Tue, 10 Oct 2017 15:15:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zjo5HFuehv8x; Tue, 10 Oct 2017 15:15:36 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 68960621BB; Tue, 10 Oct 2017 15:15:35 -0400 (EDT) To: Kathleen Moriarty , The IESG Cc: ideas@ietf.org, ideas-chairs@ietf.org, aretana.ietf@gmail.com References: <150765270772.13511.6510075730975367892.idtracker@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <0ed178fa-f683-e0a4-e47c-a58ec2d0bc89@htt-consult.com> Date: Tue, 10 Oct 2017 15:15:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150765270772.13511.6510075730975367892.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Ideas] Kathleen Moriarty's Block on charter-ietf-ideas-00-06: (with BLOCK) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 19:18:11 -0000 I am and have been on Jewish Holidays since Sept 20th and it continues until Oct 16th. But there is some time between all of the actual Holidays to see how far I have fallen behind. First: I have a contract with Huawei to work on IDEAS and I believe I have a track record of concern for and methods of addressing privacy. I plan on doing my best not to allow this item to slip even for ID/Loc technologies that are not fundimentally security based. With my work on HIP, this whole area is one I have spent a lot of cycles thinking about and how I would tackle it if people would pay me to work on it (see start of this para). Second: Privacy is in the charter. You want more privacy, work on the documents. Third: I am in private conversations with companies that want me to help develop point solutions that IDEAS is addressing in the broad. Only one of which is really paying attention to privacy and security. This will happen, piecemeal, if the IETF does not get out in front of the wave. Another 4 month delay is not good. One of the projects is in final funding efforts. And I think I am seeing only a piece of what companies are out there trying to invent. Fourth: Privacy concerns are in the charter. I have a number of IDEAS (pun intented) on how to build up a strong privacy model and still have expectation that it will be deployed. Finally, I am just one person, and can be run over by an IETF bus. It has happened before. I got ran over by the CANbus 25 years ago... Bob On 10/10/2017 12:25 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > charter-ietf-ideas-00-06: Block > > 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-ideas/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I think there should be another BoF to discuss the privacy aspects and let the > community have a chance to voice opinions and fully hash this out. I suspect > we'll see appeals (rightfully so) if that does not happen. > > > > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Tue Oct 10 12:35:58 2017 Return-Path: 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 5B44A134210; Tue, 10 Oct 2017 12:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jhSPsJPvXRMK; Tue, 10 Oct 2017 12:35:54 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B883013307B; Tue, 10 Oct 2017 12:35:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0B114621A2; Tue, 10 Oct 2017 15:35:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q+zaSjb4tkIT; Tue, 10 Oct 2017 15:35:39 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 29D0462163; Tue, 10 Oct 2017 15:35:35 -0400 (EDT) To: Stephen Farrell , ietf@ietf.org Cc: ideas@ietf.org References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> From: Robert Moskowitz Message-ID: Date: Tue, 10 Oct 2017 15:35:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------5B064D69EBFA925BA1060558" Content-Language: en-US Archived-At: Subject: Re: [Ideas] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 19:35:57 -0000 This is a multi-part message in MIME format. --------------5B064D69EBFA925BA1060558 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Stephen, and others... I am on Jewish Holidays since Sept 20th and I will finally be past them on Oct 16th. I do have some time between the actual Holidays to see how far I have fallen behind. That said, I will attempt to address a couple concerns here on the IETF list for the broader audience. I am also concerned that some ID/Loc technologies seem to allow for PII to be enshrined in ID. I have always been against that. I have always seen a strictly one-way mapping that could take a human PII and find a ID for that. Phone number lookup technologies based on LDAP have always supplied this. Nothing new here, if done right. Human PII based ID should not be encouraged in this work, but is more the feature of an underlying ID/Loc technology (note, HIP does NOT do this). Thus this is out of scope of IDEAS. And, as I am funded to work on IDEAS, I will vigorously work against anything that expands what we already have (and maybe get this out of in ID/Loc tech that has it). This is about machines, and processes, have ID/Loc through some underlying technology (e.g. HIP, ILA, LISP) to have a common ID discovery and Loc back to ID (for things like HTTP redirects). As the charter says, strong access control will be designed in (but of course no assurance of implementing). Note that HIP has a course access control in its RVS service in that an RVS COULD ignore a redirect from an Initiator nore registered to the RVS. But we need finer grain access control and, well it is in the charter. Why do this? ID/Loc has a number of use cases, but is limited by the lack of discovery services (well, HIP can use DNS) and reverse discovery (but this is from Loc to get ID and only if authorized). We feel that adding in what we have learned limits ID/Loc will broaden its use. Bob On 09/29/2017 02:31 PM, Stephen Farrell wrote: > As currently described, I oppose creation of this working > group on the basis that it enables and seemingly encourages > embedding identifiers for humans as addresses. Doing so > would have significant privacy downsides, would enable > new methods for censorship and discrimination, and could > be very hard to mitigate should one wish to help protect > people's privacy, as I think is current IETF policy. > > If the work precluded the use of any identifiers that > strongly map to humans then I'd be ok with it being done > as it'd then only be a waste of resources. But I don't > know how that could be enforced so I think it'd be better > to just not do this work at all. > > S. > > On 29/09/17 17:13, 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. >> >> IDentity Enabled Networks (ideas) >> ----------------------------------------------------------------------- >> Current status: Proposed WG >> >> Chairs: >> Padma Pillay-Esnault >> >> Assigned Area Director: >> Alvaro Retana >> >> Routing Area Directors: >> Alia Atlas >> Alvaro Retana >> Deborah Brungard >> >> Mailing list: >> Address: ideas@ietf.org >> To subscribe: https://www.ietf.org/mailman/listinfo/ideas >> Archive: https://mailarchive.ietf.org/arch/browse/ideas/ >> >> Group page: https://datatracker.ietf.org/group/ideas/ >> >> Charter: https://datatracker.ietf.org/doc/charter-ietf-ideas/ >> >> 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. >> Identifier-locator separation protocols require infrastructure that allows >> nodes to discover the network topological location(s) of its peer(s) for >> packet delivery. A common infrastructure and protocol could be used by >> identifier/locator protocols as well as network virtualization. However, >> additional infrastructure and new protocol extensions are needed to address >> new requirements that go well beyond the traditional discovery service and >> mapping of identifier-to-location for packet delivery. Identifier-locator >> protocols are also useful for additional services involving dynamic >> association of a name to a set of network addresses - these include dynamic >> multicast, cloud service anycast and context-aware IoT queries. >> >> The IDEAS WG is chartered to produce a framework document that defines the >> expected behavior of a mapping system across the multiple existing use cases. >> The framework will aim at a homogeneous behavior across use cases, and it >> will call out specific trade-offs that may be considered in the development >> of solutions. We refer to the framework providing the set of services as >> Generic Identity Services (GRIDS). >> >> Some of the areas that must be considered when developing the framework >> include: >> >> - Description of interfaces for different protocols to interact with the >> framework (e.g. id-loc split protocols, management protocols, etc) >> >> - Description of identifier/locator mapping resolution and mapping update >> (e.g. discovery, pub/sub, multi-homing, ...) >> >> - Registration and lifecycle management of identities and their associated >> identifiers. >> >> - Identity authentication and authorization (e.g. access to framework, update >> of information for identifiers..) >> >> - Description of required basic network policies and policy enforcement needs >> (e.g. ability to look up an identifier-locator pair, permit forwarding >> traffic for particular endpoints on a per-identity basis, etc.) >> >> - 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. >> >> - Security analysis of the complete system, including authentication, >> authorization requirements and protection of any metadata. >> >> - Operational and deployment considerations >> >> The IDEAS WG will closely coordinate with the LISP and HIP WGs (and with >> others as needed) in order to keep them well-informed of the progress. Any >> extension to existing protocols that is identified while developing the >> framework document will be carried out in the responsible WG for that >> protocol; any extension work to be done in this WG will require re-chartering. >> >> WG deliverables include: >> >> (1) Generic Identity Services Framework >> >> (2) Other WG sustaining/informational documents may include: >> >> - Problem statement >> - Use cases >> - Requirements for identifier/locator mapping and resolution >> - Requirements for identity authentication and authorization service (for >> GRIDS) - Applications of the architecture for use cases - Threat model >> document >> >> These documents will not be published as RFCs, but will be maintained in a >> draft form or on a collaborative Working Group wiki to support the efforts of >> the Working Group and help new comers. >> >> Milestones >> >> January 2018 Adopt WG draft for the Generic Identity Services framework >> July 2018 WGLC for the Generic Identity Services framework >> September 2018 Send Generic Identity Services framework draft to the IESG >> November 2018 Recharter or Close >> >> >> > > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas --------------5B064D69EBFA925BA1060558 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Stephen, and others...

I am on Jewish Holidays since Sept 20th and I will finally be past them on Oct 16th.  I do have some time between the actual Holidays to see how far I have fallen behind.  That said, I will attempt to address a couple concerns here on the IETF list for the broader audience.

I am also concerned that some ID/Loc technologies seem to allow for PII to be enshrined in ID.  I have always been against that.  I have always seen a strictly one-way mapping that could take a human PII and find a ID for that.  Phone number lookup technologies based on LDAP have always supplied this.  Nothing new here, if done right.  Human PII based ID should not be encouraged in this work, but is more the feature of an underlying ID/Loc technology (note, HIP does NOT do this).

Thus this is out of scope of IDEAS.  And, as I am funded to work on IDEAS, I will vigorously work against anything that expands what we already have (and maybe get this out of in ID/Loc tech that has it).

This is about machines, and processes, have ID/Loc through some underlying technology (e.g. HIP, ILA, LISP) to have a common ID discovery and Loc back to ID (for things like HTTP redirects).  As the charter says, strong access control will be designed in (but of course no assurance of implementing).  Note that HIP has a course access control in its RVS service in that an RVS COULD ignore a redirect from an Initiator nore registered to the RVS.  But we need finer grain access control and, well it is in the charter.

Why do this?  ID/Loc has a number of use cases, but is limited by the lack of discovery services (well, HIP can use DNS) and reverse discovery (but this is from Loc to get ID and only if authorized).  We feel that adding in what we have learned limits ID/Loc will broaden its use.

Bob

On 09/29/2017 02:31 PM, Stephen Farrell wrote:
As currently described, I oppose creation of this working
group on the basis that it enables and seemingly encourages
embedding identifiers for humans as addresses. Doing so
would have significant privacy downsides, would enable
new methods for censorship and discrimination, and could
be very hard to mitigate should one wish to help protect
people's privacy, as I think is current IETF policy.

If the work precluded the use of any identifiers that
strongly map to humans then I'd be ok with it being done
as it'd then only be a waste of resources. But I don't
know how that could be enforced so I think it'd be better
to just not do this work at all.

S.

On 29/09/17 17:13, 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.

IDentity Enabled Networks (ideas)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Padma Pillay-Esnault <padma.ietf@gmail.com>

Assigned Area Director:
  Alvaro Retana <aretana@cisco.com>

Routing Area Directors:
  Alia Atlas <akatlas@gmail.com>
  Alvaro Retana <aretana@cisco.com>
  Deborah Brungard <db3546@att.com>

Mailing list:
  Address: ideas@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/ideas
  Archive: https://mailarchive.ietf.org/arch/browse/ideas/

Group page: https://datatracker.ietf.org/group/ideas/

Charter: https://datatracker.ietf.org/doc/charter-ietf-ideas/

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.
Identifier-locator separation protocols require infrastructure that allows
nodes to discover the network topological location(s) of its peer(s) for
packet delivery. A common infrastructure and protocol could be used by
identifier/locator protocols as well as network virtualization. However,
additional infrastructure and new protocol extensions are needed to address
new requirements that go well beyond the traditional discovery service and
mapping of identifier-to-location for packet delivery. Identifier-locator
protocols are also useful for additional services involving dynamic
association of a name to a set of network addresses - these include dynamic
multicast, cloud service anycast and context-aware IoT queries.

The IDEAS WG is chartered to produce a framework document that defines the
expected behavior of a mapping system across the multiple existing use cases.
 The framework will aim at a homogeneous behavior across use cases, and it
will call out specific trade-offs that may be considered in the development
of solutions.  We refer to the framework providing the set of services as
Generic Identity Services (GRIDS).

Some of the areas that must be considered when developing the framework
include:

- Description of interfaces for different protocols to interact with the
framework (e.g. id-loc split protocols, management protocols, etc)

- Description of identifier/locator mapping resolution and mapping update
(e.g. discovery, pub/sub, multi-homing, ...)

- Registration and lifecycle management of identities and their associated
identifiers.

- Identity authentication and authorization (e.g. access to framework, update
of information for identifiers..)

- Description of required basic network policies and policy enforcement needs
(e.g. ability to look up an identifier-locator pair, permit forwarding
traffic for particular endpoints on a per-identity basis, etc.)

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

- Security analysis of the complete system, including authentication,
authorization requirements and protection of any metadata.

- Operational and deployment considerations

The IDEAS WG will closely coordinate with the LISP and HIP WGs (and with
others as needed) in order to keep them well-informed of the progress.  Any
extension to existing protocols that is identified while developing the
framework document will be carried out in the responsible WG for that
protocol; any extension work to be done in this WG will require re-chartering.

WG deliverables include:

(1) Generic Identity Services Framework

(2) Other WG sustaining/informational documents may include:

- Problem statement
- Use cases
- Requirements for identifier/locator mapping and resolution
- Requirements for identity authentication and authorization service (for
GRIDS) - Applications of the architecture for use cases - Threat model
document

These documents will not be published as RFCs, but will be maintained in a
draft form or on a collaborative Working Group wiki to support the efforts of
the Working Group and help new comers.

Milestones

January 2018 Adopt WG draft for the Generic Identity Services framework
July 2018 WGLC for the Generic Identity Services framework
September 2018 Send Generic Identity Services framework draft to the IESG
November 2018 Recharter or Close





      

      

      

      
_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


    

    

  


--------------5B064D69EBFA925BA1060558--


From nobody Tue Oct 10 12:56:50 2017
Return-Path: 
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 E7633132E24; Tue, 10 Oct 2017 12:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 a6A0zC5pfg-h; Tue, 10 Oct 2017 12:56:42 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 AA7201286C7; Tue, 10 Oct 2017 12:56:42 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id b79so6057618pfk.5; Tue, 10 Oct 2017 12:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jiikU+2ytEurwxkanntq7iWyP40sIsV7fP/gUY6sCP0=; b=HiXe8zLX0P8B2Q5N9qpf5L/jiw+C2+9/dltCgLeGHNEcRtVczOT6+a3DEGERH342s3 4OQ8HiVTYFGyP1Z791g2wjSa5fAmMrXUd7hQuXM3S9lMT8V7iFCgLuBbx4zmbX9ISAmH QS4vQb24pIuNb40qJN3OMfjaxGJoSuc5q3ArwTv/HxDL5JGz017RwVPZftZeLmdGfzZW X4XwNGExE8IqefGq2SKuGx5o63v1TGf7YV+ixjWS/xU7EfV1nD/JDQpbLLtFy+6SaOx+ YuV838vt2u/gmeYD6wko5SgzgxqAlLqwV53rqTQbcREZkj1KZ9wCoLCAIy8D6/wT58rg MVbQ==
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=jiikU+2ytEurwxkanntq7iWyP40sIsV7fP/gUY6sCP0=; b=MV5xi8KLw9QElmvoSfmNE/U9lvxbMicq+RNF/cYEv/6MTffdrMAsWSBScVZq8FdCZn Xt13+rjNnI+SA5ZKpwyDAqOsD4Sd82PIHop6Pf7D7GBY8+qbosrPR58eAZ3KD3qWrb8c S7fONi9AKoHA8eeoaTr90c7YsRCpCVsogDKnqbz+2d1AKfngRjd9gPVYZhc+8IEzssF1 9+86FUtDu8DpI25rm89ROqSmZ2C4Zu8H//dEiWkI3ygs5hynd/Ggz6UIbDhSm0Zzx56H rn6TFkv4ppxKc+5uUJFTC8XiibWJm/OI2pzfsHUvRImozMzQSitKQFo/aSLNYdgapfpR DD3g==
X-Gm-Message-State: AMCzsaVq3iUU9LpbmKhl2sViiehS3CjwlUH663dn7XqBZ+lM6KhwZmZa sva+hb3T+XZuuSk9QJGd83LHx9JrN1VN23/qn9U=
X-Google-Smtp-Source: AOwi7QC6MNPUWufb5UTXazlyZteRlp7zQdVOL9HJn1qgFuwrlyy+SrIjJoTd215iB3szUsRP+V6kEs67F/auQLxxlJk=
X-Received: by 10.84.211.144 with SMTP id c16mr13415680pli.233.1507665402181;  Tue, 10 Oct 2017 12:56:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.194 with HTTP; Tue, 10 Oct 2017 12:56:01 -0700 (PDT)
In-Reply-To: <0ed178fa-f683-e0a4-e47c-a58ec2d0bc89@htt-consult.com>
References: <150765270772.13511.6510075730975367892.idtracker@ietfa.amsl.com> <0ed178fa-f683-e0a4-e47c-a58ec2d0bc89@htt-consult.com>
From: Kathleen Moriarty 
Date: Tue, 10 Oct 2017 15:56:01 -0400
Message-ID: 
To: Robert Moskowitz 
Cc: The IESG , ideas@ietf.org, ideas-chairs@ietf.org,  aretana.ietf@gmail.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Ideas] Kathleen Moriarty's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Oct 2017 19:56:45 -0000

Hi Bob,

I think it's really important to have the community hash this out in a
formal BoF.  If that does not happen, I'd bet the work will get held
up in appeal cycles.  I don't think the community is ready to have
this work go forward in it current state.  Lots of work has gone into
preventing tracking at other layers and that work is important.

Best,
Kathleen

On Tue, Oct 10, 2017 at 3:15 PM, Robert Moskowitz
 wrote:
> I am and have been on Jewish Holidays since Sept 20th and it continues until
> Oct 16th.  But there is some time between all of the actual Holidays to see
> how far I have fallen behind.
>
> First:  I have a contract with Huawei to work on IDEAS and I believe I have
> a track record of concern for and methods of addressing privacy.  I plan on
> doing my best not to allow this item to slip even for ID/Loc technologies
> that are not fundimentally security based.  With my work on HIP, this whole
> area is one I have spent a lot of cycles thinking about and how I would
> tackle it if people would pay me to work on it (see start of this para).
>
> Second:  Privacy is in the charter.  You want more privacy, work on the
> documents.
>
> Third:  I am in private conversations with companies that want me to help
> develop point solutions that IDEAS is addressing in the broad. Only one of
> which is really paying attention to privacy and security.  This will happen,
> piecemeal, if the IETF does not get out in front of the wave.  Another 4
> month delay is not good.  One of the projects is in final funding efforts.
> And I think I am seeing only a piece of what companies are out there trying
> to invent.
>
> Fourth: Privacy concerns are in the charter.  I have a number of IDEAS (pun
> intented) on how to build up a strong privacy model and still have
> expectation that it will be deployed.
>
> Finally, I am just one person, and can be run over by an IETF bus. It has
> happened before.  I got ran over by the CANbus 25 years ago...
>
> Bob
>
>
> On 10/10/2017 12:25 PM, Kathleen Moriarty wrote:
>>
>> Kathleen Moriarty has entered the following ballot position for
>> charter-ietf-ideas-00-06: Block
>>
>> 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.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-ideas/
>>
>>
>>
>> ----------------------------------------------------------------------
>> BLOCK:
>> ----------------------------------------------------------------------
>>
>> I think there should be another BoF to discuss the privacy aspects and let
>> the
>> community have a chance to voice opinions and fully hash this out.  I
>> suspect
>> we'll see appeals (rightfully so) if that does not happen.
>>
>>
>>
>>
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
>
>



-- 

Best regards,
Kathleen


From nobody Tue Oct 10 13:24:23 2017
Return-Path: 
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 E3F8A1342F6; Tue, 10 Oct 2017 13:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 DMxVUYlALi-s; Tue, 10 Oct 2017 13:24:00 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F201B1342F2; Tue, 10 Oct 2017 13:23:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88654BE5B; Tue, 10 Oct 2017 21:23:57 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgqo_GmMYR0C; Tue, 10 Oct 2017 21:23:52 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80CF4BE56; Tue, 10 Oct 2017 21:23:52 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507667032; bh=98zgoMjn5PicbyKYPdFD7+HF3dPCbiWyFI6KQTggAxU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zUPBA61WZPLOjRV6AyEWC4owq4cKyUn1VUoxsbYVgpXWm40bAp+NIy9sYx5jdbaXx B97of6wJdvzFjl7HYwiswuvJq6jSc0YVF1M0v1/5dnshFiLGx0JjUwL5hNJ8mwuBWv N1MihwoNQlQKKAIt+73jwGVw5UlUFmaQ+Z5gDang=
To: Robert Moskowitz , ietf@ietf.org
Cc: ideas@ietf.org
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Tue, 10 Oct 2017 21:23:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dx2Sb595Hahsvoe28IBbVLr9fG75tJvUn"
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Oct 2017 20:24:05 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Dx2Sb595Hahsvoe28IBbVLr9fG75tJvUn
Content-Type: multipart/mixed; boundary="nlaUB0apHUnxoPsO3D7W6o1vKhaXdJR1p";
 protected-headers="v1"
From: Stephen Farrell 
To: Robert Moskowitz , ietf@ietf.org
Cc: ideas@ietf.org
Message-ID: 
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com>
 <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>
 
In-Reply-To: 

--nlaUB0apHUnxoPsO3D7W6o1vKhaXdJR1p
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hi Bob,

On 10/10/17 20:35, Robert Moskowitz wrote:
> Stephen, and others...
>=20
> I am on Jewish Holidays since Sept 20th and I will finally be past them=

> on Oct 16th.=C2=A0 I do have some time between the actual Holidays to s=
ee how
> far I have fallen behind.=C2=A0 That said, I will attempt to address a =
couple
> concerns here on the IETF list for the broader audience.
>=20
> I am also concerned that some ID/Loc technologies seem to allow for PII=

> to be enshrined in ID.=C2=A0=20

"Enshrined in" isn't that clear to me (but I did say
"embedding" below which is just as bad:-). As we know,
long-lived identifiers that correlate with people can
be enough to cause problems, e.g. IMEIs and MS-ISDNs,
if exposed to other parts of the network.

> I have always been against that.=C2=A0 I have always
> seen a strictly one-way mapping that could take a human PII and find a
> ID for that.=C2=A0 Phone number lookup technologies based on LDAP have =
always
> supplied this.=C2=A0 Nothing new here, if done right. Human PII based I=
D
> should not be encouraged in this work, but is more the feature of an
> underlying ID/Loc technology (note, HIP does NOT do this).
>=20
> Thus this is out of scope of IDEAS.=C2=A0=20

I don't follow how the last statement follows from the
preceeding paragraph. I also saw nothing in the charter
or the use-cases draft or in the list archive to back
up that conclusion.

> And, as I am funded to work on
> IDEAS, I will vigorously work against anything that expands what we
> already have (and maybe get this out of in ID/Loc tech that has it).

Sure.

>=20
> This is about machines, and processes, have ID/Loc through some
> underlying technology (e.g. HIP, ILA, LISP) to have a common ID
> discovery and Loc back to ID (for things like HTTP redirects).=C2=A0=20

If that's the case, then there appears to be serious confusion
in the use-cases draft at least. And "identity" seems a fairly
mad term to pick if one means processes or devices, as it pretty
much guarantees raised hackles and confusion.

> As the
> charter says, strong access control will be designed in (but of course
> no assurance of implementing).=C2=A0=20

I don't see such a statement in the -06 charter sorry.

> Note that HIP has a course access
> control in its RVS service in that an RVS COULD ignore a redirect from
> an Initiator nore registered to the RVS.=C2=A0 But we need finer grain =
access
> control and, well it is in the charter.
>=20
> Why do this?=C2=A0 ID/Loc has a number of use cases, but is limited by =
the
> lack of discovery services (well, HIP can use DNS) and reverse discover=
y
> (but this is from Loc to get ID and only if authorized). We feel that
> adding in what we have learned limits ID/Loc will broaden its use.

TBH, I don't get the motivation here at all and I haven't
been enlightened by the discussion so far, nor from reading
the use-cases draft, but likely that's my fault.

Cheers,
S.


>=20
> Bob
>=20
> On 09/29/2017 02:31 PM, Stephen Farrell wrote:
>> As currently described, I oppose creation of this working
>> group on the basis that it enables and seemingly encourages
>> embedding identifiers for humans as addresses. Doing so
>> would have significant privacy downsides, would enable
>> new methods for censorship and discrimination, and could
>> be very hard to mitigate should one wish to help protect
>> people's privacy, as I think is current IETF policy.
>>
>> If the work precluded the use of any identifiers that
>> strongly map to humans then I'd be ok with it being done
>> as it'd then only be a waste of resources. But I don't
>> know how that could be enforced so I think it'd be better
>> to just not do this work at all.
>>
>> S.
>>
>> On 29/09/17 17:13, 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.
>>>
>>> IDentity Enabled Networks (ideas)
>>> ---------------------------------------------------------------------=
--
>>> Current status: Proposed WG
>>>
>>> Chairs:
>>> =C2=A0=C2=A0 Padma Pillay-Esnault 
>>>
>>> Assigned Area Director:
>>> =C2=A0=C2=A0 Alvaro Retana 
>>>
>>> Routing Area Directors:
>>> =C2=A0=C2=A0 Alia Atlas 
>>> =C2=A0=C2=A0 Alvaro Retana 
>>> =C2=A0=C2=A0 Deborah Brungard 
>>>
>>> Mailing list:
>>> =C2=A0=C2=A0 Address: ideas@ietf.org
>>> =C2=A0=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo/idea=
s
>>> =C2=A0=C2=A0 Archive: https://mailarchive.ietf.org/arch/browse/ideas/=

>>>
>>> Group page: https://datatracker.ietf.org/group/ideas/
>>>
>>> Charter: https://datatracker.ietf.org/doc/charter-ietf-ideas/
>>>
>>> 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.=

>>> Identifier-locator separation protocols require infrastructure that
>>> allows
>>> nodes to discover the network topological location(s) of its peer(s) =
for
>>> packet delivery. A common infrastructure and protocol could be used b=
y
>>> identifier/locator protocols as well as network virtualization. Howev=
er,
>>> additional infrastructure and new protocol extensions are needed to
>>> address
>>> new requirements that go well beyond the traditional discovery
>>> service and
>>> mapping of identifier-to-location for packet delivery.
>>> Identifier-locator
>>> protocols are also useful for additional services involving dynamic
>>> association of a name to a set of network addresses - these include
>>> dynamic
>>> multicast, cloud service anycast and context-aware IoT queries.
>>>
>>> The IDEAS WG is chartered to produce a framework document that
>>> defines the
>>> expected behavior of a mapping system across the multiple existing
>>> use cases.
>>> =C2=A0 The framework will aim at a homogeneous behavior across use ca=
ses,
>>> and it
>>> will call out specific trade-offs that may be considered in the
>>> development
>>> of solutions.=C2=A0 We refer to the framework providing the set of
>>> services as
>>> Generic Identity Services (GRIDS).
>>>
>>> Some of the areas that must be considered when developing the framewo=
rk
>>> include:
>>>
>>> - Description of interfaces for different protocols to interact with =
the
>>> framework (e.g. id-loc split protocols, management protocols, etc)
>>>
>>> - Description of identifier/locator mapping resolution and mapping
>>> update
>>> (e.g. discovery, pub/sub, multi-homing, ...)
>>>
>>> - Registration and lifecycle management of identities and their
>>> associated
>>> identifiers.
>>>
>>> - Identity authentication and authorization (e.g. access to
>>> framework, update
>>> of information for identifiers..)
>>>
>>> - Description of required basic network policies and policy
>>> enforcement needs
>>> (e.g. ability to look up an identifier-locator pair, permit forwardin=
g
>>> traffic for particular endpoints on a per-identity basis, etc.)
>>>
>>> - 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.
>>>
>>> - Security analysis of the complete system, including authentication,=

>>> authorization requirements and protection of any metadata.
>>>
>>> - Operational and deployment considerations
>>>
>>> The IDEAS WG will closely coordinate with the LISP and HIP WGs (and w=
ith
>>> others as needed) in order to keep them well-informed of the
>>> progress.=C2=A0 Any
>>> extension to existing protocols that is identified while developing t=
he
>>> framework document will be carried out in the responsible WG for that=

>>> protocol; any extension work to be done in this WG will require
>>> re-chartering.
>>>
>>> WG deliverables include:
>>>
>>> (1) Generic Identity Services Framework
>>>
>>> (2) Other WG sustaining/informational documents may include:
>>>
>>> - Problem statement
>>> - Use cases
>>> - Requirements for identifier/locator mapping and resolution
>>> - Requirements for identity authentication and authorization service
>>> (for
>>> GRIDS) - Applications of the architecture for use cases - Threat mode=
l
>>> document
>>>
>>> These documents will not be published as RFCs, but will be maintained=

>>> in a
>>> draft form or on a collaborative Working Group wiki to support the
>>> efforts of
>>> the Working Group and help new comers.
>>>
>>> Milestones
>>>
>>> January 2018 Adopt WG draft for the Generic Identity Services framewo=
rk
>>> July 2018 WGLC for the Generic Identity Services framework
>>> September 2018 Send Generic Identity Services framework draft to the
>>> IESG
>>> November 2018 Recharter or Close
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
>=20
>=20


--nlaUB0apHUnxoPsO3D7W6o1vKhaXdJR1p--

--Dx2Sb595Hahsvoe28IBbVLr9fG75tJvUn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZ3SxXAAoJEC88hzaAX42isvUH/iLUXbdRslF4RMhnol/NMsbr
UOVil0vQ02gjNlKbp5ETrgYmA312saDGYYLr/Iw2y/i6EygTF3qv/zbMyfC5sUZx
RQm3Pmzzr3KwzzEB2wVdvEQd3Ma3Jn4byKVWCklYZPTNW45gF99H2KA+utsGXU2U
vpQLZrtgggCp4zrcrEFWaBLLTDGUV+M/mWJG76PgZKTCijlS6JDLy0Pf6VZQkmcA
iHm56rux2Fsx2MqBh45GU0VO8LwtkfsY11UQdGMz97RB+pIXNr2H3n8us0b86vT8
xmbB675V7xJItpvy+rluV78wRTxLJ4ZB4ebIZETDN73oHEl2shTQeHop27D5dmA=
=y68T
-----END PGP SIGNATURE-----

--Dx2Sb595Hahsvoe28IBbVLr9fG75tJvUn--


From nobody Tue Oct 10 17:30:35 2017
Return-Path: 
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 99B2A134705 for ; Tue, 10 Oct 2017 17:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sO2GvSeftK2B for ; Tue, 10 Oct 2017 17:30:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03CD1346E9 for ; Tue, 10 Oct 2017 17:30:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQH31804; Wed, 11 Oct 2017 00:30:29 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Oct 2017 01:30:29 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Tue, 10 Oct 2017 17:30:27 -0700
From: Alexander Clemm 
To: "ideas@ietf.org" 
Thread-Topic: New revision posted on draft-ccm-ideas-identity-use-cases
Thread-Index: AdNCJ759WLnyNEFUS8OQ3qb/AaAdvw==
Date: Wed, 11 Oct 2017 00:30:26 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.124]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59DD6626.00B0, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4ac353568a8779dc5ad6cd6107ca780a
Archived-At: 
Subject: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 00:30:34 -0000

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5sjceml521mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FWIW, we have just posted an updated revision of the draft on Identity Use =
Cases in IDEAS:
https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-02
We took into account and tried to address recent discussions on the mailing=
 list to improve on the previous version and hopefully alleviate at least s=
ome of the concerns that were raised.
Kind regards
--- Alex (on behalf of the coauthors)

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5sjceml521mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











FWIW, we have just posted an updated revision of the=
 draft on Identity Use Cases in IDEAS: 



https://tools.ietf.org/html/draft-ccm-ideas-ident=
ity-use-cases-02



We took into account and tried to address recent dis=
cussions on the mailing list to improve on the previous version and hopeful=
ly alleviate at least some of the concerns that were raised.


Kind regards


--- Alex (on behalf of the coauthors)  






--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5sjceml521mbxchi_--


From nobody Tue Oct 10 18:07:57 2017
Return-Path: 
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 840D31270AB; Tue, 10 Oct 2017 18:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zCrgtshL43bM; Tue, 10 Oct 2017 18:07:55 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9387E13234B; Tue, 10 Oct 2017 18:07:55 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e25V4-0006w8-3p; Wed, 11 Oct 2017 01:07:54 +0000
Date: Wed, 11 Oct 2017 10:07:52 +0900
Message-ID: 
From: Randy Bush 
To: Alvaro Retana 
Cc: IETF Rinse Repeat , Bad Ideas 
In-Reply-To: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>  <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 01:07:56 -0000

> I can also see that clarifications about the intention or assurances
> about what the (proposed) WG should produce/focus on haven=A2t been
> enough to reduce the criticism of both the charter and the existing
> (individual) work.

that is because papering over dangerous things with assertions of good
intent is a path to hell.  one has to actually fix the things.

randy


From nobody Wed Oct 11 00:01:35 2017
Return-Path: 
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 7312B132C2A; Wed, 11 Oct 2017 00:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 dctTurE_yri1; Wed, 11 Oct 2017 00:01:27 -0700 (PDT)
Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFDE13202D; Wed, 11 Oct 2017 00:01:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.43,360,1503385200";  d="asc'?scan'208";a="220636095"
Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 10 Oct 2017 23:30:55 -0700
Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Oct 2017 00:01:26 -0700
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 11 Oct 2017 00:01:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xAl6DD7qafmnJ9x1owsF3+AnrAqO7eSOuVdzX5Fxrt4=; b=iRvfevBHUrk/TL9g7sFa48OM3scEPi4Q1Y4bXTFB5XHWVPr0d3fC+qZncxH8DEIG4tbrGACby0ZlcIidcqVy1g0t1h6a/dFJZ6a5yCutTG3f+zUwirMZdJK1W4t71RDzaz2RA8c/VLrj0QXsNn4/dpTpq87I45wUZecKMzpINlQ=
Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 11 Oct 2017 07:01:25 +0000
Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0077.020; Wed, 11 Oct 2017 07:01:23 +0000
From: "Eggert, Lars" 
To: Alvaro Retana 
CC: "ietf@ietf.org" , "ideas@ietf.org" 
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTOT35v3hyWdVoV0KqrqLEQ0bs66LZGgGSgAAfwwCAARL6Y4AABPsAgAAEGseAAXvFAIAABqOAgAA8jwCAATWVAIABAKOA
Date: Wed, 11 Oct 2017 07:01:23 +0000
Message-ID: <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>  <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.1.7)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; 
x-originating-ip: [217.70.211.15]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:7IUzPBl5TdWxlGYsakVSVshsK9CdKaAwEWHy1q0RZK48QJjqzdgrU9hIf80RbW+Q7+L0oX/RNpHsEOPIWXpUxYjzFb7Q7H0eLhx1hphsILcynY2rXxJXGXFccU6dNEBEFO57tZik8bydn4CvEd20nUwCqy5jQskiWMEnWwp79XF8vWNk2YRyuAtqYskd6C2flhvfFrRfDiGe4M87ypjYsjygpuIa2X+F5Jvii+CsHkkPqZYsW+QmYLcVrgs4KaRX++Xr7JK+feG/SX+zs0d4sgzwqJdxNsOffIsBZO2VVrCQMEIQ1GDe+cdieT5bLSoRGi30ksRc2an1GNc64oAYeQ==; 5:z4Dh27Bhqyegz2dADxrTVtmNaXPt4IiRUDEujLnCxsHB/2Q4zXUY8kHVpoaILORVNmJYq7DTWd7eqs0IdO1RRLMMbmsknNcV6zAGQiE17jiwi7vCqAcdX4NOtSF4J9cSmTq37dMI/v+WpoUszRmv+2erb63QGzk0oUZFBcri1VU=; 24:qaBPLJ8DIfY1CRav9ewlX7HN4nq4HauHiBsIhTcqD8Li5Bxu4i+TONoSbsJqmIQESb8cWFNkSN82pbH+t6qj1a1PDqlxVJq1n+WuKQHNFFs=; 7:P29K24sLll1GWR4nZObnwL9oDjDdsOCQPpEbfDhWkJXqd5tp2qBTrgkn2vT9Taw9Xm9Zmh2J2fvFmvNJKv7+vufopVQSA2iKcOFDuz983DRQigyxzxt0Iocub427XQof3sLTNJuBYvUEQpKqI6Jw+mbpdDcZA6tpcW0TgSztrFyMDTWaZLTeS4ED2o3NheV8X9bhd5AbqKSmYkD+4iQ+Qyuys3YiFjpzc1SPLhknyv8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 53feb44c-6189-4fd7-622c-08d51075e26e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1764; 
x-ms-traffictypediagnostic: BLUPR06MB1764:
x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; 
x-forefront-prvs: 0457F11EAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377424004)(189002)(51444003)(52314003)(199003)(24454002)(50226002)(5660300001)(6246003)(39060400002)(6916009)(2950100002)(4326008)(106356001)(105586002)(6486002)(6506006)(86362001)(77096006)(101416001)(7736002)(229853002)(189998001)(14454004)(2900100001)(82746002)(68736007)(66066001)(25786009)(36756003)(33656002)(99286003)(102836003)(6116002)(3846002)(53546010)(305945005)(97736004)(53936002)(6512007)(478600001)(6436002)(4001150100001)(8936002)(81166006)(93886005)(81156014)(99936001)(316002)(3660700001)(76176999)(83716003)(8676002)(2906002)(50986999)(54906003)(3280700002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_DF7227E7-E378-474B-BF3B-C56A59E1D24D"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 07:01:23.7958 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764
X-OriginatorOrg: netapp.com
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 07:01:30 -0000

--Apple-Mail=_DF7227E7-E378-474B-BF3B-C56A59E1D24D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

On 2017-10-10, at 17:42, Alvaro Retana  wrote:
> Right after I send this e-mail I will be opening the ballot [1] for =
this week=E2=80=99s IESG Telechat discussion of this (proposed) WG.  I =
will be balloting =E2=80=9CYes=E2=80=9D because I think that the =
discussion could be taken further in the context of a WG (hopefully with =
additional security/privacy expertise).  I know that the charter text is =
not perfect, and realize that I may be in the rough anyway.

not only is the charter text "not perfect", it *raises* serious security =
and privacy concerns.

Going forward with the current charter text is hence exactly the wrong =
thing to do. At the very least, the charter text requires a serious =
refactoring, to attempt to either address the raised concerns or to =
explicitly (and drastically) limit the scope of the work so that there =
is consensus that these issues can be worked out in a WG.

The statement to take this "further in the context of a WG (hopefully =
with additional security/privacy expertise)" basically asks the rest of =
us who have no interest in this work to spend cycles on it anyway, in =
order to do damage control in a WG. The reason we do consensus calls on =
charters is so that we *don't* need to do that for ideas that are =
clearly problematic and shouldn't be chartered.

Lars

--Apple-Mail=_DF7227E7-E378-474B-BF3B-C56A59E1D24D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlndwcMACgkQVLXDCb9w
wVfRrg//ZL40KGnILvi9CSwfy/zmFpx3h2KBJexjLdJoDfUuOzMs5yzFQrPycIiN
R2u+zPNX8Ku/tVShN3qwlci5xrALvkcVbniLRKk64y001AJu7ltx75+1sQ7WCEw3
1/7wGZRbxyQ/wzK2ViJ7QFQL40r+Obyb1WypwIPB5QFYy/klXd0e/xyYDxQwqY7d
xAsPGNbrHWXjAF7/aHHLaJ5LF80Dn5uZUqoZKz3bJ9qhA+FgrbdVkafYIRtBiPby
yw70x+eb5p42kTwbHu4vWMrc6zyA2hoAN2uQYe1qvGCDmGf8R8jw78pv6GFUah5v
B2tKKbPYi60XwworMQ58N6h5MpQGwUlbahwKaV++yTGMZKA5tuwbqPo8kBth7THY
xpI9irTNjXVwU+JOyKOuDgK3NS5Rpu5bzN9wm7srW45Ga8uJYuzontY+4QolKjUi
3uZsg1cA1bKxJIDo8rEDn4bdTCBNlidxD7Fnsstr/8XIVTmL1SWMgZNecH2seE7L
XEfq+CDS/QIH5WhjtPoF8cQRNj/0z4CcmXaSttWiDPn2afjwlMMPolyeuww1daMC
EhkPeFBmUcjybwpQDPNy26lQMy+zVgGotBRky+88K0JguGcYRfpWMvRrFBekS0D3
mDfmIklpa+AoQ8es81Dbk4GWgwt7Sr9BzmoMHMfKxonrt3x7wO4=
=vfnb
-----END PGP SIGNATURE-----

--Apple-Mail=_DF7227E7-E378-474B-BF3B-C56A59E1D24D--


From nobody Wed Oct 11 00:14:27 2017
Return-Path: 
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 9368013202D; Wed, 11 Oct 2017 00:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 s7sGZDbGfCvF; Wed, 11 Oct 2017 00:14:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8315912EC30; Wed, 11 Oct 2017 00:14:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F639BE56; Wed, 11 Oct 2017 08:14:18 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yV9FxJCCnkV; Wed, 11 Oct 2017 08:14:16 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3DCD3BE49; Wed, 11 Oct 2017 08:14:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507706056; bh=duLTBA3VIQUalRh4uxHXkjm1AXQGVz+pfNK0xUp5Qvk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kNKTXbV2z42tSVBKFFo9a/6+CfCEDm0KP4AqdQyt0U1ULZV3pj7oQo0m47OmCyWVr /R6d8ORT0UIyWxWgFVGQxWH8xq7/vkOY0jCNYN09xedFu1/akVk86rqTsvVi/dQ8AU BmyD4buYJdLbMH1I9DdWye0eoyhlHrBAH1CzseBw=
To: "Eggert, Lars" , Alvaro Retana 
Cc: "ideas@ietf.org" , "ietf@ietf.org" 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>  <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com>  <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <9dfaba08-ed86-2c88-10e7-e57b817d3c6f@cs.tcd.ie>
Date: Wed, 11 Oct 2017 08:14:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3vlwWUmvPfuq5rsURK97a6lJ25ONwUBUv"
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 07:14:22 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3vlwWUmvPfuq5rsURK97a6lJ25ONwUBUv
Content-Type: multipart/mixed; boundary="kHWPHXwAvkwWKCT7RWHBdPqWjck76CEdm";
 protected-headers="v1"
From: Stephen Farrell 
To: "Eggert, Lars" , Alvaro Retana 
Cc: "ideas@ietf.org" , "ietf@ietf.org" 
Message-ID: <9dfaba08-ed86-2c88-10e7-e57b817d3c6f@cs.tcd.ie>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com>
 <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>
 
 <6.2.5.6.2.20171008102541.11499408@elandnews.com>
 
 <6.2.5.6.2.20171008112206.1100fa88@elandnews.com>
 <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com>
 
 <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com>
 
 <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>
In-Reply-To: <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>

--kHWPHXwAvkwWKCT7RWHBdPqWjck76CEdm
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


I agree with Lars' statement below and don't understand the
logic of the "yes" ballot here. That said, I see there are
now also two "block" ballots [1] so it looks like the IESG
collectively are doing the right thing.

S.

[1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/

On 11/10/17 08:01, Eggert, Lars wrote:
> Hi,
>=20
> On 2017-10-10, at 17:42, Alvaro Retana  wrote:
>> Right after I send this e-mail I will be opening the ballot [1] for th=
is week=C3=A2=E2=82=AC=E2=84=A2s IESG Telechat discussion of this (propos=
ed) WG.  I will be balloting =C3=A2=E2=82=AC=C5=93Yes=C3=A2=E2=82=AC=C2=9D=
 because I think that the discussion could be taken further in the contex=
t of a WG (hopefully with additional security/privacy expertise).  I know=
 that the charter text is not perfect, and realize that I may be in the r=
ough anyway.
>=20
> not only is the charter text "not perfect", it *raises* serious securit=
y and privacy concerns.
>=20
> Going forward with the current charter text is hence exactly the wrong =
thing to do. At the very least, the charter text requires a serious refac=
toring, to attempt to either address the raised concerns or to explicitly=
 (and drastically) limit the scope of the work so that there is consensus=
 that these issues can be worked out in a WG.
>=20
> The statement to take this "further in the context of a WG (hopefully w=
ith additional security/privacy expertise)" basically asks the rest of us=
 who have no interest in this work to spend cycles on it anyway, in order=
 to do damage control in a WG. The reason we do consensus calls on charte=
rs is so that we *don't* need to do that for ideas that are clearly probl=
ematic and shouldn't be chartered.
>=20
> Lars
>=20


--kHWPHXwAvkwWKCT7RWHBdPqWjck76CEdm--

--3vlwWUmvPfuq5rsURK97a6lJ25ONwUBUv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZ3cTHAAoJEC88hzaAX42iuRIIAJWHIEDtd875YAzyQj6x32gX
ZjWFR9n33eSr0SfDb3X8I7XtzFTUyCLRJVIwg5IC6cbqec7aooL/K36o/5O86/5D
rzUFBe2jSbLvq+y5y8PdPPtZ2VznTPXibkSx4kehOgwMaPgTCmuaawIPAd9xpdqB
9N9IHtO/ui5BzOZN/5844E+Pk7sc4DIy+hTF/n6LfUyLNHGufO/5rmQ3lfwznooo
6qJE9X1ZVHOyMJ/2awsdk0GllprUYfNDQceG8f6gii7NcXrqx6AdCGGGd0A7gyuj
WvqzitLmuN4NjnaCZe9OroL5odR9RLEyBlhaYi7+2AWgIyrZVEcB9+MYma8m64w=
=7dU0
-----END PGP SIGNATURE-----

--3vlwWUmvPfuq5rsURK97a6lJ25ONwUBUv--


From nobody Wed Oct 11 00:30:01 2017
Return-Path: 
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 5E99D132153; Wed, 11 Oct 2017 00:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QJQSmJDVNdSr; Wed, 11 Oct 2017 00:29:53 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 47FDC132076; Wed, 11 Oct 2017 00:29:53 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e2BSf-0000Td-NT; Wed, 11 Oct 2017 07:29:50 +0000
Date: Wed, 11 Oct 2017 16:29:47 +0900
Message-ID: 
From: Randy Bush 
To: "Eggert, Lars" 
Cc: Alvaro Retana , Bad Ideas , IETF Rinse Repeat 
In-Reply-To: <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>  <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com>  <62958257-9F18-4176-B29F-0D0D4B31E14B@netapp.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 07:29:54 -0000

> The statement to take this "further in the context of a WG (hopefully
> with additional security/privacy expertise)" basically asks the rest
> of us who have no interest in this work to spend cycles on it anyway,
> in order to do damage control in a WG. The reason we do consensus
> calls on charters is so that we *don't* need to do that for ideas that
> are clearly problematic and shouldn't be chartered.

this is a terrible scaling problem.  lack of guts in the iesg devolves
into a massive time burden on a lot of people.

randy


From nobody Wed Oct 11 02:56:37 2017
Return-Path: 
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 8B46C13307E; Wed, 11 Oct 2017 02:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 3wMj8jHdNApZ; Wed, 11 Oct 2017 02:56:28 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 DE27D133188; Wed, 11 Oct 2017 02:56:27 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id t69so3292386wmt.2; Wed, 11 Oct 2017 02:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=dXZyZ36QaRYhdahSMJy4jpIXOA9ZG3ojYDkpaFrtwUU=; b=oM7bLuXpdl9azf1qA4PhHZoNhnEkx31yAL3RJhng1PYG80ksH2FTK542ETrhgy1EZq FMUES4UpaeCwnuQvC/qFcqkZBhE1TVAVz2EkxNPOQjPKz3FQ9UElNtroHqoVguPgaMsS T+Gh+aj18eVu4e5D1I1OIkXuedTdX+MTSVgsgnKf1UW3dLVgz2gJgCIvyx2LmvtjEFOK 5wWgHUJQ5XQlyrXFRHg9xzi6hzhEHHxvy4a7piEAiWds5fKHpDnm2cXf30jGN2u9wwAO naz4bXaY/hmQXnRKE5IobHvwMnpi9nvJIb4JJKWa1/qHCo+fjFzbjuo0YtbuVzkx3WlL FqCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=dXZyZ36QaRYhdahSMJy4jpIXOA9ZG3ojYDkpaFrtwUU=; b=oPqNRiBT4Rrok7qYVrqWsU+FQswCDRIVYcb1KKPGYkQwS0BA48o2x2+WWwLcgUgmp+ Z6DBdbJSpeR5q3KUors75gzj14Nyy+lw8WjZfSyHRlLQ09ixLyxpPHNwdMnOaywHJe/H /mSY6fqR48/7yMcHYpPy8Pq0YoQcvV54ZFSxzpgz4WWlNEMbBgSRLizSQynGJi8KsjWF 9iUfTeYcYvruk46jVnzkRRlp4TZaChVDnEEo3mSmkZHWorGEaFxc+AJnQuimL4XfD7dx nbUJlKmLkx7P9hgbH5admPpXm3gCPDYe2OL7bsf3g9VeKutplWOcotJOa3gMeOcuGLQD EQ2A==
X-Gm-Message-State: AMCzsaVEkQqSm6pn9tSWPICdKRcPzJkaXXxCJXUM2V/IwBWYzhBRlLmX 2wh1sxHdzhByq5i5Cbm4EFk=
X-Google-Smtp-Source: AOwi7QDZGXhj+w770NtvLOrjjnpt44RV7DH06YG7ZEGhyNUeWJxDwB58vJAxKbZGAwSD0ixdQ/lTKg==
X-Received: by 10.80.219.66 with SMTP id b2mr21422928edl.256.1507715786437; Wed, 11 Oct 2017 02:56:26 -0700 (PDT)
Received: from [10.150.4.1] (41-114-103-145.static.glaslokaal.nl. [145.103.114.41]) by smtp.gmail.com with ESMTPSA id c25sm12105038edb.28.2017.10.11.02.56.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 02:56:25 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/f.26.0.170902
Date: Wed, 11 Oct 2017 02:56:24 -0700
From: Jeff Tantsura 
To: Alvaro Retana , "ietf@ietf.org" 
CC: "ideas@ietf.org" 
Message-ID: <4766C4E6-396B-482F-84C6-8F1FFC24D8B4@gmail.com>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>  <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 09:56:30 -0000

Hi,

I share all the concerns expressed, these have to be taken very seriously a=
nd properly addressed, I expect authors and proponents to do so rather soon!
I also support Alvaro=E2=80=99s view on future evolution and further fine-tuning =
of the charter and deliverables within a new WG.  =20

Cheers,
Jeff

-----Original Message-----
From: ietf  on behalf of Alvaro Retana 
Date: Tuesday, October 10, 2017 at 08:56
To: "ietf@ietf.org" 
Cc: "ideas@ietf.org" 
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

    [Apologies for not chiming in before. [*]]
   =20
    I=E2=80=99ve been reading this thread and discussing with others in the IAB/I=
ESG.  Thank you for all the comments and opinions!
   =20
    The concerns about privacy/anonymity and the potential results (trackin=
g, censorship, etc.) are clear.  It is a serious topic and I wouldn=E2=80=99t have=
 expected less.  I can also see that clarifications about the intention or a=
ssurances about what the (proposed) WG should produce/focus on haven=E2=80=99t bee=
n enough to reduce the criticism of both the charter and the existing (indiv=
idual) work.
   =20
    At this point in the process, and without trying to run the WG or rewri=
te the documents on this thread, all I can offer is charter text.  My expect=
ation is for the support documents (i.e. the individual drafts that have bee=
n written so far) to be discussed and consensus reached on them =E2=80=93 vs assum=
ing that they are a foregone conclusion.  I think that the number of use cas=
es require that formal discussion anyway.  Whatever the result of the charte=
ring effort is, I hope that interested people will join the mailing list and=
 contribute with the same enthusiasm.  To me, the widening of the audience h=
as been as important as the discussion itself.
   =20
    Right after I send this e-mail I will be opening the ballot [1] for thi=
s week=E2=80=99s IESG Telechat discussion of this (proposed) WG.  I will be ballot=
ing =E2=80=9CYes=E2=80=9D because I think that the discussion could be taken further in =
the context of a WG (hopefully with additional security/privacy expertise). =
 I know that the charter text is not perfect, and realize that I may be in t=
he rough anyway.
   =20
    Thanks!
   =20
    Alvaro.
   =20
   =20
    [1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/  =20
   =20
    [*] I=E2=80=99m in the process of changing jobs, took a couple of (I would st=
rongly argue, well-deserved) days off in between, e-mail went missing, chang=
ed e-mail systems 3 times=E2=80=A6    Definitely not the best timing. :-(
   =20
    =20
   =20
   =20
   =20



From nobody Wed Oct 11 03:56:23 2017
Return-Path: 
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 3F4B2133226; Wed, 11 Oct 2017 03:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1qc4sza0FHnF; Wed, 11 Oct 2017 03:56:20 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A675133053; Wed, 11 Oct 2017 03:56:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXI64017; Wed, 11 Oct 2017 10:56:16 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Oct 2017 11:56:15 +0100
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.215]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000;  Wed, 11 Oct 2017 03:56:06 -0700
From: Uma Chunduri 
To: Stephen Farrell , Robert Moskowitz , "ietf@ietf.org" 
CC: "ideas@ietf.org" 
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTOT4HqNfbNA2TZ0OR3IdlIasmsqLMpUwAgBFbboCAAA2BgIAAdv4w
Date: Wed, 11 Oct 2017 10:56:05 +0000
Message-ID: <25B4902B1192E84696414485F572685401A8872C@SJCEML701-CHM.china.huawei.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.201.113.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59DDF8D1.002C, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.215, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6c3af99f58e1567df8b7e11a874c70d8
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 10:56:22 -0000

SGkgU3RlcGhlbiAtDQoNCkkgd291bGQgbGV0IEJvYiB0byByZXNwb25kIHRoZSBxdWVzdGlvbnMg
eW91IGFza2VkIC0gYnV0IElmIEkgbWF5IGZvciB0aGUgYmVsb3cgcXVlc3Rpb24gDQoNCgkJPj4g
DQoJCT4+IFRoaXMgaXMgYWJvdXQgbWFjaGluZXMsIGFuZCBwcm9jZXNzZXMsIGhhdmUgSUQvTG9j
IHRocm91Z2ggc29tZSANCgkJPj4gdW5kZXJseWluZyB0ZWNobm9sb2d5IChlLmcuIEhJUCwgSUxB
LCBMSVNQKSB0byBoYXZlIGEgY29tbW9uIElEIA0KCQk+PiBkaXNjb3ZlcnkgYW5kIExvYyBiYWNr
IHRvIElEIChmb3IgdGhpbmdzIGxpa2UgSFRUUCByZWRpcmVjdHMpLg0KDQoJPklmIHRoYXQncyB0
aGUgY2FzZSwgdGhlbiB0aGVyZSBhcHBlYXJzIHRvIGJlIHNlcmlvdXMgY29uZnVzaW9uIGluIHRo
ZSB1c2UtY2FzZXMgZHJhZnQgYXQgbGVhc3QuIEFuZCAiaWRlbnRpdHkiIHNlZW1zIGEgZmFpcmx5
IG1hZCB0ZXJtIHRvIHBpY2sgaWYgb25lIG1lYW5zIHByb2Nlc3NlcyBvciBkZXZpY2VzLCBhcyBp
dCBwcmV0dHkgbXVjaCBndWFyYW50ZWVzIHJhaXNlZCBoYWNrbGVzIGFuZCBjb25mdXNpb24uDQoN
CltVbWFdOiANCg0KMS4gSURFQVMgb25seSBpbnRlbmRlZCBkZWFsIHdpdGggYXNwZWN0cyBmb3Ig
Y29udHJvbC9tYXBwaW5nIHBsYW5lIG9mIElEL0xPQyBwcm90b2NvbHMuIA0KICAgICAgSG93ICBh
bmQgd2hhdCBraW5kIG9mIElkZW50aWZpZXIncyB1c2VkIGluIHRoZSBkYXRhIHBhY2tldHMgYXJl
IGdvdmVybmVkIGJ5IHRoZSAgcmVzcGVjdGl2ZSBJRC9MT0MgcHJvdG9jb2wgaW4gdXNlLiAgSnVz
dCBnaXZlIHNvbWUgZXhhbXBsZXMgLQ0KICAgICAgSXQgY291bGQgYmUgSElUIGluIGNhc2Ugb2Yg
SElQIHdpdGggc2VjdXJpdHkgcHJvcGVydGllcywgRUlEL0Fub255bW91cyBFSUQncyBpbiBjYXNl
IG9mIExJU1Agd2l0aCBlbmNhcHN1bGF0aW9uLg0KICANCiAgICAgVGhpcyBoYXMgYmVlbiBleHBs
aWNpdGx5IHVwZGF0ZWQgaW4gdGhlIHVzZS1jYXNlIGRyYWZ0IGFuZCBjYW4gYmUgZnVydGhlciB1
cGRhdGVkIGluIHRoZSBjaGFydGVyLiBCdXQsIEkgd291bGQgbm90ZSAgdGhpcyBpcyB0aGUgaW50
ZW50aW9uIGZvciB0aGUgIGZvbGxvd2luZyBpbiB0aGUgY3VycmVudCBjaGFydGVyIHRleHQgLQ0K
ICAgICAgIlRoZSBJREVBUyBXRyB3aWxsIGNsb3NlbHkgY29vcmRpbmF0ZSB3aXRoIHRoZSBMSVNQ
IGFuZCBISVAgV0dzIChhbmQgd2l0aA0KCW90aGVycyBhcyBuZWVkZWQpIGluIG9yZGVyIHRvIGtl
ZXAgdGhlbSB3ZWxsLWluZm9ybWVkIG9mIHRoZSBwcm9ncmVzcy4iDQoNCjIuICBBbmQgcmVnYXJk
aW5nIHRoZSB1c2FnZSBvZiB0aGUgdGVybSAiaWRlbnRpdHkiIC0gbm90IHN1cmUgd2hhdCdzIHRo
ZSBjb25mdXNpb24gYW5kIHdoeSB0aGlzIGhhcyBiZWVuIGFzc29jaWF0ZWQgd2l0aCBodW1hbnMg
dG8gc3RhcnQgd2l0aC4gVGhpcyBoYXMgYmVlbiBmdXJ0aGVyIGNsYXJpZmllZCBpbiB0aGUgZGlz
Y3Vzc2lvbnMgcGFzdCBmZXcgZGF5cyBhbmQgYWxzbyBiZWVuIHVwZGF0ZWQgaW4gdGhlIGRvY3Vt
ZW50LiANCiAgICAgIE5vdyB0aGUgdGVybSwgIHdlIGZlbHQgYXBwcm9wcmlhdGUgYXMgdGhlIGlu
dGVudCBpcyBpbiB0aGUgY29udGV4dCAgb2YgQVVUSCAoZXhhbXBsZXMgb2YgaWRlbnRpZmllcyB0
aG91Z2h0IHRocm91Z2ggSVBWNF9BRERSLCBGUUROLCBSRkM4MjJfQUREUiwgSVBWNl9BRERSLCBE
RVJfQVNOMV9ETiwgREVSX0FTTjFfR04sIEtFWV9JRHMgZXRjKSAsIA0KICAgICAgIHdoaWNoIGlz
IGNvbnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3ZSB1
c2UgdG9kYXkqIGFzIGRlZmluZWQgYnkgSUVURi4gDQoNCi0tDQpVbWEgQy4NCg0KKiBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtdGxzMTMtMjENCiAgIGh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTk2IA0KICAgT3Igb25lIG9mIHRoZSAyMC8zMCsgRUFQ
IEFVVEggbWV0aG9kcyB3aXRoIG11dHVhbCBhdXRoZW50aWNhdGlvbiBwcm9wZXJ0aWVzIChkZXBl
bmRpbmcgdGhlIGxvdyBwb3dlci9oaWdoIHBvd2VyIG1vYmlsZS9pbmR1c3RyaWFsL3ZlaGljdWxh
ciBJb1QgZGV2aWNlIGluIHF1ZXN0aW9uKQ0K


From nobody Wed Oct 11 04:56:29 2017
Return-Path: 
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 7913113305F; Wed, 11 Oct 2017 04:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JB1F1raJ5Rcy; Wed, 11 Oct 2017 04:56:26 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 78E9113304D; Wed, 11 Oct 2017 04:56:26 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e2Fcd-0001Jq-Nv; Wed, 11 Oct 2017 11:56:24 +0000
Date: Wed, 11 Oct 2017 20:56:21 +0900
Message-ID: 
From: Randy Bush 
To: Uma Chunduri 
Cc: IETF Rinse Repeat , Bad Ideas 
In-Reply-To: <25B4902B1192E84696414485F572685401A8872C@SJCEML701-CHM.china.huawei.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <25B4902B1192E84696414485F572685401A8872C@SJCEML701-CHM.china.huawei.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 11:56:27 -0000

> 1. IDEAS only intended deal with aspects for control/mapping plane of
>    ID/LOC protocols.

please stop using the word 'intended' and it's friends.  joseph ii had
wonderful intent, but did not succeed.

how about 'will be chartered to only do X.'  'will not by charter' etc.

and let's see the revised charter.

note that ipv6 MAC-derived EUI addresses were intended only to map
identity to location.  they are a privacy disaster.

randy


From nobody Wed Oct 11 05:21:17 2017
Return-Path: 
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 48A061320C9; Wed, 11 Oct 2017 05:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 us8hnekgWih0; Wed, 11 Oct 2017 05:21:07 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972C11342D2; Wed, 11 Oct 2017 05:21:06 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9BCL41a007719; Wed, 11 Oct 2017 13:21:04 +0100
Received: from 950129200 (62.192.112.87.dyn.plus.net [87.112.192.62]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9BCL1PP007703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Oct 2017 13:21:03 +0100
Reply-To: 
From: "Adrian Farrel" 
To: 
Cc: 
Date: Wed, 11 Oct 2017 13:21:03 +0100
Message-ID: <05aa01d3428b$69222890$3b6679b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdNCi2XDwA3qavwwR0S6VNhqD+IZRA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23386.006
X-TM-AS-Result: No--9.754-10.0-31-10
X-imss-scan-details: No--9.754-10.0-31-10
X-TMASE-MatchedRID: cTwTy1nILiLMHUInqqZ02hWCVBr+Ay980nXvwjW2mSWmKn0WszswH8Lm p4jPUF8t2BgAhpJqDmmPgvujI3XDfrE8iKjgaIfGlVHM/F6YkvQGwd8wUY9uM16h6sWm+pWd4qS OTf7raZF7tgTPLzrW2i5SWE9/6EYOVCFefQRV3M5IRA38P/dwbkEfDC/+cVmmFJfW7wEu1kD0T3 Risbtv4/QAGnwdE7nfU9ppuNDleoZPB4rXagQZ+xi14cCd2FejJPNIV6GF8mtk2J2ef3Nd3wOHl es/nBwnTMDcUZMOT5eWNrS+2ymUOHZ41k2pZTcfcFEiuPxHjsVy2CK2WfrdRS3FY27PpHmsXAxU NdULeEYpJoYHgmIwOr59kd3tU9KQemzGG4qDPaloe+401GwOsn0tCKdnhB581B0Hk1Q1KyLUZxE AlFPo846HM5rqDwqtk1KUrXGvNw0o9jlMQyIWK6JMup4ItiKnyU1OQKPdrwGMZWweiRdBFUMMpr cbiest
Archived-At: 
Subject: [Ideas] Needless playing with semantics [Was : 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 12:21:10 -0000

It is fruitless to debate what "identity" means. Much better to qualify =
it when you use it. When you mean "identity of a device" say so and =
don't use a shorthand. When you mean "identity of an individual" be =
explicit. Sure, you have to use a few more pixels, but you will be =
better understood.

It would also be helpful IMHO if the proponents were far clearer and =
blunt in their statements of intention. When saying "it is not our =
intention to do foo," you are not saying "doing foo is proscribed" and =
you are not saying "achieving foo as a by-product is unacceptable." =
Clarity is always helpful.

Adrian

> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Uma Chunduri
> Sent: 11 October 2017 11:56
> To: Stephen Farrell; Robert Moskowitz; ietf@ietf.org
> Cc: ideas@ietf.org
> Subject: RE: [Ideas] WG Review: IDentity Enabled Networks (ideas)
>=20
> Hi Stephen -
>=20
> I would let Bob to respond the questions you asked - but If I may for =
the below
> question
>=20
> 		>>
> 		>> This is about machines, and processes, have ID/Loc through
> some
> 		>> underlying technology (e.g. HIP, ILA, LISP) to have a common
> ID
> 		>> discovery and Loc back to ID (for things like HTTP redirects).
>=20
> 	>If that's the case, then there appears to be serious confusion in =
the use-
> cases draft at least. And "identity" seems a fairly mad term to pick =
if one means
> processes or devices, as it pretty much guarantees raised hackles and =
confusion.
>=20
> [Uma]:
>=20
> 1. IDEAS only intended deal with aspects for control/mapping plane of =
ID/LOC
> protocols.
>       How  and what kind of Identifier's used in the data packets are =
governed by
> the  respective ID/LOC protocol in use.  Just give some examples -
>       It could be HIT in case of HIP with security properties, =
EID/Anonymous EID's in
> case of LISP with encapsulation.
>=20
>      This has been explicitly updated in the use-case draft and can be =
further
> updated in the charter. But, I would note  this is the intention for =
the  following in
> the current charter text -
>       "The IDEAS WG will closely coordinate with the LISP and HIP WGs =
(and with
> 	others as needed) in order to keep them well-informed of the =
progress."
>=20
> 2.  And regarding the usage of the term "identity" - not sure what's =
the confusion
> and why this has been associated with humans to start with. This has =
been
> further clarified in the discussions past few days and also been =
updated in the
> document.
>       Now the term,  we felt appropriate as the intent is in the =
context  of AUTH
> (examples of identifies thought through IPV4_ADDR, FQDN, RFC822_ADDR,
> IPV6_ADDR, DER_ASN1_DN, DER_ASN1_GN, KEY_IDs etc) ,
>        which is consistent with any of the authentication mechanism we =
use today*
> as defined by IETF.
>=20
> --
> Uma C.
>=20
> * https://tools.ietf.org/html/draft-ietf-tls-tls13-21
>    https://tools.ietf.org/html/rfc5996
>    Or one of the 20/30+ EAP AUTH methods with mutual authentication =
properties
> (depending the low power/high power mobile/industrial/vehicular IoT =
device in
> question)


From nobody Wed Oct 11 07:53:57 2017
Return-Path: 
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19913318B; Wed, 11 Oct 2017 07:53:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 07:53:55 -0700
Archived-At: 
Subject: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 14:53:55 -0000

Alissa Cooper has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I do not think this group is ready to be chartered at this time given the
significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the
mapping system and the identity management system envisioned here do not appear
to be backed up by those who have developed and deployed ID/LOC separation
protocols. Nor do there seem to be compelling arguments that the framework that
this proposed WG would produce would be the motivator for further interoperable
deployments.

(2) The work proposed here seems as if it would have a substantial intrinsic
impact on user privacy if widely deployed. In cases like these, I don't believe
it's sufficient to say that the WG will analyze the situation and propose
mitigations; the work proposal itself needs to explain how the design of the
infrastructure envisioned is going to mitigate what seem like obvious attacks
on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in
Singapore, or at a potential future BoF) would need to resolve both of the
above issues in order to address concerns raised by the community.





From nobody Wed Oct 11 07:57:23 2017
Return-Path: 
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 9B4A5134224; Wed, 11 Oct 2017 07:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QfDYOK0TaqOE; Wed, 11 Oct 2017 07:57:10 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2A2132331; Wed, 11 Oct 2017 07:57:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D58CA62169; Wed, 11 Oct 2017 10:57:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oAXZGJ7gk4Km; Wed, 11 Oct 2017 10:56:54 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 46ED362164; Wed, 11 Oct 2017 10:56:53 -0400 (EDT)
To: Brian E Carpenter , Dino Farinacci 
Cc: "ideas@ietf.org" , "ietf@ietf.org" , "lisp@ietf.org list" 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>
From: Robert Moskowitz 
Message-ID: 
Date: Wed, 11 Oct 2017 10:56:48 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 14:57:14 -0000

Just sqeezing in a couple more replies before the last days of the 
Holiday...

On 10/04/2017 05:56 PM, Brian E Carpenter wrote:
> On 05/10/2017 09:35, Dino Farinacci wrote:
>> Adding lisp@ietf.org to cc list.
>>
>> How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated?
> That seems reasonable, well defined and relatively uncontentious.
>
> The current proposed charter leaves me a bit puzzled. Firstly I agree
> that the name 'IDEAS' is misleading,

And other wg's are not?  The IETF's desire for 'nice' names often 
results in names a little misleading.  Thus need to read the charter.  
Not that everyone who worked on the charter got what they wanted.  It is 
called compromise.

> and 'GRIDS' tramples on previous work,

Yeah, I did/dont like it.  But it is not my draft.

> and 'identity' is a red flag.

Whow there!  You were part of the Namespace Research Group?  I think?  I 
was and we we worked a lot on this and came to the conclusion that there 
could be no conclusion.  Not even a rough concensus, it seemed.

I have been using 'identity' to apply to things for 20 years. Pretty 
much ever since I started working with things.  Anyone that holds the 
position that 'identity' means we are talking only about people are 
allowing their thinking to be clouded.

So we use qualify our use of such terms.  That is why I called it a 
'Host Identity', then I was challenged as to what I was naming? Were you 
at the NL meeting the week before Oslo?  'Oh you are naming the stack'.  
ARGH!

enough history.

> But if we get past terminology distractions,
> where's the meat? All the interesting stuff is relegated to drafts or a
> wiki, and the output is a 'framework'. The IETF has a very mixed record
> with 'framework' documents.

The meat is what is missing in current ID/Loc technologies to realize 
the full potential.  Discovery. Some level of reversiblity. Strong 
access controls.

I plan on doing some real protocol work.  And some real implementation 
guidelines for protecting privacy.

Bob

>
>      Brian
>
>> I have made suggestions before that such a working group should be in the ops area. Some examples include and are not limited to v6ops, dnsop, and mboned.
>>
>> Cheers,
>> Dino
>>
>>> On Oct 4, 2017, at 12:45 PM, Stephen Farrell  wrote:
>>>
>>>
>>> Hiya,
>>>
>>> TL;DR - I am now even more convinced that this ought not
>>> go ahead. (Sorry;-)
>>>
>>> On 04/10/17 19:48, Alexander Clemm wrote:
>>>> There were a couple of things raised in the overall thread that I
>>>> just wanted to quickly respond to:
>>>>
>>>> Clearly privacy is an important issue and concern.  The current
>>>> charter proposal includes a requirement for a detailed analysis of
>>>> this aspect.  If this aspect needs to be expanded, sure, let's do
>>>> this.
>>> TBH, I don't think that'd help, for me at least. I don't
>>> see any way in which such permanent strings representing
>>> identity can be defined to be usable as claimed and not
>>> be perniciously privacy invasive. So some promises to
>>> ponder the problem in charter text wouldn't do it for
>>> me. (And tbh, I've seen that can kicked down that road
>>> before, so I'm skeptical of such promises in general.)
>>>
>>>> Everyone seems to be jumping up and down regarding the use of the
>>>> term of "identity" as if a foregone conclusion that this is a synonym
>>>> for "privacy invasion".   However: - "Identity" does not imply
>>>> "personal identity".  Really, this is an identifier scheme for
>>>> endpoints.
>>> Sorry, what I assume is the relevant draft [1] says the "identity"
>>> (denoted "IDy") is a "Unique and Permanent Identity" and that
>>> "Networks may treat traffic differently depending on the IDy of
>>> source or destination" and also seems to envisage a large logical
>>> database of everyone's IDy's: "Identity also allows to have metadata
>>> associated it to be applied, regardless of which IDf is used to
>>> refer it." (Where IDf is the identifier that'll later be mapped
>>> to a locator via, I assume, HIP or LISP or similar.)
>>>
>>> I think it's entirely correct to jump up and down about the
>>> privacy consequences of the above. (Not to mention the potential
>>> censorship and discriminatory aspects.)
>>>
>>>      [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01
>>>
>>>> Perhaps even "identity" is a misnomer.
>>> Well, it was presumably your choice (where your == some set of
>>> the proponents). If that's a mistake, then it seems a fairly
>>> fatal one - to get the name wrong for an effort all about mapping
>>> names to identifiers;-)
>>>
>>>> If you will,
>>>> identity as conceived in the context of IDEAS is a second level of
>>>> identifier that does not have to be exposed over the data plane -
>>>> Because of this, it may result in greater privacy than existing
>>>> schemes, not less.
>>> I see that argument in [1] but I'm not buying it tbh. To get
>>> that level of protection from such an indirection, one would
>>> have to have something like Tor hidden services and perhaps
>>> one would have to *not* standardise the mapping from human
>>> meaningful identifiers to those used as IDf, and esp. not the
>>> reverse mapping. Defining that reverse mapping cannot but be
>>> privacy invasive afaics. (There could maybe be ways to define
>>> how an already hashed human meaningful identifier could then
>>> be further hashed to become an IDy but I don't really see the
>>> point of that at all, other than to just standardise something
>>> for the fun of the process.)
>>>
>>>> It enables you, for example, to obfuscate
>>>> endpoints to outside observers as you wouldn't need to use personal
>>>> unique long-lived identifiers, quite the contrary. - There is also a
>>>> security dimension here. If I am victim of a phishing attack because
>>>> my network information (like today) is exposed to botnets,
>>> (Nit: that says nothing about being a victim of, only of being
>>> a target of, an attempted attack. Speaking of victims also
>>> tends not to lead to more objective analysis, so I think it's
>>> better to not go there unless it's relevant, which I don't
>>> think is the case here, because...)
>>>
>>> I don't understand what network information you mean. If you
>>> mean email addresses, and are proposing that the email ecosystem
>>> change to use some IDf or LOC values, that doesn't seem at all
>>> realistic to me. If you don't mean email addresses then I don't
>>> see how any lower layer change will affect attempted phishes.
>>> The routing area is probably also the entirely wrong venue for
>>> any real anti-phishing effort.
>>>
>>> That really wasn't a good example;-)
>>>
>>>> phishers
>>>> etc who can hide from me (but not I from them) and remain anonymous
>>>> or impersonate legitimate users, I do consider this a very serious
>>>> threat also to my privacy.  How can IETF counteract such threats?  I
>>>> think that IDEAS, if done right, can provide a contribution here.
>>> I don't see that at all. Unless I'm mistaken that seems like
>>> wishful thinking to me.
>>>
>>>> One aspect that has been missing from the discussion is the question
>>>> whether there is a distinction between the network provider who
>>>> provides GRIDS services and an outside attacker / observer.  I think
>>>> this distinction is important.  The way I see it, if done right
>>>> (sure, big "if", and requiring detailed analysis), IDEAS as I would
>>>> envision it can contribute greatly to provide greater security and
>>>> privacy from outside attackers.  At the same time, as it is currently
>>>> envisioned, there clearly is a trust relationship between an entity
>>>> and the provider of "its" GRIDS services.  The mapping database will
>>>> have information about locator-identifier and identifier-identifier
>>>> mappings, so GRIDS will know which identifiers its endpoints are
>>>> using.  Clearly, if this trust is abused because the provider cannot
>>>> be trusted, if you are concerned that it sells your endpoint’s
>>>> information to the mob or a suppressive government, there is an
>>>> issue.  However, when concerned about this scenario, it seems to me
>>>> one would have equal reason to e.g. not trust your mobile service
>>>> provider either, who can track you, knows your location, and has your
>>>> customer data.
>>> ISTM that introducing that GRIDS thing makes matters worse and not
>>> better, because, as you yourself say, it is clear that whoever has
>>> access to the GRIDS information would be better able to track people
>>> compared to now.
>>>
>>> I would prefer to see fewer long lived identifiers in networking
>>> and not more, and this proposal introduces more long lived identifiers
>>> (erroneously calling those identities).
>>>
>>> Regardless of what one thinks of them, given that things like
>>> HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit
>>> adding this extra layer of indirection with a privacy invasive
>>> "Unique and Permanent" identifier which seems to be the only
>>> non-overlapping part of this work - in fact I only see downsides.
>>>
>>> Cheers,
>>> S.
>>>
>>>
>>>> --- Alex
>>>>
>>>>
>>>>> -----Original Message----- From: Ideas
>>>>> [mailto:ideas-bounces@ietf.org] On Behalf Of
>>>>> stephen.farrell@cs.tcd.ie Sent: Wednesday, October 04, 2017 9:35
>>>>> AM To: tom@herbertland.com Cc: ideas@ietf.org;
>>>>> phill@hallambaker.com; ietf@ietf.org Subject: Re: [Ideas] WG
>>>>> Review: IDentity Enabled Networks (ideas)
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, 4 October 2017, Tom Herbert wrote:
>>>>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker
>>>>>>  wrote:
>>>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> As currently described, I oppose creation of this working
>>>>>>>> group on the basis that it enables and seemingly encourages
>>>>>>>> embedding identifiers for humans as addresses. Doing so would
>>>>>>>> have significant privacy downsides, would enable new methods
>>>>>>>> for censorship and discrimination, and could be very hard to
>>>>>>>> mitigate should one wish to help protect people's privacy, as
>>>>>>>> I think is current IETF policy.
>>>>>>>>
>>>>>>>> If the work precluded the use of any identifiers that
>>>>>>>> strongly map to humans then I'd be ok with it being done as
>>>>>>>> it'd then only be a waste of resources. But I don't know how
>>>>>>>> that could be enforced so I think it'd be better to just not
>>>>>>>> do this work at all.
>>>>>>>>
>>>>>>>> S.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I know how to restrict the work to 'meaningless' identifiers,
>>>>>>> require that the identifiers be the output of a cryptographic
>>>>>>> algorithm.
>>>>>>>
>>>>>>> Now strictly speaking, this only limits scope to identifiers
>>>>>>> that are indexical as opposed to rendering them meaningless but
>>>>>>> I think that was the sense of it.
>>>>>>>
>>>>>>>
>>>>>>> Nöth proposed a trichotemy of identifiers as follows
>>>>>>>
>>>>>>> * Identity, the signifier is the signified (e.g. data: URI)
>>>>>>>
>>>>>>> * Indexical, the signifier is related to the signified by a
>>>>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP
>>>>>>> fingerprints etc.)
>>>>>>>
>>>>>>> * Names,  the signifier is the related to the signified by a
>>>>>>> purely conventional relationship, (e.g. example.com to its
>>>>>>> owner)
>>>>>>>
>>>>>>>
>>>>>>> There is a big difference between attempting to manage
>>>>>>> indexical signifiers and names. Especially when the people
>>>>>>> trying to do so refuse to read any of the literature on
>>>>>>> semiotics.
>>>>>>>
>>>>>>> Names are problematic because the only way that a conventional
>>>>>>> relationship can be implemented is through some sort of
>>>>>>> registration infrastructure and we already have one of those
>>>>>>> and the industry that manages it has a marketcap in the tens of
>>>>>>> billions.
>>>>>>>
>>>>>>> Identifiers do lead to tractable solutions. But, this proposal
>>>>>>> looks a bit unfocused for IRTF consideration, an IETF WG?
>>>>>>> Really?
>>>>>>>
>>>>>> Identifiers are equivalent to addresses in that they indicate a
>>>>>> node in the network for the purposes of end to end
>>>>>> communications. The only difference between identifiers and
>>>>>> addresses is that identifiers are not topological. Virtual
>>>>>> addresses in network virtualization are also identifiers. So the
>>>>>> security properties are the same when considering privacy. For
>>>>>> instance, if applications use temporary addresses for privacy, it
>>>>>> would have equivalent properties using temporary identifiers. In
>>>>>> fact from the application POV this would be transparent. It could
>>>>>> get a pool of apparently random addresses to choose from as
>>>>>> source of communication, it shouldn't know or even care if the
>>>>>> addresses are identifiers.
>>>>>>
>>>>>> Identity is a completely separate concept from identifiers. Is
>>>>>> not required in any of the identifier/locator protocols and AFAIK
>>>>>> none of them even mention the term. There is no association of an
>>>>>> identity of user behind and identifier any more than there is an
>>>>>> association of identity behind IP address. The fact that the
>>>>>> words "identifier" and "identity" share a common prefix is an
>>>>>> unfortunate happenstance :-).
>>>>>
>>>>> Yes. But doesn't that mean either the name of this effort is wildly
>>>>> misleading or else the effort is hugely problematic from a privacy
>>>>> POV? Either way, istm this ought not proceed.
>>>>>
>>>>> S.
>>>>>
>>>>>> Tom
>>>>>>
>>>>> _______________________________________________ Ideas mailing list
>>>>> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas
>>> _______________________________________________
>>> Ideas mailing list
>>> Ideas@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ideas
>> .
>>
>


From nobody Wed Oct 11 08:17:51 2017
Return-Path: 
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 3214613339A; Wed, 11 Oct 2017 08:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MMxXIw7EOF6S; Wed, 11 Oct 2017 08:17:38 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4511332CE; Wed, 11 Oct 2017 08:17:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 90E2162169; Wed, 11 Oct 2017 11:17:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p0buDVjXYpkx; Wed, 11 Oct 2017 11:17:34 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C87916216C; Wed, 11 Oct 2017 11:17:31 -0400 (EDT)
To: S Moonesamy , Uma Chunduri 
Cc: ideas@ietf.org, ietf@ietf.org
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>  <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> <6.2.5.6.2.20171009124208.0f3a8ed8@elandnews.com>
From: Robert Moskowitz 
Message-ID: 
Date: Wed, 11 Oct 2017 11:17:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6.2.5.6.2.20171009124208.0f3a8ed8@elandnews.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 15:17:42 -0000

On 10/09/2017 04:08 PM, S Moonesamy wrote:
> Hi Uma,
> At 10:14 AM 09-10-2017, Uma Chunduri wrote:
>> [Uma]: I am not sure what do you mean by "Privacy requirements 
>> redefined".  Today in
>
> I was commenting on the text from the proposed charter.  There are one 
> or more RFCs which discusses about privacy.
>
>> [Uma]: What's  the relevance of the same here.  IDEAS is not seeking 
>> to change any type of LOC information used in ID/LOC protocols... 
>> this is governed by ID/LOC protocol in use. It could be IPv4 or 
>> (mostly) IPv6.
>>                IDEAS doesn't alter or won't come into picture outside 
>> of ID/LOC protocol context.
>
> If the IETF were to decide that it will stop doing IPv4 work except 
> for maintenance, should the working group be allowed to add in support 
> for IPv4?

Unfortunately, a technology that intentionally breaks IPv4 will not get 
deployed.  It needs to give a 'nod' to backwards compatiblity. A part of 
me would really like to come up with the 'killer protocol' that everyone 
needs but just can't EVER be made to work with IPv4, so sorry world, you 
just have to get over it (IPv4).  If you want something to fit into 
factories, you have to work around IPv4.  It will be interesting to see 
how 6TISCH works out there (with 4in6?)...

Bob


From nobody Wed Oct 11 09:16:09 2017
Return-Path: 
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 A59FB13202D for ; Wed, 11 Oct 2017 09:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 esJV745_Kdrq for ; Wed, 11 Oct 2017 09:16:06 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EB8134293 for ; Wed, 11 Oct 2017 09:16:05 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e2Jfv-0002lc-3p for ideas@ietf.org; Wed, 11 Oct 2017 18:16:04 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e2Jfs-0004h2-M4 for ideas@ietf.org; Wed, 11 Oct 2017 12:16:01 -0400
Received: (qmail 29808 invoked from network); 11 Oct 2017 16:15:59 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.26]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Oct 2017 16:15:58 -0000
To: Robert Moskowitz , Brian E Carpenter , Dino Farinacci 
Cc: "ideas@ietf.org" , "ietf@ietf.org" , "lisp@ietf.org list" 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> 
From: Christian Huitema 
Message-ID: 
Date: Wed, 11 Oct 2017 09:15:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------92B9B6E8D99A2797A6DF8518"
Content-Language: en-US
X-Originating-IP: 168.144.250.230
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.26)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5nt2WKbMNDUxhDfjWr63rHQXv9krsgRhBn0ayn6qsUc7p7He3a39gjg/ 9oOEoAajC61PdOWeIW8R8TgUu5HhPnLvU34AIGAPTAurSGpeYPBrTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz5TPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+OlqTWdUBHTyoJG+mqGBYi8bWhnKPmUW/oWx9V3wTBfG4Y+ZnfomCI+rgOtA8u12EwuwjY+ quNh23liqqeOwMwwqy4lE5s79uoGaeHjfOqnzPcqs5RcLqZ0NIAm9sCHr2eyNIkhDia+jiI1x+25 WhJqOf3+cMSJJ9Vk8Y6lSpImWOFtQUIkkMAnR5eEArf6zd8XhA0UizXQaOxPdjju+1r1qq9IJIue NdZ12JJe7t4cD3McN6qoXPjenLhIOF1oeRblTmB8yAD5l+TFYh5LfUT7zCwgjlYquyZL172GCMIx Azov5QJXcIJIVSSZ2lmGoFzGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAInD3q08gexeH56OZWSJPgEONoJfh+XjGSeeT90H/uIHh 9CIcA3vy4ZVtV9mI7OCgwpqCLNTK5hdImtbQi8Hm7GbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWWMqPnh3oWYEaqVdFM1yo4PfFcHV2tQAVqGdj/zM7G/GvAlpVif2edmNpSuMMbNDZ5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 16:16:08 -0000

This is a multi-part message in MIME format.
--------------92B9B6E8D99A2797A6DF8518
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 10/11/2017 7:56 AM, Robert Moskowitz wrote:

>> and 'identity' is a red flag.
>
> Whow there!=C2=A0 You were part of the Namespace Research Group?=C2=A0 =
I think?=C2=A0
> I was and we we worked a lot on this and came to the conclusion that
> there could be no conclusion.=C2=A0 Not even a rough concensus, it seem=
ed.
>
> I have been using 'identity' to apply to things for 20 years. Pretty
> much ever since I started working with things.=C2=A0 Anyone that holds =
the
> position that 'identity' means we are talking only about people are
> allowing their thinking to be clouded.=20

I am concerned that the current proponents of the IDEAS work are mainly
resisting the feedback, treating it as some roadblock put in the path of
their work by misguided privacy purists, and attempting to remove the
roadblocks by adding some weasel words to the charter. I would feel much
more confident if these proponents acknowledged the tension between
privacy and stable identifiers of any sort, if that tension was clearly
noted in the charter, and if privacy goals were clearly stated.

Specifically, I think there is a contradiction between some of
documents. For example, draft-padma-ideas-problem-statement-01 states tha=
t:

   o  A single entity may have multiple IDs, and IDs of the same entity
      may have different life spans that are different from the lifespan
      of the entity.  Furthermore, it is understood that IDs may have
      different lifecycles, which may be permanent or ephemeral by
      choice or design.

   o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
      for a permanent ID to protect the privacy of the related entity.

But then, draft-ccm-ideas-identity-use-cases-01 states that:

   a.  Unique and Permanent Identity representing the entity enables
       authentication (AUTH) with the mapping and Identity services
       infrastructure.  While it is possible to do AUTH on Identifiers
       those are not permanently associated to the entity.  Moreover,
       AUTH operation is a relatively an expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for lot of applications.

The tension is obvious. On one hand, the ephemeral identifiers envisaged
in the problem statement would pretty much align the privacy properties
of the ID to those of IPv6 privacy addresses, and that's good. On the
other hand, the requirement to perform authentication on identities
completely negates that property.

I would be fine if the support for "Unique and Permanent Identity" was
explicitly excluded from the charter. There is obviously a need to
support some form of access control to a mapping database, but you do
not need a reference to a permanent identity for that -- systems similar
to CGA would work just fine.

--=20
Christian Huitema


--------------92B9B6E8D99A2797A6DF8518
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/11/2017 7:56 AM, Robert Moskowitz wrote:

    

    

      
and 'identity' is
        a red flag.
        

      

      

      Whow there!  You were part of the Namespace Research Group?  I
      think?  I was and we we worked a lot on this and came to the
      conclusion that there could be no conclusion.  Not even a rough
      concensus, it seemed.
      

      

      I have been using 'identity' to apply to things for 20 years.
      Pretty much ever since I started working with things.  Anyone that
      holds the position that 'identity' means we are talking only about
      people are allowing their thinking to be clouded.
    

    

    I am concerned that the current proponents of the IDEAS work are
    mainly resisting the feedback, treating it as some roadblock put in
    the path of their work by misguided privacy purists, and attempting
    to remove the roadblocks by adding some weasel words to the charter.
    I would feel much more confident if these proponents acknowledged
    the tension between privacy and stable identifiers of any sort, if
    that tension was clearly noted in the charter, and if privacy goals
    were clearly stated. 

    

    Specifically, I think there is a contradiction between some of
    documents. For example, draft-padma-ideas-problem-statement-01
    states that:

    
   o  A single entity may have multiple IDs, and IDs of the same entity
      may have different life spans that are different from the lifespan
      of the entity.  Furthermore, it is understood that IDs may have
      different lifecycles, which may be permanent or ephemeral by
      choice or design.

   o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
      for a permanent ID to protect the privacy of the related entity.

    But then, draft-ccm-ideas-identity-use-cases-01 states that:

    
   a.  Unique and Permanent Identity representing the entity enables
       authentication (AUTH) with the mapping and Identity services
       infrastructure.  While it is possible to do AUTH on Identifiers
       those are not permanently associated to the entity.  Moreover,
       AUTH operation is a relatively an expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for lot of applications.



    The tension is obvious. On one hand, the ephemeral identifiers
    envisaged in the problem statement would pretty much align the
    privacy properties of the ID to those of IPv6 privacy addresses, and
    that's good. On the other hand, the requirement to perform
    authentication on identities completely negates that property.

    

    I would be fine if the support for "Unique and Permanent Identity"
    was explicitly excluded from the charter. There is obviously a need
    to support some form of access control to a mapping database, but
    you do not need a reference to a permanent identity for that --
    systems similar to CGA would work just fine.

    

    
-- 
Christian Huitema

  


--------------92B9B6E8D99A2797A6DF8518--


From nobody Wed Oct 11 10:32:57 2017
Return-Path: 
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 C823A12895E; Wed, 11 Oct 2017 10:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 imUUCu4xJ5PL; Wed, 11 Oct 2017 10:32:47 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 2BFB2126DD9; Wed, 11 Oct 2017 10:32:47 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id q124so6799787wmb.0; Wed, 11 Oct 2017 10:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rvYsW/4Tk2d7QtfMqQn7wYR4YILkyYS/TaHSOsMbsuc=; b=dYXP+DhKoOq6VgJxSYzzwDAWZyc7WmgaJkUDg5Qv7ZZNuMtUr9ZOWNnVObQHEuXrsV TkVpAjcNwiEL1Pyj3Hew5bExedO0DLNTaM6MCbH417o4VKPBf5QcZUslEygFkqzofmao 43KXnZOV7Mrd1VSogIJ+RsFnxUl4EYHbTNwfKKikEHabwE4CSb1IMLBR30wmjLU/cF1Q onp8shWy/OvNc9da2Z754hAySV7ezEynxzd95/riFVqs2I7JZHe+7PBHGHdj077hf1wh LidLoj0SysvLcdogEUl0k5DtVUtJP3gIabPmNza86f8+zs5NeCYrsUScEhp8dydhDfTq 1+tw==
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=rvYsW/4Tk2d7QtfMqQn7wYR4YILkyYS/TaHSOsMbsuc=; b=ZxaESS0cx00Jdm4rKnpTXizLx490vLfEeSfhaw+haYAkaykRVgvQsG+hnNI/gLhrH8 3sipoMkkQ3k9RpU5XMphVNaY8ezveL7zmi937CizFY3Jz+S10/2p85VrXzc2Cif42Deg QkYLZ/2jep/4TwZK253cTqFWVttVr2HVFElYAwou9qmJ57ocO626Q0IY70Zj5a+cQrCJ p4yLpaZlmSUNgylyJ91RN3a66tBHRL1aaYYhHC02Kr5bMezoaZddKNUebxDE5FAC0VzQ H0aSSwC+ZBUOE1ktfUW67c3b3mugPusX0SrRoJsotdnz3+I8uxw9gFSjJ3DRdvrc+Wjy iHAg==
X-Gm-Message-State: AMCzsaU2h/RyWsiFyYxNsy/Z/TccN9cRlyRqNcRP8DX5wo6MlnajCnio wpVP/grHG4EBYUUl08we6XdnSYMxIOkl2AVXAGE=
X-Google-Smtp-Source: AOwi7QDOoPEc+JmW8HJqlgoWm4bmg2WKrunbAWx5HgGormDJkg1OSfL3G+SuaAGlKeawZ6KPl9AiaqM3Mtbb+LlJgA0=
X-Received: by 10.223.173.175 with SMTP id w44mr327153wrc.19.1507743165659; Wed, 11 Oct 2017 10:32:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Wed, 11 Oct 2017 10:32:44 -0700 (PDT)
In-Reply-To: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>  
From: Padma Pillay-Esnault 
Date: Wed, 11 Oct 2017 10:32:44 -0700
Message-ID: 
To: Christian Huitema 
Cc: Robert Moskowitz ,  Brian E Carpenter , Dino Farinacci ,  "ideas@ietf.org" , "ietf@ietf.org" , "lisp@ietf.org list" 
Content-Type: multipart/alternative; boundary="f403045ceff2cd3fef055b48cf14"
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 17:32:50 -0000

--f403045ceff2cd3fef055b48cf14
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema 
wrote:

> On 10/11/2017 7:56 AM, Robert Moskowitz wrote:
>
> and 'identity' is a red flag.
>
>
> Whow there!  You were part of the Namespace Research Group?  I think?  I
> was and we we worked a lot on this and came to the conclusion that there
> could be no conclusion.  Not even a rough concensus, it seemed.
>
> I have been using 'identity' to apply to things for 20 years. Pretty much
> ever since I started working with things.  Anyone that holds the position
> that 'identity' means we are talking only about people are allowing their
> thinking to be clouded.
>
>
> I am concerned that the current proponents of the IDEAS work are mainly
> resisting the feedback, treating it as some roadblock put in the path of
> their work by misguided privacy purists, and attempting to remove the
> roadblocks by adding some weasel words to the charter. I would feel much
> more confident if these proponents acknowledged the tension between privacy
> and stable identifiers of any sort, if that tension was clearly noted in
> the charter, and if privacy goals were clearly stated.
>
>
As one of the proponents, I feel I need to speak up because blanket
statements are just not helping.

Speaking on behalf of my fellow proponents, we have always welcomed
constructive feedback from people who want/can contribute and make the
technology better. We have been willing to clarify the charter
(clarification does not mean weaseling).

If it is helpful to  move forward, I am willing to volunteer for this work
and discuss with anyone to ensure constructive feedback and comments are
addressed.


Specifically, I think there is a contradiction between some of documents.
> For example, draft-padma-ideas-problem-statement-01 states that:
>
>    o  A single entity may have multiple IDs, and IDs of the same entity
>       may have different life spans that are different from the lifespan
>       of the entity.  Furthermore, it is understood that IDs may have
>       different lifecycles, which may be permanent or ephemeral by
>       choice or design.
>
>    o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
>       for a permanent ID to protect the privacy of the related entity.
>
> But then, draft-ccm-ideas-identity-use-cases-01 states that:
>
>    a.  Unique and Permanent Identity representing the entity enables
>        authentication (AUTH) with the mapping and Identity services
>        infrastructure.  While it is possible to do AUTH on Identifiers
>        those are not permanently associated to the entity.  Moreover,
>        AUTH operation is a relatively an expensive and inefficient
>        procedure (compared to LOC resolution for example) and can cause
>        excessive startup delays for lot of applications.
>
>
>
As said earlier this draft was not updated by the authors and a new version
was posted yesterday.

https://www.ietf.org/mail-archive/web/ideas/current/msg00520.html



> The tension is obvious. On one hand, the ephemeral identifiers envisaged
> in the problem statement would pretty much align the privacy properties of
> the ID to those of IPv6 privacy addresses, and that's good. On the other
> hand, the requirement to perform authentication on identities completely
> negates that property.
>
> I would be fine if the support for "Unique and Permanent Identity" was
> explicitly excluded from the charter.
>

AFAIK, none of the proponents resisted that.


> There is obviously a need to support some form of access control to a
> mapping database,
>

Agreed.


> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
>


The identity of the device is just adding a lever of identifier which
effectively allows authentication to modify the identifiers used by that
device but also what the users of these identifiers can look up. If we had
used "user of identifier" it would have been misconstrued for humans. So
damn if you do and damn if you don't ...

We are open for discussions anytime.

Padma



>
> --
> Christian Huitema
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>
>

--f403045ceff2cd3fef055b48cf14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema &l=
t;huitema@huitema.=
net> wrote:

 =20
   =20
 =20
  

    
On 10/11/2017 7:56 AM, Robert Moskowitz wrote:

    

    

      
and 'identit=
y' is
        a red flag.
        

      

      

      Whow there!=C2=A0 You were part of the Namespace Research Group?=C2=
=A0 I
      think?=C2=A0 I was and we we worked a lot on this and came to the
      conclusion that there could be no conclusion.=C2=A0 Not even a rough
      concensus, it seemed.
      

      

      I have been using 'identity' to apply to things for 20 years.
      Pretty much ever since I started working with things.=C2=A0 Anyone th=
at
      holds the position that 'identity' means we are talking only =
about
      people are allowing their thinking to be clouded.
    

    

    I am concerned that the current proponents of the IDEAS work are
    mainly resisting the feedback, treating it as some roadblock put in
    the path of their work by misguided privacy purists, and attempting
    to remove the roadblocks by adding some weasel words to the charter.
    I would feel much more confident if these proponents acknowledged
    the tension between privacy and stable identifiers of any sort, if
    that tension was clearly noted in the charter, and if privacy goals
    were clearly stated. 

    

As one of the proponents, I =
feel I need to speak up because blanket statements are just not helping.=C2=
=A0

Speaking on behalf of my fellow proponents, we=
 have always welcomed constructive feedback from people who want/can contri=
bute and make the technology better. We have been willing to clarify the ch=
arter (clarification does not mean weaseling).=C2=A0

If it is helpful to =C2=A0move forward, I am willing to volunteer for th=
is work and discuss with anyone to ensure constructive feedback and comment=
s are addressed.



    Specifically, I think there is a contradiction between some of
    documents. For example, draft-padma-ideas-problem-statement-01
    states that:

    
   o  A single entity may have multiple IDs, a=
nd IDs of the same entity
      may have different life spans that are different from the lifespan
      of the entity.  Furthermore, it is understood that IDs may have
      different lifecycles, which may be permanent or ephemeral by
      choice or design.

   o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
      for a permanent ID to protect the privacy of the related entity.
    But then, draft-ccm-ideas-identity-use-cases-01 states that:

    
   a.  Unique and Permanent Identity represent=
ing the entity enables
       authentication (AUTH) with the mapping and Identity services
       infrastructure.  While it is possible to do AUTH on Identifiers
       those are not permanently associated to the entity.  Moreover,
       AUTH operation is a relatively an expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for lot of applications.



    

As said earlier this draft was n=
ot updated by the authors and a new version was posted yesterday.


=C2=A0
The tension is obvious. On one hand, the ephemeral id=
entifiers
    envisaged in the problem statement would pretty much align the
    privacy properties of the ID to those of IPv6 privacy addresses, and
    that's good. On the other hand, the requirement to perform
    authentication on identities completely negates that property.

    

    I would be fine if the support for "Unique and Permanent Identity&=
quot;
    was explicitly excluded from the charter. 

<=
/div>
AFAIK, none of the proponents resisted that.
=C2=A0
There is obviously a need
    to support some form of access control to a mapping database, 

Agreed.
=C2=A0
but
    you do not need a reference to a permanent identity for that --
    systems similar to CGA would work just fine.
=C2=
=A0

The identity of the device is just adding =
a lever of identifier which effectively allows authentication to modify the=
 identifiers used by that device but also what the users of these identifie=
rs can look up. If we had used "user of identifier" it would have=
 been misconstrued for humans. So damn if you do and damn if you don't =
...=C2=A0

We are open for discussions anytime.

Padma




    

    
--=20
Christian Huitema

  



_______________________________________________

lisp mailing list

lisp@ietf.org

https://www.ietf.org/mailman/listinfo/lisp





--f403045ceff2cd3fef055b48cf14--


From nobody Wed Oct 11 11:48:11 2017
Return-Path: 
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 425F91331D7; Wed, 11 Oct 2017 11:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zSScPSDkL436; Wed, 11 Oct 2017 11:48:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388941331DD; Wed, 11 Oct 2017 11:48:00 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXJ38193; Wed, 11 Oct 2017 18:47:58 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Oct 2017 19:47:57 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Wed, 11 Oct 2017 11:47:54 -0700
From: Alexander Clemm 
To: Padma Pillay-Esnault , Christian Huitema 
CC: "ideas@ietf.org" , "lisp@ietf.org list" , Dino Farinacci , Robert Moskowitz , Brian E Carpenter , "ietf@ietf.org" 
Thread-Topic: [Ideas] [lisp]  WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTQrcK0eH/tmmnfEmavTiozjDgVKLe+kVA
Date: Wed, 11 Oct 2017 18:47:52 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8E6D@sjceml521-mbx.china.huawei.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.142]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8E6Dsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59DE675E.0237, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 846096c927bee242d3d60c086cccb0f6
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 18:48:04 -0000

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8E6Dsjceml521mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VHdvIGFkZGl0aW9uYWwgdGhvdWdodHMgaW5saW5lLCA8QUxFWD4NCg0KRnJvbTogSWRlYXMgW21h
aWx0bzppZGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGFkbWEgUGlsbGF5LUVz
bmF1bHQNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMSwgMjAxNyAxMDozMyBBTQ0KVG86IENo
cmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KQ2M6IGlkZWFzQGlldGYub3Jn
OyBsaXNwQGlldGYub3JnIGxpc3QgPGxpc3BAaWV0Zi5vcmc+OyBEaW5vIEZhcmluYWNjaSA8ZmFy
aW5hY2NpQGdtYWlsLmNvbT47IFJvYmVydCBNb3Nrb3dpdHogPHJnbS1pZXRmQGh0dC1jb25zdWx0
LmNvbT47IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBp
ZXRmQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkZWFzXSBbbGlzcF0gV0cgUmV2aWV3OiBJRGVu
dGl0eSBFbmFibGVkIE5ldHdvcmtzIChpZGVhcykNCg0KDQoNCk9uIFdlZCwgT2N0IDExLCAyMDE3
IGF0IDk6MTUgQU0sIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0
bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4gd3JvdGU6DQoNCk9uIDEwLzExLzIwMTcgNzo1NiBBTSwg
Um9iZXJ0IE1vc2tvd2l0eiB3cm90ZToNCmFuZCAnaWRlbnRpdHknIGlzIGEgcmVkIGZsYWcuDQoN
Cldob3cgdGhlcmUhICBZb3Ugd2VyZSBwYXJ0IG9mIHRoZSBOYW1lc3BhY2UgUmVzZWFyY2ggR3Jv
dXA/ICBJIHRoaW5rPyAgSSB3YXMgYW5kIHdlIHdlIHdvcmtlZCBhIGxvdCBvbiB0aGlzIGFuZCBj
YW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlcmUgY291bGQgYmUgbm8gY29uY2x1c2lvbi4g
IE5vdCBldmVuIGEgcm91Z2ggY29uY2Vuc3VzLCBpdCBzZWVtZWQuDQoNCkkgaGF2ZSBiZWVuIHVz
aW5nICdpZGVudGl0eScgdG8gYXBwbHkgdG8gdGhpbmdzIGZvciAyMCB5ZWFycy4gUHJldHR5IG11
Y2ggZXZlciBzaW5jZSBJIHN0YXJ0ZWQgd29ya2luZyB3aXRoIHRoaW5ncy4gIEFueW9uZSB0aGF0
IGhvbGRzIHRoZSBwb3NpdGlvbiB0aGF0ICdpZGVudGl0eScgbWVhbnMgd2UgYXJlIHRhbGtpbmcg
b25seSBhYm91dCBwZW9wbGUgYXJlIGFsbG93aW5nIHRoZWlyIHRoaW5raW5nIHRvIGJlIGNsb3Vk
ZWQuDQoNCkkgYW0gY29uY2VybmVkIHRoYXQgdGhlIGN1cnJlbnQgcHJvcG9uZW50cyBvZiB0aGUg
SURFQVMgd29yayBhcmUgbWFpbmx5IHJlc2lzdGluZyB0aGUgZmVlZGJhY2ssIHRyZWF0aW5nIGl0
IGFzIHNvbWUgcm9hZGJsb2NrIHB1dCBpbiB0aGUgcGF0aCBvZiB0aGVpciB3b3JrIGJ5IG1pc2d1
aWRlZCBwcml2YWN5IHB1cmlzdHMsIGFuZCBhdHRlbXB0aW5nIHRvIHJlbW92ZSB0aGUgcm9hZGJs
b2NrcyBieSBhZGRpbmcgc29tZSB3ZWFzZWwgd29yZHMgdG8gdGhlIGNoYXJ0ZXIuIEkgd291bGQg
ZmVlbCBtdWNoIG1vcmUgY29uZmlkZW50IGlmIHRoZXNlIHByb3BvbmVudHMgYWNrbm93bGVkZ2Vk
IHRoZSB0ZW5zaW9uIGJldHdlZW4gcHJpdmFjeSBhbmQgc3RhYmxlIGlkZW50aWZpZXJzIG9mIGFu
eSBzb3J0LCBpZiB0aGF0IHRlbnNpb24gd2FzIGNsZWFybHkgbm90ZWQgaW4gdGhlIGNoYXJ0ZXIs
IGFuZCBpZiBwcml2YWN5IGdvYWxzIHdlcmUgY2xlYXJseSBzdGF0ZWQuDQoNCkFzIG9uZSBvZiB0
aGUgcHJvcG9uZW50cywgSSBmZWVsIEkgbmVlZCB0byBzcGVhayB1cCBiZWNhdXNlIGJsYW5rZXQg
c3RhdGVtZW50cyBhcmUganVzdCBub3QgaGVscGluZy4NCg0KU3BlYWtpbmcgb24gYmVoYWxmIG9m
IG15IGZlbGxvdyBwcm9wb25lbnRzLCB3ZSBoYXZlIGFsd2F5cyB3ZWxjb21lZCBjb25zdHJ1Y3Rp
dmUgZmVlZGJhY2sgZnJvbSBwZW9wbGUgd2hvIHdhbnQvY2FuIGNvbnRyaWJ1dGUgYW5kIG1ha2Ug
dGhlIHRlY2hub2xvZ3kgYmV0dGVyLiBXZSBoYXZlIGJlZW4gd2lsbGluZyB0byBjbGFyaWZ5IHRo
ZSBjaGFydGVyIChjbGFyaWZpY2F0aW9uIGRvZXMgbm90IG1lYW4gd2Vhc2VsaW5nKS4NCg0KSWYg
aXQgaXMgaGVscGZ1bCB0byAgbW92ZSBmb3J3YXJkLCBJIGFtIHdpbGxpbmcgdG8gdm9sdW50ZWVy
IGZvciB0aGlzIHdvcmsgYW5kIGRpc2N1c3Mgd2l0aCBhbnlvbmUgdG8gZW5zdXJlIGNvbnN0cnVj
dGl2ZSBmZWVkYmFjayBhbmQgY29tbWVudHMgYXJlIGFkZHJlc3NlZC4NCg0KPEFMRVg+ICsxIG9u
IHdlbGNvbWluZyBjb25zdHJ1Y3RpdmUgZmVlZGJhY2suICBUbyBpbmNvcnBvcmF0ZSBpdCB3ZSBu
ZWVkIHRvIHVwZGF0ZSBkb2N1bWVudHMuICBBbiB1cGRhdGUgdG8gdGhlIGNjbSB1c2UgY2FzZSBk
b2N1bWVudCB3YXMgcG9zdGVkIHllc3RlcmRheSAocmV2IC0wMikgd2hpY2ggaW5jb3Jwb3JhdGVz
IGEgbG90IG9mIHRoZSBmZWVkYmFjayBnaXZlbi4gIENsZWFybHksIHRoaXMgd2lsbCBub3QgYmUg
dGhlIGxhc3QgdXBkYXRlIGFuZCBvdGhlciBkb2N1bWVudHMgbmVlZCB0byBmb2xsb3cuDQo8L0FM
RVg+DQoNCg0KU3BlY2lmaWNhbGx5LCBJIHRoaW5rIHRoZXJlIGlzIGEgY29udHJhZGljdGlvbiBi
ZXR3ZWVuIHNvbWUgb2YgZG9jdW1lbnRzLiBGb3IgZXhhbXBsZSwgZHJhZnQtcGFkbWEtaWRlYXMt
cHJvYmxlbS1zdGF0ZW1lbnQtMDEgc3RhdGVzIHRoYXQ6DQoNCiAgIG8gIEEgc2luZ2xlIGVudGl0
eSBtYXkgaGF2ZSBtdWx0aXBsZSBJRHMsIGFuZCBJRHMgb2YgdGhlIHNhbWUgZW50aXR5DQoNCiAg
ICAgIG1heSBoYXZlIGRpZmZlcmVudCBsaWZlIHNwYW5zIHRoYXQgYXJlIGRpZmZlcmVudCBmcm9t
IHRoZSBsaWZlc3Bhbg0KDQogICAgICBvZiB0aGUgZW50aXR5LiAgRnVydGhlcm1vcmUsIGl0IGlz
IHVuZGVyc3Rvb2QgdGhhdCBJRHMgbWF5IGhhdmUNCg0KICAgICAgZGlmZmVyZW50IGxpZmVjeWNs
ZXMsIHdoaWNoIG1heSBiZSBwZXJtYW5lbnQgb3IgZXBoZW1lcmFsIGJ5DQoNCiAgICAgIGNob2lj
ZSBvciBkZXNpZ24uDQoNCg0KDQogICBvICBFcGhlbWVyYWwgKHRlbXBvcmFyeSkgSURzIG1heSBi
ZSB1c2VkIGFzIGEgc2hvcnQtbGl2ZWQgcHNldWRvbnltDQoNCiAgICAgIGZvciBhIHBlcm1hbmVu
dCBJRCB0byBwcm90ZWN0IHRoZSBwcml2YWN5IG9mIHRoZSByZWxhdGVkIGVudGl0eS4NCkJ1dCB0
aGVuLCBkcmFmdC1jY20taWRlYXMtaWRlbnRpdHktdXNlLWNhc2VzLTAxIHN0YXRlcyB0aGF0Og0K
DQogICBhLiAgVW5pcXVlIGFuZCBQZXJtYW5lbnQgSWRlbnRpdHkgcmVwcmVzZW50aW5nIHRoZSBl
bnRpdHkgZW5hYmxlcw0KDQogICAgICAgYXV0aGVudGljYXRpb24gKEFVVEgpIHdpdGggdGhlIG1h
cHBpbmcgYW5kIElkZW50aXR5IHNlcnZpY2VzDQoNCiAgICAgICBpbmZyYXN0cnVjdHVyZS4gIFdo
aWxlIGl0IGlzIHBvc3NpYmxlIHRvIGRvIEFVVEggb24gSWRlbnRpZmllcnMNCg0KICAgICAgIHRo
b3NlIGFyZSBub3QgcGVybWFuZW50bHkgYXNzb2NpYXRlZCB0byB0aGUgZW50aXR5LiAgTW9yZW92
ZXIsDQoNCiAgICAgICBBVVRIIG9wZXJhdGlvbiBpcyBhIHJlbGF0aXZlbHkgYW4gZXhwZW5zaXZl
IGFuZCBpbmVmZmljaWVudA0KDQogICAgICAgcHJvY2VkdXJlIChjb21wYXJlZCB0byBMT0MgcmVz
b2x1dGlvbiBmb3IgZXhhbXBsZSkgYW5kIGNhbiBjYXVzZQ0KDQogICAgICAgZXhjZXNzaXZlIHN0
YXJ0dXAgZGVsYXlzIGZvciBsb3Qgb2YgYXBwbGljYXRpb25zLg0KDQoNCg0KQXMgc2FpZCBlYXJs
aWVyIHRoaXMgZHJhZnQgd2FzIG5vdCB1cGRhdGVkIGJ5IHRoZSBhdXRob3JzIGFuZCBhIG5ldyB2
ZXJzaW9uIHdhcyBwb3N0ZWQgeWVzdGVyZGF5Lg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
LWFyY2hpdmUvd2ViL2lkZWFzL2N1cnJlbnQvbXNnMDA1MjAuaHRtbA0KDQo8QUxFWD4gSSB0aGlu
ayB5b3UgbWVhbnQgdG8gc2F5IGl0ICp3YXMqIHVwZGF0ZWQgOy0pDQpkcmFmdC1wYWRtYS1pZGVh
cy1wcm9ibGVtLXN0YXRlbWVudCB3aWxsIHByZXN1bWFibHkgYmUgb25lIG9mIHRoZSBkb2N1bWVu
dHMgdGhhdCBhcmUgbmV4dCBpbiBsaW5lIGZvciB1cGRhdGluZy4gIDwvQUxFWD4NCg0KVGhlIHRl
bnNpb24gaXMgb2J2aW91cy4gT24gb25lIGhhbmQsIHRoZSBlcGhlbWVyYWwgaWRlbnRpZmllcnMg
ZW52aXNhZ2VkIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB3b3VsZCBwcmV0dHkgbXVjaCBhbGln
biB0aGUgcHJpdmFjeSBwcm9wZXJ0aWVzIG9mIHRoZSBJRCB0byB0aG9zZSBvZiBJUHY2IHByaXZh
Y3kgYWRkcmVzc2VzLCBhbmQgdGhhdCdzIGdvb2QuIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgcmVx
dWlyZW1lbnQgdG8gcGVyZm9ybSBhdXRoZW50aWNhdGlvbiBvbiBpZGVudGl0aWVzIGNvbXBsZXRl
bHkgbmVnYXRlcyB0aGF0IHByb3BlcnR5Lg0KDQpJIHdvdWxkIGJlIGZpbmUgaWYgdGhlIHN1cHBv
cnQgZm9yICJVbmlxdWUgYW5kIFBlcm1hbmVudCBJZGVudGl0eSIgd2FzIGV4cGxpY2l0bHkgZXhj
bHVkZWQgZnJvbSB0aGUgY2hhcnRlci4NCg0KQUZBSUssIG5vbmUgb2YgdGhlIHByb3BvbmVudHMg
cmVzaXN0ZWQgdGhhdC4NCg0KVGhlcmUgaXMgb2J2aW91c2x5IGEgbmVlZCB0byBzdXBwb3J0IHNv
bWUgZm9ybSBvZiBhY2Nlc3MgY29udHJvbCB0byBhIG1hcHBpbmcgZGF0YWJhc2UsDQoNCkFncmVl
ZC4NCg0KYnV0IHlvdSBkbyBub3QgbmVlZCBhIHJlZmVyZW5jZSB0byBhIHBlcm1hbmVudCBpZGVu
dGl0eSBmb3IgdGhhdCAtLSBzeXN0ZW1zIHNpbWlsYXIgdG8gQ0dBIHdvdWxkIHdvcmsganVzdCBm
aW5lLg0KDQoNClRoZSBpZGVudGl0eSBvZiB0aGUgZGV2aWNlIGlzIGp1c3QgYWRkaW5nIGEgbGV2
ZXIgb2YgaWRlbnRpZmllciB3aGljaCBlZmZlY3RpdmVseSBhbGxvd3MgYXV0aGVudGljYXRpb24g
dG8gbW9kaWZ5IHRoZSBpZGVudGlmaWVycyB1c2VkIGJ5IHRoYXQgZGV2aWNlIGJ1dCBhbHNvIHdo
YXQgdGhlIHVzZXJzIG9mIHRoZXNlIGlkZW50aWZpZXJzIGNhbiBsb29rIHVwLiBJZiB3ZSBoYWQg
dXNlZCAidXNlciBvZiBpZGVudGlmaWVyIiBpdCB3b3VsZCBoYXZlIGJlZW4gbWlzY29uc3RydWVk
IGZvciBodW1hbnMuIFNvIGRhbW4gaWYgeW91IGRvIGFuZCBkYW1uIGlmIHlvdSBkb24ndCAuLi4N
Cg0KV2UgYXJlIG9wZW4gZm9yIGRpc2N1c3Npb25zIGFueXRpbWUuDQoNClBhZG1hDQoNCg0KDQoN
Cg0KDQotLQ0KDQpDaHJpc3RpYW4gSHVpdGVtYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KbGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BAaWV0Zi5vcmc8
bWFpbHRvOmxpc3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2xpc3ANCg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8E6Dsjceml521mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6
MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CnNwYW4uZ21haWwtbTI1NjA5NDU2NjUzNTgyODg5OTFtLTgyNzk0ODY0OTcxNDEyNTU1MzRnbWFp
bC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8yNTYwOTQ1NjY1MzU4Mjg4OTkxbV8tODI3OTQ4
NjQ5NzE0MTI1NTUzNGdtYWlsLTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD
b25zb2xhczt9DQpzcGFuLmdtYWlsLW0yNTYwOTQ1NjY1MzU4Mjg4OTkxbS04Mjc5NDg2NDk3MTQx
MjU1NTM0Z21haWwtaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fMjU2MDk0NTY2NTM1
ODI4ODk5MW1fLTgyNzk0ODY0OTcxNDEyNTU1MzRnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t
LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N
CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s
PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs
aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ud28gYWRkaXRpb25hbCB0aG91
Z2h0cyBpbmxpbmUsICZsdDtBTEVYJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElkZWFzIFttYWlsdG86aWRlYXMt
Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGFkbWEgUGlsbGF5LUVzbmF1
bHQ8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDExLCAyMDE3IDEwOjMzIEFN
PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5l
dCZndDs8YnI+DQo8Yj5DYzo8L2I+IGlkZWFzQGlldGYub3JnOyBsaXNwQGlldGYub3JnIGxpc3Qg
Jmx0O2xpc3BAaWV0Zi5vcmcmZ3Q7OyBEaW5vIEZhcmluYWNjaSAmbHQ7ZmFyaW5hY2NpQGdtYWls
LmNvbSZndDs7IFJvYmVydCBNb3Nrb3dpdHogJmx0O3JnbS1pZXRmQGh0dC1jb25zdWx0LmNvbSZn
dDs7IEJyaWFuIEUgQ2FycGVudGVyICZsdDticmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20mZ3Q7
OyBpZXRmQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRlYXNdIFtsaXNwXSBX
RyBSZXZpZXc6IElEZW50aXR5IEVuYWJsZWQgTmV0d29ya3MgKGlkZWFzKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9jdCAxMSwgMjAxNyBhdCA5OjE1
IEFNLCBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVt
YS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPk9uIDEwLzExLzIwMTcgNzo1
NiBBTSwgUm9iZXJ0IE1vc2tvd2l0eiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmFuZCAnaWRlbnRpdHknIGlz
IGEgcmVkIGZsYWcuIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2hvdyB0aGVyZSEmbmJzcDsgWW91IHdlcmUgcGFydCBv
ZiB0aGUgTmFtZXNwYWNlIFJlc2VhcmNoIEdyb3VwPyZuYnNwOyBJIHRoaW5rPyZuYnNwOyBJIHdh
cyBhbmQgd2Ugd2Ugd29ya2VkIGEgbG90IG9uIHRoaXMgYW5kIGNhbWUgdG8gdGhlIGNvbmNsdXNp
b24gdGhhdCB0aGVyZSBjb3VsZCBiZSBubyBjb25jbHVzaW9uLiZuYnNwOyBOb3QgZXZlbiBhIHJv
dWdoIGNvbmNlbnN1cywgaXQgc2VlbWVkLg0KPGJyPg0KPGJyPg0KSSBoYXZlIGJlZW4gdXNpbmcg
J2lkZW50aXR5JyB0byBhcHBseSB0byB0aGluZ3MgZm9yIDIwIHllYXJzLiBQcmV0dHkgbXVjaCBl
dmVyIHNpbmNlIEkgc3RhcnRlZCB3b3JraW5nIHdpdGggdGhpbmdzLiZuYnNwOyBBbnlvbmUgdGhh
dCBob2xkcyB0aGUgcG9zaXRpb24gdGhhdCAnaWRlbnRpdHknIG1lYW5zIHdlIGFyZSB0YWxraW5n
IG9ubHkgYWJvdXQgcGVvcGxlIGFyZSBhbGxvd2luZyB0aGVpciB0aGlua2luZyB0byBiZSBjbG91
ZGVkLg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkkgYW0gY29uY2VybmVkIHRoYXQg
dGhlIGN1cnJlbnQgcHJvcG9uZW50cyBvZiB0aGUgSURFQVMgd29yayBhcmUgbWFpbmx5IHJlc2lz
dGluZyB0aGUgZmVlZGJhY2ssIHRyZWF0aW5nIGl0IGFzIHNvbWUgcm9hZGJsb2NrIHB1dCBpbiB0
aGUgcGF0aCBvZiB0aGVpciB3b3JrIGJ5IG1pc2d1aWRlZCBwcml2YWN5IHB1cmlzdHMsIGFuZCBh
dHRlbXB0aW5nIHRvIHJlbW92ZSB0aGUgcm9hZGJsb2NrcyBieSBhZGRpbmcgc29tZSB3ZWFzZWwg
d29yZHMgdG8NCiB0aGUgY2hhcnRlci4gSSB3b3VsZCBmZWVsIG11Y2ggbW9yZSBjb25maWRlbnQg
aWYgdGhlc2UgcHJvcG9uZW50cyBhY2tub3dsZWRnZWQgdGhlIHRlbnNpb24gYmV0d2VlbiBwcml2
YWN5IGFuZCBzdGFibGUgaWRlbnRpZmllcnMgb2YgYW55IHNvcnQsIGlmIHRoYXQgdGVuc2lvbiB3
YXMgY2xlYXJseSBub3RlZCBpbiB0aGUgY2hhcnRlciwgYW5kIGlmIHByaXZhY3kgZ29hbHMgd2Vy
ZSBjbGVhcmx5IHN0YXRlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBvbmUgb2YgdGhlIHByb3BvbmVudHMs
IEkgZmVlbCBJIG5lZWQgdG8gc3BlYWsgdXAgYmVjYXVzZSBibGFua2V0IHN0YXRlbWVudHMgYXJl
IGp1c3Qgbm90IGhlbHBpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5nIG9uIGJlaGFsZiBvZiBteSBmZWxsb3cgcHJv
cG9uZW50cywgd2UgaGF2ZSBhbHdheXMgd2VsY29tZWQgY29uc3RydWN0aXZlIGZlZWRiYWNrIGZy
b20gcGVvcGxlIHdobyB3YW50L2NhbiBjb250cmlidXRlIGFuZCBtYWtlIHRoZSB0ZWNobm9sb2d5
IGJldHRlci4gV2UgaGF2ZSBiZWVuIHdpbGxpbmcgdG8gY2xhcmlmeSB0aGUgY2hhcnRlciAoY2xh
cmlmaWNhdGlvbiBkb2VzIG5vdCBtZWFuIHdlYXNlbGluZykuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGl0IGlzIGhlbHBmdWwg
dG8gJm5ic3A7bW92ZSBmb3J3YXJkLCBJIGFtIHdpbGxpbmcgdG8gdm9sdW50ZWVyIGZvciB0aGlz
IHdvcmsgYW5kIGRpc2N1c3Mgd2l0aCBhbnlvbmUgdG8gZW5zdXJlIGNvbnN0cnVjdGl2ZSBmZWVk
YmFjayBhbmQgY29tbWVudHMgYXJlIGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0FMRVgmZ3Q7ICYjNDM7MSBvbiB3ZWxjb21pbmcg
Y29uc3RydWN0aXZlIGZlZWRiYWNrLiZuYnNwOyBUbyBpbmNvcnBvcmF0ZSBpdCB3ZSBuZWVkIHRv
IHVwZGF0ZSBkb2N1bWVudHMuJm5ic3A7IEFuIHVwZGF0ZSB0byB0aGUgY2NtIHVzZSBjYXNlIGRv
Y3VtZW50IHdhcyBwb3N0ZWQgeWVzdGVyZGF5IChyZXYNCiAtMDIpIHdoaWNoIGluY29ycG9yYXRl
cyBhIGxvdCBvZiB0aGUgZmVlZGJhY2sgZ2l2ZW4uJm5ic3A7IENsZWFybHksIHRoaXMgd2lsbCBu
b3QgYmUgdGhlIGxhc3QgdXBkYXRlIGFuZCBvdGhlciBkb2N1bWVudHMgbmVlZCB0byBmb2xsb3cu
ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWNpZmljYWxseSwgSSB0aGluayB0aGVy
ZSBpcyBhIGNvbnRyYWRpY3Rpb24gYmV0d2VlbiBzb21lIG9mIGRvY3VtZW50cy4gRm9yIGV4YW1w
bGUsIGRyYWZ0LXBhZG1hLWlkZWFzLXByb2JsZW0tc3RhdGVtZW50LTAxIHN0YXRlcyB0aGF0Ojxv
OnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBIHNpbmdsZSBlbnRpdHkg
bWF5IGhhdmUgbXVsdGlwbGUgSURzLCBhbmQgSURzIG9mIHRoZSBzYW1lIGVudGl0eTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYXkgaGF2ZSBk
aWZmZXJlbnQgbGlmZSBzcGFucyB0aGF0IGFyZSBkaWZmZXJlbnQgZnJvbSB0aGUgbGlmZXNwYW48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2Yg
dGhlIGVudGl0eS4mbmJzcDsgRnVydGhlcm1vcmUsIGl0IGlzIHVuZGVyc3Rvb2QgdGhhdCBJRHMg
bWF5IGhhdmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgZGlmZmVyZW50IGxpZmVjeWNsZXMsIHdoaWNoIG1heSBiZSBwZXJtYW5lbnQgb3IgZXBo
ZW1lcmFsIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGNob2ljZSBvciBkZXNpZ24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgRXBoZW1lcmFsICh0ZW1w
b3JhcnkpIElEcyBtYXkgYmUgdXNlZCBhcyBhIHNob3J0LWxpdmVkIHBzZXVkb255bTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgYSBwZXJt
YW5lbnQgSUQgdG8gcHJvdGVjdCB0aGUgcHJpdmFjeSBvZiB0aGUgcmVsYXRlZCBlbnRpdHkuPG86
cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB0aGVuLCBkcmFmdC1jY20t
aWRlYXMtaWRlbnRpdHktdXNlLWNhc2VzLTAxIHN0YXRlcyB0aGF0OjxvOnA+PC9vOnA+PC9wPg0K
PHByZT4mbmJzcDsmbmJzcDsgYS4mbmJzcDsgVW5pcXVlIGFuZCBQZXJtYW5lbnQgSWRlbnRpdHkg
cmVwcmVzZW50aW5nIHRoZSBlbnRpdHkgZW5hYmxlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDthdXRoZW50aWNhdGlvbiAoQVVUSCkg
d2l0aCB0aGUgbWFwcGluZyBhbmQgSWRlbnRpdHkgc2VydmljZXM8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5mcmFzdHJ1Y3R1cmUu
Jm5ic3A7IFdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIGRvIEFVVEggb24gSWRlbnRpZmllcnM8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
dGhvc2UgYXJlIG5vdCBwZXJtYW5lbnRseSBhc3NvY2lhdGVkIHRvIHRoZSBlbnRpdHkuJm5ic3A7
IE1vcmVvdmVyLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBBVVRIIG9wZXJhdGlvbiBpcyBhIHJlbGF0aXZlbHkgYW4gZXhwZW5zaXZl
IGFuZCBpbmVmZmljaWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBwcm9jZWR1cmUgKGNvbXBhcmVkIHRvIExPQyByZXNvbHV0aW9u
IGZvciBleGFtcGxlKSBhbmQgY2FuIGNhdXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4Y2Vzc2l2ZSBzdGFydHVwIGRlbGF5cyBm
b3IgbG90IG9mIGFwcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5BcyBzYWlkIGVhcmxpZXIgdGhpcyBkcmFmdCB3YXMgbm90IHVwZGF0ZWQgYnkg
dGhlIGF1dGhvcnMgYW5kIGEgbmV3IHZlcnNpb24gd2FzIHBvc3RlZCB5ZXN0ZXJkYXkuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWRlYXMvY3VycmVudC9tc2cw
MDUyMC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkZWFzL2N1
cnJlbnQvbXNnMDA1MjAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtBTEVY
Jmd0OyBJIHRoaW5rIHlvdSBtZWFudCB0byBzYXkgaXQgKjxiPndhczwvYj4qIHVwZGF0ZWQgOy0p
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+ZHJhZnQtcGFkbWEtaWRlYXMtcHJvYmxlbS1zdGF0ZW1lbnQgd2ls
bCBwcmVzdW1hYmx5IGJlIG9uZSBvZiB0aGUgZG9jdW1lbnRzIHRoYXQgYXJlIG5leHQgaW4gbGlu
ZSBmb3IgdXBkYXRpbmcuJm5ic3A7ICZsdDsvQUxFWCZndDs8L3NwYW4+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZW5zaW9uIGlzIG9idmlvdXMuIE9uIG9uZSBo
YW5kLCB0aGUgZXBoZW1lcmFsIGlkZW50aWZpZXJzIGVudmlzYWdlZCBpbiB0aGUgcHJvYmxlbSBz
dGF0ZW1lbnQgd291bGQgcHJldHR5IG11Y2ggYWxpZ24gdGhlIHByaXZhY3kgcHJvcGVydGllcyBv
ZiB0aGUgSUQgdG8gdGhvc2Ugb2YgSVB2NiBwcml2YWN5IGFkZHJlc3NlcywgYW5kIHRoYXQncyBn
b29kLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHJlcXVpcmVtZW50DQogdG8gcGVyZm9ybSBhdXRo
ZW50aWNhdGlvbiBvbiBpZGVudGl0aWVzIGNvbXBsZXRlbHkgbmVnYXRlcyB0aGF0IHByb3BlcnR5
Ljxicj4NCjxicj4NCkkgd291bGQgYmUgZmluZSBpZiB0aGUgc3VwcG9ydCBmb3IgJnF1b3Q7VW5p
cXVlIGFuZCBQZXJtYW5lbnQgSWRlbnRpdHkmcXVvdDsgd2FzIGV4cGxpY2l0bHkgZXhjbHVkZWQg
ZnJvbSB0aGUgY2hhcnRlci4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BRkFJSywgbm9uZSBvZiB0aGUgcHJvcG9u
ZW50cyByZXNpc3RlZCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgb2J2aW91c2x5IGEgbmVlZCB0
byBzdXBwb3J0IHNvbWUgZm9ybSBvZiBhY2Nlc3MgY29udHJvbCB0byBhIG1hcHBpbmcgZGF0YWJh
c2UsDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0
OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YnV0IHlvdSBkbyBub3QgbmVlZCBh
IHJlZmVyZW5jZSB0byBhIHBlcm1hbmVudCBpZGVudGl0eSBmb3IgdGhhdCAtLSBzeXN0ZW1zIHNp
bWlsYXIgdG8gQ0dBIHdvdWxkIHdvcmsganVzdCBmaW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpZGVu
dGl0eSBvZiB0aGUgZGV2aWNlIGlzIGp1c3QgYWRkaW5nIGEgbGV2ZXIgb2YgaWRlbnRpZmllciB3
aGljaCBlZmZlY3RpdmVseSBhbGxvd3MgYXV0aGVudGljYXRpb24gdG8gbW9kaWZ5IHRoZSBpZGVu
dGlmaWVycyB1c2VkIGJ5IHRoYXQgZGV2aWNlIGJ1dCBhbHNvIHdoYXQgdGhlIHVzZXJzIG9mIHRo
ZXNlIGlkZW50aWZpZXJzIGNhbiBsb29rIHVwLiBJZiB3ZSBoYWQgdXNlZCAmcXVvdDt1c2VyIG9m
IGlkZW50aWZpZXImcXVvdDsNCiBpdCB3b3VsZCBoYXZlIGJlZW4gbWlzY29uc3RydWVkIGZvciBo
dW1hbnMuIFNvIGRhbW4gaWYgeW91IGRvIGFuZCBkYW1uIGlmIHlvdSBkb24ndCAuLi4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ug
YXJlIG9wZW4gZm9yIGRpc2N1c3Npb25zIGFueXRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhZG1hPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwt
bTI1NjA5NDU2NjUzNTgyODg5OTFtLTgyNzk0ODY0OTcxNDEyNTU1MzRnbWFpbC1ob2VuemIiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4
ODg4Ij4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y
OiM4ODg4ODgiPkNocmlzdGlhbiBIdWl0ZW1hPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQps
aXNwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+bGlzcEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3AiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8L2E+PG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8E6Dsjceml521mbxchi_--


From nobody Wed Oct 11 12:17:59 2017
Return-Path: 
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 E133E13330E; Wed, 11 Oct 2017 12:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level: 
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 gdVk-ERzAz8x; Wed, 11 Oct 2017 12:17:52 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 D61A3133071; Wed, 11 Oct 2017 12:17:52 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id n73so1713884pfg.10; Wed, 11 Oct 2017 12:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BiTGsCwF3UcZ6PhCc1ho0EmiCVpkRo5bBTsFx7ZaSxU=; b=dz3pCYMhwHcuCddhJL/37EsDL+bZ6dFxLJkR0kUoCq98SnJLF6Mysth89L+/i1somn Zzh6RTuKPfuEKA8Oo6J/oNcuW6gyT0c/v7geihn6iiz6ydJ1q0/ve6eIJurWF06PUKwt z0tt04o9qXM2Her1TuT9h3arGdvbVX/BPTz5YOItS8D/o39LWhxsz+4JjD97rvNN+q05 BhiIjLHLoFuFTz9pGQYKUhiHYrZlBDJLimUx1LQVZnssZdQwJCgGaCqFly8dC+pB/1Bf RAEZz/vwpI4jZw0S/gEM0bL1Lfl44DPL90/NruBK1xifk6Cd+KXZT1XgLya9cMUy+bD3 z6SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BiTGsCwF3UcZ6PhCc1ho0EmiCVpkRo5bBTsFx7ZaSxU=; b=XRlNDz21h2PQPisNMPt8+bkzqa0WS4zisvb/0vEbrzZMaT+3OY5YMgx7NMYimhQl2v /KFFqAaEQHsC57wchV+bf+bVWIzJwEz0wrmvnjKqCUgKd7RcsUq+bOmML5vabfKIXrNn 8g2nc2eHcDvTnssN7d1OnJ/XneOxt7rDRfE2oxeiHZ5Vvwi6NJGyAYi2Kkk2JEkLuub3 tfbq6Kooc5wKV56/+iNu3W5mWwrzvSYQ0s21X10JJ8BJwEvTXFxaxQskv5f91JvaY43N iScMjMZcbzEN6p/GmtHxAIIDPvsZnbgWRW3KeEUZvE/u3YBEVuBGAOLyn4yq5I7nVYr/ tlzA==
X-Gm-Message-State: AMCzsaXlXj10y0mNY1UrGANVcntB99bjVOJTwun7y7ZAxThz4rKxweGv wcJ8jHsWIPl8mc5GoFmEWXc=
X-Google-Smtp-Source: AOwi7QABFxXerQ8N5A5anpwnKZRDY98/L0jirb8ebFtFC5PVkFgngk4burwSFt3CJK/rM7hCZDT39g==
X-Received: by 10.84.179.195 with SMTP id b61mr42179plc.19.1507749472532; Wed, 11 Oct 2017 12:17:52 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id z8sm28064343pfl.135.2017.10.11.12.17.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 12:17:51 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Content-Type: text/html; charset=us-ascii
X-Apple-Auto-Saved: 1
X-Apple-Mail-Plain-Text-Draft: yes
From: Dino Farinacci 
X-Apple-Mail-Remote-Attachments: YES
X-Apple-Base-Url: x-msg://780/
In-Reply-To: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
X-Apple-Windows-Friendly: 1
Date: Wed, 11 Oct 2017 12:07:46 -0700
Cc: The IESG , ideas@ietf.org, ideas-chairs@ietf.org, aretana.ietf@gmail.com
X-Apple-Mail-Signature: SKIP_SIGNATURE
Content-Transfer-Encoding: 7bit
Message-Id: <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
X-Uniform-Type-Identifier: com.apple.mail-draft
To: Alissa Cooper 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:17:54 -0000


(1) The work is insufficiently motivated. The claims about the need for the
mapping system and the identity management system envisioned here do not appear
to be backed up by those who have developed and deployed ID/LOC separation
protocols. Nor do there seem to be compelling arguments that the framework that
this proposed WG would produce would be the motivator for further interoperable
deployments.

This is simply not true. The IETF mailing lists are not finding the reach of interest that exists in the industry.

Dino




From nobody Wed Oct 11 12:25:42 2017
Return-Path: 
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 840B113309C; Wed, 11 Oct 2017 12:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 r8r5ptMYgA4Q; Wed, 11 Oct 2017 12:25:35 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 A0585126B6D; Wed, 11 Oct 2017 12:25:34 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id q132so7666699wmd.2; Wed, 11 Oct 2017 12:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Amu0cBZIgwm/UwKIma3F9EtTYFkXlK2ioRyNLYGfkGQ=; b=qsQeSmQOK4PDQn4dQ/6397dpnca2emFAzH5kqDwzD5fqtZlYvNYMsttRgPor6NSDEf F4L4gf5XdZpdp5y2wLhk2i38So6F83XRQoyP78WHnENQtz9N4ZVUPSZ+lqMc9qRk7ABr iABpqDVfyWN0X+vbglGi4O5x/zp9och/fpl+my6RzW5Y37P773BQnmrEfum6EKdsuuuM DoO+dzncQdQhgq9gmPm1u02sTN4etm703YoI+QF0mHxy0EdmXPNWX7Pn6QrKcQ38VQ8P 3qHU1lJuNLoVxMgokxgLGeyyKb0Tk0Qg9waOPtyq57ZABY+sIUlO8NtRgUmblPjJIqfq xU+Q==
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=Amu0cBZIgwm/UwKIma3F9EtTYFkXlK2ioRyNLYGfkGQ=; b=IpTfsCDkenTvHwV90nsdcs4kGidS6xrsbARep5MTqgUGQtB9kVs9klzpanocdxbTDA cM4SsQsrhR7iZiji9K9XIwp6hKgQfRDqF8CVRdB9/7Z2sHUeCi7IK030Zu6zOdexKWnk L/Lp7jEu07Qe1iq+pCB/TnEVk+YSXBIz8xcNJuFFPWf6rtU9nviBqu6ynHFbr0aXaz9O e+J/0d/cjdeog6Fa/TMCGJRJpUUoU6EbondWatLX1hRiPX5tUnK6cqu2wna4MRojNUI3 PgY1E4fpp+jO0eFxTxBlxMJFpqBgy+nLHao0kYV0jQzkMx6iuJeXRy8ac6n8T+AzZ1mk xAaQ==
X-Gm-Message-State: AMCzsaV+WmXaYHvpnXSVuLziPjQTmfixA86ZrcdGN0K+ZX163/8LGKaB AhjtDT2jPJ0e2XcgrZnSb7uA4az3VFEewO9Ta+0=
X-Google-Smtp-Source: AOwi7QA6jT3KEicjsJ79sA00y/jP5nvm4EfElklJyg9OeBwwapd0IjD228JESLld5rEqhSUOqETzEtQJaCFyBr9snBc=
X-Received: by 10.28.10.145 with SMTP id 139mr6863wmk.5.1507749933227; Wed, 11 Oct 2017 12:25:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Wed, 11 Oct 2017 12:25:32 -0700 (PDT)
In-Reply-To: 
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com> 
From: Padma Pillay-Esnault 
Date: Wed, 11 Oct 2017 12:25:32 -0700
Message-ID: 
To: Eric Rescorla 
Cc: Dino Farinacci , Alissa Cooper , ideas@ietf.org, ideas-chairs@ietf.org, The IESG ,  Alvaro Retana 
Content-Type: multipart/alternative; boundary="001a114440ca2e2679055b4a638b"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:25:36 -0000

--001a114440ca2e2679055b4a638b
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:20 PM, Eric Rescorla  wrote:

>
>
> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci 
> wrote:
>
>> (1) The work is insufficiently motivated. The claims about the need for
>> the
>> mapping system and the identity management system envisioned here do not
>> appear
>> to be backed up by those who have developed and deployed ID/LOC separation
>> protocols. Nor do there seem to be compelling arguments that the
>> framework that
>> this proposed WG would produce would be the motivator for further
>> interoperable
>> deployments.
>>
>>
>> This is simply not true. The IETF mailing lists are not finding the reach
>> of interest that exists in the industry
>>
>

>
> Be that as it may, the determination of consensus and justification has to
> be made primarily on what appears on the mailing lists and at meetings.
>

Why are we discounting the interest showed at the BOF?

Padma

>
> -Ekr
>
>
>> Dino
>>
>>
>

--001a114440ca2e2679055b4a638b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 12:20 PM, Eric Rescorla <<=
a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:


On Wed, Oc=
t 11, 2017 at 12:07 PM, Dino Farinacci <farinacci@gmail.com> wrote:
(1) The work is insufficiently motivated. The claims abou=
t the need for the
mapping system and the identity management system env=
isioned here do not appear
to be backed up by those who have developed a=
nd deployed ID/LOC separation
protocols. Nor do there seem to be compell=
ing arguments that the framework that
this proposed WG would produce wou=
ld be the motivator for further interoperable
deployments.

This is simply not true. The IETF mailing lists are not findi=
ng the reach of interest that exists in the industry
=C2=A0

Be that as it may, th=
e determination of consensus and justification has to be made primarily on =
what appears on the mailing lists and at meetings.
<=
/blockquote>

Why are we discounting the interest showed =
at the BOF?

Padma
=


-Ekr


Dino










--001a114440ca2e2679055b4a638b--


From nobody Wed Oct 11 12:28:19 2017
Return-Path: 
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 CFF691342C2 for ; Wed, 11 Oct 2017 12:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 ssjIXZZaCsST for ; Wed, 11 Oct 2017 12:28:13 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 CBAC7126B6D for ; Wed, 11 Oct 2017 12:28:12 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id o52so8528849qtc.9 for ; Wed, 11 Oct 2017 12:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VrfzaZkX+cF6//RCQiTavZmTiqhyUZvTyJZwzITsflg=; b=wg6AvbhcUHhTdJasXNOPIMMmwTeVMMVwNaV8OjZf94qZNqElmNvIZGHLdC/2YGJZVi DujcW4OJLF59Yk6+5CRWLYJqw1lPMz9iFJCPRnexBcgRTdAzQUgip/p7npxR+kd1GsCW JCXXemp00x2vgikC/gnSF1kXFbp6ZUnLA3jKCZezBu9LQJJknoOpZNa1KxxVcdlz8SNa 5v+Pgkqwyyfn7ia2dlu8XWZQ/a50dq5Tf8vhcDELuEmwihqR13eJpLiGGtTjbsfVFvHn LWzQY00nwF2mZO3NGF++irwzP/F+9gTttDtKFO2uUaBolrYFBi6kt7qgqc+0xvnSkVzr tAyA==
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=VrfzaZkX+cF6//RCQiTavZmTiqhyUZvTyJZwzITsflg=; b=NRtaCLsvFQzwmkaVXkUQHgIjNsYgBlo5sgX04Gi1DKgAU+NLqrG4YcepiKinF7RCW4 CCxAT82ZQZ6KUaAi2AesR1PQNERuyD6M/JLaDQeMVDnBt7Xa6NIdSUy7l1J8Y7DbYpQ6 CCrsCmiKhvCWsQxazifXCUv2I7x3yjQwvQu3l9lX6KJa/veUUai7d9VW8aJE7KE5SN4a 8ujtgO7bjXot/zzhXvyEhcsJ5sd9oST3uYKXaNVG+6w0kOitAfU4aYh0/uHeKrTjNp1B ddrFVnCES5IEiKVWHFrl9teIaUjLV204fz0rInbj/AcxgdSzEFPaRg8jh63O5XJVm8bk fIPw==
X-Gm-Message-State: AMCzsaVMcYTbFSHJxWoZ68PCbzrDFeYVnmCyD1tuo/2ghYpVqYMxkK2j H5/KM0S5kcmBJIq2W8KwiHT67uAYDGRLvRF9Cf7aJQ==
X-Google-Smtp-Source: AOwi7QACicXA5WEHEG7BTSmv5VRXrLdLTET9waKl50yCHhbnnuRJxK29fDaeXanY4PEo5Dfnz1lj9YC36jCGudsDEY4=
X-Received: by 10.37.51.68 with SMTP id z65mr394104ybz.353.1507749682817; Wed, 11 Oct 2017 12:21:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 11 Oct 2017 12:20:42 -0700 (PDT)
In-Reply-To: <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>
From: Eric Rescorla 
Date: Wed, 11 Oct 2017 12:20:42 -0700
Message-ID: 
To: Dino Farinacci 
Cc: Alissa Cooper , ideas@ietf.org, ideas-chairs@ietf.org,  The IESG , aretana.ietf@gmail.com
Content-Type: multipart/alternative; boundary="001a1148aa624142ab055b4a54c1"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:28:14 -0000

--001a1148aa624142ab055b4a54c1
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci 
wrote:

> (1) The work is insufficiently motivated. The claims about the need for the
> mapping system and the identity management system envisioned here do not
> appear
> to be backed up by those who have developed and deployed ID/LOC separation
> protocols. Nor do there seem to be compelling arguments that the framework
> that
> this proposed WG would produce would be the motivator for further
> interoperable
> deployments.
>
>
> This is simply not true. The IETF mailing lists are not finding the reach
> of interest that exists in the industry
>

Be that as it may, the determination of consensus and justification has to
be made primarily on what appears on the mailing lists and at meetings.

-Ekr


> Dino
>
>

--001a1148aa624142ab055b4a54c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci <=
farinacci@gmail.co=
m> wrote:
(1) The wo=
rk is insufficiently motivated. The claims about the need for the
mappin=
g system and the identity management system envisioned here do not appearto be backed up by those who have developed and deployed ID/LOC separatio=
n
protocols. Nor do there seem to be compelling arguments that the frame=
work that
this proposed WG would produce would be the motivator for furt=
her interoperable
deployments.

This is simply=
 not true. The IETF mailing lists are not finding the reach of interest tha=
t exists in the industry

Be tha=
t as it may, the determination of consensus and justification has to be mad=
e primarily on what appears on the mailing lists and at meetings.

-Ekr


Dino

=







--001a1148aa624142ab055b4a54c1--


From nobody Wed Oct 11 12:30:21 2017
Return-Path: 
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 E4937126B6D; Wed, 11 Oct 2017 12:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 C1WnmzYVv-04; Wed, 11 Oct 2017 12:30:13 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 2AED4124239; Wed, 11 Oct 2017 12:30:13 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id b79so1765450pfk.5; Wed, 11 Oct 2017 12:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1jR23qx8x/APwAjzzLB2zlPhNtVCOJJC0hFzF0SttI=; b=XR5hiP5MHU6IdFCwHbSwABap/ou4BAJELkzA7561ZAF1BHVOogxEjjBtMKqU/0dtB2 vpM4Tp4kRHMMEqn4MtnqQWucaGYjyAdEa7KpKJt/83LUBW11pNl1/Yt+VH7P3z6/uhFC t0/lul7eRSumbdCW1gNHQzn/HUcb+RKQnbZrrn13HdRXUQFcvlEgmZlheftvQ0J/Gnud UtrObW77Y1X/msrzaa7MJYBcZDH6rE9IkgZw1z1LremEaGxJt2dxpSKClpu6xU+Zv+qC j4hgjji6h/UiTcIr/EEsOZLWqymoeXXfcf1V5GrFkM9lcU5SD4xjAUTMH8mJAeCAbIE4 uczQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1jR23qx8x/APwAjzzLB2zlPhNtVCOJJC0hFzF0SttI=; b=SN+BJxPSm059oN4ZjpGS8w5jOJUCHfhDdm7cN72Oa48VAwPdo4DspyeJf0CG4w71UM sSQ9x7o6SDJQiK+aA9xdpDNGuu8bht3J5nWl55relhHBVeLP3IDDUzbf/R827eIR925p uJEdhyTphTstR6MqgonNkEX0BMaK4zQkKUbIw5Msswp7xUEszAkeOrOUk2Jw8yaqNHep 5hTbsxP55b91vFPpjMWVtGdI2Hn/p0uZyfhO9FeLOE96Ir8JpB1k8ZKiLoWpEOV0sAY3 ydpPnvMV/IX4BbhqljZW72pHymfmQ70nSBjSGlcxsPV8h8LPnpPo1t9rq66pTvqvuVsz 4yOw==
X-Gm-Message-State: AMCzsaWJTftTO+jlSn1lkYyLib+vJneZq0W0Ce8HaZ53UZ5FtE0B3iIc F5R9uIhtGJX73cWXnuU4Ua8=
X-Google-Smtp-Source: AOwi7QAR8k1iH9U/NpX7yljjceGrJuAs0iRUa6Xb+VFXIUySrwwoRvkZZxDVYZ404qmt1ha/VNmwUg==
X-Received: by 10.98.12.203 with SMTP id 72mr48059pfm.263.1507750212795; Wed, 11 Oct 2017 12:30:12 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id 24sm22696396pfk.9.2017.10.11.12.30.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 12:30:12 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 12:30:11 -0700
Cc: Alissa Cooper , ideas@ietf.org, ideas-chairs@ietf.org,  The IESG , aretana.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:30:15 -0000

I am reaching out to the SD-WAN community. There has been huge =
investment from the VC community in overlay startups. They are all using =
proprietary control-planes. There is no interoperability among them. The =
IETF should not ignore this market and should help shape it.

This is VXLAN-in-the-data-center market all over again making IETF =
working group nvo3 irrelevant.

Mapping Databases ARE being deployed under the auspices of =
SDN-controllers. There are high profile user-groups that endorse the =
activity. It is not going away.=20

IETF needs to lead and not follow.

Dino


> On Oct 11, 2017, at 12:20 PM, Eric Rescorla  wrote:
>=20
>=20
>=20
> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci  =
wrote:
>> (1) The work is insufficiently motivated. The claims about the need =
for the
>> mapping system and the identity management system envisioned here do =
not appear
>> to be backed up by those who have developed and deployed ID/LOC =
separation
>> protocols. Nor do there seem to be compelling arguments that the =
framework that
>> this proposed WG would produce would be the motivator for further =
interoperable
>> deployments.
>=20
> This is simply not true. The IETF mailing lists are not finding the =
reach of interest that exists in the industry
>=20
> Be that as it may, the determination of consensus and justification =
has to be made primarily on what appears on the mailing lists and at =
meetings.
>=20
> -Ekr
>=20
>=20
> Dino
>=20
>=20


From nobody Wed Oct 11 12:31:10 2017
Return-Path: 
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 941E81321DC for ; Wed, 11 Oct 2017 12:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 qA6yrui7ARWK for ; Wed, 11 Oct 2017 12:31:03 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 723FA126B6D for ; Wed, 11 Oct 2017 12:31:02 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id k31so8561009qta.6 for ; Wed, 11 Oct 2017 12:31:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gRxaxAjoGTGcFkzt8uxgrYUWyj4hcRht4NMJ5wNqUjk=; b=ON4NM+KH8auHdBv4b6niMNraRW6sfiD/EFQrP4K/o0//Vi68HaTVS4cTvSmO/LUKIY JFc1gHH1oV1Gon0DRtHRn8UYZWnXxcqxasQrQM3qTuw44jw6LMYTaoFiT2cq5Kt7qlDP b5WF3iiHkOlKEwOHPPo+TWt7VRjOffSxTx7yea4FCtUvdUeVjnoDPJtSkMsjdslldXZ5 Ile6vjy9oHcdM1f3Pqbuzj46VK1uE+p3VL0ImbFDmQ3p9TZzCC7uIjt+4g/rs2kjbj2j nVl/vTlm4TDxOG7ilXbtlOLhtgPs8AT9F18A/ByF/VNas6agRNuqgRUbqt6eIeZ34gLj 7Ryg==
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=gRxaxAjoGTGcFkzt8uxgrYUWyj4hcRht4NMJ5wNqUjk=; b=SA7LzKiw04S5NoZk0PODAF4hB9ObGtJY7pzhG+ej4DV8j7M+LgiZgDTXxNJEUw28Ko okaoBixch/V8NYstKyz0SVaBWHWylS/kTnvqS0WGHBFJxmVZHyhEB3fwCWGGv+LWbO/+ pFxzwU7Ko4Gu+T5WgW4Oqy8iX4nBvCDLHtpZVV56m4Dpmf9o4TLrAQ5alFp1HNz0FFkS NnAIbNXdDBYeD7fkvGOu5l6Ny7CticDIiLf2n2RCRsUfba251teuwCRv2GxF2uown0uZ xOMH32otJbPMdTIX0ydF7XN2Y3lZZk2sc5azd/wWXvMAkxeOEbzlFs8s6hwhGvzzk3NS AjnA==
X-Gm-Message-State: AMCzsaWsjOKr4YLSPPO0PbPKXAe+R8bii8F2fp11e5q2sLK/beeJUkUw sd2gud/TTNe/4wHUxYZ//2OlR+ehk0m7qhEdL7iOGA==
X-Google-Smtp-Source: AOwi7QDEsvG7B28g6YTWuswQolkLQ65y6R2fcevpEvnY0Y65aHUsR1mTi3KMLKdCcY4EeiqmwmpQTDj9YfuQv8ftxWc=
X-Received: by 10.129.167.66 with SMTP id e63mr423760ywh.294.1507750261634; Wed, 11 Oct 2017 12:31:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 11 Oct 2017 12:30:21 -0700 (PDT)
In-Reply-To: 
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>  
From: Eric Rescorla 
Date: Wed, 11 Oct 2017 12:30:21 -0700
Message-ID: 
To: Padma Pillay-Esnault 
Cc: Dino Farinacci , Alissa Cooper , ideas@ietf.org, ideas-chairs@ietf.org, The IESG ,  Alvaro Retana 
Content-Type: multipart/alternative; boundary="94eb2c079026c1454c055b4a7655"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:31:04 -0000

--94eb2c079026c1454c055b4a7655
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:25 PM, Padma Pillay-Esnault  wrote:

>
>
> On Wed, Oct 11, 2017 at 12:20 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci 
>> wrote:
>>
>>> (1) The work is insufficiently motivated. The claims about the need for
>>> the
>>> mapping system and the identity management system envisioned here do not
>>> appear
>>> to be backed up by those who have developed and deployed ID/LOC
>>> separation
>>> protocols. Nor do there seem to be compelling arguments that the
>>> framework that
>>> this proposed WG would produce would be the motivator for further
>>> interoperable
>>> deployments.
>>>
>>>
>>> This is simply not true. The IETF mailing lists are not finding the
>>> reach of interest that exists in the industry
>>>
>>
>
>>
>> Be that as it may, the determination of consensus and justification has
>> to be made primarily on what appears on the mailing lists and at meetings.
>>
>
> Why are we discounting the interest showed at the BOF?
>

I'm not, hence "mailing lists and at meetings".

However, based on the minutes, the BOF also seems to fall far short of
consensus:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-ideas/

And of course the sentiment on the IETF list is rather more negative.

-Ekr


> Padma
>
>>
>> -Ekr
>>
>>
>>> Dino
>>>
>>>
>>
>

--94eb2c079026c1454c055b4a7655
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 12:25 PM, Padma Pillay-Esnault <padma.ietf@=
gmail.com> wrote:


On Wed, Oct 11, 2017 at 12:20 PM, E=
ric Rescorla <ekr@rtfm.com> wrote:

On Wed, Oct 11, 2017 at 12:07 PM, Dino F=
arinacci <farinacci@gmail.com> wrote:
(1) The work=
 is insufficiently motivated. The claims about the need for the
mapping =
system and the identity management system envisioned here do not appear
=
to be backed up by those who have developed and deployed ID/LOC separation<=
br>protocols. Nor do there seem to be compelling arguments that the framewo=
rk that
this proposed WG would produce would be the motivator for furthe=
r interoperable
deployments.

This is simply n=
ot true. The IETF mailing lists are not finding the reach of interest that =
exists in the industry
=C2=A0

Be that as it may, the determination of cons=
ensus and justification has to be made primarily on what appears on the mai=
ling lists and at meetings.

Why are we discounting the interest showed at the BOF?

I'm not, hence &quo=
t;mailing lists and at meetings".

However, ba=
sed on the minutes, the BOF also seems to fall far short of consensus:=C2=
=A0https://datatracker.ietf.org/meeting/99/materials/minutes-99-ideas/=


And of course the sentiment on the IETF list =
is rather more negative.

-Ekr
=C2=A0
Padma
=


-Ekr
<=
/div>


Dino













--94eb2c079026c1454c055b4a7655--


From nobody Wed Oct 11 12:34:32 2017
Return-Path: 
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 A3D8C13314B for ; Wed, 11 Oct 2017 12:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 i0nrGFpFeYLD for ; Wed, 11 Oct 2017 12:34:28 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E9313208E for ; Wed, 11 Oct 2017 12:34:28 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e2Mlu-0004kL-LB for ideas@ietf.org; Wed, 11 Oct 2017 21:34:27 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e2Mlr-0001u0-EI for ideas@ietf.org; Wed, 11 Oct 2017 15:34:24 -0400
Received: (qmail 17983 invoked from network); 11 Oct 2017 19:34:22 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.26]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Oct 2017 19:34:21 -0000
To: Padma Pillay-Esnault 
Cc: "ideas@ietf.org" , "lisp@ietf.org list" , Dino Farinacci , "ietf@ietf.org" 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>   
From: Christian Huitema 
Message-ID: 
Date: Wed, 11 Oct 2017 12:34:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E14CE32255CE1CCBF53D2ED8"
Content-Language: en-US
X-Originating-IP: 168.144.250.234
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iByNP7nk5j/Y1Q+TiGXDQgXv9krsgRhBn0ayn6qsUc7p7He3a39gjg/ 9oOEoAajC61PdOWeIW8R8TgUu5HhPnJhFuXRIl8RfvwDILrcSMZpTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKc15MKAE5KxEGDeWlpUyi4Ajj0HlFDoqoWF20+xKQ35+qr5V2ZbZ4HnGWDW DCGQER28QWdnB3wN1Us5flF/yXto+m6tTHY+01PY0Fa/G3bd5Npo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c23FTWvBAoIj/HBKTnC/ezEM7WlAdJFHxvEAket/MWp 8LixlQACPJaGyff01nUzUQ7h9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GjgObG0KE8JsFWzIVsmKmW5nHEeB4hpRrmo/duzUUp/Jp oblrMa1IlXifk90DDtVXs797QYJMDAOYPtd3KM7+hXLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+JLQ1IU2ZpZjfZbEadRQesoj2lB9TLiDMfXuvSrucRXqjh4tEWL5TmLyaFLQm70v2psib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:34:31 -0000

This is a multi-part message in MIME format.
--------------E14CE32255CE1CCBF53D2ED8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:

>     but you do not need a reference to a permanent identity for that
>     -- systems similar to CGA would work just fine.
>
>  
>
> The identity of the device is just adding a lever of identifier which
> effectively allows authentication to modify the identifiers used by
> that device but also what the users of these identifiers can look up.
> If we had used "user of identifier" it would have been misconstrued
> for humans. So damn if you do and damn if you don't ... 
>
> We are open for discussions anytime.
>

Some thing you should be hearing is that "long term identity of device"
has almost the same privacy properties as "long term identity of the
device's owner". You may think that identifying a random piece of
hardware is no big deal, but it turns out that the network activity and
network locations of that piece of hardware can be associated to those
of its human owner. So you need the same kind of protection for these
device identifiers as for human identifiers.

-- 
Christian Huitema


--------------E14CE32255CE1CCBF53D2ED8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:

    

    

      

        
but you do not need a reference to a
          permanent identity for that -- systems similar to CGA would
          work just fine.

      

      
 

      

      


      

      
The identity of the device is just adding a lever of
        identifier which effectively allows authentication to modify the
        identifiers used by that device but also what the users of these
        identifiers can look up. If we had used "user of identifier" it
        would have been misconstrued for humans. So damn if you do and
        damn if you don't ... 

      


      

      
We are open for discussions anytime.

      


      

    

    

    Some thing you should be hearing is that "long term identity of
    device" has almost the same privacy properties as "long term
    identity of the device's owner". You may think that identifying a
    random piece of hardware is no big deal, but it turns out that the
    network activity and network locations of that piece of hardware can
    be associated to those of its human owner. So you need the same kind
    of protection for these device identifiers as for human identifiers.

    
-- 
Christian Huitema

  


--------------E14CE32255CE1CCBF53D2ED8--


From nobody Wed Oct 11 12:39:22 2017
Return-Path: 
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 D387C124239; Wed, 11 Oct 2017 12:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 GBanYIrteCIL; Wed, 11 Oct 2017 12:39:19 -0700 (PDT)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 CBCE91342D6; Wed, 11 Oct 2017 12:39:18 -0700 (PDT)
Received: by mail-pf0-x243.google.com with SMTP id h28so3118444pfh.5; Wed, 11 Oct 2017 12:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y3St2vojiMxDh3g/qp72u+d4nT9sShZsbDYQSvrcRAc=; b=sMcoSSqi0n4MC8QyBTQymYi/1NkTJhupE9TKu+J2Hwg6dmUSfmU4mx+AvX9vg87HOa LV7v+1+UuSwrTapCQSfJU6WTjYemXNPR8PqUaUxnk4lpFhzpxXZB1O0v/7MkkJia/JdU 6hHU7w+/Ti2Iq5/zxaEPCBTzMPcl7DctbpMEt3f69JCqFGwJI3CQsnNcD6bh3o8N5ZQW 2Sb2aHP3D6hB4LetJpTK7/E1yDh8FWhg1KHXkocH3FOtjuYJAtdtwlxu4ii3BFMlmO75 0lCvYn+8ZMLG1S+xDxuiTLkl0fZyyyPN4g4MEWvaHSN+oNMt/3KnTlHeYyqB6NxUlHHR FX2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y3St2vojiMxDh3g/qp72u+d4nT9sShZsbDYQSvrcRAc=; b=sGMn4V6f4TG/7phwbxIAwNMDbxubsrH4NJY6qSmU8/3RL76NJ+iw+irYYmfn6lZCWW /eVmZ0IEhYzlDs9gGP8+Q008vBP6FjLMYeeYpS9bIblww9OQksfj5iyYzh9+iUGt9/Ny 3uxObdmQ/nwkSXlLUPXZOXmRgpzPgaa8eOXMOmY6ffS1dRn30Kvg7LPE2U5POBe3xMhS VfGRhs4LPqmViy7YriDUn2rLEnmZVg8JYe9YgfuM6/PDVj60j2kEyc7Vx3nV8zWnGtHn JdLdD9Q/S7fPoXNOTCEDnhW9a8XJwqBCSdKGJ5WPLa6IwGnTbamYAvyOrMnm1araM0cq doWA==
X-Gm-Message-State: AMCzsaV6citwVnaC2+JzhFAiSSTfN2CibxThR3Uslaz3Ff7aAL9M2tIT oYTHZ0IpVUoSwx9APHpy8xcmd/pm
X-Google-Smtp-Source: AOwi7QBbdbywYyDlopdurCmIct7gKuaY16Q3vdYaekWaU09zTvqQm00xqunS13Y7Ux4EJ7Z+2xgtAw==
X-Received: by 10.84.150.101 with SMTP id g92mr99450plg.168.1507750758254; Wed, 11 Oct 2017 12:39:18 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id s3sm15070525pfk.7.2017.10.11.12.39.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 12:39:17 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 12:39:16 -0700
Cc: Padma Pillay-Esnault , "ideas@ietf.org" , "lisp@ietf.org list" , "ietf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>    
To: Christian Huitema 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:39:21 -0000

Let me ask for your opinion Christian (or anyone else for that matter). =
If a device is assigned a private/public key-pair and the identifier for =
the device is a hash of the public-key, is the identifier private?

Is the identifier trackable even when its network location is not =
generally known, not advertised publicly, and possibly changing =
frequently?

Dino

> On Oct 11, 2017, at 12:34 PM, Christian Huitema  =
wrote:
>=20
> On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:
>> but you do not need a reference to a permanent identity for that -- =
systems similar to CGA would work just fine.
>> =20
>>=20
>> The identity of the device is just adding a lever of identifier which =
effectively allows authentication to modify the identifiers used by that =
device but also what the users of these identifiers can look up. If we =
had used "user of identifier" it would have been misconstrued for =
humans. So damn if you do and damn if you don't ...=20
>>=20
>> We are open for discussions anytime.
>>=20
>=20
> Some thing you should be hearing is that "long term identity of =
device" has almost the same privacy properties as "long term identity of =
the device's owner". You may think that identifying a random piece of =
hardware is no big deal, but it turns out that the network activity and =
network locations of that piece of hardware can be associated to those =
of its human owner. So you need the same kind of protection for these =
device identifiers as for human identifiers.
> --=20
> Christian Huitema
>=20


From nobody Wed Oct 11 12:42:24 2017
Return-Path: 
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 BCEF7124239 for ; Wed, 11 Oct 2017 12:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 OsArpDzdlqj9 for ; Wed, 11 Oct 2017 12:42:17 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 0F0FB134184 for ; Wed, 11 Oct 2017 12:42:17 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id z50so8672901qtj.4 for ; Wed, 11 Oct 2017 12:42:16 -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=D1ZVd2vgEhyYGsZA1Oo0sL71/5HvaKTCKKbWhuEe1DA=; b=uY73sZJPrese2XanJZSvHCXmInVoE9M+0t+1k35Gr2BaSCd63fuMCEs+KWbUm/TUmz qZT0ncLmRbWMRA/gBTtrzzlZ9dY+LuHBNMp5B7d6DgtqbjLM9C7hWj8japCA6Fq1S23S WYLXZJgcwPvDfk1KhH2KGv+A0HSn1ScyX5QMIgR+sw7biyiiCCDIMRQ3ryiznDduBYEc jYJmNfpVk+zZSV+8v4qiDrWk5PZ50Pnol9G+6txHARJ+ZBgKOP24QlsaxY1GP8iKhEno z7+L8CAFeLLzH+TZUMNpdtg24fwCTwYP4T9m3C/3q+eEG1Be7hGgw6r8VAn5t0FgFJZC kxZA==
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=D1ZVd2vgEhyYGsZA1Oo0sL71/5HvaKTCKKbWhuEe1DA=; b=arXqBsSenGXutOr2yrmtyWzs0Ol8tPpED4c5zAIk3vy29qXvfyJhgA6HgftAwSILDh ASqeaceTTS83SqDYrozNjqvZidtfqD0jEtsMezNzmvfcXye+I9OQnP2dGEe8it33CLwi e7zs/Z9/+x4Vuf2J73+80+dtw4FIyctx0PRJcWJ7XGpYhKb5EAPi1U9rCwmptjjKXUHz oCjbfliseE+GYgZeHQ8p/AyvrWjPl46G3IKyx8Pz3ESY1kan72M0JBL3G1y2F56DsXMJ WP4MGdpbymGp1MMQ2aJggZNECZ/UMQMDWmA+r4cbnYlHpHtaIzbxB1pV99uPupx6lKvs sQMA==
X-Gm-Message-State: AMCzsaV1wvQ8Z8ffTEOcJA8SQbyjYiml3e3YhXrXyIwE72xv/KDwQEAw iXtACAlItfgsPFOmIw4AmQnGs7flZbE2QVZphir4EA==
X-Google-Smtp-Source: AOwi7QAiHVy/qyvHZ2u5VcNHV5vRhCyGThrHqI8jhXsu4crh5CjVYBTsbAUg42mNoQI2/cYsMSyi9GckdxOQq9ENMB8=
X-Received: by 10.200.47.85 with SMTP id k21mr205495qta.286.1507750936199; Wed, 11 Oct 2017 12:42:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.144 with HTTP; Wed, 11 Oct 2017 12:42:15 -0700 (PDT)
In-Reply-To: 
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>  
From: Tom Herbert 
Date: Wed, 11 Oct 2017 12:42:15 -0700
Message-ID: 
To: Dino Farinacci 
Cc: Eric Rescorla , ideas-chairs@ietf.org, ideas@ietf.org,  Alissa Cooper , The IESG , aretana.ietf@gmail.com
Content-Type: multipart/alternative; boundary="001a1137ae26f65806055b4a9e32"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:42:20 -0000

--001a1137ae26f65806055b4a9e32
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:30 PM, Dino Farinacci 
wrote:

> I am reaching out to the SD-WAN community. There has been huge investment
> from the VC community in overlay startups. They are all using proprietary
> control-planes. There is no interoperability among them. The IETF should
> not ignore this market and should help shape it.
>
> This is VXLAN-in-the-data-center market all over again making IETF working
> group nvo3 irrelevant.
>
> Mapping Databases ARE being deployed under the auspices of
> SDN-controllers. There are high profile user-groups that endorse the
> activity. It is not going away.
>
> IETF needs to lead and not follow.
>
> +1

The need for a common mapping system has already been discussed for for
years in nvo3. With the emergence of identifier-locator protocols, and
particularly their utility to provide seamless mobility at large scale, the
need for a well defined mapping system has become more evident. IMO this is
a problem IETF should work on.

Note that identity, which is what most of this discussion has been about,
is only one aspect of the mapping system for identifier-locator protocols
and network virtualization. There are many other aspects that have not been
mentioned but need attention. I am worried that we might be throwing the
baby out with the bath water as they say...

Tom


> Dino
>
>
> > On Oct 11, 2017, at 12:20 PM, Eric Rescorla  wrote:
> >
> >
> >
> > On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci 
> wrote:
> >> (1) The work is insufficiently motivated. The claims about the need for
> the
> >> mapping system and the identity management system envisioned here do
> not appear
> >> to be backed up by those who have developed and deployed ID/LOC
> separation
> >> protocols. Nor do there seem to be compelling arguments that the
> framework that
> >> this proposed WG would produce would be the motivator for further
> interoperable
> >> deployments.
> >
> > This is simply not true. The IETF mailing lists are not finding the
> reach of interest that exists in the industry
> >
> > Be that as it may, the determination of consensus and justification has
> to be made primarily on what appears on the mailing lists and at meetings.
> >
> > -Ekr
> >
> >
> > Dino
> >
> >
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>

--001a1137ae26f65806055b4a9e32
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 12:30 PM, Dino Farinacci <=
farinacci@gmail.co=
m> wrote:
I am reaching out=
 to the SD-WAN community. There has been huge investment from the VC commun=
ity in overlay startups. They are all using proprietary control-planes. The=
re is no interoperability among them. The IETF should not ignore this marke=
t and should help shape it.



This is VXLAN-in-the-data-center market all over again making IETF working =
group nvo3 irrelevant.



Mapping Databases ARE being deployed under the auspices of SDN-controllers.=
 There are high profile user-groups that endorse the activity. It is not go=
ing away.



IETF needs to lead and not follow.


+1

The need for a common mapping system ha=
s already been discussed for for years in nvo3. With the emergence of ident=
ifier-locator protocols, and particularly their utility to provide seamless=
 mobility at large scale, the need for a well defined mapping system has be=
come more evident. IMO this is a problem IETF should work on.
Note that identity, which is what most of this discussion has b=
een about, is only one aspect of the mapping system for identifier-locator =
protocols and network virtualization. There are many other aspects that hav=
e not been mentioned but need attention. I am worried that we might be thro=
wing the baby out with the bath water as they say...

Tom
=C2=A0

Dino






> On Oct 11, 2017, at 12:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>

>

>

> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci <farinacci@gmail.com> wrote:

>> (1) The work is insufficiently motivated. The claims about the nee=
d for the

>> mapping system and the identity management system envisioned here =
do not appear

>> to be backed up by those who have developed and deployed ID/LOC se=
paration

>> protocols. Nor do there seem to be compelling arguments that the f=
ramework that

>> this proposed WG would produce would be the motivator for further =
interoperable

>> deployments.

>

> This is simply not true. The IETF mailing lists are not finding the re=
ach of interest that exists in the industry

>

> Be that as it may, the determination of consensus and justification ha=
s to be made primarily on what appears on the mailing lists and at meetings=
.

>

> -Ekr

>

>

> Dino

>

>




_______________________=
________________________

Ideas mailing list

Ideas@ietf.org

https://www.ietf.org/mailman/listinfo/ideas





--001a1137ae26f65806055b4a9e32--


From nobody Wed Oct 11 12:44:31 2017
Return-Path: 
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 29A041342DB for ; Wed, 11 Oct 2017 12:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 eqagzkaDOIJ1 for ; Wed, 11 Oct 2017 12:44:27 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 75BC51321DC for ; Wed, 11 Oct 2017 12:44:27 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id a43so8742741qta.0 for ; Wed, 11 Oct 2017 12:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C8GjxdzAv2fl8bNhyQ/q/aRdfCqad8gWHpE69YiZOWk=; b=Y0YVy5N7D3VFLEXSMYQt6Pf7RV20uZShHqTbzEed6zwjWxdXTSLEH9swhHRvm6BQGd SqF1QBYf8HGYx2mlhY3tns0/CPOqgtcr1E0uGzmudZtGyYEt4r6KyaNey0xMapv3JBG2 7PaKmUbqegjNpbLH9mIg3fMkggOrup2zkRyPpKCnmve+ydTJ8PjihZok0xcSrWpbHmjU RhrRva8BEFvB7F23JpI5w/ZJCQwi9AtoQf1YjmJ0meJ+CysilUL0SjPH4t2rlsqA7LPt xL8iN3Ia/M9GWzn9//rtDduMKlwk1dxiITdpKDu/2q2itrM21N10iUCaMZltx0StkDzE Qo1w==
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=C8GjxdzAv2fl8bNhyQ/q/aRdfCqad8gWHpE69YiZOWk=; b=mNu1Ktx/R8TczZD0KxJcl5qC0MHsur2moT5NWZN10IxupZ63pzZFffMYkEStDz9omI Tnr7dcYA4cJStGfVyiV6YJjLjtyUuxLguqMT5dxtdttkoSiDiiuQfmPEfkhIKAfcDJCc nWC0sod0lVMVwzu3e5kyHPunSUfDoZhonkg6e9E3JEzlkP5TSasYJR5bG0nKXOrxDBka jJ97heNSLm2LCnloXMtnLtkycYFUXBz2BB1A7fBB+DlRjHNUgiX5YBsM4OI8i4YcFdd5 n6s7Dn1IuXUHGu9Yn8KmWFWTA5hoRw76HMrvHPDkL1cktzfgITomuWqrJar9kH7nv940 pxLw==
X-Gm-Message-State: AMCzsaU8TtQ9JZgpvEv0qz6+KkOhxHZq2XbZgG7ZV9HlagjgNuR2Lqrj 1P0ANP4iLPcgizKIoKW9zkL6/oeO9JGwdX78pKu1iw==
X-Google-Smtp-Source: AOwi7QCDpkQIJCGbA7HhOdHcL+QhvTMpLAIa+InGYGKfEkFy3Qj8ItPOsV6mtEq5XfVkPdUlkds9O0GpVTvyufrO0U4=
X-Received: by 10.37.45.110 with SMTP id s46mr428166ybe.400.1507751066585; Wed, 11 Oct 2017 12:44:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 11 Oct 2017 12:43:46 -0700 (PDT)
In-Reply-To: <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>     <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>
From: Eric Rescorla 
Date: Wed, 11 Oct 2017 12:43:46 -0700
Message-ID: 
To: Dino Farinacci 
Cc: Christian Huitema , "ietf@ietf.org" ,  "ideas@ietf.org" , "lisp@ietf.org list" 
Content-Type: multipart/alternative; boundary="f4030435adecbbe39d055b4aa667"
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:44:29 -0000

--f4030435adecbbe39d055b4aa667
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci 
wrote:

> Let me ask for your opinion Christian (or anyone else for that matter). If
> a device is assigned a private/public key-pair and the identifier for the
> device is a hash of the public-key, is the identifier private?
>
>
I can't answer this in isolation. Does the identifier show up on the wire?
If so, then totally.

-Ekr


Is the identifier trackable even when its network location is not generally
> known, not advertised publicly, and possibly changing frequently?
>
> Dino
>
> > On Oct 11, 2017, at 12:34 PM, Christian Huitema 
> wrote:
> >
> > On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:
> >> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
> >>
> >>
> >> The identity of the device is just adding a lever of identifier which
> effectively allows authentication to modify the identifiers used by that
> device but also what the users of these identifiers can look up. If we had
> used "user of identifier" it would have been misconstrued for humans. So
> damn if you do and damn if you don't ...
> >>
> >> We are open for discussions anytime.
> >>
> >
> > Some thing you should be hearing is that "long term identity of device"
> has almost the same privacy properties as "long term identity of the
> device's owner". You may think that identifying a random piece of hardware
> is no big deal, but it turns out that the network activity and network
> locations of that piece of hardware can be associated to those of its human
> owner. So you need the same kind of protection for these device identifiers
> as for human identifiers.
> > --
> > Christian Huitema
> >
>
>

--f4030435adecbbe39d055b4aa667
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <farinacci@gmail.com&g=
t; wrote:
Let me ask for your opin=
ion Christian (or anyone else for that matter). If a device is assigned a p=
rivate/public key-pair and the identifier for the device is a hash of the p=
ublic-key, is the identifier private?



I can't answer this in isolation. =
Does the identifier show up on the wire? If so, then totally.
-Ekr



Is the identifier trackable even when its network location is not generally=
 known, not advertised publicly, and possibly changing frequently?



Dino



> On Oct 11, 2017, at 12:34 PM, Christian Huitema <huitema@huitema.net> wrote:

>

> On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:

>> but you do not need a reference to a permanent identity for that -=
- systems similar to CGA would work just fine.

>>

>>

>> The identity of the device is just adding a lever of identifier wh=
ich effectively allows authentication to modify the identifiers used by tha=
t device but also what the users of these identifiers can look up. If we ha=
d used "user of identifier" it would have been misconstrued for h=
umans. So damn if you do and damn if you don't ...

>>

>> We are open for discussions anytime.

>>

>

> Some thing you should be hearing is that "long term identi=
ty of device" has almost the same privacy properties as "long ter=
m identity of the device's owner". You may think that identifying =
a random piece of hardware is no big deal, but it turns out that the networ=
k activity and network locations of that piece of hardware can be associate=
d to those of its human owner. So you need the same kind of protection for =
these device identifiers as for human identifiers.

> --

> Christian Huitema

>







--f4030435adecbbe39d055b4aa667--


From nobody Wed Oct 11 12:46:38 2017
Return-Path: 
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 24D8B1342D5; Wed, 11 Oct 2017 12:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 qgaRHldqe17A; Wed, 11 Oct 2017 12:46:31 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 0EF1C13307B; Wed, 11 Oct 2017 12:46:30 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id x7so1825854pfa.1; Wed, 11 Oct 2017 12:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wtrRrRiJUYb6SbC0JHPiKS/y2wlVTMag0wC7ZbwS8U=; b=HGuCH4XbaiYONl2tX5xE4PVQxP9Kc9uAg1A5jGFazZlRv1yXmGokd6qhtn3QiEZzuh /wRa3/Z8L6QfjcTgihthPpp3/WUlzdx8iDllbC1GAiXav/2jGWGoej2+0vqB615SsZec MW0Rnqrpi3U7bhR+9mlbqvaRJNYXpz6Qx3bu2pHYUoLTxMOsKzW2dw7IvKBghwtB9UKs CGzRzCMA7eQYNhLvn2n04fE83ZTCftuQofgUR60dElv2nOU+BjKEE05CkQ+Ijafuhxe7 4VZEueG181AYJ4/dz3IcX+smSriGizxRjtSM2HOX+5cFYRWDlH8GzEcSU/Ri9MKbTpTJ GJgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wtrRrRiJUYb6SbC0JHPiKS/y2wlVTMag0wC7ZbwS8U=; b=aC+p5vd01v+ffVbojjxYNVfQ0FsXNG4dm1oT2jROVCEFfo/sfm6HLM7scRnH6h8hEU COkxSpISis0eE6XKW8Rgu28rgCXLE+z+z4IA+pvPWQUXlgPqGADBH94Abh4VrZxHJCRq 20bQV9/oraJ7bg2q8qUm0dshe+snf/59qbyJc4SPwuZnpAz1h97fFoTPTLIhObmqNFOq wzOglFgyS/KWTi5gouCcbMK3nT8fbUQY+nCuHXNc3dHKf2W2pqT4zUbfT+ONkjHrCnHN eEF5xan7NWaM/hD2jdTKznEdPOxNUVXHf9PkMN25JsThxRLi+JgcJrWWxhgqRTja+Us+ 9vOw==
X-Gm-Message-State: AMCzsaVCghAoCGRxvC8cxvDrRTcM7JI8sXSkwpmhzuAJG0Gs6wdWgTNg P844A8d5IVQ+YSCeTJ75gsM=
X-Google-Smtp-Source: AOwi7QDolLyr+WMg9yGiZD3J63hGbdsbpIZC0RRXCXXZz485PUxR7CqagsC2X3fdymVhVLIpn7RqAA==
X-Received: by 10.98.192.6 with SMTP id x6mr110857pff.170.1507751190566; Wed, 11 Oct 2017 12:46:30 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id t81sm5116865pfg.187.2017.10.11.12.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 12:46:29 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 12:46:29 -0700
Cc: Eric Rescorla , ideas-chairs@ietf.org, ideas@ietf.org, Alissa Cooper , The IESG , aretana.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <6025671C-8868-4955-B65B-99A497550FAC@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   
To: Tom Herbert 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:46:37 -0000

> The need for a common mapping system has already been discussed for =
for years in nvo3. With the emergence of identifier-locator protocols, =
and particularly their utility to provide seamless mobility at large =
scale, the need for a well defined mapping system has become more =
evident. IMO this is a problem IETF should work on.

A public mapping system has been discussed in the LISP WG (and many have =
been designed to compare tradeoffs) since 2009. And before that in the =
IRTF Routing RG dating back to 2006.

And there was/is a 30 country, 300 site pilot research network run by =
vendors/researchers/ISPs dating back to 2007.

Dino


From nobody Wed Oct 11 12:50:00 2017
Return-Path: 
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 76DA813307B; Wed, 11 Oct 2017 12:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 AWGYrQaere_0; Wed, 11 Oct 2017 12:49:54 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 43A291320CF; Wed, 11 Oct 2017 12:49:52 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id u138so7873475wmu.4; Wed, 11 Oct 2017 12:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MzJzM2f0prtnowu+H/s6+7byUFMH4yEClyAZxsAk3AI=; b=f5N+SXiWJk6lUBogi14T3U4+rD/63qMDQLcwM57G6PDScD9zx16efd9Kf741Ip76Pv GAUAcPzrYUSNuPUwVKo9MKQJDWRapTNlGbc3qel77SmKbOlBMK5kjAZ8Pi4SUFq/LWCP 6/Ov1wvThR5pm5MrRAZ+0rBaH3cJJbxndps3ZoFRPhb/QixROO6gX78/52q/PZK8DkeK ccol+5+HEF1Y46nz5VhxSmGpeZWGO5/RPs5eXZePv4va0yT6tQEUahhx/7Ly8nWv/VMS 7SKTb/v+E+gtqB80RFg/iPUnzAQxHJ9FGhQ/iM5Shpdd5c1zKzmHvYAJu87eXWi+ybsx fzXA==
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=MzJzM2f0prtnowu+H/s6+7byUFMH4yEClyAZxsAk3AI=; b=DjUbzTYRZTa83o5AgVfkv9pCEKfEHMCcFfq4FZBO3ik68d7xBjfADFNhezcpsZcARC Bur8cv6Vv+tNOdXabCyoV9/VR1LYmbgqs0qwEbKZS8rXgmSQJhas6d8yI1J+8MVdl4s1 GK85WIgmtj1EFxeHWY+6zfiV9Cdx+Qjl0MIEyTmfFSEJ6A8qLbRl6Z0rqGmN9G6zyz8k TI+s/QDayP0YYoxQgy1grh/3O24TxaZgiR4cYBtc4KOw6ff9NL3dBs5uVLr93u4c32Yo j1h/mbLqKqE3BZ4PUSHmJtapgRxGZVLsqgXfRtk+Ogn6MhtbS3iQsrBM5oiKAuw9veOp //eA==
X-Gm-Message-State: AMCzsaUlRrcgHSMwhI8f2qUjDu8SLSPftPSRmDloohK/0tVsKwZiyIaL vIz86MTzrs+5/9m1zFW3xc/qwmPcCtS18RY7gXg=
X-Google-Smtp-Source: AOwi7QDvRNvkdyc9kfE45tMTCeyUKCITbQMzuQxZ/MRNL8z0Dimpx5VV6E2QeEaLkgTNdQweljeW9wjCKVJQAKaRDWE=
X-Received: by 10.223.199.15 with SMTP id k15mr99378wrg.111.1507751390728; Wed, 11 Oct 2017 12:49:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Wed, 11 Oct 2017 12:49:49 -0700 (PDT)
In-Reply-To: <666d4b84-72e6-8d5a-cc67-8c698d07c5b9@huitema.net>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>    <01dd6551-16f6-46e2-e861-94285c160f35@gmail.com> <28999ddc-840a-30c6-5b22-bc9b2e06a2a7@htt-consult.com>   <666d4b84-72e6-8d5a-cc67-8c698d07c5b9@huitema.net>
From: Padma Pillay-Esnault 
Date: Wed, 11 Oct 2017 12:49:49 -0700
Message-ID: 
To: Christian Huitema 
Cc: Robert Moskowitz , Stephen Farrell ,  Brian E Carpenter , IETF Discussion Mailing List , ideas@ietf.org
Content-Type: multipart/alternative; boundary="089e0824490c0dd9ed055b4aba71"
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:49:57 -0000

--089e0824490c0dd9ed055b4aba71
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 9:19 AM, Christian Huitema 
wrote:

>
>
> On 10/11/2017 9:11 AM, Robert Moskowitz wrote:
>
> On 10/11/2017 11:20 AM, Stephen Farrell wrote:
>
>
> On 11/10/17 16:12, Robert Moskowitz wrote:
>
> And interesting that it seems there have been no major breachs of things
> like SIM databases but ones with extensive PII have.
>
> https://www.theguardian.com/us-news/2015/feb/19/nsa-gchq-sim
> -card-billions-cellphones-hacking
>
> Admittedly quite a sophisticated attacker.
>
>
> Well, that is a horse of a different color.
>
>
> Don't forget that what the spooks can do today, the gangsters will do
> tomorrow, and the high school kids not so long after that...
>

If we (community of IETF) decide no work should be done unless we have an
absolute fool-proof system against insider attacks (which I do not believe
we have an answer to that) or correlation by transitivity to humans then I
would like to have some clarifications.

The need for privacy is a given and no one is disputing that but where I
struggle is in what context?

(1) Discovery vs tracking
What is considered discovery and what is considered tracking?
If you can discover then you can track? So the only way is to access
control the discovery and this is what this proposal is about!

(2) Type of data, transitivity to human
What type of data are we talking about here? Do we believe that having
careful applications where encrypted sensitive data are not colocated with
location information so that attacks will require multi-level attacks on
multiple systems and cross-referencing a deterrent and good enough? If on
top of that we have sensitive information (human) encrypted database with
one way communications and changing identifiers etc etc as discussed.... is
that a good start or not even close?

(3) Tracking as a business model
How about companies specialized with services of tracking and discovering
things?
Pet tracking ? How about the truck driver with assisted driving?  Asset
tracking as in bikes where people swipe a wireless card? How would this
business model even work if they cannot recover their assets because we can
track a person through transitivity?

(4) Tracking who and by whom
More concerning to me is that privacy is tricky, depending on the
perspective...
We want to protect the "good" guys but isn't that also enabling the privacy
of the "bad" guys?
Should the individual behind mirai bonnet attacks or gansters be entitled
to privacy and non tracking?

(5) Tracking is all evil?
BUT then there is this annoying question that comes back to my mind .. do
we EVER consider that human tracking is needed or beneficial?
What about disaster recovery scenarios or emergency services or people who
willingly want to participate in such a service?

For example with an aging population, assisted living with monitoring
health devices is a trend in the industry. These devices can be mobile. Not
everyone can afford a caregiver full time ... So is it just going to be "no
sorry ma'am someone may use this technology to do bad things with it?" It
might be a matter of life and death to be able to track a person.

The truth is that these services exist today outside of IETF technology and
people are willingly subscribing to it because their priorities are
different.


While I completely agree we should be careful in what we do.

Disclaimer trying to clarify how/where ideas is situated in all that?
1. It was not aimed for a wide scale deployed on the internet but it may be
large enterprises.
2. It had no human info but it has been inferred this may be possible
through transitivity
3. It has changing identifiers

So we need protection  - again no one disputes that ... if we have better
technology let's integrate it.

Let's not through the baby with the bathwater ...



Padma

-- 
> Christian Huitema
>
>

--089e0824490c0dd9ed055b4aba71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 9:19 AM, Christian Huitema &l=
t;huitema@huitema.=
net> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 10/11/2017 9:11 A=
M, Robert Moskowitz
      wrote:

    

    
On
      10/11/2017 11:20 AM, Stephen Farrell wrote:
      

      

        

        On 11/10/17 16:12, Robert Moskowitz wrote:
        

        
And interestin=
g
          that it seems there have been no major breachs of things
          

          like SIM databases but ones with extensive PII have.
          

        

        https://www.theguardian.com/us-news/=
2015/feb/19/nsa-gchq-sim-card-billions-cellphones-hacking
        

        

        Admittedly quite a sophisticated attacker.
        

      

      

      Well, that is a horse of a different color.
    

    

    Don't forget that what the spooks can do today, the gangsters will
    do tomorrow, and the high school kids not so long after that...

If we (community of IETF) decide no work sho=
uld be done unless we have an absolute fool-proof system against insider at=
tacks (which I do not believe we have an answer to that) or correlation by =
transitivity to humans then I would like to have some clarifications.
=


The need for privacy is a given and no one is disputing=
 that but where I struggle is in what context?

(1) Discovery vs tracking=C2=A0
What is considered discovery and=
 what is considered tracking?
If you can discover then you can tr=
ack? So the only way is to access control the discovery and this is what th=
is proposal is about!

(2) Type of data, transitivi=
ty to human
What type of data are we talking about here? Do we be=
lieve that having careful applications where encrypted sensitive data are n=
ot colocated with location information so that attacks will require multi-l=
evel attacks on multiple systems and cross-referencing a deterrent and good=
 enough? If on top of that we have sensitive information (human) encrypted =
database with one way communications and changing identifiers etc etc as di=
scussed.... is that a good start or not even close?

(3) Tracking as a business model
How about companies specialize=
d with services of tracking and discovering things?=C2=A0
Pet tra=
cking ? How about the truck driver with assisted driving?=C2=A0 Asset track=
ing as in bikes where people swipe a wireless card? How would this business=
 model even work if they cannot recover their assets because we can track a=
 person through transitivity?=C2=A0

(4) Tracking w=
ho and by whom
More concerning to me is that privacy is tric=
ky, depending on the perspective...
We want to protect the "=
good" guys but isn't that also enabling the privacy of the "b=
ad" guys?
Should the individual behind mirai bonnet attacks =
or gansters be entitled to privacy and non tracking?
(5) Tracking is all evil?
BUT then there is thi=
s annoying question that comes back to my mind .. do we EVER consider that =
human tracking is needed or beneficial?
What about disaster recov=
ery scenarios or emergency services or people who willingly want to partici=
pate in such a service?=C2=A0=C2=A0

For example wi=
th an aging population, assisted living with monitoring health devices is a=
 trend in the industry. These devices can be mobile. Not everyone can affor=
d a caregiver full time ... So is it just going to be "no sorry ma'=
;am someone may use this technology to do bad things with it?" It migh=
t be a matter of life and death to be able to track a person.=C2=A0

The truth is that these services exist today outside of I=
ETF technology and people are willingly subscribing to it because their pri=
orities are different.


While =
I completely agree we should be careful in what we do.=C2=A0
=

Disclaimer trying to clarify how/where ideas is situated in =
all that?
1. It was not aimed for a wide scale deployed on the in=
ternet but it may be large enterprises.
2. It had no human info b=
ut it has been inferred this may be possible through transitivity=C2=A0
3. It has changing identifiers

So we need p=
rotection =C2=A0- again no one disputes that ... if we have better technolo=
gy let's integrate it.=C2=A0

Let's not thr=
ough the baby with the bathwater ...



Padma

--=20
Christian Huitema

  






--089e0824490c0dd9ed055b4aba71--


From nobody Wed Oct 11 12:51:58 2017
Return-Path: 
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 9A29B132351; Wed, 11 Oct 2017 12:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 nHBsRq31QtD0; Wed, 11 Oct 2017 12:51:40 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 B3BF313307B; Wed, 11 Oct 2017 12:51:40 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id n73so1816509pfg.10; Wed, 11 Oct 2017 12:51:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vC/Ez/TBsoaazVU+xkU2Ny7qXJ4UoUPDVj6TsAZcxVg=; b=isX7G69A/5zhcEjyFKrrCw65sVgqht7R7wOgx+JLigtbrBIs5/l0JSsOLZEYY5esKn pMD2h/jg/NHLp1QXYiKyAxDEwiWb11WrqqRrB2rel12tnP+ikyg2rY5xzcBS8CDk7Bav Qd1mDdRFuTyT6AUv4rUj18aXtqXtiphLQNC1px9ZPFb7iSoVAYjv+PO4bwvPYllWZh4E vOszwjNeQ+tnomr7ErlUHYvYQrILA1mynnQ6CH9CylkgW4uExT2rb9NjRll1ZInW9Tcq UiQRoBkfxAoYYTFjAu9ylheo3mkHCBG3qttLHzFTZp0oKIbBcVci1yFECTkw/XTD61Km j7cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vC/Ez/TBsoaazVU+xkU2Ny7qXJ4UoUPDVj6TsAZcxVg=; b=OSQKyf2G+SS6NXtNEqRxxjHY8HrX7FZSPX0X6XfIopgCFgjVRZ3l7DZXosqfY3eFR+ 5WiuZxr0d4miLXLtAIYgRsOUDEIUqCqleoNUC1kmZamw2DFxPOcYUJwejM0py0Edl/DT 3EkPvbGuiurC9qUmbLzzd6J3VCjPz5Hp5DqgWaZ2Z3+B9CUKP7/yRrK86b2xQcFoHpLi YfPRazDuqMQOBRul6W+KygVk2p9kUceSII53BHEJrvBbyl8tLL7OdpB8TX7qeJogxw+T ewxsa/MGRK9orMLSPd0ip18bYLFKjwU7IMZzwxcOQN5ExosyQ6AU2MUjSttcfoBqnrh+ ENxg==
X-Gm-Message-State: AMCzsaVQ7V/5S/WzUTUNMqa2sLJqPiTPJ2BMJuhp0sKn2qDBTmWouQUt 9hcwYf7214BgtPIcw2htocc=
X-Google-Smtp-Source: AOwi7QBhyPfODimblgpsPa0jUozgGVUYfrVMcByCXpTmePIpmjLC6eXnn0o45ZSPE1pnln34A+1NXw==
X-Received: by 10.98.24.20 with SMTP id 20mr105918pfy.71.1507751500277; Wed, 11 Oct 2017 12:51:40 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id r77sm17440000pfk.93.2017.10.11.12.51.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 12:51:39 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 12:51:38 -0700
Cc: Christian Huitema , "ietf@ietf.org" ,  "ideas@ietf.org" , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>     <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com> 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:51:47 -0000

> On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci  =
wrote:
> Let me ask for your opinion Christian (or anyone else for that =
matter). If a device is assigned a private/public key-pair and the =
identifier for the device is a hash of the public-key, is the identifier =
private?
>=20
>=20
> I can't answer this in isolation. Does the identifier show up on the =
wire? If so, then totally.

When the payload is encrypted, it does not. So let me ask you these =
follow-up questions:

(1) If a host sources a packet with its identifier in one VM and an =
encapsulator in another VM (in the same physical system) encapsulates =
the packet but encrypts the payload before encapsulation, has the =
identifier remain private?

(2) If in (1), the packet is decapsulated by an intermmediate point, and =
then reencapsulated but the packet is encrypted with a new session key =
(from a new ECDH exchange) to the destination, has the identifier =
remained private?

Dino

>=20
> -Ekr
>=20
>=20
> Is the identifier trackable even when its network location is not =
generally known, not advertised publicly, and possibly changing =
frequently?
>=20
> Dino
>=20
> > On Oct 11, 2017, at 12:34 PM, Christian Huitema =
 wrote:
> >
> > On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:
> >> but you do not need a reference to a permanent identity for that -- =
systems similar to CGA would work just fine.
> >>
> >>
> >> The identity of the device is just adding a lever of identifier =
which effectively allows authentication to modify the identifiers used =
by that device but also what the users of these identifiers can look up. =
If we had used "user of identifier" it would have been misconstrued for =
humans. So damn if you do and damn if you don't ...
> >>
> >> We are open for discussions anytime.
> >>
> >
> > Some thing you should be hearing is that "long term identity of =
device" has almost the same privacy properties as "long term identity of =
the device's owner". You may think that identifying a random piece of =
hardware is no big deal, but it turns out that the network activity and =
network locations of that piece of hardware can be associated to those =
of its human owner. So you need the same kind of protection for these =
device identifiers as for human identifiers.
> > --
> > Christian Huitema
> >
>=20
>=20


From nobody Wed Oct 11 12:52:40 2017
Return-Path: 
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 EB9961342E2; Wed, 11 Oct 2017 12:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZoqNhNawnEO2; Wed, 11 Oct 2017 12:52:28 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A7B1342F7; Wed, 11 Oct 2017 12:52:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0CCDA621D5; Wed, 11 Oct 2017 15:52:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Ho+7yIppRKY; Wed, 11 Oct 2017 15:52:09 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1108B621CD; Wed, 11 Oct 2017 15:52:06 -0400 (EDT)
To: Dino Farinacci , Eric Rescorla 
Cc: ideas-chairs@ietf.org, ideas@ietf.org, Alissa Cooper ,  The IESG , aretana.ietf@gmail.com
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>  
From: Robert Moskowitz 
Message-ID: <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com>
Date: Wed, 11 Oct 2017 15:52:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:52:38 -0000

Just before I shut down for the week...

And I am in conversation with VC funding for IIoT that will build their 
own just like this.  Only one will put any effort into privacy because 
there is no leadship.

Dino and I are connected outside the IETF.  These groups come to us to 
talk, then go back and do their own thing to fill the void.  They will 
NOT come to the IETF, but will take what is offered.

Bob

On 10/11/2017 03:30 PM, Dino Farinacci wrote:
> I am reaching out to the SD-WAN community. There has been huge investment from the VC community in overlay startups. They are all using proprietary control-planes. There is no interoperability among them. The IETF should not ignore this market and should help shape it.
>
> This is VXLAN-in-the-data-center market all over again making IETF working group nvo3 irrelevant.
>
> Mapping Databases ARE being deployed under the auspices of SDN-controllers. There are high profile user-groups that endorse the activity. It is not going away.
>
> IETF needs to lead and not follow.
>
> Dino
>
>
>> On Oct 11, 2017, at 12:20 PM, Eric Rescorla  wrote:
>>
>>
>>
>> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci  wrote:
>>> (1) The work is insufficiently motivated. The claims about the need for the
>>> mapping system and the identity management system envisioned here do not appear
>>> to be backed up by those who have developed and deployed ID/LOC separation
>>> protocols. Nor do there seem to be compelling arguments that the framework that
>>> this proposed WG would produce would be the motivator for further interoperable
>>> deployments.
>> This is simply not true. The IETF mailing lists are not finding the reach of interest that exists in the industry
>>
>> Be that as it may, the determination of consensus and justification has to be made primarily on what appears on the mailing lists and at meetings.
>>
>> -Ekr
>>
>>
>> Dino
>>
>>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Wed Oct 11 12:53:39 2017
Return-Path: 
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 EB3A51342EB; Wed, 11 Oct 2017 12:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=RgNtFT8V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hgOa81s9
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 WFoqiJj5gubA; Wed, 11 Oct 2017 12:53:09 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4821342E9; Wed, 11 Oct 2017 12:52:59 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E618421590; Wed, 11 Oct 2017 15:52:58 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 11 Oct 2017 15:52:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=zmcF1w5RksoANN5vfbkqxt+vJ2L/bIjFMjHIGdaU0yk=; b=RgNtFT8V 4zCF/GHxAV+wUckal2sWuD1mqhjNvRRuFKm8s9oFA8PpSN7O/5NCgWkvbwwoK5ef GbvMlZIDItgZCi+l0MliOzJt9vRZt2GMpj9mI61UVGPpDS3CESK5ag5OQ65ZiP9o 3QuqvHFiIHw1erOEOmImWjwbp1I1CJLZy/H+9EuW4OSAeB7QX8319TDMvCarl0PB rFl0SUdYsZPZQeWfI2m+EUgzd7281LN4R7ks9Fb6h+ZX8yxz/PoWbPRtxJz9uAQn 0JjMG8WSiKV0Rc3gArygfY2B2DDaNcfqgkORkuVJQTjYjodPke+LFhpcsLWrmTPK TUQx/Aulsd63Tw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=zmcF1w5RksoANN5vfbkqxt+vJ2L/b IjFMjHIGdaU0yk=; b=hgOa81s9JQjNIxq+apEBqD/XBU+rgBvJArMlxNqyuN1UX yteUxLDupSun/fbVgaIQeyCpGIH/biXsawdRH2rGQHe3hB5azFzEPREE1nsQ1UXu qyuPv3aa1lglvDZzwNhJli5zeUN3zzx1tvJix5IZHfnXKnLGxpZXiKgyZffwXrEw 0wT7yHqdg4lh4pUsfMEB2xrkVemy3OTKg7R+Gr7713bzcAlwsI574F9zeHa6gTHl 3Lp5h30qOMXiHyu72pNh0FZSBgzG8MXowxgdy6XhYm0cJybq+KojLJUemJG5sRgb D+4AwrwQ5ocpnmJXQ+7HgB3fignysC8WKZ4YG1XyA==
X-ME-Sender: 
Received: from sjc-alcoop-88112.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 63EE82479F; Wed, 11 Oct 2017 15:52:57 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E536AA4B-29E1-43A6-A99D-19F194539EBD"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: 
Date: Wed, 11 Oct 2017 15:52:55 -0400
Cc: Dino Farinacci , Eric Rescorla , ideas-chairs@ietf.org, ideas@ietf.org, IESG , aretana.ietf@gmail.com
Message-Id: <98DFD478-9B18-4F5E-B5DC-0DD254DC7FC2@cooperw.in>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   
To: Tom Herbert 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:53:29 -0000

--Apple-Mail=_E536AA4B-29E1-43A6-A99D-19F194539EBD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Oct 11, 2017, at 3:42 PM, Tom Herbert  wrote:
>=20
>=20
>=20
> On Wed, Oct 11, 2017 at 12:30 PM, Dino Farinacci > wrote:
> I am reaching out to the SD-WAN community. There has been huge =
investment from the VC community in overlay startups. They are all using =
proprietary control-planes. There is no interoperability among them. The =
IETF should not ignore this market and should help shape it.
>=20
> This is VXLAN-in-the-data-center market all over again making IETF =
working group nvo3 irrelevant.
>=20
> Mapping Databases ARE being deployed under the auspices of =
SDN-controllers. There are high profile user-groups that endorse the =
activity. It is not going away.
>=20
> IETF needs to lead and not follow.
>=20
> +1
>=20
> The need for a common mapping system has already been discussed for =
for years in nvo3. With the emergence of identifier-locator protocols, =
and particularly their utility to provide seamless mobility at large =
scale, the need for a well defined mapping system has become more =
evident. IMO this is a problem IETF should work on.
>=20
> Note that identity, which is what most of this discussion has been =
about, is only one aspect of the mapping system for identifier-locator =
protocols and network virtualization. There are many other aspects that =
have not been mentioned but need attention. I am worried that we might =
be throwing the baby out with the bath water as they say=E2=80=A6

The immediate question before the IESG is whether to charter a working =
group with the charter and deliverables as currently proposed. If =
someone wanted to propose a more limited charter or a different charter =
that focuses on these unmentioned aspects, we would certainly evaluate =
it anew.

Alissa

>=20
> Tom
> =20
> Dino
>=20
>=20
> > On Oct 11, 2017, at 12:20 PM, Eric Rescorla > wrote:
> >
> >
> >
> > On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci =
> wrote:
> >> (1) The work is insufficiently motivated. The claims about the need =
for the
> >> mapping system and the identity management system envisioned here =
do not appear
> >> to be backed up by those who have developed and deployed ID/LOC =
separation
> >> protocols. Nor do there seem to be compelling arguments that the =
framework that
> >> this proposed WG would produce would be the motivator for further =
interoperable
> >> deployments.
> >
> > This is simply not true. The IETF mailing lists are not finding the =
reach of interest that exists in the industry
> >
> > Be that as it may, the determination of consensus and justification =
has to be made primarily on what appears on the mailing lists and at =
meetings.
> >
> > -Ekr
> >
> >
> > Dino
> >
> >
>=20
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org 
> https://www.ietf.org/mailman/listinfo/ideas =

>=20


--Apple-Mail=_E536AA4B-29E1-43A6-A99D-19F194539EBD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Oct 11, 2017, at 3:42 PM, Tom Herbert <tom@herbertland.com>=
 wrote:



On Wed, Oct 11, 2017 at 12:30 PM, =
Dino Farinacci <farinacci@gmail.com> wrote:
I am reaching out to =
the SD-WAN community. There has been huge investment from the VC =
community in overlay startups. They are all using proprietary =
control-planes. There is no interoperability among them. The IETF should =
not ignore this market and should help shape it.



This is VXLAN-in-the-data-center market all over again making IETF =
working group nvo3 irrelevant.



Mapping Databases ARE being deployed under the auspices of =
SDN-controllers. There are high profile user-groups that endorse the =
activity. It is not going away.



IETF needs to lead and not follow.


+1

The need for a common =
mapping system has already been discussed for for years in nvo3. With =
the emergence of identifier-locator protocols, and particularly their =
utility to provide seamless mobility at large scale, the need for a well =
defined mapping system has become more evident. IMO this is a problem =
IETF should work on.

Note that identity, which is what most of this discussion has =
been about, is only one aspect of the mapping system for =
identifier-locator protocols and network virtualization. There are many =
other aspects that have not been mentioned but need attention. I am =
worried that we might be throwing the baby out with the bath water as =
they say=E2=80=A6

The immediate question before the IESG is whether =
to charter a working group with the charter and deliverables as =
currently proposed. If someone wanted to propose a more limited charter =
or a different charter that focuses on these unmentioned aspects, we =
would certainly evaluate it anew.

Alissa


Tom
 

Dino






> On Oct 11, 2017, at 12:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>

>

>

> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci <farinacci@gmail.com>=
 wrote:

>> (1) The work is insufficiently motivated. The claims about the =
need for the

>> mapping system and the identity management system envisioned =
here do not appear

>> to be backed up by those who have developed and deployed ID/LOC =
separation

>> protocols. Nor do there seem to be compelling arguments that =
the framework that

>> this proposed WG would produce would be the motivator for =
further interoperable

>> deployments.

>

> This is simply not true. The IETF mailing lists are not finding the =
reach of interest that exists in the industry

>

> Be that as it may, the determination of consensus and justification =
has to be made primarily on what appears on the mailing lists and at =
meetings.

>

> -Ekr

>

>

> Dino

>

>




_______________________________________________

Ideas mailing list

Ideas@ietf.org

https://www.ietf.org/mailman/listinfo/ideas






=

--Apple-Mail=_E536AA4B-29E1-43A6-A99D-19F194539EBD--


From nobody Wed Oct 11 12:58:48 2017
Return-Path: 
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 4CB641342DB for ; Wed, 11 Oct 2017 12:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 CkcTNsExpyAc for ; Wed, 11 Oct 2017 12:58:39 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 65DE613307B for ; Wed, 11 Oct 2017 12:58:37 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id p1so8825586qtg.2 for ; Wed, 11 Oct 2017 12:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l70Gu05Ng6IDXOQ9t7Dw+emfQY83Pr+3ePuITM/8kQ8=; b=gmqTKbrtN5LZ31Zb9fRcfrynkXQbmL0dAkxkaD16DCGqn2afjn7b2x77QTkepanXe4 IWbhvQO/MNBe+BeVrGC6vTNIZ6XRq21i+KuO1H/oBBp4wmZoRepTQzUZnvvRReaB+v/0 D9kblX1rgl0plxOgnQsku7N5I1jHJTPjzvieCepk0fO+6qQyjtjb+Uqi8M1UyIqXQ1lt e1N9Rw/m5x5mCRDtQA115vsFVN7iaPm4Y/5QKwYKEkxELpP22zjjEEdLHW/XPs0s6fic 97/oZRjjMHx68DqfNnEzeQSLQS46xhNPRqBzzdEFL0WU4G+Onc09RGVG/bnWjLpcDSBd dSgA==
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=l70Gu05Ng6IDXOQ9t7Dw+emfQY83Pr+3ePuITM/8kQ8=; b=NoYlceCjeWyn8J1y7D0TgXdaR2T1uq8Gt8lfxSgX6w7wVdD/wbXXHn5r5XMqm5+u+k 2SQlG6gmsRo2Qlsy8QtZa0I8G8wGjLbm8g0wouy1neYorQNcbwnA9ZOm8dVZXLKSaka6 rGeOQdxawH2fdyNs2wYJ1fIc3X19xXKjVmu63+wYN08Zkzj3jJeqaT6uIUccT+QOyIBs ZY31jJqQ+9idTqI5r+3oKH7uJM5cxlk0q+733Q4g1Kig1if9imAZhEQJeGXOnxK5IRAy Ahe4672cPuj8xXlkqxrvhZXSqw6NSFbwdAj5aRtQLUcyfoSD4e62gNeXYLVrz6Vnietd vQQA==
X-Gm-Message-State: AMCzsaX1mEGfJPtSC2OxbZX5Hihi1Glmn4dJccp/JMqr/O5Los33FXYo GF38RlRTbjSfBp8qxtj+CCHVofaWECn0LQyZVHl6Hw==
X-Google-Smtp-Source: AOwi7QCeKPm9S1Ah83s+nDSkDjSd1vOks1XlbguHucB/+kRmy3ekBQb8JhlpcOirwqJAl++NWqwerEu3s2N8lGANSkQ=
X-Received: by 10.37.51.68 with SMTP id z65mr445311ybz.353.1507751916477; Wed, 11 Oct 2017 12:58:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 11 Oct 2017 12:57:55 -0700 (PDT)
In-Reply-To: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>     <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>  
From: Eric Rescorla 
Date: Wed, 11 Oct 2017 12:57:55 -0700
Message-ID: 
To: Dino Farinacci 
Cc: Christian Huitema , "ietf@ietf.org" ,  "ideas@ietf.org" , "lisp@ietf.org list" 
Content-Type: multipart/alternative; boundary="001a1148aa62643246055b4ad9cf"
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:58:45 -0000

--001a1148aa62643246055b4ad9cf
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:51 PM, Dino Farinacci 
wrote:

> > On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci 
> wrote:
> > Let me ask for your opinion Christian (or anyone else for that matter).
> If a device is assigned a private/public key-pair and the identifier for
> the device is a hash of the public-key, is the identifier private?
> >
> >
> > I can't answer this in isolation. Does the identifier show up on the
> wire? If so, then totally.
>
> When the payload is encrypted, it does not.


Are the handshakes that establish the cryptographic keys used to encrypt
the payload themselves encrypted? If it's IKE, the answer is probably yes,
but if not, I don't know.


So let me ask you these follow-up questions:
>
> (1) If a host sources a packet with its identifier in one VM and an
> encapsulator in another VM (in the same physical system) encapsulates the
> packet but encrypts the payload before encapsulation, has the identifier
> remain private?
>
> (2) If in (1), the packet is decapsulated by an intermmediate point, and
> then reencapsulated but the packet is encrypted with a new session key
> (from a new ECDH exchange) to the destination, has the identifier remained
> private?
>

Generally, I don't tend to think of things as being "private" or
"non-private". Rather we talk about who has a given capability or piece of
information. I think it's clear that in these cases the identifier was
available to the machine doing the deencapsulation/reencapsulation.
Obviously, that's worse for privacy than having it not have that
information. How much worse depends on a lot of factors.

In this particular, work, however, it seems like the privacy concerns are
about:

1. Whether the ID mapping systems reveal who is talking to who.
2. Whether this creates persistent identifiers that would otherwise be
destroyed when people changed their location

Maybe Christian and Stephen would like to say more about their concerns
-Ekr

>
> Dino
>
> >
> > -Ekr
> >
> >
> > Is the identifier trackable even when its network location is not
> generally known, not advertised publicly, and possibly changing frequently?
> >
> > Dino
> >
> > > On Oct 11, 2017, at 12:34 PM, Christian Huitema 
> wrote:
> > >
> > > On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:
> > >> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
> > >>
> > >>
> > >> The identity of the device is just adding a lever of identifier which
> effectively allows authentication to modify the identifiers used by that
> device but also what the users of these identifiers can look up. If we had
> used "user of identifier" it would have been misconstrued for humans. So
> damn if you do and damn if you don't ...
> > >>
> > >> We are open for discussions anytime.
> > >>
> > >
> > > Some thing you should be hearing is that "long term identity of
> device" has almost the same privacy properties as "long term identity of
> the device's owner". You may think that identifying a random piece of
> hardware is no big deal, but it turns out that the network activity and
> network locations of that piece of hardware can be associated to those of
> its human owner. So you need the same kind of protection for these device
> identifiers as for human identifiers.
> > > --
> > > Christian Huitema
> > >
> >
> >
>
>

--001a1148aa62643246055b4ad9cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 12:51 PM, Dino Farinacci <=
farinacci@gmail.co=
m> wrote:
=
> On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <farinacci@gmail.com> wrote:

> Let me ask for your opinion Christian (or anyone else for that matter)=
. If a device is assigned a private/public key-pair and the identifier for =
the device is a hash of the public-key, is the identifier private?

>

>

> I can't answer this in isolation. Does the identifier show up on t=
he wire? If so, then totally.



When the payload is encrypted, it does not.

Are the handshakes that establish the cryptographic keys used to en=
crypt the payload themselves encrypted? If it's IKE, the answer is prob=
ably yes, but if not, I don't know.


=

So let me ask you these follow-up questions:=




(1) If a host sources a packet with its identifier in one VM and an encapsu=
lator in another VM (in the same physical system) encapsulates the packet b=
ut encrypts the payload before encapsulation, has the identifier remain pri=
vate?



(2) If in (1), the packet is decapsulated by an intermmediate point, and th=
en reencapsulated but the packet is encrypted with a new session key (from =
a new ECDH exchange) to the destination, has the identifier remained privat=
e?

Generally, I don't tend to think=
 of things as being "private" or "non-private". Rather =
we talk about who has a given capability or piece of information. I think i=
t's clear that in these cases the identifier was available to the machi=
ne doing the deencapsulation/reencapsulation. Obviously, that's worse f=
or privacy than having it not have that information. How much worse depends=
 on a lot of factors.

In this particular, work, ho=
wever, it seems like the privacy concerns are about:

1. Whether the ID mapping systems reveal who is talking to who.
2. Whether this creates persistent identifiers that would otherwise be de=
stroyed when people changed their location

Maybe C=
hristian and Stephen would like to say more about their concerns
=
-Ekr=C2=A0



Dino




>

> -Ekr

>

>

> Is the identifier trackable even when its network location is not gene=
rally known, not advertised publicly, and possibly changing frequently?

>

> Dino

>

> > On Oct 11, 2017, at 12:34 PM, Christian Huitema <huitema@huitema.net> wrote:

> >

> > On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:

> >> but you do not need a reference to a permanent identity for t=
hat -- systems similar to CGA would work just fine.

> >>

> >>

> >> The identity of the device is just adding a lever of identifi=
er which effectively allows authentication to modify the identifiers used b=
y that device but also what the users of these identifiers can look up. If =
we had used "user of identifier" it would have been misconstrued =
for humans. So damn if you do and damn if you don't ...

> >>

> >> We are open for discussions anytime.

> >>

> >

> > Some thing you should be hearing is that "long term identity=
 of device" has almost the same privacy properties as "long term =
identity of the device's owner". You may think that identifying a =
random piece of hardware is no big deal, but it turns out that the network =
activity and network locations of that piece of hardware can be associated =
to those of its human owner. So you need the same kind of protection for th=
ese device identifiers as for human identifiers.

> > --

> > Christian Huitema

> >

>

>







--001a1148aa62643246055b4ad9cf--


From nobody Wed Oct 11 13:00:03 2017
Return-Path: 
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 67B14134184; Wed, 11 Oct 2017 12:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 c2g9gamFTC7f; Wed, 11 Oct 2017 12:59:49 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 134441320CF; Wed, 11 Oct 2017 12:59:49 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id p87so1858592pfj.3; Wed, 11 Oct 2017 12:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YEx9VG5pTYJBg+WfJhdv96McePHUjKGdgmt8jkD/ZqY=; b=NPWfUbeMOMMQjylJ6Z6Pf3S2YI1F1mCJQi4yxIDq4dngE/6L7PkospqvIZMs3hJR/o VmNVHK6kqd56YyJ87tqSY0QMSkSQxy4IGiRRvqbAZKOJqfDeLCOuqZYkltYRi62mhhal Cdy+EjYlPY0hC3HXww1ZZjFDECmfiZ7DRcPZd+KuzPABoK/arsQaV+cHIjxKF2msj7sJ 2D2f/LVXN5Gl56oNS3RCgsDuapzopElaqrLXwhDMQrj05sqVHKWPORkSPrqY20wByrVq 8OUYL5Pv0EPelIyHMopmpB0VpRYhJhNywA1T0Bk8pm3yOfdupqnFJk4FPTEg0t1A3dR/ iNng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YEx9VG5pTYJBg+WfJhdv96McePHUjKGdgmt8jkD/ZqY=; b=MaKxq9nR7l//t6gQzpawSLybMG9jx81lHa90CG9XfmAQhAJ0p3xyMXQEF/GyvBTB8v Of8yFWAPPRAMNnfF0S1YNQbZdZT1qC23HuXAeIc4kK/QnyRiZ6mR4qEQnfIyBc1C8hlq tKaZJvm20PiPiargnWiNNwdBJqduQvNhDJsZW36zW2nqKibrvT2bnRKqQifeSDSTfUhR zD+Z8q9Ixcc1FlekAASfd7L9yYHVdgcjHlZK/GiPVSx0hBMxMmB3iA4ny+CzUAeuUvYd 5sUSaQb1JxVkQwZ7NROl45poVv8PJwNlRoNl3R/4ajxcaqU2u49S3LcvQcgmWY7Dr3r4 gMlA==
X-Gm-Message-State: AMCzsaV5lmFGi/wYlu3eLXfVekg2VAJilLm8njt0Js3bk96R8Rn35l51 Hu0CdrT4RYiELY4CNTAez24=
X-Google-Smtp-Source: AOwi7QBZXhDzqlEIyY3MOHLAof/3hDBk3ljp3c++o7DAO7wGnzK3xn2tNnd0ddqYvKB9ERR+gZCCHA==
X-Received: by 10.98.4.67 with SMTP id 64mr132492pfe.214.1507751988718; Wed, 11 Oct 2017 12:59:48 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id e2sm27201537pfc.176.2017.10.11.12.59.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 12:59:48 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com>
Date: Wed, 11 Oct 2017 12:59:47 -0700
Cc: Eric Rescorla , ideas-chairs@ietf.org, ideas@ietf.org, Alissa Cooper , The IESG , aretana.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com>
To: Robert Moskowitz 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 19:59:55 -0000

> Dino and I are connected outside the IETF.  These groups come to us to =
talk, then go back and do their own thing to fill the void.  They will =
NOT come to the IETF, but will take what is offered.

And of course, the typical mantra from them (and I know you all have =
heard this before):

(1) The IETF is too slow.

(2) The IETF cannot decide.

(3) The IETF has too many options. So we are going to pick one and put =
our Intellectual Property on top of it (i.e. SD-WAN IPsec doesn=E2=80=99t =
interoperate).

(4) We can do protocols better and faster than the IETF.

(5) We want to build our own protocols so we look innovative.

(6) We can get strategic interoperability with our business partners.

Dino=


From nobody Wed Oct 11 13:04:12 2017
Return-Path: 
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 4358F132351; Wed, 11 Oct 2017 13:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 I5W9nRz7UeLt; Wed, 11 Oct 2017 13:04:09 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 DAB94134292; Wed, 11 Oct 2017 13:04:08 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id q124so7867013wmb.0; Wed, 11 Oct 2017 13:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9tBJ4D/2VkTg47yr+iB+9B+K73xY903nyiQUF+9mqxA=; b=YByBbFW4FePNfAO7SHBY9eBgs0Mj1jAWcJ0Rx58XGeAn/We0AMj9PxPskwZGF+TXBg 6YeC/g6mUm9hPm6oAYqz25jWeRLd2m4q4qjVMK21R2So//TAi/DyHuYOi435sCyD33mY r6DZJ/D9TOoDWmnf6T61Stabmqzz1gzZZe7RIiGeTr9ymJ4kBYEU9QPR/IBDpYrJRNdF 3x/TB2zYlDsMmNoLysjiVlGD15Y5UFFP+YfdlF2EJDs0MAzxi7Dk52zbCC2Ht2EfXj62 oakfB23TpLVPEWxMk4e5ucYCjcWut6Jbl10sV/g6zrUqRlB4xrm7ygVKAkXj8M4wtxry /YEg==
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=9tBJ4D/2VkTg47yr+iB+9B+K73xY903nyiQUF+9mqxA=; b=RS0nVVOPrIzptArenIq9sF3nft+psDqF8HAz+pXx55jMFKZW0hiQZG+uCcd9OM/7iY C8L1ct6zQIHgQVR7MmboG46NlHnf+N+gybxDeMS5x8/aJqIw399bcXTeMt1FUgnAP2fF QVT6rYH1Nz7YyiW9LKdK7jwhXSMMThsOlwS0dERWmYzpgHI3NNCKAZ+sQO1sNu0dPu3t 9A/F4PW3rXwpsYJjOSjt51RsaPFmukxVL2CUn8KzXK37SW7sNnT16RwoYA61mL2pNALG YVW1dgg+8iDJSJ8rdSp6M8oiun2/ojIb5qm/0GMS6hQUPVbqqQLTrSiu8SmibkPzKq+f Ccpw==
X-Gm-Message-State: AMCzsaXiGuLCPr7irA5agDk7q+bbkB00nlsYoyypJeE8mzFq+7dtjBrP cg3adpFkatH1T2qh/tt6xj3Y79G8x/J+97+dLZ4=
X-Google-Smtp-Source: AOwi7QBpNbf4YrkTqVAgRFeiNDiCv2bNf7dS54v9WeC48y/gcsvHMtJ+KtSnEx2r5pH7aKVGkTJOq+KcHz0ccq1oZO0=
X-Received: by 10.223.146.101 with SMTP id 92mr107604wrj.21.1507752247501; Wed, 11 Oct 2017 13:04:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Wed, 11 Oct 2017 13:04:06 -0700 (PDT)
In-Reply-To: <98DFD478-9B18-4F5E-B5DC-0DD254DC7FC2@cooperw.in>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>    <98DFD478-9B18-4F5E-B5DC-0DD254DC7FC2@cooperw.in>
From: Padma Pillay-Esnault 
Date: Wed, 11 Oct 2017 13:04:06 -0700
Message-ID: 
To: Alissa Cooper 
Cc: Tom Herbert , Dino Farinacci ,  Eric Rescorla , ideas-chairs@ietf.org, ideas@ietf.org, IESG , Alvaro Retana , Padma Pillay-Esnault 
Content-Type: multipart/alternative; boundary="94eb2c0896a81f285a055b4aed93"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:04:11 -0000

--94eb2c0896a81f285a055b4aed93
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 11, 2017 at 12:52 PM, Alissa Cooper  wrote:

>
>
> The immediate question before the IESG is whether to charter a working
> group with the charter and deliverables as currently proposed. If someone
> wanted to propose a more limited charter or a different charter that
> focuses on these unmentioned aspects, we would certainly evaluate it anew.
>
>
I'll take this task up and work on it.

Padma


> Alissa
>
>
>

--94eb2c0896a81f285a055b4aed93
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 12:52 PM, Alissa Cooper <<=
a href=3D"mailto:alissa@cooperw.in" target=3D"_blank">alissa@cooperw.in=
> wrote:


The immediate question before th=
e IESG is whether to charter a working group with the charter and deliverab=
les as currently proposed. If someone wanted to propose a more limited char=
ter or a different charter that focuses on these unmentioned aspects, we wo=
uld certainly evaluate it anew.


I'll take this task up and work on it.

Padma
=C2=A0
Alissa

<=
br>



--94eb2c0896a81f285a055b4aed93--


From nobody Wed Oct 11 13:08:16 2017
Return-Path: 
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 67E4D132F65; Wed, 11 Oct 2017 13:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=fZZIQx+t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S1l5iu6O
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 dFTlL6cKtXn3; Wed, 11 Oct 2017 13:08:09 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C299E1320CF; Wed, 11 Oct 2017 13:08:08 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0398021886; Wed, 11 Oct 2017 16:08:08 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 11 Oct 2017 16:08:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Sfc4T1J1/x2AYpEcv08PjNnoyYIG2 RioqMknRUaziWM=; b=fZZIQx+tmTcGjIBb0d74WeiuXCoAzUAuEB/UZrzzMaukW 4EyeIkVe45PtkhV5jkqw+DdxRrVfYvaLhr8bmes3ZY4SPZEu9Zb3huGh/JMbLQbd NYbV3ymcws1p70JYL+rTGgMVXRzrODkCI5eSb1hl+T8ioYlDhXH788+Zob1Yzk0t u0FgVcLsoZjRYY09srjXpxYBjJflQNtbIV5ewwrzx1xP6IQAowYfxhx3AqnUasO7 Ad2+Xmrh4PmzpOnjwc9Kof2ZEWLI8TW5OGFKYKMJFzBlEJjbNflg0uw24KJE/0cL OBS6dfXY1ug5IznYOr7hg95EevSzzHPegFaGnRH/g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Sfc4T1 J1/x2AYpEcv08PjNnoyYIG2RioqMknRUaziWM=; b=S1l5iu6OO6g/pByzICpeFc BAJ3qWyPGr2S7VTy5jrFXOsH5zCFvl9xTGXHRO8NFV4NBnJbOh1VDq4uWydd4nLL dN2v8laAyJCfkkUOkR8OOzs+3qXvo+BixwBD19VkymiQit8ii7qWySM+VN/w/CPz AYvC/UlbuhwjkMC6nf1dOFoljvQWgF8bBS2SH4/fTy9w5dTobFDvEwa62f/0FPjJ BDzq8nOe9yR1HUVXHKA2yb/ktQxO6d87Zs7abpgdV1h8rPoBfOzSkaa5icidLlB3 XB5PykZyLkyc/GlwWJb5X6a+ehf8FQed5Ebqdyrljvk47s5YrCqFKc/fhNeo51Jw ==
X-ME-Sender: 
Received: from sjc-alcoop-88112.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 8FB252479F; Wed, 11 Oct 2017 16:08:06 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>
Date: Wed, 11 Oct 2017 16:08:04 -0400
Cc: Robert Moskowitz , Eric Rescorla ,  ideas-chairs@ietf.org, ideas@ietf.org, IESG , aretana.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com> <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:08:10 -0000

> On Oct 11, 2017, at 3:59 PM, Dino Farinacci  =
wrote:
>=20
>> Dino and I are connected outside the IETF.  These groups come to us =
to talk, then go back and do their own thing to fill the void.  They =
will NOT come to the IETF, but will take what is offered.
>=20
> And of course, the typical mantra from them (and I know you all have =
heard this before):
>=20
> (1) The IETF is too slow.
>=20
> (2) The IETF cannot decide.
>=20
> (3) The IETF has too many options. So we are going to pick one and put =
our Intellectual Property on top of it (i.e. SD-WAN IPsec doesn=E2=80=99t =
interoperate).
>=20
> (4) We can do protocols better and faster than the IETF.
>=20
> (5) We want to build our own protocols so we look innovative.
>=20
> (6) We can get strategic interoperability with our business partners.

I don=E2=80=99t understand how chartering this WG with the proposed =
charter =E2=80=94 to write a framework document =E2=80=94 addresses any =
of these concerns. Furthermore, it isn=E2=80=99t the function of the =
chartering process to change people=E2=80=99s minds about what they find =
deficient about the IETF. The function of the chartering process is to =
scope out and define new pieces of work for which there is support in =
the IETF community.

=E2=80=9CThe IETF=E2=80=9D amounts to the people who come to the IETF to =
do the work and review the work. Work doesn=E2=80=99t get chartered =
unless the people who want it can at least minimally engage, explain why =
they want it in a way that is compelling to others, and explain how it =
fits within the scope of the rest of the IETF=E2=80=99s work and the =
internet architecture.

As I said in my note to Tom, this charter ballot isn=E2=80=99t a death =
sentence on all mapping system work forever more. It=E2=80=99s a =
judgment about the charter text and deliverables as they are right now.

Alissa

>=20
> Dino


From nobody Wed Oct 11 13:13:08 2017
Return-Path: 
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 8A171132D17; Wed, 11 Oct 2017 13:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 wv_M4FAUKPX6; Wed, 11 Oct 2017 13:13:06 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 D93C81320CF; Wed, 11 Oct 2017 13:13:05 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id i124so7977277wmf.3; Wed, 11 Oct 2017 13:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w7ENiy3rAe5VNJ70RS/gxaveTM0Do8kd9srjzZ6mbaA=; b=rFEr8yuxdpwQ+HxsbvguVy8Rsms4avtOV4NhbMmXhhnl0+ktCPjq6yFsQ+1KfCvKYp 8Cq0A9UrcY2UGPrfa8jCIcEMM0jDrkm38pM6QY8qKq1EGT5LPoEZPbC3MTl3tXyi8FSX C93sxIGTzaQSv/mvqxpVRSwk2JNrFl8jrYioOrNMmDNNOkx5Tw4XOP24Oix6qd8MTu+N Q2hT8P67kTrjuyqAsbe7hrVC6046h/WRmdMcfm1qWd9oY0r6bliV3ag1KAAzbEGC0MXt p3KhaUAuUCDm+G8Hvwh3oEOCMFT7T4u5qKIA00LML8iC9JtjW0PXrr6MZ3zOkOuOAjaw sWiw==
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=w7ENiy3rAe5VNJ70RS/gxaveTM0Do8kd9srjzZ6mbaA=; b=h4Pv1VclWqR6s4YHH7aSl85szrwpqnK2uI9qTmgEtRaXYiQcTjjQaWorDOODzm1V6S YwBBBxpDaILJRbovB3H9eJGlEGpKZqngRErhAcS2iy1VNYkdq562fwqEAqwGwZ+qEZNH JrzamhAP80VUI44W8oVcpsZyKEukOWAcxPEICdheQxl77moSBypksFbhwwE8lC0YmSY+ WnPjJY1HqAt0NDvvNI776V8T7BUptwAltJNPu96Q1ffemiqUPIFVeeqsY8vAu4rG8lUW BhHjIS83OmdlDTScOmBgxaURde/YpinEA7OsFv72ZCS6Io4+u+7KN4XvSgeCvTokUQjM THlw==
X-Gm-Message-State: AMCzsaXrC/dES3pqAQw9sKt3+SMoO3UoBEfo8bgLldYfupcPkpEAPY7D KQgPNZHbluaiL1L+MzV5TcHObEQ8Jr10v6v7+0M=
X-Google-Smtp-Source: AOwi7QAOcXOi7zhkZlwYd8mcmxWIsOlwNjNtcKy36xOuoHKbrfpPOayUsMA0IhYlfb/+JO50waxp4t9DhZWDnPzAvLA=
X-Received: by 10.28.141.1 with SMTP id p1mr77492wmd.68.1507752784487; Wed, 11 Oct 2017 13:13:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Wed, 11 Oct 2017 13:13:03 -0700 (PDT)
In-Reply-To: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com>  <6.2.5.6.2.20171008102541.11499408@elandnews.com>    <01dd6551-16f6-46e2-e861-94285c160f35@gmail.com> <28999ddc-840a-30c6-5b22-bc9b2e06a2a7@htt-consult.com>   <666d4b84-72e6-8d5a-cc67-8c698d07c5b9@huitema.net> 
From: Padma Pillay-Esnault 
Date: Wed, 11 Oct 2017 13:13:03 -0700
Message-ID: 
To: Christian Huitema 
Cc: Robert Moskowitz , Stephen Farrell ,  Brian E Carpenter , IETF Discussion Mailing List , ideas@ietf.org
Content-Type: multipart/alternative; boundary="001a11469d4020ea40055b4b0dce"
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:13:07 -0000

--001a11469d4020ea40055b4b0dce
Content-Type: text/plain; charset="UTF-8"

typo

On Wed, Oct 11, 2017 at 12:49 PM, Padma Pillay-Esnault  wrote:

>
>
> Let's not *throw the baby with the bathwater ...
>
>
>
> Padma
>
>>
>>

--001a11469d4020ea40055b4b0dce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



typo

On Wed, Oct 11, 2017 at 12:49 PM, =
Padma Pillay-Esnault <padma.ietf@gmail.com> wrote:


Let's not *throw the baby with the=
 bathwater ...



Padma



--001a11469d4020ea40055b4b0dce--


From nobody Wed Oct 11 13:13:20 2017
Return-Path: 
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 981451342DF; Wed, 11 Oct 2017 13:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 uP33ybxaUfcz; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 C0E691330C1; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id b85so1873087pfj.13; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=omD/jzmAGtRvmPhYaA4R3ozEGotE0Wc5ccebyDMcEbw=; b=ZzlBsMsqunyigHGNOa3Ju+Gzo6zo7rl6q9wyfMhY5n2RYCdq5cb5IHCCkpOLVkTr9T t9MzopETYgTyW6sK5Pwd/Pon90WVdjeQJbDgxQ3MCLLLNQf5Kt0CqFXsJZKIOouQ5tuq J4O4x28npTiY1dhiTEipbVtfDvNPqci/Sw1rtAVrrl/zSxaa3qgTI+u2ZvzqElpR35rt 9lDmKDglqZOXODTBIBsFCztlO8FI9+4v43BdmOZ3FPaNXPEOEYd6Rgtkqwp0z6Npedkd ITSyi1jOGz0yUwFogf6MWCtOzuZAzqcFkh6WytBkRQhrebmSiyy8xvue4yZi2alxYNCw yjUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=omD/jzmAGtRvmPhYaA4R3ozEGotE0Wc5ccebyDMcEbw=; b=WaNpqZZKaZSKZKfLn72gqLi4fgg0xfQ7bTe51yIVl5qKDtITbci6UoH4RMXA2t4hK9 pyFXf+qgZNifHzG4cazDzMcAmcBSxkyZ607P0e+cCJuCe2JXKoXLlP+/YHRn97s+0wfA IfuM22pgSyvloEAUSbXdv6765JjzXlSQzUgVPeGrh2OEVSHN02ooZyqBEOLrw//omtqw mr5afNffeBXdKBFZz74FsMbn+DxcKUZiSTmhI2+cfi597X/xjpJ1GZZH+2F6nqkBD2pu Ph+ksIhrnJW7hnr6CsEg43oH+yPCx/ZBJsQeOfWOpF0UAC/n+kYalFHiR4zLstydNcGC vgFg==
X-Gm-Message-State: AMCzsaWlJ5R8Ifxevn/WYi7iwEl4fCIjMoBgl/rBGprMcEejqDpkgFli vfvg/DTzFCKZoGGNGIocuMUnmRM7
X-Google-Smtp-Source: AOwi7QAEeAVcn6/I5jmYsNr5MiAAPDZMp64Fg2RjjbplYEe6XkvVNdUTfHkQCsngebtLjggqzkndSA==
X-Received: by 10.99.116.25 with SMTP id p25mr158145pgc.26.1507752789320; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id a25sm25523054pfc.143.2017.10.11.13.13.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 13:13:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 13:13:07 -0700
Cc: Christian Huitema , "ietf@ietf.org" ,  "ideas@ietf.org" , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>     <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>   
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:13:12 -0000

> When the payload is encrypted, it does not.
>=20
> Are the handshakes that establish the cryptographic keys used to =
encrypt the payload themselves encrypted? If it's IKE, the answer is =
probably yes, but if not, I don't know.

For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the =
Map-Request/Map-Reply exchange carry the EIDs in the clear. However, =
DTLS could be used but it would take more RTTs to get mappings in the =
encapsulator (causing more packet loss).

> So let me ask you these follow-up questions:
>=20
> (1) If a host sources a packet with its identifier in one VM and an =
encapsulator in another VM (in the same physical system) encapsulates =
the packet but encrypts the payload before encapsulation, has the =
identifier remain private?
>=20
> (2) If in (1), the packet is decapsulated by an intermmediate point, =
and then reencapsulated but the packet is encrypted with a new session =
key (from a new ECDH exchange) to the destination, has the identifier =
remained private?
>=20
> Generally, I don't tend to think of things as being "private" or =
"non-private". Rather we talk about who has a given capability or piece =
of information. I think it's clear that in these cases the identifier =
was available to the machine doing the deencapsulation/reencapsulation. =
Obviously, that's worse for privacy than having it not have that =
information. How much worse depends on a lot of factors.

It needs the information for table lookups. So how private/trackable are =
IP addresses in packets today?

> In this particular, work, however, it seems like the privacy concerns =
are about:
>=20
> 1. Whether the ID mapping systems reveal who is talking to who.

The charter talks about no designs or solutions. In LISP, the mappings =
are not revealed to the world, you need to sign Map-Registers (to make =
your network location available to others) and you need to sign =
Map-Requests (for retrieving network location).

And if you cannot get network location, you can't send packets (i.e. =
DoS) the destination or any nodes close to the destination (much better =
than what we have on the Internet today where anyone can send packets =
anywhere).

> 2. Whether this creates persistent identifiers that would otherwise be =
destroyed when people changed their location

We can solve this quite easily. I=E2=80=99ll use Bitcoin wallet =
addresses as an example. You can keep changing them for every =
transaction so there is no association analysis. We have a working group =
draft in the LISP WG that does just that.

> Maybe Christian and Stephen would like to say more about their =
concerns
> -Ekr=20

Would welcome.

Dino


From nobody Wed Oct 11 13:17:02 2017
Return-Path: 
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 EC62813307B for ; Wed, 11 Oct 2017 13:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 oq6wx0DlFG4f for ; Wed, 11 Oct 2017 13:16:56 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 01294132EDA for ; Wed, 11 Oct 2017 13:16:56 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id z28so6505162qtz.13 for ; Wed, 11 Oct 2017 13:16:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lMVdzJvvwslKsPtjHj94/rVZeR95JUz/EuuBmkdy9ZE=; b=Ol7V6K1B9Y994WEBXFxakHGdk8kvSDknP/T36R+Rb9J2ZmD5TKaAz00JTsHwcHx+uL +tHssXIKmgmk8tL6+kUhBznUW5jfXlrNQ+ZTM9P4DQIysPGouI7et8PZ+7f8bKRCPtzp bOrluAksyZ1VhtUK9BpaBef9fiCZclQPdeIZkR4zwTiHmn9UCRvRK+ils4XL5iEvjWgB unlxjWjCE3hXjTCQaHvV7X4ceJoj7mwn1TmWCAWwOdxNus+qdGJ8NUk820l+xpGwZUac dKFdST7zAguovj+EJSR1qrIJT+LUUeheB76y+PQ0FkiZyawGOBlggu4ntboJ8RMGH0Yu E1/A==
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=lMVdzJvvwslKsPtjHj94/rVZeR95JUz/EuuBmkdy9ZE=; b=Jd4lQyj2JrBPBxf2QB2JhVMxdMNqzkDol4J1ShLqqAk0ZfUnFXUE0lJP7BCGhwq6JY /b+8mQq3GxBW+O1ZBeXPaz8XUpJPVPe2reNALCxLVs3yu9CZFE63kOjVRCObQwsnmBf0 Zo01+PG/vbUcQWPhMunRmfys3xVwJbHMs0nic1Nzsb9mvoJgtytxfjU8+pDOvpNewnkK dsMAZ8J2niGB99Va3i6gqJvLFhBa4frsbTngdzQUz036e+pMoaJs4jR5hmFfXmnJqC2b pSRqxZWO6ZgEwuyeOJdfPKybmiLh1ZP5fgqIaNacP//jeqoaPLBOZSc/OAKcZ+eepFXn nXAA==
X-Gm-Message-State: AMCzsaWDrcvxigIDxzucyxEccSFvNCD+RRlgi4Va5HyQaeN+1OiPVYz3 PG4/YrNzGqa24J067AsDJNj5HpgAMztulur8ZXYEDA==
X-Google-Smtp-Source: AOwi7QBtyctBc6qRELys5UtjZ73Ph9pGTzJrBHQbYEoHne4EStIR79phCbOSl/Lxdot8fuFINSHthJJCH3/nhYjtGFk=
X-Received: by 10.37.83.66 with SMTP id h63mr452358ybb.397.1507753015112; Wed, 11 Oct 2017 13:16:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 11 Oct 2017 13:16:14 -0700 (PDT)
In-Reply-To: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>     <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>    
From: Eric Rescorla 
Date: Wed, 11 Oct 2017 13:16:14 -0700
Message-ID: 
To: Dino Farinacci 
Cc: Christian Huitema , "ietf@ietf.org" ,  "ideas@ietf.org" , "lisp@ietf.org list" 
Content-Type: multipart/alternative; boundary="001a113e688ee00e6d055b4b1aae"
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:16:58 -0000

--001a113e688ee00e6d055b4b1aae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 11, 2017 at 1:13 PM, Dino Farinacci  wrote=
:

> > When the payload is encrypted, it does not.
> >
> > Are the handshakes that establish the cryptographic keys used to encryp=
t
> the payload themselves encrypted? If it's IKE, the answer is probably yes=
,
> but if not, I don't know.
>
> For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the
> Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTLS
> could be used but it would take more RTTs to get mappings in the
> encapsulator (causing more packet loss).
>
> > So let me ask you these follow-up questions:
> >
> > (1) If a host sources a packet with its identifier in one VM and an
> encapsulator in another VM (in the same physical system) encapsulates the
> packet but encrypts the payload before encapsulation, has the identifier
> remain private?
> >
> > (2) If in (1), the packet is decapsulated by an intermmediate point, an=
d
> then reencapsulated but the packet is encrypted with a new session key
> (from a new ECDH exchange) to the destination, has the identifier remaine=
d
> private?
> >
> > Generally, I don't tend to think of things as being "private" or
> "non-private". Rather we talk about who has a given capability or piece o=
f
> information. I think it's clear that in these cases the identifier was
> available to the machine doing the deencapsulation/reencapsulation.
> Obviously, that's worse for privacy than having it not have that
> information. How much worse depends on a lot of factors.
>
> It needs the information for table lookups. So how private/trackable are
> IP addresses in packets today?
>

Uh really terrible? That's why things like Tor exist.

I'm not sure it's useful to continue with the technical side of the present
discussion. We're not trying to design a system here. The requirements for
the system the WG is to design is is properly the kind of question that
needs to be hashed out for the charter for the WG.

-Ekr



>
> > In this particular, work, however, it seems like the privacy concerns
> are about:
> >
> > 1. Whether the ID mapping systems reveal who is talking to who.
>
> The charter talks about no designs or solutions. In LISP, the mappings ar=
e
> not revealed to the world, you need to sign Map-Registers (to make your
> network location available to others) and you need to sign Map-Requests
> (for retrieving network location).
>
> And if you cannot get network location, you can't send packets (i.e. DoS)
> the destination or any nodes close to the destination (much better than
> what we have on the Internet today where anyone can send packets anywhere=
).
>
> > 2. Whether this creates persistent identifiers that would otherwise be
> destroyed when people changed their location
>
> We can solve this quite easily. I=E2=80=99ll use Bitcoin wallet addresses=
 as an
> example. You can keep changing them for every transaction so there is no
> association analysis. We have a working group draft in the LISP WG that
> does just that.
>
> > Maybe Christian and Stephen would like to say more about their concerns
> > -Ekr
>
> Would welcome.
>
> Dino
>
>

--001a113e688ee00e6d055b4b1aae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 11, 2017 at 1:13 PM, Dino Farinacci <<=
a href=3D"mailto:farinacci@gmail.com" target=3D"_blank">farinacci@gmail.com=
> wrote:
> When th=
e payload is encrypted, it does not.

>

> Are the handshakes that establish the cryptographic keys used to encry=
pt the payload themselves encrypted? If it's IKE, the answer is probabl=
y yes, but if not, I don't know.



For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) t=
he Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTL=
S could be used but it would take more RTTs to get mappings in the encapsul=
ator (causing more packet loss).



> So let me ask you these follow-up questions:

>

> (1) If a host sources a packet with its identifier in one VM and an en=
capsulator in another VM (in the same physical system) encapsulates the pac=
ket but encrypts the payload before encapsulation, has the identifier remai=
n private?

>

> (2) If in (1), the packet is decapsulated by an intermmediate point, a=
nd then reencapsulated but the packet is encrypted with a new session key (=
from a new ECDH exchange) to the destination, has the identifier remained p=
rivate?

>

> Generally, I don't tend to think of things as being "private&=
quot; or "non-private". Rather we talk about who has a given capa=
bility or piece of information. I think it's clear that in these cases =
the identifier was available to the machine doing the deencapsulation/reenc=
apsulation. Obviously, that's worse for privacy than having it not=
 have that information. How much worse depends on a lot of factors.



It needs the information for table lookups. So how private/trackable=
 are IP addresses in packets today?

Uh =
really terrible? That's why things like Tor exist.

=

I'm not sure it's useful to continue with the technical side o=
f the present discussion. We're not trying to design a system here. The=
 requirements for the system the WG is to design is is properly the kind of=
 question that needs to be hashed out for the charter for the WG.

-Ekr

=C2=A0



> In this particular, work, however, it seems like the privacy concerns =
are about:

>

> 1. Whether the ID mapping systems reveal who is talking to who.



The charter talks about no designs or solutions. In LISP, the mappin=
gs are not revealed to the world, you need to sign Map-Registers (to make y=
our network location available to others) and you need to sign Map-Requests=
 (for retrieving network location).



And if you cannot get network location, you can't send packets (i.e. Do=
S) the destination or any nodes close to the destination (much better than =
what we have on the Internet today where anyone can send packets anywhere).=




> 2. Whether this creates persistent identifiers that would otherwise be=
 destroyed when people changed their location



We can solve this quite easily. I=E2=80=99ll use Bitcoin wallet addr=
esses as an example. You can keep changing them for every transaction so th=
ere is no association analysis. We have a working group draft in the LISP W=
G that does just that.



> Maybe Christian and Stephen would like to say more about their concern=
s

> -Ekr



Would welcome.



Dino







--001a113e688ee00e6d055b4b1aae--


From nobody Wed Oct 11 13:23:43 2017
Return-Path: 
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 F17D8134249 for ; Wed, 11 Oct 2017 13:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 NtPwj88ToXTe for ; Wed, 11 Oct 2017 13:23:40 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 D91B6132D17 for ; Wed, 11 Oct 2017 13:23:39 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id n61so9009493qte.10 for ; Wed, 11 Oct 2017 13:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=8eS/ipoPvY+V7LmBArDrCiiOcnwvBmrkSyyGouut1G8=; b=fc9pE9/ebiSTAezYHOAlduLe7S5l6fl4uUk+LvP+2gCsh0DYnCfjIhbKMSZIpt1Qwb KCM+6uh3M+KyJpnhQmcR6urVFxNtysXhCDOb9DGDob/xxrOmsJcxuzdfz5HZqGCfNysQ FH7DoS30pVKqd6t2zbPpuDa1/fgW59bSRiu0OiEEUA8C/U+9utOpaqDOXHc5qVMm3URV SlAY+HZPmMq+R/4RKbb2qGJVm+76PFhaXyhTe9mXghQzdM2//fFihqY54RiCB5j75JmX U8qPDPmRczeotP9Hyfw41V8BrjgKe7CA4Apy4Q6U04szApEF/MuRurUa7UDLzNehqwN8 MCrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8eS/ipoPvY+V7LmBArDrCiiOcnwvBmrkSyyGouut1G8=; b=gU+GCvWGM053wKaY/CINP7he1B6bbAiLtAr3gAf2heB6c+wBrTemyZqM2IUu87At1I Yqck7ABz8k6Gz/Szd1XhYjOpdDEjDGOL/FhAagoVXS9AdFPuVGLpFTVMoNueHN5i5bmu Xhvja89+AUxxpF82HSoMUe5aSN5kfBHmJAkE6zH2AV01TwfuV5Bb9FC/yFnYRPYbV/sN nDK0WO1BF1BrV6dB5Mk4hMDGbkHE0nw7eTlhcuaefvTBlR/X7YyrEB0coCNmHvJjHXMz QvCFO6EDhdR2Ni6kD55Kf1V75T5/i2mpYd6jD/IZ0+7KXZwmPK1WXd1LxNXJgHicARmv sjSQ==
X-Gm-Message-State: AMCzsaUkS1iiVhyBa+ag05n+mBZM6UyoGsAJ45VxlwC94NRD6cRwXTY5 mTBlgN3Zo8zzt6Z2l9NGgoflM267
X-Google-Smtp-Source: AOwi7QDCMvqgblcsOkg4Jsa4Ikh0sSjLVzsWI3mBbsmcfrVPolC0QUKqO4CJ/OsCru5QieZEGUJZ/Q==
X-Received: by 10.55.33.71 with SMTP id h68mr333750qkh.109.1507753418478; Wed, 11 Oct 2017 13:23:38 -0700 (PDT)
Received: from host-4-159.cnri.reston.va.us (cnri-7-77.cnri.reston.va.us. [132.151.7.77]) by smtp.gmail.com with ESMTPSA id m5sm8249396qkd.97.2017.10.11.13.23.37 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 13:23:37 -0700 (PDT)
To: ideas@ietf.org
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
From: Sam Sun 
Message-ID: 
Date: Wed, 11 Oct 2017 16:23:36 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------9A34967E7B3FAC918D2C2EF6"
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:23:42 -0000

This is a multi-part message in MIME format.
--------------9A34967E7B3FAC918D2C2EF6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

My recall from the last BoF meeting is that we got quite a large number 
of hums on the issues reflected in the current charter. I believe there 
are sufficient motivations here.

The disputes on privacy protection and discoverability in the mailing 
list only shows the interests from the community looking for a better 
solution. Having disputes about different approaches, or even question 
whether or not there’s any feasible solution, is exactly why we need to 
form a WG to work on this, IMHO.

Sam


On 10/11/17 10:53 AM, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> charter-ietf-ideas-00-06: Block
>
> 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.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-ideas/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> I do not think this group is ready to be chartered at this time given the
> significant objections from the community.
>
> There seem to be two key problems with the work as proposed:
>
> (1) The work is insufficiently motivated. The claims about the need for the
> mapping system and the identity management system envisioned here do not appear
> to be backed up by those who have developed and deployed ID/LOC separation
> protocols. Nor do there seem to be compelling arguments that the framework that
> this proposed WG would produce would be the motivator for further interoperable
> deployments.
>
> (2) The work proposed here seems as if it would have a substantial intrinsic
> impact on user privacy if widely deployed. In cases like these, I don't believe
> it's sufficient to say that the WG will analyze the situation and propose
> mitigations; the work proposal itself needs to explain how the design of the
> infrastructure envisioned is going to mitigate what seem like obvious attacks
> on privacy that the proposed designs open up.
>
> I think further discussions of this work (in private, on the list, at a bar in
> Singapore, or at a potential future BoF) would need to resolve both of the
> above issues in order to address concerns raised by the community.
>
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


--------------9A34967E7B3FAC918D2C2EF6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
      My recall from the last BoF
        meeting is that we
        got quite a large number of hums on the issues reflected in the
        current charter.
        I believe there are sufficient motivations here. 

        

        The disputes on privacy protection and discoverability in the
        mailing list only
        shows the interests from the community looking for a better
        solution. Having disputes
        about different approaches, or even question whether or not
        there’s any feasible
        solution, is exactly why we need to form a WG to work on this,
        IMHO.

        

        Sam

      
    

    

    
On 10/11/17 10:53 AM, Alissa Cooper
      wrote:

    

    

      
Alissa Cooper has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I do not think this group is ready to be chartered at this time given the
significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the
mapping system and the identity management system envisioned here do not appear
to be backed up by those who have developed and deployed ID/LOC separation
protocols. Nor do there seem to be compelling arguments that the framework that
this proposed WG would produce would be the motivator for further interoperable
deployments.

(2) The work proposed here seems as if it would have a substantial intrinsic
impact on user privacy if widely deployed. In cases like these, I don't believe
it's sufficient to say that the WG will analyze the situation and propose
mitigations; the work proposal itself needs to explain how the design of the
infrastructure envisioned is going to mitigate what seem like obvious attacks
on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in
Singapore, or at a potential future BoF) would need to resolve both of the
above issues in order to address concerns raised by the community.




_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


    

    

  


--------------9A34967E7B3FAC918D2C2EF6--


From nobody Wed Oct 11 13:38:29 2017
Return-Path: 
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 030D31330C1; Wed, 11 Oct 2017 13:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 gBVCNG3q8k-i; Wed, 11 Oct 2017 13:38:26 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 B6A93126B6D; Wed, 11 Oct 2017 13:38:25 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id x54so9116394qth.12; Wed, 11 Oct 2017 13:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=vouyB1CsKY9zAUBEIrKCH8tBmyOxeRf3BqC4wyiPJBI=; b=nh/AnaVXWQ/DYw6Q7r7IF+dnvqbrlhn2x+hxPv5EwypfbDi2zL4XOXoMmVdgpMjW1f cEty9Hx41fjKi+tOD5B8KajH8CLMnA6MZH7ue3hEkiaxGqAzseuI9HW8+gcF17HfXz5Y Sj5AoKzNpbBvDNaB+BesUbbcg82J/Igcvcy5IhxHoP1yG3MLvmhqaAIYOjWgM7Omh95E 15OHczOaqshmzwFBrwwKanS1fOELc1hlhszMtoOgyy8kkDNa095/zY717MsQ+HuI5Cwy pvmb1HSa2dT/iuPXfyYMS3P9k2GwP39oMbAiTn7ly5xKL9ViooJfFyY+BopXymvCk+DR oR2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vouyB1CsKY9zAUBEIrKCH8tBmyOxeRf3BqC4wyiPJBI=; b=XnEtNYbZyefj5ApDejoq/suw75zE0LaPmvTI/HPsgZ8rBplmxzjhoam3s23IsX5TBK UH18TyaCIzCy8CndM8XlFsSxgUU8mc21eNtG1yOBpNLeDbMqAgj/wTIxNzecmOj/DLPx 0eUdb97I4CSL3DEp8UPEi5AfiI3412lbRrbSJxS+hR1EMsmtTcJ2X+XnF1avIC+y+KCI GoIORG66d8IGqx1RXtruB5lW3wKSbFhuE0OVpCLHPlm3LKMzQdVtffVyr6WCQ+QjSF19 OsRrKiu04pnGvQiBtH0ZKqoGYWUiMF+ZyqX4vhqTeiYPpeZsdGptLFP4lTKHfHeGDxqo YKSw==
X-Gm-Message-State: AMCzsaXhTEXcWaerXwOMdx/mqh/EpbeQ9Ci0IR6FBuODAfOYuiORccIb kx8KAQMZcMUVuspP3U0p8TyPPEVA
X-Google-Smtp-Source: AOwi7QCgqpylPUYHPUlyGB/O+CtNAKzwfFbCX7AFLr0z8KBPnIVkJPt+m+CrP976KR2SC/OHCns1QQ==
X-Received: by 10.237.38.36 with SMTP id z33mr440169qtc.258.1507754304830; Wed, 11 Oct 2017 13:38:24 -0700 (PDT)
Received: from host-4-159.cnri.reston.va.us (cnri-7-77.cnri.reston.va.us. [132.151.7.77]) by smtp.gmail.com with ESMTPSA id t9sm8683618qti.47.2017.10.11.13.38.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 13:38:23 -0700 (PDT)
To: Alissa Cooper , The IESG 
Cc: ideas@ietf.org, ideas-chairs@ietf.org, aretana.ietf@gmail.com
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
From: Sam Sun 
Message-ID: 
Date: Wed, 11 Oct 2017 16:38:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------24FF8BF7922C1D750145812B"
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:38:28 -0000

This is a multi-part message in MIME format.
--------------24FF8BF7922C1D750145812B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

My recall from the last BoF meeting is that we got quite a large number 
of hums on the issues reflected in the current charter. I believe there 
are sufficient motivations here.

The disputes on privacy protection and discoverability in the mailing 
list only shows the interests from the community looking for a better 
solution. Having disputes about different approaches, or even question 
whether or not there’s any feasible solution, is exactly why we need to 
form a WG to work on this, IMHO.

Sam


On 10/11/17 10:53 AM, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> charter-ietf-ideas-00-06: Block
>
> 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.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-ideas/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> I do not think this group is ready to be chartered at this time given the
> significant objections from the community.
>
> There seem to be two key problems with the work as proposed:
>
> (1) The work is insufficiently motivated. The claims about the need for the
> mapping system and the identity management system envisioned here do not appear
> to be backed up by those who have developed and deployed ID/LOC separation
> protocols. Nor do there seem to be compelling arguments that the framework that
> this proposed WG would produce would be the motivator for further interoperable
> deployments.
>
> (2) The work proposed here seems as if it would have a substantial intrinsic
> impact on user privacy if widely deployed. In cases like these, I don't believe
> it's sufficient to say that the WG will analyze the situation and propose
> mitigations; the work proposal itself needs to explain how the design of the
> infrastructure envisioned is going to mitigate what seem like obvious attacks
> on privacy that the proposed designs open up.
>
> I think further discussions of this work (in private, on the list, at a bar in
> Singapore, or at a potential future BoF) would need to resolve both of the
> above issues in order to address concerns raised by the community.
>
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


--------------24FF8BF7922C1D750145812B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
My recall from the last BoF
        meeting is that we got quite a large number of hums on the
        issues reflected in the current charter. I believe there are
        sufficient motivations here. 

        

        The disputes on privacy protection and discoverability in the
        mailing list only shows the interests from the community looking
        for a better solution. Having disputes about different
        approaches, or even question whether or not there’s any feasible
        solution, is exactly why we need to form a WG to work on this,
        IMHO.

        

        Sam

    

    
On 10/11/17 10:53 AM, Alissa Cooper
      wrote:

    

    

      
Alissa Cooper has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I do not think this group is ready to be chartered at this time given the
significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the
mapping system and the identity management system envisioned here do not appear
to be backed up by those who have developed and deployed ID/LOC separation
protocols. Nor do there seem to be compelling arguments that the framework that
this proposed WG would produce would be the motivator for further interoperable
deployments.

(2) The work proposed here seems as if it would have a substantial intrinsic
impact on user privacy if widely deployed. In cases like these, I don't believe
it's sufficient to say that the WG will analyze the situation and propose
mitigations; the work proposal itself needs to explain how the design of the
infrastructure envisioned is going to mitigate what seem like obvious attacks
on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in
Singapore, or at a potential future BoF) would need to resolve both of the
above issues in order to address concerns raised by the community.




_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


    

    

  


--------------24FF8BF7922C1D750145812B--


From nobody Wed Oct 11 13:41:38 2017
Return-Path: 
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 622581243F6; Wed, 11 Oct 2017 13:41:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150775449235.24828.2446474491472474284.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 13:41:32 -0700
Archived-At: 
Subject: [Ideas] Spencer Dawkins' Abstain on charter-ietf-ideas-00-06: (with COMMENT)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:41:32 -0000

Spencer Dawkins has entered the following ballot position for
charter-ietf-ideas-00-06: Abstain

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm seeing offers of text changes from proponents. I'd Defer this one, but that
only allows two weeks for the conversation to stabilized. So, Abstain.

FWIW, I balloted Yes to send the charter to the community for comments, and was
hoping to ballot Yes for approval, but since I don't know what text I'm
balloting on, that's the best I can offer.

I look forward to continued progress (because the discussion is certainly
continuing).



From nobody Wed Oct 11 13:50:36 2017
Return-Path: 
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 94AD0132D17; Wed, 11 Oct 2017 13:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 o35aUECmX9hN; Wed, 11 Oct 2017 13:50:25 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 ED9BA126B6D; Wed, 11 Oct 2017 13:50:24 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id a43so9299895qta.0; Wed, 11 Oct 2017 13:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0v3LrLj4qwxfgbExL4EK1rgIV7nlwYP6jIIphvkOzeU=; b=oUFwFs6ETJiWi//Qpt1ttG+sSXwZPpTSyO2dkjE4dA1wW4pw0kXEH701Aw18iQ2LEQ SUiD0rGIMEevOvEA2J8GuOkJqi6gEIHL2H9z0LHms6hqx2BzS7bgvBbBjKRsQraPxkT4 SUWoGUfUT311++6UNHO3Rv7VB7kLh0JsteDLa5uVHXG2cGO2tqSHd0PBSyZl9Eu5A/ZO rCAPLKAS1MV2MOjbFGwDfg1oW2DyWr4a7oKJDEewT4DT3P1/kc/VkBJ6tsVRHwInCcf5 QL+p18BR5TmVwE2fir8xh2sADPu+trP18TXQIKAshqzR/yPY0vQhgzjglXzrU65NwF2h aNKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0v3LrLj4qwxfgbExL4EK1rgIV7nlwYP6jIIphvkOzeU=; b=c1XGfREaflFKNcU5f9waxj23xoeMIWYVbI1LGI2YjdIk8c85GiMTtWHaUW42lHjTks r89wH1nWqa7Mwchi+YcfgCbNutQLJvlM7de0Rol/iu170MmokS4ME5+jePVRYGhWiefz 7kRiLo7HdGkaShIbd70osRKZP0p2rkq9WpG8WuxfMaNh/KyJtgM9Qpbs1BdfJiYn/+4f RT23c1dTQXM6941cZOYYnn7sXGZNMWw/TNQNg1hM6mxiOlPzuNGg8lcnwqX6aaZr+rmb LM5ZMtd1hkMGqvpUaNTvDxBUv4rf13HNCGocdb5A4IvAoxQLppMT1OWgNVKvjsR1mKKE GNrw==
X-Gm-Message-State: AMCzsaXLEYq6GMFGQpcza5MoCiSmooGyqy3SFZJPcmotmldX6C8ILU8f jaF68/Ap65jSt1SOR+sZbuIJwQKzQqQ=
X-Google-Smtp-Source: AOwi7QDhZn5V0OoX9l6wLZ2tIhQgY25OzDuBrEjKSco+OUCkeBOyz8C/U2vcmL/wtkqp+H3Ic3awGA==
X-Received: by 10.237.38.36 with SMTP id z33mr485762qtc.258.1507755023621; Wed, 11 Oct 2017 13:50:23 -0700 (PDT)
Received: from host-4-159.cnri.reston.va.us (cnri-7-77.cnri.reston.va.us. [132.151.7.77]) by smtp.gmail.com with ESMTPSA id i92sm8545239qtb.65.2017.10.11.13.50.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 13:50:22 -0700 (PDT)
To: Padma Pillay-Esnault , Christian Huitema 
Cc: "ideas@ietf.org" , "lisp@ietf.org list" , Dino Farinacci , Robert Moskowitz , Brian E Carpenter , "ietf@ietf.org" 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>   
From: Sam Sun 
Message-ID: <5c28dab9-cb0a-e693-f75b-528dc212ea98@gmail.com>
Date: Wed, 11 Oct 2017 16:50:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------45BDC75F3D1A7FC31FD7423D"
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] [lisp] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:50:27 -0000

This is a multi-part message in MIME format.
--------------45BDC75F3D1A7FC31FD7423D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I second Padma on this!

I suggest we all work more constructively in refining our charter here, 
and be more focused on the tasks listed in the charter. It's probably 
too early to fight on the exact meaning of any particular word (e.g. 
'identity'). Features like privacy protection and discoverability can 
also be left for discussion when we work on the details of the 
framework, instead of being used to kill the whole proposal.

By the way, statements like "someone else failed before" should never be 
a reason to stop working on something of such importance.

Sam


On 10/11/17 1:32 PM, Padma Pillay-Esnault wrote:
>
>
> On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema 
> > wrote:
>
>     On 10/11/2017 7:56 AM, Robert Moskowitz wrote:
>
>>>     and 'identity' is a red flag.
>>
>>     Whow there!  You were part of the Namespace Research Group?  I
>>     think?  I was and we we worked a lot on this and came to the
>>     conclusion that there could be no conclusion.  Not even a rough
>>     concensus, it seemed.
>>
>>     I have been using 'identity' to apply to things for 20 years.
>>     Pretty much ever since I started working with things.  Anyone
>>     that holds the position that 'identity' means we are talking only
>>     about people are allowing their thinking to be clouded. 
>
>     I am concerned that the current proponents of the IDEAS work are
>     mainly resisting the feedback, treating it as some roadblock put
>     in the path of their work by misguided privacy purists, and
>     attempting to remove the roadblocks by adding some weasel words to
>     the charter. I would feel much more confident if these proponents
>     acknowledged the tension between privacy and stable identifiers of
>     any sort, if that tension was clearly noted in the charter, and if
>     privacy goals were clearly stated.
>
>
> As one of the proponents, I feel I need to speak up because blanket 
> statements are just not helping.
>
> Speaking on behalf of my fellow proponents, we have always welcomed 
> constructive feedback from people who want/can contribute and make the 
> technology better. We have been willing to clarify the charter 
> (clarification does not mean weaseling).
>
> If it is helpful to  move forward, I am willing to volunteer for this 
> work and discuss with anyone to ensure constructive feedback and 
> comments are addressed.
>
>
>     Specifically, I think there is a contradiction between some of
>     documents. For example, draft-padma-ideas-problem-statement-01
>     states that:
>
>         o  A single entity may have multiple IDs, and IDs of the same entity
>            may have different life spans that are different from the lifespan
>            of the entity.  Furthermore, it is understood that IDs may have
>            different lifecycles, which may be permanent or ephemeral by
>            choice or design.
>
>         o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
>            for a permanent ID to protect the privacy of the related entity.
>
>     But then, draft-ccm-ideas-identity-use-cases-01 states that:
>
>         a.  Unique and Permanent Identity representing the entity enables
>             authentication (AUTH) with the mapping and Identity services
>             infrastructure.  While it is possible to do AUTH on Identifiers
>             those are not permanently associated to the entity.  Moreover,
>             AUTH operation is a relatively an expensive and inefficient
>             procedure (compared to LOC resolution for example) and can cause
>             excessive startup delays for lot of applications.
>
>
> As said earlier this draft was not updated by the authors and a new 
> version was posted yesterday.
>
> https://www.ietf.org/mail-archive/web/ideas/current/msg00520.html
>
>     The tension is obvious. On one hand, the ephemeral identifiers
>     envisaged in the problem statement would pretty much align the
>     privacy properties of the ID to those of IPv6 privacy addresses,
>     and that's good. On the other hand, the requirement to perform
>     authentication on identities completely negates that property.
>
>     I would be fine if the support for "Unique and Permanent Identity"
>     was explicitly excluded from the charter.
>
>
> AFAIK, none of the proponents resisted that.
>
>     There is obviously a need to support some form of access control
>     to a mapping database,
>
>
> Agreed.
>
>     but you do not need a reference to a permanent identity for that
>     -- systems similar to CGA would work just fine.
>
>
>
> The identity of the device is just adding a lever of identifier which 
> effectively allows authentication to modify the identifiers used by 
> that device but also what the users of these identifiers can look up. 
> If we had used "user of identifier" it would have been misconstrued 
> for humans. So damn if you do and damn if you don't ...
>
> We are open for discussions anytime.
>
> Padma
>
>
>
>
>     -- 
>     Christian Huitema
>
>
>     _______________________________________________
>     lisp mailing list
>     lisp@ietf.org 
>     https://www.ietf.org/mailman/listinfo/lisp
>     
>
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


--------------45BDC75F3D1A7FC31FD7423D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I second Padma on this!

      

      I suggest we all work more constructively in refining our charter
      here, and be more focused on the tasks listed in the charter. It's
      probably too early to fight on the exact meaning of any particular
      word (e.g. 'identity'). Features like privacy protection and
      discoverability can also be left for discussion when we work on
      the details of the framework, instead of being used to kill the
      whole proposal. 

      

      By the way, statements like "someone else failed before" should
      never be a reason to stop working on something of such importance.

    

    Sam

    

    

    
On 10/11/17 1:32 PM, Padma
      Pillay-Esnault wrote:

    

    

      


        


          
On Wed, Oct 11, 2017 at 9:15 AM,
            Christian Huitema <huitema@huitema.net>
            wrote:

            

              

                  
On 10/11/2017 7:56 AM, Robert Moskowitz wrote:

                  

                  

                    
and
                      'identity' is a red flag. 

                    

                    

                    Whow there!  You were part of the Namespace Research
                    Group?  I think?  I was and we we worked a lot on
                    this and came to the conclusion that there could be
                    no conclusion.  Not even a rough concensus, it
                    seemed. 

                    

                    I have been using 'identity' to apply to things for
                    20 years. Pretty much ever since I started working
                    with things.  Anyone that holds the position that
                    'identity' means we are talking only about people
                    are allowing their thinking to be clouded. 

                  

                 I am concerned that the current proponents of
                the IDEAS work are mainly resisting the feedback,
                treating it as some roadblock put in the path of their
                work by misguided privacy purists, and attempting to
                remove the roadblocks by adding some weasel words to the
                charter. I would feel much more confident if these
                proponents acknowledged the tension between privacy and
                stable identifiers of any sort, if that tension was
                clearly noted in the charter, and if privacy goals were
                clearly stated. 

                

              

            

            


            

            
As one of the proponents, I feel I need to speak up
              because blanket statements are just not helping. 

            


            

            
Speaking on behalf of my fellow proponents, we have
              always welcomed constructive feedback from people who
              want/can contribute and make the technology better. We
              have been willing to clarify the charter (clarification
              does not mean weaseling). 

            


            

            
If it is helpful to  move forward, I am willing to
              volunteer for this work and discuss with anyone to ensure
              constructive feedback and comments are addressed.

            


            

            


            

            

              
 Specifically, I think there is a
                contradiction between some of documents. For example,
                draft-padma-ideas-problem-statement-01 states that:

                
   o  A single entity may have multiple IDs, and IDs of the same entity
      may have different life spans that are different from the lifespan
      of the entity.  Furthermore, it is understood that IDs may have
      different lifecycles, which may be permanent or ephemeral by
      choice or design.

   o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
      for a permanent ID to protect the privacy of the related entity.

                But then, draft-ccm-ideas-identity-use-cases-01
                states that:

                
   a.  Unique and Permanent Identity representing the entity enables
       authentication (AUTH) with the mapping and Identity services
       infrastructure.  While it is possible to do AUTH on Identifiers
       those are not permanently associated to the entity.  Moreover,
       AUTH operation is a relatively an expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for lot of applications.



              

            

            


            

            
As said earlier this draft was not updated by the
              authors and a new version was posted yesterday.

            


            

            
            


            

            
 

            

              
The tension is obvious. On one
                hand, the ephemeral identifiers envisaged in the problem
                statement would pretty much align the privacy properties
                of the ID to those of IPv6 privacy addresses, and that's
                good. On the other hand, the requirement to perform
                authentication on identities completely negates that
                property.

                

                I would be fine if the support for "Unique and Permanent
                Identity" was explicitly excluded from the charter. 

            

            


            

            
AFAIK, none of the proponents resisted that.

            
 

            

              
There is obviously a need to
                support some form of access control to a mapping
                database, 

            

            


            

            
Agreed.

            
 

            

              
but you do not need a reference to
                a permanent identity for that -- systems similar to CGA
                would work just fine.

            

            
 

            

            


            

            
The identity of the device is just adding a lever of
              identifier which effectively allows authentication to
              modify the identifiers used by that device but also what
              the users of these identifiers can look up. If we had used
              "user of identifier" it would have been misconstrued for
              humans. So damn if you do and damn if you don't ... 

            


            

            
We are open for discussions anytime.

            


            

            
Padma

            


            

            


            

            

              


                    

                    
-- 
Christian Huitema

                  

              

              _______________________________________________

              lisp mailing list

              lisp@ietf.org

              https://www.ietf.org/mailman/listinfo/lisp

              

            

          

          

        

      

      

      

      

      
_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


    

    

  


--------------45BDC75F3D1A7FC31FD7423D--


From nobody Wed Oct 11 13:58:19 2017
Return-Path: 
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 EBD3C132D17; Wed, 11 Oct 2017 13:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=oL3G1dUk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eKuL3PUe
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 iSMDaVt6iVpA; Wed, 11 Oct 2017 13:58:16 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7CD1286C7; Wed, 11 Oct 2017 13:58:15 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B090F20D56; Wed, 11 Oct 2017 16:58:14 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 11 Oct 2017 16:58:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=DQNg5G0pW7YSvBrnYDbCVolY9VIk/nXlEcxuhBg3qWQ=; b=oL3G1dUk D4t/EE0Q4lBiNqXmV5HdS9FASAc2q3gQ8EEL89/DJsAfGx86VIjqEJFjPXMP3ujC x4mFO79bqUJQpEUZ0oBCiJ0NwqDsBEko+0pj5tJFE+Fz9LaHbeZwyqN/kYrVDtwL fvMyUkctG5W1N3ngLJHsLZ0HxpazX197Ywi55jm5AneFAQzhl2lqYd6R7BH+aNfU 2qqbMp2E0/Ugr5ON5yYdlBw2GH5x9cj2a16u4laKzOUBNdqMQEBpXqoVltA9vXkR ywIIQGXMl+kOJeNxlvLnOJrMdNiaHiK+ClxEdWZiaSpEFY4l+Ial+YFGW0eNEPe3 9/mYJ3a4iz8Rbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=DQNg5G0pW7YSvBrnYDbCVolY9VIk/ nXlEcxuhBg3qWQ=; b=eKuL3PUe0HPqNKi0xgogscfIuyKq5JPeCXpQFBdg8OejS lFXZE5yzFdpWoXSap3ngVpPNjwXeUzDNdclwpsebrkOnfIyO7ILYVarPkGp9jvYd ALZxmxg+ijiwI9EzOq++8VSJSd1CqZvnNo76M5N2+ak5bFro6rxVMxynFv6rJP5q Z74ByJ06nYHiOT+IpZs1TWkM11kBOBkNpYOd9t2EGhVwM6BfVav+W6Fb9euH//dv jYdstU1KgNRu0BKOp8TZtdpJvhP5COFIy4kQEQ6woEkN5gAl0sIpIBl0tsQYuZcy Rxwr34tH90mFC4DBll1H/LAYBdknQ2l0NMtRXEbMw==
X-ME-Sender: 
Received: from sjc-alcoop-88112.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 6715A247AD; Wed, 11 Oct 2017 16:58:13 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_92B8B867-B651-433F-B643-0A7FC122B466"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: 
Date: Wed, 11 Oct 2017 16:58:12 -0400
Cc: IESG , ideas@ietf.org, ideas-chairs@ietf.org, aretana.ietf@gmail.com
Message-Id: <19E6AAF8-4A05-4D72-A48E-A6D7BEEEF8AE@cooperw.in>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> 
To: Sam Sun 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 20:58:18 -0000

--Apple-Mail=_92B8B867-B651-433F-B643-0A7FC122B466
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Oct 11, 2017, at 4:38 PM, Sam Sun  wrote:
>=20
> My recall from the last BoF meeting is that we got quite a large =
number of hums on the issues reflected in the current charter. I believe =
there are sufficient motivations here.=20
>=20
I don=E2=80=99t see this clearly reflected in the minutes or on the list =
discussion. =46rom the minutes it sounds like there was general interest =
in the work, but also acknowledgment that folks with deployments are not =
engaged, and many folks present who hadn=E2=80=99t read the problem =
statement or felt that the problem was not well defined. =46rom the list =
discussion, at least for the identity management piece I see only the =
proponents defending the proposal (but happy to be corrected =E2=80=94 =
I=E2=80=99m looking at this for the first time this week so may have =
missed some messages).
>=20
> The disputes on privacy protection and discoverability in the mailing =
list only shows the interests from the community looking for a better =
solution. Having disputes about different approaches, or even question =
whether or not there=E2=80=99s any feasible solution, is exactly why we =
need to form a WG to work on this, IMHO.
>=20
This seems backwards to me. We don=E2=80=99t typically form working =
groups in order to determine whether there is work to be done and =
whether there is any way that work can be designed in alignment with our =
BCPs and principles about things like privacy. That is what the =
chartering process is for.

Alissa
>=20
> Sam
>=20
>=20
> On 10/11/17 10:53 AM, Alissa Cooper wrote:
>> Alissa Cooper has entered the following ballot position for
>> charter-ietf-ideas-00-06: Block
>>=20
>> 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.)
>>=20
>>=20
>>=20
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-ideas/ =

>>=20
>>=20
>>=20
>> =
----------------------------------------------------------------------
>> BLOCK:
>> =
----------------------------------------------------------------------
>>=20
>> I do not think this group is ready to be chartered at this time given =
the
>> significant objections from the community.
>>=20
>> There seem to be two key problems with the work as proposed:
>>=20
>> (1) The work is insufficiently motivated. The claims about the need =
for the
>> mapping system and the identity management system envisioned here do =
not appear
>> to be backed up by those who have developed and deployed ID/LOC =
separation
>> protocols. Nor do there seem to be compelling arguments that the =
framework that
>> this proposed WG would produce would be the motivator for further =
interoperable
>> deployments.
>>=20
>> (2) The work proposed here seems as if it would have a substantial =
intrinsic
>> impact on user privacy if widely deployed. In cases like these, I =
don't believe
>> it's sufficient to say that the WG will analyze the situation and =
propose
>> mitigations; the work proposal itself needs to explain how the design =
of the
>> infrastructure envisioned is going to mitigate what seem like obvious =
attacks
>> on privacy that the proposed designs open up.
>>=20
>> I think further discussions of this work (in private, on the list, at =
a bar in
>> Singapore, or at a potential future BoF) would need to resolve both =
of the
>> above issues in order to address concerns raised by the community.
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ideas =

>=20


--Apple-Mail=_92B8B867-B651-433F-B643-0A7FC122B466
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Oct 11, 2017, at 4:38 PM, Sam Sun <sam.sun.ietf@gmail.com> wrote:


 =20
    
 =20
  
My recall from the =
last BoF
        meeting is that we got quite a large number of hums on the
        issues reflected in the current charter. I believe there are
        sufficient motivations here. 
I don=E2=80=99t see =
this clearly reflected in the minutes or on the list discussion. =46rom =
the minutes it sounds like there was general interest in the work, but =
also acknowledgment that folks with deployments are not engaged, and =
many folks present who hadn=E2=80=99t read the problem statement or felt =
that the problem was not well defined. =46rom the list discussion, at =
least for the identity management piece I see only the proponents =
defending the proposal (but happy to be corrected =E2=80=94 I=E2=80=99m =
looking at this for the first time this week so may have missed some =
messages).

        

        The disputes on privacy protection and discoverability in the
        mailing list only shows the interests from the community looking
        for a better solution. Having disputes about different
        approaches, or even question whether or not there=E2=80=99s any =
feasible
        solution, is exactly why we need to form a WG to work on this,
        IMHO.
This =
seems backwards to me. We don=E2=80=99t typically form working groups in =
order to determine whether there is work to be done and whether there is =
any way that work can be designed in alignment with our BCPs and =
principles about things like privacy. That is what the chartering =
process is for.

Alissa

        

        Sam

    

    
On 10/11/17 10:53 AM, Alissa Cooper
      wrote:

    

    

      
Alissa Cooper has entered the following =
ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://data=
tracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I do not think this group is ready to be chartered at this time given =
the
significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for =
the
mapping system and the identity management system envisioned here do not =
appear
to be backed up by those who have developed and deployed ID/LOC =
separation
protocols. Nor do there seem to be compelling arguments that the =
framework that
this proposed WG would produce would be the motivator for further =
interoperable
deployments.

(2) The work proposed here seems as if it would have a substantial =
intrinsic
impact on user privacy if widely deployed. In cases like these, I don't =
believe
it's sufficient to say that the WG will analyze the situation and =
propose
mitigations; the work proposal itself needs to explain how the design of =
the
infrastructure envisioned is going to mitigate what seem like obvious =
attacks
on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a =
bar in
Singapore, or at a potential future BoF) would need to resolve both of =
the
above issues in order to address concerns raised by the community.




_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/=
mailman/listinfo/ideas


    

    

  




=

--Apple-Mail=_92B8B867-B651-433F-B643-0A7FC122B466--


From nobody Wed Oct 11 14:15:13 2017
Return-Path: 
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 2C49013219E; Wed, 11 Oct 2017 14:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ij2ynI-Nno4O; Wed, 11 Oct 2017 14:15:06 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 94B041286C7; Wed, 11 Oct 2017 14:15:06 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id m28so2066243pfi.11; Wed, 11 Oct 2017 14:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VqWHemtECkl3Qq7M+sRYxY9gQ/eKjzY1ytSYKdm2qvE=; b=CSYU0pVkREMsBHMXzECJXpEtpCcctERE6zal/4AV/TxZeMK4BKfdHv5TwxoALQR/yw hjjPeLroZtIiNc8Ftl0AutuUaqBgZIeV+FE+Hinw83hhU32iC0+Z0NAQ5qSZTslIh7Tx 77avc4oQll6RT1iX2umU9UpRYWg5SazICquMMsf87HleQEP8OnM7PRjTWxyaudcygQts X9xLSk6bsgxf9Ky9rMCBEa2ztPLgrPV7iJyw+ATpklXYANErBopo+/WqtihqNEx0AWTz EHr/hV1aDafN19AjFBGHFdprrXBmE0+L1N+LJ1jOFf2cPRMKe6t9yteFssu2y+Hupmri TydA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VqWHemtECkl3Qq7M+sRYxY9gQ/eKjzY1ytSYKdm2qvE=; b=JSofCMHtIivpJ/IhE8pOUAVPYwIDdZFDYFGL58600MJ4Ovb561ujZHRbxXylfAKOtg TULyv5hk+Tq0R6WBXDIIvXskcxlljmNLVUDFMoO1mGJqbkulHP1u1M23OVT5nqCadKoU c142XAp4lRQmy7qyrQdGEahw1eo6g6dYogOSfuadKfIT704dB/yQwpBYTsCCTBMmVgUT ILyY8cBpitVhPtAhCOmAxkuwlCCk+m6C3ztiNkcpitewYF+TvYZi6MwNue/wcxzsog22 medqxf8FfKXjt9qRWzPzqZmz2zMG3ZhgVqafkPKJVW/t7u7NQhuVsmzksRXLy8eoi+Y0 P0tA==
X-Gm-Message-State: AMCzsaXYz54/9bPhARp7s+v7WZ0Q01EMvFQBLuDRmcXOhRjWqoTOs9E8 gSm6ywM2ikj4n7y3uzmBqhE=
X-Google-Smtp-Source: AOwi7QDGMOwwff35QHFJI1dYoTZOwJDmzEeio6CaCBc/tevXYg9XP0F1GlpT8AHWhE4orydPi+23TA==
X-Received: by 10.98.109.194 with SMTP id i185mr254470pfc.67.1507756506082; Wed, 11 Oct 2017 14:15:06 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id q70sm22198901pfj.39.2017.10.11.14.15.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 14:15:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 14:15:04 -0700
Cc: Robert Moskowitz , Eric Rescorla ,  ideas-chairs@ietf.org, ideas@ietf.org, IESG , aretana.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CED1916-4E42-4AE1-B3F8-500A8030C072@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com> <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com> 
To: Alissa Cooper 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 21:15:08 -0000

> On Oct 11, 2017, at 1:08 PM, Alissa Cooper  wrote:
>=20
>=20
>> On Oct 11, 2017, at 3:59 PM, Dino Farinacci  =
wrote:
>>=20
>>> Dino and I are connected outside the IETF.  These groups come to us =
to talk, then go back and do their own thing to fill the void.  They =
will NOT come to the IETF, but will take what is offered.
>>=20
>> And of course, the typical mantra from them (and I know you all have =
heard this before):
>>=20
>> (1) The IETF is too slow.
>>=20
>> (2) The IETF cannot decide.
>>=20
>> (3) The IETF has too many options. So we are going to pick one and =
put our Intellectual Property on top of it (i.e. SD-WAN IPsec doesn=E2=80=99=
t interoperate).
>>=20
>> (4) We can do protocols better and faster than the IETF.
>>=20
>> (5) We want to build our own protocols so we look innovative.
>>=20
>> (6) We can get strategic interoperability with our business partners.
>=20
> I don=E2=80=99t understand how chartering this WG with the proposed =
charter =E2=80=94 to write a framework document =E2=80=94=20

Agree. But the work is important and the limited definition of the work =
MUST be in the charter.

> =E2=80=9CThe IETF=E2=80=9D amounts to the people who come to the IETF =
to do the work and review the work. Work doesn=E2=80=99t get chartered =
unless the people who want it can at least minimally engage, explain why =
they want it in a way that is compelling to others, and explain how it =
fits within the scope of the rest of the IETF=E2=80=99s work and the =
internet architecture.
>=20
> As I said in my note to Tom, this charter ballot isn=E2=80=99t a death =
sentence on all mapping system work forever more. It=E2=80=99s a =
judgment about the charter text and deliverables as they are right now.

Understand. Thanks for being open minded.

Dino

>=20
> Alissa
>=20
>>=20
>> Dino
>=20


From nobody Wed Oct 11 14:25:39 2017
Return-Path: 
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 09C771321A0; Wed, 11 Oct 2017 14:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 PjHW_UQ5NIyH; Wed, 11 Oct 2017 14:25:29 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 970ED132332; Wed, 11 Oct 2017 14:25:29 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id b85so2086718pfj.13; Wed, 11 Oct 2017 14:25:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=irwgIGZU//9IyWU1pCjxaq/c1KvWyuS8o8eD0xRX+SA=; b=Hn75PX8ffnmNMP7tWsFseE+NarPEZnbrNWNCklPmm4HiKsJqT0NWkgEpjs8uzbgCt/ 1TI61NDshLFRMx2KT0JjkCXTLHlHNaQYz0cVVQCheTmJrDA7Xsr02XEspLRskbd3uszQ +z29fT5kzmWwLkGnsKCFu5FQIElm+YP/fHF4wp4O2UumHYzOAAC6qKpb3+flu6w31v/N 1Pb3IrnDhRjRxqST3rYtQ56rVVKSUupTjnM6iHANVb+wHh9kxyvkMhszeQ2OQ2+w7NQZ WOSQGbx3wC/9XF/pcoy0Rs4nHovvmXja4hRgRZf0xl2eF7iAIqZXB2nAkTg2Og27A4eG CNEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=irwgIGZU//9IyWU1pCjxaq/c1KvWyuS8o8eD0xRX+SA=; b=dxBP0xlg/oNgmhg7CvHXTYXeBbhSpzb/uVceSAn4MRR24MaWQBlU0OlaZFYPRIlXU6 B2R9P9i0aSEQTpxbq+d46w8w83OC9H5+O6guz6KcS6AQg+DVuhmxb3/8s4K1VTGfbcAD 4fAcyQKg+6xvtC6HWbnzWGthB+xVD6clpmeh7SCTkiMGLLZxrPpVE0bzbOgv1B4rzQqG 8RdJ2wVsI/4/bp/mc6schggm2/Bp4uEjWSNnnphFLNJ2JPe5bE70VmUPQOj0yPDWaLck jOlX/PVH71GGIHbyoUb46IJSEm8FNAAev1/GOVwMt8f3LRHVVvfPVVT2Zob3B4HPFtcj Fjgg==
X-Gm-Message-State: AMCzsaV+F2flnealsJ7LYzebdiTJNqLZN77GnqU2LkK0xCuMXzx5PueP jhP7r8/j/P6H+sZunojwqqc=
X-Google-Smtp-Source: AOwi7QBKjac0GMEF++3zi3oZkI720vtAJl47GUDA1YR1pGU/OEoqgpdMb2IjA79Bml4Jb+/RDYJ1Cg==
X-Received: by 10.98.35.18 with SMTP id j18mr285814pfj.37.1507757129178; Wed, 11 Oct 2017 14:25:29 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id g68sm24656165pfc.64.2017.10.11.14.25.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 14:25:28 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci 
In-Reply-To: 
Date: Wed, 11 Oct 2017 14:25:27 -0700
Cc: Christian Huitema , "ietf@ietf.org" ,  "ideas@ietf.org" , "lisp@ietf.org list" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ED1DD7F-FD96-4934-9518-EDE5DB4858BE@gmail.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>   <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>  <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com>     <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com>     
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Ideas] [lisp]  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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 21:25:31 -0000

>> It needs the information for table lookups. So how private/trackable =
are IP addresses in packets today?
>=20
> Uh really terrible? That's why things like Tor exist.

TOR exists because the network layer doesn=E2=80=99t have sufficient =
security. I=E2=80=99m preaching to the choir.

> I'm not sure it's useful to continue with the technical side of the =
present discussion. We're not trying=20

It is useful because there is usually no technical discussion among =
people from different areas of expertise. The discussion tend to happen =
when a decision like this is made.

So I=E2=80=99ll take the discussion whenever I can get it!

> to design a system here. The requirements for the system the WG is to =
design is is properly the kind of question that needs to be hashed out =
for the charter for the WG.

I am trying to design a system. And we need more deployment experience. =
And I think an IETF working group can help facilitate this. Otherwise, =
people will do it else where and new protocols will surface OUTSIDE of =
the IETF. And that is when scale, security and interoperability is not =
priority.=20

In the IETF, we are for the common good.=20

Dino


From nobody Wed Oct 11 14:36:46 2017
Return-Path: 
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 8F06D1321A0; Wed, 11 Oct 2017 14:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 Di42W4ki31QK; Wed, 11 Oct 2017 14:36:43 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 2EA2C1320D9; Wed, 11 Oct 2017 14:36:43 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id n61so9568827qte.10; Wed, 11 Oct 2017 14:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=m67DVlXkmYZNL09akbjqNN/n7ud8h5DWL2zZJB3GBnQ=; b=NQ06ngWhzeX1oWG7ltvvQZrRkEF0xGCCi4xXc8fXx791qt7G8K7FqkotWNyboOLvBJ mnSRloJMq6ou6+Pkvr1VsdRSHf3V5v5/j5f6mvt7u+MeJOJe1SfqOFeugV3bwWmsakQf 5leip3kI9LtTVseDsJKwT00rJteVw/eHA7rbygnrjsQVhmvHkbQXhk0LsjNC30FCmd7C YegYQmUsFFCVLv5NttemPsUOaqR7a1cdFUXM1MdL9QByukOTBDqf/6MYIXNdCfIs3FaV AjRXwhvuqBcX7/iR9Jt+si66e05CX0baQ/xDFYBclpaK4Z5jT59NI41xgQFSM5BtMqok sChw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=m67DVlXkmYZNL09akbjqNN/n7ud8h5DWL2zZJB3GBnQ=; b=qazDgDNZ71JsSGYBN7OVwQ1bpMS1rBIqFOkKX2Ryg2nLdLF/l8VabRN5sfDzvgO6GY YYZP7QO/RYy8lH9swW+q5BFKrd0la7Fia4T1vNzBjZT95z2bSSfU7ourRfyACxDywPXp CsEgSElBtQ4gRyXQ6GAz+fa3rcbJJBajbPruq1j0Kfm8jKgIJTa0Rkr6JVgUKd/QJD2/ xSjzhgMPhD3arfEkcehg24B36/lqG1HsV/yG78UbfHW4aE0N2KOVLS8nmG8fwoU9wOIP Cxvp6V8XzcK+9Cy4xtoX96aAalXKS0yMBHuWBecRQ/FD6C0vm1otoNpSRp05/3GLHXyf KokQ==
X-Gm-Message-State: AMCzsaWglv3HGLnKjF/uVnaZaKFIYuDEuL+hcQaKtlSudWHODPZf55Eq Kgqx8n5byeF0wOAXPXL2KvE=
X-Google-Smtp-Source: ABhQp+S4wr5iD/UhFbLix6d9QSsZreGk2nM0qt9EzcSLjpIsxeg02JJOSdkNBmEUFGoclTMQ2MeNyQ==
X-Received: by 10.55.22.146 with SMTP id 18mr576777qkw.281.1507757802350; Wed, 11 Oct 2017 14:36:42 -0700 (PDT)
Received: from host-4-159.cnri.reston.va.us (cnri-7-77.cnri.reston.va.us. [132.151.7.77]) by smtp.gmail.com with ESMTPSA id f64sm8514760qka.6.2017.10.11.14.36.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 14:36:41 -0700 (PDT)
To: Alissa Cooper 
Cc: IESG , ideas@ietf.org, ideas-chairs@ietf.org, aretana.ietf@gmail.com
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com>  <19E6AAF8-4A05-4D72-A48E-A6D7BEEEF8AE@cooperw.in>
From: Sam Sun 
Message-ID: 
Date: Wed, 11 Oct 2017 17:36:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19E6AAF8-4A05-4D72-A48E-A6D7BEEEF8AE@cooperw.in>
Content-Type: multipart/alternative; boundary="------------F52B1A742766373B1C76A731"
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 21:36:46 -0000

This is a multi-part message in MIME format.
--------------F52B1A742766373B1C76A731
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 10/11/17 4:58 PM, Alissa Cooper wrote:
>
>> On Oct 11, 2017, at 4:38 PM, Sam Sun > > wrote:
>>
>> My recall from the last BoF meeting is that we got quite a large 
>> number of hums on the issues reflected in the current charter. I 
>> believe there are sufficient motivations here.
>>
> I don’t see this clearly reflected in the minutes or on the list 
> discussion. From the minutes it sounds like there was general interest 
> in the work, but also acknowledgment that folks with deployments are 
> not engaged, and many folks present who hadn’t read the problem 
> statement or felt that the problem was not well defined. From the list 
> discussion, at least for the identity management piece I see only the 
> proponents defending the proposal (but happy to be corrected — I’m 
> looking at this for the first time this week so may have missed some 
> messages).
>>
>>
>> The disputes on privacy protection and discoverability in the mailing 
>> list only shows the interests from the community looking for a better 
>> solution. Having disputes about different approaches, or even 
>> question whether or not there’s any feasible solution, is exactly why 
>> we need to form a WG to work on this, IMHO.
>>
> This seems backwards to me. We don’t typically form working groups in 
> order to determine whether there is work to be done and whether there 
> is any way that work can be designed in alignment with our BCPs and 
> principles about things like privacy. That is what the chartering 
> process is for.
>
This is good clarification.

The proposed charter did state the exact works to be done, including 
"security analysis of the complete system". Intrinsic impact on user 
privacy could be covered here. Whether the infrastructure envisioned 
opens up obvious attacks on privacy depends how the system is finally 
defined. With proper access control and protection on data 
confidentiality, it may or may not.


Sam



> Alissa
>>
>>
>> Sam
>>
>>
>> On 10/11/17 10:53 AM, Alissa Cooper wrote:
>>> Alissa Cooper has entered the following ballot position for
>>> charter-ietf-ideas-00-06: Block
>>>
>>> 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.)
>>>
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/charter-ietf-ideas/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> BLOCK:
>>> ----------------------------------------------------------------------
>>>
>>> I do not think this group is ready to be chartered at this time given the
>>> significant objections from the community.
>>>
>>> There seem to be two key problems with the work as proposed:
>>>
>>> (1) The work is insufficiently motivated. The claims about the need for the
>>> mapping system and the identity management system envisioned here do not appear
>>> to be backed up by those who have developed and deployed ID/LOC separation
>>> protocols. Nor do there seem to be compelling arguments that the framework that
>>> this proposed WG would produce would be the motivator for further interoperable
>>> deployments.
>>>
>>> (2) The work proposed here seems as if it would have a substantial intrinsic
>>> impact on user privacy if widely deployed. In cases like these, I don't believe
>>> it's sufficient to say that the WG will analyze the situation and propose
>>> mitigations; the work proposal itself needs to explain how the design of the
>>> infrastructure envisioned is going to mitigate what seem like obvious attacks
>>> on privacy that the proposed designs open up.
>>>
>>> I think further discussions of this work (in private, on the list, at a bar in
>>> Singapore, or at a potential future BoF) would need to resolve both of the
>>> above issues in order to address concerns raised by the community.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ideas mailing list
>>> Ideas@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ideas
>>
>


--------------F52B1A742766373B1C76A731
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 10/11/17 4:58 PM, Alissa Cooper
      wrote:

    

    

      
      

      

        

          
On Oct 11, 2017, at 4:38 PM, Sam Sun <sam.sun.ietf@gmail.com>
            wrote:

          

          

            
            

              
My recall from
                  the last BoF meeting is that we got quite a large
                  number of hums on the issues reflected in the current
                  charter. I believe there are sufficient motivations
                  here. 

                

            

          

        

        
I don’t see this clearly reflected in the minutes or on the
          list discussion. From the minutes it sounds like there was
          general interest in the work, but also acknowledgment that
          folks with deployments are not engaged, and many folks present
          who hadn’t read the problem statement or felt that the problem
          was not well defined. From the list discussion, at least for
          the identity management piece I see only the proponents
          defending the proposal (but happy to be corrected — I’m
          looking at this for the first time this week so may have
          missed some messages).

        

          

            

              
 

                  The disputes on privacy protection and discoverability
                  in the mailing list only shows the interests from the
                  community looking for a better solution. Having
                  disputes about different approaches, or even question
                  whether or not there’s any feasible solution, is
                  exactly why we need to form a WG to work on this,
                  IMHO.

                

            

          

        

        
This seems backwards to me. We don’t typically form working
          groups in order to determine whether there is work to be done
          and whether there is any way that work can be designed in
          alignment with our BCPs and principles about things like
          privacy. That is what the chartering process is for.

        


        

      

    

    This is good clarification. 

    

    The proposed charter did state the exact works to be done, including
    "security analysis of the complete system". Intrinsic impact on user
    privacy could be covered here. Whether the infrastructure envisioned
    opens up obvious attacks on privacy depends how the system is
    finally defined. With proper access control and protection on data
    confidentiality, it may or may not.

    

    

    Sam

    

    

    

    

      

        
Alissa

        

          

            

              
 

                  Sam

              

              
On 10/11/17 10:53 AM, Alissa
                Cooper wrote:

              

              

                
Alissa Cooper has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I do not think this group is ready to be chartered at this time given the
significant objections from the community.

There seem to be two key problems with the work as proposed:

(1) The work is insufficiently motivated. The claims about the need for the
mapping system and the identity management system envisioned here do not appear
to be backed up by those who have developed and deployed ID/LOC separation
protocols. Nor do there seem to be compelling arguments that the framework that
this proposed WG would produce would be the motivator for further interoperable
deployments.

(2) The work proposed here seems as if it would have a substantial intrinsic
impact on user privacy if widely deployed. In cases like these, I don't believe
it's sufficient to say that the WG will analyze the situation and propose
mitigations; the work proposal itself needs to explain how the design of the
infrastructure envisioned is going to mitigate what seem like obvious attacks
on privacy that the proposed designs open up.

I think further discussions of this work (in private, on the list, at a bar in
Singapore, or at a potential future BoF) would need to resolve both of the
above issues in order to address concerns raised by the community.




_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


              

              

            

          

        

      

      

    

    

  


--------------F52B1A742766373B1C76A731--


From nobody Wed Oct 11 15:08:12 2017
Return-Path: 
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBDE1330C1; Wed, 11 Oct 2017 15:08:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150775968538.16711.15177859388936829449.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 15:08:05 -0700
Archived-At: 
Subject: [Ideas] Adam Roach's Block on charter-ietf-ideas-00-06: (with BLOCK)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Oct 2017 22:08:05 -0000

Adam Roach has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I agree with Kathleen's evaluation and second her proposal to have additional
privacy-focused discussions around the charter language prior to moving forward.





From nobody Wed Oct 11 17:01:16 2017
Return-Path: 
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 665F7132939; Wed, 11 Oct 2017 17:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 8S2kNlMi87Ll; Wed, 11 Oct 2017 17:00:30 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 5975B1342FA; Wed, 11 Oct 2017 17:00:24 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id e64so2509586pfk.9; Wed, 11 Oct 2017 17:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EoGSZr1uzmC5qWEDfcv8vQbJVaYxYGcE/NexrCRI/sI=; b=LF9k667nTdA80qd6IQRWrGJ9XonUV8lV8zsUoKQIYGB8opzVJW2NgGCr6rybArWqa6 cAaTykJyga+VGIpuvUq47eUmJVwBF5MZMvipiT+3krqUzjeXj3oL3gj3VMoWEwtxZlfd C7Dx77juYRRb81XJDslwZGXrXKrS283N4b6n11ZFhu1hftgm+TkpxHHaNbUSr+G+5hVx V8/IXEQVUTU36rsjitbGfEOnEEOx7SD1h9hLDZQ50BZ6/zWWrde7uP2Ueuj6EyahcIfK DWPa3UrEIbZ0/P2pkFuU4ezUlWM1MMpKXKbqlbnY3B4hBCXAdqsGPho6ZGk0L2YiMPPA 9xkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EoGSZr1uzmC5qWEDfcv8vQbJVaYxYGcE/NexrCRI/sI=; b=AsMfQRdpqgcBu8wa08242M6TSozhaHjhbyrbsyXLrI0d88/TKRFVoluP8JSsmgEcpP 60bmbK5JPlK8AYUo8vgXmks1W6jungHYNGQvrcEUSHeiGII9kpvZZe5NKwSLN2oVJjNh 9Cu6L5MjKWMFIqu5SuUTL2ZZPXzmr5sXC3WkOg5e22TGJAKyOQgiHCzhtrQGOLZl4Dqp 9m0XGgN/gypIXiwrKg3K9GTq2Nh8esmeh3QAqo511P8NqoEQFORrs5TGXp0NpwkUmjFe 3WfVUsw7FDX6TZyxU9uyBHIhC6h9FPxkLYCfmwPRwSS8eqoNIQBcs8nMCFeuCO6q8VBU 3vCg==
X-Gm-Message-State: AMCzsaXFUSUWwjg4lsNxNkaj2iz/ifpt2ZBQjzaUIn2KnnH6SZ660Ru+ I0bc49Z98JtyKYzaUKuHpv41nfk=
X-Google-Smtp-Source: AOwi7QCcYdQQ3W+tQvmIQa74QzzisYhB0dKoYOOOe4N9tStNf0y+j9COnH/Xo9FM9QCuleE8DPRorA==
X-Received: by 10.98.252.71 with SMTP id e68mr532722pfh.319.1507766423455; Wed, 11 Oct 2017 17:00:23 -0700 (PDT)
Received: from ?IPv6:2600:1010:b04c:26b6:35c4:532e:4231:b8de? ([2600:1010:b04c:26b6:35c4:532e:4231:b8de]) by smtp.gmail.com with ESMTPSA id y5sm28685292pfd.89.2017.10.11.17.00.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 17:00:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409
Mime-Version: 1.0 (1.0)
From: Sharon 
X-Mailer: iPhone Mail (15A421)
In-Reply-To: 
Date: Wed, 11 Oct 2017 17:00:20 -0700
Cc: ideas@ietf.org, LISP mailing list list , NVO3 , routing-discussion@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
To: Padma Pillay-Esnault 
Archived-At: 
Subject: Re: [Ideas] [lisp] IDEAS @IETF98 Minutes
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 00:00:35 -0000

--Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Discussed these 2 ID networking items with Albert and others, perhaps this i=
s a good thread:

1. MAMBO -=20

Map-Assisted Measurnent Based Overlay
The notion here is that identity based overlays offer global (map-assisted) c=
hoices hop by hop underlays do not. One factor in making these choices can b=
e by measuring the pearson correlation coefficient (pcc) between the tunnels=
. If considered when selecting between VTEP X or VTEP Y to reach a multi hom=
e EID or a load balanced EID it can double-quadruple overall overlay capacit=
y.=20

2. Lisp-Lambda -
A serverless (or virtual-appliance-less) alternative to service function cha=
ining which is hard to scale and dev-ops. Its done by mapping flows at the I=
TR, ETR, or STR (segment) to queues, and using the mapping to invoke the (ca=
ched) function on the flow queue packets rather then hair pining the packets=
 in and out of function virtual appliances. Saves nic-ram-nic-ram... costly l=
ifting.

There are reference implementations and simulations to both if theres intere=
st.=20


--szb

> On Apr 13, 2017, at 12:01 AM, Padma Pillay-Esnault  w=
rote:
>=20
> =20
>=20
>=20
> Please find below the minutes of the meeting.
>=20
> Many thanks to our two scribes: Toerless Eckert and Uma Chunduri.
>=20
>=20
> If you have any comments/corrections please let us know.
>=20
> Thanks
>=20
> Padma
>=20
>=20
>=20
> IDEAS Side Meeting Minutes=20
>=20
> =20
>=20
> 1. Slides
>=20
> Please find below a pointer to the slides
>=20
> https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=3D=
sharing
>=20
> =20
>=20
> =20
>=20
> 2. Agenda=20
>=20
> 2.1. Introduction and Problem Statement for IDEAS  - Padma Pillay-Esnault
>=20
> =20
>=20
> https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-0=
1.txt   =20
>=20
> =20
>=20
> IDEAS Introduction
>=20
> =20
>=20
> IDEAS aims to be the forum where common issues across all ID Enabled Netwo=
rks can be discussed.
>=20
>  Goals:
>=20
> -       to create awareness
>=20
> -       to present the work proposed in IDEAS
>=20
> -       A generic architecture that is scalable, extensible, robust, secur=
e, and flexible for future ID enabled networks
>=20
> -        to sollicit comments and feedback from the community on the draft=
s
>=20
> -       to call for new contributions
>=20
>  =20
>=20
> Problem Statement
>=20
> Motivation: Why Now?
>=20
> ID solutions can address diverse areas
>=20
>             IOT, M2M communication, Discovery, privacy, Latency, Virtualiz=
ation
>=20
> Beneficial to have standardized common infra across ID protocols
>=20
> =20
>=20
> Key Issues Identified
>=20
> Lack of common Infrastructure cause harder to deploy a common solution E2E=

>=20
>   -       No Common Management due to disjoint nature
>=20
>   -       No Common/consistent policy framework
>=20
>   -       Risk of fragmented communication
>=20
>  Identifier Lifecycle
>=20
>   -       No guidance or allocation scheme for public IDs
>=20
>   -       Agreed upon ID format and scope in cross-domain communication
>=20
>   -       Recycling IDs
>=20
>   -       Better address merging of networks
>=20
>  Security of Mapping Systems
>=20
>   -       Secured access to the MS
>=20
>   -       data integrity, Confidentiality, Anonymity, Access control
>=20
>   -       DDOS attack prone
>=20
> =20
>=20
> Proposal
>=20
> -       To investigate the opportunity of a new specification effort to ad=
dress some specific problems from an ID Enabled Networks perspective.
>=20
> -       To find a common solution and infrastructure that can be shared by=
 current protocols and facilitate the introduction of new ID-based services w=
hile avoiding rehashing the same problems again each time a new service pops=
 up
>=20
> -       Generic Resilient ID Services (GRIDS) infrastructure with standard=
ized access and multiple services.  The services include
>=20
>       -       secured registration
>=20
>       -       discovery
>=20
>       -       updates with data integrity,
>=20
>       -       mapping and resolution capabilities,
>=20
>       -       define relationships between IDs or group of IDs
>=20
>       -       access control policy and security
>=20
> - Other Related Work/ Groups
>=20
>        - LISP (ALT, DDT)
>=20
>        - HIP uses DNS
>=20
>        - NVO3 WG
>=20
> =20
>=20
> Questions:
>=20
> Eric Nordmark: What=E2=80=99s unclear is what is out of scope re. Identifi=
er. Are you considering "what is an identifier", clearly this is not about U=
RI, how about IP in IP with IPsec ? Is one of them an identifier the other o=
ne a locator. Even LISP was not clear cut between locator/identifier as one c=
ould be routed locally.
>=20
> =20
>=20
> Padma Pillay-Esnault: Regarding scope, the way we thinking about this, the=
re can be multiple scopes with multiple allocation systems. The range of sol=
utions is so vast that it may not be appropriate to only have one solution. P=
lenty options of where to put it and how to put. GRIDS can be used as local,=
 proximity, global instance just as possible to have Private ID.
>=20
> =20
>=20
> Bob Moskovitz: Concept of Identity and Identifier is important and  I have=
 been involved and saw some form of this for the last 20 years may be more. I=
t really does to be discussed in the list. Definitely it needs to be fleshed=
 out a lot more about
>=20
> what identifiers are, should be part of the work, tough problem with lots o=
f opinions.
>=20
> =20
>=20
> =20
>=20
> 2.2. Requirements for Generic Resilient Identity Services (GRIDS) in IDEAS=
  - Alex Clemm
>=20
> =20
>=20
> https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt
>=20
> =20
>=20
> - This is the core infrastructure document which captures all requirements=

>=20
>      - Talked on Core components of GRIDS
>=20
>      - GRIDS-MS, GRIDS-IS are covered
>=20
>      - Grouping and Meta data are not described yet
>=20
>      - Identity and Identifier definitions elaborated
>=20
>      - Talked in details about mapping services
>=20
>      - Identity related services are detailed
>=20
>           - Structured and unstructured identifiers
>=20
>           - Grouping related services
>=20
>      - Requirement (Distribution, Redundancy, Performance and Scale..)
>=20
>      - Key performance requirements
>=20
>      - Security requirements
>=20
>      - GRIDS should be able to be deployed in private space as well as in p=
ublic domain
>=20
> =20
>=20
> - The naming evolved from mapping system, which was too functionally const=
rained.
>=20
> =20
>=20
> Questions:=20
>=20
> Ravi Ravindran: Trying to understand scope: trying to expand LISP ?
>=20
> What is the scope ?=20
>=20
> =20
>=20
> Alex Clemm: No, not planning to just "expand lisp", that should be done in=
 LISP WG. Some of those questions are better answered in the use cases, clea=
r which ones are not resolved by LISP.
>=20
> =20
>=20
> Benjamin Damm: How is this different from Multicast DNS ?
>=20
> =20
>=20
> Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that=
 would not be a great idea but there would be a lot of
>=20
> problems, DDoS, etc.. Think that metadata is not optional but must be call=
ed mandatory. Determined by use case.
>=20
> =20
>=20
> Alex Clemm: Note taken
>=20
> =20
>=20
> Dino Farinacci:  rfc8060 defines multiple RLOC types, eg: LISP can support=
 those. Does this look like multicast DNS ? No, this is network layer mappin=
g information mapping addresses to addresses.
>=20
> =20
>=20
> Eric Nordmark: Multicast DNS is a local service, this is meant to be globa=
l.
>=20
> =20
>=20
> =20
>=20
> 2.3. A Blockchain-based Mapping System - Jordi Paillisse=20
>=20
> - Blockchain is decentralized and secured
>=20
>      - Add blocks of data one after other
>=20
>      - Blockchain work flow
>=20
>      - Transaction with a data, Senders Signature and Senders Public Key t=
o a P2P network
>=20
>      - Properties
>=20
>         - Decentralized, No prior trust is required
>=20
>            Data can be added but not modifiable
>=20
>      - Basic Idea
>=20
>         - Store mappings in blockchain
>=20
>         - EID prefixes are distributed to all participants
>=20
>      - Pros and Cons
>=20
>         - Infrastructure less, Decentralized, fast lookup, secure, no prio=
r trust, simple rekeying
>=20
>         - Cons
>=20
>             - Slow updates, costly boot strapping
>=20
>      - Comparison with LISP DDT
>=20
>         - No Infra, easy management
>=20
>      - Issues with RPKI
>=20
>          - Anonymity (prefix linked to owner name)
>=20
>          - Revocation issues (block chain doesn=E2=80=99t use certificates=
)
>=20
>      - Scalability
>=20
>          - Growth similar to BGP Churn
>=20
>          - Prefix delegation + Mappings
>=20
>      - Design considerations
>=20
>            - Bitcoin is too restrictive
>=20
>            - New technologies - More scalable and more contracts
>=20
>      - Dedicated chains..
>=20
> =20
>=20
> Questions:
>=20
> Toerless Eckert: what is the incentive model for participants to deploy th=
e necessary infrastructure for this system ? In bitcoin, the security is ach=
ieved  through tremendous amount of calculation, the cost for that hardware i=
s financed by handing out bitcoins for successful calculations. Do we need t=
o hand out IPv4 addresses to pay for IDEAS bitchain calculations ?
>=20
> =20
>=20
> Jordi Paillisee: Good question, there are some new blockchain methods with=
 other incentive structures. See references on last slide of the slide deck.=

>=20
> Regarding incentive it is about security.
>=20
> =20
>=20
> Dino Farinacci:=20
>=20
> When a new registration added (Say Jordi first and then 100000 more record=
s added. Now the entry moved to the end. This solution will have
>=20
> complete history of movements. Q1: can the really old stuff be chopped off=
. Q2: if RLOCs change etc. is it not really slow when you need to look throu=
gh a lot of other newer mappings ?
>=20
> Jordi Paillisee : Q1 Answer: It can be mitigated through implementation
>=20
> Q2 answer: implementation detail. Database should have latest data for all=
 entities, not in sequential order of evens.
>=20
> =20
>=20
> Manu Sporny: Blockchain developer. Referring to blockchain group (w3c-bloc=
kain group) met in the morning, sees overlap with that work, how could we cr=
eate alignment. Whom to talk to coordinate ?=20
>=20
> Padma Pillay-Esnault: Let=E2=80=99s discuss this offline.
>=20
> =20
>=20
> 2.4. Use Cases for IDEAS - Tom Herbert
>=20
> https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt
>=20
> =20
>=20
> - Mapping essentially a distributed key/value store
>=20
>        - Key is fixed size per mapping DB
>=20
>       - Maps "virtual address" to "physical address"
>=20
>        - Mapping table is assumed to be distributed and possibly shared fo=
r load
>=20
>        - Rate of entry is important characteristic
>=20
> =20
>=20
>        - Use Cases:
>=20
>               - Common Control plane
>=20
>               - Mobility
>=20
>               - Network Virtualization (for network simplification)
>=20
>               - Heterogeneous Multi-Access (hetnet)
>=20
>               - Security
>=20
>               - Device Discovery
>=20
>        - Mobility
>=20
>            - Map entity to its current location for forwarding
>=20
>            - Variants        =20
>=20
>                - Encap: IP Mobility, IPIP, GTP etc..
>=20
>                - ID/LOC: LISP, ILA
>=20
>            - Properties
>=20
>        - Mobility sub-cases
>=20
>            - Within a single mobile network
>=20
>            - Mobility between mobile networks
>=20
>            - Multi-homed devices
>=20
>            - Hetnet environments
>=20
>            - Whole networks are mobile (WIFI in bus)
>=20
>        - Network Virtualization
>=20
>            - Variants
>=20
>               - Encap: Map virtual IP address to Physical address
>=20
>               - ID/LOC split
>=20
>            - Properties
>=20
>               - Mostly in DC
>=20
>        - Address resolution static tunnels
>=20
>            - Could be used as alternative means to resolve L2/L3
>=20
>        - Host Routes
>=20
>            - A network could implement virtualization simply by creating a=
 host route
>=20
> =20
>=20
> Questions:
>=20
> Bob Moskovitz: We have been mobile since 1993. We need to start looking at=
 mobility as baseline. Would almost challenge in discussion the starting poi=
nt. Take rate of mobility (how fast it can move) as distinguishing attribute=
.
>=20
> =20
>=20
> Tom Herbert: Agree. How quickly is my "device" going from one network to a=
nother. With higher rate, updates become a problem. Also get more and more u=
se cases where latency becomes an issue. Hope we could avoid relying on a di=
stributed system. Control path is critical system, keeping everything in syn=
c with low latency and secure, reliable, available. Can we design this syste=
m with applicability across different use cases.
>=20
> =20
>=20
> Mike McBride: There are applications like AR/VR that have strict requireme=
nts hopefully, that is also included in use cases.
>=20
> =20
>=20
> Tom Herbert: Yes this has been discussed in the draft.
>=20
> =20
>=20
> Padma Pillay-Esnault: Yes there different strict requirements depending on=
 the different use cases. Earlier there was a question regarding IOT use cas=
es. The requirements may vary for example depending if the type of IOT devic=
e. If it battery  operated (supposed to last 10 years) then it may have only=
 one way communication (such as a pet tracker or sensor) and may even be on n=
on-IP. In some cases proximity and context may be important too.
>=20
> =20
>=20
> 2.5. Mobility First and Global Name Resolution Service - Parishad Karimi
>=20
> https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt
>=20
> =20
>=20
> -Name based communications
>=20
>       - Name based Architectures IP =3D=3D> LISP, HIP at IETF MF and NDN (=
in academia)
>=20
>       - MF - Mobility First Background
>=20
>          - MF started in 2010 under NSF, FIA
>=20
>       - MF Protocol Layers
>=20
>           - GUID (global Unique Identifiers)
>=20
>           - We seek to use global name resolution system for resolution
>=20
>       - Name Resolution Requirements
>=20
>           - Low propagation and response Latency
>=20
>           - Storage and load scalability
>=20
>           - Security and reliability
>=20
>           - Extensibility and flexibility
>=20
>      - Structure of mapping should not be limited
>=20
>      - Why can=E2=80=99t DNS can be supported (DNS Deficiencies)
>=20
>           - TTL based caching
>=20
>           - High Mobility makes caching ineffective
>=20
>           - Static Placement of AUTH Servers
>=20
>           - Reliance on hierarchal (relating root)
>=20
>      - For MF we have looked into DMAP and GMAP and Auspice
>=20
>      - Comparison of all three systems
>=20
>      - Conclusion - We need a global mapping system with MF project
>=20
> =20
>=20
> =20
>=20
> 2.6 Conclusion & Next steps - Padma Pillay-Esnault
>=20
> Where do we want to go from here ?
>=20
> Next Steps Slide:
>=20
> - We need more collaboration from the community and looking forward for mo=
re participation on topics such as Blockchain and distributed trust, Late bi=
nding, Fast Caching, Security, DDOS protection ....
>=20
> =20
>=20
> - Let=E2=80=99s take discussions to the alias
>=20
> - Discuss the scope of work=20
>=20
> =20
>=20
> 3. Other Info
>=20
> Mailing list: IDEAS
>=20
> List address: ideas@ietf.org
>=20
> Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dideas
>=20
> To subscribe: https://www.ietf.org/mailman/listinfo/ideas
>=20
> =20
>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

--Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Discussed these 2 ID networking items w=
ith Albert and others, perhaps this is a good thread:

1.=
 MAMBO - 

Map-Assisted Measurnent Based Overlay
=
The notion here is that identity based overlays offer global (map-assisted) c=
hoices hop by hop underlays do not. One factor in making these choices can b=
e by measuring the pearson correlation coefficient (pcc) between the tunnels=
. If considered when selecting between VTEP X or VTEP Y to reach a multi hom=
e EID or a load balanced EID it can double-quadruple overall overlay capacit=
y. 

2. Lisp-Lambda -
A serverless (or virtual-applianc=
e-less) alternative to service function chaining which is hard to scale and d=
ev-ops. Its done by mapping flows at the ITR, ETR, or STR (segment) to queue=
s, and using the mapping to invoke the (cached) function on the flow queue p=
ackets rather then hair pining the packets in and out of function virtual ap=
pliances. Saves nic-ram-nic-ram... costly lifting.

=
There are reference implementations and simulations to both if theres intere=
st. 


--szb

On A=
pr 13, 2017, at 12:01 AM, Padma Pillay-Esnault <padma.ietf@gmail.com> wrote:



















 =

Please find below the minutes of the meeting.
Many thanks to our two scribes=
: Toerless Eckert and Uma Chunduri.

If you have any comments/corrections p=
lease let us know.

Thanks=


Padma

IDEAS Side
Meeting Minutes 



 



1.
Slides



Please
find below a pointer to the slides



https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=3D=
sharing


 



 



2.
Agenda 



2.1.
Introduction and Problem Statement for IDEAS  - Padma Pillay-Esnau=
lt



 



=
https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01.=
txt    



 



IDEAS Introd=
uction



 
=



IDEAS
aims to be the forum where common issues across all ID Enabled Networks can b=
e
discussed.



 Goals:



-       to create awareness



-       to present the work proposed=

in IDEAS 



-       A generic architecture that i=
s
scalable, extensible, robust, secure, and flexible for future ID enabled
networks 



-        to sollicit comments a=
nd feedback from the
community on the drafts



-       to call for new contributions<=
span>



  



Problem
Statement



Motivation:
Why Now? 



ID
solutions can address diverse areas



   =
;         IOT, M2M communication, Di=
scovery, privacy,
Latency, Virtualization



Beneficial
to have standardized common infra across ID protocols


 
=



Key
Issues Identified



Lack
of common Infrastructure cause harder to deploy a common solution E2E=

  -&n=
bsp;      No Common Management due to
disjoint nature
  -       No
Common/consistent policy framework
  -     &n=
bsp; Risk of fragmented
communication



 Identifier
Lifecycle
  -       No guidance or allocation
scheme for public IDs
  -       Agreed upon ID format and scope
in cross-domain communication
  -       Recycling IDs
  -  &n=
bsp;    Bet=
ter address merging of
networks



 Security
of Mapping Systems
  -       Secured access to the MS
  -  &=
nbsp;    da=
ta integrity,
Confidentiality, Anonymity, Access control
=
  -     =
;  DDOS attack prone<=
/span>



 
=



Proposal
-  =
;    
To investigate the opportu=
nity of a new specification effort to
address some specific problems from an ID Enabled Networks perspective.
- &=
nbsp;    
To find a common solution a=
nd infrastructure that can be shared
by current protocols and facilitate the introduction of new ID-based service=
s
while avoiding rehashing the same problems again each time a new service pop=
s
up
-=
      
Generic Resilient ID Servi=
ces (GRIDS) infrastructure with
standardized access and multiple services. 
The services include
      -       <=
/span>secured registration=

   =
   -       discovery
      -    &n=
bsp;  updates with da=
ta integrity,
      -       =
mapping and resolution
capabilities,
      -       =
define relationships between
IDs or group of IDs
      -       <=
/span>access control policy and
security
- Other Related Work/ Groups



    &nb=
sp;  - LISP (ALT, DDT)



    &nb=
sp;  - HIP uses DNS



    &nb=
sp;  - NVO3 WG



 



Questions:<=
/span>



Eric
Nordmark: What=E2=80=99s unclear is what is out of scope re. Identifier. Are=
 you
considering "what is an identifier", clearly this is not about URI,
how about IP in IP with IPsec ? Is one of them an identifier the other one a=

locator. Even LISP was not clear cut between locator/identifier as one could=
 be
routed locally.



 



Padma
Pillay-Esnault: Regarding scope, the way we thinking about this, there can b=
e
multiple scopes with multiple allocation systems. The range of solutions is s=
o
vast that it may not be appropriate to only have one solution. Plenty option=
s
of where to put it and how to put. GRIDS can be used as local, proximity,
global instance just as possible to have Private ID. 


 



Bob
Moskovitz: Concept of Identity and Identifier is important and  I have
been involved and saw some form of this for the last 20 years may be more. I=
t
really does to be discussed in the list. Definitely it needs to be fleshed o=
ut
a lot more about 



what
identifiers are, should be part of the work, tough problem with lots of
opinions.



 



 



2.2.
Requirements for Generic Resilient Identity Services (GRIDS)
in IDEAS  - Alex Clemm



 



https://=
www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt



 



-
This is the core infrastructure document which captures all requirements



   =
; 
- Talked on Core components of GRIDS



   =
; 
- GRIDS-MS, GRIDS-IS are covered



   =
;
 - Grouping and Meta data are not described yet
=



   =
; 
- Identity and Identifier definitions elaborated



   =
; 
- Talked in details about mapping services



   =
; 
- Identity related services are detailed



   =
;      
- Structured and unstructured identifiers



   =
;    
  - Grouping related services



   =
; 
- Requirement (Distribution, Redundancy, Performance and Scale..)



   =
; 
- Key performance requirements



   =
; 
- Security requirements



   =
; 
- GRIDS should be able to be deployed in private space as well as in public
domain



 



-
The naming evolved from mapping system, which was too functionally constrain=
ed.



 



Questions: <=
span>



Ravi
Ravindran: Trying to understand scope: trying to expand LISP ?<=
/span>



What
is the scope ? 



 



Alex
Clemm: No, not planning to just "expand lisp", that should be done in
LISP WG. Some of those questions are better answered in the use cases, clear=

which ones are not resolved by LISP.



 



Benjamin
Damm: How is this different from Multicast DNS ?



 



Bob
Moskovitz: I can totally implement everything in GRIDS in DNS but that would=

not be a great idea but there would be a lot of



problems,
DDoS, etc.. Think that metadata is not optional but must be called mandatory=
.
Determined by use case.



 



Alex
Clemm: Note taken



 



Dino
Farinacci:  rfc8060 defines multiple RLOC types, eg: LISP can support t=
hose.
Does this look like multicast DNS ? No, this is network layer mapping
information mapping addresses to addresses.



 



Eric
Nordmark: Multicast DNS is a local service, this is meant to be global.



 



 



2.3.
A Blockchain-based Mapping System - Jordi Paillisse 



-
Blockchain is decentralized and secured



    &nb=
sp;- Add blocks of data one after other



   =
; 
- Blockchain work flow



   =
; 
- Transaction with a data, Senders Signature and Senders Public Key to a P2P=

network



   =
; 
- Properties



   =
;    
- Decentralized, No prior trust is required



   =
;       
Data can be added but not modifiable



   =
; 
- Basic Idea



   =
;    
- Store mappings in blockchain



   =
;    
- EID prefixes are distributed to all participants



   =
; 
- Pros and Cons



   =
;    
- Infrastructure less, Decentralized, fast lookup, secure, no prior trust,
simple rekeying



   =
;    
- Cons



   =
;        
- Slow updates, costly boot strapping



   =
; 
- Comparison with LISP DDT



   =
;    
- No Infra, easy management



 
   - Issues with RPKI



   =
;     
- Anonymity (prefix linked to owner name)



   =
;     
- Revocation issues (block chain doesn=E2=80=99t use certificates)



   =
; 
- Scalability



   =
;     
- Growth similar to BGP Churn



   =
;     
- Prefix delegation + Mappings



   =
; 
- Design considerations



   =
;       
- Bitcoin is too restrictive



   =
;       
- New technologies - More scalable and more contracts


   =
; 
- Dedicated chains..



 



Questions:<=
/span>



Toerless
Eckert: what is the incentive model for participants to deploy the necessary=

infrastructure for this system ? In bitcoin, the security is achieved 
through tremendous amount of calculation, the cost for that hardware is
financed by handing out bitcoins for successful calculations. Do we need to
hand out IPv4 addresses to pay for IDEAS bitchain calculations ?



 



Jordi
Paillisee: Good question, there are some new blockchain methods with other
incentive structures. See references on last slide of the slide deck.<=
/span>



Regarding
incentive it is about security.



 



Dino
Farinacci: 



When
a new registration added (Say Jordi first and then 100000 more records added=
.
Now the entry moved to the end. This solution will have<=
/p>


complete
history of movements. Q1: can the really old stuff be chopped off. Q2: if RL=
OCs
change etc. is it not really slow when you need to look through a lot of oth=
er
newer mappings ?



Jordi
Paillisee : Q1 Answer: It can be mitigated through implementation



Q2
answer: implementation detail. Database should have latest data for all
entities, not in sequential order of evens.



 



Manu
Sporny: Blockchain developer. Referring to blockchain group (w3c-blockain
group) met in the morning, sees overlap with that work, how could we create
alignment. Whom to talk to coordinate ? 



Padma
Pillay-Esnault: Let=E2=80=99s discuss this offline.



 



2.4.
Use Cases for IDEAS - Tom Herbert



https://=
www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt



 



-
Mapping essentially a distributed key/value store



   =
;   
- Key is fixed size per mapping DB



   =
;   -
Maps "virtual address" to "physical address"



   =
;   
- Mapping table is assumed to be distributed and possibly shared for load



   =
;   
- Rate of entry is important characteristic



 



   =
;   
- Use Cases:



   =
;          
- Common Control plane



   =
;         
 - Mobility



   =
;          
- Network Virtualization (for network simplification)


   =
;          
- Heterogeneous Multi-Access (hetnet)



   =
;          
- Security



   =
;          
- Device Discovery



   =
;   
- Mobility



   =
;       
- Map entity to its current location for forwarding



   =
;       
- Variants         



   =
;           
- Encap: IP Mobility, IPIP, GTP etc..



   =
;           
- ID/LOC: LISP, ILA



   =
;       
- Properties



   =
;   
- Mobility sub-cases



   =
;       
- Within a single mobile network



   =
;       
- Mobility between mobile networks



   =
;       
- Multi-homed devices



   =
;       
- Hetnet environments



   =
;       
- Whole networks are mobile (WIFI in bus)



   =
;   
- Network Virtualization



   =
;       
- Variants



   =
;          
- Encap: Map virtual IP address to Physical address



   =
;           -
ID/LOC split



   =
;       
- Properties



   =
;          
- Mostly in DC



   =
;   
- Address resolution static tunnels



   =
;       
- Could be used as alternative means to resolve L2/L3


   =
;   
- Host Routes



   =
;       
- A network could implement virtualization simply by creating a host route



 



Questions:<=
/span>



Bob
Moskovitz: We have been mobile since 1993. We need to start looking at mobil=
ity
as baseline. Would almost challenge in discussion the starting point. Take r=
ate
of mobility (how fast it can move) as distinguishing attribute.=




 



Tom
Herbert: Agree. How quickly is my "device" going from one network to
another. With higher rate, updates become a problem. Also get more and more u=
se
cases where latency becomes an issue. Hope we could avoid relying on a
distributed system. Control path is critical system, keeping everything in s=
ync
with low latency and secure, reliable, available. Can we design this system
with applicability across different use cases.



 



Mike
McBride: There are applications like AR/VR that have strict requirements
hopefully, that is also included in use cases.



 



Tom
Herbert: Yes this has been discussed in the draft.



 



Padma
Pillay-Esnault: Yes there different strict requirements depending on the
different use cases. Earlier there was a question regarding IOT use cases. T=
he
requirements may vary for example depending if the type of IOT device. If it=

battery  operated (supposed to last 10 years) then it may have only one=

way communication (such as a pet tracker or sensor) and may even be on non-I=
P.
In some cases proximity and context may be important too.



 



2.5.
Mobility First and Global Name Resolution Service - Parishad Karimi



https://www.ietf.org/id/d=
raft-karimi-ideas-gnrs-00.txt=




 



-Name
based communications



 
    - Name based Architectures IP =3D=3D> LISP, HIP a=
t IETF
MF and NDN (in academia)



   =
;  
- MF - Mobility First Background



   =
;     
- MF started in 2010 under NSF, FIA



   =
;  
- MF Protocol Layers



   =
;      
- GUID (global Unique Identifiers)



   =
;      
- We seek to use global name resolution system for resolution



   =
;  
- Name Resolution Requirements



   =
;      
- Low propagation and response Latency



   =
;      
- Storage and load scalability



   =
;      
- Security and reliability



   =
;      
- Extensibility and flexibility



   =
; 
- Structure of mapping should not be limited



   =
; 
- Why can=E2=80=99t DNS can be supported (DNS Deficiencies)



   =
;      
- TTL based caching



   =
;      
- High Mobility makes caching ineffective



   =
;      
- Static Placement of AUTH Servers



   =
;      
- Reliance on hierarchal (relating root)



   =
; 
- For MF we have looked into DMAP and GMAP and Auspice


   =
; 
- Comparison of all three systems



   =
; 
- Conclusion - We need a global mapping system with MF project<=
/span>



 



 



2.6
Conclusion & Next steps - Padma Pillay-Esnault



Where
do we want to go from here ?



Next
Steps Slide:



-
We need more collaboration from the community and looking forward for more
participation on topics such as Blockchain and distributed trust, Late bindi=
ng,
Fast Caching, Security, DDOS protection ....



 
=



-
Let=E2=80=99s take discussions to the alias



-
Discuss the scope of work 



 
=



3.
Other Info



Mailing
list: IDEAS



List
address: ideas@ietf.org



Archive: https://mailarchive.ietf.org/arch/sear=
ch/?email_list=3Dideas<=
/span>



To
subscribe: https://www.ietf.org/mailman/listinf=
o/ideas


 





____________________=
___________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman=
/listinfo/lisp
=

--Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409--


From nobody Wed Oct 11 18:48:37 2017
Return-Path: 
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7427D1270AB; Wed, 11 Oct 2017 18:48:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Deborah Brungard 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150777291541.16832.1951800972110220056.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 18:48:35 -0700
Archived-At: 
Subject: [Ideas] Deborah Brungard's Block on charter-ietf-ideas-00-06: (with BLOCK and COMMENT)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 01:48:35 -0000

Deborah Brungard has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

As other ADs have noted, I don't think this group is ready to be chartered considering
the on-going community discussion/concerns raised and the on-going discussion
among the proponents on what they want to do.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

FWIW - similar to Spencer, I had voted Yes to send the charter to the community
for review with the comment that I was concerned the use cases were very
diverse and it was not clear if a common approach would be achievable. The
community's concerns on basic definitions (id, mapping system, privacy) and the
inability for the proponents to clarify with concise definitions, I now don't
think this is ready to be a working group.

Instead of continuing to boil the ocean on use cases to justify motivation, it
would be more helpful to focus on what specifically are the IETF requirements
for the mapping system.

The dashed list is also boiling the ocean, it needs to be more scoped, e.g. "A
security analysis of the complete system" doesn't sound appropriate for a
Framework document. The security and operational considerations need to be
defined up-front as will scope the work. All of these are listed as "some areas
that must be considered" but this is not a research group, it needs to be much
more focused for a working group.

The charter describes a target of a common infrastructure and  protocol.
It gives no indication that the work needs to take into consideration the work
already done or the expectations of how it will work with the current
applications and solutions.

And no explanation of why at this time a single solution is viewed as possible
or why a single solution is the correct answer for a diversity of use cases.



From nobody Wed Oct 11 20:22:54 2017
Return-Path: 
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048AD134320; Wed, 11 Oct 2017 20:22:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150777857299.16865.11417955671778590032.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 20:22:52 -0700
Archived-At: 
Subject: [Ideas] Ben Campbell's Abstain on charter-ietf-ideas-00-06: (with COMMENT)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 03:22:53 -0000

Ben Campbell has entered the following ballot position for
charter-ietf-ideas-00-06: Abstain

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the comments that this should have further discussion about
privacy. An additional BLOCK on that point doesn't seen necessary.

I agree with Spencer that we don't seem to be talking about _this_ charter
anymore. I think that ideally we should withdraw this from consideration, and
readdress it with a new charter proposal. So I'm ABSTAINing.



From nobody Thu Oct 12 02:29:38 2017
Return-Path: 
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 17FCE134320; Thu, 12 Oct 2017 02:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 kHX6wVxOrWim; Thu, 12 Oct 2017 02:29:29 -0700 (PDT)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 173821332CE; Thu, 12 Oct 2017 02:29:29 -0700 (PDT)
Received: by mail-wm0-x244.google.com with SMTP id i124so11507927wmf.3; Thu, 12 Oct 2017 02:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Fzj45xjJy+NKi6olubxVNBt0oILgtQPo0dEOaYVzrtY=; b=qPgI0wCW4E9R3D/T5sTSmshYSSHOeos8aA7piFZXz104nPUFWs8AsM+PsYXx3TOaP8 yspOcYR7csnv010c2fnmF4uM/ZbbRyrEULdbpVCwDXmEAXnMb/s5qLL7uixa4euLeCa/ CyLef9rWMA9tlcew1+JpyqizQ46c6BPVTuxniLPRafYmRVadGf1MjfNRZBF2+TPXT291 e1N/2l6s1KgsEgv+/SG6eMhK63Zi/OZQO+0jNEAk5xIVuoPtH5JGmNOuxRllLUY+IFt9 RVvWkMsMNnRDZaRAFXjvNoVj3JyGTHUM7jS68E7mo3+RjUfhsR/aq/SYoVjZ+f+QRu47 Ecww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Fzj45xjJy+NKi6olubxVNBt0oILgtQPo0dEOaYVzrtY=; b=RjUPSLYFRTjlZtoh495K7xakhRmfWd0rtosB9wopNOYsF1MXYLwt2DBhhrhyROG935 /AaR9+rKobtdzkyJ/dEF4l0PDQaq8OH5vLnEb5TvO4Un56cuIy699vivoRijPE7oTpG7 oLZ9QX7tP7hsXN3q1vfEHBQ2Bs0F+if6LzMbxE3Gzrz5tr1gKNDC6Vo+MSoDR9mDXz+u LRHXUvmNqiZs4xy7Gl1gm9y4T8Jda74VYa7ZBLhylLn+Es3jembtthw/ZkZpe/VqI7kI zwaT0B8spDc4JUVISs1NuDaLxjPTX6e8I8yuQeEwzwJc004Jsgh7JKLCTDzJdh7M+qrb hH2A==
X-Gm-Message-State: AMCzsaX9TTGY0UvKJ7kzqyidXsj3G+20dqViReOGoiLnSvg4qeBTXH3b c1per3yhUOqlWEnXmttMvZM=
X-Google-Smtp-Source: AOwi7QA28FEklLpFs+nvnR7k4M2l5yCpyCADoMKybRTkbbu9u8LMLFNq/52zNVYcaX+Tlxkc8USeug==
X-Received: by 10.28.151.198 with SMTP id z189mr1224760wmd.133.1507800567577;  Thu, 12 Oct 2017 02:29:27 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id w14sm9814348wmf.13.2017.10.12.02.29.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 02:29:26 -0700 (PDT)
To: Dino Farinacci , Eric Rescorla 
Cc: ideas-chairs@ietf.org, ideas@ietf.org, Alissa Cooper ,  The IESG , aretana.ietf@gmail.com
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>  
From: Stewart Bryant 
Message-ID: <88f90686-902d-ec98-2ce0-6a4c41794fb0@gmail.com>
Date: Thu, 12 Oct 2017 10:29:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 09:29:31 -0000

I agree with Dino on this.

We need to find ways to lead and not follow, even if the technology and 
the consequences are not to our taste. The market will do what makes 
economic sense even if it is not "pure". Pursuit of purity in the face 
of economics leads to irrelevance.

This seems a useful body of work to complement our traditional 
approaches to this problem.

- Stewart



On 11/10/2017 20:30, Dino Farinacci wrote:
> I am reaching out to the SD-WAN community. There has been huge investment from the VC community in overlay startups. They are all using proprietary control-planes. There is no interoperability among them. The IETF should not ignore this market and should help shape it.
>
> This is VXLAN-in-the-data-center market all over again making IETF working group nvo3 irrelevant.
>
> Mapping Databases ARE being deployed under the auspices of SDN-controllers. There are high profile user-groups that endorse the activity. It is not going away.
>
> IETF needs to lead and not follow.
>
> Dino
>
>
>> On Oct 11, 2017, at 12:20 PM, Eric Rescorla  wrote:
>>
>>
>>
>> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci  wrote:
>>> (1) The work is insufficiently motivated. The claims about the need for the
>>> mapping system and the identity management system envisioned here do not appear
>>> to be backed up by those who have developed and deployed ID/LOC separation
>>> protocols. Nor do there seem to be compelling arguments that the framework that
>>> this proposed WG would produce would be the motivator for further interoperable
>>> deployments.
>> This is simply not true. The IETF mailing lists are not finding the reach of interest that exists in the industry
>>
>> Be that as it may, the determination of consensus and justification has to be made primarily on what appears on the mailing lists and at meetings.
>>
>> -Ekr
>>
>>
>> Dino
>>
>>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Thu Oct 12 06:22:52 2017
Return-Path: 
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 2AAC8134211; Thu, 12 Oct 2017 06:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 quWWkOPd2vam; Thu, 12 Oct 2017 06:22:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEEA120720; Thu, 12 Oct 2017 06:22:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQM64246; Thu, 12 Oct 2017 13:22:34 +0000 (GMT)
Received: from LHREML502-MBS.china.huawei.com ([10.201.109.53]) by lhreml707-cah.china.huawei.com ([10.201.108.48]) with mapi id 14.03.0301.000;  Thu, 12 Oct 2017 14:22:24 +0100
From: Georgios Karagiannis 
To: Stephen Farrell 
CC: "ideas@ietf.org" , "ietf@ietf.org" , "Uma Chunduri" , "Joel M. Halpern" , Benjamin Kaduk , Jari Arkko 
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTPUTr8mvVhpJ8Xk2HRextCZOYFaLUJ9qAgAAzkoCAAA3FAIAAAIUAgAAA8wCAABzkAIAAFVQAgADQAACAAQb2wIAADNoAgAm5MzA=
Date: Thu, 12 Oct 2017 13:22:24 +0000
Message-ID: 
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>  <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com>  <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.62.107]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.59DF6C9F.0072, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce
Archived-At: 
Subject: Re: [Ideas] 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 13:22:51 -0000

SGkgU3RlcGhlbiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCBpbnNpZ2h0cyBvbiB0
aGlzIHRvcGljLCBzaW5jZSB5b3Ugd2VyZSBhbiBJRVRGIFNlY3VyaXR5IEFEIGZvciBzZXZlcmFs
IHllYXJzOw0KDQpJbiB0aGUgcHJldmlvdXMgZW1haWwgSSB3YW50ZWQgdG8gbWVudGlvbiBhIHBv
c3NpYmxlIElFVEYgYmFzZWQgc29sdXRpb24gKG9yIGFuIGVuaGFuY2VtZW50IG9mIHRoaXMpIHRo
YXQgY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCB0aGUgZHluYW1pYyBtYW5hZ2VtZW50L3JlZnJlc2hp
bmcgb2YgSWRlbnRpdGllcywgaS5lLiwgdXNpbmcgdGhlIEZlZGVyYXRpb24gY29uY2VwdCBwcm9w
b3NlZCBpbiBSRkM3ODMxLCBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNzgzMS50
eHQNCg0KDQpBbiBlbmhhbmNlZCBBQkZBQiBzb2x1dGlvbiBtaWdodCBiZSB1c2VkIHRvIHN1cHBv
cnQgdGhlIGxpZmVjeWNsZSBtYW5hZ2VtZW50IG9mIElkZW50aXRpZXMuIFRoZSBJZGVudGl0eSBw
cm92aWRlciBzdG9yZXMgdGhlIElkZW50aXRpZXMgYW5kIHRoZSBSZWx5aW5nIFBhcnR5IGNhbiBi
ZSBhIGNvbnRyb2xsZXIgdGhhdCBjb250cm9scyB3aGVuIHRoZSBJZGVudGl0aWVzIG5lZWQgdG8g
YmUgcmVmcmVzaGVkOw0KDQpUaGVzZSBlbnRpdGllcyBhbmQgdGhlaXIgcmVsYXRpb25zaGlwcyBh
cmUgaWxsdXN0cmF0ZWQgZ3JhcGhpY2FsbHkgYmVsb3cgKHRha2VuIGZyb20gUkZDNzgzMSkNCg0K
DQogICAgICAgICAgICAgLC0tLS0tLS0tLS1cICAgICAgICAgICAgICAgICAgICAgICAgLC0tLS0t
LS0tLVwNCiAgICAgICAgICAgICB8IElkZW50aXR5IHwgICAgICAgRmVkZXJhdGlvbiAgICAgICB8
IFJlbHlpbmcgfA0KICAgICAgICAgICAgIHwgUHJvdmlkZXIgKyA8LS0tLS0tLS0tLS0tLS0tLS0t
LS0+ICsgUGFydHkgICB8DQogICAgICAgICAgICAgYC0tLS0tLS0tLS0nICAgICAgICAgICAgICAg
ICAgICAgICAgJy0tLS0tLS0tLScNCiAgICAgICAgICAgICAgICAgICAgPA0KICAgICAgICAgICAg
ICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAgICAgIFwgQXV0aGVudGljYXRpb24NCiAgICAg
ICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAg
ICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXCAgKy0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBcIHwgICAgICAgICB8ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdnwgQ2xp
ZW50ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyANCg0KICAgICAgICAgICAgICAg
IEVudGl0aWVzIGFuZCBUaGVpciBSZWxhdGlvbnNoaXBzDQoNCk5vdGUgdGhhdCB0aGUgYWJvdmUg
aXMgZm9yIGZ1cnRoZXIgc3R1ZHkgYW5kIGhhcyBub3QgYmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUg
SURFQVMgcHJvcG9uZW50czsNCg0KDQpCZXN0IHJlZ2FyZHMsDQpHZW9yZ2lvcw0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllXSANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAwNiwgMjAxNyAx
MTozMiBBTQ0KVG86IEdlb3JnaW9zIEthcmFnaWFubmlzOyBVbWEgQ2h1bmR1cmk7IEpvZWwgTS4g
SGFscGVybjsgQmVuamFtaW4gS2FkdWs7IEphcmkgQXJra28NCkNjOiBpZGVhc0BpZXRmLm9yZzsg
aWV0ZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJZGVhc10gV0cgUmV2aWV3OiBJRGVudGl0eSBF
bmFibGVkIE5ldHdvcmtzIChpZGVhcykNCg0KDQpIaXlhLA0KDQpPbiAwNi8xMC8xNyAwODo0OSwg
R2Vvcmdpb3MgS2FyYWdpYW5uaXMgd3JvdGU6DQo+IEhpIGFsbCwNCj4gDQo+IFBsZWFzZSBub3Rl
IHRoYXQgSSBoYXZlIGxvb2tlZCBpbnRvIHRoZSBvdXRwdXQgb2YgdGhlIChjb25jbHVkZWQpIElF
VEYgDQo+IEFCRkFCIFdHLiBJbiBvcmRlciB0byBhbnN3ZXIgbWFueSBxdWVzdGlvbnMvY29uY2Vy
bnMgdGhhdCBoYXZlIGJlZW4gDQo+IHJhaXNlZCBkdXJpbmcgdGhlIHByZXZpb3VzIElERUFTIGRp
c2N1c3Npb25zLCBpdCBtaWdodCBiZSB1c2VmdWwgdG8gDQo+IGNvbnNpZGVyIHRoZSByZXN1bHRz
IG9mIHRoZSBJRVRGIEFCRkFCIFdHLg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dn
L2FiZmFiL2RvY3VtZW50cy8NCj4gDQo+IFdlIGNvdWxkIGluY29ycG9yYXRlIHRoZWlyIGNvbmNl
cHRzIGFib3V0IGlkZW50aXR5IGFuZCBob3cgaWRlbnRpdHkgDQo+IGNhbiBiZSBlc3RhYmxpc2hl
ZCBhbmQgbGV2ZXJhZ2VkIGluIGEgZGlzdHJpYnV0ZWQgd2F5IGFibGUgdG8gc2F0aXNmeSANCj4g
dHJ1c3QgYW5kIHByaXZhY3kgY29uY2VybnMuDQoNCkkgaGF2ZSBubyBjbHVlIGhvdyBHU1MtQVBJ
IGlzIGV2ZW4gcmVsZXZhbnQgaGVyZS4gYWJmYWIgd2FzIGEgZmluZSB0aGluZyBmb3IgSklTQyBh
bmQgZnJpZW5kcyB0byBkbyB0byBhcyBhIHdheSB0byB0cnkgYnJvYWRlbiB0aGUgYmVuZWZpdCB0
aGV5IGdvdCBmcm9tIHRoZWlyIGV4aXN0aW5nIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBzZXR1
cCwgaW4gdGhlaXIgY2FzZSBpbnZvbHZpbmcgVUsgdW5pdmVyc2l0aWVzLiBJdCBpcyBub3QgYXQg
YWxsIGNsZWFyIHRoYXQgdGhhdCB3b3VsZCBiZSBldmVuIHJlbGV2YW50IGlmIG9uZSB3YW50ZWQg
dG8gYnVpbGQgdGhlIGtpbmQgb2YgYWxsIGVuY29tcGFzc2luZyBJZFBzIGVudmlzYWdlZCBpbiB0
aGUgaWRlYXMgY2hhcnRlci9kcmFmdC4NClRoZSByZWxhdGlvbnNoaXBzIHRoYXQgdW5pdmVyc2l0
eSBhY2NvdW50IGhvbGRlcnMgaGF2ZSB3aXRoIHRoZWlyIG93biBhbmQgb3RoZXIgYWNhZGVtaWMg
aW5zdGl0dXRpb25zIGFuZCB3aXRoIGFwcGxpY2F0aW9ucyBydW5uaW5nIGluIHN1Y2ggZW52aXJv
bm1lbnRzICh0aGF0IGJlaW5nIHRoZSBwb2ludCBvZiBhYmZhYikgZG9uJ3Qgc2VlbSB0byBtZSB0
byBnZW5lcmFsaXNlIHRvIGxvd2VyIGxheWVycyBpbiBhbnkgdXNlZnVsIG1hbm5lci4NCg0KSW4g
YW55IGNhc2UsIGlmIHRoaXMgcHJvcG9zYWwgaXMgb25seSBub3cgYXQgdGhlIHBvaW50IHdoZXJl
IHlvdSdyZSBzdGFydGluZyB0byBwb25kZXIgdGhlIGJhc2ljIGFyY2hpdGVjdHVyZSB0aGVuIEkn
ZCBjb25jbHVkZSBpdCdzIG5vd2hlcmUgbmVhciByZWFkeSB0byBjaGFydGVyLg0KKEFzIHdlbGwg
YXMgYmVpbmcgYSBiYWQgaWRlYSBmcm9tIHRoZSBwcml2YWN5IFBPVjstKQ0KDQpXR3MgZm9yIHN1
Y2ggZGVjaXNpb25zIGNhbiBiZSBhIGdvb2QgcGxhbiB3aGVuIHRoZXJlJ3MgYSBmZXcga25vd24g
YXJjaGl0ZWN0dXJhbCBjaG9pY2VzIG9uIHRoZSB0YWJsZSwgYW5kIGlmIGRpZmZlcmVudCBzZXRz
IG9mIGZvbGtzIG5lZWQgYSB2ZW51ZSB0byByZWFjaCBjb25zZW5zdXMgb24gd2hpY2ggcm9hZCB0
byB0YWtlIC0gc3VnZ2VzdGluZyBhYmZhYiBhdCB0aGlzIHBvaW50IHNvdW5kcyBsaWtlIGZsb3Vu
ZGVyaW5nIGFyb3VuZCBsb29raW5nIGZvciByZWFzb25zIHRvIGV4aXN0IHRiaC4gKFNvcnJ5IHRv
IGJlIGJsdW50IGFuZCBpdCBtYXkgbm90IGJlIHRoYXQsIGJ1dCBpdCBhcHBlYXJzIHRvIGJlIHRo
YXQgdG8gbWUuKQ0KDQpTLg0KDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywgR2Vvcmdpb3MNCj4gDQo+
IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBJZGVhcyBbbWFpbHRvOmlkZWFz
LWJvdW5jZXNAaWV0Zi5vcmddIA0KPiBPbiBCZWhhbGYgT2YgVW1hIENodW5kdXJpIFNlbnQ6DQo+
IFRodXJzZGF5LCBPY3RvYmVyIDA1LCAyMDE3IDc6MDUgUE0gVG86IEpvZWwgTS4gSGFscGVybjsg
QmVuamFtaW4gDQo+IEthZHVrOyBKYXJpIEFya2tvIENjOiBpZGVhc0BpZXRmLm9yZzsgaWV0ZkBp
ZXRmLm9yZyBTdWJqZWN0OiBSZToNCj4gW0lkZWFzXSBXRyBSZXZpZXc6IElEZW50aXR5IEVuYWJs
ZWQgTmV0d29ya3MgKGlkZWFzKQ0KPiANCj4gSGkgSm9lbCwNCj4gDQo+IEluLWxpbmUgW1VtYV06
DQo+IA0KPiANCj4gQmVzdCBSZWdhcmRzLCAtLSBVbWEgQy4NCj4gDQo+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tIEZyb206IEpvZWwgTS4gSGFscGVybiANCj4gW21haWx0bzpqbWhAam9lbGhh
bHBlcm4uY29tXSBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDQsIDIwMTcgOTo0MSBQTSANCj4g
VG86IFVtYSBDaHVuZHVyaSA8dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+OyBCZW5qYW1pbiBLYWR1
ayANCj4gPGthZHVrQG1pdC5lZHU+OyBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4g
Q2M6DQo+IGlkZWFzQGlldGYub3JnOyBpZXRmQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbSWRlYXNd
IFdHIFJldmlldzoNCj4gSURlbnRpdHkgRW5hYmxlZCBOZXR3b3JrcyAoaWRlYXMpDQo+IA0KPiBZ
b3Ugc2VlbSB0byBiZSBtYWtpbmcgc29tZSB1bnN0YXRlZCBhc3N1bXB0aW9ucy4NCj4gDQo+IElm
IGJ5ICJQcm92aWRlciIgaW4gIlByb3ZpZGVyIGJhc2VkIEFVVEgiIHlvdSBtZWFuIHRoZSBsYXN0
IGhvcCANCj4gY29tbXVuaWNhdGlvbnMgc2VydmljZSBwcm92aWRlciwgdGhlbiBJIHdvdWxkIGZ1
bmRhbWVudGFsbHkgZGlzYWdyZWUgDQo+IHdpdGggeW91LiBbVW1hXTogSSBtZWFudCBJZFAgYW5k
IGl0J3MgYW4gb3J0aG9nb25hbCBkaXNjdXNzaW9uIGlmIGJvdGggDQo+IHJvbGVzIHBsYXllZCBi
eSBzYW1lIGVudGl0eS4uDQo+IA0KPiBUaGUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlIHByb3ZpZGVy
IGhhcyBubyByb2xlIGluIGNyZWF0aW5nIG9yIA0KPiBhdXRoZW50aWNhdGluZyBpZGVudGlmaWVy
cy4gIFRoZWlyIGpvYiBpcyB0byBwcm92aWRlIGxvY2F0b3JzLiBbVW1hXToNCj4gQWJzb2x1dGVs
eS4NCj4gDQo+IE5vdywgdGhvc2Ugc2VydmljZSBwcm92aWRlcnMgbWF5IGhhdmUgYW4gYXV0aGVu
dGljYXRpb24gcmVsYXRpb25zaGlwLCANCj4gYmFzZWQgb24gc29tZSBpZGVudGlmaWVycywgaW4g
b3JkZXIgdG8gcHJvdmlkZSBjb21tdW5pY2F0aW9ucyANCj4gc2VydmljZXMuIEJ1dCB0aGUgaWRl
bnRpZmllcnMgZm9yIHRoYXQgYXJlIGNvbXBsZXRlbHkgdW5jb3VwbGVkIGZyb20gDQo+IGFuZCB1
bnJlYWx0ZWQgdG8gdGhlIGlkZW50aWZpZXJzIG5lZWQgZm9yIGFuIElEIC8gTG9jYXRvciBzeXN0
ZW0uDQo+IA0KPiBZZXMsIGlmIHRoZXJlIGlzIGEgcHJvdmlkZXIgb2YgaWRlbnRpZmllcnMgKG5v
dCBhbGwgc3lzdGVtcyBldmVuIA0KPiByZXF1aXJlIHRoYXQpLA0KPiANCj4gW1VtYV06ICBZZXMs
IG1heSBiZSBub3QgYWxsIHN5c3RlbXMgcmVxdWlyZSB0aGF0LCBlc3BlY2lhbGx5IGlmIHRoaXMg
DQo+IGlzIGEgbG9jYWwgZGVwbG95bWVudC4NCj4gDQo+IHRoZW4gdGhlIHVzZXIgb2YgdGhlIGlk
ZW50aWZpZXIgbmVlZHMgdG8gaGF2ZSBhbiBhcHByb3ByaWF0ZSANCj4gcmVsYXRpb25zaGlwIHdp
dGggdGhlIHByb3ZpZGVyIG9mIHRoZSBpZGVudGlmaWVyLiBBbmQgdGhhdCBuZWVkcyB0byBiZSAN
Cj4gcmVsYXRlZCB0byB0aGUgYXV0aGVudGljYXRpb24gbmVlZGVkIHRvIHVwZGF0ZSB0aGUgbWFw
cGluZyBzeXN0ZW0uIA0KPiBbVW1hXTogWWVzLg0KPiANCj4gDQo+IEJ1dCBuZWl0aGVyIG9mIHRo
b3NlIHJlcXVpcmUgYW55dGhpbmcgb3RoZXIgdGhhbiB0aGUgaWRlbnRpZmllciBhbmQgDQo+IHN1
aXRhYmxlIGtleWluZy4gW1VtYV06IElmIGl0J3MgYSBsb2NhbCBzeXN0ZW0gc2ltcGxlIGtleWlu
ZyBpcyBlbm91Z2ggDQo+IChpbiB0aGUgZXhwZW5zZSBvZiBrZXkgbWFuYWdlbWVudCBldGMpIGFz
IGFsbCBkZXZpY2VzIG1heSBiZSBtYW5hZ2VkIA0KPiBieSB0aGUgc2FtZSBvcmcuDQo+IA0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBJZGVhcyBtYWls
aW5nIGxpc3QgDQo+IElkZWFzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vaWRlYXMNCj4gDQo+IA0KDQo=


From nobody Thu Oct 12 06:43:09 2017
Return-Path: 
X-Original-To: ideas@ietf.org
Delivered-To: ideas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95371134504; Thu, 12 Oct 2017 06:43:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, ideas-chairs@ietf.org, ideas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150781578357.16703.9419274212599252246.idtracker@ietfa.amsl.com>
Date: Thu, 12 Oct 2017 06:43:03 -0700
Archived-At: 
Subject: [Ideas] Benoit Claise's Block on charter-ietf-ideas-00-06: (with BLOCK)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 13:43:03 -0000

Benoit Claise has entered the following ballot position for
charter-ietf-ideas-00-06: Block

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



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

At this point in time, I believe the community should meet in Singapore to discuss IDEAS.
Whether this is a BoF or WG, I guess that same points would be on the table.
So use the BoF time.
The BoF objectives could be:
1. What are the privacy issues?
2. If we need to address those, how? (no need for the full solution, but potential tracks)
3. Based on 1 and 2, should we charter IDEAS?
4. If yes, work on the charter text





From nobody Thu Oct 12 08:11:37 2017
Return-Path: 
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 C5A181344C5 for ; Thu, 12 Oct 2017 08:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 P0VXi_2BwO1p for ; Thu, 12 Oct 2017 08:11:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F39D1332CA for ; Thu, 12 Oct 2017 08:11:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXN54249; Thu, 12 Oct 2017 15:11:29 +0000 (GMT)
Received: from YYZEML701-CHM.china.huawei.com (10.218.33.71) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Oct 2017 16:11:19 +0100
Received: from YYZEML702-CHM.china.huawei.com ([169.254.6.110]) by YYZEML701-CHM.china.huawei.com ([10.218.33.71]) with mapi id 14.03.0301.000; Thu, 12 Oct 2017 11:11:09 -0400
From: AshwoodsmithPeter 
To: "ideas@ietf.org" 
Thread-Topic: charter-ietf-ideas-00-06
Thread-Index: AdNDaMxCiCjOceMPTkCY5VOYBfaqMA==
Date: Thu, 12 Oct 2017 15:11:08 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E23236ECA0@YYZEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.60.144]
Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E23236ECA0YYZEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59DF8622.0034, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.6.110, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 763f81b6d62c873f5a80ae5646af0bef
Archived-At: 
Subject: [Ideas] charter-ietf-ideas-00-06
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 15:11:36 -0000

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E23236ECA0YYZEML702CHMchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree with Stuart and Dino,

Mapping systems and other massively distributed noSQL databases are the rea=
son why OTT applications exist and operate so well at such huge scales but =
they are mostly proprietary and often used for specific applications.

There is a great opportunity with 5G to bring a more modern and flexible ro=
uting architecture to life but it needs a standardized widely deployed low =
latency mapping system.

Peter Ashwood-Smith

----

Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
Stewart Bryant  Thu, 12 October 2017 09:29 UTCSho=
w header
I agree with Dino on this.

We need to find ways to lead and not follow, even if the technology and
the consequences are not to our taste. The market will do what makes
economic sense even if it is not "pure". Pursuit of purity in the face
of economics leads to irrelevance.

This seems a useful body of work to complement our traditional
approaches to this problem.

- Stewart



On 11/10/2017 20:30, Dino Farinacci wrote:
> I am reaching out to the SD-WAN community. There has been huge investment=
 from the VC community in overlay startups. They are all using proprietary =
control-planes. There is no interoperability among them. The IETF should no=
t ignore this market and should help shape it.
>
> This is VXLAN-in-the-data-center market all over again making IETF workin=
g group nvo3 irrelevant.
>
> Mapping Databases ARE being deployed under the auspices of SDN-controller=
s. There are high profile user-groups that endorse the activity. It is not =
going away.
>
> IETF needs to lead and not follow.
>
> Dino
>
>
>> On Oct 11, 2017, at 12:20 PM, Eric Rescorla ; wrote:
>>
>>
>>
>> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinacci ; wrote:
>>> (1) The work is insufficiently motivated. The claims about the need for=
 the
>>> mapping system and the identity management system envisioned here do no=
t appear
>>> to be backed up by those who have developed and deployed ID/LOC separat=
ion
>>> protocols. Nor do there seem to be compelling arguments that the framew=
ork that
>>> this proposed WG would produce would be the motivator for further inter=
operable
>>> deployments.
>> This is simply not true. The IETF mailing lists are not finding the reac=
h of interest that exists in the industry
>>
>> Be that as it may, the determination of consensus and justification has =
to be made primarily on what appears on the mailing lists and at meetings.
>>
>> -Ekr
>>
>>
>> Dino
>>
>>


--_000_7AE6A4247B044C4ABE0A5B6BF427F8E23236ECA0YYZEML702CHMchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable












Agree with Stuart and Dino,



 



Mapping systems and other massively distributed no=
SQL databases are the reason why OTT applications exist and operate so well=
 at such huge scales but they are mostly proprietary
 and often used for specific applications. 



 



There is a great opportunity with 5G to bring a mo=
re modern and flexible routing architecture to life but it needs a standard=
ized widely deployed low latency mapping system.



 



Peter Ashwood-Smith



 



----



 



Re: [Ideas] Alissa Cooper's Block on charter-ietf-=
ideas-00-06: (with BLOCK)


Stewart Bryant <stewart.bryant@gmail.com> Thu, 12 October 2017 09:29=
 UTCShow
 header 


I agree with Dino on this.


 


We need to find ways to lead and not follow, even if th=
e technology and



the consequences are not to our taste. The market will =
do what makes



economic sense even if it is not "pure". Purs=
uit of purity in the face



of economics leads to irrelevance.

 


This seems a useful body of work to complement our trad=
itional



approaches to this problem.


 


- Stewart


 


 


 


On 11/10/2017 20:30, Dino Farinacci wrote:


> I am reaching out to the SD-WAN community. There h=
as been huge investment from the VC community in overlay
 startups. They are all using proprietary control-planes. There is no inter=
operability among them. The IETF should not ignore this market and should h=
elp shape it.


> 


> This is VXLAN-in-the-data-center market all over a=
gain making IETF working group nvo3 irrelevant.


> 


> Mapping Databases ARE being deployed under the aus=
pices of SDN-controllers. There are high profile user-groups
 that endorse the activity. It is not going away.


> 


> IETF needs to lead and not follow.


> 


> Dino


> 


> 


>> On Oct 11, 2017, at 12:20 PM, Eric Rescorla &l=
t;ekr@rtfm.com>;
 wrote:


>> 


>> 


>> 


>> On Wed, Oct 11, 2017 at 12:07 PM, Dino Farinac=
ci <farinacci@gmail.com>;
 wrote:


>>> (1) The work is insufficiently motivated. =
The claims about the need for the


>>> mapping system and the identity management=
 system envisioned here do not appear


>>> to be backed up by those who have develope=
d and deployed ID/LOC separation


>>> protocols. Nor do there seem to be compell=
ing arguments that the framework that


>>> this proposed WG would produce would be th=
e motivator for further interoperable


>>> deployments.


>> This is simply not true. The IETF mailing list=
s are not finding the reach of interest that exists in the
 industry


>> 


>> Be that as it may, the determination of consen=
sus and justification has to be made primarily on what appears
 on the mailing lists and at meetings.


>> 


>> -Ekr


>> 


>> 


>> Dino


>> 


>> 


 






--_000_7AE6A4247B044C4ABE0A5B6BF427F8E23236ECA0YYZEML702CHMchi_--


From nobody Thu Oct 12 12:02:51 2017
Return-Path: 
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 F3825134575 for ; Thu, 12 Oct 2017 12:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 QH42AkrCHH-C for ; Thu, 12 Oct 2017 12:02:48 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 5456A134571 for ; Thu, 12 Oct 2017 12:02:47 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id f8so15497700qta.5 for ; Thu, 12 Oct 2017 12:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=JPrhfoJ1NGE0ooXVgBNnqy6h+udr2jBZ/bOKOEOVNvo=; b=HE/IEs1JpcpjQ7zHaGLY9/o+LYCAf0GubEw079fsrdWIBVjtZdF1tM/zkdZptcxJBl xaFPn5dZBBMVEnsd+ccDNjcy/ll/O3CW+Fwk3pGL0T3QVhs3bXtw1514fQNvGNNDDxAy djabNST2fGJdgd9XkNCiVe7cMn4AG5s1crrp51sELbm1XQIqBdN2eJ0jjVx2a6k1x1yR dgrld8WNPpE63dG2m7ak1NUApFdGHCqji8YOpOUtMzJggKVD2v6rF6NbCT25HrGb3Oum iSx8Bgg6DvOgqvwSFkDUgjuYbLS+PIGn8nek6mSOfvUjtlaN9DOWE/bxgJmhSHQ1BrKI 1HJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=JPrhfoJ1NGE0ooXVgBNnqy6h+udr2jBZ/bOKOEOVNvo=; b=r/FU+wIfi8HmxxKSJ9+79OO4qkHGw+ZVDLDz7RIdht3MlKIGWlyq+PWJXypXGRw8xp LT6PGwhN3VOQbD4Rcr5fKia26dGRKBtzBF18W3surYUbrpmuD1aUpmGa6HwJ6+tOhqAa exUYlWvPnzFm6FFp0EqjAwBWlqN/BKANFI70V46TcrecO9O3eot9h0XcCzJbhKqzFSf8 KoXwnIDBHvdWk4Y3agRIxGwz+Lpl5n1aWS44kTuS4PUxmEhYsVFBfyCH6PwFlzyyqAhZ knnADRaROv1Nwqpfj4KCw/yJME5E8fWscJ/D7028D9Zh2lF8XSYeV/GrB+fOESLxNz07 voJw==
X-Gm-Message-State: AMCzsaUvrFHHxnSAwoBxXWNW+ghdM2vdUhLZCudy/fNICH0AJ34246Iv EHIgjiiq0/5VeccTY8Sql/AuCA==
X-Google-Smtp-Source: ABhQp+RDUN3PWMQtLd+HdHkoLXhwePAgaunINr/XScNU8m6bg0yh6QiFJbKQggiR5H4N0AJ8JQGNUQ==
X-Received: by 10.37.173.67 with SMTP id l3mr331697ybe.249.1507834966014; Thu, 12 Oct 2017 12:02:46 -0700 (PDT)
Received: from [192.168.1.144] (cpe-65-190-24-92.nc.res.rr.com. [65.190.24.92]) by smtp.gmail.com with ESMTPSA id f200sm7327138ywb.23.2017.10.12.12.02.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 12:02:45 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Thu, 12 Oct 2017 15:02:44 -0400
From: Alvaro Retana 
To: 
CC: Deborah Brungard 
Message-ID: <0B355082-BEEB-48E4-A1EC-E7D8AC0A9E6F@gmail.com>
Thread-Topic: IDEAS Chartering Result
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3590665365_681494175"
Archived-At: 
Subject: [Ideas] IDEAS Chartering Result
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Oct 2017 19:02:51 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3590665365_681494175
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Dear IDEAS list:

=20

First of all, I want to thank everyone who has participated in the discussi=
on of the proposed charter over the last couple of weeks, as well as everyon=
e who has invested time in the development of related documents.

=20

Today, in our Formal Telechat, the IESG reached consensus to not approve th=
e proposed charter [1].=C2=A0 The discussion during the External Review period h=
ad a significant effect on the decision.=C2=A0 To be clear, this decision doesn=E2=
=80=99t close the door to any IDEAS-related work in the future.

=20

I want to encourage everyone to continue the work, even if informally.=C2=A0 Pa=
rt of the discussion during today=E2=80=99s call was about the possibility of hold=
ing a BoF at IETF 100 to focus on the privacy aspects.=C2=A0 I advocated against=
 it because I think that the time is too short to organize and achieve a fru=
itful discussion.=C2=A0 Instead, I suggest side meetings and informal conversati=
ons to move the common understanding forward.

=20

WG Chartering doesn=E2=80=99t have to be done during the =E2=80=9CIETF cycle=E2=80=9D, the IE=
SG doesn=E2=80=99t have to wait until right before IETF 101 to consider a revised =
charter.=C2=A0 The process can be run at any point and a WG can have interim (vi=
rtual or physical) meetings any time.=C2=A0 Please keep that in mind as you move=
 forward.

=20

=20

One of the issues mentioned during the External Review (and pointed out to =
me in private, by a couple of different people) had to do with the affiliati=
on of most of the people advocating for the WG and offering clarifications.=C2=
=A0 Due to my recent change in affiliation [2], that group now includes me.=C2=A0 =
While I have only worked at me new employer for 4 days (including today!), I=
 decided to not continue as sponsoring AD for this effort.=C2=A0 I don=E2=80=99t doubt=
 anyone=E2=80=99s integrity or intention, but I think it is important to eliminate=
 any appearance of being partial =E2=80=93 the effectiveness of the IESG depends o=
n the impartiality of its members!

=20

Deborah Brungard, who, among other things, is the Responsible AD for the li=
sp WG, has volunteered to be the point of contact for the IESG.=C2=A0 As this ef=
fort moves forward and if a new charter wants to be put out for IESG conside=
ration, please get in touch with Deborah.

=20

Thanks!

=20

Alvaro.

=20

=20

[1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/=20

[2] https://mailarchive.ietf.org/arch/msg/routing-discussion/QNH1Le1mqbFAHm=
oAwt0jQ-YsPuk=20


--B_3590665365_681494175
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Dear IDEAS list:
 
First of all, I want to thank everyone who has participated=
 in the discussion of the proposed charter over the last couple of weeks, as=
 well as everyone who has invested time in the development of related docume=
nts.
=
 
Today, in our Formal Telechat, the IESG reached consensus to not approve t=
he proposed charter [1].=C2=A0 The discussion during the External Review period =
had a significant effect on the decision.=C2=A0 To be clear, this decision doesn=
=E2=80=99t close the door to any IDEAS-related work in the future.
 
I want to encourag=
e everyone to continue the work, even if informally.=C2=A0 Part of the discussio=
n during today=E2=80=99s call was about the possibility of holding a BoF at IETF 1=
00 to focus on the privacy aspects.=C2=A0 I advocated against it because I think=
 that the time is too short to organize and achieve a fruitful discussion.=C2=A0=
 Instead, I suggest side meetings and informal conversations to move the com=
mon understanding forward.
 
WG Chartering doesn=E2=80=99t have to be done during the =E2=
=80=9CIETF cycle=E2=80=9D, the IESG doesn=E2=80=99t have to wait until right before IETF 101=
 to consider a revised charter.=C2=A0 The process can be run at any point and a =
WG can have interim (virtual or physical) meetings any time.=C2=A0 Please keep t=
hat in mind as you move forward.
 
<=
span style=3D'font-size:11.0pt'> 
One of the issues mentioned during the Exter=
nal Review (and pointed out to me in private, by a couple of different peopl=
e) had to do with the affiliation of most of the people advocating for the W=
G and offering clarifications.=C2=A0 Due to my recent change in affiliation [2],=
 that group now includes me.=C2=A0 While I have only worked at me new employer f=
or 4 days (including today!), I decided to not continue as sponsoring AD for=
 this effort.=C2=A0 I don=E2=80=99t doubt anyone=E2=80=99s integrity or intention, but I thi=
nk it is important to eliminate any appearance of being partial =E2=80=93 the effe=
ctiveness of the IESG depends on the impartiality of its members!=

 
Deborah Brung=
ard, who, among other things, is the Responsible AD for the lisp WG, has vol=
unteered to be the point of contact for the IESG.=C2=A0 As this effort moves for=
ward and if a new charter wants to be put out for IESG consideration, please=
 get in touch with Deborah.
 
Thanks!
 
<=
span style=3D'font-size:11.0pt'>Alvaro.
 
 
[1] https://datatracker.ietf.org/doc/charter-=
ietf-ideas/ballot/ 
[2] https://mailarchive.ietf.org/arch/=
msg/routing-discussion/QNH1Le1mqbFAHmoAwt0jQ-YsPuk 


--B_3590665365_681494175--



From nobody Sat Oct 14 18:43:55 2017
Return-Path: 
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 8A51F1326DF for ; Sat, 14 Oct 2017 18:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Rx7PWm5MHJ15 for ; Sat, 14 Oct 2017 18:43:51 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CA51320DC for ; Sat, 14 Oct 2017 18:43:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 90C6E6221C; Sat, 14 Oct 2017 21:43:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DYmowUHrr2ku; Sat, 14 Oct 2017 21:43:39 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3D9B162217; Sat, 14 Oct 2017 21:43:38 -0400 (EDT)
To: Alvaro Retana , ideas@ietf.org
Cc: Deborah Brungard 
References: <0B355082-BEEB-48E4-A1EC-E7D8AC0A9E6F@gmail.com>
From: Robert Moskowitz 
Message-ID: <02ca2a30-87c7-f6dd-bad5-b5014cc6b943@htt-consult.com>
Date: Sat, 14 Oct 2017 21:43:34 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <0B355082-BEEB-48E4-A1EC-E7D8AC0A9E6F@gmail.com>
Content-Type: multipart/alternative; boundary="------------ED27CE2523F758129A5F8E2D"
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] IDEAS Chartering Result
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Oct 2017 01:43:54 -0000

This is a multi-part message in MIME format.
--------------ED27CE2523F758129A5F8E2D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

In a sense the funding issue is kind of interesting.  I remember past 
efforts funded by principally one company...

In my case, I am being funded to do something I really wanted to do for 
some years, but could not get backing to do it.  So actually it is the 
other way around.

In large measure the organization does not understand privacy issues by 
what they say are challenges.  Basically we really need to rethink use 
of IP addresses.  Actually IPv6 makes this possible with multiple 
addressing to a single host really working.  In theory.

Also it is not the case that the MAC address of a mobile device is for 
traffic for that device.  More and more, mobile devices are acting as 
hotspots. So there is already a n-1 mapping starting.  We leverage that 
for ID/Loc.  Different IP address == Loc per host to start making 
associations between one communication use with another.

Please schedule a BOF so we can get the community to really think about 
what it will take for privacy in ANY workgroup in the IETF. Don't blame 
IDEAS for the IETF's failure in this area.

I will work with others for a set of presentations while we work on the 
charter.

Bob

On 10/12/2017 03:02 PM, Alvaro Retana wrote:
>
> Dear IDEAS list:
>
> First of all, I want to thank everyone who has participated in the 
> discussion of the proposed charter over the last couple of weeks, as 
> well as everyone who has invested time in the development of related 
> documents.
>
> Today, in our Formal Telechat, the IESG reached consensus to not 
> approve the proposed charter [1].  The discussion during the External 
> Review period had a significant effect on the decision.  To be clear, 
> this decision doesn’t close the door to any IDEAS-related work in the 
> future.
>
> I want to encourage everyone to continue the work, even if 
> informally.  Part of the discussion during today’s call was about the 
> possibility of holding a BoF at IETF 100 to focus on the privacy 
> aspects.  I advocated against it because I think that the time is too 
> short to organize and achieve a fruitful discussion.  Instead, I 
> suggest side meetings and informal conversations to move the common 
> understanding forward.
>
> WG Chartering doesn’t have to be done during the “IETF cycle”, the 
> IESG doesn’t have to wait until right before IETF 101 to consider a 
> revised charter.  The process can be run at any point and a WG can 
> have interim (virtual or physical) meetings any time.  Please keep 
> that in mind as you move forward.
>
> One of the issues mentioned during the External Review (and pointed 
> out to me in private, by a couple of different people) had to do with 
> the affiliation of most of the people advocating for the WG and 
> offering clarifications.  Due to my recent change in affiliation [2], 
> that group now includes me.  While I have only worked at me new 
> employer for 4 days (including today!), I decided to not continue as 
> sponsoring AD for this effort.  I don’t doubt anyone’s integrity or 
> intention, but I think it is important to eliminate any appearance of 
> being partial – the effectiveness of the IESG depends on the 
> impartiality of its members!
>
> Deborah Brungard, who, among other things, is the Responsible AD for 
> the lisp WG, has volunteered to be the point of contact for the IESG.  
> As this effort moves forward and if a new charter wants to be put out 
> for IESG consideration, please get in touch with Deborah.
>
> Thanks!
>
> Alvaro.
>
> [1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/
>
> [2] 
> https://mailarchive.ietf.org/arch/msg/routing-discussion/QNH1Le1mqbFAHmoAwt0jQ-YsPuk 
>
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


--------------ED27CE2523F758129A5F8E2D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    In a sense the funding issue is kind of interesting.  I remember
    past efforts funded by principally one company...

    

    In my case, I am being funded to do something I really wanted to do
    for some years, but could not get backing to do it.  So actually it
    is the other way around.

    

    In large measure the organization does not understand privacy issues
    by what they say are challenges.  Basically we really need to
    rethink use of IP addresses.  Actually IPv6 makes this possible with
    multiple addressing to a single host really working.  In theory.

    

    Also it is not the case that the MAC address of a mobile device is
    for traffic for that device.  More and more, mobile devices are
    acting as hotspots. So there is already a n-1 mapping starting.  We
    leverage that for ID/Loc.  Different IP address == Loc per host to
    start making associations between one communication use with
    another.

    

    Please schedule a BOF so we can get the community to really think
    about what it will take for privacy in ANY workgroup in the IETF. 
    Don't blame IDEAS for the IETF's failure in this area.

    

    I will work with others for a set of presentations while we work on
    the charter.

    

    Bob

    

    
On 10/12/2017 03:02 PM, Alvaro Retana
      wrote:

    

    

      
      
      
      
      
      

        
Dear IDEAS
            list:

        
 

        
First of
            all, I want to thank everyone who has participated in the
            discussion of the proposed charter over the last couple of
            weeks, as well as everyone who has invested time in the
            development of related documents.

        
 

        
Today, in
            our Formal Telechat, the IESG reached consensus to not
            approve the proposed charter [1].  The discussion during the
            External Review period had a significant effect on the
            decision.  To be clear, this decision doesn’t close the door
            to any IDEAS-related work in the future.

        
 

        
I want to
            encourage everyone to continue the work, even if
            informally.  Part of the discussion during today’s call was
            about the possibility of holding a BoF at IETF 100 to focus
            on the privacy aspects.  I advocated against it because I
            think that the time is too short to organize and achieve a
            fruitful discussion.  Instead, I suggest side meetings and
            informal conversations to move the common understanding
            forward.

        
 

        
WG
            Chartering doesn’t have to be done during the “IETF cycle”,
            the IESG doesn’t have to wait until right before IETF 101 to
            consider a revised charter.  The process can be run at any
            point and a WG can have interim (virtual or physical)
            meetings any time.  Please keep that in mind as you move
            forward.

        
 

        
 

        
One of the
            issues mentioned during the External Review (and pointed out
            to me in private, by a couple of different people) had to do
            with the affiliation of most of the people advocating for
            the WG and offering clarifications.  Due to my recent change
            in affiliation [2], that group now includes me.  While I
            have only worked at me new employer for 4 days (including
            today!), I decided to not continue as sponsoring AD for this
            effort.  I don’t doubt anyone’s integrity or intention, but
            I think it is important to eliminate any appearance of being
            partial – the effectiveness of the IESG depends on the
            impartiality of its members!

        
 

        
Deborah
            Brungard, who, among other things, is the Responsible AD for
            the lisp WG, has volunteered to be the point of contact for
            the IESG.  As this effort moves forward and if a new charter
            wants to be put out for IESG consideration, please get in
            touch with Deborah.

        
 

        
Thanks!

        
 

        
Alvaro.

        
 

        
 

        
[1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/
            

        
[2] https://mailarchive.ietf.org/arch/msg/routing-discussion/QNH1Le1mqbFAHmoAwt0jQ-YsPuk
            

      

      

      

      

      
_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


    

    

  


--------------ED27CE2523F758129A5F8E2D--


From nobody Sat Oct 14 18:46:55 2017
Return-Path: 
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 749C21326DF for ; Sat, 14 Oct 2017 18:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LN_p_qsQ1k3o for ; Sat, 14 Oct 2017 18:46:51 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2F11320DC for ; Sat, 14 Oct 2017 18:46:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9AEE262217; Sat, 14 Oct 2017 21:46:49 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iFdts9bJo85U; Sat, 14 Oct 2017 21:46:40 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D16E8621F8; Sat, 14 Oct 2017 21:46:39 -0400 (EDT)
From: Robert Moskowitz 
To: Alvaro Retana , ideas@ietf.org
Cc: Deborah Brungard 
References: <0B355082-BEEB-48E4-A1EC-E7D8AC0A9E6F@gmail.com> <02ca2a30-87c7-f6dd-bad5-b5014cc6b943@htt-consult.com>
Message-ID: 
Date: Sat, 14 Oct 2017 21:46:36 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <02ca2a30-87c7-f6dd-bad5-b5014cc6b943@htt-consult.com>
Content-Type: multipart/alternative; boundary="------------B0385AF006BEBD339B52396E"
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] IDEAS Chartering Result
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Oct 2017 01:46:53 -0000

This is a multi-part message in MIME format.
--------------B0385AF006BEBD339B52396E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

And IP addressing is really orthogonal to IDEAS.  IDEAS only exposes the 
deficiencies we have allowed to be deployed.

Bob

On 10/14/2017 09:43 PM, Robert Moskowitz wrote:
> In a sense the funding issue is kind of interesting.  I remember past 
> efforts funded by principally one company...
>
> In my case, I am being funded to do something I really wanted to do 
> for some years, but could not get backing to do it.  So actually it is 
> the other way around.
>
> In large measure the organization does not understand privacy issues 
> by what they say are challenges.  Basically we really need to rethink 
> use of IP addresses.  Actually IPv6 makes this possible with multiple 
> addressing to a single host really working.  In theory.
>
> Also it is not the case that the MAC address of a mobile device is for 
> traffic for that device.  More and more, mobile devices are acting as 
> hotspots. So there is already a n-1 mapping starting. We leverage that 
> for ID/Loc.  Different IP address == Loc per host to start making 
> associations between one communication use with another.
>
> Please schedule a BOF so we can get the community to really think 
> about what it will take for privacy in ANY workgroup in the IETF. 
> Don't blame IDEAS for the IETF's failure in this area.
>
> I will work with others for a set of presentations while we work on 
> the charter.
>
> Bob
>
> On 10/12/2017 03:02 PM, Alvaro Retana wrote:
>>
>> Dear IDEAS list:
>>
>> First of all, I want to thank everyone who has participated in the 
>> discussion of the proposed charter over the last couple of weeks, as 
>> well as everyone who has invested time in the development of related 
>> documents.
>>
>> Today, in our Formal Telechat, the IESG reached consensus to not 
>> approve the proposed charter [1].  The discussion during the External 
>> Review period had a significant effect on the decision.  To be clear, 
>> this decision doesn’t close the door to any IDEAS-related work in the 
>> future.
>>
>> I want to encourage everyone to continue the work, even if 
>> informally.  Part of the discussion during today’s call was about the 
>> possibility of holding a BoF at IETF 100 to focus on the privacy 
>> aspects.  I advocated against it because I think that the time is too 
>> short to organize and achieve a fruitful discussion.  Instead, I 
>> suggest side meetings and informal conversations to move the common 
>> understanding forward.
>>
>> WG Chartering doesn’t have to be done during the “IETF cycle”, the 
>> IESG doesn’t have to wait until right before IETF 101 to consider a 
>> revised charter.  The process can be run at any point and a WG can 
>> have interim (virtual or physical) meetings any time.  Please keep 
>> that in mind as you move forward.
>>
>> One of the issues mentioned during the External Review (and pointed 
>> out to me in private, by a couple of different people) had to do with 
>> the affiliation of most of the people advocating for the WG and 
>> offering clarifications.  Due to my recent change in affiliation [2], 
>> that group now includes me.  While I have only worked at me new 
>> employer for 4 days (including today!), I decided to not continue as 
>> sponsoring AD for this effort.  I don’t doubt anyone’s integrity or 
>> intention, but I think it is important to eliminate any appearance of 
>> being partial – the effectiveness of the IESG depends on the 
>> impartiality of its members!
>>
>> Deborah Brungard, who, among other things, is the Responsible AD for 
>> the lisp WG, has volunteered to be the point of contact for the 
>> IESG.  As this effort moves forward and if a new charter wants to be 
>> put out for IESG consideration, please get in touch with Deborah.
>>
>> Thanks!
>>
>> Alvaro.
>>
>> [1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/
>>
>> [2] 
>> https://mailarchive.ietf.org/arch/msg/routing-discussion/QNH1Le1mqbFAHmoAwt0jQ-YsPuk 
>>
>>
>>
>>
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


--------------B0385AF006BEBD339B52396E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    And IP addressing is really orthogonal to IDEAS.  IDEAS only exposes
    the deficiencies we have allowed to be deployed.

    

    Bob

    

    
On 10/14/2017 09:43 PM, Robert
      Moskowitz wrote:

    

    

      
      In a sense the funding issue is kind of interesting.  I remember
      past efforts funded by principally one company...

      

      In my case, I am being funded to do something I really wanted to
      do for some years, but could not get backing to do it.  So
      actually it is the other way around.

      

      In large measure the organization does not understand privacy
      issues by what they say are challenges.  Basically we really need
      to rethink use of IP addresses.  Actually IPv6 makes this possible
      with multiple addressing to a single host really working.  In
      theory.

      

      Also it is not the case that the MAC address of a mobile device is
      for traffic for that device.  More and more, mobile devices are
      acting as hotspots. So there is already a n-1 mapping starting. 
      We leverage that for ID/Loc.  Different IP address == Loc per host
      to start making associations between one communication use with
      another.

      

      Please schedule a BOF so we can get the community to really think
      about what it will take for privacy in ANY workgroup in the IETF. 
      Don't blame IDEAS for the IETF's failure in this area.

      

      I will work with others for a set of presentations while we work
      on the charter.

      

      Bob

      

      
On 10/12/2017 03:02 PM, Alvaro Retana
        wrote:

      

      

        
        
        
        
        
        

          
Dear IDEAS
              list:

          
 

          
First of
              all, I want to thank everyone who has participated in the
              discussion of the proposed charter over the last couple of
              weeks, as well as everyone who has invested time in the
              development of related documents.

          
 

          
Today, in
              our Formal Telechat, the IESG reached consensus to not
              approve the proposed charter [1].  The discussion during
              the External Review period had a significant effect on the
              decision.  To be clear, this decision doesn’t close the
              door to any IDEAS-related work in the future.

          
 

          
I want to
              encourage everyone to continue the work, even if
              informally.  Part of the discussion during today’s call
              was about the possibility of holding a BoF at IETF 100 to
              focus on the privacy aspects.  I advocated against it
              because I think that the time is too short to organize and
              achieve a fruitful discussion.  Instead, I suggest side
              meetings and informal conversations to move the common
              understanding forward.

          
 

          
WG
              Chartering doesn’t have to be done during the “IETF
              cycle”, the IESG doesn’t have to wait until right before
              IETF 101 to consider a revised charter.  The process can
              be run at any point and a WG can have interim (virtual or
              physical) meetings any time.  Please keep that in mind as
              you move forward.

          
 

          
 

          
One of the
              issues mentioned during the External Review (and pointed
              out to me in private, by a couple of different people) had
              to do with the affiliation of most of the people
              advocating for the WG and offering clarifications.  Due to
              my recent change in affiliation [2], that group now
              includes me.  While I have only worked at me new employer
              for 4 days (including today!), I decided to not continue
              as sponsoring AD for this effort.  I don’t doubt anyone’s
              integrity or intention, but I think it is important to
              eliminate any appearance of being partial – the
              effectiveness of the IESG depends on the impartiality of
              its members!

          
 

          
Deborah
              Brungard, who, among other things, is the Responsible AD
              for the lisp WG, has volunteered to be the point of
              contact for the IESG.  As this effort moves forward and if
              a new charter wants to be put out for IESG consideration,
              please get in touch with Deborah.

          
 

          
Thanks!

          
 

          
Alvaro.

          
 

          
 

          
[1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/
              

          
[2] https://mailarchive.ietf.org/arch/msg/routing-discussion/QNH1Le1mqbFAHmoAwt0jQ-YsPuk
              

        

        

        

        

        
_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


      

      

      

      

      

      
_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


    

    

  


--------------B0385AF006BEBD339B52396E--


From nobody Sun Oct 15 19:47:06 2017
Return-Path: 
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 F04AA133341 for ; Sun, 15 Oct 2017 19:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 pN0MFFl0HfnH for ; Sun, 15 Oct 2017 19:47:03 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 72C8C1320DC for ; Sun, 15 Oct 2017 19:47:03 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id q83so8080421qke.6 for ; Sun, 15 Oct 2017 19:47:03 -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=YElqTewhTyUzHThVKDfNQyVSQW6F5bQDlPmigavNwDs=; b=SwHKWyS630laeCCXpYxKljdO8DdVQBQzOZxL/+2t9siccUbXSlITdmxOrsduIFGRrB +ixHRq4F8dT7jR/rKXvUyRit+vXp7nZxDe0+cjq11Fri647OnWxbmqGy7B+3RK8mqcL2 rKMXBs+0iqwG+V+XxJiAuq7LO18G8giprZoLGrTX+VofQUN2v/bMf7SwkQoOSkyNV35Q 1wvO/Vw3MuZJzUwHvvLJqXXNGEc+HY8nDNI+RarJL81Vr1THPrsg79XZ4me4d7u/7gn3 F9199I2s1AICozZWdI7priuFVs5YMQ31wcNdlZWFf3G/DObltXnOvKdwZra60/Wd2Y3K TB4g==
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=YElqTewhTyUzHThVKDfNQyVSQW6F5bQDlPmigavNwDs=; b=MviT3zAMhf1OYPcRQ1xn9aiEb9UFxXCC0S9JZ44nS6YHn26o/I/aWHv1FTid1xtMkQ UMp9fIdD3DBd9c8agUteQ16lADN9M2WXmGV7YcueLYC72zSQb03pqfGbvArcRsSMpftG koqdooAgAcueIH4TXrvCP0VqA4avRUaVBUZ48hh8Nkdmj/fyoGSru0j91QQJt1F6LKzE F1e9m/KfHxrWfD0WQSK7zJbWTGp8fBNxTKuvLU3A0A3sxrrzpwMhdEpPyMey7ZwHnJdb R7tOf3szvU49zF6iQzUw5KUCCoTARbuAU83oseqCy2q/RJRqDmXLPrnPgYQrfV3bvkzU 0lCg==
X-Gm-Message-State: AMCzsaUSQVTIgjaR0p/UaZpzF4tpfGa4gneRHbHyZzl8wqY0Wb8rSRcj dxWvs4Bj6ef8iacnxYRIwtcjhcmV3i4eP6eMWA1vKw==
X-Google-Smtp-Source: ABhQp+QaIsm49fU5axG+AmykTov2Hoy8Wi6odOzFv/UQJrKQiOo1t1tp8O4CMUx85ddXJdRjOuh8swjw4RnJsuHoXX8=
X-Received: by 10.55.89.65 with SMTP id n62mr10834439qkb.51.1508122022421; Sun, 15 Oct 2017 19:47:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Sun, 15 Oct 2017 19:47:01 -0700 (PDT)
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com>
From: Tom Herbert 
Date: Sun, 15 Oct 2017 19:47:01 -0700
Message-ID: 
To: Alexander Clemm 
Cc: "ideas@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Oct 2017 02:47:05 -0000

On Tue, Oct 10, 2017 at 5:30 PM, Alexander Clemm
 wrote:
>
> FWIW, we have just posted an updated revision of the draft on Identity Use Cases in IDEAS:
>
> https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-02
>
> We took into account and tried to address recent discussions on the mailing list to improve on the previous version and hopefully alleviate at least some of the concerns that were raised.


Hello,

I have a comment on the definition of "identity" in IDEAS.

This draft defines identity as:

"IDy: Identity - an identifier for a communications entity that MAY be
assigned by the GRIDS-provider and that is used by the provider to
identify and authenticate the communications entity, but that is not
revealed in the packet headers."

By my count this is at least the fifth definition of identity that has
been proposed either in drafts or on the list, and this one is no more
enlightening than any of the previous definitions. First of all, this
says identity is an "identifier". Does this mean that identity is a
type of identifier per the definition of identifier above? Secondly,
this says identity is used to identify a communication entity, however
above it says an identifier "denotes information to unambiguously
identify a communications entity"-- so both of them "identify a
communications entity"... I don't see the difference.

The rest of the draft, including the picture of the relationship
between identifiers, identify, and locators, seems to imply a
potentially more useful and crisp definition of identity. As stated in
the introduction: "An IDy serves as a collection of identifiers that
are associated with the same endpoint". This could be rephrased to
define identity as "a group of identifiers that share some common
properties". Given this "group" definition of identity, then it
becomes natural to consider group policy and group operations over
sets of identifiers.

Tom


From nobody Mon Oct 16 11:18:08 2017
Return-Path: 
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 3D441134522 for ; Mon, 16 Oct 2017 11:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 5f_0-MPpckfX for ; Mon, 16 Oct 2017 11:18:05 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 6779C13451B for ; Mon, 16 Oct 2017 11:18:05 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id k31so33590620qta.6 for ; Mon, 16 Oct 2017 11:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=INvSdjas18B467TJW4tsX3kd9kOknx1fmyionrWOS8M=; b=ml/Ys7eVnwkpI/PtSGGtbS4YHFqen/i+FhCvA0N2UubVnuwR4xBv8zhKl5jlm8cbRk XAgRusXigaLalgH6jJX8csytH/1gqt49Xs/o7kVBuotX/n9NcL2KSX2mO4AX8yEBLYOs 2t4xNzlkJuBfxlb5NmRFVXoLloBb2zzN+U8fvIYOQvsIJ2RnlR5+Tdlfe91SZp2LdXm4 zHuuqtIPzlxaums7ZCf0JzQk/G3E87mCckbUstSHEPQa7T3zgnpL0cq3IAKYhv2ZLvr8 5RSefVCGfs0ApwE8b+FqLUdW/+mhX2I4ZwI1bCYkXa2YOH0CSz63LAgqkZkQlTF6skBe UN/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=INvSdjas18B467TJW4tsX3kd9kOknx1fmyionrWOS8M=; b=r47y5bOnZE25+C9ItMBTEfpPz/ksKLHzqk+O8rR/9pTndZPXPZKdg7AhsNoaKoolNa bZWifSI0XgEGQvXtXBWxfIcB3ltDjXtqmBINzs6kmhQj9rc+NHDiq/8V8uS5L8hcfrmS 8rYN5MQ3Mi1vHFpF+w1xs6mAmgm1SVKfbKWOgFM7VEqLrb1poMx+mN4o9/N1jKeDYkDK iGv1Oneu/yrnakBfW4L8UEQTooNjLKiofa2Gb8tqaMjOQfBu/PUKKsVJfaXV3SPYoErF l79e8gT435MmHHh/tO2j8W7GSaJr7KQFO7osMPPI+6PrSPGPqvgiRuxq1HnUbCIE+L2R c+vg==
X-Gm-Message-State: AMCzsaV6wmCeFCBfsa8KUlzC1EcrPW8p55sIEAhV5RhNX4QkZmZoESOM St0kPJD9NkuJN8G4PI1oeRphvugAyqlemAI06a/k00nJ
X-Google-Smtp-Source: AOwi7QDC1TIAjkdYloRkOIstmlcDpBfIyqXjkkCPiKH1gYluQcTV/ES7g3fuXWakc7lVUzKORZ/nRqnlH8CTMGN+I7M=
X-Received: by 10.237.60.46 with SMTP id t43mr15592708qte.294.1508177884161; Mon, 16 Oct 2017 11:18:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Mon, 16 Oct 2017 11:18:03 -0700 (PDT)
From: Tom Herbert 
Date: Mon, 16 Oct 2017 11:18:03 -0700
Message-ID: 
To: ideas@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Oct 2017 18:18:07 -0000

I reviewed the revised draft and have included comments on various
sections below.

Overall, this draft is better than the previous ones, but I think
still needs some clarifications and more discussion about security.


Abstract:

"IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity
(IDy) into networking."

Identity is already used in networking. For instance, identity is part
of X.509 certs exchanged in TLS for instance. Maybe this should be
"into the networking layer"

2. Acronyms

"Communications Entity" I don't think this term is necessary to
define, "node" should suffice. A node is any endpoint of communication
and can be real or virtual. An identifier is a non-topological
identification of a node.

"Locator" definition really doesn't say way a locator is.

"MS" Why "traditional"? Can't this be just be any mapping server? The
acronym also conflict the use of MS in section 1 which denotes it to
be Mapping System not Mapping Server. Mapping system should probably
have its own acronym also.

3. Uses for IDy

"IDy representing the communications entity enables authentication
(AUTH) with the mapping and Identity services infrastructure."

It is not clear to me what the relationship between IDy and other
forms of identity that are commonly used for authentication. For
instance, if a mobile network operator choose might chose to control
access to all of its devices based on certificates, X.509 identity,
and TLS/DTLS. In this case, does IDy == X.509 identity?

"IDy provides de-anonymization for various data plane ephemeral
Identifiers, if required, and enables resolution of"

What does "if required" mean here. Is this referring to the
requirements of framework, or per use case, per deployment, etc...

"which communications entity is behind these identifiers for
legitimate users (entities itselfin some cases)."

I'm don't know what "legitimate users" means. Maybe it means authorized parties?

I think the most critical use case isn't described here. It is in
mobility where a devices may have many thousands of identifiers
assigned to it. When the device moves, all the identifiers must move
with it and want this to be performed in one operation in the
infrastructure. Without the ability to perform a group operation,
identifier-locator might not be able to scale. Today this is done by
virtue of moving a device prefix, but device prefixes do not have
reasonable privacy or security properties (see ongoing discussion in
v6 ops about host prefix assignment and privacy ramifications).

4. IDy in IDEAS

"An IDy identifies a Communications Entity."

So does an IDf :-)

The diagram is good and makes the relationships clear.

5.1 Privacy

"This allows a communications entity to reveal "who it is" to the
receiver if it chooses to do so,"

Since the receiver already knows all of it's identifiers, it can
inform other parties it's communicating "who it is" using its side
channel communications. I don't see why the mapping system needs to be
involved here.

Also, several places in this document seem to assume that
communicating endpoints have implemented identifier-locator protocols
and can access a common mapping system. I think that is much more the
exception than the rule. Consider that a mobile network may implement
mapping system to facilitate mobility of devices in the network. A
communicating node on the Internet should not care about that and
identifier-locator must be transparent to the communication.

5.2.  Unified Policies

I think it's easier to say that identity provides an equivalent
(although more flexible) mechanism for network policy than prefix
based policy mechanisms in use today.

"some requesting groups may receive an empty response from GRIDS
Infrastructure for IDfs referring to a certain IDy"

This is very weak security. All it takes is one node leaking
information to the rest of the world to break this. The fact that
someone keeps their name out of the phone book doesn't mean they won't
get barraged by sales calls.

5.2.1 Access Restriction Policies

The first paragraph here is redundant with end of previous paragraph.

"A communications entity may define that it wants to communicate only
with certain other entities.  To achieve this, a communications entity
MAY define a rule regarding who can request and obtain its IDf."

I think I'm missing something basic here. If host A wants to talk to
host B, is the idea that host A first needs to know the identity of
host B? And then uses the identity to lookup identifiers? If so, how
does host A find the identity of host B? DNS? What if host A is a
random node on the Internet and host B is node in a mobile network
that has the mapping system for which host A doesn't talk to?

"The GRIDS Infrastructure with may be a means to find a set of
communications entities with certain associated metadata, provided
that they have agreed to be searchable"

So being searchable is opt-in then? What does it mean that they
"agreed to be searchable"? Is this a box that is an end user checks
off when they sign up for carrier service?

5.4.  Access Security and Manageability

"There are various possible scenarios on why a long-lived IDfs by a
communications entity has to be withdrawn."

The phrase "long-lived" is ill-defined. Not just in this document, but
I've noticed this popping up in other WGs. The obvious problem is that
there is no common definition of the time it takes something to be
long-lived. Someone might say a day, another an hour, a minute, a
second, ten milliseconds etc. In identifier-locator, it may be that a
node wants to use a different identifier in every connection it
creates which is the best privacy it can get.

The only reasonable answer may be that the node being assigned
identifiers or identities controls their life cycle. So from the POV
of the mapping system there doesn't need to be any distinction between
long-lived and ephemeral. Persistent identifiers may be needed for
servers.

5.5.  Delay-Tolerant Networking (DTN)

I'm not sure why this is relevant here. Proxies already exist for
various purposes, the use of identifier-locator shouldn't have any
bearing on that.

8.  Security Considerations

This section needs to be expanded considerably.

Statements like "This abstraction gives significant security
benefits..." aren't very interesting in this section-- this should be
in the motivation section. What is interesting in this section are the
potential security risks, threats, and mitigations that are created by
the proposal.

"The IDy concept and data stored in GRIDS are intended for routing and
forwarding purposes only."

This is intent, but it's pretty obvious that the system could be used
for other purposes. For instance, a mapping system could be used to
track the geo-location of the device. There may be legal justification
for that, but nevertheless, this is an example if the data being used
in GRIDs for purposes other than routing or forwarding.

"They are in no way intended and must not be used to store human-
identifiable information, personal identifiers, and the like."

A major use case of identifier-locator protocols is going to be
mobility in public wireless networks. The preponderance of devices in
these networks today are personal devices that typically have a 1-1
correspondence between the device and a human user. So if a such a
device is being tracked, then the human behind them is being tracked.
If someone has access to the mapping system information (e.g. they can
get all the IDfs for an IDy) the only missing piece of information
needed to track individuals is the name of the user. Since identifiers
are public, all they need to do is match one identifier to a name.
This is easily done of they have access to an authenticated service
where users login-- there are many examples of such services and there
are companies that already implement this sort tracking within their
own services. What we don't want is a means to enable tracking across
the whole Internet.

The tracking problem is two fold.

First, if I know all of the identifiers for a user's device then a I
can track the users network communications by IP address. This can be
done in the network with packet traces or server logs.

Secondly, if I have access to the locator information for a device
then I will know the physical location of the device with pretty good
accuracy. Since, the there's a human user of the device then I know
where they are. This by the way is why I don't think end user devices
should ever participate in identifier-locator protocols, doing so
would make is easy to determine locations of individuals and hence
enable stalkers everywhere!

All of this is not to say the data should not be collected, to the
contrary it is probably a necessity to make identifier-locator
protocols useful and improve privacy. It's also true, that this sort
of data (like device to location) must already be maintained in mobile
networks, and there are already services that are designed to track
location of humans (e.g. Life360). The controversy arises from the
fact that this is being introduced into IP (much broader use case),
its defining defining a potentially common standard means to access
the data, and unlike services seems to be opt-out more than opt-in
from users POV.

I suggest that the security section acknowledges that the data in a
mapping system is HIGHLY sensitive and then highlight appropriately
strong methods to protect the data and limit the scope of
dissemination.

Tom


From nobody Mon Oct 16 15:38:18 2017
Return-Path: 
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 A083F133205 for ; Mon, 16 Oct 2017 15:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iTW_D8f2mX1P for ; Mon, 16 Oct 2017 15:38:15 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E3213458D for ; Mon, 16 Oct 2017 15:38:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXW04401; Mon, 16 Oct 2017 22:38:13 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Oct 2017 23:38:12 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001;  Mon, 16 Oct 2017 15:38:04 -0700
From: Alexander Clemm 
To: Tom Herbert 
CC: "ideas@ietf.org" 
Thread-Topic: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
Thread-Index: AdNCJ759WLnyNEFUS8OQ3qb/AaAdvwEO/iGAABpkCnA=
Date: Mon, 16 Oct 2017 22:38:03 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67C5@sjceml521-mbx.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.45]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E534D5.00C8, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: afa5e0de417254cf2e08e7fc38f7ab7a
Archived-At: 
Subject: Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Oct 2017 22:38:16 -0000

SGVsbG8gVG9tLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuICBTb21lIGJyaWVmIHJl
cGxpZXMsIGlubGluZSwgPEFMRVg+DQoNCi0tLSBBbGV4DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29t
XQ0KDQoNCi4uLg0KDQo+IEJ5IG15IGNvdW50IHRoaXMgaXMgYXQgbGVhc3QgdGhlIGZpZnRoIGRl
ZmluaXRpb24gb2YgaWRlbnRpdHkgdGhhdCBoYXMgYmVlbg0KPiBwcm9wb3NlZCBlaXRoZXIgaW4g
ZHJhZnRzIG9yIG9uIHRoZSBsaXN0LCBhbmQgdGhpcyBvbmUgaXMgbm8gbW9yZSBlbmxpZ2h0ZW5p
bmcNCj4gdGhhbiBhbnkgb2YgdGhlIHByZXZpb3VzIGRlZmluaXRpb25zLiBGaXJzdCBvZiBhbGws
IHRoaXMgc2F5cyBpZGVudGl0eSBpcyBhbg0KPiAiaWRlbnRpZmllciIuIERvZXMgdGhpcyBtZWFu
IHRoYXQgaWRlbnRpdHkgaXMgYSB0eXBlIG9mIGlkZW50aWZpZXIgcGVyIHRoZQ0KPiBkZWZpbml0
aW9uIG9mIGlkZW50aWZpZXIgYWJvdmU/IFNlY29uZGx5LCB0aGlzIHNheXMgaWRlbnRpdHkgaXMg
dXNlZCB0byBpZGVudGlmeSBhDQo+IGNvbW11bmljYXRpb24gZW50aXR5LCBob3dldmVyIGFib3Zl
IGl0IHNheXMgYW4gaWRlbnRpZmllciAiZGVub3Rlcw0KPiBpbmZvcm1hdGlvbiB0byB1bmFtYmln
dW91c2x5IGlkZW50aWZ5IGEgY29tbXVuaWNhdGlvbnMgZW50aXR5Ii0tIHNvIGJvdGggb2YNCj4g
dGhlbSAiaWRlbnRpZnkgYSBjb21tdW5pY2F0aW9ucyBlbnRpdHkiLi4uIEkgZG9uJ3Qgc2VlIHRo
ZSBkaWZmZXJlbmNlLg0KDQo8QUxFWD4gV2VsbCwgdGhlIGRlZmluaXRpb25zIGFyZSBldm9sdmlu
ZyBhcyB3ZSBob3BlIHRvIGdldCB0aGVtIG1vcmUgY29uY2lzZS4gIA0KDQpGb3IgdGhhdCBkZWZp
bml0aW9uOiB5ZXMsIHRoZSBJRHkgaXMgYW4gaWRlbnRpZmllci4gIEhvd2V2ZXIsIGl0IGlzIGEg
InNwZWNpYWwiIGlkZW50aWZpZXIgaW4gdGhhdCBpdCBpcyBuZXZlciByZXZlYWxlZCBpbiBwYWNr
ZXQgaGVhZGVyLCBub3IgcmV2ZWFsZWQgdG8gYW5vdGhlciBjb21tdW5pY2F0aW9ucyBlbnRpdHkg
LSB1bmxpa2UgYW4gSURmLiAgDQoNCkFub3RoZXIgYXNwZWN0IHRoYXQgaXMgbWVudGlvbmVkIGlu
IHRoZSBkcmFmdCwgYnV0IG5vdCBpbiB0aGUgZGVmaW5pdGlvbnMgKGFuZCB3ZSBuZWVkIHRvIHJl
dmlzaXQgdGhpcykgY29uY2VybnMgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gYSAic2Vjb25kLW9y
ZGVyIiAoSURmKSBhbmQgYSAiZmlyc3Qtb3JkZXIiIGlkZW50aWZpZXIgKElEeSkgLSB0aGUgc2Vj
b25kLW9yZGVyIHBvdGVudGlhbGx5IGJlIHJvb3RlZCAvIGFuY2hvcmVkIGluIHRoZSBmaXJzdC1v
cmRlciBpZGVudGlmaWVyLCByZXNwZWN0aXZlbHkgdGhlIGZpcnN0LW9yZGVyIGlkZW50aWZpZXIg
cmVhbGx5IGRlbm90aW5nIGEgY29sbGVjdGlvbiAvIGdyb3VwaW5nIG9mICJzZWNvbmQtb3JkZXIi
IGlkZW50aWZpZXJzLiAgQXMgbWVudGlvbmVkIGJlbG93LCBwZXJoYXBzICB3ZSBzaG91bGQgYWRk
IGFuIGFydGljdWxhdGlvbiBzdWNoIGFzICIiIEFuIElEeSBzZXJ2ZXMgYXMgYSBjb2xsZWN0aW9u
IG9mIGlkZW50aWZpZXJzIHRoYXQgYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBlbmRwb2lu
dCINCg0KPC9BTEVYPg0KDQo+IA0KPiBUaGUgcmVzdCBvZiB0aGUgZHJhZnQsIGluY2x1ZGluZyB0
aGUgcGljdHVyZSBvZiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4NCj4gaWRlbnRpZmllcnMsIGlk
ZW50aWZ5LCBhbmQgbG9jYXRvcnMsIHNlZW1zIHRvIGltcGx5IGEgcG90ZW50aWFsbHkgbW9yZSB1
c2VmdWwNCj4gYW5kIGNyaXNwIGRlZmluaXRpb24gb2YgaWRlbnRpdHkuIEFzIHN0YXRlZCBpbiB0
aGUgaW50cm9kdWN0aW9uOiAiQW4gSUR5IHNlcnZlcw0KPiBhcyBhIGNvbGxlY3Rpb24gb2YgaWRl
bnRpZmllcnMgdGhhdCBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIGVuZHBvaW50Ii4gVGhp
cw0KPiBjb3VsZCBiZSByZXBocmFzZWQgdG8gZGVmaW5lIGlkZW50aXR5IGFzICJhIGdyb3VwIG9m
IGlkZW50aWZpZXJzIHRoYXQgc2hhcmUNCj4gc29tZSBjb21tb24gcHJvcGVydGllcyIuIEdpdmVu
IHRoaXMgImdyb3VwIiBkZWZpbml0aW9uIG9mIGlkZW50aXR5LCB0aGVuIGl0DQo+IGJlY29tZXMg
bmF0dXJhbCB0byBjb25zaWRlciBncm91cCBwb2xpY3kgYW5kIGdyb3VwIG9wZXJhdGlvbnMgb3Zl
ciBzZXRzIG9mDQo+IGlkZW50aWZpZXJzLg0KPiANCg0KPEFMRVg+IEkgYW0gZ2xhZCB0aGF0IHlv
dSBmaW5kIHRoYXQgdGhpbmdzIGFyZSBnZXR0aW5nIGNyaXNwZXIgLSBJIHRha2UgaXQgdG8gbWVh
biB0aGF0IHdlIGFyZSBvbiB0aGUgcmlnaHQgcGF0aCEgIFllcywgdGhpcyBpcyB3aGF0IHdlIG5l
ZWQgdG8gcmVmbGVjdCAvIGluY29ycG9yYXRlLiAgSG93ZXZlciwgSSB0aGluayB3ZSBuZWVkIHRv
IGJlIG1vcmUgc3BlY2lmaWMgdGhhbiBqdXN0IHNheWluZyBJRHkgcmVmZXJzIHRvIGEgZ3JvdXBp
bmcgaW4gdGhlIGdlbmVyYWwgc2Vuc2UgLSBpdCByZWZlcnMgdG8gYSBncm91cGluZyBvZiBpZGVu
dGlmaWVycyB0aGF0IHJlZmVyIHRvIHRoZSBzYW1lIGNvbW11bmljYXRpb25zIGVudGl0eSAgKHRo
YXQgaXMgdGhlIHByb3BlcnR5IHRoZXkgaGF2ZSBpbiBjb21tb24sIEkgZ3Vlc3MpIA0KPC9BTEVY
Pg0KDQo=


From nobody Mon Oct 16 16:45:55 2017
Return-Path: 
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 6DA66132403 for ; Mon, 16 Oct 2017 16:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 E0NNhKwIjYEO for ; Mon, 16 Oct 2017 16:45:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1120126BF0 for ; Mon, 16 Oct 2017 16:45:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQT62231; Mon, 16 Oct 2017 23:45:47 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 00:45:45 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Mon, 16 Oct 2017 16:45:40 -0700
From: Alexander Clemm 
To: Tom Herbert , "ideas@ietf.org" 
Thread-Topic: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
Thread-Index: AQHTRqsmf6hiJoT45EuGVllvxpgrQ6LnEYrw
Date: Mon, 16 Oct 2017 23:45:39 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67EC@sjceml521-mbx.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59E544AC.0069, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 29cc6edb49b2ff973d78594621a6b010
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Oct 2017 23:45:53 -0000

Hi Tom,

Thank you for your review!  A couple of replies inline, 

Thanks
--- Alex

> -----Original Message-----
> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Tom Herbert
> Sent: Monday, October 16, 2017 11:18 AM
> To: ideas@ietf.org
> Subject: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
>=20
> I reviewed the revised draft and have included comments on various
> sections below.
>=20
> Overall, this draft is better than the previous ones, but I think still n=
eeds
> some clarifications and more discussion about security.

 Glad to hear we are making progress!=20


>=20
>=20
> Abstract:
>=20
> "IDentity-EnAbled networkS (IDEAS) introduce the concept of Identity
> (IDy) into networking."
>=20
> Identity is already used in networking. For instance, identity is part of=
 X.509
> certs exchanged in TLS for instance. Maybe this should be "into the
> networking layer"

 Sure, makes sense

>=20
> 2. Acronyms
>=20
> "Communications Entity" I don't think this term is necessary to define,
> "node" should suffice. A node is any endpoint of communication and can be
> real or virtual. An identifier is a non-topological identification of a n=
ode.

 Node is fine with me, but given the "pickiness" of some of the feedb=
ack, we decided to be more specific at least in this revision.  I would not=
 mind to change it back to just "node'.=20


>=20
> "Locator" definition really doesn't say way a locator is.
>=20
> "MS" Why "traditional"? Can't this be just be any mapping server? The
> acronym also conflict the use of MS in section 1 which denotes it to be
> Mapping System not Mapping Server. Mapping system should probably have
> its own acronym also.
>=20

 Sure


> 3. Uses for IDy
>=20
> "IDy representing the communications entity enables authentication
> (AUTH) with the mapping and Identity services infrastructure."
>=20
> It is not clear to me what the relationship between IDy and other forms o=
f
> identity that are commonly used for authentication. For instance, if a mo=
bile
> network operator choose might chose to control access to all of its devic=
es
> based on certificates, X.509 identity, and TLS/DTLS. In this case, does I=
Dy =3D=3D
> X.509 identity?
>=20

 If the operator chooses to, they could do it.  It depends on the use=
 case / specific requirements. =20

> "IDy provides de-anonymization for various data plane ephemeral
> Identifiers, if required, and enables resolution of"
>=20
> What does "if required" mean here. Is this referring to the requirements =
of
> framework, or per use case, per deployment, etc...
>=20

 It refers to the use case
=20

> "which communications entity is behind these identifiers for legitimate u=
sers
> (entities itselfin some cases)."
>=20
> I'm don't know what "legitimate users" means. Maybe it means authorized
> parties?

 Authorized and authenticated.  It enables the resolution only when t=
he communications entity agrees to reveal an identifier under which it is k=
nown (note: this would not be an IDy). =20

As we tried to explain, the purpose is to let a receiver know who the sourc=
e of a packet is, if the source is identified by an anonymized ID to obfusc=
ate who it is to outside observers but not the receiver.  The sender still =
has the choice to obfuscate who it is even to the receiver, but then it is =
up to the receiver to decide if it wants to accept a packet from a source w=
ho does not want to reveal who it is.



>=20
> I think the most critical use case isn't described here. It is in mobilit=
y where a
> devices may have many thousands of identifiers assigned to it. When the
> device moves, all the identifiers must move with it and want this to be
> performed in one operation in the infrastructure. Without the ability to
> perform a group operation, identifier-locator might not be able to scale.
> Today this is done by virtue of moving a device prefix, but device prefix=
es do
> not have reasonable privacy or security properties (see ongoing discussio=
n in
> v6 ops about host prefix assignment and privacy ramifications).

 Thank you for your suggestion.  We shall look into adding it.  Can w=
e come back to you to help us craft some text? =20
=20

>=20
> 4. IDy in IDEAS
>=20
> "An IDy identifies a Communications Entity."
>=20
> So does an IDf :-)
>=20
> The diagram is good and makes the relationships clear.
>=20
> 5.1 Privacy
>=20
> "This allows a communications entity to reveal "who it is" to the receive=
r if it
> chooses to do so,"
>=20
> Since the receiver already knows all of it's identifiers, it can inform o=
ther
> parties it's communicating "who it is" using its side channel communicati=
ons. I
> don't see why the mapping system needs to be involved here.

 This can do more!  Yes, the receiver knows its identifiers, but the =
sender may know only a publicly known identifier.  When sending a packet, a=
n observer can still tell that someone is sending packets to this particula=
r receiver. =20

The "side channel" can be used to indicate to the sender which identifier i=
t should use for the receiver.  This can be an entirely anonymized IDf, all=
owing to obfuscate both sender and receiver.   The side channel can be prov=
ided through GRIDS, and the IDf to use can be provided to the sender in res=
ponse to a map resolution request along with the locator of the receiver. =
=20

=20

>=20
> Also, several places in this document seem to assume that communicating
> endpoints have implemented identifier-locator protocols and can access a
> common mapping system. I think that is much more the exception than the
> rule. Consider that a mobile network may implement mapping system to
> facilitate mobility of devices in the network. A communicating node on th=
e
> Internet should not care about that and identifier-locator must be
> transparent to the communication.
>=20
> 5.2.  Unified Policies
>=20
> I think it's easier to say that identity provides an equivalent (although=
 more
> flexible) mechanism for network policy than prefix based policy mechanism=
s
> in use today.
>=20
 Sure, thanks
=20

> "some requesting groups may receive an empty response from GRIDS
> Infrastructure for IDfs referring to a certain IDy"
>=20
> This is very weak security. All it takes is one node leaking information =
to the
> rest of the world to break this. The fact that someone keeps their name o=
ut
> of the phone book doesn't mean they won't get barraged by sales calls.

 Do you have a better suggestion?  I do think this is an improvement =
over the situation that we have today.  Also, remember that we could quickl=
y "cycle through" IDfs, in case IDfs do get compromised over time. =20
=20

>=20
> 5.2.1 Access Restriction Policies
>=20
> The first paragraph here is redundant with end of previous paragraph.
>=20
> "A communications entity may define that it wants to communicate only wit=
h
> certain other entities.  To achieve this, a communications entity MAY def=
ine a
> rule regarding who can request and obtain its IDf."
>=20
> I think I'm missing something basic here. If host A wants to talk to host=
 B, is
> the idea that host A first needs to know the identity of host B? And then=
 uses
> the identity to lookup identifiers? If so, how does host A find the ident=
ity of
> host B? DNS? What if host A is a random node on the Internet and host B i=
s
> node in a mobile network that has the mapping system for which host A
> doesn't talk to?
>=20

=20
If A wants to talk to B, A needs to have some way to refer to B.  For this,=
 he needs to know an IDf.  This can be a well-known IDf under which B is co=
mmonly known.  It is NOT the IDy.  B's  IDy is only used by the mapping sys=
tem / GRIDs to "group" the IDfs that belong to B, and for B to authenticate=
 itself to GRIDS/  mapping system. =20

To the second part of your question, we are not looking at Inter-GRIDS scen=
arios. =20
=20

> "The GRIDS Infrastructure with may be a means to find a set of
> communications entities with certain associated metadata, provided that
> they have agreed to be searchable"
>=20
> So being searchable is opt-in then? What does it mean that they "agreed t=
o
> be searchable"? Is this a box that is an end user checks off when they si=
gn up
> for carrier service?

 Yes, it is opt-in.  The idea is that the node or its owner will have=
 the ability to control who can discover or track their locator.  Today the=
re is no such control.  This is why botnets are so successful. =20
=20


>=20
> 5.4.  Access Security and Manageability
>=20
> "There are various possible scenarios on why a long-lived IDfs by a
> communications entity has to be withdrawn."
>=20
> The phrase "long-lived" is ill-defined. Not just in this document, but I'=
ve
> noticed this popping up in other WGs. The obvious problem is that there i=
s no
> common definition of the time it takes something to be long-lived. Someon=
e
> might say a day, another an hour, a minute, a second, ten milliseconds et=
c. In
> identifier-locator, it may be that a node wants to use a different identi=
fier in
> every connection it creates which is the best privacy it can get.
>=20
> The only reasonable answer may be that the node being assigned identifier=
s
> or identities controls their life cycle. So from the POV of the mapping s=
ystem
> there doesn't need to be any distinction between long-lived and ephemeral=
.
> Persistent identifiers may be needed for servers.

  Sure.  "Long-lived" is relative.  In the context and for the purpos=
es of this document, it refers to a time duration that is long enough for a=
n IDf to be "known".  In many cases, you do want other entities to be able =
to find you, so you need to give them something that they can use to refer =
to you. =20


>=20
> 5.5.  Delay-Tolerant Networking (DTN)
>=20
> I'm not sure why this is relevant here. Proxies already exist for various
> purposes, the use of identifier-locator shouldn't have any bearing on tha=
t.

 Thanks, note taken
=20

>=20
> 8.  Security Considerations
>=20
> This section needs to be expanded considerably.
>=20
> Statements like "This abstraction gives significant security benefits..."=
 aren't
> very interesting in this section-- this should be in the motivation secti=
on.
> What is interesting in this section are the potential security risks, thr=
eats, and
> mitigations that are created by the proposal.
>=20
> "The IDy concept and data stored in GRIDS are intended for routing and
> forwarding purposes only."
>=20
> This is intent, but it's pretty obvious that the system could be used for=
 other
> purposes. For instance, a mapping system could be used to track the geo-
> location of the device. There may be legal justification for that, but
> nevertheless, this is an example if the data being used in GRIDs for purp=
oses
> other than routing or forwarding.
>=20
> "They are in no way intended and must not be used to store human-
> identifiable information, personal identifiers, and the like."
>=20
> A major use case of identifier-locator protocols is going to be mobility =
in
> public wireless networks. The preponderance of devices in these networks
> today are personal devices that typically have a 1-1 correspondence betwe=
en
> the device and a human user. So if a such a device is being tracked, then=
 the
> human behind them is being tracked.
> If someone has access to the mapping system information (e.g. they can ge=
t
> all the IDfs for an IDy) the only missing piece of information needed to =
track
> individuals is the name of the user. Since identifiers are public, all th=
ey need
> to do is match one identifier to a name.
> This is easily done of they have access to an authenticated service where
> users login-- there are many examples of such services and there are
> companies that already implement this sort tracking within their own
> services. What we don't want is a means to enable tracking across the who=
le
> Internet.
>=20
> The tracking problem is two fold.
>=20
> First, if I know all of the identifiers for a user's device then a I can =
track the
> users network communications by IP address. This can be done in the
> network with packet traces or server logs.
>=20
> Secondly, if I have access to the locator information for a device then I=
 will
> know the physical location of the device with pretty good accuracy. Since=
, the
> there's a human user of the device then I know where they are. This by th=
e
> way is why I don't think end user devices should ever participate in iden=
tifier-
> locator protocols, doing so would make is easy to determine locations of
> individuals and hence enable stalkers everywhere!
>=20
> All of this is not to say the data should not be collected, to the contra=
ry it is
> probably a necessity to make identifier-locator protocols useful and impr=
ove
> privacy. It's also true, that this sort of data (like device to location)=
 must
> already be maintained in mobile networks, and there are already services
> that are designed to track location of humans (e.g. Life360). The controv=
ersy
> arises from the fact that this is being introduced into IP (much broader =
use
> case), its defining defining a potentially common standard means to acces=
s
> the data, and unlike services seems to be opt-out more than opt-in from
> users POV.
>=20
> I suggest that the security section acknowledges that the data in a mappi=
ng
> system is HIGHLY sensitive and then highlight appropriately strong method=
s
> to protect the data and limit the scope of dissemination.

 Yes, clearly there is more for the section.  At this point, we are l=
imiting this to the statement that we are aware that there are security ram=
ifications and that more work is needed, referring to the work that is char=
tered separately.   As this part gets developed further, we will expand on =
this section, and we will certainly indicate that mapping data is security =
and privacy sensitive.  At the same time, one aspect to point out is that m=
any of the security that have been pointed out are not introduced by or eve=
n specific to IDEAS, but are artefacts of today's data planes, in many case=
s not secured at all.=20


>=20
> Tom
>=20
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Mon Oct 16 17:31:58 2017
Return-Path: 
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 BACD1126BF0 for ; Mon, 16 Oct 2017 17:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GDR4Q57WiC59 for ; Mon, 16 Oct 2017 17:31:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1ED13202D for ; Mon, 16 Oct 2017 17:31:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQT65936; Tue, 17 Oct 2017 00:31:52 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 01:31:49 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Mon, 16 Oct 2017 17:31:42 -0700
From: Uma Chunduri 
To: "ideas@ietf.org" 
Thread-Topic: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
Thread-Index: AQHTRqsmzhTtyxc/w0CsYMOotXbfdqLnLFXQ
Date: Tue, 17 Oct 2017 00:31:41 +0000
Message-ID: <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.246.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59E54F78.0108, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 29cc6edb49b2ff973d78594621a6b010
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 00:31:58 -0000

Thx for the feedback on this version. I saw Alex's responses - some more of=
 it below.

--
Uma C.

----

	>I think the most critical use case isn't described here. It is in mobilit=
y where a devices may have many thousands of identifiers assigned to it. Wh=
en the device moves, all the identifiers must move
               > with it and want this to be performed in one operation in =
the infrastructure. Without the ability to perform a group operation, ident=
ifier-locator might not be able to scale. Today this is done by virtue=20
               >of moving a device prefix, but device prefixes do not have =
reasonable privacy or security properties (see ongoing discussion in v6 ops=
 about host prefix assignment and privacy ramifications).
[Uma]: Yes.

	>The phrase "long-lived" is ill-defined. Not just in this document, but I'=
ve noticed this popping up in other WGs. The obvious problem is that there =
is no common definition of the time it takes something to be long-lived.=20
                >Someone might say a day, another an hour, a minute, a seco=
nd, ten milliseconds etc. In identifier-locator, it may be that a node want=
s to use a different identifier in every connection it creates which is the=
 best privacy it can get.
[Uma]:  It's relative. This is not new and not introduced in IDEAS.  This i=
s nothing but HIT in HIP or EID in LISP (which are used for location resolu=
tion today).  The context of this usage is to differentiate from the one ti=
me anonymous identifiers used in the data plane.. Can clarify further.

	>This by the way is why I don't think end user devices should ever partici=
pate in identifier-locator protocols...
 [Uma]: You  are making a pretty broad statement here.  Which device uses t=
his is orthogonal to IDEAS.   We have a host based solution (ID/LOC) HIP  a=
nd a network based solution LISP.



From nobody Mon Oct 16 18:25:00 2017
Return-Path: 
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 4B0491323B8 for ; Mon, 16 Oct 2017 18:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 1XxTyzEuZHSv for ; Mon, 16 Oct 2017 18:24:57 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 3372F12ECEC for ; Mon, 16 Oct 2017 18:24:57 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id b15so165711qkg.9 for ; Mon, 16 Oct 2017 18:24:57 -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:content-transfer-encoding; bh=cU2nXvKrDl9IgeiFUz6t/BG2XdHB7bKcMqMcuxbSB+s=; b=AVknvQQ74MNb8jaY1IAc+M9IvilGBLxjYsoXAaY9pFO0i2YKRAEJUEfQFMpvSH7EYz E5gUYgbRv1JeIf5jPV+ay+Vw215Ac6Esncz7ushbpZ0BPPvQvHz0vpM11T2wheGdb45l i0lEN1PiwRPI+GZ7eo344hEXytvi5YlgNXeYmjtZKjrAzmXq9B+rwd1APRnaR2lS6OAZ +ZPTBFUtS7GzS6gcO2AzEQIQI+383bFcSOvn6LpezTWmpWLpTdWKb6+gjqcSsx6Kfs5v Dq22PCH4oaZpT/tYjOgClAaZGPK1crL0HtGe3kX26l4rUd5eQWGUabSkSrsDFUOjaFjw 2xkw==
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:content-transfer-encoding; bh=cU2nXvKrDl9IgeiFUz6t/BG2XdHB7bKcMqMcuxbSB+s=; b=jYQ1PPuxS9KYbRojnXn/qRn5c6T0cKZWmvLQi1RXO/Uh75cAmB7RSt0DL1SlSHTZkm nqOb1gQjgOyjM474mVRlYTVopp/2oO5xrfxi7iHjIay8N0ck3s3GryWnAFXkKXvKW7DY AOTlFEnKqtXOXown1WPmDqGqiz5OALdBEdDOC9YanSn9GcFTx+A9aSTzjsIMGBFfMsvX wnQUaZmuguR5ELGHHUod79FWCEsHGTizje8MOr72ASNj/Vx3qVePqu1WC6p+/I876Phn SzfF8ZIbKCfVFSCRK+gw/AXgfKWKodmlPoOvYrzmpTa+BX00Qidvk7rtYoN+rFjpX/4T QCDg==
X-Gm-Message-State: AMCzsaVsUyR7Hcks5jl4lWX1/w52qUMxcYLLOE8dQRk89IRrvJG0HIGL 7jWT6B9QAhayDdElgDK7JIvSL4UqEuD2PLQNhmOrhPbD
X-Google-Smtp-Source: ABhQp+QimqK1fpGiwpHuk7fgjjLmCFAFzsuBr9dpZDbmxpeWzpnN3kI3fq9dXZG0B5ZxW9B1BWOdsKQImAyH5sTozlo=
X-Received: by 10.55.89.65 with SMTP id n62mr15115258qkb.51.1508203496016; Mon, 16 Oct 2017 18:24:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Mon, 16 Oct 2017 18:24:55 -0700 (PDT)
In-Reply-To: <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com>
References:  <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com>
From: Tom Herbert 
Date: Mon, 16 Oct 2017 18:24:55 -0700
Message-ID: 
To: Uma Chunduri 
Cc: "ideas@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 01:24:59 -0000

On Mon, Oct 16, 2017 at 5:31 PM, Uma Chunduri  wro=
te:
> Thx for the feedback on this version. I saw Alex's responses - some more =
of it below.
>
> --
> Uma C.
>
> ----
>
>         >I think the most critical use case isn't described here. It is i=
n mobility where a devices may have many thousands of identifiers assigned =
to it. When the device moves, all the identifiers must move
>                > with it and want this to be performed in one operation i=
n the infrastructure. Without the ability to perform a group operation, ide=
ntifier-locator might not be able to scale. Today this is done by virtue
>                >of moving a device prefix, but device prefixes do not hav=
e reasonable privacy or security properties (see ongoing discussion in v6 o=
ps about host prefix assignment and privacy ramifications).
> [Uma]: Yes.
>
>         >The phrase "long-lived" is ill-defined. Not just in this documen=
t, but I've noticed this popping up in other WGs. The obvious problem is th=
at there is no common definition of the time it takes something to be long-=
lived.
>                 >Someone might say a day, another an hour, a minute, a se=
cond, ten milliseconds etc. In identifier-locator, it may be that a node wa=
nts to use a different identifier in every connection it creates which is t=
he best privacy it can get.
> [Uma]:  It's relative. This is not new and not introduced in IDEAS.  This=
 is nothing but HIT in HIP or EID in LISP (which are used for location reso=
lution today).  The context of this usage is to differentiate from the one =
time anonymous identifiers used in the data plane.. Can clarify further.
>
>         >This by the way is why I don't think end user devices should eve=
r participate in identifier-locator protocols...
>  [Uma]: You  are making a pretty broad statement here.  Which device uses=
 this is orthogonal to IDEAS.   We have a host based solution (ID/LOC) HIP =
 and a network based solution LISP.
>
Uma,

This problem I highlighted would only exist on public networks where
end user devices are not under complete control of the
infrastructure-- i.e. smart phones on a public carrier network. In a
private data center for instance, where all hosts can be controlled,
there is no issue in running identifier-locator on hosts and that in
fact is a common deployment of network virtualization.

The exploit I'm conjecturing would work like this:

* Suppose that a UE (e.g. a smartphone) participating in an
identifier/locator protocols is hacked.
* The only thing the hacker does is to tap all packets sent or
received on wireless network interface.
* In order to be able to tap packets all a user needs to do is "root"
the Android device (that is gain root access) and then run tcpdump.
This is not difficult to do, there are instructions on the web how to
set this up.
* Once tcpdump is running, the hacker can now see the locators of
destinations the device is sending packets and can easily correlate
those packets to the higher level communications. It can also derive
their device's locator by looking at received packets.
* The hacker can then just drive around sending traffic between two
devices in their car. From this, they can create a geo map of
locators. The granularity of this map is the granularity of the
locators. Presumably, locators might refer to eNodeBs, so smaller
cells yield more accurate locator to physical location mapping.
* Given that one hacker can do this, then thousands will do it and web
sites will spring up that provide locator geo maps in a mash up.
* Efforts to obfuscate or rotate identifiers does not help much here.
Obfuscation complicates routing in the network such that translations
need to happen anyway. Periodic rotation of locators is defeated if
there are enough devices doing the mapping to keep the maps up to
date.
* The net effect is that this enables stalkers. An individual simply
initiates a communication with their target. For instance, this could
be a chat or phone call. If in doing this the locators for the device
belonging to the target are made visible to the hacker, then the
physical location of the target can be deduced using the locator geo
maps described above to the accuracy of the locator to physical world
maps.

It's true this may be orthogonal to the design of a mapping system or
identifier-locator protocol, however it does illustrate the dangers of
not adequately protecting sensitive information. Anyone who works at
companies like Apple and Google that regularly collect device
geo-location can vouch that it is among the most sensitive of all the
PII they collect. Accordingly, they implement extremely strong access
controls to the point that even that only a tiny number of employees
can directly access the data.

Tom

>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Tue Oct 17 11:03:16 2017
Return-Path: 
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 855F2133070 for ; Tue, 17 Oct 2017 11:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 XfCPjAnZjp0y for ; Tue, 17 Oct 2017 11:03:08 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 5C04A133052 for ; Tue, 17 Oct 2017 11:03:08 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id z50so5443149qtj.4 for ; Tue, 17 Oct 2017 11:03:08 -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:content-transfer-encoding; bh=NPLzgcLyP3osf+tEREXLhmMtnTRn81aq0ZwqALEI4X0=; b=MHDobh58+p7xSA8OxNa843DO+lgdY1dIvG0kJFr9jSvTgz8x6jDnzUVuZF8qWAYIWb pyDm9fR3STAWc6gR/Y3NyTErmZfYlIa4pS+2maDtE6O8613P044NxD9xztSrNDMZzGAQ p2jRyUrF0tKCaERpxEs0unvrBYdRtXAgE9FGxRsJVpeJ1+Z+zV7IlC8cArGYWp42H3gP uRVyfc8tMdrwfq+emDTO+XyBYQ/hppVVq6Hrqiewba/u9lY0VKRynLRyECdUOC21LOQF BF7Q6MwRUwkxDmhdLl+WqaqguLVnD9sAhi1Ns+wGr1KY4joW9bOsw/4GlH/T9QHZyPmT Z5qg==
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:content-transfer-encoding; bh=NPLzgcLyP3osf+tEREXLhmMtnTRn81aq0ZwqALEI4X0=; b=Qv1THtHy/Qla6MXmSQ0BkgbnSzYgQsgehl6JA0RMc+1IdNzr/q7OrgfPwhyJhLQpf5 le+/CQxxZKhLuiq2SVQgYajnrnITL/wTu51j4XTYlJ6MMuADPZz7Kp6xq1Oxfh7Eaz1M oV9n3YCICSwbmOtknXHKgjoB3jeTEDzZ0j335+7GPUmYbJ8N9Sgt5c7Lvpp3eN6YXKrS eKLQgCqUSe6ilZzLOXJmlgLBB55n6hFvt4Gp3VIzVzpKLePORb8F5yV/csc8xsDKKuUd bKOQx38mhdTXScIRW0WMcA8uBY6nMLyS4gR3qxgML/JoABWXAdUqOFsFg92zRrfx2gLl i2Rg==
X-Gm-Message-State: AMCzsaUV+xoX+QnSXsXTo5Ow1+4bZMqzI0m2X/NTL9COSuW0McOy25gV VjQbgn7FYiIZnSShwrlUWrjN+mrdUpX723IjLRyt1Q==
X-Google-Smtp-Source: AOwi7QCpMDLgnrxWZQ+ju9N1krHL+BZCyinhCXQ/FkBcVm1+uva3GyTKvN2rLDt0sMOIO1py0ajpI8VhqghatYB/lMQ=
X-Received: by 10.200.47.85 with SMTP id k21mr21398550qta.286.1508263387430; Tue, 17 Oct 2017 11:03:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 11:03:06 -0700 (PDT)
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67C5@sjceml521-mbx.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67C5@sjceml521-mbx.china.huawei.com>
From: Tom Herbert 
Date: Tue, 17 Oct 2017 11:03:06 -0700
Message-ID: 
To: Alexander Clemm 
Cc: "ideas@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 18:03:14 -0000

On Mon, Oct 16, 2017 at 3:38 PM, Alexander Clemm
 wrote:
> Hello Tom,
>
> Thank you for your comments.  Some brief replies, inline, 
>
> --- Alex
>
>> -----Original Message-----
>> From: Tom Herbert [mailto:tom@herbertland.com]
>
>
> ...
>
>> By my count this is at least the fifth definition of identity that has b=
een
>> proposed either in drafts or on the list, and this one is no more enligh=
tening
>> than any of the previous definitions. First of all, this says identity i=
s an
>> "identifier". Does this mean that identity is a type of identifier per t=
he
>> definition of identifier above? Secondly, this says identity is used to =
identify a
>> communication entity, however above it says an identifier "denotes
>> information to unambiguously identify a communications entity"-- so both=
 of
>> them "identify a communications entity"... I don't see the difference.
>
>  Well, the definitions are evolving as we hope to get them more con=
cise.
>
> For that definition: yes, the IDy is an identifier.  However, it is a "sp=
ecial" identifier in that it is never revealed in packet header, nor reveal=
ed to another communications entity - unlike an IDf.
>
> Another aspect that is mentioned in the draft, but not in the definitions=
 (and we need to revisit this) concerns the distinction between a "second-o=
rder" (IDf) and a "first-order" identifier (IDy) - the second-order potenti=
ally be rooted / anchored in the first-order identifier, respectively the f=
irst-order identifier really denoting a collection / grouping of "second-or=
der" identifiers.  As mentioned below, perhaps  we should add an articulati=
on such as "" An IDy serves as a collection of identifiers that are associa=
ted with the same endpoint"
>
> 
>
>>
>> The rest of the draft, including the picture of the relationship between
>> identifiers, identify, and locators, seems to imply a potentially more u=
seful
>> and crisp definition of identity. As stated in the introduction: "An IDy=
 serves
>> as a collection of identifiers that are associated with the same endpoin=
t". This
>> could be rephrased to define identity as "a group of identifiers that sh=
are
>> some common properties". Given this "group" definition of identity, then=
 it
>> becomes natural to consider group policy and group operations over sets =
of
>> identifiers.
>>
>
>  I am glad that you find that things are getting crisper - I take i=
t to mean that we are on the right path!  Yes, this is what we need to refl=
ect / incorporate.  However, I think we need to be more specific than just =
saying IDy refers to a grouping in the general sense - it refers to a group=
ing of identifiers that refer to the same communications entity  (that is t=
he property they have in common, I guess)
> 
>
Alex,

In my design for ILA I have defined "identifier group" as "a set of
identifiers or other identifier groups that share some common
properties". This is derived from the traditional idea of groups of
objects that is seen in other areas of networking and computer
science. Identifier groups can be created for ad hoc purposes and is
distinct from identity. Being a member of group does not imply that an
identity is derived from the group. The analogy is that you and I may
have subscribed to IDEAS mailing list which is a group, but I don't
think that the mailing list gives me an identity nor that you and I
now share an identity by virtue of subscribing to the same list.
Identity might be a possible property of an identifier group I
suppose, but I would need to think that through and have a better
understanding of exactly what identity is.

Anyway, I have a draft on the concept of identifier groups and some
examples of their use if anyone is interested.

Tom


From nobody Tue Oct 17 13:59:00 2017
Return-Path: 
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 5330213219F for ; Tue, 17 Oct 2017 13:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Yi8zOD142llS for ; Tue, 17 Oct 2017 13:58:57 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5781320B5 for ; Tue, 17 Oct 2017 13:58:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXY08443; Tue, 17 Oct 2017 20:58:55 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 21:58:54 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001;  Tue, 17 Oct 2017 13:58:51 -0700
From: Alexander Clemm 
To: Tom Herbert 
CC: "ideas@ietf.org" 
Thread-Topic: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
Thread-Index: AdNCJ759WLnyNEFUS8OQ3qb/AaAdvwEO/iGAABpkCnAAN+T9AAAIyVOQ
Date: Tue, 17 Oct 2017 20:58:50 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6CC8@sjceml521-mbx.china.huawei.com>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA89A5@sjceml521-mbx.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB67C5@sjceml521-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.110]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.59E66F0F.0030, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: afa5e0de417254cf2e08e7fc38f7ab7a
Archived-At: 
Subject: Re: [Ideas] New revision posted on draft-ccm-ideas-identity-use-cases
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 20:58:58 -0000

SGkgVG9tLA0KT25lIHJlc3BvbnNlIGF0IHRoZSBib3R0b20sIGJlbG93DQpUaGFua3MNCi0tLSBB
bGV4DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVG9tIEhlcmJlcnQg
W21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE3
LCAyMDE3IDExOjAzIEFNDQo+IFRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBo
dWF3ZWkuY29tPg0KPiBDYzogaWRlYXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJZGVhc10g
TmV3IHJldmlzaW9uIHBvc3RlZCBvbiBkcmFmdC1jY20taWRlYXMtaWRlbnRpdHktdXNlLQ0KPiBj
YXNlcw0KPiANCj4gT24gTW9uLCBPY3QgMTYsIDIwMTcgYXQgMzozOCBQTSwgQWxleGFuZGVyIENs
ZW1tDQo+IDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gSGVsbG8gVG9t
LA0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiAgU29tZSBicmllZiByZXBs
aWVzLCBpbmxpbmUsIDxBTEVYPg0KPiA+DQo+ID4gLS0tIEFsZXgNCj4gPg0KPiA+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBo
ZXJiZXJ0bGFuZC5jb21dDQo+ID4NCj4gPg0KPiA+IC4uLg0KPiA+DQo+ID4+IEJ5IG15IGNvdW50
IHRoaXMgaXMgYXQgbGVhc3QgdGhlIGZpZnRoIGRlZmluaXRpb24gb2YgaWRlbnRpdHkgdGhhdA0K
PiA+PiBoYXMgYmVlbiBwcm9wb3NlZCBlaXRoZXIgaW4gZHJhZnRzIG9yIG9uIHRoZSBsaXN0LCBh
bmQgdGhpcyBvbmUgaXMgbm8NCj4gPj4gbW9yZSBlbmxpZ2h0ZW5pbmcgdGhhbiBhbnkgb2YgdGhl
IHByZXZpb3VzIGRlZmluaXRpb25zLiBGaXJzdCBvZiBhbGwsDQo+ID4+IHRoaXMgc2F5cyBpZGVu
dGl0eSBpcyBhbiAiaWRlbnRpZmllciIuIERvZXMgdGhpcyBtZWFuIHRoYXQgaWRlbnRpdHkNCj4g
Pj4gaXMgYSB0eXBlIG9mIGlkZW50aWZpZXIgcGVyIHRoZSBkZWZpbml0aW9uIG9mIGlkZW50aWZp
ZXIgYWJvdmU/DQo+ID4+IFNlY29uZGx5LCB0aGlzIHNheXMgaWRlbnRpdHkgaXMgdXNlZCB0byBp
ZGVudGlmeSBhIGNvbW11bmljYXRpb24NCj4gPj4gZW50aXR5LCBob3dldmVyIGFib3ZlIGl0IHNh
eXMgYW4gaWRlbnRpZmllciAiZGVub3RlcyBpbmZvcm1hdGlvbiB0bw0KPiA+PiB1bmFtYmlndW91
c2x5IGlkZW50aWZ5IGEgY29tbXVuaWNhdGlvbnMgZW50aXR5Ii0tIHNvIGJvdGggb2YgdGhlbQ0K
PiAiaWRlbnRpZnkgYSBjb21tdW5pY2F0aW9ucyBlbnRpdHkiLi4uIEkgZG9uJ3Qgc2VlIHRoZSBk
aWZmZXJlbmNlLg0KPiA+DQo+ID4gPEFMRVg+IFdlbGwsIHRoZSBkZWZpbml0aW9ucyBhcmUgZXZv
bHZpbmcgYXMgd2UgaG9wZSB0byBnZXQgdGhlbSBtb3JlDQo+IGNvbmNpc2UuDQo+ID4NCj4gPiBG
b3IgdGhhdCBkZWZpbml0aW9uOiB5ZXMsIHRoZSBJRHkgaXMgYW4gaWRlbnRpZmllci4gIEhvd2V2
ZXIsIGl0IGlzIGEgInNwZWNpYWwiDQo+IGlkZW50aWZpZXIgaW4gdGhhdCBpdCBpcyBuZXZlciBy
ZXZlYWxlZCBpbiBwYWNrZXQgaGVhZGVyLCBub3IgcmV2ZWFsZWQgdG8NCj4gYW5vdGhlciBjb21t
dW5pY2F0aW9ucyBlbnRpdHkgLSB1bmxpa2UgYW4gSURmLg0KPiA+DQo+ID4gQW5vdGhlciBhc3Bl
Y3QgdGhhdCBpcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LCBidXQgbm90IGluIHRoZSBkZWZpbml0
aW9ucw0KPiAoYW5kIHdlIG5lZWQgdG8gcmV2aXNpdCB0aGlzKSBjb25jZXJucyB0aGUgZGlzdGlu
Y3Rpb24gYmV0d2VlbiBhICJzZWNvbmQtDQo+IG9yZGVyIiAoSURmKSBhbmQgYSAiZmlyc3Qtb3Jk
ZXIiIGlkZW50aWZpZXIgKElEeSkgLSB0aGUgc2Vjb25kLW9yZGVyIHBvdGVudGlhbGx5DQo+IGJl
IHJvb3RlZCAvIGFuY2hvcmVkIGluIHRoZSBmaXJzdC1vcmRlciBpZGVudGlmaWVyLCByZXNwZWN0
aXZlbHkgdGhlIGZpcnN0LW9yZGVyDQo+IGlkZW50aWZpZXIgcmVhbGx5IGRlbm90aW5nIGEgY29s
bGVjdGlvbiAvIGdyb3VwaW5nIG9mICJzZWNvbmQtb3JkZXIiIGlkZW50aWZpZXJzLg0KPiBBcyBt
ZW50aW9uZWQgYmVsb3csIHBlcmhhcHMgIHdlIHNob3VsZCBhZGQgYW4gYXJ0aWN1bGF0aW9uIHN1
Y2ggYXMgIiIgQW4NCj4gSUR5IHNlcnZlcyBhcyBhIGNvbGxlY3Rpb24gb2YgaWRlbnRpZmllcnMg
dGhhdCBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lDQo+IGVuZHBvaW50Ig0KPiA+DQo+ID4g
PC9BTEVYPg0KPiA+DQo+ID4+DQo+ID4+IFRoZSByZXN0IG9mIHRoZSBkcmFmdCwgaW5jbHVkaW5n
IHRoZSBwaWN0dXJlIG9mIHRoZSByZWxhdGlvbnNoaXANCj4gPj4gYmV0d2VlbiBpZGVudGlmaWVy
cywgaWRlbnRpZnksIGFuZCBsb2NhdG9ycywgc2VlbXMgdG8gaW1wbHkgYQ0KPiA+PiBwb3RlbnRp
YWxseSBtb3JlIHVzZWZ1bCBhbmQgY3Jpc3AgZGVmaW5pdGlvbiBvZiBpZGVudGl0eS4gQXMgc3Rh
dGVkDQo+ID4+IGluIHRoZSBpbnRyb2R1Y3Rpb246ICJBbiBJRHkgc2VydmVzIGFzIGEgY29sbGVj
dGlvbiBvZiBpZGVudGlmaWVycw0KPiA+PiB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNh
bWUgZW5kcG9pbnQiLiBUaGlzIGNvdWxkIGJlIHJlcGhyYXNlZA0KPiA+PiB0byBkZWZpbmUgaWRl
bnRpdHkgYXMgImEgZ3JvdXAgb2YgaWRlbnRpZmllcnMgdGhhdCBzaGFyZSBzb21lIGNvbW1vbg0K
PiA+PiBwcm9wZXJ0aWVzIi4gR2l2ZW4gdGhpcyAiZ3JvdXAiIGRlZmluaXRpb24gb2YgaWRlbnRp
dHksIHRoZW4gaXQNCj4gPj4gYmVjb21lcyBuYXR1cmFsIHRvIGNvbnNpZGVyIGdyb3VwIHBvbGlj
eSBhbmQgZ3JvdXAgb3BlcmF0aW9ucyBvdmVyIHNldHMNCj4gb2YgaWRlbnRpZmllcnMuDQo+ID4+
DQo+ID4NCj4gPiA8QUxFWD4gSSBhbSBnbGFkIHRoYXQgeW91IGZpbmQgdGhhdCB0aGluZ3MgYXJl
IGdldHRpbmcgY3Jpc3BlciAtIEkNCj4gPiB0YWtlIGl0IHRvIG1lYW4gdGhhdCB3ZSBhcmUgb24g
dGhlIHJpZ2h0IHBhdGghICBZZXMsIHRoaXMgaXMgd2hhdCB3ZQ0KPiA+IG5lZWQgdG8gcmVmbGVj
dCAvIGluY29ycG9yYXRlLiAgSG93ZXZlciwgSSB0aGluayB3ZSBuZWVkIHRvIGJlIG1vcmUNCj4g
PiBzcGVjaWZpYyB0aGFuIGp1c3Qgc2F5aW5nIElEeSByZWZlcnMgdG8gYSBncm91cGluZyBpbiB0
aGUgZ2VuZXJhbA0KPiA+IHNlbnNlIC0gaXQgcmVmZXJzIHRvIGEgZ3JvdXBpbmcgb2YgaWRlbnRp
ZmllcnMgdGhhdCByZWZlciB0byB0aGUgc2FtZQ0KPiA+IGNvbW11bmljYXRpb25zIGVudGl0eSAg
KHRoYXQgaXMgdGhlIHByb3BlcnR5IHRoZXkgaGF2ZSBpbiBjb21tb24sIEkNCj4gPiBndWVzcykg
PC9BTEVYPg0KPiA+DQo+IEFsZXgsDQo+IA0KPiBJbiBteSBkZXNpZ24gZm9yIElMQSBJIGhhdmUg
ZGVmaW5lZCAiaWRlbnRpZmllciBncm91cCIgYXMgImEgc2V0IG9mIGlkZW50aWZpZXJzDQo+IG9y
IG90aGVyIGlkZW50aWZpZXIgZ3JvdXBzIHRoYXQgc2hhcmUgc29tZSBjb21tb24gcHJvcGVydGll
cyIuIFRoaXMgaXMNCj4gZGVyaXZlZCBmcm9tIHRoZSB0cmFkaXRpb25hbCBpZGVhIG9mIGdyb3Vw
cyBvZiBvYmplY3RzIHRoYXQgaXMgc2VlbiBpbiBvdGhlcg0KPiBhcmVhcyBvZiBuZXR3b3JraW5n
IGFuZCBjb21wdXRlciBzY2llbmNlLiBJZGVudGlmaWVyIGdyb3VwcyBjYW4gYmUgY3JlYXRlZA0K
PiBmb3IgYWQgaG9jIHB1cnBvc2VzIGFuZCBpcyBkaXN0aW5jdCBmcm9tIGlkZW50aXR5LiBCZWlu
ZyBhIG1lbWJlciBvZiBncm91cA0KPiBkb2VzIG5vdCBpbXBseSB0aGF0IGFuIGlkZW50aXR5IGlz
IGRlcml2ZWQgZnJvbSB0aGUgZ3JvdXAuIFRoZSBhbmFsb2d5IGlzIHRoYXQNCj4geW91IGFuZCBJ
IG1heSBoYXZlIHN1YnNjcmliZWQgdG8gSURFQVMgbWFpbGluZyBsaXN0IHdoaWNoIGlzIGEgZ3Jv
dXAsIGJ1dCBJDQo+IGRvbid0IHRoaW5rIHRoYXQgdGhlIG1haWxpbmcgbGlzdCBnaXZlcyBtZSBh
biBpZGVudGl0eSBub3IgdGhhdCB5b3UgYW5kIEkgbm93DQo+IHNoYXJlIGFuIGlkZW50aXR5IGJ5
IHZpcnR1ZSBvZiBzdWJzY3JpYmluZyB0byB0aGUgc2FtZSBsaXN0Lg0KPiBJZGVudGl0eSBtaWdo
dCBiZSBhIHBvc3NpYmxlIHByb3BlcnR5IG9mIGFuIGlkZW50aWZpZXIgZ3JvdXAgSSBzdXBwb3Nl
LCBidXQgSQ0KPiB3b3VsZCBuZWVkIHRvIHRoaW5rIHRoYXQgdGhyb3VnaCBhbmQgaGF2ZSBhIGJl
dHRlciB1bmRlcnN0YW5kaW5nIG9mIGV4YWN0bHkNCj4gd2hhdCBpZGVudGl0eSBpcy4NCj4gDQo+
IEFueXdheSwgSSBoYXZlIGEgZHJhZnQgb24gdGhlIGNvbmNlcHQgb2YgaWRlbnRpZmllciBncm91
cHMgYW5kIHNvbWUNCj4gZXhhbXBsZXMgb2YgdGhlaXIgdXNlIGlmIGFueW9uZSBpcyBpbnRlcmVz
dGVkLg0KPiANCj4gVG9tDQoNClN1cmUsIHRoZXJlIGFyZSB1c2VzIGZvciBncm91cGluZyBzZXJ2
aWNlcy4gICBCdXQganVzdCB0byBiZSBjbGVhciwgd2hhdCB3ZSBoYWQgaW4gbWluZCB3aXRoIHJl
Z2FyZHMgdG8gSUR5LCB3aGlsZSBpdCBzZXJ2ZXMgYXMgYSBzcGVjaWFsIHB1cnBvc2UgImdyb3Vw
IiAob3IgcmVhbGx5LCBhIGNvbGxlY3Rpb24pIHRoZXJlIGFyZSBhIGZldyBkaWZmZXJlbmNlcyBj
b21wYXJlZCB0byBhIGdlbmVyYWwtcHVycG9zZSBncm91cC4gIFNwZWNpZmljYWxseSwgd2l0aCBn
ZW5lcmFsIGdyb3VwcywgeW91IGNvdWxkIGhhdmUgbWFueS10by1tYW55IHJlbGF0aW9uc2hpcHMg
LSB0aGUgc2FtZSBlbnRpdHkgY291bGQgYmUgcGFydCBvZiBtYW55IGdyb3Vwcy4gIEluIHRoaXMg
Y2FzZSwgdGhlIHNhbWUgSURmIHdvdWxkIGdlbmVyYWxseSBjb250YWluZWQgaW4gb25lLCBhbmQg
b25seSBvbmUgZ3JvdXAuICANCi0tLSBBbGV4DQo=


From nobody Tue Oct 17 14:17:12 2017
Return-Path: 
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 0930313219F for ; Tue, 17 Oct 2017 14:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 md1teeTliY7n for ; Tue, 17 Oct 2017 14:17:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCE3132331 for ; Tue, 17 Oct 2017 14:17:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQV37883; Tue, 17 Oct 2017 21:17:06 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 22:17:05 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001;  Tue, 17 Oct 2017 14:17:01 -0700
From: Uma Chunduri 
To: Tom Herbert 
CC: "ideas@ietf.org" 
Thread-Topic: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
Thread-Index: AQHTRqsmzhTtyxc/w0CsYMOotXbfdqLnLFXQgACJJ4CAAJq/MA==
Date: Tue, 17 Oct 2017 21:17:00 +0000
Message-ID: <25B4902B1192E84696414485F572685413514329@sjceml521-mbs.china.huawei.com>
References:  <25B4902B1192E84696414485F572685413513F1D@sjceml521-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.49.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E67353.001A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 29cc6edb49b2ff973d78594621a6b010
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 21:17:10 -0000

Q29taW5nIGJhY2sgdG8gdGhlIElERUFTIHdvcmssIG9uZSBvZiB0aGUgZ29hbHMgaXMgdG8gY3Jl
YXRlIGEgc3RhbmRhcmRpemVkIG1hcHBpbmcgc3lzdGVtIHdpdGggdmFyaW91cyBJRCBzZXJ2aWNl
cyAobW9iaWxpdHksIGFjY2VzcyBzZWN1cml0eSwgcHViL3N1YiwgIGdyb3VwaW5nIGV0YykuIA0K
VGhlcmUgYXJlIHZhcmlvdXMgZW50ZXJwcmlzZSBkZXBsb3ltZW50cyB3aGVyZSB0aGVzZSBzZXJ2
aWNlcyBhcmUgbmVlZGVkIGFuZCB0aGUgYWJpbGl0eSB0byBhdXRob3JpemUgIHdobyBjYW4gdXBk
YXRlIG1hcHBpbmcgYW5kIHdobyBjYW4gcmVxdWVzdCBtYXBwaW5nIGlzIGNyaXRpY2FsIGZvciBk
ZXBsb3lpbmcgc29tZSBvZiAgdGhlc2Ugc2VydmljZXMuIA0KRm9yIElMQSBvciAgZm9yIERDIFZN
IG1vYmlsaXR5IHNvbWUgb2YgdGhlIHNlcnZpY2VzIG1heSBub3QgYmUgbmVlZGVkIG9yIElkZW50
aXR5IGlzIGFuIG92ZXJoZWFkIChidXQgSSBzYXcgZnJvbSB5b3VyIHJlc3BvbnNlcyBlYXJsaWVy
LCB5b3UgbmVlZCBhdXRob3JpemF0aW9uIG9uIHdobyBjYW4gdXBkYXRlIGluIGEgbXVsdGkgdGVu
ZW5hbnQgZW52aXJvbm1lbnRzKSANCmFuZCB0aGF0IGNhbiBiZSBtYWRlIG9wdGlvbmFsIGlmIG5v
dCBuZWVkZWQuICBCdXQsIEkgc2VlIHlvdSBhcmUgYXJndWluZyBvbiBib3RoIHNpZGVzLiAgSWYg
eW91IGhhdmUgYSBiZXR0ZXIgc29sdXRpb24gdG8gYWRkcmVzcyB0aGUgYWJvdmUgbmVlZHMgcGxl
YXNlIHNoYXJlIGl0Lg0KDQotLQ0KVW1hIEMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dIA0KU2VudDog
TW9uZGF5LCBPY3RvYmVyIDE2LCAyMDE3IDY6MjUgUE0NClRvOiBVbWEgQ2h1bmR1cmkgPHVtYS5j
aHVuZHVyaUBodWF3ZWkuY29tPg0KQ2M6IGlkZWFzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lk
ZWFzXSBDb21tZW50cyBvbiBkcmFmdC1jY20taWRlYXMtaWRlbnRpdHktdXNlLWNhc2VzLTAyDQou
Li4NCg0KCT5UaGlzIHByb2JsZW0gSSBoaWdobGlnaHRlZCB3b3VsZCBvbmx5IGV4aXN0IG9uIHB1
YmxpYyBuZXR3b3JrcyB3aGVyZSBlbmQgdXNlciBkZXZpY2VzIGFyZSBub3QgdW5kZXIgY29tcGxl
dGUgY29udHJvbCBvZiB0aGUNCgk+aW5mcmFzdHJ1Y3R1cmUtLSBpLmUuIHNtYXJ0IHBob25lcyBv
biBhIHB1YmxpYyBjYXJyaWVyIG5ldHdvcmsuDQoNCgk+IEluIGEgcHJpdmF0ZSBkYXRhIGNlbnRl
ciBmb3IgaW5zdGFuY2UsIHdoZXJlIGFsbCBob3N0cyBjYW4gYmUgY29udHJvbGxlZCwgdGhlcmUg
aXMgbm8gaXNzdWUgaW4gcnVubmluZyBpZGVudGlmaWVyLWxvY2F0b3Igb24gaG9zdHMgYW5kIHRo
YXQgaW4gZmFjdCBpcyBhIGNvbW1vbiBkZXBsb3ltZW50IG9mIG5ldHdvcmsgdmlydHVhbGl6YXRp
b24uDQpbVW1hXTogU3VyZSwgYWdyZWUuIEFuZCB5b3UgbmVlZCBhIG1hcHBpbmcgc3lzdGVtIHdp
dGggc3RhbmRhcmRpemVkIGludGVyZmFjZXMgYW5kIGEgY29udHJvbCBwcm90b2NvbCB0byBpbnRl
cmFjdCB0byBhZGRyZXNzaW5nIHRoaXMgc3BhY2UuDQoNCgk+VGhlIGV4cGxvaXQgSSdtIGNvbmpl
Y3R1cmluZyB3b3VsZCB3b3JrIGxpa2UgdGhpczoNCgk+KiBTdXBwb3NlIHRoYXQgYSBVRSAoZS5n
LiBhIHNtYXJ0cGhvbmUpIHBhcnRpY2lwYXRpbmcgaW4gYW4gaWRlbnRpZmllci9sb2NhdG9yIHBy
b3RvY29scyBpcyBoYWNrZWQuDQpbVW1hXTogVGhlcmUgYXJlIHNvIG1hbnkgY2FzZXMsIHdoZXJl
ICB0aGluZ3MgbmVlZCB0byBiZSBoYW5kbGVkLCB3aGljaCBpbmNsdWRlcyBub3Qgb25seSBoYWNr
ZWQgYnV0IGxvc3Qvc3RvbGVuIGRldmljZXMgZXRjLiBUaGVyZSBpcyBzb21ldGhpbmcgY2FsbGVk
IHJldm9jYXRpb24gb3IgZGlzYWJsaW5nIHRoZSBkZXZpY2UgYmFzZWQgb24gdGhlIGF1dGguIG1l
dGhvZCB1c2VkIGluIHRoZSBkZXZpY2UgYnkgdGhlIHByb3ZpZGVyLg0KDQogICAgICAgICAgICAg
ICAgLi4uDQoNCgk+KiBFZmZvcnRzIHRvIG9iZnVzY2F0ZSBvciByb3RhdGUgaWRlbnRpZmllcnMg
ZG9lcyBub3QgaGVscCBtdWNoIGhlcmUuDQoJPk9iZnVzY2F0aW9uIGNvbXBsaWNhdGVzIHJvdXRp
bmcgaW4gdGhlIG5ldHdvcmsgc3VjaCB0aGF0IHRyYW5zbGF0aW9ucyBuZWVkIHRvIGhhcHBlbiBh
bnl3YXkuIFBlcmlvZGljIHJvdGF0aW9uIG9mIGxvY2F0b3JzIGlzIGRlZmVhdGVkIGlmIHRoZXJl
IGFyZSBlbm91Z2ggZGV2aWNlcyBkb2luZyB0aGUgbWFwcGluZyB0byBrZWVwIHRoZSBtYXBzIHVw
IHRvIGRhdGUuDQpbVW1hXTogT2JmdXNjYXRpb24gb2J2aW91c2x5IGRvZXNuJ3Qgc29sdmUgYWxs
IHRoZSBldmlscy4gSXQgaGFzIGl0cyBvd24gcGxhY2UgYW5kIGlmIHdlIHRydWx5IGNhcmUgdXNl
IGVuZCB0byBlbmQgZW5jcnlwdGlvbiB3aGVyZSBldmVyIGlzIG5lZWRlZC4NCiAgICAgICAgICAg
ICAgICBBZ2FpbiwgZGF0YSBwbGFuZSBjb25zdHJ1Y3RzIGFuZCBtZWNoYW5pc21zIGZvciBwcm90
ZWN0aW9uIGFyZSB1bmRlciB0aGUgcHVydmlldyBvZiB0aGUgdW5kZXJseWluZyBJRC9MT0MgcHJv
dG9jb2wgaW4gcXVlc3Rpb24uIElERUFTIGNhbiBvbmx5IGhlbHAgYXVnbWVudCBzb21lIG9mIHRo
ZSBmZWF0dXJlcyBuZWVkZWQgZm9yIHRoZXNlIHByb3RvY29scy4NCg0KCT5JdCdzIHRydWUgdGhp
cyBtYXkgYmUgb3J0aG9nb25hbCB0byB0aGUgZGVzaWduIG9mIGEgbWFwcGluZyBzeXN0ZW0uLg0K
W1VtYV06IFllcywgaXQncyBtb3N0bHkgb3J0aG9nb25hbCAgdG8gSURFQVMuDQoNCiAgICAgICAg
ICAgICAgICA+IEFueW9uZSB3aG8gd29ya3MgYXQgY29tcGFuaWVzIGxpa2UgQXBwbGUgYW5kIEdv
b2dsZSB0aGF0IHJlZ3VsYXJseSBjb2xsZWN0IGRldmljZSBnZW8tbG9jYXRpb24gY2FuIHZvdWNo
IHRoYXQgaXQgaXMgYW1vbmcgdGhlIG1vc3Qgc2Vuc2l0aXZlIG9mIGFsbCB0aGUgUElJIHRoZXkg
Y29sbGVjdC4gDQoJPkFjY29yZGluZ2x5LCB0aGV5IGltcGxlbWVudCBleHRyZW1lbHkgc3Ryb25n
IGFjY2VzcyBjb250cm9scyB0byB0aGUgcG9pbnQgdGhhdCBldmVuIHRoYXQgb25seSBhIHRpbnkg
bnVtYmVyIG9mIGVtcGxveWVlcyBjYW4gZGlyZWN0bHkgYWNjZXNzIHRoZSBkYXRhLg0KDQpbVW1h
XTogWW91IGFyZSByaWdodC4gVGhpcyBpcyBleGFjdGx5ICB3aGF0IHdlIGhhdmUgYmVlbiBhcmd1
aW5nIGFzIHdlbGwuICBBbnkgZGF0YSB0aGF0IGlzIHNlbnNpdGl2ZSB3aWxsIGhhdmUgc3Ryb25n
IGFjY2VzcyBjb250cm9scyBhbmQgbm90IHB1YmxpY2x5IGV4cG9zZWQuIA0KIAlBbHNvLCBJIGFt
IG5vdCB1bmRlcnN0YW5kaW5nIHRoZSBhYm92ZSBsb2dpYyBmdWxseSAgLSBiZWNhdXNlIGFsbCBz
b3J0cyBvZiBQSUkgaXMgY29sbGVjdGVkIGluIHZhcmlvdXMgYXBwbGljYXRpb25zIG9yIGp1c3Qg
YmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHlvdSBhcmUgb24geW91ciBjZWxsdWxhciBkZXZpY2Ug
eW91ciBwcm92aWRlciBjYW4gdHJhY2sgeW91IChvciBob3cgdGhlc2UgYXJlIHByb3RlY3RlZCB0
b2RheSkuIA0KCVByaXZhY3kgc2VlbXMgbW9yZSBvZiBhIG1pc25vbWVyIHNvbWV0aW1lcyAoZnJv
bSB0aGUgYXBwcywgdG8gYnJvd3NlciB0byB0aGUgY2VsbHVsYXIgZGV2aWNlcyBhbmQgdGhpcyAg
b25seSBmdXJ0aGVyIHByb2xpZmVyYXRlcyB3aXRoIGFsbCBzb3J0cyBvZiAgZGV2aWNlcyBkb2lu
ZyBNMk0gd291bGQgYmUgb24gdmFyaW91cyBuZXR3b3JrcyBzb29uKS4NCiAgICAgICAgICAgICAg
DQogICAgICAgICAgICANCg==


From nobody Tue Oct 17 15:17:48 2017
Return-Path: 
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 4E471132D45 for ; Tue, 17 Oct 2017 15:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 WYxHOySXPk7R for ; Tue, 17 Oct 2017 15:17:46 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 0DD0E13304B for ; Tue, 17 Oct 2017 15:17:46 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id k123so4035780qke.3 for ; Tue, 17 Oct 2017 15:17:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eqInE2Jfxg+OWw+41/NGMTt1yNGhLNGm/HFCHC9agMM=; b=ADPPw+XfO35OSWMG8QN8Y0NxF+iIUC6jtqFcxQwiAGe0nQjFspfEgr2AsFIhg/I/uK e3LnzW4NheATPhj0qu+qq5K5jlK87H/oeLtVVF6ykumW6sne8jAd1tdvxWfG2Bu5Lnle yb+yQ8/Pz/fkZpasKB0Gj+c3r0ZSyq7uRdHm36vtkB5Et7plUryTHWksNuEWUnAs7IA3 ugakLzBwYcJP9i/r44XBUOec1ZuAOF49CDuXJuv4u2jGyeW6JYrNC9dzHEllyL72xFic ELtfoivi0gl0IVT5Zl5hfZCmjLXMb440JHR5vTVy3DH684PUkRRSxcrxYWrlWftVfT6o oq7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eqInE2Jfxg+OWw+41/NGMTt1yNGhLNGm/HFCHC9agMM=; b=OEKwpOlRo7Pabka6NODEGZlk8k5lXqhg549qGtE8+BYPL/c9slYTpRDZsObF+5F8B+ uHum+W24wgf5emQZNLYjq0pzovVYYchjuOt/+G8v60GPBYYs4Hx/v8rYGoXesnNWaWjD 30u+j0bFWMId+cpl566XzkyGUWeYMYnz4cLqtGsF0pt26WXs7i/+QbP8rBeR7G38DljC VKNhGz3ZB2B9E6UenVN8fmDlNNZUR1LTVNZMSp4QYyyBhTlfZW1E9+2Iw+03s4TgEyjV VRMszZiYS+XVYQhN1S5tDd4u+zNH030sviNo9OrQUi/L65Z+5KsCjkomDFap1qKwJZhM TLgA==
X-Gm-Message-State: AMCzsaUOwg6r1vIxUFc7kWTB1GMk63IHLRjW8gJ9sk9Z20xuQFDlYWuB nrh8KSP5YgM6V8hqIcyau9GT3YrDU65DyEY/uE6NVmoc
X-Google-Smtp-Source: ABhQp+RES71au1MhhBXaW+oKEeme9FWkmxl5NDgcokJBhDr9EzPzNAtdS3CgV95vw3ZunDZiFLwRbKw2F5S/HCxmkIY=
X-Received: by 10.55.106.132 with SMTP id f126mr19722691qkc.295.1508278664898;  Tue, 17 Oct 2017 15:17:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 15:17:44 -0700 (PDT)
From: Tom Herbert 
Date: Tue, 17 Oct 2017 15:17:44 -0700
Message-ID: 
To: ideas@ietf.org, Uma Chunduri 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 22:17:47 -0000

> Coming back to the IDEAS work, one of the goals is to create a standardized mapping system with various ID services (mobility, access security, pub/sub,  grouping etc).
> There are various enterprise deployments where these services are needed and the ability to authorize  who can update mapping and who can request mapping is critical for deploying some of  these services.
> For ILA or  for DC VM mobility some of the services may not be needed or Identity is an overhead (but I saw from your responses earlier, you need authorization on who can update in a multi tenenant environments)
and that can be made optional if not needed.  But, I see you are
arguing on both sides.  If you have a better solution to address the
above needs please share it.

Uma,

Authorization of operations on a mapping system is not optional,
however I don't see that this problem is unique to mapping systems nor
something that hasn't already been implemented. There are already many
built out networks that have implemented mapping systems that include
authorization of operations on the system. Google Cloud for instance
operates a huge multi-tenant network and I suspect they use LOAS to
authenticate access to the system since that is already what they use
for everything else anyway. And it makes sense for them to reuse the
authentication system that they are using for all of their other
services; I doubt anything defined IDEAS would change their minds on
authentication of their mapping system.

In my design for ILA, I'm fond of using TLS for communications which
provides both security (encryption) and verifiable identity in
certificates. The X.509 identity can be used to against ACLs to
control read and write access. Like Google, I also intend on using the
same method for other accessing shared critical services in my
network. If this is the same thing as identity being described in
IDEAS then I guess we're on the same page, but from the definitions of
identity being proposed I'm not sure it is equivalent.

Tom


From nobody Wed Oct 18 06:04:48 2017
Return-Path: 
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 4DC7112421A for ; Wed, 18 Oct 2017 06:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IQkFU7UxtPJK for ; Wed, 18 Oct 2017 06:04:42 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD0A132D44 for ; Wed, 18 Oct 2017 06:04:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E49B7621F0 for ; Wed, 18 Oct 2017 09:04:41 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GUC8jwkdcbwb for ; Wed, 18 Oct 2017 09:04:34 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 12477621AE for ; Wed, 18 Oct 2017 09:04:33 -0400 (EDT)
To: "ideas@ietf.org" 
From: Robert Moskowitz 
Message-ID: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com>
Date: Wed, 18 Oct 2017 09:04:31 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 13:04:46 -0000

I chose the subject line carefully as you will see by my analysis of the 
privacy issue(s).  I have discussed this with Padma before bringing this 
up to the list.

Here is the privacy attack, as I see it:

It is fairly well established that web sites collect a lot of personal 
information and information about the device(s) connected to that 
personal information.  IP addresses, even the actual address of NATed 
clients are part of the harvest.  Mal and his cousins are busy stealing 
this information and putting it all together in their own big data pile.

Meanwhile, Eve and her cousins are busy watching the network and seeing 
which IP addresses are communicating with other IP addresses.  Eve and 
cohorts put their data together with Mal and cohorts' data and then is 
able to note that:  "Hey look, Alice is talking directly with Barb."  
Oh, look, they both moved to new addresses, but we can see it is still 
Alice and Barb.

What is going on here?

ID/Loc technologies, enhanced with IDEAS technology, will make 
Peer-to-Peer communications without any triangular routing achievable.  
As long as these P2P communications use the same IP addresses as used in 
web Client/Server communications, the linkage is there to the privacy 
leakage occuring through those websites.

Three things have to happen to protect the privacy of P2P communications 
from the swamp of privacy leakage in C/S communications.

Identities need to be masked/hidden by both the ID/Loc technologies and 
IDEAS.

Identifiers of all ilk, both in the control channel and the data channel 
need to change with each move using some Perfect Forward Secrecy (PFS) 
technology.

Multiple IP addresses MUST be used, at least separating the P2P from C/S 
communications.  Different addresses for different P2P connections is wise.

Note that if IDEAS-ID/Loc does everything to hide and confuse 
Identity/Identifier, it is all for naught if multiple IP addresses are 
not used.  At this point I should mention that TLS 1.3 may have a 
similar privacy risk, but that is for a different soapbox.

Action plan:

The IDEAS charter should say something like:

"IDEAS will act as an enabling technology for the various ID/Loc 
technologies currently specified within the IETF.  As such it will 
result in a wider deployment of, mobile, Peer to Peer communications.  
Care will be taken in the design of the IDEAS technology not to enable 
the privacy leakage attacks in current Client/Server (predominately 
web-based) to be linked to these P2P communications."

This means that whatever technology we come up for IDEAS will mask/hide 
PII/Identity/Identifier.  So that Eve is in the dark and we need only 
defend the IDEAS data store from Mal.

Each ID/Loc technolgy (and this means ME with HIP) will need revisions 
to both their control and data plane (this means ESP for HIP) to change 
how Indentity and Identifiers are handled to break privacy tracking by 
Eve.  This may require using IDEAS as an enabler of privacy functions (I 
suspect I will need it in HIP to deal with the HI in the R1 packet).  
TLS 1.3 may also need revisions with its zero RT method.

The final, and potentially big one that is outside the IETF's control is 
that OSs and ISPs MUST enable support for multiple addresses per host 
and let technologies within the hosts (like ID/Loc) to get addresses to 
provide privacy separation.  This ALSO extends to MAC addresses!  Eve 
could be tapping into those IPFIX flows (now there is a BIG privacy 
leakage attack that no one is talking about) and getting all the MAC/IP 
address mappings!

One caveat that makes the multiple address not so big of a challenge is 
that ISPs are already providing some level of multiple address support 
by allowing hotspot usage on the mobile devices.  The IP address seen on 
the network MAY be from a given device or a device using it as a 
gateway.  This will become increasingly more common with automotive 
hotspots.  But this is NOT something we should count on as a mitigation 
of this privacy attack.

==========

Conclusion

IDEAS will analyse all security and privacy risks and include mitigation 
approaches in its design.

I will take this attack to the HIP group for revisions there.  I already 
have some work going (fast moblity draft for one) that I can leverage to 
this purpose.

I will reach out to the experts of other ID/Loc technologies (including 
MobileIKE) to discuss what they can do to ensure privacy as a design goal.

Finally, as some of you know, my suit has a kevlar armor layer.  So have 
at it!   :)

Bob


From nobody Wed Oct 18 07:16:05 2017
Return-Path: 
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 9BCD6132CE7 for ; Wed, 18 Oct 2017 07:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=surrey.ac.uk
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 nI84-92UMH6D for ; Wed, 18 Oct 2017 07:15:57 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0104.outbound.protection.outlook.com [104.47.2.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D0E124B17 for ; Wed, 18 Oct 2017 07:15:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surrey.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eD+lJaCmr/3+y9+VRt2+NdvzuFjBXvdpADgzPrG6mOw=; b=B2JNH9nls5nQVNLygUfl0ghJY21m+ACXxZ242wlDNqIsvJq21/zPvNuMqa+sI/MDrD3iDDMNc9pwD5jCO+yJqZcuYSn2rUMWt6hICRHTU9VPpDxdgaH5s4NAsPbDa7vqIFMqQ/hnhX4vvI5U7vqG31ZRyf1o/xoiDCF/BcpQFqs=
Received: from DB3PR0602MB3756.eurprd06.prod.outlook.com (52.134.70.31) by DB3PR0602MB3753.eurprd06.prod.outlook.com (52.134.66.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 18 Oct 2017 14:15:49 +0000
Received: from DB3PR0602MB3756.eurprd06.prod.outlook.com ([fe80::68b8:8f98:fb4:632]) by DB3PR0602MB3756.eurprd06.prod.outlook.com ([fe80::68b8:8f98:fb4:632%13]) with mapi id 15.20.0077.021; Wed, 18 Oct 2017 14:15:49 +0000
From: 
To: , 
Thread-Topic: [Ideas] Addressing the privacy issues exposed by IDEAS
Thread-Index: AQHTSBGvgANDWu6ZqUSw0oVCV8dWfaLpowMQ
Date: Wed, 18 Oct 2017 14:15:49 +0000
Message-ID: 
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com>
In-Reply-To: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=d.lake@surrey.ac.uk; 
x-originating-ip: [64.134.234.51]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB3PR0602MB3753; 6:2KL75QYmmpVX8x4S3laBtCTegHKc9MY/oKuqmWBUz/d/NkYtCtnr77eigRYo82aLRbsj7EjHAEDVy2rTG2z4kQ6TJZ5FegbS4RUt3h+0UKPZbjskxDoUBNAOQd/G/jop9dB1BvCc32YYIVcnKsF6ts5at3BKF+pMEUsM6cY6RxqrrG5+O+3s96N544zDvb7oxxlON4u+z6/lUxpyhXlnZIY1XGjvwU5lKfsNxo25nIVllqMwNMLGCeq9i2jIZ+tjDGWe6+7dYf6+3sa+DFSni5Zst0Jc2muAj5YQCAA84cyn2PkeG+xlP+r4R7irvd1L0PMbE9+ienFAbfAeXW1X4g==; 5:CZpchyiwm/y+ITY021K/WQnzvfdRBdwk/2l9LrmtTdWrz5Al3RH0GL7cX8zGZv3D5FH92igKQsxWLRVRRMYeA3dqiCr2J2pnVSizlYQW68O3xAZPdtcJR+F9vQbKl39WogClbhjkhE97rTu4uK8gKhLM3CVOUcJhuK7AXs0ZNCk=; 24:hU2BO2LpPNh3je+7FjD/ZHsXf+7NMNwoCyKgCwnp1LYgBCgWteoAnwn1ML1xdvAWq+iysc1pO57oaoGYz7e4YZ1iLQ2FFafhqcavYV/Cdr0=; 7:FmGjaqlzqNZyvKCWOIVq5DHVjvf0ck0SZVGS64F91KvkAQIVc81rfPYff7SLEoqTj69yEVF+Xt0vHgZJDr9GoHwN6AFTHkvFutiK6FnNoDeMSYU3dm4uwzPwonI+3DizjY3CUJR0bG4m6OuDjkYBXQF0+LULFSc33R3JtlLmdxA1PkhbqzjMKKGF4lzhAt8Qs2smNa8F8hirPM+diY8ge0/xgiBoS0ViYbdDT0oKDzQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ab8121ec-79b8-45d8-3b30-08d51632bba8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB3PR0602MB3753; 
x-ms-traffictypediagnostic: DB3PR0602MB3753:
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR0602MB3753; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR0602MB3753; 
x-forefront-prvs: 0464DBBBC4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(189002)(199003)(13464003)(53936002)(33656002)(2906002)(786003)(7736002)(229853002)(305945005)(66066001)(3280700002)(9686003)(106356001)(14454004)(316002)(101416001)(6306002)(99286003)(3660700001)(3846002)(102836003)(6436002)(74316002)(55016002)(5660300001)(50986999)(54356999)(76176999)(6246003)(74482002)(7696004)(189998001)(68736007)(6506006)(110136005)(97736004)(966005)(6116002)(2501003)(81166006)(81156014)(105586002)(25786009)(8676002)(42882006)(5250100002)(8936002)(2900100001)(2950100002)(86362001)(478600001)(53546010)(31153001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3753; H:DB3PR0602MB3756.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: surrey.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: surrey.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 14:15:49.4864 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3753
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: DB3PR0602MB3756.eurprd06.prod.outlook.com
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-TransportTrafficSubType: 
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 64.134.234.51
X-MS-Exchange-CrossPremises-transporttraffictype: Email
X-MS-Exchange-CrossPremises-transporttrafficsubtype: 
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: DB3PR0602MB3753.eurprd06.prod.outlook.com
Archived-At: 
Subject: Re: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 14:16:04 -0000

Bob

A very interesting discussion and one we need to clear before we can move o=
n IMvHO!

Your comment:

	" ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-P=
eer communications without any triangular routing achievable."   =20

Yes but we need to keep in mind the operation of LI and should be supportiv=
e of that.   It can be achieved without triangular routing, but we should n=
ot consider it as an after-thought.   It is a regulatory and business requi=
rement for the operators and they will (and have) reject any technology whi=
ch does not meet these needs.   That is why we are still seeing anchored GT=
P tunnels in Rel.15.

	Meanwhile, Eve and her cousins are busy watching the network and seeing wh=
ich IP addresses are communicating with other IP addresses.  Eve and cohort=
s put their data together with Mal and cohorts' data and then is able to no=
te that:  "Hey look, 	Alice is talking directly with Barb." =20

Whilst I love your sarcasm, there is another, less nefarious reason for the=
 interception and that it is to do with allocation of resources and deliver=
y against SLAs in mobile networks.    As mobile becomes the pre-dominant mo=
de of connection to the Internet (driven by the trend to virtually zero cos=
t we are witnessing in most geographies now for mobile packages), given tha=
t we have a very limited transport resource (RF spectrum), controlled acces=
s to and differentiated services over the Air Interface will be key to new =
services.  The ONLY reasons VoLTE works is because we have hard allocation =
of everything from radio bearer to packet-core and back.=20

If we imagine a world where services other than default-bearer mobile broad=
band and dedicated bearer VoLTE exist (and this is the basic premise for 5G=
), then having knowledge of location, service and end-point is vital so tha=
t a) resources can be allocated and b) you (and I) can be billed for it app=
ropriately.

In terms of privacy, one aspect is missing from you critique - location.   =
A mobile operator will know simply from association of IMSI to IP address t=
o GTP TEID exactly which cell(s) you are on.

David

-----Original Message-----
From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
Sent: 18 October 2017 06:05
To: ideas@ietf.org
Subject: [Ideas] Addressing the privacy issues exposed by IDEAS

I chose the subject line carefully as you will see by my analysis of the pr=
ivacy issue(s).  I have discussed this with Padma before bringing this up t=
o the list.

Here is the privacy attack, as I see it:

It is fairly well established that web sites collect a lot of personal info=
rmation and information about the device(s) connected to that personal info=
rmation.  IP addresses, even the actual address of NATed clients are part o=
f the harvest.  Mal and his cousins are busy stealing this information and =
putting it all together in their own big data pile.

Meanwhile, Eve and her cousins are busy watching the network and seeing whi=
ch IP addresses are communicating with other IP addresses.  Eve and cohorts=
 put their data together with Mal and cohorts' data and then is able to not=
e that:  "Hey look, Alice is talking directly with Barb." =20
Oh, look, they both moved to new addresses, but we can see it is still Alic=
e and Barb.

What is going on here?

ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer=
 communications without any triangular routing achievable. =20
As long as these P2P communications use the same IP addresses as used in we=
b Client/Server communications, the linkage is there to the privacy leakage=
 occuring through those websites.

Three things have to happen to protect the privacy of P2P communications fr=
om the swamp of privacy leakage in C/S communications.

Identities need to be masked/hidden by both the ID/Loc technologies and IDE=
AS.

Identifiers of all ilk, both in the control channel and the data channel ne=
ed to change with each move using some Perfect Forward Secrecy (PFS) techno=
logy.

Multiple IP addresses MUST be used, at least separating the P2P from C/S co=
mmunications.  Different addresses for different P2P connections is wise.

Note that if IDEAS-ID/Loc does everything to hide and confuse Identity/Iden=
tifier, it is all for naught if multiple IP addresses are not used.  At thi=
s point I should mention that TLS 1.3 may have a similar privacy risk, but =
that is for a different soapbox.

Action plan:

The IDEAS charter should say something like:

"IDEAS will act as an enabling technology for the various ID/Loc technologi=
es currently specified within the IETF.  As such it will result in a wider =
deployment of, mobile, Peer to Peer communications. =20
Care will be taken in the design of the IDEAS technology not to enable the =
privacy leakage attacks in current Client/Server (predominately
web-based) to be linked to these P2P communications."

This means that whatever technology we come up for IDEAS will mask/hide PII=
/Identity/Identifier.  So that Eve is in the dark and we need only defend t=
he IDEAS data store from Mal.

Each ID/Loc technolgy (and this means ME with HIP) will need revisions to b=
oth their control and data plane (this means ESP for HIP) to change how Ind=
entity and Identifiers are handled to break privacy tracking by Eve.  This =
may require using IDEAS as an enabler of privacy functions (I suspect I wil=
l need it in HIP to deal with the HI in the R1 packet). =20
TLS 1.3 may also need revisions with its zero RT method.

The final, and potentially big one that is outside the IETF's control is th=
at OSs and ISPs MUST enable support for multiple addresses per host and let=
 technologies within the hosts (like ID/Loc) to get addresses to provide pr=
ivacy separation.  This ALSO extends to MAC addresses!  Eve could be tappin=
g into those IPFIX flows (now there is a BIG privacy leakage attack that no=
 one is talking about) and getting all the MAC/IP address mappings!

One caveat that makes the multiple address not so big of a challenge is tha=
t ISPs are already providing some level of multiple address support by allo=
wing hotspot usage on the mobile devices.  The IP address seen on the netwo=
rk MAY be from a given device or a device using it as a gateway.  This will=
 become increasingly more common with automotive hotspots.  But this is NOT=
 something we should count on as a mitigation of this privacy attack.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Conclusion

IDEAS will analyse all security and privacy risks and include mitigation ap=
proaches in its design.

I will take this attack to the HIP group for revisions there.  I already ha=
ve some work going (fast moblity draft for one) that I can leverage to this=
 purpose.

I will reach out to the experts of other ID/Loc technologies (including
MobileIKE) to discuss what they can do to ensure privacy as a design goal.

Finally, as some of you know, my suit has a kevlar armor layer.  So have=20
at it!   :)

Bob

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


From nobody Wed Oct 18 08:02:12 2017
Return-Path: 
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 9214F13421C for ; Wed, 18 Oct 2017 08:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 w3S0CQYElyyu for ; Wed, 18 Oct 2017 08:02:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6481A13420D for ; Wed, 18 Oct 2017 08:02:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQW84093; Wed, 18 Oct 2017 15:01:59 +0000 (GMT)
Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 18 Oct 2017 16:01:59 +0100
Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.158]) by YYZEML702-CHM.china.huawei.com ([169.254.6.229]) with mapi id 14.03.0361.001;  Wed, 18 Oct 2017 11:01:56 -0400
From: AshwoodsmithPeter 
To: "d.lake@surrey.ac.uk" , "rgm-ietf@htt-consult.com" , "ideas@ietf.org" 
Thread-Topic: [Ideas] Addressing the privacy issues exposed by IDEAS
Thread-Index: AQHTSBG29cxS1EAkj0ic8a5MP0OoK6Lp6hyA///AziA=
Date: Wed, 18 Oct 2017 15:01:55 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2323942B7@YYZEML701-CHM.china.huawei.com>
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.60.215]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59E76CE8.0055, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.158, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6dbe0d9135e8be4c33731be29973c42d
Archived-At: 
Subject: Re: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 15:02:09 -0000

> >	" ID/Loc technologies, enhanced with IDEAS technology, will make Peer-t=
o-Peer communications without any triangular routing achievable."   =20

> Yes but we need to keep in mind the operation of LI and should be support=
ive of that.   It can be achieved without triangular routing, but we should=
 not consider it as an after-thought.   It is a regulatory and business req=
uirement for the operators and they will (and have) reject any technology w=
hich does not meet these needs.   That is why we are still seeing anchored =
GTP tunnels in Rel.15.

LI - Lawful Intercept can be implemented with ID/Loc technologies via the m=
apping system. In fact traffic can be directed to any convenient DC for int=
ercept rather than having to be on a known data path. Fixed tunnels actuall=
y give you less flexibility for intercept since you can only do it on paths=
 that you know the traffic is traversing and for access technologies that u=
se those tunnels.

An ID loc / mapping system approach means that all interception for lawful,=
 policy, etc. reasons are handled the same way, for multiple different acce=
ss technologies and work under mobility the same way regardless of access. =
I'd have thought the regulatory bodies would be all over a more flexible in=
tercept technology ;(


Cheers,

Peter


....

David

-----Original Message-----
From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
Sent: 18 October 2017 06:05
To: ideas@ietf.org
Subject: [Ideas] Addressing the privacy issues exposed by IDEAS

I chose the subject line carefully as you will see by my analysis of the pr=
ivacy issue(s).  I have discussed this with Padma before bringing this up t=
o the list.

Here is the privacy attack, as I see it:

It is fairly well established that web sites collect a lot of personal info=
rmation and information about the device(s) connected to that personal info=
rmation.  IP addresses, even the actual address of NATed clients are part o=
f the harvest.  Mal and his cousins are busy stealing this information and =
putting it all together in their own big data pile.

Meanwhile, Eve and her cousins are busy watching the network and seeing whi=
ch IP addresses are communicating with other IP addresses.  Eve and cohorts=
 put their data together with Mal and cohorts' data and then is able to not=
e that:  "Hey look, Alice is talking directly with Barb." =20
Oh, look, they both moved to new addresses, but we can see it is still Alic=
e and Barb.

What is going on here?

ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer=
 communications without any triangular routing achievable. =20
As long as these P2P communications use the same IP addresses as used in we=
b Client/Server communications, the linkage is there to the privacy leakage=
 occuring through those websites.

Three things have to happen to protect the privacy of P2P communications fr=
om the swamp of privacy leakage in C/S communications.

Identities need to be masked/hidden by both the ID/Loc technologies and IDE=
AS.

Identifiers of all ilk, both in the control channel and the data channel ne=
ed to change with each move using some Perfect Forward Secrecy (PFS) techno=
logy.

Multiple IP addresses MUST be used, at least separating the P2P from C/S co=
mmunications.  Different addresses for different P2P connections is wise.

Note that if IDEAS-ID/Loc does everything to hide and confuse Identity/Iden=
tifier, it is all for naught if multiple IP addresses are not used.  At thi=
s point I should mention that TLS 1.3 may have a similar privacy risk, but =
that is for a different soapbox.

Action plan:

The IDEAS charter should say something like:

"IDEAS will act as an enabling technology for the various ID/Loc technologi=
es currently specified within the IETF.  As such it will result in a wider =
deployment of, mobile, Peer to Peer communications. =20
Care will be taken in the design of the IDEAS technology not to enable the =
privacy leakage attacks in current Client/Server (predominately
web-based) to be linked to these P2P communications."

This means that whatever technology we come up for IDEAS will mask/hide PII=
/Identity/Identifier.  So that Eve is in the dark and we need only defend t=
he IDEAS data store from Mal.

Each ID/Loc technolgy (and this means ME with HIP) will need revisions to b=
oth their control and data plane (this means ESP for HIP) to change how Ind=
entity and Identifiers are handled to break privacy tracking by Eve.  This =
may require using IDEAS as an enabler of privacy functions (I suspect I wil=
l need it in HIP to deal with the HI in the R1 packet). =20
TLS 1.3 may also need revisions with its zero RT method.

The final, and potentially big one that is outside the IETF's control is th=
at OSs and ISPs MUST enable support for multiple addresses per host and let=
 technologies within the hosts (like ID/Loc) to get addresses to provide pr=
ivacy separation.  This ALSO extends to MAC addresses!  Eve could be tappin=
g into those IPFIX flows (now there is a BIG privacy leakage attack that no=
 one is talking about) and getting all the MAC/IP address mappings!

One caveat that makes the multiple address not so big of a challenge is tha=
t ISPs are already providing some level of multiple address support by allo=
wing hotspot usage on the mobile devices.  The IP address seen on the netwo=
rk MAY be from a given device or a device using it as a gateway.  This will=
 become increasingly more common with automotive hotspots.  But this is NOT=
 something we should count on as a mitigation of this privacy attack.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Conclusion

IDEAS will analyse all security and privacy risks and include mitigation ap=
proaches in its design.

I will take this attack to the HIP group for revisions there.  I already ha=
ve some work going (fast moblity draft for one) that I can leverage to this=
 purpose.

I will reach out to the experts of other ID/Loc technologies (including
MobileIKE) to discuss what they can do to ensure privacy as a design goal.

Finally, as some of you know, my suit has a kevlar armor layer.  So have=20
at it!   :)

Bob

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas


From nobody Wed Oct 18 08:10:50 2017
Return-Path: 
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 1284013334E for ; Wed, 18 Oct 2017 08:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3-ysbi1L2fBm for ; Wed, 18 Oct 2017 08:10:46 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D5A13420D for ; Wed, 18 Oct 2017 08:10:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D3FA3621F4; Wed, 18 Oct 2017 11:10:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zVLKIeHPiJFp; Wed, 18 Oct 2017 11:10:36 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 040BD621F2; Wed, 18 Oct 2017 11:10:34 -0400 (EDT)
To: AshwoodsmithPeter , "d.lake@surrey.ac.uk" , "ideas@ietf.org" 
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E2323942B7@YYZEML701-CHM.china.huawei.com>
From: Robert Moskowitz 
Message-ID: 
Date: Wed, 18 Oct 2017 11:10:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2323942B7@YYZEML701-CHM.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 15:10:49 -0000

On 10/18/2017 11:01 AM, AshwoodsmithPeter wrote:
>>> 	" ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable."
>> Yes but we need to keep in mind the operation of LI and should be supportive of that.   It can be achieved without triangular routing, but we should not consider it as an after-thought.   It is a regulatory and business requirement for the operators and they will (and have) reject any technology which does not meet these needs.   That is why we are still seeing anchored GTP tunnels in Rel.15.
> LI - Lawful Intercept can be implemented with ID/Loc technologies via the mapping system. In fact traffic can be directed to any convenient DC for intercept rather than having to be on a known data path. Fixed tunnels actually give you less flexibility for intercept since you can only do it on paths that you know the traffic is traversing and for access technologies that use those tunnels.

I had another proposal for LI using IPFIX or similar to fork traffic 
from the routing note between Alice and Barb.  And as long as Alice or 
Barb stays on the cellular network, their location would be known and 
the forking would move to a new place.

And none of this addresses that perhaps the traffic is from a connected 
friend via the mobile device's hotspot functionality.

Bob

>
> An ID loc / mapping system approach means that all interception for lawful, policy, etc. reasons are handled the same way, for multiple different access technologies and work under mobility the same way regardless of access. I'd have thought the regulatory bodies would be all over a more flexible intercept technology ;(
>
>
> Cheers,
>
> Peter
>
>
> ....
>
> David
>
> -----Original Message-----
> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
> Sent: 18 October 2017 06:05
> To: ideas@ietf.org
> Subject: [Ideas] Addressing the privacy issues exposed by IDEAS
>
> I chose the subject line carefully as you will see by my analysis of the privacy issue(s).  I have discussed this with Padma before bringing this up to the list.
>
> Here is the privacy attack, as I see it:
>
> It is fairly well established that web sites collect a lot of personal information and information about the device(s) connected to that personal information.  IP addresses, even the actual address of NATed clients are part of the harvest.  Mal and his cousins are busy stealing this information and putting it all together in their own big data pile.
>
> Meanwhile, Eve and her cousins are busy watching the network and seeing which IP addresses are communicating with other IP addresses.  Eve and cohorts put their data together with Mal and cohorts' data and then is able to note that:  "Hey look, Alice is talking directly with Barb."
> Oh, look, they both moved to new addresses, but we can see it is still Alice and Barb.
>
> What is going on here?
>
> ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable.
> As long as these P2P communications use the same IP addresses as used in web Client/Server communications, the linkage is there to the privacy leakage occuring through those websites.
>
> Three things have to happen to protect the privacy of P2P communications from the swamp of privacy leakage in C/S communications.
>
> Identities need to be masked/hidden by both the ID/Loc technologies and IDEAS.
>
> Identifiers of all ilk, both in the control channel and the data channel need to change with each move using some Perfect Forward Secrecy (PFS) technology.
>
> Multiple IP addresses MUST be used, at least separating the P2P from C/S communications.  Different addresses for different P2P connections is wise.
>
> Note that if IDEAS-ID/Loc does everything to hide and confuse Identity/Identifier, it is all for naught if multiple IP addresses are not used.  At this point I should mention that TLS 1.3 may have a similar privacy risk, but that is for a different soapbox.
>
> Action plan:
>
> The IDEAS charter should say something like:
>
> "IDEAS will act as an enabling technology for the various ID/Loc technologies currently specified within the IETF.  As such it will result in a wider deployment of, mobile, Peer to Peer communications.
> Care will be taken in the design of the IDEAS technology not to enable the privacy leakage attacks in current Client/Server (predominately
> web-based) to be linked to these P2P communications."
>
> This means that whatever technology we come up for IDEAS will mask/hide PII/Identity/Identifier.  So that Eve is in the dark and we need only defend the IDEAS data store from Mal.
>
> Each ID/Loc technolgy (and this means ME with HIP) will need revisions to both their control and data plane (this means ESP for HIP) to change how Indentity and Identifiers are handled to break privacy tracking by Eve.  This may require using IDEAS as an enabler of privacy functions (I suspect I will need it in HIP to deal with the HI in the R1 packet).
> TLS 1.3 may also need revisions with its zero RT method.
>
> The final, and potentially big one that is outside the IETF's control is that OSs and ISPs MUST enable support for multiple addresses per host and let technologies within the hosts (like ID/Loc) to get addresses to provide privacy separation.  This ALSO extends to MAC addresses!  Eve could be tapping into those IPFIX flows (now there is a BIG privacy leakage attack that no one is talking about) and getting all the MAC/IP address mappings!
>
> One caveat that makes the multiple address not so big of a challenge is that ISPs are already providing some level of multiple address support by allowing hotspot usage on the mobile devices.  The IP address seen on the network MAY be from a given device or a device using it as a gateway.  This will become increasingly more common with automotive hotspots.  But this is NOT something we should count on as a mitigation of this privacy attack.
>
> ==========
>
> Conclusion
>
> IDEAS will analyse all security and privacy risks and include mitigation approaches in its design.
>
> I will take this attack to the HIP group for revisions there.  I already have some work going (fast moblity draft for one) that I can leverage to this purpose.
>
> I will reach out to the experts of other ID/Loc technologies (including
> MobileIKE) to discuss what they can do to ensure privacy as a design goal.
>
> Finally, as some of you know, my suit has a kevlar armor layer.  So have
> at it!   :)
>
> Bob
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Wed Oct 18 08:12:57 2017
Return-Path: 
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 4377113334E for ; Wed, 18 Oct 2017 08:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 S_dzSGVnrOQR for ; Wed, 18 Oct 2017 08:12:54 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D37132CE7 for ; Wed, 18 Oct 2017 08:12:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 760D1621F4; Wed, 18 Oct 2017 11:12:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Lp4P8fTmjKFS; Wed, 18 Oct 2017 11:12:44 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1F66E621F2; Wed, 18 Oct 2017 11:12:40 -0400 (EDT)
To: d.lake@surrey.ac.uk, ideas@ietf.org
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com> 
From: Robert Moskowitz 
Message-ID: <27effb8d-3771-0862-368b-53a015945931@htt-consult.com>
Date: Wed, 18 Oct 2017 11:12:35 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 15:12:56 -0000

On 10/18/2017 10:15 AM, d.lake@surrey.ac.uk wrote:
> Bob
>
> A very interesting discussion and one we need to clear before we can move on IMvHO!
>
> Your comment:
>
> 	" ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable."
>
> Yes but we need to keep in mind the operation of LI and should be supportive of that.   It can be achieved without triangular routing, but we should not consider it as an after-thought.   It is a regulatory and business requirement for the operators and they will (and have) reject any technology which does not meet these needs.   That is why we are still seeing anchored GTP tunnels in Rel.15.
>
> 	Meanwhile, Eve and her cousins are busy watching the network and seeing which IP addresses are communicating with other IP addresses.  Eve and cohorts put their data together with Mal and cohorts' data and then is able to note that:  "Hey look, 	Alice is talking directly with Barb."
>
> Whilst I love your sarcasm,

You should see the original version I sent to Padma.  I toned it down.  :)

Would make for some great slides for the next IETF session!  If someone 
good at making such slides to a try at it...

Bob

>   there is another, less nefarious reason for the interception and that it is to do with allocation of resources and delivery against SLAs in mobile networks.    As mobile becomes the pre-dominant mode of connection to the Internet (driven by the trend to virtually zero cost we are witnessing in most geographies now for mobile packages), given that we have a very limited transport resource (RF spectrum), controlled access to and differentiated services over the Air Interface will be key to new services.  The ONLY reasons VoLTE works is because we have hard allocation of everything from radio bearer to packet-core and back.
>
> If we imagine a world where services other than default-bearer mobile broadband and dedicated bearer VoLTE exist (and this is the basic premise for 5G), then having knowledge of location, service and end-point is vital so that a) resources can be allocated and b) you (and I) can be billed for it appropriately.
>
> In terms of privacy, one aspect is missing from you critique - location.   A mobile operator will know simply from association of IMSI to IP address to GTP TEID exactly which cell(s) you are on.
>
> David
>
> -----Original Message-----
> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
> Sent: 18 October 2017 06:05
> To: ideas@ietf.org
> Subject: [Ideas] Addressing the privacy issues exposed by IDEAS
>
> I chose the subject line carefully as you will see by my analysis of the privacy issue(s).  I have discussed this with Padma before bringing this up to the list.
>
> Here is the privacy attack, as I see it:
>
> It is fairly well established that web sites collect a lot of personal information and information about the device(s) connected to that personal information.  IP addresses, even the actual address of NATed clients are part of the harvest.  Mal and his cousins are busy stealing this information and putting it all together in their own big data pile.
>
> Meanwhile, Eve and her cousins are busy watching the network and seeing which IP addresses are communicating with other IP addresses.  Eve and cohorts put their data together with Mal and cohorts' data and then is able to note that:  "Hey look, Alice is talking directly with Barb."
> Oh, look, they both moved to new addresses, but we can see it is still Alice and Barb.
>
> What is going on here?
>
> ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable.
> As long as these P2P communications use the same IP addresses as used in web Client/Server communications, the linkage is there to the privacy leakage occuring through those websites.
>
> Three things have to happen to protect the privacy of P2P communications from the swamp of privacy leakage in C/S communications.
>
> Identities need to be masked/hidden by both the ID/Loc technologies and IDEAS.
>
> Identifiers of all ilk, both in the control channel and the data channel need to change with each move using some Perfect Forward Secrecy (PFS) technology.
>
> Multiple IP addresses MUST be used, at least separating the P2P from C/S communications.  Different addresses for different P2P connections is wise.
>
> Note that if IDEAS-ID/Loc does everything to hide and confuse Identity/Identifier, it is all for naught if multiple IP addresses are not used.  At this point I should mention that TLS 1.3 may have a similar privacy risk, but that is for a different soapbox.
>
> Action plan:
>
> The IDEAS charter should say something like:
>
> "IDEAS will act as an enabling technology for the various ID/Loc technologies currently specified within the IETF.  As such it will result in a wider deployment of, mobile, Peer to Peer communications.
> Care will be taken in the design of the IDEAS technology not to enable the privacy leakage attacks in current Client/Server (predominately
> web-based) to be linked to these P2P communications."
>
> This means that whatever technology we come up for IDEAS will mask/hide PII/Identity/Identifier.  So that Eve is in the dark and we need only defend the IDEAS data store from Mal.
>
> Each ID/Loc technolgy (and this means ME with HIP) will need revisions to both their control and data plane (this means ESP for HIP) to change how Indentity and Identifiers are handled to break privacy tracking by Eve.  This may require using IDEAS as an enabler of privacy functions (I suspect I will need it in HIP to deal with the HI in the R1 packet).
> TLS 1.3 may also need revisions with its zero RT method.
>
> The final, and potentially big one that is outside the IETF's control is that OSs and ISPs MUST enable support for multiple addresses per host and let technologies within the hosts (like ID/Loc) to get addresses to provide privacy separation.  This ALSO extends to MAC addresses!  Eve could be tapping into those IPFIX flows (now there is a BIG privacy leakage attack that no one is talking about) and getting all the MAC/IP address mappings!
>
> One caveat that makes the multiple address not so big of a challenge is that ISPs are already providing some level of multiple address support by allowing hotspot usage on the mobile devices.  The IP address seen on the network MAY be from a given device or a device using it as a gateway.  This will become increasingly more common with automotive hotspots.  But this is NOT something we should count on as a mitigation of this privacy attack.
>
> ==========
>
> Conclusion
>
> IDEAS will analyse all security and privacy risks and include mitigation approaches in its design.
>
> I will take this attack to the HIP group for revisions there.  I already have some work going (fast moblity draft for one) that I can leverage to this purpose.
>
> I will reach out to the experts of other ID/Loc technologies (including
> MobileIKE) to discuss what they can do to ensure privacy as a design goal.
>
> Finally, as some of you know, my suit has a kevlar armor layer.  So have
> at it!   :)
>
> Bob
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Wed Oct 18 09:18:41 2017
Return-Path: 
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 8DED41321CB for ; Wed, 18 Oct 2017 09:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 qBlEJHstQCRs for ; Wed, 18 Oct 2017 09:18:38 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 E63B413301E for ; Wed, 18 Oct 2017 09:18:37 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id y23so6898715qkb.10 for ; Wed, 18 Oct 2017 09:18:37 -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=qV3TJXi7kaF74g833APqJ1D278J54pDmV92YJ0rIK8w=; b=MEYDg9lsgAOcGXGN33NWD2gtqpWazMPwbvPbEeduq8+a8TGWq8SUrFsPguW/lXJMQc 8mN2ZEHSu49tqJRjlWV10eupW1BTDpqNiV7ZW8XTn459oRtWkCGOvYb3rDOe4UIKYoo7 vgfED5ujBdmcPq4Ur0zbjMQeXv+Sptcx6PYT9uVeNs4w1HAaxl4op4bOCxxItd1RiF2C 73Qh6j6X/KSG0ENAY6yO2ToNteaH4MbcBm7vCoQNXyQotY+6SaBUs8SGI80TkezbvmZY xRVowCQLzjPFo4Lf93gZkHejLZAcbB+SiWUpFeDuzsNKX9/mO2nLL54rebIcrNRq9qdI cYnQ==
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=qV3TJXi7kaF74g833APqJ1D278J54pDmV92YJ0rIK8w=; b=e/lBJVR2ft3Grgoqzi1IJA62QTphA9pGJ23ncfTaTnX6f9ppaNfpwLBRBwFlZQXNXm N4A4V8rYvVtIcNvUTyCZoz+F2CaZksl+5+U1ZMt9d3lmp847+CG0PjPXQa2UpLQE1YVS KkeH0LL323nEH1zfPL/v3ImdVSiJ+uQR+yZyof157aIF41wT4BSrkvxMoBoy2/e5C4+U ScXKrUQTBtLvd7mlfi8E03FoYcNgVDC9RwcyOqDglLu/RWAUYUpCM+wlTUF+b93zHSmu D5zptejiZlXOyz2gkJRpBuMwBo1lAsrkKqWSCmZHJo1XoSfcVPshHUO+kXtOxuhny4AA hB1A==
X-Gm-Message-State: AMCzsaXD0bxK3rLrtiJIA8sAXHuqf4JwdwhWRSoaoSiIiCBXS96i1ftJ 6hAoIqshl2StFGVfsR0+3tuLJ/HSwg6akqKs6YUl4w==
X-Google-Smtp-Source: ABhQp+RUnAaaUxFaIybDrzdbfshwPLgHVofrUkcVm699AizCgWV9SaUBofSjYvV+WJXRIULNKyUwsBe4EFAHlXnsOWQ=
X-Received: by 10.55.106.132 with SMTP id f126mr2986491qkc.295.1508343516835;  Wed, 18 Oct 2017 09:18:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Wed, 18 Oct 2017 09:18:36 -0700 (PDT)
In-Reply-To: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com>
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com>
From: Tom Herbert 
Date: Wed, 18 Oct 2017 09:18:36 -0700
Message-ID: 
To: Robert Moskowitz 
Cc: "ideas@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 16:18:40 -0000

On Wed, Oct 18, 2017 at 6:04 AM, Robert Moskowitz
 wrote:
> I chose the subject line carefully as you will see by my analysis of the
> privacy issue(s).  I have discussed this with Padma before bringing this up
> to the list.
>
> Here is the privacy attack, as I see it:
>
> It is fairly well established that web sites collect a lot of personal
> information and information about the device(s) connected to that personal
> information.  IP addresses, even the actual address of NATed clients are
> part of the harvest.  Mal and his cousins are busy stealing this information
> and putting it all together in their own big data pile.
>
> Meanwhile, Eve and her cousins are busy watching the network and seeing
> which IP addresses are communicating with other IP addresses.  Eve and
> cohorts put their data together with Mal and cohorts' data and then is able
> to note that:  "Hey look, Alice is talking directly with Barb."  Oh, look,
> they both moved to new addresses, but we can see it is still Alice and Barb.
>
> What is going on here?
>
> ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer
> communications without any triangular routing achievable.  As long as these
> P2P communications use the same IP addresses as used in web Client/Server
> communications, the linkage is there to the privacy leakage occuring through
> those websites.
>
> Three things have to happen to protect the privacy of P2P communications
> from the swamp of privacy leakage in C/S communications.
>
> Identities need to be masked/hidden by both the ID/Loc technologies and
> IDEAS.
>
> Identifiers of all ilk, both in the control channel and the data channel
> need to change with each move using some Perfect Forward Secrecy (PFS)
> technology.
>
> Multiple IP addresses MUST be used, at least separating the P2P from C/S
> communications.  Different addresses for different P2P connections is wise.
>
Bob,

It's more than just using multiple addresses. Today carriers are
assigning multiple addresses giving /64s so that a UE is getting 2^64
addresses. The problem is that this is done by a prefix assignment for
each device which means the device is easily tracked by that. What we
want are multiple addresses with some specific properties for privacy.

Here the properties of addresses that I came up with:

     o They are composed of a global routing prefix and a suffix that
        is internal to an organization or provider. This is the same
property for IP
        addresses [RFC3513].

      o The registry and organization of an address can be determined by
        the network prefix. This is true for any global address.

      o The organizational bits in the address should have minimal
        hierarchy to prevent inferences. It might be reasonable to have
        an internal prefix that divides identifiers based on broad
        geographic regions, but detailed information such as location,
        department in an enterprise, or device type should not be
        encoded in a globally visible address.

      o Given two addresses and no other information, the
        desired properties of correlating them are:

         o It can be inferred if they belong the same organization and
           registry. This is true for any two global IP addresses.

         o It may be inferred that they belong to the same broad
           grouping, such as a geographic region, if the information is
           encoded in the organizational bits of the address.

         o No other correlation can be established. For example, it
           cannot be inferred that the IP addresses address the same
           node, the addressed nodes reside in the same subnet, rack, or
           department, or that the nodes for the two addresses have any
           geographic proximity to one another.

> Note that if IDEAS-ID/Loc does everything to hide and confuse
> Identity/Identifier, it is all for naught if multiple IP addresses are not
> used.  At this point I should mention that TLS 1.3 may have a similar
> privacy risk, but that is for a different soapbox.
>
> Action plan:
>
> The IDEAS charter should say something like:
>
> "IDEAS will act as an enabling technology for the various ID/Loc
> technologies currently specified within the IETF.  As such it will result in
> a wider deployment of, mobile, Peer to Peer communications.  Care will be
> taken in the design of the IDEAS technology not to enable the privacy
> leakage attacks in current Client/Server (predominately web-based) to be
> linked to these P2P communications."
>
> This means that whatever technology we come up for IDEAS will mask/hide
> PII/Identity/Identifier.  So that Eve is in the dark and we need only defend
> the IDEAS data store from Mal.
>
> Each ID/Loc technolgy (and this means ME with HIP) will need revisions to
> both their control and data plane (this means ESP for HIP) to change how
> Indentity and Identifiers are handled to break privacy tracking by Eve.
> This may require using IDEAS as an enabler of privacy functions (I suspect I
> will need it in HIP to deal with the HI in the R1 packet).  TLS 1.3 may also
> need revisions with its zero RT method.
>
> The final, and potentially big one that is outside the IETF's control is
> that OSs and ISPs MUST enable support for multiple addresses per host and

ISP support requires a protocol to do bulk address assignment. This is
supported with DHCP, although it would be nice to have a method to
compress addresses in a response to 64 bits (identifiers) assuming
they all have a common 64 bit prefix. Of course Android doesn't
support DHCPv6 so they're going to need to be convinced that /128
address assignments are a leap forward.

OSes support multiple addresses to be configured on an interface
(order of 1000s). But the use of addresses needs to change to support
privacy. The concept of different address per outgoing connection
needs to be implemented. The semantics of INADDR_ANY need to be
modified to restrict the addresses allowed for incoming connections
(this is already be worked on container virtualization). There's also
a few "philosophical" questions relating to expected uses of any
assigned address-- like how to deal with ICMP. For instance, should
all of the addresses assigned to a device respond to ping?

> let technologies within the hosts (like ID/Loc) to get addresses to provide
> privacy separation.  This ALSO extends to MAC addresses!  Eve could be
> tapping into those IPFIX flows (now there is a BIG privacy leakage attack
> that no one is talking about) and getting all the MAC/IP address mappings!
>
RFC4941 talks about the problem of embedding IEEE identifiers into
IPv6 addresses. That practice is no longer considered acceptable. In
some sense, identifier-locator takes this it's logical extreme where
the "identifier" used to create addresses changes at the time
granularity of every new connection.

> One caveat that makes the multiple address not so big of a challenge is that
> ISPs are already providing some level of multiple address support by
> allowing hotspot usage on the mobile devices.  The IP address seen on the
> network MAY be from a given device or a device using it as a gateway.  This
> will become increasingly more common with automotive hotspots.  But this is
> NOT something we should count on as a mitigation of this privacy attack.
>
I was thinking about this problem. The normal way to implement a hot
spot is to give a device a prefix and delegate addresses from that
prefix. But that means the prefix is encoded in addresses which breaks
the address privacy properties above. I think the alternative is to
just to assign a host spot a whole bunch of /128 addresses and let
them do what they please with them. They can delegate addresses to the
their tethered clients.  So devices in the identifier-locator network
may each be assigned 1000s of addresses, and device that are hot spots
for many clients may end up needing 100s of thousands or more. The net
result is that the mapping system is going to need to scale to very
large numbers, I am assuming the system will need to track more than
1T identifiers at scale. Not going to be easy :-)

Tom


From nobody Wed Oct 18 09:29:09 2017
Return-Path: 
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 7478C133055 for ; Wed, 18 Oct 2017 09:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 77Eo9OWWt_pr for ; Wed, 18 Oct 2017 09:29:05 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE7813304E for ; Wed, 18 Oct 2017 09:29:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 233BD60944; Wed, 18 Oct 2017 12:29:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z8Kr2+xcBZ74; Wed, 18 Oct 2017 12:28:56 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 56E6A62201; Wed, 18 Oct 2017 12:28:55 -0400 (EDT)
To: Tom Herbert 
Cc: "ideas@ietf.org" 
References: <9155d3fe-cbe2-ae2d-9c59-f3dee85b1409@htt-consult.com> 
From: Robert Moskowitz 
Message-ID: 
Date: Wed, 18 Oct 2017 12:28:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Addressing the privacy issues exposed by 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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 16:29:07 -0000

Tom,

Excellent analysis.  Thanks for this.

Bob

On 10/18/2017 12:18 PM, Tom Herbert wrote:
> On Wed, Oct 18, 2017 at 6:04 AM, Robert Moskowitz
>  wrote:
>> I chose the subject line carefully as you will see by my analysis of the
>> privacy issue(s).  I have discussed this with Padma before bringing this up
>> to the list.
>>
>> Here is the privacy attack, as I see it:
>>
>> It is fairly well established that web sites collect a lot of personal
>> information and information about the device(s) connected to that personal
>> information.  IP addresses, even the actual address of NATed clients are
>> part of the harvest.  Mal and his cousins are busy stealing this information
>> and putting it all together in their own big data pile.
>>
>> Meanwhile, Eve and her cousins are busy watching the network and seeing
>> which IP addresses are communicating with other IP addresses.  Eve and
>> cohorts put their data together with Mal and cohorts' data and then is able
>> to note that:  "Hey look, Alice is talking directly with Barb."  Oh, look,
>> they both moved to new addresses, but we can see it is still Alice and Barb.
>>
>> What is going on here?
>>
>> ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer
>> communications without any triangular routing achievable.  As long as these
>> P2P communications use the same IP addresses as used in web Client/Server
>> communications, the linkage is there to the privacy leakage occuring through
>> those websites.
>>
>> Three things have to happen to protect the privacy of P2P communications
>> from the swamp of privacy leakage in C/S communications.
>>
>> Identities need to be masked/hidden by both the ID/Loc technologies and
>> IDEAS.
>>
>> Identifiers of all ilk, both in the control channel and the data channel
>> need to change with each move using some Perfect Forward Secrecy (PFS)
>> technology.
>>
>> Multiple IP addresses MUST be used, at least separating the P2P from C/S
>> communications.  Different addresses for different P2P connections is wise.
>>
> Bob,
>
> It's more than just using multiple addresses. Today carriers are
> assigning multiple addresses giving /64s so that a UE is getting 2^64
> addresses. The problem is that this is done by a prefix assignment for
> each device which means the device is easily tracked by that. What we
> want are multiple addresses with some specific properties for privacy.
>
> Here the properties of addresses that I came up with:
>
>       o They are composed of a global routing prefix and a suffix that
>          is internal to an organization or provider. This is the same
> property for IP
>          addresses [RFC3513].
>
>        o The registry and organization of an address can be determined by
>          the network prefix. This is true for any global address.
>
>        o The organizational bits in the address should have minimal
>          hierarchy to prevent inferences. It might be reasonable to have
>          an internal prefix that divides identifiers based on broad
>          geographic regions, but detailed information such as location,
>          department in an enterprise, or device type should not be
>          encoded in a globally visible address.
>
>        o Given two addresses and no other information, the
>          desired properties of correlating them are:
>
>           o It can be inferred if they belong the same organization and
>             registry. This is true for any two global IP addresses.
>
>           o It may be inferred that they belong to the same broad
>             grouping, such as a geographic region, if the information is
>             encoded in the organizational bits of the address.
>
>           o No other correlation can be established. For example, it
>             cannot be inferred that the IP addresses address the same
>             node, the addressed nodes reside in the same subnet, rack, or
>             department, or that the nodes for the two addresses have any
>             geographic proximity to one another.
>
>> Note that if IDEAS-ID/Loc does everything to hide and confuse
>> Identity/Identifier, it is all for naught if multiple IP addresses are not
>> used.  At this point I should mention that TLS 1.3 may have a similar
>> privacy risk, but that is for a different soapbox.
>>
>> Action plan:
>>
>> The IDEAS charter should say something like:
>>
>> "IDEAS will act as an enabling technology for the various ID/Loc
>> technologies currently specified within the IETF.  As such it will result in
>> a wider deployment of, mobile, Peer to Peer communications.  Care will be
>> taken in the design of the IDEAS technology not to enable the privacy
>> leakage attacks in current Client/Server (predominately web-based) to be
>> linked to these P2P communications."
>>
>> This means that whatever technology we come up for IDEAS will mask/hide
>> PII/Identity/Identifier.  So that Eve is in the dark and we need only defend
>> the IDEAS data store from Mal.
>>
>> Each ID/Loc technolgy (and this means ME with HIP) will need revisions to
>> both their control and data plane (this means ESP for HIP) to change how
>> Indentity and Identifiers are handled to break privacy tracking by Eve.
>> This may require using IDEAS as an enabler of privacy functions (I suspect I
>> will need it in HIP to deal with the HI in the R1 packet).  TLS 1.3 may also
>> need revisions with its zero RT method.
>>
>> The final, and potentially big one that is outside the IETF's control is
>> that OSs and ISPs MUST enable support for multiple addresses per host and
> ISP support requires a protocol to do bulk address assignment. This is
> supported with DHCP, although it would be nice to have a method to
> compress addresses in a response to 64 bits (identifiers) assuming
> they all have a common 64 bit prefix. Of course Android doesn't
> support DHCPv6 so they're going to need to be convinced that /128
> address assignments are a leap forward.
>
> OSes support multiple addresses to be configured on an interface
> (order of 1000s). But the use of addresses needs to change to support
> privacy. The concept of different address per outgoing connection
> needs to be implemented. The semantics of INADDR_ANY need to be
> modified to restrict the addresses allowed for incoming connections
> (this is already be worked on container virtualization). There's also
> a few "philosophical" questions relating to expected uses of any
> assigned address-- like how to deal with ICMP. For instance, should
> all of the addresses assigned to a device respond to ping?
>
>> let technologies within the hosts (like ID/Loc) to get addresses to provide
>> privacy separation.  This ALSO extends to MAC addresses!  Eve could be
>> tapping into those IPFIX flows (now there is a BIG privacy leakage attack
>> that no one is talking about) and getting all the MAC/IP address mappings!
>>
> RFC4941 talks about the problem of embedding IEEE identifiers into
> IPv6 addresses. That practice is no longer considered acceptable. In
> some sense, identifier-locator takes this it's logical extreme where
> the "identifier" used to create addresses changes at the time
> granularity of every new connection.
>
>> One caveat that makes the multiple address not so big of a challenge is that
>> ISPs are already providing some level of multiple address support by
>> allowing hotspot usage on the mobile devices.  The IP address seen on the
>> network MAY be from a given device or a device using it as a gateway.  This
>> will become increasingly more common with automotive hotspots.  But this is
>> NOT something we should count on as a mitigation of this privacy attack.
>>
> I was thinking about this problem. The normal way to implement a hot
> spot is to give a device a prefix and delegate addresses from that
> prefix. But that means the prefix is encoded in addresses which breaks
> the address privacy properties above. I think the alternative is to
> just to assign a host spot a whole bunch of /128 addresses and let
> them do what they please with them. They can delegate addresses to the
> their tethered clients.  So devices in the identifier-locator network
> may each be assigned 1000s of addresses, and device that are hot spots
> for many clients may end up needing 100s of thousands or more. The net
> result is that the mapping system is going to need to scale to very
> large numbers, I am assuming the system will need to track more than
> 1T identifiers at scale. Not going to be easy :-)
>
> Tom
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Wed Oct 18 09:44:43 2017
Return-Path: 
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 4E35D132031 for ; Wed, 18 Oct 2017 09:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AHeR4m6vZzBc for ; Wed, 18 Oct 2017 09:44:41 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEC81321CB for ; Wed, 18 Oct 2017 09:44:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXZ74826; Wed, 18 Oct 2017 16:44:12 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 18 Oct 2017 17:44:11 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Wed, 18 Oct 2017 09:44:09 -0700
From: Uma Chunduri 
To: "ideas@ietf.org" 
Thread-Topic: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
Thread-Index: AQHTR5XBzhTtyxc/w0CsYMOotXbfdqLpxQKw
Date: Wed, 18 Oct 2017 16:44:09 +0000
Message-ID: <25B4902B1192E84696414485F57268541351464E@sjceml521-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.244.88]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59E784F6.01E6, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 43b90be12dc817f85ccc921e5186a203
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 16:44:42 -0000

VG9tLA0KDQoNCgk+R29vZ2xlIENsb3VkIGZvciBpbnN0YW5jZSBvcGVyYXRlcyBhIGh1Z2UgbXVs
dGktdGVuYW50IG5ldHdvcmsgYW5kIEkgc3VzcGVjdCB0aGV5IHVzZSBMT0FTIHRvIGF1dGhlbnRp
Y2F0ZSBhY2Nlc3MgdG8gDQoNCkNvbnRleHQgaGVyZSBpcyBub3Qgd2hlcmUgdG8gZGVwbG95IHRo
aXMgYnV0IGhvdyB0byBtYWtlIGEgbWFwcGluZyBzeXN0ZW0gd2hlcmUgaXQncyBhcHBsaWNhYmxl
IGZvciBtdWx0aXBsZSBlbnZpcm9ubWVudHMgKGVudGVycHJpc2UsIERDLCAgZXRjLi4pICAgd2l0
aCBmbGV4aWJpbGl0eSB0byB3b3JrIHdpdGggZXhpc3RpbmcgSUQvTE9DIHByb3RvY29scy4NCg0K
CT5JbiBteSBkZXNpZ24gZm9yIElMQSwgSSdtIGZvbmQgb2YgdXNpbmcgVExTIGZvciBjb21tdW5p
Y2F0aW9ucyB3aGljaCBwcm92aWRlcyBib3RoIHNlY3VyaXR5IChlbmNyeXB0aW9uKSBhbmQgdmVy
aWZpYWJsZSBpZGVudGl0eSBpbiBjZXJ0aWZpY2F0ZXMuIFRoZSBYLjUwOSBpZGVudGl0eSBjYW4g
YmUgdXNlZCB0byBhZ2FpbnN0IEFDTHMgdG8gY29udHJvbCByZWFkIGFuZCB3cml0ZSBhY2Nlc3Mu
IA0KDQpDb3VwbGUgb2YgdGhpbmdzOg0KMS4gSUxBIGlzIG9uZSBvZiB0aGUgZGF0YSBwbGFuZXMg
YW5kIGxvdCBvZiBpc3N1ZXMgeW91IHJhaXNlZCBpbiB0aGlzIHRocmVhZCBhcHBsaWNhYmxlIHRo
ZXJlIHRvbywgSU1PLiBXaGF0IHdlIHRob3JvdWdobHkgbG9va2VkIGludG8gd2VyZSB0aGUgZXhp
c3RpbmcgSUVURiBhcHByb3ZlZCBJRC9MT0MgdGVjaG5vbG9naWVzIChISVAgJiBMSVNQKSwgd2hl
cmUgdGhlcmUgYXJlIG11bHRpcGxlICBpbW1lZGlhdGUgdXNlIGNhc2VzDQoyLiBJIHdvdWxkIG5v
dGUgLSAgREMvVk0gd2l0aCBtdWx0aS10ZW5hbnQgbW9iaWxpdHkgaXMgb25seSBvbmUgb2YgdGhl
IHVzZSBjYXNlcyBmb3IgSURFQVMgLSBhbmQgQUZBSUsgeW91IGNvbnRyaWJ1dGVkIGEgbG90IGZy
b20gSUxBIHBvdi4NCjMuIE9uIHVzaW5nIFRMUy9YLjUwOSAgLSB3ZSBhcmUganVtcGluZyB3YXkg
YWhlYWQgb2Ygb3Vyc2VsdmVzIC0gd2UgY2FuIGNvbWUgYmFjayBvbiB0aGlzIGlmIHdlIGhhdmUg
KmEgd2cqDQo0LiBUaGUgYWJvdmUgYWxzbyBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIHRoZSBkZXZp
Y2UgaW4gcXVlc3Rpb24gdG9vIChmb3IgbG93IHBvd2VyIGRldmljZXMgIzMgbWF5IG5vdCBiZSBh
cHBsaWNhYmxlKS4NCjUuIFdlIGFsc28gb3VnaHQgdG8gc2VlICYgbGVhcm4gd2h5IEVBUC1BS0Eg
aXMgYWxsIG92ZXIgYW5kIHVzZWQgZm9yIGRlY2FkZXMgaW4gb3RoZXIgU0RPcyAoaW5jbHVkaW5n
IGZvciBub24tM0dQUCBhY2Nlc3MpICBhbmQgY29udGludWUgdG8gcGxheSBhIHNpZ25pZmljYW50
ICYgZXhwYW5kZWQgcm9sZSBpbiA1Ry4NCg0KCT5JZiB0aGlzIGlzIHRoZSBzYW1lIHRoaW5nIGFz
IGlkZW50aXR5IGJlaW5nIGRlc2NyaWJlZCBpbiBJREVBUyB0aGVuIEkgZ3Vlc3Mgd2UncmUgb24g
dGhlIHNhbWUgcGFnZS4uDQoNCkFmdGVyIG1vbnRocyBvZiBkaXNjdXNzaW9uIG9uIHRoaXMgbGlz
dCBvbiB0aGlzIHRvcGljIC0gdGhlIGFib3ZlIGluZGl2aWR1YWwgcHJlLXByZS13ZyBkb2N1bWVu
dCB3YXMgcHV0IHRvZ2V0aGVyIHRvIGFsbG93IHN0cnVjdHVyZWQgZmVlZGJhY2sgYW5kIHRvIGV2
b2x2ZSBvdXIgdGhpbmtpbmcgYXJvdW5kIHdoYXQgaGFzIHRvIGJlIGRvbmUgZm9yIHZhcmlvdXMg
cmVxdWlyZW1lbnRzLg0KQW55IGZ1cnRoZXIgZmVlZGJhY2sgaXMgd2VsY29tZS4uLg0KDQotLQ0K
VW1hIEMuDQo=


From nobody Wed Oct 18 10:34:50 2017
Return-Path: 
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 EBBEC132F7C for ; Wed, 18 Oct 2017 10:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 VKIgQvRLVs-c for ; Wed, 18 Oct 2017 10:34:47 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 632691270AB for ; Wed, 18 Oct 2017 10:34:47 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id o187so7214997qke.7 for ; Wed, 18 Oct 2017 10:34:47 -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=4QIa64Xl/JCxoh2UyUnCoycWTrnAkNFG71sbtovAwDE=; b=zjLmu2t0sX3zTSkg9W/XowgGzl8mB0OsILclwmKNwdYXqXNQAJoR+/+Q9huCsRj7ql yX9vUlzjqGqMLIZCCEx7hYb5QJt5p4dq6HR2Xn8PIqTHZ4Z1TEIXKiEKXJpnvdiY4ng9 Ihkb8qWtkELAenTPWU1uAXIcsvBCSQRE8pkzxXsilWZLTeVjTVkc6kLm5AwkWdk90FkB ugZCtpCBIdMSfZ2tAfdzbVOvL6dfZorqGG0EvTAW5tr/f/b8I11OwSXuwhpDtVCU4HqN QstcuFZR4FzCWqsRyJLiJODHKLKWUG2805OZfKQwCybu8TPWX26pzxiupB0CrRnlOjD5 hZ6w==
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=4QIa64Xl/JCxoh2UyUnCoycWTrnAkNFG71sbtovAwDE=; b=LJBRgtuadt9lbyKV+Hv65f/pz1lyxt+UJNok0tbJpJuL7IVTwbnjfTK0PhFMQgQLmV z0U1yP6aRd18Dl5EhNffqi8TThQPr2ST+RIhe1HhYXtxTtcg5/+plH6kwywaLLR8i9Kd 2CkcZmNHlXaOOX4M2etTnDC/OBw+QDbeXw9ShwOd3ioYZ7ryFJY5tvEnjrHr4mJEGJiM 0FaU+0W6LJbRIbK6x1Wh2k7UbfteCuTn0IfCWy91Teh9TXS4gwlXT8I3odcsUn/rVR6E M5qLqHf5/KjN8OhZQnVBjmyy0LQAzDbKQ+4cX67Rh8Po6yxgFENnk5c2Zlj2huwaVg3k pHaQ==
X-Gm-Message-State: AMCzsaX7UkQwRgaXo3HltQ1zb5YWdICUxbcMOKvZkZwspP/9cRGdaJUD Hpy5H8HXJivPzhg4QbEc8lPwIjP3pYBscpIntcptLA==
X-Google-Smtp-Source: ABhQp+ThY3RGXGN6wDTz5CTMq2GBvGbfNp2td7Rmlfr2AMyOSsylspfu3eDTzf+hYSWOsq8Om/neXPxbWBa14ySuhvM=
X-Received: by 10.55.148.70 with SMTP id w67mr3623470qkd.102.1508348086410; Wed, 18 Oct 2017 10:34:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Wed, 18 Oct 2017 10:34:45 -0700 (PDT)
In-Reply-To: <25B4902B1192E84696414485F57268541351464E@sjceml521-mbs.china.huawei.com>
References:  <25B4902B1192E84696414485F57268541351464E@sjceml521-mbs.china.huawei.com>
From: Tom Herbert 
Date: Wed, 18 Oct 2017 10:34:45 -0700
Message-ID: 
To: Uma Chunduri 
Cc: "ideas@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 17:34:49 -0000

On Wed, Oct 18, 2017 at 9:44 AM, Uma Chunduri  wrote:
> Tom,
>
>
>         >Google Cloud for instance operates a huge multi-tenant network and I suspect they use LOAS to authenticate access to
>
> Context here is not where to deploy this but how to make a mapping system where it's applicable for multiple environments (enterprise, DC,  etc..)   with flexibility to work with existing ID/LOC protocols.
>
>         >In my design for ILA, I'm fond of using TLS for communications which provides both security (encryption) and verifiable identity in certificates. The X.509 identity can be used to against ACLs to control read and write access.
>
> Couple of things:
> 1. ILA is one of the data planes and lot of issues you raised in this thread applicable there too, IMO. What we thoroughly looked into were the existing IETF approved ID/LOC technologies (HIP & LISP), where there are multiple  immediate use cases

The deployment of HIP and LISP pale in comparison to the deployed uses
of VXLAN, nvgre, ILA, and a few hacked up internal protocols that do
identifier-locator. If I wanted to build something practical and that
scales I'd be more inclined to look at what is being used and what
lessons can be learned.

> 2. I would note -  DC/VM with multi-tenant mobility is only one of the use cases for IDEAS - and AFAIK you contributed a lot from ILA pov.

To be clear, ILA is suitable for both the DC _and_ public wireless
network use cases. We are designing and implementing both for both use
cases.

> 3. On using TLS/X.509  - we are jumping way ahead of ourselves - we can come back on this if we have *a wg*

Sure, but my point is that people may have already have a solution for
this part of the problem. To say that mapping systems today have no
solution to security doesn't seem not correct. As we learned well in
nvo3, the industry doesn't wait for IETF!

> 4. The above also depends on the type of the device in question too (for low power devices #3 may not be applicable).

IMO its unlikely that low powered or end devices would directly access
the mapping system. In both the design for DC and  (likely design) for
wireless mobile networks the infrastructure uses identifier-locator to
implement an overlay network. In the DC case this is consistent with
the nvo3 architecture (i.e. identifier-locator is transparent to VMs).
In the same manner, the mobility in the mobile networks can be
implemented in the infrastructure. This is where some reference
network architecture on what actual and practical deployment would
look like helps.


From nobody Wed Oct 18 15:02:39 2017
Return-Path: 
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 A12391320DC for ; Wed, 18 Oct 2017 15:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, 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 rdV2qFLlVekz for ; Wed, 18 Oct 2017 15:02:35 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 4A0BA1321A1 for ; Wed, 18 Oct 2017 15:02:35 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id f8so12198393qta.5 for ; Wed, 18 Oct 2017 15:02:35 -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; bh=YlAtVLGDK/fa3wyfTb3+ZOW6BDWcfy+M6LSO4yLmp14=; b=S5G2UnCQJhgGQa9g3EEC9WrSbPbXqEVMYELuXwcYC94aCuRe0KBPfove54amSMdHLr 89v+UhaeT1mvSP5oF6h58fj/Z6+ClxIrIavSEj4/RXE9toQ5Uh+7WGe+zYJVUGklaUhK e37FW8kcHKP5iYJnXXsoy+Edz+w76mn7cIfBT/nZPHZu4lxVI1qB2DgFX+gCpdnxvTZn 6dlO0wR/UWNAlmeBEc5XQ/FlRObokVtmrlf8AMyRtqT5vdpjqeQIgNMtuWzw6oFYD2Dt qQnRqqDGvlOO66zZfmxW7U0gidBpC5A12Q2QxGWrt1Ef1OmYFaPY3i6BmiKEbf1in90W nrUw==
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; bh=YlAtVLGDK/fa3wyfTb3+ZOW6BDWcfy+M6LSO4yLmp14=; b=eIDvZ+tmodLJSgMgFgCJtD9kZmhRndH73mNQ55A4VTTBXsgBO5QFn3M6jlmT/UTFV+ 30T7JsbAJ3ICPPCNviQA78bwNy3fIsh18Qoh0b8kAcSp5UdaGyTcHuQpy76Q5Qp87v+h C5rad8d2xHTFEtEHKp0qQkOJfVWwIRbsWS0hBI/lAJE2hC/uEap4V+d1qsGgsAPy/8QQ /4YRdegwlzO3WEVialZwJU8/y40JXQZAh/oOSa3NQUQ5ClQtf8KuJ/5yZZIElnKJbk7a gynfxP6Yx67zi9SM2KB+gWMLYp061wRwvdzLyjPxR7U/2hdE/Nww4BJL5eGS9tFHqOK6 gc3g==
X-Gm-Message-State: AMCzsaXlgsAOaJesKB70RUusPhbHKh2JVhG1l2pV7OJfLb2uqV88Mf2o SAsgheRg9XFNV1kMMlZexphtQ2RgyUOddqez/5Is/g==
X-Google-Smtp-Source: ABhQp+Ta6QtvJbiuHv/LsDxzd0o8qL4NGJALNDwSTo8qKW/pPnaCfTMP6dSl9+ftmUOus1nY2o0kccLJRjEX4VodnnI=
X-Received: by 10.200.53.89 with SMTP id z25mr5601427qtb.58.1508364153098; Wed, 18 Oct 2017 15:02:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Wed, 18 Oct 2017 15:02:32 -0700 (PDT)
In-Reply-To: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com>
References:  <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com>
From: Tom Herbert 
Date: Wed, 18 Oct 2017 15:02:32 -0700
Message-ID: 
To: ideas@ietf.org
Content-Type: multipart/alternative; boundary="001a113edd8089b117055bd965ed"
Archived-At: 
Subject: [Ideas] Fwd: [v6ops] Google Alert - IPv6
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 22:02:38 -0000

--001a113edd8089b117055bd965ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This was forwarded to v6ops and seems apropos for IDEAS. I'm a little
surprised that only now are they realizing how good NAT is at hiding users'
identity. Ephemeral untraceable addresses and identifier-locator will give
at least the same privacy benefits (and hence unpleasantness for some) as
NAT without needing NAT.

Tom

[image: Google]

IPv6
Daily update =E2=8B=85 October 18, 2017
NEWS

Europol wants ISPs to aid law enforcement by dropping CGN technologies

Help Net Security
CGN was meant to be a temporary workaround for the problem arising from the
slow transition from IPv4 to *IPv6*. But, according to Europol, for some ..=
.
Europol cops lean on phone networks, ISPs to dump CGNAT walls that 'hide'
cyber-crooks

-
The Register
CGN has created an "online capability gap" between cyber criminals and law
enforcement, says ...

-
www.v3.co.uk
Full Coverage

[image: Google Plus]

[image:
Facebook]

[image:
Twitter]

Flag
as irrelevant

Europol Calls on Internet Providers to End CGNAT IP Address Sharing

ISPreview.co.uk (blog)
However the shift from the old IPv4 (ran out of spare addresses) to newer
*IPv6* addressing system has caused some providers, which don't have a ...
[image: Google Plus]

[image:
Facebook]

[image:
Twitter]

Flag
as irrelevant




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a113edd8089b117055bd965ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This was=
 forwarded to v6ops and seems apropos for IDEAS. I'm a little surprised=
 that only now are they realizing how good NAT is at hiding users' iden=
tity. Ephemeral untraceable addresses and identifier-locator will give at l=
east the same privacy benefits (and hence unpleasantness for some) as NAT w=
ithout needing NAT.

Tom

     
  =20
 
 
   <=
tr>  =
   =
=20
   
___________________________________=
____________

v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops




--001a113edd8089b117055bd965ed--


From nobody Thu Oct 19 14:57:06 2017
Return-Path: 
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 31CFD134303; Thu, 19 Oct 2017 14:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QMxy3WYjPAkW; Thu, 19 Oct 2017 14:56:50 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 500CD134316; Thu, 19 Oct 2017 14:56:50 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f4so19020951wme.0; Thu, 19 Oct 2017 14:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F7eeVCgz/xOptrVlsnzFftNAt5wQJy0UUhI/s+Ma38o=; b=frVvFTqufRHcnflHw3jw+u2U/tKv6bPE/EEmqPxQd+C8eIXyX/5YvmThIXqw3/8aGC 0vQHRZ+E1sOCzPTeR50Ax/H6kr0ePwvb2145jmCF3CHW9LxXjdJVSAoKM+wuK6LV8k3H jR7L3GymsLUpCa1BiJISODKHtaZjQXiXK9abz9D31caRrVcLEZXbHgYQzYgCxe2jDMiZ /HEJJWmKL1tqGtK48gSKI7TjN6XYqhVoPh/1KMk1iPwsAEzWTxSDMFaXKHtTuL32XUEF oVnulXUB0PTTnWAh4Vh1qnwHBllt/K8lDdneRR7zcNFHVPsCSL1W68rfO5rBtMzv02ch Ymmw==
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=F7eeVCgz/xOptrVlsnzFftNAt5wQJy0UUhI/s+Ma38o=; b=T2dtJGvzP9UYFM5qf+2026hNC2PHpup4HU73L7dCZMW0RqkNvQDC35KfoiuuBpZJso 4PVkrfdhWZ7/L0BsBwbCZigEzHD2Wa+PhHnEdww8KG3yiSr1P1m+sMDvk/u78HeVvclK k22hwxadUaQSM0c9a7kG4M3OS35iP7y9ahQ3OUIcbXuJ4KXXg1Sa/L4FCEu2gpe7TrIL b0IkxJbooUiPJtPnIXtjy9QGk7wM5m0a7Cw8rs2i0G+7Pw1k25Vs8YKv1I4htgfZ4193 0eZeylQnwWUzSSN59syB6YLbS73Iib6NEfSSQQDFBx1iYs7YZOR4Zbnql2nUveLF6tAL LohQ==
X-Gm-Message-State: AMCzsaVJXOabDpGIOPqfbqOudAlJ39yvn+UGiJ/s6KLre4lAHVxZx/UU hrMgT6mg1/n+vI5BDhw8SK91zr8qG9wzcZHjBpY=
X-Google-Smtp-Source: ABhQp+QKlDBUH3ohnEo1AVkI05dZ48GkvGFaqTn4MoIS2pSBB4hhiByhilo+FnsYNmJXvUZ67NYUO6a+ouD1QmiGAWo=
X-Received: by 10.28.178.81 with SMTP id b78mr2736577wmf.157.1508450208676; Thu, 19 Oct 2017 14:56:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.183.202 with HTTP; Thu, 19 Oct 2017 14:56:48 -0700 (PDT)
In-Reply-To: <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com> <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>
From: Alia Atlas 
Date: Thu, 19 Oct 2017 17:56:48 -0400
Message-ID: 
To: Dino Farinacci 
Cc: Robert Moskowitz , Eric Rescorla ,  ideas-chairs@ietf.org, Alissa Cooper , ideas@ietf.org,  Alvaro Retana , The IESG 
Content-Type: multipart/alternative; boundary="001a11443e36d9805e055bed6e10"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Oct 2017 21:56:58 -0000

--001a11443e36d9805e055bed6e10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dino,

I hear and understand your frustration and am, frankly, delighted to hear
that you are reaching out to the SD-WAN community.

In making a determination of work to be done, considering the broader
industry and associated eco-systems is critical.  Having sufficient
IETF community interest to do the work is also important - but sometimes
engagement happens after or when a WG is chartered.

As for the usual mantra, a standard pushback is that the IETF is as fast as
the volunteers who are supported to do the work....
Innovation is even more persuasive when it is an IETF RFC :-)

Please let me know if I can help.

Regards,
Alia

On Wed, Oct 11, 2017 at 3:59 PM, Dino Farinacci  wrote=
:

> > Dino and I are connected outside the IETF.  These groups come to us to
> talk, then go back and do their own thing to fill the void.  They will NO=
T
> come to the IETF, but will take what is offered.
>
> And of course, the typical mantra from them (and I know you all have hear=
d
> this before):
>
> (1) The IETF is too slow.
>
> (2) The IETF cannot decide.
>
> (3) The IETF has too many options. So we are going to pick one and put ou=
r
> Intellectual Property on top of it (i.e. SD-WAN IPsec doesn=E2=80=99t int=
eroperate).
>
> (4) We can do protocols better and faster than the IETF.
>
> (5) We want to build our own protocols so we look innovative.
>
> (6) We can get strategic interoperability with our business partners.
>
> Dino
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>

--001a11443e36d9805e055bed6e10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dino,

I hear and understand your frustr=
ation and am, frankly, delighted to hear that you are reaching out to the S=
D-WAN community.

In making a determination of work=
 to be done, considering the broader industry and associated eco-systems is=
 critical.=C2=A0 Having sufficient
IETF community interest to do =
the work is also important - but sometimes engagement happens after or when=
 a WG is chartered.

As for the usual mantra, a sta=
ndard pushback is that the IETF is as fast as the volunteers who are suppor=
ted to do the work....
Innovation is even more persuasive when it=
 is an IETF RFC :-)

Please let me know if I can he=
lp.

Regards,
Alia

On Wed, Oct 11, 2017 at 3:5=
9 PM, Dino Farinacci <farinacci@gmail.com> wrote:
> Dino and I are connected ou=
tside the IETF.=C2=A0 These groups come to us to talk, then go back and do =
their own thing to fill the void.=C2=A0 They will NOT come to the IETF, but=
 will take what is offered.



And of course, the typical mantra from them (and I know you all have=
 heard this before):



(1) The IETF is too slow.



(2) The IETF cannot decide.



(3) The IETF has too many options. So we are going to pick one and put our =
Intellectual Property on top of it (i.e. SD-WAN IPsec doesn=E2=80=99t inter=
operate).



(4) We can do protocols better and faster than the IETF.



(5) We want to build our own protocols so we look innovative.



(6) We can get strategic interoperability with our business partners.




Dino

_______________________________________________

Ideas mailing list

Ideas@ietf.org

https://www.ietf.org/mailman/listinfo/ideas





--001a11443e36d9805e055bed6e10--


From nobody Thu Oct 19 17:58:32 2017
Return-Path: 
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 D3E4D134965; Thu, 19 Oct 2017 17:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 PU8D4pgMns_a; Thu, 19 Oct 2017 17:58:23 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 62F1F13495A; Thu, 19 Oct 2017 17:58:22 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id z50so16709493qtj.4; Thu, 19 Oct 2017 17:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yAB4H6p8Au3+fP9shIidZ+gCUBMU7U/tFYcfO9zmGx0=; b=WgXlNHWQot32SBlq9hhOhdymtVoTuWjFlBCvxSVk4x7sW9FbiGRQjnLBfVmWMs5qdr xo815bwdMusyVexloelrOOxq0opTKZ6JywgLAaK2t4bNLX0lTUwxeGLTEYVJ03lLWSAK E/yNZPAIq8qjxnwzs9NyYpG3c+8K1AV/zHp3vhg6DLvNqmQVgny1mvwpQQqAL7e2IiQi OTJqJ1iQmyGWbPBejGfp17SDFqvmKvQFfYcdAsWNtAE0LRaTOpp4NOmGWP20QnCy8OJD CaVc1vLMECmPKkPL3shDMl44wiHWbku0KIQggNbxfs4oP/YzYzPu0Xt3Ge+scE4wO7I4 E6Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yAB4H6p8Au3+fP9shIidZ+gCUBMU7U/tFYcfO9zmGx0=; b=pcJoxsXd788507eZNm83eMMD+Bes2suUxplJBQX671ayw5EV2CJ+IPDkzeVXeT7HKb KQKhT1q4gCyu9oLJVW+vfaW5t57Afyb3PagzFPipBIuYxBni2H2nDFmjKmJmmJMp6vg9 1WoSdtkgOf43JQhZ+RmpModDACBIediunIZ1YSuTfwsugmEKTKu8+SBzfX3oVGXz1X6a 5rSiJkdqgw4SHAK31iZgIDpT6i3lXiK3TPQVomdhthrQPX/2ZwjuYp3abKY3PRVpm2Ei GLuAG/zhOcyc/VScQnNvW6h2Y4JKlEr2I44FctyKwq5EFZ11ooUChcC2D6i7x9n9LGKf CEXA==
X-Gm-Message-State: AMCzsaX4fGauMT2HFUF/U8L+Z4cd+bz6sNJwwdj4L8e8GoxdJ8AIOaW5 oud7hndo69KeMX6QDpNT7mM=
X-Google-Smtp-Source: ABhQp+SYo8+gVlzLsV2IExGtoVm5rTeB7pS7oamZ1eqxgfuYZJpoYS0egOO7ZgZ4vwp7vo5Ay2g2xQ==
X-Received: by 10.200.20.146 with SMTP id l18mr4714365qtj.189.1508461100683; Thu, 19 Oct 2017 17:58:20 -0700 (PDT)
Received: from ?IPv6:2600:380:591c:9c83:99f3:13ea:87f8:f9d3? ([2600:380:591c:9c83:99f3:13ea:87f8:f9d3]) by smtp.gmail.com with ESMTPSA id g23sm8576186qta.35.2017.10.19.17.58.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 17:58:19 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Dino Farinacci 
X-Mailer: iPhone Mail (15A421)
In-Reply-To: 
Date: Thu, 19 Oct 2017 20:58:19 -0400
Cc: Robert Moskowitz , Eric Rescorla , ideas-chairs@ietf.org, Alissa Cooper , ideas@ietf.org, Alvaro Retana , The IESG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <12F16851-7B26-47E3-9B27-AB97A1C7B34D@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com> <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com> 
To: Alia Atlas 
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Oct 2017 00:58:25 -0000

> As for the usual mantra, a standard pushback is that the IETF is as fast a=
s the volunteers who are supported to do the work....

Okay then, let=E2=80=99s get going with the work. I=E2=80=99ll be at the fir=
st IDEAs WG in Singapore.=20

I am not alone here.=20

The volunteers are just as fast as the IETF supports them.=20

Dino=


From nobody Fri Oct 20 08:18:26 2017
Return-Path: 
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 E47F613420F; Fri, 20 Oct 2017 08:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 rVdaMD6i93Nl; Fri, 20 Oct 2017 08:18:24 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 509AF126D0C; Fri, 20 Oct 2017 08:18:24 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id b15so14701064qkg.9; Fri, 20 Oct 2017 08:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=I1bipAeC1UEhdUYZ03sXafzS6UND3TiLuCIq0jvRVgc=; b=d0mO+SAvV1DZhzgl55MFgaZpO3OoItxeKLdMd9tRr3mymlC+BedFQPL7SrtEvbjMEQ gCzzabxpvYqSyCrxoe2YUm7T0eVi5J75DW6NZnMiMPtQnpK0Q4ANXc6/RDLJBNx8IXk9 UtUvqQG/M0w8BEyPiayX1bZmNX57sfCvXws3Q4qIfmxtCszPKyghLOtdiEmYVKpI/4/X aMtP3Fc0VbW+IWlX3xPIT+DVyNxacPUiL/KK5xlOtnxZ/FxKbzLrjxkG2b4aTjeGpgVn zRdWc8paiYHGKVFUoBG8WzJpZg9KVps5RFIJxTYK2hbRJcl5xVobAeQiBSDrzHLjHKHm fxRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=I1bipAeC1UEhdUYZ03sXafzS6UND3TiLuCIq0jvRVgc=; b=a+kTps9uacLyp6L+qM0yJepujSKGLmg1Z6bCmZCC1U1t7O6x6zUqS90qgBzm4h9LSa 7VbS/uFOdi/q9RInswTR3ErhsggmwE68oAOGRjunW20db8XKMmMjOz6f18yXDRyseY95 arZRF5qgO6YqsmAFrNGNL2kvmoW3zruR4CkTAQpNaJPKw3xV72Z3bDk02hrk1sZGKsej 7JJUT2gn7UIUMYb7HbsJH1JQ7kQKogXq3emszRYZ+pL1YG04oJ/cm3s39T28ddHNSQOT Gcv/Pc3MhYYwFWja5WhZEij+M6mLRmoWpb+t3LA2rzJiTie6HHOb4bMJspa7fzkfIiZ9 km6g==
X-Gm-Message-State: AMCzsaXeXw3foBRv2gYTcIFZhZg4CE9nls2qnfz+c65FBE97d4wgo1MQ EGwz3j66RCIJukxcOe5P0YO7W9jw
X-Google-Smtp-Source: ABhQp+SV0TaAHqBAoB0FJG1WybBJbfQIfC1p9g6NBQL8NvUHCoMNmWdYYMoQfIdzW++ahmCl2wEOxg==
X-Received: by 10.55.212.80 with SMTP id l77mr7512460qki.82.1508512702626; Fri, 20 Oct 2017 08:18:22 -0700 (PDT)
Received: from host-4-139.cnri.reston.va.us (cnri-7-62.cnri.reston.va.us. [132.151.7.62]) by smtp.gmail.com with ESMTPSA id x35sm727476qte.26.2017.10.20.08.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 08:18:21 -0700 (PDT)
To: Dino Farinacci , Alia Atlas 
Cc: Eric Rescorla , Robert Moskowitz , ideas-chairs@ietf.org, Alissa Cooper , ideas@ietf.org, Alvaro Retana , The IESG 
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com> <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>  <12F16851-7B26-47E3-9B27-AB97A1C7B34D@gmail.com>
From: Sam Sun 
Message-ID: <13d29ea0-255d-c01a-1a6d-984fd66b5deb@gmail.com>
Date: Fri, 20 Oct 2017 11:18:15 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <12F16851-7B26-47E3-9B27-AB97A1C7B34D@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Oct 2017 15:18:26 -0000

I second Dino on this.

Sam


On 10/19/17 8:58 PM, Dino Farinacci wrote:
>> As for the usual mantra, a standard pushback is that the IETF is as fast as the volunteers who are supported to do the work....
> Okay then, let’s get going with the work. I’ll be at the first IDEAs WG in Singapore.
>
> I am not alone here.
>
> The volunteers are just as fast as the IETF supports them.
>
> Dino
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas


From nobody Fri Oct 20 08:44:28 2017
Return-Path: 
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 56C001342CE; Fri, 20 Oct 2017 08:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3Ga7O3PHiPQB; Fri, 20 Oct 2017 08:44:24 -0700 (PDT)
Received: from lucky1.263xmail.com (lucky1.263xmail.com [211.157.147.134]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26921342C5; Fri, 20 Oct 2017 08:44:23 -0700 (PDT)
Received: from langao?cdi.cn (unknown [192.168.165.105]) by lucky1.263xmail.com (Postfix) with ESMTP id 72DE27F0F; Fri, 20 Oct 2017 23:44:16 +0800 (CST)
X-263anti-spam: KSV:0;BIG:0;
X-MAIL-GRAY: 0
X-MAIL-DELIVERY: 1
X-KSVirus-check: 0
X-ADDR-CHECKED: 0
X-ABS-CHECKED: 0
X-SKE-CHECKED: 0
X-ANTISPAM-LEVEL: 2
Received: from mail-pf0-f174.google.com (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTPA id C5EAF423; Fri, 20 Oct 2017 23:44:13 +0800 (CST)
X-RL-SENDER: langao@cdi.cn
X-FST-TO: ideas-chairs@ietf.org
X-SENDER-IP: 209.85.192.174
X-LOGIN-NAME: langao@cdi.cn
X-UNIQUE-TAG: 
X-ATTACHMENT-NUM: 0
X-SENDER: langao@cdi.cn
X-DNS-TYPE: 1
Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com [209.85.192.174]) by smtp.263.net (Postfix) whith ESMTP id 221864XI9SI; Fri, 20 Oct 2017 23:44:15 +0800 (CST)
Received: by mail-pf0-f174.google.com with SMTP id n14so11588168pfh.8; Fri, 20 Oct 2017 08:44:15 -0700 (PDT)
X-Gm-Message-State: AMCzsaUovjYulV7Dm2AKyeFRVNjJIN1r26VZ4MR9ck289fg2uX11ujPW PoNCGmgfSpEoO6a2050PfaG6mTWL6AVNuJ2qhUw=
X-Google-Smtp-Source: ABhQp+QvBVSF6oc0OuLT00l3Xznm4/HX5jSH6cMijQtLpTMjM5Y/1B3T2NpOXs8VQwJV0+oZcjAWUNHXteN8sbLynjs=
X-Received: by 10.101.69.6 with SMTP id n6mr4823351pgq.290.1508514251293; Fri, 20 Oct 2017 08:44:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.159.9 with HTTP; Fri, 20 Oct 2017 08:44:10 -0700 (PDT)
In-Reply-To: <12F16851-7B26-47E3-9B27-AB97A1C7B34D@gmail.com>
References: <150773363527.24819.15137383317907133805.idtracker@ietfa.amsl.com> <47ABE650-B83D-4400-B27C-C0E5F1C8BA13@gmail.com>   <398a807d-f998-8136-d0ca-24841cff4ac5@htt-consult.com> <8DCD1593-5B71-4404-A041-E08EE04826BF@gmail.com>  <12F16851-7B26-47E3-9B27-AB97A1C7B34D@gmail.com>
From: Lan Gao 
Date: Fri, 20 Oct 2017 23:44:10 +0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dino Farinacci 
Cc: Alia Atlas , Eric Rescorla ,  Robert Moskowitz , ideas-chairs@ietf.org,  Alissa Cooper , ideas@ietf.org, Alvaro Retana , The IESG 
Content-Type: multipart/alternative; boundary="089e0822d4ac164a77055bfc58df"
Archived-At: 
Subject: Re: [Ideas] Alissa Cooper's Block on charter-ietf-ideas-00-06: (with BLOCK)
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Oct 2017 15:44:27 -0000

--089e0822d4ac164a77055bfc58df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Definitely not alone. The IETF and the Volunteers are codependent. Neither
of us can move forward if the other doesn't support its counterpart.
Hopefully we can make IDEAs into something that benefits us all.

On Fri, Oct 20, 2017 at 8:58 AM, Dino Farinacci  wrote=
:

> > As for the usual mantra, a standard pushback is that the IETF is as fas=
t
> as the volunteers who are supported to do the work....
>
> Okay then, let=E2=80=99s get going with the work. I=E2=80=99ll be at the =
first IDEAs WG in
> Singapore.
>
> I am not alone here.
>
> The volunteers are just as fast as the IETF supports them.
>
> Dino
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>



--=20
*Lan Gao*
Primary internet Platform Manager | Content Digital Innovation Technology
Phone: (+86)13439899334
Web: www.cdi.cn

--089e0822d4ac164a77055bfc58df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Definitely not alone. The IETF and the Volunteers are=
 codependent. Neither of us can move forward if the other doesn't suppo=
rt its counterpart. Hopefully we can make IDEAs into something that benefit=
s us all.

On Fri, Oct 20, 2017 at 8:58 AM, Dino Farinacci <farin=
acci@gmail.com> wrote:
> As for the usual mantra, a standard pushback is that the =
IETF is as fast as the volunteers who are supported to do the work....



Okay then, let=E2=80=99s get going with the work. I=E2=80=99ll be at=
 the first IDEAs WG in Singapore.



I am not alone here.



The volunteers are just as fast as the IETF supports them.




Dino

_______________________________________________

Ideas mailing list

Ideas@ietf.org

https://www.ietf.org/mailman/listinfo/ideas





-- 
=

Lan Gao
Primary internet Platfo=
rm Manager | Content Digital Innovation Technology
Phone: (+86)13439899334




--089e0822d4ac164a77055bfc58df--


From nobody Wed Oct 25 08:14:10 2017
Return-Path: 
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 2922513F3F4; Wed, 25 Oct 2017 08:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Ue3zxxavTtdF; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A939F13F3D0; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 87E9D460160; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1508944427; bh=MRs/LV3BcnotPN+9F219xsr+m6bkbw0jA3rNzmHjDl4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AM0YuCsAXPdjqIE51gW+R+bPEAHqoP7asqoPIlbmae9Up0QqoVW0ZVDz9ZJ8mWwN2 4cBPuPZWibdYmZyPWTxBQV+Io67BdpuzCr9poIzV2nplaW0FW4FaQ8ovS/S0eA568/ ZUuFixyNzG8MgujQQJjoF8XVfxDDcCrOTACvtsqQ=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [97.65.134.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A147F2407FB; Wed, 25 Oct 2017 08:13:46 -0700 (PDT)
To: Sharon , Padma Pillay-Esnault 
Cc: ideas@ietf.org, NVO3 , LISP mailing list list , routing-discussion@ietf.org
References:  
From: "Joel M. Halpern" 
Message-ID: 
Date: Wed, 25 Oct 2017 11:13:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Ideas] [lisp] IDEAS @IETF98 Minutes
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." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Oct 2017 15:13:54 -0000

Regarding the second of your two points, I am not following you:

On 10/11/17 8:00 PM, Sharon wrote:
> Discussed these 2 ID networking items with Albert and others, perhaps 
> this is a good thread:
> 
...
> 
> 2. Lisp-Lambda -
> A serverless (or virtual-appliance-less) alternative to service function 
> chaining which is hard to scale and dev-ops. Its done by mapping flows 
> at the ITR, ETR, or STR (segment) to queues, and using the mapping to 
> invoke the (cached) function on the flow queue packets rather then hair 
> pining the packets in and out of function virtual appliances. Saves 
> nic-ram-nic-ram... costly lifting.
> 

I am not asking why or how one can use LISP to direct traffic.  I 
understand that.
Rather, the description of service function chaining is veyr confusing.
1) One of the points of SFC is to direct packets to virtual service 
functions.  We are not mandating virtual service functions, but rather 
enabling their use when operators want to use them.  A technique that 
avoids such direction would seem to prevent such usage, defeating the point.
2) NSH (and more generally SFC) can be used to direct traffic on paths 
that do not happen to touch any service functions.  If the service 
function path goes through a sequence of service function forwarders, 
but does not actually visit any service functions, nothing is violated.

So while I have no problem with using LISP for chaining (either using 
LISP mapping to drive NSH SFPs or using LISP multi-hope technology for 
the data plane) I find the explanation you provided avoce confusing.

Yours,
Joel


 
    3D"Googl=    
  
    IPv6  Daily update =E2=8B=85 October=
 18, 2017      
   NEWS    
       
    
    
    Europol Calls on Internet Providers to End CGNAT IP Addr=
ess Sharing    
 
  However the shift from the old IPv4 (ran out of spare addresses) to n=
ewer IPv6 addressing system has caused some providers, which don'=
;t have a=C2=A0...
 
   
 
   3D"Google    3D"Faceboo=    3D"Twitter"    Fla=
g as irrelevant