Subject: [Ideas] Your input needed: Charter Proposal

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 2 Aug 2017 00:05:12 -0700

Dear Ideas

Please find below the updated charter that includes some feedback from our
BOF chairs and AD.

Your input and support greatly appreciated.
Please send your comments and proposed changes on the alias.

IDEAS: “IDentity EnAbled networkS”

Proposed Charter

Network solutions based on the concept of Identifier-Locator separation are
increasingly considered to support mobility 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. 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.  In addition,
identity-enabled networks introduce the concept of identity-identifier
split. This split enables networks provide communication services for
endpoints regardless of the particular identifier used at any particular
point in time.

Examples of the problem space are:

- Privacy:  The use of long-lived and public identifiers may be desirable
for looking up a peer, however it causes privacy issues as well. Indeed,
when identifier-location pairs can be looked up without restriction, flows
can be pinned by anybody to specific end systems.  The endpoint
communications should be able to change their identifier while retaining
their identity and associated policies. This indirection should help
discourage undesired traffic and conceal sensitive network information of
end devices to eavesdroppers.

- Access control : An identifier may reveal information to which the
end-users may not want to be associated with (for example mapped location).
Therefore, it is desirable to have a certain degree of control over who can
look up the identifier-locator binding information for example.

- Common infrastructure and Primitives: The application of common and
consistent basic networking policies that can apply at the level of entity
reduces operational complexity associated with managing services for
individual endpoints. Likewise, mapping services and infrastructure that
apply to identity-identifier as well as identifier-locator mappings reduces
operational and deployment complexity.

The Identity Enabled Networks (IDEAS) working group is chartered to develop
a framework that can be used by identifier-based protocols and provides
services to address those requirements. We refer to the framework providing
the set of services as Generic Identity Services (GRIDS).

The working group will identify gaps and make recommendations on changes
needed for interactions between the framework and identifier-enabled
protocols.

Specifically, the IDEAS WG is chartered to work on these areas for the
framework:

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

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

-Identifier/locator mapping and resolution (e.g. discovery, pub/sub,
multihoming...)

-Definition and enforcement of basic networking policies (e.g. ability to
look up an identifier-locator pair, permit forwarding traffic for
particular endpoints on a per-identity basis…)

-Identity and Identifier Metadata (fixed or slow changing)

-Definition of primitives for interworking with identifier-location split
protocols

-Management aspects and Data Models where appropriate.

The IDEAS WG will collaborate with other Working Groups to ensure
interoperability with LISP, HIP, ILA and other relevant work. Furthermore,
it will try to reuse technologies already developed when appropriate.

WG deliverables include:

Generic Identity Services Framework

WG sustaining/informational documents may include:

These documents may not necessarily be published, but may 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:

-Problem statement

-Use cases

-Requirements

- Applications of the architecture for use cases

Milestones

March 2018 Adopt WG draft for the Identity Services framework

August 2018 WGLC for the Identity Services framework

December 2018 Send Identity Services framework draft to the IESG

---

From: Michael Menth <[email-masked]>
Date: Wed, 2 Aug 2017 09:32:34 +0200

Hi Padma, all,

Am 02.08.2017 um 09:05 schrieb Padma Pillay-Esnault:
> Dear Ideas
> 
> Please find below the updated charter that includes some feedback from
> our BOF chairs and AD. 
> 
> Network solutions based on the concept of Identifier-Locator separation
> are increasingly considered to support mobility and multi-homing across
> 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.  In
> addition, identity-enabled networks introduce the concept of
> identity-identifier split. This split enables networks provide
> communication services for endpoints regardless of the particular
> identifier used at any particular point in time.
> 
> 
> - Privacy:  The use of long-lived and public identifiers may be
> desirable for looking up a peer, however it causes privacy issues as
> well. Indeed, when identifier-location pairs can be looked up without
> restriction, flows can be pinned by anybody to specific end systems. 
> The endpoint communications should be able to change their identifier
> while retaining their identity and associated policies. This indirection
> should help discourage undesired traffic and conceal sensitive network
> information of end devices to eavesdroppers.
The last paragraph is not fully clear.

> end-users may not want to be associated with (for example mapped
Not fully clear.

Therefore, it is desirable to have a certain degree of
> control over who can look up the identifier-locator binding information
> for example.

> consistent basic networking policies that can apply at the level of
> entity reduces operational complexity associated with managing services
> for individual endpoints. 
This is not a full sentence. Meaning?

Likewise, mapping services and infrastructure
> that apply to identity-identifier as well as identifier-locator mappings
> reduces operational and deployment complexity.
Is that the suggestion to have one mapping system for both loc-id and
idy-idf mapping?

> 
>  
> 
> The Identity Enabled Networks (IDEAS) working group is chartered to
> develop a framework that can be used by identifier-based protocols and
> provides services to address those requirements. We refer to the
> framework providing the set of services as Generic Identity Services
> (GRIDS).
The term Generic Identity Services may be a bit misleading. I perceived
that GRIDS stands primarily for the idy-idf mapping system but I
understand by the expansion of the acronym services based on idy. There
is some potential for mistake.

> -Registration and lifecycle management of identities and their
> associated identifiers.
> 
> -Definition and enforcement of basic networking policies (e.g. ability
> to look up an identifier-locator pair, permit forwarding traffic for
> -Definition of primitives for interworking with identifier-location
> split protocols
> 

- Access restriction for lookup of identity-identifier information

That is probably the hardest part if scalability and privacy are expected.

> interoperability with LISP, HIP, ILA and other relevant work.
> Furthermore, it will try to reuse technologies already developed when
> appropriate.
> 
>                  
> 
> WG deliverables include:
> 
> These documents may not necessarily be published, but may be maintained
> in a draft form or on a collaborative Working Group wiki to support the

Best wishes,

Michael

>  
> 
>  
> 
> 
> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Tom Herbert <[email-masked]>
Date: Wed, 2 Aug 2017 09:46:17 -0700

On Wed, Aug 2, 2017 at 12:05 AM, Padma Pillay-Esnault
<[email-masked]> wrote:
> require infrastructure that allows nodes to discover the network topological
> location(s) of its peer(s) for packet delivery.

This is true, but there is currently no common IETF protocol to do
this. A common infrastructure and protocol could be used by
identifier/locator protocols as well as network virtualization. My
understanding is that developing such a protocol would be the goal of
the WG, if so it should be explicitly stated here in the charter.

> However, additional
> infrastructure and new protocol extensions are needed to address new
> requirements that go well beyond the traditional discovery service and
This seems weak to me. Identifier/locator protocols have already been
successfully deployed without the concept of identity. I don't see
that where lack of the identity has prevented networks to provide
communication services (although I'm not sure what the scope of
"communication services" is). I think a clearer rationalization is
needed for identity.

> the set of services as Generic Identity Services (GRIDS).

The use of terms identifier and identity seems a little haphazard here
and elsewhere. For instance, if the working group is chartered to
"chartered to develop a framework that can be used by identifier-based
protocols" then should the WG group be Identifier Enabled Networks and
the services be Generic Identifier Services? I realize this is only
nomenclature, but I think if the implication is that this creates a
required dependency on identity for existing identifier/locator
protocols this could meet resistance.

Tom

> -Identity authentication and authorization (e.g. access to framework, update
> of information for identifiers..)
>
> look up an identifier-locator pair, permit forwarding traffic for particular
> endpoints on a per-identity basis…)
>
> These documents may not necessarily be published, but may 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:
>
> -Problem statement
>
> -Use cases
>
> -Requirements
>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 2 Aug 2017 22:57:01 +0000

Hi,

I have a couple of comments and questions, which I put inline, <ALEX>.

Thanks
--- Alex

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Wednesday, August 02, 2017 12:05 AM
To: [email-masked]
Cc: Padma Pillay-Esnault <[email-masked]>
Subject: [Ideas] Your input needed: Charter Proposal

Dear Ideas

Please find below the updated charter that includes some feedback from our BOF chairs and AD.

Proposed Charter

Network solutions based on the concept of Identifier-Locator separation are increasingly considered to support mobility 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. 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.  In addition, identity-enabled networks introduce the concept of identity-identifier split. This split enables networks provide communication services for endpoints regardless of the particular identifier used at any particular point in time.
<ALEX> Not sure why the following text from the previous version was struck – IMHO it would make sense to keep it:
“At the same time, end users require greater privacy for their networking information and protection from outside threats, while operators demand greater operational efficiency. Identity-enabled networks aim to enable networking applications and services that provide a high degree of privacy and control of end points over their networking data, coupled with greater inherent security than provided by today’s networks.

In order to address those challenges, identity-enabled networks introduce the concept of identity-identifier split. This split lets networks provide communication services for endpoints regardless of the particular identifier used at any particular point in time. This requires a set of services, referred to as Generic Identity Services. Those services allow to: (1) manage the lifecycle of identities and identifiers, (2) manage mappings between identities and identifiers in addition to mappings between identifiers and locators, and (3) access to a range of value-added services such as the articulation of basic communication policies that are based on the concept of identity.”

Privacy, operational efficiency, control of endpoints over their networking data feature prominently in our use cases and problem statement.  I don’t intend to engage in circular arguments but I am not quite clear why those aspects were removed – it would seem to me they should be featured as part of the motivation.

</ALEX>

Examples of the problem space are:
- Privacy:  The use of long-lived and public identifiers may be desirable for looking up a peer, however it causes privacy issues as well. Indeed, when identifier-location pairs can be looked up without restriction, flows can be pinned by anybody to specific end systems.  The endpoint communications should be able to change their identifier while retaining their identity and associated policies. This indirection should help discourage undesired traffic and conceal sensitive network information of end devices to eavesdroppers.

- Access control : An identifier may reveal information to which the end-users may not want to be associated with (for example mapped location). Therefore, it is desirable to have a certain degree of control over who can look up the identifier-locator binding information for example.

- Common infrastructure and Primitives: The application of common and consistent basic networking policies that can apply at the level of entity reduces operational complexity associated with managing services for individual endpoints. Likewise, mapping services and infrastructure that apply to identity-identifier as well as identifier-locator mappings reduces operational and deployment complexity.

The Identity Enabled Networks (IDEAS) working group is chartered to develop a framework that can be used by identifier-based protocols and provides services to address those requirements. We refer to the framework providing the set of services as Generic Identity Services (GRIDS).

The working group will identify gaps and make recommendations on changes needed for interactions between the framework and identifier-enabled protocols.

Specifically, the IDEAS WG is chartered to work on these areas for the framework:
-Registration and lifecycle management of identities and their associated identifiers.
-Identity authentication and authorization (e.g. access to framework, update of information for identifiers..)
-Identifier/locator mapping and resolution (e.g. discovery, pub/sub, multihoming...)
-Definition and enforcement of basic networking policies (e.g. ability to look up an identifier-locator pair, permit forwarding traffic for particular endpoints on a per-identity basis…)
-Identity and Identifier Metadata (fixed or slow changing)
-Definition of primitives for interworking with identifier-location split protocols
-Management aspects and Data Models where appropriate.
 <ALEX> Earlier revision did not include the last 3 items: metadata, primitives for interworking, management aspects.  I believe those will be required for a complete system so on those grounds don’t object to including them; however, I do have concerns regarding if the scope becomes too large.  IMHO we should consider removing them, in the interest of sharper focus (which is still large); we can always add stuff later.
</ALEX>
The IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work. Furthermore, it will try to reuse technologies already developed when appropriate.

WG deliverables include:
Generic Identity Services Framework
<ALEX> We have heard mixed messages regarding the use of the term “framework” in the context of IETF.  Can we include definition of the framework as part of our deliverables, or would a framework be something that might be specified as background information to provide context, with the actual deliverable consisting instead of service interfaces, data models, and possibly protocols and protocol extensions? (Perhaps Alvaro can provide direction here?)
</ALEX>

WG sustaining/informational documents may include:
These documents may not necessarily be published, but may 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:
-Problem statement
-Use cases
-Requirements
- Applications of the architecture for use cases

Milestones

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 2 Aug 2017 23:09:52 +0000

Hi Tom,

One response to your second comment, inline, <ALEX>

Thanks
--- Alex

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Wednesday, August 02, 2017 9:46 AM
To: Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

On Wed, Aug 2, 2017 at 12:05 AM, Padma Pillay-Esnault <[email-masked]> wrote:
> Network solutions based on the concept of Identifier-Locator 
> separation are increasingly considered to support mobility and 
> multi-homing across heterogeneous access networks. Identifier-locator 
> separation protocols require infrastructure that allows nodes to 
> discover the network topological

This is true, but there is currently no common IETF protocol to do this. A common infrastructure and protocol could be used by identifier/locator protocols as well as network virtualization. My understanding is that developing such a protocol would be the goal of the WG, if so it should be explicitly stated here in the charter.

> endpoints regardless of the particular identifier used at any 
> particular point in time.
>
This seems weak to me. Identifier/locator protocols have already been successfully deployed without the concept of identity. I don't see that where lack of the identity has prevented networks to provide communication services (although I'm not sure what the scope of "communication services" is). I think a clearer rationalization is needed for identity.

