RE: Draft EOS minutes

Hmmm, let's see.
SNMPv1 has been declared historic. 
SNMPv3 is the recommended protocol for network management. 
SNMPv3 has a boot count.
A boot count solves the reported problem.
Ergo, the SNMP community has already provided a protocol update that solves
this problem.
 
I believe the world's most widely used enterprise routers already include
support for SNMPv3.
SNMPv3 needs to be enabled and configured in the router before it will be
effective.
SNMPv3 needs to be used by the operators before it will be effective.
Ergo, you should use the SNMPv3 implementation provided in the device to
effectively solve your reported problem.
 
Right?
dbh
 
 -----Original Message-----
From: Tom Petch [mailto:[email protected]]
Sent: Friday, September 13, 2002 6:47 AM
To: Harrington, David; [email protected]
Subject: Re: Draft EOS minutes



Sorry I am less than clear; practical example follows.
 
Using the world's most widely used enterprise router and software, if I
reboot many times, I get (mostly) the precise same sequence of SNMPv1 traps
from the same IP address/port with the same OIDs and the same values.  The
only difference from one sequence to another is in the (copy of the)
sysUpTime, which, reset on boot, has a very small standard deviation, more
like hundredths of a second as opposed to a second.  (These boxes really are
predictable).
 
So when, as has happened, the router boots and crashes during startup and
does so every two minutes or less, how can I distinguish this situation from
packets getting duplicated in the network, even perhaps as part of a
malicious replay attack?
 
I think of TCP connection startup where I can tell because (most) systems
use a pseudo-random seed to initialise the sequence number so I expect to
detect a duplicate SYN or SYN-ACK.
 
If the request-id was pseudo-random, no problem - but it isn't!
 
SNMPv3 would have a boot count but SNMPv1 packets, native or created via
RFC2576, do not.
 
Tom Petch, Network Consultant
[email protected] <mailto:[email protected]> 
+(44) 192 575 3018

-----Original Message-----
From: Harrington, David < [email protected] <mailto:[email protected]> >
To: 'Tom Petch' < [email protected]
<mailto:[email protected]> >; [email protected]
<mailto:[email protected]>  < [email protected] <mailto:[email protected]> >
Date: 12 September 2002 23:00
Subject: RE: Draft EOS minutes


Hi Tom,
 
I'm a bit confused about your suggestion. Maybe you can reword so I can
understand your point.
 
PDUs don't really deliver notifications. Messages deliver PDUs. PDUs may
contain notifications.
 
Are you asking that each message be identified? That information is already
available by checking the source address in the UDP packet. The message
header includes a request ID, so duplicates can be detected. Snmpv3
supplements this with the contextEngineID to identify the engine that
sourced the PDU.
 
Am I misunderstanding your question?
 
dbh

-----Original Message-----
From: Tom Petch [mailto:[email protected]]
Sent: Thursday, September 12, 2002 3:24 PM
To: Glenn Waters; [email protected]
Subject: Re: Draft EOS minutes


Following the work in Disman has highlighted a number of difficulties with
the basic technology of SNMP but as has been pointed out to me, most of
those are Mib-related,not SNMP-the-protocol-related.
 
But one that I see as SNMP (sensu stricto) and hence a possibility for this
group, is the difficulty of identifying a PDU (as opposed to identifying a
MIB object at which SNMP is very good).  Sometimes it matters to know where
information came from eg which PDU delivered the Notification so as to
track/correlate/eliminate duplicates etc.
 
As defined, SNMP does not seem to have any reliable way of doing so; any
ideas?
 
 
Tom Petch
[email protected] <mailto:[email protected]>