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

At Tue, 22 Feb 2005 12:53:29 +0900,
Shoichi Sakane <[email protected]> wrote:
> 
> > > Maybe it should be more specific so that a sender
> > > can know that it's really the KE payload that's
> > > causing problems?
> > 
> > I agree with you, however there is no suitable error type in both RFC2408
> > and the IKEv2 specification.  INVALID_KE_PAYLOAD would be better, but the
> > meaning is slightly different from this context.  do you have any idea ?
> 
> > > Another possibility that I haven't
> > > looked at yet is for the receiver to _not_ send its
> > > KE payload back in which case the sender would realize
> > > that the receiver didn't perform the DH and it could
> > > proceed as if the sender KE wasn't present at all?
> > 
> > could you explain me with another word ?  i could not understand what
> > you said.  probably language issue. i am sorry.
> 
> I have understood what you mean.  so the responder has three choices
> when it receives a KE payload.  that is:
> 
> 	- return a notify payload with INVALID_KE_PAYLOAD.
> 	- return a notify payload with NO_PROPOSAL_CHOSEN.
> 	- reply without KE payload.
> 
> so I would like to propose the following process.  any idea ?
> 
>    All node conformed to the document MAY implement the KE payload
>    handling.  If a node receives a KE payload, and the receiver does not
>    support the KE handling, and does not want to proceed the negotiation,
>    then the receiver SHOULD send a Notify payload of the type
>    NO_PROPOSAL_CHOSEN to the sender.  If the receiver wants to keep the
>    negotiation without the KE payload handling, then the receiver sends
>    a response witout a KE payload.  the sender MAY reject it by its policy
>    in this case.

The sender (I assume you meant the initiator) can't reject it
because the ACK message can't carry it.


>    If the receiver does not want to process the KE payload by its policy,
>    the receiver SHOULD send a Notify payload of tye type INVALID_KE_PAYLOAD
>    to the sender.
>    Notification Data MUST contain the KE payload in both case.  the Protocol
>    ID MUST be 1, and the SPI Size MUST be zero.

What is the difference between NO_PROPOSAL_CHOSEN and
INVALID_KE_PAYLOAD?  "Not supported" and "Rejected by policy"?

-- 
KAMADA Ken'ichi <[email protected]>