This presentation is based on the slides listed in references. SNMPv1 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed in references.

Outline Introduction SNMP Organization model SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

Outline Introduction SNMP Organization model SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

Simple Network Management Protocol (SNMP) SNMP is one of the most widely used network management protocols In fact SNMP is a management standard not only a protocol When we say SNMP management, we are really referring to Internet management standard SNMP communication protocol is a part of the standard SNMP Goals Ubiquity From PCs to Carrier networks From small to large network elements Inclusion of management functions should be inexpensive Small code Limited functionality Management extensions should be possible New MIBs

SNMP Versions SNMPv1 SNMPv2 SNMPv3 The initial version Performance & Security limitations SNMPv2 Initially intended to resolve SNMPv1 issues, but Performance improvement More standard management information (MIB-II) SNMPv3 Major focus on security

Four Key Parts Structure of Management Information (SMI): Data definition language for MIB objects Management Information Base (MIB): View of agent, set of MOs, some standard MIBs SNMP communication protocol Manager  Agent: object info, commands, … Security and administration capabilities Major addition in SNMPv3

SMI: Data Definition Language We want to ensure that the syntax and semantics of management data are well-defined and unambiguous SMI is the language in which that information is specified It does not define what specific data is required for a particular managed network entity To do this, SMI allows us to use base data types Higher level constructs, including sequences, objects and modules.

Management Information Base (MIB) The MIB can be thought of as a virtual information store, holding managed objects whose values collectively reflect the current state of the network Managed objects are specified and gathered into MIB modules using SMI There are now over ~150 standardized MIB modules and many, many more vendor-specific (private) MIB modules

SNMP Communication Protocol Two ways to convey MIB information and commands Manager initiated A managing entity initiates a request to management agent The agent receives the request, performs some action, and sends a reply to the request Typically this is used to query or modify MIB object values within the managed device Agent initiated A management agent sends an unsolicited message, known as a trap message, to the managing entity Usually used to notify a managing entity of an exceptional situation that has resulted in changes to MIB object values

SNMP Management Models Organization Model Relationship between network element, agent, and manager Hierarchical architecture Information Model Uses ASN.1 syntax SMI (Structure of Management Information MIB (Management Information Base) Communication Model Communication services addressed by messages Security Model Security framework community-based model

Outline Introduction SNMP Organization model SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

Organization Model Describes components of a network management system, focuses on Infrastructure Manager & Agent & Proxies & RMON Two & Three Tier Architecture Functions SNMP Operations Manager initiated: Request Response Agent initiated: Trap

Two-Tier Organization Model Basic SNMP organization model is two-tier Single & multiple managers are allowed There is not any predefined manager for agents Any manager can manage any agent Security: Community (password) is needed

Three-Tier Organization Model: RMON Managed object comprises network element and management agent RMON (Remote Monitoring) acts as an agent and a manager RMON gathers data from MO, analyses the data, and stores the data Communicates the statistics to the manager

Three-Tier Organization Model: Proxy Proxy server converts non-SNMP data from non-SNMP objects to SNMP compatible objects and messages Proxy agent Management station Mapping function Proxied device Management process Manager process Agent process SNMP SNMP Protocol architecture used by proxied device Protocol architecture used by proxied device UDP UDP IP IP Network-dependent protocols Network-dependent protocols Network-dependent protocols Network-dependent protocols

SNMP Operations Operations supported in SNMP are the inspection and modification of variables & notification Four Services Get, Set, GetNext, Trap Five SNMP Messages GetRequest, SetRequest, GetNextRequest, GetResponse, Trap Get, Set, GetNext Request Get Response Trap Manager Agent(s)

SNMP Operations Get GetNext Set Trap Get Request Get Response Manager Agent GetNext Request Set Request Trap Get GetNext Set Trap

System Architecture

Outline Introduction SNMP Organization model SNMP Information model ASN.1 review SMI & MIB MIB development SNMP Communication model SNMP Administration model & Security

Presentation Problem in NM Networks are heterogeneous systems How data are represented? E.g. Integer in little-endian or big-endian ordering? We need standard ways of communicating the same information to/from all devices ASN.1 from the ISO also provides this kind of translation in a more generic form ASN.1 is very general & complex SMI also provides this kind of translation for SNMP network management Subset of ASN.1 which is customized for network mgmt

Abstract & Transfer Syntaxes User is concerned with semantics of data User User The user of data transfer comp. e.g., SNMP, FTP, TELNET for TCP/IP User Presentation Mapping Concerned with syntax of data Application Component Application Component Local Abstract Local Mapping Syntax ASN.1 Mapping Local Storage Local Storage Encoding Rules (BER) Encoding Rules Data Transfer Component Data Transfer Component Transfer Mechanisms for transfer of data between end systems (e.g., TCP or UDP) Syntax Binary representation of data

ASN.1 vs. BER Example Birthday ::= SEQUENCE { name VisibleString, day DayOfYear } Type Definition using ASN.1 myBirthday Birthday ::= { name "Jane", day 129 } Value Assignment Birthday Length Contents 30 ?? VisibleString Length Contents 1A 04 "Jane" DayOfYear Length Contents 51 02 00 81 BER Encoding 0A

ASN.1: Backus-Nauer Form (BNF) Definition: <name> ::= <definition> <entity> denotes “entity” and the symbol “::=“ represents “defined as” Primitive definitions: <digit> ::= 0|1|2|3|4|5|6|7|8|9 <op> ::= +|-|x|/ An entity number can be constructed from primitives: <number> ::= <digit> | <digit> <number> Example: 1 is primitive 1 21 is construct of 2 and 1 321 is construct of 3 and 21

ASN.1: Modules Group of assignments: Modules Start with capital letters Usually modules are built from primitive (atomic) data types (e.g., INTEGER, REAL, etc..) May use ASN.1 constructs (e.g., SET, SEQUENCE, etc.)

ASN.1: Modules Constructs: “list makers” Primitives data types A module PersonnelRecord (a set of data types) Construct: alternatives Primitives data types Three construction mechanisms (develop structured data types): Alternatives: CHOICE List: SET and SEQUENCE Repetition: SET OF and SEQUENCE OF

Outline Introduction SNMP Organization model SNMP Information model ASN.1 review SMI & MIB MIB development SNMP Communication model SNMP Administration model & Security

SNMP Information Model Structure of Management Information (SMI) Management Information Base (MIB) Managed Object Scalar Aggregate or tabular object Collections of related objects are defined in MIB modules These modules are written using an adapted subset of ASN.1 Structure of Management Information (SMI) defines that adapted subset

MIT: Management Information Tree SNMP MIB has a hierarchal structure It is called Management Information Tree (MIT) To group related information e.g., all information about NIC is grouped as a sub-tree of node corresponding to the NIC There are two (in fact three including traps) types of node Leaf node  management parameter & value Some leaf nodes define traps Middle node  to group other nodes Each node has a unique ID in the tree (known as OID): 1) By concatenation the name of (grand) parent nodes & this node 2) By concatenation of the child # of (grand) parent nodes & this node

Defined using SMI

MIB Structure Object identification? How to construct the MIT Parent & Child relations

Object Name & MIT Structure Each object is uniquely identified through hierarchical naming in MIT SMI uses two mechanisms altogether A descriptive name Example: sysName, uptime, ospfVersion, … Location of the object in MIT Each object has a unique parent node Each node has a unique childe # in the children of its parent Example: ospfVersion is the first version of ospf

MIB Structure: Parent Nodes Does not contain any data No data type is needed Used only for grouping related objects Only to construct the MIT Name Location in MIT

SMI Type for Parent Nodes OBJECT IDENTIFIER Is a primitive type Commonly used syntax internet OBJECT IDENTIFIER ::= { dod 1 } Alternative syntax internet OBJECT IDENTIFIER STATUS Current Description "The Internet Sub-node" ::= { dod 1 } Descriptive name MIT Location

Alternative Naming All these are the same internet OBJECT IDENTIFIER ::= {iso org(3) dod(6) 1 } internet OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)} internet OBJECT IDENTIFIER ::= {1 3 6 1} internet OBJECT IDENTIFIER ::= {iso org dod internet } internet OBJECT IDENTIFIER ::= { iso org dod(6) internet(1) } internet OBJECT IDENTIFIER ::= { iso(1) org(3) 6 1 } internet OBJECT IDENTIFIER ::= { dod 1 }

MIB Structure: Leaf Nodes Leaf nodes contain data Data can be Simple scalar Complex structure The type of the data must be specified In addition to Name MIT Location

Object Data Type Although SMI is based on ASN.1, it has its own types, examples: INTEGER, Integer32, Unsigned32, OCTET STRING, OBJECT IDENTIFIER, IPaddress, Counter32, Counter64, SEQUENCE, … Subtype: INTEGER (0..255), OCTET STRING (SIZE 0..255) Enumeration error-status INTEGER { noError(0) tooBig(1)}

Application-Wide SMI Types 231 IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING 160.85.128.1 [ms] 10 1 20 2 A0 55 80 01

SMI Structured Types SEQUENCE, SEQUENCE OF: SET, SET OF, CHOICE of ASN.1 are not included in SNMP-based management Usually used to construct tables or two-dimensional arrays of other types of data An individual row is a SEQUENCE, defining the different types making up the various columns A collection of rows forming the table is made using a SEQUENCE OF construct It must be a sequence of the same type Example: TCP connection table

SMI Type for Leaf Nodes OBJECT-TYPE: Used to specify managed objects Includes the data type, status, and semantics The OBJECT-TYPE construct has four parts: SYNTAX: The basic data type associated with the object (Only one data type per object in SMI!) MAX-ACCESS: Whether the object can be read, written, created, or used in a notification STATUS: Whether the object definition is current, obsolete (for historical purposes), or deprecated DESCRIPTION: A human-readable definition of the object, giving all necessary semantic information

SMI: OBJECT-TYPE Example ipInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of input datagrams successfully delivered to IP user- protocols (including ICMP)" ::= { ip 9}

MIB Structure: Notifications Notifications are sent by agent to inform manager Usually contains some objects to be send by the notification In addition to Name MIT Location

SMI Types for Notifications NOTIFICATION-TYPE macro is used to define traps Trap name, OID, Objects, and descriptions TemperatureAlarm NOTIFICATION-TYPE OBJECTS {lowThreshold, highThreshold, currentTemperature} STATUS current DESCRIPTION "This alarm indicates that system temperature violates configured thresholds" ::= { environmentTraps 4}  

MIB Structure: Modules Modules are high-level optional abstraction layer to group related management objects Provide some information about the objects Usually, each HW/SW component is treated as a module, e.g., Protocols: IP, TCP, UDP, … Line Card Modem …

SMI Type for Modules MODULE-IDENTITY Allows related objects to be grouped together within a MIB module It specifies the location of module in the MIT More over, the MODULE-IDENTITY construct contains clauses that document the module This includes the author of the module, the data of the last update, a revision history, and a textual description of the module.

SMI: MODULE-IDENTITY Example ipMIB MODULE-IDENTITY LAST-UPDATED “941101000Z” ORGANZATION “IETF SNMPv2 Working Group” CONTACT-INFO “Keith McCloghrie ……” DESCRIPTION “The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.” REVISION “019331000Z” ……… ::= {mib-2 48}

MIB Structure: MIB Coarse grain grouping of objects Related modules are grouped in a MIB, e.g., Cisco has it own MIB file(s) containing the modules of Cisco routers Standard MIBs (e.g., RFC1213) are defined in separated MIB files

SMI Type for MIB Definition <mib name> DEFINITIONS ::= BEGIN <imports> <definitions> END Import is similar to #include in C IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI Definitions include OBJECT-TYPE, OBJECT IDENTIFIER, MODULE-IDENTITY

MIB Example SIP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, IpAddress FROM SNMPv2-SMI; sipMIB MODULE-IDENTITY LAST-UPDATED "9403311818Z" ORGANIZATION "IETF Interfaces Working Group" CONTACT-INFO " ... " DESCRIPTION "The MIB module to describe SMDS interfaces" ::= { mib-2 36 } sipMIBObjects OBJECT IDENTIFIER ::= { sipMIB 1 }

MIB Example sipL3Table OBJECT-TYPE SYNTAX SEQUENCE OF SipL3Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP L3 parameters and state variables, one entry per SIPL3 interface." ::= { sip 1 } sipL3Entry OBJECT-TYPE SYNTAX SipL3Entry "This list contains SIP L3 parameters and state variables." INDEX { sipL3Index } ::= { sipL3Table 1 } END

