So the first benefit I want to talk about is the added
reliability that IKEv2 provides us.
IKE version 2 gives us the ability to provide this crucial benefit using a
message flow system containing requests and responses.
Since this flow ensures that message exchanges occur in pairs,
then we know that these devices will be able to ensure reliability.
The initiator sends the request,
and it is up to them to be responsible for the reliability.
They're supposed to either retransmit the request or drop
the connection to the peer if they don't receive a reply
back from the previous request.
Using this method,
you either have the IKEv2 connection established and being reliable,
or you drop the connection and move on.
IKEv2's Mobility and Multihoming protocol,
or MOBIKE, gives us the special ability for remote access users.
What this added benefit for using IKEv2 does for us is that it keeps our VPN
connection active when moving from one IP address to another.
This allows for the mobility that we desire in today's
world while keeping the security intact.
MOBIKE is also great for redundancy in enterprise environments.
Let's say you have a multihomed host for your VPN connection.
When an interface goes down on it,
traditionally the VPN connection would go down too.
With MOBIKE, that doesn't happen.
You can essentially use it to move the traffic to another
one of the interfaces that is working, thus keeping your connection alive.
Now that that form of redundancy is done,
let's talk about high availability, or HA.
Let's say you have multiple VPN gateways that your clients are connecting to.
What happens when you need to take one down for maintenance?
Or what about when it gets overloaded with connections and needs to
share the load so its performance won't be impacted?
Well,
IKEv2 has redirect mechanisms built into it so that
you can help with these issues.
This is all based on your configuration as far as the
times and methods used for redirection.
So let's say that your interface dies and the connection can't stay on it.
You can have the VPN head in, send a redirect message to the clients,
and have it select their new gateways if you need to do this.
The redirect will be used to migrate the traffic over
to the other VPN termination device,
and it gives flexibility with the connections so
that you can support more uptime.
Prior to IKE version 2,
the only way to choose what traffic is tagged to protect via
the VPN tunnel was through the use of source and destination IP
and ports or which protocol it is.
With this,
both devices needed to agree on the exact ones being
sent through the individual SA.
IKEv2 gives us a little more flexibility with this.
It was built to allow more than one combination of these parameters in each SA.
What this means for us is that we're able to send multiple types of
traffic through each tunnel or SA at the same time,
including both IPv4 and IPv6 traffic.
This is huge for migrating your network to IPv6 if you haven't already done so.
The next benefit that this has over IKEv1 is the ability to
create multiple SAs using the same IP range,
port, and protocol combinations amongst the devices.
This is through the use of something called identities.
Within the IKEv2 payload,
the optional IDR payload data chooses which identities the initiator
wants to talk to based on the information provided.
It gives us the ability to create multiple SAs going to the same
IP address that's hosting multiple identities.
This way, they can only talk to the identities that they choose through the SA,
and you get more flexibility within the protocols.
The final huge benefit that I want to talk about is the SA lifetime option.
The lifetime setting gives you the ability to locally
configure the IKEv2 SA lifetime.
This occurs on both ends of the link, not just one.
With IKEv1, two peers will negotiate and agree upon the lifetime setting,
so both would expire at the same time essentially.
IKEv2 changes this by locally configuring it.
Within IKEv2, these settings can have different values,
so each end would either rekey or terminate the SA at different times.
This gives us the ability to define which end of the link has to initiate the rekeys and/or terminate the connections.