WEBVTT

0:00:02.780000 --> 0:00:07.280000
 Hello and welcome to this video
 titled SNMP versions.

0:00:07.280000 --> 0:00:11.220000
 In this video I'm going to compare
 the different versions of SNMP and

0:00:11.220000 --> 0:00:15.460000
 we're going to talk about something
 called SNMP Community Strings.

0:00:15.460000 --> 0:00:20.160000
 I'm going to show you how in Cisco iOS
 to configure SNMP Community Strings

0:00:20.160000 --> 0:00:25.940000
 and I'm going to finish off with
 an overview of SNMP version 3.

0:00:25.940000 --> 0:00:30.780000
 So let's talk about the first two flavors
 or versions of SNMP version

0:00:30.780000 --> 0:00:33.560000
 1 and version 2c.

0:00:33.560000 --> 0:00:40.220000
 So version 1 clearly is the oldest, not
 used as much anymore so you won't

0:00:40.220000 --> 0:00:41.400000
 see that very much.

0:00:41.400000 --> 0:00:46.560000
 Mostly things have been standardized
 on SNMP version 2c.

0:00:46.560000 --> 0:00:52.760000
 Now between version 1 and version 2c
 you can see here that version 2c

0:00:52.760000 --> 0:00:55.560000
 had some extended capabilities
 of SNMP.

0:00:55.560000 --> 0:00:58.700000
 For example there was
 support of new MIBs.

0:00:58.700000 --> 0:01:03.200000
 So the database, the MIB database was
 restructured, new object IDs were

0:01:03.200000 --> 0:01:07.880000
 created, new types of SNMP
 messages were created.

0:01:07.880000 --> 0:01:12.900000
 For example the get bulk request
 and the inform message.

0:01:12.900000 --> 0:01:19.140000
 And solve some of the performance
 deficiencies of SNMP version 1.

0:01:19.140000 --> 0:01:26.040000
 You see one of the big downsides of
 SNMP version 1 is that the MIB for

0:01:26.040000 --> 0:01:29.780000
 any different OID and remember an OID
 is a long string of numbers like

0:01:29.780000 --> 0:01:36.120000
 1.3.6.2.1. It can go out and each string
 of numbers represents a piece

0:01:36.120000 --> 0:01:38.180000
 of data that you're trying to get.


0:01:38.180000 --> 0:01:40.400000
 It might represent
 an interface name.

0:01:40.400000 --> 0:01:44.340000
 It might represent a particular set of
 statistics on an interface or route

0:01:44.340000 --> 0:01:45.640000
 in a routing table.

0:01:45.640000 --> 0:01:51.440000
 Each thing that you could possibly retrieve
 from an SNMP agent is retrievable

0:01:51.440000 --> 0:01:55.420000
 by sending something called an OID,
 that long string of numbers.

0:01:55.420000 --> 0:02:00.480000
 Well in SNMP version 1 any of those
 things that you could retrieve, the

0:02:00.480000 --> 0:02:04.640000
 MIB, remember the MIB is the database
 that lives on the agent.

0:02:04.640000 --> 0:02:07.460000
 So it lives on the switch,
 on the router.

0:02:07.460000 --> 0:02:11.340000
 It's where it stores all these statistics
 that you can pull via SNMP.

0:02:11.340000 --> 0:02:17.120000
 Well all of the fields within the MIB,
 the maximum size with 32 bits.

0:02:17.120000 --> 0:02:20.480000
 Now you might think, oh well with 32
 bits that gives me, you know, what,

0:02:20.480000 --> 0:02:23.200000
 like a billion combinations
 of numbers.

0:02:23.200000 --> 0:02:27.160000
 But there's some things that
 change over so fast.

0:02:27.160000 --> 0:02:31.760000
 For example, imagine if you were trying
 to query a 10 gigabit ethernet

0:02:31.760000 --> 0:02:35.380000
 interface for its packet
 count or its bit count.

