Re: [secdir] secdir review of draft-ietf-sfc-problem-statement-10

Benjamin Kaduk <kaduk@MIT.EDU> Sat, 17 January 2015 18:39 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9771ACECF; Sat, 17 Jan 2015 10:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmLlNBzFG_K4; Sat, 17 Jan 2015 10:39:14 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62F31AC3AC; Sat, 17 Jan 2015 10:39:11 -0800 (PST)
X-AuditID: 1209190e-f799e6d000000cfe-25-54baab03db96
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.12.03326.30BAAB45; Sat, 17 Jan 2015 13:33:39 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t0HIXcAu007036; Sat, 17 Jan 2015 13:33:39 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0HIXW7Z004835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jan 2015 13:33:36 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0HIXVg0002656; Sat, 17 Jan 2015 13:33:31 -0500 (EST)
Date: Sat, 17 Jan 2015 13:33:31 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Paul Quinn (paulq)" <paulq@cisco.com>
In-Reply-To: <8C00C887-4A6A-481F-A472-6081FD4DC895@cisco.com>
Message-ID: <alpine.GSO.1.10.1501151240220.23489@multics.mit.edu>
References: <alpine.GSO.1.10.1501021718550.23489@multics.mit.edu> <8C00C887-4A6A-481F-A472-6081FD4DC895@cisco.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; boundary="-559023410-1969023811-1421344152=:23489"
Content-ID: <alpine.GSO.1.10.1501171259430.23489@multics.mit.edu>
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLKsWRmVeSWpSXmKPExsUixG6nosu8eleIwd+/VhZvv9xjt5jxZyKz xcdTb5gs9r9aymrxYeFDFouHky+xO7B5TPm9kdVjyZKfTB7npnxn9Nj6ZAm7x5fLn9kCWKO4 bFJSczLLUov07RK4MhYfEi5Y38hY0f3nP0sD46W0LkZODgkBE4n/jZcZIWwxiQv31rN1MXJx CAksZpI4O6efFcLZyChx4fdlVpAqIYFDTBIXZ0RCJBoYJRrmH2YGSbAIaEs8+PqHCcRmE1CR mPlmIxuILSKgJXH712YWkAZmgXVMEm+OfgGbJCzgKPH8MITNKWArMeHLZbBBvEDx7n1nWCC2 FUk0L5gNZosK6Eis3j+FBaJGUOLkzCdgNrNAoMSmg8uhbEeJLy2XGScwCs1CUjYLSdksJGUQ trrEgU8XoWxtifs329hgahrnbWBZwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81 pXQTIyjWOCX5djB+Pah0iFGAg1GJh5fjx84QIdbEsuLK3EOMkhxMSqK8y2fvChHiS8pPqcxI LM6ILyrNSS0+xCjBwawkwns8HSjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgm K8PBoSTBq7McqFGwKDU9tSItM6cEIc3EwQkynAdo+L9lIMOLCxJzizPTIfKnGBWlxHljQJoF QBIZpXlwvbBU+IpRHOgVYV5tkCoeYBqF634FNJgJaHD+4x0gg0sSEVJSDYzS6wRv9j5j/ppo /uoNs0bZPSP2XcmTn5jn3Ai13HY35kaNWEXp4rLbkhevrnpu6/klusYkVGZ7p60gT4bnzLNh f07PvnIkoD/2XE32jatbisKUdedcj6peXueTelTP2OdWejz3r3cztmxl3Nud9jVrS37IOZ13 a/c3eRl1yEldn7hBZbkbj40SS3FGoqEWc1FxIgDn9GHZYAMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/B7Fww8_s5b23OsAXKOTECXesd4Q>
Cc: "tnadeau@lucidvision.com" <tnadeau@lucidvision.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "draft-ietf-sfc-problem-statement.all@tools.ietf.org" <draft-ietf-sfc-problem-statement.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-sfc-problem-statement-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jan 2015 18:39:19 -0000

On Mon, 12 Jan 2015, Paul Quinn (paulq) wrote:

> Ben,
>
> Thank you for your detailed review and sorry for the delayed reply due
> to the holidays.

Understood.

> I added some comments inline below.  I’ve also cc’d our document
> shepherd, Joel, since I’m not sure he was on the original distribution.

Thanks.  I'll reply inline and trim unneeded bits...

> > On Jan 2, 2015, at 7:39 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> >
> > Hi all,
> >
> > Here are the potential security considerations I came up with so far:
> >
> > * An error in service classification could lead to untrusted traffic
> > flowing through a service function chain intended for trusted traffic
> > only.  In various hypothetical situations, this could lead to an attacker
> > being able to execute privileged actions via a trusted service, execute a
> > DoS attack against an internal service, etc.  It is important for service
> > classification to "fail safe" to avoid this class of issues.  ("Failing
> > safe" might or might not include just dropping such traffic.)
>
> PQ> This statement applies to all things that depend on classification,
> or configuration in general.  Perhaps a statement about “risk associated
> with configuration or other operational errors” and service chaining
> would help clarify.

Yes, it is a very broad concern.  The main point is to mention the general
concern in this document, so that it is kept in mind as more concrete
proposals are being made.  I think that the sort of statement you propose
could suffice, but would probably need to see the actual statement to be
sure.

> > * Similarly, errors in translating from an existing network/service
> > topology to a separate service overlay (e.g., omission or addition of a
> > firewall element) could lead to an attacker sending traffic in the real
> > network to services which ought to be disallowed by the service overlay.
>
> PQ>  The above suggested statement (or something similar) would cover this as well.

Yes.  There are lots of ways that traffic could end up where it's not
supposed to; my bullet points are just an attempt to enumerate some of
those ways, with the hope that being enumerated will make them less likely
to be problems in actual operation.

> > * The dataplane metadata could open up a giant rabbit hole of information
> > leakage.  It is tempting to say that the metadata would only flow inside
> > the network boundaries of a single (corporate) entity, but "SSL added and
> > removed here :-)" should convince us that that's not a workable solution.
> > Metadata could conceivably include the type of traffic, client information
> > (i.e., personally identifying information), and more, some of which should
> > receive protection from eavesdroppers on the dataplane which will not need
> > to process the traffic in question.
>
> PQ> The “value” of the metadata is highly variable, in some
> environments, as you point out, it might be sensitive.  Perhaps we can
> add the following to the security considerations sections:
>
> 1.  If data plane confidentiality or integrity is required, a transport
> that supports the requisite functionality (e.g. IPSec) should be used to
> create the service overlay.

Maybe even SHOULD?

> 2.  Similarly, control plane messages may be authenticated or encrypted,
> as required by an operator, using existing mechanisms (e.g. SSL)

It's probably better to say TLS than SSL.

I think these additions would address my concerns in this area.

> >
> > * Metadata can come from "external sources".  Those sources should be
> > trustworthy and verified, or attackers could send traffic where they
> > oughtn't be able to.
>
> PQ>  Covered by the above control plane text.

I'm not sure.  This probably just means that I don't fully understand how
the external sources would be providing metadata -- if it inherently must
flow over the control plane, then sure, it's covered by the above text.


> > Here's the grammar and language issues that bothered me, roughly sorted
> > with the more important ones coming first and otherwise in order of
> > appearance:
> >
> > Section 3 has the text "the SFC working group will [...]", which seems
> > more appropriate for a WG charter than an informational RFC.  I see this
> > had been brought up in discussion of the -03, but I did not see any
> > obvious resolution in a quick skim.  To be clear, I would be fine with
> > something that didn't explicitly say what the WG would do, like "SFC may
> > include solutions utilizing the following elements" or something similar.
>
> PQ> The complete current version states: “...will investigate solutions
> that address the following elements:..” which was widely reviewed and
> accepted the WG members.

I'm not objecting to the specific things to be done.  My point is very
close to what Barry put in his COMMENT: there's no need to publish an RFC
to say that "WG X will do thing Y" (that's what a charter is for) -- WG X
should just do thing Y.  It can, however, be useful to publish an RFC
saying that "WG X has investigated the issue and concluded that thing Y
should be done", and I would prefer that this document was worded in such
a fashion.  That is, I would prefer to replace "Concretely, the SFC
working group will investigate solutions" with "Solutions should be
investigated".  But, as for Barry, it is not my place to block the
document on this point.  I have noted that it seems weird to me, and will
not object if you go forward with it.

> > The document uses some acronyms that are not expanded.  I expect most
> > readers to be familiar with some, but not all, of:
> > * Open Systems Interconnection
> > * the OSI model, e.g., layer 3, layer 7, etc. (I had to think a moment
> > about "L4-L7")
> > * transmission control protocol
> > * Virtual Local Area Network
> > * Border Gateway Protocol
> > * internet protocol
> > * virtual private network
> > * multiprotocol label switching
> > * Wide Area Network
> > * datacenter
>
> PQ> As you point out, many of these are well known terms to readers of
> the draft, as was the case with the reviewers.

Yup.  Barry was kind enough to point out the RFC Editor's list of
acceptable acronyms
(https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt), so
there is only potential concern about the individual OSI layers and "DC"
for datacenter.  I'm sorry I didn't know about that list in advance to
save the trouble.

> > I can't find a parse that I'm happy with of the first paragraph of section
> > 3.3.  In particular, I'm not sure whether the leading "As such" is just a
> > transition leading into a new sentence (equivalent to "Thus,"), in which
> > case it should be offset by a comma, or if the "such" binds to "metadata"
> > (equiavent to "Since such").  In the first version, I guess the metadata
> > is supposed to be sent out-of-band and interpreted by functions along the
> > service overlay, but I don't see how it would then *not* be used to
> > control the route by which packets travel.  In the latter version, the
> > sentence is incomplete, since there's no dependent clause.
> >
>
> PQ> As such does not mean “thus”, thus (;-)) the sentence can read:
>
> "As such it is not used as forwarding information to deliver packets
> along the service overlay."

Okay, that is enough for me to disambiguate.  I very strongly suggest that
you put a comma after "such".

> Having said that, it’s pretty minor point, and can be fixed several ways
> if reader find it confusing/offensive:
>
> - I believe the correct use of “as such” in this context is to remove
>   the word metadata immediately following “as such”.
> - As such —> Metadata (i.e. remove as such)

Well, replacing it with "it" instead of just removing it.

That would work for me, though I think I would prefer "As such, this
metadata [...]".

I still don't see how (e.g.) antecedent classification is not used as
forwarding information for (overlay-level) packet delivery, but am willing
to take your word for it.

> > The abstract uses the phrase "ordered set of instances", but a set is
> > explicitly unordered.  Is there a better term to use, like "graph",
> > "network", or "structure"?  (The word "set" also appears in the second
> > paragraph of the abstract, but may be more appropriate in that usage.)
>
>
> PQ>  Is there not a concept of an ordered set as well?

In formal mathematics, not exactly.  If you have a full order relation for
any pair of elements, then it is just an ordered list (or sequence).  You
can also have a partial order, where any given pair of elements might not
be comparable; this sort of thing produces more interesting mathematics
because there are more possibilities than just a fully ordered list.

Anyway, this is not a formal mathematical setting, so you're probably fine
leaving it as-is; I just wanted to ask whether "graph" or "network" would
be more elucidating terms to use.  In particular, the reader (me) wants to
know if the order is a full order or a partial order -- saying that it is
a list would make clear that it is a full order, and a graph or network is
more likely to correspond to a partial order.

> > I'm not sure I'm interpreting the third paragraph of section 2.1 correctly
> > -- is the issue that the network topology needs to change in front and
> > behind of each service function, whenever a new service function is
> > required?  Or is it that the network topology must change before and after
> > a new service function is introduced, in order to allow inserting the
> > function without loss of serice?  I would also find the last sentence more
> > clear if reorderd to be "[...] all traffic often passes through the same
> > strict order, whether a given service needs to be applied or not.”
>
> PQ> In many cases, both.  But the intent here is to describe the “front”
> and “behind” issue.

Okay.  I think that is the way I interpret the current text, which is
good.  But using "front" and "behind" might make things more clear.

> > In section 2.3, I don't understand what "constrained service function high
> > availability" is.  Is the issue just that the topology forces a situation
> > which could be subject to reduced availability because certain
> > high-availability techniques are not usable in that topology?
>
> PQ>  Correct, as described in the next paragraph:
>
> "Since traffic reaches many service functions based on network
>    topology, alternate, or redundant service functions must be placed in
>    the same topology as the primary service."

