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

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

Simon,

Many thanks for your detailed review, and in particular your conclusion:
"I still would classify this document as Ready."

It is true that this new architecture introduces a model in which there is a more dynamic service application, decoupling it from network topology path; however, there is no administrative domain changes or admin fragmentation. In other words, taking it very concrete, there is no change in expectations regarding for example encryption. The service is potentially applied in another part of the network and a chain can be created dynamically, but all within the same admin domain as before. 

I am happy to add some text strengthening the security considerations -- however, I am concerned with any text that could be interpreted as a specific strong requirement of encryption on solutions. 

Your proposal ends too definitively as "this
 introduce security and privacy aspects that needs to be addressed", while I see it more as "potentially" or "may in some cases". 

Further, I believe that the main concern you raise is already covered in the "SFC Encapsulation" section of the Security Considerations. 

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On May 24, 2015, at 15:11, Simon Josefsson <[e-mail]> 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