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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Sep 2017 13:44:35 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-nsh-24: 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-nsh/

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

First, I'd like to thank the authors and WG for your efforts in recent
revisions of this draft, it has come a long way.  I still want to poke at the
lack of a requirement for either integrity protection on the NSH itself or for
MUSTs on protections from the transport encapsulation.  Attacks inside of a
data center or single operator domains happen all too often.  The number from
2016 is up 164% as of a statistic I saw earlier today.  We can't srug this off
anymore.

Security Considerations section:
First two sentences say:
   NSH is designed for use within operator environments.  As such, it
   does not include any mandatory security mechanisms.

I think you intended the first sentence to say, "within a single operator
environment" as what you have now could be multiple networks managed separately
with that statement.  Then for the second sentence, I know you don't have an
integrity mechanism mandated, but I really think one should be.  Couldn't the
path be altered and not detectable if there is no integrity checking?  This
could be used to avoid security protections or to route it inappropriately
through a multi-tenant environment.  Sure, the underlying protocol should
provide session encryption on application traffic, but there's no reason why
security shouldn't have been baked into this protocol as a requirement.

>From the architecture document, the security considerations section calls
attention to possible issues related to lack of integrity checking.  Since no
encapsulating transport is specified with required session encryption, and the
NSH addition doesn't have integrity protection, how will you meet this
architecture requirement from RFC7665:

  Service Overlay:  Underneath the service function forwarders, the
        components that are responsible for performing the transport
        forwarding consult the outer-transport encapsulation for
        underlay forwarding.  Used transport mechanisms should satisfy
        the security requirements of the specific SFC deployment.  These
        requirements typically include varying degrees of traffic
        separation, protection against different attacks (e.g.,
        spoofing, man-in-the-middle, brute-force, or insertion attacks),
        and can also include authenticity and integrity checking, and/or
        confidentiality provisions, for both the network overlay
        transport and traffic it encapsulates.

It seems from this text, something should be specified for the transport
encapsulation.

>From the text in the draft under review:
   As with many
   other protocols, without enhancements, the NSH encapsulation could can be
   spoofed
   or otherwise modified and is subject to snooping and modification in transit.

   However, the deployment scope (as defined in [RFC7665]) of the NSH
   encapsulation is limited to a single network administrative domain as
   a controlled environment, with trusted devices (e.g., a data center)
   hence mitigating the risk of unauthorized manipulation of the
   encapsulation headers or metadata.

This is in direct conflict with the Service Overlay requirements in the
Security Considerations of RFC7665.

Section 8.1
I'd like to see some MUSTs to address the concerns listed in RFC7665 for
encapsulation requirements or an addition of integrity protection on NSH itself.

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

This introductory text is much improved from a previous version and my
comments, thanks for the update.  This helps quite a bit.

   The Network Service Header (NSH) specification defines a new protocol
   and associated encapsulation for the creation of dynamic service
   chains, operating at the service plane.  The NSH is designed to
   encapsulate an original packet or frame, and in turn be encapsulated
   by an outer transport encapsulation (which is used to deliver the NSH
   to NSH-aware network elements), as shown in Figure 1:

Section 8.1:
I don't think you need the text on BCP38.  It's a helpful recommendation in
general, but I don't see how it's directly applicable to this specification.

Thank you for adding the text on Boundary protections per the SecDir review, I
think this is very helpful.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 04:48:23 +0000

Thank you Kathleen for reviewing this document and the input below!

Please see inline.

> On Sep 26, 2017, at 4:44 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> revisions of this draft, it has come a long way.

Thank you for early feedback, which helped us improve the spec!

>  I still want to poke at the
> 2016 is up 164% as of a statistic I saw earlier today.

Search engines find all sort of interesting and uninteresting statistics searching for “2016 is up 164%”. Try it :-)

If you are referring to the Gemalto [1] [2] study, those are _not_ “Attacks inside of a data center or single operator domains”. Those are number of data records lost or stolen. You implied the number of attacks inside a data center increased by that number, which may or may not be the case, but there does not seem to be a study about it.

Please note that I am not minimizing the issue, nor looking the other way or burying the head in the sand... But throwing a number like 164% without its semantic and context does not convey actionable information. 

[1] http://breachlevelindex.com/assets/Breach-Level-Index-Report-H1-2017-Gemalto.pdf
[2] http://www.digitaltransactions.net/news/story/7421

Anyway...

>  We can't srug this off

Agreed. We are not shrugging it off. See below.

> with that statement.

Yes! Thank you for catching this. We also caught it in a re-review.

>  Then for the second sentence, I know you don't have an
> path be altered and not detectable if there is no integrity checking?

The path can be altered in the transport encapsulation easier.

But the main point is that there are ways to provide integrity checking within the transport encapsulation, with proven existing mechanisms. And we advocate their use.

>  This

