[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and TCP
Between a pair of 586/90 boxes running BSDI, NRL IPsec, and cisco's ikmpd(8),
there is not a huge performance problem due to key management with the kinds
of things I normally do (telnet, ftp, rlogin).
In any event, a clever key mgmt implementation would acquire more than one IPsec SA
at a time and cache the extra SAs in the key engine for future use. In such a case,
there would generally be zero startup latency when locality holds (note that when
locality does not hold, any inline key management scheme would also have a startup delay
due to initial exchange of master keys (KEK) and algorithm information). Since the source
to cisco's daemon is available (modulo export controls), anyone could add that feature
to the daemon if they wished to do so. Since cisco's competitors are building products
around the freely distributable cisco daemon, it would be unwise for cisco to spend
lots of time optimising performance of its UNIX key management daemon. However,
I speculate that if someone else did such performance optimisations, cisco might well
be willing to incorporate context diffs. One would need to ask the maintainer of
cisco's daemon to ascertain their policy on contributions of course.
A couple of router vendors have implemented dynamic key management schemes
based on D-H in their products. In both of the cases that I'm aware of,
the D-H overhead is not a significant performance issue (probably in part
due to thoughtful implementations).
Ran
rja@inet.org
References: