Tom,
I'm not sure security should *always* be deployed end-to-end, as there
might be use cases where it's perfectly acceptable, or it may even be
required, to deploy security at the DC edge or ToR (e.g. for better
troubleshooting, traffic inspection, or even just cost/operational
reasons). I guess that, ultimately, it depends from the threat model
you're trying to address.
As long as the architecture allows to combine security with the network
virtualization function, it can allow different deployment models,
including the one you describe.
This is actually an argument for proper layering, where a flexible
architecture could separate the network virtualization layer, from the
metadata layer (e.g. service function), and from the security layer.
Different combinations of those layers may allow for different
deployment models. Also it seems very likely that well known security
mechanisms (such as IPsec) could be applied to address some of the
security challenges you describe.
Fabio
On 3/21/14, 9:25 AM, Tom Herbert wrote:
Looking a some of the proposals related to nvo3, I am concerned that
assumptions are being baked in that the data center network will
provide adequate security of a protocol.
>From geneve draft:
"Within a particular security domain, such as a data center operated
by a single provider, the most common and highest performing security
mechanism is isolation of trusted components."
>From nsh draft:
"In many deployments, NSH will be used in a controlled environment,
with trusted devices (e.g. a data center) thus mitigating the risk of
unauthorized header manipulation."
This seem to be punting the security of a protocol to be someone
else's problem. Even in the data center, our security threats are
increasing and obviously the push to allow third party code to run in
that environment probably increases the threats by an order of
magnitude.
Here are some perspectives from a large deployment:
1) Given the value of the data that is being carried in packets, the
cost of a breach is potentially **very** high.
2) Any single device which is completely comprised should still only
have limited access and bad effects.
3) Inevitably, misconfiguration or bad routing will misdirect traffic
and inadvertently bypass network security for some packets.
4) In environments that allow third party VMs we must assume that
every hosting device is potentially untrusted.
5) Corollary to above, every host now must implement a security perimeter.
6) We will never completely trust third party devices for which we
don't own the code or implementation.
7) In a large network bit errors, HW failures, SW bugs are common
occurrences. It's problematic that in VXLAN and nvgre even a single
bit error in the vni could misdirect a packet to the wrong VM (no CRC
or checksum protects vni).
8) We know that threats to our network will only increase overtime, we
must be able to adapt accordingly. This becomes a big problem if we
became completely dependent on network HW for security (cost of
swapping out HW is prohibitive).
So fundamentally, we need end to end security within the protocols--
at least that covers any fields that are sensitive to corruption or
snooping. Mechanisms in the network are still very important, but in
themselves not adequate and should be complementary to security within
the protocol.
Please take this under consideration.
Thanks,
Tom
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
