[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
rekeying issues, was Re: FW: IPSec Monitoring MIB works for IPv4 only?
Yea, you're right. I'm somewhat baffled by the re-keying issue. At
the Raleigh bakeoff and at the Binghamton bakeoff there was quite a
bit of re-keying done. In fact, in Raleigh there was a 6 or 7 vendor
mesh (each had 5 or 6 peers) with re-keying every 5 minutes or so. This
went on for a couple of hours until people got distracted and tore
their node down to do other things.
In Binghamton I did re-keying with a few vendors (like 4, I'd have
to check my notes) and as far as I know none did what was proposed
in draft-jenkins-ipsec-rekeying-00.txt and, from my brief discussions
with 2 of the implementors I successfully rekeyed with, we did things
subtly different and it still worked. The draft mentions quite a
bit of conditional state that must be maintained, like creating but
not using outbound SAs until traffic is received on the inbound SA,
that is difficult to maintain and also might have its own issues.
Perhaps if the vendors who've exhibited successful rekeying (I can
think of SSH, TimeStep, Checkpoint, Cisco, Radguard, Network Alchemy, IRE,
TIS off the top of my head, but that is not meant to be a complete list
and I apologise in advance if I didn't mention anyone with whom I did
successfully re-key) just documented what they do this might cease to
be an issue.
Dan.
On Mon, 23 Nov 1998 14:21:50 EST you wrote
> The re-keying issues aren't there.
>
> For my opinions on that see
> <ftp://ftp.ietf.org/internet-drafts/draft-jenkins-ipsec-rekeying-00.txt>.
>
> This document also expresses our concerns with the delete notification and
> its use.
>
> I will be updating this (sometime) to reflect the view that there should be
> more than one phase 1 SA allowed between peers.
Follow-Ups:
References: