1. Leveraging SDN for ARP Security
Jacob H. Cox Jr., Russell J. Clark, Henry L. Owen III Georgia Institute of Technology
Presented
By Jacob H. Cox Jr.
For IEEE SoutheastCon 2016
On April
My research focuses on Leveraging SDN” capabilities towards modular, security solutions for edge-devices. In this talk, we’ll discuss the address resolution protocol (ARP) and how SDN can be used to secure it.
The outline…

2. Outline Why SDN? ARP & ARP Poisoning Traditional Mitigation Methods
Related Work
Network Flow Guard (NFG) ARP (NFGA)
Future Work
Conclusion
Address Resolution Protocol (ARP)

3. Why SDN?
Problem: The tight coupling of control and data planes within traditional network devices make edge-device security solutions tediously complex, time consuming, expensive, and prone to error. *SDN separates the control plane from the network's data plane to offer a simple and programmable means to dynamically control OpenFlow switches that theoretically enables new approaches to edge-device security.
So, why SDN. Well, the problem we’re trying address is that …
Objective: To investigate how software defined networking (SDN) can mitigate or eliminate network security attack vectors in network edge-devices. We propose Network Flow Guard (NFG) as a novel, modular, and SDN-based solution to counter known security vulnerabilities. Specifically, this project seeks to detect and remove rogue DHCP servers from the network.
Now usually, I find one of the best ways to find new projects is to listen to network operator’s complain. Chances are they’re complaining about a potential project. This is what led me to the rogue DHCP server problem.
About 80% of network attacks originate from inside the network (KPMG E-fraud report)
Did you know that the easiest attacks inside a network are ARP spoofing attacks?
Objective: apply Network Flow Guard (NFG), a modular, SDN- based solution to mitigate or eliminate network security attack vectors in edge-devices.
*Software Defined Networks (SDN)

4. ARP-Request (who-has)
ARP and ARP Poisoning
ARP Packet Characteristics:
RFC 826
Ethernet type = 2054
Protocol = 1,2 (ARP)
ARP-Request (Broadcast)
ARP-Reply (Unicast) H1
ARP-Request (who-has)
Server
ARP-Reply (is-at)
ARP Table IP
MAC
72:3c:14:e2:74:0a
How ARP works
Network Attacks
Blackhole (Common)
Malicious Web Server
Man-in-the-Middle
ARP-Request (who-has) H1
Server
ARP-Reply (is-at)
Well how is ARP compromised anyway?
About 80% of network attacks originate from inside the network (KPMG E-fraud report)
ARP attacks are considered one of the easiest attacks inside a network.
In the top-left corner, we see how ARP is supposed to work. To the right of that, we see a Wireshark capture of an ARP transaction and some additional ARP protocol information worth remembering. For instance, the ARP-Request (proto=1) is a broadcast while an ARP reply (proto = 2) are unicast.
In the bottom-left, we see how ARP is compromised. Note that ARP is what we call a stateless protocol….
The bottom right shows us to what ends an ARP Poison compromise is used. Compromises can include documents, s, or VoiceIP conversations. ARP spoofing attacks go undetected by firewalls and operating system security: Firewalls do not protect against ARP based attack.
So, how do network operators address this problem?
ARP-Reply (is-at)
ARP Table
Attacker IP
MAC
ba:d0:14:e2:7b:ad IP
MAC
72:3c:14:e2:74:0a
How ARP is Compromised

