Subject: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 28 May 2015 05:52:59 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-sfc-architecture-08: 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 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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I note the charter calls for this deliverable to "provide
a description of... security models" The charter also
generally notes that "The SFC WG will closely consider and
address the management and security implications when
documenting these deliverables." My conclusion is that this
deliverable needs to reflect the results of a security
analysis that the wg are suppoed to have carried out but that
it's currently too vague only saying that solutions need to
consider this. (Essentially this is a continuation of the
mail threads from the secdir review [1] and a satisfactory
resolution of that will probably resolve this.)

   [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html

(2) Metadata that contains information that is protected in
the data plane SHOULD be equally well protected when passed
about by SFC. I hope that's acceptable and documented. I'm
not sure myself if "passed about" ought also include within a
device but maybe it should really.  But at minimum, I do
think you need to define confidentiality and origin
authentication services for SFC metadata and/or for the SFC
encapsulation as a whole. And I think this architecture
document needs to say that those services have to be
well-defined as part of any solution. (And I am not
saying that this draft needs to define how to do those.)

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 10:03:31 -0400

I am not sure what you mean by "Metadata that contains information that 
is protected in the data plane".  Most of what ends up in the metadata 
is information that is passed on other interfaces directly to relevant 
functions, or locally determine and locally processed.

The protection used for policy systems (which provide much of the 
information) is based on the presence of persistent connections and 
usage which crosses domains.  Are you arguing that if AAA is encrypted 
then policy delivered by AAA resulting in metadata in the packet must be 
encrypted in the data packets?

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 15:35:41 +0100

> functions, or locally determine and locally processed.

So what I had in mind were things like the following.

- Packet is sent along a SFP A,B,C
- B to C link is via say a TLS VPN
- Metadata is created at A and is in the SFC encapsulation
  and not protected by the VPN
- That seems bad

S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 10:38:52 -0400

IF A, B, and C are service function forwarders (SFF), with a TLS 
protected link for SFC, then the metadata will be protected.  (Such a 
link would be a transport mechanism, which SFC does not describe or 
mandate.  The SFC architecture is transport agnostic.)

If A, B, and C are service functions used by SFC, then there is no link 
between B and C, so it can't be protected by TLS.

So I can not see what more needs to be said?

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 16:47:14 +0000

Stephen,

> On May 28, 2015, at 10:38 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> IF A, B, and C are service function forwarders (SFF), with a TLS protected link for SFC, then the metadata will be protected.  (Such a link would be a transport mechanism, which SFC does not describe or mandate.  The SFC architecture is transport agnostic.)
> 

Further to this point, the “Service Overlay” section of the “Security Considerations” already covers this (see last sentence).

The example below would equally protect the metadata created at A as the payload.

Thanks,

— Carlos.

> If A, B, and C are service functions used by SFC, then there is no link between B and C, so it can't be protected by TLS.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 18:05:27 +0100

Hiya,

I have to say I'm not understanding either your or Joel's responses
here but I'll look at it again later on (don't have time now).

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 21:35:09 +0100

> mandate.  The SFC architecture is transport agnostic.)

Ah, no the scenario I was thinking about is where, from
the perspective of SFC, the TLS packets are the payload
that is encapsulated. I guess A, B and C could be mail
servers with starttls only turned on between B and C
because that link is "external" (though within the same
administrative domain). If some SFC thing at A were to
dive into the SMTP traffic and pull out sensitive meta0
data then we wouldn't want that sent in clear from B to C
because of the SFC encapsulation, right?

S.

>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 28 May 2015 16:44:39 -0400

That case would not occur within a service chain.
A service chain is about delivery of a packet to a series of services to 
which it is not addressed  (generally followed by delivery to the target 
to which it is addressed.)
An SMTP server relaying email produces separate packets.  The packets 
from the user to the SMTP server are on one chain.  The packets from 
that server to another are completely separate, and on a different 
chain.  As such, those TLS SMTP packets between the servers would not 
have any metadata from the first transfer.

Mail servers are not SFC service functions.  The only time it gets close 
is when you are doing port 25 redirection, and then the service chain 
ends at the mail server.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 21:56:47 +0100

Joel,

If you are asserting that SFC cannot be used in a manner that
has the problem I was trying to exemplify then I have to say,
I'm skeptical. I also note that so-called HTTP "enrichment"
is one of the examples cited in the arch draft, and there's
not much difference between that and email from the relevant
perspective.

I also hope that I've succeeded in explaining the problem as
I see it. If not please ask and I'll try some more to clarify.
(Since you did not ask that, I assume you do get what I mean,
but it would be helpful if you would acknowledge that so we
can communicate more easily.)

Can you point me at some piece of text in some draft that
ensures that this problem cannot occur? If not, (which I
think is the case), wouldn't we be better off acknowledging
that it is an issue and one that needs to be tackled as
best we can, as indeed Alia's earlier mail seems (to me)
to suggest?

Thanks,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 17:18:21 -0400

While SMTP servers are a bad example, service chaining can be use with 
HTTP inserted (quasi-trasnparent) proxies or TCP optimizers.  Both of 
those terminate connections and create new packets.  As such, the two 
sides of such devices are on separate service chains.  In order for the 
two sides to be on the same chain, the service function would have to 
copy the service chaining and related metadata from one side to the 
other.  I can't stop them from doing so, but in most cases it would be 
misleading.

What we have done is to recognize that these are generally different 
service chains.  Because the packets will get different treatments.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 22:24:53 +0100

Joel,

I'm afraid you've lost me again, but since it's now time for
me to go to the pub, that's fine:-)

For me the important thing is if meta-data is inserted at A and
then packets are encrypted by something between B and C, then
we do not want cleartext meta-data attached to the ciphertext
sent from B to C to always have to risk making the encryption
pointless.

To me, that means that this architecture needs to call for the
existence of a confidentiality service that can be used to
protect at least the meta-data. (And it could protect more too
I guess but the details would be for the WG to figure later.)

I think additional scenarios can similarly justify a need for
the definition of a data origin authentication service.

If we agreed about that and could move on to how that ought be
expressed in the arch document, that'd be great. (But as I'll
be in the pub, I won't find out 'till tomorrow:-)

Cheers,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 17:28:19 -0400

Enjoy the pub.

No, I do not agree.  I do not see that the archtiecture needs to mandate 
a confidentiality service to protect the meta-data.  The data can only 
leak across the kind of boundary you describe if the service function 
chooses to leak it.  Given taht it will have to have access to the meta 
data, no confidentiality mechanism will prevent that.

Note that the encrypted packet produced by the service function is 
addressed to some end point.  I am failing to see how the problem you 
are asking us to address could arise.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 09:05:32 +0100

Joel,

> Enjoy the pub.

I did, of course:-)

> a confidentiality service to protect the meta-data.  

I'm sorry but that's just unhelpful. I did not speak of mandating
and doing so is simply to introduce a distracting negative ambiguity.

I am discussing whether the architecture should call for a protocol
solution that has a well-defined way to provide confidentiality and
data origin authentication. Whether and when that may, should or
must be used is not a part of the architecture.

It will help the discussion if you are similarly precise. It will
IMO prove really hard to resolve the discussion if such ambiguities
are constantly introduced. (I have seen the same in response to the
secdir review where their suggestion that X be defined is met with
an objection to X being forced to be used all the time.)

> The data can only
> chooses to leak it.  

Rubbish. If the protocol solution provides no confidentiality
service for meta-data then the leakage is inevitable as there
will be no possible alternative.

Yes a bad actor deploying can always leak, we are here considering
how to enable good actors to do the right thing.

> Given taht it will have to have access to the meta

Frankly, ISTM that you are doing more than that. My impression is
that you are opposed to defining a confidentiality service. I would
be happy to be corrected in that.

I do understand that calling for a confidentiality service does
not mean that it will be easy to define a useful confidentiality
service. I am quite sure that the IETF could muck that up as we
have done in the past (e.g. with SIP & S/MIME) but I am equally
sure we could also succeed, and I think we should try and indeed
our BCPs call for us to do just that, once we recognise there is
a need for such a service. And that last is, I think, entirely
clear.

S.

>>>>>>>>>> email addresses included in the To and CC lines. (Feel free to
>>>>>>>>>> cut
>>>>>>>>>> this

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 May 2015 10:28:40 -0400

Would you consider the following sentence pair that Carlos and I have 
been debating to be helpful:

“some protocols may optionally include confidentiality provisions for 
metadata and service function path identity, which may be used in some 
deployments. The architecture does not mandate such function.“

?
Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 15:34:31 +0100

> deployments. The architecture does not mandate such function.“

Not really no. I think that says nothing at all while at the same
time having the ambiguity around the term "mandate" that I pointed
out below.

I have no clue why the SFC architecture cannot simply say that
a confidentiality service needs to be defined.

S.

>>>>>>>>>>> I am not sure what you mean by "Metadata that contains
>>>>>>>>>>> information
>>>>>>>>>>> that

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 29 May 2015 11:09:29 -0400

I am not sure I like the following, but to try to move this forward, would

Protocols addressing this architecture need to include definitions for 
how security services are provided with that solution, although 
implementation of such mechanisms may be optional.

work for you?
Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 16:22:56 +0100

Hiya,

> implementation of such mechanisms may be optional.

Sorry, I'm really not at all sure that's a good idea as I suspect
it has too high a liklihood that those who want to see such work
done, and those who don't, both read it and are not unhappy;-)

I'm not interested in trying to force the SFC WG to define some
mythical security that never gets implemented really so I think
maybe we'll be better off if we do enough of the analysis now(ish)
to know that the architecture can say "protocols need to
define a confidentiality service that can protect meta-data
and a data-origin authentication services that can protect the
SFC encapsulation." I do think that may need a bit more work
though before one would be happy to put it out in the RFC.
And one possible outcome of that work could be that it says
instead "we know we do really need a confidentiality service
but we can't see how that's practical right now" if that is
in fact the case. (Which is possible, since these middle to
middle confidentiality things are v. hard to do.)

BTW - is there a reason to want this document to proceed to
be an RFC very quickly? If so, be good to know. If not, then
we don't need to rush to a compromise that we might all be
sad about later.

S.

>>>>>>>>>>> If A, B, and C are service functions used by SFC, then there
>>>>>>>>>>> is no
>>>>>>>>>>> link
>>>>>>>>>>>>> information) is based on the presence of persistent
>>>>>>>>>>>>> connections
>>>>>>>>>>>>> and
>>>>>>>>>>>>> then policy delivered by AAA resulting in metadata in the
>>>>>>>>>>>>> packet
>>>>>>>>>>>>> must be
>>>>>>>>>>>>>> When responding, please keep the subject line intact and
>>>>>>>>>>>>>> reply
>>>>>>>>>>>>>> to all

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 May 2015 11:27:46 -0400

Hi,

Sent from my iPhone

> On May 29, 2015, at 11:22 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I agree with Stephen.  His wording is more direct and to the point.

Kathleen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 May 2015 11:50:36 -0400

The document is a deliverable milestone intended to frame agreements 
which will then guide the protocol design process.  The protocol process 
is going to try to move quickly.  So we want this done, and argument 
resolved, ASAP.

Would:

Protocols addressing this architecture must include mechanisms to 
provide confidentiality and integrity of metadata carried by the 
protocol, although implementation of such mechanisms may be optional.

be any better?  I don't want to include data origin authentication 
because that would require separate protection for each piece of 
metadata (as they may come from separate sources).  We already have size 
concerns with this whole mechanism.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 29 May 2015 17:38:38 +0000

Stephen, (and Kathleen, as this relates to the heart of your concern as well),

Would that proposal below be the actionable middle-ground satisfying your concerns? I would actually tweak a bit to say:

“Protocols addressing this architecture must include adjunct mechanisms to provide confidentiality and integrity of metadata carried by the protocol, although implementation of such mechanisms may be optional.”

Please let us know — thanks,

— Carlos.

> On May 29, 2015, at 11:50 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> The document is a deliverable milestone intended to frame agreements which will then guide the protocol design process.  The protocol process is going to try to move quickly.  So we want this done, and argument resolved, ASAP.
> 
> Would:
> 
> Protocols addressing this architecture must include mechanisms to provide confidentiality and integrity of metadata carried by the protocol, although implementation of such mechanisms may be optional.
> 
> be any better?  I don't want to include data origin authentication because that would require separate protection for each piece of metadata (as they may come from separate sources).  We already have size concerns with this whole mechanism.
> 
> Yours,
> Joel
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 May 2015 13:41:15 -0400

Alia's text helps with my concern.  Let's keep this to Stephen's discuss points that I support.

Thank you,
Kathleen 

Sent from my iPhone

> On May 29, 2015, at 1:38 PM, "Carlos Pignataro (cpignata)" <[email-masked]> wrote:
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 29 May 2015 17:47:42 +0000

> On May 29, 2015, at 1:41 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Alia's text helps with my concern.

We believe Alia’s text is mostly redundant and too verbose, resulting in a low SNR.

Let’s go back to your DISCUSS to understand your concern again… although I feel we are starting to go in circles...

“1. The Security Considerations section only talks about privacy of the SFC
information for classification.  The more important point may be the privacy of
any data gathered from a payload used for the classification and this needs to
be mentioned.”

The text that Alia provided seems to be covered by the second sentence of the existing text here, and so does the information derived from classification into metadata:

   SFC Encapsulation:  The SFC Encapsulation provides at a minimum SFP
        identification, and carries metadata.  An operator may consider
        the SFC Metadata as sensitive.  From a privacy perspective, a
        user may be concerned about the operator revealing data about
        (and not belonging to) the customer.  Therefore, solutions
        should consider whether there is a risk of sensitive information
        slipping out of the operators control.  Issues of information
        exposure should also consider flow analysis.

What’s missing again?

Thank you,

— Carlos.

>  Let's keep this to Stephen's discuss points that I support.
> 
> Thank you,
> Kathleen
> 
> Sent from my iPhone
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 22:20:18 +0100

> concerns with this whole mechanism.

I'd need to think a bit about origin-auth vs. (presumably)
hob-by-hop integrity (maybe via AEAD), but it's a good
question.

Has someone done an analysis on the relevant threats?

S.

>>>>>>>>> sides of such devices are on separate service chains.  In order
>>>>>>>>> for
>>>>>>>>> the
>>>>>>>>>>> which it is not addressed  (generally followed by delivery to
>>>>>>>>>>> the
>>>>>>>>>>> target
>>>>>>>>>>> chain.  As such, those TLS SMTP packets between the servers
>>>>>>>>>>> would
>>>>>>>>>>> not
>>>>>>>>>>> Mail servers are not SFC service functions.  The only time it
>>>>>>>>>>> gets
>>>>>>>>>>> close
>>>>>>>>>>>>>>> is protected in the data plane".  Most of what ends up in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> metadata
>>>>>>>>>>>>>>> is information that is passed on other interfaces
>>>>>>>>>>>>>>> directly to
>>>>>>>>>>>>>>> relevant
>>>>>>>>>>>>>>> The protection used for policy systems (which provide
>>>>>>>>>>>>>>> much of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> The document, along with other ballot positions, can be
>>>>>>>>>>>>>>>> found
>>>>>>>>>>>>>>>> here: