Subject: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Fri, 08 Sep 2017 15:01:32 -0700

Spencer Dawkins has entered the following ballot position for
charter-ietf-ideas-00-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ideas/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

If only "Yes, but ..." was a position I could select ...

I'm really glad to see this going forward - enough to ballot "Yes".

This looks like a framework that could be used in a number of use cases, and my
"Yes, but ..." is that it's not clear to me, how much analysis of ID/Loc
separation security implications that some folks downstream are going to have
to do, when using this framework.

I'm remembering an exchange with a document editor on the last telechat that
could be summarized as "we didn't do the work on general security implications
of X, so each usage of X has to do that work itself, rather than pointing to
previous work". OK, if that's where we are, but IDEAS hasn't already done the
same thing (yet).

I'm looking at deliverables like "Requirements for identity authentication and
authorization service (for GRIDS)" and "Threat model document", so I know
there's SOMEthing in there, but I don't know what else might be required, if
someone wanted to think about the general security implications of GRIDS, and I
note that those deliverables are listed as living drafts or wiki entries, which
doesn't sound like anything GRIDS framework usages would be able to point to,
when they need to look at security implications.

Is a look at general security implications, in a form that specific framework
usages can point to, on the table for IDEAS?

(It doesn't have to be, for me to ballot Yes, but I did have to ask, right?)

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 11 Sep 2017 18:55:36 +0000

charter-ietf-ideas-00-00: Yes
We support standardizing the mapping system and control plane protocols.

Kalyani Bogineni
Verizon

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Friday, September 08, 2017 6:02 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [E] [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_charter-2Dietf-2Dideas_&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo&m=4iTQevao0FvmGJ2lQosFV_brUjdjM9g2wGBLFxgT5Fs&s=w6TJbOQo5YtxXCLwzLkvFZmbH9XAyByGSWycK2md3Hs&e= 

This looks like a framework that could be used in a number of use cases, and my "Yes, but ..." is that it's not clear to me, how much analysis of ID/Loc separation security implications that some folks downstream are going to have to do, when using this framework.

I'm remembering an exchange with a document editor on the last telechat that could be summarized as "we didn't do the work on general security implications of X, so each usage of X has to do that work itself, rather than pointing to previous work". OK, if that's where we are, but IDEAS hasn't already done the same thing (yet).

I'm looking at deliverables like "Requirements for identity authentication and authorization service (for GRIDS)" and "Threat model document", so I know there's SOMEthing in there, but I don't know what else might be required, if someone wanted to think about the general security implications of GRIDS, and I note that those deliverables are listed as living drafts or wiki entries, which doesn't sound like anything GRIDS framework usages would be able to point to, when they need to look at security implications.

Is a look at general security implications, in a form that specific framework usages can point to, on the table for IDEAS?

_______________________________________________
Ideas mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ideas&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo&m=4iTQevao0FvmGJ2lQosFV_brUjdjM9g2wGBLFxgT5Fs&s=t9wokY80pZ8u3yVsBlAumHv46uTMT6LWzptTTFlFlys&e=

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Sep 2017 14:17:23 -0500

Hi, Kalyani,

> We support standardizing the mapping system and control plane protocols.

I'm sorry, but I don't understand this as a response to whether security
analysis at the framework level is in scope for IDEAS?

Thanks,

Spencer

> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_charter-2Dietf-2Dideas_&d=DwICAg&c=
> udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=
> IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo&m=4iTQevao0FvmGJ2lQosFV_
> brUjdjM9g2wGBLFxgT5Fs&s=w6TJbOQo5YtxXCLwzLkvFZmbH9XAyByGSWycK2md3Hs&e=
>
>
>
> This looks like a framework that could be used in a number of use cases,
> and my "Yes, but ..." is that it's not clear to me, how much analysis of
> ID/Loc separation security implications that some folks downstream are
> going to have to do, when using this framework.
>
> I'm remembering an exchange with a document editor on the last telechat
> that could be summarized as "we didn't do the work on general security
> implications of X, so each usage of X has to do that work itself, rather
> than pointing to previous work". OK, if that's where we are, but IDEAS
> hasn't already done the same thing (yet).
>
> I'm looking at deliverables like "Requirements for identity authentication
> and authorization service (for GRIDS)" and "Threat model document", so I
> know there's SOMEthing in there, but I don't know what else might be
> required, if someone wanted to think about the general security
> implications of GRIDS, and I note that those deliverables are listed as
> living drafts or wiki entries, which doesn't sound like anything GRIDS
> framework usages would be able to point to, when they need to look at
> security implications.
>
> Is a look at general security implications, in a form that specific
> framework usages can point to, on the table for IDEAS?
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_ideas&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LR
> xpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo&m=
> 4iTQevao0FvmGJ2lQosFV_brUjdjM9g2wGBLFxgT5Fs&s=
> t9wokY80pZ8u3yVsBlAumHv46uTMT6LWzptTTFlFlys&e=
>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 11 Sep 2017 19:39:41 +0000

Spencer:

We are supportive of IDEAS charter that includes what is of interest to us: mapping system and
control plane protocols.

Regards,
Kalyani Bogineni
Verizon

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Monday, September 11, 2017 3:17 PM
To: Bogineni, Kalyani
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [E] [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

Hi, Kalyani,

On Mon, Sep 11, 2017 at 1:55 PM, Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>> wrote:
charter-ietf-ideas-00-00: Yes
We support standardizing the mapping system and control plane protocols.

I'm sorry, but I don't understand this as a response to whether security analysis at the framework level is in scope for IDEAS?

Thanks,

Spencer

Kalyani Bogineni
Verizon

-----Original Message-----
From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Spencer Dawkins
Sent: Friday, September 08, 2017 6:02 PM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [E] [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

_______________________________________________
Ideas mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ideas&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9Mzr2tsDA8-g976yWB1sPbdMo&m=4iTQevao0FvmGJ2lQosFV_brUjdjM9g2wGBLFxgT5Fs&s=t9wokY80pZ8u3yVsBlAumHv46uTMT6LWzptTTFlFlys&e=

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 11 Sep 2017 22:14:24 +0000

Spencer:

Hi!

The support documents are listed as examples, and the current intent is not to publish them.

I fully expect the Framework to have appropriate Security Considerations (i.e. not a section saying that other documents will consider security) so that every future document doesn’t have to re-examine, at least the general portion.  Other documents may obviously contain specific considerations applicable to them (for extensions, protocols, etc.).

If you want to, I can add a line pointing explicitly at general security implications of GRIDS as part of the items that should be considered when developing the framework.

Thanks!

Alvaro.

On 9/8/17, 6:01 PM, "Spencer Dawkins" <[email-masked]> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Sep 2017 23:05:24 -0500

Hi, Alvaro,

On Mon, Sep 11, 2017 at 5:14 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

> I fully expect the Framework to have appropriate Security Considerations
> (i.e. not a section saying that other documents will consider security) so
> that every future document doesn’t have to re-examine, at least the general
> portion.  Other documents may obviously contain specific considerations
> applicable to them (for extensions, protocols, etc.).
>

This sounds excellent.

> If you want to, I can add a line pointing explicitly at general security
> implications of GRIDS as part of the items that should be considered when
> developing the framework.

Do the right thing, but I do think recent experience has shown that it's
easy to push off the security analysis at the framework level so that a
working group can produce a specific usage quickly (or, it would have been
quickly, if the specific usage was able to point to existing security
analysis in the framework itself ;-)

Spencer

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Sep 2017 13:35:55 -0700

On Fri, Sep 8, 2017 at 3:01 PM, Spencer Dawkins
<[email-masked]> wrote:
>e
Spencer,

I believe there are two discrete components being championed in IDEAS:
One, is mapping system of identifier to locators and the other is
introduction of identity mapping. The former looks much more like a
routing or name resolution protocol, and the later would be doing
identity management and possible collecting PII. There are obviously
many security implications to both parts, however I think the threats
and sensitivity between these is quite different, i.e. hacking into
the ID/loc mapping data base could result in misdirecting packets,
hacking into identity store may result in loss of users' privacy.
These seem fundamentally different so security considerations should
probably be considered independently of each other.

Tom

> https://www.ietf.org/mailman/listinfo/ideas

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 Sep 2017 20:56:41 +0000

Spencer,

	I believe there are two discrete components being championed in IDEAS:
	One, is mapping system of identifier to locators and the other is introduction of identity mapping. The former looks much more like a routing or name resolution protocol, and the later would be doing identity management and possible collecting PII. There are obviously many security implications to 	both parts, however I think the threats and sensitivity between these is quite different, i.e. hacking into the ID/loc mapping data base could result in misdirecting packets, hacking into identity store may result in loss of users' privacy.

[Uma]: Tom, you summarized well. I would note there is interconnected aspect to these 2 items w.r.t security. Identity AUTH can inherently bring security (and if needed privacy) to Identifier/Location mapping and strengthen that area tremondoesly. 
However, Identity privacy itself has  to be tackled and there are existing well defined mechanisms for that as discussed earlier in the IDEAS list (pointer from Diego, is a great example). 
When we described identity and it's uses here https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01#section-7 , we noted threat analysis aspect in Section 7 and was reflected in charter too. 

	These seem fundamentally different so security considerations should probably be considered independently of each other.

[Uma]: Different but interdependent on some aspects as mentioned above.

	Tom

	> (It doesn't have to be, for me to ballot Yes, but I did have to ask,

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 Sep 2017 23:35:12 +0000

Hi Alvaro,

From: Ideas [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, September 11, 2017 9:05 PM
To: Alvaro Retana (aretana) <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>
Subject: Re: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

Hi, Alvaro,

On Mon, Sep 11, 2017 at 5:14 PM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:
Spencer:

Hi!

This sounds excellent.

[Uma]: Agree with your thoughts w.r.t security aspects in the framework and subsequent documents.

--
Uma C.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 13 Sep 2017 22:16:49 -0500

So, responding to Uma's response to Tom's response to my response to the
proposed charter (whew!),

On Wed, Sep 13, 2017 at 3:56 PM, Uma Chunduri <[email-masked]>
wrote:

> introduction of identity mapping. The former looks much more like a routing
> or name resolution protocol, and the later would be doing identity
> management and possible collecting PII. There are obviously many security
> implications to      both parts, however I think the threats and
> sensitivity between these is quite different, i.e. hacking into the ID/loc
> mapping data base could result in misdirecting packets, hacking into
> identity store may result in loss of users' privacy.
>

Tom's response to me makes sense.

> [Uma]: Tom, you summarized well. I would note there is interconnected
> aspect to these 2 items w.r.t security. Identity AUTH can inherently bring
> security (and if needed privacy) to Identifier/Location mapping and
> strengthen that area tremondoesly.
> However, Identity privacy itself has  to be tackled and there are existing
> well defined mechanisms for that as discussed earlier in the IDEAS list
> (pointer from Diego, is a great example).
> When we described identity and it's uses here https://tools.ietf.org/html/
> draft-ccm-ideas-identity-use-cases-01#section-7 , we noted threat
> analysis aspect in Section 7 and was reflected in charter too.
>

Uma's response to Tom makes sense.

>         These seem fundamentally different so security considerations
> should probably be considered independently of each other.
>

So, what I'm not understanding, is that there are two work items, and only
one framework deliverable. Is the intention that the identifier/locator
mapping system and the identity mapping system are different enough to have
different security considerations, but are so tightly interwoven that
neither is usable without the other, or with any other mapping system
separately, so it makes sense to lump them into one framework?

Again, either answer is OK, but if I'm going to ask, now would be the time
:-)

Spencer

        Tom

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 14 Sep 2017 15:52:12 +0000

Hi Spencer,

Quick response In-line [Uma]:

Thx!
--
Uma C.

From: Ideas [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Wednesday, September 13, 2017 8:17 PM
To: Uma Chunduri <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

So, responding to Uma's response to Tom's response to my response to the proposed charter (whew!),

        Spencer,

So, what I'm not understanding, is that there are two work items, and only one framework deliverable. Is the intention that the identifier/locator mapping system and the identity mapping system are different enough to have different security considerations, but are so tightly interwoven that neither is usable without the other, or with any other mapping system separately, so it makes sense to lump them into one framework?

[Uma]: AFAICT, one cohesive framework to cover these 2 aspects is a good option. Obviously,  solutions are vastly different on how to do Identity privacy and federated Identifier/location mapping system with Identity services and those can be taken up in different documents later.

Again, either answer is OK, but if I'm going to ask, now would be the time :-)

[Uma]: Me too and would be happy to listen other opinions. Thanks for thoughtful comments and follow-up.

Spencer

        Tom

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 14 Sep 2017 16:49:47 +0000

Hi,

I agree with Uma’s comments that one framework should cover both idy/idf mapping and idf/locator mapping, although different aspects/focuses will be considered.

Thanks,
Yingzhen

From: Ideas [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Thursday, September 14, 2017 8:52 AM
To: Spencer Dawkins at IETF <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: Re: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

Hi Spencer,

Thx!
--
Uma C.

From: Ideas [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Wednesday, September 13, 2017 8:17 PM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ideas] Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

        Spencer,

Spencer

        Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 14 Sep 2017 10:14:52 -0700

On Wed, Sep 13, 2017 at 8:16 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
>> implications to      both parts, however I think the threats and sensitivity
>> between these is quite different, i.e. hacking into the ID/loc mapping data
>> base could result in misdirecting packets, hacking into identity store may
>> result in loss of users' privacy.
>
>
>> When we described identity and it's uses here
>> https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01#section-7
>> , we noted threat analysis aspect in Section 7 and was reflected in charter
>> too.
>
>
Spencer,

The underlying mapping system (basically specialized key/value store
with protocol) is common between the two use cases. However, the these
cases are independent in a least the sense that identifier/locator
protocols (as well as those for network virtualization) require
identifier->locator mapping but don't require any concept of identity.
I believe, the need for the ID/loc mapping is well understood at this
point, whereas the concept and rationalization for identity in this
area are still emerging. Both of these are valid items to pursue, but
I hope that a WG can minimize dependencies so that development of the
ID/loc mapping system does not become a long, drawn out multi-year
process. If this can be done in a single framework then that would be
okay I think.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Sep 2017 10:27:01 -0700

> process. If this can be done in a single framework then that would be

Agree 100%.

Dino

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 Sep 2017 13:40:40 -0500

Hi, Tom and Dino,

> > process. If this can be done in a single framework then that would be

You guys are thinking about the stuff I was wondering about. I'll trust
that the right thing happens.

Thanks,

Spencer, who has stayed as a Yes ballot through this conversation ...

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Sep 2017 11:43:37 -0700

> You guys are thinking about the stuff I was wondering about. I'll trust that the right thing happens.
> 
> Thanks,
> 
> Spencer, who has stayed as a Yes ballot through this conversation … 

From a LISP perspective, you do a mapping system lookup on some opaque key that returns a record. If the opaque key is an Identity that returns a Identifier record, so be it. And if the opaque key is an Identifier (EID) that returns a Location (RLOC) record, then so be it.

We can have the mapping system take the former lookup and return both records. So a two stage lookup can be avoided.

Dino