[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft EOS minutes



Title: 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
nwnetworks@dial.pipex.com
+(44) 192 575 3018
-----Original Message-----
From: Harrington, David <dbh@enterasys.com>
To: 'Tom Petch' <nwnetworks@dial.pipex.com>; eos@ops.ietf.org <eos@ops.ietf.org>
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:nwnetworks@dial.pipex.com]
Sent: Thursday, September 12, 2002 3:24 PM
To: Glenn Waters; eos@ops.ietf.org
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?