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

["Joel M. Halpern" <[e-mail]>]

The "plain text payload" is an IP packet.  Customer IP packet protection 
needs are, in almost all cases I can think of, independent of the 
routing path through the network that the packet takes.  As such, I do 
not see why SFC adding yet another means to direct traffic flows changes 
the protection needs for customer IP packets.

Note that many of the results SFC is trying to simplify are achieved 
today, albeit with more complexity.

So I am having trouble seeing what requirement you want the SFC 
architecture to call out.

Yorus,
Joel

On 5/27/15 2:16 PM, Benjamin Kaduk wrote:
> On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote:
>
>>
>>> On May 26, 2015, at 7:41 PM, Benjamin Kaduk <[e-mail]> wrote:
>>>
>>>
>>> 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.
>
> I think we disagree on 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.
>
> So, you believe that the SFC Encapsulation section is intended to cover
> the potential need for confidentiality protection of the plaintext payload
> which is being encapsulated by SFC?
>
> I think that given the way the current text flows from "an operator may
> consider the SFC Metadata as sensitive" straight into "from a privacy
> perspective, a user may be concerned about the operator revealing data
> about [...] the customer", it causes me to read that privacy concern as
> applying only to the SFC Metadata (i.e., not to the original payload).
> Likewise for the "risk of sensitive information slipping out of the
> operators [sic] control"; since the paragraph started with the SFC
> Metadata, it seems like this paragraph may apply only to the metadata.
>
>> But as I said, I would not oppose strengthening this section even more.
>
> But more generally, I think the rhetoric is better (stronger) if it is of
> the form "you should do this thing (general concept); here are some
> concrete examples", rather than "you should do this list of things"
> without giving the overarching motivation.  This is a lot of why I am
> pushing for added (summary) text.
>
>>> 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 think I only have the points I mentioned above (lack of clarity
> regarding protecting the original payload, and clear rhetoric).  But let's
> see if Simon has anything else to add, as well.
>
>>> 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'm sorry that my message was unclear; I was not intending to "acknowledge
> that [my concerns] are already addressed", but rather to say that the
> existing text gets some of the way there, but there were still things
> missing.  (Hopefully this email is helping clarify already.)
>
>>>   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.
>
> Just to ensure we're getting through to each other, do you mind pointing
> to the specific text that you have in mind that is supposed to already
> say this?
>
>> “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.”
>
> I might add in "new" or "chained" before the very last "model", but this
> seems to catch the sentiment I was going for.  The idea would be to insert
> this as a new paragraph after the first paragraph of section 6?
>
> Thank you,
>
> Ben
>