0% found this document useful (0 votes)
100 views

Limitations of Snmpv1 History of Snmpv2 - Hierarchies - Security Snmpv2 Protocol Operations Transport Independence Rfcs

SNMPv2 HIERARCHIES: ORIGINAL IDEA MANAGER TO MANAGER (M2M) MIB (EXPRESSION, EVENT AND NOTIFICATION LOG MIB) SCRIPT (SCRIPT AND SCHEDULE MIB) REMOTE OPERATIONS BASED (REMOPS MIB) THREE APPROACHES ARE STANDARDIZED.

Uploaded by

coolparkinglot
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
100 views

Limitations of Snmpv1 History of Snmpv2 - Hierarchies - Security Snmpv2 Protocol Operations Transport Independence Rfcs

SNMPv2 HIERARCHIES: ORIGINAL IDEA MANAGER TO MANAGER (M2M) MIB (EXPRESSION, EVENT AND NOTIFICATION LOG MIB) SCRIPT (SCRIPT AND SCHEDULE MIB) REMOTE OPERATIONS BASED (REMOPS MIB) THREE APPROACHES ARE STANDARDIZED.

Uploaded by

coolparkinglot
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

SNMPv2

OVERVIEW:

LIMITATIONS OF SNMPv1 HISTORY OF SNMPv2 HIERARCHIES SECURITY SNMPv2 PROTOCOL OPERATIONS TRANSPORT INDEPENDENCE RFCs
Copyright 2001 by Aiko Pras These sheets may be used for educational purposes

LIMITATIONS OF SNMPv1
UNDOCUMENTED RULES LIMITED ERROR CODES LIMITED DATA TYPES LIMITED NOTIFICATIONS LIMITED PERFORMANCE TRANSPORT DEPENDENCE LACK OF HIERARCHIES LACK OF SECURITY

HISTORY OF SNMPv2
SNMP security SMP
full standard

SNMP/SMI v1

SMIv2

SNMPv3 DISMAN

1990

1991

1992

1993

proposed standard

1994

1995

V2Usec V2* ... draft standard

SNMPv2

parties

proposed standard

community

1996

1997

1998

1999

full standard
2000

draft standard

HIERARCHIES: ORIGINAL IDEA


MANAGER TO MANAGER (M2M) MIB

M
inform command

M
poll

STANDARD MIB APPROACH LIMITED FUNCTIONALITY RUN-TIME BEHAVIOUR MUST BE DEFINED AT IMPLEMENTATION TIME

HIERARCHIES: STATUS
WORK HAS MOVED TO A SEPARATE DISTRIBUTED MANAGEMENT GROUP (DISMAN)

THREE APPROACHES ARE STANDARDIZED: MIB BASED (EXPRESSION, EVENT AND NOTIFICATION LOG MIB) SCRIPT BASED (SCRIPT AND SCHEDULE MIB) REMOTE OPERATIONS BASED (REMOPS MIB)

SNMPv2 SECURITY: WHAT HAPPENED?


APRIL 1993: PROPOSED STANDARD FOUR EDITORS SECURITY BASED ON PARTIES FIRST PROTOTYPES APPEARED SOON JUNE 1995: PROPOSED STANDARD REJECTED BY TWO OF THE ORIGINAL EDITORS! AUGUST 1995: GENERAL AGREEMENT THAT PARTY BASED MODEL WAS TOO COMPLEX! MANY NEW PROPOSALS APPEARED: SNMPv2C: COMMUNITY BASED SNMPv2U: USER BASED ... 1997: NEW SNMPv3 WORKING GROUP WAS FORMED WITH NEW EDITORS

SNMPv2 PROTOCOL OPERATIONS


get set

MIB
response
manager agent manager

MIB
response
agent

getNext

trap

MIB
response
manager agent manager

MIB
agent

getBulk

inform

MIB
response
manager agent

response
manager

MIB
"agent"

GET
manager

get

agent

MIB response

SIMILAR TO SNMPv1, EXCEPT FOR "EXCEPTIONS" POSSIBLE EXCEPTIONS:


noSuchObject noSuchInstance

EXCEPTIONS ARE CODED WITHIN THE VARBINDS EXCEPTIONS DO NOT RAISE ERROR STATUS AND INDEX

GET EXAMPLES
get(1) response(error-status => noError, 1.2 => noSuchObject) get(1.1) response(error-status => noError, 1.2.0 => noSuchInstance) get(1.1.9) response(error-status => noError, 1.2.0 => noSuchInstance) get(1.2) response(error-status => noError, 1.4.0 => noSuchObject) get(1.4.0) response(error-status => noError, 1.4.0 => noSuchObject) get(1.1.0, 1.4.0) response(error-status => noError, 1.1.0 => 130.89.16.2, 1.4.0 => noSuchObject)

GET-NEXT
manager

getNext

agent

MIB response

SIMILAR TO SNMPv1, EXCEPT FOR "EXCEPTIONS" POSSIBLE EXCEPTIONS:


endOfMibView

EXAMPLE
getNext(1.4.0) response(error-status => noError, 1.4.0 => endOfMibView)

GET-BULK
manager

getBulk

agent

MIB response

NEW IN SNMPv2

TO RETRIEVE A LARGE NUMBER OF VARBINDS

IMPROVES PERFORMANCE!

GETBULK PERFORMANCE
3300 2910
Source: Steve Waldbusser, Carnegie-Mellon University Figures based on original (party based) SNMPv2

v1 v2

1600

210

195

110

NO SECURITY

