Re: #23 [*] KE interoperability (section 6.8)

> > I haven't looked it up in the draft, but my feeling is
> > that the Receiver MUST implement KE payloads, though
> > I suppose that it may be administratively rejected with
> > an error message if it doesn't want to participate. 

I disagree.  it must reduce the value of using KINK.

> > IKEv1 doesn't define it because it always expects that
> > the initial DH is performed; KINK doesn't require this
> > since there's already a shared key in the ticket.

I am assuming that "the initial DH" means the group number used
in phase 1.  If so, there is no description in RFC2409 to use
the same group in phase 2 when the negotiation uses KE payload.
actually, it brought an interoperability problem at the test event.
so we have to describe what KINK do that.

> Sakane-san's point (as far as I can read) is that
> if KINK allows using KE payloads, the following 3 issues
> should be considered.  I think only the 3rd item needs additional
> text to the KINK spec.
> 
> - Which error code is returned when the responder doesn't support KE,
>   if we go with IKEv1.
>   (I think INVALID-PAYLOAD-TYPE is enough.)
> 
> - KINK (nor IKEv1) doesn't negotiate DH group,
>   so the operators must agree the group in advance.
>   (I don't know whether KINK spec needs to describe this though.)
> 
> - KINK initiators usually set inbound SAs before CREATE command,
>   but it's not possible when using KE payloads.

Thank you for the clarification.

> > > and an initiator can not install the inbound SA when the initiator
> > > choices to send KE because KEYMAT is not calculated before the initiator
> > > receives KE from the responder.  the document has to touch this situation.

I noticed what the document probably does not touch.  When a responder
accepts the KE from the initiator, it would be better that the responder
SHOULD(or MUST) add ACKREQ bit to the response message in order to be
less packet loss.