The dreaded but necessary theory

- [Instructor] One of the joys of having been in IT for a while now is you see things that are just taken so for granted that were so amazing when they came out. I mean, wireless networking, are you kidding me? We're going to be able to take our laptops and our tablets and just go anywhere with them? As I look around our studio here I notice a few wires, so we're not totally wireless yet, but we've certainly come a long way there. And the reason I mention that, on a related topic, it was amazing when we could first VPN in from home. We could connect to the network from home.

But it's not enough just to have that one click away anymore. We've got to have that connection be as secure as possible, and that's what virtual private networks, VPNs, are all about. We say VPN so often that we forget what the P actually stands for in there, and it's Private, it's privacy. And with VPNs bringing security to a connection using a shared channel-- and, of course, that shared channel is being treated as though it were a private network-- we often refer to VPNs simply as tunnels, because the VPN is effectively tunneling through an existing communication outlet such as a Serial interface on a Cisco router.

And the great thing is we can apply security rules and policies to the tunnel without applying them to the interface or the connection that we're tunneling through. A couple of terms I want to be crystal clear on, data origin authentication being the first. Now, data origin authentication allows the receiver to guarantee the source of the packet, where encryption, we know what that's all about. That makes the contents of packets unreadable during the transmission, which make the intercepted packets useless to the interceptor.

And integrity is the receiver's ability to ensure the data was not tampered with during transmission. Now, a protocol that I honestly never thought would make a comeback is the Generic Routing Encapsulation, or GRE. And you're thinking, "Hey, "I don't want generics, I want the name brand stuff." Well, that's not a good reason to not use GRE. Generics can be good. But here's a reason that is a good reason not to use GRE. There's no encryption scheme. And you're wondering, if this is your first exposure to it, well, how did this ever make a comeback? Stick around, we're getting to that.

Don't go on any long trips. This huge security hole is corrected by IP Security, which is generally referred to as IPSec. Be careful how you type that in documentation. IPSec offers encryption and authentication, and it's actually a combination of three protocols; Authentication Header, AH, which defines a method for authentication and securing data; Encapsulating Security Payload, ESP, which defines a method for authenticating, securing, and encrypting data; and then finally the IKE, the Internet Key Exchange, which negotiates the security parameters and the authentication keys.

Here's the IPSec packet format. And you can see that AH is in a field by itself, where ESP, the Encapsulating Security Payload, is doing just that. It is encapsulating the data because we have a header, and we have a trailer. Now, Authentication Header, defined in RFC 2402, it offers solid security with data origin authentication and optional anti-replay protection. Now, the drawback with AH is that the authentication it provides for the IP header, it's not complete.

Because some of the IP fields can't be correctly predicted by the receiver, because some may change during transmission. AH will, however, protect the IP packet's payload. In short, with AH we have data origin authentication, we have data integrity, and optional anti-replay protection. AH does not offer data confidentiality. Now the Encapsulating Security Payload does exactly what it says. We saw on the format-- goodness, pardon me-- we have an ESP header and a trailer encapsulating the data.

ESP gives us data origin authentication, anti-replay protection, and data confidentiality. Now already you may be thinking this kind of sounds like TCP and UDP argument. and the other one doesn't. So in this case, why do we ever use AH? Why don't we use ESP all the time? Well, it's the overhead, of course. It's the same thing as TCP/UDP. TCP gives us a lot of great features, but it's also got a lot more overhead. ESP gives us more features, but it requires strong cryptography, and that can be a problem in two ways.

First off, it does make ESP much more processor-intensive than AH is. And strong cryptography is not available everywhere, and, frankly, it's not allowed everywhere. AH has no such requirement. However, that full encapsulation of data does make ESP a very wise choice whenever it's feasible. Now, both of these babies can be run in either tunnel mode or transport mode. Now in tunnel mode, the entire IPSec process is transparent to the end hosts, and specialized IPSec gateway devices handle that part of the load.

Tunnel mode encrypts the entire IP packet, and then that encrypted packet is placed into another IP packet. And that encapsulating packet, that's going to have the IP addresses configured on the tunnel endpoints, and it's those tunnel IP addresses that will be used to route the packet. Now let's step up here just a little bit. Transport mode, it does encrypt the IP packet payload, but the IPSec header is inserted directly after the IP header. And as a result of that, there is no protection for the original IP address, and it's the original IP address that's used for routing, and only data from the transport layer up is protected by IPSec.

Now, we've just got a little more theory, and then we're going to start building one of these babies. So let's look at the five main steps that are involved in creating an IPSec VPN. We start with process initialization-- makes sense-- via the receipt of interesting traffic. And we've talked about interesting traffic in another video, I believe, that you've probably seen to this point, but interesting traffic is that traffic that triggers something. It could be a phone call if you're working with dial-up links here with a VPN.

It actually starts the creation of the VPN. And then interesting traffic is defined by something called a crypto access-list, and, lord, does that sound complicated. It's really not. It's just like a regular ACL. It's a scary name, I admit. Next up, IKE Phase 1, and that's where the Internet Key Exchange Security Association, or IKE SA, is going to be negotiated. Now next up is the cleverly named IKE Phase 2, and that's where the IPSec Security Association is negotiated.

When that's complete, the IPSec tunnel, which is also called the IKE Phase 2 tunnel, that build is complete. Now the data transfer can take place. And when that transfer's complete, we don't want the tunnel just sitting there. We want to go ahead and tear it down. Now that tunnel termination can be configured to happen either after a certain number of bytes have passed through the tunnel, or after the data transfer has been idle for a given period of time. So we can give it an idle timeout, or just say, when this much data passes through, go ahead and tear down the tunnel.

Now I know you're already thinking the same thing I was thinking the first time I saw that. If traffic is flowing through the tunnel at the same time the tunnel's supposed to come down, what happens? Do you want to tear the tunnel down when there's still traffic in it? Well, no, a new Security Association can be agreed upon while the existing one is still in place. Now, that is the theory. On the next video we're going to dive right into the VPN creation. Be very sure that you're clear on the material in this. This isn't just a little bit of stuff I have to read you before we get to the fun stuff, which is actually building one.

You definitely want to know this particular material cold. I would recommend watching the videos with the construction and then coming back and watching this one at least one more time, when you have some more readouts on the router and some more labs to compare it to. So let me be quiet here, and I'll start talking again at the beginning of the very next video.