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

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

Simon,

> On May 27, 2015, at 1:13 AM, Simon Josefsson <[e-mail]> wrote:
> 
> Den Tue, 26 May 2015 19:41:42 -0400 (EDT)
> skrev Re: [secdir] Review of draft-ietf-sfc-architecture-08:
> 
>> 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".
> 
> Agreed.
> 
>> 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.
> 
> That's better, thank you.  I believe it would have been better to
> include a discussion of security concerns in the architecture document
> itself -- doing security right sometimes requires architectural
> changes, so if it is done later you might realize serious issues -- but
> barring that, adding a statement to acknowledge that no security
> analysis has been done, and that it has to be done, seems appropriate.

A security analysis has been done, resulting in the identification of key areas of security considerations to be taken into account during protocol design and solution deployment.

At an architectural level, Section 6 identifies the architectural building blocks and their specific security considerations, to be addressed by the realization of the architecture. This statement is not an acknowledgement that no security analysis has been done.

> 
> /Simon


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

Thank you, Ben. This is already corrected in our working copy.

Best,

— Carlos.