<ALEX>
A few examples are given in the identity use cases document (https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01). 

For example:  Communication and firewall policies aim at specifying rules which endpoint should be blocked from sending traffic to another endpoint.  Policies that are articulated based on locators are going to be insuffient, given that the rule will apply to an endpoint as identified by an identifier, irrespective of its locator (which is subject to change, and which should not require an update to policies and firewall rules whenever the locator changes).  Now, as discussed, there is a clear case to potentially change identifiers frequently when communicating, i.e. to use an ephemeral identifier (from a pool, or assigned dynamically, etc).  In such a case, how would policies, firewall rules etc be applied?  Updating those rules dynamically becomes a significant management challenge (and may be impossible in case of "fresh" ephemeral identifiers).  On the other hand, there is still a desire for security and a legitimate case to be made for firewalls and communication policies.  It should not have to be a choice between either providing security for a receiver (through those rules), or privacy for the sender (through ephemeral identifiers); instead a system should be able to provide both.  This is what the identity/identifier split enables.  

</ALEX>

> while retaining their identity and associated policies. This 
> indirection should help discourage undesired traffic and conceal 
> sensitive network information of end devices to eavesdroppers.
>
>
>
> Therefore, it is desirable to have a certain degree of control over 
> who can look up the identifier-locator binding information for example.
>
>
>
> entity reduces operational complexity associated with managing 
> services for individual endpoints. Likewise, mapping services and 
> infrastructure that apply to identity-identifier as well as 
> identifier-locator mappings reduces operational and deployment complexity.
>
>
>
> framework providing the set of services as Generic Identity Services (GRIDS).

The use of terms identifier and identity seems a little haphazard here and elsewhere. For instance, if the working group is chartered to "chartered to develop a framework that can be used by identifier-based protocols" then should the WG group be Identifier Enabled Networks and the services be Generic Identifier Services? I realize this is only nomenclature, but I think if the implication is that this creates a required dependency on identity for existing identifier/locator protocols this could meet resistance.

Tom

 >
>
>
> The working group will identify gaps and make recommendations on 
> changes needed for interactions between the framework and 
> identifier-enabled protocols.
>
>
>
> Furthermore, it will try to reuse technologies already developed when appropriate.
>
>
>
> WG deliverables include:
>
> These documents may not necessarily be published, but may 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:
>
> -Problem statement
>
> -Use cases
>
> -Requirements
>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 2 Aug 2017 23:22:17 +0000

> location(s) of its peer(s) for packet delivery.

	This is true, but there is currently no common IETF protocol to do this. A common infrastructure and protocol could be used by identifier/locator protocols as well as network virtualization. 
	My understanding is that developing such a protocol would be the goal of the WG, if so it should be explicitly stated here in the charter.

[Uma]: I agree with this.  This should be stated in the deliverables 9order can vary).
              This is also referred  as inter-grids protocol definition in the problem statement slides @IETF99. 

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 2 Aug 2017 23:39:43 +0000

Hi Michael,

