Subject: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Thu, 28 May 2015 06:24:29 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Stephen's discuss and comment points and am just adding a
few that I think are also important.

1. The Security Considerations section only talks about privacy of the
SFC information for classification.  The more important point may be the
privacy of any data gathered from a payload used for the classification
and this needs to be mentioned.

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

1. For the Service Functions, I would think you would want to leave out
"Lawful Intercept" as a device type since it's not a universal
requirement on networks and immediately raises privacy concerns.

2. Section 3, #3
Classification on part of the packet payload will become increasingly
more difficult as encryption is rolled out.  The IETF and IAB both
support the increased use of encryption for privacy and security purposes
and are looking to have it end-to-end where possible.  With the work out
of TCPInc, encryption will be even more prevalent.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 28 May 2015 15:33:18 +0200

Kathleen,
> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
And? Is this a valid reason not to mention it?

Regards, Benoit
> .

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 May 2015 09:37:40 -0400

> And? Is this a valid reason not to mention it?

Do you mean not to mention the privacy concerns?  If so, no as we are not
there yet and it will take years before we get to a state where this won't
matter.  There are too many protocols that we do not have answers for yet
and then deployment of those that have been approved will also take time.
There's too much of a gap, so the concern is valid and should be mentioned.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Benoit Claise <[email-masked]>
Date: Thu, 28 May 2015 15:42:31 +0200

On 28/05/2015 15:37, Kathleen Moriarty wrote:
>
>
> On Thu, May 28, 2015 at 9:33 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Kathleen,
>
>         Please refer to
>         https://www.ietf.org/iesg/statement/discuss-criteria.html
> Do you mean not to mention the privacy concerns?
No, "Classification on part of the packet payload". I agree that the 
privacy concerns must be mentioned.
Maybe I misunderstood your comment that you wanted to remove the 
"Classification on part of the packet payload" from the draft.

Regards, Benoit
> If so, no as we are not there yet and it will take years before we get 
> to a state where this won't matter. There are too many protocols that 
> we do not have answers for yet and then deployment of those that have 
> been approved will also take time.  There's too much of a gap, so the 
> concern is valid and should be mentioned.
>
> Thanks,
> Kathleen
>
>
>     Regards, Benoit
>
>
>
>         .
>
>
>
>
>
> -- 
>
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 May 2015 09:48:04 -0400

> "Classification on part of the packet payload" from the draft.

I just want the security consideration to be stated clearly, thanks.  This
functionality will go away in time.  SPs are already having trouble with
DLP solutions, so a warning is enough I think and is what is appropriate
for the section (considerations).

Thanks,
Kathleen

> to a state where this won't matter.  There are too many protocols that we
> do not have answers for yet and then deployment of those that have been
> approved will also take time.  There's too much of a gap, so the concern is
> valid and should be mentioned.
>
>  Thanks,
> Kathleen
>
>
>> Regards, Benoit
>>
>>>
>>>
>>> .
>>>
>>>
>>
>
>
>  --
>
> Best regards,
> Kathleen
>
>
>

-- 

Best regards,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 10:06:18 -0400

I do not know what it would mean to apply privacy to information that is
a) gathered from a payload
b) and delivered along with that unprotected payload?

Yours,
Joel

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 May 2015 10:10:46 -0400

Hi Joel,

> b) and delivered along with that unprotected payload?

If you go back to the text in my discuss, I'm concerned about privacy of
data that is in a payload that may be used in the SFC architecture.  I am
not saying that you have to apply privacy, just that it may be exposed when
payloads are accessed and used.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 10:19:12 -0400

I am missing your point.  Sorry.  If it is in the payload, it is 
exposed.  If the payload is protected from exposure, then SFC won't be 
able to extract it, so can't expose it.  We are clear already in the 
document that SFC metadata has to be protected from exposure outside of 
the domain, noit because it is in the payload, but for cases where it is 
derived from other sources that may be sensitive.

So I have real trouble figuring out how to address this concern.

