Subject: [sfc] will you trust your SF?

From: "Elzur, Uri" <[email-masked]>
Date: Thu, 5 Nov 2015 21:19:24 +0000

Hi

in continuation of the discussion in the meeting today, I'd like to surface this issue and hopefully it can be easily and quickly resolved. In the discussion about Map assisted SFC Proxy, we discussed the potential of an SF (e.g. NAT) to legitimately change the 5 tuple. Control Plane intervention may be needed in such case to update the map (as the new 5 tuple may not be there) and to imply the SF is trusted for this operation.

This goes beyond the question of what to do in the case the SF changed the 5-tuple. It is the question of: is the SF trusted - for the sake of the 5 tuple, as well as for NSH header changes (e.g. SI decrement or even SPI change in case a "Classifier" is incorporated). If not, the SFF (or the Proxy) has to keep that state and VERIFY it on the outbound...

There are opinions as if we need to allow for some SF that are fully trusted and some that are not trusted. I assume all agree the SFF is part of the infrastructure and is trusted. We need to close on this for the NSH draft too.

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Elzur, Uri" <[email-masked]>
Date: Thu, 12 Nov 2015 06:42:28 +0000

Hi

Should I deduce from the no response on the list that the WG is in agreement that the SF should be trusted ?
For multiple reasons that can simplify handling the external tunnel encapsulations (if present) as well as NSH header itself

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Thursday, November 5, 2015 1:19 PM
To: [email-masked]
Subject: [sfc] will you trust your SF?

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: Dave Dolson <[email-masked]>
Date: Thu, 12 Nov 2015 07:32:11 +0000

Uri,

I think the consequences of not trusting the SF are that it be treated like a "legacy SF" device in the sense that it not be sent packets with NSH headers.
Trusting the SF with NSH headers and metadata gives it the ability to move packets to any chain, perhaps crossing tenant boundaries.

So therefore, SFs using NSH must be trusted. The architecture supports the SF-Proxy approach if operators have untrusted SFs.

In my opinion, the issues of so-called "legacy" SFC are therefore elevated in importance. We should be discussing "legacy and untrusted SF".
E.g., in https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-06
could be entitled, "SFC Header Mapping for Legacy SF and Untrusted SF"

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Thursday, November 12, 2015 3:42 PM
To: Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: Ron Parker <[email-masked]>
Date: Thu, 12 Nov 2015 14:38:02 +0000

Dave,

I agree with your analysis.   What we've been thinking of as "legacy SF" (i.e., incapable of processing NSH) can be applied equally to untrusted SF (i.e., capable of processing NSH, but local policy is to not provide NSH).

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, November 12, 2015 2:32 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Uri,

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Thursday, November 12, 2015 3:42 PM
To: Elzur, Uri; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Thursday, November 5, 2015 1:19 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] will you trust your SF?

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Nov 2015 10:22:58 -0500

I have heard from concern from customers in this regard.
For example, they have asked whether we can ensure that the service 
function will not modify the service path identification, even while 
they expect it to consume and produce metadata.

Yours,
Joel

On 11/12/15 1:42 AM, Elzur, Uri wrote:
> Hi
>
> Should I deduce from the no response on the list that the WG is in
> agreement that the SF should be trusted ?
>
> For multiple reasons that can simplify handling the external tunnel
> encapsulations (if present) as well as NSH header itself
>
> Thx
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Elzur, Uri
> *Sent:* Thursday, November 5, 2015 1:19 PM
> *To:* [email-masked]
> *Subject:* [sfc] will you trust your SF?
>
> Hi
>
> in continuation of the discussion in the meeting today, I’d like to
> surface this issue and hopefully it can be easily and quickly resolved.
> In the discussion about Map assisted SFC Proxy, we discussed the
> potential of an SF (e.g. NAT) to legitimately change the 5 tuple.
> Control Plane intervention may be needed in such case to update the map
> (as the new 5 tuple may not be there) and to imply the SF is trusted for
> this operation.
>
> This goes beyond the question of what to do in the case the SF changed
> the 5-tuple. It is the question of: is the SF trusted - for the sake of
> the 5 tuple, as well as for NSH header changes (e.g. SI decrement or
> even SPI change in case a “Classifier” is incorporated). If not, the SFF
> (or the Proxy) has to keep that state and VERIFY it on the outbound…
>
> There are opinions as if we need to allow for some SF that are fully
> trusted and some that are not trusted. I assume all agree the SFF is
> part of the infrastructure and is trusted. We need to close on this for
> the NSH draft too.
>
> Thx
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Ron Parker <[email-masked]>
Date: Thu, 12 Nov 2015 15:31:17 +0000

Joel,

As optional behavior for SFF, a stateful SFF would have the ability to enforce policy regarding attached SF's authorization to change path-id, remove meta-data, add meta-data, change meta-data, etc.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 10:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

I have heard from concern from customers in this regard.
For example, they have asked whether we can ensure that the service function will not modify the service path identification, even while they expect it to consume and produce metadata.

Yours,
Joel

On 11/12/15 1:42 AM, Elzur, Uri wrote:
> in continuation of the discussion in the meeting today, I'd like to 
> Control Plane intervention may be needed in such case to update the 
> map (as the new 5 tuple may not be there) and to imply the SF is 
> trusted for this operation.
>
> the 5-tuple. It is the question of: is the SF trusted - for the sake 
> of the 5 tuple, as well as for NSH header changes (e.g. SI decrement 
> or even SPI change in case a "Classifier" is incorporated). If not, 
> the SFF (or the Proxy) has to keep that state and VERIFY it on the 
> outbound...
>
> part of the infrastructure and is trusted. We need to close on this 
> for the NSH draft too.
>
> Thx
>
> Uri ("Oo-Ree")
>
> C: 949-378-7568
>
>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 12 Nov 2015 16:05:08 +0000

