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

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

Ben,

> On May 28, 2015, at 12:24 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote:
> 
>> Ben,
>> 
>>> On May 27, 2015, at 2:16 PM, Benjamin Kaduk <[e-mail]> wrote:
>>>> 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).
>> 
>> OK, let’s make sure we have a way forward for both of them.
>> 
>>>>> 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?
>>> 
>> 
>> What changes the flow of data in the network (i.e., direct user traffic
>> to the ‘remote machine’ (as you called it) is the overlay — that is why
>> in the “Service Overlay” section of the Security Considerations we have:
>> 
>>        and can also include authenticity and integrity checking, and/or
>>        confidentiality provisions.
>> 
>> The use of the SFC Encapsulation is for SFP encapsulation and metadata sharing.
> 
> Now that you have pointed me at it, I do see how you feel that the issue
> is already covered.  Let me see if I have any suggestions for new text
> that would not have required you to point me at it in order for me to see
> it.
> 

OK.

> One thing that comes to mind would be to add a clause at the end of the
> sentence to reiterate what data is being protected.  It is late here, so I
> have confused myself as to whether that should be "for both the traffic
> being forwarded and its encapsulation" or just "for the traffic being
> forwarded”.

I can add “, for both the network overlay transport and traffic it encapsulates” at the end of that sentence? Or "for both the traffic being forwarded and its encapsulation” as well. I thought this was understood, however.

> 
> It seems like it would also be helpful to spend another clause or sentence
> expounding how the security requirements of the specific SFC deployment
> are determined -- perhaps, "These security requirements will depend both
> on the structure of the network where SFC is being deployed and the
> details of the protocol implementing the SFC architecture; the security
> assessment should consider potential threats from both inside and outside
> the network."  That's probably overkill, but is perhaps illustrative.

To me, it is closer to overkill, but I would not oppose if you very strongly feel it adds value, even if merely illustrative.

> 
>>>> “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.
>> 
>> Either ‘chain’ or ‘new’ univocally disambiguates ‘model’ — sure.
>> 
>>> The idea would be to insert
>>> this as a new paragraph after the first paragraph of section 6?
>>> 
>> 
>> Yes, or as the first paragraph of Section 6, as a preamble to the section. Either.
> 
> Sounds good.

Done. Thanks.

— Carlos.

> 
> -Ben