Internet DRAFT - draft-bernardo-sec-arch-sdnnvf-architecture
draft-bernardo-sec-arch-sdnnvf-architecture
Network Working Group Danilo Valeros Bernardo
Internet-Draft Db2P Sydney, Australia
Intended status: Informational
Expires: March 20, 2015 September 20, 2014
Software-Defined Networking and Network Functions Virtualization Security Architecture
draft-bernardo-sec-arch-sdnnvf-architecture-01.txt
Abstract
SDN and NFV have been creating paradigm shifts across major service providers, governments,
and industries. In most recent months, these two novel frameworks created jitters and
excitements across major academic institutions and communities of practice. While these are
considered disruptive to major network infrastructures operating on status quo, SDN and NFV
nonetheless bring network resiliency, scalability, manageability, and, most importantly,
lower long-term operational expenditures.
They create opportunities for innovation that engage key players from networks, security,
and software to develop new software controllers, APIs, networks, and technologies.
This document aims to propose a formal security architecture that overarches important aspects
of SDN and NFV 's frameworks.
The architecture can be elaborated and modified as these two frameworks mature over time.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. The list of current Internet-Drafts
is at http://datatracker.ietf.org/drafts/current/.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Internet-Drafts are draft documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 21, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors.
All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.
Bernardo, DV Expires March 20, 2015 [ Page 1]
Internet-Draft SDN/NFV Security Architectures September 2014
Code Components extracted from this document must include Simplified BSD License text as
described in Section 4.e of the Trust Legal Provisions and are provided without warranty
as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Introducing Software-Defined Networking . . . . . . . . 2
1.2 Introducing N FV. . . . . . . . . . . . . . . . . . . . 3
2. Security Risks. . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Mitigations. . . . . . . . . . . . . . . . . . . . . 4
4. Security Architectures. . . . . . . . . . . . . . . . . . . . 5
4.1 Practical Security Architecture . . . . . . . . . . . . 5
4.2 Enterprise Security Architecture. . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Addresses . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
1.1 Even though its concept had been around for decades, SDN did not really gain momentum
until it was implemented within an academic environment in 2011. This has gained
prominence since then.
In 2012, it was widely speculated that Google implemented SDN and OpenFlow into their
networks, and created their own OpenFlow-enabled switches due to the limited vendors
supporting this protocol.
This speculation has since gained significant interests across many industries.
To understand SDN is to look at the OSI layer,where one will find similar concepts
of abstraction and separation, and tiering and layering.
In SDN, control and data planes are separated, centralizing the control and programmability
of the network. APIs are Application Program Interfaces, created to connect applications
on the plane.
The Northbound APIs achieve abstractions to the top of the framework while the Southbound APIs do
the same at the bottom of the framework. East and westbound APIs, which are formally introduced in
this draft, can be used for horizontal communications across devices, systems , or software
on a given plane.To put it simply, the northbound and southbound APIs are used for vertical
connections, while the east and westbound APIs are for horizontal connections.
The application tier hosts business applications and application-based security systems.
The control plane composes controllers, where routing and security policies are implemented.
The data plane is basically the infrastructures composing network devices, routers, switches,
and security devices.
Each plane can be virtualized as and when needed. Initially, it targeted campus, data centre
and cloud, but eventually adapted by service and network providers.
Bernardo, DV Expires March 20, 2015 [ Page 2]
Internet-Draft SDN/NFV Security Architectures September 2014
1.2 What is NFV
On the other hand, NFV , which was formalized in 2012, relocates network functions from dedicated
hardwareappliances to generic servers. It was initially intended for routers, firewalls, and gateways,
but can be expanded to include load balancers and other intermediary devices.
Unlike SDN, NFV does not have a specific protocol. Both SDN and NFV create open innovation by
third parties, reducing capital and operational expenditures.
2. Security Risks
The creation of SDN/NFS is undoubtedly based on the existing traditional networks. The defined
goals are focused on either the enhancement of existing network designs or innovation, building
new infrastructures from scratch as part of the green field strategy or moving traditional
infrastructures to SDN (i.e., Brownfield) with a mixture of frameworks (hybrid).
This novel creation brings new perspectives on how to effectively manage infrastructures that are
beneficial to the businesses' bottom lines, while supporting a significant increase of traffic
engineering requirements.
Subsequently, since the design is based on the traditional networks in terms of design, the risks
associated with the traditional networks are inherited by the new frameworks. It is therefore
important to evaluate risks according to best practices, whenever available. However, SDN/NFV
best practices are limited to date, due to the lack of extensive industry-based use cases
surrounding security and risks.
SDN and NFS, like any new frameworks, have new security risks that need to be addressed. For example,
the issues surrounding the absence of standards in the development of northbound APIs, including limited
information about the east and westbound APIs, raise potential risks - especially when they are open
to third-party development, where almost everyone can participate in an open-source software development
for SDN controllers, orchestrators, and applications, and can design the systems whenever he/she likes
without functional and security considerations put in place.
Certainly, the need to identify the risks when implementing SDN is equally paramount to achieving
resilient and secure infrastructures.
o The following are the risks identified on SDN/NFV based on the
traditional network designs.
a. Adversarial traffic flows - traffic passing through network devices,
interfaces, and hosts.
b. Attacks on vulnerabilities in network devices - not updated patch and
version
c. Attacks on vulnerabilities in orchestrators and administrative
servers - unsecure servers, lacks security on admin profile
d. Attacks on control plane communications- single point of failures,
unreliable controllers and unsecure connections
o New risks associated with SDN/NFV implementations are identified, and
are as follows:
e. Attacks on SDN controllers - unreliable software APP/SDN controller
f. Attacks on Southbound interfaces - exposed interfaces
g. Unsecure openflow traffic - unencrypted /unsecure traffic
h. Unreliable North/East-West APIs - unreliable software installed
across the same broadcast domain
i. Vulnerable Programming models - inadequate security involvement in
the Software Development Lifecycle
Bernardo, DV Expires March 20, 2015 [ Page 3]
Internet-Draft SDN/NFV Security Architectures September 2014
These new frameworks will continue to evolve and eventually used across the industries,
so as the increments of the security risks.
Therefore appropriate security mitigations must be considered.
3. Security Mitigations
A few have been identified that must be considered when implementing SDN/NFV.
j. Hypervisors must be secure
k. Controllers must be secure
l. Hardening OS security
m. Extensive API validations
n. Extensive APPs penetration tests
o. Monitor traffic
p. Protocol must be secure
q. Session establishment protocol for communication and traffic flow
must be secure
r. Multiple authentication
s. Limited time options for messaging
t. Network devices must be secure
u. Separation/segmentation of networks and subnets
4. Security Architectures
4.1 Practical Security Architecture
+-----------------+ +---+ (j.)
| (l.,n.) |<-----|VMs|----+
Application Security |Application Plane| +---+|VMs|
| [Security] | +---+
+-----> | +----+ +----+ | <-----+
| | |APPS|(n.)APPS| | |
| | +----+...+----+ | |
| +-----------------+ |
| Monitoring (s.,o.) ^<----> Extensive |
| v(n.,m.)Validations|
| +-----------------+ |
| | NorthBound API | SSL/TLS, |
| | | SSH/HTTPS |
Governance <--> | +-----------------+ / (r.,q.) <-->BEST Practices
| ^ (q.) +-----+ |
| Monitoring (p.)v /|Admin| |
| (s.,o.) +-----------------+/ +-----+ |
| |Control Plane(k.)| |
+---------+ | | [Security](n.) | | +---------+
(m.) | West API|-----> | +----+...+----+ | <-----| East API| (m.)
+---------+ | | |SDN Controllers| | +---------+
| | +----+...+----+ |(u.) |
Control Plane Security| +-----------------+ |
| ^ |
| v (p.) |
| +-------------------+ |
| |SouthBound API | |
| |OpenFlow,PCE,SMNP..| |
| +-------------------+ |
| ^ <-----> Secure |
| Monitoring v (q.) Connections |
| (s.,o.) +-----------------+ |
| | Data Plane(l.)| |
Date Plane Security | | [Security](t.)| |
+-----> | Network Devices| <-----+
+-----------------+ \
(u.) \_ +---+ (j.)
|VMs|----+
+---+|VMs|
+---+
Bernardo, DV Expires March 20, 2015 [ Page 4]
Internet-Draft SDN/NFV Security Architectures September 2014
4.2 Enterprise Security Architecture
+-----------------+
| |
|Application Plane|
| [Security] |
+-----> | +----+ +----+ | <-----+
| | |APPS| |APPS| | |
| | +----+...+----+ | |
| +-----------------+ |
| Monitoring ^ <----> Extensive |
| v Validations|
| +-----------------+ |
| | NorthBound API | SSL/TLS, |
| | | SSH/HTTPS |
Governance <--> | +-----------------+ / | <-->BEST Practices
| ^ +-----+ |
| Monitoring v /|Admin| |
| +-----------------+/ +-----+ |
| | Control Plane | |
+---------+ | | [Security] | | +---------+
| West API|-----> | +----+...+----+ | <-----| East API|
+---------+ | | |SDN Controllers| | +---------+
| | +----+...+----+ | |
| +-----------------+ |
| ^ |
| v |
| +-------------------+ |
| |SouthBound API | |
| |OpenFlow,PCE,SMNP..| |
| +-------------------+ |
| ^ <-----> Secure |
| Monitoring v Connections |
| +-----------------+ |
| | Data Plane | |
| | [Security] | |
+-----> | Network Devices| <-----+
+-----------------+
Bernardo, DV Expires March 20, 2015 [ Page 5]
Internet-Draft SDN/NFV Security Architectures September 2014
6. IANA Considerations
This document does not require any action from IANA.
7. Security Considerations
All components discussed in this draft paper have their own specific
security requirements that MUST be considered.
The enterprise security architecture and its underlying considerations
for SDN and NFV are presented here.
8. Acknowledgements
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Addresses
Danilo Valeros Bernardo
Sydney, Australia.
Email: bernardan@gmail.com
Bernardo, DV Expires March 20, 2015 [ Page 4]
