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

[Benjamin Kaduk <[e-mail]>]

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.

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

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.

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

-Ben