[Chair hat off ...]

Honestly the whole SF trust issue makes no sense to me from a practical perspective. Presumably if I have programmatic control over network elements then I can do whatever I want and it has nothing to do with NSH. The argument that an SF can do bad things is a red herring given that if I can gain access to any network element I can do bad things - add routes to VRFs that should not be there, put interfaces into the wrong VRF, inject routes that force traffic in a certain direction, the list goes on and on and on .. What I can do from an SFC perspective is verify traffic from SF->SFF (which I need for loop prevention anyway) to make sure that packets received from an SF comply with the SFP policy implemented at the SFF e.g. I only expect to receive <SPI(10), index (254) from SF1 etc ..

Jim

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Elzur, Uri" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 12, 2015 at 1:42 AM
To: "Elzur, Uri" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] will you trust your SF?

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 12 Nov 2015 16:10:43 +0000

Could not agree more. We need to focus on the security aspects that NSH brings to the table and not generic things that were always there.

I have the same concerns about the SFC security requirements draft/presentation in Yokohama. The document mixes generic security attacks that were always possible in IP networks with NSH specific things.  I think somebody went to the mike (Linda?) and said something like: too many requirements detract/weakens the real stuff we should be looking into.

Thanks,

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 12, 2015 at 8:05 AM
To: "Elzur, Uri" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] will you trust your SF?

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 12 Nov 2015 16:49:32 +0000

Hi Ron, Joel, Uri, WG,

>From my humble network operator's point of view: The SF security discussion lost any relation to reality. You could ask, do you trust the network, the operator? Operators enforce policies and handle metadata (data plane,  control plane) in the network, in SFCs, for charging etc. since ever.  
If a SF is not doing what I expect, I would fix this issue (inhouse, or with the vendor).  

The discussion about reclassification indicates that we probably should explain  this mechanism in some more detail in an existing draft (control plane draft?). Will the SF itself modify a SFF forwarding table or is SF going to trigger C-Plane to modify forwarding table(s)? I would prefer the latter.

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Ron Parker
Gesendet: Donnerstag, 12. November 2015 16:31
An: Joel M. Halpern; Elzur, Uri; [email-masked]
Betreff: Re: [sfc] will you trust your SF?

Joel,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 10:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 12 Nov 2015 16:58:08 +0000

I am bit lost on this whole trust issue. If there is concern about trusting a particular SF it should go beyond just NSH headers. How does rcving SF-B knows that payload is really from SF-A, or is the src_ip is not spoofed? There are many ways to solve those.

So what is the concern,
   A) non transport level encryption scheme(all practical scheme has built in authentication)  doesn't protect NSH payload?
   B) Rcving SF must be able to verify that NSH hdr came from SF-A or more generally produced by one of the trusted SF?

I can smell yet another mess of shared secret and associated infrastructure mess...

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 12, 2015 at 6:38 AM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, "Elzur, Uri" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] will you trust your SF?

Dave,

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, November 12, 2015 2:32 AM
To: Elzur, Uri <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Uri,

-Dave

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: Dave Dolson <[email-masked]>
Date: Thu, 12 Nov 2015 22:39:43 +0000

I think the basic conclusion is that NSH-aware SFs must be trusted.

This m‎eans one cannot have NSH-aware tenants in the same way that one can have virtual-machine tenants--which can be isolated.

From: Sumandra Majee
Sent: Friday, November 13, 2015 1:58 AM
To: Ron Parker; Dave Dolson; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

So what is the concern,
   A) non transport level encryption scheme(all practical scheme has built in authentication)  doesn’t protect NSH payload?
   B) Rcving SF must be able to verify that NSH hdr came from SF-A or more generally produced by one of the trusted SF?

I can smell yet another mess of shared secret and associated infrastructure mess…

Dave,

I agree with your analysis.   What we’ve been thinking of as “legacy SF” (i.e., incapable of processing NSH) can be applied equally to untrusted SF (i.e., capable of processing NSH, but local policy is to not provide NSH).

   Ron

Uri,

I think the consequences of not trusting the SF are that it be treated like a “legacy SF” device in the sense that it not be sent packets with NSH headers.
Trusting the SF with NSH headers and metadata gives it the ability to move packets to any chain, perhaps crossing tenant boundaries.

In my opinion, the issues of so-called “legacy” SFC are therefore elevated in importance. We should be discussing “legacy and untrusted SF”.
E.g., in https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-06
could be entitled, “SFC Header Mapping for Legacy SF and Untrusted SF”

-Dave

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Hi

in continuation of the discussion in the meeting today, I’d like to surface this issue and hopefully it can be easily and quickly resolved. In the discussion about Map assisted SFC Proxy, we discussed the potential of an SF (e.g. NAT) to legitimately change the 5 tuple. Control Plane intervention may be needed in such case to update the map (as the new 5 tuple may not be there) and to imply the SF is trusted for this operation.

This goes beyond the question of what to do in the case the SF changed the 5-tuple. It is the question of: is the SF trusted - for the sake of the 5 tuple, as well as for NSH header changes (e.g. SI decrement or even SPI change in case a “Classifier” is incorporated). If not, the SFF (or the Proxy) has to keep that state and VERIFY it on the outbound…

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Nov 2015 17:44:15 -0500

Trust is not usually an all-or-nothing proposition.  NSH aware SF (and 
even non-NSH-aware SF) are trusted to do certain things, and to not do 
certain things.  The more you have to trust it, the more constraints 
(testing, whatever).

So being able to say that I only trust this SF so much is helpful. 
Strictly necessary?  Probably not.  But being able to indicate that 
certain restrictions should be checked if possible seems desirable.
And being able to restrict the what kinds of trust are given allows the 
operator more flexibility.

Just for context, even operations staff are not trusted to do 
everything.  They have roles, and permissions based on those roles.

Yours,
Joel

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 13 Nov 2015 05:37:40 +0000

(Reply #2, may want to read the other one first)

Pls note comments on other mail on this thread. One of the implications of the trust is elimination of a potential SFF requirements to keep state for enforcing "correct" SF behavior. Some SF must be trusted as they can change even the internal packet too. if he SF is "not trusted' then the SFF should check the internal headers too...
 and so we should debate if we even have a class of "unstusted SF" that are processing only a portion of the NSH header (e.g. SI).

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, November 12, 2015 7:31 AM
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Joel,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 10:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 13 Nov 2015 05:37:35 +0000

Few comments

1)      The NSH draft right now, is careful stating that an SF can ONLY decrement the SI and technically can't change the SPI and w/o a classifier can't change metadata ("Context Header") either. It is not easy/possible from an SFF point of view to tell which SF comprises a Classifier too or not. without Control Plane indication the SFF can't tell if an SF is to be trusted or not. Now, this has implications.

2)      A Trusted SF - may be / should be  privy to the whole external packet, as it may need it for further processing or simplification (e.g. in a multi tenancy scenario be able to associate dup  IP addresses with the right tenant for employing diff policy/processing/SPI). As the SF is trusted, no state in the SFF is required on the Tx, to ensure no abuse of the NSH (SI or SPI). State may still be required somewhere, for the case an internal field has changed e.g. due to NAT which may change the classification results and hence the forwarding/processing decision.

3)      "Local circuit" concept (i.e. between the SFF and the SF) - becomes optional. One may prefer Eth+NSH locally as an example, and use some form of tunneling outside on the "transport", but one may also simply extend the "tunnel" to the SF too. This promotes also, the question of the vTEP for the external "transport". The local vSwitch (integrated w the SFF or not) should have that responsibility. This is a bit out of scope for the SFC WG, though.

4)      Legacy and Proxy -  the SFF is to be programmed as to what encapsulation to use on the "local circuit" . A Proxy is a trusted entity and therefore is no different from a trusted SF as above. A legacy SF is not participating in NSH processing and so it is may be irrelevant if it is to trusted or not..

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 6:38 AM
To: Dave Dolson; Elzur, Uri; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Dave,

   Ron

Uri,

-Dave

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 13 Nov 2015 05:37:45 +0000

(reply #4, you may want to read them in order)

I can see how the title "trust your SF" is implying this is part of the Security draft, sorry, but this was not my intention. At least not the main reason for the message. . To me this is more part of the arch and NSH discussion as to the provisions of an SF and the state/enforcement required by an SFF

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Thursday, November 12, 2015 8:50 AM
To: Ron Parker; Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Hi Ron, Joel, Uri, WG,

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Ron Parker
Gesendet: Donnerstag, 12. November 2015 16:31
An: Joel M. Halpern; Elzur, Uri; [email-masked]
Betreff: Re: [sfc] will you trust your SF?

Joel,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 10:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 13 Nov 2015 05:37:44 +0000

(reply #3, you may want to read the other ones first)

Agree w the sentiment of further focusing the security requirements draft. however,

The use model where trusting he SF or not, becomes interesting is that of BYOD SF.
I also think we should have clear agreement as to whether SF is trusted (or not say by Control Plane signaling) and adjust the SFF enforcement accordingly

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 8:11 AM
To: Jim Guichard (jguichar); Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 13 Nov 2015 05:37:46 +0000

(Reply #6, you may want to read them in order)

It is about the normative text in the arch an NSH draft and the provisions allowed for an SF. If trusted to decrement the SI, why not change the SPI. If not what is the requirement for SFF enforcement etc.

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Sumandra Majee [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 8:58 AM
To: Ron Parker; Dave Dolson; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

So what is the concern,

Dave,

   Ron

Uri,

-Dave

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

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

Yes, https://tools.ietf.org/html/draft-mglt-sfc-security-environment-req-00#section-7 is already discussing NSH security aspects.

-Tiru

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Thursday, November 12, 2015 9:41 PM
To: Jim Guichard (jguichar); Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

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

Agreed, SF are trusted network elements. A untrusted SF can do lot of damage (clone traffic to attacker, leak privacy sensitive info etc.)

-Tiru
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, November 12, 2015 9:35 PM
To: Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 13 Nov 2015 07:24:52 +0000

"The use model where trusting he SF or not, becomes interesting is that of BYOD SF.”

It seems again we are conflating generic security requirements with NSH.  If you trust the device then you accept it being part of a chain. If a device is compromised changing NSH metadata is the least of the problems.

I will reiterate my point about NSH security requirements. What new specific NSH attacks (and only NSH) we should guard against. Solving device trust issue, IP networks layer issues, transport issues, etc seems very much out of scope of this WG.

Thanks,

From: "Elzur, Uri" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 12, 2015 at 9:37 PM
To: Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] will you trust your SF?

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 8:11 AM
To: Jim Guichard (jguichar); Elzur, Uri; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Thanks,

[Chair hat off …]

Honestly the whole SF trust issue makes no sense to me from a practical perspective. Presumably if I have programmatic control over network elements then I can do whatever I want and it has nothing to do with NSH. The argument that an SF can do bad things is a red herring given that if I can gain access to any network element I can do bad things – add routes to VRFs that should not be there, put interfaces into the wrong VRF, inject routes that force traffic in a certain direction, the list goes on and on and on .. What I can do from an SFC perspective is verify traffic from SF->SFF (which I need for loop prevention anyway) to make sure that packets received from an SF comply with the SFP policy implemented at the SFF e.g. I only expect to receive <SPI(10), index (254) from SF1 etc ..

Jim

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 13 Nov 2015 16:54:51 +0000

Reinaldo

It seems like we are arguing for the same outcome. My argument is NOT about the security aspect, it is about the SF role under SFC for the purpose of clarifying the potential role SF can play and for SFF simplification (e.g. no need to keep state for checking the SF was indeed doing it role vs abusing SI or SPI. Can share the external tunnel info with the SF [if the latter is capable of processing when it is present] and use it on the egress etc. Still need to keep state for forwarding in some cases). If we agree an "SF can be trusted for NSH purposes"  then it can lead to some simplifications, I believe

I'm also ok leaving status quo as-is with a delicate balance of SF, SFF and proxy roles. But I do think that making the assumption like you make, that the issue of the SF being rogue or not is beyond this WG scope, can simplify our drafts. At the same time, we need to agree to the NSH SPECIFC security aspects and this is on-going on the ml

Hope this makes my comments a bit clearer

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 11:25 PM
To: Elzur, Uri; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] will you trust your SF?

"The use model where trusting he SF or not, becomes interesting is that of BYOD SF."

Thanks,

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 13 Nov 2015 17:04:05 +0000

Perfect, thank you.

From: "Elzur, Uri" <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 13, 2015 at 8:54 AM
To: Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] will you trust your SF?

Reinaldo

It seems like we are arguing for the same outcome. My argument is NOT about the security aspect, it is about the SF role under SFC for the purpose of clarifying the potential role SF can play and for SFF simplification (e.g. no need to keep state for checking the SF was indeed doing it role vs abusing SI or SPI. Can share the external tunnel info with the SF [if the latter is capable of processing when it is present] and use it on the egress etc. Still need to keep state for forwarding in some cases). If we agree an “SF can be trusted for NSH purposes”  then it can lead to some simplifications, I believe

I’m also ok leaving status quo as-is with a delicate balance of SF, SFF and proxy roles. But I do think that making the assumption like you make, that the issue of the SF being rogue or not is beyond this WG scope, can simplify our drafts. At the same time, we need to agree to the NSH SPECIFC security aspects and this is on-going on the ml

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 11:25 PM
To: Elzur, Uri; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Thanks,

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Thanks,

[Chair hat off …]

Jim

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 15 Nov 2015 23:56:45 +0000

+1

There is infrastructure and there is application. The promise of SFC is to bring any vendor, third party or home grown SFs into the operator's network. This requires either the SFs (applications) be robust, certified (how?) to work and maintain a secure environment or, simply make the SFFs (infrastructure) robust and secure with control plane enforcing trust between SFF and SF.

It seems fine for SFs to influence the forwarding decisions at SFF via metadata (fully under SFF's control) but not itself make the forwarding decisions - as is allowed via the manipulation of the service index by the SFs. If SFFs are the ones allowed to make forwarding decisions, why allow SFs to decrement the service index and on top of that check whether SF did the right thing - completely redundant and unnecessary and even incorrect if you think how it leads to a forwarding decision at SFF. IOW, ServicePath and ServiceIndex is owned by SFF and should be opaque to SFs.

Making metadata available for SFs and SFFs, in the data plane, is NSH's value. While consuming that metadata to offer enhanced service is SFs value. SFFs on the other hand ensure traffic is forwarded along the right path to the right SFs. Whether the SF instance is part of SFC1 or 10 or 100 or, how packets move from one SF to another must not be mixed with SF focus on delivering service if we are to keep the architecture clean and simple.

As Uri points out, SFF clearly is infrastructure and the separation between infrastructure and application is important to operators and needs to be maintained. 

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 16 Nov 2015 00:02:55 +0000

This is akin to allowing any application in the data center make forwarding decisions that the switches and routers then use to forward packets on!

The switch/router/fabric is better served with forwarding packets while the applications do their stuff: Infrastructure vs. application. Don't mix them.

Surendra.

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, November 12, 2015 8:05 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 16 Nov 2015 04:16:31 +0000

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Thursday, November 12, 2015 9:38 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Few comments

1)      The NSH draft right now, is careful stating that an SF can ONLY decrement the SI and technically can't change the SPI and w/o a classifier can't change metadata ("Context Header") either. It is not easy/possible from an SFF point of view to tell which SF comprises a Classifier too or not. without Control Plane indication the SFF can't tell if an SF is to be trusted or not. Now, this has implications.
SK> The normative requirement that SF decrement SI is incorrect. It mixes forwarding decision with service delivery! You are correct in observing control plane involvement is required to put the environment/deployment in order and identifying the roles of the components.

2)      A Trusted SF - may be / should be  privy to the whole external packet, as it may need it for further processing or simplification (e.g. in a multi tenancy scenario be able to associate dup  IP addresses with the right tenant for employing diff policy/processing/SPI). As the SF is trusted, no state in the SFF is required on the Tx, to ensure no abuse of the NSH (SI or SPI). State may still be required somewhere, for the case an internal field has changed e.g. due to NAT which may change the classification results and hence the forwarding/processing decision.
SK> Clear separation of service/application vs. infrastructure is absolutely essential. This does not prevent co-location of architecture components. Having SFs make forwarding decisions while SFFs enforcing those decisions muddles the water, whether SF is trusted or not. In multi-tenancy SF is better served with the use of metadata to identify tenant than the SPI itself and treat SPI+SI as opaque data.

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 6:38 AM
To: Dave Dolson; Elzur, Uri; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] will you trust your SF?

Dave,

   Ron

Uri,

-Dave

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 16 Nov 2015 05:59:48 +0000

What kind of new requirements is SF not modifying service index bringing into NSH security ?

If SF is trusted and it is not supposed to modify the service index but because of a bug or bad configuration it modifies the SFP then it can be detected by SFF and rectified. But if an SF is untrusted (like an host installing an malicious java script) then it can do lots of damage to the network and may not always be possible to detect an infected SF.

If SF not modifying service index needs to be solved at the protocol level then it brings in new NSH security requirements like 
- SF can decrypt the service path header but it cannot update and re-encrypt the Service Path Header.

We probably have to discuss the role of SF if it allowed to decrypt the service path header, decrypt NSH metadata, modify NSH metadata, add NSH metadata etc.

-Tiru

> From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar
> (smkumar)
> Sent: Monday, November 16, 2015 5:27 AM
> There is infrastructure and there is application. The promise of SFC is to bring
> any vendor, third party or home grown SFs into the operator's network. This
> requires either the SFs (applications) be robust, certified (how?) to work and
> maintain a secure environment or, simply make the SFFs (infrastructure)
> robust and secure with control plane enforcing trust between SFF and SF.
> 
> It seems fine for SFs to influence the forwarding decisions at SFF via
> metadata (fully under SFF's control) but not itself make the forwarding
> decisions - as is allowed via the manipulation of the service index by the SFs.
> If SFFs are the ones allowed to make forwarding decisions, why allow SFs to
> decrement the service index and on top of that check whether SF did the
> right thing - completely redundant and unnecessary and even incorrect if you
> think how it leads to a forwarding decision at SFF. IOW, ServicePath and
> ServiceIndex is owned by SFF and should be opaque to SFs.
> 
> Making metadata available for SFs and SFFs, in the data plane, is NSH's value.
> While consuming that metadata to offer enhanced service is SFs value. SFFs
> on the other hand ensure traffic is forwarded along the right path to the right
> SFs. Whether the SF instance is part of SFC1 or 10 or 100 or, how packets
> move from one SF to another must not be mixed with SF focus on delivering
> service if we are to keep the architecture clean and simple.
> 
> As Uri points out, SFF clearly is infrastructure and the separation between
> infrastructure and application is important to operators and needs to be
> maintained.
> 
> Surendra.
> 
> 
> function will not modify the service path identification, even while they
> expect it to consume and produce metadata.
> 
> Yours,
> Joel
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 16 Nov 2015 06:26:11 +0000

[Skipping to the top of this thread and repeating some things from previous responses.]

Keep the separation

*        between packet forwarding and service delivery

*        between application and infrastructure

*        between metadata and forwarding data

*        etc.

Simple SFs without forwarding constraints enables SFs to focus on service delivery and not service chaining and forwarding complexity, that goes into the SFFs. Enable SFs to consume metadata for value added service delivery and not for packet forwarding, that belongs in SFF.

Operators want the flexibility to on-board any SF into the service plane without having to concern themselves about how that affects packet forwarding in their infrastructure. Whether SF is trusted or not, SF must stay off doing the SFF's job.

If ETSI/NFV is any guide, this separation in operators' view should be obvious.

NSH draft until the last couple of revisions stayed off the normative language in this regard and is misguided in specifying, for instance, the decrement of SI at SF as opposed to SFF. This tosses architecture robustness out the window.

Surendra.

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Friday, November 13, 2015 8:55 AM
To: Reinaldo Penno (repenno) <[email-masked]>; Jim Guichard (jguichar) <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Reinaldo

SK>

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Mon, 16 Nov 2015 14:30:16 +0000

Ad'hoc Service chaining solutions are in production today in various networks, supporting transparent and non transparent middleboxes through various schemes.
Firewalls for example are inserted between clients and servers transparently, and in effect they are treated as trusted entities, as they are given access to the
content of the traffic allowing them to view and modify it. Who does not trust his Firewall appliance ?

I think we can safely assume that the same will apply when NSH is used for service chaining.

So the question I have is then why wouldn't we trust SFs as far as routing is concerned when we will have to trust them with the traffic content ?

Nicolas

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: lundi 16 novembre 2015 00:57
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

+1

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 16 Nov 2015 16:54:57 +0000

You are absolutely correct, there could be bugs in SF that affect any part of NSH and you can't blindly forward on data that comes back from SFs. Likewise, there could be bugs in SFFs too but SFFs being part of infra usually go through much stringent scrutiny and assessment.

To make the architecture robust, SFFs should not assume the integrity of the SPI+SI coming back from SFs and forward on that, let alone requiring SFs to modify the forwarding-data in NSH.

Surendra.

-----Original Message-----
From: Tirumaleswar Reddy (tireddy) 
Sent: Sunday, November 15, 2015 10:00 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Joel M. Halpern <[email-masked]>; Elzur, Uri <[email-masked]>; [email-masked]
Subject: RE: [sfc] will you trust your SF?

-Tiru

> There is infrastructure and there is application. The promise of SFC 
> is to bring any vendor, third party or home grown SFs into the 
> operator's network. This requires either the SFs (applications) be 
> robust, certified (how?) to work and maintain a secure environment or, 
> simply make the SFFs (infrastructure) robust and secure with control plane enforcing trust between SFF and SF.
> 
> metadata (fully under SFF's control) but not itself make the 
> forwarding decisions - as is allowed via the manipulation of the service index by the SFs.
> If SFFs are the ones allowed to make forwarding decisions, why allow 
> SFs to decrement the service index and on top of that check whether SF 
> did the right thing - completely redundant and unnecessary and even 
> incorrect if you think how it leads to a forwarding decision at SFF. 
> IOW, ServicePath and ServiceIndex is owned by SFF and should be opaque to SFs.
> 
> While consuming that metadata to offer enhanced service is SFs value. 
> SFFs on the other hand ensure traffic is forwarded along the right 
> path to the right SFs. Whether the SF instance is part of SFC1 or 10 
> or 100 or, how packets move from one SF to another must not be mixed 
> with SF focus on delivering service if we are to keep the architecture clean and simple.
> 
> As Uri points out, SFF clearly is infrastructure and the separation 
> between infrastructure and application is important to operators and 
> needs to be maintained.
> 
> Surendra.
> 
> 
> > This goes beyond the question of what to do in the case the SF 
> > changed the 5-tuple. It is the question of: is the SF trusted - for 
> > the sake of the 5 tuple, as well as for NSH header changes (e.g. SI 
> > decrement or even SPI change in case a "Classifier" is 
> > incorporated). If not, the SFF (or the Proxy) has to keep that state 
> > and VERIFY it on the outbound...
> >

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 16 Nov 2015 17:05:37 +0000

Nicolas,

Inline.

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 6:30 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Joel M. Halpern <[email-masked]>; Elzur, Uri <[email-masked]>; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Ad'hoc Service chaining solutions are in production today in various networks, supporting transparent and non transparent middleboxes through various schemes.
SK> Agree, wearing my vendor hat, I do it for day job - I admit.

Firewalls for example are inserted between clients and servers transparently, and in effect they are treated as trusted entities, as they are given access to the content of the traffic allowing them to view and modify it.
SK> VLAN stitching has existed for a long long time and service chaining is not something new.

Who does not trust his Firewall appliance ?
SK> They were controlled by physical cabling and an inline deployment model with everything on the underlay network. The drawbacks of the legacy and the reason for SFC ... are in problem statements and use cases.

I think we can safely assume that the same will apply when NSH is used for service chaining.
SK> Probably not. We have changed everything - explicit steering, overlay networks, metadata, etc. Also, note that there are many different types of firewalls, not all of them fall into the traditional definition.

So the question I have is then why wouldn't we trust SFs as far as routing is concerned when we will have to trust them with the traffic content ?
SK> they are two different planes: User Plane vs. Forwarding Plane.

Surendra.

Nicolas

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: lundi 16 novembre 2015 00:57
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

+1

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: "Elzur, Uri" <[email-masked]>
Date: Tue, 17 Nov 2015 03:53:37 +0000

Sharing some thoughts in response:

Clearly some SFs must be trusted e.g. NAT. NAT  is an example of an SF that is part of the infrastructure. At the same time some SFs may only be trusted to do some things but not  everything, but clearly as they have been put on a Service Chain, should get  access to some network processing… this is part of moving from physical to virtual SFs

IOW, Part of the SFC functionality/intention and architectural direction is about letting SFs influence the forwarding. To be clear, it seems like, Influence ≠ direct or control the forwarding.
The question is what is the right balance. To me SFs ≠  applications, as mentioned above. At the same time, we may want to limit the potential damage a rogue/buggy SF may have on neighbors SPI etc. This is the task of the SFC Security  draft to point out the critical risks and then we see what is the best course of action to address them.  Altenatively we can agree to create two classes of SF (I’m not a fan…) to be indicated by the Control Plane (whch can be done today too!)

As to the SI vs SPI: if the criteria prevent damage to thy neighboring chain, SI decrement is not a issue. And it is an indication of the SF being alve and doing some action which may be better option that he SFF blindly decrementing SI

Thx
Uri (“Oo-Ree”)
C: 949-378-7568

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Sunday, November 15, 2015 3:57 PM
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: RE: [sfc] will you trust your SF?

+1

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

On 11/12/15 1:42 AM, Elzur, Uri wrote:
> *To:* [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Elzur, Uri" <[email-masked]>
Date: Tue, 17 Nov 2015 03:55:54 +0000

Hi Surendra

Pls see [UE] below

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Sunday, November 15, 2015 8:17 PM
To: Elzur, Uri; Ron Parker; Dave Dolson; [email-masked]
Subject: RE: [sfc] will you trust your SF?

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Thursday, November 12, 2015 9:38 PM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Few comments

1)      The NSH draft right now, is careful stating that an SF can ONLY decrement the SI and technically can't change the SPI and w/o a classifier can't change metadata ("Context Header") either. It is not easy/possible from an SFF point of view to tell which SF comprises a Classifier too or not. without Control Plane indication the SFF can't tell if an SF is to be trusted or not. Now, this has implications.
SK> The normative requirement that SF decrement SI is incorrect. It mixes forwarding decision with service delivery! You are correct in observing control plane involvement is required to put the environment/deployment in order and identifying the roles of the components.
[UE] replied in the other thread

2)      A Trusted SF - may be / should be  privy to the whole external packet, as it may need it for further processing or simplification (e.g. in a multi tenancy scenario be able to associate dup  IP addresses with the right tenant for employing diff policy/processing/SPI). As the SF is trusted, no state in the SFF is required on the Tx, to ensure no abuse of the NSH (SI or SPI). State may still be required somewhere, for the case an internal field has changed e.g. due to NAT which may change the classification results and hence the forwarding/processing decision.
SK> Clear separation of service/application vs. infrastructure is absolutely essential. This does not prevent co-location of architecture components. Having SFs make forwarding decisions while SFFs enforcing those decisions muddles the water, whether SF is trusted or not. In multi-tenancy SF is better served with the use of metadata to identify tenant than the SPI itself and treat SPI+SI as opaque data.
[UE] SF are not making forwarding decisions, however they can influence them. They can also alter the packet content e.g NAT and this is desired

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Dave,

   Ron

Uri,

-Dave

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Elzur, Uri" <[email-masked]>
Date: Tue, 17 Nov 2015 04:00:58 +0000

Draft-quinn-sfc-nsh-07 form February of this year has

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Sunday, November 15, 2015 10:26 PM
To: Elzur, Uri; Reinaldo Penno (repenno); Jim Guichard (jguichar); [email-masked]
Subject: RE: [sfc] will you trust your SF?

Keep the separation

*         etc.

Surendra.

From: sfc [mailto:[email-masked]] On Behalf Of Elzur, Uri
Sent: Friday, November 13, 2015 8:55 AM
To: Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>>; Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] will you trust your SF?

