sdn, nfv, and - afcea · pdf file2 motivation for sdn •increase the pace of network...
TRANSCRIPT
2
Motivation for SDN • Increase the pace of network protocol innovation
• Reduce cost of and time to deployment
• Enable new networking applications
• Remove constraining vendor standards and increase market opportunities
• Allow best-of-breed open source standards to emerge
3 3
SDN Primarily Lives Here (but moving into core)
Practical SDN Scope—from Internet to End User
Tier 1 Routers Internet Core
Tier 2 ISP A
Tier 2 ISP C
Tier 2 ISP B
Local ISP 1 Enterprise
2
Incr
easi
ng
Pack
et S
wit
chin
g R
ates
Specialized, Costly Hardware Optical Link Switching
Affordable switch hardware Gigabit Ethernet, Wireless
4 4
The hype—the reality
• Networking equipment has been software defined for a long time
– The key—proprietary interfaces limit accessibility
– If you’re a vendor-employed engineer, you may likely be able to develop your own applications readily because of the programming APIs available to you
• But for the rest of us, SDN enables rapid prototyping of new protocols and ideas before large-scale industry adoption
– This doesn’t mean that you should deploy an SDN system operationally as soon as you get something “working”
• Industry has rallied around SDN concepts, but have different viewpoints about its use
– ONF focused on the OpenFlow specification only
– While OpenDaylight focused on applications
5 5
Observations about SDN
• Security is on the backburner for protocol definitions
– For OpenFlow: MITM, DoS, lack of Flow Table verification, “Listener mode” all vulnerabilities
• Performance and scalability of arbitrary-depth packet switching limits large-scale use (e.g. Tier 1 routers)
• Stability of open-source appliques
6 6
Why should we care about SDN? • Silicon Valley’s view:
– Primarily to virtualize network services and infrastructure in the cloud
– Full commoditization of platforms
– Reduction in operational expenses by 80%
• Energy savings, equipment replacement savings (95% utilization)
• Military networking view:
– Rapid prototyping capabilities-reduce development time by 50%+
– Security: major opportunities in both cyber defense and offense
– Major advance in enabling new Network Management/Operations features
• Other views:
– Wireless: provisioning backhaul nets more efficiently, reduced complexity for handoff
– Development and experimentation of new protocols
~$15B industry as of 2015, growing exponentially with increased industry support
White box commodity hardware becoming commonplace
7 7
Network Functions Virtualization (NFV) • Created by service providers
• Focused on leveraging SDN concepts to reduce costs
• Not limited to SDN-only APIs
– OpenStack, for example
– Other methods for virtualization
• Command line/console/scripting
• SNMP
• Virtual machines/servers
• Examples of network functions:
– Virtualized router services
– IDSs
NFV
Expensive, specialized hardware Limited efficiency, scalability, upgradability
Inexpensive, reconfigurable server racks Maximum efficiency
Router IDS Firewall
NFV App Store
8 8
NFV-SDN Datacenter
• Data center implementations becoming more
dependent on NFV/SDN architectures
• Engineering trades
– Instantiation time vs availability vs resource allocation
SDDC #1 Customer X
SDDC #2 Customer Y
Orchestration, Billing, Monitoring
Commodity Hardware, Software APIs for control/configuration
9 9
“Centralized Traffic Engineering deployed in 2 months” “Can emulate entire backbone in software” “Hitless SW upgrades and new features” “Higher network utilization” (95%) Google had to develop their own redundancy, security, and scalable cooperation amongst controllers—this is NOT part of the OpenFlow specification
*taken from Google presentation at ONS 2013
An Industry Example Google Data Center
10 10
Industry Support for SDN Security
• SDSec: “Software-Defined Security”
• vArmour
– Silicon Valley-based company that focuses on “SDSec”
• SRI International FortNOX + SE Floodlight
– Attempts to secure OpenFlow command requests
• Likely first steps:
– Providing automated, similar functions (e.g. IDS, firewall) implemented in something like OpenFlow
• Other applications
– Moving target defense, honeypot redirection, network visibility provisioning on a user-by-user basis
11 11
FortNOX
*taken from Porras, et al., “A Security Enforcement Kernel for OpenFlow Networks,” HotSDN Proceedings, 2012.
12 12
OpenDaylight Controller Shield
• Architecture design aims
to protect attacks from
all potential entry points
Major features (so far…)
• East-west peer controller authentication
• Fresh packet-in monitoring per port/switch
Challenges
• No solutions to large-scale key/certificate
management for authentication
• Only emergent—many features still being
developed for future releases
13 13
Moving Target Defense with SDN
• Images taken from C. Corbett, A. Dalton, et al. “Countering Intelligent Jamming with Full Protocol Stack Agility,” IEEE Security and Privacy Magazine, Vol. 12 Issue 2, 2014.
14 14
SDN for Military—Notional Applications
• Enterprise
– Wired-side network resource provisioning and NFV
– Dynamic routing applications
– Data center energy savings
– New NetOps applications
• Tactical
– Multi-exit wireless and handover
– Mobile ad-hoc network reconfiguration
– Enhanced cross-layer cooperation
– Sensor network management
15 15
Military SDN Example: DISA milCloud
• Taken from J. Martin (DISA) presentation on milCloud, DISA Enterprise Information Services, AFCEA JIE Event, 2014
• http://www.afcea.org/events/jie/14/documents/MILCLOUD_MARTIN--FINAL.pdf
16 16
Military SDN Integration Roadmap A practical perspective
• SDN opens up new opportunities for fine-grain
control of packets
• Overnight large-scale adoption of new protocols like
OpenFlow not practical or recommended
– Security concerns, compatibility, ecosystem immaturity
• But! Vendors are increasingly building APIs like
OpenFlow into their products
– Why not investigate using these APIs just like others
that have been provided over the years (SNMP, CLI,
SSH, …)
17 17
Military SDN
Integration Roadmap
Now
• Experimental/prototype configurations for tailored applications
• Limited applications in data centers
• Growth in security studies/assessments
Late 2010s
• Testing with SDN APIs on emerging vendor product lines
• Further augmentation of existing federal systems that already provide NFV functions (e.g. milCloud)
• Compatibility assessments
• Continuing security assessments
• Better understanding of emerging threats from new attack surfaces
• Maturing network defense and management systems leveraging SDN concepts
2020s
• Acceptance of SDN APIs for general networking approaches
• Standardized government certifications for employing secure SDN platforms, protocols
• Improved interoperability, scalability
• Best practices emerging from ecosystem maturity
• Economies of scale reducing network infrastructure costs
• Commodity hardware
• Emerging leadership in SDN solutions (open standards and vendors)
18 18
Wrap-up
• Hype for SDN continues into 2015
– Security methods are reactionary at best, but progress is evident (isn’t this often the case?)
– Open developer communities are increasing the pace of innovation, many new projects just this year
– But best of all—much of the ecosystem is completely FREE and OPEN
• SDN a key enabler for rapid prototyping and testing new capabilities quickly
– But should never be a replacement for rigorous T&E before deployment
• SDN can be applied to help solve multiple networking challenges
– Wireless, cloud provisioning, moving target defense, policy-based network management
19 19
Backup
20 20
Military SDN Roadmap: Current
• Nascent SDN field with security concerns
– OpenDaylight Controller Shield, FortNOX and SE-
Floodlight starting to secure controllers
– More research needed to determine vulnerabilities
• Data center applications largely dependent on home-
grown reliability, scalability methods
• Experimental prototype innovation pace speeding up
– Much easier to test new protocol implementations
21 21
Military SDN Roadmap: Late 2010s
• Industry organizations like OpenDaylight, OpenFlow will continue building ecosystem of applications and standards
– Advances in SDN-based management and defense improving today
• Hardware advances will improve packet handling performance
• Government systems likely to experiment more with new SDN approaches as vendor hardware increases support
• Major new attacks and vulnerabilities discovered and industry shifts to address challenges
22 22
Military SDN Roadmap: 2020s and beyond
• Large-scale acceptance and adoption of SDN-based open approaches to support networking applications
• As is the case with existing OS builds or vendor hardware, government certifications likely to emerge
• Network hardware fully commoditized
• Improved interoperability/scalability solutions
• Clear industry leaders in SDN approaches and vendor hardware
23 23
Military Networking SDN Example: Heterogeneous Wireless Tactical Network
Network Node
Radio 1
Radio 2
SAT 1
• Links can form between any radio type • Packets can reach their destinations through multiple links • In an on-the-move environment, links will come and go often
• Traditional routing • OSPF, radio
extensions maybe…
• Packets are routed according to the “best link” at the time
• But we can do a bit more with SDN…
24 24
Military Networking SDN Example Heterogeneous Wireless Tactical Network
SDN Controller
• QoS example: ALL packets from a particular IP address that is mission critical send across all links
Flow Update
Pkt Pkt
Pkt Pkt
Pkt
Commander’s Intent
NEW MISSION!! CRITICAL DATA FROM ONE NODE MUST TAKE
PRECEDENCE!
25 25
Military Networking SDN Example: Credential login and network visibility provisioning—new user
A
B C
D
Physical Connection Permissible Path
AD Server
User Info
Maps Server
Video Server SDN
Controller Accept
Flow Update Flow
Update Flow Update Flow
Update Flow Update
26 26
Military Networking SDN Example: Credential login and network visibility provisioning—administrator
A
B C
D
Physical Connection Permissible Path
AD Server Maps Server
Video Server SDN
Controller