Alright, so we just covered IKEv1's main mode in some pretty good detail.
Now we're going to talk about its sibling, IKEv1 aggressive mode.
In aggressive mode, the conversations between the devices are little different.
There aren't three different conversations or exchanges happening anymore.
What happens in aggressive mode is that the devices
cram as many items as possible, just about all,
into the first conversation.
Things like the Diffie-Hellman key and the identity of
the device are in that exchange.
Then the other end does the same and sends the same items back,
which finishes the process.
The SA is then built, and IPsec SAs are ready to be defined and established.
Using aggressive mode has its flaws though.
Sure, it's a bit quicker when it comes to SA establishment,
but speed is not everything.
If we're sending almost all of the information needed to
establish the secure connection in one exchange,
then how is it secured?
At least in main mode you don't have the ability to have someone sniff the
traffic and determine who's initiating the IKE conversations.
Since main mode uses more than one exchange,
some added security is present there.
This here is a huge security risk and poses a severe threat to infrastructures.
This mode is very exploitable and should not be used whenever
possible if you are choosing to use IKEv1.
So we can see it in action and analyze this information for ourselves,
let's get into the lab and start configuring.
We're going to be talking about configuring and analyzing what
the heck is going on in aggressive mode so we can see the
differences between this and main mode.
Here we're not going to use DMVPN,
and we'll configure the connections using crypto maps on our g0/1 interfaces.
This is by far the least efficient method of configuring an
IPsec connection between two devices.
I'm using this configuration here to ensure that we
have the proper protection in place.
With a crypto map, we set the peers and transform sets,
and using this access list and match statement,
we define what our interesting traffic is.
Here, I'm just using a permit IP any any,
which should not be used in a production environment at all if you
care about the functionality of your network.
You would typically define exactly what traffic you want
to be sent using the crypto map here.
For a lab environment though and just for showing how this ISAKMP mode works,
it'll be okay.
We also are defining some additional information
within the ISAKMP configuration here.
We have some extra configuration items from the previous labs in here still,
but that's okay.
It's this line with the ISAKMP key that's from the DMVPN configuration.
The isakmp peer address command,
along with setting the aggressive mode password and
our own IP address are what's new,
as well as this crypto map config for the IPsec section.
It's the same on the Site1 router too, just with different IP addresses.
I'm turning on the capture now so that we can see the packets
after we put the configuration in here.
We'll go ahead and speed up while we copy and paste
the configurations into the routers.
As always, I'm doing a ping test to verify connectivity,
and it looks like it's working.
We can ping through.
Our show crypto isakmp sa command shows that were good in this negotiation,
and let's stop on this ipsec sa show command so that
we can see what's going on here.
Here,
you notice that the interface that we applied the configuration to is
shown and that the name of the crypto map is tagged.
We have the same local and peer information is always as well.
We have our inbound and outbound ESP information,
including the individual SPIs and can also see the status of these as active.
Now I want to download the capture so that we can see how
the packets are acting and reacting.
Pulling up the capture and scrolling down,
you see we only have three packets exchanged for aggressive mode
compared to the six that we had before for main mode.
Let's expand these to get insight into all this information
that's being shared in that one packet.
As you can see here, it designates the exchange as aggressive mode.
We see many more payloads in here than what we saw
in the main mode exchanges too, but with a lot of the same information.
During aggressive mode,
we're cramming the security association negotiation parameters,
the NAT-T payloads, the key exchange, nonce,
and the identification information all into this one packet exchange.
The next packet, the responders, does the same.
They send the proposals and responses to the proposals in
here with all of the other information.
Can you think of how it could be a security risk or what you could
do with this information if you sniff the wire?
Let me know in the course comments or in social media.
The final packet from the initiator is the verification of the authentication
hashes and the establishment of the SAs in a secure manner.
Now that that's done after only three packets,
phase 2 can start, and we'll be well on our way to seeing the ESP encapsulation in use.