0:02:35.380000 --> 0:02:41.400000
 Well a 32 bit field could very quickly
 be filled up if that interface

0:02:41.400000 --> 0:02:43.120000
 is really, really busy.

0:02:43.120000 --> 0:02:47.460000
 So there were a lot of situations where
 a 32 bit field was just not appropriate

0:02:47.460000 --> 0:02:51.540000
 for the quantity or type of
 data we were trying to get.

0:02:51.540000 --> 0:02:54.740000
 And that was a big problem
 with SNMP version 1.

0:02:54.740000 --> 0:02:58.720000
 So one of the big changes of SNMP version
 2 is they said hey, let's increase

0:02:58.720000 --> 0:03:08.360000
 the size which is what it's
 been pretty much ever since.

0:03:08.360000 --> 0:03:10.720000
 Also the get bulk message.

0:03:10.720000 --> 0:03:15.900000
 So previously with SNMP version 1, if
 you want to get something, you sent

0:03:15.900000 --> 0:03:21.120000
 an SNMP get message which meant you were
 asking for a single OID, a single

0:03:21.120000 --> 0:03:25.040000
 string of numbers which would get you
 back a single piece of information

0:03:25.040000 --> 0:03:27.240000
 of whatever you were looking for.

0:03:27.240000 --> 0:03:30.400000
 Get bulk was another type of message
 where you could actually request

0:03:30.400000 --> 0:03:32.420000
 a lot of things all at once.

0:03:32.420000 --> 0:03:37.800000
 So in other words, if I wanted to get
 50 or 60 piece of information in

0:03:37.800000 --> 0:03:43.640000
 SNMP version 1, I'd have to send 60
 or 50 SNMP get messages one right

0:03:43.640000 --> 0:03:45.360000
 after the other.

0:03:45.360000 --> 0:03:50.760000
 But in SNMP version 2, I could just
 send one SNMP get bulk message and

0:03:50.760000 --> 0:03:55.540000
 they get all that data
 back as SNMP responses.

0:03:55.540000 --> 0:04:01.980000
 Now, both SNMP version 1 and version
 2C utilize something called community

0:04:01.980000 --> 0:04:05.760000
 strings. I'm going to talk about that
 in just a second, but for now, just

0:04:05.760000 --> 0:04:10.120000
 think of that as being a very crude
 form of a plain text password.

0:04:10.120000 --> 0:04:14.940000
 So the NMS when talking to the agent,
 because after all, if that agent

0:04:14.940000 --> 0:04:20.500000
 is your router, your switch, you don't
 want any rogue NMS out there talking

0:04:20.500000 --> 0:04:25.320000
 to your device and getting its information
 or heavens forbid, some rogue

0:04:25.320000 --> 0:04:31.840000
 NMS sending an SNMP set message and changing
 your device's configuration.

0:04:31.840000 --> 0:04:35.440000
 So for that, there was a very crude form
 of password security called community

0:04:35.440000 --> 0:04:41.280000
 strings. Now, SNMP version 2, as it
 says here, was not compatible with

0:04:41.280000 --> 0:04:44.320000
 version 1 as the message
 types were different.

0:04:44.320000 --> 0:04:47.800000
 Now let's talk about community
 strings for just a moment.

0:04:47.800000 --> 0:04:53.160000
 So on your SNMP agent, your router,
 your switch, at an absolute minimum,

0:04:53.160000 --> 0:04:55.580000
 you have to configure
 community strings.

0:04:55.580000 --> 0:04:58.900000
 As a matter of fact, he won't even
 recognize that he's supposed to be

0:04:58.900000 --> 0:05:04.740000
 an agent until you do configure at
 least one SNMP community string.

0:05:04.740000 --> 0:05:08.600000
 Now, this is just for SNMP
 version 1 and version 2C.

0:05:08.600000 --> 0:05:13.020000
 SNMP version 3, whole different beast
 that we'll talk about later.

0:05:13.020000 --> 0:05:16.800000
 So with community strings, there were
 two different types, only two.

0:05:16.800000 --> 0:05:20.080000
 And you could do both of them, or you
 could just do one or the other.

0:05:20.080000 --> 0:05:23.240000
 There was a community string which was
 read only, and actually when you

0:05:23.240000 --> 0:05:27.320000
 configure the community string in
 iOS, you'll see R-O for read only.

0:05:27.320000 --> 0:05:30.440000
 And there's another one,
 which is read right.

0:05:30.440000 --> 0:05:33.780000
 So the read only community string,
 that was a basically, think of that

0:05:33.780000 --> 0:05:38.860000
 as being a password when an
 NMS wanted to read data.

0:05:38.860000 --> 0:05:43.120000
 Read right would be for something
 that wanted to change your data.

0:05:43.120000 --> 0:05:47.820000
 For example, let's say that we have
 two network management systems, two

0:05:47.820000 --> 0:05:53.580000
 NMSs. Okay, one network management
 system is being, we're letting our

0:05:53.580000 --> 0:05:57.480000
 sort of junior level network administrators
 control that one.

0:05:57.480000 --> 0:06:01.440000
 Now, they're sort of wet behind the ears,
 they're kind of new in our company.

0:06:01.440000 --> 0:06:06.960000
 And so we want them to be able to retrieve
 data via the read only community

0:06:06.960000 --> 0:06:11.720000
 string, but we don't want their NMS
 to have any potential of screwing

0:06:11.720000 --> 0:06:13.040000
 up our routers and switches.

0:06:13.040000 --> 0:06:18.320000
 So under no circumstances, should
 they send an SNMP set message?

0:06:18.320000 --> 0:06:23.380000
 And if they do, we want the agents
 to just ignore that set message.

0:06:23.380000 --> 0:06:27.220000
 So what we'll do is we'll configure
 a read only community string, give

0:06:27.220000 --> 0:06:31.120000
 it a simple password like read or something
 like that, and we'll tell

0:06:31.120000 --> 0:06:34.200000
 those people over there, hey, here's
 the community string you need.

0:06:34.200000 --> 0:06:37.620000
 So when they go into their network management
 system and they configure

0:06:37.620000 --> 0:06:41.780000
 their NMS to point to router one, switch
 one, switch two and their IP

0:06:41.780000 --> 0:06:46.280000
 addresses, they'll also have to type
 in the read only community string

0:06:46.280000 --> 0:06:48.380000
 for all those devices.

0:06:48.380000 --> 0:06:53.440000
 Once they type that in, their NMS will
 know it's a read only string because

0:06:53.440000 --> 0:06:58.400000
 in the GUI, when you're saying add
 device, you say router one, he's 1

0:06:58.400000 --> 0:07:03.060000
.1.1.1, it'll say, okay, what's your
 read only community string?

0:07:03.060000 --> 0:07:04.980000
 What's your read right
 community string?

0:07:04.980000 --> 0:07:08.360000
 Well, we haven't given them the
 read right community string.

0:07:08.360000 --> 0:07:09.740000
 They don't know what it is.

0:07:09.740000 --> 0:07:12.160000
 So all they can do is type in the
 read only community string.

0:07:12.160000 --> 0:07:17.380000
 So their NMS is not even a bother sending
 out SNMP set messages because

0:07:17.380000 --> 0:07:21.020000
 it doesn't have a read
 right community string.

0:07:21.020000 --> 0:07:25.560000
 The other NMS over here, this is for
 a more senior level engineers and

0:07:25.560000 --> 0:07:26.660000
 network administrators.

0:07:26.660000 --> 0:07:33.480000
 So their NMS will give them both the read
 only and the read right community

0:07:33.480000 --> 0:07:39.080000
 string. So their NMS could potentially
 send SNMP set messages to change

0:07:39.080000 --> 0:07:43.780000
 some of the operational characteristics
 of the various SNMP agents out