As for your comments,
I have no problem removing LI as an example.  I also have no problem 
leaving it in.  it is a service functions a significant number of 
operators are looking at.  There is no service function that will be 
used by all operators.
As for pervasive encryption, it is true that it will become much more 
common, and such will affect which service functions are useful.  Which 
is one of several reasons why the architecture does not try to define 
the set of service functions.

Yours,
Joel

On 5/28/15 10:10 AM, Kathleen Moriarty wrote:
> Hi Joel,
>
> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> data that is in a payload that may be used in the SFC architecture.  I
> am not saying that you have to apply privacy, just that it may be
> exposed when payloads are accessed and used.
>
> Thanks,
> Kathleen
>
>
>     Yours,
>     Joel
>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 May 2015 10:30:30 -0400

On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern <[email-masked]>
wrote:

> I am missing your point.  Sorry.  If it is in the payload, it is exposed.
> If the payload is protected from exposure, then SFC won't be able to
> extract it, so can't expose it.  We are clear already in the document that
> SFC metadata has to be protected from exposure outside of the domain, noit
> because it is in the payload, but for cases where it is derived from other
> sources that may be sensitive.
>
> Right, but you are pulling that content out and using it in ways that may
not have been intended by those who created it and didn't encrypt it.  This
raises the security/privacy concern that their data may be used in ways
they did not intend and be put into places they didn't expect.  If it's
data that has to be tracked for record retention, through an ESI data map
or similar, its one more place this data resides that needs to be tracked.
If the warning is there that this could happen and is a possible privacy
concern, my point is addressed.

Thank you,
Kathleen

> leaving it in.  it is a service functions a significant number of operators
> are looking at.  There is no service function that will be used by all
> operators.
> common, and such will affect which service functions are useful.  Which is
> one of several reasons why the architecture does not try to define the set
> of service functions.
>
> Yours,
> Joel
>

-- 

Best regards,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 10:35:10 -0400

There is already text about letting information out of the service 
chaining domain.

As for recording information
a) that would be a service function behavior, not an SFC behavior
b) that is not made easier or harder by the use of SFC

In the abstract warning operators that retaining subscriber information 
is a sensitive undertaking is sensible.  But it seems a really bad fit 
for this document.  It is an application issue.

Yours,
Joel

On 5/28/15 10:30 AM, Kathleen Moriarty wrote:
>
>
> On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern <[email-masked]
>     exposed.  If the payload is protected from exposure, then SFC won't
>     be able to extract it, so can't expose it.  We are clear already in
>     the document that SFC metadata has to be protected from exposure
>     outside of the domain, noit because it is in the payload, but for
>     cases where it is derived from other sources that may be sensitive.
>
> Right, but you are pulling that content out and using it in ways that
> may not have been intended by those who created it and didn't encrypt
> it.  This raises the security/privacy concern that their data may be
> used in ways they did not intend and be put into places they didn't
> expect.  If it's data that has to be tracked for record retention,
> through an ESI data map or similar, its one more place this data resides
> that needs to be tracked.  If the warning is there that this could
> happen and is a possible privacy concern, my point is addressed.
>
> Thank you,
> Kathleen
>
>     As for pervasive encryption, it is true that it will become much
>     more common, and such will affect which service functions are
>     useful.  Which is one of several reasons why the architecture does
>     not try to define the set of service functions.
>
>     Yours,
>     Joel
>
>         On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                  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
>                  I agree with Stephen's discuss and comment points and
>         am just
>                  adding a
>                  1. The Security Considerations section only talks about
>         privacy
>                  of the
>                  SFC information for classification.  The more important
>         point
>                  may be the
>                  1. For the Service Functions, I would think you would
>         want to
>                  leave out
>                  support the increased use of encryption for privacy and
>         security
>                  purposes
>                  and are looking to have it end-to-end where possible.
>         With the
>                  work out

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 16:39:43 +0000

Kathleen,

Thank you for taking the time to review this document.

I am responding to this email on the thread, because I think it is the one that most clearly explains your concerns. I also include an additional clarification you wrote on a different email, all below for context.

