On Sat, 25 Feb 2006, Matthew Closson wrote:
On Sat, 25 Feb 2006, Joachim Schipper wrote:
On Sat, Feb 25, 2006 at 10:29:11AM -0500, Matthew Closson wrote:
Rather than have isakmpd bring up all tunnels when the daemon starts up,
is there a way to have it bring up the tunnels on demand? For example.
host_a ----> router_b <------------> router_c <----- host_d
Is there a way to setup isakmpd so that if host_a tries to send a packet
to host_d, router_b will start IPSEC negotiation with router_c at that
point, instead of as soon as isakmpd starts?
Why would you want to do that? It's not like keeping a tunnel up will
use any significant amount of resources, while on-demand tunneling will
prove to impose quite a bit of delay.
Joachim
Some of my IKE-peers seem to operate this way. For example more than one
cisco admin has called me to ask why we have active tunnels but no data going
through them. And some remote implementations such as Sonicwall seem to take
the tunnel down when there is being no data passed back and forth without
sending me a teardown notify message. I realize that on-demand tunneling
will present a delay to startup the tunnel, but I am still curious to know if
it is possible to do this on OpenBSD/isakmpd and how I might go about doing
it. Thanks,
-Matt-
Okay so I've been trying to find out exactly how cisco handle's
renegotiation when lifetime's expire and I found this:
----------------------------------------------------------------
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt4/scipsec.htm#xtocid2141715
How These Lifetimes Work
Assuming that the particular crypto map entry does not have lifetime
values configured, when the router requests new security associations it
will specify its global lifetime values in the request to the peer; it
will use this value as the lifetime of the new security associations. When
the router receives a negotiation request from the peer, it will use the
smaller of either the lifetime value proposed by the peer or the locally
configured lifetime value as the lifetime of the new security
associations.
The security association (and corresponding keys) will expire according to
whichever comes sooner, either after the number of seconds has passed
(specified by the seconds keyword) or after the amount of traffic in
kilobytes is passed (specified by the kilobytes keyword). Security
associations that are established manually (via a crypto map entry marked
as ipsec-manual) have an infinite lifetime.
A new security association is negotiated before the lifetime threshold of
the existing security association is reached, to ensure that a new
security association is ready for use when the old one expires. The new
security association is negotiated either 30 seconds before the seconds
lifetime expires or when the volume of traffic through the tunnel reaches
256 kilobytes less than the kilobytes lifetime (whichever comes first).
If no traffic has passed through the tunnel during the entire life of the
security association, a new security association is not negotiated when
the lifetime expires. Instead, a new security association will be
negotiated only when IPSec sees another packet that should be protected.
----------------------------------------------------------------------
So lets say I establish a tunnel between a cisco device and OpenBSD and
3600 seconds later lifetime expires but no traffic has been passed during
the entire life of the security association. OpenBSD will try to
renegotiate the security association, will the cisco as well, or will it
not because there is no traffic has taken place which would actually use
the tunnel?
-Matt-