SMI for Organization of a MIB Defined by DEFINITION Defined by MODULE-IDENTITY Defined by OBJECT-TYPE Defined by OBJECT IDENTIFIER Defined by NOTIFICATION-TYPE Note: These are currently in used SNMPv1 & SNMPv2 macros (SNMPv2 replaced some SNMPv1 macros)

Managed Object: Single Instance Object type and data type are synonymous Object identifier is data type, not instance

Managed Object: Multiple Instances

Object Types Two main object types Simple objects According to where multiple instances of objects are Simple objects Value is a scalar (Integer, String, …) Single instance in each node Examples: System name, Upitme, … Aggregate objects also called tabular objects A group of objects Can be represented by a table with Columns of objects, Rows of instances

Aggregate Object Example IP address table Consists of objects: IP address Subnet mask Interface Broadcast address MTU Multiple instances of these objects associated (per interface) with the node

Aggregate Object Type as Table The objects TABLE T and ENTRY E are objects that are logical objects. They define the grouping and are not accessible Columnar objects are objects that represent the attributes and hence are accessible Each instance of E is a row of columnar objects 1 through 5 Multiple instances of E are represented by multiple rows We need to define each element in a row (the columnar objects) Then we need to define a SEQUENCE of the columnar objects which is the ENTRY Finally, we define a “SEQUENC OF” Enterry

Aggregate Object Instances as Table The row # in this example T T.E T.E.1.1 T.E.5.1 T.E.2.1 T.E.3.1 T.E.4.1 T.E.1.2 T.E.5.2 T.E.2.2 T.E.3.2 T.E.4.2 T.E.1.3 T.E.5.3 T.E.2.3 T.E.3.3 T.E.4.3 T.E.1.4 T.E.5.4 T.E.2.4 T.E.3.4 T.E.4.4 Object ID Not accessible {Table, Entry, Object, Index } Row 3: the third instance of the object

Table Indexing Index can be anything Usually a column is used as index not row # The index of table

Aggregate Object Example: IP Table Aggregate M.O. : Table Object

Aggregate Object Example: IP Table Aggregate M.O. : Entry Object

Aggregate Object Example: IP Table Aggregate M.O. : Columnar Objects ipAdEntAddr OBJECT-TYPE ... ::= { ipAddrEntry 1 } ipAdEntIfIndex OBJECT-TYPE ::= { ipAddrEntry 2 } ipAdEntNetMask OBJECT-TYPE ::= { ipAddrEntry 3 } ipAdEntBcastAddr OBJECT-TYPE ::= { ipAddrEntry 4 } ipAdEntReasmMaxSize OBJECT-TYPE ::= { ipAddrEntry 5 }

Aggregate Object Example: IP Table Managed objects Their location in the MIB Their data types

Aggregate Object Example: IP Table ipAddrTable {1.3.6.1.2.1.4.20} ipAddrEntry (1) ipAdEntAddr (1) ipAdEntIfIndex (2) ipAdEntNetMask (3) ipAdEntBcastAddr (4) ipAdEntReasmMaxSize (5) Columnar object ID of ipAdEntBcastAddr is (1.3.6.1.2.1.4.20.1.4) iso org dod internet mgmt mib ip ipAddrTable ipAddrEntry ipAdEntBcastAddr 1 3 6 1 2 1 4 20 1 4

Aggregate Object Example: IP Table Row ipAdEntAddr ipAdEntIfIndex IpAdEntNetMask IpAdEntBcastAddr IpAdEntReasmMaxSize 1 123.45.2.1 255.255.255.0 12000 2 123.45.3.4 3 255.255.0.0 165.8.9.25 10000 4 9.96.8.138 15000 Object instances of ipAddrTable (1.3.6.1.2.1.4.20) Node 1 under ipAddrEntry Columnar Object Row # Object Identifier ipAdEntAddr 1.3.6.1.2.1.4.20.1.1 2 {1.3.6.1.2.1.4.20.1.1.123.45.3.4} ipAdEntIfIndex 1.3.6.1.2.1.4.20.1.2 3 {1.3.6.1.2.1.4.20.1.2.165.8.9.25} ipAdEntBcastAddr 1.3.6.1.2.1.4.20.1.4 1 {1.3.6.1.2.1.4.20.1.4.123.45.2.1} IpAdEntReasmMaxSize 1.3.6.1.2.1.4.20.1.5 4 {1.3.6.1.2.1.4.20.1.5.9.96.8.138} Index of the object instance Object ID for ipAddrEntry Object Id for specific instances