5. Traditional ARP Poison Mitigation
Observations:
Significant network operator involvement
Expensive and proprietary devices
Network topology changes
Network protocol changes
Host installations
Middleboxes
Product OS
Protection
Active/ Passive
Antidote
Linux No
Passive
Arp_Antidote
Arp_Alert
ArpON
Linux, OSX,
BSD, Solaris
Yes
Active
ArpStar
Arpwatch
ArpWatchNG
Snort
Window, Linux
Winarpwatch
Windows
Xarp
Windows, Linux
Pro-Version
Active+ Passive
Quite a few measures for detecting ARP poisoning exist. Some simply protect the host, like ArpOn. Others detect ARP poisoning if observed (great for hubs, not so much of mac-learning switches.
There have been several programs, proposed to detect and protect against ARP spoof. Yet, most of them work ineffectively. Some of them can only detect but not protect, such as XArp [15], ARPWatch [5]. Several programs (such as Anti Netcut [12], NoCut [16], and AntiARP [11]) have been tested in our lab [14] and found an ineffectiveness of protection.
ArpON (ARP handler inspection) is a Host-based solution that make the ARP standardized protocol secure in order to avoid the Man In The Middle (MITM) attack through the ARP spoofing, ARP cache poisoning or ARP poison routing attack. Uses host authentication on every with every host in the path chain. ArpON is a proactive Point-to-Point, Point-to-Multi- point and Multipoint based solution that requires a daemon in every host of the connection for authenticate each host through an authenti- cation of type cooperative between the hosts.
Arpwatch: is a tool that monitors ethernet activity and keeps a database of Ethernet/IP address pairings. It also reports certain changes via . Arpwatch uses libpcap, a system-independent interface for user-level packet capture.
XArp is a security application that detects ARP based attacks. Uses active and passive modules to detect hackers on subnets.
Host-based ARP Security Solutions
Venkatramulu, S. and Rao, C. G., “Various solutions for address resolution protocol spoofing attacks," International Journal of Scientifc and Research Publications, vol. 3, no. 7, 2013.
Image:

6. Traditional ARP Poison Mitigation
Static ARP Tables [1]: Host-based Solution
Effective, kernel ignores all ARP replies
Not scalable, each subnet device must hold all other subnet device info.
Pre-created load files burden operators (must manage and maintain)
Networks may need DHCP service to handle limited range of IP addresses
Dynamic Arp Inspection (DAI): Network device solution
Vender-centric and proprietary solution
Maintains DHCP snooping database and ARP access lists
Enabled per switch and VLAN via CLI by network operators
SDN cannot trivially extend DAI
Static configurations (sometimes needed) cause the kernel to ignore all ARP-replies for IP addresses that are not statically
stored in its ARP table [1]. Static ARP tables (Even pre-created files for loading devices) are not scalable, and they present a huge burden for network operators).
Static ARP tables: Impossible administrative overhead. Secure distribution of tables not possible. Depending on OS version static ARP-entries are being overwritten.
Since port-security, static configuration, access-lists, and other well-known security features are not adequate countermeasures for ARP poisoning, Dynamic Arp Inspection (DAI) was developed for some proprietary switches. Its default setting is that all ports are untrustworthy and inspects ARP packets from untrusted ports.
As a result, all ARP traffic from untrusted ports are compared against a DHCP snooping database or against ARP access-lists to ensure valid MAC:IP table bindings [10], [11]. However, this protocol must be enabled per switch and VLAN via CLI by network operators, and it is subject to configuration problems. It is also a proprietary solution used by commercial vendors which further
ensures vendor lock-in. Nor can it be extended to SDNs in a controller agnostic way.
[1] A. Lockhart, Network security hacks. ” O’Reilly Media, Inc.”, 2006.

7. Related Work
Cho et al. [1] use an SDN controller as an ARP proxy to reduce ARP broadcast traffic. Intended for cloud services and not security. Targets ARP-Requests not ARP-replies.
Kang et al. [2] captures MAC:IP associations as instances are created in cloud environments and adds them to a reliable ARP table. SDN controller checks ARP- replies via table lookup. Not applicable for physical networks using DHCP, and both static and dynamic port allocations
Sphinx [3] protects enterprise SDNs by gleaning state and forwarding metadata from OpenFlow control messages in to flow graphs. Changes in graphs generate flags. ARP security is a secondary function; it only flags possible ARP spoofing
Before I discuss our SDN related solution, let me point out that some have already been offered.
The first two are solutions geared towards cloud solutions. The first chooses to let the controller serve as a proxy for all ARP requests, which may not be the best use of clock cycles for the controller. The second assigns MAC and IP information to VMs at createion and loads them into a table. This table is consulted by the controller before allowing ARP-replies to pass.
Sphinx is unique in that it constructs flow graphs and alerts when a change occurs. But it only provided detection, and hosts my actually move.
[1] Cho, Hyunjeong, Saehoon Kang, and Younghee Lee. "Centralized ARP proxy server over SDN controller to cut down ARP broadcast in large-scale data center networks." Information Networking (ICOIN), 2015 International Conference on. IEEE, 2015.
[2] H. S. Kang, J. H. Son, and C. S. Hong, “Defense technique against spoofing attacks using reliable arp table in cloud computing environment,” in Network Operations and Management Symposium (APNOMS), th Asia-Pacific. IEEE, 2015, pp. 592–595
[3] M. Dhawan, R. Poddar, K. Mahajan, and V. Mann, “Sphinx: Detecting security attacks in software-defined networks,” in Proceedings of the 2015 Network and Distributed System Security (NDSS) Symposium, 2015

8. Network Flow Guard for ARP (NFGA)
Instead of this!
Network Flow Guard (NFG) Goals
Modular, SDN-based, security framework
Use common protocols
No change to network architecture
Minimal Network Operator Involvement
Detect and Prevent ARP Poisoning
Handle both Dynamic and Static IP allocations
Pyretic Framework
Controller (POX)
NFG Coupler
Other Mod
Switch Mod
ARP Mod
Other Mods
Switch and ARP Functions
Many SDN solutions assume all responsibility for the network or they lack extensibility. However, such solutions can be equally challenging for Network Operators to adapt, tweak, and incorporate in their own networks. Instead, Network Flow Guard offers a modular format that allows operators to easily incorporate other features
Discuss Modularity, Topology Requirements, Network Operator Involvement, Use of existing protocols.

9. NFG for ARP (High Level)
Pyretic ARP and DHCP Capture Examples (Bottom)
High-level NFGA algorithm (Top Right)
ARP Validator (Bottom Right)
NFGA High Level
From the high level view, NFG ARP receives DHCP and ARP packets (selected via Pyretic query as shown in bottom left). Note that Pyretic is a modular, programming language that sits atop a POX controller providing user abstraction for network application development. It allows us to tell the switch which packets are of interest to us, so if a packet arrives having ethtype of 2054, protocol 2, it is identified as an ARP reply.
Note that NFG for ARP accommodates both static and dynamic address allocation.
Pyretic Queries for ARP and DHCP packets
ARP Validator

10. NFG for ARP (Dynamic Table)
Dynamic Table Build Algorithm (Right)
Dynamic Table Sequence (Below)
DHCP
Server
DHCP Discovery (State: ignored) 1)
DHCP Offer (State: Initialized) 2)
DHCP Request(State: Pending) 3)
DHCP Ack. (State: Verified) 4)
J. Cox, R. Clark, and H. Owen. "Leveraging SDN for ARP Security." SOUTHEASTCON 2016, IEEE. IEEE, 2016.
Dynamic Table (Entry Steps)
Pkt
MAC IP
Port
State
Fixed 1)
----
------ 2)
11:22:33:44:55:66
None
Initialized (0)
False 3) 3
Pending (1) 4)
Verified (2)

11. Set Up and Test Scripts
We developed a test environment within a Mininet [16] framework. Within this environment, we utilize an OpenFlow [13] enabled virtual switch connected to a POX controller [15], a Lighttpd [17] web server, a DHCP server, six hosts running a Linux Ubuntu OS, and a network address translator (NAT) serving as an intermediate router.
The coupler orchestrates the handling of packets through modules instantiated as objects.
Test Scenarios using ArpPoison
Mininet Test Environment for NFG

12. Future Work
Expand NFG to address additional edge-based security threats such as rogue NAT devices, etc.
Develop a framework on top of Ryu to allow for modular security concepts like NFG. (Why? See next slide.)
The primary reason we are considering Ryu is the limited number of header fields offered by Pyretic.

13. Pyretic vs RYU (Why Change?)
Pyretic (OpenFlow 1.0 only)
Ingress
Port
Ether
Src
Ether
Dst
Ether
type
VLAN ID
VLAN
Priority
IP src IP
dst
IP Proto
IP ToS Bits
TCP/UDP
src port
TCP/UDP
dst port
RYU (OpenFlow 1.0 – 1.5)
Ethernet
ARP
ICMP
src
ethertype
dst
src_mac
dst_mac
src_ip
dst_ip
hlen
hwtype
opcode
plen
proto
code
csum
data
type
IPv4
UDP
hdr_len
flags
tot_len
option
offset id
tos
ttl
src_port
dst_port
TCP
IPv6
DHCP
seq
ack
win_size
bits
urgent
Intentionally not shown
**My work still requires a framework to operate atop RYU to achieve modularity similar to Pyretic.

14. Conclusion
NFG offers the following advantages for edge-device security
Automated prevention of ARP poisoning attacks
Minimal Network operator involvement
No change to existing Network Architectures or Protocols
Easily updated to include additional security features (modular, extensible)
The primary reason we are considering Ryu is the limited number of header fields offered by Pyretic.

15. Leveraging SDN for ARP Security
Questions??