Some comments/responses in-line [Uma]:
--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Wednesday, August 02, 2017 12:33 AM
To: [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

Hi Padma, all,

Am 02.08.2017 um 09:05 schrieb Padma Pillay-Esnault:
> IDEAS: "IDentity EnAbled networkS"
> 
>                  
> 
> Proposed Charter
> 
>                  
> 
> discover the network topological location(s) of its peer(s) for packet 
> delivery. 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.  In addition, 
> endpoints regardless of the particular identifier used at any particular point in time.
> 
> 

Not fully clear.

> control over who can look up the identifier-locator binding 
> information for example.

> services for individual endpoints.

> that apply to identity-identifier as well as identifier-locator 
> mappings reduces operational and deployment complexity.

Is that the suggestion to have one mapping system for both loc-id and idy-idf mapping?

[Uma]:  Having one mapping-system (at least deployed that way) for both IDf/Loc and IDy/IDf has advantages w.r.t latency for lot of use cases. 
Remember, there is a relevant operation for example, during location resolution, if the sender  identifier is verified against IDy/IDf  to see if this is allowed or not (or sender group).  For this to happen having both (IDy/IDf and IDf/Loc) together is definitely an  advantage. 
> framework providing the set of services as Generic Identity Services 

The term Generic Identity Services may be a bit misleading. I perceived that GRIDS stands primarily for the idy-idf mapping system but I understand by the expansion of the acronym services based on idy. There is some potential for mistake.

[Uma]:  Michael, not sure what's the mistake here. The services alluded here are envisioned to be defined on the entity's stable  Identity but not on the Identifier (which is not associated all the time to the entity, relatively).
To be defined Identity services *can be* used by any IDentifier/Loc protocol. But it is not necessary to use all of these,  by a particular Identifier/Loc protocol.
> particular endpoints on a per-identity basis...)
> 

Best wishes,

Michael

---

From: Tom Herbert <[email-masked]>
Date: Wed, 2 Aug 2017 17:38:53 -0700

> For example:  Communication and firewall policies aim at specifying rules which endpoint should be blocked from sending traffic to another endpoint.  Policies that are articulated based on locators…
If the only intent of this is merely to make management simpler then
identity might be the wrong term. Maybe this should be something like
identifier group. Regardless, my fundamental question still remains,
what does it mean when this information is compromised by the network?
(note this is "when" not "if")

Suppose for instance that my host connects to another host that is
behind a firewall. If I want to frequently change my local address
because it's a long lived connection then a remote (stateful) firewall
needs to participate have knowledge of the end host identity and would
participate in an identity protocol. But from the host perspective
this seems to create a privacy issue. I have no reason to trust and
remote network or firewall and frankly only trust my local network out
of necessity (local networks already have identities of users). If
IDEAS would purposely share identifying information for users outside
of their local network I think this is a potential issue.

Btw, for changing identifiers on long lived connections the
possibility that MPTCP and MPT (recently proposal in int-area) are
possibly relevant and should be considered to see if they could solve
the problem.

Tom

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 2 Aug 2017 17:39:05 -0700

Dear Michael

Thank you for your comments.

See below <PPE> for suggestions.
Please feel free to propose alternate text.

> The last paragraph is not fully clear.

<Padma>
How about just removing it?

> > control over who can look up the identifier-locator binding information
<Padma> Propose the following
  Access control : Unrestricted look up on an identifier may reveal
information such as the locator to eavesdroppers. Today, there is no way to
prevent the look up of an identifier with some user defined policy or finer
grain rules.

> Is that the suggestion to have one mapping system for both loc-id and
<Padma> Propose the following
Common infrastructure and Primitives: The lack of a common infrastructure
is a  barrier for  the application of common and consistent basic
networking policies.

Regarding your question - colocation is a plus IMHO.

> <Padma>
Clarifications?

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 2 Aug 2017 17:57:34 -0700

Hi Alex

Please see <Padma> below

On Wed, Aug 2, 2017 at 3:57 PM, Alexander Clemm <[email-masked]>
wrote:

> *From:* Ideas [mailto:[email-masked]] *On Behalf Of *Padma
> Pillay-Esnault
> *Sent:* Wednesday, August 02, 2017 12:05 AM
> *To:* [email-masked]
> *Cc:* Padma Pillay-Esnault <[email-masked]>
> *Subject:* [Ideas] Your input needed: Charter Proposal
>
>
>
> Dear Ideas
>
>
>
> <ALEX> Not sure why the following text from the previous version was
> struck – IMHO it would make sense to keep it:
>
> “At the same time, end users require greater privacy for their networking
> information and protection from outside threats, while operators demand
> greater operational efficiency. Identity-enabled networks aim to enable
> networking applications and services that provide a high degree of privacy
> and control of end points over their networking data, coupled with greater
> inherent security than provided by today’s networks.
>
>
>
> In order to address those challenges, identity-enabled networks introduce
> the concept of identity-identifier split. This split lets networks provide
> identifier used at any particular point in time. This requires a set of
> services, referred to as Generic Identity Services. Those services allow
> to: (1) manage the lifecycle of identities and identifiers, (2) manage
> mappings between identities and identifiers in addition to mappings between
> identifiers and locators, and (3) access to a range of value-added services
> such as the articulation of basic communication policies that are based on
> the concept of identity.”
>
>
>
> Privacy, operational efficiency, control of endpoints over their
> networking data feature prominently in our use cases and problem
> statement.  I don’t intend to engage in circular arguments but I am not
> quite clear why those aspects were removed – it would seem to me they
> should be featured as part of the motivation.
>
>
>
> </ALEX>
>

<Padma> One of the feedback we got on this section is as follows:

*"The overall structure of the charter should be crisp in describingthe
problem space rather than talking nebulously about privacy,protection, and
efficiency"*

So took a stab at cutting down on this part.

> provides services to address those requirements. We refer to the framework
> providing the set of services as Generic Identity Services (GRIDS).
>
>
>
>  <ALEX> Earlier revision did not include the last 3 items: metadata,
> primitives for interworking, management aspects.  I believe those will be
> required for a complete system so on those grounds don’t object to
> including them; however, I do have concerns regarding if the scope becomes
> too large.  IMHO we should consider removing them, in the interest of
> sharper focus (which is still large); we can always add stuff later.
>
> </ALEX>
>

