Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document

From: [email-masked]
Date: Wed, 21 Sep 2005 17:36:52 +0300

Tero Kivinen wrote:

> Where does it say it is required to work? The normal operation
> is to use the SPIr that is set by the responder when he sets
> it. Where is the exception to this case. Note, that responder
> is supposed to be using SPIr zero, but this is the case where
> he decided not to use SPIr zero.

It's required to work, because the responder cannot distinguish 
it from a completely new attempt to establish an IKE_SA.

(Also, if you would send a non-zero SPIr, what Message ID do
you use? If the responder is keeping state (and you agree to that),
than that would imply incrementing the message ID... and if you
don't increment it, then the text about Message IDs in 
Section 2.2 is incorrect.)

<snip>

> I disagree with your interpretation of the spec...
> 
> Can you show me the place where it says that you are not allowed to
> include N(COOKIE) to the all retries IKE_SA_INIT messages?

The spec in general seems to follow the principle that it
describes how the protocol works, but not how it doesn't. For
instance, there's nothing saying that you're not allowed to
include N(COOKIE) in the CREATE_CHILD_SA exchange. Nevertheless,
I would not consider that to be part of the interoperable
behavior defined by the specification.

Thus, we're not looking for text saying "N(COOKIE) MUST NOT be
included"; we're looking for text saying it is.

Currently, what I see is text essentially saying "if the response
contains a cookie, retry the request with the cookie and all
other payloads unchanged". IMHO this would imply (even without
an explicit "MUST NOT") that if the response doesn't contain a 
cookie, you don't include it in the request either...?

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Sep 2005 19:02:19 +0300

> it from a completely new attempt to establish an IKE_SA.

True.

> Section 2.2 is incorrect.)

I am using Message ID 0, as it is IKE_SA_INIT. On the other hand I am
trying to cope with the implementation which is doing something
differently anyways, so I just try to be cope with it (I do assume he
did have some reason I do not know, and he returned me SPIr because of
he needs it). 

> behavior defined by the specification.

N(COOKIE) payloads are allowed in CREATE_CHILD_SA exchanges too. On
the other hand there is no requirement for the other end to copy them
back in any places. Notify payloads are specifically allowed anywhere:

----------------------------------------------------------------------
   A Notify Payload may appear in a response message (usually
   specifying why a request was rejected), in an INFORMATIONAL
   Exchange (to report an error not in an IKE request), or in any
   other message to indicate sender capabilities or to modify the
   meaning of the request.
----------------------------------------------------------------------

> included"; we're looking for text saying it is.

The text which says it must be replied to IKE_SA_INIT if it was
returned by the responder, do apply for later IKE_SA_INITs too. So I
would say it is mandatory to include it in all IKE_SA_INIT messages if
responder gave it to you based on the "This notification MUST be
included in an IKE_SA_INIT request retry if a COOKIE notification was
included in the initial response.".

> other payloads unchanged".

COOKIE description I quoted above is quite clear saying it must be
included in an IKE_SA_INIT request retry, and it does not say it
should be only limited to the first retry. 

> IMHO this would imply (even without an explicit "MUST NOT") that if
> the response doesn't contain a cookie, you don't include it in the
> request either...?

But the "initial response" did include the ocokie, and we are retrying
that exchange, thus we MUST include it...
-- 
[email-masked]