[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC Key Management performance model
- To: ipsec@ans.net
- Subject: IPSEC Key Management performance model
- From: "marcus (m.d.) leech" <mleech@nortel.ca>
- Date: Mon, 27 May 1996 12:27:13 -0400
- Organization: Nortel Technologies, System Security Services
- Sender: ipsec-approval@neptune.tis.com
- X400-Content-Type: P2-1984 (2)
- X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<199605271627.AA144104433@bcarh6]
- X400-Originator: mleech@bcarh6dc.ott.bnr.ca
- X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 27 May 1996 12:27:59 -0400
- X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 May 1996 12:27:59 -0400
- X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 May 1996 12:27:59 -0400
- X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 May 1996 12:27:59 -0400
-----BEGIN PGP SIGNED MESSAGE-----
I'm growing increasingly concerned about the *potential* performance problems
of PK-based key management in a large infrastructure like the Internet.
Has anyone done any models, or is there any "real" data on the expected
performance in performance-hungry situations like large servers with
very large, dynamic client bases?
How are existing SSL-based servers coping with large dynamic client bases
(in which session-key caching doesn't do you very much good). Real-world
numbers with large SSL servers can at least give us an approximation of
the expected performance of IPSEC Key Management. If security association
establishment takes 0.1 cpu-seconds, for example, then a server in which
the arrival of new security association requests exceeds a handful
per second will be completely unable to do its "real" work.
Am I unduly pessimistic, or do "real-world" numbers with large SSL servers
show that there's a potential problem? Is there a free lunch? Why does it
always rain immediately after you've watered the lawn? If seven layers is
the answer, what is the question?
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQBVAwUBManX36p9EtiCAjydAQE78wIAsdOiP5MovTxuvc4SmV5VGK42qVRR5Yq7
D56RE9T39BE61Iuu11XXlOONSVsGAWQsz8JcqELeObEwTtq4J8B/bw==
=65ox
-----END PGP SIGNATURE-----
--
----------------------------------------------------------------------
Marcus Leech Mail: Dept 4C16, MS 238, CAR
Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145
Systems Security Services Fax: (ESN) 393-7679 +1 613 763 7679
Nortel Technology mleech@nortel.ca
-----------------Expressed opinions are my own, not my employer's------
Follow-Ups: