Re: [secdir] Review of draft-ietf-sfc-architecture-08

[Benjamin Kaduk <[e-mail]>]

Hi Carlos,

On Tue, 26 May 2015, Carlos Pignataro (cpignata) wrote:

> > On May 25, 2015, at 11:01 PM, Benjamin Kaduk <[e-mail]> wrote:
> >
> > insist that encryption always be used, but please do not claim that being
> > in a single administrative domain excuses the operator from considering
> > whether encryption is necessary.
> >
>
> My point was a different one: that SFC does not change these
> requirements.
>
> I may have misunderstood, but what I read in Simon's review (admittedly
> oversimplified) was: in SFC you move services from on-network-path
> (which, as an aside, is really the other way around; it is moving from
> creating an on-network-path steering of network topology through the
> service) to a machine ‘elsewhere' — and thus, consequently, you have to
> encrypt.

I do not think anyone is saying "you must encrypt".

My take of the key point is that SFC is (potentially) going to be making
the actual physical flow of data very different from how it currently is,
and potentially also divorced from the conceptual topology of the service
function chain (if the service functions are laid out "strangely" compared
to the physical topology).  This has the potential to drastically change
the security issues an operator deploying things has to consider, and an
architecture document should point out that both protocol designers
implementing the architecture and operators using such protocols should be
aware of the new security environment.  Thus, we are proposing that it is
mandatory for protocol designers and operators to consider whether they
should be encrypting, but not mandatory for them to encrypt (if they are
satisfied with their topology).

> My point is that the logic above (which, again, I may have
> misunderstood) does not follow.
>
> There may be additional security and privacy considerations needed in
> the DC, in mobile networks, etc. However, the SFC architecture does not
> change that, and mandating encryption on SFCs might not be the right
> answer. As we wrote, the solution realizing the architecture need to
> perform part of that analysis.

I think that the SFC architecture does have the potential to change where
additional security and privacy considerations are needed.  There can
definitely be security and privacy considerations within a single
administrative domain, and I do not think the current document has
sufficient acknowledgement of the potential for the new architecture to
require drastically different security and privacy measures in some (not
all!) cases.  (Yes, I did read through it before composing this mail.)

I see some text in each of the three areas listed which sort-of addresses
my concerns, ("Used transport mechanisms should satisfy the security
requirements of the specific SFC deployment", "These include [...]
potential confidentiality issues of that policy", "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"), but they could easily be missed by the reader,
and do not convey a single central sense that adopting SFC will involve a
full reevaluation of network security policy.  That reevaluation will
include security/privacy issues for the original payload as well as the
classification and encapsulation data added by the SFC protocol(s).


> As I had said, I am more than happy adding text strengthening the
> security considerations — as long as we do not mandate a solution at a
> specific layer.

To partially crib from Simon's proposal, how about

The architecture described here is different from the current model, and
moving to the new model could lead to different security arrangements and
modeling. For example, when service functions are moved from on-path
static machines to dynamic remote machines, this can change the flow of
data through the network, and the security and privacy considerations of
the protocol and deployment will need to be reevaluated in light of the
new topology.

The word "reevaluated" is intended to indicate that a new analysis should
be performed, but not that a different conclustion must necessarily be
reached.

-Ben

P.S. "consdierations" in the second paragraph of section 6 is a typo