Subject: Re: KINK should referenece to IKEv2?

From: Shoichi Sakane <[email-masked]>
Date: Wed, 02 Feb 2005 11:14:06 +0900

> Somebody will need to help me (us) here: can
> IKEv1 successfully establish 2401bis SA's? Can
> IKEv2 successfully establish 2401 SA's? I'm _guessing_
> that the answer to both is "yes", but the big question
> is whether there's anything in IKEv2 what is exchanged
> across the wire to inform the other side whether it's
> 2401 or 2401bis. If so, we may need a similar mechanism.

Stephan Kent who is 2401bis author answered to my question
in the ipsec mailing list:

	2401bis implicitly establishes requirements for certain features for
	a key/SA management protocol to enable systems to make full use of
	the IPsec features defined in 2401bis. IKEv2 satisfies these
	requirements; IKE v1 does not. It's way too late to suggest that we
	degrade requirements in 2401bis to be backwards compatible with IKE
	v1.

it seems that IKEv1 does not work on 2401bis.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2005 14:19:35 -0500

[Adding Steve to make sure I'm not misrepresenting what he means.]

>>>>> "Shoichi" == Shoichi Sakane <[email-masked]> writes:

    >> Somebody will need to help me (us) here: can IKEv1 successfully
    >> establish 2401bis SA's? Can IKEv2 successfully establish 2401
    >> SA's? I'm _guessing_ that the answer to both is "yes", but the
    >> big question is whether there's anything in IKEv2 what is
    >> exchanged across the wire to inform the other side whether it's

    Shoichi> Stephan Kent who is 2401bis author answered to my
    Shoichi> question in the ipsec mailing list:

    Shoichi> 	2401bis implicitly establishes requirements for
    Shoichi> certain features for a key/SA management protocol to
    Shoichi> enable systems to make full use of the IPsec features
    Shoichi> defined in 2401bis. IKEv2 satisfies these requirements;
    Shoichi> IKE v1 does not. It's way too late to suggest that we
    Shoichi> degrade requirements in 2401bis to be backwards
    Shoichi> compatible with IKE v1.

    Shoichi> it seems that IKEv1 does not work on 2401bis.

That's not how I read what Steve is saying.  A 2401bissystem can
support IKEv1.  However the 2401bis SPD can require the system to do
things that IKEv1 cannot do.

Put another way, a 2401bis system can have multiple key management
protocols.  At least one of these protocols needs to support all the
attributes of a 2401bis SPD.  For this reason and because it is
explicitly required, 2401bis systems MUST support ikev2.

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.

--Sam

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 14:47:21 -0500

>[Adding Steve to make sure I'm not misrepresenting what he means.]

Sam,

Your characterization of 2401bis is correct, i.e., if one chooses to 
use IKEv1 with a 2401bis implementation, then it may not be possible 
to instantiate some SAs, i.e., ones that make use of new SPD features.

Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Feb 2005 12:10:41 -0800

> 2401bis would like to have from an automated key management protocol

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2005 15:22:38 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> So from Steve's last email, I read it as our having met
    Michael> your requirement since IKEv1 can still do its job on
    Michael> 2401bis as well as it did for 2401. 

More or less.  There are issues like the SPD PAD split that need to be
addressed in the document.  Similarly, we need to confirm that the
text added about rekey timeouts does not conflict with kink.  But I do
expect the answer to this question to be yes.

    Michael> A more interesting
    Michael> question is whether there's a way for KINK to easily
    Michael> inherit the new/changed IKEv2 payloads that support the
    Michael> 2401bis features. 

Or whether there is an easy way to get this functionality.  Note this
is not a requirement I have, but I do agree as an individual that it
is at least worth thinking about.

I think the main 2401bis feature is multiple SAs between two
destinations.  Kink actually already has this capability.  It may be
that by changing the text slightly and removing the requirement on
selecting which SA to use if multiple SAs exist, we can get most
2401bis functionality.

--Sam

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 17:03:36 -0500

Sam,

>selecting which SA to use if multiple SAs exist, we can get most

2401 already requires support for multiple SAs between a pair of 
peers. What 2401bis adds is a requirement to support these multiple 
SAs to have identical selectors, and where we are not just replacing 
one SA with a successor.

Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Feb 2005 15:25:31 -0800

> SAs to have identical selectors, and where we are not just replacing 

We're somewhat far afield of KINK, but what was this
for? Load balancing? QoS treatment? 

		Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Feb 2005 18:27:14 -0500

>for? Load balancing? QoS treatment?

QoS.

Steve

---

From: Masahiro =Rhythm Drive= Ishiyama <[email-masked]>
Date: Thu, 03 Feb 2005 12:22:41 +0900

>>>>> On Wed, 2 Feb 2005 14:47:21 -0500, Stephen Kent <[email-masked]> said:
 > 

	I'm getting a little bit confused. If I understand correctly,
	we can implement KINK that works with 2041bis-based IPsec
	stack, using IKEv1 payload. So how about the opposite side? I
	mean, can we implement KINK that works both 2041-based and
	2041bis-based IPsec stack? As some people mentioned before,
	there are already so many 2041-based IPsec stacks in the
	market. Basically I want a KINK daemon/application/whatever
	that works on existing 2041-based systems, but I wish that
	code conforms the KINK-RFC-specification.

masahiro

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 03 Feb 2005 15:04:57 +0900

> SAs to have identical selectors, and where we are not just replacing 

2401bis requires a system complies 2401bis to handle multiple SAs
with same selector, but different "classifier" between same two nodes.
it means that it requires a key management protocol to establish
multiple SAs somehow.  i think that current kink specification can do that.

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 04 Feb 2005 12:29:10 +0900

My point was that I would not be happy that KINK based on 2401bis did not
work on an 2401 base platform due to market issue.  So I suggested that
it would be better to fix the specification based on 2401 first.

But, I change my mind.  I probably confused.  KINK can be based on
2401bis and can support its all feature like IKEv2.  In this case when
KINK runs on 2401, KINK doesn't use of its feature related to 2401bis,
that is all.  In fact, our IKEv2 pre-implementation based works fine
on a 2401 platform.  But it must be too much for KINK requirement
to support all feature of 2401bis.

So As I read Sam's last mail, my current opinion is that:

	- we have to describe the document complying with 2401bis wording
	  and its model.
	- we don't need to make KINK which supports all feature of 2401bis.
	- if above two are true, we don't need to take IKEv2 format by force.
	  just use almost current payloads.
	- however we have to describe how KINK works on 2401bis.
	- we have to also describe what KINK dosen't support the features
	  although it may be unnecessary.

Here is Sam's assumptions:
	1. Making Kink based on 2401bis will not require significant change.
	2. Making Kink based on 2401bis will not create significant
	   confusion for 2401 implementers.
	3. Making kink based on 2401bis will not require significant work
	   for people who have mostly complete kink implementations.

#1 is almost true.  I believe that we don't need significant change of
KINK specification, but we need to work improving the text a lot.
#2 is true.  because we don't need significant change of KINK
specification from #1.
#3 is true. because from #2.

Well, at least for me, there is no reason that we are sticking
to current specification related to 2401.