On Sat, Mar 04, 2006 at 10:28:39AM -0500, Matthew Closson wrote:
> 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
<...>
> 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.
<...>
> 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?
This is, I suppose, implementation defined. Which is to say, IPsec
specifies that rekeying must be done (as you posted above), and that it
is possible to start a new connection or tear an old one down, but I do
not think it specifies some sort of timeout-due-to-lack-of-data (some
schemes, like Dead Peer Detection, for detecting if neither side is out
to lunch aside).
If you have Cisco gear, you can just try it out. I have heard good
things about interoperability of OpenBSD's IPsec implementation, so I
feel confident stating that it should work - though I am not sure in
exactly what way.
Joachim
