By Nicholas Greene
We already know that IPsec is here to stay, especially since it’s such an integral part of IPv6. So, how did IPv6 become so ingrained with IPsec? Why was IPsec developed in conjunction with IPv6, and how did it get to where it is today? To answer these questions, let’s quickly revisit the origins of IPsec.
Let’s go back to the 1990s, when (as most people think) IPv6 was first being developed because of IP address exhaustion. But in reality, along with the address exhaustion, something else was abundantly clear to the Internet Engineering Task Force (IETE). During its inception, the Internet was a relatively private technology. Truth be told, I don’t think the original technology was ever intended to become the public platform that it is today. And as most people involved with networking will tell you, security for a private network is a very different beast than from public network security. A public security remedy is what the IETF ultimately realized was lacking as the Internet became increasingly public.
“The obvious need for securing content at layer three [the ‘network’ layer of the seven-layer OSI networking model] was what spurred the development of IPsec,” said Paul Hoffman, head of the VPN Consortium. “There is security for each protocol at each layer, and IPsec is for that IP.” See, as the Internet grew, a number of applications and protocols began to appear that SSL wasn’t really equipped or designed to deal with.
Essentially, SSL at the time, wasn’t well-suited for public networks. There were two reasons for this. The first one: SSL was — and still is — software dependent, meaning it’s only able to secure specific applications. So SSL worked for the small, private networks, but this posed a problem with the birth of the Internet as we know it today. Since SSL wasn’t designed to work with the new applications, it couldn’t secure them. Granted, SSL/TLS nowadays can work for public networks, but back then, not so much.
Here’s the second reason. While SSL was suitable for establishing remote connections between systems, it provided no way of securing those remote connections against attack from the higher layers. The fact that these connections were so often insecure left the user’s machine — and data — vulnerable to outside access.
In light of these realities, a new security protocol became necessary. This excerpt from the TCP IP Guide explains:
“What was really needed was a solution to allow security at the IP level so all higher-layer protocols in TCP/IP could take advantage of it. When the decision was made to develop a new version of IP (IPv6), this was the golden opportunity to resolve not just the addressing problems in the older IPv4, but the lack of security as well.”
I’ve got to hand it to the folks at the IETF- they’ve got rather incredible foresight. They saw it all coming, and swooped in to kill two birds with one stone, tackling both the address exhaustion and the network security issue with IPv6. Of course, since they knew that network security would probably become a problem long before address exhaustion, we’re just now beginning to see the last of the 32-bit IPv4 addresses assigned.
I’ve noticed a bit of confusion as to the status of IPsec in the Internet Protocol Suite- namely, as to whether or not it’s mandatory in IPV6. I was told by Paul Hoffman that it’s never been mandatory…even though most sources cite it as a mandatory element. Why the contradiction?
Turns out, there’s actually some rather confusing wording related to IPsec’s status in IPV6.
Essentially, IPV6 lists IPsec implementation as mandatory. What this means is that IPV6 has to have IPsec available…but sysops don’t actually have to deploy that implementation. Either way, it’ll still be present in IPv6, should anyone choose to deploy it. So, ultimately, IPsec is definitely here to stay.
VPN Haus 