Subject: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-nsh-24: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Sep 2017 19:02:33 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-sfc-nsh-24: No Objection

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

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

Substantive:

- General: This is a mechanism to add metadata to user flows. There is very
little discussion about how that metadata may relate to the application layer
payloads. It's likely that some of those payloads will be encrypted by the user
in an attempt to control what information is shared with middleboxes. I'd like
to see some discussion about how this relates to the guidance in RFC 8165. 
(Note: I am on the fence about whether this should be a DISCUSS. But since "on
the fence" is probably insufficient grounds for a DISCUSS, I'm leaving it as a
comment.)

- General: I support Kathleen's DISCUSS points concerning integrity protection.
The document leaves that up to the transporting protocol. I think it's
reasonable to recommend that that protocol at least default to providing
integrity protection unless there's a good reason not to.

-2.2, "version": How is the version field to be used by consumers? That is,
what should a recipient do if the field contains a version number it doesn't
support/recognize?

-2.2, MD type 0x0: "Implementations SHOULD silently
   discard packets with MD Type 0x0."
Why not MUST?

-- MD type 0xF: "Implementations not explicitly configured to be part of
   an experiment SHOULD silently discard packets with MD Type 0xF."
Why not MUST?

-2.2, Next Protocol Values:
Why are there 2 experimental values? (as opposed to 1, or, well, 3).

-2.3, last paragraph (and several other places):
This draft seems to take a position that a failed SFP means the service level
flow fails. Are there no use cases where delivery of the service flow is
critical and should happen even if the chain of middleboxes fails?

-2.4, paragraph starting with "An SFC-aware SF MUST receive the data
semantics..." I'm not sure what the intent of this paragraph is. Is that MUST
really a statement of fact? Or is there really and expectation of an
out-of-band delivery of some semantic definition?

-3, list item 1: "A service classifier MUST insert an NSH at the start of an
SFP." What if an initial classifier receives a packet that already has an NSH?
Can multiple NSHs be stacked?

-7.1, last paragraph: "Depending on the information carried in the metadata,
data privacy
   considerations may need to be considered. "
"may need to be considered" is weak sauce. Data privacy always needs to be
considered, even if the _output_ of that consideration is that there is nothing
sensitive being carried. Please consider dropping the "may".

Also, this seems like an odd place to bury a privacy discussion. Please
consider moving this to a "Privacy Considerations" section.

-8, first paragraph:
It seems like insider attacks are worth at least a mention when discussing a
single operator environment as a mitigator against attacks.

-8.1, 2nd paragraph:
This doesn't seem like a single operator scenario, in the sense that part of
the flow crosses a network that is not controlled by that operator.

-8.3, 4th paragraph: Please elaborate on what is meant by "obfuscating"
subscriber identifying information (as opposed to "encrypting" or "leaving it
out in the first place".)

Editorial:

-2.2, "O bit", last paragraph: "The configurable parameter MUST be
   disabled by default."
Does "disabled" mean "unset"  (or "set to zero")?

-2.2, "unassigned bits": "At reception, all
   elements MUST NOT modify their actions based on these unknown bits."
Isn't that MUST NOT just a restatement of the "MUST ignore" from the previous
sentence? There's no problem with reinforcing a point, but there shouldn't be
multiple instances of the same 2119 requirement. Also, would logging a warning
violate the "MUST NOT modify their actions/MUST ignore" requirement?

-8, first paragraph: "NSH is designed for use within operator environments."
Is there a missing "single" before "operator"?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Sep 2017 22:45:19 -0400

Ben, I am  really not clear on what to do with your comment about 
encrypted content.

Nothing in this work enables or promotes operators breaking encryption 
(an earlier version had a line that incorrectly suggested such.)
The metadata is used to mark what the operator wants to know about the 
packet.  Even for encrypted content, the operator may need to knwo the 
ssubscriber ID.  For encrypted content, the operator might (or might 
not) choose to put metadata indicating the the content is 
uninterpretable (if he decides it is uninterpretable.)  Clearly, he can 
not put on infomration about the encrypted information, as he does not 
see that.
I can not figure out where we would say something like that, or why we 
would say it.

Yours,
Joel

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Sep 2017 23:15:02 -0500

Hi Joel,

On reflection, the “encrypted payload” part may be a red herring. Let me generalize that to “withheld information”.  As you mention, the metadata marks what the operator wants to know about a packet, but that may sometimes conflict with what the user doesn’t want to them to know. Here’s an example:

Lets consider an end user that doesn't want to be tracked for advertising purposes. They block certain tracking cookies and anything else that shows continuity of identity to web servers. But as you mention, the operator needs or wants to know the subscriber ID, so the classifier adds that to the NSH.. The terminal element in the chain happens to be a web service that uses the NSH contents to track the user for advertising purposes. You may recall a controversy a while back about a major operator doing something similar using HTTP header enrichment.

I think the answer to this for this particular case is that the NSH is assumed not to go outside a single administrative domain, and that all elements in the same domain can be assumed to have access to the same information. That is, the NSH is just a convenient way to transfer metadata they could pass in other ways. While the user may not be consoled by the fact that the web service tracking them belongs to the same company as their access network, the use of the NSH doesn’t add an issue that couldn’t already exist. (This suggests that the idea of a single operator environment may be considerably more complex that the draft makes it sound, but I don’t see much to do about that.)

So I guess what I am asking for is some text that recognizes that users have an interest in metadata minimization, and some suggestion that operators keep that in mind, and not add metadata beyond the minimum needed to make the SFP function correctly.

(To bring encryption back into the picture, one can probably construct similar cases involving VPNs—for example services that add the original source IP address as metadata to a VPN flow.)

Thanks!

Ben.

> On Sep 27, 2017, at 9:45 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Ben, I am  really not clear on what to do with your comment about encrypted content.
> 
> Nothing in this work enables or promotes operators breaking encryption (an earlier version had a line that incorrectly suggested such.)
> The metadata is used to mark what the operator wants to know about the packet.  Even for encrypted content, the operator may need to knwo the ssubscriber ID.  For encrypted content, the operator might (or might not) choose to put metadata indicating the the content is uninterpretable (if he decides it is uninterpretable.)  Clearly, he can not put on infomration about the encrypted information, as he does not see that.
> I can not figure out where we would say something like that, or why we would say it.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Sep 2017 00:38:05 -0400

As far as I can tell, the key is the text in the middle where you note 
that this is all information that is available to the operator.  There 
are all sorts of ways they can collect this information already, for use 
within their domain.  The only viable solution to preventing the 
operator from having information you don't want is to not tell them. 
Which is why HTTPS, while not perfect, is useful.  And is being used more.

For example, an operator running CG Nat could collect the subscriber 
information (subscriber ID and currently used IP address).  They can 
collect their NAT bindings.  And they can sell that correlation to a 
third party.  None of that requires or makes any use of NSH.

The point of NSH is to make it practical for the operator to use 
disassembled functions where currently he must use integrated monoliths.
So, for example, in the same CGNat scenario, with NSH the operator can 
mark the subscribe ID in the metadata so that he can apply subscriber 
policy in separate service functions, rather than requiring that they be 
tightly coupled to ingress device that knows who the subscriber is.
This ability to decompose is being asked for by operators all over the 
place.  (For those looking to place this is the buzzword spectrum, this 
is different from micro-services, although service chaining can be used 
along with micro-service architectures.)

If you have specific text you can suggest on minimization, we can 
presumably add it.  I don't think any of us disagree with the idea.  It 
is clearly not something we can enforce.  So I don't know how much good 
it will do.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 28 Sep 2017 06:24:59 +0000

Dear Ben,

With regards to your comments vs. RFC8165, I don't see how the advice in 8165 can be followed here.

I have raised the specifics of service chaining during the IETF LC of draft-hardie (8165): you can check at https://www.ietf.org/mail-archive/web/ietf/current/msg100909.html (search for "service function chaining"). 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Ben Campbell
> Envoyé : jeudi 28 septembre 2017 06:15
> À : Joel M. Halpern
> Cc : [email-masked]; [email-masked]; The IESG;
> [email-masked]
> Objet : Re: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-nsh-24:
> (with COMMENT) - Encrypted content
> 
> Hi Joel,
> 
> On reflection, the “encrypted payload” part may be a red herring. Let me
> generalize that to “withheld information”.  As you mention, the metadata
> marks what the operator wants to know about a packet, but that may
> sometimes conflict with what the user doesn’t want to them to know. Here’s
> an example:
> 
> Lets consider an end user that doesn't want to be tracked for advertising
> purposes. They block certain tracking cookies and anything else that shows
> continuity of identity to web servers. But as you mention, the operator
> needs or wants to know the subscriber ID, so the classifier adds that to
> the NSH.. The terminal element in the chain happens to be a web service
> that uses the NSH contents to track the user for advertising purposes. You
> may recall a controversy a while back about a major operator doing
> something similar using HTTP header enrichment.
> 
> I think the answer to this for this particular case is that the NSH is
> assumed not to go outside a single administrative domain, and that all
> elements in the same domain can be assumed to have access to the same
> information. That is, the NSH is just a convenient way to transfer
> metadata they could pass in other ways. While the user may not be consoled
> by the fact that the web service tracking them belongs to the same company
> as their access network, the use of the NSH doesn’t add an issue that
> couldn’t already exist. (This suggests that the idea of a single operator
> environment may be considerably more complex that the draft makes it
> sound, but I don’t see much to do about that.)
> 
> So I guess what I am asking for is some text that recognizes that users
> have an interest in metadata minimization, and some suggestion that
> operators keep that in mind, and not add metadata beyond the minimum
> needed to make the SFP function correctly.
> 
> (To bring encryption back into the picture, one can probably construct
> similar cases involving VPNs—for example services that add the original
> source IP address as metadata to a VPN flow.)
> 
> Thanks!
> 
> Ben.
> 
> ssubscriber ID.  For encrypted content, the operator might (or might not)
> choose to put metadata indicating the the content is uninterpretable (if
> he decides it is uninterpretable.)  Clearly, he can not put on infomration
> about the encrypted information, as he does not see that.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 Sep 2017 13:35:52 +0000

Ben,

Thanks for taking the time to review and provide these comments.

Joel and Med answered a couple of these, I will focus on the remaining ones.

> On Sep 27, 2017, at 10:02 PM, Ben Campbell <[email-masked]> wrote:
> 

Our working copy contains this text — will post before the Telechat:

"If a packet presumed to carry an NSH header is received at an SFF, and the SFF does not understnad the version of the protocol as indicated in the base header, the packet MUST be discarded, and the event SHOULD be logged."

>   discard packets with MD Type 0x0."

Because we do not want a hammer larger than needed. SHOULD achieves our goal without locking the door for good, should valid reasons be found.

>   an experiment SHOULD silently discard packets with MD Type 0xF."

Ditto.

> Why are there 2 experimental values? (as opposed to 1, or, well, 3).

No particular reason. One seems not enough potentially for creative experimentation. 

My favorite number is 27, but we felt that was too many :-) 

