Subject: [sfc] Ben Campbell's No Record on charter-ietf-sfc-01-01: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jan 2018 19:48:05 -0800

Ben Campbell has entered the following ballot position for
charter-ietf-sfc-01-01: No Record

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-sfc/

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

Would it be reasonable to add a focus on privacy considerations, either as part
of item 2), or as a separate top-level item?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Jan 2018 23:08:46 -0500

Item 2 already includes confidentiality explicitly.
I do not think adding the word privacy would help us understand that 
there is something else to be covered.  If there is soemthing else, i am 
happy to add it (see it added, since this belongs to the IESG at this 
point).  But I think it would take more wording that just saying 
"privacy" in the list of security issues.

Yours,
Joel

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jan 2018 22:40:57 -0600

> On Jan 23, 2018, at 10:08 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I do not think adding the word privacy would help us understand that there is something else to be covered.  If there is soemthing else, i am happy to add it (see it added, since this belongs to the IESG at this point).  But I think it would take more wording that just saying "privacy" in the list of security issues.

I see confidentiality as a necessary but not sufficient condition for privacy. For example, if a network function uses the service chaining header as a channel for the equivalent of header enrichment, it may create a privacy problem by passing metadata down the chain that the user may have preferred to keep private. The fact that the channel may have confidentiality protection doesn’t change that.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jan 2018 08:19:50 -0500

Given that the operation of SFC is entirely within one domain, I do not 
see how a service function can create and pass down metadata "that the 
user would have preferred to keep private."  SFC is NOT for the operator 
to pass metdata to end services outside of their control.  As such, the 
metadata is carrying information the operator knows to that same operator.

Within the operator's domain, it is both ineffective and outside of our 
scope to attempt to define what metadata operators choose to put on packets.

So the quesiton again is what you would like to see covered in that 
point that will be useful in improving privacy.

Yours,
Joel

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Jan 2018 09:49:48 -0600

I mainly want to make sure that the privacy considerations that have already been considered continue to carry forward into ongoing work.

I think it would be nice to have a bit more nuanced guidance about keeping things in the "same domain". With the current popularity of hosted cloud environments, domains may overlap. Or a single operator may be made of multiple business units where it may or may not make sense to share privacy-sensitive information. I also have a somewhat cynical expectation that some operators will define the term “domain” more expansively that we might have in mind.

In any case, this was not a blocking comment.

Thanks!

Ben.

> On Jan 24, 2018, at 7:19 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Given that the operation of SFC is entirely within one domain, I do not see how a service function can create and pass down metadata "that the user would have preferred to keep private."  SFC is NOT for the operator to pass metdata to end services outside of their control.  As such, the metadata is carrying information the operator knows to that same operator.
> 
> Within the operator's domain, it is both ineffective and outside of our scope to attempt to define what metadata operators choose to put on packets.
> 
> So the quesiton again is what you would like to see covered in that point that will be useful in improving privacy.
> 
> Yours,
> Joel
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 24 Jan 2018 11:45:06 -0500

> On Jan 24, 2018, at 8:19 AM, Joel M. Halpern <[email-masked]> wrote:
> 

But this is something we take into consideration all the time when defining types or data structures to hold specific kinds of data. When I look at some of what is proposed in https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-06 <https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-06>, for example, it seems like the kind of granularity Ben is talking about would be worth some discussion, because it might not be the case that every node in the domain should be authorized to consume every piece of header metadata. Even if it’s just in one of the informational applicability documents that the charter talks about, this seems like it should be called out somewhere.

Alissa

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jan 2018 11:50:55 -0500

That is why we have confidentiality called out as a work topic. 
Figuring out how to do it effectively, so only the right things can see 
the information (and similarly for integrity so only the right things 
can modify the information) has a lot of complexity, and is agreed to be 
important.

If there are additional specific words you think would help that bullet, 
please say so.

Yours,
Joel

On 1/24/18 11:45 AM, Alissa Cooper wrote:
> 
>> On Jan 24, 2018, at 8:19 AM, Joel M. Halpern <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Given that the operation of SFC is entirely within one domain, I do 
>> not see how a service function can create and pass down metadata "that 
>> the user would have preferred to keep private."  SFC is NOT for the 
>> operator to pass metdata to end services outside of their control.  As 
>> such, the metadata is carrying information the operator knows to that 
>> same operator.
>>
>> Within the operator's domain, it is both ineffective and outside of 
>> our scope to attempt to define what metadata operators choose to put 
>> on packets.
> 
> But this is something we take into consideration all the time when 
> defining types or data structures to hold specific kinds of data. When I 
> look at some of what is proposed in 
> https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-06, 
> for example, it seems like the kind of granularity Ben is talking about 
> would be worth some discussion, because it might not be the case that 
> every node in the domain should be authorized to consume every piece of 
> header metadata. Even if it’s just in one of the informational 
> applicability documents that the charter talks about, this seems like it 
> should be called out somewhere.
> 
> Alissa
> 
>>
>>>> On Jan 23, 2018, at 10:08 PM, Joel M. Halpern <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> there is something else to be covered.  If there is soemthing else, 
>>>> i am happy to add it (see it added, since this belongs to the IESG 
>>>> at this point).  But I think it would take more wording that just 
>>>> saying "privacy" in the list of security issues.
>>> I see confidentiality as a necessary but not sufficient condition for 
>>> privacy. For example, if a network function uses the service chaining 
>>> header as a channel for the equivalent of header enrichment, it may 
>>> create a privacy problem by passing metadata down the chain that the 
>>> user may have preferred to keep private. The fact that the channel 
>>> may have confidentiality protection doesn’t change that.
>>>>
>>>> Yours,
>>>> Joel
>>>>