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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]