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

[Simon Josefsson <[e-mail]>]

If it is unreasonable to expect that encryption/authentication will be
part of the architecture, I believe there is a significant problem with
this architecture.  The argument that security is not necessary within
a single administrative domain is one that I complete disagree with.  I
am hoping that I am missing some context here.

/Simon

> While the paragraph you suggest looks reasonable, I am somewhat 
> concerned if readers draw the conclusion that we expect to include
> data plane authentication and / or encryption mechanisms as a
> mandatory part of the solution.  There is no such expectation.  While
> there is reason to be concerned about exposure of information across
> the Internet, the document begins by specifically noting that this
> architecture is for use with a single administrative domain.
> 
> I am thus concerned that adding the suggested text may give rise to 
> unreasonable expectations on solutions which comply with this
> architecture.
> 
> Yours,
> Joel
> 
> On 5/24/15 3:10 PM, Simon Josefsson wrote:
> > Hello.
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should
> > treat these comments just like any other last call comments.
> >
> > This is an architectural document, so it doesn't have the usual
> > security impact that you can easily review.  The Security
> > Considerations section gently refer any security considerations to
> > the future documents that will actually realize the archicture.
> >
> > The security considerations that you would expect to be discussed
> > in an architecural document are those on an architectural level.
> > The archicture proposed here is to change how network services are
> > delivered.  The document doesn't give many examples, but my
> > understanding is that the intended services would include firewalls,
> > NAT, proxies, packet filtering, anti-spam measures, anti-DDOS
> > measure, QoS, and so on.
> >
> > The traditional model is static services coupled to network topology
> > and physical resource. The new model introduced by this document, as
> > far as I understand, is a dynamic model where delivery of these
> > services can be moved around more dynamically, by tunneling traffic
> > to the service and back.
> >
> > I may have missed it, but I feel that the security consequences of
> > moving to this new architecture is not discussed in the document.
> >
> > Some obvious security considerations that are introduced with an
> > architecture like this are:
> >
> >    1) When delivery of a service is moved from an on-network-path
> >    machine to a machine sitting somewhere else, there ought to be
> > some consideration to authenticating the involved entities and
> > encrypting the traffic between them.
> >
> >    2) Auditing who has powers over a communication channel will be
> >    different -- before you evaluated the wires and who had access
> > to the machines connected to the wires.  Now you have to review the
> > policies configured in the machines and what external entities are
> > involved, together with the operational aspects of this boxes that
> > perform the service delivery.
> >
> >    3) Moving traffic around raises the challenge how to achieve that
> >    without negatively affecting privacy of the traffic.
> >
> >    4) Protecting the SFC configuration and policies is critical for
> >    secure operations.  Anyone who gains access may be able to modify
> >    traffic.
> >
> > If the above is a bit handwavy, allow me to be more concrete.
> > Adding something like the following to the security considerations
> > would at least acknowledge that there are inherent security
> > considerations with this architecture:
> >
> >    The architecture described here is different from the current
> > model, and moving to the new model will lead to different security
> >    arrangements and modeling. For example, when service functions
> > are moved from on-path static machines to dynamic remote machines,
> > this introduce security and privacy aspects that needs to be
> > addressed.
> >
> > All this said, I still would classify this document as Ready.  It
> > mostly just disappoint me that a new architecture can be introduced
> > without containing a significant discussion of security properties.
> >
> > /Simon
> >