|
0:00:14
|
In this section we are going to begin our discussion of IPSec
|
|
0:00:18
|
and the general protocols that go along with IPSec
|
|
0:00:21
|
including the ISAKMP and IKE negotiation
|
|
0:00:25
|
some of the differences between the authentication header and the Encapsulating Security Protocol or AH versus ESP
|
|
0:00:32
|
and also the difference between the transport mode of IPsec versus the tunnel mode
|
|
0:00:40
|
Now as we know IPSec is a suite of security protocols
|
|
0:00:44
|
that is mainly designed to do four things
|
|
0:00:47
|
first of which is to authenticate
|
|
0:00:49
|
the data that is going between two pairs
|
|
0:00:52
|
to make sure that when the packet is recieved
|
|
0:00:54
|
we actually know that the
|
|
0:00:56
|
the source of the packet is valid, so who did the packet come from
|
|
0:01:00
|
the integrity of the packet to make sure that some one has not changed it in the transit path
|
|
0:01:05
|
to do some sort of Man in the Middle attack or some sort of packet injection attack
|
|
0:01:11
|
like to try to take over a tcp session, for example
|
|
0:01:15
|
the third would be the confidentiality of the data
|
|
0:01:18
|
which is typically what we think about
|
|
0:01:21
|
or for talking about an IPSec VPN
|
|
0:01:23
|
this is where we would do the actual encryption
|
|
0:01:26
|
to make sure that no one in the transit path
|
|
0:01:28
|
path can actually read the packet
|
|
0:01:31
|
and then finally Anti-reply
|
|
0:01:34
|
which would make sure that for an duplicate type flows
|
|
0:01:37
|
that were going to discard any thing that is previously received
|
|
0:01:42
|
so each of these four individual pieces that make up the IPSec suite
|
|
0:01:46
|
they are designed to prevent against individual attacks on the network
|
|
0:01:50
|
that would get into a little bit of more detail when we talk about specific
|
|
0:01:54
|
security vulnerabilities at the application layer and the network and the transport layer
|
|
0:02:00
|
but overall the idea behind the IPSec
|
|
0:02:02
|
is that we are trying to protect the data between two individual pairs
|
|
0:02:07
|
Now in order to do this
|
|
0:02:09
|
we need to eshtablish an IPSec tunnel between the two peers
|
|
0:02:13
|
what are these peers be to routers
|
|
0:02:15
|
whether its ASA firewalls, whether its an end client
|
|
0:02:19
|
running something like the easyVPN client
|
|
0:02:22
|
but our first step in eshtablishing the tunnel
|
|
0:02:25
|
is to
|
|
0:02:26
|
eshtablish two different data structure
|
|
0:02:29
|
the first of which is known as the Security Association or the SA
|
|
0:02:34
|
Now the SA is going to hold the actual encryption in authentication state
|
|
0:02:39
|
which would be things like the encryption key or the authentication key
|
|
0:02:43
|
whether we are doing pre-shared keys or certificate authority
|
|
0:02:47
|
then in encryption keys whether we are doing 3DES or AES 256 bit
|
|
0:02:54
|
This is essentially the
|
|
0:02:55
|
the control plane state
|
|
0:02:57
|
on the IPSec peer
|
|
0:02:59
|
so that when the packet comes in, it knows what to do it
|
|
0:03:04
|
Now in the data plane, this is where we have the Security Parameter Index or the SPI number
|
|
0:03:11
|
and the SPI is going to be a number that is assigned to an individual security association
|
|
0:03:16
|
and its actual field inside the packet header
|
|
0:03:20
|
that is going to tell the IPSec peer, what is the particular SA
|
|
0:03:24
|
that this packet belongs to
|
|
0:03:27
|
so its similar to
|
|
0:03:28
|
How a VLAN header works or how a MPLS label works
|
|
0:03:32
|
where its a field inside the actual data plane
|
|
0:03:36
|
so that if I have multiple IPSec tunnels
|
|
0:03:39
|
I can figure out that its supposed to be related to one security association versus the other
|
|
0:03:46
|
Now from our point of view with an implementation
|
|
0:03:49
|
the security parameter index or the spi, we don't need to worry about
|
|
0:03:53
|
this is going to be a dynamically negotiated number between the peers
|
|
0:03:57
|
mainly what we need to focus on from an implementation
|
|
0:04:02
|
verification and a troubleshooting point of view
|
|
0:04:04
|
is what exactly goes on, when we are trying the build the Security Association or the SA
|
|
0:04:10
|
and this is done through the IPSec tunnel negotiation
|
|
0:04:14
|
so the first step
|
|
0:04:15
|
of eshtablishing the tunnel
|
|
0:04:17
|
is to figure out how do we eshtablish the SAs of the security association
|
|
0:04:21
|
and this is going to happen through two main negotiation phases
|
|
0:04:26
|
the first of which is considered our IPSec phase I
|
|
0:04:30
|
is where we authenticate the end points
|
|
0:04:34
|
so if router1 is trying to establish an IPSec tunnel with router2
|
|
0:04:38
|
first thing that router1 needs to know is this actually router2 that I am trying to talk to
|
|
0:04:44
|
and this is what the ISAKMP and the IKE protocols are going to be used for
|
|
0:04:50
|
Now once this phase I negotiation is complete
|
|
0:04:53
|
the end result is going to be, whats known as the ISAKMP SA
|
|
0:04:58
|
that is going to be used to create a secured tunnel for our further negotiation
|
|
0:05:04
|
so once phase I is complete and we have the ISAKMP SA
|
|
0:05:07
|
then we go into our second phase of negotiation
|
|
0:05:10
|
which is where we were actually established in the IPSec tunnel
|
|
0:05:13
|
thats going to be used actually transport the protected data
|
|
0:05:19
|
so these two portions when we actually look at the configuration of these
|
|
0:05:22
|
on the different platforms
|
|
0:05:24
|
we will see there is different types of verification commands, different types of configurations
|
|
0:05:28
|
that we need to deal with in phase I and separately then phase II
|
|
0:05:33
|
Now just like any other layered approach in the network
|
|
0:05:37
|
like a layer3 routing protocol is not going to work unless you are
|
|
0:05:41
|
underlying layer2 switching or layer2 LAN is working
|
|
0:05:45
|
same is going to be true with IPSec
|
|
0:05:48
|
if we run into a problem in phase I negotiation
|
|
0:05:51
|
then it doesn't matter what goes on in phase II or later
|
|
0:05:55
|
as none of that is going to work without the underlying
|
|
0:05:58
|
basic negotiation
|
|
0:06:00
|
so we do need to be aware of what are the individual commands that we would issue
|
|
0:06:03
|
like the show commands the debug commands
|
|
0:06:05
|
to look at the verification of the ISAKMP SA for phase I
|
|
0:06:09
|
versus the IPSec SA for phase II
|
|
0:06:15
|
Now the first of these for phase one
|
|
0:06:18
|
there is two different protocols that we use to accomplish this
|
|
0:06:20
|
ISAKMP and IKE
|
|
0:06:23
|
these are the ones that are actually used in to form the Security Association or the SA
|
|
0:06:28
|
and they use a bi directional connection on UDP port 100
|
|
0:06:33
|
so this would then imply if I am trying to establish a VPN tunnel, an IPSec VPN tunnel between router1 and router2
|
|
0:06:40
|
and I am using ISAKMP for the negotiation
|
|
0:06:43
|
first thing I need to check is do I actually have basic IP reachability
|
|
0:06:47
|
and do I have reachablity for UDP port 500
|
|
0:06:51
|
so if there is any type of filtering
|
|
0:06:53
|
in the transit path, like an ASA or IOS firewall
|
|
0:06:57
|
we need to make sure that UDP 500 is going to work in both direction
|
|
0:07:02
|
Now when we actually look at the configuration of this
|
|
0:07:05
|
we will look at different scenarios of transitting
|
|
0:07:07
|
IPSec tunnels through things like Content Based Access Control
|
|
0:07:10
|
or zone based policy firewall
|
|
0:07:13
|
the ASA's Modular Policy Framework
|
|
0:07:15
|
and talk about some of the different design situation
|
|
0:07:18
|
on where can this reachability of UDP port 500
|
|
0:07:22
|
be a problem
|
|
0:07:24
|
when we are trying to actually establish the VPN tunnel
|
|
0:07:29
|
Now the first of these protocols ISAKMP
|
|
0:07:31
|
which is the Internet Security Association in Key Management Protocol
|
|
0:07:36
|
this is the underlying framework
|
|
0:07:38
|
that defined not specifically how
|
|
0:07:42
|
the negotiation of the tunnel
|
|
0:07:44
|
is going to happen
|
|
0:07:45
|
but from a more general perspective it says that
|
|
0:07:48
|
we need to do authentication and we need to generate encryption keys
|
|
0:07:52
|
but just that it should occur, not neccessarily how exactly it does occur, from an implementation point of view
|
|
0:07:59
|
this is where IKE comes in, or the Internet Exchange
|
|
0:08:04
|
IKE is a specific implementation
|
|
0:08:07
|
of ISAKMP
|
|
0:08:09
|
that are used to generate
|
|
0:08:10
|
the authentication keys, and the encryption keys between two different individual pairs
|
|
0:08:16
|
Now for the vast majority of our purposes
|
|
0:08:20
|
the terms ISAKMPs and IKE are generally interchangeable
|
|
0:08:24
|
but technically it is incorrect to in order to say that ISAKMP is IKE or IKE is ISAKMP
|
|
0:08:31
|
because ISAKMP again is the overall
|
|
0:08:34
|
framework that says we want to establish a tunnel
|
|
0:08:38
|
IKE is just one of the individual implementations that says, this is how I am going to do it
|
|
0:08:44
|
so you could use other implementations like Kerberos
|
|
0:08:48
|
in order to establish a tunnel through ISAKMP
|
|
0:08:51
|
but for our purposes
|
|
0:08:53
|
with the IOS, with the ASAs, with the easyVPN clients
|
|
0:08:57
|
we are going to be using IKE to accomplish it
|
|
0:09:00
|
So thats why from the vast majority of time from our perspective
|
|
0:09:04
|
someone says IKE or ISAKMP
|
|
0:09:06
|
really talking about the same thing
|
|
0:09:08
|
is just as phase I negotiation
|
|
0:09:11
|
that is going to end up with our secure tunnel
|
|
0:09:14
|
that we can then use, in order to actually exchange the IPSec keys
|
|
0:09:18
|
in order to build the encrypted tunnel or to build the authenticated tunnel
|
|
0:09:25
|
So again thats what the goal of this first phase for ISAKMP is
|
|
0:09:29
|
to figure out, are the peers that are trying to establish the tunnel, who they say they are
|
|
0:09:35
|
and once the authentication occurs
|
|
0:09:38
|
that were going to create an encryption tunnel
|
|
0:09:40
|
that is allow us, going to allow us to
|
|
0:09:42
|
to further exchange more secure information
|
|
0:09:47
|
So it gets kind of confusing sometimes the way that this is described
|
|
0:09:51
|
but ISAKMP itself does
|
|
0:09:53
|
create an encryption tunnel
|
|
0:09:55
|
then once that encryption tunnel is up
|
|
0:09:57
|
then we are going to do
|
|
0:09:59
|
more negotiations inside of that
|
|
0:10:02
|
to make sure that someone doesn't know the actual encryption or decryption case
|
|
0:10:06
|
that we are going to use for the final data transport
|
|
0:10:11
|
so again these functions of ISAKMP occur and what we define as the
|
|
0:10:14
|
phase I negotiations or the
|
|
0:10:16
|
phase I ISAKMP negotiation
|
|
0:10:18
|
and the end result is that we establish the ISAKMP Security Association or the ISAKMP SA
|
|
0:10:25
|
Now once we do this
|
|
0:10:27
|
we could then perform some additional negotiations
|
|
0:10:30
|
which is sometimes defined as phase 1.5 negotiation
|
|
0:10:34
|
for things like extended athentication or mode configuration
|
|
0:10:39
|
which are sometimes called Xauth for mode config
|
|
0:10:42
|
and generally these are going to be used for
|
|
0:10:45
|
advanced application like easyVPN
|
|
0:10:48
|
where may be I want to give the client the specific IP address
|
|
0:10:52
|
from a VPN pool
|
|
0:10:53
|
and I wanted to offer a username and password authentication for them
|
|
0:10:58
|
so these extensions
|
|
0:11:00
|
are going to happen once the basic ISAKMP Security Association is up
|
|
0:11:04
|
but before the final ipsec tunnel is created
|
|
0:11:08
|
So when we get into our remote access VPNs, we will talk a little bit more
|
|
0:11:12
|
about the phase 1.5 negotiations in detail
|
|
0:11:16
|
but in general once ISAKMP phase I is done
|
|
0:11:19
|
then we go into the actual data protection parameters
|
|
0:11:22
|
or what we define as our phase II negotiation
|
|
0:11:25
|
which the end result is the IPSec SA
|
|
0:11:29
|
this is where we actually define things like we are going to do
|
|
0:11:32
|
AES for the encryption, we are going to use md4 for the authentication
|
|
0:11:36
|
and this is what actually results
|
|
0:11:38
|
in the data plane tunnel
|
|
0:11:41
|
from the two pairs, whether it be IOS Lan-to-Lan VPN tunnel
|
|
0:11:46
|
or an easyVPN client going to an ASA running easyVPN server
|
|
0:11:53
|
Now to actually negotiate the phase I tunnel
|
|
0:11:57
|
which again is the ISAKMP SA
|
|
0:11:59
|
we need to make sure that the peers agree on different parameters
|
|
0:12:04
|
mainly there is going to be four parameters that we need to configure
|
|
0:12:08
|
make sure that the peers are actually agreeing on
|
|
0:12:10
|
the first of which is going to be
|
|
0:12:12
|
How was the tunnel authenticated
|
|
0:12:15
|
in general there is going to be
|
|
0:12:17
|
two athentication mechanism we can use
|
|
0:12:21
|
some platforms support a third
|
|
0:12:23
|
but the vast majority of them is going to be either using pre shared keys
|
|
0:12:27
|
or RSA signatures
|
|
0:12:30
|
where pre shared key is going to be, one peer saying the password is cisco, the other pair saying the password is cisco
|
|
0:12:37
|
then based on
|
|
0:12:38
|
just them having the same platform, they are both going to athenticate with each other
|
|
0:12:42
|
So similarly to how like a PPP CHAP authentication works
|
|
0:12:46
|
Now for RSA signatures
|
|
0:12:49
|
this would then be relying on an external certificate athority or a CA
|
|
0:12:54
|
to make sure that the individual peers
|
|
0:12:57
|
have signed certificate, that each other are trusting
|
|
0:13:01
|
so whether you are running your own internal certificate authority server
|
|
0:13:05
|
or whether they are
|
|
0:13:07
|
a publicly assigned to someone like verisign or entrust
|
|
0:13:11
|
we would make sure that all of the end points trust these certificate authority
|
|
0:13:15
|
then based on the
|
|
0:13:17
|
the PKI, the
|
|
0:13:20
|
the public keys and the private keys
|
|
0:13:23
|
of the certificate authority
|
|
0:13:24
|
we would be able to find out that the peers are actually who they say they are
|
|
0:13:30
|
there is another version of this, that is RSA encryption
|
|
0:13:33
|
or sometimes called the RSA encrypted ??
|
|
0:13:37
|
that some versions of cisco RSAs support
|
|
0:13:41
|
but we will that the ASA does not support this
|
|
0:13:43
|
the easyVPN client does not support this
|
|
0:13:46
|
So this is more of a legacy mechanism that you can do manual RSA keys
|
|
0:13:52
|
but again the vast majority of time, its going to be one of the first
|
|
0:13:55
|
of these two methods, either preshared keys or RSA signatures
|
|
0:14:02
|
once we agree on the authentication mechanism
|
|
0:14:05
|
then we need to figure out how are we going to encrypt the phase I tunnel or ISAKMP tunnel
|
|
0:14:10
|
and this can be done with either DES or 3DES or AES
|
|
0:14:16
|
you will see some
|
|
0:14:17
|
platforms are going to support different versions
|
|
0:14:20
|
of these protocols like different key length of AES
|
|
0:14:24
|
and generally its going to depend on the version of code
|
|
0:14:27
|
that particular platform is running
|
|
0:14:31
|
then we have the hashing algorithm
|
|
0:14:34
|
which is going to be used for the integrity check
|
|
0:14:37
|
to make sure that the packet is not changed
|
|
0:14:39
|
from the source to the destination
|
|
0:14:41
|
and we have two variation of this, the md5 hash and the SHA hash
|
|
0:14:48
|
now both md5 and SHA are one way hashing or one way encryptions
|
|
0:14:54
|
where something like 3DES or AES
|
|
0:14:57
|
is a reversible encryption
|
|
0:14:59
|
which means that you have your encryption key and you have your decryption key
|
|
0:15:03
|
but in the case of hashing algorithms
|
|
0:15:05
|
it is a one way function
|
|
0:15:08
|
takes some sort of clear text input
|
|
0:15:10
|
run it through md5
|
|
0:15:12
|
and then I result in a fixed length output
|
|
0:15:15
|
so to make sure that my clear text input which essentially is the packet
|
|
0:15:20
|
and goes into md5 or goes into SHA
|
|
0:15:22
|
I come out with an md5 hash or an SHA hash
|
|
0:15:26
|
if on the other side their hash matches mine
|
|
0:15:29
|
then it basically means that no one has modified the packet in the
|
|
0:15:32
|
the transit path
|
|
0:15:35
|
Now the main difference between these two
|
|
0:15:37
|
is that md5 uses a shorter
|
|
0:15:40
|
length key
|
|
0:15:41
|
then SHA does
|
|
0:15:43
|
So SHA is a little bit more
|
|
0:15:45
|
secure than md5
|
|
0:15:47
|
but as you can imagine since you it uses a longer key length
|
|
0:15:50
|
SHA is going to be more processor intensive than md5 is
|
|
0:15:54
|
Same would be true of AES versus 3DES versus DES
|
|
0:15:59
|
where AES, since it uses longer key lengths
|
|
0:16:01
|
its going to be more processor intensive that 3DES or DES
|
|
0:16:09
|
then lastly we have the Diffy Halman group, or DH group
|
|
0:16:13
|
which generally is going to be number 1, 2 or 5
|
|
0:16:17
|
depending on the platform you may see some other additional variations for this
|
|
0:16:21
|
but essentially what this controls
|
|
0:16:24
|
is the actual encryption and decryption key
|
|
0:16:27
|
that is then used for the actual encryption algorithm
|
|
0:16:34
|
So the larger the Diffy Halman group is
|
|
0:16:38
|
controls how large of a value can we use for
|
|
0:16:42
|
a pseudo random prime number
|
|
0:16:45
|
thats used with the DH function
|
|
0:16:49
|
that basically figures out
|
|
0:16:50
|
how random is the encryption key going to be
|
|
0:16:53
|
So the larger the Diffy Halman group which
|
|
0:16:56
|
means the larger the prime number
|
|
0:16:58
|
it means you have more possibilities for figuring out what the
|
|
0:17:01
|
the encryption and the decryption key is
|
|
0:17:04
|
So just like the md5 versus the SHA
|
|
0:17:07
|
SHA is using longer key length, so its going to be more processor intensive
|
|
0:17:12
|
Diffy Halman group 5 is going to use
|
|
0:17:14
|
a larger pseudo random number
|
|
0:17:17
|
than group 2 or group 1
|
|
0:17:20
|
so its going to be more secure but its going to be more processor intensive
|
|
0:17:28
|
Now the combination of these parameters
|
|
0:17:31
|
that were using for the ISAKMP SA
|
|
0:17:33
|
this is what makes up what we define as the ISAKMP policy
|
|
0:17:38
|
Now once we agree on what the ISAKMP policy is
|
|
0:17:42
|
the peer that is starting the
|
|
0:17:44
|
IKE tunnel or the IPSec tunnel
|
|
0:17:46
|
its called the IKE initiator
|
|
0:17:49
|
they are going to send this policy to the remote peer
|
|
0:17:52
|
through what we call the proposal process
|
|
0:17:54
|
there are basically going to say, these are the different values that I support
|
|
0:17:58
|
for my phase I negotiation
|
|
0:18:01
|
may be I am going to have pre shared keys
|
|
0:18:03
|
with single DES encryption, md5 and Diffy Halman group 2
|
|
0:18:08
|
if you agree on this
|
|
0:18:10
|
then you as the responder are going to say, yes I accept your proposal
|
|
0:18:13
|
or no I reject the proposal because may be I don't support md5
|
|
0:18:17
|
may be I am only going to run SHA
|
|
0:18:21
|
Now we will see the key as that when we actually configure the tunnels
|
|
0:18:25
|
the IPSec peers
|
|
0:18:26
|
can offer multiple
|
|
0:18:28
|
ISAKMP policies through an individual proposal process
|
|
0:18:33
|
where may be I have 10 different policies configured
|
|
0:18:36
|
and which ever the first of these 10 policies that matches that you will accept
|
|
0:18:41
|
thats where you are going to respond back with and say yes I will use
|
|
0:18:44
|
RSA signatures and yes I will use AES, SHA and Diffy Halman group 5
|
|
0:18:51
|
Now configuration wise
|
|
0:18:53
|
we will see since multiple policies are sent through the proposal process
|
|
0:18:57
|
there is going to be an issue with the order of operations
|
|
0:19:01
|
of how the ISAKMP policies are actually defined
|
|
0:19:05
|
where typically we would want the most secure policy at the top
|
|
0:19:10
|
and the lesser secure policy down towards the bottom
|
|
0:19:14
|
but we will take a look at that when we actually look at the configuration and verification
|
|
0:19:18
|
the key point to remember is that the order of the ISAKMP policies does matter
|
|
0:19:25
|
Now inside this actual proposal process
|
|
0:19:28
|
there is two different ways that the
|
|
0:19:30
|
the actual negotiation can occur
|
|
0:19:33
|
they are called main mode and aggressive mode
|
|
0:19:37
|
the first one for main mode
|
|
0:19:39
|
uses six different messages for the negotiation
|
|
0:19:43
|
so the initiator sends the request to the responder, responder sends respond back
|
|
0:19:48
|
back and forth six times in order to negotiate
|
|
0:19:51
|
the final proposal
|
|
0:19:54
|
Now this takes longer to negotiate
|
|
0:19:56
|
then the aggressive mode
|
|
0:19:58
|
because we are using more messages than the other else
|
|
0:20:02
|
but the main advantage of this
|
|
0:20:04
|
is that it hides the party's identities
|
|
0:20:07
|
before the final ISAKMP security association is established
|
|
0:20:13
|
or as with the aggressive mode
|
|
0:20:14
|
it uses only three messages for the negotiation
|
|
0:20:18
|
which means that it takes less time to negotiate
|
|
0:20:21
|
but the disadvantage is that it does not hide the party's identities
|
|
0:20:25
|
and the reason you would want to use one versus the other
|
|
0:20:29
|
is with aggressive mode
|
|
0:20:31
|
this is going to give us some more flexibility
|
|
0:20:33
|
when we are trying to do individual attributes
|
|
0:20:36
|
that are based on the users authentication
|
|
0:20:40
|
and typically this is done with easyVPN deployments
|
|
0:20:44
|
where based on the username and password
|
|
0:20:48
|
that the individual VPN user is giving to the server
|
|
0:20:51
|
thats going to control,
|
|
0:20:52
|
what are the individual ISAKMP parameters
|
|
0:20:55
|
and the individual IPSec parameters
|
|
0:20:58
|
that user is supposed to get
|
|
0:21:02
|
Now if we were to compare this to the actual main mode negotiation
|
|
0:21:05
|
the first of these messages are when the initiator sends the responder
|
|
0:21:10
|
these are the individual ISAKMP policies that I support
|
|
0:21:14
|
So I am proposing this particular
|
|
0:21:17
|
hash value, this particular ciper which would be the encryption
|
|
0:21:20
|
this particular Diffy Halman group
|
|
0:21:23
|
then the responder is going to say
|
|
0:21:26
|
either or yes, I agree on this particular proposal or No, I do not agree
|
|
0:21:32
|
then we actually go through the
|
|
0:21:35
|
the Diffy Halman key exchange
|
|
0:21:37
|
which is going to be again to
|
|
0:21:39
|
generate the
|
|
0:21:41
|
the actual encryption and decryption keys
|
|
0:21:46
|
the responder says, yes, I am also going through the Diffy Halman exchange
|
|
0:21:50
|
the result of this is that the ISAKMP Security Association is created
|
|
0:21:55
|
Now once the ISAKMP SA is there
|
|
0:21:58
|
we can encrypt packet going over the tunnel
|
|
0:22:00
|
either using 3DES or AES
|
|
0:22:03
|
whatever we decided on in the actual ISAKMP proposal process
|
|
0:22:08
|
but only once this tunnel is up
|
|
0:22:10
|
do we then go into the athentication
|
|
0:22:13
|
where the initiator is going to send their identity
|
|
0:22:16
|
whether this be a
|
|
0:22:18
|
a hostname or whether it would be a certificate
|
|
0:22:22
|
then the responder is going to say
|
|
0:22:24
|
either yes authentication is correct or no authentication is bad
|
|
0:22:28
|
and then we can proceed on from there
|
|
0:22:32
|
but the key point being is that we don't
|
|
0:22:34
|
exchange
|
|
0:22:36
|
the hostnames or we don't exchange the certificates
|
|
0:22:38
|
until the actual ISAKMP SA is created
|
|
0:22:42
|
where as when we compare this to the aggressive mode
|
|
0:22:46
|
an aggressive mode for the first initiation
|
|
0:22:50
|
we send them the ISAKMP poilcies
|
|
0:22:53
|
through the proposal process
|
|
0:22:54
|
but we also send them our identity immediately
|
|
0:22:58
|
which would be things like the
|
|
0:23:00
|
the VPN tunnel group
|
|
0:23:02
|
in the case of easyVPN, the username and password
|
|
0:23:07
|
which is then going to control
|
|
0:23:09
|
when the responder says the particular proposal that I accept
|
|
0:23:15
|
it can be based on the initiaters identity
|
|
0:23:18
|
so at this point we don't have the security association established yet
|
|
0:23:22
|
because we now start to go through the Diffy Halman key exchange
|
|
0:23:25
|
then the initiator responds
|
|
0:23:28
|
says we now agree on the Diffy Halman exchange
|
|
0:23:49
|
but the reason it is important to mention the differences between them
|
|
0:23:45
|
with a lot of granularity are you going to use main mode or are you going to use aggressive mode
|
|
0:23:42
|
you can't really control
|
|
0:23:39
|
Now we will see, when we actually get into the implementation
|
|
0:23:31
|
Now the ISAKMP SA is up
|
|
0:23:33
|
and now the full authentication is complete
|
|
0:23:54
|
is that when we look at the verification
|
|
0:23:57
|
with the different show commands, with the different debug commands
|
|
0:24:00
|
we would want to know, are we trying to
|
|
0:24:02
|
use main mode versus aggressive for this individual tunnel
|
|
0:24:06
|
because the work
|
|
0:24:09
|
flow when we are at the six messages for a negotiation versus the three
|
|
0:24:13
|
is going to be different
|
|
0:24:15
|
what are we using, main mode versus aggressive mode
|
|
0:24:20
|
So next once our ISAKMP SA is done negotiating through phase I
|
|
0:24:25
|
Now we go into phase II
|
|
0:24:26
|
which is designed to generate the IPSec
|
|
0:24:29
|
SA or the IPSec Security Association
|
|
0:24:33
|
just like in phase I, we need to agree
|
|
0:24:35
|
on some of the different parameters that we are going to use
|
|
0:24:38
|
and the most important one of these
|
|
0:24:40
|
is going to be how are we going to do the encryption
|
|
0:24:43
|
and how are we going to do the authentication
|
|
0:24:47
|
this is where the peers will decide, Are we going to use ESP versus AH?
|
|
0:24:52
|
Are we going to use md5 versus SHA?
|
|
0:24:55
|
if we are doing encryption
|
|
0:24:57
|
are doing DES, 3DES, AES
|
|
0:25:00
|
you also see someother
|
|
0:25:02
|
platforms support different types of encryption
|
|
0:25:05
|
like CO is another method
|
|
0:25:08
|
and we are also going to decide are we running IPSec
|
|
0:25:10
|
in tunnel mode versus transport mode
|
|
0:25:15
|
Now as we go through our different configurations, we will look at these at more detail
|
|
0:25:19
|
what is the result of an ESP tunnel
|
|
0:25:22
|
thats in tunnel versus transport mode
|
|
0:25:25
|
whats the result of Authentication Header in tunnel mode versus transport mode
|
|
0:25:29
|
but all of these options are going to be negotiated during our phase II exchange
|
|
0:25:35
|
the peers will also have to agree on whats known as the proxy identities
|
|
0:25:40
|
which is going to define what is the actual traffic that is supposed to go into the tunnel
|
|
0:25:46
|
which is also sometimes called the proxy ACL
|
|
0:25:49
|
So this is when the routers are defining
|
|
0:25:51
|
I want traffic from my local VLAN 10 going to remote VLAN 20
|
|
0:25:56
|
to go into the tunnel
|
|
0:26:00
|
the peers are also going to negotiate the
|
|
0:26:03
|
security association lifetime or the SA lifetime
|
|
0:26:07
|
that is going to control
|
|
0:26:08
|
after what period of time, do we have to renegotiate
|
|
0:26:11
|
phase II or do we have to renegotiate
|
|
0:26:13
|
the phase I
|
|
0:26:17
|
Now phase II uses whats known as
|
|
0:26:19
|
quick mode negotiation
|
|
0:26:22
|
in order to establish the phase II IPSec SA
|
|
0:26:25
|
and the reason why
|
|
0:26:26
|
is that during phase I
|
|
0:26:28
|
we already did athentication
|
|
0:26:31
|
So authentication already occurred, we already have the encrypted tunnel
|
|
0:26:35
|
that was generated with the ISAKMP SA
|
|
0:26:38
|
So there is only two basic messages that are needed
|
|
0:26:41
|
for the actual IPSec SA establishment
|
|
0:26:44
|
its the initiator saying
|
|
0:26:46
|
this is the proposal that I am giving you
|
|
0:26:49
|
this is the Diffy Halman Key exchange that we are going to do
|
|
0:26:52
|
these are the proxy identities
|
|
0:26:54
|
where I want to encrypt traffic from segment A going to segment B
|
|
0:26:59
|
then the responders going to send us respond saying
|
|
0:27:02
|
this is the Security Association that I selected
|
|
0:27:06
|
so based on your proposal
|
|
0:27:08
|
may be you offered ESP and I accepted it
|
|
0:27:11
|
and you offered ESP with md5 and 3DES
|
|
0:27:16
|
We also do the Diffy Halman key exchange again
|
|
0:27:21
|
which means that for the phase I tunnel of ISAKMP
|
|
0:27:25
|
we are using different
|
|
0:27:27
|
encryption keys and decryption keys
|
|
0:27:30
|
than the phase II IPsec SA
|
|
0:27:35
|
Now once we have both of these tunnels established, the phase I and phase II
|
|
0:27:40
|
eventually the security associations are going to timeout
|
|
0:27:43
|
because they have a limit to how long they could be up
|
|
0:27:47
|
whether this is based on a time value
|
|
0:27:49
|
or whether its based on a
|
|
0:27:51
|
an actual data exchange value, like a kilo byte
|
|
0:27:54
|
total value before we have to reset the SA
|
|
0:27:58
|
Now once the SA actually expires
|
|
0:28:01
|
the peers are going to try to re
|
|
0:28:03
|
key or re establish the security association
|
|
0:28:06
|
and again, as I mentioned the lifetime can be either in
|
|
0:28:09
|
time or it can be in a bit value or a byte value
|
|
0:28:15
|
this value technically does not need to match between the peers
|
|
0:28:19
|
which every has lower of the request values, is going to be chosed
|
|
0:28:24
|
so if you say that your lifetime, you want it to 5 hours
|
|
0:28:27
|
but I say I want my life to be 30 minutes
|
|
0:28:30
|
we are going to choose the 30 minute
|
|
0:28:33
|
so regardless of whether you the initiator or you are the reciever
|
|
0:28:36
|
we are always going to choose what the lower value
|
|
0:28:40
|
Now this is also where we would need to take into account
|
|
0:28:43
|
are we running what is known as perfect forward or pss
|
|
0:28:49
|
Now PFS is requested as part of the quick mode negotiation
|
|
0:28:54
|
for the phase II IPSec Security Association
|
|
0:28:57
|
that says when I rekey
|
|
0:29:00
|
the IPSEc SA
|
|
0:29:03
|
So when the lifetime times out and I need to re establish a new encryption key
|
|
0:29:07
|
am I going to rerun the Difffy Halman exchange to generate new keying material
|
|
0:29:14
|
or am I going to use the DH exchange that we run originally
|
|
0:29:19
|
Now when perfect forward secrecy is on
|
|
0:29:22
|
It means that your IPSec SA, once it is rekeyed
|
|
0:29:26
|
the encryption and decryption key are completed independent from the previous one
|
|
0:29:32
|
where the idea behind this is that its going to be more secured
|
|
0:29:36
|
but at the expense of the CPU resource
|
|
0:29:39
|
because you actually have to calculate what are the large prime numbers
|
|
0:29:42
|
and then go through the step by step exchange to result in the encryption and decryption keys
|
|
0:29:49
|
but the again behind this is that if some were to compromise one of the keys
|
|
0:29:54
|
they would not be able to figure out the subsequent
|
|
0:29:57
|
encryption and decryptions
|
|
0:30:02
|
Now there is another portion of our phase II negotiation
|
|
0:30:06
|
the peers need to decide
|
|
0:30:08
|
what is the specific security protocol that we are going to actually use
|
|
0:30:12
|
for the tunnel
|
|
0:30:13
|
and there is two main protocols that we support
|
|
0:30:15
|
the Authentication Header or AH
|
|
0:30:18
|
and the encapsulating security payload or ESP
|
|
0:30:23
|
and again this is negotiated during phase II
|
|
0:30:26
|
through what we define as the transformed set
|
|
0:30:30
|
where we would define
|
|
0:30:31
|
we want ESP with md5 and ESP with 3DES
|
|
0:30:36
|
or AH with SHA
|
|
0:30:40
|
Now the difference between them
|
|
0:30:43
|
first and foremost is that with authentication header
|
|
0:30:46
|
we are using a different transport
|
|
0:30:48
|
than we are using with ESP
|
|
0:30:50
|
where AH uses IP protocol number 51
|
|
0:30:54
|
ESP uses IP protocol number 50
|
|
0:30:58
|
so they are separate
|
|
0:30:59
|
Non comparable header format
|
|
0:31:02
|
if I peer is using AH the other peer cannot use ESP
|
|
0:31:06
|
we have the agree on using one or the other, not both of them at the same time
|
|
0:31:11
|
Now as for the individual features
|
|
0:31:14
|
authentication header supports authentication
|
|
0:31:17
|
as does ESP
|
|
0:31:19
|
AH also supports the integrity checking
|
|
0:31:22
|
as does ESP
|
|
0:31:25
|
but ESP also supports the inspection and the anti-reply
|
|
0:31:32
|
so again the key difference between these is that AH only supports authentication
|
|
0:31:38
|
and based on this
|
|
0:31:39
|
its rarely used for IPSec VPN deployment
|
|
0:31:44
|
so things like a LAN-to-LAN VPN tunnel
|
|
0:31:46
|
or
|
|
0:31:48
|
its less likely that you would use AH
|
|
0:31:51
|
because we don't support encryption, we only support authentication
|
|
0:31:57
|
Now there are still legitimate users for AH
|
|
0:32:00
|
one of them, that is very common, is with OSPF version 3
|
|
0:32:05
|
for IPv6 routing this what we would use for our
|
|
0:32:11
|
where as ESP, since it supports both encryption and the authentication
|
|
0:32:15
|
this is going to be the preferred method for the vast majority of the IPSec VPN
|
|
0:32:21
|
we will also see that the easyVPN client
|
|
0:32:25
|
that runs on your end workstation
|
|
0:32:28
|
it only supports ESP
|
|
0:32:30
|
because the idea behind the VPN client is that you want to support encryption not just the authentication
|
|
0:32:39
|
Now each of these two protocols
|
|
0:32:41
|
both Authentication Header and ESP
|
|
0:32:44
|
support two different modes of encapsulation
|
|
0:32:47
|
that are known as tunnel mode and transfer mode
|
|
0:32:51
|
Now in transport mode
|
|
0:32:54
|
regardless of whether we running ESP or AH
|
|
0:32:57
|
the original IP header is going to be maintained
|
|
0:33:02
|
only the payload of the packet
|
|
0:33:04
|
like if we are doing web browsing it would be our tcp
|
|
0:33:08
|
layer4 header
|
|
0:33:10
|
then down to the actual application payload
|
|
0:33:12
|
that is where the athentication and that is where the encryption would occur
|
|
0:33:18
|
typically this is used in a host to host IPsec environment
|
|
0:33:23
|
where may be you have
|
|
0:33:25
|
multiple windows machine on the LAN
|
|
0:33:27
|
that are running IPSec directly with each other
|
|
0:33:31
|
we would be using transfer mode as opposed to tunnel mode
|
|
0:33:34
|
we will also see this is used in some cases with
|
|
0:33:37
|
other tunnelling mechanisms like GRE tunnels
|
|
0:33:42
|
specifically when we are running Dynamic Multipoint VPN or DMVPN
|
|
0:33:47
|
we would be running IPSec in transfer mode as opposed to the tunnel mode
|
|
0:33:53
|
Now with tunnel mode
|
|
0:33:55
|
we are adding a new IP header
|
|
0:33:59
|
taking the original header and the original payload
|
|
0:34:02
|
and that is whats going to be authenticated and that is whats going to be encrypted
|
|
0:34:07
|
So this is the more typically application when we are thinking of the actual VPN tunnel
|
|
0:34:12
|
between IPsec gateways like a LAN-to-LAN tunnel
|
|
0:34:16
|
or the easyVPN client
|
|
0:34:18
|
they are going to be running
|
|
0:34:20
|
IPsec in tunnel mode as opposed to the tranport mode
|
|
0:34:25
|
Now if we were to visualize the differences between them
|
|
0:34:28
|
when we look at Authentication Header
|
|
0:34:31
|
and we have our original IP packet
|
|
0:34:34
|
we have the
|
|
0:34:36
|
the IP header
|
|
0:34:38
|
thats followed by our actual payload, like in this case, its TCP
|
|
0:34:42
|
followed by the actual data
|
|
0:34:44
|
if we were to run in transport mode
|
|
0:34:48
|
we would be inserting the authentication header
|
|
0:34:51
|
between the original header
|
|
0:34:53
|
and the original payload
|
|
0:34:57
|
so like the name implies, Authentication Header, its just a header that is added, on this, you know
|
|
0:35:01
|
trailer, for a full encapsulation
|
|
0:35:06
|
if we were to run in tunnel mode
|
|
0:35:09
|
we would take the original IP header
|
|
0:35:12
|
add the authentication header on top of that
|
|
0:35:14
|
then add a new outer IP header
|
|
0:35:18
|
and this is where
|
|
0:35:19
|
the authentication
|
|
0:35:21
|
is going to occur
|
|
0:35:23
|
where within transport mode, the authentication occurs just on the original payload
|
|
0:35:28
|
in tunnel mode its going to occur on the original IP header plus the original payload
|
|
0:35:34
|
if we were to compare this to ESP
|
|
0:35:37
|
where again we have our normal layer3 header followed by layer4 and beyond
|
|
0:35:42
|
for transport mode
|
|
0:35:44
|
we are inserting the new header
|
|
0:35:46
|
and the new trailer
|
|
0:35:49
|
between the original header
|
|
0:35:51
|
and the original payload
|
|
0:35:54
|
whereas in tunnel mode, we have the
|
|
0:35:57
|
new IP header, the ESP header
|
|
0:35:59
|
the original IP header
|
|
0:36:01
|
the payload and then the trailer
|
|
0:36:05
|
where in the case of transport mode
|
|
0:36:08
|
this is where the authentication and the encryption occurs
|
|
0:36:12
|
and in tunnel mode, this is where the authentication and encryption occurs
|
|
0:36:19
|
So you could see just by visualizing the difference between AH and ESP
|
|
0:36:23
|
the advantage of using ESP is that we do support the encryption
|
|
0:36:28
|
but the advantage of AH is that its a more lightweight encapsulation
|
|
0:36:33
|
we have just the small header, we don't have an additional trailer
|
|
0:36:37
|
so when we are looking at the actual processing
|
|
0:36:40
|
to athenticate AH versus to decrypt or encrypt ESP
|
|
0:36:44
|
AH is going to take less CPU overhead
|
