|
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:nwnetworks@dial.pipex.com]
Sent: Friday, September
13, 2002 6:47 AM
To: Harrington, David;
eos@ops.ietf.org
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.
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
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?
|