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

["Joel M. Halpern" <[e-mail]>]

There may well be something that can be said in the architecture that 
would be helpful.  My concern is that given teh current IETF 
environment, adding the suggested wording to the architecture could 
easily lead the IESG to expect mandatory-to-implement data plane packet 
authentication and / or encryption.

There are proposals to add optional mechanisms to the dataplane 
protocol.  The proposals I have seen have no impact on the architecture.

Yours,
Joel

On 5/26/15 5:33 PM, Stephen Farrell wrote:
>
> 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
>