Eric, it would be good if you could describe the "spoofing" and possible other vulnerabilities that you see. Not sure that the generic IETF mailing list is the proper mailing list for that. I propose we move the discussion to the SNMPv3 mailing list. I copied the WG chairs to see if they would permit us to have that discussion over there. If so, they can send the ptr to the list. Thanks, Bert > -----Original Message----- > From: Fleischman, Eric [mailto:eric.w.fleischman@boeing.com] > Sent: woensdag 6 augustus 2003 20:08 > To: Uri Blumenthal; Bill Strahm > Cc: ietf@ietf.org > Subject: RE: Securing SNMPv3 via SSH tunnels > > > Uri, > > I don't think that this list would be well served by a debate > on whether SNMPv3's security provisions are adequately secure > or not, though I personally would greatly value having a > private discussion with interested individuals on that topic. > > Suffice it to say here that I am familiar with RFC 3414 and > RFC 3415 and I am skeptical that existing SNMPv3 security > provisions provide adequate protections for the application I > am building. I am therefore seeking to supplement SNMPv3's > security provisions via mechanisms which are less subject to > abuse, which is why I made my original posting to this list. > > I have no ax to grind in this matter -- I am only seeking > after the welfare of our product. It is, of course, possible > that I have overlooked something important which would > justify your skepticism of my current conclusions. If so, I > would value privately benefiting from the wisdom of your > insights. I similarly would value learning the insights of > any other reader with experience securing SNMPv3 for > mission-critical devices which do not sit behind firewalls. > > --Eric > > -----Original Message----- > From: Uri Blumenthal [mailto:uri@lucent.com] > Sent: Wednesday, August 06, 2003 10:32 AM > To: Bill Strahm > Cc: Fleischman, Eric; ietf@ietf.org > Subject: Re: Securing SNMPv3 via SSH tunnels > > > Bill, what is this about? Eric obviously wasn't aware > that the problems he listed applied to the older versions > of SNMP protocol, namely SNMPv1 and SNMPv2c. The current > standard SNMPv3 (which obsoletes those) is designed > specifically to address the listed vulnerabilities. > > So this whole notion of securing SNMPv3 with SSH is > ridiculous. > > > On 8/6/2003 12:34 PM, Bill Strahm wrote: > > The problem that you have with TCP (and made worse by SSH > tunneling on top of > > it) is that the number of round trips needed to > successfully get a data packet > > through is unreasonably high in a situation where you are > attempting to > > diagnose a network fault. > > > > The other choice is to leave a LOT of state open (ie. TCP > connections) > > requiring a lot of extra memory, etc. on the device. That > said there is no > > reason why you can not create a tunnel to a secure > environment and run your > > SNMP traffic from there. > > > > Bill > > > > On Wed, Aug 06, 2003 at 08:42:49AM -0700, Fleischman, Eric wrote: > > > >>I am seeking to secure SNMPv3 communications (e.g., RFC > 3414), trying to protect against its well-known > vulnerabilities such as spoofing. Had SNMPv3 run over TCP, > instead of UDP as it does, then I perhaps may attempt to > protect it via SSH port forwarding (i.e., SSH tunneling). > Coincidentally, I've just read a description in Bob Toxen's > book "Real World Linux Security" (page 141) about an approach > he has apparently used of wrapping UDP in TCP and SSH in > order to accomplish SSH port forwarding for UDP-based > protocols as well. This makes me wonder whether SNMPv3 may be > a viable candidate for SSH tunneling after all. I am > wondering whether anybody in the list has any insights as to > the viability and weaknesses of this suggested approach. I am > especially interested in learning how people on this list > secure SNMPv3. Thank you. > > > > > > > > > _______________________________________________ > This message was passed through > ietf_censored@carmen.ipv6.cselt.it, which is a sublist of > ietf@ietf.org. Not all messages are passed. Decisions on what > to pass are made solely by Raffaele D'Albenzio. >