[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: ISAKMP performance



-----BEGIN PGP SIGNED MESSAGE-----


On Tue, 15 Jul 1997 pcalhoun@usr.com wrote:
    >> Now certainly to initial boot-up where all the calls come in
    >> simultaneously is a problem (about 3 minutes), but let's look
    >> at a more serious problem. Say the average call lasts 1 hour,
    >> that means that over a 24 hour period a NAS would have to cache
    >> about 24000 enties. Assume that an SA takes up about 128 bytes
    >> (should be less, but it is easier on the math :) that would be
    >> 3Mb of cached SAs. Since we are dealing with embedded boxes,
    >> they do not have virtual memory available :(

>>>>> "Norman" == Norman Shulman <norm@tor.securecomputing.com> writes:
    Norman> Having dynamic SAs time out after an idle period of say 4
    Norman> hours would mean that even a fully loaded NAS would never
    Norman> have to cache more than 5,000 SAs, which only takes 625
    Norman> KB.


  Another way to solve this is to realize that the NAS doesn't store
the user authentication database locally either. The long term SA
(spi+keys) can be stored in the radius/tacacs server. This is
desirable, since the user may login to different NAS servers each
day. Clearly, the keys need to be protected in transit. IPsec between
the NAS and authentication server should provide that (or a physically
secure wire may be appropriate). 
  Some might worry that the keys aren't well enough protected:
however, if the user authentication packets are not breakable, then
the bad guy can just impersonate the user logging into the NAS
anyway. 

] It isn't that sun never sets; rather dawn and dusk are united | one quark   [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    | two quark   [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [





-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM8zZYMmxxiPyUBAxAQGw4QMArjH9gXj2zFhnoMiuXp9ilb+u757+dINe
faynkCdEi7hHtCc7m1tyA36C5pwXdR+QgtmJH0LfzM1tVF4cD5Yn2SeJyVJrL1so
f/umxFmbmmZi24d6CQeZ3FLjzafM4khJ
=rvFV
-----END PGP SIGNATURE-----


Follow-Ups: References: