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

[Benjamin Kaduk <[e-mail]>]

Hi Carlos,

Sorry for the delayed reply.

On Thu, 28 May 2015, Carlos Pignataro (cpignata) wrote:

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

I think that either of those would improve the clarity, thank you.

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

I do not feel very strongly.  This was just me attempting to brainstorm
for places that new text could have made the document more clear; I wanted
to include some concrete text as part of the brainstorming, to help make
clear my thought process.  I was definitely not expecting you to include
the whole thing verbatim -- maybe some pieces of it, or maybe none of it
at all, if you don't think it is needed (which seems to be the case).

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

Thanks for all these updates; I think they go a long way to addressing the
concerns that were raised during the secdir review.

-Ben