Partial Path Encryption via Waypoints

Our PPE approach allows better end-to-end protection of unencrypted traffic. In many cases, online servers do not provide an encryption option. This is especially true for Internet-of-Things (IoT) devices, but even well-known sites such as www.webmd.com leave all communication including sensitive medical queries unencrypted. Without encryption, end-users may pass personal infor- mation such as usernames, passwords, medical conditions, or more subtle information such as political interests in unencrypted packets that are sent across in the Internet. We seek to reduce the exposure of unencrypted information with PPE via waypoints. Because we do not control the destination server, we cannot force it to encrypt traffic to an end-host. However, we may use a waypoint to encrypt traffic for a majority of a packet’s routing path across the Internet, if the waypoint is strategically placed.

Figure 5.2 shows how waypoint routing helps encrypt end-to-end traffic. The bottom path from the host shows what path HTTP traffic would take if not using PPE. Without PPE, the traffic traverses 5 hops before reaching the destination. With PPE, the home router encrypts and tunnels the traffic to a waypoint hosted by a cloud provider. In the top path, the packet only traverses 3 hops, assuming a single router in the cloud provider, before reaching the destination. The number of hops saved (2 in our example) is dependent on the destination and how many hops the destination is from the nearest cloud provider.

In practice, the PPE module builds and maintains a table of destination IP addresses and two sets of hop counts to reach those destination. The first hop count is the minimum number

Host R1 R2 R3 R4

Waypoint

Destination Figure 5.2: Overview of how partial path encryption with waypoint works. Traffic is encrypted at the router per flow and routed through a waypoint in the cloud where it is decrypted and routed to the destination. This incurs a smaller number of hops where the original traffic is unencrypted.

of hops required to reach a destination from each of the cloud providers that host a waypoint. The second hop count is number of hops required to reach the destination directly from the home router. The latter count can be derived by passively watching traffic and checking the TTL or explicitly generating OpenFlow PacketOut events to invoke responses from the destinations. If the hop count from any waypoint is less that that of the path directly from the residential network, the PPE module may direct the route agent to tunnel all traffic to the waypoint over an encrypted tunnel, for example, using IPSec. Importantly, this decision of using a waypoint could consider other factors such the difference in hop count or the ASes along the path since some ASes are known to be more malicious than others [159].

5.4

Implementation

To determine the feasibility of our ReSDN infrastructure, we created a prototype using a consumer- grade router and an OpenFlow controller in a cloud data center. We flashed a TP-LINK TL- WR1043ND v2 router with a custom build of the OpenWrt (Chaos Calmer 15.05) image. To enable OpenFlow support, we selected the kernel-level Open vSwitch package.

To ensure continued operation in the event of connectivity issues when reaching the cloud controller, we ran NAT, a DNS recursive resolver, and DHCP services locally along with OpenFlow. We had to create a virtual interface to act as an intermediary between the router’s WAN interface and the router’s internal LAN. To enable NAT functionality, we created static rules in iptables for masquerading. We did not have to make any special changes for the DHCP or DNS services. We can conceal the complexity of these routing configurations by including them inside the firmware upgrade process.

We then created two cloud virtual machines (VMs). One VM hosts the OpenFlow controller, and the other VM hosts a waypoint. We used Ubuntu 14.04 Linux server micro-VM instances in the Amazon EC2 compute cloud with the multi-tenant configuration, which was eligible for Amazon’s free tier. Each VM has a single 2.5 GHz core with 1 GByte of RAM and used a dynamic global IP address but operates behind NAT. We performance latency tests and determine the North Virginia data center provided the best performance to our residential network. In the future, we will streamline this evaluation to enable the router to automatically determine the best cloud

location.

5.4.1

DNS Blacklist

Our DNS blacklist is an elevation-centric application that consumes elevated DNS queries, which the controller naturally receives since each DNS query uses a new network flow. The DNS blacklist examines the packet, compares the requested host name with an existing list of banned sites, and drops the packet if it is on the blacklist. Otherwise, the function allows the DNS packet to be forwarded unmodified. When the controller is initialized, the blacklist function retrieves the blacklist from a remote server hosting a popular domain blacklist [55]. Because we use fine-grained flow control, packets are always elevated to the controller. Accordingly, the controller needs a way to determine if the user has enabled the blacklist or not. To do this, the controller differentiates based on the reason for elevation. If the user has not explicitly, enabled the blacklist, the DNS packet is elevated due to a flow miss. If enabled, a flow match causes elevation and allows the controller to act. We implement the blacklist as a POX [31] module.