Do you mean the “overlying” protocol should provide session encryption on application traffic?

The underlying protocol is already covered in Section 8.1.

>        transport and traffic it encapsulates.

I may be missing something, but what I read from RFC 7665 says:

      "Used transport mechanisms should satisfy
       the security requirements of the specific SFC deployment."

> It seems from this text, something should be specified for the transport

I agree and disagree, in a way.

Yes, something ought to be specified, for the transport encapsulation specifications, not for the NSH spec.

Or rephrasing, the document is specifying the NSH data plane layer, not beyond. And in this context is specifying security elements in the transport encapsulation in a generic fashion, and for the Metadata itself.

> Security Considerations of RFC7665.

I do not think it is, as shown above. Could you please be more specific?

Please note that we meaningfully and dramatically “beefed up” all this text from when you reviewed -18.

> encapsulation requirements or an addition of integrity protection on NSH itself.

See above.

We cannot add a MUST for something we are not specifying. And at the NSH itself, we are being very explicit about the threats and motivations, Section 8.3.

Great to hear!

>   to NSH-aware network elements), as shown in Figure 1:

I just remember that you had suggested adding a pointer to Figure 3 from RFC 7665 as well. Will add that to the Intro.

> general, but I don't see how it's directly applicable to this specification.

It seems relevant in the context of filtering traffic that goes into the service function path. But if you insist, we can comment it out in the source.

> think this is very helpful.

Of course! Thank you again, Kathleen.

— Carlos.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Sep 2017 12:47:01 -0400

Hi Carlos,

Thanks for the quick response, inline.

> If you are referring to the Gemalto [1] [2] study, those are _not_ “Attacks inside of a data center or single operator domains”. Those are number of data records lost or stolen. You implied the num…

Another source quoted it incorrectly, but 918 is a really high number
of data breaches compromising 1.9 billion records.  918 data centers
being compromised 9 months into the year is something to consider when
you are putting out technology that establishes alternate paths
through a data center that might not follow the logical path - easier
to avoid mitigation points if the data center is relying on those
inline.

https://www.gemalto.com/press/Pages/First-Half-2017-Breach-Level-Index-Report-Identity-Theft-and-Poor-Internal-Security-Practices-Take-a-Toll.aspx

> [2] http://www.digitaltransactions.net/news/story/7421

Sorry, I see these types of reports often and it's just a reminder
that this is important, the numbers are no declining and this
technology could have an impact on how traffic is routed or mis-routed
through a data center and could be used during an attack.

> The path can be altered in the transport encapsulation easier.

It's not an excuse to not do this correctly.  We should be working to
minimize the attack surface given the current state of compromises.

> But the main point is that there are ways to provide integrity checking within the transport encapsulation, with proven existing mechanisms. And we advocate their use.

I don't see that strongly enough, hence wanting to discuss this more.

> The underlying protocol is already covered in Section 8.1.

No, I'm worried about the NSH content specifically as that is what
this draft is about.

>        the security requirements of the specific SFC deployment."

But you only have SHOULD statements to address these concerns and not
MUST statements for the encapsulating transport.

> Yes, something ought to be specified, for the transport encapsulation specifications, not for the NSH spec.

Then you need to point to it in another draft from NSH or we have a
gap that allows for problems to surface.

> Or rephrasing, the document is specifying the NSH data plane layer, not beyond. And in this context is specifying security elements in the transport encapsulation in a generic fashion, and for the…

Then where is it specified and how is it linked to this draft to form
adequate requirements?

> I do not think it is, as shown above. Could you please be more specific?

The text from the draft under review states that you can rely on the
single domain operator environment as a security measure and that's
really not adequate to address the problems stated in the first
paragraph of the quoted text - spoofed and active interception attacks
- these happen during attacks within the data center.  Since it is one
way to alter the flow of traffic, I think there really should be
integrity protection built into NSH.

> Please note that we meaningfully and dramatically “beefed up” all this text from when you reviewed -18.

Yes, and while I appreciate the improvements, there is more work to be
done for today's treat landscape.  We're not talking about a legacy
protocol here with no options, something can be done.

> We cannot add a MUST for something we are not specifying. And at the NSH itself, we are being very explicit about the threats and motivations, Section 8.3.

I'd prefer integrity protection to be added directly into NSH anyway.

> I just remember that you had suggested adding a pointer to Figure 3 from RFC 7665 as well. Will add that to the Intro.

Thanks!

> It seems relevant in the context of filtering traffic that goes into the service function path. But if you insist, we can comment it out in the source.

Take it or leave it, it doesn't matter much.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 17:48:41 +0000

Hi, Kathleen,

Thanks for the dialogue — Please see inline, I am focusing on the actionable comments, and the ones where I think views mostly diverge.

> On Sep 27, 2017, at 12:47 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Carlos,
> 

Of course. But my point is that we are not doing this incorrectly.

First, if you look at how service chaining is achieved today, it should be clear to you that this technology not only does not make things worst but also reduces the attack surface.

More on this below. I believe I understand *exactly* what is the disagreement.

> I don't see that strongly enough, hence wanting to discuss this more.

Sounds good — let’s discuss it.

> No, I'm worried about the NSH content specifically as that is what

The NSH content is protected by the transport encapsulation, as required by specific deployments.

> MUST statements for the encapsulating transport.

Which means it is correctly meeting the architectural requirement. RFC 7665 does not say “you MUST anything for transport”.

And also because this document does *not* specify the transport encapsulation. 

That said, there is a MUST in Section 8.1. And even, I would not oppose changing another SHOULD to MUST in Section 8.1., maybe the first one.

> gap that allows for problems to surface.

The other way around, a transport encapsulation would point to NSH.

> single domain operator environment as a security measure

What you are stating is incorrect.

And this, I believe, is a key source of your DISCUSS, which I think is a misunderstanding of the existing text.

The draft currently says:

   Operators SHOULD then select a transport
   encapsulation protocol such as one that supports [RFC6071] to provide
   the needed protection (e.g., authenticity, confidentiality) for the
   traffic between SFC components.

And then says:

   One useful element of providing privacy protection for sensitive
   metadata is described under the "SFC Encapsulation" area of the
   Security Considerations of [RFC7665].  Operators can and should use
   indirect identification for metadata deemed to be sensitive (such as
   personally identifying information) significantly mitigating the risk
   of privacy violation. 

And then further says:

   For those situations where obfuscation is either inapplicable or
   judged to be insufficient, an operator can also encrypt the metadata.
   An approach to an optional capability to do this was explored in
   [I-D.reddy-sfc-nsh-encrypt].  For other situations where greater
   assurance is desired, optional mechanisms such as
   [I-D.brockners-proof-of-transit] can be used.

So, following on [I-D.reddy-sfc-nsh-encrypt], it says:

   This draft adds authentication
   and optional encryption directly to NSH.  This way NSH data does not
   have to rely on underlying transport encapsulation for security and
   confidentiality.

And:

   An NSH imposer inserts an Authentication Tag TLV for data origin
   authentication and integrity protection.

All the pieces are there.

> and that's

See above.

> protocol here with no options, something can be done.

Could you please share more specifics based on the responses above?

> I'd prefer integrity protection to be added directly into NSH anyway.

I understand that, and the current text gives integrity protection using proven existing protocols in the encap, and points to optional methods to do something in NSH, including Proof of Transit [I-D.brockners-proof-of-transit].

>> I just remember that you had suggested adding a pointer to Figure 3 from RFC 7665 as well. Will add that to the Intro.

You are welcome.

> Take it or leave it, it doesn't matter much.

Sounds good — thanks!

— Carlos.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 27 Sep 2017 18:36:06 +0000

Hi,

> On Sep 26, 2017, at 4:44 PM, Kathleen Moriarty <[email-masked]> wrote:
> 

PQ> And thank you for the detailed reviews!  Your feedback has helped improve this draft and is much appreciated!

> security shouldn't have been baked into this protocol as a requirement.

PQ>  The draft clearly provides well understood and accepted forms of integrity and/or confidentiality using standard protocols.   Requiring “baked in” security — in the form of integrity and/or confidentiality — seems not only unnecessary but a burden that the IETF, in general, has not imposed.   Let’s look at recent work in a couple of other WGs for some recent data points: i) nvo3: VXLAN and  geneve, ii) SPRING and segment routing.    In all those cases, “integrity” is not (correctly) enforced in the dataplane.   NSH follows a similar philosophy.  

<trimmed>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Sep 2017 14:41:31 -0400

On Wed, Sep 27, 2017 at 2:36 PM, Paul Quinn (paulq) <[email-masked]> wrote:

> PQ> And thank you for the detailed reviews!  Your feedback has helped
> improve this draft and is much appreciated!
>
>
>
> PQ>  The draft clearly provides well understood and accepted forms of
> integrity and/or confidentiality using standard protocols.   Requiring
> “baked in” security — in the form of integrity and/or confidentiality —
> seems not only unnecessary but a burden that the IETF, in general, has not
> imposed.   Let’s look at recent work in a couple of other WGs for some
> recent data points: i) nvo3: VXLAN and  geneve, ii) SPRING and segment
> routing.    In all those cases, “integrity” is not (correctly) enforced in
> the dataplane.   NSH follows a similar philosophy.
>

VXLAN is an Independent Stream RFC.
Geneve has not finished going through the process and NVO3 is working
on draft-mglt-nvo3-geneve-encryption-option-00 as an example mechanism.

SPRING drafts are not through the IESG yet - but are based on reusing the
existing 18+ year old MPLS data-plane.  The IPv6 version has its own issues
and has not progressed.

 Regards,
Alia