<Padma> This was part of the original version and I add them back here.

> <ALEX> We have heard mixed messages regarding the use of the term
> “framework” in the context of IETF.  Can we include definition of the
> framework as part of our deliverables, or would a framework be something
> that might be specified as background information to provide context, with
> the actual deliverable consisting instead of service interfaces, data
> models, and possibly protocols and protocol extensions? (Perhaps Alvaro can
> provide direction here?)
>
> </ALEX>
>
>
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 2 Aug 2017 18:11:01 -0700

On Wed, Aug 2, 2017 at 5:38 PM, Tom Herbert <[email-masked]> wrote:

> > This is true, but there is currently no common IETF protocol to do this.
> A common infrastructure and protocol could be used by identifier/locator
> protocols as well as network virtualization. My understanding is that
> developing such a protocol would be the goal of the WG, if so it should be
> explicitly stated here in the charter.
> >
> >> However, additional
> successfully deployed without the concept of identity. I don't see that
> where lack of the identity has prevented networks to provide communication
> services (although I'm not sure what the scope of "communication services"
> is). I think a clearer rationalization is needed for identity.
> >
> > <ALEX>
> > A few examples are given in the identity use cases document (
> https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01).
> >
> > For example:  Communication and firewall policies aim at specifying
> rules which endpoint should be blocked from sending traffic to another
> endpoint.  Policies that are articulated based on locators are going to be
> insuffient, given that the rule will apply to an endpoint as identified by
> an identifier, irrespective of its locator (which is subject to change, and
> which should not require an update to policies and firewall rules whenever
> the locator changes).  Now, as discussed, there is a clear case to
> potentially change identifiers frequently when communicating, i.e. to use
> an ephemeral identifier (from a pool, or assigned dynamically, etc).  In
> such a case, how would policies, firewall rules etc be applied?  Updating
> those rules dynamically becomes a significant management challenge (and may
> be impossible in case of "fresh" ephemeral identifiers).  On the other
> hand, there is still a desire for security and a legitimate case to be made
> for firewalls and communication policies.  It should not have to be a
> choice between either providing security for a receiver (through those
> rules), or privacy for the sender (through ephemeral identifiers); instead
> a system should be able to provide both.  This is what the
> identity/identifier split enables.
> >
<Padma> No it is not a group .. this is another convoluted word as you can
belong to many groups with other entities.
You raise an interesting question, well it is dependent on what type of
information you tie to it or not.

> of their local network I think this is a potential issue.

<Padma> let say today I put myself on a do not call list? Whether I put
myself there or not does not create more issues regarding my phone# as it
was already possible to scan all numbers anyway. But would I put sensitive
info no ...  In short, you can determine what you want to share or not
share ...

> protocols" then should the WG group be Identifier Enabled Networks and the
> services be Generic Identifier Services? I realize this is only
> required dependency on identity for existing identifier/locator protocols
> this could meet resistance.
> >
> > Tom
> >
> >  >
> >>
> >>

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 3 Aug 2017 07:01:16 +0000

Dear all,

Please note that I very much agree with Alex that before continuing with the definition of the IDEAS charter, we need to clarify which of the below options should be applied regarding the term “framework” in the context of IETF (and IDEAS):

(1)    definition of the framework as being the Work Item and deliverable;

(2)    only used to specify the background information and to provide context, with the actual work items and deliverables will consist instead of service interfaces, data models, and possibly protocols and protocol extensions

(3)    both options described above

Best regards,
Georgios

From: Ideas [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Thursday, August 03, 2017 12:57 AM
To: Padma Pillay-Esnault; [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

Hi,

Thanks
--- Alex

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Wednesday, August 02, 2017 12:05 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Subject: [Ideas] Your input needed: Charter Proposal

Dear Ideas

Proposed Charter

</ALEX>

WG deliverables include:

Milestones

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 3 Aug 2017 23:16:11 +0000

Hi Tom
Some responses, <ALEX2>
cheers
--- Alex
-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, August 02, 2017 5:39 PM
To: Alexander Clemm <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

On Wed, Aug 2, 2017 at 4:09 PM, Alexander Clemm <[email-masked]> wrote:
>> requirements that go well beyond the traditional discovery service 
>> and mapping of identifier-to-location for packet delivery.  In 
If the only intent of this is merely to make management simpler then identity might be the wrong term. Maybe this should be something like identifier group. Regardless, my fundamental question still remains, what does it mean when this information is compromised by the network?
(note this is "when" not "if")

<ALEX2> It may not be the only intent, but I would view it as an important one.  Not sure identifier group captures it.  Of course, you can say that ultimately there is a group of identifiers associated with an identity, but the membership of that may change over time. 
What information is compromised here?  The entire group of all identifiers?  Then you would have defeated the purpose of this.  This is why identity should not be exposed.
</ALEX2>

Suppose for instance that my host connects to another host that is behind a firewall. If I want to frequently change my local address because it's a long lived connection then a remote (stateful) firewall needs to participate have knowledge of the end host identity and would participate in an identity protocol. But from the host perspective this seems to create a privacy issue. I have no reason to trust and remote network or firewall and frankly only trust my local network out of necessity (local networks already have identities of users). If IDEAS would purposely share identifying information for users outside of their local network I think this is a potential issue.

<ALEX2> The assumption here is that you would be trusting your GRIDS provider.  (Which is a vast improvement over having to trust any hop on the Intenet.)  When you say "local" vs "remote" network, I assume you are talking about inter-GRIDS scenarios.  This is one of the questions, which information can be shared / leaded between GRIDS providers.  Probably not all information, but for this scenario, I would assume that yes, your identifiers (respectively the fact that they are tied to the same endpoint/identity) is information that would be shared.    
</ALEX2>

Btw, for changing identifiers on long lived connections the possibility that MPTCP and MPT (recently proposal in int-area) are possibly relevant and should be considered to see if they could solve the problem.

<ALEX2> Sure, we should look it.  We should not solve non-problems.  </ALEX2>

Tom

>> develop a framework that can be used by identifier-based protocols 
>> and provides services to address those requirements. We refer to the 
>> -Definition and enforcement of basic networking policies (e.g. 
>> ability to look up an identifier-locator pair, permit forwarding 
>> traffic for particular endpoints on a per-identity basis…)
>>
>> maintained in a draft form or on a collaborative Working Group wiki 
>> to support the efforts of the Working Group and help new comers:
>>
>> -Problem statement
>>
>> -Use cases
>>
>> -Requirements
>>

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 3 Aug 2017 23:40:44 +0000

Hi Padma,

Some responses, inline, <ALEX2>

--- Alex

From: Padma Pillay-Esnault [mailto:[email-masked]]
Sent: Wednesday, August 02, 2017 5:58 PM
To: Alexander Clemm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

Hi Alex

Please see <Padma> below

On Wed, Aug 2, 2017 at 3:57 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks
--- Alex

From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Padma Pillay-Esnault

Dear Ideas

Proposed Charter

</ALEX>

<Padma> One of the feedback we got on this section is as follows:
"The overall structure of the charter should be crisp in describing
the problem space rather than talking nebulously about privacy,
protection, and efficiency"

<ALEX2> Is the issue that it is not crisp enough or that it is not something to focus on?  Personally, I still find this to be an important problem that I have not seen addressed elsewhere, and something we could play a role in, so I would have preferred to rephrase it e.g. as follows
(note that making it clearer makes it unfortunately longer):
At the same time, end users require greater privacy for their networking information and protection from outside threats, while operators demand greater operational efficiency. Identity-enabled networks aim to enable networking applications and services that provide a high degree of privacy and control of end points over their networking data, coupled with greater inherent security than provided by today’s networks. To this end, the working group shall define mechanisms that let endpoints dynamically change identifiers to, for example, facilitate anonymity through obscurity while preventing security issues that might result from abuse, ensuring that information about actual endpoints and their location is revealed only on a need-to-know basis.
However, given it’s removed, my assumption is this should not be in charter at all?
</ALEX2>

<ALEX2>
As deliverables,I would still cut down (i.e. delete) these items in the interest of keeping the scope small.  It is straightforward to add them later.  If the goal is to deliver a framework, sure, all those items will have placeholders and be addressed in the framework.
</ALEX2>

WG deliverables include:
Generic Identity Services Framework
<ALEX> We have heard mixed messages regarding the use of the term “framework” in the context of IETF.  Can we include definition of the framework as part of our deliverables, or would a framework be something that might be specified as background information to provide context, with the actual deliverable consisting instead of service interfaces, data models, and possibly protocols and protocol extensions? (Perhaps Alvaro can provide direction here?)
</ALEX>
<ALEX2> Please refer to Georgios email.  I believe we need guidance on this as a working group, to avoid going down too far one path.  Personally, I am in favor of defining a framework as a deliverable, which will be needed for context for any subsequent specific interfaces/protocols/data models etc.
</ALEX2>

Milestones

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 3 Aug 2017 22:42:49 -0700

Hi Alex

See <Padma2>

On Thu, Aug 3, 2017 at 4:40 PM, Alexander Clemm <[email-masked]>
wrote:

> *From:* Padma Pillay-Esnault [mailto:[email-masked]]
> *Sent:* Wednesday, August 02, 2017 5:58 PM
> *To:* Alexander Clemm <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Ideas] Your input needed: Charter Proposal
>
>
>
> Hi Alex
>
>
>
> On Wed, Aug 2, 2017 at 3:57 PM, Alexander Clemm <
> [email-masked]> wrote:
>
> Hi,
>
>
>
> *"The overall structure of the charter should be crisp in describing the
> problem space rather than talking nebulously about privacy, protection, and
> efficiency"*
>
>
>
> <ALEX2> Is the issue that it is not crisp enough or that it is not
> something to focus on?
>

<Padma2> It was not crisp enough but it does not mean that we should not
focus on it as the problem space clearly mention privacy.

IMHO, efficiency and not creating more security risks are must in all work
in IETF hence the feedback.

Personally, I still find this to be an important problem that I have not
> seen addressed elsewhere, and something we could play a role in, so I would
> have preferred to rephrase it e.g. as follows
>
> At the same time, end users require greater privacy for their networking
> inherent security than provided by today’s networks. To this end, the
> working group shall define mechanisms that let endpoints dynamically change
> identifiers to, for example, facilitate anonymity through obscurity while
> preventing security issues that might result from abuse, ensuring that
> information about actual endpoints and their location is revealed only on a
> need-to-know basis.
>

<Padma2> I will see how to integrate this and will send an update version
tomorrow.

> However, given it’s removed, my assumption is this should not be in
<Padma2> I see what you mean. How about integrating the proposed the text
above?That should be satisfactory cover this aspect or we can add it in the
list of areas covered in framework.

> As deliverables,I would still cut down (i.e. delete) these items in the
> interest of keeping the scope small.  It is straightforward to add them
> later.  If the goal is to deliver a framework, sure, all those items will
> have placeholders and be addressed in the framework.
>

<Padma2> I think we are in agreement here. The version here is under the
assumption that the deliverable is the framework. Therefore these areas
should be considered for the framework.

> <ALEX2> Please refer to Georgios email.  I believe we need guidance on
> this as a working group, to avoid going down too far one path.  Personally,
> I am in favor of defining a framework as a deliverable, which will be
> needed for context for any subsequent specific interfaces/protocols/data
> models etc.
>
> </ALEX2>
>
>
<Padma2>
Personally, defining a framework as a deliverable looks to be a reasonable
and workable objective for a new wg.

I am ccing here Alvaro for guidance regarding this specific question both
you and Georgios raised.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Aug 2017 09:06:03 -0700

> What information is compromised here?  The entire group of all identifiers?  Then you would have defeated the purpose of this.  This is why identity should not be exposed.

Yes, identity should not be exposed by a third party. But neither
should credit card numbers, social card numbers, passport numbers, or
voter registration-- and yet history is replete with incidents of this
sort of sensitive information being exposed. It is impossible to build
a system that can't be compromised, and even if we could build a
perfectly secure system there is no way to enforce that all providers
don't inadvertently or purposely expose the information.

> <ALEX2> The assumption here is that you would be trusting your GRIDS provider.  (Which is a vast improvement over having to trust any hop on the Intenet.)  When you say "local" vs "remote" network,…

Making "the fact that they are tied to the same endpoint/identity"
visible is contrary to the need for anonymity and privacy. Even today
a host can use different source addresses for different flows
(consider that UEs are typically assign a /64 which gives a host
plenty of address to choose from). The Internet works perfectly well
with this model. Sorry, I'm just not seeing how adding identity to the
Internet improves it or improves service to users.

Tom

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 4 Aug 2017 17:31:34 +0000

Hi Tom,

Please find my response at the bottom, <ALEX3>

Thanks
--- Alex

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Friday, August 04, 2017 9:06 AM
To: Alexander Clemm <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

> What information is compromised here?  The entire group of all identifiers?  Then you would have defeated the purpose of this.  This is why identity should not be exposed.

Yes, identity should not be exposed by a third party. But neither should credit card numbers, social card numbers, passport numbers, or voter registration-- and yet history is replete with incidents of this sort of sensitive information being exposed. It is impossible to build a system that can't be compromised, and even if we could build a perfectly secure system there is no way to enforce that all providers don't inadvertently or purposely expose the information.

Making "the fact that they are tied to the same endpoint/identity"
visible is contrary to the need for anonymity and privacy. Even today a host can use different source addresses for different flows (consider that UEs are typically assign a /64 which gives a host plenty of address to choose from). The Internet works perfectly well with this model. Sorry, I'm just not seeing how adding identity to the Internet improves it or improves service to users.

<ALEX3>

Well, it depends on what you mean with "the Internet works perfectly well with this model".  It works perfectly well also for the mirai botnets, the stalkers, the phishers, the outside parties (beyond your SP) who want to profile your communications exchanges.  I think we should try to do better than that.    

The aspect I've been trying to get across concerns that there is an issue today with the desire of users to remain anonymous, while being protected from threats, and while being able to control their own data (beyond personal data of the application level also network level data such as their locator).  Some of these goals are contradictory - the ability to remain anonymous can be exploited by the botnet that launches an attack and wants to evade detection, etc.   How do we strike the right balance?   Presumably there is a good reason for firewalls - but in as far as firewall rules are locator/Ip-based (and possibly identifier-based, but given identifiers can be ephemeral becoming impossible to maintain), those mechanisms are too easy to defeat.  Identity, to me, seems to be a reasonable mechanism to add to the networking arsenal to allow to better strike that balance.  

</ALEX3>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Aug 2017 11:12:44 -0700

On Fri, Aug 4, 2017 at 10:31 AM, Alexander Clemm
<[email-masked]> wrote:
> The aspect I've been trying to get across concerns that there is an issue today with the desire of users to remain anonymous, while being protected from threats, and while being able to control their own data (beyond personal data of the application level also network level data such as their locator).  Some of these goals are contradictory - the ability to remain anonymous can be exploited by the botnet that launches an attack and wants to evade detection, etc.   How do we strike the right balance?

By that same argument encryption has the same problem. We want keep
private communications secret, but allow law enforcement to able to
read the terrorists plans. This was the intent of key escrow, but that
failed pretty spectacularly. It failed in part because of the obvious
privacy concerns and possibility of abuse by authority, but also
failed because the database itself with all the keys cannot be
adequately secured (like my previous point).

> Presumably there is a good reason for firewalls

It's arguable whether there is good reason for firewalls any more. In
any case firewalls are not a necessary part of the Internet
architecture, we should not be building Internet protocol based on
their requirements, firewalls should be the ones adapt to Internet
protocols.

> - but in as far as firewall rules are locator/Ip-based (and possibly identifier-based, but given identifiers can be ephemeral becoming impossible to maintain), those mechanisms are too easy to defeat.  Identity, to me, seems to be a reasonable mechanism to add to the networking arsenal to allow to better strike that balance.
>
Please quantify: "but given identifiers can be ephemeral becoming
impossible to maintain".

Tom

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 4 Aug 2017 18:45:03 +0000

Hi Tom, 

Replies inline below, <ALEX4>

--- Alex

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Friday, August 04, 2017 11:13 AM
To: Alexander Clemm <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

> The aspect I've been trying to get across concerns that there is an issue today with the desire of users to remain anonymous, while being protected from threats, and while being able to control the…

By that same argument encryption has the same problem. We want keep private communications secret, but allow law enforcement to able to read the terrorists plans. This was the intent of key escrow, but that failed pretty spectacularly. It failed in part because of the obvious privacy concerns and possibility of abuse by authority, but also failed because the database itself with all the keys cannot be adequately secured (like my previous point).

<ALEX4> I would argue that the problems are not the same as with encryption (and the state with regards to balance between choices there is arguably better than what have in the rest of networking space), but yes, I agree there are clear analogies.   I am not clear about your suggestion or your conclusion here.  Are you saying we should just give up and accept having to choose between security and privacy, and that the choice is in favor of privacy over security, or really perhaps neither?    
</ALEX4>

> Presumably there is a good reason for firewalls

It's arguable whether there is good reason for firewalls any more. In any case firewalls are not a necessary part of the Internet architecture, we should not be building Internet protocol based on their requirements, firewalls should be the ones adapt to Internet protocols.

<ALEX4> True, but my point is that there are legitimate reasons why people have concerns about allowing just any uncontrolled communications/packets anonymously on their network.  It would be good if we could address those concerns, not punting the problem and leaving it to someone else to solve it (or not).   I think that there is an opportunity that the identity concept can play here.  
</ALEX4>

> - but in as far as firewall rules are locator/Ip-based (and possibly identifier-based, but given identifiers can be ephemeral becoming impossible to maintain), those mechanisms are too easy to defe…
Please quantify: "but given identifiers can be ephemeral becoming impossible to maintain".

<ALEX4> How often do you expect ephemerals IDs to be used?  Your management overhead will be proportional to that rate.  Whenever you have a new / previously unknown identifier of an endpoint that you would like to subject to a rule, you would have to make an update (to the rule, to a database somewhere, in one or possibly multiple places depending on your defense architecture).   
</ALEX4>

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Aug 2017 15:31:37 -0700

> <ALEX4> I would argue that the problems are not the same as with encryption (and the state with regards to balance between choices there is arguably better than what have in the rest of networking…

My point is that if I want secure communications today I would encrypt
the communications. If I want to obfuscate source I can get multiple
addresses from my source provider and use different ones per my needs.
There should be no reason for any node in the path to have to
correlate that two source address really belong to the same entity. If
the peer needs to do this it will use higher layer mechanisms to
establish identity. The mapping system might have two identifiers
sharing the same locator, but that should not imply any semantics or
that they share any other properties.

> <ALEX4> True, but my point is that there are legitimate reasons why people have concerns about allowing just any uncontrolled communications/packets anonymously on their network.  It would be good…

Such concerns are local issues not global. A network is free to apply
whatever mechanisms it deems necessary to solve it's perceived
problems, but this is not a problem for IETF to generically solve.

> <ALEX4> How often do you expect ephemerals IDs to be used?  Your management overhead will be proportional to that rate.  Whenever you have a new / previously unknown identifier of an endpoint that…
I expect them to be used like any other IP addresses. We typically
don't put rules for individual IP addresses in firewall rules so I
would expect that individual identifiers would not be placed into the
firewall either. If a site wishes they can  structure identifiers to
include some aggregation information and that can be used in firewall
rules. This sort of aggregation is already being done in at least one
case I know of where a small 8 bit prefix in the identifier indicates
the department of an enterprise (not specifically identity of the end
point).

Tom

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 4 Aug 2017 23:51:42 +0000

Hi Tom,

Yes, you can obfuscate and you can move everything into the application-layer.  But this means giving up on e.g. anonymization-coupled-with-security value at the level of the network; at the network level you are clearly sacrificing one for the other. I still think that having the option to introduce a notion of identity is useful and enables interesting services that can be provided by a network provider (without having to rely and depend on stuff at the app layer).  It gives you another tool at your disposal you can use and that will be straightforward to incorporate in mapping infrastructure.  

Now, we could take the identity out of identity-enabled networks, in which case we are left with just mapping and perhaps identifier lifecycle services as well as a WG that is IMHO somewhat misnamed.  Perhaps this can provide a deliverable that is sufficient for an initial step, but I think it falls a bit short on vision for my taste.  Anyway, just my two cents.  

--- Alex

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Friday, August 04, 2017 3:32 PM
To: Alexander Clemm <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Your input needed: Charter Proposal

> <ALEX4> I would argue that the problems are not the same as with encryption (and the state with regards to balance between choices there is arguably better than what have in the rest of networking…

My point is that if I want secure communications today I would encrypt the communications. If I want to obfuscate source I can get multiple addresses from my source provider and use different ones per my needs.
There should be no reason for any node in the path to have to correlate that two source address really belong to the same entity. If the peer needs to do this it will use higher layer mechanisms to establish identity. The mapping system might have two identifiers sharing the same locator, but that should not imply any semantics or that they share any other properties.

> <ALEX4> True, but my point is that there are legitimate reasons why people have concerns about allowing just any uncontrolled communications/packets anonymously on their network.  It would be good…

Such concerns are local issues not global. A network is free to apply whatever mechanisms it deems necessary to solve it's perceived problems, but this is not a problem for IETF to generically solve.

> <ALEX4> How often do you expect ephemerals IDs to be used?  Your management overhead will be proportional to that rate.  Whenever you have a new / previously unknown identifier of an endpoint that…
I expect them to be used like any other IP addresses. We typically don't put rules for individual IP addresses in firewall rules so I would expect that individual identifiers would not be placed into the firewall either. If a site wishes they can  structure identifiers to include some aggregation information and that can be used in firewall rules. This sort of aggregation is already being done in at least one case I know of where a small 8 bit prefix in the identifier indicates the department of an enterprise (not specifically identity of the end point).

Tom