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

[Benjamin Kaduk <[e-mail]>]

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.

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.  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.

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