> critical and should happen even if the chain of middleboxes fails?

The issue is that with SI=0 there is no next SF to deliver.

> out-of-band delivery of some semantic definition?

There is the expectation of control plane download of it upon SFP programming.

> Can multiple NSHs be stacked?

Not on this document, we clarified this based on Suresh’ comment.

> sensitive being carried. Please consider dropping the "may”.

We could drop it. However, there are very valid cases of SFC with NO metadata, and then the consideration is NULL. That’s the reason, no MD, no consideration.

> single operator environment as a mitigator against attacks.

Will address as part of the larger security conversation.

> the flow crosses a network that is not controlled by that operator.

Why not? It is very common to connect two parts of an operation with tunnels of various kinds.

> out in the first place”.)

Will consider as part of the larger security conversation.

> Does "disabled" mean "unset"  (or "set to zero”)?

No. It means disabled.

> violate the "MUST NOT modify their actions/MUST ignore" requirement?

It is slightly different.

> Is there a missing "single" before "operator"?

Good point, fixed already.

Thanks,

Carlos.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 29 Sep 2017 15:43:17 -0500

To be clear, I am not asking for the NSH to comply with the advice in 8165. I am asking it to acknowledge that advice, and say how that advice applies. If the answer is “it doesn’t apply because...”, that’s fine. But I think it’s a problem for this draft to ignore that advice entirely.

Here’s an example of some potential text to add to the security considerations section, or even better, a privacy considerations section.  (I’m not saying this is correct—it’s just an example of what I have in mind.)

“ The NSH provides a mechanism for network elements to attach metadata to user data flows. [RFC 8165] describes some risks and advice related to metadata insertion by middleboxes. The advice to limit such metadata to that included by the end-system is not feasible for SFC because [reasons]. The impact of the metadata is somewhat mitigated by the limitation of the NSH to a single operator environment, since such an operator can be assumed to already have access to the inserted information.

However, implementors and operators should be aware that metadata often has privacy implications, and those implications are sometimes hard to predict. Therefore attached metadata should be limited to that necessary for correct operation of the SFP. “

Thanks!

Ben.

> On Sep 28, 2017, at 1:24 AM, [email-masked] wrote:
> 
> Dear Ben,
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 29 Sep 2017 16:02:48 -0500

Thanks for the response. Comments inline, with sections that do not seem to need further discussion deleted.

Ben.

> On Sep 28, 2017, at 8:35 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
>> 

[…]
> Because we do not want a hammer larger than needed. SHOULD achieves our goal without locking the door for good, should valid reasons be found.

Do you envision situations where it might make sense to _not_ drop such packets? If so, it would be helpful to mention that in the text.

>>  an experiment SHOULD silently discard packets with MD Type 0xF."

Also ditto :-)

> My favorite number is 27, but we felt that was too many :-)

Okay :-)

> The issue is that with SI=0 there is no next SF to deliver.

Maybe there’s no next SF, but one assumes the encapsulated packet is addressed to an end-system of some sort, which may or may not be part of the SFP? Are there never situations where it would make sense to give up on the SFP but still route the content to its destination?

> There is the expectation of control plane download of it upon SFP programming.

I guess my question is, are you stating a normative requirement, or just acknowledging the fact that the receiving SF must know the semantics to do anything useful with the NSH?

[…]

> We could drop it. However, there are very valid cases of SFC with NO metadata, and then the consideration is NULL. That’s the reason, no MD, no consideration.

From the first sentence, it doesn’t seem like this text is talking about a null metadata case. But I think perhaps we are conflating the ideas “privacy consideration” and “privacy impact”. A “consideration” is something that implementors/operators needs to think about. The results of such thought might be that the specific metadata has no impact on privacy.

[…]

> Why not? It is very common to connect two parts of an operation with tunnels of various kinds.

Yes, but those tunnels cross outside of the administrative domain. I recognize that it is common to do that. Maybe it is worth mentioning that crossing a third party network _without_ such encapsulation is out of scope?

[…]

>> Does "disabled" mean "unset"  (or "set to zero”)?

I don’t understand how you disable a bit. The bit is still there and readable either way, right?

> It is slightly different.

How is it different?

Any comment on whether logging violate the "MUST NOT modify actions" requirement??

[…]