One of the two modes that IKE phase 1 uses is called main mode.
We're going to detail this during this clip and see
it in action so we can analyze it.
Main mode exchanges a bunch of packets back and forth to exchange all of the
parameters and information needed to establish the first SAs.
These are called the ISAKMP SAs in some interpretations.
Main mode gives us three different two-way conversations between the
devices participating in IKE phase 1 negotiations.
During the first conversation,
the devices verify which algorithms and hashes will be used
in the IKE SAs that are being established.
During this exchange, multiple proposals can be sent by the initiator,
and the responder essentially chooses one and sends it
in the reply for these parameters.
These are known as the ISAKMP SA attributes.
The second conversation is all about the keys.
It's used to generate the keys that will verify and prove their identities.
Finally, in the third conversation, the identities are actually verified,
and the IKE SAs are established,
and the signatures are verified so that the tunnels can
be used further on in the process.
With the successful establishment of these SAs,
the next phase is able to get under way so that we can use IPsec.
I want to dig into the main mode establishment and see the operations in
progress so that we can analyze what was happening.
During this demo, we'll configure and analyze the IPsec tunnels using main mode.
We'll start out with the configuration and testing of main mode.
Then,
we're going to analyze the packets so that we can see what's going on
with this configuration and how the SAs are established.
Then, we'll move along and talk about the other phase 1 mode.
We're starting these IKEv1 demos off with the main
mode configuration and analysis.
As you can see here,
we're back to our basic DMVPN configuration with the
IPsec configs that we used previously.
I changed the age protocol to ESP so that we can get our encryption going again.
Looking at this config, we're using AES,
SHA-256, and pre-shared keys, and we're doing this in tunnel mode.
Before we copy-paste these configurations into the devices so that we
can secure the connections between the two sites,
we're going to turn on our packet capture so that we can do the
analysis and see the exchanges for main mode.
Now that that's done,
let's go ahead and copy-paste the configs into the devices and get it working.
The HQ router is first,
and it gives us the thumbs up saying ISAKMP has turned on now.
And the same for Site1 router.
We're good to go.
Of course,
I'm doing a ping test to be able to ensure that the
link is fully up and operational,
which it is based on my five replies coming back.
Doing a show crypto ipsec sa command,
we see that the tunnel is functioning with the Tunnel0 interface
being the one that the SAs are applied to.
We also see that our packets are being encapsulated and decapsulated,
as well as encrypted and decrypted.
Our ISAKMP SAs also look normal with the QM_IDLE state telling
us that we have our full SAs established.
Now that that's all working as expected with main mode,
which is the default mode for many different
applications and vendor implementations,
we can go in and download our capture for analysis.
Alright, pulling up the Wireshark capture so that we can see what's going on,
in the beginning of the IPsec connections we have those ISAKMP
packets that we've seen before in the lab.
Notice that there are six packets here that we capture before the mode switches.
These first six packets are the three main mode
exchanges that we discussed earlier.
The subsequent quick mode packets are for phase 2,
which we'll dig into later on.
Let's check out this first exchange and see what's going on.
Here,
you can see that our initiator already designated an SPI for
this particular SA that's being established and has some
payloads that it's sending over to the peer.
This security association payload is what gives us a lot of the
information that we want to help us establish those initial SAs.
Drilling down into this datagram,
we have a proposal here designating the ISAKMP protocol to be used.
Looking at the payload inside, we have some IKE attributes here.
This is one proposal out of many that could be sent to
negotiate these initial parameters.
Look,
we're using standard AES with SHA for our hashing algorithm
and pre-shared keys for the authentication.
Remember, there can be many proposals sent in the first exchange,
and the responder gets to pick one to use moving forward out of those.
The proposals are those sets of algorithms and parameters so they know how to
hash and authenticate the keys being sent for authentication.
Looking at the second packet in the exchange,
the responder fills out their SPI for this SA and includes in
the payload information which proposal, if there were multiple,
will be used.
It does this by resending the IKE attributes agreed upon in the SA payload.
Since both devices are compatible with these
parameters and only one proposal was sent,
they're agreeing on it.
The next exchange is all about the keys.
Here's where the nonce is set along with the exchange data.
The nonce is randomly generated data that's hashed with the
other items used for authentication and is crucial to the
anti-replay protections that IPsec provides.
This data can't be predicted since it's random data.
These are the two most important payloads here since
it contains all of the key data.
The responders packet contains the same payloads and
fields with the data being different within the packet
since it's unique to that device.
The next exchange is number three,
where the peers are authenticated and the essays are established.
As you can see here, we're already encrypting some data within this exchange. This is good since the next phase is all about establishing that IPsec SA.