Reinaldo

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Elzur, Uri" <[email-masked]>
Date: Tue, 17 Nov 2015 04:04:45 +0000

Nicolas

Pls see response in the other mail on this thread. Some SFs are part of the infrastructure as you pointed out. If we are to have "less trusted SFs" too, it wil have implications on the Control plane and on the ability of these less privileged SF to be used in multi-tenant env.

It may add unnecessary complexity. So I was proposing trust the SF, subject to WG agreed processed input of SFC Security work

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 6:30 AM
To: Surendra Kumar (smkumar); Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Ad'hoc Service chaining solutions are in production today in various networks, supporting transparent and non transparent middleboxes through various schemes.
Firewalls for example are inserted between clients and servers transparently, and in effect they are treated as trusted entities, as they are given access to the content of the traffic allowing them to view and modify it. Who does not trust his Firewall appliance ?

Nicolas

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: lundi 16 novembre 2015 00:57
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

+1

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Tue, 17 Nov 2015 08:51:10 +0000

Hello Uri

I agree with this proposal.  It is the logical conclusion I reach from the note I made.

+1 also on your other point stating that the SI modification is an indication for the SFF that the SF is active.

From  a security point of view the points that I can see that should be tackled:

- Control if SFs in a chain can be dedicated to a chain / tenant or can process traffic  from multiple chains / tenants

   Allowing a chain user to specify that it wants dedicated resources to handle his traffic seems useful.  This does not   seem too costly to implement.

