IPv6 Focus Month: Guest Diary: Stephen Groat - IPv6 moving target defense

Published: 2013-03-27
Last Updated: 2013-03-27 19:42:06 UTC
by Adam Swanger (Version: 1)
2 comment(s)

[Guest Diary: Stephen Groat] [IPv6 moving target defense]

Today we bring you a second guest diary from Stephen Groat where he speaks about IPv6 moving target defense. By frequency hopping in the large IPv6 address space, we're able to create a moving target defense that protects privacy and avoids attackers.

Virginia Tech has developed a moving target defense for IPv6 that adds privacy, anonymity, and security without impacting communications or operations. The Moving Target IPv6 Defense (MT6D) continually rotates through dynamically obscured network addresses while maintaining existing connections. Static addresses are easy targets for address tracking and network attacks. MT6D prevents attackers from targeting specific addresses by dynamically rotating network and transport layer addresses without impacting preexisting sessions. The dynamic addresses are not linked to specific components, requiring attackers to scan the subnet for targets. The immense address space of IPv6 provides an environment so large that an efficient search is infeasible [6]. In the unlikely event that attackers locate a target, the damage they can inflict is limited to the interval between address rotations; reacquiring the target is infeasible.

MT6D modifies the network and transport layer addresses of the sender and receiver nondeterministically. It is capable of dynamically changing these addresses to hide identifiable information about a host, effectively obscuring communicating hosts from any third-party observer. A key feature of MT6D is that this obscuration can be made mid-session between two hosts without causing the additional overhead of connection reestablishment or breakdown. Changing addresses mid-session protects communicating hosts from an attacker being able to collect all packets from a particular session for the purpose of traffic correlation.

MT6D IIDs are computed using three components obscured by a function, usually a hash. The first component is a value specific to an individual host (e.g. a MAC address). The second component is a secret (e.g. symmetric key) shared by the sender and receiver. The third component is a changing value known by both parties (e.g. time). The only one of these three values that must be kept secret is the shared secret. The function results in a 64-bit output used as the MT6D IID and has the form:

II D' = f {IVx*S*CVi}64

where II D' represents the obscured IID for host x at xi a particular instance i , IVx represents a value specific to the individual host x , S represents the shared secret, and CVi represents the changing value at instance i. The three components are combing using an operation denoted by * which concatenates. The 64-bit function result is denoted by f{•}64.

In our implementation, each packet is encapsulated in User Datagram Protocol (UDP) to prevent Transmission Control Protocol (TCP) connection establishment and termination from occurring every time a MT6D address rotates. Encapsulating packets as UDP has a minimal effect on the transport layer protocol of the original packet. Since transport layer protocols are end-to-end, decapsulation will occur before the host processes the original packet. A session using TCP will still exchange all required TCP-related information. This information will simply be wrapped in a MT6D UDP packet. Additionally, any lost packets that were originally TCP will be retransmitted after retransmission timeout occurs.

MT6D provides the option of encrypting each original packet before appending it

with the MT6D header. By encrypting the original packet, a third party is unable to glean any useful information. For example, if the original packet is sent using TCP, the header gets encrypted so that a third party cannot attempt to correlate network traffic using the TCP sequence numbers. Additionally, the nature of the network traffic is also kept private through encryption.

The architecture of a MT6D device mimics a network bridge. Outbound packets are sent to an encapsulator that constructs a MT6D packet. The MT6D packet contains the entire original packet excluding original addresses. When a MT6D packet arrives at its destination, the packet enters a decapsulator which restores the packet to its original form. The design of MT6D facilitates implementation either embedded directly on components or as stand-alone gateway devices.

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

2 comment(s)


Adam - that's the best explanation of MT6D I've read. Were you one of the people that developed this at Virginia Tech? Are there any shipping implementations or you're looking for funding? Just curious because I've had a few inquiries.
@James negative sir, I am just the poster. This is a guest diary entirely written by Stephen Groat. ISC also recently published a diary by him at https://isc.sans.edu/diary/IPv6+Focus+Month%3A+Guest+Diary%3A+Stephen+Groat+-+Geolocation+Using+IPv6+Addresses/15349

Diary Archives