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

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

Ben,

> On May 25, 2015, at 11:01 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Sun, 24 May 2015, Carlos Pignataro (cpignata) wrote:
> 
>> 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.
> 
> As I attemted to say in my secdir review of the sfc-problem-statement
> document
> (http://www.ietf.org/mail-archive/web/secdir/current/msg05351.html), it is
> not clear that being within the same administrative domain excuses one
> from considering whether encryption is necessary.  I seem to recall that,
> e.g., Google is encrypting all inter-datacenter traffic (I don't remember
> about intra-datacenter traffic, though).
> 
> I do not think it is realistic to think that one can protect a network at
> the boundary -- there are always ways for sufficiently advanced attackers
> to get in, and some form of defense in depth is needed.  Now, I grant that
> encryption may not always be needed, and it is not the place of SFC to
> insist that encryption always be used, but please do not claim that being
> in a single administrative domain excuses the operator from considering
> whether encryption is necessary.
> 

My point was a different one: that SFC does not change these requirements.

I may have misunderstood, but what I read in Simon's review (admittedly oversimplified) was: in SFC you move services from on-network-path (which, as an aside, is really the other way around; it is moving from creating an on-network-path steering of network topology through the service) to a machine ‘elsewhere' — and thus, consequently, you have to encrypt.

My point is that the logic above (which, again, I may have misunderstood) does not follow.

There may be additional security and privacy considerations needed in the DC, in mobile networks, etc. However, the SFC architecture does not change that, and mandating encryption on SFCs might not be the right answer. As we wrote, the solution realizing the architecture need to perform part of that analysis.

As I had said, I am more than happy adding text strengthening the security considerations — as long as we do not mandate a solution at a specific layer.

Best,

— Carlos.

> -Ben Kaduk