Someone recommended I start another blog for the dissertation project (Secure IPv6-based Communications across Multiple Untrusted Networks), so here it is:
IPsec isn’t straightforward to understand or explain, as it’s not a single protocol. It’s more complex than that, being a collection of open standards, protocols and functions designed to be interoperable between any two points across the Internet. I really sucked at explaining a project to a couple of interviewers the other week, partly because of this.
Short for Internet Protocol Security, IPsec provides confidentiality, integrity and authentication for communications between networks, and between endpoints when IPv6 is deployed. It was actually developed as a native feature of IPv6, but doesn’t seem in any way ‘mandatory’ as numerous other sources are claiming. As we’ll see, the only obvious difference between IPv4 and IPv6 in relation to IPsec is Network Address Translation. Forget the articles that drone on about how IPv4 addresses are running out – the real problem is our reliance on NAT.
There are two modes of use for IPsec: In Transport Mode, only the TCP payload – the content of the traffic – is encrypted, while all other components such as headers and routing information are unprotected. The more commonly-used TLS/SSL might have been developed simply to make this form of encryption more convenient and readily implemented.
In Tunnel Mode, the entire TCP/IP packet is encrypted and encapsulated within another packet. This outer packet is routed to the destination IPsec tunnel gateway, decrypted and forwarded.
In order to understand the basics of how IPsec works, we only need to look at four central components:
* Authentication Headers (AH) provide integrity and authentication.
* Encapsulating Security Payload (ESP) provides confidentiality, authentication and integrity.
* Security Associtions (SA) provide the algorithms and data that enable the use of AH and ESP operations.
* Internet Security Association andKey Management Protocol (ISAKMP) for authentication and key exchange.
The Authentication Header (AH) ensures integrity and authentication of IP packets. It protects the IP payload and all header fields, except for those that might be altered during transport. It’s mainly used for authenticating the sender of the packet, and for detecting any alterations to the payload as it was routed between the source and destination.
In Transport Mode the payload is hashed, and an integrity check value is placed in an AH header field. In Tunnel Mode, an Integrity Check Value (ICV) is generated for the whole encapsulated packet. At first, it appears anyone could intercept this, alter the payload, rehash it and put the new Integrity Check Value in the header. To eliminate this possibility, both parties share a secret key when establishing the connection (I’ll come to this in a minute), and that secret key is hashed alongside the payload to generate the ICV.
Unfortunately IP addresses are also included when generating the ICV, which is what makes this component of IPsec incompatible with Network Address Translation, so this only works between IPsec gateways until IPv6 is fully deployed.
Encapsulating Security Payload
The Encapsulating Security Payload (ESP) can provide authentication, integrity and confidentiality of TCP/IP packets, working in either encryption only or authentication only configuration. In Tunnel Mode, the entire encapsulated packet is protected, and but the authentication method here only covers the payload and ESP headers. It also adds some padding to improve the efficiency of whatever block cipher might be used. Anyone intercepting the traffic won’t be able to determine the payload or its type.
Together, AH and ESP provide the essential components of a VPN connection when used in Tunnel Mode between two gateways. When implemented alongside IPv6, this type of connection could be made between two clients on separate LANs, which is currently impossible with Network Address Translation.
The Security Associations Database and Key Exchange
Security Associations are simply the authentication and encryption algorithms being used for an IPsec connection, plus the keys. They are initialised as the IPsec link is established, using the Internet Association and Key Management Protocol (ISAKMP).
This information is maintained in a Security Associations Database (SADB), hich specifies the following:
* Authentication algorithms
* Authentication secret
* Encryption algorithm
* Secret key
* Key exchange parameters
A Security Association is one-way, so at least two are required for secure communication between two entities, and the SADB should potentially scale up to support secure multicasting over IPsec.
As with any secure connection, the problem is two endpoints must share a secret key without a third-party intercepting it, and this must happen before any IPsec encryption or authentication is set up. With TLS/SSL, this is acheived using asymmetric encryption to exchange a symmetric encryption key. With IPsec, the common method is the Internet Key Exchange (IKE/ISAKMP), which is normally based on the Diffie-Hellman algorithm.
I’ll probably be in a better position to explain how the Diffie-Hellman algorithm works if I add it to the XeroCrypt software. Basically two communicating parties each generate a random number, which is a secret key used in a mathematical operation to generate two more values – one public and the other private. The two entities exchange their public values, and use them in another mathematical operation that should generate the same result on both sides – this is the shared secret key.
This is something I’ve been thinking about for several months. In the context of IPv4, multicasting is about broadcasting data to a group of clients that have established a connection to a specific multicast address, and this can be used for broadcasting media such as IPTV and Internet radio. Currently with most the Internet still being IPv4-based, the nodes in a multicast group are invariably routers. When IPv6 is fully deployed, the nodes could be the endpoints themselves, and this is why I reckon IPv6 multicasting could be used as the basis for a group messaging system or a new type of distributed social network. The need for a central server would be removed, and the endpoints would be communicating pretty much directly. At least that’s the assumption I’m building on.
The concept I’m developing was partly inspired from a job I worked several years ago, where there was a demand for highly secure IP-based group communications, and the expensive proprietary stuff being deployed for that had some very serious flaws. IPv6 multicasting has certain features that should make it a much better alternative.
From what I gather, any address with the FF:: prefix, apart from the FF01:: to FF0F:: block and a few reserved addresses, can be used for multicasting, and this is what might provide confidentiality for a group. Anyone who wanted to listen in on the communications would have to sift through roughly 1.3 x 10e36 addresses to find the correct one.
Of course, the major flaw in my argument is the communications would vulnerable to Deep Packet Inspection anyway, but we have IPsec which is supposedly a native feature of IPv6. With each client having a persistent address, and Security Association Databases being able to accommodate any number of endpoints, it should be possible for a closed group to communicate securely over IPsec links. It would also solve the problem of authenticating the group membership. It seems Cisco and Louise McKeag at Techworld have already thought of multicasting/IPsec combinations before I did.
It’s only recently I’ve given IPv6 any serious thought, and I’m still going through a mass of literature on the subject and related technologies. As I’ve already pointed out, it’s still TCP/IP, which encapsulates data and routes it exactly as with IPv4, but the colossal address range makes numerous other things possible. Without giving too much away, this is one component of a system I believe will defeat traffic filtering and interception, hence my interest.
Without Network Address Translation, hosts located anywhere can form a group sharing a multicast address – one host sends data to that address, and it would be broadcast to the entire group.
IPv6 multicast addresses begin with ff:, so there are 2e+112 possible addresses a group can use, disregarding a handful of reserved addresses. The other bits in the first segment determine the type of multicasting.
A third party trying to intercept the broadcasts for a given group must therefore potentially scan through 2e+112 addresses to determine the correct one. We could say this is comparable to cracking 112-bit encryption. However, there are a couple of problems: the group must be able to select a random multicast address, and that address must somehow be communicated securely. It leaves us with the old key distribution problem, but that might be solveable with some implementation of RSA.
Also in my previous post, I pointed out that it’s possible to allocate roughly 6.67e+25 addresses to each square centimetre of the Earth’s surface, assuming my maths is correct. The point here is there’s no practical limit to the number of addresses a proxy server could use and discard, which makes the task of blacklisting them extremely difficult. This could even negate the current need to use proxies to defeat IP-based filtering systems.
A few readers might wonder why I haven’t mentioned IPsec yet. IPsec is natively supported by IPv6, and functions at the TCP/IP layer instead of the application layer. This enables secure tunnels to be established between two points, and unlike SSL provides security for both routing and payload. It’s not commonly used at the moment as Network Address Translation re-encapsulates data, making it difficult to preserve the integrity of TCP/IP packets.
Where I’m Going with All This
Recent events proved the concepts of copyright and ‘intellectual property’ have been taken way out of proportion. Increasingly web sites are being arbitrarily blocked and removed without due process, ‘checks and balances’ provide no real protection, and we came dangerously close to allowing the US government to degrade the DNS in the name of copyright. As some of us feared, the United States is following China’s lead in blocking traffic exchanged between the US and other countries.
All this directly contradicts what ‘Cyber Security Strategies’ are supposed to achieve, and in the long run it will ultimately degrade the security of the Internet while aiding criminals. In my view, this is an engineering problem in need of a solution.
Looking at this objectively, the IPv6 Internet should route traffic without interference and regardless of content, especially when it develops into an ‘Internet of things’ that connects all manner of electrical and electronic device. To preserve the reliability and security of the Internet, a new system – perhaps a successor to the Tor network that takes advantage of IPv6 – is needed to render useless whatever methods are used for blocking traffic.