Subject: [sfc] Stephen Farrell's No Objection on draft-ietf-sfc-architecture-11: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Fri, 31 Jul 2015 07:13:54 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-sfc-architecture-11: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

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

Thanks for the extensive discussion about the security aspects
of this architecture. I think in -11 we've probably gotten as far
as we're likely to agree upon in terms of addressing those (which
is far enough for me to change from a discuss to a no-objection
ballot) and we can work further on the topic as specific protocols 
that adhere to this architecture emerge.

I didn't check if the (non-blocking) comments below were
taken into account or not in -11. If we need to chat about 
any of them feel to ping me.

OLD COMMENTS BELOW

- It occurs to me that it might really be better for the WG
to not publish this as an RFC now, but rather to put it on
hold until they've made progress on the solutions. Perhaps
revistiting this when the solutions are just at WGLC would
result in the eventual RFC being a much more useful document.
I think this one has to hedge so many bets that it's quite
vague and won't be very useful even in the medium term. But
that's just a suggestion, I can see why the WG might prefer
to push this out, even if that might only give the appearance
of progress and not reflect real progress.

- While IPR on an architecture document is sad to see, esp
with what seems like it may be restrictive licensing, I do
see the wg debated that and decided to move on.

- The charter text describing this deliverable notes that
"The initial scope is restricted to a single administrative
domain, keeping in mind that architectural decisions made for
the intra-domain case may have implications for the
inter-domain case." So I think there is also a currently
missing analysis (or the results of that) as to how the
single-domain elements of this architecture might impinge on
a later inter-domain architecture. So the text at the 
end of section 1.1 appears to contradict the chartered 
goals.

- Chains will require some representation, and re-ordering
that is security sensitive (e.g. swap order of f/w and nat
for fun) therefore there must be a requirement for some data
integrity service and origin authentication and an
authorisation decision function and therefore there must
(istm) be a need for the architecture to define a chain
producing entity of some kind that could be authenticated.
That is an example of the missing security analysis that
really is needed before this proceeds. (See my discuss point
2)

- 1.1: "classified on ingress" and applicable to mobile
networks are slightly incongrous. In the case of WiFi when do
the packet ingress? (When it gets to the AP or leaves the
mobile node transmitter?) I suspect you really mean the wired
bits of a mobile network so it might be better to say that.

- 1.2 should follow 1.3 I think.

- 1.2: What does "chaining logic" mean? You say there's no
standard chaining logic, which is maybe right, but then you
imply that a fully ordered set of SF's is a well defined
thing. I'm not sure that makes sense. Perhaps what you want
to say is that the architecture doesn't determine if an SFC
{{A,B},C} is or is not the same as {{B,A},C} but that later
protocol work will have to do that. (In fact, I think you
could say a lot more here and probably should.)

- 1.2: what is a "chaining policy"? Isn't here where those
terms need to be defined.

- 1.3: SFC definition: by ordered do you mean fully or
partially ordered?

- 1.3: I'd omit LI as a SF - we won't be standardising that
(cf. RFC2804) so better to not drag in the controversy
really. Similarly, HOST_ID injection is not afaik any kind of
standard and perhaps not likely to be (cf. some confict
reviews on the same telechat as this) so I'd also drop that.
And I think all of the exemplar SF's should really have a
reference (ideally an RFC).

- Figure 1 caption is misleading. That seems to me to show a
set of paths through (one or more) graphs but doesn't show
the full graphs themselves.

- 2.2: The concept of a bi-directional SFC seems odd.  Does
the example given imply that all traffic (of what kind?) that
followed SF1->SF2->SF3 on the way "in" must follow
SF3->SF2->SF1 on the way "out"? If so, then I think more
precision is needed really. The hybrid concept seems even
odder to me.

- 2.3: How can an SFP "be vague" - surely the point of an
architecture is to avoid such vagueness? If you mean that an
SFP representation can embody an if-statement then saying
that would be the thing to do.

- Section 3: I think there's maybe a missing principle here
about not making security and privacy worse in general.

- 4.1: I wonder if one could ever get enough SFC control
traffic that congestion would be an issue?  If so, should you
say rather that any transport that has some way of handling
congestion is ok. If not, then I guess the current text is
fine.