Standard MIB Information model of SNMP standard SMI Which is discussed MIB A set of standard MIBs The standard MIBs define The overall structure of MIB The location of future development is specified The required management objects must be implemented

Standard MIBs To identify objects used in Internet experiments {1 3 6 1} directory mgmt experimental private (1) (2) (3) (4) To identify objects used in Internet experiments Reserved for future use Used for objects defined in IAB-approved documents Used heavily by commercial vendors

Standard MIBs Internet {1 3 6 1} directory mgmt experimental private (1) (2) (3) (4) mib-2 (1) system (1) interfaces (2) at (3) ip (4) icmp (5) snmp (11) transmission (10) cmot (9) egp (8) udp (7) tcp (6)

Standard MIBs Internet {1 3 6 1} directory mgmt experimental private (1) (2) (3) (4) enterprises (1) hp (11) cisco (9) 3Com (43) Cabletron (52)

Interface Group

IP Group

IP Routing Table

SNMP Information Model Characteristics Not possible to change the structure of a MIB In SNMPv2 it is possible to change tables No explicit action is supported Action through side-effect of setting a value Access is provided only to leaf objects in the MIB tree Not possible to access an entire table or a row of a table with a single atomic action SNMP MIBs are NOT object-oriented Inheritance is not supported These simplify the implementation of SNMP but limit the capability of the NMS

Outline Introduction SNMP Organization model SNMP Information model ASN.1 review SMI & MIB MIB development SNMP Communication model SNMP Administration model & Security

SNMP MIB Modeling MIB is essential for developing and operating management systems Analysis of MIB objects is required before writing MIB definitions Using the designed model, MIB definitions can be easily generated Similar to software engineering -- must design a system before any implementation!

Step 1: MIB Design Components Attributes Statistics State Setting Collections of logical & physical component that are being managed Attributes Fairly static properties of a modeled object Statistics Useful information about what a system has been doing State The current condition of a system Setting Value of system parameters Actions Control a system Traps Notifications

Components Components Physical containment E.g., a list of interface cards Logical containments E.g., software components Start from the top level and work down until reasonable size is reached Cardinality How many of an item are present in a system?

Modeling Example - Router Containments Hardware CPU RAM Line Card NIC Software Routing OSPF Management SNMP

Attributes The fairly static properties Examples Typically read-only NIC serial number # Of CPU Amount of RAM Manufacture data of router backplane OSPF version …

Statistics Show a picture of the past (history) Examples A record of the interesting events which occurred since a specific point in time Read-only Examples # of sent packets # of dropped packets # of CPU overutilization # of OSPF restarts …

State Show the current condition of the resource Read-only Stages of operation, examples Enabled/Disabled state of NIC Used/Unused MD5 in OSPF … Resource usage level, examples Current routers temperature Current link bandwidth Current CPU usage

Setting The configurable parameters of system Examples System behavior depends on them Read-Write Examples IP address OSPF area CPU over utilized threshold IPsec parameter settings …

Actions SNMP does not support explicit action operation Represented in terms of implicit actions which do their work through side effects This is achieved by setting some value of a MIB object Typically write-only Examples Restart BGP Ping a remote router Shut down a NIC …

Trap To notify the manager about the events Examples No Read, No Write Over temperature trap CPU over utilized trap BGP route changes (route flapping) Link over utilization …

Step 2: Translate Model into MIB Each component is modeled as a module: MODULE-IDENTITY General guide lines Sub-components with a cardinality > 1 should be part of a table Attributes of an object can be Octet String - human readable descriptions or binary data Integer - measurable quantities Statistics representing increasing values are Counter type Stats representing high or low water marks are Integer type System setting can be any type depends on the setting Integer for threshold, String for Hostname, IP-Address for address, … Actions are encoded as Enumerate types ON (1), OFF (0), START(2), STOP (3), … Traps also include additional data to be send States, Setting, and Statistics

