-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Security always has convenience and cost trade-offs.
A paper addressing one aspect of this is: "Experimental evaluation of the IP address space randomisation (IASR) technique and its disruption to selected network services" Maxwell Dondo, DRDC – Ottawa Research Centre www.dtic.mil/get-tr-doc/pdf?AD=AD1004299 The only one of the techniques cited therein with which I am familiar in detail is ARCSYNE, which is not open source / open standards based; however, ID/locator separation can be used to develop standards based IP address hopping [using mobility/multihoming support techniques], as presaged in Erik Nordmark's subject draft. Some ID/locator split approaches may be more conducive to [location] privacy than others; a recent (not security focused) overview of many of the approaches is: "Locator/Identifier Split Networking: A Promising Future Internet Architecture" Bohao Feng, Hongke Zhang, Huachun Zhou, Shui Yu IEEE Communications Surveys & Tutorials, Vol. 19 No. 4, 4th quarter 2017 https://ieeexplore.ieee.org/document/7983351/ Personally I am fond of the Host Identity Protocol (HIP), _inter alia_: because, as a host based approach, it can minimize exposure of bindings of HIs (athough it reveals HITs in the base exchange) to nodes other than network path endpoints; and because HIs, as hashes of public keys, can be pre-generated in batches and updated frequently. Unfortunately, if HIs are stored in DNS HIP RRs (needed for Responder reachability from Initiators without prior coordination), dynamic DNS updates could be monitored to link successive HIs. IP address hopping (as a moving target defense) still can commence once an association is established (enabling HIP locator UPDATEs to be sent inside the IPsec ESP tunnel), but the base exchange at the start of the session exposes both HITs. :-/ There have been proposals to mitigate this but I don't see any sign of them in RFC 7401. On 7/3/2018 11:36 AM, Jon Crowcroft wrote: > agree...of course... > > just we need to start adding > security +cost+ considerations... > to drafts >> On Tue, Jul 3, 2018 at 8:19 AM, Jon Crowcroft >> <jon.crowcr...@cl.cam.ac.uk> wrote: >>> beware of sidechannel attacks - eg. a sequence of efficient routes can >>> determine a sequence of locations just from latency/rtt estimation >>> (observe outbound data and likely return path ack packets) - you want >>> privacy, you're gonna pay >>> >> >> Yep, we also know there is a lot of effort being done to extract >> information from cipher text like apply machine learning to the data. >> As compute and data acquisition techniques advance, attacks on the >> Internet only get more sophisticated. Work will always be needed to >> mitigate new attacks and that will have cost. It's a never ending >> problem, but it's worth it to continually try to solve IMHO. >> >> Tom >> >> >>> On Tue, Jul 3, 2018 at 5:14 PM, Tom Herbert <t...@quantonium.net> wrote: >>>> On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft >>>> <jon.crowcr...@cl.cam.ac.uk> wrote: >>>>> what we need is compact onion routing - maybe we could call it garlic >> routing. >>>>> >>>>> in all seriousness, if people are worried about privacy with regards >>>>> network operators, or state actors co-ercing network operators, at >>>>> this level, that is what you want. otherwise forget about efficient >>>>> mobile routing - the fact is that the signature of the set of >>>>> locations you visit is enough to re-identify a node pretty quickly - >>>>> its been done (see wetherall's work on this a few years back on simply >>>>> looking at sequences of wifi AP associations, without bothing with end >>>>> system mac addr, to uniquely matc individual (indeed, find their home) >>>>> - you have to get the threat model appropriately...and proportioately >>>> >>>> Jon, >>>> >>>> The threat is not limited to coming from network operators, it is >>>> basically from the whole Internet. IP addresses must be sent as clear >>>> text, and when they encode personally identifiable information then >>>> that can be used by third parties to compromise privacy. In mobile >>>> addresses, the threat is both comprising identity and location of the >>>> user. Identity can be compromised when the same address (or device >>>> specific prefix in case of RFC4941 addresses) is reused for different >>>> flows, location is compromised when an address encodes a locator that >>>> can be used to determine specific location. There are publicized >>>> examples of third parties using IP addresses to expose identity and >>>> location (e.g. >> https://theintercept.com/2018/03/26/facebook-data-ice-immigration/). >>>> >>>> In order to provide privacy in addressing, IP addresses need to be >>>> purged of PII. This likely entails minimizing aggregation and a high >>>> frequency of address change in a host. On the surface, this does seem >>>> to be in conflict with "efficient mobile routing" as you mentioned, >>>> however I don't believe that efficient routing is an acceptable trade >>>> off for not providing adequate privacy to users. Alternatives that >>>> achieve both goals should be investigated. >>>> draft-herbert-ipv6-prefix-address-privacy-00 suggests "hidden >>>> aggregation" as one possibility. >>>> >>>> Tom >>>> >>>>> >>>>> On Mon, Jul 2, 2018 at 11:42 PM, Erik Nordmark <nordm...@acm.org> >> wrote: >>>>>> >>>>>> This is a rough draft, but hopefully it can stimulate more >> discussion around >>>>>> privacy considerations. >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: New Version Notification for >> draft-nordmark-id-loc-privacy-00.txt >>>>>> Date: Mon, 02 Jul 2018 15:34:11 -0700 >>>>>> From: internet-dra...@ietf.org >>>>>> To: Erik Nordmark <nordm...@sonic.net> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-nordmark-id-loc-privacy-00.txt >>>>>> has been successfully submitted by Erik Nordmark and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-nordmark-id-loc-privacy >>>>>> Revision: 00 >>>>>> Title: Privacy issues in ID/locator separation systems >>>>>> Document date: 2018-07-02 >>>>>> Group: Individual Submission >>>>>> Pages: 6 >>>>>> URL: >>>>>> >> https://www.ietf.org/internet-drafts/draft-nordmark-id-loc-privacy-00.txt >>>>>> Status: >> https://datatracker.ietf.org/doc/draft-nordmark-id-loc-privacy/ >>>>>> Htmlized: >> https://tools.ietf.org/html/draft-nordmark-id-loc-privacy-00 >>>>>> Htmlized: >>>>>> https://datatracker.ietf.org/doc/html/draft-nordmark-id-loc-privacy >>>>>> >>>>>> >>>>>> Abstract: >>>>>> There exists several protocols and proposals for >> identifier/locator >>>>>> split which have some form of control plane by which participating >>>>>> nodes can use to share their current id to locator information >> with >>>>>> their peers. This document explores some of the privacy >>>>>> considerations for such a system. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 5gangip mailing list >>>>>> 5gan...@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/5gangip >>>>> >>>>> _______________________________________________ >>>>> 5gangip mailing list >>>>> 5gan...@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/5gangip >>>> >>>> _______________________________________________ >>>> 5gangip mailing list >>>> 5gan...@ietf.org >>>> https://www.ietf.org/mailman/listinfo/5gangip >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > - -- Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 <stu.c...@critical.com> www.critical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAls74RcACgkQS7PQ0a2weL67CwCeLWYcM7t8/drzgP8yuX8Pt8CF sokAoPRlJsRBYxINh/1U+ffzLNBEyqkb =OCEK -----END PGP SIGNATURE----- _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
