implementor's view of ikev2 simul rekey

[jeff pickering <jppcreekside@yahoo.com>]

Given that we have 3 weeks for CP v DHCP, I would like
to add some text to the simul rekey area because it
addresses a real issue and the solution is simple.

The issue is that any approach to the simul reky
problem
needs to address 2 issues:

1) The first is the prevention of the socerer's
appretice
problem where multiple rekey could result in an
expanding
number of rekey'd SAs. The current text rightly notes
that the potential exists for a rekey to result in
multiple SAs and goes on to say that these must be
detected and each side should discard one of the
duplicates. Unfortunately, it doesn't specify which SA
should be deleted. This could result in each side
simultaneously deleting different SAs which could
cause
temporary connectivity loss. Since prevention of this
by specifying which SA should be deleted would be
trivial, I dont see any reason for not adding text to
the spec for doing this. For example, text could be
easily added saying to keep the rekeyed SA created by
the original SA initiator.

2) The second problem that needs to be addressed is
the "whose child is this" problem. This arises during
simul rekey of IKE SAs because child SAs that exist
prior to rekey are inherited by the rekeyed IKE SA,
but if multiple IKE SAs exist for a short period, you
can't tell which new IKE SA is the inheritor. Each
side could think differently. This is currently
addressed in the  spec by saying that a child request
should be accepted on either of the SA's. But from an
implementor's viewpoint (admittedly mine), this is
truly ugly. As an alternative, I would like to propose
a very simple alternative that, IMHO, is simple and
clean. This would be to prevent duplicate SA creation
by using a tie-breaking mechanism that states when an
attempt to simul rekey is detected (which must be done
per current spec anyway, ie detect and incoming reky
request when you have sent a rekey request but have
not yet received a response), you allow only the
preferred rekey to succeed (eg request by original
initiator). This also
has the added benefit of being forward compatible with
allowing multiple equivalent SAs for QOS. Without
this, my belief is that there will be an
interoperability problem adding this in the future.

In summary, Im suggesting at a minimum a text change
to spec which duplicate should be deleted. I also
propose a simple enhancement which could totally
prevent duplicates using a mechanism equivalent to
that used for the same purpose by BGP and has been
field proven.
I dont propose text changes today but would be willing
to do so if this is of interest.

Regards,
Jeff

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com