Step 3: Using the MIB MIB files are complied in both manager & agent software

Step 3: Using the MIB (cont’d) Compiling MIB in NMS Usually, is simply parsing and/or processing Examples Simple MIB Browser parses the MIB and display its tree structure More powerful NMS applications map OIDs to high-level management parameters, e.g., OSPF version Cisco  1.2.3.4.5.6.7.8 Juniper  1.2.6.1.1.1.1.

Step 3: Using the MIB (cont’d) Compiling MIB in Agent Is developing an executable code from MIB Based on an existing agent framework Example Net-SNMP agent Implements SNMP protocol (we don’t need to develop it) Provides an API to develop plug-in (module) A MIB to read OSPF version is implemented as a module It uses the Net-SNMP API to connect the agent core It uses the vendor specific API to access the version of the OSPF

Outline Introduction SNMP Organization model SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

Communication Model Architecture SNMP protocol SNMP protocol MIB Management messages SNMP protocol Packet formats & operation SNMP protocol MIB SNMP protocol’s management parameters

Communication Model: Architecture Communicate management information between network manager and managed elements Operation: 5 messages From manager to agent get-request, get-next request, set-request From agent to manager get-response, trap SNMP messages are exchanged using UDP (connection less) transport protocol Port 161: Agent listens for messages from manager Port 162: Manager listen for trap messages from agents

SNMP Protocol Message Types Function GetRequest GetNextRequest Mgr-to-agent: “get me data” (instance or next in list) SetRequest Mgr-to-agent: set MIB value Agent-to-mgr: value, response to Request GetResponse Agent-to-mgr: inform manager of exceptional event Trap

Communication Model: SNMP Protocol Message & PDU structure

SNMPv1 Protocol: Message Formats Version Community SNMP PDU (a) SNMP message PDU type request id Variable bindings (b) GetRequest PDU, GetNextRequest PDU, and SetRequest PDU PDU type request id error status error index Variable bindings (c) GetResponse PDU PDU type enter- prise agent addr generic trap specific trap time stamp Variable bindings (d) Trap PDU

GetRequest & GetRespone PDU Is issued by an SNMP manager to retrieve information Includes PDU type, request-id & variablebindings GetResponse PDU containing the same request-id is used for the reply Operation is atomic (all values are returned or none is valid) If error-status = noError  All variable bindings are valid If error-status ≠ noError error-index = index of a variable binding that cause error None of variable binding is valid Possible error-status: noSuchName: object instance cannot be found tooBig: the size of resulting values exceed a limitation genErr: Generic error

SetRequest & GetResponse PDU Is issued by an SNMP manager to modify information GetResponse PDU containing the same request-id is used for the reply if the operation succeeds, a GetResponse PDU is returned with the same variablebindings as in the original SetRequest PDU The operation is atomic If any one of the values can’t be set, then the whole operation fails Manager should re-set the values However, transaction is not supported Possible error-status: noSuchName, tooBig, genErr badValue: PDU contains at least one pair of variable name and value that is inconsistent

Trap PDU Is issued by an SNMP agent to notify NMS of some significant event Trap PDU does not require a response and is not acknowledged  can get lost Generic Trap types: coldStart (0): unexpected restart due to a crash or major fault warmStart (1): routine restart linkDown (2): a communication link is inoperational linkUp (3): the link is back in operation authenticationFailure (4): received authentication-failed egpNeighborLoss (5): EGP neighbor is down enterpriseSpecific (6): some enterprise-specific event occurred

GetRequest Issues Assume browsing the following MIB

GetRequest Issues (cont’d) Hidden assumption in the previous example We know all the elements in MIB including the number of columns and rows in the table In practice, tables are dynamic We may don’t know the number or row If we have MIB, we only know column # In some situations, we may have not all information about MIB We just know an object identifier

Solution for GetRequest Issues SNMP support two object access modes: 1) Random access: Using the OID 2) Serial access: Using Lexicographical order Lexicographical ordering is also referred to as: preorder traversal (root, left, right) of a tree depth-first search Useful for examining MIBs whose structure is not known to NMS It is known as “MIB walk”

Lexicographical Ordering Example of lexicographic order of numbers

