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

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

Hi, Ben,

> On May 28, 2015, at 12:02 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Wed, 27 May 2015, Joel M. Halpern wrote:
> 
>> The "plain text payload" is an IP packet.  Customer IP packet protection needs
>> are, in almost all cases I can think of, independent of the routing path
>> through the network that the packet takes.  As such, I do not see why SFC
>> adding yet another means to direct traffic flows changes the protection needs
>> for customer IP packets.
>> 
>> Note that many of the results SFC is trying to simplify are achieved today,
>> albeit with more complexity.
>> 
>> So I am having trouble seeing what requirement you want the SFC architecture
>> to call out.
> 
> I believe that the main motivating factor is the case where the NSA or
> some other "three-letter agency" is sniffing traffic within a network.
> There was a bunch of news about "ssl added and removed here" a while back,
> motivating some companies to increase the use of encryption within their
> networks.

This is a very noble goal, but let’s not DoS-attack this draft to solve that higher-level objective. :-)

I look forward to satisfactorily addressing the security concerns, and strengthening the SFC architecture. I believe we have convergence points in your other response. I will reply with the specifics there, but a couple additional thoughts below.

> 
> If the attacker only has access to a small number of nodes or links within
> the network, then changing the paths over which data passes can
> potentially expose it to surveillance when it was not before.

“Changing the path" can potentially remove traffic from surveillance points also, net-improving the situation. My point is that it is conjecture.

>  You are
> correct that SFC itself may not be adding new real requirements on what
> data (paths) should be protected, but it is, in some sense, the first "new
> thing" now that we are aware of the extent to which networks come under
> attack.  As such, we are inclined to take the opportunity to remind
> readers of the potential for these attacks and that they may want to
> consider countermeasures as appropriate.

Given this objective, and the fact you acknowledge that SFC may not be adding new real requirements, I’d recommend a more holistic approach instead of reminding only SFC readers in a corner of the security considerations.

Best,

— Carlos.

> 
> So, it is not exactly an additional requirement in practice, but rather an
> additional requirement in terms of what we document in IETF protocols, an
> addition made to reflect our changed understanding of the world in which
> we operate.
> 
> -Ben