0:07:43.780000 --> 0:07:49.640000
 there. So I want to show you here,
 this is a sniffer trace of an SNMP

0:07:49.640000 --> 0:07:52.200000
 version 2C message.

0:07:52.200000 --> 0:07:54.920000
 So this is right after
 the UDP header.

0:07:54.920000 --> 0:07:58.740000
 And the main things I want to call out
 in this is that notice of the community

0:07:58.740000 --> 0:08:02.000000
 string, it's sent in plain text.

0:08:02.000000 --> 0:08:07.240000
 So whether this was the read only or
 the read right community string,

0:08:07.240000 --> 0:08:12.120000
 anybody with wire shark, if they caught
 that packet, would see what the

0:08:12.120000 --> 0:08:13.660000
 community string is.

0:08:13.660000 --> 0:08:17.400000
 Now you might think, well, wait a second
 then, how do I prevent somebody

0:08:17.400000 --> 0:08:23.700000
 with, you know, just whipping a server
 out of their backpack, whipping

0:08:23.700000 --> 0:08:26.720000
 out some, you know, network management
 software and installing on that

0:08:26.720000 --> 0:08:30.760000
 server and now trying to control my network
 because they saw what my community

0:08:30.760000 --> 0:08:37.140000
 string is. Well, one thing you can
 do optionally with SNMP, you don't

0:08:37.140000 --> 0:08:42.120000
 have to do it, but when you're on the
 router, the switch, the agent, you

0:08:42.120000 --> 0:08:46.940000
 can actually configure an access list
 and tell SNMP, hey, when an SNMP

0:08:46.940000 --> 0:08:52.940000
 message comes in like an SNMP get or
 an SNMP set, only if it came from

0:08:52.940000 --> 0:08:56.300000
 this source IP address
 is it authorized.

0:08:56.300000 --> 0:09:00.260000
 If it came from any other source
 IP address, ignore it.

0:09:00.260000 --> 0:09:04.500000
 So we can't hide the community string,
 it's right here in plain text for

0:09:04.500000 --> 0:09:09.560000
 anybody to see, but we can sort of
 lock down the agent to only respond

0:09:09.560000 --> 0:09:13.320000
 to messages if they came
 from authorized sources.

0:09:13.320000 --> 0:09:20.380000
 We can also see here in this slide, in
 this get message, there's the OID.

0:09:20.380000 --> 0:09:24.120000
 So maybe on the actual graphical user
 interface, we clicked a button for

0:09:24.120000 --> 0:09:29.300000
 get routing table or get
 IP interface statistics.

0:09:29.300000 --> 0:09:33.580000
 That may have been what we selected,
 but in the background, that NMS knew

0:09:33.580000 --> 0:09:40.200000
 that that item we wanted corresponded
 to this OID in the MIB database.

0:09:40.200000 --> 0:09:41.900000
 And so that's actually
 what goes out.

0:09:41.900000 --> 0:09:47.020000
 That's what the agent can respond
 to is an OID value.

0:09:47.020000 --> 0:09:53.060000
 All right, so how do we do basic configuration
 of SNMP version 1 or SNMP

0:09:53.060000 --> 0:09:58.640000
 version 2C? Well, like I said, you don't
 have to configure an access list,

0:09:58.640000 --> 0:10:04.000000
 but if you don't, anybody who's got your
 community string is able to talk

0:10:04.000000 --> 0:10:06.660000
 to your device via SNMP.

0:10:06.660000 --> 0:10:10.400000
 So here we see in the first couple
 of lines, we've got an access list

0:10:10.400000 --> 0:10:14.740000
 configured, and in this case, we're
 using a standard access list called

0:10:14.740000 --> 0:10:22.600000
 admins, and then we're saying, okay,
 only permit SNMP messages if they

0:10:22.600000 --> 0:10:27.020000
 came from a source address that's in
 this particular network right here,

