RE: Draft EOS minutes

At 12:19 AM 9/16/2002 -0400, Harrington, David wrote:
>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?

right. I think you are making a very important point, which is that
the IETF is done working on SNMPv1 (and SNMPv2C).  The IETF should
not spend any effort whatsoever fixing these versions of SNMP.

>dbh

Andy


> 
> -----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 
><mailto:[email protected]>[email protected] 
>+(44) 192 575 3018 
>-----Original Message----- 
>From: Harrington, David <<mailto:[email protected]>[email protected]> 
>To: 'Tom Petch' <<mailto:[email protected]>[email protected]>; <mailto:[email protected]>[email protected] <<mailto:[email protected]>[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 
><mailto:[email protected]>[email protected] 
>