Subject: [sfc] SFC Security Requirements comments

From: Joe Clarke <[email-masked]>
Date: Wed, 4 Nov 2015 20:27:15 -0500

I figure I'll get the ball rolling with comments on 
draft-mglt-sfc-security-environment-req-00.

In particular, I want to comment on section SFC Data Plane Requirements. 
  It was raised today in the session that REQ16 and REQ17 are 
problematic given certain use cases.  The use case of load balancing 
within a domain was brought up.  I can think of other use cases where 
REQ17, specifically, would be a problem.

If you assume that REQ14 and REQ15 are in place (and these are very 
important IMHO), then the risks associated with REQ16 and REQ17 are 
mitigated.  One could not inject their own metadata or modify existing 
metadata unless they could provide proper authn.

Additionally, on REQ17, while this is a good recommendation in general 
(i.e., think about what you want to send and be frugal with space), it 
uses a strong word, MUST without providing any real guidance as to what 
the limit might be.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Nov 2015 20:37:36 -0500

From where I sit, and with the deploymenbts I expect, requiring 
authentication of SFC NSH or of the whole packet seems excessive.  Given 
that the NSH header metadata is going to be modified at many service 
functions, this means that SF have to be able to generate the 
authentication.

And there is a very challenging quesiton as to who would be expected to 
do the work of validating the authentication?  Every Service Function?

So I am doubtful of REQ-14 mandating authentication within the SFC 
space.  When we have inter-domain links, authentication and encryption 
become relevant.
I understand that hard-shell / weak innards security is questionable. 
But adding significant overhead in both sapce and time seems highly 
questionable.

Yours,
Joel

On 11/4/15 8:27 PM, Joe Clarke wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Sharon <[email-masked]>
Date: Wed, 4 Nov 2015 17:54:09 -0800

This is part of the motivation for the draft Alberto presented stripping NSH before SFs, keeping attack surface same as "normal" networking. 

However stripping context while keeping SFC connectionless requires some map-assistance so packets can show up anywhere and chains can fork physically and logically.

--szb

> On Nov 4, 2015, at 5:37 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> From where I sit, and with the deploymenbts I expect, requiring authentication of SFC NSH or of the whole packet seems excessive.  Given that the NSH header metadata is going to be modified at many service functions, this means that SF have to be able to generate the authentication.
> 
> And there is a very challenging quesiton as to who would be expected to do the work of validating the authentication?  Every Service Function?
> 
> So I am doubtful of REQ-14 mandating authentication within the SFC space.  When we have inter-domain links, authentication and encryption become relevant.
> I understand that hard-shell / weak innards security is questionable. But adding significant overhead in both sapce and time seems highly questionable.
> 
> Yours,
> Joel
>

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Nov 2015 15:25:11 +0000

Joel,

Is the question whether there should be authentication at all, or whether it should be mandatory vs. optional?    If optional, it would lend itself to carriage within the metadata (although type 1 could be challenging).

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, November 4, 2015 8:38 PM
To: [email-masked]
Subject: Re: [sfc] SFC Security Requirements comments - REQ 14

So I am doubtful of REQ-14 mandating authentication within the SFC space.  When we have inter-domain links, authentication and encryption become relevant.
I understand that hard-shell / weak innards security is questionable. 
But adding significant overhead in both sapce and time seems highly questionable.

Yours,
Joel

On 11/4/15 8:27 PM, Joe Clarke wrote:
> uses a strong word, MUST without providing any real guidance as to 
> what the limit might be.
>
> Joe
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 5 Nov 2015 17:40:25 +0000

> On Nov 4, 2015, at 8:54 PM, Sharon <[email-masked]> wrote:
> 

Are you implying that the SFs are more trusted w/o NSH?

---

From: Sharon <[email-masked]>
Date: Thu, 5 Nov 2015 12:50:26 -0800

Yes.

--szb

> On Nov 5, 2015, at 9:40 AM, Paul Quinn (paulq) <[email-masked]> wrote:
> 
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 5 Nov 2015 22:17:50 +0000

I find that a tough assumption to accept within a given administrative domain.  Let's ignore NSH for a moment: SFs perform a slew of operations that require trust, including in some cases holding a trusted certificate.  If you can't trust you services, then the you need to consider why you've deployed them.  Taking it one step further: why trust the network nodes then?

Certainly, we should allow for verification/authenticity (when needed) but we need to be pragmatic with our trust model.

Paul

> On Nov 5, 2015, at 3:50 PM, Sharon <[email-masked]> wrote:
> 
> Yes.
> 
> --szb
>

---

From: Sharon <[email-masked]>
Date: Thu, 5 Nov 2015 16:10:44 -0800

I guess the point is that by stripping the NSH before the SFs we trust the SFs no more and no less then we trust any service endpoint or bump on the wire we apply today. The NSH gives more context information then before which exposes the solution to bugs and assumptions. Having no context information maximizes dev-ops permutation freedom. 

There's also the legacy functions, macs, sriov etc considerations.

Having said that I do believe that in this new sfc domain the notion of an NSH allows us to dynamically link NFV solutions using destination based connectionless networking - which is very good. Probably the only way to scale overlays and avoid circuits and state fragility.

--szb

> On Nov 5, 2015, at 2:17 PM, Paul Quinn (paulq) <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 5 Nov 2015 19:16:03 -0500

Optional authentication is fine.  As you say, we have a TLV structure. 
With a little care we can define how to use that to allow for 
authentication when useful.

Mandatory authentication (as appears to be described by the current 
REQ-14 text) is what causes me concern.

Yours,
Joel

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 Nov 2015 19:30:35 -0500

FWIW, we need to be a bit more precise in our wording on security
requirements. There are two important nuances:

1) Mandatory to use, meaning the protocol only works if the feature is
enabled and works. This sort of implies that you can't *disable* its
usage in the field.

2) Mandatory to implement, but optional to use.  If something is
mandatory to implement, "compliant" implementations MUST support the
feature. Whether the feature is used in practice is a separate matter
left to the operator. The rational behind "mandatory to implement" is
that an operator may not actually have the option to enable security
if a product chooses not to implement an "optional" features.

draft-mglt-sfc-security-environment-req-00.txt is unclear at present
on which of the above is intended, but one can certainly read the
following:

   REQ14: Communications within the SFC Data Plane MUST be authenticated
          in order to prevent the traffic to be modified by an attacker.

as intending 1.

For completeness, I should point that even if the final spec calls for
2), vendors may choose not to follow the requirement (and then be
uncompliant), if they don't think it makes sense for their customers
(the original IPv6 mandate to include IPsec comes to mind, for
example). So if the WG chooses 2) - which is what I expect is the most
reasonable course, it should pay careful attention to making the
details something vendors think is useful, necessary and workable in
practice. I.e, the cost of mitigation matches the threat level.

Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Nov 2015 19:49:40 -0500

When it comes to per-packet authentication mechanisms, applied to every 
packet from every subscriber (which is what REQ14 asks us to implement) 
there is real cost in meeting such a requirement.

Which is why I expressed concern about the requirement during the 
meeting in Yokohama.  I do no think that particular requirement has WG 
consensus, and I think it is an over-reach.

Including Authentication as an optional capability, well specified and 
well integrated, makes good sense to me.  Making it mandatory to 
implement seems to much.  And claiming it is mandatory to use would be a 
flat lie.

Yours,
Joel

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 13 Nov 2015 04:59:52 +0000

Authenticating SFC encapsulation is required to prevent various attacks like man-in-middle attacker modifying NSH, attacker sending spoofed NSH etc. The reason the requirement is saying 'MUST' is to do our best to provide BCP for NSH security, if an operator turn-off security then it's a risk he is willing to take.

-Tiru

> Sent: Friday, November 13, 2015 6:20 AM
> To: Thomas Narten
> Cc: [email-masked]; Ron Parker
> Which is why I expressed concern about the requirement during the meeting
> in Yokohama.  I do no think that particular requirement has WG consensus,
> and I think it is an over-reach.
> 
> Including Authentication as an optional capability, well specified and well
> integrated, makes good sense to me.  Making it mandatory to implement
> seems to much.  And claiming it is mandatory to use would be a flat lie.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Nov 2015 00:47:10 -0500

Conversely, if the operators do not want it, and including it 
(authentication capability) in the product at suitable scale will 
introduce noticeable real costs, mandating implementation in the RFC is 
merely a recipe for almost all vendors to fudge in their descriptions of 
what they offer.  Mandating that we make it available is defensible, but 
really hard to make meaningful in practice.

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Fri, 13 Nov 2015 05:47:38 +0000

Integrity of both the data and the origin can (and perhaps should) be provided using AH - an already standardized, and implemented mechanism for preventing such threats at the network level.  It seems far-fetched that we're entertaining the idea that up-stack protocols need to re-invent AH to satisfy data and origin integrity requirements.

If an implementer would like to use NSH on a non-IP network, it should be enough to simply say that they must provide the appropriate analog for AH, if it exists and note the repercussions of using an NSH conveyance which lacks data and origin integrity assurance.

If the argument is that IPSec is too <anything> to use for NSH, then that is, explicitly, a statement that data and origin integrity aren't important enough to make the (arguably less than re-inventing AH) effort to provide the security.  

So, we could be hard line and put MUST's in that will be ignored, or we could be adventurous and shim into the NSH specification a lesser integrity mechanism that will require defense and maintenance, or we could be pragmatic and stipulate the use of existing technology to satisfy the concerns being raised while noting that the lack of enthusiasm for those existing technologies belies a pre-existing judgement about the validity of those concerns in real usage.

________________________________________
From: sfc <[email-masked]> on behalf of Tirumaleswar Reddy (tireddy) <[email-masked]>
Sent: Thursday, November 12, 2015 11:59 PM
To: Joel M. Halpern; Thomas Narten
Cc: Ron Parker; [email-masked]
Subject: Re: [sfc] SFC Security Requirements comments - REQ 14

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 13 Nov 2015 06:18:34 +0000

AH would meet the REQ-14, but REQ-15 won't be met by AH. We have to first discuss and freeze the security requirements and then look into possible solutions.

-Tiru

> From: Ian Smith [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 11:18 AM
> To: Tirumaleswar Reddy (tireddy); Joel M. Halpern; Thomas Narten
> Integrity of both the data and the origin can (and perhaps should) be
> provided using AH - an already standardized, and implemented mechanism
> for preventing such threats at the network level.  It seems far-fetched that
> we're entertaining the idea that up-stack protocols need to re-invent AH to
> satisfy data and origin integrity requirements.
> 
> If an implementer would like to use NSH on a non-IP network, it should be
> enough to simply say that they must provide the appropriate analog for AH,
> if it exists and note the repercussions of using an NSH conveyance which
> lacks data and origin integrity assurance.
> 
> If the argument is that IPSec is too <anything> to use for NSH, then that is,
> explicitly, a statement that data and origin integrity aren't important enough
> to make the (arguably less than re-inventing AH) effort to provide the
> security.
> 
> So, we could be hard line and put MUST's in that will be ignored, or we could
> be adventurous and shim into the NSH specification a lesser integrity
> mechanism that will require defense and maintenance, or we could be
> pragmatic and stipulate the use of existing technology to satisfy the concerns
> being raised while noting that the lack of enthusiasm for those existing
> technologies belies a pre-existing judgement about the validity of those
> concerns in real usage.
> 
> 
> Authenticating SFC encapsulation is required to prevent various attacks like
> man-in-middle attacker modifying NSH, attacker sending spoofed NSH etc.
> The reason the requirement is saying 'MUST' is to do our best to provide BCP
> for NSH security, if an operator turn-off security then it's a risk he is willing to
> take.
> 
> -Tiru
> 
> > When it comes to per-packet authentication mechanisms, applied to
> > every packet from every subscriber (which is what REQ14 asks us to
> > implement) there is real cost in meeting such a requirement.
> >
> > > 1) Mandatory to use, meaning the protocol only works if the feature
> > > is enabled and works. This sort of implies that you can't *disable*
> > > its usage in the field.
> > >
> > > feature. Whether the feature is used in practice is a separate
> > > matter left to the operator. The rational behind "mandatory to
> > > implement" is that an operator may not actually have the option to
> > > enable security if a product chooses not to implement an "optional"
> features.
> > >
> > > For completeness, I should point that even if the final spec calls
> > > for 2), vendors may choose not to follow the requirement (and then
> > > be uncompliant), if they don't think it makes sense for their
> > > customers (the original IPv6 mandate to include IPsec comes to mind,
> > > for example). So if the WG chooses 2) - which is what I expect is
> > > the most reasonable course, it should pay careful attention to
> > > making the details something vendors think is useful, necessary and
> > > workable in practice. I.e, the cost of mitigation matches the threat level.
> > >
> > > Thomas
> > >
> > >
> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 13 Nov 2015 06:31:05 +0000

Yes, security comes at a cost and with the current threat landscape, REQ14 is saying it's MUST. I understand your point, we should discuss the negative implications if REQ14 is changed to "SHOULD" or "RECOMMENDED".
If NSH security is not implemented and SFC is subjected to attacks then operators will not even have the option protect NSH.

-Tiru

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 11:17 AM
> To: Tirumaleswar Reddy (tireddy); Thomas Narten
> Conversely, if the operators do not want it, and including it (authentication
> capability) in the product at suitable scale will introduce noticeable real costs,
> mandating implementation in the RFC is merely a recipe for almost all
> vendors to fudge in their descriptions of what they offer.  Mandating that we
> make it available is defensible, but really hard to make meaningful in
> practice.
> 
> Yours,
> Joel
> 
> >> meeting in Yokohama.  I do no think that particular requirement has
> >> WG consensus, and I think it is an over-reach.
> >>
> >> Including Authentication as an optional capability, well specified
> >> and well integrated, makes good sense to me.  Making it mandatory to
> >> implement seems to much.  And claiming it is mandatory to use would be
> a flat lie.
> >>
> >> Yours,
> >> Joel
> >>

---

From: Ron Parker <[email-masked]>
Date: Fri, 13 Nov 2015 14:12:34 +0000

I'll point out that SFC is not only for operators.   It has application in the enterprise, as well, where security concerns and practices may differ from the operator environment.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 12:47 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; Thomas Narten <[email-masked]>
Cc: [email-masked]; Ron Parker <[email-masked]>
Subject: Re: [sfc] SFC Security Requirements comments - REQ 14

Conversely, if the operators do not want it, and including it (authentication capability) in the product at suitable scale will introduce noticeable real costs, mandating implementation in the RFC is merely a recipe for almost all vendors to fudge in their descriptions of what they offer.  Mandating that we make it available is defensible, but really hard to make meaningful in practice.

Yours,
Joel

On 11/12/15 11:59 PM, Tirumaleswar Reddy (tireddy) wrote:
>> implement seems to much.  And claiming it is mandatory to use would be a flat lie.
>>
>> Yours,
>> Joel
>>
>>> enable security if a product chooses not to implement an "optional" features.
>>>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 13 Nov 2015 10:59:11 -0500

To be clear, when I used the term "operator", I meant it as a general
way to refer to anyone who is actually involved in
operation/deployment. That definitely includes enterprise deployments.

At the end of the day, those actually using/deploying the technology
carry the most weight (IMO) in terms of defining requirements.

Thomas

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Nov 2015 16:25:11 +0000

+1. 

It brings back my comments during the WG adoption for this draft. The security requirement for SFC can be very different under different deployment scenarios. In a closed deployment, e.g. all SFs and SFFs are directly attached and are placed in a enclosure of the provider CO, the security threats are different from the SFs hosted in public cloud and attached to SFFs via public internet. Therefore,  security requirement are different. 

Linda 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ian Smith
Sent: Thursday, November 12, 2015 11:48 PM
To: Tirumaleswar Reddy (tireddy); Joel M. Halpern; Thomas Narten
Cc: [email-masked]; Ron Parker
Subject: Re: [sfc] SFC Security Requirements comments - REQ 14

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 14 Nov 2015 03:37:49 +0000

> From: Linda Dunbar [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 9:55 PM
> To: Ian Smith; Tirumaleswar Reddy (tireddy); Joel M. Halpern; Thomas
> Narten
> Subject: RE: [sfc] SFC Security Requirements comments - REQ 14
> 
> +1.
> 
> It brings back my comments during the WG adoption for this draft. The
> security requirement for SFC can be very different under different
> deployment scenarios. In a closed deployment, e.g. all SFs and SFFs are
> directly attached and are placed in a enclosure of the provider CO, the
> security threats are different from the SFs hosted in public cloud and
> attached to SFFs via public internet. Therefore,  security requirement are
> different.

Yes, we can update the draft to discuss SFC deployments, threats possible and associated security requirements. That way a security requirements in one deployment could be optional and in another deployment will be mandatory. 

-Tiru