0:10:27.020000 --> 0:10:30.860000
 the 192.168.99.0 network.

0:10:30.860000 --> 0:10:36.860000
 Okay, if it comes from that source,
 now what has to be true?

0:10:36.860000 --> 0:10:45.180000
 Well, if they issue the community of
 INE, we have designated that as a

0:10:45.180000 --> 0:10:47.000000
 read-write community.

0:10:47.000000 --> 0:10:52.740000
 Now notice, INE here on this particular
 line, there's no mention of that

0:10:52.740000 --> 0:10:56.440000
 access list. You don't see
 the word admins anywhere.

0:10:56.440000 --> 0:11:00.160000
 So anybody who's got the community string
 of INE in lowercase who knows

0:11:00.160000 --> 0:11:07.100000
 that, no matter where they are, can issue
 an SNMP set or an SNMP get message

0:11:07.100000 --> 0:11:13.000000
 to this router or switch, this
 SNMP agent, not very secure.

0:11:13.000000 --> 0:11:15.040000
 So that's probably a bad idea.

0:11:15.040000 --> 0:11:16.360000
 We don't want that in there.

0:11:16.360000 --> 0:11:22.120000
 Now in the second line, we've also
 provided another read-write string.

0:11:22.120000 --> 0:11:24.900000
 This is called admin 1234.

0:11:24.900000 --> 0:11:29.900000
 So this agent, this router, the switch
 will respond to SNMP messages using

0:11:29.900000 --> 0:11:33.480000
 either one, INE or admin 1234.

0:11:33.480000 --> 0:11:36.720000
 So you can see here, you can configure
 an agent to be responsive to more

0:11:36.720000 --> 0:11:38.440000
 than one community string.

0:11:38.440000 --> 0:11:45.200000
 But if somebody sends a message with admin
 1234, now they have to be coming

0:11:45.200000 --> 0:11:49.040000
 from a source that's permitted
 in this access list.

0:11:49.040000 --> 0:11:58.900000
 So if an NMS in the 57.62 network sent
 an SNMP get message with admin

0:11:58.900000 --> 0:12:03.100000
 1234, he would not be responded to
 because he did not pass the access

0:12:03.100000 --> 0:12:07.880000
 list. And then optionally, you don't
 have to do this, but here we see

0:12:07.880000 --> 0:12:11.880000
 some additional SNMP messages where
 you can set the location and you can

0:12:11.880000 --> 0:12:13.320000
 set the contact.

0:12:13.320000 --> 0:12:17.960000
 Both of those are retrievable
 via a MIB object.

0:12:17.960000 --> 0:12:21.480000
 So there's an OID string, a big long
 string of numbers that you can send

0:12:21.480000 --> 0:12:26.000000
 to get the location of a device
 or get the contact of a device.

0:12:26.000000 --> 0:12:30.340000
 And that device will only respond with
 those OIDs if it's been configured

0:12:30.340000 --> 0:12:31.920000
 with something like this.

0:12:31.920000 --> 0:12:36.600000
 So that's the real basics right there
 of how to configure SNMP version

0:12:36.600000 --> 0:12:42.200000
 2C. Now what about SNMP version 3?


0:12:42.200000 --> 0:12:45.240000
 SNMP version 3 was a whole
 different beast.

0:12:45.240000 --> 0:12:49.700000
 It's actually a lot better because it
 provided some really big security

0:12:49.700000 --> 0:12:55.640000
 benefits. You see, in the world of SNMP,
 all three versions, we have these

0:12:55.640000 --> 0:12:58.140000
 things called security models.

0:12:58.140000 --> 0:13:00.580000
 And there's three security models.


0:13:00.580000 --> 0:13:03.400000
 And that's what I'm going
 to show you right here.

0:13:03.400000 --> 0:13:06.080000
 So these are your three
 security models.

0:13:06.080000 --> 0:13:08.980000
 We can see here on the left
 what their names are.

0:13:08.980000 --> 0:13:13.760000
 One is called no off, no priv.

0:13:13.760000 --> 0:13:21.460000
 So that is S, oops, I guess I should
 write it better, SNMP version 1 and

0:13:21.460000 --> 0:13:27.480000
 version 2C. So version 1 and version
 2C is no off, no priv.

0:13:27.480000 --> 0:13:28.900000
 What the heck does that mean?

0:13:28.900000 --> 0:13:33.160000
 Well, that means that we're not really
 validating the authentication of

0:13:33.160000 --> 0:13:34.620000
 the device, of the NMS.

0:13:34.620000 --> 0:13:38.980000
 So from the agent's perspective, he'll
 talk to anybody that provides the

0:13:38.980000 --> 0:13:40.420000
 correct community string.

0:13:40.420000 --> 0:13:42.520000
 We're not doing any
 kind of encryption.

0:13:42.520000 --> 0:13:45.040000
 We're not doing any kind
 of message integrity.

0:13:45.040000 --> 0:13:49.300000
 We're not checking to see if the message
 was damaged or changed in transit.

0:13:49.300000 --> 0:13:51.720000
 That's no off, no priv.

0:13:51.720000 --> 0:13:55.060000
 And that's the default of
 version 1 and version 2C.

0:13:55.060000 --> 0:14:00.020000
 Now with SNMP version 3, you've got
 a couple of other levels that the

0:14:00.020000 --> 0:14:01.540000
 other versions did not have.

0:14:01.540000 --> 0:14:05.940000
 You could do off, no priv.

0:14:05.940000 --> 0:14:09.040000
 By the way, priv here
 stands for privacy.

0:14:09.040000 --> 0:14:14.620000
 So if you do off, no priv, what you're getting
 is you're getting authentication

0:14:14.620000 --> 0:14:17.360000
 and you're getting
 message integrity.

0:14:17.360000 --> 0:14:20.760000
 So with message integrity, basically what's
 happening is you're configuring

0:14:20.760000 --> 0:14:22.180000
 like a password.

0:14:22.180000 --> 0:14:25.480000
 Let's just say Cisco 1, 2, 3.

0:14:25.480000 --> 0:14:27.100000
 It's not a community string.

0:14:27.100000 --> 0:14:29.620000
 It's actually a password.

0:14:29.620000 --> 0:14:34.360000
 And then with authentication, no privacy,
 this password is actually being

0:14:34.360000 --> 0:14:35.900000
 used for a couple of
 different things.

0:14:35.900000 --> 0:14:41.400000
 Number one, when the SNMP message comes
 in, like the SNMP set or the SNMP

0:14:41.400000 --> 0:14:48.140000
 get message, in place of a community
 string, it'll have Cisco 1, 2, 3.

0:14:48.140000 --> 0:14:52.760000
 Now if the NMS has that, and if the
 agent has been configured for that,

0:14:52.760000 --> 0:14:54.000000
 you're authenticated.

0:14:54.000000 --> 0:14:55.140000
 Right? We believe you.

0:14:55.140000 --> 0:14:56.360000
 You've got the right password.

0:14:56.360000 --> 0:14:58.300000
 But now we take it a step further.


0:14:58.300000 --> 0:15:00.560000
 And by the way, that's
 in plain text.

0:15:00.560000 --> 0:15:02.780000
 But now we take Cisco 1, 2, 3.

0:15:02.780000 --> 0:15:08.560000
 We take that. We take the actual
 body of the SNMP message itself.

0:15:08.560000 --> 0:15:16.660000
 And we hash it. We put into a hashing
 digest either an MD5 or secure hash

0:15:16.660000 --> 0:15:19.380000
 algorithm. You get to pick
 which one you want.

0:15:19.380000 --> 0:15:22.880000
 Secure hash algorithm is actually
 a little bit better than MD5.

0:15:22.880000 --> 0:15:26.340000
 But whichever one you pick,
 let's say you choose MD5.

0:15:26.340000 --> 0:15:30.860000
 The MD5 algorithm will take your password
 of Cisco 1, 2, 3, your actual

0:15:30.860000 --> 0:15:35.800000
 message of SNMP, hash it together,
 and come up with a hash digest, and

0:15:35.800000 --> 0:15:38.140000
 put that in there as well.

0:15:38.140000 --> 0:15:40.320000
 That gives you your
 message integrity.

0:15:40.320000 --> 0:15:45.160000
 Because now if I, let's say I am the
 NMS and you are a router, you are

0:15:45.160000 --> 0:15:52.120000
 the SNMP agent. I send you
 an SNMP set message.

0:15:52.120000 --> 0:15:55.180000
 Or let's say an SNMP get message.

0:15:55.180000 --> 0:15:57.520000
 I'm trying to get some
 information from you.

0:15:57.520000 --> 0:16:00.560000
 Let's say there's a man in the middle
 who's watching all this, who's capable

0:16:00.560000 --> 0:16:03.540000
 of intercepting our traffic
 and changing it.

0:16:03.540000 --> 0:16:06.640000
 He's probably not going to
 change my SNMP get message.

0:16:06.640000 --> 0:16:07.980000
 He doesn't really care about that.


0:16:07.980000 --> 0:16:11.740000
 What he's interested in is
 what you send back to me.

0:16:11.740000 --> 0:16:16.900000
 So let's say that you're sending back
 to me something like the routing

0:16:16.900000 --> 0:16:22.780000
 table. So I sent you an OID, big long
 string of numbers in my SNMP request,

0:16:22.780000 --> 0:16:25.560000
 my get message, that said,
 give me your routing table.

0:16:25.560000 --> 0:16:27.960000
 Now, you send your
 routing table back.

0:16:27.960000 --> 0:16:31.560000
 Now, if we did not have message integrity,
 for example, if we were dealing

0:16:31.560000 --> 0:16:37.900000
 with SNMP version 1 or version 2C, when
 you sent back your SNMP response,

0:16:37.900000 --> 0:16:40.220000
 and that's actually the name of the
 message that had the routing table

0:16:40.220000 --> 0:16:43.820000
 inside of it, this man in the
 middle could capture that.

0:16:43.820000 --> 0:16:44.960000
 He could change it.

0:16:44.960000 --> 0:16:46.200000
 He could add routes to it.

0:16:46.200000 --> 0:16:48.060000
 He could strip routes
 away from it.

0:16:48.060000 --> 0:16:52.000000
 And then when I got it as the NMS,
 I would have no way of knowing that

0:16:52.000000 --> 0:16:55.700000
 what I actually received was not
 what you had actually sent.

0:16:55.700000 --> 0:16:57.780000
 It had been changed in some way.

0:16:57.780000 --> 0:17:03.280000
 But with SNMP version 3, if I'm doing
 authentication, no privacy, off,

0:17:03.280000 --> 0:17:08.420000
 no priv, now, when you send your SNMP
 response, you'll take that password

0:17:08.420000 --> 0:17:13.360000
 that we share, Cisco 123, you'll take
 the actual data, which is the routing

0:17:13.360000 --> 0:17:17.760000
 table, and you'll hash it all together
 and create a digest from MD5, and

0:17:17.760000 --> 0:17:19.360000
 you'll stick that in there.

0:17:19.360000 --> 0:17:24.080000
 Now, that guy in the middle, there
 is no way he can intercept that and

0:17:24.080000 --> 0:17:27.440000
 change that packet
 without me knowing.

0:17:27.440000 --> 0:17:32.900000
 That's the whole point, because if I
 get the packet now and something's

0:17:32.900000 --> 0:17:36.100000
 been changed, the digest
 won't match up.

0:17:36.100000 --> 0:17:40.460000
 You see, I'll get your packet, I'll
 take that password that we share,

0:17:40.460000 --> 0:17:44.200000
 I'll take the contents of your packet,
 I'll run it through the digest,

0:17:44.200000 --> 0:17:46.440000
 the MD5 digest, and I'll
 say, wait a second.

0:17:46.440000 --> 0:17:50.800000
 The MD5 digest I created as a result
 of this is not the same as what's

0:17:50.800000 --> 0:17:55.460000
 in that packet. That tells me that
 something has changed here.

0:17:55.460000 --> 0:17:59.420000
 That's how we get the message
 integrity of SNMP 3.

0:17:59.420000 --> 0:18:03.720000
 But you have to do authentication to
 privacy or authentication privacy,

0:18:03.720000 --> 0:18:05.560000
 and that's the last one here.

0:18:05.560000 --> 0:18:10.300000
 Off privacy. Now you can actually do
 authentication, message integrity,

0:18:10.300000 --> 0:18:18.120000
 and encryption. We can encrypt the
 whole packet using either DES56 or

0:18:18.120000 --> 0:18:20.000000
 actually even AES.

0:18:20.000000 --> 0:18:24.200000
 Most systems now support AES encryption
 as well, as part of SNMP version

0:18:24.200000 --> 0:18:31.540000
 3. So you can see SNMP version 3 added
 a lot of security enhancements.

0:18:31.540000 --> 0:18:36.260000
 In addition to that, the message format
 is totally, totally different.

0:18:36.260000 --> 0:18:37.520000
 Let me show you.

0:18:37.520000 --> 0:18:41.600000
 So once again, let's just
 do a comparison here.

0:18:41.600000 --> 0:18:43.500000
 So let's go back.

0:18:43.500000 --> 0:18:47.440000
 This right here was our
 SNMP version 2 message.

0:18:47.440000 --> 0:18:50.060000
 Pretty simple. You can
 read through it.

0:18:50.060000 --> 0:18:51.860000
 Everything's in plain text.

0:18:51.860000 --> 0:18:53.380000
 Most of it makes a lot of sense.

0:18:53.380000 --> 0:18:56.240000
 There's some fields in there that we
 have no idea what they do, but we

0:18:56.240000 --> 0:18:58.600000
 can pretty much understand
 what's going on there.

0:18:58.600000 --> 0:19:02.200000
 Now let's take a look at an
 SNMP version 3 message.

0:19:02.200000 --> 0:19:04.260000
 Look at this one right here.

0:19:04.260000 --> 0:19:07.540000
 Wow. Totally drastically
 different.

0:19:07.540000 --> 0:19:12.780000
 You can see so 99% of those fields in
 there, I don't know what they are.

0:19:12.780000 --> 0:19:16.520000
 You probably don't know what they are,
 but the takeaway from this is clearly

0:19:16.520000 --> 0:19:23.020000
 an SNMP version 3 device is not backwards
 compatible and can't talk to

0:19:23.020000 --> 0:19:25.160000
 an SNMP version 2 device.

0:19:25.160000 --> 0:19:27.360000
 This actually is doing encryption.


0:19:27.360000 --> 0:19:28.780000
 We can see that right here.

0:19:28.780000 --> 0:19:31.580000
 It says encryption is set.

0:19:31.580000 --> 0:19:33.840000
 Authentication is set.

0:19:33.840000 --> 0:19:37.860000
 And then there's all sorts of, and
 here's the encrypted message, which

0:19:37.860000 --> 0:19:41.840000
 we can't tell what it is because
 it's been encrypted.

0:19:41.840000 --> 0:19:46.720000
 So that is some of the various differences
 between the SNMP versions.

0:19:46.720000 --> 0:19:51.200000
 And we can see here the SNMP version
 3 much more secure than SNMP versions

0:19:51.200000 --> 0:19:54.340000
 1 and version 2C.

0:19:54.340000 --> 0:19:55.980000
 So thank you for watching
 this video.