Below you say:
“I'm concerned about privacy of data that is in a payload that may be used in the SFC architecture.”
and
“you are pulling that content out and using it in ways that may not have been intended by those who created it and didn't encrypt it.”

I am also having some trouble exemplifying and visualizing your concern, and how to address it.

Could you please, perhaps, be more explicit as to how ‘content is pulled from the payload and used in unintended ways’? What exactly do you have in mind? Can you share an example?

The payload is being used to classify — what other unintended use do you see?

Classification based on inspecting a payload is certainly not a new element created by this architecture.

Thanks,

— Carlos.

> On May 28, 2015, at 10:10 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Joel,
> 
> On Thu, May 28, 2015 at 10:06 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> If you go back to the text in my discuss, I'm concerned about privacy of data that is in a payload that may be used in the SFC architecture.  I am not saying that you have to apply privacy, just that it may be exposed when payloads are accessed and used.
> 
> Thanks,
> Kathleen
> 

[…]

> On May 28, 2015, at 10:30 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> On Thu, May 28, 2015 at 10:19 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> I am missing your point.  Sorry.  If it is in the payload, it is exposed.  If the payload is protected from exposure, then SFC won't be able to extract it, so can't expose it.  We are clear already in the document that SFC metadata has to be protected from exposure outside of the domain, noit because it is in the payload, but for cases where it is derived from other sources that may be sensitive.
> 
> Right, but you are pulling that content out and using it in ways that may not have been intended by those who created it and didn't encrypt it.  This raises the security/privacy concern that their data may be used in ways they did not intend and be put into places they didn't expect.  If it's data that has to be tracked for record retention, through an ESI data map or similar, its one more place this data resides that needs to be tracked.  If the warning is there that this could happen and is a possible privacy concern, my point is addressed.
> 
> Thank you,
> Kathleen
> 
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 May 2015 16:32:07 -0400

Carlos & Joel,

Apologies for top-posting, but just quickly....

Private information could absolutely be pulled from the packet and even
placed into metadata as an easy shortcut for flow identification.
Consider a case where the packet included the EMEI and that was used as
part of a flow identifier.  It does a great job as a unique part of a flow
identifier tuple - but it also reveals the user and handset.

Perhaps something along the lines of:

"The SFC architecture does not define what types of service functions might
be included.  However, it does allow for the passing of information from
one service function to the next in the SFP.  This information might be
passed indirectly via metadata that identifies the flow and allows the next
service function to look up that information.  Alternately, that
information might be passed directly in a packet's metadata.  It is
important to consider the privacy considerations of how that information is
shared along the SFP and that it is removed promptly when no longer needed
operationally for the SFP.

For instance, one type of service function that may exist is a flow
classifier.  Depending upon whether or not the packet is encrypted, as is
increasingly common [ REFERENCE NEEDED], metadata to identify the flow
might be pulled from the packet's headers and/or from DPI.  When metadata
is derived from information that a user may consider private (i.e.
identity, equipment, URI, application, etc.), there are many ways [see RFC
6973] to mitigate the threat of leaking such pre-processed private data
across the SFC.   For example, one method might be to process and provide
an otherwise unrelated identifier or tuple to be forwarded along the SFP as
metadata or associated indirectly with that metadata."

When you combine the reality of pervasive monitoring - even within some
administrative domains that have not agreed to it - with passing private
information along with the packets, I do think it is useful to have some
considerations that address this.

Obviously, as the control plane and details for passing along meta-data
gets further developed, this can be better articulated.

Please let me know if this helps clarify.

Thanks,
Alia

