Subject: RE: [Isms] TLS / SSH scalability concerns

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 12 May 2005 14:49:08 -0700

FYI (in case you not already know):

http://www.umiacs.umd.edu/docs/Du.ppt

They concluded that SNMP/TLS was more efficient than USM.  Anyway, these
results need to be taken w/ a grain of salt as there are many factors
(e.g. # msgs per session) that may affect the results.

Khanh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Thursday, May 12, 2005 2:10 PM
> To: Kaushik Narayan (kaushik)
> Cc: [email-masked]
> Subject: [Isms] TLS / SSH scalability concerns
> 
> On Thu, May 12, 2005 at 01:16:01PM -0700, Kaushik Narayan wrote:
> 
> > With protection at the transport layer, SNMP engines, for e.g. will 
> > need to open new connections even all they might be doing is 
> > collecting operStatus every minute, the other option is to 
> have long  
> > lived connections and typically with a ratio of 10,000:1 between 
> > managed elements and management systems that would be a lot of open 
> > connections. Long lived connections also have the side 
> effect that TLS 
> > cipher suites negotiated during connection establishment will apply 
> > for the length of the connection. This would result in same 
> protection 
> > for all SNMP data transported during the lifetime of a connection 
> > irrespective of whether it is configuration, operational or 
> > performance data (isn't this why there was securityLevel in 
> every SNMPv3 message).
> 
> Are your products really choosing a different securityLevel 
> depending on whether they operate on configuration, 
> operational or performance data?
> Is this the default setup or something someone could in 
> principle configure?
>  
> > In the past when we tried to run SNMPv2c over IPSec and it failed 
> > miserably since management systems typically hosted on 
> desktops with 
> > 500MB of RAM could not scale to even 10s of devices and in 
> most cases 
> > operators are managing tens of thousands.
> 
> Do you really poll 10,000 boxes from a single centralized 
> manager? And does your management software running on a 500MB 
> desktop really scale to tens of thousands of boxes with 
> SNMPv3 security enabled?
> 
> What I recall from other big companies selling management 
> products is that they usually ask customers for some quite 
> powerful hardware even to manage modest networks and that 
> these vendors are usually very proud of their distributed 
> data collection engines...
> 
> But I do agree with you that scalability in the number of 
> devices that can be polled is a critical point to have in 
> mind when moving to a TLS transport. For situations where you 
> poll a single variable from a very large number of nodes, TLS 
> will raise overhead. On the other hand, if the data you like 
> to poll does not fit into a few tiny PDUs anymore (and that 
> is often already the case if you poll a few ifTable columns 
> from an IEEE 802 switch these days), then a TCP based 
> transport will at some point become more efficient due to 
> larger message sizes and all the nice things that TCP does 
> for you. (And I assume you are aware of the various 
> proprietary ways to ship larger SNMP data sets via protocols 
> such FTP to overcome SNMP's relatively poor performance for 
> larger data sets.)
> 
> I do agree that scalability needs to be taken into account 
> and that this is a real issue (while repairing broken 
> networks with SNMP really is a myths in my view a non-issue).
> 
> My personal take on this is that SNMPv3/USM is out there and 
> going to stay so in cases where you need high end small-data 
> lots-of-devices polling engines, you can still use SNMPv3/USM 
> (and you have to pay the price for the key management or you 
> resort to noAuth/noPriv to avoid lengthy computations). For 
> the more bulky-data medium-number-of- devices situations, I 
> do not think TLS will be unfeasible. Note that I am reading 
> my email using imaps and I you can be sure that I am not the 
> only imap reader on our IMAP server polling mail boxes, which 
> BTW is just one of these many Intel PCs.
> 
> /js
> 
> P.S. If you have contacts to customers who are polling 10,000+ devices
>      from a single centralized server, please ask them whether they 
>      are willing to support research by capturing traces, running them
>      through analyzers and and giving condensed information 
> to the NMRG. 
>      I like to see some more substance added to scalability 
> discussions 
>      such as this one by having some reliable data sources 
> and traffic 
>      models.
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 16 May 2005 15:20:23 -0700

>>>>> On Thu, 12 May 2005 14:49:08 -0700, "Khanh Nguyen (khanhvn)" <[email-masked]> said:

Khanh> FYI (in case you not already know):
Khanh> http://www.umiacs.umd.edu/docs/Du.ppt

After that presentation was given, I actually stood up to the
microphone and explained a number of the biases in it that made it an
unfair comparison.  In summary, they were comparing an optimized
implementation that had been around for a while against one that had
never been optimized and was even implemented in less-than-optimal
ways at times due to the fact it was supposed to be a reference
implementation.  The authors agreed that their data was based on the
only 2 data points and they couldn't do a better analysis since they
had no other data to go by and that the margin of error was likely
fairly high.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 16 May 2005 15:42:10 -0700

>>>>> On Mon, 16 May 2005 15:20:23 -0700, Wes Hardaker <[email-masked]> said:

Wes> After that presentation was given, I actually stood up to the
Wes> microphone and explained a number of the biases in it that made it an
Wes> unfair comparison.

I should follow that up with it's not that I don't believe that the
results are true.  They may be.  I just don't trust that particular
data set at all to draw that conclusion from.

-- 
Wes Hardaker
Sparta, Inc.