[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
David_Mason@nai.com ("Mason, David") writes:
> On further thought, it seems that sending keepalives while there are TCP
> connections open or for an N minute linger period really only helps the
> transport case (so that the decapsulated packet is guaranteed to have the
> same source address after a rekey).
>
> Keeping the NAT mapping alive so that the "outside" peer can rekey doesn't
> work unless that peer maintains information about SAs that no longer exist
> (this would have to be done in both the kernel and in the IKE daemon). If a
> rekey is required when an SA expires it will generally have been performed
^^^^^^^^^
> already so as to provide lossless rekey.
>
> The inside peer can rekey at any time - it will just cause a new NAT mapping
> to be created. In the tunnel case this shouldn't cause any problems. Did I
> miss something here?
Possibly - but if you do that, you have to do (computationally considerably
more expensive) Phase I every time too, because the IKE mapping _may_ have
reset then also (_even_ if your Phase I lifetime hasn't expired.. I think
that running IKE over NATs is bad idea to start with :>).
It's debatable if 5 minutes is the right way to do it, but _some_ way of
making sure that (even potentially somewhat delayed) Phase II is 'enough'
to handle the rekey cases.
Admittedly, I think this is mostly rare case because typically you'd have
rekey occur _way_ before the old SA dies as you pointed it out. Some
implementations seem to assume that soft ==~ hard limit, though, making too
optimistic guesstimates about when to rekey.
> -dave
-Markus
--
Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)