Last Call Review of draft-ietf-sfc-architecture-08
review-ietf-sfc-architecture-08-secdir-lc-josefsson-2015-05-28-00

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


Attachment:


pgp5EoHQ_dIKp.pgp




Description:

 OpenPGP digital signatur