Hi Bob, On 10/10/17 20:35, Robert Moskowitz wrote: > 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. "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. 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. 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. > > 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). 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). 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. 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. 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. > > 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@xxxxxxxx) by 2017-10-09. >>> >>> IDentity Enabled Networks (ideas) >>> ----------------------------------------------------------------------- >>> Current status: Proposed WG >>> >>> Chairs: >>> Padma Pillay-Esnault <padma.ietf@xxxxxxxxx> >>> >>> Assigned Area Director: >>> Alvaro Retana <aretana@xxxxxxxxx> >>> >>> Routing Area Directors: >>> Alia Atlas <akatlas@xxxxxxxxx> >>> Alvaro Retana <aretana@xxxxxxxxx> >>> Deborah Brungard <db3546@xxxxxxx> >>> >>> Mailing list: >>> Address: ideas@xxxxxxxx >>> 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ideas > >
Attachment:
signature.asc
Description: OpenPGP digital signature