From nobody Wed Nov 1 10:21: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 8AA1013F9AA; Wed, 1 Nov 2017 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 FDvC12faLQUP; Wed, 1 Nov 2017 10:21:51 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4905C13F991; Wed, 1 Nov 2017 10:21:51 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5560358C4F6; Wed, 1 Nov 2017 18:21:46 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 405ABB0D054; Wed, 1 Nov 2017 18:21:46 +0100 (CET) Date: Wed, 1 Nov 2017 18:21:46 +0100 From: Toerless Eckert To: Christian Huitema Cc: Padma Pillay-Esnault , "ideas@ietf.org" , "lisp@ietf.org list" , Dino Farinacci , "ietf@ietf.org" Message-ID: <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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, 01 Nov 2017 17:21:54 -0000 On Wed, Oct 11, 2017 at 12:34:19PM -0700, Christian Huitema wrote: > 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. Sure, but i don't think it can be generalized: There will be more and more non-individually owned nodes in public and corporate infrastructures where requirements will be quite different from those derived from individual human privacy. If lets say those long term identifiers do not provide good human privacy protection but good communications security properties and managed transpacency for regulators then they could still be a great benefit for those class of nodes. [rant] Trying to get more privacy into network layer is like making tobacco more organic. You can get buried in the organic section of the graveyard after you die of lung cancer. Great success! Aka: Where is the IETF on any warnings, architectures or recommendations on the actual application layer: "Inhaling of this web page / IoT device will expose your personal activities related to it, social security number and credit card information to a "trusted set" of 1000 collaborating web services companies of which 10 at least have already been fined several times for leaking your information - and then made even more money out of it" (sorry, just can't get beyond the fact that equifax is not making money out of their leakage...) Should come with every mayor web page and IoT device. [/rant] Venting aside, i'd actually love to understand better if/what IETF does for privacy inside eg: a TLS payload, besides sipbrandy/dprive/perc ? Cheers Toerless > -- > Christian Huitema > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas From nobody Thu Nov 2 08:30: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 9FAA3136001 for ; Thu, 2 Nov 2017 08:30:17 -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=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 Bh6NrAopGiEl for ; Thu, 2 Nov 2017 08:30:16 -0700 (PDT) Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::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 8933613A2B8 for ; Thu, 2 Nov 2017 08:30:12 -0700 (PDT) Received: by mail-ua0-x243.google.com with SMTP id e46so4256372uaa.4 for ; Thu, 02 Nov 2017 08:30: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=0YDnVodjsKJZ2cUlNPs3xCRZ2v1Gqd4oIuQfAYOb0UA=; b=aQP8Ld6FPuvOoizzw+kIms8wQEteGVMMoLsRFy2NgH/9zAG4fNj5cTBBz8iwgS5CMy FqZR2m9r3ZPYrFzKdcOPUgCU0K/M9lmF8G83O/s10V4JFcqzoykaFX4GCmVgj5xyEbn9 lk0cceqw9LBB8ZwbGL9JjSTZoJ4HM2WdhUjluwI8uVdqky7u7DHuoNnX3+ruIM9UUkwt UNBgJVt6KKSO0KbWhEbYERUmNzEpzIpiE11V2DTl3ZW69w/FMdWDsbDyvj7dZao119Eo pvL4JM/L+1Pp5tv786YrPidQsBFP/NfXNxGg7C0sTXMuvtSNAQVIE1x6k2j9lixm/OXa mHIQ== 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=0YDnVodjsKJZ2cUlNPs3xCRZ2v1Gqd4oIuQfAYOb0UA=; b=mJaXH/vCuN7EVcYabHBQz9WfQul5Ft9cGPxZ/LWZFcdqrueejUdT+fY/iszL/osYdw WA77QmhnJkqtvSWCbofvdVEstU2MRxIi93Glb8t9VCwozKilzIHdCdDEGVUz+SmoEHTa HoLWglD5VkWU0Ax1wSAFHhu4WSWRy1NQ1L9lrqHPMzGZjkg2RTUSZ+a7k076OGmxw8eT K34JcciWx719RhhnYQSErOkGHXaBynNePbCQeORz8B4C85LWaX6lCUzuQPtO0rzRbs12 22SBXl0bsHqjO+MbedrPu8VXxI4fnLBcMbjTrSNd5VWSYCqL4Rp3sDwesiqPYXgRdlRi R7rw== X-Gm-Message-State: AMCzsaUFq/xwklbKLCo0o05ugvIaX1ZC5QoXWDREB33/Kd2A8WiVB9XU StP1jSFQFF5m5HQ0aGpR/FIMzTftA+PjUJNu5tYX1g== X-Google-Smtp-Source: ABhQp+SaVrAbsJKwiDzMP1+5KlJmpV1k4uBCkBZpvil031q2Iy+MRpGrmCvZ8oxQFGIW2i8WWmHjAxDaqOr8QxeJuLA= X-Received: by 10.176.83.206 with SMTP id l14mr3297045uaa.167.1509636611570; Thu, 02 Nov 2017 08:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.69.4 with HTTP; Thu, 2 Nov 2017 08:30:11 -0700 (PDT) In-Reply-To: <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> References: <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> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Thu, 2 Nov 2017 08:30:11 -0700 Message-ID: To: Toerless Eckert Cc: Christian Huitema , Padma Pillay-Esnault , "ietf@ietf.org" , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" 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: Thu, 02 Nov 2017 15:30:18 -0000 On Wed, Nov 1, 2017 at 10:21 AM, Toerless Eckert wrote: > On Wed, Oct 11, 2017 at 12:34:19PM -0700, Christian Huitema wrote: >> 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. > > Sure, but i don't think it can be generalized: > > There will be more and more non-individually owned nodes in public and > corporate infrastructures where requirements will be quite different > from those derived from individual human privacy. > Toerless, That maybe true, but personal devices, such as smart phones and cars that are associated with individuals, are hardly going away anytime soon. How addresses are assigned to these devices has a material impact on individual privacy. Even right now there are two long threads on v6ops right now that are delving precisely into privacy of IPv6 addresses that may be relevant. This includes discussion about CGNAT and efforts by some governments to illegalize it because the privacy it gives is too strong for law enforcement. > If lets say those long term identifiers do not provide good human > privacy protection but good communications security properties and > managed transpacency for regulators then they could still be a great > benefit for those class of nodes. > > [rant] > > Trying to get more privacy into network layer is like making > tobacco more organic. You can get buried in the organic section > of the graveyard after you die of lung cancer. Great success! > > Aka: Where is the IETF on any warnings, architectures or recommendations > on the actual application layer: > Maybe there should be something like that. But, not unlike security, if the goal is to derive a system with good privacy characteristics then privacy should be considered at every layer including the networking layer. Tom From nobody Fri Nov 3 10:53: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 4B9C513FF0F; Fri, 3 Nov 2017 10:53:05 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Zdsrjj_Hox1d; Fri, 3 Nov 2017 10:53:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3344C13FF0E; Fri, 3 Nov 2017 10:53:03 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0E70058C4B2; Fri, 3 Nov 2017 18:52:59 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E996CB0D084; Fri, 3 Nov 2017 18:52:58 +0100 (CET) Date: Fri, 3 Nov 2017 18:52:58 +0100 From: Toerless Eckert To: Tom Herbert Cc: Christian Huitema , Padma Pillay-Esnault , "ietf@ietf.org" , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Message-ID: <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 03 Nov 2017 17:53:05 -0000 Thanks, Tom, inline On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: > Toerless, > > That maybe true, but personal devices, such as smart phones and cars > that are associated with individuals, are hardly going away anytime > soon. How addresses are assigned to these devices has a material > impact on individual privacy. Even right now there are two long > threads on v6ops right now that are delving precisely into privacy of > IPv6 addresses that may be relevant. This includes discussion about > CGNAT and efforts by some governments to illegalize it because the > privacy it gives is too strong for law enforcement. Sure. All i was saying is that we should not dismiss solutions if they do not help to improve privacy. It reminds me of the congestion control principles and the fact that a lot of money is made with video in controlled networks without congestion control. As in: "Sorry, we couldn't build a great solution for sensor devices in manufacturing plants because those solutions wouldn't pass the privacy bar". I am not even aware if we have good characterizations of solutions vs. privacy like IMHO we have for congestion control, but of course its a more complex topic. (IMHO: lot more cases IMHO to distinguish). That being said, i would of course love to see that we leverage IDEAs to also create options that (could) enhance privacy, i just don't think that we will make a lot of progress if we can not do this work in a WG but if all the complex issues have to be resolved on pre-wg mailing lists before even charters are accepted. This is part of whats wrong with the IETF if i may say so. For example, Christian contested that long lived identifiers help to improve privacy (for device = individual case) and those arguments about privacy had the IESG turn their opinions. IMHO: The long-lived identifiers are meant to be functionally limited. You do increase the bar of identifying an individual when you do this because the web applications need to do more work to correlate application layer information across multiple functional identifiers. So, how & where do we even create a common understanding about the qualitative and quantitative privacy benefits of technology options if not in a WG. Functional identifiers just being one example. Even more fundamentally: If each individual application layer function requires authentication via e.g.: government, google or facebook ID, and all those web services are free to correlate their information in the backend, any network layer privacy work is just like growing organic tobacco. Which is why i really would like to know what the state of requirements/BCP etc. is re. privacy at app layer in the IETF, because without that knowledge, i can only define the privacy benefits of a network layer enhancement under the ASSUMPTION of particular application behavior. My impression of IETF policy is "you have to trust the web services provider (not to share/correlate/abuse user/client information)" and in the same breath "you can not trust the network service provider (to behave in the same way)". Would love to get pointed to documents proving this impression to be wrong. Especially the option that there can be network providers that users may want to trust more than arbitrary web services providers should IMHO be acknowledged. And thats definitely an option i think is worthwhile to build solutions against. Cheers Toerless > Tom From nobody Sat Nov 4 09:34: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 2123813FB7D for ; Sat, 4 Nov 2017 09:34:11 -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=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 QFsYI6r4ImSo for ; Sat, 4 Nov 2017 09:34:09 -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 D987813FB8F for ; Sat, 4 Nov 2017 09:34:08 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id x195so962778qkb.12 for ; Sat, 04 Nov 2017 09:34: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; bh=N2cJJmGPQB3YYPqVgzmP/XInW/7BxdRmLIQi8CY91Pg=; b=SLVMLd1oUhfPI8BfXMj5rbfed6hDXq6K4OR06KM95pN1s8sRFVay6VEUu3Eknxkenb nEcdMNlogGqHmeEGA3lu/Lbru7Csbu0m4jjrERRBAStnd4yWFmhgARpNTFx65+7adnnD Y+iemAysANswGEvnUCNRo8NtcUxwkLkgG2liqPH+fhtUXJ//dQttkxSZBfvH8dLXypvk jN051OnphMpC/0WdXjYUGsFcTo7iSuKSD5lQuYXJhGvPqCPneYdDC/T+MsqzVlgFRwVx KXbNca05EGG46tXUUy3s46pl0wkTcWfHZxe6bQGZK9/OVrLgMGjxsjyU6vgT8gaOj318 2urg== 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=N2cJJmGPQB3YYPqVgzmP/XInW/7BxdRmLIQi8CY91Pg=; b=RO7DBojluzvBVzle9dIZybK6MMaegc+VATqYKHm4RsGq28uWtSmmnG01Jyinmw+6V3 vpNiqjIQErz9wUUkzhhXfPXfZGoDxwe01AdrD4rzTCizlVLLIMKYPBjMW+tCp88PWkHz PQm3PWONT35thtmJSmVQOO0iC4lLtP3AGlj591huAZCMmzAxa47C0Kga1UB0nP1P2vgv 4/dkMv85//8Cz1s/xHFr6PAvxiVAPGqr8xLXk+jIVq7d4Sp2MRwbeV7XLF4LRGkalwJx 756SSyslE3YxqNLxLNlNY3iBk3EaH4OIA79pHOFgeYIXlJGlbNW3ZQ5o5b4UpiCRHzy5 848w== X-Gm-Message-State: AJaThX5W4mS5fOFP8ZauXGk4QJU/bQqw5n62jhgaTNVHErFlD4esnllm 4p8GwYU8aNlpItoEubAbEfkACC6HrQIlaZyhzx5kaw== X-Google-Smtp-Source: ABhQp+T6kd5WKzMvnG7nDu0/M2o48uS3IEAY6PhlJ7ZYBWKFNSM1x/PE0uCmDI0e8xl2J4KRyHvmd9jjUPl/5+tz73o= X-Received: by 10.55.148.70 with SMTP id w67mr15088843qkd.102.1509813247785; Sat, 04 Nov 2017 09:34:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Sat, 4 Nov 2017 09:34:07 -0700 (PDT) In-Reply-To: <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Sat, 4 Nov 2017 09:34:07 -0700 Message-ID: To: Toerless Eckert Cc: Christian Huitema , Padma Pillay-Esnault , "ietf@ietf.org" , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" 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: Sat, 04 Nov 2017 16:34:11 -0000 On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert wrote: > Thanks, Tom, inline > > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: >> Toerless, >> >> That maybe true, but personal devices, such as smart phones and cars >> that are associated with individuals, are hardly going away anytime >> soon. How addresses are assigned to these devices has a material >> impact on individual privacy. Even right now there are two long >> threads on v6ops right now that are delving precisely into privacy of >> IPv6 addresses that may be relevant. This includes discussion about >> CGNAT and efforts by some governments to illegalize it because the >> privacy it gives is too strong for law enforcement. > > Sure. All i was saying is that we should not dismiss solutions if they > do not help to improve privacy. It reminds me of the congestion control > principles and the fact that a lot of money is made with video in > controlled networks without congestion control. As in: "Sorry, we couldn't > build a great solution for sensor devices in manufacturing plants because > those solutions wouldn't pass the privacy bar". > > I am not even aware if we have good characterizations of solutions > vs. privacy like IMHO we have for congestion control, but of course its > a more complex topic. (IMHO: lot more cases IMHO to distinguish). > > That being said, i would of course love to see that we leverage IDEAs to > also create options that (could) enhance privacy, i just don't think that > we will make a lot of progress if we can not do this work in a WG but > if all the complex issues have to be resolved on pre-wg mailing lists before > even charters are accepted. This is part of whats wrong with the IETF > if i may say so. > > For example, Christian contested that long lived identifiers help to > improve privacy (for device = individual case) and those arguments about > privacy had the IESG turn their opinions. > > IMHO: The long-lived identifiers are meant to be functionally limited. You do > increase the bar of identifying an individual when you do this because the > web applications need to do more work to correlate application layer > information across multiple functional identifiers. > > So, how & where do we even create a common understanding about the qualitative and > quantitative privacy benefits of technology options if not in a WG. Functional > identifiers just being one example. > > Even more fundamentally: If each individual application layer function requires > authentication via e.g.: government, google or facebook ID, and all those > web services are free to correlate their information in the backend, any > network layer privacy work is just like growing organic tobacco. > > Which is why i really would like to know what the state of requirements/BCP etc. > is re. privacy at app layer in the IETF, because without that knowledge, i can > only define the privacy benefits of a network layer enhancement under the > ASSUMPTION of particular application behavior. > I don't think that's true. Privacy enhancements at the network layer are needed to prevent inferences of PII by third party using just network layer information that might be passively intercepted. Knowledge of the application is not needed. In the base case scenario, it should be impossible for a random intermediate node in the Internet to determine who is communicating to whom (identity), where someone is communicating from (location), and what they are saying (content). > My impression of IETF policy is "you have to trust the web services > provider (not to share/correlate/abuse user/client information)" and in the > same breath "you can not trust the network service provider (to behave in the > same way)". Would love to get pointed to documents proving this impression to > be wrong. Especially the option that there can be network providers that > users may want to trust more than arbitrary web services providers should IMHO > be acknowledged. And thats definitely an option i think is worthwhile to build > solutions against. > I doubt there's any IETF RFC or BCP stating whom were required to trust as a MUST. Personally, I don't inherently trust web service providers, network service providers, government, vendors, or really anyone else involved in communications (including myself :-) ). Some trust is needed out of necessity to do anything useful, but we should always be searching for ways to further minimize that. A good example is turning up the TLS on the Internet; this eliminated the need to trust the network with our plaintext. I believe a similar thing will happen with addressing, we'll figure out how to eliminate all PII from addresses so that we don't have to trust the network to not be making inferences that breaks privacy. Tom From nobody Sat Nov 4 14: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 490D413FB06; Sat, 4 Nov 2017 14:37:28 -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 K6xc3ak-BtB0; Sat, 4 Nov 2017 14:37:27 -0700 (PDT) Received: from bsa2.jck.com (bsa2.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 12AA313FADA; Sat, 4 Nov 2017 14:37:26 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eB67z-0005ws-Fk; Sat, 04 Nov 2017 17:37:19 -0400 Date: Sat, 04 Nov 2017 17:37:12 -0400 From: John C Klensin To: Tom Herbert , Toerless Eckert cc: ideas@ietf.org, "lisp@ietf.org list" , Christian Huitema , Dino Farinacci , ietf@ietf.org Message-ID: In-Reply-To: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> 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] [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: Sat, 04 Nov 2017 21:37:28 -0000 --On Saturday, November 4, 2017 09:34 -0700 Tom Herbert wrote: >... > A good example > is turning up the TLS on the Internet; this eliminated the > need to trust the network with our plaintext. And, for many people, replaces it with the need to trust firewall and security appliance providers who have concluded that they need to intercept and decrypt traffic in order to identify malware and other undesirable traffic. At least in principle, one does get to choose which vendor to trust and does know (by virtue of having to install special certificates) which vendor or provider is being trusted, but those options may not be meaningful for typical users. I worry with that example and several others that the IETF is not adequately distinguishing between "increasing privacy" or "preventing mass surveillance" on the one hand and forcing users into a "who do your trust" or even "who does someone trust on your behalf" shell game on the other. best, john From nobody Mon Nov 6 12:01: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 54D6913FB3E; Mon, 6 Nov 2017 12:01:54 -0800 (PST) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 R41QdZQirOvw; Mon, 6 Nov 2017 12:01:51 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0450713AF75; Mon, 6 Nov 2017 12:01:50 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4950D58C4FA; Mon, 6 Nov 2017 21:01:45 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 320C6B0D0C7; Mon, 6 Nov 2017 21:01:45 +0100 (CET) Date: Mon, 6 Nov 2017 21:01:45 +0100 From: Toerless Eckert To: Tom Herbert Cc: "ideas@ietf.org" , "lisp@ietf.org list" , Christian Huitema , Dino Farinacci , Padma Pillay-Esnault , "ietf@ietf.org" Message-ID: <20171106200144.GA21604@faui40p.informatik.uni-erlangen.de> References: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 06 Nov 2017 20:01:54 -0000 On Sat, Nov 04, 2017 at 09:34:07AM -0700, Tom Herbert wrote: > On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert wrote: > > Thanks, Tom, inline > > > > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: > >> Toerless, > >> > >> That maybe true, but personal devices, such as smart phones and cars > >> that are associated with individuals, are hardly going away anytime > >> soon. How addresses are assigned to these devices has a material > >> impact on individual privacy. Even right now there are two long > >> threads on v6ops right now that are delving precisely into privacy of > >> IPv6 addresses that may be relevant. This includes discussion about > >> CGNAT and efforts by some governments to illegalize it because the > >> privacy it gives is too strong for law enforcement. > > > > Sure. All i was saying is that we should not dismiss solutions if they > > do not help to improve privacy. It reminds me of the congestion control > > principles and the fact that a lot of money is made with video in > > controlled networks without congestion control. As in: "Sorry, we couldn't > > build a great solution for sensor devices in manufacturing plants because > > those solutions wouldn't pass the privacy bar". > > > > I am not even aware if we have good characterizations of solutions > > vs. privacy like IMHO we have for congestion control, but of course its > > a more complex topic. (IMHO: lot more cases IMHO to distinguish). > > > > That being said, i would of course love to see that we leverage IDEAs to > > also create options that (could) enhance privacy, i just don't think that > > we will make a lot of progress if we can not do this work in a WG but > > if all the complex issues have to be resolved on pre-wg mailing lists before > > even charters are accepted. This is part of whats wrong with the IETF > > if i may say so. > > > > For example, Christian contested that long lived identifiers help to > > improve privacy (for device = individual case) and those arguments about > > privacy had the IESG turn their opinions. > > > > IMHO: The long-lived identifiers are meant to be functionally limited. You do > > increase the bar of identifying an individual when you do this because the > > web applications need to do more work to correlate application layer > > information across multiple functional identifiers. > > > > So, how & where do we even create a common understanding about the qualitative and > > quantitative privacy benefits of technology options if not in a WG. Functional > > identifiers just being one example. > > > > Even more fundamentally: If each individual application layer function requires > > authentication via e.g.: government, google or facebook ID, and all those > > web services are free to correlate their information in the backend, any > > network layer privacy work is just like growing organic tobacco. > > > In the base case scenario, > it should be impossible for a random intermediate node in the Internet > to determine who is communicating to whom (identity), where someone is > communicating from (location), and what they are saying (content). As an individual i agree. An individual who needs to VPN across his home gateway routers in different countries to get access to entertainment options when being abroad. But then there are so many paychecks people want to live off: There is a lot of "Internet" business riding on geo-location of locators (for better or worse). So, when it comes to IESG review of proposed work, how would a scheme be vetted wrt. those business models ? If we would take this geo-location awareness away from the network layer, i can already see how any web browser would become even more DRM encumbered, reaching down into the system to also protect reading of GPS location, and i have to run from my hotel room outside to the street to catch a GPS signal to let me watch my movie. Like those pico-cells from ATT. Likewise, service-provider want to have subscriber-IDs to be able to treat traffic from multiple subscribers fairly because there is really no good way to do this without an explicit subscriber-ID if you want real address anonymity (whether its identifier or locators). And that requirement i actually agree to as an individual even a lot more than the geoloc one. IMHO we must as the IETF be a lot more flexibility with allowing different requirements and business models, else we will just see ore and more of the counter reaction nicely summarized in http://queue.acm.org/detail.cfm?id=1242499> I like a well standardized and documented IETF solution that exposes end-user data a lot more than the secret dealings at application level that happen today. Especially when we could start thinking of how to guarantee that we provide means for the end-user/app to device what to present to whom and why. > > Which is why i really would like to know what the state of requirements/BCP etc. > > is re. privacy at app layer in the IETF, because without that knowledge, i can > > only define the privacy benefits of a network layer enhancement under the > > ASSUMPTION of particular application behavior. > > I don't think that's true. Privacy enhancements at the network layer > are needed to prevent inferences of PII by third party using just > network layer information that might be passively intercepted. > Knowledge of the application is not needed. Right. I can make life for those third parties harder by introducing what i called functional identifiers, where ultimately every type of interaction you do uses a different identifier and can therefore at network layer by passive observers not be correlated into a single identity. But introducing that type of work into network layer makes only sense if we want to assume that there is no correlation across multiple functions at the application layer anyhow. That was the example. > > My impression of IETF policy is "you have to trust the web services > > provider (not to share/correlate/abuse user/client information)" and in the > > same breath "you can not trust the network service provider (to behave in the > > same way)". Would love to get pointed to documents proving this impression to > > be wrong. Especially the option that there can be network providers that > > users may want to trust more than arbitrary web services providers should IMHO > > be acknowledged. And thats definitely an option i think is worthwhile to build > > solutions against. > > > I doubt there's any IETF RFC or BCP stating whom were required to > trust as a MUST. Personally, I don't inherently trust web service > providers, network service providers, government, vendors, or really > anyone else involved in communications (including myself :-) ). +1 > Some trust is needed out of necessity to do anything useful, but we should > always be searching for ways to further minimize that. The more you want to do across the Internet, the more you need to trust those web services providers with your data. The real challenge is create more transparency in those web service providers to allow for more verification of what they do. And why the heck should i not be able to get better services from network service providers ? What they would need to know for interesting services is so much less than what app providers are collecting about me. Why would i oppose a subscriber ID so a network service provider can provide fairness better ? > A good example > is turning up the TLS on the Internet; this eliminated the need to > trust the network with our plaintext. The problem with TLS is that it is evolving in a way that will again lead to a weapons race. For example the fact that 1.3 removed totally the option for no-encryption. Therefore eliminating the option of apps who need observable, authenticated traffic to rely on just TLS. Or the fact that it mandates encryption of certs so you can not even authenticate the identify of a web service (not the client). There are good reasons why you want to have this profile, but there are also good reason why you want othre profiles, and those get consistently shot down in the IETF. And thats bad politics. > I believe a similar thing will > happen with addressing, we'll figure out how to eliminate all PII from > addresses so that we don't have to trust the network to not be making > inferences that breaks privacy. The VPN service providers to access netflix abroad are an interesting data point in this battle. Obviously i need to trust them to keep my identify "private". Netflix did recently block a lot of them. What would happen if ever more subscriber would use SPs offering that type of locators. Would the OOT provider like hulu/netflix wake up and relax geo-locking Or do we get the GPS geoloc as i fear ? In any case: a) if we want to get more addressing privacy, it would be good to discuss the expectable outcomes of that, and b) i can not see how to create that privacy without putting more trust into some entities (such as the access==VPN SP). Cheers Toerless > Tom > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas -- --- tte@cs.fau.de From nobody Sat Nov 11 19:53: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 43D97126DD9 for ; Sat, 11 Nov 2017 19:53:30 -0800 (PST) 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 XyWyFDwlzk3Z for ; Sat, 11 Nov 2017 19:53:29 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 E2BBC126B6D for ; Sat, 11 Nov 2017 19:53:28 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id l25so1074121uag.8 for ; Sat, 11 Nov 2017 19:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yy+EtVDe+EAZHVXiU4CodGDJRiBznGn1yHusUMgLhGo=; b=SEnllCDcyix1pbYnL0eyNMNcr6tman1+3nMf9h2bbEcjTPxaUHHN9Nw6z7CXl1X/hd tAcxbsX+OxpSt2Nu3zV08T4l7kYDdwvWDCNrmiEXB3js0fINKsRc5aL4ZOtMym1uX9ED EYBG/81T630xYfdiFgGTFEOkMCKQA9DoauaGF3q3mnZKNOrd+8YJeouyIyfp6Cr/u8nL cK1qXB1y2EqZTAkWq1IFml5mOYZrWZcPjpGAmBNlmq5uh+tYPglZ1zjF0iuUfuYpfKXA xCUXl7+9QDeiEbpY73F4dmfhYLyUcHxmOHfSmuQJgB2klRXKXEMyI+1vPO6CiCqebxEY NO9w== 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=yy+EtVDe+EAZHVXiU4CodGDJRiBznGn1yHusUMgLhGo=; b=R0pUPd5cpZvW2ROPHUNonWLRsLGCDEE3IPzLOCuWrie2BCZAj7wTcRHq4seNXoMm83 1PNoEhhPtwjqocIN6/zVhy4opA5uECNJnPPOxinI6PiSgQdWWRx9D6WVP62R4JugMkqo BYJ4fwkMgF5ngJcwiy/Sem0AeoxLN2BF02ceik6219UP6EKIOsbc0Cae4NtKHT17Q2ha AwYOrSMnzbIMAahwG7pLdBi7esy6Yv0a+3129S36rjQ2d2WjyoMsBbA+Q0frDCbaLSXS eWA0hLVIGroAGOqpNmhsLKEe5h/4Ya65fRETFg7zJA6aNDW245jCFc/LD5Gs+BgRc7iu r/yg== X-Gm-Message-State: AJaThX6yKhyUd9CxG3DMLcEgrrzs1Z/TNdSNI6wbtSqpB8BQF7XFm0Zv /mzzceXAfFpDAKOhvRgO/thinf7ZL5sNA3O0g86tmA== X-Google-Smtp-Source: AGs4zMYW7eBK4hVnhQLFeqH0veXuZyS9avh3gXIoLNhQjpLDNZIdbVkfX1FFcV82gZqTcRL5zUaK2T3b5YuDCmLEqQQ= X-Received: by 10.159.60.8 with SMTP id u8mr4401822uah.60.1510458807768; Sat, 11 Nov 2017 19:53:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.62.13 with HTTP; Sat, 11 Nov 2017 19:53:27 -0800 (PST) From: Padma Pillay-Esnault Date: Sun, 12 Nov 2017 11:53:27 +0800 Message-ID: To: ideas@ietf.org Content-Type: multipart/alternative; boundary="f403043ec350af5e50055dc11884" Archived-At: Subject: [Ideas] IDEAS Side Meeting @ IETF100 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, 12 Nov 2017 03:53:30 -0000 --f403043ec350af5e50055dc11884 Content-Type: text/plain; charset="UTF-8" Dear IDEAS We will be holding a side meeting in Singapore. Date: Thursday 16th November Time: 10 - 11:30 am Room: Hullet We have received some constructive feedback from the external review. Here are some of the topics that came up on the aliases. We need to converge/compromise on when presenting the next charter: - Scope of work (enterprise, global, public/private, control plane, not human ...... ) - Security (The solution for access to grids and for control plane) - Anonymity/Privacy (identifiers and ip address tracking, pros/cons of solutions, ...) - Policy (what is acceptable and what is censorship?) - Network management/analytics (vs tracking) - AFAB solution how/where does it fit? - best current practices for IPv6 address assignment( RFC 7934)? See you there Padma --f403043ec350af5e50055dc11884 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IDEAS

We will be holding a side me= eting in Singapore.

Date: Thursday 16th November
Time: 10 - 11:30 am=C2=A0
Room: Hullet=C2=A0
<= br>
We have receive= d some constructive feedback from the external review.

=
Here are some of the topics that came up on the aliases. We need= to converge/compromise on when presenting the next charter:
- Scope of work (enterprise, global, p= ublic/private, control plane, not human ...... )
- Security (The solution for access to grids and f= or control plane)
- Anon= ymity/Privacy (identifiers and ip address tracking, pros/cons of solutions,= =C2=A0...)
- Policy (wh= at is acceptable and what is censorship?)
- Network management/analytics (vs tracking)
-=C2=A0AFAB solutio= n how/where does it fit?
- best current practices for IPv6 address assignment( RFC 7934)?=C2= =A0

See you there

=
Padma
--f403043ec350af5e50055dc11884--