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

[Stephen Farrell <[e-mail]>]

I've yet to read this one so could be plain wrong but I don't
see that our choices here are an architecture that defines (or
re-uses) no security mechanisms/services at all or one that
encrypts everything, but fwiw your response below Joel and earlier
ones read as if those are the only choices and I find that hard
to believe.

S.

On 26/05/15 22:22, Joel M. Halpern wrote:
> Given the expected construction and usage for this, if we rite into the
> archtiecture that encryption and authentication of data plane messages
> are mandatory, then
> presumably we will also write such "mandatory" mechanisms into the data
> plane mechanism we specify.
> 
> At which point we are writing a specification which will be widely ignored.
> 
> Given that we are talking about passing packets through a series of
> service functions, requiring encryption between them causes a drastic
> increase in complexity and latency.  As far as I can tell from the way
> customers expect to use this, it is simply unacceptable.  For inter-DC
> (or POP<->DC) operators who wish to protect that traffic wil likely want
> to do so whether or not they are using service chaining.  As such, the
> protection is not a service chaining issue.
> 
> So, sorry, but I have to respectfully disagree with you Simon.
> 
> Yours,
> Joel
> 
> On 5/26/15 4:17 PM, Simon Josefsson wrote:
>> 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
>>>>
>>
> 
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview