So what we've done at this point is we have explored the idea of a GRE tunnel
and connecting two routers together.
So this tunnel is great, it allows for direct communication, we can form
routing relationships, but we also know that this is an overlay.
It's not an actual direct connection, it's sort of this virtual connection, and
we're leveraging encapsulation to make it happen.
So the reality is that we still have a bunch of other devices that we have to
pass through physically in order to get from one router to the other, and these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
pass through physically in order to get from one router to the other, and these
devices are known as the underlay.
Now these devices might be part of our enterprise network, maybe we're just
leveraging overlay or tunnel technology for a particular reason, but the
reality is that this underlay could also be an untrusted network.
For example, especially the internet, but we might also decide that certain
service provider wide area networking technologies like MPLS, maybe we don't
want to necessarily trust those either. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
want to necessarily trust those either.
And so it's great that we've established this tunnel, but because we are
building it over an untrusted underlay, there might be some security issues.
For example, what happens if somebody in this underlay here is going to start
sniffing our traffic.
So maybe we have some form of dishonest service provider or a rogue employee
who just understands that, hey, I work for the service provider, but I know WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
who just understands that, hey, I work for the service provider, but I know
that this is a wealthy company, I'm going to try to steal some secrets from
them, whatever the situation is.
We certainly don't want to make ourselves vulnerable to that, even if we do
trust the company that runs the underlay, again, just takes one rogue employee
to decide to go in there and try to do something malicious.
The other thing that we maybe not even think about is the idea that we are
opening ourselves up to rogue devices. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
opening ourselves up to rogue devices.
For example, I have decided that I want to connect to 10.1.1.1 here, and I'm
assuming that 10.1.1.1 is an IP address that belongs to router 4, and borrowing
the number from our topology in the last skill.
And so, yeah, maybe it belongs to router 4, but what if this threat actor spins
up their own router, we'll call this our X, it's a bad rogue router, and sets
it up to run the same configuration with 10.1.1.1.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it up to run the same configuration with 10.1.1.1.1.
And maybe they're able to make it so that this router forms a connection, we've
built the tunnel to the wrong router, and now, all of a sudden, we have a man
in the middle attack, because they have hijacked our tunnel connection, they
continue to pass our traffic on to the rest of the network, so we don't even
realize we've formed a tunnel to the wrong router, and yeah, that's going to
cause a lot of potential problems.
All they need to know for this is some basic IP configuration, there's no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All they need to know for this is some basic IP configuration, there's no
passwords, there's no authentication, there's nothing happening here for us to
secure this.
And so, absolutely, this is going to be a problem for us from a security
perspective, and this can apply not just to the internet, but even service
providers.
So, we've talked about some of the values of these, the concept of IPsec, and
how IPsec is going to help us start to lock some of this down.
But we need to now move on from white boarding or chalkboarding out the IPsec WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we need to now move on from white boarding or chalkboarding out the IPsec
solution and move to actual configuration.
So, what we're going to learn, what we're going to look at as we go through the
configuration process here, is that it starts with iC, the internet key
exchange, but remember iC is an implementation of iSecamp.
And Cisco really likes this iSecamp term, to the point that we don't actually
see iC very often, now with iC V2, they kind of change that, but with iC V1 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
see iC very often, now with iC V2, they kind of change that, but with iC V1
especially we're talking about iSecamp configurations.
So, this is going to be how we start our configuration on a Cisco router and i
OS XE device.
So, we're going to walk through this process from a chalkboard perspective,
then we'll log in to perform the actual configurations.
It makes sense to diagram this out because we're going to end up with some
different policies and configurations that tie into one another.
It's going to help for us to diagram this out and have a sense of how this all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to help for us to diagram this out and have a sense of how this all
comes together.
So, let's just put a number one here. The first thing we're going to want to
start with is creating what's known as, actually let's put the one down here,
what's known as a crypto iSecamp policy.
The iSecamp policy is where we're going to configure our Haggle parameters.
Remember, Haggle, yes intentionally spelled with 1G there, then English
normally there's doo-gies, but it's an acronym. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
normally there's doo-gies, but it's an acronym.
It's meant to help us remember what we're configuring as part of this policy.
The policy is interesting because we're not actually going to create a name for
this policy, nor are we going to reference it later.
Instead, we're going to assign a priority value to this where the lower
priority is better.
I might give it a priority of 10 or something along those lines, and then Cisco
iOS is going to adopt that policy as part of all of our iPec tunnels, again, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
iOS is going to adopt that policy as part of all of our iPec tunnels, again,
based on the priority level for the configurations.
It's kind of interesting how that works. So either way, we recall what Haggle
means for us. We have to configure things like the hash, which is going to be
MD5 or some form of SHA.
In the modern era, we should really be using SHA-256 or greater, MD5 and SHA-1,
and considered to be a little bit legacy at this point.
Our authentication, we want to configure, we could use hashing or certificates, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Our authentication, we want to configure, we could use hashing or certificates,
really, but we're going to use pre-shared keys as part of our lab topology here
.
Just understand we have multiple options, but pre-shared key is a pretty good
way to do this for a lab environment.
It makes it nice and simple. We have to configure that Diffie-Homing group.
So that group ID will probably configure 16 in the lab. We've said we want 14
or greater. That continues to change over time.
By the time you're watching this, maybe a higher group level is recommended, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
By the time you're watching this, maybe a higher group level is recommended,
but this is essentially equating to how many bits we're going to use as part of
our Diffie-Homing key exchange.
We also have to configure the lifetime in seconds. Then we also need to worry
about the encryption that we're going to use for this tunnel.
Probably going to use AES because the only other options are seriously outdated
at this point.
We can either use DES, which you don't want to use, or triple DES, which is
three times as good, potentially.
That's still considered to be pretty weak. We want to use AES where we can. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's still considered to be pretty weak. We want to use AES where we can.
This leads us to a conversation, at least a question, of what is this
encryption for?
Recall what we're talking about with Ike. We have two phases. We have to worry
about phase one and phase two.
Phase one is the control plane tunnel. Phase two is the data plane tunnel. This
whole thing right here, this is for our phase one tunnel.
Meaning we're going to use this for communications to the other device, but I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meaning we're going to use this for communications to the other device, but I
can set all of these configuration parameters,
whatever I want to put in here, but it only affects the phase one tunnel. I'm
still going to have to configure the phase one tunnel after all this.
How do we go, or the phase two tunnel, rather? Let's go ahead and move on from
here. We're going to go to the second step.
Let's go ahead and change the color here to distinguish. Second step here is to
configure a transform set.
This is where we start to get into the phase two tunnel configuration, but it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is where we start to get into the phase two tunnel configuration, but it
takes a little bit of a roundabout approach.
With the ISA camp policy, we configure everything in one go. Here, it's really
nice and convenient for the phase one tunnel.
For phase two, as we start to move down here, we have to configure several
different entities and start to apply those entities to the interface, as well
as to one another, to some extent.
The transform set is how we're going to establish the phase two tunnel. We need WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The transform set is how we're going to establish the phase two tunnel. We need
to set configuration parameters.
For example, we're going to use ESP or authentication header. We also have to
set our encryption methods, as well as our authentication methods.
Now, we might say, "Oh, okay, well, if I'm using authentication header, I'm
going to have to configure authentication methodologies, but if I configure ESP
, then I would only have to configure encryption."
That might be how we'd interpret this, but keep in mind, ESP does both. It sets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That might be how we'd interpret this, but keep in mind, ESP does both. It sets
encryption and authentication, so I'm going to have to set both of these if I'm
using ESP, which is likely in a production environment.
I'm also going to set that tunnel versus transport mode. Remember the
difference. This is very important when we're setting up our tunnels.
If I look at my overall packet that I'm encapsulating, remember, I'm going to
put the outer header out here, and this can't be encrypted.
I cannot encrypt the outer header because that's what the underlay is looking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I cannot encrypt the outer header because that's what the underlay is looking
at. If the underlay can't read the outer IP address, then they can't get me to
my final destination.
I cannot encrypt the outer header. What I can encrypt is the inner header and
the payload from the original packet. The payload will say, "This is going to
be encrypted for the transport mode operation."
The tunnel mode operation says, "Okay, yeah, we're going to encrypt the payload
, but we're also going to go ahead and encrypt the inner header." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
, but we're also going to go ahead and encrypt the inner header."
This is considered to be a little bit more secure because even if we used
transport mode to encrypt the payload, that's great, but this thread actor who
's acting down here, we've protected the payload, but they can still see where
we're going.
We can still see the final destination IP address, which might be well inside
the network. Maybe it's a server. Maybe it's a credit card server that I'm
targeting with this communication, and so now they can see the IP address
because we didn't encrypt the inner header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because we didn't encrypt the inner header.
That would be why we'd want to consider using tunnel mode, especially when we
're using something like the Internet, and it's a seriously untrusted
environment.
That is the transform set, and that's the value in configuring different
options, and we'll see how exactly that works.
It's a little bit different than we might expect. We don't configure a
transform set and then start to configure options like we often do.
Instead, it's all one line for the most part. We'll see that coming up here. It
's, again, kind of interesting how it comes together. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
's, again, kind of interesting how it comes together.
Number three. Next thing we need to do is configure an IPsec profile.
The IPsec profile is going to receive the transform set. I actually apply the
transform set here to the IPsec profile, and the IPsec profile also allows for
other options.
The most part, we don't use those options very often, but if we need them, then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The most part, we don't use those options very often, but if we need them, then
they're there. If we're not using those options, it feels a little silly
because all we're really doing is saying, "Hey, I'm going to apply this one
transform set to this one profile," and we might have said, "Hey, let's just
not configure a profile," but it is what it is.
Lastly, we're going to apply this IPsec profile to the tunnel interface.
We do need to put configuration on the tunnel interface. We have to apply the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We do need to put configuration on the tunnel interface. We have to apply the
IPsec profile, but we also need to set the protection mechanism.
Basically specifying that, "Yeah, we're going to use this particular
configuration," and then we're also going to have to set the IPsec mode.
We'll see that configuration here coming up, and the tunnel configuration at
that point should be the end of this, so we should be good to go.
We've got our phase one configuration in place. We've got all of our phase two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got our phase one configuration in place. We've got all of our phase two
information there as well, and so that's going to apply it to the tunnel, and
as long as I do that on both sides, we should see the IPsec tunnel come online.
At that point, our tunnel is protected. One last note in all of this is that
this skill is going to be focusing on IKEV1.
The reason for that is because this is not a security course. This is a
security section within an enterprise networking course.
Cisco really wants us to understand the mechanisms of IKEV1 because it's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco really wants us to understand the mechanisms of IKEV1 because it's the
foundational concepts and principles of forming a secure connection.
IKEV2 is a little bit more complex in its configuration, and it's really
outside the scope of the course.
If you want to learn more about IKEV2, we have a score course that would stand
for security course, sort of like this is the enterprise networking course exam
and course.
Cisco has a security core exam, and therefore we have a security core course.
We can go ahead and check out IKEV2 over in our other security content, but for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We can go ahead and check out IKEV2 over in our other security content, but for
again, staying within the scope and context of the encore, we are going to be
focusing in on IKEV1 for our configuration, and really, as we've seen, most of
our conversations are just centered around this more foundational protocol.