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

From: <[email-masked]>
Date: Tue, 3 Oct 2017 14:39:30 +0000

Hi Ben, 

This makes a lot of sense. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Ben Campbell [mailto:[email-masked]]
> Envoyé : vendredi 29 septembre 2017 22:43
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joel M. Halpern; [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
> 
> 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,
> >
> > 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.
> >>
> >>> 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
> >>>
> >>> On 9/27/17 10:02 PM, Ben Campbell wrote:
> >>>> 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: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 Oct 2017 16:33:55 +0000

Ben,

Thanks for the follow-up — please find additional comments and responses, inline. Two of your comments resulted in text changes.

> On Sep 29, 2017, at 5:02 PM, Ben Campbell <[email-masked]> wrote:
> 
> 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.
> 

I do not. Although I/we do not envision them now, someone might in the future (drop loudly, find situations to quarantine them, tunnel them to a sink for something not silently drop, etc)

> 
>>> 
>>> -- MD type 0xF: "Implementations not explicitly configured to be part of
>> Ditto.
> Also ditto :-)

Idem. :-)

>> No particular reason. One seems not enough potentially for creative experimentation.
>> 
>> My favorite number is 27, but we felt that was too many :-)
> 
> Okay :-)
> 

Given the field is an octet, we felt 2 was enough but not too many. 1 seemed too small of a number. This also coincides with how Experimental values are reserved for other octet values. For example, RFC 4727, Sections 2.3 and 3.3, and RFC 3692 <https://tools.ietf.org/html/rfc3692#section-2.1>

Is there a particular reason why you ask?

>>> 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
>> 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?
> 

I cannot think of any. Seems like a risk of leakage.

>>> semantics..." I'm not sure what the intent of this paragraph is. Is that MUST
>> 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?
> 

Ah, I see. Acknowledging the fact, explaining. 

Will s/MUST receive/needs to receive/.

The sentence that follows is actually a requirement:

   An SF or SFC Proxy that does not know the format or semantics of the
   Context Header for an NSH with MD Type 1 MUST discard any packet with
   such an NSH

And just for completeness, this is where the document states control plane is out of scope.

S1.2:

   An NSH-aware control plane is outside the scope of this document.

S1.5:

  The semantics of
       the shared metadata is communicated via a control plane, which is
       outside the scope of this document, to participating nodes.

And newly added, S6.1:

   The information contained in Tables 1-4 may be received from the
   control plane, but the exact mechanism is outside the scope of this
   document.

> […]
> 
>>> -7.1, last paragraph: "Depending on the information carried in the metadata,
>>> data privacy
>>> "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”.
>> 
>> 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.
> 

Good point. “data privacy considerations” -> “data privacy impact”. And we can drop the “may” as well. Good to strengthen operators and implementors to consider it. 

> […]
> 
>> 
>>> -8.1, 2nd paragraph:
>>> This doesn't seem like a single operator scenario, in the sense that part of
>> 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?
> 

OK, will consider this as part of looking more holistically at Section 8.

> […]
>>> Does "disabled" mean "unset"  (or "set to zero”)?
>> 
>> No. It means disabled.
> 
> I don’t understand how you disable a bit. The bit is still there and readable either way, right?
> 

The bit is still there, readable, and it can still take either of two values: 0, and 1, as in Section 2 of RFC 3514 :-)

But, the sentence you copied does not have any mention of “disabling a bit”. It is talking about “disabling a configuration parameter”.

The same paragraph, earlier, says “a configurable parameter to enable forwarding”. That parameter MUST be disabled by default.

>>> 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
>> It is slightly different.
> 
> How is it different?

The former says “do not change the bits, ignore them”. The latter says “do not change your actions based on the value of those bits, ignore them. The ignore them part is common, but they are different because one refers to the packet and the other to the actions.

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

Sorry I thought I had commented on that.

Logging would not violate that requirement because there is no logging that is based on the values of those bits. Basically, logging does not change the bits, and an SFP element does not decide to log or not based on the value of those bits.

> […]

Thanks!

— Carlos.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 6 Oct 2017 16:40:46 -0500

Hi, comments inline:

> On Oct 3, 2017, at 11:33 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
>> 
>> […]
>>> 
>>>> 

Okay. I think an example or two like that in the text would be helpful. I’m not looking for anything constraining. (Keep in mind these are all non-blocking comments :-)  )

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

that :-)

> Is there a particular reason why you ask?

Only that I usually see either one value or a range of values marked “experimental”, so 2 seemed odd.

> I cannot think of any. Seems like a risk of leakage.

Okay, It might be worth a mention somewhere that this draft assumes that a failure of the service path means a failure to deliver the packets to the end-system.

[…]

> The same paragraph, earlier, says “a configurable parameter to enable forwarding”. That parameter MUST be disabled by default.

Ah, misread. I thought the “O-bit” was the parameter, but we are talking about a configurable parameter about how you react to the O-bit. I would argue that the behavior indicated by the parameter is disabled, rather than the parameter itself, but that’s less confusing than “disabling the O-bit” as I originally read things.

> The former says “do not change the bits, ignore them”. The latter says “do not change your actions based on the value of those bits, ignore them. The ignore them part is common, but they are differ…

I interpreted “ignore” to mean “don’t pay attention to them”, in addition to “preserved unmodified” meaning “don’t change them."

> Logging would not violate that requirement because there is no logging that is based on the values of those bits. Basically, logging does not change the bits, and an SFP element does not decide to…

I meant logging a warning that you received a packet with a non-zero value.

Thanks!

Ben.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 6 Oct 2017 18:58:09 -0400

Hi Ben,

On Fri, Oct 6, 2017 at 5:40 PM, Ben Campbell <[email-masked]> wrote:

> > Given the field is an octet, we felt 2 was enough but not too many. 1
> seemed too small of a number. This also coincides with how Experimental
> values are reserved for other octet values. For example, RFC 4727, Sections
> 2.3 and 3.3, and RFC 3692 <https://tools.ietf.org/html/rfc3692#section-2.1
> >
> >

Bitter experience (reputedly since I don't have the example) talks of early
implementations that squat on the 1 experimental value - which then becomes
that first feature.
In routing, we encourage allocating a small number - to allow for better
flexibilty.

Regards,
Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 16 Oct 2017 14:22:51 +0000

Ben, Med,

We will indeed add such considerations within the security considerations we are revising.

Thanks!

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

On Oct 3, 2017, at 10:39 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Ben,

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]]
Envoyé : vendredi 29 septembre 2017 22:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
The IESG; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-nsh-24:
(with COMMENT) - Encrypted content

Thanks!

Ben.

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

Dear Ben,

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG;
[email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-nsh-24:
(with COMMENT) - Encrypted content

Hi Joel,

Thanks!

Ben.

On Sep 27, 2017, at 9:45 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
wrote:

Yours,
Joel