Re: KINK should referenece to IKEv2?

On Wed, 2005-02-02 at 11:19, Sam Hartman wrote:
> I'm not trying to require Kink to support all features that 2401bis
> requires from a key management protocol.  It's fine if on a 2401bis
> system sometimes the IPsec architecture requests Kink to set up a SA
> but Kink fails because it does not support something about the SA.
> 
> What I am requiring is that Kink work with a 2401bis system.  That is,
> the Kink specification needs to use the same terminology and model as
> 2401bis.  Similarly it needs to be possible to implement Kink on a
> 2401bis system and the only problem should be that some features
> 2401bis would like to have from an automated key management protocol
> are not available.

So from Steve's last email, I read it as our having met
your requirement since IKEv1 can still do its job on
2401bis as well as it did for 2401. A more interesting 
question is whether there's a way for KINK to easily
inherit the new/changed IKEv2 payloads that support the
2401bis features. Without having read what exactly ikev2
did to do this, it strikes me as a non-trivial issue since
it requires dragging in all kinds of "what if's" of negotiation,
downgrading, etc, but like I said I haven't looked at what
they did to the phase 2 payloads. If they did a good job
and the new "phase 2" proposals can gracefully downgrade
in the same message to ikev1 compatible proposals, it may 
be relatively straightfoward, but I'm dubious since ikev2 
doesn't even have a "phase 1" so the protocol drivers are fundamentally
different. For example: does v1/v2 they even 
run on the same port?

		Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQgEzwbMsDAj/Eq++AQJHjwP+OI2N9dLJMc/7kQhJD/kjTSGGemcf2gw3
Nm5OgeDpGkcvUXFrYCX45vnehpjEsSMK6MwaKaT9TmxukEJ10/UhcQ1RaERTlq3m
ephFZeTKRY1OL1uMSEMfbaCSB6YUT3zKb2fYThTzjRNZjaG7r2EuLlsPGRVe0AgA
8mqJGN8If8k=
=WhB2
-----END PGP SIGNATURE-----