Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Feb 2015 16:44:37 -0500

Hi Paul,

On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) <[email-masked]> wrote:

> Hi Kathleen,
>
> We are working my way through the IESG comments, thanks for sending yours!
>

Thank you and sorry for my delay in response.

>
> Please see inline.
>
> Paul
>
>
> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty <
> [email-masked]> wrote:
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I didn't see any mention of risks with multiple tenants and shared
> > infrastructure for service functions, is that a concern?  This
> > consideration may fall into the same description as the second point from
> > Ben's SecDir review (linked in Stephen's review). Although the SecDir
> > review point could be within a single tenant environment where there may
> > or may not be various levels of trust depending on access constraints (to
> > the same or different set of applications for a single tenant).  I'd like
> > to make sure both points get addressed or if someone can tell me why it
> > doesn't matter, that would be fine too.
>

Is this problem addressed by SFC encapsulation?  Doe it somehow mark the
sessions to ensure the streams as it goes through service chains is
following the chain for that specific service and instance of that service
that might be tenant specific?  I'd like to see some language added on this
topic.

> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I agree with Barry, Alissa, and maybe others that a wiki may be a better
> > option, but I won't stand in the way of publication.  I do think the
> > problem SFC is working on is important and the work will be worthwhile,
> > but this draft isn't ready ready or may not need to be published.
>
> Having worked on SFC since the first BoF I strongly feel that a formal
> problem statement needs to be codified, particularly in a space that isn’t
> as familiar to many as other working groups.  As I mentioned to Alia, there
> is a clear need for the information, and to have it officially documented
> as an RFC for the rest of the WG efforts.
>
>
> >
> > There are still numerous security considerations to be included as
> > pointed out in the SecDir review and in Stephen's DISCUSS points that I
> > support.
> >
>
> We will augment the security considerations appropriately.
>
>
> > The draft mentions ordering for service functions, and it would be good
> > to see some concrete examples of how security may be an issue with
> > different options for ordering.  Since SFC's scope is a single
> > administrative domain, the service chaining could result in session
> > decryption at various points in the chain that could result in security
> > and privacy exposures within that domain (typically considered a
> > manageable risk).
>
> But this isn’t really the focus of SFC WG because that encrypt/decrypt can
> happen today using the exiting service insertion techniques.  What we are
> focused on here is how to improve service chaining technology, we don’t get
> involved in the actual services.
>

Could you add a statement to that effect, perhaps to the end of the last
sentence in Section 2.4.

Suggest change from:

Furthermore, altering the order of a

   deployed chain is complex and cumbersome.
To:

Furthermore, altering the order of a

   deployed chain is complex and cumbersome, and is therefore out-of-scope
for SFC.

>
>
> >   Functionality may be limited for some of the service
> > functions if the decryption does not happen prior to that point and risk
> > prioritization will be necessary (exposure of data, session interception,
> > corruption of data, etc. could result from this exposure) since this is
> > likely to be used in hosted environments with multiple tenants.  The
> > SecDir review did mention crossover between management/control and data
> > planes, but tenant isolation may also need to be mentioned.
> >
> > Some nits (I don't think others mentioned these, but sorry if they were
> > already addressed):
> > Section 2.1: 3rd paragraph:
> > Is this intended to mean after a new service function is added?  I can't
> > imagine that this our happen on the fly, so I think that's the case and
> > adding a word or two may help:
> > from:
> >   As more service functions are required - often with strict ordering -
> >   topology changes are needed before and after each service function is
> > added
> >   resulting in complex network changes and device configuration.
>
> Thank you, we’ll make that paragraph more specific.
>
> >
> > 4th paragraph:  I'm have trouble reading this paragraph as I think it
> > contradicts itself, but the example in the following paragraph is
> > helpful.  If topology dictates placement, how could using topology not be
> > viable?  Maybe rewording it would help:
> >   The topological coupling limits placement and selection of service
> >   functions: service functions are "fixed" in place by topology and
> >   therefore placement and service function selection taking into
> >   account network topology information is not viable.  Furthermore,
> >   altering the services traversed, or their order, based on flow
> >   direction is not possible.
> >
>
> The intent here was to convey that placement isn’t dynamic, and one
> functions are “inserted” an operator cannot easily take network information
> into account if/when things need to change or be updated.  In other words,
> the topology dictates placement, rather than the traffic.  I agree the text
> does explain it well and will clean it up.
>

In the security considerations section, the second paragraph on
Classification uses the term "pervasive encryption", where I think you just
mean encryption.  One might use encryption to protect against pervasive
monitoring and we can hope that encryption becomes pervasive one day but
the meaning wound't be what was intended below.

From:

The use of pervasive encryption varies based on type of traffic,
      environment and level of operator control.

To:

The use of encryption varies based on type of traffic,

      environment and level of operator control.

> > Thanks,
> > Kathleen
> Thanks again!
> Paul

Thank you!

-- 

Best regards,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Feb 2015 18:35:29 -0500

I am not sure I understand what the question is about tenant isolation.

Multi-tenant support can be provided in many ways.  You can have a 
service chain per tenant.  You can have tenant IDs in the metadata, use 
common chains, and separate things on the far end.  And there are 
probably more ways.

is there something in the problem statement that leads you to expect 
this problem to be addressed?  Even the architecture does not address 
this.  In fact, as far as I can tell the encapsulation is unlikely to 
deal directly with this, as it is a solution property, not an 
architectural or protocol property.

Sorry if I am being obtuse.
Yours,
Joel

On 2/13/15 4:44 PM, Kathleen Moriarty wrote:
> Hi Paul,
>
> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Kathleen,
>
>     > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     >
> following the chain for that specific service and instance of that
> service that might be tenant specific?  I'd like to see some language
> added on this topic.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Feb 2015 18:50:02 -0500

On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern <[email-masked]>
wrote:

> Multi-tenant support can be provided in many ways.  You can have a service
> chain per tenant.  You can have tenant IDs in the metadata, use common
> chains, and separate things on the far end.  And there are probably more
> ways.
>

Sure, I'd just like to see a little more text on that.  Tenants are
mentioned in the introduction (1st paragraph), then the term doesn't appear
again.

   The delivery of end-to-end services often require various service
   functions including traditional network service functions (for
   example firewalls and server load balancers), as well as application-
   specific features such as http header manipulation.  Service
   functions may be delivered within the context of an isolated user
   (e.g. a tenant), or shared amongst many users/user groups.

> is there something in the problem statement that leads you to expect this
> problem to be addressed?  Even the architecture does not address this.  In
> fact, as far as I can tell the encapsulation is unlikely to deal directly
> with this, as it is a solution property, not an architectural or protocol
> property.
>
> If it's inherently addressed, it would be good to have an idea of how it
is addressed in this problem statement.  I suspect that is the case and
would like to know how you establish an isolated user and perhaps say that
this is not part of the problem if it's been solved.  Maybe it's through
the encapsulation.  Linda responded with some thoughts on markings for
sessions, which makes sense.  The solutions may not need to talk about it
at all if laid out correctly in this draft, which I suspect is the case.

Thank you,
Kathleen

>> [email-masked]

-- 

Best regards,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Feb 2015 19:43:41 -0500

My first reaction is to suggest removing the last sentence you quote.  I 
don't think it matters.  The reason I say that is that from what I 
understand, tenant isolation is not an important part of the problem / 
driver for the SFC work.  Rather, the SFC work can be used to provide 
tenant isolation if folks choose to do so.

Having said that, I will leave it to the chairs and authors.

Yours,
Joel

On 2/13/15 6:50 PM, Kathleen Moriarty wrote:
>
>
> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     service chain per tenant.  You can have tenant IDs in the metadata,
>     use common chains, and separate things on the far end.  And there
>     are probably more ways.
>
>
> mentioned in the introduction (1st paragraph), then the term doesn't
> appear again.
>
>     this problem to be addressed?  Even the architecture does not
>     address this.  In fact, as far as I can tell the encapsulation is
>     unlikely to deal directly with this, as it is a solution property,
>     not an architectural or protocol property.
>
> would like to know how you establish an isolated user and perhaps say
> that this is not part of the problem if it's been solved.  Maybe it's
> through the encapsulation.  Linda responded with some thoughts on
> markings for sessions, which makes sense.  The solutions may not need to
> talk about it at all if laid out correctly in this draft, which I
> suspect is the case.
>
> Thank you,
> Kathleen
>
>         On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq)
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Hi Kathleen,
>
>              We are working my way through the IESG comments, thanks for
>         sending
>              yours!
>
>
>              > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty
>         <[email-masked]
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>              >
>              >
>              >
>         ------------------------------__------------------------------__----------
>              > DISCUSS:
>              >
>         ------------------------------__------------------------------__----------
>              >

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Feb 2015 21:32:09 -0500

Hi Joel,

Sent from my iPhone

> On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> My first reaction is to suggest removing the last sentence you quote.  I don't think it matters.  The reason I say that is that from what I understand, tenant isolation is not an important part of the problem / driver for the SFC work.  Rather, the SFC work can be used to provide tenant isolation if folks choose to do so.

That may be fine, but I'd like to understand why it's not a problem in this discussion first.

Thanks,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Feb 2015 23:50:46 -0500

For me, the question is which of the following two questions the 
document is trying to address:

1) What problems are driving and prompting the effort.  This is 
generally about problems with current tools and techniques.

2) What problems are likely to come up during the effort, and need to be 
solved.  This would include architectural issues, protocol design 
constraints, and deployment issues.

I have generally understood working group problem statements to be 
addressing the first question.  It seems that you are looking for a 
document that covers the second question.  While the two are related, 
they seem to me to not be the same.  Differing understandings of the 
charter goal will make for rather different expectations of the content 
of the document.

Yours,
Joel

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 14 Feb 2015 10:26:33 -0500

Hi Joel,

Sent from my iPhone

> On Feb 13, 2015, at 11:50 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> For me, the question is which of the following two questions the document is trying to address:
> 
> 1) What problems are driving and prompting the effort.  This is generally about problems with current tools and techniques.
> 
> 2) What problems are likely to come up during the effort, and need to be solved.  This would include architectural issues, protocol design constraints, and deployment issues.
> 
> I have generally understood working group problem statements to be addressing the first question.  It seems that you are looking for a document that covers the second question.  

Nope, just looking for an answer to my question to understand scope.  

> While the two are related, they seem to me to not be the same.  Differing understandings of the charter goal will make for rather different expectations of the content of the document.

Whether or not it goes in the draft, I'd like to understand what the problem statement covers, what is in scope or out of scope and to understand why.  It would help to just get an answer to my discuss question whether or not it goes in the draft.  Talking around it doesn't help me understand why this does or doesn't belong in the draft.  The problem statement covers service chaining through shared infrastructure.  If you are deciding how to direct traffic through service chains, I think my question is a fair one and I'd love to get an answer.  If it's not in scope, it should be clear why it's not in the draft.

Thank you,
Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 14 Feb 2015 11:58:20 -0500

That is a very fair request.  If one of the authors does not get to it 
soon, I will send my take on an answer later today.
Thank you,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Sat, 14 Feb 2015 17:32:13 +0000

I'm on it :). Might be Monday though. 

> On Feb 14, 2015, at 11:59 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> That is a very fair request.  If one of the authors does not get to it soon, I will send my take on an answer later today.
> Thank you,
> Joel
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Xuxiaohu <[email-masked]>
Date: Sun, 15 Feb 2015 10:13:34 +0000

Hi Joel,

You have raised a very interesting point. In the MPLS/BGP IP VPN case, if we choose to contain tenant ID in the metadata and use common chains identified by the NSH, where should the egress PE's address and the VPN label assigned by the PE address be located in the data packet if the NSH is imposed on the original IP packet (i.e., customer packet)? Otherwise, if the NSH is imposed on the encapsulated VPN packet (e.g., IP-in-MPLS-in-GRE-in-IP), should the intermediate SFFs or SFs be capable of decapsulating the encapsulated VPN packet?

Best regards,
Xiaohu

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Saturday, February 14, 2015 7:35 AM
> To: Kathleen Moriarty
> Cc: [email-masked]; [email-masked];
> [email-masked]; The IESG
> Subject: Re: [sfc] Kathleen Moriarty's Discuss on
> draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT)
> 
> chain per tenant.  You can have tenant IDs in the metadata, use common chains,
> and separate things on the far end.  And there are probably more ways.
> 
> fact, as far as I can tell the encapsulation is unlikely to deal directly with this, as it
> is a solution property, not an architectural or protocol property.
> 
> <[email-masked]
> > Is this problem addressed by SFC encapsulation?  Doe it somehow mark
> > the sessions to ensure the streams as it goes through service chains
> > is following the chain for that specific service and instance of that

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 16 Feb 2015 07:56:09 -0500

I agree. Like any other networking technology, it can be associated with a tenant but that is really unrelated to the tech. 

	--Tom

> On Feb 13, 2015:7:43 PM, at 7:43 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 16 Feb 2015 07:57:47 -0500

The text says that it "can" be provided in many ways. It does not say that it is intrinsic to the tech.  All that its saying is that you can do this if you want, and that is perhaps something people might want to do.

	--Tom

> On Feb 13, 2015:9:32 PM, at 9:32 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Joel,
> 
> Sent from my iPhone
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 16 Feb 2015 14:52:12 +0000

Hi,

In general SFC doesn’t change the security posture wrt tenancy, so I tend to agree with Joel: let’s remove the sentence that add confusion.

There’s no implication that the SFC encap will provide tenant information or isolation (although in many cases I suspect it might carry some form of tenant ID).  If there’s a need for transport isolation, then the network transport must provide it, as it must today.  

If the WG agrees, I’m fine with a simple clarifying statement, something along the lines of

“If tenant isolation is required in an SFC deployment, an appropriate network transport overlay that provides adequate isolation and identification can be used.  Additionally, tenancy might be used in the selection of the appropriate service chain, however, as stated, the network overlay is still required to provide transport isolation.  SF deployment and how specific SFs might or might not be allocated per tenant is outside the scope of this document."

> On Feb 13, 2015, at 7:43 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Feb 2015 10:02:11 -0500

Paul,

On Mon, Feb 16, 2015 at 9:52 AM, Paul Quinn (paulq) <[email-masked]> wrote:

> Hi,
>
> In general SFC doesn’t change the security posture wrt tenancy, so I tend
> to agree with Joel: let’s remove the sentence that add confusion.
>
> There’s no implication that the SFC encap will provide tenant information
> or isolation (although in many cases I suspect it might carry some form of
> tenant ID).  If there’s a need for transport isolation, then the network
> transport must provide it, as it must today.
>
> “If tenant isolation is required in an SFC deployment, an appropriate
> network transport overlay that provides adequate isolation and
> identification can be used.  Additionally, tenancy might be used in the
> selection of the appropriate service chain, however, as stated, the network
> overlay is still required to provide transport isolation.  SF deployment
> and how specific SFs might or might not be allocated per tenant is outside
> the scope of this document."
>

Thank you.  I think this text is very helpful to understand the scope of
the problem and what SFC will and will not address.  It's a good clarifying
statement.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ron Parker <[email-masked]>
Date: Mon, 16 Feb 2015 15:16:48 +0000

Hi, Paul.

Your proposed text looks good to me.   It is very clear about how SFC deals with tenancy and isolation issues.

Kathleen, this was a very useful discussion.   Thanks for bringing it up.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Monday, February 16, 2015 9:52 AM
To: Joel M. Halpern
Cc: Kathleen Moriarty; [email-masked]; [email-masked]; [email-masked]; The IESG
Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT)

Hi,

>> If it's inherently addressed, it would be good to have an idea of how 
>> it is addressed in this problem statement.  I suspect that is the 
>> case and would like to know how you establish an isolated user and 
>> perhaps say that this is not part of the problem if it's been solved.  
>> Maybe it's through the encapsulation.  Linda responded with some 
>> thoughts on markings for sessions, which makes sense.  The solutions 
>> may not need to talk about it at all if laid out correctly in this 
>> draft, which I suspect is the case.
>> 
>> Thank you,
>> Kathleen
>>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 16 Feb 2015 15:40:35 +0000

> On Feb 16, 2015, at 10:16 AM, Ron Parker <[email-masked]> wrote:
> 
> Hi, Paul.
> 

Thanks for the quick review!

> Kathleen, this was a very useful discussion.   Thanks for bringing it up.

Agreed, thank you.  I’ll give the list a little while to weigh in, then push a new version.

Thanks
Paul