Subject: [sfc] Kathleen Moriarty's No Objection on draft-ietf-sfc-problem-statement-12: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 17 Feb 2015 15:37:54 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-problem-statement-12: No Objection

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/

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

Thanks for addressing my question on multi-tenancy and adding in text to
describe how that could be handled.

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: Alia Atlas <[email-masked]>
Date: Tue, 17 Feb 2015 23:00:57 -0500

Paul,

Have you looked at and considered Kathleen's comments?

Thanks for the hard work so far,
Alia

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 18 Feb 2015 20:35:48 +0000

Alia,

Yes, they were largely addressed in the previous rev.  Specific comments below.

Thanks!
Paul

On Feb 17, 2015, at 11:00 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Paul,

On Tue, Feb 17, 2015 at 6:37 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-sfc-problem-statement-12: No Objection

----------------------------------------------------------------------
COMMENT:
———————————————————————————————————

<trimmed>

PQ>  draft clarifies “front” vs “behind” to make this clear.

PQ>  I believe that a clarification was added about network topology information.