- [Instructor] In this video,
we want to talk about EIGRP authentication.
Before we get into the EIGRP specific discussion though,
let's talk about authentication in general.
After all, we've got a lot of routing protocols
that can dynamically form neighborships.
So what's to prevent a malicious user
from plugging their router into the network
and forming neighborships with our existing routers?
They might corrupt our routing table,
they might force traffic to flow through their router,
where they would capture it.
Well the way to prevent that is through authentication.
And we've got two basic types.
We've got plain text authentication,
and we have hash based authentication.
First, let's consider plain text authentication.
Consider this topology,
we've got R1 and R2 using plain text authentication,
which means they each have a local key configured on them.
And let's say R1 wants to send a routing update to R2,
well included with that routing update
is that local key,
and router R2 is going to ask, do these keys match?
If we do have a match,
then that routing update is going to be accepted.
However, if we have a malicious user
connect with their router to the network
and they don't have a matching key,
in a case like that
the routing update is going to be rejected.
In fact, the neighborship itself would be rejected.
However, we might have a malicious user
launch a man in the middle attack against us.
With a man in the middle attack,
they may convince R1
to send them one of those routing updates
along with the key.
And the challenge is, the key is in plain text,
so they can capture that packet and they can read it.
They could then connect their own router to the network,
configure their router with that captured key,
and their rogue router would be authenticated by R2.
We don't want that to happen.
So plain text authentication
is probably not going to be a best practice,
instead, we want to take a look at hash based authentication.
But first, here's a listing of protocols
that support plain text authentication.
We have RIP version two, OSPF version two and IS-IS.
Now let's take a look at hash based authentication.
With hashing authentication, we take a local key
and a routing update
and we run them through a hashing algorithm.
And that's going to create what's called a hash digest
or sort of a fingerprint,
you can think of it that way.
And we then send that routing update
along with the hash digest to our neighbor.
And the neighbor is going to take a look
at that routing update along with its local key
and calculate a hash on its side.
And it's going to compare the hash that it just calculated
with a hash that it received from R1 in this case.
And if the hash digests match,
then this routing update is considered to be authenticated.
So if these digests match,
then we're going to accept the routing update.
And we have two hashing algorithms
that I want you to know about.
One of them is called MD5 and one is SHA
or secure hash algorithm.
And MD5 is supported on this list of routing protocols.
And SHA is supported on this list of routing protocols.
But let's consider when we might not see SHA support
with these routing protocols.
First of all, some of our IPv6 routing protocols,
well specifically RIPng and OSPF version three,
they don't natively do authentication.
Instead, they rely on IPsec, which can use SHA.
That's how they get their SHA support.
But I wanted to include the IPv4 routing protocols
of OSPF version two and IS-IS in this list,
and say that they do support SHA
because there are some RFCs out there
that say you can run SHA with those routing protocols,
but, you might not find support
for those routing protocols running SHA
on your Cisco IOS router.
Specifically, there's RFC 5709,
that says OSPF version two can support SHA.
There's a similar RFC, it's 5310.
It says that IS-IS can support SHA,
but, just because I listed them here for completion sake,
please know that you might not have that support
on your devices.
And, in both plain text authentication,
and hashing authentication,
notice we had a local key on each router,
we call that a shared secret key.
However, over time, one of those local keys
on one of those routers it might become compromised.
So Cisco tells us to make things more secure,
we should periodically change those keys.
Well that could sort of be a hassle couldn't it?
To have to go to every router every Monday morning,
as an example, and change the keys.
Here's what we can do instead.
Instead of manually changing those keys each time,
we could create what is called a key chain.
With a key chain we can assign different lifetimes
to the keys on a chain.
And if we do that, we call those time based key chains.
For example, we might have a key that's valid for sending
and receiving for a period of time,
and then it's not valid any longer.
And we want to make sure there's not a period of time
where we don't have a key that's currently active.
To prevent that from happening,
Cisco recommends that we overlap
the lifetimes of the keys on a key chain,
so we don't have any gaps in our coverage.
Now, let's go out to a live topology,
see how to configure one of those time based key chains,
and then see how we can do a EIGRP authentication
for both IP version four and IP version six.
Let's begin by creating a key chain named R1 key chain,
we're going to do that on R1.
We'll go into global configuration mode,
and we say key chain R1 key chain.
Now that we've created the key chain,
we can put some keys on that key chain.
Let's create key one.
And the string for this key chain is going to be primary_key.
I'll say key-string,
primary_key.
Now we say when is this key valid
for both accepting and sending updates?
I'll say the accept lifetime,
and we can specify a time of day.
So I'll say midnight,
I'll say 00:00:00 to represent midnight,
on will say June 1st 2020.
And how long is it going to be good for?
What is the duration?
Well, I could specify a number of seconds.
But instead of specifying a number of seconds,
what I can do instead,
if we give some more context sensitive help,
I could give a specific time to stop.
Let's say that we want this to stop
on July 1st at midnight.
So I'll say once again, 00:00:00.
And this will be July 1st 2020.
And that's the accept lifetime,
let's also configure the send lifetime.
And I'll use the same dates.
So let's say send-lifetime 00:00:00 June 1st 2020,
going all the way through midnight,
00:00:00 on July 1st 2020.
So what we've done so far is we created a key
that has the string primary key.
And we said when it's valid to accept
and when it's valid to send.
Now let's create a second key for our key chain
that's going to overlap the end of the lifetime
of our first key by just a little bit,
so we don't have a gap.
Let's exit out of this configuration mode
and say key-two,
and I'm going to call this key string, secondary_key.
And once again, we'll configure the accept lifetime.
00:00:00.
I'm going to make this June the 30th.
So it's going to be midnight
the day before the other key expires,
June the 30th 2020.
And instead of setting a number of seconds
that this is valid
or saying a time that this expires,
I could say infinite.
So if I don't want to configure any additional keys right now,
I can say infinite.
So we'll do that in this example.
So we'll still have a key until I come back
and add some more time based keys later on.
That was the accept lifetime.
Let's do the send lifetime,
I'll say send-lifetime 00:00:00,
June 30th 2020 to infinity and beyond.
Now, I've created my two keys,
let's look at our key chain.
We'll say show key chain.
And you see I've got one called primary key
and secondary key.
And we see their send and accept lifetimes.
And we see which ones are currently valid.
So these are valid right now.
And we haven't attached these keys
to a routing protocol yet,
we're just creating the keys.
And let's go over to router R2
and create a matching set of keys on R2's key chain.
We'll go into global configuration mode.
And I'll say we've got a key chain
called R2 key chain,
and we've got key-one with the key-string
of primary_key, so that matches with R1.
And I'll say the accept lifetime
is starting at midnight on June 1st 2020,
and it's ending at midnight on July 1st 2020.
Let's set the send lifetime to 00:00:00
on June 1st 2020,
going all the way to midnight on July 1st 2020.
That's our first key,
let's create our second key, key two.
And this is going to have a key string of, secondary_key.
And it's going to have an accept lifetime,
beginning on midnight of June 30th 2020,
with an infinite lifetime,
and the send lifetime is also going to begin at midnight
on June 30th 2020.
And it's good for infinity
unless we come back and make a change.
And let's verify this key chain,
we'll say show key chain.
Everything looks good there.
So we've created our key chains.
Now, let's configure authentication for EIGRP
for IP version four using those key chains.
Let's go back to R1,
and I'm going to go into the interface of gigabit 0/2,
and I'm going to say IP authentication mode
EIGRP autonomous system one.
And notice with context sensitive help,
there is no support for SHA here,
there's only MD5 support on my router.
I'll say MD5 is our hashing algorithm.
And now I need to say what key chain we're going to be using.
Oh and notice when I set up authentication,
we lost our neighborship with R2
because we don't have matching authentication.
Hopefully we'll fix that here in just a few moments.
But let's say what key chain we're using,
I'll say IP authentication,
key chain for EIGRP autonomous system one, R1 key chain.
Let's do a show IP EIGRP neighbors command.
And we do not have a neighbor, it was torn down.
So let's go to R2 and see if we can fix that.
On R2, we'll go into interface gigabit 0/1,
which is the interface pointing up to R1.
And I'll say IP authentication mode
EIGRP autonomous system one,
our only option for hashing is MD5 IP authentication.
The key chain we're using
for EIGRP autonomous system one on R2
is R2 key chain.
And hopefully, R1 and R2 will negotiate
and reform their neighborship.
Look at that it says we have a new adjacency.
So if I do a show IP EIGRP neighbors command,
great news I am once again a neighbor with R1.
So that's a look at how to configure authentication
using a time based key chain for EIGRP for IP version four.
Now let's take a look at EIGRP for IP version six.
It's going to be very similar,
the main difference being in interface configuration mode,
we're going to say IPv6 instead of saying IP,
other than that it's pretty much identical.
Let's go back to R1,
and we'll say configure terminal,
interface gigabit 0/2 pointing down to R2.
This time we'll say IPv6 authentication mode
EIGRP autonomous system one.
Again, SHA is not an option.
I'll say MD5.
And we lost our neighborship again.
This time an IPv6 neighborship.
And I'll say IPv6 authentication,
key chain for EIGRP autonomous system one
is R1 key chain we can use the same key chain.
Let's give a matching configuration on R2.
We'll go into interface gigabit 0/1.
And we'll say IPv6 authentication mode
EIGRP autonomous system one MD5.
And IPv6 authentication,
key chain for EIGRP autonomous system one
is called R2 key chain.
And let's see if our IPv6 neighborship is restored.
Oh, and it is.
Says we have a new adjacency,
and we'll confirm that by doing a show IPv6
EIGRP neighbors command.
We have two neighbors.
In fact, let's give this command,
let's do a show IPv6 EIGRP interfaces detail command.
And this is going to show that we are using authentication
with MD5 as the hashing algorithm.
It says authentication mode is MD5,
and the key chain we're using is the R2 key chain.
And that's a look at how to do EIGRP authentication
for both IPv4 and IPv6, using a time based key chain.