Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
Could SDN have avoided recent DDoS network outage ?
November 09, 2016 | By Zeeshan Rizvi @ Cisco
Online viewer:
Comments (0)

We are pleased to share with you all an interesting article contributed by Zeeshan Rizvi. 


Zeeshan Rizvi

Cloud / DevOps / SDN Strategy at Cisco Systems Inc



All Articles by Zeeshan Rizvi

  How to contribute your article to Netmanias.com !  
  List of Contributors  


Last week’s DDOS (Distributed Denial of Service) attack may have caused companies up to $110 million in lost revenue and sales [1]. As a result, throughout the day on Friday the 21st October, many users were unable to connect to popular sites like Twitter, Netflix, Spotify, Financial Times and many more in various parts of the U.S. as depicted on outage map above [4]. This was unprecedented, since attack vectors were non-traditional and according to different reports ranged from 500-700 Gbps attack traffic volume. Adding to misery, most of the attack traffic originated from discrete IP’s from vulnerable IoT end points like IP camera’s and DVR’s. 
How all of this mess could have been avoided or effectively countered with SDN (Software Defined Networking)? To better understand, lets first start out by understanding what SDN is. SDN or Software Defined Networking essentially allows for network/infrastructure behavior change from a programmatic perspective leveraging orchestration and automation which in turn enables optimizations, scalability and innovation. Notice the emphasis is on programmability. How you programmatically change device behaviors, protocols etc. or how to programmatically extract actionable information from traffic flows and perform intelligent decisions based on that information. 
This programmatic aspect has far deeper implications than what one might superficially can think of. Most immediate of which is that learning or mastering a particular vendor’s device syntax is no longer necessary. You no longer would need to learn Cisco IOS, Juniper's Junos or Arista’s EOS in order to be able to communicate to them or provision / manage them programmatically. Instead you’d be better off learning python and REST based interfaces for these device management functions. Most of these vendors and their likes have been quick to adopt Python and opening up device access via API’s as well. Automation tools like AnsiblePuppet and Chef can significantly improve repeatability and scale for commonly occurring problem sets.
As a result of broad industry adoption now there’s a plethora of material (examples [2]) on how to perform your day to day functions with out having to worry about the device command line syntaxes and automating the heck out of it. This introduces tremendous efficiencies and scale: a troubleshooting, diagnosis and break fix task that took hours can now be boiled down to a matter of minutes or even seconds. 
While DNS innovations like those of Cisco’s OpenDNS’ SmartCache exist to keep DNS queries to websites humming along, there are still measures that need to be taken in order to effectively deter and recover from a DDoS attack. Let’s see what are the possible options for configuring your network (manually) while facing a DOS/DDOS situation: 
  • Re-configure your DNS server to point to a different provider if your current provider is under attack
  • Ensure / Configure DNSSEC
  • Ensure / Configure anti IP spoofing 
  • Configure BGP for traffic diversion and/or traffic black holing 
  • Blocking specific regional IP blocks e.g. from different countries
  • Reconfigure your Access Control Lists (ACL's)
  • Optimize load balancer settings 
  • Reconfigure your server’s IP address 
All of these (albeit non-exhaustive) steps require manual intervention and multiple sub configuration steps. Some of the steps are required at your end while others at your service provider’s end. However, measures which could be under your control would still require significant investigation and time investment in order to manually configure network infrastructure. To complicate things further each passing hour your network or resources are inaccessible it can cost you any where from $60,000 to $100,000 per hour depending on the size of your company [3].
Now imagine if these measures that constitute of multiple steps and sub-steps are all automated and orchestrated across different processes. Your IT staff would be able to configure and manage diverse devices with a single user interface : Python . The diversity could range from F5 load balancers to Cisco or Juniper firewalls, routers and switches, to WAF’s (Web Application Firewalls) from Barracuda or Imperva etc . But it would not matter since you’d be able to automate/orchestrate them via their open API’s, a core tenet of SDN or network programmability. Yes, it sounds like nirvana but we’re closer to bridging the gap between it and today’s (network) realities then one might would imagine.

As always, feedback, comments and questions are welcome !





[1] Dynatrace / CNN:  http://money.cnn.com/2016/10/22/technology/dyn-cyberattack/

[2] References for Network Automation & Orchestration via Programmable API's

Cisco Switch Automation:  https://www.linkedin.com/pulse/python-program-auto-configure-cisco-access-layer-daniel-gilbertson

Data Center related open sourced scripts and tools:  https://github.com/datacenter

Juniper:  https://www.juniper.net/techpubs/en_US/junos14.2/information-products/pathway-pages/rest-api/rest-api.html#overview


Arista:  https://eos.arista.com/arista-eapi-101/

[3] SecurityWeek.com:  http://www.securityweek.com/ddos-attacks-cost-40000-hour-incapsula 

[4] Courtesy of KrebsOnSecurity/DownDetector.com


This article was originally published at https://www.linkedin.com/pulse/could-sdn-have-avoided-recent-ddos-network-outage-zeeshan-rizvi





Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
Netmanias Blog
Netmanias Blog
Netmanias Blog
Netmanias Blog
Netmanias Blog
Netmanias Blog
Netmanias Blog

[HFR Private 5G: my5G]


Details >>







Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file







View All (858)
4.5G (1) 5G (102) AI (8) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (11) QoS (3) RCS (4) Railway (1) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.