Subject: KINK should referenece to IKEv2?

From: Shoichi Sakane <[email-masked]>
Date: Thu, 20 Jan 2005 11:15:53 +0900

In my opinion from reading the minutes at the IETF50 minneapolis,
there is no strict reason to change the referenece from IKEv1 to IKEv2
because the ISAKMP payload in the KINK is just used to carry a set of
IPsec parameters, and Notification Payloads.

---

From: Kazunori Miyazawa <[email-masked]>
Date: Thu, 20 Jan 2005 11:30:47 +0900

> IPsec parameters, and Notification Payloads.

We should have a consensus whether we will discuss KINK based on rfc2401bis
or rfc2401.

--
Kazunori Miyazawa

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 20 Jan 2005 12:20:17 +0900

> We should have a consensus whether we will discuss KINK based on rfc2401bis

Well I put on a KINK hat, if the KINK specification will conform to
rfc2401bis and if the KINK won't work on the stack based on *RFC2401*,
we won't be happy because it will take long time to deploy the stack
based on rfc2401bis.  so we need to implement a stack based on rfc2401bis
first before we will run a KINK function.

so we can have four choices while researching the difference between
2401bis and RFC2401 from KINK requirement of view:

	1. make a standard base on both rfc2401 and IKEv1.
	2. make a standard base on both rfc2401 and IKEv2.
	3. make a standard base on both 2401bis and IKEv1.
	4. make a standard base on both 2401bis and IKEv2.

I would like #1 then we proceed to #4.

---

From: Nobuo OKABE <[email-masked]>
Date: Thu, 20 Jan 2005 12:56:18 +0900 (JST)

From: Shoichi Sakane <[email-masked]>
Subject: Re: KINK should referenece to IKEv2?
Date: Thu, 20 Jan 2005 12:20:17 +0900

> I would like #1 then we proceed to #4.