Lexicographical Ordering Example of lexicographic order of MIB Lexicographical order of OIDs MIB 1 1.1 1.1.5 1.1.18 1.2 1.2.6 2 2.2 2.10 2.10.9 3 3.4 3.21 9

GetNextRequest Example

GetNextRequest & GetResponse PDU Is issued by an SNMP manager to retrieve information The PDU is the same as GetRequest PDU except: In the GetRequest PDU, each variable in the variablebindings list refers to an object instance whose value is to be returned In the GetNextRequest PDU, for each variable in the variablebindings, the value of the object instance that is next in lexicographic order is returned Similar to GetRequest, operation is atomic Allows NMS to discover the structure of a MIB view dynamically Provides an efficient mechanism for searching a table whose entries are unknown

Communication Model: SNMP MIB

Outline Introduction SNMP Organization model SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

SNMP Security Concepts Authentication service Agent may wish to limit access to the MIB to authorized managers Access policy Agent may wish to give different access privileges to different managers

SNMP Community The first version of SNMP had only a simple security functionality, through communities A pair of manager and agent Each community Has a unique name Also called its community string A subset of MIB objects available to the community Also called a MIB view An access mode (read only or read-write) is defined for each community

SNMP Community (cont’d) A managing entity could be part of an agent’s community only by knowing the community name The name was in effect also the password! The community name is always sent in the clear (unencrypted) so anyone can sniff it! Each SNMP agent can define multiple communities Multiple manager can manage the agent Different views & access

SNMP Community (cont’d) SNMP MIB View A subset of objects within a MIB Different MIB views may be defined for each community The objects in a view need not belong to a single sub-tree SNMP Access Mode An access mode {READ-ONLY, READ-WRITE} is defined for each community The access mode is applied uniformly to all objects in the MIB view SNMP Community Profile A combination of a MIB view and an access mode

Community Profile Operations on an object determined by community profile and the access mode of the object

MIB ACCESS Category vs. SNMP Access Mode READ-ONLY READ-WRITE read-only Available for get operation read-write Available for get and set operations write-only Implementation-specific Available for set, implementation-specific for get not accessible Unavailable

SNMPv1 Security: Drawbacks If there is not any attacker!!!, community is a sufficient, but! No encryption (everything is transferred in plain) The community string can be sniffed Attacker will be manager! Transferred data can be sniffed  no confidentiality No integrity check Data modification  invalid management parameters Not per-user password, community string a shared secret! If a member of community reveal the string  whole community is compromised No message stream protection Replay attack

SNMPv1 Security (cont’d) In the end, it was better than nothing at the time, and could be used reasonably Block SNMP at firewalls to prevent access by all external intruders Change community strings from default values (usually “public” for read-only and “private” for read-write) Only allow SNMP requests from certain internal addresses (though addresses could be spoofed) Use a dedicated line to a device for SNMP access But, because of security concerns, early SNMP was primarily used only for monitoring SetRequest was rarely used or supported No community with read-write access!

Outline Introduction SNMP Organization model SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

Summary SNMP (Internet Management system) SMI (subset of ASN.1): Data type language MIB: The virtual database of management objects SNMP protocol: transmit messages SNMP can be viewed as four models Organization model: Manager, Agent, Proxy, … Information model: SMI & MIB Communication model: get/set/response/ trap Security model: community profile

Many of these problems are addressed in SNMPv2! Limitations of SNMPv1 SNMP may not be suitable for the management of truly large networks because of the performance limitations of polling SNMP is not well suited for retrieving large volumes of data, such as an entire routing table SNMP traps are unacknowledged & may not be delivered SNMP provides only trivial authentication SNMP does not support explicit actions SNMP does not support manager-to-manager communication Many of these problems are addressed in SNMPv2!

References Reading Assignment: Chapters 4 & 5 of “Mani Subramanian,  ‘Network Management: Principles and Practice’, Pearson Education, 2012” www.simpleweb.org R. Dssouli, “Advanced Network Management,” Concordia Institute for Information Systems Engineering, http://users.encs.concordia.ca/~dssouli/INSE 7120.html Nhut Nguyen, “Telecommunications Network Management,” University of Texas at Dallas, www.utdallas.edu/~nhutnn/cs6368/ J. Won-Ki Hong, “Network Management System,” PosTech University, dpnm.postech.ac.kr/cs607/