On Thu, May 28, 2015 at 12:39 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> I am responding to this email on the thread, because I think it is the one
> that most clearly explains your concerns. I also include an additional
> clarification you wrote on a different email, all below for context.
>
> Below you say:
> *“I'm concerned about privacy of data that is in a payload that may be
> used in the SFC architecture.”*
> and
> *“you are pulling that content out and using it in ways that may not have
> been intended by those who created it and didn't encrypt it.”*
>
> Could you please, perhaps, be more explicit as to how ‘content is pulled
> from the payload and used in unintended ways’? What exactly do you have in
> mind? Can you share an example?
>
>> exposed.  If the payload is protected from exposure, then SFC won't be able
>> to extract it, so can't expose it.  We are clear already in the document
>> that SFC metadata has to be protected from exposure outside of the domain,
>> noit because it is in the payload, but for cases where it is derived from
>> other sources that may be sensitive.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 16:50:05 -0400

If the data is already in the packet, and the packet is not protected, 
then while copying it may make it easier to extract, that ease is pretty 
small, and the data was already extractable before service chaining.
If the data is in the packet and the packet is encrypted, then SFC does 
not see it, and can not use it.

As for information that is derived from other sources, we already have 
text in the document that this can be sensitive and needs to be handled 
with care.

For the most part, the text you propose is harmless, but does not add 
anything to what the document already says.
The one exception is with the notion of removing the metadata when it is 
no longer needed.  Since service chaining does not know the semantics or 
users of the metadata, it can't perform such removal.  And a service 
function has no way to know if some later service function may need the 
data.  Which leaves us only removal at exit from service chaining, which 
is already required.

Yours,
Joel

On 5/28/15 4:32 PM, Alia Atlas wrote:
>> or similar, its one more place this data resides that needs to be tracked

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 May 2015 17:20:51 -0400

Joel,

Sent from my iPhone

> On May 28, 2015, at 4:50 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> If the data is already in the packet, and the packet is not protected, then while copying it may make it easier to extract, that ease is pretty small, and the data was already extractable before service chaining.
> If the data is in the packet and the packet is encrypted, then SFC does not see it, and can not use it.
> 

I can see your point of view, but that does not mean that a warning is not needed.  Someone may not be aware that their plain text traffic could be used in the ways that are possible.  Alia's suggested text addresses this possible concern and is much appreciated to remove my discuss.

Let me know if/when this text is incorporated.

Best regards,
Kathleen 

> As for information that is derived from other sources, we already have text in the document that this can be sensitive and needs to be handled with care.
> 
> For the most part, the text you propose is harmless, but does not add anything to what the document already says.
> The one exception is with the notion of removing the metadata when it is no longer needed.  Since service chaining does not know the semantics or users of the metadata, it can't perform such removal.  And a service function has no way to know if some later service function may need the data.  Which leaves us only removal at exit from service chaining, which is already required.
> 
> Yours,
> Joel
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 May 2015 17:23:22 -0400

Joel,

First,  there are scenarios where it isn't as clear-cut.  For instance,
perhaps the classifier can decrypt or perhaps the classifier encrypts the
packet afterwards.

The extra ease makes the difference for a collector that is picking up
headers rather than full packets.

It makes a difference for service functions that may work only on the
header and meta-data.

If your point is that there are no concerns around privacy, then that meets
to be reasoned and spelled out clearly.   While in routing, we are not
aware of many of the attacks & pervasive monitoring that is happening,
that doesn't mean we don't need to consider it.

Yes, I appreciate that you added that.   However,  as is obvious from the
discussion,  the kind of privacy concerns and motivations don't spring
really to mind for many readers.

It is pretty bland,  with the exception of references to RFC 6973.  I would
be happy to see better text suggested that indicates significant
consideration of the concerns.

no longer needed.  Since service chaining does not know the semantics or
users of the metadata, it can't perform such removal.  And a service
function has no way to know if some later service function may need the
data.  Which leaves us only removal at exit from service chaining, which is
already required.

I would think that could depend upon the control-plane or orchestration
system.   For the case of information indirectly pointed to by meta-data,
this also indicates that the data should be removed when the flow or SFP is
no longer in use.

Regards,
Alia

>>> data that is in a payload that may be used in the SFC architecture.  I
am
>>>> exposed.  If the payload is protected from exposure, then SFC won't be
able
>>>> Right, but you are pulling that content out and using it in ways that
may