I agree with your choise (i.e. #4) if we can keep new milestones
which the chairs proposed today.

My point is how stable 2401bis is.

----- nobuo

---

From: Nobuo OKABE <[email-masked]>
Date: Thu, 20 Jan 2005 13:02:59 +0900 (JST)

Sorry, I goofed.
Please ignore my previous mail.

I fully agree with sakane-san (i.e. first #1, then #4).

From: Nobuo OKABE <[email-masked]>
Subject: Re: KINK should referenece to IKEv2?
Date: Thu, 20 Jan 2005 12:56:18 +0900 (JST)

----- nobuo

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jan 2005 08:33:07 -0800

> I would like #1 then we proceed to #4.

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.

		Mike

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jan 2005 14:57:49 -0500

>>>>> "Kazunori" == Kazunori Miyazawa <[email-masked]> writes:

    Kazunori> Shoichi Sakane wrote:
    >> In my opinion from reading the minutes at the IETF50
    >> minneapolis, there is no strict reason to change the referenece
    >> from IKEv1 to IKEv2 because the ISAKMP payload in the KINK is
    >> just used to carry a set of IPsec parameters, and Notification
    >> Payloads.
    >> 

    Kazunori> We should have a consensus whether we will discuss KINK
    Kazunori> based on rfc2401bis or rfc2401.

Speaking as an AD, if 2401bis is approved by IETF 62, Kink will be
based on 2401bis.  If not, then it depends on where 2401bis is, where
Kink is, and how fast things are moving.

This decision is based on the following assumptions; if these
assumptions are false the decision should be revisited.  Making Kink
based on 2401bis will not require significant change.  Making Kink
based on 2401bis will not create significant confusion for 2401
implementers.  Making kink based on 2401bis will not require
significant work for people who have mostly complete kink
implementations.

Note that I have not made the claim that kink should be based on ikev2
instead of ikev1.  I've made a related claim: the WG must come to
consensus on whether kink implements features like multiple SAs
between the same nodes that are supported by 2401bis but not 2401.  If
the working group decides not to support all the things that 2401bis
requires from ikev2, then the wg needs to explain why it made that
decision.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jan 2005 15:02:07 -0500

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

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

My understanding is that 2401bis supports both ikev2 and ikev1.
However 2401bis has SPD entries that cannot be satisfied by ikev1.
I.E.  2401bis allows multiple SAs to exist between the same two peers.  

There are things that ikev2 can negotiate that a pure 2401
implementation would not support.

I believe it would be OK to have an ikev2 implementation that simply
made sure not to do that.

--Sam

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 27 Jan 2005 14:35:07 +0900

> Kink is, and how fast things are moving.

I dont understand why KINK will be based on 2401bis when 2401bis
is approved by IETF62.  There are lots of platforms based on 2401.
KINK should be based on 2401 in order to deploy it.  If the market
will not choice 2401bis and if a kink implementation based on 2401bis
does not work on a platform based on 2401, then KINK will not deploy.

it is not easy to know how difference between 2401bis and 2401,
and it is not easy to know if a key management daemon based on
2401bis will work on a platform based on 2401.  so I said in previous
mail that we should make kink based on 2401 then make kink based on
2401bis.  kink header has a version field.

---

From: Kazunori Miyazawa <[email-masked]>
Date: Fri, 28 Jan 2005 14:17:27 +0900

> 2401bis.  kink header has a version field.

I agree with Sakane-san.

I think if kink is based on 2401bis, it would use IKEv2 instead of ISAKMP.
If it uses IKEv2, I guess there are conflicts which are rekeying and dead peer
handling because IKEv1 does not mention those process and KINK specifies it by
it self. Changing for IKEv2 and resolving new issues need a long time.
I think we should go with 2401.

--
Kazunori Miyazawa

---

From: Nobuo OKABE <[email-masked]>
Date: Fri, 28 Jan 2005 15:08:03 +0900 (JST)

From: Kazunori Miyazawa <[email-masked]>
Subject: Re: KINK should referenece to IKEv2?
Date: Fri, 28 Jan 2005 14:17:27 +0900

> I think we should go with 2401.

I also agree with Sakane-san.

And I have an observation.

    Our discussions will be more productive
    if we can categorize issues.

    Some issues were based on Kerberos clarification
    and/or kcrypt, some were on 2401bis,
    some were on IKEv2 and so on.

    We can go forward with Kerberos related issues
    even if we can not solve 2401bis and/or IKEv2 related issues
    which may need long time to be solved.

----- nobuo

---

From: Sam Hartman <[email-masked]>
Date: Fri, 28 Jan 2005 16:10:18 -0500

Kazunori> Shoichi Sakane wrote:
    >>> Speaking as an AD, if 2401bis is approved by IETF 62, Kink
    >>> will be based on 2401bis.  If not, then it depends on where
    >>> 2401bis is, where Kink is, and how fast things are moving.
    >> I dont understand why KINK will be based on 2401bis when
    >> 2401bis is approved by IETF62.  There are lots of platforms
    >> based on 2401.  KINK should be based on 2401 in order to deploy
    >> it.  If the market will not choice 2401bis and if a kink
    >> implementation based on 2401bis does not work on a platform
    >> based on 2401, then KINK will not deploy.  it is not easy to
    >> know how difference between 2401bis and 2401, and it is not
    >> easy to know if a key management daemon based on 2401bis will
    >> work on a platform based on 2401.  so I said in previous mail
    >> that we should make kink based on 2401 then make kink based on

    Kazunori> I agree with Sakane-san.

    Kazunori> I think if kink is based on 2401bis, it would use IKEv2
    Kazunori> instead of ISAKMP.  

That would be a valid way of making Kink based on 2401bis.  It seems
like a lot of work and I am not sure it is in the best interest of the
working group to choose to make Kink work with 2401bis that way.

Again, I did present the assumptions under which I decided to require
2401bis.  You would need to show me that one of those assumptions is
wrong in order to convince me to change my mind.

--Sam