Re: IPsec by David
David
Tue Aug 12 01:32:26 CDT 2003
Technically the effect would be a complete failure to communicate as PFS is
going to be needed to be turned on for all peers, not just the server.
Performance will be hindered as it takes a couple seconds to generate all
new keying material (the diffie-helman computations are intensive). If your
quick mode lifetimes are long, then this isn't as big a deal since you
wouldn't need to do it that often, however if you've got shorter lifetimes
you could start seeing problems on slower or heavily used machines. Client
side, you'll find that many applications don't respond well to noticeable
losses in connectivity during a session. They start throwing up error msgs
or freezing user input which is very disconcerting. On the server you'll see
the cpu chugging harder as it's generating more and more keys for all your
clients.
So should you, or shouldn't you turn on PFS? As with all security concerns,
it's a matter of comfort. Take a look around the web and I'm sure you'll
eventually find sites (upstanding and otherwise) which will enumerate the
typical amount of time it would take to crack a key. Some of the options
would take years to crack. Compare that with how much data you expect could
be compromised during the lifetime of your keys (eventually a connection
will either be shut down, or run out of re-keys forcing a complete rebuild
of the ipsec session) and how likely such data would be detrimental to your
organization.
You may decide that instead of setting the Quick Mode PFS option, you just
set the re-key value from 0 (which actually means unlimited) to something
like 2 or 3 and lower the lifetime of your quick modes such that you'll just
create new ipsec sessions every half hour. You can do the same trick by
extending the lifetime of your quick modes a bit, but turn on Main Mode PFS
(which is just a UI shortcut for setting the quick mode rekey value from 0
to 1). A question you might have is: if I'm going to play around with the
lifetimes, why don't I just extend the the quick mode lifetime, and turn on
quick mode pfs, thus saving the trouble of doing the additional peer
authentication step that is done during main mode? The answer would tie back
to the first sentence of this post which is that quick mode pfs would
require both peers set, while changing main mode settings does not.
Additionally, it should be noted that the Require and Respond policies
aren't really meant to be used together without some modification. There are
instances where one side will expect to send data in the clear while the
other side may require the data to be secured and drop the packet; eg, ICMP
is usually needed in the clear but the default response filters that get
plumbed on the client are for all traffic. In fact, none of the
out-of-the-box policies are really meant for user consumption. They should
be used as examples to help you build the most appropriate policy for your
environment; few environments are simple enough to only use these basic
rules.
Here's an example of a rather basic hurdle you'd need to handle if you just
stuck with the default server Require policy: This policy requires all
traffic, except ICMP, to be ipsec secured using kerberos as an
authentication method. This means that when you need to talk to the DC, that
traffic needs to be secured using a valid kerb ticket. Now what if you're
actually in the process of trying to get your kerb ticket?
--
David
Microsoft Windows Networking
This posting is provided "AS IS" with no warranties, and confers no rights.
"Lin" <rlinkc@hotmail.com> wrote in message
news:044101c35e22$6c2af740$a601280a@phx.gbl...
> the IPsec policy for the domain, w2k server (require) w2k
> pro (respond)
> what would be the effect of setting perfect forward
> secrecy on win2k server?
> using new key everytime would be more secure?
>