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

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 07 Jan 2015 12:58:41 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-problem-statement-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/

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

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

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.

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).   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.  

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.

Thanks,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 8 Jan 2015 16:23:57 +0000

Kathleen, 

-----Original Message-----

DISCUSS:

I didn't see any mention of risks with multiple tenants and shared infrastructure for service functions, is that a concern?  

[Linda]Same as VPN service where VPN ID is used to differentiate traffic from different tenants,  when one Service Function applies treatment to traffic from different tenants, some identifiers in packet header fields, e.g. SFC ID, VLAN/MPLS/etc in the header field, can be used to differentiate the tenants. 

If tenants need more stringent separation, different instances of the Service Function have to be used (or instantiated for those tenants). 

Linda

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.

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.   

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.

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).   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.  

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:

Thanks,
Kathleen

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

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 13 Jan 2015 14:11:45 +0000

Hi Kathleen,

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

Please see inline.

Paul

> On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 

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.

> pointed out in the SecDir review and in Stephen's DISCUSS points that I

We will augment the security considerations appropriately.

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

>   Functionality may be limited for some of the service

Thank you, we’ll make that paragraph more specific.

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

> Kathleen

Thanks again!
Paul