It might be more clear if this was described as "constraints on" service
function high availability.  Your call.

> > The second paragraph of the abstract is hard to parse; my best effort at
> > cleaning it up is "The set of enabled service function chains reflects the
> > service offerings of a given operator, and is designed in conjunction with
> > application delivery, service, and network policy.", but I fear that has
> > changed the meaning somehow.  ("chains" needs to be plural, as does
> > "reflects", but there's also a missing article for "operator service
> > offerings", and the two "ands" in the final clause read oddly.)
>
>
> PQ> I’m not sure what is hard to parse, it seemed well understood by the
> WG members.

Since WG members are (apparently) the main audience for this document I
should probably leave it alone, then.  Well, I would still
s/reflect/reflects/ to get singular/plural agreement.  Looking at it
again, I think most of what confused me was the "X and Y and Z" construct,
for which I may not have picked the right grouping the first time around.

> > The definition for "classification" doesn't seem grammatical.  Perhaps,
> > "Locally instantiated policy to match traffic flows to the appropriate
> > outbound action(s)"?  Additionally, should the definition be explicitly
> > constrained to just forwarding actions (my proposal is not)?
>
> PQ> This is the definition that WG come up with after several rounds off
> back and forth (it’s used in other SFC drafts).  We tried to keep it
> generic, rather than constrained.

I think the main thing that feels odd to me is that the subject of the
sentence (in a sentence classification sense) is the policy, whereas I
would naively expect the matching to be the main thing involved in
classification.  The naive resolution to this issue would be to reorder
things, as "Matching of traffic flows as a result of locally instantiated
policy for identification of appropriate outbound forwarding actions".
This does not trip my "feels weird" sense, so I think I have found the
precise nature of my concern.  I understand that the WG spent a lot of
time coming up with this definition, so I won't insist on any changes; I
will just note that there are potential grammar issues with it.

> > In the definition for "service function", is "One of" needed?  Also,
> > s/the Service Function/a Service Function/ in the last sentence of the
> > first paragraph.  In the second paragraph, there's no need to say "etc."
> > when prefaced with "includes:" -- just say "and TCP optimization" (note
> > s/optimizer/optimization/ for tense consistency).
>
> PQ> Did you mean “One or”?  If so, then yes.

I did not mean "One or".  I refer to the sentence "One of multiple Service
Functions can be embedded in the same network element."  I do not see an
occurrence of "One or" in the definition of "Service Function".  Ah,
perhaps this is just a typo; that sentence does make more sense with "One
or" instead of "One of" (but "more" is I think more common than "multiple"
to follow it in this usage).

> > The definition for "Service Function Chain" is ... odd.  I believe that
> > "their ordering requirements" refers to the ordering of service functions

This is actually "their ordering constraints"; I'm not sure how I
mistranscribed it.

> > within the chain, but "their ordering requirements that must be applied to
> > packets" actually reads that the ordering requirements come from the set
> > of service functions but is applied to the packets and/or frames.  I would
> > probably try to instead say something about "the constraints on the order
> > in which service functions are applied to packets and/or frames".
> > Additionally, "linear progression" is a bit vague; is the intention just
> > to say that it may allow branching and need not be a complete/strict
> > ordering (i.e., it could be a partial order)?
>
> PQ>  This oddness can be quickly resolved I think:
>
>       A service Function chain defines an abstract set of service functions
>       and associated ordering constraints
>       that must be applied to packets and/or frames selected as a result
>       of classification.

That's an improvement, yes.  It might be possible to do better, but it's
probably not worth the time.

> As for the linear sentence, yes, it is to simply convey that there maybe
> a non-linear sequence of functions.

Okay.

> > In the fourth paragraph of section 2.1, I'm failing to interpret the
> > phrase "placement and service function selection taking into account
> > network topology information is not viable."  Is it adding anything that
> > is not said prior to the colon in that sentence?
>
> PQ>  There is some redundancy there that can be cleaned up.

Okay.

> PQ>  We’ll go through the corrections above and clean things as needed.

Sure.


Thanks for picking up these changes, and helping me resolve my confusion.

Sorry it took so long to get back to you.

-Ben