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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Ben,

Thanks for the follow-up, please see inline.

> On May 26, 2015, at 7:41 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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.

Fully agree — and I believe this is what the current Security Considerations section achieves.

In particular, Section 6 highlights the areas of the new architecture (Overlay, Classification, Encapsulation) of which designers and operators ought to be aware.

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

Further specifically, the "SFC Encapsulation” seems to cover this.

But as I said, I would not oppose strengthening this section even more.

> 
>> 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 do not disagree. Are there areas beyond what’s already in the Security considerations that require specific focus?

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

This is the key of the review, IMHO. On one hand, you seem to acknowledge that your security concerns are already addressed with the existing text. On the other hand, you seem to want to child-proof the text in case a reader misses what is already there already addressing the concern.

I support your view of elevating the message with a central sense of ‘this is an architecture and re-evaluate security’. However, that is not (in my read) what the text proposed by Simon achieved.

I’ll be happy to add a short preamble sentence/paragraph to Section 6 with this, if the WG agrees.

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

Yes — which is what the doc already says.

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

“Reevaluated” is significantly better, of course. Here’s another proposal:

"The architecture described here is different from the current model, and
moving to the new model could lead to different security arrangements and
modeling. In the SFC architecture, a relatively static topologically-dependent
deployment model is replaced with the chaining of sets of service functions.
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 model.”

Simon, Ben, Joel, Jim, Thomas, Alia, WG,

Thoughs?

— Carlos.

> 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