White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue

Navigation

Page 25 of 144

Understanding OPNFV 25 virtualized environments: ● Topology validation and enforcement: Topology validation and enforcement is the process of making sure that traffic can only go where it's supposed to. In a physical network this is more straightforward; traffic can be administratively separated. In a virtualized environment, this is more involved – the theoretical possibility exists for traffic to go anywhere, and for inadvertent loops to be exploited. ● Availability of management support infrastructure: In this case, we're talking not about the higher-ups in the organization, but rather about the ability to administer a system after it has crashed. While the preference is for a separate physical network, for cost reasons, this is normally provided by connectivity through a separate port; it's important to make sure that this access is protected, at a minimum by VPN. ● Secured boot: It's important that a host be able to verify that VNFs are genuine before firing them up, and for a VNF to know that a host hasn't been compromised before performing sensitive operations. ● Secure crash: When and if a VNF crashes, the system must make sure to destroy all references to it, such as open connections or data that's been persisted to the file system. ● Performance isolation: In a public cloud, this is often called the "noisy neighbor" problem; two processes running on the same core or sharing other resources can interfere with each other's performance. To solve this problem, you can specify that processes must have their own reserved resources, but that brings its own challenges based on resource usage. ● User/tenant authentication, authorization and accounting: NFV increases the number of layers at which users must be identified, as well as the complexity of accounting requirements. Some security risks can be mitigated with the use of tokens rather than direct identity passing, but overall, NFV does present a larger attack surface than traditional hardware environments. ● Authenticated time service: In this case, it's a matter of a potential for attacks, rather than actual attacks that is being pointed out; some code relies on timing to function properly, so it queries multiple sources to get the "true" time. A VNF, however, can only talk to a hypervisor, so there is no possibility of getting multiple "votes". (Note that this is actually a cloud issue, as opposed to a NFV-specific issue.) ● Private keys within cloned images: In an ideal world, cloned images would not include private keys or passwords for access, and instead that information would be injected at boot time. Unfortunately, we do not live in an ideal world. This is a problem that's not necessarily a technical challenge, but an operational one. ● Back-doors via virtualized test & monitoring functions: Another operational issue involves test or debug interfaces that may be enabled on an official or unofficial basis to enable operators to test or debug production components. If you must leave them in place, they must be protected from attack. ● Multi-administrator isolation: Mitigation of Multi-Administrator Isolation issues is an

Articles in this issue

view archives of White Papers - Understanding OPNFV