WITH AUTHENTICATION

WITH ENCRYPTION

GET-BULK
getBulk REQUEST HAS TWO ADDITIONAL PARAMETERS:
non-repeators max-repetitions

THE FIRST N ELEMENTS (non-repeators) OF THE VARBIND LIST ARE TREATED AS IF THE OPERATION WAS A NORMAL getnext OPERATION

THE NEXT ELEMENTS OF THE VARBIND LIST ARE TREATED AS IF THE OPERATION CONSISTED OF A NUMBER (max-repetitions) OF REPEATED getnext OPERATIONS

GET-BULK

REQUEST(non-repeaters = N; max-repetitions = M; VariableBinding-1; ... ; VariableBinding-N; VariableBinding-(N+1); ... ; VariableBinding-(N+R) )

N-TIMES

RESPONSE( VariableBinding-1; ... ; VariableBinding-N; VariableBinding-(N+1); ... ; VariableBinding-(N+R)


1st LEXICOGRAPHICAL SUCCESSOR 2n d LEXICOGRAPHICAL SUCCESSOR 3 th LEXICOGRAPHICAL SUCCESSOR

VariableBinding-(N+1); ... ; VariableBinding-(N+R) VariableBinding-(N+1); ... ; VariableBinding-(N+R) ... VariableBinding-(N+1); ... ; VariableBinding-(N+R)
M-TIMES

M th LEXICOGRAPHICAL SUCCESSOR

GET-BULK EXAMPLE
getBulk(max-repetitions = 4; 1.1) response( 1.1.0 => 130.89.16.2 1.2.1.0 => printer-1 1.2.2.0 => 123456 1.3.1.1.2.1 => 2 )

getBulk(max-repetitions = 3; 1.3.1.1;

1.3.1.2;

1.3.1.3)

response( 1.3.1.1.2.1 => 2; 1.3.1.2.2.1 => 1; 1.3.1.3.2.1 => 2 1.3.1.1.3.1 => 3; 1.3.1.2.3.1 => 1; 1.3.1.3.3.1 => 3 1.3.1.1.5.1 => 5; 1.3.1.2.5.1 => 1; 1.3.1.3.5.1 => 2 )

SET
manager

set

agent

MIB response

SIMILAR TO SNMPv1 CONCEPTUAL TWO PHASE COMMIT: PHASE 1: PERFORM VARIOUS CHECKS PHASE 2: PERFORM THE ACTUAL SET

MANY NEW ERROR CODES ARE DEFINED

NEW ERROR CODES FOR SETS SNMPv1


PHASE 1:
badValue badValue badValue badValue badValue noSuchName noSuchName noSuchName noSuchName genErr genErr genErr genErr

SNMPv2
wrongValue wrongEncoding wrongType wrongLength inconsistentValue noAccess notWritable noCreation inconsistentName resourceUnavailable genErr CommitFailed undoFailed

PHASE 2:

TRAP
manager agent

MIB trap

SNMPv1:
COLD START WARM START LINK DOWN LINK UP AUTHETICATION FAILURE EGP NEIGHBOR LOSS

SNMPv2:
MIBs MAY NOW INCLUDE NOTIFICATION TYPE MACROS FIRST TWO VARBINDS: sysUptime AND snmpTrapOID USES SAME FORMAT AS OTHER PDUs

EXAMPLE OF NOTIFICATION TYPE MACRO

linkUp OBJECTS STATUS DESCRIPTION entity ::= {snmpTraps 4}

NOTIFICATION-TYPE {ifIndex} current "A linkUp trap signifies that the has detected that the ifOperStatus object has changed to Up"

INFORM
manager "agent"

inform

MIB

Response

CONFIRMED TRAP
ORIGINALLY TO INFORM A HIGHER LEVEL MANAGER SAME FORMAT AS TRAP PDU POSSIBLE ERROR: tooBig

REPORT
manager agent

report

NEW PDU TO SIGNAL PROTOCOL EXCEPTIONS / ERRORS NO SEMANTICS DEFINED IN SNMPv2

TRANSPORT DEPENDANCE

SNMPv1: UDP

SNMPv2: UDP CLNS (OSI) DDP (APPLETALK) IPX

SNMPv2 RFCs
COMMUNICATION MODEL
DRAFT STANDARD RFC 1905, RFC1906

COMMUNITY BASED SNMP SAME SECURITY MECHANISMS AS SNMPv1 EXPERIMENTAL STATUS RFC 1901 USER BASED SECURITY (AUTHENTICATION / ENCRYPTION / ACCESS CONTROL) EXPERIMENTAL STATUS RFC 1909, RFC1910 STANDARD RFC2578, RFC2579, RFC2580

SECURITY MODEL - SNMPv2C:

SECURITY MODEL - SNMPv2U:

INFORMATION MODEL:

SNMPv2 - SUMMARY
TRAPS HAVE SAME FORMAT AS OTHER PDUS GET-BULK PDU ADDITIONAL ERROR CODES FOR SETS SNMPv2C: COMMUNITY BASED SNMPv2U: USER BASED

IMPROVED COMMUNICATION MODEL

TWO SECURITY MODELS

INDEPENDENCE OF UNDERLYING TRANSPORT


MIB-II SPLIT INTO MODULES

SECURITY AND HIERARCHIES TO SNMPv3 & DISMAN IMPROVED INFORMATION MODEL (SMIv2)
ADDITIONAL DATA TYPES TEXTUAL CONVENTIONS E.G. ROW STATUS NOTIFICATIONS

You might also like