- Control if/what Information can be "leaked" from the infrastructure to the SF via the NSH metadata

 Metadata/context data has been defined as a mean to  share information amongst SFs  and classifiers, between SFs, and between   external systems and SFs (e.g., orchestration). This could lead to a great variety of use cases for Metadata transport
 So I don't think there is a strong case to make the SFF as an enforcement point to control such information exchanges.

Nicolas

-----Original Message-----
From: Elzur, Uri [mailto:[email-masked]]
Sent: mardi 17 novembre 2015 05:05
To: Nicolas BOUTHORS; Surendra Kumar (smkumar); Joel M. Halpern; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Nicolas

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Monday, November 16, 2015 6:30 AM
To: Surendra Kumar (smkumar); Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Nicolas

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: lundi 16 novembre 2015 00:57
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

+1

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 17 Nov 2015 18:14:18 +0000

Hi Uri,

I've tried consolidate the crux of your other comments here to do a single response, please correct me if I misstate any of your comments/response or if I'm taking them out of context.

Uri>>SF are not making forwarding decisions, however they can influence them.
SK2> SI dictates what the next hop is at the SFF. IOW, this index clearly instructs the SFF where the packet must be sent next. An SI value of 2 may mean send to a FW or 1 may mean the chain is done and forward on the underlay, etc.. So, this is not influencing, this is the actual decision - let's not confuse this. Also, this is not random, this is all programmed by the control plane.

Uri>>As to the SI vs SPI: if the criteria prevent damage to thy neighboring chain, SI decrement is not a issue.
SK2> SFF is the one with the steering tables, which is programmed by the control plane dictating how the packets should be steered. There is a well formulated structure that control plane manages. If an entity other than SFF wants to decrement, then that should be under control planes control to ensure packet forwarding on the overlay network is correct. Otherwise you have a wild west. By allowing this, you are removing the distinction between SF and SFF - you might as well collapse them into one. The control plane now not only needs to manage the service chains but also the SFs - becomes intractable.

Uri>> ...And it is an indication of the SF being alve and doing some action which may be better option that he SFF blindly decrementing SI
SK2> As for knowing whether SF is alive, you don't need a decrement from the SF, the fact that the SFF is receiving the packet from that SF is indication enough. Anything beyond needs to well defined in the context of OAM and not overload forwarding with OAM.

