[AUDIO LOGO]
So next, let's take a look at BGP neighbor authentication.
Now, of course, the primary reason for this
is to try to prevent unauthorized neighborships.
If somebody else doesn't know the password,
then they can't form a neighborship with us.
So this is a relatively common thing to do.
Now, in the case of IOS XE, it only
supports MD5 authentication.
And honestly, we just put a password
on a neighbor statement.
So it's a fairly straightforward process.
IOS XR gets a little bit more interesting
because it supports MD5, of course,
but it also supports SHA-1 authentication
and the opportunity to use a keychain.
So we'll take a look at both of these options,
and we'll take a look at configuring these
between IOS XE and IOS XR.
So let's jump in and take a quick look
at some details on authentication.
And then we'll jump into the command line
and get this set up on both platforms.
So again, the main purpose of BGP authentication
is to protect those BGP neighborships, making sure
that we don't get neighbors that we don't
want that aren't authorized.
Now, there are two major features
that focus around protecting these neighborships.
Of course, one of them is neighbor authentication.
That is, of course, our topic in this video.
There's also TTL security, and we
will be talking about this one in the next video.
So this topic is coming up very shortly.
But as far as authentication itself,
as we said during the introduction,
IOS XE supports HMAC-MD5 authentication,
and this is put on a neighbor statement.
IOS XR supports both HMAC-MD5 and HMAC-SHA-1,
specifically SHA1-12.
Now, here's the interesting thing.
MD5 authentication can be configured here
under neighbor configuration or in a keychain.
SHA-1 authentication has to be done in the keychain option.
Now, a very important thing to understand here
and we'll see why as we get into Wireshark,
but these authentications are compatible with each other.
These authentications are not, and the reason
has to do with how this MD5 authentication is actually
carried in the TCP header.
IOS XR carries it differently, whether you're
using the neighbor or the keychain,
and the neighbor is the one that's
compatible with MD5 authentication on IOS XE,
or you could say, per the standard.
What exactly does that mean?
Well, if we go down here just a little bit further,
when we're talking about HMAC-MD5 here,
it uses the IP address, and the most important thing here
is TCP option 19.
IOS XE and the neighbor configuration on IOS XR
both use TCP option 19.
We'll see when we look at the SHA-1 authentication
that that's carried actually in an experimental field
in the TCP header.
It is not carried in option 19.
But just to wrap up the MD5 part here,
since it does use the IP address and TCP option 19,
there are a few caveats.
This means, it cannot traverse NAT or PAT.
It cannot traverse any firewalls that randomizes TCP sequence
numbers, and it cannot traverse any firewalls that actually
remove option 19 since it's using that.
So other than that, authentication
is really not that difficult.
Let's go ahead and jump into the command-line
and configure this.
As always, we'll start by taking a quick look at our diagram.
And what we're going to be doing is
we're going to authenticate with MD5 the connection between R6
and R1.
And then we'll authenticate with SHA-1 the connection
between R1 and R2.
So let's just go ahead and jump into the command-line
and get started.
So we'll just start here on router 1.
We'll simply go into router BGP 100.
Again, under the neighbor configuration because this
is the one that uses option 19.
And we'll simply set a password.
We'll make it secret pass with some special characters there.
Super secret password.
Let's commit our changes.
Exit configuration.
Now, what we should see is the neighborship actually go down
between router 1 and router 6.
Now, this is going to take 3 minutes.
So we could actually get router 6 configured and up
and running without it ever even going down.
However, since we want to see that the password is actually
working, we'll just go ahead and fast-forward
until that neighborship actually goes down.
And we can see that we're already getting messages
that it's getting invalid or bad MD5 authentication from router
6.
So it's just a matter of time until that neighbor fails.
So here, we see that the neighbor has finally gone down.
We're, of course, still getting those bad authentication
messages.
That will continue until we actually fix the problem.
So let's go over to router 6.
Router 6, of course, also sees that the neighborship
has gone down.
So let's go ahead and fix it.
This, of course, is going to be for neighbor 50.0.167.1,
and we're simply going to set the password
to the same password, and our configuration,
and we should see that neighborship
come back up very shortly.
So here, we can see the neighborship came back up.
Let's jump into Wireshark and just take a real quick look
at that option 19 on the packet, so we
can see what this looks like.
So here, we have a keepalive message just being sent
between router 1 and router 6.
And here, under TCP, if we open this header,
we can scroll down.
Here, we see options.
We can see that one of those options is TCP MD5 signature.
But if we open it up even further,
we see that it's MD5 Signature Option 19, and that's
the TCP header option that we're using for this authentication.
So now, let's go back and configure SHA-1 authentication
between routers 1 and 2.
So for this we need a keychain.
So we'll just do a keychain.
We'll just call it BGP_KEY.
We'll make a key 1.
First thing we want to do is set the cryptographic algorithm.
Now, if we look at the options here, we support SHA-1 and MD5,
but remember that specifically, it supports
HMAC-SHA1-12 or HMAC-MD5.
Now, again, we can't actually do the HMAC-MD5 here
to go towards IOS XE, and we'll see why in just a moment.
We already saw that that uses option 19.
But if we turn on SHA-1 here, we set up our key string,
we'll just make it the same password,
we also have to set up a send-lifetime,
so it knows when to send it.
We're just going to tell it to start sending it, basically
forever, starting, say, January 1 of 2000, and send it forever.
We're not too concerned about send-lifetimes
and receive-lifetimes right now.
Then we'll go into router BGP 100 and towards our neighbor
10.2.2.2.
We'll use our keychain BGP_KEY.
Now, of course, as soon as we commit this,
we should start getting error messages,
and we can see that almost right away,
we start getting these TCP bad authentication messages
coming from router 2.
So now, let's go ahead and put our configuration on router 2.
It's the exact same configuration as router 1.
So we'll just paste it in.
The only difference, of course, is its neighbor 1.
Let's go ahead and commit those changes and exit configuration.
Now, we could have, again, waited for the neighborship
to go down, but I think we're all fairly confident
that it would have.
We were already getting error messages.
So now, let's jump over to Wireshark
and take a look at what the packet actually
looks like in the TCP header.
So here, we have a keepalive between router 1 and router 2.
And if we come down here and look at our TCP header,
notice that now, under Options, it says, experimental.
If we open this up, we see that it actually
lists it as RFC3692.
Style is Experiment 2.
This is quite simply a header that's
available for people who want to expand on the protocol, which
is essentially what we're doing here
by using SHA-1 authentication.
Just to contrast this to a connection that's
not doing any authentication, let's take a look
at this keepalive between router 2 and router 3.
So if we highlight this packet and we
look under TCP, what we actually see
is there's no options at all.
So if we're not doing authentication,
there are no options.
If we're doing traditional BGP authentication with MD5,
it's option 19.
And if we're doing SHA-1 authentication or MD5
authentication with a keychain, then we're
going to be using the RFC3692-style.
But whatever combination, we can see that this is now working.
So in this video, we saw BGP neighbor authentication working
between IOS XE and IOS XR using traditional MD5 authentication
configured under the neighbor configuration
using TCP option 19, and we saw using SHA-1
with a keychain between two IOS XR
devices using our experimental headers in TCP.
I hope this has been informative for you,
and I'd like to thank you for viewing.