Uri>> Clearly some SFs must be trusted e.g. NAT. NAT  is an example of an SF that is part of the infrastructure.
SK2> This came up at the open-mic in Yokohama, I think Kent or someone had some good comments on it. NAT brings up a lot of questions. And so does routing that is part of many traditional firewalls or load balancers, which Nicolas brought up. As an example, what happens to the overlay when the packet is transformed through a SF - does it terminate, or is it replaced with a new one or continues through it ? What are the implications of each ? What happens to the SPI+SI? It is not a question of mechanics but the underlay/overlay semantics come into picture to keep packet forwarding correctness in the networks. Beyond that, what does it map to in SFC architecture, etc.

SK2> While I am happy to contribute to the NAT discussion, the SI issue we are talking does not warrant that - it is much general: SF vs. SFF. I would prefer as WG, we address the SI even before we get to the NAT part to demonstrate SFC with NSH is viable in real-world.

Finally, thanks for the SI snippet below. The "MUST" in that is the problem. Until the WG resolves this, please remove this requirement. It simply does not make sense to mix network forwarding with service delivery - they are two distinct things. Let implementations make the right decision.

Surendra.

From: Elzur, Uri [mailto:[email-masked]]
Sent: Monday, November 16, 2015 8:01 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Reinaldo Penno (repenno) <[email-masked]>; Jim Guichard (jguichar) <[email-masked]>; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Thx

Uri ("Oo-Ree")
C: 949-378-7568

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Sunday, November 15, 2015 10:26 PM
To: Elzur, Uri; Reinaldo Penno (repenno); Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] will you trust your SF?

Keep the separation

*        etc.

Surendra.

Reinaldo

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 17 Nov 2015 18:15:44 +0000

>>+1 also on your other point stating that the SI modification is an indication for the SFF that the SF is active.

You should be able to tell that by the fact that the SFF is receiving packets from that SF and don't need a decrement. For getting more insight into the health of the SF, OAM would be the right way to address it. Alternately, if inline method is preferred, there are TLVs to achieve that.

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nicolas BOUTHORS
Sent: Tuesday, November 17, 2015 12:51 AM
To: Elzur, Uri <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Hello Uri

Nicolas

-----Original Message-----
From: Elzur, Uri [mailto:[email-masked]]
Sent: mardi 17 novembre 2015 05:05
To: Nicolas BOUTHORS; Surendra Kumar (smkumar); Joel M. Halpern; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Nicolas

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Monday, November 16, 2015 6:30 AM
To: Surendra Kumar (smkumar); Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Nicolas

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: lundi 16 novembre 2015 00:57
To: Joel M. Halpern; Elzur, Uri; [email-masked]
Subject: Re: [sfc] will you trust your SF?

+1

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 12, 2015 7:23 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] will you trust your SF?

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 17 Nov 2015 18:48:48 +0000

Hi Surendra,

>Finally, thanks for the SI snippet below. The “MUST” in that is the problem. Until the WG resolves this, please remove this requirement. It simply does not make sense to mix network forwarding with service delivery – >they are two distinct things. Let implementations make the right decision.

Jim> removal of text from a WG document is a decision that the WG needs to make based on consensus (as determined by the chairs). This issue is not resolved and consensus must be reached before any change to the text is made.

Jim

From: Elzur, Uri [mailto:[email-masked]]
Sent: Monday, November 16, 2015 8:01 PM
To: Surendra Kumar (smkumar) <[email-masked]<mailto:[email-masked]>>; Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>>; Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] will you trust your SF?

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Keep the separation

·        between packet forwarding and service delivery

·        between application and infrastructure

·        between metadata and forwarding data

·        etc.

Operators want the flexibility to on-board any SF into the service plane without having to concern themselves about how that affects packet forwarding in their infrastructure. Whether SF is trusted or not, SF must stay off doing the SFF’s job.

If ETSI/NFV is any guide, this separation in operators’ view should be obvious.

Surendra.

Reinaldo

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Thanks,

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Thanks,

[Chair hat off …]

Jim

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

Hi

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

---

From: Dave Dolson <[email-masked]>
Date: Tue, 17 Nov 2015 19:46:00 +0000

Surendra,
In your comment,
SK2> As for knowing whether SF is alive, you don't need a decrement from the SF, the fact that the SFF is receiving the packet from that SF is indication enough.

You are making an assumption that it is easy for an SFF to determine where a packet came from. This may be true for local direct connections, but in other cases would require checking source MAC addresses or source IP addresses (if these can even be trusted). Upon receiving a packet, decide whether it came from an SF or an SFF in order to decide whether to decrement the SI or not.

As currently defined, with the SF decrementing the index, the SFF can forward the packet purely based on lookup tables indexed by {SPI,SI}.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, November 17, 2015 1:14 PM
To: Elzur, Uri; Reinaldo Penno (repenno); Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] will you trust your SF?

Hi Uri,

Surendra.

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Keep the separation

*        etc.

Surendra.

Reinaldo

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 23 Nov 2015 07:36:40 +0000

Dave,

Sorry for the delayed response. Not assuming anything. Let me put together a draft on this.

Surendra.

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, November 17, 2015 11:46 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Elzur, Uri <[email-masked]>; Reinaldo Penno (repenno) <[email-masked]>; Jim Guichard (jguichar) <[email-masked]>; [email-masked]
Subject: RE: [sfc] will you trust your SF?

Surendra,
In your comment,

-Dave

Hi Uri,

Surendra.

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Keep the separation

*        etc.

Surendra.

Reinaldo

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Thanks,

[Chair hat off ...]

Jim

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568

Hi

Thx

Uri ("Oo-Ree")
C: 949-378-7568